12. Example User Interfaces for
Various Caregivers

12.1 Project Context: User Interfaces

This chapter presents an example user interface for the automated patient medical record system. The user interface was developed to handle the composite of workflows of the caregivers within the HMO.

Caregivers who provide patient care in our HMO are listed in section 4.2. The organization wants to preserve all current workflows, as described in section 4.3 but removing unneeded paperwork and duplicated entrance of information. New capabilities described in chapters 7 and 8 need to be supported.

The previous chapter describes a process that could have been used to identify this composite user interface. This user interface was chosen because it can handle all the workflows for all caregivers in the HMO; the user interface would be tailorable by type of caregiver as well as by each individual caregiver.

As a basis for the description of the composite user interface and the workflows, we start with the conceptual view of the system previously as presented in section 7.9 and figure 7.15 and now shown here in figure 12.1.

This conceptual view includes the following parts:

· methods to identify patients of interest to a caregiver: methods tailored to the specific caregiver to select a patient and verify that the correct selection has been made

· a quick overview of clinical information for a patient: a summary of patient clinical information tailored to the caregiver (e.g., current medications, past encounters, immunizations, etc.)

· defined outcome cases, chronic condition management cases, and patient cases for a patient: a list of defined outcome and chronic condition management cases (identifying treatment plans and related information) and patient cases (identifying case notes for a case manager)

· synopses of past encounters for a patient: a list of caregiver or automated system generated summaries of each encounter; synopses could also exist for a case and a clinical pathway

· documents making up a patient’s chart: the set of documents making up the chart, with documents organized by encounter, defined outcome case, chronic condition management case, patient case, or clinical pathway. These are the “source documents”.

· the ability to perform and record actions dealing with the patient’s care: this covers all activities to schedule or perform services and record care, including the following: (1) ordering clinical laboratory tests, medications, diagnostic images, etc., and receiving back results, including alarms of abnormal results; (2) documenting patient care, producing documents in the chart; (3) messaging between caregivers; (4) making patient appointments; (5) viewing medical and HMO reference information, including HMO guidelines and drug formulary.

The proposed automated patient medical record system would be tailorable by job category or individual caregiver. For example, the type of patient lists immediately available to a caregiver (e.g., Inpatient Census, Outpatient Schedule) might be dependent upon type of caregiver. Patient medical record information might be organized differently for an ophthalmologist versus an internal medicine physician. The following sections describe how the user interface might look to different types of caregivers and describes additional aspects of user interface design.

What is presented here are screens of the automated patient medical record system, equivalent to a prototype of the system. A prototype is a realistic model of a system in terms of the user interfaces, which looks like the real system but isn’t. Although it looks like the real system, it does not function like the real system in one or more ways (e.g., it probably has no databases or underlying code and its screen navigation is likely to be unlike the real system).

Why prototype? Prototyping is for experimenting--showing a system to users for their evaluation without going through the hard, hard, time-consuming work of actually building the system.

12.2 Choice of a Graphical User Interface (GUI) Model

There are several choices for user interfaces for the automated patient medical record system: character-based, Graphical User Interface (GUI), or Internet like with hypertext.

Character-based user interfaces still exist largely because of the success of the IBM Corporations Customer Information Control Systems (CICS), one of IBM’s most popular mainframe system software systems, which supports creation of applications on character-based terminals [1]. In the next section, 12.2.1, we will explore the limitations of character-based interfaces. (CICS is discussed further in section 17.3.1.)

GUI is the proper interface for many parts of the automated patient medical record. GUI is a user interface that makes use of every addressable dot (called a “pixel”) on the screen and thus makes it possible to create detailed visual symbols for user navigation, characters, pictures, and lines. A particular category of GUI interface uses “Cooperative Business Objects” (CBOs), real world “business objects” that are relatively independent from each other [2]. Another term for a GUI interface using CBOs is an Object Oriented User Interface (OOUI). See section 12.2.2.

Internet/Intranet/Extranet hypertext documents must be formatted in HTML XML, or SGML. Many medical references are available through documents in such a form on the Internet. Whether it is feasible to also present documents making up the patient chart in the form of such hypertext documents is explored in section 12.4.

12.2.1 Limitations of Character-Based User Interfaces

Reference [2] presents a comparison of character-based systems such as CICS versus GUI PC systems. First consider a CICS character-based approach for an automated patient medical record system. The initial character-based screen might be a menu, a list of selections, as pictured in figure 12.2, including the following selections:

· PATIENT INFORMATION: Identify a patient by entrance of a patient identifier and display associated patient demographics information

· PATIENT LISTS: Select a Patient List for display, such as a particular provider’s outpatient schedule

· PATIENT CLINICAL SUMMARY: Select a Clinical Summary of the patient’s clinic information (e.g., medications, previous encounters, etc.) for display.

· ENCOUNTER SYNOPSES: Display summaries of previous encounters.

· CHART DISPLAY: Display documents in the chart.

· CASE DISPLAY: Display defined outcome cases, chronic condition management cases, and patient cases.

· ORDERING: Enable various types of orders to be executed, including clinical laboratory tests, prescriptions, charts, etc.

· DOCUMENTATION: Enable selection of a type of chart document and allow entrance of information into the document.

· APPOINTMENT: Make an appointment.

· EMAIL/MESSAGING: Allow e-mail, messages to be sent to other people.

· MEDICAL REFERENCE: Allow display of a medical reference such as MEDLINE.

Selection of PATIENT INFORMATION from the menu might bring up a screen to display and collect patient demographics information. See figure 12.3.

Selection of PATIENT LISTS from the menu might bring up a list of patient lists available to the user for display. The user can select the type of patient list to display and enter a date if required to identify the patient list to display. See figure 12.4.

As shown by this example, some characteristics of a character-based user interface are the following:

· The user can do only one thing at a time: The user selects what to do from a menu. In order to start a function, any other function being executed must first be completed. Two or more functions cannot be handled concurrently.

· The character-based structure enforces business rules but guides and restricts the user through all processes.

· The character-based structure does not easily handle indefinite and large lists (i.e., menus) of different types of selections such as might occur within the PATIENT LISTS function (with possible display many different types of patient lists), the CHART DISPLAY function (with possible display of many different parts of a chart), the CASE DISPLAY function (with possible display of many defined outcome cases, chronic condition management cases and patient cases) or the DOCUMENTATION section (with a possible capability to enable entrance of a large number of different types of chart documents).

· the screen structure is inflexible: the screen is of fixed size, a fixed number of characters wide by a fixed number of characters in height. Images, line drawings, waveforms, etc. can not be displayed.

The first two characteristics, one thing at a time enforcing business rules, limit the way the user can work; however, guiding the user through the processes may assist new users. The last two characteristics, information limited to the size of the screen, make it difficult to handle indefinite lists of selections and variable information.

Other problems with character-based user interfaces are as follows:

· Character-based user interfaces do not support standard word processing capabilities for text, such as word wrap (forcing a word which is at the end of a line to the next), insertion of text, or deletion of text.

· Without mouse support, it is difficult to go from field to field. Cursor movement is generally restricted to be from field to next field, left to right and top to bottom. Not so obvious key combinations allow cursor positioning to the first field, the last field, the next field, the previous field and the next line.

· Character-based user interfaces do not provide the equivalent of the GUI message box. Message boxes can pop up and inform the user of an important event. For example, the GUI message box in figure 12.5 shows an alarm being presented to the caregiver showing a clinical laboratory test result that is out of range.

12.2.2 A GUI System Defined in Terms of Cooperative Business Objects

With a GUI interface, the user has many graphic elements available, including windows; bitmaps and drawings; drop-down menus; message and dialog boxes, and “controls” of various types, including group boxes, static text boxes, scroll bars, input fields, single-selection lists, radio buttons, check boxes, tabbed structures, and controls specific to pen input. Reference [3] describes these controls and the screens starting at figure 12.5 in this chapter collectively show many of these controls.<