CHIME Time: How much risk is required to create best applications for patient care?

I have been involved in the automation of healthcare operations since the early 1980s and have had the opportunity to participate in early healthcare information technology implementations, including some of the most recent.

With the industry entering the second stage of meaningful-use requirements, and a larger percentage of providers using HIT that ever before, I've had a chance to reflect about the past, and also worry about the future.

For the past 30-plus years, healthcare organizations have focused efforts on automating the back-office functions of the business—registration, charge capture, billing, accounting and the like. Only recently have IT efforts concentrated on the core of our business—applications intended for patient care. The way the meaningful-use program has been formulated, we must move in that direction at a fast pace if we are going to avoid penalties for failing to meet meaningful-use requirements.

The applications that we're using today were not created in a short period of time—they took decades of development and refinement. Many of the applications have been Web-enabled, but the underlying architecture was developed in the 1980s and 1990s. They meet the requirements for certification, but I wouldn't label any of them as innovative, at least by today's standards.

The systems and applications in use today are very complex and have a lot of moving parts to function in the healthcare environment and to meet current and future certification requirements. With such steep requirements for years of development and amount of time for R&D, what is the likelihood that we'll see new, innovative products for our space in the next three to five years? Or should we be concerned that what we have now will be what we have to work with in the future?

Most of the complete systems we have today started as applications that were developed for specific functionality, such as lab systems, ambulatory EHRs or billing applications. Developers expanded them over time to add the functionality they have today, and they have been refined to meet the requirements of certification.

Now, consider whether there is an innovative company out there that has the venture funding to create a full-blown application suite, built on a single database (which appears to be the most recent requirement) that will enable providers to become more efficient and more responsive to the data and research demands of a reforming healthcare system. Can this mythical company afford to not sell a single system until all the applications are functional and certifiable? A “killer-app” could be the beginning of the next generation of innovative EHR software; is there a company willing to start the development process now and take a gamble?

Additionally, what is the future for niche applications, such as departmental or special purpose applications, that often have so much rich functionality but require integration into core applications? Will the market for these applications start to shrink because they require integration, often a dauntingly expensive and time-intensive process? It will be interesting to watch the market to see the future for niche applications.

Let's think outside the box a bit. What if there was an architecture that enabled niche applications to easily plug into core applications, which use a single database platform for both inpatient and outpatient settings? This is the objective of the service-oriented architecture (SOA) approach; however, what I'm imagining is something much more standardized where application connections between modules were so well defined that you could just unplug one and plug in another. (I'm not just thinking here; this is fantasizing.)

Market forces, on both providers and vendor companies, seem to be bursting the bubble on this fantasy of mine. The fast-moving meaningful-use stages place the ultimate premium on speed, not waiting, and certainly avoiding IT investment and implementation mistakes. No one can bear the risk of waiting for the revolutionary, and the fear of failure seems to be mitigated by going with the “tried and true.” So who has the courage to take a risk?

As we wonder where the HIT industry is headed, will there be collective bearing of the risk that we truly need to take? Or are there such tight boundaries around application functionality and certification that innovation and creativity are held captive?