RELATED CASES

This Application is a Continuation of U.S. application Ser. No. 09/241,214 filed Feb. 1, 1999 now U.S. Pat. No. 6,389,477; which is a Continuation of U.S. application Ser. No. 08/196,452 filed Feb. 14, 1994, now U.S. Pat. No. 5,867,688. Each said patent application is assigned to and commonly owned by Metrologic Instruments, Inc. of Blackwood, N.J., and is incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to a system for data acquisition and retrieval through the use of a user interface remotely located from the control system.

2. Description of the Related Art

Today, most commercial businesses require field employees, such as at points of sale, to fill out paper forms with data sets concerning individual customers or products sold/manufactured. These reports are then collected, compiled and assimilated at a central location and filed for future access. Most modern businesses require this information to be continuously updated and that the field personnel be afforded quick access thereto in order to reduce business costs, improve efficiency, increase accuracy, and the like. Heretofore, data sets concerning matters, such as customer or product information, have been primarily compiled through paper forms completed by field personnel and later possibly entered into some form of central database.

In the healthcare field, hospitals utilize a significant amount of data retrieval and acquisition, with respect to patient information. All data sets containing patient information (data field) such as patient name (a data set header), date of birth, place of business, address, phone numbers, language, billing account number, social security number, drivers license number, and the like were written on paper forms and maintained in a paper file, and optionally entered by the hospital staff into a common database. Thereafter, the patient information was supplemented with information pertaining to their health condition, such as vital signs, fluid intake, fluid output and the like, which were written on different paper forms by a nurse and later keyed into this common database. Similarly, when patients undergo testing, the test results were manually keyed into the common database and/or written on forms stored in the patient's paper file.

An alternative example lies in the insurance industry in which field claims adjustors travel to the site of an insurance claim and evaluate the damaged property. These adjustors fill out multiple forms identifying the damage and the insured person's general information. For instance, in an automotive accident the claims adjustor must describe each problem with the insured car, such as dents, scratches, and the like. These forms are later processed manually or keyed into a common database, after which, the claimant ultimately is paid.

A substantial amount of data acquisition and retrieval is also utilized in factory environments. During the course of manufacturing various products, floor workers and quality review must complete multiple forms concerning a given production unit.

However, every business requiring significant amounts of data acquisition and retrieval in its day-to-day business encounter similar problems. First and foremost, a significant amount of the field operative's time is required in filling out the corresponding paperwork, in which the potential for user error exists. Also, in systems using paper forms, the information must be ultimately transferred to an electronic database, which provides a second opportunity for user error. Clearly, it would be advantageous to reduce the number of user entries, thereby reducing the likelihood of error.

Further, in many markets, field personnel at one location typically require information quickly from another field location. For instance, in a hospital environment, a doctor within the general ward may require immediate information concerning a patient from the radiology department. However, the process under which the information is written down and carried between departments is very slow. Similarly, doctors and nurses require immediate and accurate knowledge of specific procedures to be followed with regard to particular patients. Past systems for maintaining individual patient procedures have proven ineffective.

Moreover, one office within a business will typically require information from another office which must be hand carried or which is unavailable after the closing hours of the second office. For instance, hospitals require lab testing results be hand-carried to doctors who may be waiting for such results during the course of surgery. Also, typically doctors require clinical data after the clinics have closed.

The need remains in this field for an improved data acquisition and retrieval system to address the problems and drawbacks heretofore experienced. The primary objective of this invention is to meet this need.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a data acquisition and retrieval system which allows users immediate real time access to all existing customer/product information.

It is an object of the present invention to provide a data acquisition and retrieval system which affords users access to wireless remote data terminals.

It is an object of the present invention to minimize the data retrieval time by reducing the necessary information transmitted between handheld units and the corresponding communications server.

It is another object of the present invention to minimize the data necessary for transmission by synchronizing operation within each handheld unit and a corresponding communications server, such synchronization including the minimization of header information for each transmission and the transmission of a command case code used directly by the command server to access a designated database.

It is another object of the present invention to provide a user interface which minimizes user error.

It is another object of the present invention to provide a user interface which utilizes an event driven architecture to allow data entry through a touch pad.

It is another object of the present invention to provide an user interface which is easily operated by using a touch pad which presents a scroll bar, rolling keys and icons for data entry.

It is another object of the present invention is to provide an user interface which allows for the scanning of bar codes to identify particular customers or products.

These and further objects will become more apparent from the drawings and detailed description hereafter.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects and features of the invention noted above are explained in more detail with reference to the drawings, in which like reference numerals denote like elements, and in which:

FIG. 1

is a block diagram of an overview of a data acquisition and retrieval system according to the present invention;

FIG. 2

illustrates a block diagram of a handheld interface according to the present invention;

FIG. 3

illustrate exemplary display screens shown on the handheld interface according to the present invention;

FIG. 4

illustrates the main processing loop by which the handheld interface monitors and responds to events selected by the user;

FIG. 5

illustrates the processing sequence of the handheld interface while displaying a patient information screen;

FIG. 6

illustrates the processing sequence of the handheld interface to initiate the patient information screen;

FIGS.

7

(

a

) and

7

(

b

) illustrate the processing sequence of the handheld interface while displaying a patient input screen;

FIG. 8

illustrates the processing sequence of the handheld interface to initiate the patient input screen;

FIG. 9

illustrates the data structure of the packets transmitted between the handheld interface and the communications server;

FIG. 10

illustrates the processing sequence undergone by the handheld interface to write data packets to the communications server;

FIG. 11

illustrates the processing sequence by which the communication server reads packets transmitted from the handheld interface;

FIG. 12

illustrates the processing sequence by which the communication server parses through a short header structure within an incoming packet to build the input buffer;

FIG. 13

illustrates the processing sequence by which the communication server parses through a long header structure within an incoming packet to build the input buffer;

FIG. 14

illustrates the processing QUEUE sequence to move completed messages to the processing QUEUE;

FIG. 15

illustrates the processing sequence by which the communication server generates the processing queue;

FIG. 16

illustrates a block diagram of the RAM section of the handheld interface;

FIG. 17

illustrates a block diagram of the communications server;

FIG. 18

illustrates an alternative data entry display for the handheld interface; and

FIG. 19

illustrates the processing sequence of the command server to process and transmit message lists.

DETAILED DESCRIPTION OF THE INVENTION

Overview

FIG. 1

illustrates a data retrieval/acquisition system according to the present invention generally illustrated by the reference numeral

1

. The instant system

1

includes a master server

2

which communicates with multiple remote input units

4

through a communications bus

6

. Each input unit

4

includes a communications server

12

directly connected to a command server

14

and data bases

16

. Each remote communications server

12

interactively communicates with one or more handheld user interfaces

8

while located within a predefined region

5

proximate thereto. This interactive communication is conducted through a wireless dedicated communication channel, such as upon an infrared carrier signal.

The communications server

12

controls all interaction between the handheld interfaces

8

, the command servers

14

, and the communications bus

6

. The command servers

14

control direct access to the databases

16

. The command servers

14

may implement any conventionally known IO management system, such as Pro-Tree (version 2.0), SQL or Paradox. The communications server

12

communicates with each handheld interface

8

through a unique communications protocol (hereafter referred to as the Handheld-Server Protocol). The communications server

12

communicates with the command servers

14

through a unique protocol (hereafter referred to as the Message List Protocol).

As explained below, the communications server

12

synchronizes its operations with those of the handheld interfaces

8

to minimize the excess data necessary for each transmission therebetween. The communications server

12

and interface

8

also utilize shorthand code values to identify constantly transmitted information, such as commands, user IDs, database IDs, and the like. By synchronizing operation of the handheld interface

8

and the corresponding communications server

12

, the instant system is able to avoid the need to transmit the user ID, time, date, authorization code, and the like during every transmission.

During operation, the user enters data at the handheld interface

8

, the data is transmitted to the communications server

12

and stored internally within the database

16

. Data may also be entered directly into the communications server

12

. Similarly, the user may request data previously submitted, in which case the communications server

12

accesses the corresponding database

16

, through the command server

14

, and transmits the necessary desired information to the requesting handheld interface

8

. Throughout operation, a backup copy may be maintained within the master server

2

for every remote database

16

. Additionally, the user may request, via the handheld interface

8

, data stored within a remote input unit

4

other than the data in the databases directly connected to the receiving communications server

12

. In such a circumstance, the corresponding communications server

12

would accept the request from the handheld interface

8

, determine that the desired information is stored within a remote database and request such information through the communications bus

6

from the communications server

12

containing the corresponding database. Thus, the communications bus

6

also allows data to be transmitted between communications servers

12

and between handheld interfaces

8

(such as when one doctor is requesting information from another doctor).

By way of example only, the instant acquisition/retrieval system

1

may be utilized within a healthcare facility wherein doctors, nurses, and staff utilize the handheld interfaces

8

to record and obtain patient information. These persons may be assigned different privileges which would allow varying levels of access to data. In this environment, each communications server may be located within a different ward or testing laboratory. Thus, a doctor in a general ward may need to send a message to, or obtain information from, a doctor or nurse in radiology. To do so, the doctor would transmit a request through the handheld interface

8

, with the request being received and decoded in the general ward's communications server

12

. The source/receiving communications server determines the appropriate destination communications server that corresponds to the destination handheld interface, into which the destination doctor or nurse has signed on. The desired message is transmitted to the radiology server, and to the corresponding handheld interface which queries the user through audio, video, or vibrating means. In a similar manner, the user within radiology may transmit a response through the corresponding radiology and general ward communications servers

12

to the requesting doctor's handheld interface

8

. Also, lab data may be quickly transmitted to a surgeon during an operation.

The instant acquisition/retrieval system

1

also allows doctors, nurses, and staff members immediate access to clinical data, even after clinic hours are closed. To do so, the user merely enters a request through his/her handheld interface

8

, which is transmitted through the corresponding communications server

12

to the clinical communications server

12

. The necessary clinical data is obtained from the clinical database and returned along the communications bus

6

. By way of example, the data acquisition/retrieval system

1

of the healthcare facility may be connected to similar systems via an ethernet connected between the master servers

2

.

The handheld interfaces

8

are used to enter all patient information such as personal information upon admittance, past medical histories, vital statistics throughout their stay in the hospital, and the like. For instance, these vital statistics may include systolic, diastolic, pulse, temperature, and respiratory information. Similarly, the handheld interface

8

may be used to enter information concerning the patient's fluid intake and output.

As will be explained below, the instant data acquisition/retrieval system

1

, also allows a user to carry a handheld interface

8

between regions (see the dashed line

5

in

FIG. 1

) dedicated to each communications server

12

. Optionally, when this occurs, the handheld interface

23

, is considered to have signed off with the old communications server (as illustrated by the dashed line

22

). Thereafter, the handheld interface

23

must be signed onto the new communications server (as illustrated by the line

24

) before it may be used for data entry.

The manner by which these objects and functions is achieved will become clear in connection with the following explanation of each module of the present invention.

Handheld Interface

FIG. 2

generally illustrates a block diagram of a handheld interface

8

having a display screen

30

which may be back-illuminated and which is controlled by a CPU

32

to display desired information thereon. The display screen

30

also functions as a touch pad and is sensitive to user contact. When contacted, the display screen

30

outputs a signal to the CPU

32

identifying the exact location of the contact therewith. The handheld interface

8

further includes a memory module

34

which stores software to control processing of the CPU

32

and which temporarily stores data received from, and transmitted to, the corresponding communications server

12

. The CPU

32

controls an IR interface

36

to control data transmissions to and from the communications server

12

. A bar code reader

37

is included to allow the user to enter customer or product information from a bar code, such as customer/patient ID and the like.

As explained below, the handheld interface

8

operates as an “event driven” device wherein the touch screen

30

is drawn to display a desired arrangement of virtual regions. Each region is assigned a unique identifier. The handheld interface

8

recognizes each contact by a user as an event. The contact/event is recognized with respect to the correspondingly defined region and the region identifier is returned. Thereafter, the CPU

32

identifies the necessary course of action based upon this identifier.

As illustrated in

FIG. 3

, during operation the CPU

32

may display a variety of menus, graphs, and the like upon the touch screen

30

. Within each display, the CPU

32

defines virtual regions which correspond to predefined processing sequences. The user initiates a desired event sequence by contacting the preferred region corresponding to the event. To facilitate the user interaction therewith, the CPU

32

provides multiple manners in which the user may enter and retrieve data. As illustrated in FIG.

3

(

a

), the CPU

32

draws a main menu

38

on the screen

30

and defines multiple menu selections

40

therein (see the flowchart of FIG.

10

). Each menu selection

40

overlays and corresponds to a virtual event region

42

corresponding to a different event/case. Every screen

30

is displayed with an escape key

43

which allows the user to escape back to a previous function/screen or back to the main menu.

When implemented in a healthcare application, as illustrated in

FIGS. 3

a

-

3

d

, when the user selects a vitals event region

44

, the CPU

32

recognizes it as such and processes a corresponding event sequence (see FIG.

13

).

As illustrated in

FIG. 3

c

, the vitals input screen

60

(also referred to as the data I/O screen) displays current patient information in the patient field

62

, such as the patient's name, social security number, status, and the date upon which the vitals were last updated. The vitals input screen

60

illustrates the last current vitals (data sets) as shown in the systolic field

46

, diastolic field

48

, pulse field

50

, temperature field

52

, and respiratory field

54

(collectively referred to as data fields). The touch screen

30

allows the user to activate a desired vital sign field by selecting a corresponding icon

46

,

48

,

50

,

52

, and

54

, respectively. Located immediately above each icon is the current value for the corresponding vitals field. This current value is also displayed within three rolling keys along side of the icon (the rolling keys are designated by the reference numeral

56

). The patient's systolic vital sign field is active in

FIG. 3

c

, as evidenced by the inverted rolling keys

56

. Proximate the rolling keys

56

is a scroll bar

58

for illustrating in a bar format the current value of the active vital sign field (i.e., systolic) which is inverted to the current level (130).

To enter new patient vitals, the user may do so in multiple ways. First, the user may update the patient's systolic vitals by consecutively contacting each rolling key

56

to be incremented. Each rolling key continuously increments, such as from 0 to 9 and then back to 0. Alternatively, the user may enter patient vitals information by contacting the scroll bar

58

at the desired position. In accordance with the flowchart of

FIG. 13

, when the user contacts the scroll bar

58

, the bar is updated to reflect the newly entered value. If the user drags his/her finger along the scroll bar

58

, the CPU

32

will continuously update the level thereof to reflect this movement of the finger. The CPU

32

updates the corresponding rolling keys

56

for the active field (i.e., the systolic field as illustrated in FIG.

3

(

c

)). The user may drag his/her finger across the scroll bar

58

until the desired value is displayed in the rolling keys

58

, at which time the user releases the scroll bar. The user may activate a different vital sign field (i.e., change the mode) by selecting the corresponding icon (

46

,

48

,

50

,

52

, and

54

).

The vitals input screen

60

further includes change function keys

64

which afford the a user's direct access to displays, graphs, screens and the transmit function. More specifically, the vitals input screen

60

allows the user direct access to the fluids input screen (not shown) for the current patient by pressing the fluids function button

66

. Alternatively, the user may view the selected vital sign field (e.g., systolic field) in a graph format by selecting the view graph button

68

. The vitals input screen

60

further includes a transmit information button

70

which the user selects once a patient's new vital information has been entered. When the transmit button

70

has been pressed, the CPU

32

transmits the updated patient information to the communications server

12

in a format described below.

FIG.

3

(

b

) illustrates a graph corresponding to the present patient's systolic vitals which is displayed when the view graph button

68

is selected.

FIG.

3

(

d

) illustrates a patient inquiry screen

74

selected from the main menu

38

(also referred to as the data set inquiry screen). The patient inquiry screen

74

displays a scrolling text window

78

which exhibits the currently selected patient's name (data set header) and those names alphabetically proximate thereto. Along one side of the scroll text window

78

is positioned a scrolling bar

80

which includes an identifier

82

designating the position of the currently selected patient's name within a master alphabetical list. The user may scroll through the patient list by contacting the scrolling bar

80

at a desired location therealong. The top and bottom of the scrolling bar

80

corresponds to the beginning and end, respectively, of the list of patient names stored within the handheld interface

8

.

The patient inquiry screen

74

also includes a virtual keypad

76

which allows the user to enter the name of a desired patient. As the user selects each letter of the desired patient's name, the CPU

34

automatically performs a search upon the entered letters and updates the scroll text window

78

correspondingly. As the user enters additional letters, the CPU

32

concatenates these letters to the end of the search string it uses and again updates the scrolling text window

78

. The patient inquiry screen

74

also includes function buttons

64

along a bottom thereof to allow the user to automatically jump to an alternative screen. A scan button

77

is included to allow the user to read bar code data from a patient's wrist band, such as patient ID.

FIG. 18

illustrates an alternative scroll bar implementation which may be used to allow the user to enter alphanumeric information. For instance, the CPU

32

may control the display screen

30

to illustrate a display field

90

and one or more scroll bars

92

. The scroll bar

92

may be defined such that one end corresponds to the letter A while the opposite end corresponds to the letter Z. The CPU

32

would define multiple regions along the length of the scroll bar

92

, each region corresponding to one letter of the alphabet. When the user contacts the scroll bar

92

, a letter corresponding to the touched regions is displayed in a first location

94

of the display field

90

.

As the user drags his/her finger along the scroll bar, the letter displayed within the first location

94

will vary corresponding to the currently selected region. Once the user removes his/her finger from the scroll bar

92

, the last identified region is designated as the correct letter and entered in the first location

94

of the display. When the user again contacts the scroll bar

92

, the CPU

32

operates to display a corresponding letter in the second field location

96

of the display field

90

.

If it is desirable to enter numerals within the display field

90

, the CPU

32

may also draw a second scroll bar

98

upon the display screen

30

. The first end of the second scroll bar would represent a 0 while the second end of the scroll bar

98

would represent a

9

. The user would enter numerals in the display fields

90

in the same manner as discussed above with respect to letters. Optionally, a single scroll bar may be provided for letters and numerals with function buttons

100

and

101

being used to assign letters or numerals to the scroll bar.

FIG. 15

illustrates the RAM section

35

of the memory within the handheld interface

8

. The RAM memory

35

includes a patient information section

200

for storing a list of patient names (data set headers) and patient identifiers (data set identifiers) associated with the present user of the handheld interface

8

. The RAM memory

35

also includes a working space

202

for storing all other information entered by the user and transmitted between the handheld interface

8

and the communications server

12

. Each time the CPU

32

transmits a request to the communications server

12

for patient information, the CPU

32

redefines the current data structure within the working space

102

to correspond to the expected format of the return data from the communications server

12

.

By way of example only, when the CPU

32

requests patient vitals, it expects the returned data to include, in a preset order, the patient's social security number, date on which the patient vitals were last updated, and the most recent systolic, diastolic, pulse, temperature and respiratory values. The CPU

32

sets up fields within the working space

202

for each of these values. When the returned data is received, the CPU

32

parses through the returned packet and assigns bytes therefrom to the desired field in the working space

202

.

The RAM

35

further includes a temporary buffer for storing incoming and outgoing packets of information which are to be transmitted to and which are received from the communication server

12

. The CPU

32

moves data from the RAM

35

into the temporary buffer

204

immediately before transmitting this information and adds a packet header

206

thereto.

FIGS. 4-8

illustrate the processing sequence by which the CPU

32

controls the main menu, vital sign patient/data set input screen and the patient information screen (

FIGS. 3

a

-

3

d

).

Generally, during operation the CPU

32

loops through one of two primary case/event handling loops (FIG.

4

). The first case/event loop operates to draw the main menu (

FIG. 3

a

) and to handle events chosen from the main menu. When an event occurs which corresponds to a defined key region within the main menu, a corresponding event identifier is returned as the calling identifier. A return code is set equal to this calling identifier and the return code is checked against a predefined value (0). If the return code is non-zero, processing flow enters the second primary loop to call the corresponding event handling function. The second primary loop corresponds to processing in which a menu other than the main menu is displayed (

FIGS. 3

b

-

3

d

). During this second loop, a code which identifies the next function to be performed is continuously checked. When the code equals zero, processing returns to the main loop. When the code is a nonzero value, the corresponding function is called. Once each function is completed it returns a code identifying the next function to be performed by the user. This configuration reduces the memory requirements by reducing the levels of functions to be called, thereby reducing the necessary stack space.

FIG. 4

generally illustrates the processing undergone by the handheld interface

8

when the user initiates the first session (i.e., when the user first logs in). When a session is initiated the handheld unit prompts the user for the user's ID and password (step

1602

). Next, a packet is constructed in the temporary buffer

204

which contains a long header

206

structure and having a data section including the user ID and password (step

1604

). This packet is transmitted (step

1606

) and a validation code therefor is waited upon. If the validation code is not received (step

1608

) processing returns to step

1602

in which the user is reprompted for the ID and password. If a validation code is received, processing continues to step

1610

in which a return code is set to indicate that processing should move to the patient inquiry module. Thereafter, the return code is tested to determine whether it equals zero (step

1623

). If the return code equals zero, processing returns to step

1614

in which the main menu is redrawn.

After this initial login sequence is completed, flow enters the main event handling loops. First, a main menu is drawn and key regions therein are defined in steps

1612

and

1614

, after which the system waits for an event to occur (step

1616

). Once an event occurs, it is determined whether the event is within a defined menu regions

42

(step

1618

) (i.e., whether the user has touched the display screen

30

at a location corresponding to a menu selection

40

). If not, processing loops back to wait for the next event. If so, an event identifier is obtained for the key region in which the event occurred (step

1620

). Next, an event handling function corresponding to the event identifier is called (step

1622

). Thereafter, processing waits for a call identifier returned from the called event handling function. A return code is set equal to the call identifier (step

1623

) and the return code is tested in step

1624

and if zero, processing returns to the initial step

1612

to redefine and redraw the main menu. If the return code does not equal zero, the process determines that the user has selected another function besides displaying the main menu. Thus, the event handling function corresponding to the non-zero return code is called (step

1626

). Thereafter, the main event handling loop waits for the called function to return a call identifier which is tested in step

1624

.

FIGS. 5 and 6

illustrate the process undergone when the patient information screen

74

is selected to be displayed (such as during the wake up function or when called by the user). First, an initialization routine is called in step

1700

(steps

1710

-

1720

in FIG.

6

). This initializing process begins by determining whether the handheld interface

8

includes a list of patient names (data set headers) and IDs (step

1710

). If this list does not exist (such as when the handheld interface has initially been woken up), the unit constructs and transmits a packet to the communications server

12

requesting the patient list associated with the currently signed-in user (step

1712

). The communications server

12

receives this packet, identifies the user ID, and requests the appropriate information from the command server

14

. Thereafter, the appropriate database

16

is read and the patient list for the user is transmitted back to the handheld interface

8

. After the interface

8

sets up the data structure in the patient memory

200

for the patient list (step

1714

), it waits for the returned patient list (step

1716

). Once the patient list (name and ID) is received, it is stored in the patient memory

200

.

The handheld interface

8

may not include sufficient display space in the scrolling text window

78

to show an entire patient's name. Thus, the patient memory section

200

will only include sufficient memory to store the maximum number of characters which may be displayed for a single patient name upon the screen. Once the patient list is stored, the patient screen format is displayed (step

1718

) as illustrated in

FIG. 3

d

. Next, the patient names are displayed in the scrolling text window

78

(step

1720

) (

FIG. 3

d

). When the patient list is too long to be completely displayed within the scrolling text window

78

, a default portion thereof is displayed. Next, the system waits for an event (step

1722

, in

FIG. 6

) and when one occurs, an event identifier is assigned thereto.

The event identifier is passed to a case/event statement which includes every possible valid value for the event identifier. By way of illustration, processing will continue along one of six possible processing paths to blocks

1724

,

1726

,

1728

,

1730

,

1750

or

1756

, depending upon which event occurred. When event

1724

occurs (i.e., the user presses the escape icon), the system returns a zero calling identifier to the main loop (thereby indicating that no new event handling function has been selected). If the event indicates that the user has touched the scrolling bar

80

, processing flows to box

1726

in which the system determines the exact location of the event (step

1732

). This location is correlated with a pointer that is used as an index into the patient list to identify the new patient to be displayed in the scrolling text window

78

. Once the event location is determined, the pointer into the patient list is updated and the scrolling text window

78

is redrawn to display the name of the selected patient and a limited number of patient names surrounding the selected name (step

1734

).

Next, the scrolling bar

80

is updated to move the identifier

82

to a new position identifying the relative location of the indexed patient within the overall patient list (step

1736

). Thus, if the first patient is selected, the identifier

82

is redrawn at the top of the scrolling bar

80

, and if the last patient is selected, the identifier

82

is drawn at the bottom of the scrolling bar

80

. If the event is identified as occurring within the scrolling text window

78

, processing flows to step

1728

. Specifically, the location of the event is again identified (step

1738

) relative to the names currently displayed. The name closest to the event is identified as the selected patient. Thereafter, the pointer into the patient list is updated to index the newly selected patient name (step

1740

). This name is displayed in the center of the scrolling text window and, optionally, may be inverted in color (step

1740

). The identifier

82

within the scrolling bar

80

is also redrawn to properly identify the new position of the selected patient within the patient list (step

1740

).

If the keypad

76

is touched, processing flows to block

1730

, at which the letter is identified which corresponds to the region touched (step

1742

). This selected letter is added to a temporary patient searching string within the work space memory

102

(step

1744

). This letter is added to a search string (which is empty until the first letter is selected). Thereafter, the processor conducts a search based upon the search string into the patient list to identify the name most closely corresponding to the letter(s) selected from the virtual keypad

76

(step

1746

). If a search string exists (i.e., the user has already entered some letters) the newly selected letter is concatenated onto the search string and a new search is conducted upon the text strings within the patient list to find the first text string which is greater in alphabetic value than (i.e., closest to) the search string. The pointer is set to the closest patient name and the scrolling text window

78

and the scrolling bar

80

are updated (steps

1746

and

1748

). If the user wishes to delete a letter from the search string, he/she simply pressing the delete region key.

If the user selects the scan region

77

, processing flow moves to block

1750

. The bar code scanner is read to obtain the bar code scanned by the user (step

1752

) (this bar code may appear on a patient's wrist band and the like). The bar code includes the patient ID, which is used to find the patient name within the patient list (step

1754

). Next, the pointer into the patient list is updated (step

1756

) and the scrolling text window

78

and scrolling bar

80

are redrawn (step

1758

).

Once the user has selected a desired patient, the user may escape from the patient inquiry screen by pressing the escape icon

43

in the upper left corner or by selecting one of the function

64

buttons at the bottom of the screen (step

1760

). As illustrated in

FIG. 3

d

, the user may escape to the main menu, review a patient's information complete record or review the patient's vitals. If the user presses one of the change function buttons

64

at the bottom of the screen, the corresponding event identifier is evaluated to determine which function key the user has selected (step

1762

) and the corresponding return code is returned to the main processing loop in

FIG. 16

(step

1764

).

FIGS. 7

a

,

7

b

and

8

illustrate the processing sequence undergone by the handheld interface

8

when the vitals/data input/output handling function is chosen (i.e., when a user desires to enter patient vitals). First, the display screen is cleared (step

1800

) and the vitals (data I/O) format is drawn upon the screen (step

1802

). Similarly, the key regions are defined which correspond to each even identifier. Next, it is determined whether the workspace memory contains vitals for a selected patient (step

1804

). If not, the processor constructs and transmits a packet (step

1806

) requesting patient vitals. Thereafter, the workspace memory

202

is set up in the data structure corresponding to patient vitals (step

1808

). Thereafter, the handheld interface waits for the returned patient vitals, receives these vitals in one or more packets and disassembles the packets and stores the patient vitals in the workspace (step

1810

). Next, the processor draws the patient vitals onto the screen (step

1812

) and sets the default mode to a predetermined field (e.g., systolic field). The vitals for the default field are drawn into the scroll bar (step

1814

) and the default rolling keys

56

corresponding to the default field are inverted. Thereafter, the handheld interface waits for an event to occur (step

1816

in

FIG. 7

a

) and when it occurs, identifies the event number corresponding thereto.

Processing flows along one of six paths depending upon which event number is identified. While each field upon the vitals screen corresponds to a separate event number, the events as displayed in

FIG. 8

may be grouped into six general categories, namely, touching a roll key, touching the icon, touching the scroll bar, touching the patient's general information, touching the escape key, and touching the change screen buttons (blocks

1818

,

1830

,

1840

,

1852

,

1858

and

1864

). Once the event number is identified as corresponding to a rolling key

56

, it is determined whether the touched rolling keys are active (step

1819

). If not active, processing returns to step

1816

. If active, a pointer is determined which identifies the field within the workspace memory

202

which corresponds to the specific roll key/vital sign selected (step

1820

).

Next, the data value identified by the pointer into the workspace is incremented by a 1, 10, 100, etc. depending upon the rolling key which was touched (step

1822

). Thus, referring to

FIG. 3

c

, if the user presses the center rolling key corresponding to the systolic field, the systolic data value within the workspace memory will be incremented by 10. Similarly, if the diastolic field is selected and the user presses the leftmost rolling key therein, the processor will increment the diastolic data value within the workspace memory by 100. Next, it is determined whether or not the incremented value has created an overflow and if so, the incremented digit is rolled-over (step

1824

). This rollover function is performed to rotate a rolling key having a current value of 9 to a new value of 0.

Thus, if the user selects the pulse vital and contacts the “1s” rolling key (which has a present value of 9), the processor will update the pulse value within the workspace memory to “80”. Thereafter, the new vital sign is drawn into the rolling keys

56

which have been updated and the new vital sign is stored in the corresponding field in the workspace memory (step

1824

). Finally, the processor updates the scroll bar

58

to reflect the change in the current data value (step

1826

).

If the event identified in step

1816

corresponds to an icon, processing proceeds to step

1830

. First, the rolling keys are deactivated for the previously active vital sign field (step

1832

) and the rolling keys for the newly chosen vital sign are activated (step

1834

). Next, the rolling keys for the deactivated and newly activated vital sign fields are inverted to display the newly active field to the user (step

1836

). Thereafter, the scroll bar

80

is redrawn with parameters, ranges and current vital signs corresponding to the newly selected vital sign field (step

1838

).

When the identified event corresponds to touching the scroll bar

80

, process flows to step

1840

. Once the scroll bar is touched, the exact location of the event is determined therein and used to identify the corresponding vital sign value (step

1842

). Then, a pointer is determined which identifies the vital sign data value within the workspace memory which corresponds to the active vital sign field (step

1844

). This vital sign data value is updated to the new vital sign value selected within the scroll bar (step

1846

). Thereafter, the active scroll keys are updated with the new data value (step

1848

) and the scroll bar is inverted to reflect the new data value (step

1850

). When the event occurs within the patient information region, processing flows to step

1852

. In such a case, the patient information screen is redrawn. To do so, a calling identifier is set to correspond to the patient information screen (step

1854

) and control is returned to the main loop (step

1856

).

Optionally, when the user touches the patient information region, a pop-up window may appear and query the user as to whether it is desirable to go to the patient information screen or enter a patient identifier through the bar code reader. In either case, if the user touches the patient information region, before new patient vital signs have been transmitted to the communication server, the user is prompted as to whether or not these vital signs should be transmitted. When the escape icon is touched, processing flows to step

1858

, after which the calling identifier is set to zero (step

1860

). Processing is returned to the main loop (step

1862

).

If the screen changing buttons are touched, processing flows then to step

1864

, after which the selected button is determined (step

1866

). In step

1867

, it is determined whether the event corresponds to the transmit button. If the selected button corresponds to the transmit button, the current patient vitals are constructed into a packet format and transmitted to the communication server

12

(step

1868

). If the selected button does not correspond to the transmit button, the calling identifier is set equal to the newly selected screen (step

1870

). Thereafter, control is returned to the main loop (step

1872

).

When the return code within the main loop is set to correspond to the view graph display screen (

FIG. 3

d

), the processor determines the active vital sign field (e.g., systolic field), and obtains the corresponding default parameters for the graph. Thereafter, the screen is cleared and a graph having the parameters for the active vital sign field is drawn. Next, the vital sign data values for the active vital sign field are read from the workspace memory and used to draw the graph.

Optionally, in the view graph screen a series of changing function buttons may be displayed along the bottom thereof. These buttons would allow the user to automatically select another vital sign to view in a graph format without intermediately returning to the vital input screen.

In accordance with the above procedure, the handheld interface

8

allows for user inputs and displays patient information to the user.

Interface-Server Protocol

Once the user enters the desired data and wishes to send this data to the communications server

12

, the user presses the transmit function button

70

. Once the CPU

32

identifies that an event has occurred which corresponds the transmit function button

70

, the main loop (

FIG. 4

) calls the transmit handling function.

FIG. 4

illustrates the process by which the CPU

32

transmits data to the communications server

12

.

As illustrated in

FIG. 9

, each transmission comprises an information packet

300

of IR signals corresponding to a packet of data, wherein every packet is constructed with the same predetermined length (e.g., 128 bytes) and in one of two formats. This length is software and operative system definable and may vary. Certain messages transmitted between the handheld interfaces

8

and the corresponding communication servers

12

comprise an amount of data which is unable to be assembled into a single packet. Thus, in such circumstances the transmitting device segments the data into a plurality of equal length packets

300

(referred to as frames). The series of frames form a message

302

.

When transmitting a message the first packet/first frame thereof is constructed with a header section

304

formed in a long header structure followed by a data field

306

. The long header

304

includes a 4 byte command field

308

, a 6 byte user identifying field

310

, and a 4 byte message total field

312

. The command field

308

identifies the process to be performed upon the subsequent data, the user ID identifies the user signed into the handheld interface

8

transmitting or receiving the packet

308

and the message total

312

identifies the total length of the message which will follow. This total length includes all bytes within subsequent packets

300

corresponding to this specific message

302

. Thereafter, a data field

314

(having 114 bytes in a packet with a 128 byte structure) follows.

If the message includes more data than will fit in a single packet, subsequent packets/frames are transmitted. These subsequent packets/frames are constructed with a short header structure

316

preceding the data segment

318

. The short header

316

includes a 4 byte command

320

and a 4 byte positioning packet

322

identifying number to enable the receiving device to determine the position of the packet within the overall message. Packets containing a short header

316

includes a 120 byte data field for a packet formed with 128 bytes. During transmission, the first packet of each message includes a long header

304

structure followed by a data field, with each subsequent packet within the message including a short header

316

instructed followed by a data field. In this manner, the device is able to increase the amount of data transmitted within each packet for long messages. The transmitting device need not send the user ID and the message total more than once for a given message since the receiving device is able to associate corresponding packets with a single message

302

based on the packet number

322

and communication channel.

To transmit a message (FIG.

10

), the CPU

32

reads the current data from the workspace memory

200

in the RAM

35

(step

400

). Next, the CPU

32

determines the length of the message and the ID of the user signed in to that handheld interface

8

(step

402

). The CPU

34

constructs a packet header formed with the long header structure (step

404

). The CPU

34

clears the packet number (step

406

) and writes the data to the transmit buffer (step

408

). If the packet is full (step

410

), the CPU

32

transmits the packet and clears the buffer (step

412

). If the packet is not full, it determines if more data exists to write to the buffer (step

414

). If no more data exists, it transmits the packet. If more data exists, it again writes to the packet. In step

416

, it is determined if more data exists, and if not it exits. If so, the packet number is incremented (step

418

). Next, the CPU