|
From the October 2001 Issue HIPAA and MCOs: Administrative Simplification or IT Modernization? |
Laying the Foundation Characterizing and conceptualizing an integrated healthcare information system is a critical step in building one.
Architecting and implementing a truly integrated healthcare information system is not easy. It’s not so much that any one part of a healthcare information system is difficult to architect and implement. Rather, it’s the combination of all the parts that becomes untenable. We are plagued by a lack of compatibility among information systems, which makes integration efforts unsuccessful or, at best, highly painful for most provider organizations. Too often, we try to somehow piece together the various components of a complex information system without having created in our minds, from the outset, a solid conceptual model of the various components needed and how these components should interrelate to achieve desired outcomes. We must first characterize and conceptualize the information system so we can abstract away the complexity, leaving behind a system we can truly understand and intuitively analyze. An Everyday Analogy Take the home stereo system for example. Most of us can purchase a home stereo system, install it, then use it regularly. We can also expand an existing stereo system without difficulty by purchasing add-on components. In the era of the “couch potato,” we can even buy a single remote control that enables us to control all the equipment at the push of a button. Let’s dissect why. Looking at the stereo system from the outside in, we inherently understand a number of key components reflected in its operation and use. For example, we know that “volume” means how loud the sound is, and that any stereo system provides a way to boost or decrease sound. When purchasing a stereo receiver as a system component, we expect it to have a volume control. No matter what the volume control looks like or how it is operated, for any receiver from any manufacturer, the volume control provides the same function. We also know that for the control that enables us to provide power to the component, the label “on” means on and “off” means off. We know that within our system, the speaker is where the sound comes from; the radio is what we use to receive broadcasts, and the compact disc player is what we use to play CDs. We know that if any component in the system has a power cord connected to it, we must plug it into an electrical outlet. All these things we seem to inherently know about stereo systems are decidedly not profound. Yet, they enable us to buy, install and use very sophisticated electronic components comprised of microprocessors, amplifiers, servo mechanisms and lasers with little or no understanding of how the components were designed and created; independent of whether they were produced by the same or different manufacturer; and with minimal concern about whether last year’s model of receiver will operate with this year’s model of speaker. Why is this? Common Reference Model We carry in our heads, gained from life experience, a model for stereo systems that we can apply to any specific system we see. The designers and manufacturers of components that comprise stereo systems, and the salespersons who sell them, share the basic model with us. This reference model enables us to map the specific stereo systems we see to a general model we already understand. Reference models for complex systems—from healthcare information systems to home stereo systems—categorize our concepts into the four primary perspectives: The information model perspective deals with terminology and concepts. For example, the term “volume” means the same thing to the designer, salesperson and consumer. The system management perspective deals with the basic controls that enable us to perform fundamental operations on the system, such as turning the power on and off. The enterprise connectivity perspective concerns the ways in which the stereo system connects to things in the home—what might be thought of as the “enterprise” within which the system resides, such as the electrical outlet for power, and an antenna or cable outlet for radio reception. The user experience perspective pertains to the overall experience of using the system for its intended purposes, such as playing a CD or listening to the radio. Now, imagine a receiver that labeled its volume control “decibel attenuator.” Would users be confused about what this control actually did? Or suppose a receiver did not have a power cord, but rather required that an electrical feed be run directly into it. A user would need to assess the added cost and complexity of installing such a system. What if there was no way to turn the system on or off? Or what if the user had to enter obscure computer instructions to listen to a CD or the radio? Would any of us purchase such a system and if we did, could we use it? Each of us can formulate these questions and evaluate whether to purchase this system because each of us mapped this system to our already-formed reference model of a stereo. Even a person who didn’t fully understand the rationale for the capabilities of such a system would immediately recognize its peculiarities. Why? Because when a system either satisfies or violates our reference model, we are able to reason about the system from the outside without needing to know anything about what’s inside. Unfortunately, when it comes to healthcare information systems, a common reference model does not yet exist. Instead, we are left to evaluate each component on its own merits and guess how this component might fit with other elements of the information system. This is a tedious and often error-prone approach, as our model may not jibe with a vendor’s model. Likewise, two different vendors’ models may not jibe with each other. Too often, we are left with a bundle of disjointed parts that struggle to be a system. Reference Model for HIS The perspectives discussed in our reference model for a stereo system are not much different from the perspectives that are applicable to a reference model for a health-care information system (HIS). The diagram below illustrates the conceptual box into which we can insert any information system to evaluate how it fits into the enterprise. Each edge represents one of the perspectives. Our job is to walk around the box and assess the system from each perspective.
Information model perspective. We need to validate that the terms and processes embodied in a system match those in the enterprise. For example, does a system that embodies concepts pertaining to patient movement within the healthcare enterprise have definitions for admit, discharge, and transfer that match the definitions within the enterprise and are consistent with how these concepts manifest in other systems used in the enterprise? In the absurd, imagine a system in which “admit” means discharge, and “discharge” means admit. As a more realistic example, imagine a system that supported admits and discharges but had no notion of patient transfer within the enterprise. Would such a system fit the workflow of an enterprise? System management perspective. We need to understand how a system is administered and managed so it remains operational in a way that is practical and consistent with the other systems in the enterprise. For example, can the system be centrally monitored using third-party network and system management tools, or does it require its own apparatus? As a simplified example, imagine a system where once it is turned on, it can never be turned off. Or, imagine a system that can experience common faults, such as filling up a disk drive, but does not notify anyone when this happens and, instead, just starts to behave erratically. Enterprise connectivity perspective. This is probably the perspective most healthcare information technologists are familiar with assessing, since most systems must connect to other systems in the enterprise to exchange data or automate workflows. The enterprise connectivity perspective cannot be assessed apart from the information model perspective and the system management perspective. Specifically, for data to be exchanged between systems, the systems must have a common information model to ensure that their interpretation of the data is the same, or that their view of the process they are automating is the same. This is far more elaborate than just the mechanics of message transmission. In relation to the system management perspective, the connectivity must be manageable, lest one system continue to send messages when the other system is not capable of receiving the messages. Once again, common centralized monitoring and administration of the two systems is key to a manageable solution. User experience perspective. This perspective captures not only the end user’s experience of using a specific application, but also the experience of using the application with other applications in the enterprise. This perspective is strongly related to the information model perspective. For example, independent of appearance, is the purpose of the application’s various controls consistent with similar controls in other applications? Do the controls match the concepts embodied in the enterprise? Is the format of data that must be input consistent? For example, are patient medical record numbers input in the same way for this application as for other enterprise applications? There is a strong affinity between the user experience perspective and the system management perspective. Can users sign on to each application in the system with a single set of credentials, and can these credentials be assigned and controlled centrally? Can the user perform common tasks once for each application (such as selecting the patient of interest), or must these tasks be performed independently for each application? The Third Dimension To complete our reference model, a third dimension is necessary. Think of the third dimension as a series of slices through the system. Each slice focuses on an attribute the system must consistently possess among all of its internal components to lay claim to an attribute. For example, how do the components of the system—each of which represents a potential point of attack—deal with security? A three-dimensional model would look like this:
There is no limit on the number of slices we can create to evaluate a system. The above diagram illustrates several high-level slices that are generally applicable:
The HIS technologist should assess each of these slices by applying the four perspectives described. For example, when thinking about security of the system from an information model perspective, it’s necessary to evaluate the fit of the system’s security terminology, concepts and processes. A system with draconian security measures might not be a good fit for a healthcare delivery organization. From a system management perspective, how are new user accounts added and removed? From an enterprise connectivity perspective, does the system require public key infrastructure? From the user experience perspective, what is required for users to identify themselves to the system? Achieving True Integration In the absence of a consistent and complete framework to represent all we know or need to know, the process of conceiving truly integrated information systems has tended to be more like an unplanned journey—and we hope we recognize the destination when we get there—as opposed to a methodically planned trip with an itinerary and map. It is never too late to construct a reference model for an organization. The demands on information systems in the healthcare environment are only compounding, and the number and complexity of IT components to choose from will only increase. Taking the time now to create a reference model will save the healthcare technologist tremendous time and headaches down the road. Most importantly, it will arm him or her with the ability to critically evaluate current strengths and weaknesses of the IT infrastructure, and identify exactly which components are needed to construct a truly integrated healthcare information system. © 2001 Nelson Publishing, Inc |
By
Robert Seliger is president and CEO of
