Monitoring complex processes
September 30, 2002 | Edward Tufte
4 Comment(s)
Seth Powsner of the Yale Medical School and I wrote 2 articles on displaying data for monitoring medical patients several years ago. These articles are now posted in the NEW section.
The information architectures shown are designed to depict a complex multivariate flow of real-time data, provide some historical context, and indicate if any part of the process is in trouble. These architectures might be helpful for the display of quality control data, portfolio management, project monitoring, project management, as well as tracking the condition of medical patients.
he discussion of medical interfaces in my Visual Explanations (pages 110-111) is based on these articles.
Topics: E.T.
For recent developments concerning the designs described in the 2 articles, contact my co-author: Seth Powsner, MD Yale Psychiatry: Seth.Powsner@Yale.Edu
I read these two articles yesterday (1.11.07), and found them enlightening in many ways. I have the following comments and questions: I found the remarks about pre-empting the development of applications embodying “institutional habit” baffling, since incorporating organizational knowledge and processes is what makes data shareable technologically and conceptually, and makes displays intuitive for multiple users. Medical professionals, especially in hospitals, work in an environment of teams and hand-offs, and the display of the data must be understandable by other users in case of emergency or treatment by other clinicians (for example, non-linear scales aren’t). This becomes a huge issue for maintaining “continuity of care” and patient safety, such as when patients are transferred from hospitals to nursing homes to multiple specialists, back again to hospitals, etc., each with its own information systems and organizational processes.
In the area of systems integration, data and metadata standards for definitions, storage and retrieval, mapping and matching, are some of the elements that enable information, and hopefully wisdom, to be shared and built upon while maintaining the integrity and accuracy of the data.
Preferences for display by each caregiver can be stored, but the “official” medical record should be intuitive and shareable for multiple users; otherwise it may still be necessary to depend on the patient’s recollections to fill in the understanding of the non-standardized bits.
I would appreciate any feedback you can give me on this issue, and some pointers to other parts of the website where issues such as groupware or workflow are discussed.
“Intuitive and shareable” information architectures also too often mean “lowest common
denominator” information architectures. The object of new systems is not merely to
replicate old systems; new systems should provide gains in substantive understanding,
greater speed, and reduce impediments to learning systems operations. Professionals can
learn how to read new information displays; indeed such learning is part of being a
professional. Information displays aimed to accommodate the bottom 20% of users will
give you a 20th-percentile product at best.
Reasonable substantive needs should drive the choice of displays. Also every user does
not have to understand everything in the record–which is surely already the case for the
current record! A good record will serve the needs of many different users, not just the
bottom 20%.
Thus designs for new information architectures should of course reduce impediments to
learning, but those designs should not compromise the substantive gains that come from
new displays. Displays should be as clear, simple, and straightforward as possible, but not
simple-minded. Often a good way to achieve clarity of design with complexity of
information is to intensity the resolution of reasonably conventional designs (as in the
case of sparklines).
A sure road to a poor, simple-minded architecture is to underestimate the intelligence of
users and their ability to learn. If the new architecture produces good substantive gains,
then there will be plenty of incentives to learn how to read the new displays.
I recently got my first taste of the VA’s VistA system, actually a commercial version based of VistA’s open source code. An electronic medical record is an relational database management problem and the biggest issue anyone has to face in designing one of these systems is the data model (Greenspun). The folks at VistA, from what I’ve seen, have laid a lot of the basic groundwork in this. Anyone’s experience with EMRs aside, we will remain indebted to everyone involved in that project for their work on the basic data model.
In terms of the basic design issues, there is plenty of room left in the GUI to improve, and I can see where a Flickr Organizr (or Adobe Lightroom, or Apple Aperture) type interface might be helpful if you wanted to pull in a number of parameters and build yourself an ad hoc visual display, where you might be able to select the ET-Powsner graphs as a possible style for appropriate data types.
The version we are testing is a web-based service by MedUnison called DocSynergy, again, derived from VistA. You can see what the VA’s dedicated client-side application looks like in the VA’s VistA monograph (page 87 is good).
Like Flickr, Google, and any number of others, I’m inclined to suspect there’s an API for VistA, so for epidemiology it should be little more than designing the interfaces you want to monitor and the program will query the database for you. There will likely be many hospitals and other data sources with divergent databases in any given epidemiologic footprint, but programmers can still tunnel into multiple databases, map variable names (which may morph based on local needs), and get you an integrated display.
Personally, I’ve found tables and maps to the most useful documents for epidemiologic stuff in New Orleans. If you only have six variables and most of them are time and space, then a Minard-style map is a nice special case, but I seem to find myself working with lots of variables and tables quickly become the only useful standard.