Skip to content Skip to navigation

Adopting The Obvious, Part 1

August 13, 2010
by Joe Bormel
| Reprints

Adopting The Obvious , Part 1

Shortening the Gap from Awareness, Jokes, and Threats to Common Use of Emerging Technologies Link to Part 2

Graphic display which summarizes all relevant traffic congestion for Washington DC

Of course, I need to travel over the red segment (lots of slow traffic) in the upper left hand area.


A decade ago, I would leave my home for work, hop in my car, turn my radio on to the news channel with traffic, and begin a morning juggling act. At eight minutes after the hour and every ten minutes thereafter, Lisa Baden, the traffic reporter would speak for 60 seconds. When Lisa began, I was supposed to give her my complete audio attention. Systematically, from worst delays to minor delays, Lisa would talk thru the up-to-the-moment, prioritized incident list. She would recommend detours, lane choices or patience. And, she would try to make it human, conversational, humorous, or compassionate. I was grateful for the help. It was so much better than driving blind.


 

What I really want is an instant display showing this

Fast forward to 2010. Smart phones and dedicated GPS units give substantially similar information. They listen and juggle. I do not. They sort out the incidents, not in terms of severity to the broadcast area, but in terms of my location and my route. The information does not come to me in an interruptive audio stream I must decode by street names (many of which I will never travel in my entire life). It comes visually, color coded, on a map, zoomed in to my preference, be it three blocks or ten miles. It's in real time, i.e. no waiting. The GPS traffic information is ad sponsored, no added cost, just like the radio.
 

If there is a problem, give me a solution if you can .
... show me in text and graphically, and give me an actionable option, in a clean, usable, context-aware display. Depicted here as the "Avoid" button.

Information access is better and more relevant.

The GPS+traffic workflow scenario produced dramatic improvements in usability and task speed. The same pattern has emerged over the last decade with electronic communication. Phones now routinely integrate e-mail/calendar/contact systems like Exchange, Gmail and MobileMe. These phone+messaging/calendaring solutions now support dramatic improvements in usability and task speed as well. On the PC and related tablet platforms, the same kinds of usability and task speed improvements are surfacing.

Here is my point. The choice of devices determines the potential usability of a solution. The resulting supported workflows can make the old world obviously obsolete. Based on what I'm seeing and hearing in the industry, this device evolution and relationship to usability and task speed perspective is being slowly recognized, if at all, by some very important decision makers.



Bloomberg Businesweek covered an analysis by Forrester Research's Ted Schadler on emerging devices, including Smartphones, tablets and their associated wireless connectivity. There's a lot of coverage of this issue as the sales volume of tablets (including the iPad) and Smartphones simply amaze and defy forecasts. One podcast titled, "Bringing iPads to Work - Should CIOs Ban Them?" does a nice job of summarizing the situation. The presenter concluded that the rate of adoption by professions is unprecedented and a locked-down policy approach to one’s user community, previously very wise, is no longer a viable approach.



Pages

Topics

Comments

Jennifer, Thanks for your comment. I strongly agree with the customization need you highlight. Two huge implications of that are that a system needs to be customizable, and and organization needs to plan for go-live to be the beginning (and not the end) of a usage or adoption project and program.

In this era of MU, there is an increasing perception (and therefore reality) that go-live needs to start a timer denoting attainment of MU performance measures. That often translates, unfortunately, into telling end users that we're done customizing at time of go-live. We need to move on to bringing up the next thing. That's often perceived as an incredible slight, insult, or otherwise demeaning act on end-users who may truly need some degree of customization, after go-live.  This is an old problem in HCIT.  With ARRA-driven time crunches, it's a risk for being a much bigger new problem as well.

Joe,
I like the analogy you used and would take it the next step.

Voice activate you navigation system in the vehicle, tell it where you are going and it automatically plots the most efficient course taking into consideration any construction, traffic activity, including accidents and even weather conditions.

Translate that into the medical record and I will give you a simple case from my practice.


A woman comes in complaining of palpitations. Examination reveals an elevated pulse but otherwise normal exam. EKG shows mild sinus tachycardia but otherwise normal. Her past history is unremarkable. There is a strong family history of thyroid disease.

I check routine lab including TSH and sure enough, she has a very low TSH. Now I have to send her back for a free T3 and Free T4 as well as thyroid antibodies.

When those results are back I will have to order an I 123 uptake and scan to differentiate between painless thyroiditis and Grave's Disease.

My suspicion is painful thyroiditis because her thyroid gland was normal to examination.

Now imagine that the EMR was tabulating the clinical information while I was entering it and was able to perform a formal Bayes calculation and determined that based on the results of the free T3 and T4 and the normal thyroid exam that I could bypass the scan and just treat with beta blocker and tincture of time.

Imagine also that the EMR advised a followup schedule for the TSH and automatically arranged the scheduling.


Wouldn't that be cool!

Great post Joe! You make a very good point about streamlining workflows for increasing clinician usability. And just like TomTom (or any of the GPS devices out there) has options for changing the voice of the person giving you directions (you can have Arnold Schwarzenegger or Yoda gudie you to the nearest Piggly Wiggly), clinicians need to be able to customize their clinical information dashboard to make it more usable for them. Some docs might want to see different information on first glance than others-just like some mornings you might want a lady with a French accent giving you directions.

Thanks Jack. That is clear and does answer my question.

Your response took me by surprise. Humbled by the amount of design, redesign, transformation, and metadesign implicit in HCIT, I'm currently reading another fascinating book by Richard Farson: The Power of Design: A Force for Transforming Everything.  ( I first blogged about an earlier Farson book, two years ago, here.  It's a book about the paradoxes in management and leadership, which, if not understood, will simply lead most people to futile frustration.)


Farson makes a number of observations and distinctions in the book. One such distinction is between Training and Education. One of the elements is that you train standardized skills. To goal is consistency (the opposite of customization), and, by design, blind to the talents and perspectives brought by the learner. Education, as you described it is comparable to Farson. Each student is unique. Assessing and grading education can be very counter productive.

Another point that Farson makes that relates to this post, "Adopting the Obvious", is that the obvious or current state is often quite invisible to those of us living in that state.  This resonated with me, especially considering that for many important operational measures, organizations planning for HCIT purchases (like EMRs) don't have very good current state data (activity costs, performance data, etc.)  In short, the obvious, isn't.
 
There's no shame intended.  It's part of the human condition for us to not see the common background.  The fish is the last to know when the fish bowl has run out of water!  I hope to pick this theme up in a future post. 

Joe,
Very well done post. I'm looking forward to the follow-on piece.

The comments you and Jennifer posted have led me to ask three questions. The first concerns when user education should begin concerning customizing information dashboards. I take it that you recommend this process should begin well ahead of a go live. Is that correct? And whenever this begins, shouldn't the process include certain limitations to ensure that clinicians can't overdo customization to the point where it adversely affects MU?

Also, the end of your comment to Jennifer is a little ominous. Does it mean that you think the MU deadlines should be extended, and if so, how far out do you think they need to move?

Jack

Thanks for the kind words, Jack. And, great questions in return!

The issue of when design should begin is a great question to ask. It depends on the project charter, not the program charter. The project charter, as I understand it from PMI perspective, needs to be specific about the five Ws (who, what, when, where, and why) of the goals.

It the hospitalists are going first (often the plan), then the design for the hospitalists should be announced and initiated at the project kick-off.

Regarding your question on deadlines, extension is not an option. Revising scope and resource commitment plans is not only an option, it's a necessity, on an on-going basis. This principle underlies Agile with Scrum, and the PDCA quality improvement model. Learning is a continual process that feeds on itself. Framing one's management responsibilities in terms of deadline extension misses an important point repeatedly made by the ONC. MU is part of a much bigger process to improve care and care delivery it includes and is synergized by ACO and Home. Both of those are linked with payment reform that requires better information management, beyond the scope of a service (like an encounter.) HITECH is an important enabler with immediate benefits. It's not something that will pass into obscurity after phase 3 in 2015. Already, the very tangible benefit of sanctified standards has resulted, as elaborated in the Final Rule last month.

I think I got that right. I'd appreciate comments from those following the MU process more closely.

Jack, I found it fascinating that you used the term User Education instead of User Training. Accidental or deliberate? and if deliberate, what's the difference from your perspective?


Joseph,
Thanks for your kind words and extending the theme. I especially appreciate both your taking the time to comment, and, providing a concrete, clinical example. All too often, people talk past each other (don't truly understand what the other is saying) when the critical step of providing an exemplary use case is omitted. I also love the fact that you framed the opportunities for improvement as an exercise in imagination. Very nice!

I have several reactions that I'd like to share beyond that.

1) All clinical vendors that I'm aware of have the ability to embed exactly that clinical decision support (CDS) into their currently shipping (pre-certification) systems. The fact that there are probably zero implementations of the CDS you described reflects the state of Kitchen, not the imagination of the Chefs.

MU will move us in the right direction, with the requirement of an up-to-date, codified problem list. That underlies the trigger, i.e. differentiating thyroid disease. How many problem lists today (where they exist on paper) simply say Thyroid Disease, rather than establishing the type or, in your example, "tachycardia" and "low TSH." As painfully small a step as it may seem, driving problem lists into general and effective use is a pre-requisite work in progress. That's embedded in that is the larger issue of workflow changes (and their usability) with respect to the work you described in your example.

The slowness of industry progress is not painless. Said differently, passion is usually somewhat painful.  I'm sure that more than one reader will experience some lament from this discussion.

2) The second idea of using Bayesian probabilities, i.e. the likelihood of this given that, is logical and consistent with our training. More likely, using Bayesian belief networks (BBN) would deliver a more powerful result. They have been used to do similar classifications to the one your described, they can learn, often with less experience than a traditional trial's worth of data, and can capture truth in care settings more effectively than many other techniques.  In the graphic example here (use Control key combined with plus key to zoom in if necessary, and Control/minus to zoom back out), the clinical inputs for patient presenting with some degree of Chest Pain, Dyspnea, Cough, etc are shown on the bottom row.  The differential diagnosis is shown in the top row, including PE, Bronchitis, Pneumonia, etc.  By putting in various values (automatically possible when electronically documented), a Bayesian Belief Network can show the resulting probabilities for competing possible diagnoses.  This is a standard example from a tool called Netica.  If you're interested, I'd recommend the AMIA tutorial on BBNs.  I'm happy to provide more details, either here or privately.

The bottom line though, for both observations, is the need for capture of adequate coded clinical data, throughout an encounter note.  ICD-9 and 10, unfortunately, often don't discriminate well enough.  Again, this upgrading the Kitchen is a pre-requisite.

Thanks again for your insightful comment.  I'm thrilled that we still have clinicians like you to ensure high quality care, while we work through evolving these nascent technologies.

Joe,
I appreciate your detailed reply to my questions. To be honest, I do think that the MU deadlines are based more upon political expediency than reality, particularly when considering the challenges faced by many smaller community and rural facilities.

Now to answer your question, my reference was deliberate. I view "User Training" as an evolution in which, for example, certified coders are trained in ICD-10 contract admin personnel are trained to assist with a MPI clean up or finance staffers are trained to use a new RCM system. In each case, the "why" is quite simple. It is the "how" that becomes the primary focus.

"User Education," to me, is a very different paradigm. Here we deal with sophisticated, usually complex, multi-level systems and processes. For instance, systems that provide critical information from multiple sources for clinical decision support. But the presentation of that information can be customized by individual clinicians to fit their unique needs and/or preferences.

However, customization can also bring unintended, potentially deadly consequences that may undermine the potential of HCIT, quality care, patient safety and even a hospital's financial viability. Therefore, while the "how" remains important, the "why" of the system or process is critical. All parties involved in the educational evolution must maintain high level bidirectional communication, because the nature of these systems or processes can significantly increase risk, while allowing any number of subjective actions on the part of their users. UT isn't rocket science. UE can be that and more.

I hope this answers your question.

Jack

Pages

Joe Bormel

Healthcare IT Consutant

Joe Bormel

@jbormel

...