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.

Input in a GUI system is by keyboard, pointer devices (mice, trackballs, glide points, etc.) or pen. Various processes can be selected via pointer device selection of buttons with icons; icons can appear as part of tool bars (see figure 12.6).

Reference [2] indicates to think of systems not in terms of applications, but in terms of real world independent “business objects” that the user uses in real life to do his or her job, but where these can cooperate with each other allowing the transfer of information from one to the other business object. The term used is “Cooperative Business Objects (CBOs)”. For example, for the automated patient medical record system, CBOs might include the following: patient, chart, documentation form, order form, appointment form.

Like real world objects, a number of these objects could be in use at the same time (e.g., an H&P document can be created concurrently with display of the patient chart). A number of instances of the same object could be in use (e.g., two patient lists, a physician’s outpatient schedule and the inpatient census could be in use).

CBOs are “cooperative” in that they would be built to allow communication between them. CBOs could be developed by different parts of the healthcare organization, completely different healthcare organizations or by outside vendors. This cooperativeness might be as simple as allowing cutting and pasting of text from one CBO to another via a clipboard; this cooperativeness might involve transfer of data in one field in one CBO automatically to the same format field in another CBO; or this cooperativeness might be transferring of objects and all associated processing from one CBO to another (a spreadsheet with all its functionality). Another method of cooperativeness is “drag-and-drop”, such as dragging a patient’s name from a patient list or Emergency Department triage document to a room shown on a room map, indicating that the patient has been assigned to that room.

One principal advantage of a CBO is that, since CBOs are relatively independent from each other, one CBO can generally be replaced by another similarly functioning CBO when the new CBO is an improvement over the earlier one, with minimal changes, if any, to the other CBOs. This is again an example of “component adaptability”, implementing a component so it can be more easily replaced later by an improved component.

The following are example CBOs making up the automated patient medical record system. Each CBO is represented by a selection button shown in the tool bar on the screen in figure 12.6:

· Patient List (identified by a “table” icon)

· Patient (identified by a “person” icon)

· Clinical Summary (identified by an abstract icon)

· Patient Chart (identified by a “chart with tabs” icon)

· Search (identified by a “magnifying glass” icon)

· Patient Cases (identified by a “cases” icon

· Encounter Synopses (identified by an abstract icon)

· Order Form (identified by an “Rx order” icon)

· Documentation Form (identified by a “pencil writing” icon)

· Appointment Form (identified by a “calendar” icon)

· E-mail/Message. (identified by an “envelope” icon)

· Medical References (identified by a “set of books” icon)

· Snapshot (identified by a “camera” icon)

· Note (identified by a “note” icon)

· Help (identified by a “question mark” icon)

· Exit (identified by an “X” icon).

Consider an example scenario for a physician who works both as an inpatient and outpatient physician and say, works in an outpatient clinic in the morning and in an inpatient unit in the evening. He might select the Patient Lists icon and create an instance of his Inpatient Physician List and an instance of his Outpatient Schedule for today, selecting the type of Patient List from a scrollable list. See figures 12.7 and 12.8. Operating systems such as Windows NT allow a number of ways to quickly switch between the two Patient Lists. At any time, one of the Patient Lists can be closed by selecting the Patient List “Cancel” button.

From a patient list, a patient can be selected (Kathy A Kelley from the outpatient schedule in figure 12.9) or the Patient icon could be selected, allowing entrance of a patient identifier (see figure 12.10). After selection of a patient, patient demographics for the patient might be displayed (see figure 12.11), and from patient demographics, the personal profile of the patient is available (see figure 12.12). From a personal profile for the patient, transfer to the personal profile for the patient’s wife, husband or children is possible (see figure 12.13) and transfer of a phone call to a specialist or case manager is possible.

After selection of the patient, icons related to the patient could be selected: Clinical Summary, Patient Chart, Search (through patient clinical information), Patient Cases, Encounter Synopses, Order Form, Documentation Form and Appointment. For example, by selecting a patient, Julie K Andrews and pressing the Summary icon, the list of Clinical Summaries available for the patient might be displayed (see figure 12.14). For example, Julie K Andrew’s Overall Clinical Summary might be selected (see figure 12.15).

The Overall Clinical Summary consists of various scrollable lists summarizing patient information and buttons to display documents. Unavailable button selections might be dimmed; for example, Julie K Andrews has cases, referrals, but no clinical pathways or trend documents.

Either pressing the “Cases” button on the Overall Clinical Summary or the “Cases“ icon on the tool bar would bring up Julie K Andrews defined outcome, chronic condition management or other cases.

The physician could see the patient’s chart by pressing the “Chart” icon on the tool bar, or if the physician had set up a relationship between encounters and the chart, see the chart for a selected encounter(s) by selecting and highlighting encounter(s) and double-clicking. For example, selection of the 9/10/1998 encounter on the Overall Clinical Summary for Julie K Andrews might bring up the chart so it shows the chart for that encounter (see figure 12.16).

The patient chart would show the main tab and a visit synopsis. Selection of any date would open up encounter information below the document date on a Document List. The physician could select other tabs either by selecting the tab on the tabbed structure or selecting the section in the Document List under an opened encounter date. When the Vital Signs tab is selected for the 9/10/1998 encounter, both the visit synopsis and the vital signs would be displayed. See figure 12.17.

At any point after a patient was selected, the caregiver could select the Snapshot icon resulting in the patient identifier and name being made an entry on the menu. Thereafter, the patient could be reselected by selecting the patient off the menu. See figure 12.18. Selecting “Close” on the “Patient” menu selection, would close and remove the current patient. The previous patient could be restored by selecting the “Previous” menu selection.

Also, when a caregiver is on a particular section of the chart, he/she can select the “Note” icon and mark a place in the chart where he/she can come back to. The caregiver could also optionally set a time when he/she is to be alarmed and re-informed about the note.

The following are some observations about CBO GUI interfaces[2]:

· Concurrency: Two different screens could potentially be displayed at the same time, for example, the patient’s Clinical Summary and the patient’s chart.

· Multiplicity: The physician can work on two instances of an object at the same time, say two patient lists (see figure 12.8) or the patient’s chart for two different encounters. (Generally, GUI systems enable an application to identify whether or not multiple instances are allowed or not; if not, selection of an icon where there already is an instance will return to the single instance rather than create another one.)

· Direct Manipulation: Information could be transferred from one screen to another, for example, from a medical reference to an H&P. The medical reference could be cut and paste into the H&P.

· Multi-media Can be Supported: graphs, voice, video, pictures, drawings, medical images (such as x-rays or CT scans), and waveforms.

· Decision-based Message Boxes: These are screens that inform the caregiver of alternative decisions and choices. When an error occurs, the error can be displayed with buttons displaying choices on how to correct the error. Also, the automated system could make recommendations on better choice care decisions, such as recommendations on less costly medications, and allow selections of these alternate medications, or selection of the original one, via buttons. And as pictured in figure 12.5, the caregiver can be informed of an alarm during other processing.

Other general attributes of GUI systems are the following:

· The application can be controlled largely by a mouse that can move around anywhere quickly on the screen, from control to control, where controls are buttons, text fields, scrollers, etc. Text entry by keyboard is also possible.

· Windows can be moved around, brought in and out of focus (i.e., be identified as the selected one), and put side by side.

· A window and areas of windows can potentially be made smaller or larger. When made smaller, scroll bars can be added allowing non-displayed parts of the screen to be displayed. Images can be scaled, though the resolution might change.

· With scroll bars, larger than screen size images can be displayed while displaying the images with high resolution. This might be useful for display of high resolution diagnostic images that require more dots (or “pixels”) than is available on the screen is properly display them.

Because of all these attributes that provide more flexibility to the user, I feel that the CBO GUI interface is far superior to the character-based interface. On the other hand, some users are uncomfortable with this flexibility and have a hard time learning GUI or mouse-based systems, especially when being trained on character-based systems.

A basic principal of quality software design, for whatever interface is chosen, is that a consistent and useable set of screen display and input standards be chosen and followed on every screen. This decreases the complexity of the system and makes the system more intuitive for the user. This use of a consistent set of screen display and input standards applies whether the screen metaphor chosen is GUI or character-based.

Where there is an industry standard for the screen metaphor, this industry standard should be followed. For example, for Microsoft Windows systems, the Microsoft windows interface guidelines for software design [3] can be used to identify these screen display and input standards. For CICS screens, screen display and input standards are identified by the IBM Corporation’s Systems Application Architecture (SAA) Common User Access (CUA) Basic Interface Design Guide document [4].

12.2.3 Pen Computers and Associated Devices

There are two categories of computers applicable for the end user of the automated patient medical record system: desktop computers (microcomputers using the traditional full-size case, monitor, and keyboard that is designed to be used in a stationary “desk-centered” environment), and portable computers (microcomputers that are easily moved from place to place and that normally use battery power for use on the go). Two categories of portable computers are laptop computers (briefcase-sized computers with capabilities similar to the desktop computer) and pen computers (computers that mainly use a pen stylus for input).

A disadvantage of using a desktop or laptop computer, whether GUI or character-oriented, is that it cannot be easily used during the time the patient is being interviewed, the keyboard and extra weight due to it get in the way. A pen computer simulates the current clipboard with notepad and is thus much easier to use during direct patient care. A pen computer mainly uses a “pen” for input, “writing” on the screen. Such pen input can control a GUI application and can be based upon GUI “controls” such as buttons, check boxes, etc. Additional “controls” might be built in to the pen computer to enable pen-specific input. Some pen computer software enables free-form note input such as hand drawn sketches.

Pen controls that are extensions to Microsoft GUI Windows systems are described in reference [3]. Controls include an interface called a “writing tool”. A writing tool interface is a standard input field with a writing tool button. When the button is tapped by the pen, a writing tool editing window appears with contiguous separate cells for each pen input character.

Also, via a pen, a user can enter “gestures” to edit text. For example, if a user enters via pen an “x “ with a circle around it after selecting text, this cuts the selected text for pasting into the text in some other location. Notes verbatim can also be entered into the computer, which could include printed or cursive characters, pictures or doodles.

When used during patient care, a pen computer is unlikely to have a keyboard, or if it does, it is likely to have a very small keyboard or screen to compensate for the extra size or weight. A pen computer will therefore not be a complete substitute for a desktop or laptop PC. A desktop or laptop PC is probably still necessary when completing input of patient clinical information when the caregiver is back in his office, when a full size keyboard is essential. Pen computers and desktop/laptop PCs thus could complement each other.

For desktop/laptop and pen computers to practically be used as complements to each other, they should probably not be two entirely different systems; otherwise, the operator would need to be trained on two completely different systems. In order to avoid this, the PC system must be “ported” to the pen computer system and be largely the same, functioning nearly the same. There are some complications to doing this: for example, currently, desktop systems for the automated patient medical record often require super VGA screens while pen computers most often use lower resolution VGA screens (see section 17.2.5).

Wake Forest University Baptist Medical Center [5] has decided to use portable pen computers with a built-in keyboard and a radio frequency network link in nursing units and doctor work areas because of security concerns and concerns about physical space taken by desktops. Desktops in patient rooms would require extra time for caregiver log-in and authentication, which hospital management determined would slow down the care process. Also, rooms are filled with diagnostic and monitoring equipment and desktops would consume more of this precious space.

Pen computers are now available that can be held like a clipboard. An example is the Qbe™ (“cube”) Personal Computer Tablet by Aqcess Technologies [6] that has both voice and handwriting recognition.

A type of very small, usually pen, computer is a PDA or personal digital assistant. These are computers small enough to be carried around in a coat pocket or handbag. They may be too small for use for point-of-care, but may be useful when the caregiver is away from the office and needs to record any information, including patient care information (e.g., consultation advice given by a specialist physician to a primary care physician over the telephone).

See section 12.3 for more about computing at the time that the patient is being seen.

12.2.4 System Tailoring for a Caregiver

The automated system could be tailored dependent upon the needs of the caregiver using the system. There could be a standard system, with optional tailoring by caregiver type (e.g., inpatient nurse, outpatient physician), caregiver department (e.g., ICU) and/or individual tailoring. This could be done via agents. Agents are also discussed in sections 7.6 and 13.7.2.8 of this book.

Tailoring could include

· the Patient Lists available to the caregiver (see section 7.7.5 and figure 12.7).

· the Patient Clinical Summaries available to the caregiver and the identification and format of clinical items in each of the summaries (see section 7.7.4.1 and figure 12.14)

· the escalation procedure for reporting on STAT, abnormal or other results when the ordering caregiver is unavailable (e.g., an alarm is sent to nurse practitioner Pat Smith if the ordering caregiver, Dr. Sally Jones, does not respond to the alarm in a given period of time) or for reporting on “unresponded-to” messages when the receiver is unavailable (see sections 7.7.2 and 7.7.3.).

12.3 Point-of-Care Input Methods

For purposes of a discussion of input methods, it is useful to distinguish computing where the patient is being seen by a caregiver versus computing when the patient is not being seen. The general term for use of computers at the time a patient is receiving care, whether in the inpatient setting with a terminal at the bedside, or in the outpatient setting while interviewing the patient, is point-of-care computing. As stated earlier, it is the author’s opinion that desktop computers (referred to here as “workstations”) can get in the way of patient care and are not appropriate for point-of-care computing.

Various input methods are listed in figure 12.19. These input methods are presented in terms of a point-of-care computing part where interview information is input directly to the automated patient medical record, and a potential later part at the workstation to complete the process, for example to correct errors occurring the point-of-care input as a result of inaccuracies in computer interpretation of pen input.

Figure 12.19—Example Point-of-Care Input Approaches

Point-of-care computing	Additional later input of patient interview information	Advantages	Disadvantages
Workstation (input directly to automated medical record)	None needed	The patient interview is input in one step. The entire patient chart is available during the interview. Requires learning only one new system. Actionable information is available.	May get in the way of patient care. May slow down patient care because caregiver might have to interrupt the interview, going to the workstation. Freehand input may not be possible. Problems if system goes down.
None--patient interview recorded on paper	Input at workstation from paper notes	Does not get in the way of patient care. This is the least expensive alternative. It requires learning only one new system. Freehand input possible. No problem of a computer system going down.	The chart is not available during the interview except on paper or by going to a workstation. Two steps are required for input of interview information, rather than one. There is a question of what to do with the informal paper notes. Re-inputting freehand input may be difficult. There is the potential for late, inaccurate, or contradictory input.
Pen computer (input directly to the automated patient record)	Corrections	The entire patient chart is available during the interview. Actionable information is available. Inputting the interview information can be done concurrently with the interview. Freehand input may be possible. The weight of a pen system is likely less than a desk-top computer.	May get in the way of patient care. The caregiver probably still needs to learn two systems, as the pen computer does not work 100% of the time in inputting text and correction might have to be made via a workstation or keyboard connected to the pen computer. The probable smaller screen size of the pen computer may make it unfeasible. Problems if system goes down.
Portable input device connected to a workstation (input directly to the automated patient record)	Corrections	Can be smaller and lighter than a pen computer. Dependent upon input device, interview information may still be recorded if system goes down. Inputting the interview information can be done concurrently with the interview. Freehand input is possible.	The chart is not available during the interview, except on paper or by going to a workstation. Most input devices do not work 100% of the time in inputting text, so input corrections are probably required at the workstation. Unproven technology. Other possible disadvantages depend upon type of input device.

Let us first consider the paper input approach: A caregiver uses paper to jot down notes while interviewing the patient, then later uses a workstation to input the notes to the automated patient medical record. The advantage of this approach over point-of-care computing is that

· During the patient interview, the caregiver can spend more time caring for the patient as the caregiver is not distracted by inputting to a computer.

The disadvantages of this input technique to point-of-care computing are the following:

· The patient’s medical record information would not be immediately available on-line to the caregiver during the interview.

· Inputting information to the automated patient medical record would be a two-step, rather than a one-step, process.

· There is the potential of the caregiver, or someone else, inputting the incorrect information into the computer due to the caregiver or someone else not being able to read the handwritten notes.

· The caregiver must remember to perform the second step of inputting information into the chart, especially in situations where this second step may be delayed due to an emergency situation.

Another input approach is for a caregiver to use a pen computer, inputting directly to the automated patient record during the patient interview. Advantages are (1) the pen computer is similar to the current paper chart clipboard and thus may not unduly get in the way of care, (2) the entire patient medical record is available on the pen computer during the interview, and (3) there is no additional input step, like there for the approach of first recording the patient interview on paper. It has the disadvantages in that (1) pen computers cannot guarantee completely accurate computer interpretation of text input with the pen—the text input may later have to be corrected, (2) a pen computer may be heavy or alternatively have too small a screen to substitute for a paper chart, and (3) the pen computer going down could disrupt the care process.

A caregiver inputting information during the patient interview to a desktop workstation has similar advantages and disadvantages to a pen computer; however, its use during the patient interview can severely interfere with the patient interview, as the caregiver would have to move away from face-to-face contact with the patient to use the workstation.

An approach that is similar to recording patient information on paper is using one of several portable input devices that record patient information on a piece of paper for backup purposes and at the same time send the information directly to a workstation. Two such input devices are the CrossPad™ portable digital notepad and wireless pen [7] that is a clipboard with cross-hatched circuitry that reads what a digitized pen writes on a sheet of paper on top of the clipboard, and the Anoto™ digital pen [8] that reads dots on the paper it writes on. The Anoto™ digital pen requires the use of special paper, referred to as “digital paper”.

These are new technologies are unproven. These devices have the same advantages and disadvantages as paper input, but turn the two-step process of inputting patient information during the interview into something simpler: instead of having to re-input the patient interview information, the user would only have to make corrections to the small parts of text information that the workstation could not accurately interpret.

These new portable input devices require that recorded information be sent to the workstation. Likewise, pen computers can be used as input devices (or “front-ends) for workstations. At least five interface methods exist for transporting this information from the input device to the workstation [9]. These five interfacing methods are listed in figure 12.20, which also lists the characteristics of each of these interfaces.

Figure 12.20—Interfaces for Portable Input Devices

Interface Type	Capabilities
Direct wire connection after recording the input	Two step operation. Not real-time. Slow total process. Fast transmission after the connection is set up. Serial, USB or IrDA connection possible. The only current interface type for the CrossPad.
Infrared	Fast. Line of sight. Cannot go through walls. Real-time.
Bluetooth	Real-time. Can penetrate objects. Supports communication within 30 feet. Selection between Bluetooth discovered devices. Security to provide only authorized access. Require very little power. Supports voice as well as data. The interface type for the Anoto pen.
HomeRF	Real-time. Requires PC card. Requires much more power than Bluetooth. Supports up to 127 nodes. Transmission rate much slower than Wireless LAN. Supports voice as well as data. Supports 50 meter transmission range. Can penetrate objects, such as walls.
80211 Wireless LAN	Real-time. Can penetrate walls. Intended for LAN connection over distances of up to several hundred feet. Expensive. Requires more power than Bluetooth or HomeRF.

Each point-of-care input approach, and the non-point-of-care approach of recording to paper, has its advantages and disadvantages.

Note that the critique that a workstation may get in the way of patient care does not apply to visits via telephone or to telemedicine where the patient is remotely located from the caregiver. In such cases, a workstation may work as well as a pen computer or digitized pen.

12.4 Use of the Internet

The Internet, with the use of the Java language, HTML and XML on Web servers, is becoming more versatile. The Internet can now be used to program very sophisticated GUI-based systems. The user could communicate with the Web server through a large variety of devices, including PCs, PDAs and other types of pen computers, and wireless telephones, with a variety of input methods including keyboard, pen input, and voice. Point-of-care input methods described in the previous section also apply to the Internet.

Many completely in-house systems are being moved to work partially or entirely on the Internet or variants of the Internet. Variants of the Internet are an intranet, a part of the Internet that is internal to an organization, and an extranet, a part of the Internet that is shared by multiple designed organizations. With future changes in Internet technology, including increases in bandwidth (speed because of optical networks), quality of service, and security, moving in-house systems to the current Internet or a future Internet, or to its variants, will likely become even more prevalent.

Should the automated patient medical record system use the current or future Internet or its variants? The author views the automated patient medical record system, as described in chapters 6 and 7, as consisting of consisting of many parts. Each part should be evaluated individually to determine its appropriateness for use of the current or future Internet:

· for large healthcare organizations, a full-featured local automated patient medical record system

· for smaller healthcare organizations, an automated patient medical record system through an ASP (an application service provider who can provide can rent usage of an automated patient medical record system)—see chapter 6

· source document repositories for storage of individual patient records

· a computer-based patient (CPR) record consisting of a summarized history of the patients encounters, health problems, medications, allergies, etc.

· a patient repository identifying the patient and healthcare and insurance organizations who would receive medical record information on the patient

· medical references available over the Internet

· patient access over the Internet to healthcare organization information of benefit to the patient.

Figure 12.21 shows the interconnections (interfaces) between these parts of the automated patient medical record. Each line in the diagram represents an interface that could potentially occur over the current or future Internet, and an intranet or extranet.

Clearly, the interfaces of medical center personnel with medical references and the patient with healthcare organization information should take place over the Internet. Should the other interfaces occur over the Internet?

Any interface that goes outside a single healthcare organization should have the characteristics of speed, security and reliability and have the ability to reach any healthcare organization in the world. This could involve an extranet, future versions of public networks such as the Internet, or perhaps a combination of both.

The Internet should be viewed as a changing network, with future likely changes including increased bandwidth, increased quality of service and greater security from unauthorized use, with changes agreed upon by a standards organization such as the World Wide Web Consortium for the Internet (W3C) [10]. In the future, the Internet is likely to use more and more optical fiber, making it faster and faster, and likely to handle different type transmissions, voice, video, and data. There are already alternative versions of the Internet available—vBNS (very high-speed Backbone Network Service) is one existing alternative version of the Internet, reserved for scientific applications, that can transfer data much faster than the current Internet [10].

The feasibility of use of the current and future Internets for the interfaces in figure 12.21 is dependent on the following:

· bandwidth: the speed of network traffic needed to handle the transmission—Dedicated network connections between healthcare organizations are the fastest.  </