Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Better EMR Design

Posted on May 23, 2012 I Written By

Priya Ramachandran is a Maryland based freelance writer. In a former life, she wrote software code and managed Sarbanes Oxley related audits for IT departments. She now enjoys writing about healthcare, science and technology.

Now that we’ve heard the statistics about EMR use, we’re also hearing a lot of opinions on EMRs, and not all of them are laudatory. In fact I read some separate articles recently, and they pretty much said the same things in so many different words:

– EMRs are not intuitively designed. They do not reflect actual workflows that most doctors or hospitals follow. Rather the applications look like they’ve been designed by a bunch of programmers who then design the UI to look like how they’re underlying data are structured.
– Because they’re pretty much being foisted on hospitals and doctor’s offices through “incentive” programs, often the resources expended on them are sunk costs. To improve the workflow of a software to accurately reflect the needs of a particular hospital, you will need to pump extra money into it. That’s about as likely to happen as a software vendor providing you a customized solution without charging you anything extra.

Let me assure you – the medical establishment has it exactly right, at least in my experience. I work as a technical writer, so much of my working life consists of documenting the products that make it to your doorsteps, and I have experienced some of the same frustrations as you. I’ve complained about them, made myself unpopular with development teams and added my two cents to feature request lists, just like many of you.

But, I also see things from a programming perspective too, and I’m here as a sort of ambassador between both worlds. Many teams I worked with had an actual designer working as part of the team.
But the designer’s role was often making the colors look attractive enough, or the font large enough to appeal to a cross-section of users. One of my old bosses, different industry and everything, called this our Lipstick on a Pig game, and plenty of times that’s what the designer’s role was. Inventing plenty of shades of lipstick for the proverbial pig.

Ergonomic design was not what the designer was tasked with doing. One place I worked at even had a doctor on payroll. Except he had a doctor’s degree from Shanghai, had not cleared his exams in the States and had no idea how medicine is practiced in the States. It sure looked good on paper when their sales team went out to clients and talked about having a dedicated doctor on staff to help with software design.

And the effect of poor design on functionality is often perplexing, sometimes disastrous. Case in point – documenting all the drugs administered to a patient. It has been drilled into programmers that clicks are sacred things, you don’t want doctors wasting too many of them.

So because we don’t want too many clicks, we list each and every medication a patient has been administered, add some pagination logic around it and call it a day.

The doctor, who is the end user, for whom we designed this software system, now sees all the information in a “convenient” list and doesn’t need to open up a medication tree to view the medications under it. Except if she has a very sick patient with multiple encounters, the case history reveals a medication that is 31 pages deep. To get to Xanax, she might have to page through 30 previous pages.

While these “features” fall into the realm of merely annoying, they’re nowhere as disastrous as those modal alerts that Barbara J. Moore talks about in her KevinMD piece. A modal window is one of those annoying windows that you have to take an action on, otherwise you can’t proceed any further in your workflow. Moore points out the hazards of such alerts which force a doctor to take a choice, any choice, but aren’t available later if the doctor wishes to review the alerts at leisure.

So yes, software vendors need people who know the workflow to design the systems. But more importantly, you – the medical establishment – must keep requesting changes or suggesting features, or vendors will remain complacent about what they put out.

Craig Be Nimble: “Disruptive” Medicine or Inefficient Method?

Posted on March 16, 2012 I Written By

Priya Ramachandran is a Maryland based freelance writer. In a former life, she wrote software code and managed Sarbanes Oxley related audits for IT departments. She now enjoys writing about healthcare, science and technology.

I came across this very thought provoking post by Dave Chase on Kevin MD today, outlining “nimble medicine”. A little bit of googling revealed that a vastly better version of it, again by Dave Chase, ran on TechCrunch in late Jan. Yes, I’m that late to the party, and I will admit I’m feeling a little cheated by Kevin MD (really, how much trouble does it take for you to point out that a version of this article ran elsewhere?) But I digress.

To exemplify nimble medicine, Chase talks about a few interesting cases:
– Dr. Craig Koniver, who has closed his B&M clinic, and now runs a mobile clinic visiting patients at their homes or workplaces
– Medlion, a Silicon Valley company, completely bypasses the insurance brokered model of primary care and uses the Direct Primary Care model instead
– Companies like have made it easier for patients to get a second opinion.

Ladies and gentlemen, here’s medicine, as it perhaps should be practiced in this age of 4GS. Of the many cases that Chase discusses, the one that is most iffy for me is the mobile clinic one. Don’t get me wrong – I’m as much a sucker for a David-Vs-Goliath story, and if Dr. Koniver’s story were on Hallmark tonight, I’d be reaching for the tissues right about now.

However. The idea sounds awesome in theory. In practice, I’m not sure the model is sustainable. In fact there might be plenty of inefficiencies built into it.

Let’s say Dr. X sees about 8-10 patients a day. This is well below the 20 minute per patient average that most PCPs see their patients for.

Patient 1 lives in the North east quadrant of the city, Patient 2 work in the heart of downtown, and Patient 3 is in a city suburb, and so on.

One way to see all his patients is to go on a strictly First-Come-First-Serve basis, based on whatever his medical assistant has scheduled. This is not a feasible alternative at all. What if Patient 1 is 20 miles W from patient 2 and Patient 3 is far, far East of Patient 1. Horribly inefficient, which is exactly why algorithms such as the Travelling Salesman were invented in order to optimize travel paths.

The other alternative for the good doc is to apply the Travelling Salesman algorithm to his situation and base his visits to patients on geography. He might schedule his patients in such a way that he first sees all his patients that live in the Northeast quadrant and so on. Except now, the most pressing patients might need to wait till Dr. X actually services the patient’s part of the city.

Dr. X can of course optimize his travel path based on location as well as patient priority/needs, which is enough to give any grown person a raging migraine. And it doesn’t even get to the bottom of Dr. X’s biggest headaches, which is that
a) he spends an inordinate amount of time in traffic in
b) a gas guzzling vehicle that houses his medical equipment.

Waste of time, money and maybe even lives (imagine a patient dying while Dr. X is negotiating rush-hour traffic in DC)

So how can Dr. X compensate for this? By charging his patients for his time and attention. Or cutting down his clientele to a tiny sliver of a neighborhood. And yet, it makes for a wonderful story on “disruptive” medicine.