Active Forum Topics | Getting Started | Interviews | EMR Forum | Medical | Billings | Press & News | Voice Recognition | The Water Cooler
In an earlier thread (http://www.emrupdate.com/forums/t/18108.aspx ) I proposed the concept of the EMR time bar, both as an interactive navigation tool and as high level visual design pattern for organizing patient data.
The key question was raised of whether the best features of an icon-based time bar could be grafted onto a more text-based GUI design, such as Synapse, which uses sortable lists, filters, tabs, search functions and so forth to achieve power and flexibility -- to make it easy to perform our everyday patient care tasks. In other words, is the time bar idiom pleasing merely because it is ‘cute’, or pleasing because it allows us to use our highly evolved visual system to pre-attentively organize a wealth of disparate data, leaving our cognitive resources free to reflect on actual patient issues?
As a first step in trying to answer this question, I took the same list view of events that Jason Murdoch posted and put it into time bar view, so that the two views could be compared side by side.
Note that I made the following changes to the first time bar design:
While I have some initial ideas about what works for this design and what might work better, I thought for now I would just post it for comment and critique.
List View:
Time Bar View:
Rick Weinhaus, M.D.
Watertown, MA
I see that both jpg files were posted at less than full size and resolution, making it difficult to see and compare them. I need some advice about how to post them at larger scale and resolution, and I will re-post them as soon as possible.
Thanks,
Your idea is intriquing but can not survive in its simplicity because of function requirements. Lets just use CCHIT on problem lists.
1. Must have problem list for a patient (easy)
2. Must have list with problem start and resolution (easy)
3. Must list problems by chronicity - acute, chronic ect (OK)
4. Problem has who entered,updated it - which doc, nurse, user themselves etc (O-OK)
5. The problems must be associated to individual orders, meds, notes (ahhh OK)
6. The problems associated must use codified orders and meds - ICD, NDC, Snomed etc (gulp)
7. The problems must be codified (g-gulp)
8. Problem list has to display as separately and together as active/resolved with all the codified data and any free text comments ( AHH)
9. Problem list displays codified - active/resolved - free text separtely as current and historical (AHHH)
10. Give multiple print options for all of the above (AAHHH)
11. All of the information is to be stored as discrete data (specifically limited data)
It is starting to be because of this - no-one is going to take CCHIT seriuosly - because it is forcing doctors to input a lot of data or use the data the EMR generates for them. But the above 11 are born out of a committee of doctors adding what is neccessary for them - So all of these need to be addressed.
Your goal is a simple interface - to be simple is very complex.
Medscribbler Getting you there sooner!
Scriptnetics
866-350-6337
Here are the re-posts of the list view and time bar view:
LIST VIEW:
TIME BAR VIEW:
What does it look like over a 20 year timespan?
Graham http://www.synapse-ehr.com/ Synapse - the EMR for the superior physician
CEOMike: Your idea is intriquing but can not survive in its simplicity because of function requirements. Lets just use CCHIT on problem lists.
Mike,
The time bar is just another way of viewing and organizing files within an EMR. It doesn’t necessarily imply anything else about how the software interface is designed. As Brendon suggested, it might be possible to provide the time bar as an ‘add-on’ feature to existing EMRs.
I couldn’t agree with you more about how CCHIT requirements interfere with a simple, clinician-oriented program. The task-directed CCHIT list of features is the exact opposite of what a goal-directed design should focus on.
Rick
gchiu: What does it look like over a 20 year timespan?
Graham,
I don’t know. Clearly, one is going to need either a very long time bar or another solution in order to to incorporate 20 years of data. And if the icons and other data elements become too crowded, then the visual simplicity of the time bar suffers. I will work on this problem.
What kinds of data did you have in mind for a 20 year timespan? The same as what is already in my time bar examples, or more like the time line that you had worked on, showing the dates of onset of problems?
I also want to work on an example of a time bar that would include all the data elements that DrMurdoch asked about in the last thread:
Can you redo your screen for my patients on Warfarin (Coumadin) that get their blood drawn 18 times per year (at three weekish intervals) ? Please add 6 doctor visits, 2 other lab tests (useful ones) , 1 CT, 1 U/S, 8 specialist vists from 4 different specialists, 1 EKG, 1 hospital admission, 1 Bone density. The patient is on 13 Medications and 4 changed that year.
Jason, could you post a date-sorted list of files that would be the equivalent of the above, preferably based on a real patient?
Re: 20 yrs of data: A window can be arbitrarily wide with a scrollbar at the bottom. Just scroll over. Filters could be important in limiting detail.
Interesting thread.
Here it is:
Graham, I’m sure you envisioned something along these lines. With this density of data points, it seems that a 20-year view is mostly good only for getting a sense of the data density itself. This example was made using only about 10 icons (events) per year, which is certainly not a lot for many patients.
In order to go that far back in the record, I would think that I would usually have a definite task in mind. For instance, let’s say that a hospital discharge summary from the past contains some crucial material bearing on the present illness and my patient can only remember that there were several hospitalizations in the mid-1990s.
I could filter, as Matt and Jason have suggested, on hospital discharge summaries (see below). In the example below, the data density is now more manageable and I could open any of the three hospital discharge summaries from this 20-year view itself.
If the data-density was still a problem, or if I wanted to review other events from this same time period, I could use the sliding tabs (shown in red) to bracket the three hospital visits and then zoom in on this shorter time interval so that it occupied the entire length of the time bar.
Rick, ultimately the only way to find out if this is a useful way of looking at patients is to implement it and see what happens.
I think 10 icons = 10 filters is way too few. That's why I use tags instead.
gchiu: Rick, ultimately the only way to find out if this is a useful way of looking at patients is to implement it and see what happens. I think 10 icons = 10 filters is way too few. That's why I use tags instead.
You are of course right about the need to test and see if the time bar actually helps. It may very well be that the time bar design will ultimately not turn out to improve EMR usability. In any event, I have found it helpful to present these preliminary design ideas to the emrupdate community. The feedback and suggestions have already been quite helpful in refining the design (for instance, see my reply to Matt below).
In order to consider more fully the issues that you and Jason raise, I need to becoming familiar with Synapse and learn how specific features (such as tags) work. I plan to download Synapse in the near future (I think I need a password from you first). I look forward very much to learning about it. It is clearly a superb program. Thanks for making it available.
mchasemd: Re: 20 yrs of data: A window can be arbitrarily wide with a scrollbar at the bottom. Just scroll over. Filters could be important in limiting detail. Interesting thread.
Matt,
A scrollbar would certainly work. Whether a scrollbar or some other idiom is used, it would be helpful to be able to adjust the time scale below the time bar so that it best suits the data points.
One design solution that would not require a scrollbar would be to click on the (newly added) back and forward arrows ( ← , → ) on the sides of the time bar itself, in order to step sequentially backward or forward through blocks of time (see below). The time interval of each step would be selected by the user, using the buttons below it (1 month, 3 months, 1 year, and so forth).
In the example below, I selected a 1-year time interval (indicated in red), showing the data points from 2004 to 2005. By clicking once on the left arrow (red), the time bar would display the dates and events from 2003 to 2004.
Note that these arrows would be in addition to the previously described back and forward arrows (<, >) that allow the user to step sequentially back and forward through individual events (icons). In the design below, I moved these icon arrows so that they are now in the same row as the icons.
Again, as Graham notes, what might work can only be determined by testing.
rweinhaus: In order to consider more fully the issues that you and Jason raise, I need to becoming familiar with Synapse and learn how specific features (such as tags) work. I plan to download Synapse in the near future (I think I need a password from you first). I look forward very much to learning about it. It is clearly a superb program. Thanks for making it available.
Rick, I'vve sent you a private message on where to download Synapse from without registering.
Otherwise, just register on our website http://www.synapsedirect.com and download it from there.