Docnotes

Google Health Was a Dumb Idea Anyway ...

It's been nearly a week since the big announcement and I've read a herd of thoughtful reviews of why google decided to shutter their health experiment.

But I've not yet seen anyone say what was obvious from the outset:  It was a dumb idea.

Google Health is a classic case of a solution looking for a problem.

When we apply technology thoughtfully - we need to be solving a problem!  No problem = no adoption.  No adoption = no revenue.

Case in point:  Tim's got a survey up on histalk at the moment.  Who reads HISTalk?  Health IT disciples.  How many of us have PHRs?  13%.

If WE don't use them .. nobody will.  

Some think that "portals" will be the answer - and will succeed where PHRs have failed.

I wouldn't bet on it.   A portal may work in a setting like Group Health / Kaiser or Geisinger - but it's not likely to work in the real world.  Patients see too many physicians - go to too many care facilities and have changing relationships with all of the above.  EHR-tethered portals simply can't scale in a way that they would need to in order for patients to embrace one or another.   As a way to communicate with a practice or a hospital - fine - I'll use a portal instead of a phone.  But as a trusted place for my medical information to "live?"  No way.

So - if Google Health was a solution looking for a problem - what problems might we solve so that the next iteration of health 2.0 entrants aren't so confused.

1. The ubiquitous clipboard.  Many companies are focused on this end of the problem.  Digitally capture "new patient information" in the office or at home.  Portals, ipads, text messaging, telephony/IVR .. 
2. Data availability.  Raise your hand if you have been to a physician who didn't have your records.  It feels rotten on both ends.     When I visited Ecuador - I was impressed that the physicians didn't really have many records.  Who had the records?  THE PATIENTS!  Got labs done?  They're sent to YOU.  The patient brings a folder into the office.   Likewise - I visited Germany a few years ago.  The patient carries a smartcard that unlocks a data repository in the cloud.  Hand the smartcard to your doctor's office .. and they get your data.  No Smartcard?  No data.
3. Communication.  No secret that I'm working on this with my team @ Twistle.  No - we're not open for business yet.  But we're funded and working.  Stealth mode.  Stay tuned.  The problem we're solving is a self-evident one:  e-communication is more efficient than in-person and telephone interactions between care providers and between patients and care providers.  7% of physicians e-mail their patients.  Will this number increase - especially as reimbursement models change?  Of course it will.  But the current tools (Intuit, RelayHealth, etc) are klunky and use proprietary APIs.  The world needs a standards-based secure e-communication tool that is easy and fun.  
4. Information.  Perhaps we call this "clinical decision support" .. or perhaps we don't.  Patients and providers need to be participants in revolutions of process.  It's not rocket science.  Indeed - that's the whole point.  Many of the steps we can take to improve care (and as a byproduct - save money) are NOT intellectually challenging.  Rather - they challenge us to be deliberate, disciplined and evidence-based in how we manage care.   Take this fantastic paper (sorry - not free) in June's Health Affairs.  Intermountain Health focused FIRST on process changes that would enhance quality.  A byproduct was (significant) savings.  Example:  inductions of labor are common.  Decades of research has demonstrated that the evidence-based criteria for labor induction are not universally applied - and that induction is associated with many bad things:  longer hospital stays, more c-sections, more infection, more sick moms, more sick babies.  So if a process is instituted that requires providers to follow a specific protocol (or make a call to get special permission) the rate of inappropriate induction can be reduced from roughly one in four deliveries to one in fifty!  The authors say:  
   
   "We estimate that the Intermountain elective induction protocol reduces health care costs in Utah by about $50 million per year. If applied nationally, it would lower health care delivery costs by about $3.5 billion annually."  
   
   Wow.  Read the paper. It's a great summary of how Health IT enables this sort of endeavor.  They couldn't have done this without clinical systems, analytics, and CPOE.

So let's focus on some real problems ...  and stop worrying about why Google killed a little beta project before it came to market.

 

 

Health IT Tweeting & Blogging

I've been blogging for a very long time.  Tweeting since before Twitter had an "e" .. (it was called twittr) .. Blogging since Blogger was just a little feature of a long-dead product called Pyra.  Raise your hand if you remember Pyra. Ok ..you get 10 extra nerd points today!

That doesn't make me an expert - but it does give me a perspective on the whole thing that may be .. umm .. mature.  

• When we started (~ 1999) - blogging was not about self-promotion or exhibitionism (as some seem to think it is ) - it was about education and transparency.  In Health Care - there were a handful of us - no more than ten people - blogging about how we experience life in this fascinating profession.
• When we started (2006) - tweeting wasn't about self-promotion or exhibitionism (as some seem to think it is) - it was about efficiently informing colleagues about something that may be important to them.  

I was on a conference call the other day and I was surprised when a colleage made a remark about tweeting as somehow inherently exhibitionistic.  I've heard this before from people I respect - and didn't give it much thought.  That's not how I view tweeting ...  so I've mistakenly lumbered away with my anachronistic (naive?) view of tweeting to simply be an efficient way of educating ("FYI - there is important news"), modeling ("I'm thinking about a topic in a certain way you may find valuable") or (less often) informing (" I ran 15 miles today").    And I understand how others may view it as something with less value and less integrity - but they are only seeing the treetops.  There is depth to Blogging and tweeting that remains at its core - valuable and important.  You just have to know where to look.

I'm not a prolific "tweeter" or "blogger" these days - but when I do post - I generally try to make it something that would be of value to others.  I don't say much that's already "out there" and I avoid "re-tweeting" unless it's something that is outside of my domain.  For example - since most of my followers work in health care and Health IT - I try not "re-tweet" something to that "circle"  - as it would just be redundant to them.   For example - I tweeted on Friday that Google Health was closing .. as it was breaking news at the time that I saw it .. but I never tweeted that ONC was releasing (great) ediucational materials on HIT because it's been tweeted hundreds of times since last Wednesday when they were released.  How would this tweet add value to the world?  Precious little.

So blogging or tweeting for the sake of blogging or tweeting IS a waste of everyone's time.   Yet careful, deliberate use of these powerful tools will contibute meaningully toward the education of our communities.  

 

Inbox Management: The Healthcare Version

Mitch Joel's posting: "5 Ways to survive your inbox" describes a set of habits one might use to maintain control:

1. Create folders. 
2. Create rules. 
3. Get it done. 
4. Create a hierarchy of response. 
5. Tell people - in your emails - how to work better with you. 

See his post for the details and editorial.  None of this is a new idea - though I like the way he describes #5 quite a bit - and will admit that I have used this tactic myself. 

But why should we work so hard to apply these principles?  Shouldn't the software facilitate this work?  As care providers - isn't it ESSENTIAL that the software do this FOR us?  One shouldn't have to think like an IT expert.  Mitch describes a set of technical tasks.  Let's change the terms a bit - and consider this from the perspective of a care provider interacting with patients electronically.

What it might look like:

1. Create folders. Categorize.  "Folders" are old-school.  We don't need legacy metaphors that evoke images of manila folders into which we throw 8.5 x 11" documents.  We need to categorize messages so that we can see patterns, find "like" messages together, or look at things together.  For example - I may want to see every time that Mrs Smith and I have discussed her sore knee.  I may want to look at all of my conversations with Dr Jones.  I shouldn't have to deliberately create these categories.  The SYSTEM should.  And the system should automagically categorize every message properly.  Is that too much to ask?  I don't think so.
2. Create rules. Prioritize.  Stuff that's important needs to get dealt with right away.  Less important stuff can be done later.  How does Google know what search results to show us first?  Did I create a rule for that?  Of course not.  While rules exist - they are transparent to me.  Google learned from my actions what content is important to me and what is not.  With a clinical messaging system - the same should happen.  The system should learn what's important and what is not so important.  I can then focus on the important messages now ("Mr Smith's INR is 4.5") and the less important ones later ("The fridge in the break room will be cleaned tomorrow.")
3. Get it done. I'll keep this one as-is.  "If you can get it done in 60 seconds or less, do it right away."  Have you tried the e-mail Game?  If not - you should.  It's good.  And it's a good example of a "focus" mode that one could employ to power through 80% of a clinical inbox in 8 minutes or less.
4. Create a hierarchy of response.   I think this one's redundant of #2 above.  Prioritize.  Not just content but people.  Stuff from some people is generally more important than stuff from some other people.  The system should learn that - and prioritize the messages accordingly.  Hooray - Five rules is now FOUR rules!  We've reduced the cognitive load by 50% already.  :-)
5. Tell people - in your emails - how to work better with you.  Facilitate Best Practices.  Process is important, and wherever possible - the system should understand "lean" processes that have been well defined - and should facilitate them.  This might mean that there are limitations of the system that enforce these processes.  For example - it's probably clinically inappropriate for a message with an important clinical question or task to be sent to more than one person.  Have you ever received a "please do this" e-mail that is addressed to seven people?  No surprise that everyone thought the other six would take care of the task - and it never gets done.  So while a clinical messaging system may be technically capable of sending a task to seven people - the system design should not allow it - since it's not consistent with best practice.  ONE "target" should be required for all such messages.  Even if that "target" person is permitted to re-assign the task.

Now it's audience participation time!  What OTHER suggestions do you have for Clinical Inbox Management?  

 

Inbox Management: The Healthcare Version

oops - duplicate post.  See previous post or click here.

Usability of EHRs Meeting at NIST

I'm here in Gaithersburg Maryland today at NIST - where the clocks are always accurate.

The context is a "Community Building Workshop" on usability of Electronic Health Records.

Longtime Docnotes readers know that I've been thinking/writing/talking about this for a long time.  Most recently - I testified (pdf) to the HIT Policy Committee's Implementation Workgroup on this topic.  

It's impressive that this has come to be a compelling topic for discussion - but there remains quite a bit fo work to do.

Notes from today's meeting:

Jodi Daniel from ONC gave a nice little intro on ONC's rationale for being involved here.  Bottom line:  

1. As usability of EHRs improves - so does adoption and the effectiveness of EHRs in the delivery of value to the nation in the form of improved efficiency and quality. 
2. Let's work together to find the right solutions
   
   Jodi is super smart.  I'm alwasy impressed with her contributions to such conversations.  She is a listener and a learner - and I always know that she is thoughtfully incorporating what she hears into the policies that eventually make their way out of ONC.  Goot to hear her make the intro from ONC and it's good to see her so engaged.
   
   

Matt Quinn gave a good intro from NIST.  What NIST is - why NIST is engaged - and what is NISTs role in this work.  Like Jodi - I've grown to know and respect Matt of the the past few years.  His pitch:

David Brick, a cardiologist from NYC gave a well-intoentioned talk on some problems he's onserved in EHRs.  He provided examples of how EHR-derived growth charts can cause both displeasure and safety problems.  David's keystone example was a system in which a 5.5 POUND patient's data could be expressed as 5.5 KILOGRAMS when a user toggles between Metric and English systems.  While I agree there is a usability issue here - his  example is a bit of a straw man.  As one considers the continuum of user experience from functional - through usable - to meaningful - this example isn't even functional.  It's flawed deign - or falwed implementation.  Period.  It's a bug that needs to be fixed.

So while one might argue that this is ALSO a usability issue - we need to be careful not to lower the bar so much that such examples become part of the usability conversation.   Would user-centered design have prevented this flaw?  Sure .. but I would suggests that we need to assume or even demand functionality in this conversation - and sink our teeth into usability -  the next hurdle that the industry needs to jump.

Ben Shneiderman from University of Maryland up next.

    Ben is a dynamic and outspoken speaker on these topics.  

He describes the industry leading works of several vendors such as Apple.  I recall the early Apple usability guidelines well - and Ben makes a good point that design guidance is a good thing.    But should an industry have design requirements?  He doesn't go so far as to say that - but he actually comes rather close.

Ben makes a set of suggestions:

•     EHR developers should publish a set of EHR usability guidelines
•     EHR developers should permit examination & discussion of products their products by researchers
•     EHR developers should report on usability study results - so that others can understand strengths and weaknesses of these products and design teams.
•     EHR developers should promote consistency with industry-led common user inerface guidleines
•     EHR developers should report failures periodically with common metrics
•     EHR developers should work with government agencies to coordiate sspceficif industry practices ..

Ben expressed frustration that vendors have not shared with him any examples, access to demonstration systems without signing NDA, access to documentation, or even details screenshots of EHRs.

Ben is a passionate and articulate guy - and his heart is clearly in the right place - but it's simply not all so simple as he portrays - and I would argue that the vendor community may not be so cooperative with him as he would like - because his demeanor is combative rather than collaborative.  How can one trust that a collaboration with Ben won't turn into a marketing tragedy?

Next up ... 

Mohammed Walji - SHARP-C

SHARP-C is an ONC-sponsored grant program @ UT - Houston.  I was an advisor for the project for a while - and I find it to be incredibly interesting - yet somewhat academic and therefore not quite ready to inform the industry.  Yet.  Perhaps they will at some point and that will be valuable indeed.

Mohammed outlined a general approach that their team is taking to usability:

TURF framework for usability:

1. Task
2. User Representation
3. Function

 

 

Facets of usability:

1. Useful - Satisfying - Usable
2. Intrinsic complexity ==> Usefulness
3. Extrinisc complexity ==> Usableness

 --

Arien Malec from ONC - descibes the successful method that government and industry worked togethersuggests that a process here enables us to:

Raise objections and concerns early in the process

Ensure the resulting usability test approach supports multiple modalities (eg dicataion)

Learn from each other and creat UX and design best practice that create superior usability and UX

Concern:

Measurement may not capture the nuances of heatlhcare

Reply: Help us define the instrucments and measurements and methodilogies

ONC suggests that the community can help define the workflow and context - sensitive tests

 "vendor community says: don't let he government tell us what is good or bad - we want the market to tell us what is good or bad"

Users "we don't want the govt to incent us to use stinky software"

Community - not ONC - can define what this is - through the (proposed) Marketing Usability Workgroup

1. Share end-user and vendor concenrs
2. Define emchanisms to endusre an deffieicne and wwell dunctioning marked
3. Supply relevant and accurate information to end users
4. Reward excellence in ux
5. Spur innovation

Workgroups comprised of:

- academic researchers

- vendors

- Users / Implementers

- Government

- Human Factors professionals

Edna Boone - HIMSS

Speaking about advantages of professional collaboration community.  Good dovetail with Arien's talk.

Usability industry - Human Factors, Design and Usability people .. 

Proposal:  A community of profession led by HIMSS Usability Taskforce - responsible for providing domain experttiese, leadership and guidance to activities, inittiateas and collaboration within the speciality of HF, usability and design ..  

Ron Kaye - FDA devices human factors guy - here to describe how FDA manages human factors issues in the medical device arena.

 

Jorge Ferrer - VA

Jorge provided an interesting literature review on recent papers that have been published in the domain of usability - and focused on a usability framwork developed at the VA - with a (too long to for me to trascribe) list of recommendations for "next steps" in usability in HIT.

 Janet Campbell - Epic

"What are the needs of software developers?"  

Usability is a journey rather than a destination.

We are not (nor will we ever be) perfect.

"Our users are smart people.  Physicians have hig standards and low tolerance for dysfunctional design."

What do providers need?

1. Safety 
2. Empowerment - customization of a user experience FOR ME
3. Adapt systems to changes or external requirelents.  Systems need to be flexible and adaptable.
4. Disabilities should be understood and anticipated (accomodate poor vision or bad mouse skills, etc).

Dialogue between user and vendor is fluid and useful.  When a third party gets involved in the conversation - it make it more complex - and sometimes the messages get less clear.  

Concern about measurement, guidelines, standards .. measuring things that are un-measureable .. or comparing systems to some sort of idealized design.  There exists a public-private partnership that is working.  There is an unspoken message here that the industry has failed.  In fact - it has not.  Is the government barking up the wrong tree?  Aiming to solve a problem that isn't in its scope to solve?  A government assessment may send the message that a certain design standard will meet the needs of all users.

We think there is a role for ONC and NIST - let's look at the common requirements - as defined by Meaningful Use - to see how we can optimize THESE processes.

 Mary Kate Foley.  VP for User Experience at athenaHealth.

Educate, Motivate, Improve.

Mary Kate describes the challenges of implementing UCD principles in an organization that previously didn't use them.

Observations:

    EHRs lag in usability

        Inhibits adoption

        Inhibits productivity

        Contributes to clinical risk

AHRQ report on EHR vendor practices and perspectives

Market factors will exert appropriate pressure 

Can we anticipate and acellerate?

Apply our UCD principles to the problem - how can we do more UCD @ EHR vendors?

    Understand the problem.  Complex needs, complex user bases.

    Focus on the target audience

        Usability maturity:  

1. Low (don't know what they don't know - no champion but may be skeptcs .. and misguided enthusiasts)
2. Medium ( a few practitioners - org still learning - many skeptics .. still some misguided enthusiasm)
3. High (ux recognized as a llever for business performance.  experienced dedicated ux people. team .. integrated with RND) .. Employ reliable UCD patterns.

Design with tartget in mind

Low - Educate

Medium Educate & Motivate

High - Motivate.

Get each vendor started where traction is likely to be greatest within vendors:  usabilty TESTING .. 

  -- 

Lyle Berkowitz

 
Shows the usability periodic table from HIMSS (see page 3 of this document)

Practice guidance:

• Engage your users from the start (not just  the physician geek).
• Consider the practice goals
• include ux questions in your RFP
• Perform usability tests when evaluating new software
• Observe other practices using the products
• Discuss findings with the vendors

--
Work has units .. Clicks .. Time .. Eergy. Effort, frustration, failure .. 

 

Lana Lowry - NIST

Bob Schumacher, User Centric

Emily Patterson, Ohio State

Bob North, Human Centered Strategies

Chris Gibbons, Johns Hopkins

 (editorial:  I like Lana - I think she is a bright, passionate advocate for doing things right.  Her slide deck, however, was the worst of the day.  It violated nearly every principle of a "usable" presentation.  She needs a copy of Presentation Zen.  I think I'll buy her a copy.  No kdding.

Lana's presentation was the first of a few sessions that got to the meat of why we were all here.  All of the previous sessions were (I think) meant to set a level playing field and make sure that the audience was all on the same page (what is the definition of usability, etc) and had been exposed to various perspectives on the matter - HF experts, government folks, vendors, etc.  In general - this worked - but it could have been done much more effiiciently.  We could have had 2 hrs of intro rather than four - and I would have preferred to spend much more time on the "meat" of the matter rather than just a few quick presentations in the afternoon.

Proposed EHR Usability Evaluation Protocol 

These presentation (I'll post later today in more detail about them) focused on the EUP and what it is.  Key message:

a) EHRs should be tested by people with advanced training in usability, human factors, cognitive science.

b) The focus should be on testing for errors.  The key here is patient safety

c) There will be a collaborative community effort that is created to define the details