A Message from a Sponsor

Here are 10 things I've learned so far from sponsoring three really large infrastructure projects this year...

1. Infrastructure is only exciting to IT people unless it reduces cost or downtime.
2. A well planned change that is executed nearly flawlessly is almost like poetry OR when it goes well it goes really well.
3. The curve balls at the beginning of a project are nothing like the ones that you get towards the end.
4. If testing is running behind then you have more risk then you actually know.
5. Vendor's are best motivated by clear messages about what's in it (or NOT in it) for them.
6. Project coordination is critical when you're ripping out and reinstalling huge chunks of your business engine.
7. There is no adequate way to thank everyone who puts their blood sweat and tears into the projects.
8. There comes a point in the project where the illusion of control is no longer an illusion. This statement is intentionally ambiguous.
9. A decision to delay is difficult but sometimes the right thing to do.
10. Project accounting is best left to accounting experts.

In the wake of delays, resource constraints, financial challenges and some big wins I still enjoy this role and would do it all over again. I'll probably even feel that way after these programs are done!

Do The Right Thing

The question of what "meaningful use" per the ARRA and HITEC is on the verge of driving some healthcare IT professionals nuts. I'll admit it drives me nuts. There is a lot of money on the line for this definition. Money that could put on ROI analysis for EHR projects and help get them off the ground. Money that could help hospitals and medical practices underwrite the change management associated with getting physicians and clinicians on board.

Acceptance is release and I've accepted that we'll know when we know. Our budget cycle started in March and it's too late to wait. Meaningful use and the technologies it is supposed to espouse are meant to eventually make healthcare more accessible and affordable for the people and communities that we serve. If we focus on the projects that help accomplish that then we're doing the right thing. Here's where I hope we go next year...

1. Shore up any antiquated ancillaries - There are a remarkable number of hospitals that don't yet have pharmacy, diagnostic imaging and laboratory automation as it is. We have all three but at differing stages of maturity and integration. We need to make sure there are no chinks in this armor.
2. Rational metric reporting - Manual abstracting of charts and data entry into a public reporting system is not going to be feasible over the next five years. We have an EMR, we have to find better ways to leverage it!
3. HIE Strategy - Once you have an EMR then there is little to no excuse to tell an outside medical practice that you can't help them see medical records, with appropriate security, through an easily repeatable, standards compliant mechanism....

Meaningful use can wait if need be. If these things aren't central to meaningful use then perhaps it's missing the mark anyways...

The Human Computer

Recently I was asked to review an article about IBM and the Mayo Clinic's recent decision to release natural language processing or NLP code to the open source community and comment on how likely the open source development model and delivery mechanisms like Software as a Service (SaaS) or Service Oriented Architecture (SOA) will become the preferred models for delivering healthcare IT solutions. I've pasted my response below...

Alright, here are some observations but be prepared, it's a bit out there......

I think that it's kind of important to draw a distinction between the FSF/OSF development model and SasS/SOA etc... as delivery model. Linux was sort of special in that it really set a new visible standard for collaborative development in a community. That's not to say that it never occurred before. DARPA/ARPA and the military contractor/technical academic community were the real pioneers for this in many respects. Think of BSD UNIX vs AT&T System V for example. You basically have academia, big R and D shops in new markets (Bell Labs) and military contractors setting up collaborative environments with tons of freedom for brilliant people who want to use their creativity. Richie and Thompson invented UNIX almost in their spare time. Ritchie invented C because he couldn't write UNIX in B (true story) and C was the great grand daddy of a ton of 4th generation languages and definitely set the standard for compilers.

The point is that Linux wasn't the prototype model. It's just that over time the companies that fostered these communities got a grip on their intellectual capital and switched the focus to selling them. Once money is attached to an idea it's no longer psychologically possible to maintain an open flow of ideas and creativity around that idea. This is a system that rewards true brainstorming where no idea is a stupid idea and the person who helps his brother/sister find an answer is more valuable than the person who builds a silver bullet to feed an ego. This I think is a key concept, more on that below.

Linux and GNU revolutionized things by understanding that a large number of brilliant creative people care more about the free and open flow of creativity and ideas than making money. CPA finance best practices don't seem to mix easily with people who are wired to understand things and solve them because it's satisfying. It creates a kind of cultural dissonance and a myth that there is a choice (albeit a suckers choice) between having either the open flow of ideas/creativity OR the efficient and effective financial principles of selling in a market. There are more and more companies though who recognize this as a suckers choice and know that it's not an OR but an AND to be successful. Red Hat supports the open source community, fosters and respects it while making buck. IBM's transformation from big iron hardware vendor to services company was enabled by their willingness to embrace the FSF community, contribute generously and then fill a niche helping their business partners deploy these far cheaper and high quality solutions to a variety of business problems. I suspect their real target in considering a purchase of sun is MySQL (the fabled open source database that does 80% of what you need a database for REALLY REALLY fast) and Java. I can imagine them turning Java loose in the FSF community and watching it blossom into capabilities that make their consulting services that much more valuable.

We're moving from an industrial age and economy into a knowledge and information age. The winners are no longer going to be defined by who can protect and sell "things" or products. Instead it's going to be more effective to foster people's built in desire to be creative, productive and, well, human. I think this is an important concept and yes, more on that below.

SaaS and SOA can be thought of as architectures. What people generally call Web 2.0 are also. They're the next layer of abstraction in the evolution of computing. Just as punch cards evolved over time into 4th generation languages each evolution brings ease of use to computing and generally amplifies our ability to solve problems more naturally. I think it's easy to forget just how unnatural it is that we rely on a bunch of signals traveling through solid state logic gates to synthesize meaning on a CRT or LCD display truly is. The real work is done at the end of the day by the person who reads and interprets those images and uses the most powerful computer known (the human brain) to translate those abstractions into action. While SaaS, SOA and Web 2.0 types of technologies can ease the burden of that translation and make it easier for us to use technology to communicate they are still terribly crude compared to the richness of human interaction. There will be successors to SaaS and SOA. So I think the REAL benefit that they provide is in simplifying the common understanding and language of how we interact with computers. Music is a pure and natural human language in many respects. Emotion and meaning can be conveyed in a very real and raw state through composition and arrangement. SaaS and SOA help us get closer (even if we're still light years away) to that quality of communication by giving us standard mechanisms to arrange how we interact with each other through technology. I think this is the link between SaaS/SOA and the cost of technology. As technology evolves towards allowing us to spend more time on the message and less time on constructing it the flow of ideas becomes easier. This is a key concept.

If the keys are that creative collaboration is becoming more valuable than proprietary protection, fostering creative collaboration will be the key to being sustainable in the future and that the evolution of technology is moving towards enabling the communication required for collaboration then where in the heck is healthcare as an industry and healthcare IT going to have to go? Here are my predictions...

1. Healthcare's cost is driven by it's complexity and variability. The need for standardization in healthcare will be both drive and be driven by the need for easy interoperable exchange of patient information across the continuum of care.
2. SaaS and SOA are most effective when dealing with the standardized exchange of data (think RSS) so if standardization continues to gain traction via HITSP, IHE etc then they will become even more viable delivery options.
3. The need to exploit our most efficient and powerful resources, the minds of countless doctors, nurses, technologists, patients and other stakeholders, will drive us to converge on technologies that simplify the creative process.

I think that the end-point is likely to be SaaS, SOA or something that comes along later that fits this bill. Creative collaboration (aka the FSF model) is gaining momentum and will reach a tipping point once the pain of doing it the way we've always done it is greater than the pain of what will come next. I think that we're on the cusp.

So here's the deal. You can't just let me ramble like this without giving me some feedback. Help me develop this idea into something useful....

P.S. I think that NLP technology (as referenced in the article) has a ton of potential and could even break down some of the barriers and challenges associated with traditional business intelligence. In the short term though structured data and standards will serve us better since they help drive down the variability that is the root cause of our countries high cost of healthcare. The decision to open source it's development is both intelligent and responsible.

The Speed of Light is Obsolete

The healthcare IT provisions of the ARRA have a lot of dollars attached to them. Elligibility for the payments starts in 2011 to the tune of 2M/hospital (acute care) and 18K/physician (ambulatory). Elligibility for the money is based on the definition of "meaningful use" of an EMR and that's interesting because "meaningful use" is yet to be defined.

From everything I hear the HIMSS Analytics group has good reason to believe that level 4 in their EMR adoption model will probably be a part of the definition. Level 4 is basically the implementation of your main ancillaries (Lab/Rad/Pharmacy etc...), a clinical data repository, bedside medication verification and CPOE (computerized physician order entry) rolled out. CPOE only has to be in one department however. Based on the low percentage of hospitals at level 4 right now there is a lot of debate if it'll be scaled back to level 3.

The speed of implementation is important because healthcare IT doesn't move at the speed of light. It moves at the speed of adoption. We're at level 3 in my organization so to get to level 4 we need to roll out CPOE. CPOE is a physician's tool. To be successful you need the buy in of the physicians and all of the folks that they work with on a daily basis from nurses to office managers.

There is a lot that can be done with technology to facilitate this. Make it easy to use, ensure that it performs well and ensure that it talks to the other systems. Not that this is easy. There's enough here to keep any IT manager a bit nutty given the complexity of these systems and the workflow that they support. We have enterprise architecgture and technology roadmaps to coordinate these pieces.

Now we just need a roadmap for physician adoption....

Is Buy to Build as David is to Goliath???

In the January CIO Connection (the CHIME newsletter, no I'm not a member but a friend is) there was an interesting article on some questions asked by Insurer Executives at a Healthcare IT Summit. One of the questions was "Should our organization take a build versus buy approach to BI?". This is a good question.

When I first came to my organization it was literally in the basement as an operator changing tapes and printing UB94s. Well, before that I was a dialysis equipment tech but that was before my IT days while I was still in college. Once I got out of the basement I started working as a UNIX admin and that's how I got involved in a custom clinical portal development project. Basically two developers, a DBA and a UNIX admit had built a system that slurped up DI and Medical Records dictations in HL7 messages, dumped them to a UNIX box, loaded them into an Oracle database and presented them on the web via Cold Fusion. There were some other interesting apps that enabled physician to physician messages (almost a pre-twitter twitter really) and the ability for a MD to grab a rounding list from a Kiosk when they walked in the door. All of this before cascading style sheets and widespread use of XML. It was cool!

Until one of the key developers left and those of us who stayed behind were left the legacy of several undocumented VB4 programs running on an NT4 server that used a weird set of spaghetti like database links and PL/SQL scripts. For a long time we were afraid to touch a lot of it until we rewrote the pieces that we wanted to keep and a few years later we implemented our preferred vendor's physician portal product with great success. Now we spend some time customizing that portal so that it integrates well with some other apps that the physicians need.

So the CIO Connection article went on to point out pros and cons of both the build vs buy BI approaches. In a nutshell, build gives you depth and control while requiring more business engagement and solid processes. Buy gives you shorter time to value with less flexibility and more risk of creating information silos. Analysis like these make deciding the right path about as clear as mud. It also makes the article pretty accurate.

I've rolled the connundrum around in my head for a long while. Given the emerging maturity of the HITSP standards for integration (considered a "glimmer" on the Gartner Hype Cycle), accelerated adoption of EMRS, economic pressures and moral obligation to continue improving patient care I've fallen on the customize/build side when it comes to Business Intelligence. The need to understand, care for, manage and secure our organization's data REQUIRES that we have high levels of business engagement/sponsorship and effective process. The deep expertise required to customize/build that environment forces the issue and the facilitation in a way that "packaged" tools don't. Plus the addition of the packaged tool vendor adds a third relationship to an already complicated mix.

I feel less strongly about building other key functions, web and collaboration tools aside. The thing that might change the game over time would be widespread adoption of HITSP standards as the glimmer brightens to a beacon. Then the art of integrating systems or delivering information to the right stakeholders becomes much easier. The interfaces between systems become predictable and the data that passes in between is better defined. Organizing the components using techniques like SOA and SAAS improve flexibility and ability to respond without sacrificing supportability.

Then build would be to David and buy would be the Goliath...

Money, Medicine and Metrics

A colleague of mine shared and article from the New England Journal of Medicine called "Money and the Changing Culture of Medicine" by Pamela Hartzband, M.D., and Jerome Groopman, M.D. The gist of the article is that the practice of medicine had both communal and market characteristics and that currently the balance is skewed towards the market end of things. For example, physicians are pushed by pay for performance, payors and medicare/medicaid to focus on the cost of care. There is currently no carrot for collaboration with peers or even patients. Additionally the article points out that studies have shown that the introduction of financial rewards into almost any situation tend to reduce willingness to collaborate. Scary!

Perhaps change is in the air though. Word on the street is that the National Quality Forum is considering different kinds of metrics. Metrics that measure things like patient engagement in their own care. Not that traditional quality metrics like the SCIP measures will go away but perhaps pay for performance will start to focus on actually changing the culture of healthcare. This is exciting!

We should be careful though. Just as paying physicians based on efficiency alone doesn't necessarily deliver the right outcomes, encouraging physicians who find the right ways to engage their patients to hold those techniques as strategic advantages may be less likely to share what worked. So I hope NQF successfully finds a way to reward and encourage the sharing of such best practices, among doctors and hospitals alike.

Back in the (Blogging) Saddle

After a week and a half of intensity at work and intensity at home I'm about to get back in the saddle again. If you have for some reason followed my twitter posts recently they are mostly about bread and chicken coops. The work-life balance tipped away from work for a while and it's been nice. I find that once I refuel like this my mind starts looking up and around again vs the heads down daily grind that can come after intense periods of work.

Work has been intense. Strategy development, team building, infrastructure projects and new technology evaluations abound. I like to get deep into a topic, obsess about it and know as much as I can in the time I have. I then come back up for air and a reality check and figuring out how much of each is needed to keep the momentum going requires more art than science right now.

So a colleague of mine gave me a few articles to read recently and I took the opportunity in a longish large meeting to scan them and it spawned a few ideas.

• An article on the effect of compensation on collaboration (negative in most cases) got cross pollinated with what I'm learning about the National Quality Forum's likely future direction on hospital metrics.
• Build vs buy on the Business Intelligence front in payor organizations. What are the lesson's learned for providers and how does that relate to emerging trends on data aggregation vendors as opposed to traditional Business Intelligence vendors.
• The economic recovery legislation and it's impact on adoption of EMRs and even more importantly the execution of those projects.

Today was a good reminder to stop, pay attention to everything going on around me and not just focus on the next steps and the plan. If you don't stop and smell the roses then you might just miss something important...