Integrating the Health care Enterprise (IHE) is an organization founded by medical professional societies in 1998 together with the health care IT industry [12]. Its aim is to improve the integration of application systems in health care and to check and certify if application software products to be used for the application systems have the process interoperability needed for this integration.

The approach taken by IHE is to analyze typical work processes occurring in health care. IHE identifes the application systems involved in these processes and the information that should be exchanged between these application systems to support the diagnostic and therapeutic processes as good as possible. For example, IHE has defned working processes in the form of "integration profles" for areas such as cardiology, pathology, radiology, and pharmacy. It has also defned integration profles for the exchange of clinical documents between different health care facilities (IHE XDS, Sect. <IP_ADDRESS>).

IHE then selects existing standards, i.e., especially HL7 V2 and DICOM, for each "transaction" (information exchange between application systems) and restricts the options offered by these standards for each transaction so that plug-andplay interoperability becomes possible.

By defning work processes, IHE supports process interoperability. Together with standards such as HL7, HL7 CDA, HL7 FHIR, openEHR, and DICOM, it indirectly supports syntactic and semantic interoperability.

IHE furthermore offers comprehensive test software enabling vendors to test their products' interfaces for IHE-conformant process interoperability and organizes large cross-vendor testing events called "IHE Connectathons" (from "connection" and "marathon").

IHE is not a standards body as such but flls a very important gap by selecting the most appropriate set of standards for a typical clinical workfow. It reduces the indeterminacy of the way of interaction, for example, between HL7 V2 and DICOM, by proposing clear rules for their joint use. The resulting technical specifcations are published annually as the IHE Technical Frameworks.

Although the profles are not communication standards, they gain normative character through their increasing dissemination and can be regarded as quasistandards for the use of communication standards.

**Fig. 3.29** IHE XDS.b actors and interactions (simplifed), using the example of a radiology report. #1–#6 indicate order of messages

#### **<IP_ADDRESS> IHE Cross-Enterprise Document Sharing (XDS)**

One of the above-mentioned technical frameworks is the IT Infrastructure Framework (ITI), which specifes standards-based implementations for exchanging clinical information. Among other things, it describes how to share documents between different health care organizations. IHE Cross-Enterprise Document Sharing (IHE XDS) is used, for example, for the Austrian ELGA (national EHR) and partly in the German Medical Informatics Initiative.

IHE XDS defnes neither the content of these documents nor their internal structure, making it "content-agnostic." Instead, it defnes actors along with their interactions and integration profles of both these components. IHE XDS.b is a prominent integration profle defning affnity domains and actors.

Figure 3.29 shows the actors in this profle and their interactions. A source system (e.g., an *RIS*) provides a new document, for example, a radiology report on Mr. Russo, along with its metadata to the document repository. This document is then registered in a document registry. A document consumer, for example, another clinical application system, such as the *MDMS*, at a different site in the health care network, can query the document registry to locate a relevant document and then query and subsequently retrieve this document from the decentral document repository. Document repositories are usually decentral, while the registry is central.

#### **<IP_ADDRESS> ISO/IEEE 11073**

The ISO/IEEE family of standards for the exchange of data between medical devices comprises, for example, a standard for exchanging bio-signals and vital parameters between point-of-care devices [13]. Furthermore, the standard enables a dynamic exchange and reconfguration of devices and remote control, for example, of infusion pumps.

Medical devices can be considered as combining an application system at the logical tool layer with a dedicated physical data processing system at the physical tool layer, which is often also called an appliance.

ISO/IEEE 11073 can be used, for example, to receive and display data from infusion pumps, respirators, ECGs, etc. on patient monitors in the ICU and for integrating medical devices in operating rooms. It is also used for receiving data from mobile wellness devices (e.g., ftness tracker) and personal health applications (e.g., diabetes app).

ISO/IEEE 11073 supports technical interoperability by defning a complete communication protocol stack and, for example, includes binary encoding of data that is optimized for near-real-time transmission. It also supports syntactic interoperability by defning the formatting and syntax for the exchanged messages.

While ISO/IEEE 11073 enables the exchange of especially vital parameters between the application systems of the medical devices, HL7 V2 and DICOM facilitate the data exchange between the application systems mentioned in Sect. 3.4. However, it is also necessary to be able to exchange data between these worlds. For example, patient demographic data is also required for the devices, and vital parameters should be able to be transferred to the EHR. Gateways are used to realize this communication.

#### **<IP_ADDRESS> open Electronic Health Record (openEHR)**

openEHR (open Electronic Health Record) is an open standard specifcation which focuses on the standardized representation of clinical information in EHRs. It has been maintained by the openEHR Foundation since the early 2000s and supports semantic and syntactic interoperability.

The specifcation follows a detailed (maximum) clinical information modeling approach and provides a formalism—the archetype defnition language (ADL) to defne *archetypes* as the basic building blocks representing clinical concepts. Furthermore, it includes the archetype query language (AQL), which—while syntactically similar to the ubiquitous SQL—operates on clinical concepts and unlike SQL—requires no knowledge of the persistence data structures (e.g., database schemata).

openEHR follows a two-layer modeling paradigm, fundamentally separating clinical content from technical details. The frst layer is the reference model, which describes the smallest logical blocks along with their implementation, for example, data types and structures or basic EHR components. As part of the archetype model, the second layer defnes the domain model representation in a maximum approach, meaning that an *archetype* (e.g., blood pressure or height), as the most basic and self-contained clinical concept, should serve all potential uses of this concept within the health care domain.

In other words, archetypes are reusable as semantic building blocks in different contexts without further modifcation. Within an archetype, each single item or data

instance can be linked or bound to a terminology (e.g., LOINC or SNOMED CT). Archetype classes include "composition", "section," and "entry," whereby the latter again includes "observation," "evaluation," "instruction," "action," and "cluster." To create more complex information units on the basis of these interchangeable building blocks in the context of specifc use cases, openEHR uses templates. An operation report, the results of an assessment test, or a form/document could, for example, be represented as templates, each assembled using archetypes just like construction bricks. A number of tools support the collaborative creation of openEHR archetypes and templates by clinicians and modelers, their governance, and the automated creation of software artifacts from them, which can be used in application systems of all kinds.

openEHR enables the defnition of a complete EHR along with methods to structure the EHR and manipulate its contents, for example, by writing (adding) compositions to the record. It also includes versioning. The open specifcation includes openly available REST APIs for programmers and vendors and supports several implementation/representation formats. Finally, it makes it possible to build a full, vendor-independent EHR within and across health care facilities.

#### **<IP_ADDRESS> Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT)**

SNOMED was developed in the 1970s and is maintained by SNOMED International, a non-proft international standards organization. SNOMED CT (Systematized Nomenclature of Medicine Clinical Terms), frst published in 2003, is currently the most comprehensive terminology in the health domain and is used in many countries worldwide. Users must obtain a license for use. The nomenclature aims to support the development of high quality, precisely defned content by standardizing medical terms and by providing ontological components such as associations and relationships between encoded concepts and entities.

SNOMED CT supports the semantic interoperability of application systems. It can be used for encoding and exchanging machine-processable data. SNOMED CT codes (like other codes from terminology standards) can be embedded in information models of other standards such as HL7 FHIR or openEHR.

SNOMED CT consists of concepts, descriptions, and relationships. A concept represents a unique clinical concept such as diabetes mellitus (disorder), which has several children concepts, such as diabetes mellitus type 1 or diabetes mellitus type 2, and so on (Fig. 3.30). Each further level in the hierarchy represents a more specific concept (partitive or taxonomic relationship). Associations between concepts may be of different types, for example, is-a (diabetes mellitus is a disorder of the endocrine system) or finding-site (structure of the endocrine system). SNOMED CT also contains synonyms and is available in multiple languages.

**Fig. 3.30** SNOMED CT example of associations between concepts. (Taken from the SNOMED CT browser [14]; use of SNOMED CT is with the permission of SNOMED International)

#### **<IP_ADDRESS> Logical Observation Identifers Names and Codes (LOINC)**

Logical Observation Identifers Names and Codes (LOINC) is a widely used terminology system for health measurements, tests such as laboratory and clinical tests, and observations. LOINC was developed in the 1990s and is maintained by the Regenstrief Institute in the United States [15].

The system defnes unique names, codes, and identifers that can be used in application systems or within communication messages such as HL7 or DICOM messages as well as in CDA documents (Sect. <IP_ADDRESS> shows an example of this), openEHR archetypes, or FHIR profles. LOINC thus supports the semantic interoperability of application systems.

LOINC codes are constituted of six components, for example, LOINC code 1554-5:

The LOINC "long common name" for this code example is "Glucose [Mass/ volume] in Serum or Plasma --12 hours fasting."

#### **<IP_ADDRESS> Clinical Data Interchange Standards Consortium (CDISC)**

The Clinical Data Interchange Standards Consortium (CDISC) spans a wide variety of standards, which are mainly—but not exclusively—designed for and used in clinical studies and trials in the pharmaceutical industry. CDISC standards were developed in the late 1990s and are maintained by the non-proft Clinical Data Interchange Standards Consortium.

CDISC standards are free to use and cover different domains and parts of the complete process to develop clinical products such as new drugs. The use of some of these standards is mandatory for reporting and submitting results from clinical trials to regulatory authorities, for example, to the FDA (U.S. Food and Drug Administration).

Common CDISC standards include the "foundational standards," which cover all necessary processes within research studies. Along the evolution of a research study, these standards cover planning (model for planning: Protocol Representation Model), data acquisition (model for data collection: Clinical Data Acquisition Standards Harmonization), organizing and managing data (e.g., Study Data Tabulation Model (SDTM), model for Questionnaires, Ratings, and Scales), and for data analysis (Analysis Data Model).

SDTM is the standard in which study data are submitted to regulatory authorities. Apart from these foundational standards, CDISC also supports a controlled terminology and includes widely used standards for data exchange, such as ODM-XML.

By employing these CDISC standards, researchers can achieve syntactic and semantic interoperability, share their data and metadata, and use a variety of software solutions (e.g., different EDC systems and analytical tools) along the study process.

## **3.8 Logical Tool Layer: Types of Integration**

Interoperable application systems can be joined together, i.e., integrated, in such a way that their combination has new properties that the application systems did not have on their own. Integration is a union of parts making a whole, which—as opposed to its parts—displays a new quality.

Integrating application systems lead to integrated health information systems. An integrated computer-based health information system typically offers better support for functions and business processes than a non-integrated information system consisting of isolated application systems. In non-integrated information systems, users may, for example, need to manually transfer data from one application system to another, or inconsistencies between data representations and semantics may exist that hinder the multiple use of data.

There are various ways of integrating application systems, resulting in different types of integration. Each type of integration leads to specifc new properties of the information system. In this section, you will learn about the following types of integration in more detail:

Note that the basic prerequisite for all types of integration is that the application systems to be integrated must be technically and syntactically interoperable so that communication is possible at all.

While interoperability makes a statement about a single application system or about a single application software product and its specifc properties and capability, integration always refers to a set of application systems and the way they are connected in a specifc information system.

## *3.8.1 Data Integration*

*Data integration* is achieved in integrated health information systems when data that have been recorded and stored once in one application component are made available in a coherent and uniform way wherever they are needed, i.e., in other application components, without having to be reentered. Data integration has two effects:

In DB1 architectures, i.e., architectures with a central database, data integration is comparatively easy to achieve. *Open platforms* are a technology that can be used to implement this even in (ACn , Vn ) architectures (Sect. 3.9.3).

In case of a decentralized DBn architecture, data integration and a uniform view on the data is more challenging. Transaction management and communication servers are integration technologies suitable to meet this challenge (Sects. 3.9.1 and 3.9.2).

Data integration helps to increase data consistency (Sect. 3.5) and to reduce unnecessary double data entry:

Assume that Mr. Russo was treated in the cardiology department, and a detailed medical history was collected and entered into the *MDMS*. Now Mr. Russo's health is deteriorating dramatically, and he must be moved to the ICU of the same hospital. If the medical history needs to be documented again, in case the information from the cardiology department cannot be accessed, there would be no data integration. If the ICU can assess and add data to the existing medical history, regardless of where and in which application system the already existing data was entered, data integration is achieved. In this example, the medical history may be sent from the *MDMS* to the *PDMS*, either directly or via respective integration technology and tools (Sect. 3.9).

To support data integration with non-computer-based application components, computer-based application components need to be able to print out data or to scan data such as paper-based documents (e.g., signed patient consent documents or a paper-based order entry form).

## *3.8.2 Semantic Integration*

Like data integration, *semantic integration* is concerned with data. Semantic integration is achieved when semantically interoperable application systems actually use the same system of concepts, i.e., they interpret data the same way. For example, when the sending application system uses the abbreviation "GOT" for a lab value, but the receiving application system does not know this code and uses "ASAT" for the same concept instead, then semantic integration is not achieved.

To achieve semantic integration of application systems, the application systems must agree on the way that information is represented, for example, within a hospital or a network of care facilities. This means that there needs to be an agreement on a common information model, for example, on Mr. Russo's blood pressure. This agreement comprises two aspects: We need to agree on how to actually represent the data values (e.g., systolic and diastolic values) by data. And we also need to agree on the underlying clinical concept and represent metadata such as the context of the measurements (resting blood pressure or exercise test), the measurement method (cuff or intra-arterial on an ICU), and so on. Contextual information can make a huge difference. For example, for a *clinical decision support system (CDSS)*, which tries to interpret the blood pressure values to determine whether the value is normal or abnormal in a specifc situation. Development of such information models is time-consuming multi-professional work, and agreeing on and maintaining them requires effort and strict governance of models. In the long term, however, these information models reduce tedious and costly mapping work and maintenance of mapping tables between application systems. Furthermore, it enables the reuse of data in contexts that differ from the original scenario in which the data was recorded, for example, for research or clinical decision support (CDS).

Thus, for semantic integration, the application systems must agree on some common terminologies. However, using terminology systems such as LOINC, SNOMED, or ICD (Sect. <IP_ADDRESS>) does not guarantee semantic integration. Instead, for real semantic integration, application systems must also agree on common information models. Such common information models contain a set of abstract concepts (e.g., patient, case, observation, entry, series of pictures) which are close to our concept of entity types and their relationships among each other. They thus try to formally represent the reality of health care through a set of concepts and their relationships. If two application components agree on the same information model, exchange of information and thus semantic integration are facilitated. Both openEHR (Sect. <IP_ADDRESS>) and HL7 FHIR (Sect. <IP_ADDRESS>) enable the creation of common information models, derived from a reference model.

Semantic integration can be elegantly and thoroughly supported by health data dictionaries. Such medical data dictionaries are central catalogs of health-related concepts and terms that offer the possibility of representing the semantic relationships among all data stored in a health information system and of linking that local vocabulary to internationally standardized nomenclatures and knowledge sources ("terminology linking" in openEHR). Such health data dictionaries (sometimes also called Medical Data Dictionaries, MDD) can be independent application components or part of existing application components.

## *3.8.3 User Interface Integration*

*User interface integration* is guaranteed when different application systems represent data and organize their user interfaces in a unifed way. For example, different application systems should display the patient's name always at the same place on their user interface. Icons for patients should code gender with the same colors. Alerts and warnings should be presented using the same colors and layout. Or the birthdate of a patient should also be displayed in the same format (e.g., yyyy-mm-dd).

The responsibility for integrating application systems in such a way that user interface integration is achieved lies with *tactical management of information systems* (Sect. 4.4). Especially at the specifcation stage of a new application software product, the relevant user interface requirements must be clearly described. This can be supported by user interface guidelines that are commissioned by standardization, governmental agencies, or leading health IT vendors.

## *3.8.4 Context Integration*

Even if data, semantic, and user interface integration is ensured, problems can arise when users use multiple application systems on one workstation, as the user and patient context may become lost through the change from one application system to another. *Context integration* is achieved if the context is preserved when the application system is changed. Or, more generally, the aim is that a task that has already been executed once for a certain purpose, such as login to a component or selecting a patient, does not need to be repeated again in the information system in order to achieve the same purpose.

Assume that the nurse Peter Smith frst wants to order a lab examination for the patient Jakub Russo at his workstation before documenting certain nursing procedures. The nurse would frst log in to the *CPOE system* and create the user context "Peter Smith." Then Peter searches for the patient Jakub Russo and orders the requested examination for him. This creates the patient context "Jakub Russo." For the next task, the nurse would have to start the *NMDS*. Without context integration, the user context "Peter Smith" would not be created in this application system

automatically and Peter would have to log in again. And without context integration, Peter would have to again select the patient and restore the patient context "Jakub Russo" before being able to document the nursing procedures. Context integration would be achieved when both login (then also called "single sign-on") and patient selection (maybe called "single patient look-up") do not have to be repeated again, even when changing the application system.

Health Level 7 provides a standard for single sign-on and single patient lockup, called CCOW (Clinical Context Object Workgroup).

## *3.8.5 Feature Integration*

*Feature integration* is achieved when features needed in more than one application system are implemented only once and can be invoked by other application systems.

In a hospital, for example, *coding of diagnoses and procedures* is a feature that should be supported by the *patient administration system*, the *OMS*, the *RIS*, and the *LIS*. The health information system would display feature integration with respect to *coding of diagnoses and procedures* if only one application component (e.g., the *patient administration system*) provides the features needed for coding diagnoses and procedures and all other application components can invoke and use these features.

Feature integration reduces the need to exchange data between application systems, reduces the danger of inconsistent data, and decreases the need to train users on multiple application systems.

On the technical level, feature integration can be supported by providing the use of features as services within an SOA (Sect. 3.9.3). Those services can be invoked by other application systems.

Overall, feature integration is an important quality characteristic within heterogeneous health information systems, as it allows features to be shared among application systems.

## *3.8.6 Process Integration*

An integrated health information system should support the business processes effectively. From this perspective, *process integration* is indeed the overall vision of integration within heterogeneous information systems, i.e., especially in (ACn , Vn ) architectures.

Process integration is guaranteed when business processes are effectively supported by a set of cooperating application systems showing process interoperability.

Typically, as we have seen, functions of a health care setting are supported by many different, yet interrelated application systems. A user must therefore use different application systems for one task.

For example, while writing the radiological report on Mr. Russo, the radiologist must work with the *CIS*, the *RIS*, and the *PACS*. To enable effective work in this process, these application systems should interoperate as transparently and smoothly as possible. If the radiologist receives the best possible support in report writing, without any interruption due to the heterogeneity of application systems, then we can say the information system is process integrated.

Obviously, process integration builds to some extent on the other integration qualities such as data integration (*CIS*, *RIS*, and *PACS* are able to exchange and jointly use patient diagnosis data without the need to reenter it), user interface integration (e.g., *CIS* and *RIS* have comparable user interfaces), context integration (e.g., when shifting between *CIS* and *RIS*, user patient context is maintained), semantic integration (e.g., procedures documented in the *RIS* are automatically understood by the *patient administration system*), and feature integration (the *RIS* invokes the billing function of the *patient administration system*). Good process integration builds on this, supports comprehensive information logistics, and prevents users from transcription and media breaks.

Process integration can be achieved, among other things, through the adoption of IHE profles (Sects. <IP_ADDRESS> and <IP_ADDRESS>) on a systematic basis.

Overall, process integration is an important quality characteristic within heterogeneous health information systems, as it describes a situation where different application systems interoperate in an optimal way so that business processes are best supported.

## **3.9 Logical Tool Layer: Integration Technologies and Tools**

To achieve data integrity (Sect. 3.5) and to support various types of integration (Sect. 3.8) in ACn architectures, specifc integration technologies are available. These integration technologies support interoperation of application systems and effcient and secure health information exchange between health care providers, and in some cases also with patients.

In this section, you will learn about transaction management, communication servers, vendor-neutral archives, and SOAs as examples of this kind of integration technologies.

## *3.9.1 Transaction Management*

*Transaction management* ensures that every update of correct data in one or more databases will lead to another state in which the data in these database(s) are still correct. This turns out to be not trivial, especially for complex update operations, the so-called transactions. It is even more complicated in settings of more than one database system, i.e., in DBn architectures.

Transaction management guarantees data integrity and especially data **C**onsistency through **A**tomicity, **I**solation, and **D**urability of any transaction (ACID conditions). Atomicity guarantees that either all of the tasks of a transaction are performed or none of them are; isolation makes intermediary updates of data inside the transaction invisible; and durability stands for persistence of the transaction's results.

The "2-phase commit protocol" was developed for transaction management in DBn architectures. Among other things, this protocol is intended to ensure data consistency in case of data redundancy. In the initial phase, it checks if the transaction can be carried out by all affected application systems. Only if the changes are possible everywhere, they are actually carried out in a second phase in all application systems. To carry out the protocol, the application systems must be tightly coupled by *synchronous communication*, and the database schemata of all involved database systems must be known. For an application system in a health information system, this means that an interface must be provided where both updates and the cancellation of these updates are possible. This is not the case for commercial application components available today. Generally, the individual database schemata of each component are also not known. Due to these reasons, the 2-phase commit protocol to ensure data consistency has usually not yet been implemented within DBn architectures of health information systems.

Nevertheless, to guarantee data consistency, the following more asynchronous approach is typically chosen within a health information system:

For every redundantly stored entity type, one application component is determined as the *primary application system* for this entity type. Thus, data on entities of this type can only be inserted, deleted, or changed in this primary application system. For example, the *patient administration system* is typically the primary application system for the entity types "patient" and "case." Consequently, data on patients and cases can be created, deleted, or changed only in the *patient administration system*. Therefore, this application system is sometimes called the "leading system."

Transactions in a database of the primary application system are carried out without regard to whether the corresponding operations can also be (immediately) carried out in the databases of the other affected application components. *Patient admission* is thereby carried out through the *patient administration system* independent of, for example, what is going on in the *RIS*. It may happen that the *RIS* is not capable of inserting corresponding data on the patient or the case that were sent by the *patient administration system* into its database at the same point in time. The *RIS* is then obliged to catch up on database operations at a later point in time.

## *3.9.2 Communication Server*

A quite simple way of communication between application systems is the asynchronous exchange of messages. *Asynchronous communication* means that the application system sending a message will continue its tasks without interruption even when awaiting a response message from the communication partner. Message exchange generates queues of messages that have to be managed. Besides direct, point-to-point communication between two application systems, tools for managing message queuing can also be used. These so-called queue managers support the sending of messages from the sender to the receiver and the distribution of a single message to numerous receivers (multicasting).

In health information systems, queue managers are typically referred to as communication servers. A communication server is an application system standing at the center of the logical tool layer of a health information system (Fig. 3.31). This architectural principle is also called star architecture (Sect. 3.6.4) and can be found in many health information systems.

Generally speaking, a *communication server* is an application system used for the asynchronous receiving, buffering, and sending of messages. It can also be used to transform messages and monitor the traffc between application systems and may provide intermediate storage of messages in case the intended recipient of the messages is not yet available (e.g., system down). An application system can send a message to the communication server over its communication interface. The communication server will then relay the message to one address or many addresses (multicasting) when these application systems are ready to receive. In the meantime, the communication server buffers the sent messages in a queue (message queuing). In the case that the receiving application system is awaiting messages in a format based on a different interoperability standard than the sending application system sends, the communication server can transform the sent message. The application systems have to provide communication interfaces for sending messages to the communication server and to receive messages from it.

In this way, the communication server is a tool to support data integration in a health information system of (DBn , ACn ) architecture. Furthermore, communication servers prevent (DBn , ACn ) styled health information systems from *spaghetti architectures* and support CP1 architectures. Application components can be more easily exchanged, thus supporting the expandability of the health information system's architecture.

Some communication servers may also provide *synchronous communication*. For this, the sending application system will pause from the time that it sends a message to the time that it receives the respective answer. In this way, communication servers can be used to invoke services as described in Sect. 3.9.4 and to provide feature integration as well.

In health information systems with DBn architecture and redundant data storage, the application components store the data needed for supporting their functions by themselves. This holds especially for data on the entity types "patient" and "case." Consequently, the communication server is used to ensure that every application system will fnd these data in its database system whenever the data is needed without having to request this data from the *patient administration system*. The following example describes how the *patient administration system* and the communication server can be integrated based on asynchronous communication and use of the interoperability standard HL7 (Sect. <IP_ADDRESS>) in order to ensure data integration as well as data consistency regarding the entity types "patient" and "case":

**Fig. 3.31** Architectural style with multiple application systems, each with its own database system, using 3LGM2 symbols. A communication server links the application components

Mr. Russo has just been admitted to Ploetzberg Hospital in the administration unit. Since the *patient administration system* is the primary application system for the entity types "patient" and "case," *patient admission* is exclusively supported by the *patient administration system* (Sect. 3.9.1). Even before Mr. Russo leaves the administration unit to go to the cardiology ward, the following messages are exchanged between the application systems (Fig. 3.31 highlights steps 2 and 3):

A similar process takes place when administrative data on Mr. Russo is updated. If his address changes, for example, this is frst documented in the *patient administration system*. This application system then sends a message on this update to the communication server (2) that multicasts this message again (3), as described above. Since the *patient administration system* is the primary application system of patient and case, all updates of related data must be performed using the *patient administration system*.

By following these processes, data consistency is provided and application systems will have actual data available in case they are needed. Above all, users in the radiology department, for example, can always fnd the administrative data on their patients in their *RIS* without the *RIS* having to make a request to the *patient administration system* beforehand.

## *3.9.3 Open Platforms and Vendor-Neutral Archives*

An application system is called *open platform* if it stores patient data based on open specifcations and open information models and provides open Application Programming Interfaces (API) for storing and querying these data. "Open" in this context means that the specifcations, information models, and interfaces are published and can be used by any vendor.

An *open platform* follows the idea that both data and metadata are stored in a centralized database, with strict separation between application logic and data storage.

The advantage of the *open platform* approach is that other application systems with different functionalities from different vendors can directly work on the same database (DB1 architecture). This facilitates both *data integrity* (Sect. 3.5) and *data integration* (Sect. 3.8.1) even in Vn architectures. The interoperability standard openEHR (Sect. <IP_ADDRESS>) provides a universal, agreed-upon information model.

*Open platforms* were frst used in medical image archives and *PACS,* then typically called vendor-neutral archives (VNAs).

For example, after admitting Mr. Russo to the cardiology ward, blood samples have to be analyzed at the laboratory and radiological images have to be taken. Using an *open platform* as in Fig. 3.24, the LIS and the RIS would be able to access the same database as the patient administration system even if they are from different vendors.

To support communication between *open platforms* and other application systems, standards such as HL7 FHIR, DICOM, or IHE profles are used (Sect. 3.7.2).

While an *open platform* may seem diffcult to introduce in a long-grown environment of different application systems with their own proprietary information models, it reduces the ever-increasing cost of mappings on the communication server side whenever a new application system is introduced. It also eliminates costly mapping processes when migrating patient data from a previous to a new application system. Open APIs also enable new vendors to integrate their application software products in given information systems by using the agreed information models and thus enable a growing "application ecosystem."

## *3.9.4 Service-Oriented Architectures*

Service-oriented architectures (SOAs) represent architectural styles of health information systems that provide the means and tools to use services for the collaboration of application systems. A service is an encapsulated feature provided by an application system in order to be invoked by other application systems (Sect. 2.9).

This results in synchronous communication between application systems, meaning that the process in the invoking application system, after starting the communication with the providing application system, is paused until a response from the partner is obtained.

The *patient administration system* may, for example, store data on the entity type "patient" and may provide a service for retrieving name, birthdate, and address of certain patients. In this case, the patient data is called a resource. Other application systems can access this resource by invoking the retrieve service and handing over a certain PIN. They will then obtain the desired data—if access is granted. Another service may be provided by application systems allowing a message to be sent to these application systems by invoking this service and handing over the message.

Therefore, this technology is very good at achieving data integration and ensuring data integrity. In particular, it facilitates the construction of DB1 architectures using VNAs.

Moreover, the *patient administration system* could provide a service for *patient admission*. The *RIS* could thus invoke this admission service, handing over data on a certain person who should be admitted to the health care facility. As a result, the *patient administration system* executes all necessary actions needed to perform *patient admission*. With such more complex services, feature integration can be achieved in addition to data integration.

When using World Wide Web technology, the resources are identifed by certain Uniform Resource Identifers (URIs). Application systems can provide basic services for GET, PUT, POST, and DELETE operations on their resources by offering the so-called RESTful APIs. For health information systems, resources as well as services for operating on the resources are standardized by FHIR (Sect. <IP_ADDRESS>).

## **3.10 Physical Tool Layer**

Application components are logical tools, and they cannot exist without physical tools as a basis. In an information system, we can describe this basis with the physical data processing systems at the physical tool layer. As stated earlier, physical data processing systems can be human actors, non-computer-based physical tools, or computer systems.

If application components that exchange data and interact with each other are installed on different physical data processing systems at the physical tool layer, these physical data processing systems have to communicate as well, i.e., integration is also needed there.

We will now have a closer look at typical computer-based physical data processing systems and their integration. You will learn about *physical interoperability* and integration and how challenges in terms of availability and security of application systems and data are addressed in the design of communication networks and the construction and operation of data centers.

## *3.10.1 Physical Data Processing Systems*

#### **<IP_ADDRESS> Servers**

Servers are used to provide sophisticated features to clients (Sect. <IP_ADDRESS>). Servers can run databases (database server), they can run the back-end part of application software products (application server), or they can support printing (printer server). Terminal servers run the front-end part of application software products, which traditionally have been implemented on and run by clients. If terminal servers are used, mere terminals (Sect. <IP_ADDRESS>) for displaying output and receiving input are suffcient. Further server types are name servers (for domain name system (DNS) management), DHCP servers (for dynamic IP assignment), mail servers (for email services), and web servers (for website management).

There is a strong trend to virtualize servers. A "real" (i.e., physical) server can simulate lots of the so-called virtual servers. Every virtual server runs a particular instance of an operating system and can be used to implement application software products. Thus, these virtual servers behave nearly identical to physical servers. This approach makes computing power in a data center much more fexible and scalable.

Virtual servers also result from coupling physical servers in order to maximize availability through redundancy. These kinds of coupled servers are called a server cluster. It makes sense to localize the members of the cluster at different sites of the data center (Sect. 3.10.3).

#### **<IP_ADDRESS> Clients and Personal Devices**

Clients comprise all data processing tools that are immediately available to the various user groups within a hospital, for example:

Mobile devices are especially important in health care settings because devices must provide both data and support of functions wherever patients are. This applies not only to health care facilities, but especially to the patient's home environment.

In medicine, there is a plethora of other personal devices in use to capture data from and about individuals, making it available for further processing in application systems. Sensors for recording vital signs such as heart rate, blood oxygen saturation levels or an ECG are not only used in the ICU of a hospital. Smartphones and smart watches also have such sensors and can provide corresponding data. These personal devices also provide sensors for personal identifcation, such as fngerprinting or retinal eye scanning. Smart cards, which are connected via special readers, are also used for identifcation.

Overall, large health care facilities such as a 1500-bed university medical center will have about 4000 clients (PCs) and 3000 mobile devices. This causes not only investment costs, but also enormous maintenance costs. The energy consumption of these devices is also considerable.

If we assume a power consumption of approx. 300 watts for one PC, this results in a total consumption of approx. 1.2 MW (megawatts) for all PCs together. The mobile devices' energy consumption must be added.

#### **<IP_ADDRESS> Storage**

Health information systems must store not only large amounts of data but also very important data that may be crucial for the patients' health and life. This requires storage devices of high capacity and high reliability. The storage media that are used range from magnetic discs for random access to magnetic tapes and optical media for backup and archiving.

Storage devices, regardless of the media used, are not specifcally attached to and exclusively used by certain servers. Moreover, storage area networks (SANs) provide storage services of different kinds to all servers integrated in this network. This technology allows the storage capacities to be scaled up or down quite easily depending on actual storage needs. Additionally, SANs help to maximize availability through redundancy. It makes sense to localize the members of an SAN at different sites of the data center (Sect. 3.10.3).

## *3.10.2 Physical Interoperability and Integration by Communication Networks*

The types of integration introduced in Sect. 3.8 relate to the logical tool layer and, more precisely, to sets of application systems. Let us supplement this catalog of integration types with *physical integration*.

Physical integration refers to a set of physical data processing systems and is guaranteed if the necessary physical communication is possible for each required data exchange. This requires having only one computer, for example, a mainframe, hosting all application systems or having physical interoperability of the physical data processing systems to be connected. For this, the devices must have hardware interfaces for data exchange. In other words, physical interoperability of physical data processing systems is a prerequisite for technical interoperability of application systems that are installed on different physical data processing systems (Sect. <IP_ADDRESS>). In other words, physical integration between physical data processing systems is a prerequisite for any kind of integration between application components.

Communication networks can be implemented by optical fbers, copper cables, and wireless LAN technologies. Different communication protocols such as Ethernet or Token Ring can be used.

The ISO/OSI reference model provides a framework for describing communication between computers at seven levels. Standards for the respective communication protocols are available for each level. With respect to the three-layer graph-based metamodel (3LGM2 ), these seven levels interconnect the physical with the logical tool layer of a health information system. Level 7 may be considered the logical tool layer which corresponds to the name of the communication standard HL7 (Sect. <IP_ADDRESS>). A set of protocols for each of the seven levels is called a protocol stack.

In order to be able to use the mobile devices required in medicine, appropriate wireless networks are necessary. Wireless local area networks (WLAN) are commonly used inside buildings, both in health care facilities and in private environments. Outside buildings, for example to connect ambulance vehicles but also to feed a limited campus of a health care facility, the same mobile networks that are also used for mobile telephony are used. Currently, ffth-generation mobile networks (5G) are being introduced. These enable high data transmission rates but require a close-meshed network of antennas. The health effects of the associated electromagnetic felds are subject to controversial debate.

The network that exclusively connects the physical data processing systems of a facility is also called intranet. Extensive security measures are required at the interface between the intranet and the internet to prevent unauthorized access to the physical data processing systems within the intranet from outside the facility. These include, in particular, the so-called frewalls. Firewalls are physical data processing systems on which incoming and outgoing communication is monitored by software.

To optimize security, the intranet itself is also partitioned into further security zones. Depending on the need for protection and the permitted user group of application systems, the physical data processing systems on which these application systems are installed are assigned to such security zones. Communication into and out of a security zone is also monitored using dedicated hardware.

## *3.10.3 Data Centers*

The servers must fulfll special requirements related to availability, stability, performance, maintainability, and redundancy. For health care facilities, this can only be economically achieved if the servers are centralized in a data center.

The reliability of the data center, with all its equipment and physical data processing systems, is the very basis for the reliability of the health information system as a whole. Although system stability of application components deals with the quality of the software used, system stability must be enhanced by redundancy. Redundancy is not needed at the logical tool layer, however, but at the physical tool layer.

This requires data centers that provide at least two redundant sites as well as mirrored servers and storage devices at each site, a stable energy supply, high-capacity air conditioning, server rooms that are burglar-proof and disaster-proof, and effective means for fre protection. Even if an information management department ensures an effective backup, the continuous operation of the data center through appropriate redundancy is of utmost importance.

Data center staff needs software tools for supervising proper operation of servers, communication network components, PCs and terminals, and the application components running on top of these physical tools.

For two redundant sites of the data center housing the servers of a large academic center, one must expect an energy consumption of 0.5 MW. This energy consumption results not only from the power consumption of the servers but also from the energy requirements of the air conditioning systems, which must dissipate the electrical energy converted into heat. Consideration should therefore be made as to whether the waste heat from the computers can be used for other useful purposes such as heating the facility's domestic water.

These and the previously mentioned fgures on client energy consumption alone make it clear that medical informatics specialists, and information managers in particular, not only have responsibility for good information systems but also for the impact of information systems on the global climate.

Not only the high energy consumption, but also the major technical challenges involved in operating a data center, suggest that smaller health care facilities in particular should consider whether servers in the cloud, and thus commercial data centers, can be used instead of own data centers. However, this requires stable and suffciently powerful communication links. In addition, the data protection regulations of the respective country must be observed. Conversely, large health care facilities can consider whether their own data center can be offered to smaller surrounding facilities for use. The large facility could then become a cloud provider for the smaller facilities.

## *3.10.4 Data Security*

Data security means protecting the data of an information system both from destruction and loss and from illegal use by unauthorized persons. This is particularly important in health information systems for two reasons. Firstly, health data is highly sensitive and represents intimate information about individuals that must never fall into the hands of third parties without the consent of the individuals concerned. Secondly, a health care facility is at risk of becoming completely incapacitated if the data in the patients' health records can no longer be accessed. This can cost lives. Recent cases of the so-called ransomware attacks on hospitals, for example, illustrate the associated dangers. In ransomware attacks, data is encrypted by criminals and a key for decryption is only made available after payment of a ransom.

It is therefore imperative to invest in protective measures at all levels. For example, as mentioned above, communication networks must be protected through their structure and suitable hardware and software, data backups must be performed and the data copy must be protected against attacks, and highly qualifed personnel must be available. We can only hint at the required know-how in this textbook and therefore refer to the relevant, current technical literature and the training and continuing education programs on data security.

In health care facilities, it is the responsibility of the management of information systems to ensure data security, while corporate management must provide the necessary fnancial resources for this purpose.

In the private environment, this responsibility lies with the individuals themselves. It is the task of politics, but also of the professional societies for medical informatics, to ensure that people are informed, educated, and advised.

## **3.11 Examples**

## *3.11.1 A Reference Model for the Domain Layer of Hospital Functions*

The reference model for the domain layer of hospital information systems consists of the subset of functions and entity types described in Sects. 3.2.3 and 3.3 that are relevant for hospitals. The reference model focuses on the activities in *patient care*. Thus, the main enterprise function is *patient care*, and there are maintenance functions supporting *patient care* such as *supply management*, *scheduling and resource allocation*, *hospital administration*, *hospital management*, and *research and teaching* (Fig. 3.32).

Furthermore, the enterprise functions in that reference model bear a relation to each other by entity types which they can update or interpret. To defne entity types within the reference model of the domain layer, the HL7-RIM5 was used.

The Reference Model for the Domain Layer of Hospital Information Systems is available as a 3LGM2 model6 and for this reason can be immediately used for modeling hospital information systems. Following the defnition of reference models in Sect. 2.13, the Reference Model of the Domain Layer can be used as a model pattern for the domain layer of hospital information systems and, additionally, can help

<sup>5</sup> http://www.hl7.org/Library/data-model/RIM/modelpage\_mem.htm.

<sup>6</sup> http://www.3lgm2.de//Modelle/Referenzmodelle\_und\_Beispielmodelle/RM\_DomainLayer\_version2\_English.z3lgm.

Patient admission

Appointment

scheduling

Patient identification

and checking for

recurrent

Administrative

admission

Medical admission

Nursing admission

Visitor and

information services

Patient administration record

record

Hospital management

to compare hospital information systems by means of a uniform terminology used for the domain layer. This means that, for each enterprise function of the Reference Model of the Domain Layer, it is possible to determine the support by application components in different information systems.

## *3.11.2 The Domain Layer of CityCare*

CityCare is a health care network in the city where Mr. Russo and his family live. In CityCare, Ploetzberg Hospital, Ernst Jokl Hospital, and a specialist medical offce for sports medicine cooperate in order to treat patients suffering from joint injuries.

Mr. Russo's son, an amateur football player, injured his knee joint during his last match. Patients suffering from joint injuries frst consult CityCare's primary care sports physician. If the physician suspects that surgery is needed, she orders MRI diagnostics at Ploetzberg Hospital. After receiving the fndings from Ploetzberg Hospital, the sports physician admits patients needing arthroscopic surgery to Ernst Jokl Hospital for further treatment.

Figure 3.33 describes the domain layer of the CityCare scenario. Functions introduced in Sect. 3.3 were used and specialized or decomposed to model the domain layer. The entity types used are described in Sect. 3.2.

**Fig. 3.33** Domain layer of CityCare

All three health care facilities cooperating in CityCare perform activities regarding the functions of *patient admission* and *execution of diagnostic and therapeutic procedures*. These functions performed by each health care facility are modeled only once at the domain layer. Ploetzberg Hospital is the only hospital offering "execution of MRI diagnostics," whereas Ernst Jokl Hospital is the only hospital offering "execution of arthroscopic surgery procedure."

Entity types such as "patient," "case," and "order" that are used or updated in all three facilities are also modeled once at the domain layer. To visualize different health care facilities, labels (see grey rectangles) were used in the 3LGM2 model.

## *3.11.3 The Logical Tool Layer of CityCare*

At the logical tool layer shown in Fig. 3.34, the application systems that are relevant for the described scenario in CityCare and their communication are modeled. For a better overview, the institutional information systems and the jointly used application systems of the network are labeled by gray rectangles.

The specialist medical offce has one application system that is used for *patient administration* and medical documentation. Both Ploetzberg Hospital (PH) and Ernst Jokl Hospital (EJH) have their own *patient administration system* and *MDMS*. These are different installations of different application software products

**Fig. 3.34** Logical tool layer of CityCare

which are therefore modeled as single application systems. For MRI diagnostics, Ploetzberg Hospital additionally uses an *RIS* and an MRI scanner which is also modeled as an application system. Images that are generated by the MRI scanner and all other medical and administrative data from the *MDMS,* the *RIS,* and the *patient administration system* are stored in the Vendor-Neutral Archive PH, an *open platform*. Thus, these other application systems do not need their own database systems. All three facilities access the central EHR system, a *clinical information system*, of the health care network. This EHR system comprises patient information such as diagnoses, fndings, and discharge letters received from all facilities. To manage the PINs from the different facilities, the health care network uses an *MPI* that assigns a transinstitutional PIN for the patients and maps the different PINs of the facilities to this transinstitutional PIN. This is a precondition for being able to build the *EHRS* in the health care network.

The matrix view in Fig. 3.35 shows which functions are supported by which application systems in CityCare. The application system of the specialist medical offce, for example, supports six different functions. We can also identify functional redundancies. For *administrative admission*, for example, all three facilities use different application systems. Within a health care network like CityCare, it would also be possible to support this function with one application system that is used by each facility. Application systems serving solely as an integration technology, such as the EJH communication server, do not need to be linked with functions at the domain layer in 3LGM2 models. For the VNA and the EHR system, no supported functions are modeled either—fnding appropriate functions is part of the exercise in Sect. 3.12.6. For the correctness of the model, application systems are only assigned to "leaf functions" but not to superordinate functions such as "execution of MRI diagnostics."

**Fig. 3.35** Matrix view visualizing the relations between functions and application systems in CityCare

The architecture of Ernst Jokl Hospital (in the left of Fig. 3.34) can be described as a star-based (DBn , ACn , Vn ) architecture. There are at least two major application systems (ACn ), probably from different vendors (Vn ), with their own respective database system (DBn ). The application systems—the patient administration system and the *MDMS*—exchange data via a communication server (star-based architecture) using HL7 V2 messages. Ploetzberg Hospital also features a star-based architecture which is, however, different from Ernst Jokl Hospital's architecture. At the center of Ploetzberg Hospital's (DB1 , ACn , Vn ) architecture, there is a *VNA* implemented as an *open platform* based on uniform information models in the openEHR standard. The hospital's interoperability experts control these information models and stipulate and enforce their use whenever a new vendor system is added. The *RIS* at Ploetzberg Hospital's radiology department communicates with the MRI scanner using the DICOM standard. The DICOM images generated by the MRI scanner as well as the radiological reports that are documented with the help of the *RIS* are stored in the *VNA*.

The institutional information system of the specialist medical offce has a (DB1 , AC1 , V1 , Cn ) architecture because it only consists of a single application system with one database system. The application system combines the functionalities of a *patient administration system* and an *MDMS*. It could therefore be regarded as the *CIS* (or *EHRS)* of a medical practice (Sect. 3.4.15). This comprehensive application system sends orders for radiological examinations or orders for surgical procedures to Ploetzberg Hospital or Ernst Jokl Hospital, respectively. For this, it uses the HL7 V2 standard.

All three care facilities work together in the CityCare health care network, which provides a centralized *EHRS* that can receive as well as provide patient EHR data on demand. For data persistence, the central *EHRS* implements the openEHR standard for highly structured EHR data and an additional database system for documents. To receive patient data, the *EHRS* provides different interfaces for the three facilities in the network: an HL7 FHIR interface for Ernst Jokl Hospital's communication server, an HL7 V2 interface for the specialist medical offce, and a native openEHR interface for Ploetzberg Hospital. For cross-network identifcation of patients, the CityCare network has implemented an *MPI* based on an IHE integration profle. In the future, it is planned to implement a portal both for external physicians and for the patients themselves so they can access their data in the central *EHRS*.

If Mr. Russo presents at Ernst Jokl Hospital, the local physician will look for available information on Mr. Russo in the hospital's *MDMS*. The system can then send a query to the CityCare network, asking for available information on Mr. Russo. The query is sent via Ernst Jokl Hospital's communication server to the network's central *EHR system* using the unique PIN for Mr. Russo. The central *EHR system* sends back Mr. Russo's data using the HL7 FHIR standard to the Ernst Jokl Hospital communication server and the data is forwarded to the EJK *MDMS*.

## *3.11.4 The Physical Tool Layer of CityCare*

At the physical tool layer of CityCare, parts of the data centers of Ploetzberg Hospital and Ernst Jokl Hospital as well as a joint data center of the health care network are modeled (Fig. 3.36). The specialist medical practice only houses three PCs on which the patient management and *MDMS* can be used. The application system is installed on an application server which is hosted by Ernst Jokl Hospital's data center. Both hospitals also host application servers on which the application systems of the respective hospitals are running. For storing data, SANs are used. In the data center of the health care network, there is an application server for the *EHRS* and another server for network management.

The relations between the logical tool layer and the physical tool layer are visualized by a matrix view (Fig. 3.37). The specialist medical practice only houses three PCs on which the patient management and *MDMS* can be used. The application system is installed on an application server which is hosted by Ernst Jokl Hospital's data center. Both hospitals also host application servers on which the application systems of the respective hospitals are running. For storing data, SANs are used. In the data center of the health care network, there is an application server for the *EHRS* and another server for network management.

**Fig. 3.36** Physical tool layer of CityCare

**Fig. 3.37** Matrix view visualizing "installation" relations between application systems and physical data processing systems

## **3.12 Exercises**

## *3.12.1 Domain Layer: Differences in Hospital Functions*

Look at the functions presented in Sect. 3.3.2.  What are the differences between these hospitals with regard to their functions? Explain your answer.

## *3.12.2 Domain Layer: Different Health care Professional Groups and Health care Facilities*

Look at the functions listed in Sect. 3.3.2. Look at the relationships between the functions and the different health care professional groups (physicians, nurses, administrative staff, others) working in hospitals and medical offces. Select one health care professional group and describe which functions are most important for this group.

## *3.12.3 Domain Layer: The Patient Entity Type*

Look at the entity type "patient" that is interpreted and updated by various functions. Which functions update the patient information, which functions interpret it?

## *3.12.4 Logical Tool Layer: Communication Server*

Imagine a hospital information system that comprises four application systems: a *PAS*, an *MDMS*, a *RIS*, and a *PDMS*. The hospital is now considering the introduction of a communication server to improve data integration. Discuss the short-term and long-term pros and cons of this decision. Which syntactic and semantic standards could be used?

## *3.12.5 Logical Tool Layer: Integration from the User's Point of View*

During a night shift, a nurse uses the *patient administration system* to conduct the administrative *patient admission*. The nurse then uses the *NMDS* to plan nursing care. Now consider the types of integration presented in Sect. 3.8 and discuss how this nurse would recognize a high (or low) level of data integration, semantic integration, user interface integration, context integration, feature integration, and process integration.

## *3.12.6 CityCare*

The following questions can be answered by reading the text and analyzing the 3LGM2 fgures of the CityCare Example 3.11.

## **References**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 4 Management Perspective: Scopes and Tasks of Managing Health Information Systems**

In Chap. 3, we discussed the technological perspective of health information systems. We will now examine how health information systems have to be managed so they will fulfll the requirements of the stakeholders as presented in Sect. 1.3.

As already introduced in Sect. 2.12, management of information systems ensures systematic information processing that supports information and knowledge logistics and therefore contributes to the health care setting's goals. High-quality health information systems and their components can only by achieved if the health information systems are systematically planned, monitored, and directed.

Management of information systems can be differentiated into strategic, tactical, and operational management of information systems. In this chapter, we will frst discuss these three scopes of management of information systems and how they are interlinked in more detail. We will then focus in more detail on strategic management of information systems and discuss tasks and methods of strategic planning, strategic monitoring, and strategic directing of health information systems. We will also discuss organizational structures for systematic management of information systems.

Finally, it is important to remember that for the management of information systems we can only say in a few cases what is indeed right and what is wrong. Rather, in practice, decisions must be made again and again as to which solutions and approaches are best suited in the respective setting (Fig. 4.1). In doing so, a balance must be reached between at times conficting goals. This balancing act is what the last section is about.

**Fig. 4.1** Health information systems constitute an essential part of providing good health care. Managing health information systems requires both professional skills and communication

After reading this chapter, you should be able to

Please note that the terms highlighted in italics are terms from the glossary or represent functions or application system types.

## **4.2 Dimensions of Managing Health Information Systems**

In this section, we present in more detail the tasks of managing health information systems in health care facilities. We will discuss strategic, tactical, and operational management, their goals, and their tasks.

As already discussed in Sect. 2.12, *management of information systems* encompasses the management of all components at the three layers of an information system—the management of functions, processes, and entity types, of application components and services, and of physical data processing systems. We consider these components the objects of *management of information systems*.

Although the layers help to structure *management of information systems* by objects, it is helpful to also divide *management of information systems* with regard to its scope into strategic, tactical, and operational management.

*Strategic management of information systems* deals with the information system as a whole and establishes strategies and principles for the evolution of the information system. An important result of strategic management activities is a strategic information management plan.

*Tactical management of information systems* deals with particular functions, application components, or physical data processing systems that are introduced, removed, or changed. Usually, these activities are done in the form of projects. Tactical information management projects are initiated by *strategic management of information systems*. Thus, *strategic management of information systems* is a vital necessity for *tactical management of information systems*. The result of tactical information management projects is an updated information system.

*Operational management of information systems* is responsible for operating the components of the information system. It ensures the smooth operation of the system in accordance with the strategic management of information systems plan. Additionally, operational information management plans, directs, and monitors permanent services for the users of the information system.

Regardless of which objects are currently being processed and on which scope *management of information systems* is currently focused, *management of information systems* is always involved in the tasks of planning, directing, and monitoring.

This results in three dimensions for classifying *management of information systems* as shown in Fig. 4.2. When combining the three scopes, the three main tasks, and the three major objects of *management of information systems*, we can also defne a 3 × 3 × 3 matrix of information management activities.

This separation of activities of *management of information systems* is essential because each of the information management scopes has different perspectives and therefore uses different methods and tools. For example, planning within *strategic management of information systems* focuses on strategic information management plans. Planning within tactical management needs, for example, methods for project management or user requirements analysis, while directing within tactical management needs methods for software development or customizing. Operational management requires methods and tools for topics that range from intra-enterprise marketing of services to service desk and network management.

Strategic, tactical, and operational management depend on each other. Figure 4.3 presents their relationships in a three-layer graph-based metamodel (3LGM2 ) domain layer.

Within *strategic management of information systems*, a strategic information management plan and project portfolios have to be created as a result of planning activities. Strategic planning depends on the business strategy of the enterprise, defned by the strategic enterprise management, on information from HIS quality indicators, and on legal regulations. Since the strategic information management plan contains a project portfolio to be performed in the coming years, strategic directing means initiating these projects. Strategic directing updates a project charter which is then processed by *tactical management of information systems*. Strategic monitoring collects various information regarding the state of the information system components and users' and patients' requirements and compares these with the strategic information management plan and the project portfolio. The resulting HIS quality indicators are fed back to strategic planning.

Within each project of *tactical management of information systems*, the course of the project must be planned (project plan) and the project will be directed and monitored according to this plan. The result of a project are updated information system components. When a project ends, the result is documented in a handover protocol which is passed to *operational management of information systems* for further operation of the information system component.

Executive operational tasks (such as operating a computer server) are not part of information management. Nevertheless, these operational tasks must be planned, directed, and monitored. This is carried out by *operational management of information systems*.

As already indicated in Fig. 4.3, *management of information systems* in health care facilities is performed in an environment full of infuencing factors. Decisions

**Fig. 4.3** 3LGM3 representation of the relationships between functions of "strategic, tactical, and operational management of information systems and related entity types"

made by the strategic enterprise management of the health care facility directly infuence *management of information systems*. For example, the decision of the strategic enterprise management of a health care facility to cooperate in a health care network will have an impact on the future state of the information system. New legal regulations also have an effect on the *management of information systems*. For example, a law enforcing the introduction of a new billing system based on patient grouping will require adaptations in application components. Patients and users, as important stakeholders of an information system, also infuence *management of information systems* with their values, attitudes, and requirements. Patients may demand a patient portal to access some of their data from home, for example. Or *management of information systems* itself may affect the management of the health care facility. If, for example, *management of information systems* proposes the introduction of a multi-professional *electronic health record system (EHRS)*, this must in turn lead to strategic activities such as process reorganization within the health care facility.

Figure 4.4 summarizes these relationships between management and operation of a health information system and the infuencing factors.

We now look at the activities of strategic, tactical, and operational management of information systems in health care facilities.

**Fig. 4.4** Strategic, tactical, and operational management of information systems in health care facilities and their relationships

## **4.3 Strategic Management of Information Systems**

*Strategic management of information systems* deals with the information system of a health care facility as a whole. It depends on and must be aligned to the facility's vision, mission, and strategic goals.

*Strategic management of information systems* and its strategic information management plan are the prerequisites for tactical and operational management of information systems in a health care facility.

We will now discuss in more detail strategic planning, monitoring, and directing of *management of information systems* in health care facilities.

## *4.3.1 Strategic Planning*

Strategic planning is the frst step of a systematic strategic information management process and leads to a strategic information management plan as basis.

Planning, as part of *strategic management of information systems*, must translate vision, mission, and strategic goals into a specifc strategic information management plan. Thus, the most important tasks of strategic planning are *strategic alignment* of business goals and strategic information management goals, and the development of both a long-term *strategic project portfolio* as part of a strategic information management plan and *annual project portfolios*.

#### **<IP_ADDRESS> Strategic Alignment of Business Goals and Information Management Goals**

The basis for *strategic management of information systems* in a health care facility is the mission of the facility. The mission describes what the basic functions of the facility are and what it stands for. For university medical centers in Germany, for example, it is stipulated by law that they must offer the basic functions of *patient care*, medical research, and teaching of future physicians.

Strategic goals are concrete specifcations of how this mission is to be fulflled within a certain, usually longer, period of time. Such goals are set by the management of the facility. The strategic, long-term goals of a health care facility are also called *business goals*. The term "business goal" should not be understood in a purely proft-oriented or economic way, which means focusing on fnancial gain only. Instead, as health care facilities should serve the needs of individual patients and of society, we should understand business goals as all goals of a health care facility that refect its mission in *patient care*, *research*, *and education*.

Health care facilities aim to provide effcient, high-quality health care. They may thus defne, for example, one or more of the following business goals as their strategic, long-term goals:

Different goals and sub-goals result in different information management strategies and different architectures of information systems. Also, advances in information and communication technology (ICT) may infuence business goals. The role of *management of information systems* thus varies between two extremes. At one extreme, *management of information systems* may be seen as a purely supporting function; that is, the business goals determine the information management planning activities. This is called "organizational pull" and the person in charge of *strategic management of information systems* needs to know the business goals of the health care facility. At the other extreme, *management of information systems* is seen as the strategic resource from which the health care facility gains competitive advantage. The application of technological advances mainly determines the further development of the health care facility and its position on the health care market. This is called "technology push." For this, the top management needs to know the potential of information systems with regard to supporting or shaping the business goals. *Strategic management of information systems* must thus be able to offer this information to top management in adequate and understandable form.

Strategic alignment describes the process that balances and harmonizes the business goals of the health care facility and the information management strategies to obtain the best results. Strategic alignment ensures that the strategic information management plan directly supports the business goals and that IT projects and IT budget can be directly tied to these business goals.

#### **<IP_ADDRESS> Strategic Information Management Plan**

The *strategic information management plan* represents the long-term planning of the information system of a health care facility. This plan describes the business goals, the information management goals, the current state of the information system, the future state of the information system, and the steps to transform the current into the planned information system. *Strategic management of information systems* must create and regularly update this plan. The strategic information management plan is the basis for all tactical and operational information management activities and is the precondition for systematically directing and monitoring the information system of a health care facility.

*Strategic management of information systems* is an ongoing process, and there is no use in trying to solve all problems of information processing at the same time. Solely a stepwise approach, based on different levels of priorities, is feasible. The strategic information management plan is therefore the basis for a *strategic project portfolio* that describes projects or groups of projects, their priority, and a rough timeline for their initiation for the coming years.

The long-term strategic information management plan is usually valid for a longer period of time (e.g., 3–5 years). However, requirements (e.g., due to legal changes or new user requests) and resources (staff, money) may change more quickly than the strategic information management plan, or strategic monitoring results may require a faster adjustment or an update of prioritization of projects. This is refected in the annual project portfolio (Sect. <IP_ADDRESS>) that is annually derived from the strategic project portfolio. It lists the projects to be executed in the next year.

The strategic information management plan should be written by the persons responsible for *strategic management of information systems* (e.g., the chief information offcer (CIO)) and approved by the top management. Without proper strategic planning, it would be a matter of chance if the information system of a health care facility fulflled strategic information goals. But considerable efforts have to be made for creating strategic plans.

Figure 4.5 presents an overall view on strategic information management planning and use.

In larger health care facilities, several stakeholders are typically involved in the creation, updating, approval, and use of strategic plans, such as top management, clinical and administrative departments, service departments and information management departments, staff members, funding institutions, consultants, or hardware and software vendors.

These stakeholders may have different expectations of a strategic plan and are involved in different lifecycle phases for the following strategic plans:

**Fig. 4.5** Strategic information management planning of health care facilities. A "strategic information management plan" gives directives for the construction and development of an information system. It describes the recent and the intended information system's architecture

Usually, the CIO, supported by the information management department, creates and maintains a proposal for the strategic information management plan. The CIO is interested in having clearly defned requirements for *management of information systems*. Top management is interested in the seamless and cost-effective operation of the health care facility. Top management approves the plans (probably together with the funding institutions). Employee representatives should be involved in eliciting the requirements, as they will be using the resulting information systems. The current strategic plan will be used by the information management departments and the vendors of components when modifying the information system. External consultants may help to create the plan though they may also be engaged in negotiations for the approval of the plan.

The most essential purpose of a strategic information management plan is to improve the information system so that it can best contribute to the business goals of the health care facility. This purpose should determine the structure of strategic plans; that is, it should show a path from the current situation to an improved situation in which the business goals are achieved as far as possible and reasonable.

A strategic information management plan thus should encompass the business goals, the resulting information management goals, the current state of the information system, and an assessment of how well the current information system fts the goals. Based on this assessment, the future state of the information system is described, together with a migration path represented by a strategic project portfolio that allows this future state to be reached.

The strategic plan must also deal with the resources needed to realize the planned architecture and must include rules for the operation of the information system and a description of appropriate organizational structures. Examples of resources are money, personnel, software and hardware, rooms for servers and (paper-based) archives, and rooms for staff training. The resources should ft the architecture and vice versa.

The general structure of strategic information management plans is described in the following paragraphs and is summarized in Fig. 4.6. It should be noted that this is only a basic structure which may be adapted to the specifc requirements of a health care facility.

**Fig. 4.6** Structure of a strategic information management plan

A short management summary and appendices describing the organizational structure, personnel resources, the building structure, etc. are likely to complement a strategic plan. Section 4.8.1 presents as example the structure of the strategic information management plan of Ploetzberg Hospital.

#### **<IP_ADDRESS> Annual Project Portfolio**

The *annual project portfolio* is derived from the strategic project portfolio as described in the strategic information management plan. While the strategic project portfolio represents the planned projects for a longer period of time (e.g., 3–5 years), the annual project portfolio describes the projects to be executed in the next year.

The annual project portfolio thus contains a list of projects to be initiated in the next year together with their priorities, timeline, and rough resources. This annual project portfolio implements the long-term strategic project planning into an annual planning. It may refect changes in prioritization of projects due to internal or external changes in the health care facility (e.g., a new data protection law or the availability of a new mobile technology). The annual project portfolio must be approved by top management, which also provides the needed resources for all projects.

An important instrument for building, managing, and updating annual project portfolios is portfolio management. Originating in the feld of fnance, the term portfolio management is today used in different management contexts.

A portfolio is a collection of objects grouped together to facilitate effective management of activities to meet strategic business objectives. Managing a portfolio comprises the selection and management of objects based on their value for the health care facility, but also based on their costs and risks and on their dependencies (i.e., one project can only start when another project has ended). Portfolio management establishes categories of objects (i.e., projects or application components) and defnes priorities for each category (i.e., which projects should start frst). Each category carries a different degree of risk and may thus need different project management methods.

In the context of *management of information systems*, portfolio management can focus on projects of information management or on components such as application components or physical data processing systems.

Project portfolio management categorizes IT projects, among other things, according to their contribution to the business goals, their risks, and their expected costs. Based on prioritizing projects, project portfolio management allows for the planning and controlling of IT projects. A project portfolio is typically built when an organization defnes or refreshes its strategic goals and its strategic information management plan. Both the fnal strategic project portfolio and the derived annual portfolio need to be authorized by the top management. To build a project portfolio, the following steps can be followed [1]:

Unlike project portfolio management, application component portfolio management considers different types of components. For example, the portfolio proposed by the Gartner Group distinguishes three categories of application components: Utility applications are application components that are essential for the operation of the health care facility but have no infuence on the business success and, therefore, are independent of the business goals (e.g., the *patient administration system*). Enhancement applications are application components that improve the performance and thus contribute to the success of a health care facility (e.g., computerbased *nursing management and documentation system (NMDS)*). Frontier applications are application components that infuence the position of the health care facility in the health care market (e.g., telemedical applications). Information management planning should aim at a well-balanced application portfolio—on the one hand, to effciently support essential functions of the health care facility and, on the other hand, to not miss out on future technological innovations.

## *4.3.2 Strategic Monitoring*

After having planned the information system strategically, one may expect that the information system will operate well in most of its functions, in most of its information processing tools, and in most parts of its operating organization. In many cases, however, problems may occur. Confdentiality of data may not be assured in some circumstances; transmission of clinical reports may not be timely; adequate data integration capabilities may not be provided and thus consistency of redundant data may not be assured between application components; or, since there is no data warehouse, the health care facility may not be able to collect and analyze aggregated data to support *patient care* and operations. There may be additional problems to be taken into account at a strategic level. For example, users may be increasingly dissatisfed with a specifc application component, technical or motivational problems may lead to a decrease in documentation quality, increased documentation time may limit the time available for direct *patient care*, there may be an unforeseen amount of high effort for support and training, or the number of medical errors may rise due to software errors or unusable software.

Besides low software quality, badly organized projects in tactical *management of information systems* or errors in *strategic management of information systems* may also lead to the problems described above. Such problems may become apparent very slowly, for example, when a formerly "good" component is not updated to match the overall technical progress, leading to inacceptable performance and functionality, or when more and more new application components need to be integrated into a spaghetti-styled architecture (compare Sect. 3.6.4). But problems may also arise very suddenly, for example, when a server suddenly crashes and no replacement is available or when, due to a software error, a wrong fnding is presented to a patient, a physician makes a wrong decision, and the patient is harmed.

Monitoring, as part of *strategic management of information systems*, means continuously auditing quality and cost of the information system and assessing whether the strategic information management plan has been implemented as intended. Auditing determines whether the information system is able to fulfll its tasks effciently, i.e., whether it contributes signifcantly to the facility's vision and mission, meets the stakeholders' requirements (Sect. 1.3), and fulflls the relevant laws. To allow auditing, monitoring needs to receive information from *tactical management of information systems* (e.g., on the successful completion of projects) and from operational management (e.g., on number of service desk calls) as well as information from users (e.g., from user satisfaction surveys) and from strategic management of the health care facility (e.g., on changes in the vision and mission). Additional information on the quality of the information system can be gained through evaluation projects. Monitoring results are used as input to direct tasks of *management of information systems*, which could, for example, initiate further projects. Monitoring results will also give feedback to update the strategic information management plan, which could, for example, lead to further activities of strategic management.

Typically, strategic monitoring comprises activities such as permanent monitoring activities, *benchmarking*, and ad hoc monitoring. These are explained in more detail in the following sections.

#### **<IP_ADDRESS> Permanent Monitoring Activities by Key Performance Indicators (KPI)**

An information system of a health care facility is typically too complex to allow all its components to be monitored at the same time. However, it is useful to defne a subset of quality criteria that is to be monitored on a regular (daily, weekly, monthly, yearly) basis. Quantitative measurements for regular monitoring of the achievement of strategic goals are also called *key performance indicators* (*KPIs*). In general, KPIs are a set of quantitative and well-defned performance measurements that demonstrate how effectively an organization is achieving key objectives. KPIs not only allow areas of improvement to be identifed but also help to compare own achievements to similar organizations (benchmarking).

KPIs for information systems demonstrate how effectively key objectives of the information system, as typically defned in the strategic information management plan, are reached. These KPIs could comprise, for example:

In Chap. 5, we will further discuss indicators for the quality of an information system and how they can be structured.

These KPIs should be recorded in quantitative and, as far as possible, in automated form to allow monitoring on a regular basis. Example 4.8.2 presents some KPIs of the information system of Ploetzberg Hospital.

Besides monitoring those indicators, data from other sources can also be related to the quality of the information system and thus be of interest for *management of information systems* as well, such as data from patient satisfaction surveys, medical error reports, or commentary on the health care facility in the local press. In addition, national legislation (e.g., new data protection law) and standardization initiatives (e.g., new version of HL7) should be monitored, as both may affect the information system.

Sudden changes in monitored numbers can indicate problems (e.g., malfunctioning of a component), which could then initiate more detailed analysis and corrections that are then to be initiated by strategic directing.

Permanent monitoring activities can be used to identify areas of improvement, but they can also be used to compare the quality of the information system with other organizations or with established standards in the form of benchmarking. Some benchmarking approaches are presented in the following section.

#### **<IP_ADDRESS> Benchmarking of Health Information Systems**

*Benchmarking* in general describes a process in which organizations evaluate various aspects of their performance and compare it to given standards or to the best organizations ("best practice"). Benchmarking uses quantitative criteria (KPIs) for comparing situations.

In strategic management, benchmarking is seen as an important approach to assess the performance of a health care facility. Benchmarking is often seen as part of a continuous quality improvement process in which health care facilities measure and then steadily improve their performance.

In strategic management of the information system of a health care facility, benchmarking can be used to assess the quality and costs of the information system in comparison with the information system of comparable facilities. Often, regional groups of health care facilities join together on an ad hoc basis to defne and compare benchmarking criteria.

The Digital Maturity Self-Assessment [2], for example, measures how well secondary care providers in England use digital technology to achieve a health and care system that is paper-free at the point of care. The assessment measures digital maturity against the following three key themes: readiness, meaning the extent to which health care facilities are able to plan and deploy digital services (e.g., strategic alignment and fnancing of IT); capabilities, meaning the extent to which health care facilities are using digital technology to support the delivery of care (e.g., IT use to support functions such as order management or decision support); and infrastructure, meaning the extent to which health care facilities have the underlying infrastructure in place to support these capabilities. These three key themes are selfassessed using a set of questions. Results can be easily compared between health care facilities to highlight opportunities for improvement or support investment decisions.

#### **<IP_ADDRESS> Ad hoc Monitoring Activities by Evaluation Projects**

Ad hoc monitoring activities may be initiated after larger changes of a component (e.g., introduction of a new application component) have been performed or when sudden larger problems have been observed. Ad hoc activities help to analyze a certain situation in detail in order to better understand the reasons of an observed problem or the consequences of a larger change. These ad hoc activities are conducted in the form of evaluation studies that are planned and conducted as evaluation projects by *tactical management of information systems* [3].

For example, during and after the introduction of a *computerized physician order entry system (CPOE)*, its quality and its effects on clinical care could be analyzed using a selection of the following evaluation questions:

Typically, quantitative and qualitative methods can be combined to answer such evaluation questions. Monitoring, as part of *strategic management of information systems*, collects and reports the evaluation results to directly give feedback to strategic planning of the information system.

We will discuss planning and conducting evaluation projects in more detail in Sect. 5.4.

## *4.3.3 Strategic Directing*

Strategic directing of information systems is a consequence of planning and monitoring the functions and the architecture of the information systems and the organization of *management of information systems*.

Directing, as part of *strategic management of information systems*, means transforming the strategic information management plan into action, i.e., systematically updating the information system to make it conform to the strategic plan. The system's manipulation is usually done by the initiation of projects. The projects deal with the construction or further development of components of the information system.

The projects to be initiated are taken from the strategic project portfolio as established in the strategic information management plan. The decision to initiate certain projects is part of strategic information planning. Strategic directing is then responsible for their prioritization, coordination, and initiation. Planning, directing, and monitoring these projects are the tasks of *tactical management of information systems*. Operational management will then be responsible for the proper operation of the components. An example of strategic directing is the initiation of a project for the introduction of the *CPOE system*.

In detail, the following main tasks of strategic directing can be identifed:

## **4.4 Tactical Management of Information Systems**

*Tactical management of information systems* deals with specifc components at the information system's three layers. It aims to introduce, remove, change, or maintain those components. Activities of *tactical management of information systems* are usually performed within projects. *Projects* are unique undertakings that are characterized by objectives, by restrictions with regard to available time and resources, and by a specifc project organization. Projects have to be initiated as part of an information strategy, which is formulated in the strategic project portfolio of the strategic information management plan. The result of all tactical information management projects is an updated information system [4].

Examples of projects of *tactical management of information systems* are:

Planning, as part of *tactical management of information systems*, means planning projects and all the resources needed for them. Even though tactical information management projects are based on the strategic information management plan, they each need an individual project plan. This project plan describes the project's scope and motivation, the problems to be solved, the goals to be achieved, the tasks to be performed, the activities to be undertaken to reach the goals, and the resources needed to complete the project.

Directing, as part of tactical management, means the execution of such tactical information management projects based on their project plan. Therefore, directing includes typical tasks of project management such as execution of the planned

**Fig. 4.7** Typical phases of tactical information management projects

working packages, resource allocation and coordination, and reporting of the project's results.

Monitoring, as part of tactical management, means continually checking whether the initiated project is running as planned and whether it will produce the expected results. Monitoring results may infuence project planning, as a project's plan may be updated or changed according to the results of the project's monitoring in a given situation.

Typically, tactical information management projects comprise a planning phase (including project initiation and planning), an execution phase (which is about monitoring the project and one or more of the following activities: system analysis and assessment, system specifcation, system selection, system introduction, and system evaluation), and a completion phase (Fig. 4.7).

## **4.5 Operational Management of Information Systems**

*Operational management of information systems* is responsible for operating the components of the information system. It ensures their smooth operation in accordance with the strategic information management plan of the health care setting.

Planning, as part of *operational management of information systems*, means planning organizational structures, procedures, and resources (e.g., fnances, staff, rooms, or buildings) that are necessary to ensure the faultless operation of all components of the information system. For example, *operational management of information systems* may require the installation of a user service desk and a service support system that enables the quick transmission of users' error notes to the responsible services. Such systems, but also respective staff resources, need to be planned and be made available for a longer period. Therefore, they should be allocated based on the strategic information management plan. Moreover, planning in this context concerns the allocation of personnel resources on a day-to-day basis (e.g., planning of shifts for staff responsible for user support or network management).

To guarantee the continuous operation of the most important *components of an information system*, it is helpful to draw up a long-term plan for *operational management of information systems*. Such a concept should clarify which components have to be supported, who is responsible for the operational support, and what the intensity of operational support should be. Table 4.1 presents components, responsibilities, tasks, and the intensity that should be defned as part of the operational management concept for the computer-based part of an information system.

As an example, a concept for operational management in a health care facility could clarify:

**Table 4.1** Dimensions to be considered for *operational management of information systems* of the computer-based part of an information system

#### 4.5 Operational Management of Information Systems

Directing, as part of *operational management of information systems*, is the sum of all management activities that are necessary to implement the plan and to ensure proper responses to operating problems of components of the information system. This comprises, for example, providing backup facilities, operating a service desk, maintaining servers, and keeping task forces available to repair network components, servers, PCs, or printers. Directing in this context deals with engaging the resources planned in such a way that faultless operation of the information system is ensured.

Monitoring, as part of *operational management of information systems*, deals with monitoring the proper working and effectiveness of components of the information system. For example, a network monitoring system may continuously be used to monitor the availability and correct working of network components of the health care facility.

Typically, three levels of operational support can be distinguished. First-level support is the frst address for all user groups with any kind of incidents disrupting the desired operating fow. It may consist, for example, of a central 24-hour hotline (service desk) responsible for frst trouble shooting and the management of user accounts, or it may consist of decentralized information managing staff. When solutions cannot be found for the reported incidents during frst-level support, secondlevel support must take over. This is performed by specially trained informatics staff, often located in the central information management department, who are usually responsible for the operation of the specifc application components. The third-level support, fnally, addresses the most severe problems that cannot be solved by the second-level support. It can be performed, for example, by specialists from the software vendor.

Operation and maintenance of components of the information system are part of its *operational management*. However, if problems occur (e.g., frequent user complaints about a *medical documentation and management system (MDMS)*), appropriate projects may be executed by *tactical management of information systems* (e.g., introducing a better version of the documentation system).

Built on top of *strategic and tactical management of information systems*, *operational management* thus offers users comprehensive services. These services go beyond simply delivering hardware and software. Rather, they are designed to help users use these components in a way that is helpful for their professional work. Such services are also known as *IT services*. Thus, the information management department of a health care facility is an IT service provider that delivers IT services to its customers, the users of the facility's information system. The management activities that serve to provide quality IT services are grouped under the term *Information Technology Service Management* (ITSM). ITSM therefore has the task to design, provide, deliver, and improve such customer-centered services. The Information Technology Infrastructure Library (ITIL) [5] is the de facto standard framework for ITSM. ITIL was developed for the British government in order to defne best practices for all governmental data centers.

For *operational management of information systems*, ITIL recommends setting up the following processes in particular:

The incident management process deals with the handling of incidents that disrupt users in the completion of their work (e.g., a non-functioning application system or printer). The aforementioned service desk is used to receive complaints about such incidents. If a solution for the customer cannot be found there immediately, the incident is declared a problem and passed on to the problem management process. If the problem management process reveals that changes need to be made to the components directly affected by the incident or to other components of the information system, the change management process will handle this. Since both small and large changes can always have side effects, ITIL also recommends a change management board as part of the process to coordinate and monitor the required changes. Incident, problem, and change management all require confguration management. With this term, ITIL means the processes that ensure that *management of information systems* always has a correct overview of all components of the information system and their connections, i.e., the information system's confguration. Corresponding confguration management systems can be based on 3LGM2 and the three levels defned there (Sect. 2.14).

Especially in a health care facility, where human lives may depend on the proper operation of the information system, it is recommended to have a systematic ITSM and to follow ITIL.

## **4.6 Organizational Structures for the Management of Health Information Systems**

Organizational structures for *management of information systems* differ greatly among health care facilities. In general, for each facility the adequate organization for strategic, tactical, and operational management of information systems and its proper integration into the decision structures of the facility must be established by *IT governance* as mentioned before. The resulting structures will depend on the facility's size, internal organization, needs, and goals.

Organizational structures can be described at the level of the health care facility as a whole (e.g., a chief information offcer, a central information management department) and at the departmental level (e.g., specifc information management staff for a certain department, a certain outpatient unit). We will now look at the role of the CIO and the information management department in more detail.

In this section, we frst discuss IT governance and the decision-making processes before discussing important roles in this context: the CIO, the *Information Management Board*, and the Information Management Department.

## *4.6.1 IT Governance and Organizational Structures for Information Management*

IT governance is the part of the overall management of a health care facility that deals with the organizational structures for decision-making in *management of information systems* [6]. The decision-making structures must be defned in such a way that the *management of information systems* is well integrated with the facility's management and is aligned to its strategic goals.

The organizational structures for decision-making must enable the *management of information systems* to create value for stakeholders (compare Sect. 1.3 for a list of stakeholders and their requirements) and minimize risks related to the information systems. Simply said, IT governance focuses on which organizational structures are needed to achieve value from the information system, and *management of information systems* describes how to use the structures for creating this value by properly planning, directing, and monitoring the information system.

In order to fnd the right organizational structures for decision-making for a health care facility, one should frst be clear about the felds in information management where decisions need to be made. In strategic information management, these are, in particular, decisions on the planned state of the facility's information system as part of the creation of the strategic information management plan. This includes decisions on the application systems to be used (Sect. 3.4), the architectural style to be used (Sect. 3.6), the design of the IT infrastructure (Sect. 2.11), and the basic IT principles that should be followed. IT principles refer, for example, to the use of certain standards (Sect. 3.7.2). In addition, there are the decisions on the migration path and the associated strategic project portfolio (Sect. <IP_ADDRESS>). Of particular importance are the fnancial decisions about the amount of investment in the information system and the allocation of the (limited) budget among the projects in the portfolio. In tactical information management, decisions must be made within the projects about the project plan and repeatedly about the appropriate execution of the individual project steps. In operational information management, decisions must be made repeatedly, especially about the prioritization of daily tasks.

Decisions in these decision-making felds can be made in different constellations depending on the circumstances of the health care facility and the management culture customary there. The types of such constellations described in the literature include business and IT monarchies as well as feudal and federal structures. In the monarchical constellations, the decision on the information system is made by the top management of the facility or by the information management leadership. Advisory bodies are often used to prepare the decisions. In feudal constellations, decisions are delegated to the management of sub-departments, such as the medical departments. In federal constellations, decisions on the information system tend to be made collegially by bodies such as an information management board (Sect. 4.6.3). Federal constellations are particularly common in large institutions or even corporate groups, as they are most likely to take into account both local characteristics and the interests of various stakeholders. Anarchic situations can also be observed, in particular in large institutions, though they may be desirable, for example in academia as a way of promoting creativity.

A framework for implementing IT governance principles in companies is COBIT (Control Objectives for Information and Related Technology) which is published by the Information Systems Audit and Control Association (ISACA). COBIT defnes goals both for the governance and the *management of information systems*. Furthermore, it describes processes and best practices that must be implemented in a company in order to achieve value creation through the information system and information. COBIT is being continuously developed and is currently available in version COBIT 2019 [7].

Depending on the decision-making feld (see above), the decision-making constellations in the same facility may well vary. Regardless of the decision-making constellations chosen, two structures are indispensable: the CIO and the information management department he or she is in charge of.

## *4.6.2 Chief Information Offcer (CIO)*

It is generally useful to centralize responsibilities for the *management of information systems* in one role. In larger health care facilities such as hospitals, this role is usually called *chief information offcer* (*CIO*) . Other common designations include vice president (or director) of information systems, of information services, of *management of information systems*, of ICT, or of information resources.

The CIO bears overall responsibility for the strategic, tactical, and operational management of the information system and the budgetary responsibility and has authority over all employees concerned with management of the information system. The specifc position of the CIO demands dedicated medical informatics competencies, executive and managerial competencies, and economic competencies.

Depending on the size of the health care facility, the role and the tasks of a CIO may be performed by one dedicated person (e.g., a full-time medical informatics specialist) or may be covered by another high-ranking role within the top management (e.g., by the chief executive offcer (CEO)).

Sometimes, the role of CIO is supported or replaced by more specifc roles such as the chief medical information offcer (CMIO) and the chief nursing information offcer (CNIO), each responsible for the related clinical aspects of information management.

If the institution has an information management board (Sect. 4.6.3), it is usually chaired by the CIO. Conversely, the leader of such a board is often considered the CIO if the position of CIO has not been explicitly established.

Ideally, the CIO should report directly to the top management of the health care facility and, therefore, should be ranked rather high in the organizational hierarchy. For example, the CIO may be chair of the information management department and in this role directly report to the CEO.

The CIO's role should be a strategic one that comprises the following tasks of strategic management of the information system:

The CIO's close relation to or, in some cases, even the membership within the top management team should provide the possibility to infuence the vision and mission of the health care facility using IT as a strategic resource. Therefore, both business and medical knowledge and the ability to effectively communicate with other managers, for example, the chief fnancial offcer (CFO) or the nursing director, is important for a CIO.

In some cases, the CIO may focus more on tactical and even operational management of the information system than on its strategic management. This may depend on the size and internal organization of the health care facility, such as top management membership, internal communication networks among top executives and the CIO, top management's strategic knowledge about the strategic role of the information system, and the personality of the CIO.

## *4.6.3 Information Management Board (IT Steering Committee)*

As explained in Sect. 4.6.1, in federal decision-making structures, strategic decisions on the information system tend to be made collegially by bodies such as an *information management board*. Members of this board are typically high-level representatives from the top management and from the main departments of a health care facility (see Sect. 4.8.3 for an example). Such a board is often referred to as the IT Steering Committee.

If the institution has an information management board, it is usually chaired by the CIO. Conversely, the leader of such a board is often considered the CIO if the position of CIO has not been explicitly established.

An information management board is particularly common in large institutions or even corporate groups, as they are most likely to take into account both local characteristics and the interests of various stakeholders.

## *4.6.4 Information Management Department*

In larger health care facilities, there is usually one central information management department (often called the department for medical informatics, data center, or ICT department). This department handles the facility's strategic management of the information system and at least of the tactical and operational information management of those parts of the information system with facility-wide relevance (e.g., the *enterprise resource planning system (ERPS)*, the *medical documentation and management system (MDMS)*, and the computer network).

In larger health care facilities, the information management department may consist of units that are responsible for certain tasks (e.g., different units for incident management, project management, clinical systems, administrative systems, IT networks, or medical devices). If the information management department also handles the strategic management of the information system, the head of this department can be considered the CIO.

With regard to the responsibilities for tactical and operational management of the information system, it is sometimes not useful and often not feasible to totally centralize these services. Especially in larger health care facilities, the services are performed in cooperation between central units and the decentralized staff. This staff may be comprised of dedicated medical informaticians or especially skilled users. These local information managers have responsibilities for tactical and operational management of the information system with regard to their own department but in accordance with the central information management department. For example, they may (with support from the central unit) introduce a facility-wide application component in their department and operate it. On the other hand, they will also have

to handle additional information needs of their departments, for example, by introducing a dedicated departmental system. However, this should be done only in accordance with the strategic information management plan.

In Sect. 4.8.3, we present as an example the organizational structure of information management of Ploetzberg Hospital.

## **4.7 Balance as a Challenge for the Management of Health Information Systems**

After reading the previous sections, it may seem that *management of information systems* must merely defne strategic goals for *management of information systems*, aligned with the business goals of the health care facility, and work towards them. However, reality is not that simple. *Management of information systems* is a lot about balancing priorities between various and often conficting goals. We will now discuss fve aspects of this task of "balancing" priorities.

## *4.7.1 Balance of Homogeneity and Heterogeneity*

The collection of information processing tools (both on the logical and at the physical tool layer) should be as homogeneous (i.e., comparable in appearance and usability, for example, using tools from the same vendor) as possible and as heterogeneous as necessary. In general, a homogeneous set of information processing tools makes training and support of users easier and thus leads to reduced costs for the health information system. However, in reality, we usually fnd a very heterogeneous set of tools at both the logical and the physical tool layer. Why?

In any health care facility, we need application systems at the logical tool layer for the support of the functions. Maximum homogeneity, at least for the computerbased part of a health information system, can easily be reached by a (DB1 , AC1 , V1 ) architecture, when just one application system exists that is implemented through a single application software product from a single manufacturer. Usually, however, diverse application software products from different manufacturers have to be purchased, which can lead to very heterogeneous (DBn , ACn , Vn ) architectures. These products might please the various stakeholders of the health care facility (which will all have optimal support for their tasks), but they will make integration, operation, and user support much more diffcult. These diffculties are often overlooked by the stakeholders concerned. In this situation, it is the task of the *management of information systems* to ensure and support an appropriate compromise between the need for economical homogeneous information processing and the needs of the various stakeholders.

At the physical tool layer, heterogeneity is often the consequence of the evolution of the health information system, comprising different generations of computer systems. This could be prevented only if all components are completely exchanged regularly, which is generally not sensible. In addition, heterogeneity is not always bad. For example, different mobile tools (laptops, tablets, and smartphones) may be needed to best support different user needs in different situations. But again, when this heterogeneity of information processing tools is not systematically managed, it can lead to the uncontrolled proliferation of tools and to unnecessary costs.

The better all stakeholders are involved in *strategic management of information systems* through an appropriate organization, the more this situation can be avoided.

## *4.7.2 Balance of Computer-Based and Paper-Based Tools*

It is the task of managing health information systems to manage information processing in such a way that the strategic goals of the health care facility can best be reached. For a health care facility whose goal it is to provide very personal and humane treatment, it might therefore make sense to abstain from the use of technology and especially computers for all immediate physician–patient contact. This would include, for example, writing with paper and pen (or with the so-called digital pens) during a direct physician–patient encounter, rather than using a computer for data entry, as this may help support this strategic goal.

For a health care facility whose goal involves technological leadership and integrated processes, it might be more appropriate to proceed in the opposite direction, i.e., to strive for a good support of all working processes through computerbased tools.

That is, the optimum of computer support is not defned by the maximum; rather, it evolves through the strategic goals of the health care facility and its stakeholders as well as through the functions to be supported.

## *4.7.3 Balance of Data Security and Working Processes*

The data stored in a health information system are worth protecting. Patients must be confdent that their data will not be made available to an unauthorized third party. To ensure this, the appropriate laws of the particular country are to be adhered to. However, health information systems are not just purely technical, but rather are socio-technical systems. This means that people are also part of the information system and are therefore also responsible for data security and protection.