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....
Sunday, March 22, 2009
Friday, March 6, 2009
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...
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...
Subscribe to:
Posts (Atom)
Posts
