Application Porfolios and Old Data

At last count we had about 480 applications in our portfolio. The 80/20 rule applies here. We spend about 80% of our time and energy on 20% of those applications. We also have run about 30% availability for our staff to support projects although following our big EMR implementations we are now probably around 15%. The portfolio keeps growing too!

There are a lot of companies out there working to write software to make the hospital experience safer, more efficient, better for physicians and better for patients and they market very aggressively to our business leaders. Fortunately we have process in place to partner with them early on to evaluate these solutions. I can still remember the old days however when a department manager would walk on over to the IS office, drop off a couple of CD's and ask if we could have their software up and running next week. We've come a long way. Now we have IT governance reviewing the major IT investments and other bodies to assist our PMO's and facility specific PM's.

So where is the portfolio growing? We support three acute care facilities and they often have different application solutions for the same problems. We can sometimes achieve standardization between them but only when the departments see value in collaboration. Even when we do achieve collaboration or the time comes to swap out an application something has to be done with the old one or more specifically the old data. We need to archive it. We have to keep it around.

This creates weird artifacts like flat file dumps of data that get shoved into Oracle database. Applications up and running without support maintenance agreements because the end-users still like the old front end. Data conversion routines that leave some minute field leftover. Requests for 130 reports against a legacy database and engagement of vendors who specialize in taking old regulatory data and making it available.

It's wacky and it keeps our portfolio from shrinking. I'm curious to hear if anyone out there has a better solution.... Seriously....

Curve Ball City

All successful projects have sponsors, formal or informal, and formalizing the role is best practice. This applies to traditional IT implementation projects as well as process or organizational change projects.

We ask a lot of our sponsors. The IT Governance group is chaired by a non-IT leader and all of our key hospital leaders participate. It takes a lot of work to keep the content and focus on track. As sponsors we ask them to add to their own complex lives of caring for patients and communities in an ever changing regulatory environment. We add PMOs, processes, architecture and the costs of infrastructure, support and licensing. I can tell that it can be borderline traumatic. I have the utmost respect for them and do my best to support and serve them.

Language is of the utmost importance. In IT and healthcare we live in a sea of acronym soup. DR, ADT, ICDs, TQM, EIGRP, RAC, AD, LDAP and hordes of others. As IT leaders the burden is on us to learn the business, jargon and culture of healthcare while not burdening our business partners with the arcane (yet exciting) nuances of technology.

Technology projects are occasionally sponsored by members of the IT leadership and so I just celebrated my first anniversary as the sponsor for a huge forklift upgrade to our clinical application suite. We're scheduled to complete 3rd quarter of next year and while this challenge is not the same sponsorship required to rip out a ADT/billing system I'm starting to get a feel for what we put our business executives through.

It's been curve ball city or perhaps more like standing at the plate looking at Jamie Moyer wondering what in the heck is he gonna show you next. He winds up, the pitch comes flying down the plate breaking low and inside [scope doubles before the charter is signed], swing and a miss. He winds up again for the 0 and 1 pitch and lets fly, 89 miles of fastball, swing, get a piece of it and foul it off behind 1st base [ehr project schedule change delaying start project due to resource collisions]. Now the 0 and 2 pitch, a high arching curve ball, but it's high so hold the bat [vendor overcomes issues getting resources to the table]. I have no idea what the next one will be but I'm starting to get the hang of it.

Our hospital sponsors are mostly like a bunch of lead-off or designated hitters. I just hope I can knock a base hit in for the team.

Launching

In healthcare IT I sometimes feel we see governance best practices as a way to "customer as king". Combined with tight budgets and multiple priorities this gives us a good way to align with the patients, physicians and other customers that we support. It also keeps us in a supporting actor role. We don't often have the lead role. The times are a changing though.

I've been spending a lot of time thinking about architecture lately, and not the baroque kind. I've watched our HIS applications evolve from monolithic mainframe apps (PCS on a Tandem) to open n-tier architectures that separate the data, business logic and presentation layers. It's exciting to watch. One of my favorites is an emergency room app by Picis. I remember standing up an old version and being excited to see that it was built out of Apache and Perl. It's architecture lent itself to our ability to deploy it with load balanced redundancy for the presentation layer and clustering for the data layer. This opportunity allowed us to deploy it across several emergency rooms without having to purchase totally separate infrastructure.

That is the kind of opportunity that a well considered architecture will provide for you. Yesterday I attended a meeting where an extremely complex report specification was being worked out. Part of the report requires the aggregation of data that is easy to extract at a point in time but not pull retrospectively. Fortunately our DBA team and our report writers have agreed to a set of best practices that include the development of stored procedures behind the crystal reports. Again architecture comes to the rescue because the aggregation of the snapshot data is easy to accomplish by modifying the stored procedure to save the results in a timestamped custom table.

Many of the vendors we work with still consider their architectures proprietary (even though they are built on open systems) or the separation between development and implementation is stark enough that their support can't answer questions about how the app is built.

The punchline is that good architecture can make or break new opportunities. It can launch IS out of the supporting actor role into the emmy winning lead spot. Architecture can accelerate service delivery and new architecture is being developed every day. I think there are two challenges to unlocking it. First, choosing the right elements so that they create rather than restrain opportunities. Second, capturing and selling the value of nuts and bolts that can make the delivery of service so much easier and faster. A third just occurred to me. That is making sure that we have the right organization and processes in place to deliver.

We have the right talent in place to help us with the first and most of the third. The second is vexing to me at times. Initiatives get off the ground with the help of a lot of players. Launching the right projects is the key to a better life through architecture.

Integration on my Mind

Lately, like a lot of other folks in this industry, I've had integration on my mind. Specifically tying together ambulatory and acute care visit data that resides in two or more different vendor's systems. It's not trivial. It depends on a lot of technical nuts and bolts with the most important being an enterprise master person identifier (EMPI, surprisingly the wikipedia entry isn't that robust) to crosswalk patient identifiers and records across the systems. Then a collection mechanism is needed. This could be collecting the information for a patient in a single view or the development of another repository that aggregates all of the pertinent information for display. All of this has to be done quickly and efficiently for the patient and/or provider.

Then we need to factor in the dynamic nature of these environments. Healthcare evolves faster and faster. So too is the technology used to support it so whatever the solution is needs to be capable of bobbing and weaving as software, requirements, processes and regulatory needs change. The current buzzword for this is agile. If we build something cumbersome and difficult to maintain then it will not survive. This is an important trait for all healthcare technologies but they don't often deliver even though it's the promise of nearly every new development environment.

As frustrating as this is it also makes the problem fascinating. I dream about it occasionally. I wonder how Software as a Service, Service Oriented Architecture, emerging standards and market forces will eventually drive towards (hopefully) sustainable solutions. There is a lot of work being done in this domain and a lot of opportunity for innovation even as our vendors struggle to align their product lines.

My advice for all healthcare IT vendors? Be the first and fastest to integrate your product with anyone else's and provide nothing but the best customer service. I think only the best are going to survive the next few years. May the best products win.

Blueberries

Not far from where my family lives there is an abandoned blueberry farm. It's not actually abandoned. It was purchased by a group that preserves farmland and now people are free to pick the blueberries. We go there nearly every year and my wife's blueberry cobbler is heaven in a bowl ala mode. There are volunteers that come in and trim back the lilacs that are trying to take over. Some years there are fewer volunteers and we trudge through boggy mud up to our calves to find unpicked berries. It's sort of a hidden community garden.

Open Source software is that way too. There are hundreds or thousands of projects developed mostly by volunteers and usually offered for free via a licensing model known as the GNU Public License (aka the GPL). Wikinomics is a great book about how open source, idea markets and the knowledge economy is being accelerated by software such as the LAMP (Linux, Apache, Mysql and PHP) stack and other technology innovations. Just as more and more farmland is preserved for future generations by passionate volunteers who see and feel the potential for a better future there are passionate volunteers who imagine, propose and participate in the development of new tools to make peoples lives better. It's inspiring.

I came to healthcare through my families love of service. I came to healthcare IT through Open Source Software so I naturally try to see our industries opportunities, challenges and possabilities through that same lens of realistic optimism. It's not always easy. The challenges are not trivial but when we get it right the blueberries are delicious and when we have a good partner to help us cook the cobbler life is good.