emergenuity logo
emergenuity The nation's "safety net"... torn to shreds
home about us learn more solutions careers testimonials news contact us

Home > News

 

 

A Radical New Approach to Clinical Information Management

By Dr. Todd Warden

The jury is unanimous. Industries of all types have seen dismal returns from IT investments:

  • Forrester Research estimates that from 1998 to 2000 US companies went on a historic technology binge, overspending on technology was $6.5 billion while Forrester CEO, George Colony mused, "Bewildered CEOs and CFOs who felt burned by the money lost, began to second guess IT decisions, lost confidence in their vendors and felt pressure from low operating margins."
  • Gartner Group research discloses that, on average, only 7% of software functionality purchased was actually used by companies. In addition, they have found that 85% of IT projects fail to meet objectives and 32% are cancelled outright.
  • The Standish Group has found that IT projects often suffer from a prolonged delay-to-realize value, averaging 18-24 months from initiation to operations.

This research reflects what the industry has learned the hard way: Most applications purchased over the past decade have been disappointing. They've missed projections on ROI, ease of use, and ability to simplify processes. Often, they've made situations worse by adding more levels of complexity. Ironically, companies are caught in a cycle of trying to get software to fix software. This pushes business leaders further away from the data and increases the chances that the next release will cause as many issues as it corrects - or more!

In healthcare, an industry awash in data from a myriad of applications, this problem has become painfully obvious. The growing complexity of healthcare service delivery demands "real-time" methods to direct clinical behavior, improve the delivery of care, enhance quality and reduce errors. While the huge investment healthcare has made in information technology assures almost any data needed to meet this goal is available, the solution to clinical information management and integration will not be a new "super application" to layer on existing applications.

A better answer lies in a new approach to integrating and coordinating existing technology at the process level and putting the power of that coordination in the hands of those closest to the business and/or clinical issue.

History of Healthcare Information Management

Healthcare has some unique sets of circumstances that make the integration and coordination of clinical information both more sought after and more challenging than some other industries. For example:

  • Communication timeliness and accuracy can often be a literal matter of life and death.
  • Complexity of healthcare transactions. Traditional industries produce sequential, simple transactions using financial software to manage their data. Healthcare has very complex transactions occurring on many different proprietary systems simultaneously which often utilize financial software to manage clinical data.
  • The level of language barrier that exist between the clinical providers and the healthcare business professionals is profound.
  • Medicare (CMS), certifying agencies and evolving healthcare legislation change the rules frequently, forcing expensive reprogramming of existing software or the purchase of new systems.
  • Physicians are fiercely independent.

For these reasons, and others, healthcare IT innovation usually lags that of other industries by three to four years. To better understand the forces affecting information management in healthcare it is important to understand the history of financial management, data management and clinical management over the last three decades.

The Care-Free 1980s

In the 1980s, financial management in healthcare was a fairly straightforward proposition: Medicare and commercial insurance provided fee-for-service reimbursement and the more services that were provided the more the hospitals and physicians were paid. This drove the structure of data management.

Data management in the '80s was almost universally oriented to capturing billing information and producing financial statements for hospitals and physicians. The data was captured in old mainframe applications that were designed to be impenetrable. The spreadsheet became a very powerful tool for management.

Clinical Management, in turn, reflected the financial and data management environments. Since hospitals and physicians were paid for more services, new services flourished. New specialties appeared: emergency medicine, pediatric, surgical, medical and neonatal subspecialties were created. Clinical data for physician management, however, was almost non-existent.

The Schizophrenic 1990s

Due to spiraling healthcare costs, Medicare changed the reimbursement system in the 1990s. They develop standardized information sets to be collected on all patients in the form of Universal Bill '92 (UB 92) for hospital payment and the HICFA 1500 for physician reimbursement. Diagnosis Related Groups (DRG) were established to fix hospital payments for a specific type of admission.

This change in reimbursement structure quickly affected data management. As the UB 92 became the standard, hospitals used this information as their sole means to profile physicians and curb over utilization under the DRGs. Vendors of financial systems developed decision support applications to facilitate data extraction on physician practices. Other applications proliferated (supplies, HR, tracking, pharmacy, radiology and laboratory) as data became seen as essential to physician management. IT staff, in turn, were tasked with producing reports from these siloed systems. As standardized relational database products pushed into the market, they expanded the opportunity to compare data from disparate sources and provide better overall analysis.

In the '90s, a schism formed between the hospitals and their medical staffs due to a disparity in reimbursement structure. Hospitals had a vested interest to restrict costs and length of stay while physicians, still operating on the fee-for-service model, had no such incentive. In addition, hospitals began to move into clinical specialty product lines (chest pain centers, cardiac catheterization, cancer centers, fast tracks and observation areas) focused on reducing cost of care.

Today's Information Age

Currently, the advent of state mandated reporting on "quality indicators" by hospitals and the introduction of "pay for performance" by Medicare (CMS) has shifted the financial management focus for hospitals squarely on quality and efficiency of care delivery in order to help capture market share.

This shift in financial management focus has increased pressure to quantify quality and efficiency in healthcare delivery. In data management then, the focus has shifted to the problem of extricating data from existing systems, rather than looking for a new set of systems to solve the quality quantification problem. However, these efforts have been complicated by the fact that the data is locked in a multitude of independent, often incompatible systems hospitals have invested in over the years. This static and laborious reporting environment does not meet the dynamic needs of the healthcare industry.

On the clinical management front, the publication in 2000 of "To Err is Human" by the Institute of Medicine sent a shock wave through the healthcare industry with its declaration that 100,000 deaths per year occur due to medical errors. The subsequent examination of errors linked to the financial push on quality and efficiency in the healthcare system served to highlight the inadequacies in clinical information management. The plethora of new medicines, tests and procedures forced a reassessment of how to manage the almost weekly introduction of these resources to avoid waste and eliminate errors.

Modern Clinical Information Management

As in most industries, two immensely powerful tools underpin applications and IT systems in healthcare: inexpensive, high-end processors and relational databases. The relational database, in particular, has become the foundation of literally every application of value to business over the last two decades. Application programmers using relational databases can:

  • Create forms to facilitate and manage accurate data entry
  • Manage enormous amounts of data
  • Create relationships between disparate sources by linking the data in tables
  • Write reports and create charts
  • Create queries and sort data with ease

Applications in healthcare, however, have been built on different platforms and with many different products. In addition, many areas of healthcare lack data collection standards, which makes the comparison and integration of certain data sets and applications frustrating at best. Further, "relational database theory" often differs among programmers, as do the languages and naming conventions utilized. These are the elements that create the proprietary nature of applications within healthcare. In many cases this has been a by-product of the process of development, in others it has been intentional to obscure the underlying logic of the application.

The power and flexibility of the relational database coupled with today's high-end processors provide healthcare with important opportunities to better manage and understand clinical information. However, in meeting the current needs of healthcare, this combination is still lacking in "real-time" capture of data from all the applications and "real-time" alerts to use the data being generated to manage the care concurrently

While there is now enough data being collected within individual systems getting at it and making it actionable in real-time has remained an obstacle in the quest to improve healthcare quality and efficiency and decrease medical errors.

Current approaches to this problem, such as database triggers coupled with asynchronous messaging technology, fall short for three reasons:

  • While information is the goal, a data-centric approach won't work. For example, the fact that a certain prescription hasn't yet been dispensed may, in and of itself, not matter unless a discharge order for the patient has also been issued. These two disparate pieces of information aren't correlated in their respective systems, nor would messages alone correlate them. In short, the complexities of turning data into information surpass the capabilities of these technologies.
  • The process of identifying and directing information to various healthcare providers is a dynamic process, with information needs changing, based on best practices, ongoing analysis of outcomes, and the evolution of treatment protocols. Database triggers and messaging technologies are simply too brittle to be economical in such a dynamic environment.
  • Since those who know where information should flow and when are typically not versed in the complex syntaxes of these technologies (indeed, they're healthcare providers, not programmers), "locking" process rules and data mapping into code only creates tomorrow's legacy systems. The requirements for information flow are far too fast moving to require specialized programmers to implement and maintain.

Event-Driven Architecture Emerges

Business process management (BPM) technology is at the forefront of an emerging trend toward event driven architectures that holds great promise for addressing the fundamental challenges of today's clinical information management environment. Currently gaining favor in other industries, BPM puts forth two compelling positions that match up well with the need for clinical management to become more real-time:

1. Don't buy more applications; better use the data being captured in you current applications.
2. Let the business or clinical leaders use the data being created to drive the business processes.

Using sophisticated technologies such as Web services and extensible markup language (XML), BPM technology offers a lightweight, highly flexible way to turn existing applications and systems into a real-time, event driven infrastructure. BPM integration technologies can generally be installed in one-third the time and at one-fifth the cost of traditional applications. The technology forces no changes to existing applications, makes integration of additional systems a trivial matter and serves three key functions:

1. Monitoring for events (transactions) and building a history of all the transactions occurring in that application in a standard business intelligence tool for detailed analysis.
2. Sending appropriate "alerts" to caregivers, administrators, or other departmental systems when a series of events occurs and those alerts match the preset "rules" criteria.
3. Enabling modification of "rules" by non-technical staff based on key feedback.

"The combination of simplicity, flexibility and unobtrusiveness to current applications makes BPM-based integration an elegant and affordable solution for healthcare and its many clinical requirements," notes David Cameron, Vice President of Product Integration at AptSoft Corporation, a company specializing in this approach to real time application integration. "The combination of both technology and a deep knowledge of the current state of clinical business processes creates a really powerful mixture with revolutionary potential."

Healthcare professionals are accustomed to dealing with individual software applications that address discreet parts of particular problems. These applications generally have pre-designed processes built into them that the user must employ without deviation. By contrast, BPM technology lets a clinical leader quickly and easily design and re-design a process that spans multiple systems, adapting the technology to meet changing needs," he added.

Because of the huge increase in the number of tests and remedies that can be ordered by physicians it is inconceivable that any one physician in an emergency department (ED) could stay current on the details of their proper use. In addition, the liability crisis has encouraged over ordering of tests as a defensive measure.

Without effective management, wasteful practices can limit access to those needing resources and cause a financial strain on both providers and patients. Following is an example of how an event driven architecture can turn insight into an existing problem gleaned from static data analysis into a new system-spanning process designed to address the problem in real time.

In this particular case a hospital made available a new test, D-Dimer, to ED physicians in June 2002 to help rule out diagnosis of a blood clot to the lung and the need for follow-on testing such as a CAT Scan. Because this was a new test and no data was available to provide guidance, there had been no physician education done instructing how the test should be used and what would be monitored to assure the new test was used appropriately.

Figure One shows a dramatic upward trend in D-Dimer tests immediately after its introduction. Follow-on CAT Scan tests continued on an ever increasing clip. Without the ability to access and analyze its data in a timely fashion, the hospital had only an anecdotal sense that the test wasn't being used effectively.

Figure One

Figure One

By February of 2003, with an effective "dynamic reporting environment" in place, the Emergency Department leadership was able to demonstrate from the academic literature that if the D-Dimer result was negative in a low risk patient there was almost no chance of the patient having a clot to the lung and therefore no reason to get a follow-up CAT Scan.

By April of 2003, the ED leadership began educating its doctors in the proper use of the test and, as can be seen in the graph, follow-on CAT Scans drop off dramatically and D-Dimer ordering becomes more prudent. They created a means to roll out the introduction of new tests and treatments in a much more effective way…a reusable "smart process".

Delays in understanding and acting on data have consequences both in terms of operational efficiency and costs. In the case of this hospital and its experience with the D-Dimer test, an analysis of cost tables (shown in the graph below) revealed actual savings seen after the physician education and monitoring of their practice was undertaken. Figure Two

Figure Two

If the training that occurred in April of 2003 had occurred at the time of the test introduction, the additional savings would have been $150,000. The actual savings since the April intervention and education has been $324,000. If this "smart process" for the introduction of new treatments and tests had been implemented at the time of the tests introduction the savings would have been $474,000. So clearly, as in other industries, time is money in healthcare. The next logical step then is to turn understanding into a real-time process that can affect behavior.

Using the example shown in Figure Two, the hospital would first identify the systems supporting the process it wished to affect. In this case, it would be systems and applications in the laboratories for ordering tests and entering test outcomes. To create a real-time environment to manage the introduction of D-Dimer, BPM integration technology would connect the disparate systems using lightweight adapters to listen for events on the systems and a rules engine is designed to monitor and coordinate the events which are occurring on these systems.

By attempting to more effectively influence physician behavior, a clinical leader using a BPM-integrated system could easily configure the following process across multiple systems:

1. The technology is instructed to monitor for an event on the lab system - "D-Dimer test ordered"
2. The rules engine is instructed if event "D-Dimer test ordered" occurs, then monitor radiology ordering system for event "follow-up X-Ray study."
3. When the event "follow-up X-Ray study" occurs in radiology, the rule would trigger a check of the lab system for D-Dimer completion and result.
4. If the lab system check returned a status of "not back" or "negative" the rule would immediately trigger an alert to the physician, prompting them to consider waiting for the result of the D-Dimer test and, if negative, to consider or reconsider the usefulness of follow-up X-Ray

In a clinical setting such as this it is important to preserve professional prerogative, therefore the system could be set to allow the physician to override the alert and order the follow-up X-Ray. However, the ability of this technology to put process design control in the hands of clinical leaders who understand the needs and behaviors of the people using them greatly increases the likelihood that desired results would be realized.

Conclusion

Physicians and clinical leaders have the experience to understand the clinical information needs of the institution. They have lived through painful application roll-outs replete with difficult to use interfaces, substandard performance and the inability to play nice with other applications. The good news is that these represent sunk costs. These applications should be viewed as very expensive data collection modules that can, when properly harnessed and choreographed by emerging BPM integration technologies, move beyond their point solution status and transform clinical data into actionable information capable of directing patient care in real-time.

This article appeared in the February 2005 issue of Business Integration Journal.

 
return to top
© Emergenuity. All Rights Reserved.