Docnotes

12 years of blogging .. about medicine, technology and their intersection ...

This post from November 26th, 1999 - was the first on this blog.  There were a few months of previous posts, but due to several platform changes back then - these seem to be lost.  

No matter.  12 years is a long time.  My blog is now officially an adolescent.  I wonder what it will be when it grows up!  Long-time readers are of course observant that I've been remarkably quiet for the past few years.  This is due to my evolving work for an HIT vendor and now the Federal Government.  

So I've been operating with this in the background for the past six years:

The opinions expressed on this blog are my own and do not represent the veiws of my employer.

And there is a rough "social media policy" (google docs - you have edit rights .. feel free to steal or enhance ... ) that I have in my head as well .. so in general I have done my best to observe and occasionally point to important publicly available information, but take care not to comment too deeply - for fear that others would interpret my commentary as a telegraph of my employer's next steps.  This wouldn't be appropriate for me to share - and increasingly - I am concerned that most of my public thoughts could be interpreted in this way - so I've been holding back from any public commentary.

So for now - here we are. 

I'll push the envelope a teensy bit and comment on some events of the past few months:

Tim HISTalk covered my arrival at ONC in a post about a month ago.    He asked the right questions about the topic at hand - but he didn't get to the one that I am hearing often these days - which is .. "Why did you leave your leadership role at one of the top health IT companies, choose to spend weekdays away from your family, AND (with two kids in college) take a giant pay cut?"  

The answer is easy:   It's the right thing to do.  

Health Care in the United States  is at a turning point.  It is well known that despite great advances - we don't provide the quality of care that we would.   It is also self-evident (to me) that technology - carefully applied - will improve both the quality of care - and the efficiency, sensitivity, and ease with which it is delivered.  Yes - some of those words may not be familiar to you - but why WOULDN'T we want it to be EASY to deliver great care?  Why shouldn't we deliver SENSITIVE care (sensitive to your hopes, religion, fears, preferences) - in addition to efficient, evidence-based and (of course) cost effective) care?

 So I have always tried to focus my work on helping others meet their true potential.   In my first career - as a 16 year old sailing teacher, I helped kids find the freedom and autonomy that a good breeze and a sunfish will provide.   As a teacher of junior high school kids - I witnessed breathtaking intellectual growth in a herd of 12 year olds who were otherwise distracted by adolescence and its daily challenges.  Working with (some say "caring for") patients as a family physician - I found that my most important work was not to take control and "fix" my patients (as some of my mentors had advised in medical school) but to partner with my patients - serving as a resource - without any judgment or critique.  As Bill Miller and James Prochaska have demonstrated (motivational interviewing, transtheoretical model) - people change when they choose to - and no sooner.  Can we facilitate growth in others?  Of course we can.  But "facilitate" and "cause" are inherently different.

As a leader in a large health IT software company - my role was often to help our teams align the software products we were producing with the needs of our customers.  This is not unlike the role of a good physician:  we need to listen carefully and critically so that we understand the needs (which will sometimes differ from the "wants") so that we can facilitate success.

And isn't that the role of government too?   Perhaps that's a political question.  Some would argue that government should get out of the way, while others would argue that there is an important role for government to provide an infrastructure with which success can be facilitated.  Is a healthy happy nation something that is important?  Are there ways that government can facilitate a migration toward these goals? 

I think so.  Keep an eye on my occasional tweets , g+ posts (rss), and posts here on this blog.  It will continue to be sparse here on the blog. 

Usability again ;-)

Anticlue responded to my post from yesterday and missed my arguement entirely, while stepping back and lecturing me on what to do.

Here's my response.  For the readers who don't know ... Elyse and I are colleagues, and I have a great deal of respect for her ... which is why I'll let loose a bit here ... all in the interests of continuing a good debate between friends .. ;-)

Elyse, you make some good points .. but by working so hard to figure out what was wrong with what I was saying .. you miss the forest for the trees, and don't seem to acknowledge the importance of the concept that that I was discussing - that usability is important.  

1) Asking if usability was in the RFP is insulting .. and misses the point that I was talking about most point-of-care products .. not one in particular.   The argument that I have consistently made is that usability is the "bullet point" most often ignored on functional matrices ... and due to its subjectivity ... most vendors can wave their hands about how easy a product is to use .. but it's not.  Measuring how long it takes to do a lookup (patient, dx code, medication, procedure code, allergy) is one way to measure usability, since these lookups occur many times during a given provider/computer interaction.  How many keystrokes or mouse-clicks does it take to accomplish a given task?  Do you argue that it is better to accomplish something with more rather than fewer actions?  I don't see how this would make something safer - as you imply.

2) Replicating the functionality that google demonstrates (BTW - they are using XMLHttpRequest) can be done in many ways   .. and of course no one is going to load a full MPI for a large healthcare organization into the browser.  This would  be dumb, as you suggest .. and would likely be a security risk if any application were to be used through a browser remotely. (BTW - Dave points out that it's only one part of our app that loads it all .. the others re-poll the database with evey keystroke, like XMLHttpRequest).   But you CAN check in with the database and maintain a responsive user interface with every keystroke.  This is what Google demonstrates.  If they're doing it with a HUGE database (the Internet) .. and many more users than the typical healthcare organization would have at any given moment .. you can be certain that such functionality could be replicated on a smaller scale for a  healthcare application. 

Hundreds or even thousands of users is a tiny load compared to the load that Google's servers endure .. and recall that I was not only talking about patient lists.  When I use epocrates on my PDA to look up a medication, I can type the 1st few letters of a medication to find it.  This is good design.  Are you arguing that it would be better to have a 1980's style screen where I type in the medication name .. click "search" and then get back what I was searching for? (or not).  Your point about misspellings also misses the mark.  Indeed, it's the instant feedback that will REDUCE the likelihood of finding the wrong diagnosis, CPT code or patient name ... not enhance it.  Let's take the example of your last name.  Let's say I don't recall whether it's IE or EI or EE or I or EA.  So I type N (space) Ely.  Done.  I found you. Now with a "old method" search: Type Neelsen, Elyse .. hit return .. find nothing.  Back to the search screen.  Nealsen .. nope .. back to search .. etc etc.  Giving the user feedback about what's in the black hole of the database is better.. not  worse.  Vendors are beginning to take advantage of this .. with windows tools .. and XMLHttpRequest .. which is good.  I applaud the use of such techniques, and I hope to see more of it in healthcare applications, as I would predict we will - so that we can focus more of our time on patient care .. and less of our time on typing and clicking and (in the age of The Tablet PC) .. pen-tapping.  I don't think I need to put this in an RFP .. or even build consensus for this concept.  It's a given.

3) Your suggestions about my making a list of issues for my practice organization, and your comment about working WITH the vendor (do you imply that I would work AGAINST them?) are again puzzling  ... and I fear that you are making statements on your weblog about what you know (or think that you  know) about what I am doing for that organization ... which is well beyond the scope of my post.  While it is true that I have been vocal about my concerns about the usability of a product in the past ... I remain a passionate advocate for the user AND the vendor.   If we can't work together, there is no way for the product to meet the needs of the user.</rant>

On a lighter note ...

I'll finish with a quiz about usability - posed by one of my heroes (who has a three-letter name that rhymes with DOG) .. and challenge my readers to go find the answer.

Which takes less time?

a) Heating water in a microwave for one minute and ten seconds.

b) Heating water in a microwave for one minute and eleven seconds.

I'll post the answer tomorrow if no one figures this out.

Google = Usabilty, Medical Software != Usability

Google Suggest is a new implementation of google that takes the search screen to the next logical step. 

When Dave and I built the "mini-EMR"  for our practice three years ago - the search screen worked like this too.  Gmail works like this .. and it's silly that all search fields don't.  If google can do this with the whole Internet - there i sno reason that someone can't do it with their database.

That am I talkin about?  Autocomplete/autoselect.

Follow the link above and you'll see what I mean.  Type the 1st few letters of what you're looking for .. and you get feedback about what's available. This makes your data entry task easier.

Now contrast that with the traditional seach screen.  Programmers - stuck in the 1980's .. when there was 128k of RAM on the client ... create a search process like this: 

Type in what you are looking for
Click "submit" or "search"
Wait
Wait more
Now see a screen that lists theresults.  If you searched for "Smith" in the phone book - you have too much info so you have to do it all over again.  If you searched for "Smitj" because you can't type very well, you get nothing and you have to do it again. 


"Oh stop whining ... this doesn't add minutes to the process .. only seconds"  you say

But if I do this 50 times a day ... it may add minutes .. and if I do it 200 times a day ... it adds many many minutes.

What's better? 

To implement what Google's done, you can apply one of two strategies:
a) maintain a connection to the database/server.  On every keypress .. send the data back to the server .. and get back the results .. showing the top handful of results.  As the user keeps typing, the number of entries that meet the search critereia gets smaller .. and the item they are searching for is found.  No "back-and-forth" to the server for the user.  This is not very hard to do anymore - and there are methods for doing this with javascript, Flash, Coldfusion, PHP and I am sure many other web technologies.  It's also rather straightforward to do this in the Palm OS (epocrates does it) and in .Net.  Alas .. I don't know much about Mac proceamming anymore .. but I'd bet that this is supported there too.   Users should demand this sort of functionality in search screens. for all of their applications.

b) The other way to accomplish this is without a background connection to the database.  Instead of checking in with every keypress, load the database into the application or into the browser when the application (or browser window) opens.  Sure -- this won't work for big big databases, but it works better than you would expect for databases of fairly significant size.  In our Mini-EMR at the office, we have 5800 patients.  All 5800 firstnames, lastnames, ages and id numbers are loaded into the browser when the user logs in.  Searching for a patient takes only a few keypresses.  To Search for Bob Jones, I would type "Jo Bo" and I'd probably see him as one of my two or three results (along with Josie Boomerang, etc) .. and it all takes me less than a second.    If a pair of Geeks like me and Dave can figure this out .. so can the programmers at GE (Medicalogic), PMSI( Practice Partner), A4 (A4 EMR) and Misys (Misys EMR) .. and an array of others .. c'mon folks .. please help your users search for patients, medications, diagnoses, allergies and procedures much faster! .. You'll make our lives better .. and will imporve patient care.

EMR Usability

We're still struggling with our EMR .. and beginning (again) the process of reviwing alternatives. 

When I read EMR evaluations, I'm often struck by the absence of usability studies.  While the vendors have lots of feature "bullets" ... usability remains largely unmeasured and hard to compare.

I'm thinking of creating a survey to capture a few important usability metrics.

Something like this pilot survey ... but with more questions.

I'm trying to think of what the questions should be.  Pelase leave comments if you have suggestsions for very simple questions .. and please do fill out the pilot survey and give me feedback about that too. 

Paper as a User Interface

The last session in this afternoon's adventure is a discussion of how OCR was used to populate an EMR.

It's a good talk.

He reviews how a paper template can be used to provide decision support and improve the quality of data entry.

They developed the concpt of "adaptive turnaround documents."

Aftern the patient checks in, a form is generated (based on a patient questionnaire that the patient fills out -- and patient demographics) that the nurse and then the physician will fill out.  So the clinical staff get a custom developed form that helps them focus on issues that the rules engine thinks are important. 

Cool

So the kid with asthma gets a different form from the adult with diabetes.

Workflow:

1. Patient checks in
2. Patient gets the survey
3. Nurse gets the patient (with the form)
4. Nurse gets the form and scans it into the "Digital Sender" (HP4101mfp) and the device e-mails the scanned image to the OCR server.
5. System reads the form and determines it slevel of confidence about each item.
6. The system then creates a form based on the inputs from the patient survey

They did a fairily thorough of QA and observation of how the system worked from a workflow standpoint.  Research findings:

1. 224 forms completed in a 6 day study period
2. 98% or so were completed
3. 98% were accurately scanned
4. It took 25 seconds to generate the form
5. 43% of the forms required some correction
1. The software prompted the nurse for corrections and/or confirmation - the average was about 1 .4 fields per form. 
2. This took about 10 seconds per form.

Soooo ..

Here's the punch line .. they can now alert the doc to clincial problems.   The doc is prompted:  "John has a BMI of 12 - you may want to consider malnutrition."

Interesting.  He's got other thoughts about faxing forms to teachers for ADHD evaluation, etc.  Cool.  Medical Informatics with paper.