e-mail: pk@sdh.sk.ca Nunzio M. Fortugno Principal Cylinea Systems - - PDF document

Thin Client Computing in a Complex Health Care Environment Page 1

• A Case Study

Kjargaard THIN CLIENT COMPUTING IN A COMPLEX HEALTH-CARE ENVIRONMENT – A CASE STUDY Submitted by: Perry Kjargaard Manager – Application Development and Integration Saskatoon District Health 701 Queen Street Saskatoon, SK, Canada S7K 0M7 Phone (306) 655-8403 e-mail: pk@sdh.sk.ca Nunzio M. Fortugno Principal – Cylinea Systems Corporation 327 Schubert Place NW Calgary, AB, Canada T3L 1X2 Phone (403) 560-1144 e-mail: nunziof@cylinea.com Michael Leydon President – QCC Communications 201 – 116 Research Drive Innovation Place Saskatoon, SK, Canada Phone (306) 249-0220 e-mail: mikel@qcc.sk.ca Guy Paterson Director – Information Systems and Telecommunications Saskatoon District Health 701 Queen Street Saskatoon, SK, Canada S7K 0M7 Phone (306) 655-8515 e-mail patersong@sdh.sk.ca

Thin Client Computing in a Complex Health Care Environment Page 2

• A Case Study

Kjargaard INTRODUCTION Saskatoon District Health (SDH) is a fully integrated healthcare organization located in the province of Saskatchewan, Canada. The district is responsible for all healthcare services within its

• boundaries. SDH consists of three major acute care hospitals located within the metropolitan area of the
• city. The district is also responsible for the provision of all public health, home care, long-term care,

mental health, laboratory, pre-hospital, addictions, and community health services and operates several rural community health centers. The district has 8,000 employees in 40 locations. It serves as a primary care provider for a population base of 330,000 and as a tertiary care center for a population of 1 million. As a major referral center, over 60 percent of the medical care provided by the district is to clients from outside its boundaries, including many from remote aboriginal communities. Clients utilizing the services of SDH are drawn from an area of 651,900 km2—an area equivalent to the size of Oklahoma, Arkansas, Mississippi, Alabama, and Indiana combined. The SDH Information Technology Group is responsible for the deployment and management of integrated healthcare information systems for the entire district. As part of a series of projects initiated in 1997, SDH was faced with a massive deployment of an integrated healthcare information system for the entire district. One of the key objectives of this “Project Connect” deployment was the provision of a desktop environment that would be capable of supporting new clinical applications and would also provide the ability to use existing legacy applications and desktop productivity software, as required by SDH business units. The desktop technology deployed also needed to be able to support near-term future technical initiatives, such as the use of J ava-based applications. During the early stages of the project, the SDH Project Connect Technical Team identified an emerging technology known as “thin client” architecture. The Project Connect Team carried out a review

• f literature, cost evaluation, and technical proof-of-concept lab test. The purpose of the investigation and

test was to answer the following questions:

• Is the new enterprise application client software compatible with a thin client architecture?
• What size of thin client middle tier server is necessary to obtain reasonable performance

under a series of predefined and variable load conditions?

• Is the thin client architecture robust enough for the enterprise environment?
• What effects will the three-tier, thin client, execution server/ application server architecture

have on the backbone and horizontal portions of the network?

• What are the potential long-term benefits of deploying a thin client architecture?

Using the test results, we prepared a cost model and a technical review of the thin client architecture showing the fit with our technical architecture blueprint and the potential economic impact

Thin Client Computing in a Complex Health Care Environment Page 3

• A Case Study

Kjargaard

• f the thin client architecture to SDH. To assist us in successfully implementing the thin client

architecture, we utilized a number of external consultants who have assisted in co-authoring this paper. Cylinea Systems Corporation undertook the initial technical design and background investigation, developed a test methodology, and reviewed the test results. QCC Communications assessed communications issues during the test phase and provided analyses of network implications. REVIEW OF TECHNOLOGY AND POTENTIAL BENEFITS Thin Client Architecture Thin client architecture is reminiscent of pre-PC computing environments where simple “dumb terminals” on users’ desks were connected to a central processing host. In such environments, management and administration activities were concentrated on the host processor. The cost of operating the terminals was low; the availability (uptime) of the terminals was primarily dependent upon the availability of the centrally managed host and tended to be quite high. With the advent of personal computer (PC) workstations, a great deal of complexity was shifted from the central computer room to the desktop. The increased power at the desktop allowed for more flexible and powerful applications, as well as easier-to-use and more engaging graphical user interfaces (GUIs). This “thick client” architecture allowed a significant distribution of computing power and placed a great deal of the control of an organization’s information technology (IT) resources into the hands of

• users. While expert at their own jobs, users typically did not have the qualifications necessary to manage

computing resources for the long-term benefit of the organization. By the late 1980s, it became apparent that the downside to the PC environment was that the increased complexity at the desktop now resulted in high costs of ownership. PCs are much more complex than terminals; they have mechanical disk drives that can fail or that can be used for unauthorized installation or copying of software and data. The PC operating software is under the control of the user, who is then able to make configuration changes (either by accident or by design) that have an impact on the function of the desktop. This double-edged sword led to significant increases in the operational costs required to maintain thick client desktop environments. Thin client architecture provides many of the benefits of a thick client (GUI, powerful and flexible applications, ease of use) while minimizing many of the disadvantages. The client device or network station—often called a network computer (NC)—is a minimalist version of a PC, with a keyboard, mouse, video display, a small processor with memory, and a network connection. The processing power of an NC resides on centralized execution servers and boot servers, which are under the management and administrative control of the IT specialists within an organization. The end users interact with the NC just as they would with a conventional PC. There is a network connection, a high-resolution display, keyboard, mouse, and, if required, sound input/ output

Thin Client Computing in a Complex Health Care Environment Page 4

• A Case Study

Kjargaard (I/ O) devices. The key difference is that other than those I/ O devices and a small local processor, the terminal has no other components. The processing is performed on the execution server. This “thinning”

• f the client removes the requirement to have a fully configured PC client on the user’s desktop, and, as

we will describe, leads to significant reduction in the total cost of ownership (TCO) of the entire network. Industry estimates have placed the long-term cost of ownership of a thin client environment at

• ne-fifth to one-tenth the per seat cost of a thick client environment. With potential savings of this

magnitude, Project Connect chose to investigate the suitability of this technology for use within the SDH. The operation of the NC devices within the SDH project architecture is illustrated in Figure 1.

Figure 1 – NC Operation Overview

Note that the architecture is a hybrid and makes use of both NCs and PCs as required within the

• district. The goal was to achieve an architecture that is robust as well as cost effective to maintain and

support, but that does not limit the ability of the SDH IT infrastructure to support a mix of past, current, and future business-critical applications. TCO and the Thin Client Cost Model Often overlooked by IT groups implementing new systems is the total cost of ownership (TCO). The TCO includes all the costs that will be incurred during the entire life cycle of an IT environment. Industry watchdogs have estimated that the monthly cost of ownership for a conventional thick client desktop is over $900 per seat ($10,800 per year). Experience of the SDH Technical Team members has shown that the cost per seat can vary dramatically. On one end of the spectrum, a large energy firm in

Thin Client Boot Server Execution Server UNIX Middle Tier Thin Client Workstation C i t r i x N T A p p s Start-up / Initialization Files JAVA Code (Java Direct to Thin Client's Internal JVM) Financials and Medical Inventory Server SDH Network Backbone Switch Execution Server JAVA Code (Java To JVM on Execution Server) IE Browser via Citrix (Java Option B)

Thin Client Computing in a Complex Health Care Environment Page 5

• A Case Study

Kjargaard Calgary achieved a low of $250 per month ($3000 per year) in a highly standardized, heavily automated, process-driven environment. Costs can rise to well over $1000 per seat ($12,000 per year) and more in

• rganizations that take an ad hoc approach to systems management. Studies by the Gartner Group and

Forrester Research conservatively estimate that implementing a thin client architecture results in a 30 percent reduction in cost of ownership (W. Kirwin, Network Computing Client/ Server [NCCS], Gartner Research Note KA-TCO-513; Rhinelander, Debunking TCO Hype, T. Forrester Brief, J

• an. 31, 1997).

TCO includes (among other factors) the following long-term operational considerations: 1. Number of support technician visits to the desktop to diagnose and correct problems. 2. Desktop hardware break/ fix costs. 3. Amount of time spent by users trying to correct problems with the desktop. 4. Management of licensed software distributed to desktops. 5. Management of software deployment to desktops. 6. Number of desktop problems caused by user intervention (removed DLLs, installed unauthorized software, etc.). 7. Management of desktop local accounts (such as network terminal local administration). 8. Backup/ recovery of locally stored data on desktops. 9. Security management of information locally stored on desktops. Additional benefits of thin client computing Our analysis shows that each of these TCO factors is significantly reduced or eliminated in a thin client environment. 1. Software deployment to thin clients requires that application software files be placed on the terminal servers only. No download to the desktop is required. 2. NC desktop hardware will have significantly reduced obsolescence due to its nature and reliability. 3. Network traffic between backbone and desktops is reduced significantly with NC desktops. Once the NC has booted up, the only network traffic is due to the exchange of screen displays, keystrokes, and mouse movement data. 4. Administration of local workstation accounts is eliminated on thin desktops. Using the following series of assumptions and estimates, a cost-benefit analysis was performed. The analysis compared the TCO of a hybrid, thick/ thin client environment vs. a pure thick (PC only) client environment. Assumptions for Our Cost Models 1. Network costs, server domain administration costs, and user training costs are equal in both scenarios. 2. Centralized server management for the thin client environment requires the equivalent of one full- time employee per 50 servers. 3. SDH will provide one terminal server for every 25 thin clients. 4. SDH will provide one boot server for every four terminal servers. Two cost models were prepared, using an optimistic and pessimistic (conservative) set of estimates and assumptions. The optimistic estimates were based on available industry data indicating that the TCO of a PC desktop is approximately $9000 per year per desktop. The pessimistic estimates (TCO = $3000 per year per desktop) were based on actual data obtained from a large Calgary firm that focussed significant resources on desktop management. Both cost-benefit models show that the

Thin Client Computing in a Complex Health Care Environment Page 6

• A Case Study

Kjargaard thin/ thick hybrid client environment yields long-term cost savings over a purely thick (PC) desktop environment. Per workstation capital costs and TCO relative to thick clients In order to compare the capital costs relative to thick clients, these assumptions were made. Also included in the model is an estimate of the number of clients who can be supported by a single terminal server. 1. Model estimates will be based upon a total population of 500 NCs and 300 PCs. 2. Model estimates will include hardware costs and software licensing costs directly related to the NC

• environment. Components such as monitors are excluded since they are required for both NCs and

PCs. 3. Additional network costs due to potentially different bandwidth demands have been excluded. (This exclusion favors the PC environment, since in general, distributed bandwidth requirements would be higher with PCs.) The cost models compare a mixed NC/ PC environment to a PC-only environment. As shown, the initial capital cost of the mixed NC/ PC environment is higher (due to the need for middle-tier servers). However, the operating cost for the NC desktop is much lower than for the PC desktop, thereby generating a potential cost savings of over $5M over the next 5 years (pessimistic case). Ongoing Operating Cost Elements It is important to note that if the current SDH costs per desktop are lower than the estimated $3000 per desktop (a low figure by industry standards) used in the TCO model, a more relevant metric that could be applied is the cost per service level currently being provided to SDH. For the same or lower cost, the NCs will enable SDH to deliver a much higher service level for the desktop environment. Tables 1 and 2 provide cost-benefit models using pessimistic and optimistic estimates respectively.

Thin Client Computing in a Complex Health Care Environment Page 7

• A Case Study

Kjargaard

Table 1 – Pessimistic Cost Model

Number of NCs to be deployed 500 Based on Estimates Provided by SDH IT Cost of PC (without monitor) $1,500.00 IBM Quote, 1998 EOY Pricing Cost of NC (without monitor) $1,500.00 IBM Quote, 1998 EOY Pricing Monthly Support Cost of PC $250.00 Based on TCO of $3000.00 per PC, per year. Monthly Support Cost of NC $30.00 Based on TCO of $360 per NC, per year. (1/8th as per Forrester) Install Labour Cost of PC $200.00 (4 hours, @ $50/hour) Install Labour Cost of NC $25.00 (1/2 hour @ $50/hour) NT User Licence $300.00 (Estimated) NT Terminal Licence $300.00 (Estimated) Execution Server Licence $300.00 (Estimated) Execution Server Cost (HW& SW) $30,000.00 IBM Quote, 1998 EOY Pricing + Software ($5000/server) Number of Execution Servers $20.00 Based on 25 NCs per Terminal Server, NCs only. Boot Server Cost (HW & SW) $25,000.00 IBM Quote, 1998 EOY Pricing Number of Boot Servers 5.00 1 Boot Server per 4 Terminal Servers PC Only PC/NC Savings Desktop Install Labour Cost $160,000.00 $72,500.00 $87,500.00 Desktop Hardware and Software Cost $1,440,000.00 $1,740,000.00

• $300,000.00

Execution Server Cost $0.00 $600,000.00

• $600,000.00

Boot Server Cost $0.00 $125,000.00

• $125,000.00

Yearly Support Cost of Desktops $2,400,000.00 $1,080,000.00 $1,320,000.00 Savings against Capital in Year 1

• $937,500.00

Yearly Desktop Operational Savings $1,320,000.00 Desktop Operational Savings over 5 Years $5,662,500.00

$0.00 $500,000.00 $1,000,000.00 $1,500,000.00 $2,000,000.00 $2,500,000.00 PC Only PC/NC

PC vs NC Cost Model (Pessimistic)

Desktop Install Labour Cost Desktop Hardware and Software Cost Execution Server Cost Boot Server Cost Yearly Support Cost of Desktops

Thin Client Computing in a Complex Health Care Environment Page 8

• A Case Study

Kjargaard

Table 2 – Optimistic Cost Model PC / NC Deployment / Support Cost Model

Model Parameter Value Notes

NCs Per Execution Server 25 Based on Tests Results and Safety Margin Number of PCs to be deployed 300 Based on Estimates Provided by SDH IT Number of NCs to be deployed 500 Based on Estimates Provided by SDH IT Cost of PC (without monitor) $1,500.00 IBM Quote, 1998 EOY Pricing Cost of NC (without monitor) $1,500.00 IBM Quote, 1998 EOY Pricing Monthly Support Cost of PC $750.00 Based on TCO of $9,000.00 per PC, per year. Monthly Support Cost of NC $93.75 Based on TCO of $1125 per NC, per year. (1/8th as per Forrester) Install Labour Cost of PC $200.00 (4 hours, @ $50/hour) Install Labour Cost of NC $25.00 (1/2 hour @ $50/hour) NT User Licence $300.00 (Estimated) NT Terminal Licence $300.00 (Estimated) Execution Server Licence $300.00 (Estimated) Execution Server Cost (HW& SW) $30,000.00 IBM Quote, 1998 EOY Pricing + Software ($5000/server) Number of Execution Servers $20.00 Based on 25 NCs per Terminal Server, NCs only. Boot Server Cost (HW & SW) $25,000.00 IBM Quote, 1998 EOY Pricing Number of Boot Servers 5.00 1 Boot Server per 4 Terminal Servers PC Only PC/NC Savings Desktop Install Labour Cost $160,000.00 $72,500.00 $87,500.00 Desktop Hardware and Software Cost $1,440,000.00 $1,740,000.00

• $300,000.00

Execution Server Cost $0.00 $600,000.00

• $600,000.00

Boot Server Cost $0.00 $125,000.00

• $125,000.00

Yearly Support Cost of Desktops $7,200,000.00 $3,262,500.00 $3,937,500.00 Savings against Capital in Year 1

• $937,500.00

Yearly Desktop Operational Savings $3,937,500.00 Desktop Operational Savings over 5 Years $18,750,000.00

$0.00 $2,000,000.00 $4,000,000.00 $6,000,000.00 $8,000,000.00 PC Only PC/NC

PC vs NC Cost Model (Optimistic)

Desktop Install Labour Cost Desktop Hardware and Software Cost Execution Server Cost Boot Server Cost Yearly Support Cost of Desktops

Thin Client Computing in a Complex Health Care Environment Page 9

• A Case Study

Kjargaard TESTING METHODOLOGIES AND TEST RESULTS Methodology A test network was implemented at the Project Connect site. An isolated network segment was created as shown in Figure 2. The devices used in the test environment are listed in Table 3.

Figure 2 – NC Pilot Test Network Configuration

10BaseT Hub (Typical Room) x n SS2200 100Mbps Switch 10.100.250.3 (Closet 6B) SS2200 100Mbps Switch 10.100.250.2 (Room 6300) NC 1 (NC LAB) 10.20.63.1 Test PC 1 IMN Enovation ORACLE Server RS/6000 10.150.1.41 (Server Room) NC Execution Server (NT Terminal Server / Citrix Metaframe) 10.20.1.2 (Server Room) NC Boot Server (Server Room) 10.20.1.1 NC 2 (NC Lab) 10.20.63.2 NC 3 (NC Lab) 10.20.63.3 Test PC 2

100 100 100

10 10 10 10 NT Primary Domain Controller 10.10.1.1 (Server Room)

100 100

10BaseT Hub 10.100.50.49 (Closet 6B) 10 10 IBM AS/400 (SDH Production Network) 10.150.1.16 10 NC 4 (NC Lab) 10.20.63.4 NC 6 (NC Lab) 10.20.63.6 NC 7 (NC Lab) 10.20.63.7 NC 5 (NC Lab) 10.20.63.5 10 10 10 10

100 100

Thin Client Computing in a Complex Health Care Environment Page 10

• A Case Study

Kjargaard

Table 3 – Devices Used in NC Tests

Device Specifications Quantity Notes IMN ORACLE Database Server IBM RS/ 6000 Model F- 50 1 This machine is significantly smaller than the planned production IMN server. However, it was not a bottleneck during testing. HBOC Server IBM AS/ 400 1 This was the only legacy production server involved in the pilot (used for testing HBOC). NC Boot Server IBM PC 300 GL (Pentium 233 with 64 MB RAM) 1 This server boots up (initializes) the NCs. NC Terminal Server A Digital (Dual Pentium 200 with 256MB RAM) 1 This terminal server was used in the morning portion of the pilot. NC Terminal Server B IBM Netfinity 7000 (Quad Pentium Pro 200MHz, 1GB RAM) 1 This terminal server was used in the afternoon portion of the pilot. NC Terminal Server C IBM Netfinity 5500 (Dual Pentium II, 450MHz, 1GB RAM) 1 This terminal server was used in supplemental testing performed after the pilot. NC Terminal Server D IBM Netfinity 5500 M10 (Dual XEON Processor, 1GB RAM) 1 This terminal server was used in supplemental testing performed after the pilot. NC Type 1 IBM NetworkStation Model 300 5 NC with 10 Mbps network connection, 32 MB RAM, slower processor. NC Type 2 IBM NetworkStation Model 1000 2 NC with 10/ 100 Mbps network connection, 64 MB RAM, faster processor. Test PCs Various IBM Pentium PCs 13 These were used to simulate NCs by running the ICA thin client software. Prior to the test, the Project Connect managers were asked to prepare test scripts for the main clinical application and for an AS-400 based legacy application. The Connect Technical Team prepared test scripts for productivity software. A test schedule was prepared showing which scripts would be executed during each part of the test. Technical teams were created to monitor the behavior of the network and of the servers during testing. Each tester was issued a testing binder containing all scripts to be performed. Any relevant information and observations were to be documented within the scripts during the test. The test was divided into two major parts. During the morning, testing took place against a terminal server configured as a dual Pentium 200 MHz with 256 MB of RAM. In the afternoon, testing took place against a terminal server configured as a Quad Pentium Pro 200 MHz with 1GB of RAM. The following reports were prepared from information gathered during the test: 1. Server Report – indicating performance vs. load (CPU, memory, page/ swap, cache, threads) 2. Network Report – utilization statistics, error statistics, traffic characterization by application (by test)

3. Application Report – summary of the test results for the applications (performance, availability) Subsequent testing was performed against a dual XEON processor server to determine the maximum useful load that could be handled by a single server.

Thin Client Computing in a Complex Health Care Environment Page 11

• A Case Study

Kjargaard Test Observations and Results Qualitative findings Observations of the users during the pilot showed that while they were connected to the small terminal server, most users found the performance at the NC to be unsatisfactory. When they were connected to the larger terminal server, performance was subjectively rated by the users as good, and comparable to their own PC desktop’s performance. NC boot server The NC boot server tested was a Type 1 (P233) personal computer (233 MHz, 64 MB RAM), connected to the test network via a 10 Mbps Ethernet connection. The boot server is used to initialize the NCs by downloading a 3 MB set of initialization files. During the pilot, the boot server central processing unit (CPU) and memory were not stressed. However, the boot server’s Ethernet connection was of insufficient bandwidth to prevent delays in booting up the NCs. This problem can easily be addressed by configuring the boot servers with high-speed network interface adapters and placing them on switched rather than shared network segments. NC execution server Three different classes of NC execution server have been tested. Table 4 presents a summary of server performance.

Table 4 – Server Performance

Server Configuration Tested Thin Client to Execution Server Ratio Achieved Dual Pentium 200 MHz, 256 MB RAM 13:1 Quad Pentium Pro 200 MHz, 1 GB RAM 40:1 Dual Pentium II 400 MHz, 1 GB RAM 25:1 Dual XEON, 1 GB RAM 50:1 The first terminal server was a dual P200 with 256 MB of RAM. The dual P200 server proved to be significantly undersized for the load generated by 20 users. During the first clinical application cycle test, server performance degraded quickly and bottomed out at the 13th user. Memory was the bottleneck and caused the server to swap to disk excessively, which increased system overhead and further degraded performance. Similar results were observed for all tests against the dual P200 box. The next server tested was a Quad P200 with 1 GB of RAM. The performance with the Quad P200 server was significantly better. The Quad P200 makes a good terminal server (40:1 NC to terminal server ratio). The model tested was overconfigured in terms of disk and internal expansion capability. In order to find a more cost efficient server platform for the district, further testing was performed with a third execution server, a PII 400. Testing with the PII 400 showed that it is slightly more than half as powerful as the Quad P200. The final testing was performed with a Dual XEON processor with 1 GB of RAM. The dual XEON server outperformed the Quad P200. Testing showed that the dual XEON server could easily handle an NC to terminal server ratio of 50:1.

Thin Client Computing in a Complex Health Care Environment Page 12

• A Case Study

Kjargaard NC workstations Two types of network station NCs were tested: 1. Type 1, which has a 10Mbps network interface, 32 MB of RAM, a smaller processor and less expansion capability, and runs its J ava virtual machine (J VM) in software. 2. Type 2, which has a 10/ 100Mbps network interface, 64 MB of RAM, a more powerful processor, greater memory expansion capability, and runs its J VM in firmware (which is flash upgradable). Both the NC models tested were found suitable for the software tested. If in future SDH wished to use the NCs for use with J ava-based applications, the Type 1 NC would not be suitable, since it runs the J VM in software and has less memory and a slower processor than the Type 2 NC. For these reasons and for long-term cost-efficiency, the selection and deployment of the Type 2 NC was recommended. Impact on Desktop Management In the execution server environment, system management is centralized to the NT domain servers, the NC boot servers, and the NC terminal servers. All user-specific configuration can be performed remotely by a systems administrator. Since the NC workstations do not have any local storage (and consequently no local NT configuration files), system management of the entire NC population can be accomplished centrally from the servers. It is important to note that these benefits are primarily derived from using the features of advanced thin client software. The same benefits could be derived whether NCs or PCs running thin client are used. In addition to these benefits, it is significant that hardware problems can be quickly resolved by removing the failed NC and replacing it with a working NC (elapsed time ~ 10–20 minutes, not including shipping and logistics time). With a PC, setup and copying of local files would lead to an elapsed time in the order of 120 minutes (excluding shipping and logistics), assuming data can be copied (recovered) from the hard drive of the failed PC. Overall reliability Based upon the experience during the pilot, at no time did any of the servers (NT domain, NC boot, NC terminal) ever require a reboot. Even when a small server was tested as the NC terminal server and was subjected to extreme processor and memory loading conditions, the server continued to operate (although slowly). During the pilot, users were challenged to try to crash the server (by running multiple applications, large data files, processor-intensive tasks, etc.). No user was able to crash any of the NC terminal servers tested. ASSESSMENT OF NETWORK EFFECTS OF THIN CLIENT In addition to selecting applications, servers, and client workstations that conformed to the thin client computing model, it was necessary to specify, provision, deploy, and integrate an underlying network infrastructure that would meet the real world data transfer requirements of the thin client computing approach. SDH therefore undertook in parallel a major network upgrade initiative as part of the overall Project Connect.

Thin Client Computing in a Complex Health Care Environment Page 13

• A Case Study

Kjargaard From a basic planning and standardization perspective, the access portion of the SDH network was specified as Ethernet (IEEE 802.3). The standard protocol suite is TCP/ IP. Any selected thin client implementation and resulting network enhancements would need to continue to conform to these network protocols. From a logical perspective, the thin client model (see Figure 3) is relatively straightforward.

Figure 3 – Basic Thin Client Logical Model

Workstation (Thin Client) Execution Server Back-End Server Access/ Distribution Network Back-End Network

To be able to specify the requirements for the underlying network, the nature of the traffic on each of the conceptual network segments needed to be understood. The thin client model creates certain qualitative expectations about network traffic patterns. In the general operational mode, there would be an expectation that traffic between a back-end server and an execution server would closely resemble conventional thick client–server computing traffic patterns, i.e., bursty - periodic instances of high traffic levels corresponding with the delivery of query results from the back-end application server to the emulated client on the execution server. As data traversing the execution-server-to-thin-client link basically involves the transmission of screen updates in one direction and keyboard/ mouse activity in the other, the traffic expectations would include a lower overall traffic level. How low would effectively be a function of the specific implementations and optimizations within the individual vendor’s thin client protocol and approach. The NC testing that was carried out included the measurement of operational traffic levels for various end use modes and applications. The measurement of actual traffic levels corresponded to these qualitative expectations. The specific test results enabled SDH IT staff to generate initial scaling plans in terms of metrics such as number of thin client endpoints per execution server and number of back-end servers per execution server. Thin client devices such as diskless NCs typically require initialization upon power-up, that is, the initial download of the basic code that allows them to function. An important aspect of the NC testing was the measurement of the traffic levels associated with the initialization or boot process. It was determined that the NC boot process was the most intensive thin client operation in terms of network utilization, since an initialization file set of several megabytes needed to be transferred from the boot server to each initializing NC. High bandwidth to the NC would be required in order accomplish this

Thin Client Computing in a Complex Health Care Environment Page 14

• A Case Study

Kjargaard initialization in a timeframe acceptable to end users. Also, if a boot server takes too long to respond to an NC boot request or if delays are encountered during the initialization file transfer, the NC may need to be

• rebooted. The network design would need to insure that boot server access would not be a bottleneck.

The testing enabled IT planners to determine scaling requirements for the number of thin client endpoints per boot server. It also became apparent that overall network capacity would need to be in place to address the rare case where many NCs needed to be simultaneously initialized, such as after a potential facility-wide power problem. The actual test results provided a number of useful traffic metrics. Thin client devices (NCs or PCs) operating with a vendor-supplied protocol required an average bandwidth of 20–30 Kbps. This traffic level corresponds closely to the vendor’s bandwidth projections. Thin client devices that are served by Web servers and running a J VM require a bandwidth similar to a PC running an Internet browser, i.e., 56–128 Kbps, with a more variable (bursty) traffic characteristic, and highly dependent upon the specific J ava application. The thin client device boot sequence requires 256–512 Kbps for a duration of 10–20 seconds (longer if the network bandwidth is not available). The thin client boot scenario could be problematic if many NCs are booted at the same time, particularly if NCs are located on shared 10 Mbps Ethernet segments. If thin client devices are provisioned on switched ports (10 or 100 Mbps), the simultaneous boot scenario would be less of an issue. While the overall test results corresponded to expectations, it is not possible to definitively claim a reduction in overall bandwidth utilization when using thin client. However, it can be stated that bandwidth requirements to the client workstation are no greater when using the various kinds of thin clients than during normal client-server operations. In addition, thin client workstations do not experience the bursty traffic demands encountered in the classic client-server case. As such, it is also possible to demonstrate performance improvements from the end user perspective in the case of the thin client approach, given proper engineering of the back-end server to execution server link. Given an understanding of the basic traffic projection information, it was possible to scale the logical model and to make some initial evaluations about the required levels of network performance. (see Figure 4)

Thin Client Computing in a Complex Health Care Environment Page 15

• A Case Study

Kjargaard

Figure 4 – Scaled Up Thin Client Logical Model

Workstations (Thin Clients) Execution Servers Back-End Servers Access/ Distribution Network Back-End Network Thin Client Tier Execution Server Tier Backend / Boot Server Tier

The scaled-up model helps to identify a number of additional network requirements. High levels

• f bandwidth should be available between the execution servers and the back-end servers. In particular,

boot servers should be provisioned with significant bandwidth, perhaps by configuring with multiple high speed (100 Mbps) network interface cards. Reasonable operational bandwidth should be provisioned for thin client network endpoints. Once the major network requirements associated with the thin client logical model were identified, it was possible to incorporate consideration of the actual physical topology of the SDH network along with real world operational issues. From the real world perspective, the SDH network is a hybrid that must support the introduction

• f new thin client applications and endpoints, continue to support PC-based applications, and maintain

support for a host of legacy applications and devices. The SDH network also needs to continue to provide network-based services such as email, Internet access, and office automation applications to existing and new endpoints via the computing model appropriate to each endpoint. The physical topology of the SDH network is quite complex. SDH includes three major acute care facilities. Network connectivity is also extended to approximately 20 additional outlying locations within the district, as well as to other districts and to Saskatchewan Health. J ust within the three major facilities, there are a total of 68 individual wiring closets that serve as gathering locations for network connections to individual end users. The network planning process included an assessment and identification of issues and requirements in the areas of network operation and management, device addressing, routing and virtual local area network (VLAN) requirements, network reliability, scalability, and cost. It was also a requirement to insure that future network applications in areas such as the transport and storage of medical images, the enabling of conferencing across sites, and potentially voice traffic would be supportable on a new network infrastructure. The network planning process investigated a number of key strategic technology issues. The first involved an assessment of whether to utilize ATM vs. Gigabit Ethernet on the main intersite links. For

Thin Client Computing in a Complex Health Care Environment Page 16

• A Case Study

Kjargaard reasons of simplicity, scalability, and supportability, Gigabit Ethernet was selected as the core intersite link technology. A second issue involved a determination of whether to provide individual switched vs. shared Ethernet ports to individual network endpoints. It was determined that individual switched Ethernet ports would be deployed to network endpoints in order to address issues of end user performance, reliability, security, and to permit the use of VLANs for flexible network configuration with

• nly a minimal cost premium.

Based upon the requirements that were identified in the overall planning phase, the network that was specified and deployed (see Figure 5) consisted of

Figure 5 – SDH High Level Network Topology

Servers:

• Execution
• Boot
• BDCs

Internet

RUH

Routing Switch

SPH

Routing Switch

SCH

Routing Switch Servers:

• Specific

Application / Back-End Servers:

• Execution
• Boot
• BDCs

End User Workstations:

• Thin or Thick

100 Mbps Ethernet Switches 30 Wiring Closets GBE Metropolitan Inter-site Links End User Workstations:

• Thin or Thick

End User Workstations:

• Thin or Thick

100 Mbps Ethernet Switches in 30 Wiring Closets Servers:

• Execution
• Boot
• BDCs

Servers:

• Specific

Application / Back-End Mail Web Services Remote Access Fiber Uplinks Fiber Uplinks Fiber Uplinks 100 Mbps Ethernet Switches 8 Wiring Closets

• high capacity routing switches located in the main computer room of each of the three acute care

facilities

• Gigabit Ethernet, operating over metropolitan area fiber optic facilities, linking the routing switches

in each of the main facilities

• 10/ 100 Mbps Ethernet switches deployed at the wiring closet level, with 100 Mbps in-building fiber

uplinks to the main routing switches, serving as the network attachment point for all endpoint devices, whether thin or thick in nature

• Category 5 copper distribution from wiring closets to all device endpoint locations
• servers (execution, boot, backup domain controllers) distributed among the three main facilities in

accordance with the appropriate scaling plans

• application (back-end) servers typically centralized to a single location, depending upon the specific

application

• Internet access, email, and remote access services centralized to a single location

Thin Client Computing in a Complex Health Care Environment Page 17

• A Case Study

Kjargaard The network that has been provisioned at SDH has demonstrated its ability to support the functional and performance requirements of the thin client computing model as a subset of its overall

• mission. It is fully expected that additional thin client applications and endpoints will be deployed upon

this network infrastructure into the future. APPLICATION, IMPLEMENTATION, AND RESULTS OF THIN CLIENT ON A LARGE SCALE SDH had no choice but to find a way to implement a low cost of ownership desktop environment for our 2000+ desktop users. We do not have the operational dollars to fund a full-scale desktop management staff. Thin client architecture offered us a solution that we could not refuse. Current Status As of November 1999 SDH has deployed a hybrid thick/ thin client environment composed of 80 percent thin client desktops. The decision to utilize a mix of PC (thick) and NC (thin) technology was made to address the specific computing needs of each SDH business unit. Where “power users” required the additional capability of a dedicated PC, they were supplied with one. Also, if a business unit required an application that was not supported on a thin client model, their users were provided with PCs. We made a conscious decision to trade off some of the benefits of a fully thin environment in order to provide the SDH business units with IT solutions optimized for their needs. Even in the hybrid environment that SDH deployed, the flexibility of the thin client model has enabled thin client applications to be used on a PC. In fact, many of the PCs deployed at SDH are running a combination of local PC applications and thin client applications hosted on the execution servers. It is worth noting that the concept of network computing does not necessarily imply that thin devices (such as NCs) are needed. Thin client software agents are available for PCs, NCs, hand-held devices running Windows CE, and UNIX workstations. The thin client architecture currently supports the mission-critical applications listed in Table 5.

Table 5– Mission-Critical Applications

Vendor Software Title McAfee Virus Checking Software Microsoft Office (Word Processing, Spreadsheet, Presentation, Database) Microsoft Outlook (Electronic Mail and Scheduling) Microsoft Office (Word Processing, Spreadsheet, Presentation, Database) Microsoft Internet Explorer (Internet Browser) QuadraMed EnOvations Software Suite (Clinical, CPI, Order management, Bed Management) ORACLE Financials, J ava version

Thin Client Computing in a Complex Health Care Environment Page 18

• A Case Study

Kjargaard Dynamed Materials Management ADAC Radiology (Quadris) BDM Radiology, CPI, ADT, Pharmacy Garman on AS-400 Supporting Home Care EPS Staff Scheduling Med2020 Health Records Physician’s Desktop (Crystal Reports / Oracle Reports) MP2 Maintenance and Energy Services HBOC Applications on the AS-400 in RUH ( using built-in IBM 5250 Terminal Emulation)

Thin Client Computing in a Complex Health Care Environment Page 19

• A Case Study

Kjargaard Deployment SDH IT developed a set of structured processes for the design, certification, deployment, and support of its information technologies. These processes were applied to the deployment of both thin and thick client desktops and are now being used to successfully manage the hybrid environment. Our experience during the past year has shown that the cost of deploying a thin client is slightly less than one- half the cost of deploying a PC:

• $134 per PC workstation (compares to our initial estimate of $200 per PC workstation)
• $66 per thin client device (compares to our initial estimate of $25 per NC workstation)

The differences between our actual costs and our initial predictions are explained by the following two observations: 1. We found that using our structured processes led to an overall reduction in the effort (and cost) required to roll out a full PC desktop. This was due to the use of reliable, repeatable processes for software testing, pre-installs, and deployments. 2. We also found that there was a fixed amount of overhead activity that applied to both the PC and NC (thin client) which could not be further reduced. This overhead activity included certification testing

• f applications, output analysis, and interaction with the SDH Business Unit (to determine hardware

placement, quantities, schedules, training needs, specialized peripherals, etc.). Realizing Value As described, SDH has been able to realize significant benefits from the thin client environment. In addition, 1. Use of thin client devices has resulted in saving physical space at space-constrained locations such as nursing stations and information kiosks. The thin clients support the same peripheral devices that PCs can support but in a much smaller footprint. 2. Use of thin client computing has significantly enhanced the security of SDH confidential patient care data and applications. 3. Use of the NC devices permitted early deployment of hardware since terminal emulation access to legacy applications was possible due to the built in VT and 5250 terminal emulation on the NC devices. Do Thin Clients Meet SDH Expectations? The thin client environment removes complexity and cost from the desktop but increases complexity and initial cost in the design and operation of the network and server environment. Since the up-front costs are not the largest component of the life-cycle costs of any information technology, the long-term desktop operational cost savings potential made good business sense to SDH. The thin client model has met our early expectations in several areas: 1. The initial desktop deployment effort was greatly simplified. 2. Ongoing software distribution and maintenance effort has been much less than had been projected for a fully thick client environment. 3. Day-to-day operation and maintenance of the thin desktops is much easier than for PCs. 4. Use of the thin client model has not hampered the use of thick clients where this was deemed appropriate due to business need. 5. The thin client environment has a tremendous amount of built-in redundancy, which results in a very high availability.

Thin Client Computing in a Complex Health Care Environment Page 20

• A Case Study

Kjargaard Early indications are that the thin client model will yield tremendous operational effort reductions which will continue to enable an IT staff complement of about 65 to service the information technology needs of a health district of over 8000 employees. What worked; what did not With any new technology, there will be issues and our deployment was no exception. Here are the “gotcha’s” that we experienced and how we dealt with them. Application co-existence issues the on execution servers – We found that some applications (or different versions of the same application) can’t co-exist on the same execution server. This situation was easily resolved by placing the applications on different terminal servers. Both applications are then equally accessible to the thin clients (since users don’t know or care which terminal server provides an application). The drawback is that it is not possible to have a single homogenous pool of execution

• servers. Instead, a number of heterogeneous server pools were required. This tends to reduce the load

balancing efficiency, since not all execution servers can be part of one large, load balancing pool. Use of DOS applications on execution servers –We found that running multiple instances of DOS applications on the execution servers tended to destabilize them (due to resource leaks) and cause them to crash once a day. We resolved this by isolating the DOS application to a limited number of execution servers and scheduling a preventive reboot on the servers that ran the DOS application. Video display resolution and display colors – Several of our new clinical and financial applications were designed for 1024 x 768 resolution. Our early designs assumed that most monitors would be 15 inches in size, but this proved to be insufficient to legibly display the high resolution required by the applications. We therefore had to introduce 17-inch displays. When using CRT displays, this makes little cost difference, but when using flat panel LCD displays (as required in space-constrained or environmentally sensitive areas), this significantly increased the cost of the display device. General stability of execution servers – Since the execution servers are executing multiple instances of applications (in time-share fashion), resource leakage problems that may be present in one application are magnified many times. We noticed that in general, an execution server supporting 25 users would become unstable after about one week of operation. We were able to resolve this by scheduling an automated preventive reboot once per week during scheduled outage windows. Network printing from the thin clients - If thin client users load the regular single-threaded NT printer drivers (as is the case when installing a printer hosted by an ordinary NT domain server), the print drivers work so long as only one thin client user on a given execution server is using the driver. As soon as more than one thin client user tries to print simultaneously, the single-threaded print driver will hang the server. This problem was easily rectified by ensuring that thin client users load and use only multi- threaded NT printer drivers.

Thin Client Computing in a Complex Health Care Environment Page 21

• A Case Study

Kjargaard Variable degrees of application compatibility with the thin client model - We were somewhat disappointed (and surprised) that some vendors are not more aggressively supporting their products on the thin client environment. Here are some of our experiences on what works well that may benefit an organization implementing a thin client architecture. Perform as much up-front testing as possible - Based on the results of our early testing with the thin client architecture, we knew that our network design would need to accommodate the simultaneous boot-up of hundreds of NC devices. Based on our testing and network traffic analysis, we came up with the notion of multi-homing our boot servers to reduce the network I/ O bottleneck during NC boot. Likewise, as we encountered technical issues with the environment, we were able to resolve them owing in large part to our testing efforts and to the versatility of the thin client architecture. Implement rigorous systems management procedures - Execution servers must be carefully managed to ensure consistency across all servers and pools of servers. Failing to do this results in inconsistent behavior on the thin clients, such as missing applications, incorrect user profiles, and wrong printer

• mappings. Good proactive/ preventive management is required to keep the servers stable. Operating

system upgrades and service patches must be carefully applied and a strong change control mechanism must be used to regulate all changes to the servers. Certify all applications that are intended for use on the thin client environment - Rigorous testing of applications must be performed to ensure that they are compatible with the thin client environment and that they can co-exist with other applications in the thin client environment. Ensure that you have skilled staff at your disposal – Several key aspects of the thin client implementation had to be figured out by experimentation and adaptation. SDH is fortunate to have an IT staff that is highly skilled in the technology, very innovative, and incredibly adaptable. The quality of the individuals involved has been a significant factor in our ongoing success with this environment. Management of Thin Clients and Associated Infrastructure A centralized server administration group consisting of one full-time NT server administrator, who manages all NT and thin client execution servers, and one full-time NT desktop administrator manage the thin client desktop environment at SDH. In addition, the following resources provide support to the thin client environment and other SDH legacy environments: one SMS administrator, one network administrator, one systems management analyst (provides systems management guidance to the administration group), one senior technical architect (provides architectural guidance to the administration group), five Level 2 support technicians (covering all SDH IT systems including NT, UNIX, and mainframe systems), and five Level 1 support staff (covering all SDH IT systems).

Thin Client Computing in a Complex Health Care Environment Page 22

• A Case Study

Kjargaard These resources support a current population of 18 NT servers, 19 thin client execution servers, 7 thin client boot servers, over 400 (and growing) thin client desktops, over 260 (and growing) PC desktops, and approximately 2000 legacy desktops that will be migrated to the new architecture over the coming year. SDH has implemented the OSI FCAPS (fault, configuration, accounting, performance, security) Systems and network management model for the ongoing operations of all of its IT environments, including the thin-client environment. Security The thin client model has significantly improved the security of SDH confidential patient care

• data. Since a thin client does not store any data locally and file I/ O can be tightly controlled, there is a

greatly reduced risk of data theft. Also, since any access to SDH applications and data requires network logon, audit of who has access is easier than in a PC environment where local PC applications can be executed by anyone who gains access to the PC. SDH is further improving security and ease of use by implementing a single sign-on/ strong authentication system that functions in the thin client environment. Use of the thin client model makes this effort much easier than it would be with thick client PCs. SUMMARY The thin client computing model has delivered significant operational benefits to SDH over traditional PC client environments. These benefits have manifested themselves in a reduced total cost of

• wnership of a critical computing resource. Even in the mixed thick/ thin client environment that was

deployed at SDH, the TCO is significantly less than if we had implemented a pure thick client environment. TCO reductions at SDH have resulted from a combination of many factors: 1. Reduced number of physical visits to diagnose and correct desktop problems. 2. Reduced desktop hardware break/ fix costs. 3. Reduction in the amount of time that users spend trying to correct problems with or modifying the desktop. 4. Reduced management of licensed desktop software. 5. Reduced number of problems caused by unauthorized user intervention at the desktop. 6. Reduced requirement for administration of local desktop device accounts. 7. Reduced requirement for security, backup, and recovery of data stored locally on desktops. 8. Simplified software deployment; publishing an application on a thin client is quick and easy, vs. deploying to a PC. 9. Thin client hardware has a longer useful life, since any device capable of running a thin client agent can be used (i.e., any PC from a 286 up, any NC, any hand-held Windows CE device, any UNIX workstation). This means that technology upgrade dollars can be focused on the centralized server environment rather than on both clients and servers.

• 10. Decrease in the normal operational network traffic between the network backbone and the desktops,

which allows the pace and cost of network upgrades to be reduced.

Thin Client Computing in a Complex Health Care Environment Page 23

• A Case Study

Kjargaard

Thin Client Computing in a Complex Health Care Environment Page 24

• A Case Study

Kjargaard AUTHOR BIOGRAPHIES Perry Kjargaard For the past two years Perry Kjargaard has been Senior IT Project Manager for enterprise IT renewal within Saskatoon District Health. This included major infrastructure renewal and implementation of numerous enterprise-wide core business IT projects. Nunzio M. Fortugno

• Mr. Fortugno is a Senior Technical Consultant and Managing Principal of CyLinea Systems

Corporation, headquartered in Calgary, AB, Canada. A graduate of the University of Saskatchewan, Mr. Fortugno specializes in IT architecture and systems management. Michael Leydon: Michael Leydon is a principal of QCC Communications Corporation and has over 20 years of experience in the design, development, and application of leading edge communication and data networking technologies. Guy Paterson Guy Paterson has 30 years of healthcare management experience. He has instituted key IT initiatives to support quality patient care. Guy has been a member of HIMSS since 1992 and a Senior Member since 1998. Guy has extensive experience in Information Technology, Data Networking, Telecommunications, IT Strategic Planning, and TeleMedicine.