{"id":501,"date":"2013-08-27T20:02:50","date_gmt":"2013-08-27T20:02:50","guid":{"rendered":"http:\/\/www.seonthemon.com\/wp351\/?p=501"},"modified":"2013-08-27T21:39:31","modified_gmt":"2013-08-27T21:39:31","slug":"i-havent-met-a-physician-yet-who-likes-emr-software","status":"publish","type":"post","link":"https:\/\/www.seonthemon.com\/wp351\/2013\/08\/27\/i-havent-met-a-physician-yet-who-likes-emr-software\/","title":{"rendered":"I haven’t met a physician yet, who likes EMR software"},"content":{"rendered":"

I only have anecdotal evidence, but every physician I talk to, hates the EMR software he has to deal with.<\/p>\n

Ye old Enterprise IT<\/h1>\n

One particularly tech savvy young resident in an area hospital, says, “… too many clicks, too many clicks<\/em>“. These are folks that live in their iPhones and iPads every spare moment they have.<\/p>\n

As he did book-keeping on his laptop, I peaked over his shoulder at the EMR program he was using. \u00a0Also, a couple of months ago, I had occasion to spend a few days at Johns Hopkins, helping take care of a family member, and I took every chance to watch the staff at work at their monitors, which now seem to be stashed into every available corner (each patient’s room had a desktop, monitor, keyboard, and mouse). \u00a0I was a little taken aback to see that they were all using Windows desktop applications. \u00a0Seen through eyes drunk on modern touch-screen mobile devices, these apps look old-fashioned – poor, tired, windows, boxes, lists and buttons, huddled together in an unappealing jumble.<\/p>\n

My doctor friend said his EMR was cumbersome to use, and it took too long to enter all the data that he is prompted for. \u00a0He seemed to unconsciously separate information that is vital to patient care, from information that is just “for billing<\/em>“. Often, he enters only the patient care information that he thinks is necessary, and ignores what he called, “fluff<\/em>“.<\/p>\n

The word “fluff<\/em>” struck a chord. \u00a0Design for mobile first. \u00a0That forces you to identify the “fluff<\/em>“, and drop it.<\/p>\n

Essentially, what I saw was classic Enterprise IT interfaces. \u00a0They serve some bare business purpose, with little thought to ease of use. \u00a0Users, doctors, and nurses, in the midst of their high-stress workdays, just deal with it, because, well, they have to.<\/p>\n

There were more tell-tale signs of Enterprise IT.<\/p>\n

\"Yea, they improve things, but everybody hates the changes. You \r\nmanage to learn one thing, and then they make you learn something \r\nnew all over again.\"<\/pre>\n
\"They never ask the doctors. \u00a0They try to keep us away from what \r\nthey are doing. \u00a0 They build something and show it to us, and it \r\nis not great, but then it is too late to change anything.\"<\/pre>\n
Impenetrable domain knowledge<\/h1>\n
The doctor is looking at lab results. \u00a0He sees that haemoglobin is low. \u00a0 In that situation he is taught to then look at past iron levels, and vitamin levels, which are results of other tests. \u00a0 In the interface he showed me, the iron levels, and vitamin levels were hard to find. \u00a0The lab results were a long Excel like table, and he had to scroll far and wide to find them. \u00a0They were not close to the haemoglobin levels. \u00a0The interface was not smart enough to offer the iron levels and vitamin levels when it detects that the haemoglobin is low. The doctor said he sometimes surrenders to fatigue and irritation and simply orders the tests for iron levels and vitamin levels again. \u00a0 Of course that is duplicated effort for someone, not to mention a wasted expense.<\/p>\n
The business analyst who modeled the diagnostic processes obviously did not know how medical personnel are expected to react to low haemoglobin. \u00a0 \u00a0The UI designer did not know that a relationship exists between low haemoglobin, and iron, and vitamin levels. \u00a0 The interface they built does not reflect that knowledge. \u00a0The EMR software did not make the physician’s job easier. \u00a0In fact, it made the whole process more inefficient, and wasteful.<\/p>\n
There must be so many other little use-cases like this. \u00a0I imagine the patient care domain is vast, varied, and complex. \u00a0 A doctor\u00a0spends years acquiring all that training, and knowledge. \u00a0 How can you expect a business analyst, or UI designer to absorb all that information? \u00a0 Even in the best of circumstances, there are so many ways for domain knowledge to get lost in the translation, from business user through business analyst, to system designer, and finally to the developer. \u00a0I imagine that this exercise is even more error-prone in a complex and information-heavy field like patient care.<\/p>\n
Are we barking up entirely the wrong tree? \u00a0Is it a fool’s errand to try to model the patient care domain in order to produce a structured interface that makes the doctor’s job easier?<\/p>\n
 <\/p>\n
A simple-minded EMR<\/h1>\n
I wonder if something like this would be a viable EMR system?<\/p>\n
A universal key<\/h3>\n
You must be able to uniquely identify a patient, a human being. \u00a0 In other words, you need a universal key for their records, which you can apply at any health-care organization they are visiting. \u00a0Say, fingerprints. \u00a0Would that work?<\/p>\n
A simple collection of documents<\/h3>\n
Medical records themselves are just a collection of documents. \u00a0They can be anything at all – plain text, HTML, WORD, EXCEL, PDF, audio, photos, video, etc. \u00a0Each provider simply creates whatever records makes them happy, in any format at all.<\/p>\n
Each document is characterized by very simple, non-medical meta-data.<\/p>\n