 |
IDS
v3.0
Med Images, Incorporated |
 |
The
new IDS v3 user interface is color neutral, to
avoid bias while viewing color-critical medical images.
Large target sizes allow for easy selection with a lightpen.
|
Med
Images places an IDS image capture and dictation recording system
in a hospital or clinic operatory. The IDS system consists of a
customized PC, monitor, and printer on a
mobile cart — a configuration elaborately tested and certified
for medical use by the FDA — and is the client-component of
a medical imaging and report transcription service.
What
It Does
During a medical procedure,
especially those which use endoscopic cameras which are inserted
into the patient’s body, the physician uses a footpedal, sterile
disposable keypad, front panel control, or the on-screen display
and lightpen to capture an image from the camera. Images
may then be adjusted for color, hue, brightness, saturation, and
cropped, rotated, or otherwise manipulated.
 |
The
system is used to dictate reports which include pictures
from endoscopic cameras.
|
After the procedure,
the physician orally dictates his report while viewing the captured
images. This may be done from any networked IDS system or standard
PC which has IDS software installed, offering the physician privacy
to collect his or her thoughts. When completed, the images and audio
files are transmitted via the internet to Med Images transcriptionists
who convert the data into a report formatted to the physician's
or hospital's style preferences. High-quality hard copies are dispatched
to concerned parties via courier or electronic copies of the report
may be printed by authorized users at any IDS terminal.
The IDS system uses a
standard PC architecture with custom enclosure and boards. Although
Windows 2000 is the operating system, this embedded system conceals
its underpinnings: an application-specific, user friendly environment
was created so that no knowledge of computers is required in order
to use this system.
What
It Was
The previous version
of this product was known as the RT2000, a kludge of many
seperate software packages crudely linked together to accomplish
basic product functionality. The interface restricted users to a
linear worklow, so that once documenting a procedure began it had
to be completed prior to performing any other task. Many product
features were so obscured by the interface that most users knew
only how to perform a specific series of tasks which were taught
by field representatives. Support and training costs were exceedingly
high.
The
interface of the previous system was so difficult to understand
that cheat sheets were taped to each system monitor prior
to shipment. |
|
 RT2000
Primary Functional Pathways
A visual diagram
of the system interface prior to our involvement.
 Acrobat,836K:
download here.
 User
Interface Specification Appendix A: Observation of RT2000
Use In Hospital Settings
Observation notes
of physicians using the previous system.
Acrobat,836K:
download here. |
The
Process
When we were brought
in, our mandate was to refine this "diamond in the rough"
into a world-class product through the design of the user interface.
All that existed of the new system was a bullet-list of undefined
wish-list features and a corporate committment to the effort. We
interviewed marketing, support, and development staff, analyzed/extracted
features from the existing product (RT2000, described above) and
created a product requirement specification which defined all aspects
of the new product, anticipating future features based on management
vision.
In collaboration with
the lead developer, we wrote the functional requirement specification
of the new system. This became the seed document for software architecture
and development, as well as for the user interface design.
After identifying the
users and their needs, key interface mechanisms to support the functional
requirements were identified, developed and tested in block form.
This offered a quick and effective means to validate the new interface's
overall structure. In
collaboration with marketing and executive staff, graphical design
options were evaluated and a design direction was adopted. Screens
depicting the key interface mechanisms with the graphical look were
created. These key screens were then homogenized in order to create
a consistent look and feel and establish interface standards.
With standards in place, the rest of the interface was fleshed out
and defined as a formal interface specification which was then built
by project developers.
Our schedule and budget
did not allow for user testing, which was a disappointment, but
heuristic review by interface design peers and general feedback
confirmed our design decisions.
Before
And After
The following series
of images depict key screens from interface, before and after our
involvement.
|
Metamedia ™
