Family Medicine Notes

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.

Posted by Jacob Reider, MD at 11:37 AM | Permalink | Comments (4)

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.

Posted by Jacob Reider, MD at 12:24 PM | Permalink

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. 

Posted by Jacob Reider, MD at 12:19 AM | Permalink

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.

Posted by Jacob Reider, MD at 03:13 PM | Permalink | Comments (2)