Architecture of Clinical Computing Systems

Thomas H. Payne1; Kent A. Beckton2    1 Medical Director, Information Technology Services, UW Medicine; Associate Professor, Department of Medicine; Adjunct Associate Professor; Department of Biomedical Informatics and Medical Education and Department of Health Services, University of Washington, Seattle, WA USA
2Director, Technical Architecture, Information Technology Services, UW Medicine, Seattle, WA USA

Abstract

The purpose of this chapter is to give an overview of the fundamentals of clinical computing system architectures. This is changing with the advent of cloud computing and sophistication of web applications, but most large organizations follow architectural models that have been in place for decades.

Keywords

architectural models

electronic medical record

computerized physician order entry

HL7

electronic health record

best-of-breed solutions

workstations

Contents

1. What is architecture, and why is it important?   11

2. Architectural models   13

3. Architecture of computing systems in healthcare organizations   14

3.1 Core EHR (electronic health record) systems   14

3.2 Departmental systems   15

3.2.1 Foundational systems   15

3.2.2 Data repositories   16

3.3 Interface engines   16

3.4 Networks, hosts, servers, "middleware," workstations   16

3.5 Best of breed versus suite from a single vendor   17

4. End-user applications: strengths/weaknesses of web and other development choices   18

4.1 Application delivery   18

5. Examples of clinical computing architectures   19

References   22

1 What is architecture, and why is it important?

To build a medical center requires expertise in engineering, human factors, design, medicine, and also architecture. It is the architect who melds design and function with engineering and practicality. We look to the architect to keep parts functioning together, and to plan for changes and additions that fit with the original design. Similarly, clinical computing systems have an architecture and often an architect behind them. Particularly in an era when most organizations license software from multiple computing system vendors, it is important to maintain an overall architecture to meet the organization's current and future needs.

The goals of a good architecture are that the resulting system:

 Is scalable

 Is supportable

 Is cost effective

 Is flexible for innovations

 Is available for intended use

 Has acceptable performance

 Has functional processes for testing and change

Architecture varies between organizations. Making the organization's architecture clear permits vendors to offer and supply elements needed within the architecture. For example, where are Master Patient Index services provided? Are departmental systems from a single vendor or several vendors? An additional challenge is that the application vendor's architecture is often different from the organization's architecture.

When components or systems are developed by internal teams, the relationship between existing and newly developed systems is understood by review of the architecture and understanding of messaging and other standards used within it. Similarly, when healthcare organizations combine computing resources as a result of a merger or in another manner, existing systems or components may be combined to form the computing of the new, larger entity. How will all these components fit together? What will be shared or duplicated?

When teams within the organization plan upgrades, improvements in availability, software and hardware changes, they are better able to plan when there is a shared understanding of how the components within their responsibility relate to other elements in the organizational clinical computing architecture. Clear description of the architecture makes implications for planned changes clearer. Long-term planning (by IT teams and executives) for migration of systems, hardware, and computing infrastructure can be better understood by examining the larger view. For clinical informaticians supporting healthcare organizations, understanding architecture can aid troubleshooting in a similar manner as an understanding of human anatomy aids diagnostic reasoning.

The purpose of this chapter is to give an overview of the fundamentals of clinical computing system architectures. This is changing with the advent of cloud computing and sophistication of web applications, but most large organizations follow architectural models that have been in place for decades.

2 Architectural models

The simplest clinical computing system architecture is a single system, with a single database in which all data are shared between applications such as patient registration, laboratory, radiology, and others. Such a system may be developed within the organization or licensed from a single vendor. Early in the history of clinical computing, this model was common. Applications may have been based on a single vendor's hardware and database management systems, with new applications added as new screens or small applications within the larger whole. Using this simple architectural model, data stored in one location could be much more easily shared between applications. For example, when a patient is registered, demographic information is stored in a database file. The laboratory module from the same system accesses the demographic information from the same database, as do the radiology and pharmacy applications. This sort of collection of applications developed from the same core system is said to be integrated together, in that they are all parts of a single, large system.

In medical centers and large clinics-the targets of this book-that simple architectural model rarely applies to clinical computing systems in use today. There are usually many separately designed computing systems, each contributing a portion of the data and functionality used in clinical care. Medical centers combine data and application functionality from many separate computer systems, some of which may be used by a large number of those involved in patient care, while others may be used by a small number of people specializing in some aspect of care. Instead of sharing a common database, many or all of these smaller applications have their own. To save the cost of re-entering information into each system, and to share data that each system contains, data are exchanged through connections called interfaces. For this reason, this model is referred to as interfaced systems.

In most organizations, the clinical computing architecture includes components of both these archetypes: integrated and interfaced systems. There may be a large core system containing integrated applications, and many smaller systems connected to this large system using interfaces. There are other methods that we describe later to permit users to view data originating from separate, smaller systems without realizing they are navigating to other systems.

Some clinical computing systems are presented to the user as a web application, and some have core services delivered through the cloud (see Chapter 4). This makes a difference in where the hardware providing functionality is located and maintained, but cloud applications can also be integrated or interfaced. If the cloud EMR (electronic medical record) is connected to a local laboratory and radiology system, the overall architecture is similar to an interfaced system as described above. Conversely, if most system components are within the cloud-based system, it resembles an integrated architecture.

The organizational clinical computing architecture defines how all the component systems fit together, how they exchange information, standards used within systems and in interfaces, what shared services exist for the benefit of all computing systems, and many other issues.1

An important starting point in planning an architecture is to establish standards, such as use of HL7 (Health Level 7). There may be more than one variation of the standard used within the organization, and this should be made explicit. Plan the architecture with an eye towards the future, and stay apprised of technical innovations.

3 Architecture of computing systems in healthcare...