According to a presentation given by Dr. Paul Chang at the 2010 Society for Imaging Informatics in Medicine (SIIM) conference, we sometimes get so focused on our own area of systems expertise that we forget to look at the outside IT world. While we're hung up on whether a system has a PACS driven or a RIS driven workflow, IT outside medicine is leaving us in its dust.
Take Wal-Mart for example: The firm knows exactly where each piece of merchandise is, because it is identified by RFID technology. In contrast, we still hear stories about patients being "lost" in the corridor as they are waiting for a radiology procedure. In addition, PACS administrators are correcting studies that were incorrectly identified with the wrong name and patient ID on an almost daily basis; most of us don't know the exact turnaround time of many of our procedures; and on and on. Given that RFID chips are so inexpensive, it is an interesting choice of many institutions to track C-arms and computers, but not the patients who make the acquisition and use of these tools possible.
There are other examples: Why does it take a physician so much time to place an order and it takes just one mouse click on Amazon? Why do we need dashboards to see the system status when the system should be auto-correcting? Why do vendors still believe they can offer “one size fits all” IT products for medicine?
It won’t be long till everyone will have a personal health record. Institutions will be forced to support the implementation of electronic health records. We can only hope that the implementers will take note of what the rest of the IT world uses today.
It took many decades of trust building and implementing secure implementations for financial institutions to deploy ATM’s, on-line banking, and many of the other features which individuals use to manage their financial records. How widely are these applications accepted? It has been a long time since I heard about someone storing their savings under a mattress.
Our task and our goal is bring health information on-line, make it accessible to the professionals who need access to it, and allow consumers to start properly managing it.
In short, the role of informatics in the development of our future health records could be significant--if only we can learn from what has been successful in other domains.
Thursday, July 1, 2010
Report from SIIM: What We Hate About Our Workstations
Radiology reading rooms are still using software and input tools that have been, at best, minimally adapted for the needs of the interpreting physician, according to a presentation by Dr. David Weiss at the 2010 Society for Imaging Informatics in Medicine (SIIM) conference in Minneapolis.
One application area that could, and should, see improvement in the immediate future is the radiology worklist. A worklist, in its simplest form, is a list of exams to be interpreted. The basic worklist sorts these by body part, modality, and other parameters on the basis of how a radiologist wishes to interpret exams. A workflow manager, which is the software that creates a worklist, prevents double reads by keeping track of who is reading what exam.
The basic worklist is just that, basic. It doesn't provide much in the way of system intelligence and minimally expedites workflow. On the other hand, a sophisticated worklist could speed workflow, improve quality, and lower costs.
Weiss believes a sophisticated worklist should have the following functionality:
The keyboard was invented in 1872 with an arrangement of input characters (QWERTY) that ensured the typewriter arms did not conflict. The mouse was developed in 1964. Not much has changed for either input device.
Weiss said that radiology software designers need to keep the following items in mind when coding their applications:
In the digital age, the radiology workstation in the primary tool of an interpreting physician who spends as much as 10-12 hours in front of these systems each day. To meet the demands of a soft-copy reading environment, developers must become more in tune with the needs of the radiology professional.
One application area that could, and should, see improvement in the immediate future is the radiology worklist. A worklist, in its simplest form, is a list of exams to be interpreted. The basic worklist sorts these by body part, modality, and other parameters on the basis of how a radiologist wishes to interpret exams. A workflow manager, which is the software that creates a worklist, prevents double reads by keeping track of who is reading what exam.
The basic worklist is just that, basic. It doesn't provide much in the way of system intelligence and minimally expedites workflow. On the other hand, a sophisticated worklist could speed workflow, improve quality, and lower costs.
Weiss believes a sophisticated worklist should have the following functionality:
- A "pending" state for a worklist item; for example, if an exam requires additional views, reconstructions, or requires a comparison study that is not readily available yet. It should not be left on top of the reading queue as a radiologist might, by accident, open up that study again.
- A good worklist should be able to move images to a QC area; for example, if the quality was identified as being either unacceptable or feedback needs to be delivered to the technologist.
- Exams might have to be moved to another radiologist, for reasons such as a double read, ownership of a study, or a second opinion. After review by a peer physician, exams should be able to be sent back to the originator or sent back to a public worklist.
- Copy cases to teaching files, with or without notes having to be supported.
- Worklists for dealing with multiple sites, such as teleradiology systems, need to be able to deal with multiple PACS vendors, multiple readers, sub-specialties, various state licenses, and hospital privileges. This sort of functionality requires a level of complexity which is not yet available from most commercial vendors. In many cases, teleradiology providers have had to develop their own worklist capabilities.
- In addition, it might be an advantage to have anti “cherry-picking” software. This would prevent a radiologist from siphoning off only the easy cases from a worklist.
The keyboard was invented in 1872 with an arrangement of input characters (QWERTY) that ensured the typewriter arms did not conflict. The mouse was developed in 1964. Not much has changed for either input device.
Weiss said that radiology software designers need to keep the following items in mind when coding their applications:
- Having to use a pull down menu is a failure,
- Keyboard strokes should not be required (remember that a reading room is dark!), and
- Applications should not use tool palettes.
In the digital age, the radiology workstation in the primary tool of an interpreting physician who spends as much as 10-12 hours in front of these systems each day. To meet the demands of a soft-copy reading environment, developers must become more in tune with the needs of the radiology professional.
Subscribe to:
Posts (Atom)