ehealth, specialists, and strategy

Sometimes I wonder if the strategy for developing and deploying ehealth/health inforamtics is effective. In Ontario, and probably in many parts of Canada, the government has developed a series of massive infrastructure projects to create a functional electronic health record. What this means is that there are multi-million dollar projects to design, develop, test, and deploy a collection of systems that will eventually (hopefully?) provide the necessary functional elements for a provincial electronic health record. There is a big emphasis on primary care and in getting the physicians to “buy-in” to the strategy (see ePhysician project). Don’t get me wrong – I think the intentions are good, but I wonder if an alternative strategy should be considered?

Last week, I had an appointment with a specialist for a follow-up visit. The experience was interesting on many levels. First, I didn’t notice any electronic automation or record keeping. The receptionist used a computer, but from what I could tell, the computer’s only function was to validate health card numbers (for reimbursement purposes of course) and (possibly) for contact information management (i.e., address book). Scheduling was done by the receptionist using a paper schedule and pencil. The specialist maintained paper-based records.

So, what does this visit have to do with ehealth strategy? Well, I was wondering if maybe the emphasis on deployment should be at the specialist level rather than the primary care physician level. When patients visit a specialist, the scope of diagnoses and treatments is narrowed from what a generalist/family practice may encounter. Also, from what I’ve been able to learn, specialists tend to focus on specific types of information, usually collected in a very particular way. Electronic scheduling and access to lab results would probably address a significant portion of the ehealth needs for a specialist.

Now, getting back to the Ontario situation. Instead of concurrently working on multiple projects, what if all of the efforts were focused on one or two things – lab results and a secure infrastructure for example. Alberta has focused on only a few systems at a time and has experienced success using this approach. I concede that Ontario is not Alberta, just like Canada is not the UK (in terms of size of population and arguably “complexity” of the problem). But, thinking that we can do it all at once may be unwise. I think the reason why people distrust government initiated projects is because the projects tend to be massive, finish late, and cost more than expected. Shouldn’t we try and learn from past mistakes and learn from successful projects to see how we can do things better?

I’m going to follow-up with posts on the potential role of open source in health care and possibly a profile of a research project that I think is a glimpse of the future (assuming I get permission of course).







2 responses to “ehealth, specialists, and strategy”

  1. Anonymous Avatar

    My observation would be that it is not so much the nature of the work but rather the workflow and the individual that drives the adoption of electronic records.

    If a system truly provided significant advantages for a specialist (read: increased reimbursement or decreased workload), I would suspect that the sytem would already have been adopted. Although II agree that it is not the most elegant system, the fact remains that you (and countless others) still end up on the dorrstep of this MD and continue to return (since it wasa follow-up) without any need for the physician to change their practice.

    I leave you with a quote a colleague mentioned once which I have only recently come to appreciate; “There are only 2 ways to get physicians to do things, either pay them or legislate them”. Sad, but I suspect for the most part true.

  2. Hans Avatar

    Thanks for the comment. I’m not sure that there is anything special or inherently attractive about technology that would compel a physician (or anyone for that matter) to just start using it. Your point about workflow is probably the best way to conceptualize the issue – we need to develop a case by understanding the workflow.