Monthly Archives: April 2009

Accelerating the adoption of Electronic Health Records (EHR)

I picked up the book “The Future of Medicine Megatrends in Healthcare” by Stephen C. Schimpff from our local library, by chance. I can read too much into the coincidence given my interest in Healthcare in general and Healthcare IT in particular or just enjoy the fact that I relish reading anything and everything Healthcare. Let’s move on.

Healthcare as a system is a complex beast and most times players forget about the most important actor in this system. The patient. The human whose “issue” needs to be resolved. We have providers, insurers, benefits, plans, employers, lawyers, and law makers (and breakers). Most of these are working toward covering their behind. And in this complex dance, often times the beneficiary is forgotten or relegated to the back. This post is not about that.

Recently the Federal Health Architecture released the Connect system, an open-source scalable solution to help organizations tie Health IT Systems to NHIN (National Health Information Network). One of the key pushes of the current US administration is digitizing medical records so we can realize the dream of electronic health records (EHRs). Also, a while back, both  Google (Google Health)  and Microsoft (Health Vault) released their versions of consumer grade one stop Health records management system. I am not sure if this has hit widespread adoption. We are skeptical and are concerned about security and privacy issues.

And here is where, I think, a third independent player, say, McKesson, can come in and help move the adoption of electronic health records. How you ask. Where is the data collection happening? I would say, most, about 70% of the information, is collected at the primary care facilities that people go to for their routine illnesses and wellness checkups. So, instead of relying on the patient or people to put their data in the “cloud” (either Goggle Health or Microsoft Health Vault), McKesson can work with the primary care facilities and, give them a system that interfaces with both Google Health and Microsoft Health Vault and stores the data in both clouds. A double entry system. I said give. Yes give, like give away, free. Google Health and Microsoft Health Vault, I am sure, have API’s (Application Programming Interfaces) that lend themselves amenable to creating applications that encapsulate workflows of a typical primary care facility. So, McKesson can put together a high performance team to develop a software system, preferably a web application that can be installed on a single server. With McKesson’s reach in the Healthcare space (McKesson is *everywhere* in Healthcare), they can influence large numbers of these primary healthcare facilities to adopt their system. Throw in some free data migration consulting work too. What do the facilities have to lose? If a company like McKesson is giving your facility a complete system, why wouldn’t you take it?

What is McKesson gaining from all this? Remember McKesson is everywhere in Healthcare. They then make their big budget systems (say, Horizon HMS – Hospital Management System) consume the data from Google Health and Microsoft Health Vault clouds. Which could then be a leverage in the sale of such systems to the hospitals. Hey hospital, this many primary care facilities and doctor’s offices in your community use our other system which seamlessly interfaces with the HMS so you can concentrate on taking care of the patients and not worry about data import tasks. I say that is a big win.

I know I am making this sound simple. But, we have to start somewhere. Like the Micofinance movement to help alleviate poverty, an open source, free, patient healthcare records management system can drive the push toward electronic health records, lowering the healthcare costs significantly. Digitizing health records is a big first step and I think giving away free systems that leverage Google and Microsoft’s clouds is the way to go. Currently you and I don’t have any control over what software system, if any, a doctor’s office uses. We don’t even know if they have proper data security policies. I don’t think any doctor’s office will let you logon to system to check your records. If the Google and Microsoft clouds are used, we would have a ready made system in place for patients to check their records. What I am proposing is we shift the responsibility of feeding the system from the patient to the folks at the doc’s office who are already doing the work, except on numerous proprietary systems that may or may not talk to each other.

Anyone listening? Well, maybe I should get started on the project. Hey where are the API docs?


tweetsharp

Quick tip:

If you are trying out the tweetsharp .Net C# API for twitter, remember that you will need to add the following using statements to your code to get the sample code working

using Dimebrain.TweetSharp.Core;
using Dimebrain.TweetSharp.Fluent;
using Dimebrain.TweetSharp.Extensions;
using Dimebrain.TweetSharp.Model;
using Newtonsoft.Json;

tweet away!


A Unit Testing Aha moment

Writing unit tests is not something we are very good at on our team. Some of us truly believe and practice the principles of TDD to the extent possible and, others simply “don’t have time”.

We did impress upon our co-workers the importance of practicing the art of writing unit tests. Off they went to write their first set of tests. D came back with questions and our conversation went something like this

D: I wrote this unit test to test this method on the data repository class that calls this other thing. So what is my unit test doing?

I: It is testing the method on the repository class.

D: So AM I good here.

I: Well here is the thing. Your unit test is testing the method foo on the repository class. But foo is calling bar on the other class. When the test fails we don’t really know if the failure is in foo or bar.

D: Ah, I see. So what good is this test?

I: The test is good. Unfortunately we have to refactor the class so we can inject into the repository this other “provider” of bar.

D: Why would I do that?

I: That will allow us to use a mock object to mock up the provider, add some “known” expectations and exclusively test foo and only foo. Any test failure tells us that something is wrong with foo.

D: Ah Ha. The unit test exposed a flaw in our design.

I: B I N G O!! Another light goes on.