Wednesday, October 3, 2007

Learning from Past HIE / RHIO Mistakes

I just received an eHealth SmartBrief which contained a great editorial from Health Data Management, "Learning From Mistakes" which discusses how we must learn from mistakes of past HIE and RHIOs. The author highlight several points that I also have been making. This did not surprise me when I read that the author, too, like my self, is a practicing physician dealing with the day-to-day chores of clinical data management,
Here a few quotes from the article:

"pioneers in this emerging field concentrated on creating entities, not functionality. " "... they set out to build an organization like a RHIO, rather than advance the attainment of information exchange. "



I have been commenting on this point of how RHIO have been all about setting up large organizations rather then entities that actually do something useful from the physician user perspective.

Another great line from the article:
"With the focus on form, not function, it was easy for participants to get sidetracked with political agendas, competing priorities and administrative processes..."

This reminded me about a recent encounter at a healthcare conference recently, where I met the head of a major EMR vendor's community based initiatives group. While discussing our RHIO initiative, SEMRHIO, I was asked by this vendor representative,"What is your governance model". I smiled and told her, " Our model is about creating real value for the physician , not about by building an organizational structure".

I believe in the "If you build it, they will come" model. Like any great invention, its the idea that comes first, then the organization. After all, Thomas Edison's light bulb came before General Electric.

With RHIOs, we need to focus on "what do our physicians need to enable them to care for their patients?". This should be the guiding principle. It usually takes several iterations to get the right model. Too many development initiatives get locked into a model from the start. RHIOs need to be agile, and have the ability to change or modify the model if required. By having something people really want, the rest should come easy.






No comments: