And why argue at all? The user interface in any software product is the easiest thing to get right. All you need to do is apply some basic principles and tweak them based on talking to users, listening and observing them in their “natural habitat”. Having done exactly that, for an inordinate amount of time, and being aware that most EHR vendors were engaging in similar efforts, I found the growing discontent with EHR user interfaces somewhat inexplicable. The common wisdom in EHR vendor circles is that doctors are unique in how they work and whenever you have two doctors in a room, there are at least three different preferences in how the EHR should present itself. As a result, you will find that most mature EHRs have dozens of different ways of accomplishing the same thing. These are called “user preferences” and are as confusing as anything you’ve ever seen. Hence the notion that if you spend enough time configuring and customizing your EHR upfront, you will increase your chances of having a less traumatic EHR experience down the road. We were an industry like no other, doomed to build software for users with no common denominator, or so I came to believe, until one afternoon in the summer of 2006…..
My personal moment of Zen occurred in an unremarkable little primary care practice somewhere in the Pacific Northwest, where a kind and wise physician offered me a chance to play doctor, right there in his cramped exam room. He handed me his shiny new tablet and sat in the patient chair across from my rolling stool. I saw that as the perfect opportunity to teach the doctor how to use “my” software. I designed large portions of it and I’ve done hundreds of “live” demos of patients with diabetes, hypertension, COPD and “by the way” to showcase the ease of use and uncanny abilities of the EHR to simplify the most onerous tasks. And then he started talking. A simple visit. A little bit of gout. Some stiffness when climbing stairs and he didn’t like his new blood pressure meds. I couldn’t keep up. I couldn’t find the right templates fast enough. I couldn’t find the right boxes to click on. I tried typing in the “versatile” text box. I am a lousy typist. I tried to write stuff down with the stylus in the “strategically located” handwriting recognition box. I kept making mistakes and couldn’t erase anything. I tried to type code words for completing the note later. My head was down and I was nervously fumbling with the stylus and the tablet keyboard and my rolling stool kept moving unexpectedly. I would have killed for a pencil and a piece of paper. I finally looked up in total defeat and saw the good doctor’s kind smile, “now you get it”. Indeed.
A recent Tech Crunch article is quoting Prof. Christensen’s (of Innovation fame) assertion that “Understanding the customer is the wrong thing to do — it’s confusing”. It seems that Prof. Christensen believes that “what’s really important is understanding the job that customers are trying to accomplish, and only once an entrepreneur truly understands the need that a product or service fulfills for the buyer can they optimize their business or product”. I couldn’t agree more. So what is the job that EHR customers are trying to accomplish? What need does the EHR fulfill for the buyer? Are the job and the need one and the same? They are not, and the difficulty in creating an interface that satisfies EHR users arises because doctors love the job and hate the need. The job is to heal people and the need is to be properly paid for services rendered, including an escalating system of regulatory incentives and penalties for activities not immediately related to patient care.
Most physicians would describe their job to be the provision of medical advice to patients seeking their help and, to paraphrase Sir William Osler, most doctors will probably agree that observing and understanding the patient who has the disease is much more important than understanding the disease itself. So what can a contemporary software program contribute to observing and understanding patients? Nothing of any significance. Someday we will have intelligent software accessing sensors plastered on patients’ organs and clothing and perhaps then software will be able to assist with observation and understanding. But right now software can only offer protocols for simple and self-evident conditions. If the original electronic calculators were only able to multiply single digit numbers, nobody would have bought anything from Texas Instruments in those early days. How about the other parts of a physician’s job? Can EHR software help with delivering babies? Or performing surgery? Or at the very least, can it assist with a physical examination? Maybe an EHR can help with formulating treatment plans and ordering therapies? Mostly an EHR cannot do any of these things, and the little it can do comes at great inconvenience to physicians, when compared to methodologies it aims to replace.
But doctors are buying EHRs at increasing rates, so perhaps EHRs cannot help with the job itself, but they fulfill a need after all. The original need EHRs were designed to fulfill was the simple need for one to be paid for the job one was doing. This is the same universal need that drives every business to acquire and use accounting software. Generating proper invoices for services rendered (claims) was the first rationale for buying software in a medical establishment. As the rules and regulations for payments became more and more complex, the need for software increased and in parallel the software began interfering with the job. And although most physicians realized that they must allow the software to interfere if they wanted to get paid properly, it didn’t require that they like this interference. Most of us pay our taxes, but this does not stop any of us from complaining about the complexity and lack of user friendliness of the tax code. Later on, Meaningful Use and other “quality” reporting initiatives introduced regulations directly into the job of physicians and their staff. EHR software, still unable to contribute much to the job, is now fulfilling a much larger and more onerous compliance need, and at least from a physician perspective, it still has to do with being paid appropriately for services rendered.
Designing an EHR from the ground up to be an integral part of the patient care experience, as the anonymous commenting physician suggested, was never in the cards. EHR software was born to fulfill externally imposed needs, and as such it was destined to be regarded with suspicion and when those needs started invading every aspect of the job, even early supporters of computerization became disenchanted with EHRs. It doesn’t really matter how many user centered usability experts the government regulates that EHR vendors employ, because it’s not about the buttons and the clicks, it’s about what the buttons do. At a recent conference I saw a presentation delivered by two primary care doctors who found a way to restore happiness to the practice of medicine. Every slide had a picture of an exam room where in addition to a happy doctor holding the hand of a sweet patient, there was a third “team member” in the background fumbling with a tablet.
Shouldn’t there be a better way? At one point shortly before the advent of Meaningful Use, there was a slight buzz in the industry regarding something called EMR Lite. A brand new notion of creating software humble enough to take on the peripheral portions of the job that could be automated with existing technology. That seed of innovation was killed off by the perpetual onslaught of Meaningful Use requirements. Should it be revived? And if so, what should it look like? Stay tuned…..
Margalit Gur-Arie was COO at GenesysMD (Purkinje), an HIT company focusing on web based EHR/PMS and billing services for physicians. Prior to GenesysMD, Margalit was Director of Product Management at Essence/Purkinje and HIT Consultant for SSM Healthcare, a large non-profit hospital organization. She shares her thoughts about HIT topics and issues at her blog, On Healthcare Technology.
Categories: Uncategorized
Over two years ago, I wrote a little blurb on the subject, mostly in reaction to a NEJM article http://onhealthtech.blogspot.com/2010/03/ehr-checklists-bayesian-diagnosis.html
I am not certain that things have changed much since then, and I have a mild level of discomfort with the NEJM authors’ thesis. I am also aware of Dr. Weed’s work in this field (which has been commercialized, but not with much success…)
Do you see any current breakthroughs in this science, or are we still where we were back then?
Bayes RULES!
http://www.bgladd.com/Total_Information_Awareness/
“While the relative “accuracy” (sensitivity & specificity) levels of many clinical methods that estimate disease probabilities (or any type of experimental assay with anterior empirical underpinnings using Bayesian statistical methods … are tolerably well-defined (and uniformly well below 99.9%)… no test is infallible, there are inescapable trade-offs in terms of relative false-positive/false negative levels associated with any assessment.”
Good article
I found a good company in Nepal that provides good services on Health Care Software development, design and maintenance. For more info visit their website http://www.deerwalk.com/it_services.
By probabilistic I mean an approach that will be based on bayes theorem and statistical principles which are needed in order to put some structure on vague patient complaints, borderline lab values and also for assessing the need of certain diagnosis tests or the importance of their results in the overall context of diagnosis.
The problem here, as you have mentioned is the chicken and egg…we certainly do not have enough statistical data to build a medical diagnosis process based solely on probabilities… (We will have this if we will gather structured data for couple of years and mine this data)
In my opinion, even without accurate numbers – the principles can still be used with rough estimates/simple models and help reach better decisions.
Margalit – this is something that really needs to be seen in a live setting, and I think there may be a site fairly close to you. While a canned and/or remote demonstration can be arranged, that simply can’t demonstrate the real effects at the point of care. Let’s message privately.
I know I’m pushing my luck, Dr. Oates, but is there a way I could take a look at new design. I am really curious now…. 🙂
This is a very valuable observation. The issue with structured data is the chicken and the egg dilemma. We could probably do something useful with lots of discrete data, but we can’t do much more than hypothesize until we have enough data, and people are not willing to go to the trouble of collecting it, until we show what we can do with it….
I am intrigued by the term “probabilistic”, Dr. Gal. What do you have in mind there, as far as data collection goes?
Indeed an important and great discussion.
In my opinion, capturing structured clinical data using EHRs is key to updating/validating and adapting medicine to the 21st century.
Despite the current problems, it is a must.
I agree with the points raised about UI/UX of EHRs and the ideas of simplicity, paper metaphors. Most of the EHRs that I saw in the last couple of years were problematic at that and that causes errors and slows the clinical process.
Dr.Oates outlined great design principles, some of which are even quite easy to implement. However, I believe that this is not a strict UI/UX problem – there is an underlying problem in the way medicine is currently being practiced that can not be solved with a good UI/NLP and etc. (Computers, unfortunately, are less artistic in their nature than physicians)
Using even an optimized EHR to capture the entire story of the patient or a semi-processed version of it in a “paper like” manner,
is not sustainable.Hints to that are in these two quotes:
“A simple visit…. I couldn’t keep up.”
“whenever you have two doctors in a room, there are at least three different preferences.”
A unified,logical and probablistic way for interacting with patients while capturing their data in a meaningful way is needed in order for computers(EHRs) to help us and with the abundance of clinical information, shortened doctor-patient visits, standards of quality and etc. this help is really needed.
Amen to this comment. But, as long as the needs of the few outweigh and just crush the needs of the many, good luck seeing progress.
Great arguments guys, but I think you’re trying to fit them into a world where people make the best decisions for all of us rather than just a few.
Margalit – We are in complete agreement that it is wasteful having physicians be the ones directly entering structured data. We also agree that the reality is that data extraction from narrative is still mostly a research effort rather than something that is practical for the masses. I also agree that old-fashioned scribes are an anachronistic approach that attempts to salvage a fundamentally flawed methodology. I tried that too 6-7 years ago before starting over and fundamentally redesigning the whole approach with a goal of all but removing the need for physicians to do any direct data entry. However, they still have to review and sign off on patient’s encounter notes as they leave the room. I haven’t been able to design around that one yet.
What a great article! I think making things “easy” where once they were hard, or making things possible where they were impossible before, is exactly what technology should do. The caveat, of course, if you want to sell the technology, is that someone should want or need to accomplish these things.
The Apple analogy is perfect for little things we all do or want to do every day in our personal lives. It doesn’t extend very well to things that we do or want to do in our professional lives, and to give Apple credit, they never really tried to go that route.
HIT designers should probably go back to the conceptual stage of product design and look at the original (paper) state of practicing medicine, and see if they can make something easy or if they can make a dream possible. Unfortunately, in a highly regulated evolutionary process, nobody can afford to do that, and innovation is being built on top of bad ideas.
Introducing complexity and then trying to reduce the complexity you introduced is not a good way to serve your customer, even if he or she is a captive customer.
Good discussion here.
Thanks for the insights in this article. Of course I have to disagree with building simple and usable interfaces being simple, just by throwing more “Experts” at this task and doing some surveys. But I think the author makes it clear later – designing software for users by asking what their needs are, is not always the best approach, because often people just don`t know or cannot clearly explain their own needs. I think that`s one point why Apple is so successful: they take away desicions from the user and try to minimize complexity. This also reminded me of a recent article on Signa vs Noise about the strive for simplicity (http://37signals.com/svn/posts/3302-competing-on-easy). As EHR systems are evolving, their interfaces will too – finding the right balance of tech hiding/ease of use and offered functionality will be one of the hardest parts down that road.
Sounds very reasonable to me. For some reason, there seems to be an assumption that interoperability requires structured data and unified terminology. I don’t know that I understand that. Most people can read narratives better than structured data, whatever that is.
I think it’s funny too that most EHRs want you to click on boxes, but then go ahead and recreate a stilted narrative for the actual note…. Not sure what the point of that is.
Obviously, all the structured data in boxes is imperative for “research” and population analytics, but I thought those are supposed to be secondary to patient care. Perhaps we forgot that.
BTW, Cerner now has the contextual search you are mentioning above. It’s not perfect, but I saw a demo that looked pretty good. I don’t know if every Cerner facility has that deployed though.
Why not keep it simple? The basic function of any record is to document an individual’s healthcare, facilitating ongoing and future healthcare efforts.
Therefore, it should be centered around the healthcare providers – physicians, midlevel providers, nurses, therapists.
Operating the EMR should not distract from the mission to deliver healthcare. Providers should create (dictate if they want) classical narratives – consults, discharge summaries, telephone notes – and these should be available within hours for in patient care and within days for outpatients. These notes should be easily identifiable by specialty and accessible with a few clicks, without cumbersome filters, and outside documents should be scanned chronologically, by historical encounter, not in a dump basket as a “scanned media” pile. Lab values should be accessible in an easy chronologic table. All this should be organized like a typical windows application, with relatively few buttons and intuitive operations (i.e. double click=start a link, right click=show a list of options for the link I worked with Epic, Cerner, meditech and 2 smaller ones. Cerner powerchart fulfilled these basic functions best. I heard that the VA system does all that as well.
What is really missing – even though I think it should be feasible – would be an index searching one specific document (or all documents, or a defined group of docs) created within the system: i.e. enter Lupus and you get all documents containing “stroke” and a smart system would also suggest: Do you want to include: CVA? Infarction? TIA? ICH?
Ideally, external documents would also be searchable, although that would require different scanning, not just photographic.
Every other function should be primarily for the interested, superusers or IT specialists.
yeah, well… i did not say it was going to be easy…:)
Technology will find her (?) way to cross over if she 🙂 is allowed to develop and grow organically. Something tells me that she will not be allowed such freedom…
Darn, I guess I’ll have to name it something else in my next blog… 🙂
Dr. Oates this is a very insightful list, and I would have expected nothing less from the maker of a leading product.
Personally, I would like to go back a couple more steps, and at this juncture challenge the notion of structured data elements having to be in any way shape or form be required to be entered by physicians. I can see structured data fields for staff and perhaps for patients too.
I think technology needs to admit that it just does not currently have the ability to abstract data points from narratives, which is what is truly desired by third parties, and quit forcing doctors to make up for lack of technology innovation by abstracting their own notes or worse, their thoughts or their patients’ stories.
BTW, I find the need for scribes ludicrous considering that technology should make one more efficient. It’s like buying a washing machine that requires employing a laundress.
I would think that the proper course of action would be to start from scratch and build, one at a time, automation for tasks that users (not necessarily buyers) wish could be automated or removed in their entirety from their workload. I am pretty sure that nobody will be asking for automation of their interaction with patients.
BTW, “EMR Lite” is now a Branded “Meaningful Use Certified” HIE product owned by Optum (subsidiary of UnitedHealthGroup). They don’t intend to support it beyond 2013.
great points. optimistically i believe that the bundled payment initiative, care coordination and the progressing from fee-for-service to accountable-care will (and already is) reviving the light EMR concept. think about it for a second… if care coordination really means having the patient front and center and focusing (for now) on just nailing the 90 days post acute… if that model works and physicians will be engaged as so clinicians, there is no doubt in my mind that that technology will find her way to cross over.
What you say is on target, and no current EHR is even close to perfect. However there are some that are far more useful and less intrusive at the point of care than others. The problem is that most EHR systems are fundamentally designed to turn doctors into distracted data trolls. This is not a flow that appeals to anyone but those that don’t understand the consequences of firing low cost transcriptionists and then over-burdening high value clinicians. To avoid this disaster at the point of care, I currently suggest, as a starting point, only implement solutions at the point of care where information should mostly already be open and visible as if the paper chart were open on a large desk and most/all information instantly viewable with just a saccade rather than repeated opening-closing of windows. To be efficient enough to be practical:
1. An ideal EHR and workflow has the ability to capture coded/structured data without requiring the physician perform a bunch of extra, “outside” clicks. Most EHR products require extra clicks that are outside of a normal clinical workflow in order to capture structured-coded data. Physicians should have an easy method to include both structured data and narrative at all locations and at any time in the record and during a patient encounter.
2. Physicians should have an ability to easily create/edit documentation templates that inherently contain the ability to delegate the routine capture of needed quality measures, patient information, etc. Most system’s templates only allow for certain sections of documentation to be automated and can’t support inclusion of coded items, flow sheets, patient education, etc. Again, addressing these takes extra steps outside the normal encounter workflow which results in inconsistencies and extra work.
3. Physicians should not routinely be forced to have to click through a bunch of pick lists or check boxes to capture structured data. For example, addressing a quality measures should just be one click within the currently open encounter or standard/automatic workflow and should not multiple clicks in other windows outside the encounter note.
4. No linear workflows should be forced onto physicians. Patient encounters involve a very non-linear approach to information gathering, yet most EHR systems attempt to force a linear input. For example, some will not allow physical findings to be entered until the vital signs are captured.
5. To be efficient, the information technology at the point of care should have the ability to keep multiple windows open concurrently. This characteristic can remove many of the clicks required to open-close and navigate. For example, the viewers for lab, radiology, problem list, current meds, allergies, and many others should already be open and ready for instant viewing without having to go through the motions of opening and closing multiple windows.
6. At a minimum, the point of care information technology should offer the ability to group documents as needed anywhere within the record. Physicians are having to travel too many places to collect the needed information when face-to-face with patients. The recent lab reports, consult notes, and radiology reports should already be within the current encounter when the physician is face-to-face with the patient.
7. The EHR must allow multiple charts to be open on multiple monitors of a single workstation.
8. The system should facilitate the capture of necessary, structured data by the patient and care teams for review/editing when the clinician is face-to-face with patients. The data entry should be in real time, but performed rarely by the clinicians who should have undivided focus on the patient.
This is all possible today with only a very few. As the fees for services wane and there is an increased appreciation for costs and efficiency, this will change. Success will come to those that learn to conserve the rarest and most valuable resource at the point of care… the clinician’s time and attention.