Replies to This Discussion

Permalink Reply by Dean Karavite on July 9, 2009 at 7:05pm

Okay, down to business. I had sent Peter some topics for discussion in what might be categorized as design issues. For example:

1. Design strategy of the contemporary EHR.
Currently mimics paper processes. Decision support is rudimentary. So, what's next?

2. IA/Usability of the contemporary EHR.
Absolutely primitive. Vendors seem ignorant of all we have learned in other areas.

3. Assessment of the current EHR.
Jury is out on cost savings, productivity, improved outcomes and safety. What can we learn from how they fail?

4. Implementing an EHR.
A very $ and painful process. While we wait for the next EHR design, too many are already committed. Can we help design a better implementation process with the EHR's we have today?

5. Data and the EHR. Current design primarily focused on operational routines. Data access is difficult and complex. How can we make data access a higher level design requirement? Then, how we might go about designing to harness data in the aggregate, but also for the single patient at the bedside.

6. Designing the EHR to promote clinician-patient interaction.
The computer is taking over the exam room. How to design the focus back to interaction between the patient and the physician?

However, maybe this isn't the best approach. Every issue listed above refers to some existing problem. Cleaning up after someone else can be challenging, but I most enjoy the opportunity to design something from the ground up without constraints, especially those introduced by other designs. I'm betting many of you feel the same way. As designers, we might cover the same topics (or others), but instead of concentrating on someone else's design, we might imagine/present our own much more elegant and ambitious "end states" of design and then discuss how they might come about. Or perhaps both are required - the former for current EHR's and the latter for the "next EHR."

To get things rolling Peter asked me to pick a topic to start things off. So... I'll take "#6. Designing the EHR to promote clinician-patient interaction" for $200 Alex. I'll also submit this NYT Op Ed letter as supporting material.

Paper charts seem to be the object of so much scorn. Archaic and worthless. Yet these artifacts supported patient care for decades and continually evolved, often in clever ways. Instead of pointing out their shortcomings, what can we learn from studying paper charts and how they *succeeded*? How can we translate (or better yet, expand) these characteristics to the EHR? I have a few examples, but will save them for later.

• ▶ Reply

Permalink Reply by Peter Jones on July 15, 2009 at 12:40pm

Dean - I had to post this today because I am both astonished and spooked at the level of specificity the Google ads have with respect to content on the book community site. The top ad link was a link directly to UserCentric's whitepaper on Measuring EMR Usability. Sometimes I wonder if Google is going to be giving better contextual insight than actual human beings, since there are posts about this topic showing up at several other places than your forum! ;) In case the link is gone, here is the direct link for those interested: http://www.usercentric.com/publications/2009/02/05/how-select-elect...

Have you read this yourself Dean (or others?) Their paper represents solid user experience research and presents a highly professional basis for evaluation and selection. This is stronger than most of the other reports I've seen, and it is very current (2009). In reading this and other usability-oriented research and whitepapers about EMR systems, I find some gaps between design / research disciplines that emphasize (to me) the need for the book. We really are working across silos - not just healthcare applications and sectors, which are silos themselves - but the different perspectives on It and interaction design, research, and user experience. We think we're speaking the same language, and we're close, but we're not. Here's a simple question: Look at the key tasks selected as examples for usability testing in the paper:

Key Tasks: Create an appointment for a new patient, find a rejected claim and correct errant information, check the status of a specific claim, check patient eligibility for Medicare.

Yes, these are key, and probably representative. AND I have no experience in testing EMRs, so I'm not a good one to make claims here. I do have some experience in designing integrated information services for them at the point of care, so I know first-hand about the problems physicians, nurses, and order entry people have with them in ecological settings.

The usability testing approach may be state of the art, but then EMRs are so bad we need more than usability guidelines. We need a way to declare them unreliable and undependable technologies. We need to expand our vocabulary beyond usability terms, to draw from other disciplines along the lines of Vicente's Human-tech approach. But where's the identification of complex or leveraged tasks? What tasks, if error-inducing, will lead to patient mortality or an institutional liability (high-hazard)? Will the optimization of any of these tasks significantly improve adoption, patient, health or user experience (leverage)? And so on. We need to blend a mix of guidelines and practices from usability, user experience, HCI, and CSE - cognitive system engineering (see R Cook and Chris Nemeth's research at: http://www.ctlab.org )

What do you guys think? Do we have any EMR usability testing studies among people in the group?

• ▶ Reply

Permalink Reply by Diana Garcia on July 24, 2009 at 4:14pm

Hi Dean,
By way of introduction, I currently work in the information systems department at a specialty hospital managing the development and support for our patient portal secure Web site.
Given your extensive experience with various EHRs and their implementations, what would you say are the biggest hurdles in 1) identifying those records that patients would actually want to access (here I make the assumption that most EHRs hold a lot of information that would not necessarily “make sense" to patients or be helpful in empowering patients/caregivers in their healthcare management) and 2) actually interfacing those records to a PHR?

• ▶ Reply

Permalink Reply by Dean Karavite on July 26, 2009 at 12:02pm

Hi Diana,
I know a few people at our hospital who are working on something similar. If you want, please feel free to email me and I could put you in touch. In the mean time, I won't pretend to have the answers, but will give it a shot.

Applying UX methods, I think the answer is, #1 is much easier. In fact, you can build up a massive list of ideas with a relatively small amount of research. I think one way to approach this is build a list of ideas and rank each both by benefit to the patient and feasibility. For any issues you identify as important yet not feasible, send it to the vendor and ask them what they are doing about it. Speaking of feasibility, #2 is the killer. However, I would add this. These systems are so complex that by the very nature of their complexity they offer many opportunities. Are they the best opportunities in terms of design? Certainly not. If you follow the manual, or talk to most consultants, they rarely seem able to address these issues, but by stretching the design/architecture of these systems you can come up with workable solutions. "Hacks" in the original, positive sense of the term.

I have an anecdotal example. It is ridiculously simple, but had value for patients. From a technology standpoint it was anything but challenging, yet for some reason entrenched EHR processes, roles, priorities... failed to provide a solution. I met a physician who had a library of no less than two hundred different patient handouts for all types of issues and was very careful to distribute these materials to his patients during visits. However, his collection was all in print and he did not have access to the electronic originals. Meanwhile the EMR could generate patient instructions to be printed at the visit, but did not support anything but text (no attachments, no pdfs...). Solution, buy a simple OCR package (or use a service) and scan in all these materials, correct mistakes and copy-paste the text into the EMR's patient instruction repository. Great, now they are in the EMR, but while our one doc has encyclopedic knowledge of what is available, what about the other docs in the clinic? Now, add in the EMR's decision support features to automatically offer to print these materials during a visit. Psuedo code - "If Patient is two years old, print patient instructions: Dealing with the Terrible Two's and Potty Training." and/or, "If patient has Asthma on problem list, Print assorted asthma related materials." Perhaps the same type of document access and/or logic could be extended to a patient portal? There are certainly plenty of online resources for patient information, but having information reviewed and recommended by my doctor/hospital would be, I think, a more trusted source.

P.S. The EHR vendor is aware of the importance of supporting attachments and it is in the works for some upgrade...

• ▶ Reply

Permalink Reply by Dean Karavite on September 19, 2009 at 5:25pm

Hello All,

This forum hasn't seen any activity for a while. I'm sure many are interested in EHR design and have a wealth of ideas, so I'm concerned about how I may have managed or opened the discussion. I thought I would try again by presenting a design and workflow problem. It is from a hospital that recently implemented a commercial EMR (one of the major ones). The problem description is very serious in terms of accuracy of patient data. So, I cannot imagine it has not been addressed by someone, somewhere. However, knowing what I know about the EMR, I can see no viable solution, or one that would not require a massive effort to work within the design constraints. If you are interested, feel free to participate in a free and open discussion. Or, rather than solve the problem, how about looking at how a design methodology could be applied to the problem? Relate a similar problem from some other field? No rules.

A little background. When people mention patient data in an EMR, I'm not sure most realize this "data" is in fact, text. "The note" is a long standing artifact or tool used by clinicians in patient care. EMR design has translated rather literally the management of the paper based note to an electronic format. While the EMR provides the capability to enter discrete data fields within the note, there are no controls and as a result consistency is rarely achieved. For example, one doctor might use a data field to document a symptom, but another doctor would use plain text (or even a slightly different data field). You have to see these note editors to believe them. They are highly reliant on very unconventional keyboard shortcuts and templates. The first time I saw one I was reminded of EMACS or some other intense Unix editor.

With this background here is a description of the problem (edited for anonymity)

"...has been charged with improving the precision and usefulness of inpatient documentation in [EMR vendor]. One of the areas of challenge relates to sorting out and summarizing the timing of events. A particular issue is that narrative documentation tends to be copied forward from one day to the next, and sometimes from one provider level to the next (e.g. the resident copies the med student note and revises, the attending copies the resident note, ...) So... basically the repetition becomes exponential. Sometimes the timing of important events such as intubation and extubation are obscured or are accidentally falsified in this "copy forward" process. The undesirable aspects of this charting behavior is certainly facilitated nicely by [THE EMR]. Also, one "reward" felt by the clinician for this behavior is that the comprehensive discharge summary becomes very easy to produce from the last progress note. In spirit, the "copy forward and revise" documentation process allows you to gradually create the discharge summary over the course of the hospitalization, which is not necessarily a bad feature by itself!"

Isn't that interesting? Forget trying to solve this problem, just discussing the user behavior as it relates to design is, I think, fascinating. On paper, the note was a "hand crafted" professional narrative of patient care, even if it was dictated. In the electronic format, it can be assembled with every possible shortcut a computer provides. If I put on my technical hat, the first thing I thought of were applications developed to facilitate document collaboration. How about you?

• ▶ Reply

Permalink Reply by Christopher Fahey on September 21, 2009 at 11:31am

I have recently been superficially exposed to some EHR systems, and I am dumbfounded.

For years I thought that EHR systems were enormously complex data systems -- more complex than, say, any web-based application or business database. I thought, for example, that they contained diagnostic logic, or counter-indications for drug combinations, or the ability to analyze an MRI in 3 dimensions.

What I have learned is that they are little more than a regular relational database, not exceptionally complex compared to those at the core of many other industries (say, no more complex than tax software). I was shocked to learn the degree to which documents are just scanned in as raw images rather than imported from some more complex image or pattern recognition system -- I had assumed that some kind of incredibly complex math requirements must explain the slowness of EHR development. And while I am not particularly amazed that there is no single data standard for interoperability between EHR systems, I am still surprised that even adhering to a standard isn't a design constraint. In short, it seems to these layman's eyes that the technological hurdles to EHR development aren't that enormous.

I have also learned that a stereotype of the physician as a computer "idiot" is fairly standard. Physicians are certainly not database architects, but still...

The literature I have seen about "the problem with EHR", in fact, usually breaks it down in those two ways:

1) The data is too complex!
2) Doctors are stupid.

As an outsider looking in, I dispute both claims. The data does not look complex compared to what banks, online retailers, search engines, and countless web-based applications already deal with every day... and I refuse to believe that doctors are any less computer savvy than the millions of Americans who can buy books on the web, and do their own taxes on their desktop PC.

I might be totally wrong here, of course. But that's the rub: It seems that the number of people in the world who know *anything at all* about EHR is extremely limited, and does not include anybody from the mainstream worlds of user experience design. It seems that the EHR world is about 20 years behind the rest of the world in terms of usability and interface design.

It reminds me of the 2000 election Florida butterfly ballot, where the UX community learned that an entire professional practice existed around ballot design, but that they existed separated from the rest of the UX world. EHR is the same: the people designing them cannot possibly be aware of the design possibilities the rest of the UX design field is already practicing, just as we in the UX world are unaware of the dismal products doctors are being forced to wrestle with.

The cure, I think, is to expose them.

I would like to see a repository of case studies into the user interfaces of EHR systems today (or at least a page full of screenshots). Such a repository would automatically invite critical viewpoints from practitioners who can actually help raise the bar and improve the usability of these systems.

But until the EHR design world overlaps the UX world, I fear it will continue to suffer from the same lagging and outdated ideas about design and use.

• ▶ Reply

Permalink Reply by Christopher Fahey on September 21, 2009 at 1:02pm

Wow, re-reading that I see I was a little harsh... Of course there are many people in the EHR field who want to bring usability and user experience lessons learned in other domains to the medical domain. I didn't mean to slight them, but rather to lament the fact that they seem to be in the minority, or at least not empowered.

Moreover, I don't mean to suggest that EHR is not a complicated problem to solve. I only mean to suggest that there are, in other fields, other problems of similar complexity that have been solved more effectively.

Again, a more public exposure to the UX community at large to the weaknesses of these systems might make a big difference, as I am sure many of my colleagues have no idea what is going on in EHR.

Conversely, exposing EHR executive decision makers (the people who apparently often don't see the UI of an EHR as an important enough problem) to the kind of difference usability and user experience design practices have brought to other fields (banking and finance, accounting, project management, retail, and more) with visceral before and after stories might light a fire under them as well.

• ▶ Reply

Permalink Reply by Dean Karavite on September 21, 2009 at 10:18pm

Hi Christopher,

I didn't see your response as harsh, just passionate! That's a good thing. It's clear you want UX to be more involved. I found myself agreeing with you. As proof, see this rather long winded post on Lou's blog about six months ago (last comment). http://www.louisrosenfeld.com/home/bloug_archive/2009/03/stop_liste...

I might regret this, but I will do a little generalizing. If and when you get involved in healthcare and EMRs you will certainly run into this. Everyone will tell you, "...but healthcare is different." Not only that, they will tell you, "...our hospital is unique." or "...our patient population is different," and so on to every level of everything they do. "We are unique" is a well known joke in hospitals. It is rarely the case, but is played all the time. Don't back down.

An anecdote. I was working with some people regarding materials management related systems in a hospital. Hospitals use a lot of stuff and it is very, very expensive. Waste is rampant and an independent bookstore manages their inventory with more discipline than that particular hospital department. The hospital hired a man who had no healthcare experience, but had extensive experience in manufacturing and supply chain logistics. He was shocked at the absence of basic materials management techniques used widely in industry. When he raised various points, he was hit with, "...but hospitals are different" or "a hospital is not a factory" (as if a super efficient factory is a loathsome thing). Slowly but surely (a year) he was able to bring them around, but it was painful and frustrating.

I'm certain anyone in UX exploring work in healthcare has and will run into similar deeply entrenched points of view that need to be challenged. So, be prepared. Also, yes doctors are very smart, but don't forget, so are nurses and techs. I doubt any other profession can match the level of expertise clinicians posses and utilize every single day. In fact, they are so smart I have seen poorly prepared consultants ripped to quivering shreds. You have to do your homework. At the same time, if you do something to actually help clinicians with their patients, their gratitude is boundless and you are in.

As for EMR design one thing EMR's actually do well is manage the transactional properties of a hospital and these properties are massive. However, while they are built to do almost anything they don't do any particular thing well. Configuring and managing these systems is one step away from programming. As you noted, the UI's are like a time warp back to the early 1990s, but there is more. These systems contain so much data, but utilizing that data, whether from a single patient or ten thousand, is very difficult and a secondary design consideration at best. "Informating" the EMR is the design I am most interested in. I could go on, but there is more than enough for everyone. It's endless.

So where to start? I might be too cynical, but the EMR vendors are going to be tough. Because they have been UX free for decades, they are making big money off of their current design state with training. Go to any major HIT vendor training facility and every hotel within 20 miles provides an EMR training shuttle. I have been trained in three systems at about $10k each and I was just one of hundreds of trainees present in the opulent and even garish facilities. There is real money here, real money from poor design.

Dean

• ▶ Reply

Permalink Reply by Colleen Jones on November 13, 2009 at 10:02am

Hello,

I wanted to share that CHI*Atlanta (local chapter of ACM SIGCHI) recently held a wonderful panel event about electronic health records including Kaiser Permanente, CDC, and Greenway Medical Technologies. (See the slides.) The slides don't do justice to the great discussion of the challenges and opportunities involved in electronic health records.

We're interested in holding a follow-up event in 2010 more focused on design for electronic health records and welcome suggestions for participants.

• ▶ Reply

Permalink Reply by Dean Karavite on November 16, 2009 at 6:10pm

Thanks Colleen! Apologies for the delay in responding, I didn't get a notification that you posted. It sounds like you had a great event. Looks like a great overview, but you also dove into some key issues. Please keep us updated. Along the same line of thought regarding the PHR, I put together this post for today.

David Blumenthal quoted: http://www.healthdatamanagement.com/news/Blumenthal-39358-1.html
""A key premise: information should follow the patient, and artificial obstacles--technical, business related, bureaucratic--should not get in the way. As a doctor, I have many times wanted access to data that I knew were buried in the computers or paper records of another health system across town. Neither my care nor my patients were well served in those instances. That is what we must get beyond."

The good news is this is getting attention: the inability to transfer a patient's electronic record from one hospital to another. Most people I know are beyond flabbergasted when discovering this is not a current capability of most EMR's. In fact, two hospitals can have the same vendor's EMR and still not have this capability. Do you know what often happens in this scenario? The hospital will print out reports from their EMR, fax it to the other hospital where someone may (or may not) enter some (all? no way) information in their EMR. How could this not have been a requirement in the design of these systems?

If you get into the workings of an EMR you cannot avoid understanding they are built on complex hierarchies and almost all of the behavior within these systems is based on relationships within these hierarchies. What do these hierarchies represent? The structure of the hospital. Most have a top level of "Enterprise" which represents the entire medical center or health system. Next comes something like "Facility" which describes major centers (such as one of many hospitals in the health system). This is followed by Locations, Floors, Units, Beds... and so on. In fact, one system I was trained on evolved from an outpatient system. It's original design did not account for an inpatient environment and you can see this in the hierarchy where everything was sort of adjusted by one level and as a result each level of their system is skewed by one level in comparison to most systems.

A wise programmer I once worked with told me that I, as a UX specialist, had to describe to him the environment in a way where he could develop a data model that would not just work for our current tasks/workflow, but be able to be versatile to account for new and improved functionality. If we got it wrong, we would encounter massive problems as the system evolved. Okay, so for these EMR's now we want to add a new top level to in some way account for any other hospital or health system? I'm not an expert in the techno lingo here, but how in the world do you shift the hierarchy of a massive complex system off of what is essentially it's core foundation? I have no idea, but something here seems simple to me - they got the data model wrong.

Let's think about these EMR's and some scenarios. I'm a patient at ABC Hospital and they need my records from XYZ Hospital where I was a patient for many visits and inpatient stays. Both EMR systems have a patient history section. What if there are discrepancies? How is this reconciled? Both systems have a Problem List, a list of medical issues I am dealing with (asthma, hypertension...). What if they don't match? Again, how are they reconciled? Does each system use the same code for asthma or hypertension? Both systems list my allergies. Again, what if there are discrepancies (not just the allergy but the severity of an allergy) and how will these be reconciled? What if XYZ had built in reminders and other features to keep me up on tests or other issues? Will ABC get all this and will they continue to work for me? Now let's really mix things up. I decide to return to XYZ for my care. Now we have to shift all the ABC records back!?! Another issue. When we think of our patient "data" a lot of what is in an EMR isn't data, but text. Text is not data. EMR's contain narrative descriptions of our care in the form of progress notes and discharge notes. If we can transfer all these, is anyone going to read them? Are they going to discover what is important within these notes? If the only workable solution is to transfer some sub set of "critical" data, then what is the point in collecting it all? I could probably go on and describe a hundred scenarios that would make a programmer (or patient) wake up screaming in their sleep.

I'm sold on the patient centered model.

• ▶ Reply

Permalink Reply by Nicole Maron on December 28, 2009 at 5:02pm

Dean and Christopher, I couldn't agree more -- a patient-centered data model supporting a user-centered system of interfaces is the ideal we should be working toward. Unlike yourselves, I'm a freelance interaction designer without medical system expertise, so when I approach a new project I partner with my client as the domain expert. Every new project is an adventure due to the domain-specific real-life problems to be solved, but the process of identifying those problems follows a familiar user-centered discovery path, and the solution goals are not often wildly unique: gaining a true understanding of user tasks and obstacles, employing a correct and scalable data model, empowering communication through consistent channels, preventing user error, providing necessary recovery systems, and ensuring usable output. If we set aside adoption and implementation issues for a moment, the understandable but still perverse overemphasis of institutional models over patient needs appears (from my admittedly limited industry viewpoint) to be the core challenge in modern health care design.

The issue of data as text is an interesting one. Many conditions have fairly standard symptoms. Many diagnostic procedures follow strict protocols. Many diagnoses have standard courses of treatment. From what I've seen so far, there appears to be quite a bit of opportunity to provide structured data options alongside text (let's assume for a moment that input solutions are a given), thereby allowing better tracking data without losing the nuances provided by text.

Of course, it's a non-trivial task to create a new, standardized patient record format. To reach its true potential -- becoming an accurate, usable tool to inform diagnoses and treatment plans, and track progress and prognoses by comparing, connecting, and surfacing these dots of data to health care providers -- it would need to be eventually joined by an industry-wide standardization of condition codes and a lot of very complex, very thoughtful logic.

I must apologize if this all seems old hat to you. I am new in this field and still mightily surprised at how, as you've pointed out, heath care system design seems to be in stuck in a time warp. I was horrified to learn that condition codes vary not only by label but even by definition among the insurance companies, and the trickle down effect on hospitals, doctors' offices and clinics is an opaque billing nightmare.

Does anyone have experience with the various open source products out there? http://en.wikipedia.org/wiki/List_of_open_source_healthcare_software

Do you think any of these are heading in the right direction regarding patient records?

• ▶ Reply

Permalink Reply by Peter Jones on December 28, 2009 at 7:06pm

Good to see your question Nicole, and thanks for the link to the Wikipedia list. I must admit I have not come across a related discussion on the Design for Care site. We are not asking questions about (at least current) open source EHR or HIT systems because these systems are not even showing up as credible alternatives in most institutional cases. The compelling rationale for using open source systems are 1) control, 2) cost reduction and 3) DIY system management. Health institutions are not driven by these requirements as much as other industries. There may be over 100 services on the market, but large institutions are unlikely to adopt them, now or in the near future.

Of those systems, one of the most well-developed and flexible EHR systems built, the VA's WorldVistA, is not even deployed by other US government departments. Even the DoD has never (to my knowledge) used the Veteran's system, which seems like an obvious relationship, since all DoD patients will transfer to the VA after service. The Va (and VistA) serves the largest number of former and active patients in any health system, globally. VistA (and its VA interface CPRS) are capable and flexible, and if not the most usable, are still better designed for large institutional demands than most of the major vendor systems. You would think if the Obama admin wanted to standardize and save useless costs so they could be spent on patient care, they could mandate the use of open systems. But that would be considered "socialism," and the US might end up with a healthcare system someday like Sweden's. Snipes aside, the economic intent of government funding of EHR systems appears to be related to stimulating a big commercial industry in name of "innovation," but not in providing better healthcare.

However, like almost anyone I know except Dean, I have not had direct access to the major vendor EHR systems we criticize. I take it from the trusted observations of the many UX and system designers we have on the community. Still, it would be good to get another opinion on the non-adoption of open source HIT. Who has another view on this question?

• ▶ Reply

▶ Reply to Discussion