One of the workshops held last week was about EHR usability, hosted by NIST. I wasn't able to attend, but I will be reading through the presentations as I am able.
One of the blog posts I retweeted this week on usability mentions Tufte's sparklines. If you don't know who Tufte is, you probably haven't been working in design, and if you are working in design and don't know him, you need to go find out.
Sparklines are very cool. They are small information graphics about the size of a a long word in text. A few examples appear in the picture below.
Let's say that you decided to implement this in an EHR. There are a couple of places that you can get open source implementations of sparklines, and there are graphic libraries that you can use to generate the images as well. Seems pretty simple in concept, with some really great value to offer providers. Let us dig into some of the issues that we'll need to address in an implementation:
Outliers: Some results can be out of range, unmeasurable, et cetera. How should these handled? This is actually one of the questions raised on the Tufte post. The response, to use log scales in some cases is not really a satisfactory answer.
Time Scale: How is the time scale determined? Is it the last year, last month, last week, or patient life? Time scale is often a question of relevance, in which case it means that clinical judgement needs to be applied. Whose judgement? The customer's? The developer's?
Units: The same result can be reported using different units. Which one do you normalize to? The example above doesn't show units at all [probably not a good idea for reasons described later]. How do you chose? Temperature above is in degrees Fahrenheit. OK, that might be fine in the US, but if I have to ship the same product to Europe, they better be in degrees Celsius, and some US institutions prefer degrees Celsius anyway. Another configuration option. That means I better report the normalized units being used. Oh, and just for fun, some results can use units of volume while others use units of weight. For example, kilogram of water takes up 1 liter of volume. I'm not sure if this is an issue for common tests, but it certainly is for some uncommon ones.
Configurability: Is Time scale, units or normal range a configurable option or not? If it is a configurable option, how do you deal with the case that clinicians at one site will have one set of expectations, and those at another have a different set, and you could have one provider having to deal with both, with the potential for misinterpreting a result because of the different system configurations? Oh, and what happens when a new system is installed with a different configuration, or some poor physician has to transition to a new system with a different configuration. If everyone uses sparklines in their EHR, what are the standards for displaying them that avoid this sort of problem (see this example for ECG graphs)?
Normal Ranges: The gray bars represent the normal range of values. This gets complicated a number of ways. Whose normals? The lab's? The healthcare provider's? The developer's? Is this configurable? Two labs may report the same lab result with different normal ranges that depend on patient age, height, weight, and other factors (including the test method). The normal range changes as the patient changes (age, height, and weight are variable over the patient life). See for example some normals for respiration rate. How do we deal with that?
Units again: Many lab systems report results using different vocabularies for units (with variations on ANSI and ISO units). Without a standard vocabulary for units (like UCUM), we need to deal with transformations to a normalized set of units.
Graphics: You are going to need a lot of these, and they need to be generated quickly. You may want to add some cool features like mouse overs or hovers. What tools should you use. How do you validate these? Do it your-selfer's be warned: Generating small images accurately and quickly takes skills with numerical algorithms and processing. A small error on a small graphic can represent a big difference in interpretation. Look at respiration again, or WBC in the image above. Are these values inside of, or outside of the normal range? How important is that? How far inside or outside is it?
Good data: Key to getting sparklines right is having good data. After all, GIGO out is one of the first things we learn in computer science. Good data means that you have good interfaces. You need to be able to ensure that WBC, glucose, et cetera all come across the lab interface in a way that they are mapped into the right place (e.g., using a vocabulary like LOINC), that normal values are present (if using the lab's normal range), that exceptional values are reported consistently, that units are mapped consistently.
So, simple idea, but a lot to think about in the implementation, and some definite prerequisites on the interoperability side before it can be executed upon.
What is the moral of this story? Nothing is ever as easy as it looks.
0 comments:
Post a Comment