PDF File: 

HCT1_wp_quinnspecial.pdf

Accenture

In this section, John Quinn offers an in-depth examination of core information systems. His discussion includes a look at the management of large hospital information systems, core building components and systems integration, and data management and architecture.

Contents

The Role of Information Management in Clinical Technology

Architecture: Core Components and Key Concepts of Integration

Information Technology Architecture

Data Architecture

The Role of Information Management in Clinical Transformation

Reliability, response time, accessibility, flexibility, and security are the most important performance factors for a clinical information system. IT managers must use their knowledge of computer technology and the industry to help their organizations plan, budget, and manage user expectations for success.

Strong information management is key to the successful implementation and adoption of a clinical transformation system. While information managers are guided by a variety of important goals, we will focus on the following five performance goals as the most critical for a successful clinical transformation implementation:

• Reliability
  
• Response time
  
• Accessibility
  
• Flexibility
  
• Security/Privacy

These performance goals affect the ability of end users (caregivers) to use a system easily, efficiently, and consistently. Fortunately, an organization's information systems department can exercise at least some control over these aspects of performance by prudently selecting, contracting, implementing, and maintaining the new technology.

Nevertheless, even under the best of circumstances, achieving these goals can be extremely challenging. Information managers will improve their organization's chances of success by helping end users establish realistic expectations, by asking the tough questions before decisions are made, and by making sure that everyone is apprised of the inevitable tradeoffs that will have to be made. Here are some of the issues that information managers must address in the course of implementing a clinical transformation initiative.

Reliability: How Much Do You Need?

How reliable does a system (or group of systems) need to be? The answer will depend on whom you ask. If you ask most caregivers, the answer will be something like "just as reliable as a paper chart." This seems like a reasonable answer at first, but if we think about it, we can see that it means much more, or much less, than it might first appear to.

A paper chart is 100 percent reliable when you can locate it. Since paper charts are notorious for being misplaced or lost, they aren't really the gold standard for reliability. But the nature of the information technology world complicates matters. When a system goes down and its data are unavailable to end users, it is the equivalent of losing not just one, but all the paper charts in the hospital and all functions, such as order entry, results communications, and knowledge-based rules that generate alerts and reminders. It's a big, big deal.

The way to compensate for system unreliability is not to maintain a "shadow" manual environment as a backup. This would be, in effect, to concede that the paper system is the truly reliable one. Moreover, one of the standard arguments for an automated system's return on investment — that it eliminates the paper chart, the chart room, and the limitations of paper charting — would be drastically undercut if one resorted to paper when the going got tough.

The best way to answer the problem is to plan for it by asking: How often and for how long can an organization allow its system to be closed down? Information managers know that all computer systems — from single PCs to large server clusters — need to be shut down periodically to allow for tasks such as upgrades and database reorganizations. And these routine and essential interruptions in service can render a clinical information system (CIS) as useless as unscheduled crashes. If end users can't see them coming, they can become frustrated with the system as a whole. Information managers need to explain the realities of maintaining IS technologies to less-computer-savvy managers and end users and keep expectations realistic.

But what about unscheduled shut-downs? The good news is that both scheduled and unscheduled down time can be addressed so that a system is available very close to 100 percent of the time. However, robust availability takes careful planning and an adequate budget; it can't be an afterthought or an add-on. It must be built in to the system and application architecture from the very beginning. Frequently, vendors sell their solution's availability features, but neglect to include the requisite hardware and software in their proposals! Only an organization's information managers can ensure that a vendor has designed its solution with high-availability features and has provided for the higher costs in their proposal.

In short, the necessary reliability is achievable, but it takes planning and money.

Response Time: How Fast Is Fast?

How responsive will the clinical transformation system be? That is, how fast can a user retrieve a chart or some other piece of information? Here again, the performance benchmark is generally the organization's paper system. How long does it take a caregiver to reach for a well-organized chart and find information in it? Just a few seconds. Caregivers naturally expect equal, or better, performance from an automated system that promises to make them more efficient and more accurate in their work.

Unfortunately, it is difficult to impossible to predict the response times of a system before it is implemented. The first challenge is the sheer complexity of the calculation. Vendors tend to measure response time by functions, such as time to log on, time to look up a patient, or time to display a result. Each of these functions must be examined individually and its likely impact on the efficiency of a caregiver's workflow determined. Calculating the combined impact of these factors and all of the causes for poor systems performance before a system is operational is quite complex.

Vendors have traditionally had the most difficulty making log-on and patient identification response times acceptable to end users. These two events are typically the first hurdles that a user encounters when attempting to use the system. Very long response times (sometimes several minutes) are not unheard of. At best, this type of performance will dishearten even the most enthusiastic of new users and likely cause skeptics to reach for the paper chart and abandon using the system altogether.

The third challenge is variability. All vendors install their solutions differently at each of their client sites. No two implementations are ever the same. The reasons for these differences are as varied as the practice of medicine and the size and organization of hospitals themselves. The intersection of process and practice within each organization and the interactions among different vendors' applications all combine to create unique configurations.

This variability makes it impossible to predict the response time characteristics of a prospective solution for a specific environment. Doing so would require measuring the performance of either an identical implementation running at a different site, or a simulation of the proposed system that included all factors affecting performance. The first option is most likely impossible. The second option is, at best, difficult to achieve and seldom available to prospective buyers.

Our advice? Be skeptical of all projected response times made by vendors prior to the actual installation. Believe it when you can see it and measure it. Avoid raising unrealistic expectations among end users that can lead to dissatisfaction with a system that is, in almost all other respects, very good. And finally, find as many installed customers of your prospective vendor with the same products you are considering. They should be approximately the same or larger in size. Talk to them; ask them questions; look at their implementation running at the busiest of times. Find out for yourself. If your vendor cannot produce references, start asking hard questions about why not.

Accessibility: If It's Real, Why Can't I Have It?

For a solution to be usable, it must be integrated seamlessly into a caregiver's workflow. Accessibility is an important ingredient in this integration. If the system is inconvenient to use or increases the chance of error, the end user has every right to reject it.

The health care information technology industry is constantly challenged by access technology, such as laptops, PDAs, and tablets. This challenge is caused by the way these devices are created and integrated into solutions. Almost all advanced CIS solutions are created by a limited number of vendors specific to this industry. These vendors rely on other vendors to build the access devices that they then integrate into their solutions.

This arrangement causes at least three problems. It can take years from the time a device is announced by a hardware developer to when a solutions provider makes it available to customers. Not all devices work the same way, so no one solution vendor can support all of them. Finally, the devices a vendor can support typically need to have reached a minimum revision level of hardware and software to be usable.

All of these factors lead to the industry's access predicament. Most vendors can barely discuss or demonstrate the latest access technologies (such as tablet PCs), and few, if any, can deliver them. If a health care organization wants to build an advanced system using the latest access technology, it will have to wait until that technology is available. If the organization's end users are led to expect too much, too soon, they will become impatient and believe the project a failure. And given the troubled development paths of some of the applications that run these access devices, they may be justified in their beliefs.

Lesson? Understand how the industry adopts technologies, and keep everyone's expectations in line with reality.

Flexibility: But at What Cost?

Flexibility is necessary because no two health care organizations will implement a system to exactly the same set of processes. Knowing this, buyers should ask: How did the vendor build flexibility into their solution, and how does this flexibility affect the performance and cost of maintaining the solution?

To achieve this essential flexibility, all vendors embed in their architectures unique mechanisms to define screens, data fields, workflow, process-driven events, and external data interfaces. These mechanisms are the tools system implementers use to customize the implementation. However, once the system is customized to the provider's needs, these same tools and capabilities will slow down the system's performance. This is another reason why it is difficult to project with certainty a solution's performance with any given combination of screens, processes, and interfaces.

A high degree of flexibility means that most commercial health care solutions are, strictly speaking, interpreters of pseudo-code (the description of the customizations). When executing software applications, they actually expend most of their CPU cycles fetching and interpreting the actions specified by this pseudo-code, which makes them much less efficient — by an order of magnitude — than if the applications were hard-coded to perform these actions. The performance trade-offs associated with flexibility are one reason why health care applications often lack the scalability of applications made for markets where such a high level of flexibility is not required.

Reality check: All solutions sacrifice some performance to support flexibility. Before implementing a solution, it is important to understand what trade-offs the vendor has made and how they will affect the system's performance. It is also good to understand how customization will affect the maintenance of the completed implementation when a new release of the software is delivered.

Security vs. Access: The Key Is Balance

Security and its functional analogue, privacy, have always been important. However, the HIPAA privacy rules have made this performance goal more important than ever.

Security is the use of mechanisms to implement an organization's privacy policy. Most often, a security plan has policy/process and technology components. For example, most health care organizations have adopted comprehensive policies, procedures, and educational processes that hopefully move them into compliance with the HIPAA privacy rule. The HIPAA security rules were published in February 2003. Providers have until April 2005 to implement these rules.

IS departments need to make investments in security technologies beyond the requirements of HIPAA. Doing so will maximize the probability that their organization's solutions will be available to end users whenever they need them. Mechanisms such as encryption, username/passwords, back up and recovery plans, and old-fashioned locks on doors can form the basis of an effective security plan.

Health care solution vendors can be significant allies in helping health care organizations maintain secure data and accessible services. All vendors build security mechanisms into their solutions that strike a balance between the need for security and end users' need to access applications and data.

When a health care organization has multiple solutions from multiple vendors (as most do), balancing security and access can be complicated. Health care organizations need custom security architectures that harmonize the security features of all their applications. A single sign-on, or user context management scheme, is one such basic requirement. Otherwise, users may have to navigate myriad usernames and passwords with multiple application log-on dialogues, all taking a minimum of many minutes, before they can do any useful work. End-user frustration with having to scale the "security wall" to access the system can lead to a blanket frustration with the system as a whole.

Conclusion

Information managers at health care organizations must manage the expectations of their end users as much as they manage the technology. How well people work with the new system is just as important as how well the system works. Managers must use their knowledge of computers and the computer industry to help their organizations plan and budget appropriately for a smooth and happy transition to a clinical transformation environment. They are frequently the only ones in the organization who can do it.

Architecture: Core Components and Key Concepts of Integration

Since single-vendor solutions are not currently a viable option for most health care providers, health care IT departments must manage the trade-offs inherent in the integration process to achieve optimum performance for users.

Keep It As Simple As You Can

Clinical transformation requires a wide range of systems that support one or more high-level health care functions. These functions include supporting physician clinical practice, patient access, departmental/support services, pharmacy/medication safety, care management, clinical documentation, and health information management (see Figure 1).

Health care organizations have a wide choice of vendors and products that can support these functions. As a rule, however, when practical, simple is best. If a single vendor with a single application architecture can meet an organization's needs, it can significantly reduce implementation and operations problems throughout the system's lifecycle. And several vendors (including Eclipsys, EPIC, IDX, and Meditech) provide solution sets on a single application architecture that cover many of the most significant health care functions.

Nevertheless, keeping it simple isn't so simple for most organizations. Some vendors offer a wide range of automation solutions based on multiple application architectures. They can meet the functional needs of every functional area they have chosen to automate, but their solutions suffer from checkered histories of vendor acquisitions and failed development strategies. They have visible problems presenting a common look and feel to users and integrating data among their underlying applications.

These difficulties aside, there are practical reasons why an organization might choose to combine multiple vendors' products. First, no one vendor can provide all the automated functionality an organization might need with a single application architecture. Second, complex health care organizations, realizing that no single vendor can be the best in all functional areas, may combine different vendors' products to cover related functional areas (such as lab, pathology, and blood bank, or medication order entry and core order entry). Third, it may be impossible to replace various application systems while implementing new clinical transformation functions (such as physician order entry and medication/patient safety). Replacing a large number of application systems at the same time can create significant financial and resource burdens on the organization, preventing it from implementing new technology and new processes at the same time.

Interfaces and Integration

Since absolute simplicity is not an option — at least not for the foreseeable future — health care organizations have to find ways to make different vendors' products work together productively and without problems. In this section, we discuss the issues associated with message-based data integration, interface integration, and presentation integration.

Message-Based Data Integration

Multiple systems need to be connected in multiple ways to create end-user efficiency and process accuracy. For example, organizations rarely choose to have routine data gathered and then manually re-entered into successive systems (scheduling, registration, and clinical exam) as a patient moves through the system. Data, once acquired, are transmitted to additional systems automatically when identified events occur (such as when scheduling is completed). Over the past 10 years, data have commonly been transmitted using the ANSI-accredited HL7 standard.

Is HL7 a Real Standard?

Using the HL7 format to communicate data is a common approach, but not nearly as simple as it first seems. HL7 first appeared as a usable standard in June 1990, as HL7 version 2.1. Most health care application vendors quickly created interfaces for their applications based on it. Over the years, HL7 evolved into the current version, 2.5. Also, a new version of HL7, based on a formal data modeling and development methodology, is emerging as HL7 version 3.0.

At first, HL7 was a U.S. standard only. Later, it took on the responsibility and burden of ANSI accreditation and is now advancing toward ISO certification. Many other countries (21 as of this writing) have created HL7 affiliates, and several foreign governments have mandated the use of HL7 in their countries. These evolutionary developments have put significant strain on the credibility of vendors who claim HL7 compliance, but have not significantly updated the work they did in the early 1990s.

HL7 2.x was designed as a "permissive" rather than a "prescriptive" standard. It accommodates all proposed processes requiring data transfer between systems instead of prescribing certain processes or subsets of data for a given process (such as data to be sent when a patient is admitted to an acute care facility). This "permissiveness," along with the wide variety of process and data needs within health care organizations, means that almost all interfaces implemented today use HL7, not as a true standard, but as a common design framework for enabling (with a certain amount of unique onsite work) data message transfer between vendors' systems. In short, HL7 does not enable a plug-and-play capability, as a true standard would.

As a result, the vendor, the organization, a third-party consultant — or a combination of all three — must use the common framework to create interface specifications unique to the health care organization. The specifications must then be turned into interface code or mappings and thoroughly tested before being put into production.

A Hodgepodge of Customized Interfaces

One significant weakness in today's system environments results from a classic "chicken and egg" situation: vendors failing to see commercial value in developing new versions of their products and health care organizations failing to upgrade their interfaces when vendors release significant new versions. User organizations sometimes "patch" instead of upgrade, and vendors sometimes delay releasing new versions because they know customers are busy patching. The result is a hodgepodge of incompatible interfaces "customized" to meet a stream of new requirements unrecognized in older versions of the standards (enterprise identifiers that span multiple provider organizations, for example). Instead of upgrading their environments in a standard way, hospitals have created non-standard environments that cause problems when newer systems and infrastructure must be added.

Interface Integration

Large, complex IT environments often require external mechanisms for controlling the flow of data between systems and managing complex interface environments. In the health care industry, these mechanisms are typically called "interface engines" ("integration brokers" in other industries). In addition to controlling message delivery, interface engines add flexibility by serving as dedicated delivery mechanisms for one or more targeted systems. Many contain interface development and testing capabilities that are ultimately required by the provider's IT organization.

Interface engines, or at least their capabilities, are now largely a requirement for organizations using multi-vendor solutions for administrative, clinical, or revenue-cycle functions. Many vendors also incorporate interface engines into their application products. However, not all vendors conveniently isolate this facility so that a buyer can select it as an option. In fact, sometimes a vendor's interface engine is also the required virtual "plug" that connects their application and its database to others through message-based interfaces.This market sub-segment is further complicated by its historical development. Several independent suppliers of interface engines developed the market before the application vendors got involved. As a result, it is common to see health care organizations with IT architectures containing many interface engine-capable components. In each instance, the organization must choose which of these components they will use to manage and control their message-based interface environment.

Presentation Integration

The development of client/server-based applications and the "common workstation" has led to the emergence of presentation integration as a requirement. Once it became possible to host multiple applications from multiple vendors on a single workstation, users started to complain about the lack of a common look and feel among the applications. The problems were often more than cosmetic. The applications' different presentation styles and methods of accepting input were confusing and led to errors in interpreting and entering data. These problems focused attention on architecture, standards, and tools for managing presentation services within the workstation environment.

An obvious recent architecture change has been the adoption of the Internet browser as the common presentation framework. This choice may seem obvious at first, but it has been challenging to make the fundamental move from the "thick" client/server applications of the 1990s (developed at a cost of tens of millions of dollars and years of time) to the browser and the presentation metaphors associated with the Internet. Most vendors have delivered isolated external applications in a browser, but few have finished re-writing their core applications for the new Web-enabled development environments.

Context Management

Beyond presentation integration, user and patient context management is required in the shared workstation environment. If a workstation hosts a common access to multiple applications used for patient care, the user's effectiveness and accuracy are greatly increased if the applications work together. For example, the applications all share data about the identity of the user, and they share patient data. The user shouldn't have to separately re-enter the data into each application.

The HL7 standard Clinical Context Object Workgroup (CCOW) specifies technically how applications should interact within the workstation or the Web and application servers in order to share user and patient data. CCOW was originally developed to support multiple client/server "thick" applications hosted by a workstation. In 2000, HL7 published a new version of the CCOW standard (1.3) that supports applications in a "thin" Web-enabled environment. The CCOW standard specifies common components and application program interfaces (APIs) that create the mechanisms for the user and patient contexts.

User context management comes into play most significantly when users first identify themselves at a device. It is a part of what is often called "common user log-on." Common user log-on allows users to identify themselves just once. The log-on environment then determines the user's established security privileges and initiates the applications assigned to that user. Commercial user log-on products, such as IBM's Tivoli, support CCOW user context management APIs in a health care environment. Many software applications use APIs to support external common user log-on applications. In health care, many support CCOW for this function.

Patient context management shares patient identification data between applications after two or more have been initiated and one application has identified the patient whose data the end user is accessing. For example, a caregiver calls up a patient's chart. Once an application makes this initial patient identification, it communicates it to the other applications instantiated in the user's applications environment. Each of these applications (if permitted and safe) will then select the same patient in its process workflow. Typically, each application receives the patient identification from the active application through an API interface and then looks up the patient on its own local database and populates its screen with the patient's information. By doing this, the application is ready as soon as the user needs it, and the user does not have to repeat the tedious and error-prone process of patient selection with each application.

Many vendors claim to support various features of CCOW. Since CCOW inherently applies to a multi-vendor environment, it is difficult to verify such claims before the applications are installed. Sadly, some claims of compliance are made to affect a sale when compliance either doesn't exist or exists under terms that the buyer didn't understand. CCOW requires infrastructure software (such as a task manager) to identify and register the participating applications and coordinate their actions. Some vendors write their own software to accomplish this task, while others purchase licenses to use third-party software. This software must also be licensed and installed in addition to the applications before a CCOW environment can be configured into an organization's IT environment.

(See Larger Image)

Figure 1: Functions Supported by Clinical Information Systems

Application Architectures

The health care CIO is at a marked disadvantage when trying to control the application architecture used within an organization. There are several reasons for this. First, the primary buyers of these applications are the end users, in many cases a group or department. These users focus on function and process and have little understanding of the underlying technologies and architecture.

Second, in almost all cases, these solutions are acquired from a limited set of vendors¹ that develop certain components, and not others, for a variety of reasons. In many cases, they are small companies that have decided to focus narrowly on a relatively few functions. If they are successful, they may grow into a major player within that functional segment. They may then expand on their success by branching out into other functions. Regardless of the path they take, their original application architecture will likely become woefully inadequate as the company grows. Success, growth, and new information technologies dictate changes in the original architecture.

Technological advances in the larger IT industry, the specific needs of important customers, financial ups and downs, and mergers and acquisitions (with, of, and by a vendor) can all influence how, why, and when these vendors develop their architectures in specific ways. Here are some of the industry trends affecting many vendors today:

• The transition to Web-enabled IT environments has forced vendors to invest heavily in new development environments and to redevelop their existing applications for the Web. Leading contenders are Java (JSP and J2EE) components and applications, Microsoft's .NET® development and runtime environments, or some combination of these two, along with legacy components, such as MUMPS databases.

• There is growing demand for delivering IT services through different types of devices, particularly mobile devices, such as tablet PCs, PDAs, and cell phones

• Newer and larger organizational requirements are emerging that stretch the limits of scalability and reliability of previous architectures

• Several U.S. and non-U.S. government-sponsored regulatory and funding initiatives are demanding capabilities not currently available in vendors' products

• The Leapfrog Group, the Institute of Medicine, and other influential and oversight bodies have pointed to the health industry's lack of computerization as a contributing factor in medical errors that can result in negative outcomes — even in patient death

• Vendor acquisitions are requiring the integration of new systems into a unifying architecture within the acquirer's existing or future suite of products

Understand Your Choices

Health care IT managers may have many component choices, but not always a lot of control. It is important that they understand these choices and their probable impact on a system's operations and acceptance by users. System solutions must perform and interact with other systems as planned, scale to give users sufficient functionality, and be available nearly 100 percent of the time with almost no possibility of loss of data. Ultimately, IT managers must make certain that their organizations' solutions fit into a plan that supports their strategic vision.

Endnotes

1 Health care IT applications developed by health care organizations are extremely rare and are generally found only in academia. The financial burden of development and maintenance mean that only very large organizations with a strong interest in applying and extending computer science to the improvement of medicine (medical informatics, for example) can commit to such significant undertakings.

Information Technology Architecture

A health care organization’s IT architecture should be extensible, flexible, portable, and secure. But achieving these goals is not straightforward, and vendors’ claims for their technologies should not be taken at face value. IT managers must understand the complexities and the trade-offs required to achieve the maximum performance possible in these areas.

Organization-Wide Systems Plan

At the highest level, information managers must have a plan for managing the evolution of their organizations' IT systems. Most health care organizations tend to select solutions from multiple vendors. Managers need to understand and plan for the compatibility and maintainability issues inherent in multi-vendor environments. Many costs and problems can be minimized if a well-thought-out, organization-wide architecture plan is developed first.

Here are a few key elements for such a plan:

• An effective plan must be rooted in the reality of the industry. Don't select architecture components that will limit your choice of vendors to one, or even none!

• A plan should take into account general IT industry trends and developments. This step is easy for health care organizations because it usually takes health care vendors several years to incorporate new information technology into their software solutions.

• Your plan should accommodate declining legacy technologies that your organization must support, but does not want to expand (mainframe technologies, for example) in addition to current and emerging technologies.

• Your plan should take into account the competencies of existing staff and the skill sets you intend to develop, both internally and through outsourced staff.

Applications Organization

All provider organizations have a wide variety of functional clinical applications needs that can be automated by one or more vendor solutions. These functions include supporting physician clinical practice, patient access, departmental/support services, pharmacy/medication safety, care management, clinical documentation, and health information management, as illustrated in more detail in the previous article.

One level beneath the organization-wide plan is the applications organization. The Applications Organization diagram (see Figure 1) outlines three basic approaches: core, single vendor, and best-of-breed.

The core systems approach provides an applications organization that optimizes the integration of data and systems performance (response time) through the use of a limited number of vendors. It strikes a balance between a single vendor solution's sub-optimal support for clinical functions and a best-of-breed approach's disregard for the exponential integration complexities that occur when each new independent solution is added.

For example, a quick analysis of a patient safety initiative might show that "tight integration" with a single vendor covering a broad range of clinical functions¹ could result in substantially fewer interfaces and considerably lower data-maintenance costs. However, such a combination would virtually eliminate the complex real-time interfaces needed to achieve consistent sub-second performance rates and acceptable user response times.

(See Larger Image)

Infrastructure Capabilities and Change

A few years ago, the commodity technologies that were available were not adequate to support most health care organization's needs, and the rate of change itself became an impediment to achieving progress in clinical transformation. Now, change in the base information technology is much slower and less radical.

An example of the past inadequacy of commodity capacity is that, a few years ago, most health care organizations were deciding whether to invest in contending private wide-area network technologies. Today, these organizations are using IP networks connected through common, high-speed Internet service providers.

An example of swift technological change was the advent of thick client/server applications in the late 1980s and their replacement with thin Web-based applications in the middle to late 1990s. No sooner had vendors started to implement their thick client/server products than customers started to demand thin client architectures. Converting to thick client architecture inadvertently wasted a tremendous amount of time and vendor capital.

Presentation/Workstation Management

The issue of thin and thick client architectures deserves some examination. Thick client architecture is, simply speaking, a form of cooperative distributive processing in which application-specific software resides on a workstation and works in conjunction with another part of the application residing on one or more server products. The workstation software has some level of revision dependency on the software running on the server, usually takes up a significant footprint in the workstation, and is not designed to run in any form of standard browser-based presentation manager.

Thin client architecture, as we will use it here, is an evolution from thick client architecture that uses the operational characteristics of the Web over an IP network — regardless of whether the Internet itself is actually used. Here, we are most interested in situations where all, or at least most, of the thin application is executed on one or more servers (Web, application, database, etc.) The workstation itself typically only has to have a copy of an Internet browser to initiate the application. The application may install some relatively small modules or plug-ins into the browser environment so that it can work with the overall application. In any case, all application-related functions on the workstation execute under the umbrella of the browser software.

The trend toward thin client and away from thick client architectures in health care is driven primarily by maintenance and deployment considerations, rather than a desire for cheaper client appliances and ubiquitous Internet access. If one examines the many problems that complicate updating workstations with thick applications, it is easy to understand this trend.

Today's thick client applications have significant amounts of code and data (master files and formularies, for example) that must be hosted on users' workstations. Updating the server software and databases without modifying the older software running on the workstations requires "version skew support," a feature that no health care vendor (we know of) provides. Some non-health care commercial applications provide version skew support, but a software manufacturer must plan for version skew before delivering software update cycles that require it.

Health care organizations could benefit from some form of version skew support. Many times, an IT organization does not own, control, or have routine access to users' workstations. Good examples of this are clinics and physician offices that are tied by practicing privileges to an acute care provider organization but aren't owned by the organization. They may also be located on property not owned by the organization. Using push technology to blindly update workstations whose configuration is not managed and previously tested is almost certain to seriously disrupt the use of the applications hosted on the workstations.

For these reasons, almost all large implementations of thick client clinical applications today require the use of Citrix® servers, or similar technology. This technology reproduces a user's workstation in the IT department's computer room for a particular vendor's solution set. The workstation runs the application in a proprietary browser loaded onto the workstation or through downloadable plug-in software running in Microsoft's Internet Explorer®. The Citrix servers are another layer of technology that must be acquired and supported and are typically located with the applications' servers. The Citrix servers have their own systems-management requirements that must be addressed, and Windows 2000-based Citrix servers can be expensive in their own right.

We regularly see IT departments of large provider organizations devote more than $500,000 in initial capital costs and one or more full-time employees to acquiring and maintaining Citrix servers for a comprehensive set of clinical applications.

Although some vendors have announced plans to move toward thin architectures and some have started to partially deliver, all vendors are still delivering solutions with the thick client components that require a Citrix infrastructure.

Flexibility

Flexible solutions are an economic necessity for vendors. No vendor can afford to build and support a custom application for each of its customers. And no two health care customers are exactly the same. Some of the differences among health care organizations are obvious, such as the number of rooms and sizes of units. Others are harder to discern but are just as common and important. For example, in the area of medication patient safety:

• Who places a medication order?
  
• What is the role of the pharmacist?
  
• Are all medications packaged in unit doses?
  
• Where is the medication dispensed?

Different providers may handle these functions differently. They may be handled differently between sites or within a single site. For this reason, most competitive clinical systems today have built-in processes for tailoring the solution to the varying needs of different organizations. Historically, some of the most successful solutions for very large organizations have had the most robust flexibility. On the other hand, some of the most successful, least expensive, and least flexible systems have been attractive to smaller organizations, such as community hospitals.

Different vendors take different approaches to delivering flexibility. These differences can have a direct affect on the cost and performance of their applications. First, a vendor's mechanism for customizing processes (for example, building a profile table to select features and workflow options) directly affects the cost of implementation. Second, a vendor's mechanism for moving previously defined customized processes from version to version and from update to update directly affects the time and cost of maintenance.

These costs are seldom known in advance and are never completely understood when a contract is negotiated. Nevertheless, these costs can be great enough, even for a large organization, to cause a clinical system to fail.

Portability

Portability is the capability to host a vendor's application on different hardware and software platforms. Buyers and sellers of clinical applications see portability as a worthy goal, but portability is hard to achieve and has its drawbacks.

One drawback is the inherent conflict between portability and the concept of an organization-wide systems architecture, which we described earlier. An organization-wide architecture standard offers an organization the advantage of having a defined, or common, hardware and systems software platform standard throughout the organization. Once a definition has been achieved, however, the IT department may become rigid and require that all solutions conform to the standard. After all, why define an architecture standard and then stray from it?

The trouble is, defined local architecture standards pose business challenges for vendors who must sell to a wide range of customers. Typically, a vendor's developers first define specifications for their internal applications architecture: database, hardware and operating systems, and languages. Sometimes, the developers will have the time and money to consider additional goals such as creating a portable product that can run on multiple architectural components. Mostly, however, business realities preclude this.

Though the market demands it, and vendors want to deliver it, no vendor can develop software that runs equally well on all hardware and systems software platforms. Therefore, buyers should not ask vendors, "Will your product run on my selected hardware and software platform X?" Rather, they should ask questions, such as:

• We have a preferred hardware and software platform X. Is your product running on this platform at a customer site that is about the same size and complexity as ours?
• What hardware and systems software do your developers and quality-control testers use to develop and test your product?
• When we call your support staff with a problem, what hardware and systems software will they use to try to recreate our problem?

These questions become particularly important if you are pushing the vendor's experience envelope with your purchase. For example, you may become the vendor's largest customer; have a more complex structure or set of processes; be requesting more functional components; and be asking for interfaces the vendor's solutions don't possess. Any one of these requirements, alone or together, could affect your implementation's performance and maintainability.

Bottom line, you should make application choices that minimize your risk. To do this, you may have to increase your budget, expand the limits of your organization's defined architecture, add staff to support your system, and lower your portability requirements. Your first and highest concern is to be convinced that you have purchased the right solution for your organization.

Extensibility

Could your prospective solution expand if your organization acquired another hospital or built additional clinics? Could new functionality be added after implementation if your organization required it? A solution's extensibility often figures prominently in an organization's IT planning. Sometimes, an organization will base its decision to buy a solution on the presumed extensibility of the vendor's architecture.

Knowing this, vendors generally try to design their application architecture to be as extensible as is possible and reasonable. Before a health care organization buys a vendor's extensibility claims, however, it should look into the issue more deeply. All solutions have limits to their extensibility, and extensibility can be a tricky issue with a number of hidden pitfalls.

One pitfall is that some vendors do not support all health care functions on a common architectural platform. When one vendor acquires another vendor, for example, the new owner may choose to consolidate all development under a single organization and redevelop the acquired applications in its own architecture. Or not. Experience shows that new owners are not likely to redevelop acquired products, but will simply re-brand them. Vendors do not always present the resulting inconsistencies in underlying architectures clearly, and health care organizations do not always know the right questions to ask. Even if they do, they may not understand the answers they receive.

Stumbling into this pitfall, a health care organization is likely to encounter others when it tries to extend technology with hidden inconsistencies. For example, suppose that an integrated delivery network with several hospitals wants to be able to transfer acute care patients between hospitals and have their records of care move with them automatically. They may also want any physician working at one hospital to be able to easily view and manage the care of any patient at any of the other hospitals in the network.

On the surface, extending the hospital's clinical systems

to provide this new functionality seems like a smart idea. However, if the vendor's solution has inconsistent architectures, it may have difficulty delivering it. For one thing, adding new functional requirements to the hospital's

existing solution may require re-implementing the solution. The solution may not support a common medical vocabulary among hospitals, forcing each hospital to maintain its own database and precluding (or at least significantly complicating) the safe transfer of clinical information between hospitals. Moreover, extending the solution to additional hospitals in the network may require a hardware configuration that is not possible.

In short, extensibility cannot be assumed, even when buying from a single vendor that claims it. Many factors, from performance to data definition and management to incompatible clinical processes may present impossible roadblocks. Buyers need to be aware of the general limitations of a vendor's solution, the potential for inconsistencies in its underlying architectures, and the very real possibility that a solution's previous implementation may preclude adding major new requirements.

HIPAA Requirements

The U.S. Health Insurance Portability and Accountability Act of 1996 stipulates that certain requirements must be incorporated into clinical transformation systems. Often, HIPAA is construed as pertaining only to an organization's billing function. However, in the United States, clinical processes cannot be authorized or deemed payable without regard to the billing function, and the clinical data are certainly covered by HIPAA's privacy and security requirements.

HIPAA governs the electronic data interchange standards between providers, clearinghouses, and payer organizations. Practically speaking, hospitals need to know if they are going to be paid before they perform non-emergency procedures. HIPAA transactions directly support functions that can verify the patient's eligibility for health insurance coverage, level of coverage, and the authorizations required for certain types of services. Furthermore HIPAA specifies the way providers, payers, and employers — and the codes for specifying procedures and diagnoses — are identified in these transactions.

Clinical systems use, and may originate, some of the data elements and transactions governed by HIPAA. They must also be able to communicate HIPAA requirements to patient financial and patient administration systems. Most important, clinical systems containing protected patient information must meet HIPAA's privacy and security requirements. They must define, implement, and enforce an organization's unique privacy policy and procedures. It is extremely important that a provider develop privacy policies and procedures with a clear understanding of what their clinical systems can and cannot do to support these requirements.

Clinical systems must support possible HIPAA privacy policy and procedure features, such as role-based security, control of access to patient information, non-burdensome access for care givers, audited extraordinary access if a legitimate caregiver is somehow not identified by the system, and screen-blanking and password-protection schemes. These last protections should prevent unauthorized access when workstations are not properly logged off, but should allow authorized caregivers to be interrupted and then return to work without having to redo burdensome log-on procedures.

It is important to note that vendors are not covered entities under HIPAA. At most, a vendor is a business associate of a covered entity such as the provider organization. The provider organization bears the responsibility of implementing HIPAA's requirements.

Summary

Purchasing and managing clinical information systems requires that managers understand the complexities of the issues and inevitable tradeoffs. Before making a decision to achieve greater portability, flexibility, or extensibility, the wise manager looks closely at the reality of the situation and takes vendors' claims and assurances with a healthy grain of salt.

Endnotes

1 For example, order entry, medication order entry, outpatient prescriptions, access to drug databases, clinical data repository common medical vocabularies, decision support repository, rules engine, dose management, formulary management, substitution/cost management, positive patient identification, drug interaction, and MAR.

Data Architecture

Data flow is the lifeblood of any clinical information system. IT departments must understand its complexities and manage trade-offs among strategies to achieve a healthy balance between a system’s two most important performance goals: accuracy and speed.

Information systems that support clinical transformation use and manage large amounts of complex data. These clinical data sets are typically part of much larger and interconnected data sets that serve a health care provider's total information needs. This larger virtual data system, as well as the databases of individual clinical applications, belong to an organization's clinical system's data architecture and need to be understood and managed.

Managing Data

At its heart, any information system that automates clinical processes is a manager of data. These systems deliver value by retrieving, storing, presenting, analyzing, receiving, routing, and triggering action based on specified data.

Data about particular patients are the core focus of these systems. But many other kinds of data must be managed to make patient data useful. For example:

• Organizational data: rooms, nursing stations, and physical resources
  
• Clinician data: identities and authorized roles and access.
  
• Test and procedure data: descriptions, requirements, and reporting
  
• Pharmaceutical and other treatment data
  
• Medical knowledge about the effects of treatments, patient symptoms, allergies, and other factors that trigger clinician notifications
  
• Coded data: almost all of the above items and core patient data are stored in a coded form

To make sense of all of these data, systems designers must create structured databases that define the varied relationships among data. For example, patients have only one date of birth, but may have a history of many visits, each of which is assigned a unique identifier code. Conversely, each unique visit identifier is associated with one and only one patient.

The plan for a database is the data model. All complex systems that must manage large amounts of data efficiently have an underlying data model. This documentation specifies parameters for the data including naming conventions, permissible sizes, rules for filing (by number or by letters and numbers, for example), data set definitions (such as patient demographics, diagnoses, or appointment schedules), and relationships among data sets (such as how patient names relate to visits that relate to caregivers that relate to procedures). All of these specifications and relationships are set out in the data model. Sometimes the specifications and descriptions are called "metadata."

Data models are the road map to the data stored and processed by the clinical information system. Without a description and a place to put a piece of data, there would be no way to store, retrieve, or process it. Database designers must first understand the data's nature, purpose, and relationships in order to place and use them in a database. Creating the data model provides this guidance.

A reference information model, or RIM, documents all of the data used across the full spectrum of an organization's applications at a very high level. Some or all of these data may exist within one database, but location is less important than definition. For example, a piece of data may be retrieved from an external system, or a "source"(such as the Internet). It may not even be stored in a patient's record, but simply used to make a programming decision (for example, has the patient visited here before?). Regardless of its location or use, the RIM must define the data so that they can be correctly retrieved.

The health care industry has several documented RIMs available as a standard reference or starting point. The HL7 RIM was developed and balloted as an ANSI standard and is widely used. It has been studied and scrutinized by hundreds of contributors from all segments of the international health care industry over the last seven years. This model can be obtained from HL7 at www.hl7.org.

Databases: Design and Performance

Once the data model is finished, designers use it as a blueprint for creating the actual databases. All databases have mechanisms or tools for creating the structure that defines the relationships among the data within a database. Though based on the data model, this structure actually determines the physical placement and interconnections among data or sets of data within the database. It is the real thing, not just a plan.

Designers create mechanisms, data indices, that enable computers to quickly find and retrieve "frequently asked for" data without having to look at all of the data in the database. For example, if Dr. Jones wants a list of patients she is seeing this morning, we would want the computer to have a way of quickly finding all patients with appointments this morning, but not all the patients the doctor sees or has ever seen. Furthermore, we would want the database to retrieve and display only the patient information we need at the time — not a life history — at least not yet. An index would enable the computer to perform this task quickly, accurately, and efficiently.

After accuracy, performance is the developer's primary goal. If a system performs so slowly that it is faster for clinicians to reach for a paper chart, they will reach for the chart. An automated system cannot make the caregiver's job more time-consuming or more cumbersome. Regrettably, we sometimes see failed implementations where people have labored for years and spent millions of dollars only to end up with a solution that performs so poorly users rightly refuse to use it.

Some types of queries to a database require greater speed than others. For example, a registration system must verify a patient's unique identifier and current provider from an enterprise-wide master index while the patient is in the waiting room. These types of inquiries must be handled within seconds at the most. On the other hand, reports and other routine messages have lower speed requirements but are much more numerous. These lower-priority messages can flood a database with hundreds, if not thousands, of sequential requests. Understanding these differences and prioritizing accordingly can help managers optimize a database's performance.

Looking at the many ways a database is accessed, it is tempting to try to enhance performance by creating tens, or even hundreds, of indices. Too many indices, however, will create a performance problem all their own. Indices help performance when a database is being read, such as when information is retrieved from the database and displayed on a screen. But data must also be written to a database, and it is here that too many indices can significantly slow things down.

Most data are written to clinical databases not with keyboards or through other human, and therefore slow, interactions. Rather, the vast majority of data written to a patient's clinical record comes from other computer systems. Some of these systems are highly automated, creating the data (such as pathology lab observations or test results) and sending them to the patient's clinical record automatically. Some data are created by human beings through dictation but are then entered into a dictation system, which sends them to the patient's record. Regardless of their provenance, these data are received by the clinical records system, associated with the correct events, and filed with the patient's record for physician review. If the data warrant it, the computer will trigger an alert to the physician through pager, phone call, or fax.

Large numbers of specialized indices can slow this writing process. Indices consume a lot of time, processing, and disk cycles on the database server during the writing process. The writing processes are invisible to users, but can be debilitating to system performance.

Once a system is running, 50 percent or more of the database server's capacity is often consumed responding to inbound messages that require data to be filed away. Curiously, this performance load is usually never considered when planning a system's requirements. Furthermore, final full-scale performance testing done just before a system goes live seldom includes attaching the system to its live inbound message streams. Thus, it is not uncommon for implementations that have passed final performance testing with flying colors to go live with depressingly poor response times.

In short, indices offer developers a trade-off and must be used with caution. Indices make inquiries fast, but database writes and updates slow. An index is not a free or even a cheap way to boost a system's overall performance.

Another balancing act for the database designer involves the concept of data normalization. Simply put, normalizing data means keeping them in only one place in the database. A RIM is typically fully normalized. We group data in a RIM based on logical categories and relationships. On balance, one would expect normalization to improve performance, but sometimes, depending on requirements for the data, de-normalizing is the better option and can speed things up.

Patient demographic data offer simple examples of both design strategies. Address and phone numbers frequently change. Name and sex seldom change. For the sake of performance, however, we may elect to copy (de-normalize) key demographic data such as age, address, and name onto an order for a lab test. We may copy these data again onto the lab result or observation record. The computer will have fewer places to look in the database to retrieve and display these records, and the lab system will stand on its own without a connection to the ordering system. However, if the data (such as address and phone number) change and they change while a lab test and evaluation are under way, we may then need to update the copies. This slows things down. De-normalization — copying demographic data onto a lab test — made reading the data faster because the computer had to access fewer areas in the database to retrieve all the data. But de-normalization made writing and updating the data much slower.

Patients' insurance data offer a similar example. We may decide to copy a patient's insurance information onto the patient's billing record to speed access. But if the patient's insurance changes or is updated before the account is closed, the system will have to find all instances of the data and change each one — a relatively slow process.

Medication prescriptions require a planned de-normalization of data. On the prescription, we need to record the patient's physician (who may not be the ordering physician) and the patient's known allergies. In both of these cases, we could point the computer to the patient's primary care physician and list of allergies (normalized data). But in fact, for clinical and legal purposes, we need to record the patient's physician and allergies at the time of the order. Therefore, we are required to de-normalize and copy these data. In this case, de-normalization means providing an accurate representation of the data at the time of the prescription. Because a patient's physician and allergies may change, it is important to record what they were at that time.

Codes and Vocabularies

Most clinical data are stored as coded values. Coded values avoid the ambiguity about meaning inherent in unstructured text, which is always open to interpretation. Coded values make it easier for a computer to recognize conditions, such as test values outside a defined range, which require action.

All coded data have meanings pegged to specific dates and times. Acceptable code values often change. However, the coded values written into a patient's medical record and their associated meanings at the time they were written must never change. A physician must always be able to look up information in a record and determine its meaning at the time it was written.

Some coding systems contain medical knowledge. For instance, a complex coding system such as SNOMED® CT contains industry-wide codes that can be matched to an institution's own synonyms for the information. This coding system allows users to build relationships among related terms in anatomy, physiology, symptoms, diagnosis, allergies, pharmaceuticals, and so on.

If a provider organization elects to use the embedded capabilities of a powerful coding system such as SNOMED® CT, several considerations must be addressed, including:

• Licensing costs for SNOMED® CT, which are not inconsiderable
  
• Support for SNOMED® CT by one's vendor
  
• Maintenance of the coding system as codes are changed and updated
  
• Synchronization of coding systems among all applications sharing data

Database Technologies: MUMPs and RDBMS

Today, two database technologies dominate the support and delivery of clinical information: MUMPS and RDBMS.

By far, the majority of clinical data is managed on evolutionary versions of a database system, originally developed over 35 years ago, called MUMPS (Massachusetts [General Hospital] utility multi-programming system). MUMPS today is delivered primarily through two products. Intersystems Corporation in Cambridge, Massachusetts, markets a product called Caché, an heir to a long line of products produced by Intersystems, DEC, and others. Meditech® in Natick, Massachusetts, produces the other technology, called MAGIC, which it uses exclusively for its own products.

A descendant (or maybe a sibling) of Dartmouth BASIC, MUMPS holds data in defined field structures called globals. MUMPS manages globals in hierarchical trees with technology that was first developed to support keyed access file systems. Both versions of MUMPS manage data themselves on secondary storage without recourse to third-party database systems.

MUMPS is a language and a database system. In the language, all references to MUMPS globals are implicit in their use and do not require specific programming statements to invoke functions such as open, read, write, update, delete, or close. The concept of converting a MUMPS application to some other language and database environment essentially entails recreating the application from scratch.

The primary reasons MUMPS is still popular are:

• Speed. Most clinical systems need all the performance they can muster to meet the demanding data needs of clinicians.
  
• Acceptance. MUMPS has long been used with many applications and by many computer professionals in the health care field.

RDBMS (relational database management systems) products, such as Oracle® and Microsoft SQL Server®, are routinely used in clinical applications developed within the last 10 to 20 years. This technology provides a vast array of advancements over MUMPS. Since it is used by the entire IT industry and not just health care, it has justified large investments in internal database features such as distributed databases, load sharing, high availability, and on-line backup and recovery.

Most recently, some vendors, such as Eclipsys®, have made good use of RDBMS technology. IDX has recently moved their Carecast product to HP's non-stop SQL database running on HP's nonstop line of servers. Nevertheless, pound-for-pound, MUMPS still delivers more mature products with better performance. And some in the industry worry that RDBMS may not be able to handle the long-term data demands of clinical applications. For now, however, the use of RDBMS in clinical applications continues to advance and deliver adequate performance. Perhaps in the future new database technologies will deliver the performance and manage the complexities of health care data even better.

Security

Privacy of patient data is a growing concern in the worldwide health care industry. Advances in information technologies that store patients' private health information and transfer it over networks drive much of this concern. Easy access to patient information by an increasingly wider range of parties has highlighted the need for security.

The Health Insurance Portability and Accountability Act of 1996 defines "privacy" as the web of policies, procedures, and employee education used to prevent unauthorized disclosure of, or access to, a patient's identifiable health information. HIPAA privacy provisions will be in effect by the time this book is published. Final rules for security must be implemented by April 2005.

Security is the physical means by which privacy is implemented. The HIPAA rules of privacy and security do not mandate specific security technologies or measures. Rather, they require provider organizations to balance costs and risks and determine what they need to do to protect patients' privacy. Both database systems and vendors' applications must possess specific security features that enable providers to implement privacy and security policies. Two examples of these features are:

• Access control. Limiting access to patient information to identified individuals with proper authorization.
  
• Reporting access. Being able to retrospectively report who has accessed a patient's information and when and where they accessed it.

Current technologies can report the who, when, and where of data access. The results may be voluminous, but today's technologies can do the job. Controlling access, however, depends on being able to identify a person and the person's role, and many clinical systems can only partially accomplish this task. Systems can recognize that a user is a physician. They may even recognize that the user is the "attending" or "primary care" physician associated with a patient. These are largely passive roles that change infrequently.

The larger problem is identifying dynamic roles that occur when a patient is referred to another physician. Sometimes the referral is formal, and the role can be captured relatively easily as "consultant." But even here, the events that initiate and terminate a temporary role may be hard to pinpoint. The acute care environment offers even greater challenges. It is not uncommon for physicians to informally request colleagues to look in on patients and offer their advice. Without formal referral processes, technology simply cannot capture this kind of dynamic role assignment and control access to patient information. Clearly, both work processes and technology will need to change if we are to make access to patients' private information truly secure.

Summary

Databases enable clinical information systems to effectively manage large amounts of complex and related data. Accuracy and speed are the twin goals, and database designers use strategies, such as indices and data normalization, to achieve them. Both of these strategies involve trade-offs, however, and must be used judiciously, on a case-by-case basis, to achieve the best overall performance for a database. As technology improves and clinical work processes evolve, barriers to better performance will be broken down.

With the advent of HIPAA, protecting the privacy of patient information has become an important goal. Through procedural and technological security measures — such as access control and access reporting features — databases can protect the privacy of patient information. Access reporting is well within the capabilities of current technologies. Some forms of access control, however, still pose significant procedural and technological challenges.