PREVENT SPAM! - Marathon Fundraising

I'm sending out the following e-mail to my friends and family on Monday.  

You can prevent this spam .. (I'm learning from Public Radio!) .. but only if you make a generous donation TODAY!

Don't put it off! .. 

-----------

Hi

Keeping this short for ya:

a) I'm running in a marathon in January. 

b) To raise cash for a good cause (LLS).

c) You have some cash you can spare.  I know you do - even just a little.  That's why I am sending you this email.

d) Click here to see my "make a donation" page .. or skip it and click here to skip the "info" page and make a donation of $4 for every mile I run.  Just $4.  Not much at all - right?     Thanks!

- Jacob   

P.S. Feel free to forward this email (or URL) to as many people as you like to encourage them to donate as well!


Oesh Running Shoe Review

Oesh (shoe spelled sideways and backwards) had gotten some good press lately.  I've read a handful of Casey Kerrigan's papers on gait and movement - so my interest was piqued when I learned that she and her husband had created a company to manufacture and sell shoes with a scientific basis - rather than a marketing/sales basis.

They started selling shoes about six months ago - but only in womens' sizes.  So I e-mailed them to ask when they would carry men's sizes, and Bob (Oesh CEO/husband) suggested that I could wear a women's size 11 since I am a dainty men's 9.5.  Yes - I am no sasquatch.

So I ordered them up and have done four runs with them in the past week.  Two short ~ 2 mile runs on pavement just to get the feel for them - then a long 15 miler - mostly on a dirt bike path over the weekend - and then about 6 miles on pavement and concrete sidewalk yesterday.

I did one 3 mile run in my Saucony Kinvara 2's two days ago.

First impressions:

  • BIG

These are not racing flats - or super light - or "minimalist" in any way. The upper is 60% leather and about 40% regular-shoe-upper-stuff (whatever that is .. nylon/dacron etc.) over padding.   The women's 11 weighs in at abuout 16 ounces dry - and much more when wet (one day was raining).  Leather loves water - as does padding - so this is not the shoe you want to wear in the rain (so I learned).  These shoes will last a very long time - and I don't doubt the company's claim that they could last 2000 miles.  There is no foam to wear out - so the only life-limiting factor will be the upper and the sole - both of which seem quite durable.

If we compare them to the Saucony Kinvara 2's - you can see that the Oesh is a more substantive shoe:

 

  • image from picasaweb.google.com
  • image from picasaweb.google.com
image from picasaweb.google.com
  • Comfortable. 

They feel good on the foot.  Soft inside - and - yes - the carbon fiber cantilever supports a very natural running or walking gait. I won't repeat all the theory behind the shoes here.  Go take a look at the website and get a quick overview of the rationale for these shoes.  Basic concepts:

  1. Impact is good.  Don't cushion the impact that happens when the foot hits the ground.
  2. Injuries happen at the point/time of maximal force - when the foot is bearing the most weight. Traditional running shoes try to reduce the force of impact with foam - so as the foor hits the ground - there is a softer landing, but a few fractions of a second later - when all of the body's weight is on this foot - the foam is now compressed - allowing rather little force to be absorbed by the shoe.

The goal is therefore to have a shoe that preserves impact forces (which theoretically build bone and muscle strength) and reduces maximal force - when the foot is bearing the most weight.    Minimalist runners will of course ask why we need to reduce ANY of this force - and I think there may be merit to such a question.  Casey Kerrigan has done a lot of research on where/when these forces occur, and what will maximize them - but I haven't seen research that demonstrates that it's better to absorb some of this force in a shoe.  Just as we need to critically questions some of the theories behind traditional shoes - it's appropriate for us to critically question some of the assumptions here as well - yes?

The method OESH uses is to put a cantilever made of carbon fiber into the sole of each shoe.  The cantilever is basically a v-shaped wedge - laid on its side - so the closed end is on the lateral (outside) edge of the shoe and the wider open end is on the medial (inner) side of the shoe.  This makes the medial edge of the sole entirely open - and I could see/feel (especially when walking) as the wedge compresses under my foot and then releases.  I didn't percieve a "spring" release - so I don't know that there is a claim that these return energy as newton does.

Here's a view of the open medial edge of the shoe.  I can put my fingers all the way in!

 

image from picasaweb.google.comimage from picasaweb.google.com image from picasaweb.google.com 

Rnning experience:

My first run - a slow ~ 2 mile test drive - was quite comfortable.  I've been wrestling with some left foot pain for the past 15 months on and off - and I was pleased to find that the run in these shoes didn't hurt at all.   Forefoot strike is easy - as they have no "drop" from heel to toe - and I found the impact noise to be a bit of a surprise.  I wonder if the neighbors thought that the Clydesdales were coming!  Clap/clap/clap/clap.  These are not the shoes to wear when you don't want anyone to know you're coming!

 As my foot makes impact with the ground - I found that the lateral inch or two of my foot was where most of the impact was felt.  Especially at the end of my 6 mile run (all on pavement and concrete) - the soles of both feet were a bit numb.  Not in a bad way - but imagine you've beel clapping your hands at a Red Sox game for a few hours - hard.  It's that sort of sensation - which isn't bad or even painful - but it's new - and likely due to the fact that the impact of footfall is preserved with these shoes.  It takes some getting used to and I found myself occasionally trying to "tiptoe" on occasion as one would do walking in the woods - trying not to make any noise - as if that would reduce the clap/clap/clap of impact with every stride.   But I kept reminding myself that impact is good - and to go with the flow - and as I stopped thinking about it - my stride got back to normal.

On my long (wet) run - the weight of these things was certainly noticeable - and when I put on my Kinvaras for a short run two days after the long run with Oesh - it was like I was running on air.  Bob (Oesh CEO/husband) suggested to me that I need to think of these things as trainers - certainly not to be worn to achieve my PR in some race - and he's spot on there.  

Like the heavier bat that little Dustin Pedroia  image from boston.sportsthenandnow.com swings in the "on deck" circle - these shoes will get you ready for walking up to the plate - and after four runs - I can say without hesitation that my nagging left foot injury is no worse - and perhaps a bit better - than it would have been had I been wearing the Kinvara 2's every day for the past week.  Last summer - I had a metatarsal fracture in my left foot - and in the context of these conversations - I think that it's entirely possible that my rotten running form had as much to do with the injury as anything else.  It's hard to get the hang of Forefoot running - especially if you've been running with a heel-strike for so long.  I went to a "chi running clinic" last Fall - and recall that even after the clinc - the teacher watched me run and said told be to stop running "on my toes."  This is a common mistake that new forefoot runners make - and it takes some practice to LIFT the foot - rather than PUSH OFF with the toes.  Since my left leg is about 3/8" shorter than my right leg (1974 injury) - I think that I am pushing off MORE with my left than my right in a subconscious effort to keep my pelvis even.  This puts too much force on the left metatarsals - and could have resulted in the fracture.  It hasn't felt quite right ever since.

The injury kept me sidelined for the 2010 marathon - but I am (so far) on track for this year's event - and I think that including the Oesh in my shoe rotation - especially on my long runs - will help me avoid injury.


Health IT Workforce Curriculum - initial impression

I've spent a number of hours today reviewing the ONC HIT Workforce Curriculum materials, and since I've seen many tweets referencing them .. I've seen little substantive narrative on their value - so I'll offer a bit here - with the caveat that this is the product of ~ 4 hours of review of only one component.  There is a mountain of material here - and while I had previously flipped through a handful of PowerPoints - today was the first time I sat down and listened to the presenters talk through each module from start to finish.  

It's an impressive set of work.  I was assigned component #12 (Quality Improvement) to review.  I can say with certainty that this isn't how I would have approached educating a group of HIT students on this topic.  Why not?

  • There is way too much detail.  Far too many trees - with only occasional views of the forest.  If I was a community college student - I wouldn't be able to digest or retain all of this detail - nor would I be able to distinguish between what's really important and what isn't.
  • Too acute-care focused.  There is far more emphasis on the challenges / opportunities / processes of acute care - with only occasional reference to outpatient care.   This is the opposite of what I would do.  Implementing HIT in mature settings (acute care facilities) is very different from outpatient settings - and small practices in particular.  Does an educated HIT worker really need to understand the Donabedian model or the SEIPS model?  No.  Never.  Call me anti-academic if you like (recall that I was an Associate Dean of Biomedical Informatics) but this material is just too deep for this audience.  
  • Disconnected from the roles that the learners are training for.  In many cases - speakers make reference to the "leadership roles" that the learners will play in health care organizations.  In the vast majority of cases - I can't imagine that the graduates of these training programs will become change agents or leaders in the organizations that hire them initially. This isn't to say that these folks aren't important (they are very important) or that they won't evolve into leaders in the years to come.  But this program isn't about training leaders - it's about training a group of  students to become familiar with this important field in order to fill a resource gap that exists in the "engine room" of the industry.  

    Again - I want to be very clear:  this is IMPORTANT work - but we shouldn't suggest that these folks will be "leading" HIT initiatives in the near term.  That's just not realistic.   The educational needs of this group are therefore quite different from the needs of undergraduate computer science students (HIT developers-to-be?) , MPH students (strategic guides to-be?), AMIA 10x10 students (CMIOs-to-be?), or Medical/Nursing informatics students (CMIO/CNIO/etc to-be?).  Alas, in many instances - I got the sense that I was listening to the re-purposed lectures of educators who had been teaching to these other groups, but failed to separate the most salient nuggets for this new type of trainee.

Way back in the "dark ages" (10 years ago) when I was a full-time educator, I worked hard to make sure that I deeply understood the needs of my learners before I launched into "covering" material for them.    I think that's a core problem here:  the faculty who developed these materials were developing them for an audience with whom they have had little interaction - and the reviewers of the materials (generally informatics experts) are looking at this from a perspective of completeness with respect to informatics education curricula that exist today.  At one point - one of the faculty mentions a book that he has written on the topic of patient safety: "as you may have read in my book on this topic .. "  Oh please.  Really?  Do you expect that these folks have read your book?  Unlikely.  Have I?  Well .. yes I have - and it's a good book.  But this isn't a forum for pitching a book.  I would suggest that this sort of narrative offers little value - and may actually detract from the curriculum.  It's easy to remove - and probably should be.

While I am certainly  looking for gaps (as I've been asked to do) - my overall sense so far is that the flaws are the opposite:  too much detail - and too much expertise - with too much of a focus on what the educator KNOWS - and too little focus in the foundational material that the learner must UNDERSTAND.  

Having said all of this - I need to be clear that I think these materials are a great resources - and a great foundation for a strong training program. 

 


"compliance"

This post on the-blog-that-used-to-be-kevin's-blog (alas, Kevin Pho writes rather few posts these days) ... is accurate, but I wish that the medical community was saying the same thing.  In general - we are not.  Patients who have guts will say this - but on the other side of the stethoscope - we continue to use such terms as "noncompliant" and "adherence" on a daily basis - and nobody recognizes how offensive it is.   I blogged about this in 2002.  Same story today.    This is a nomenclature is symptom of a problem - not the problem itself.  Care providers who have been taught to expect patients to "comply" are not learning the skills they will need to really help patients meet their treatment goals. 


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?  

 


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