Think of a clinical information technology initiative as the biggest jigsaw puzzle ever. Then envision having to put it together using some pieces already on hand and many others that first have to be identified, agreed upon, purchased separately and then pieced together--forming what everyone in a provider organization can recognize as a cohesive design for safety, efficiency and better care.
The elements add up to the most technologically diverse and complex IT structure ever attempted in a hospital. Its many parts should be able to operate independently for the purposes of a department or clinical grouping but also be interdependent in an overall scheme of bringing information from many places to a single clinician caring for a patient.
For all their complexity, however, clinical information initiatives "are not IT projects," says Randy Thomas, vice president of advisory services with Healthlink, a Houston-based healthcare IT consulting firm. "They should not be led out of IT. It is about transforming the organization and about how care is delivered."
Organizations setting out to build a structure for clinical computerization "need to understand where it is that they want to get to," Thomas says. "And in doing that, they need to involve physicians and nurses and pharmacists and IT people, people from admitting and scheduling and so forth. It really touches on all aspects of the organization."
As a result of uncoordinated change over the years and insufficient scrutiny of the status quo, many care processes and hospital routines are in need of repair and won't be fixed by introducing automation, experts say.
"The main thing is not to think of this enabling technology as the pill that's going to solve their problems," says Marion Ball, Healthlink's vice president of clinical informatics strategy. "To a great extent, technology is only a very small part of what the journey entails. It is by and large 20% technology and 80% a culture issue of transforming indeed the entire way in which their institutions will be practicing their professions from this time onward."
Reworking clinical and administrative processes is a must before taking the first step toward buying an IT system, says Michael Kreitzer, an independent IT consultant. If decisionmakers go ahead without a clear sense of the processes to be changed with or without IT, he says, they do a disservice to their organization.
"The key is to gain agreement on, and document, the organization's vision for itself as a provider, then develop the IT plan to support those other plans," Kreitzer says.
The execution of that vision ultimately requires knowing all there is to know about a patient, making sure the knowledge travels with that patient throughout an episode of care, being able to retrieve the data in future encounters, and having the right details on hand for a particular clinician quickly and completely wherever the encounter takes place.
Technology is the foundation
Depending on how the puzzle is put together--including plentiful pieces of process and culture change--the IT components laced throughout the clinical environment will either boost the chances of delivering those requirements or leave clinicians shortchanged and dissatisfied, Thomas says. "The small part is the technology (compared with process and culture), but the transformation that we're looking for in healthcare isn't possible without that foundation of technology."
Most hospitals and healthcare systems already have a collection--some would say a hodgepodge--of computerized capabilities to capture, collect, transmit and store a variety of data serving financial, administrative and clinical activities. The trick is to deftly upgrade the systems now in place, elevate them to a new and more rigorous level of clinical fact-gathering and processing, and integrate a new layer of computer applications and essential care processes to complete the foundation of a useful and well-received clinical IT superstructure.
Unlike previous generations of IT implementation, the construction of a electronic medical record is not a typical project with a beginning, middle and end, says Thomas Handler, a research director with the healthcare practice of Gartner, an IT research and advisory firm. He characterizes clinical computerization as "a work in progress for the next half century."
Once the effort commences, "there are periods of more activity and less activity, but you're always implementing," says Mitchell Morris, vice president and managing director with First Consulting Group.
First the essential framework has to be in place. In discussions with more than a dozen consultants, information executives and other experts, Modern Healthcare identified a core contingent of technical capabilities and organizational preparedness that can put hospitals where they want to be technologically. Those include:
* Identifying and accounting for the IT systems needed to feed the clinical decision and treatment process. Hard decisions will have to be made on whether to keep existing systems, what to acquire first on a list of unmet data needs, and how to make sure information from one system can be exchanged with other crucial systems--for instance, pharmacy data that can synchronize with systems to record when medications are given.
* Interconnecting IT systems to ensure that historical and incoming data can be shared and combined. Overcoming the Achilles' heel of clinical systems--lack of data-interchange standards--will require either an expensive IT translation process to merge data from disparate vendor products or a decision to contract with one company that has brought many of the systems together already via a common computer architecture.
* Ensuring that database capacity and processing speed are adequate to meet more complex needs. Storing data for future patient encounters or for research on quality improvement requires much more capacity than is required for managing current hospitalizations and outpatient procedures. The response time also has to be quick and the reliability of access unquestioned.
The sum of its parts
In the mid-1990s, what hospitals knew as clinical IT systems were mainly self-contained computer applications serving departmental needs in areas such as laboratory, pharmacy and radiology services. Rudimentary order-entry systems were used by clerks on nursing floors and elsewhere in the hospital to send test orders automatically to those departments and receive results.
Focused on managing department procedures, these IT systems kept track of lab specimens, recorded quality-control information and juggled the schedule of X-rays and other imaging tests, among their many other duties. But as attention turned to improving the base of clinical patient information, it became important for certain data in these systems to be shared--compiled in clinical databases, for example, or fed to other IT systems that monitor or analyze patient-care activities.
Once the objective became as ambitious as supplanting the paper medical record with an electronic one, the first part of the solution was to make sure the details once available in a thick folder could still be available by computer--and more easily accessible.
To do that, providers first have to know what total complement of data they want to capture. Then they have to list what they have now, decide what IT pieces to keep or replace, and fill in data gaps through acquisitions, says Skip Lemon, vice president of implementation services with First Consulting.
Individually, systems continue to address the day-to-day tasks of pharmacists, radiologists, nurses and lab technicians among others, so they must be tailored to improve the clinicians' routines. But they also must address the long-range goal of building a comprehensive and technically sound electronic medical record, and systems should be purchased with that in mind, Handler says. "The endpoint is the same for everyone," he says. "The only difference is the time frame."
Among IT systems already in place, older versions of pharmacy applications may be least likely to handle the responsibility for both internal functions and external communications, according to consultants interviewed by Modern Healthcare.
Pharmacy IT systems verify details of prescriptions, check for interference with other medications, adjust medication choices against a formulary of available drugs and arrange for them to be dispensed to a patient, Handler says. But a new generation of systems is needed to go beyond those duties, working closely with other systems that must exchange medication information with the pharmacy, he says.
In addition to the holdovers from decades past, newer IT systems have emerged to automate documentation duties historically done on paper, such as patient assessments, medication logs and other nursing record-keeping. Like the applications for laboratory, pharmacy and radiology, they yield information for both internal use and supplementing the electronic medical record.
Tying them together are systems that supply "context," helping to correctly identify individuals and supplying information "essential to the correct management of clinical encounters," Handler says. A master index of patients, for example, is vital when data on the same person need to be retrieved from a collection of computer systems that may not uniformly identify and register that person the same way. In addition, registration systems have to be able to contribute admission, transfer and discharge information to the computerized mix.
"If an individual cannot be uniquely identified, or if the (electronic record) system remains unaware of an active case, clinical care cannot be effective, efficient or accurate, and cannot provide views across episodes of care," he says.
Other context examples, Handler says, include systems that provide knowledge of formulary restrictions, coverage limits, exceptions and referral management--insurance information that should be made available at the point of care because it can alter choices of medical treatment. Such systems cross over into financial management, but working them into the computerized record is essential, he says.
"Officials cannot forget that healthcare is a business and these systems are necessary to ensure the fiscal health of the enterprise," Handler says.
Coupled together, clinical and financial IT structures can improve revenue cycle management, trigger billing codes when an order is placed and validate compliance with claims rules stipulated by Medicare and other payers, he says.
Difficult issues of integration
The technical task of integrating the various IT systems has always been an expensive proposition, starting with the disparate starting points for many of them. The approach selected for hurdling the integration obstacle can make a big difference in deciding what systems to buy and from whom, experts say.
A vendor's programming decisions on how to represent data in electronic form make little difference in the operation of a computer application as long as the IT system keeps to itself. But to share its information with another system--the most basic activity in the operation of a computerized record--the assumptions underlying each system's method of creating and communicating data have to be made the same somehow.
If not, the various applications won't be "interoperable": They won't be able to exchange data or merge their contributions in a common database for use in compiling a patient-specific record or sifting through information from many sources to reach conclusions. And those are the fundamental rationales for all the effort on the technology in the first place.
In today's healthcare IT environment, the task of making all the systems comprising a clinical network fit together requires intricate translation products called interfaces. Those go-betweens have to be managed closely to guarantee their glitch-free operation and must be periodically revised when updates in any system affect how data is being translated to others, experts say.
A common set of standards to make different vendor versions of IT systems interoperable is a goal in the healthcare industry but is still a long way off, observers agree. Meanwhile, the proficiency of "middleware" to connect IT systems together lags behind the considerable proficiency of healthcare applications themselves, says David Brailer, coordinator of the HHS office set up to promote healthcare IT adoption.
An alternative to such a difficult and uncertain process is to gradually build a lineup of essential clinical systems using components from a single IT company. Brought to market only during the past several years, these "application suites" are engineered to be interoperable and to share a common database that integrates all data without the need for interfaces.
Arguing that such tight coupling of data sources and computer functions is of prime importance in achieving a smooth-working electronic record, many experts see the single-vendor approach as the preferred solution until the time comes when IT systems are built to be more flexible in their ability to connect with any other system.
"You have to have a flexible architecture," Healthlink's Ball says. "Eventually we will be able to seamlessly interoperate, but at the moment we're looking more at going to one company because there's more possibility of being able to exchange the information."
Gartner similarly advocates a lineup of nine core components of a computerized record that should be bought from a single IT company. "For the foreseeable future you cannot get a (computerized record) otherwise," Handler says.
Others recognize the option but point out the pitfalls of using a single company to solve the integration problem.
"We've got a challenge," says William Stead, director of the informatics center at Vanderbilt University Medical Center, Nashville, "because the current predominant vendor model is to attempt to get hold of a customer and to do what they need through a suite of products that are integrated hopefully to a significant degree."
It's a good approach as long as a provider isn't in need of a particular system outside the realm of its chosen vendor, he says. But if other systems have to be brought in, "The very thing that tends to make the suite work together well makes it harder to work with other things," Stead says.
That includes not only future additions but also systems that provider organizations already operate and that function well, Lemon says. "There is an ounce of truth to what they're saying" about going with one vendor, he says, but he questions whether it's worth "ripping out a well-functioning current system" and losing the full investment and productive use.
Some existing systems are better bets than others to keep around, Lemon says. For example, lab systems are logically organized through long-standing efforts of pathologists and can be adapted adequately to other vendors' products until the end of their useful life. Registration systems also have been taken to a new level, he says, through previous upgrades to meet standards rooted in the Health Insurance Portability and Accountability Act of 1996 and the efforts of a group called Health Level 7. Interfaces that once took weeks to install now can be done in a day, he says.
Pharmacy IT systems in a larger network of feeder systems, by contrast, should be from the same vendor, Lemon says. Medication information figures prominently in both informing physicians about extenuating circumstances during ordering and supplying key information on medication safety at a patient's bedside. Synchronizing the systems is difficult and could become a patient-safety issue, he says.
Don't get turned around
All these considerations for building a clinical IT network have to be well-understood at the outset, says Thomas of Healthlink, "because every vendor has their own way of painting the world. And the one thing you don't want to do is to get turned around and start thinking from a vendor-centric perspective.
"You really need to understand where your organization is going, what your current environment is, where the gaps are and where you've got to fill in," she says, "because you can't go tearing out perfectly functional systems just because they don't interoperate with a particular vendor's solution."
Handler agrees that some laboratory and registration systems can be preserved for the time being, but at a price of higher overhead to keep the interfaces between them working successfully. He also cautions that the downside of going with one vendor has to be understood--each component system might not be the best available for departmental needs even though it may be much better for the overall integration goal.
Not to be overlooked, expansion of database storage and increases in processing speed should proceed in lock step with expansion of the clinical application roster, experts say. Nearly all institutions have a data center, but many are limited to supporting basic administrative functions such as registration and rudimentary message exchanges involving test orders and results.
The clinical process will require vastly more storage for the quantum leap in data coming from many more IT feeder systems, both for current hospitalizations and to accumulate patient information over time. And when hundreds of clinicians are using the IT system to zero in on specific bits of information on demand, databases have to add "horsepower for very quick response time," Lemon says.
Operating costs for data storage and operation "would double easily" in the process of taking data centers to the next level, he adds.
One complicating factor to be aware of, says consultant Kreitzer, is a dichotomy of uses for a database: one for the retrospective analysis of information, the other for on-the-spot data in a clinical situation. The computer searches for each are fundamentally different, and failure to account for that could compromise the efficiency and response time of a database, he says. For example, just the raw processing time for conducting analyses could be a drain on the power needed for speedy physician sessions.
Kreitzer recommends splitting the initiative into two database efforts, and tackling first the database for retrospective analysis and research by such professionals as case and risk managers. The information provided by such a database can reveal sore spots in a clinical operation and thus help set a direction and a sequence for using IT to improve the clinical areas of a healthcare organization, he says. Meanwhile, it will help risk managers contain and ultimately prevent inadequate care and its consequences.
Data collected to satisfy retrospective needs likely will satisfy basic caregiver needs as well, he says, helping to jump-start the clinical improvement effort. Though a wide range of data from many sources will someday populate databases for clinicians' daily work, just having current medications, lab results and a lab history will satisfy physicians' short list of requirements, Kreitzer says.
Already collected for case and risk managers, those data also can be dumped into a different database for clinical practitioners and "materially improve daily operation" of clinical departments while helping care teams develop better protocols and processes of care, he says. Then with marginal extra cost, providers can add test results and progressively other information to the database.
What do you think?
Write us with your comments. Via e-mail, it's [email protected]; by fax, 312-280-3183.
This special report is the second of two parts on issues involving adoption of clinical information technology. Last week's installment, "Building a `system of systems' " and "One step at a time" (July 5, p. 20), explored a logical progression of projects to build a clinical foundation, as well as educating the physician community on IT. This week's package examines in more technical detail the various components of an IT structure and the obstacles to success in creating an accessible and acceptable IT network.