Remote data collecting and address providing method and apparatus

Abstract

An information system network and method for use thereof for remotely gathering information and storing the information at specific network memory locations for easy access, the system including at least a remote information collecting device and a network including an input device and a memory storage device, the collecting device in remotely gathering information and, based on the information gathered, generating storage addresses and browser configuration information to enable easy review and modification of collected information and subsequent storage.

Claims

I claim:

1. An apparatus for use with a network system including an input device and a network device linked to the input device, the input: device equipped to receive information including information units and network device target addresses associated with information units, the input device also capable of transferring the received units to associated target addresses, the apparatus for remotely collecting at least one information unit, correlating the at least one unit with at least one target address and providing the information unit and target address to the input device, the apparatus comprising:

a collector for remotely collecting the at least one information unit;

a memory;

a processor linked to the collector for receiving the at least one information unit therefrom and also linked to the memory for providing the information unit thereto and accessing information units stored therein, the processor also providing a target address for the collected information unit;

an output device linked to the processor for transmitting the information unit and target address to the input device; and

a clock linked to the processor for identifying the time, when collected information is received by the processor, the processor identifying an event time and including the event time in an associated information unit.

2. The apparatus of claim 1 wherein information units and target addresses are collected and transmitted via wireless communication and the collector and output device are both included in a transceiver which collects and transmits information units.

3. The apparatus of claim 1 wherein the processor generates target addresses for collected information units.

4. A method for use with a network system including a remote data collector device, an input device and a network device linked to the input device, the collection device including a collector, a memory, a processor and an output device and for remotely collecting information units and providing the units to the input device, the input device equipped to receive information including information units and network device target addresses associated with information units, the input device also capable of transferring the received units to associated target addresses, the method for remotely collecting information and providing the collected information to target addresses on the network device, the method comprising the steps of, using the collection device:

(i) collecting at least one information unit;

(ii) when the at least one information unit is collected, identifying an event time and adding the event time to the information unit;

(iii) providing a target address for the collected information unit; and

(iv) transmitting the information unit and target address to the input device.

5. The apparatus of claim 1 wherein the apparatus is used by a specific user, a user identifier is stored in the memory and the processor includes the user identifier in the information unit.

6. An apparatus for use with a network system including an input device and a network device linked to the input device, the input device equipped to receive information including information units and network device target addresses associated with information units, the input device also capable of transferring the received units to associated target addresses, the apparatus for remotely collecting at least one information unit, correlating the at least one unit with at least one target address and providing the information unit and target address to the input device, the apparatus comprising:

a collector for remotely collecting the at least one information unit;

a memory;

a processor linked to the collector for receiving the at least one information unit therefrom and also linked to the memory for providing the information unit thereto and accessing information units stored therein, the processor also providing a target address for the collected information unit;

an output device linked to the processor for transmitting the information unit and target address to the input device;

wherein the apparatus is used to collect a plurality of information units, the processor provides a different target address for each of the collected information units, the output device transfers the collected units and associated target addresses to the input device.

7. The apparatus of claim 1 further including an audio sensor and wherein, when audio information is collected, the processor forms an information unit therefrom and provides a target address therefore for delivery to the input device via the output device.

8. The apparatus of claim 1 further including a video sensor and wherein, when video information is collected, the processor forms an information unit therefrom and provides a target address therefore for delivery to the input device via the output device.

9. An apparatus for use with a network system including an input device and a network device linked to the input device, the input device equipped to receive information including information units and network device target addresses associated with information units, the input device also capable of transferring the received units to associated target addresses, the apparatus for remotely collecting at least one information unit, correlating the at least one unit with at least one target address and providing the information unit and target address to the input device, the apparatus comprising:

a collector for remotely collecting the at least one information unit;

a memory;

a processor linked to the collector for receiving the at least one information unit therefrom and also linked to the memory for providing the information unit thereto and accessing information units stored therein, the processor also providing a target address for the collected information unit;

an output device linked to the processor for transmitting the information unit and target address to the input device; and

at least first and second target address indicating buttons linked to the processor, the first button indicating a first target address and the second button indicating a second target address and wherein, when the first button is selected, the processor correlates the first-target address and a collected information unit and when the second button is selected the processor correlates the second target address and the collected information unit.

10. The apparatus of claim 1 wherein a browser which communicates in a computer language is loaded onto the input device and the apparatus formats information units and target addresses in the computer language prior to transmitting to the input device.

11. The apparatus of claim 10 wherein the computer language is a markup language.

12. The apparatus of claim 1 wherein the network device is a memory storage device and the target address specifies a specific network device address.

13. An apparatus for use with a network system including an input device and a network memory storage device linked to the input device, the input device equipped to receive information including information units and network device target addresses associated with information units, the input device also capable of transferring the received units to associated target addresses, the apparatus for remotely collecting at least one information unit, correlating the at least one unit with at least one target address and providing the information unit and target address to the input device, the apparatus comprising:

a collector for remotely collecting the at least one information unit;

a memory;

a processor linked to the collector for receiving the at least one information unit therefrom and also linked to the memory for providing the information unit thereto and accessing information units stored therein, the processor also providing a specific network device target address for the collected information unit;

an output device linked to the processor for transmitting the information unit and target address to the input device; and

wherein the memory storage device includes several network servers, the input device is capable of receiving more than one target address for each information unit and storing an information unit at more than one target address, and the processor is capable of correlating an information unit with more than one target address and transmitting more than one target address for each information unit.

14. The apparatus of claim 1 wherein the input device includes a display and a browser is loaded onto the input device and is capable, when a display format is provided, of displaying information on the display, the processor further providing a display format for each information unit.

15. The apparatus of claim 14 wherein the processor provides display formats which specify browser interaction tools, the interaction tools useable by a system user to modify or approve information displayed on the display.

16. The apparatus of claim 15 wherein the interaction tools include icons and pull down windows.

17. A network system for information gathering, storage and retrieval, the system including:

(a) a collection device comprising:

(i) a collector for remotely collecting at least one information unit;

(ii) a memory;

(iii) a processor linked to the collector for receiving the at least one information unit therefrom and also linked to the memory for providing the information unit thereto and accessing information units stored therein, the processor also providing a network device target address for the collected information unit; and

(iv) an output device linked to the processor for transmitting the information unit and target address;

(b) a network device;

(c) an input device equipped to receive transmitted information units and associated target addresses, the input device also capable of transferring the received units to associated network device target addresses; and

a specifier apparatus which provides a target address for information to be collected by the collection device wherein, the collector receives the target address, the processor stores the target address and, when an information unit is later collected, the processor correlates the collected information unit and the target address for transmission to the input device.

18. A method for information gathering, transmission and retrieval and for use with a system including a collection device, an input device and a network device linked to the input device, the method also for use with a specifier apparatus which provides a target address for information to be collected by the collection device, the method comprising the steps of:

using the specifier apparatus, providing a target address to the collection device;

(a) using the data collection device for:

(i) storing the target address;

(ii) remotely collecting at least one information unit;

(iii) correlating the collected information unit and the target address for transmission to the input device; and

(iv) transmitting the information unit and target address to an input device;

(b) when the input device receives information units and associated addresses, transferring the received units to associated target addresses.

19. The system of claim 17 wherein an information packet includes at least an information unit and a target address and the system input device can receive the information packet and identify each of the information unit and the target address and wherein, prior to transmitting the information unit and the target address, the processor combines the information unit and the target address forming an information packet and the output device transmits the information packet to the input device.

20. The system of claim 17 further including a specifier apparatus which provides both an information unit and an associated target address as an information packet to be collected by the collection device wherein, the collector receives the information packet, the processor stores the information packet and, when the input device receives the information packet, the input device identifies the information unit and the target address and transmits the information unit to the target address.

21. The system of claim 20 wherein the specifier apparatus includes a plurality of specifier apparatuses, each specifier apparatus providing a separate information packet, the collector receiving each information packet, the processor storing each information packet and, when the input device receives the each information packet, the input device transmits the information unit in each packet to an associated target address.

22. The system of claim 17 wherein the collection device is used by a specific user, a user identifier is stored in the memory and the processor includes the user identifier in the information unit.

23. The system of claim 17 wherein the input device is also equipped to interrogate a user and only allows valid system users to transmit information units thereto.

24. The system of claim 17 wherein a browser which communicates in a computer language is loaded onto the input device and the collection device formats information units and target addresses in the computer language prior to transmitting to the input device.

25. The system of claim 17 wherein the network device is a memory storage device.

26. The system of claim 25 wherein the memory storage device includes several network servers and the processor provides target addresses which specify addresses on at least one of the servers.

27. An apparatus for use with a remote data collection device and a network system, the system including an input device and a network device, the input device equipped for receiving and transmitting information units to network device addresses, the collection device for remotely collecting information units and providing the information units and associated network device target addresses to the input device wherein the target addresses indicate where collected information is to be transmitted, the apparatus for providing target addresses to the collection device, the collection device including a collector, the apparatus comprising:

a processor including an address specifier indicating a target address for collected information; and

a specifier transmitter linked to the processor for transferring the target address to the collector.

28. The apparatus of claim 27 wherein the network device is a memory storage device, the processor is linked to the memory storage device and, when an information unit is stored at a memory storage device target address, the processor identifies that the information unit has been stored.

29. The apparatus of claim 28 further including an indicator and a timer and wherein an event associated with an information unit is to occur within a specific time period and the processor monitors the specific time periods and, wherein, when a time period expires prior to an information unit associated with the event being stored, the processor indicates that the event did not occur within the specific time period via the indicator.

30. The apparatus of claim 29 wherein the indicator is an alarm.

31. The apparatus of claim 27 wherein the apparatus is a first apparatus in a system which includes other apparatus and the information unit is received from one of the other apparatuses.

32. The apparatus of claim 27 wherein the apparatus also provides the collected information unit and the processor correlates the information unit with the target address forming an information packet and the output device transfers the information packet to the collection device.

33. The apparatus of claim 27 wherein the input device includes a display and a browser is loaded onto the input device and is capable, when a display format is provided, of displaying information on the display, the processor further providing a display format for each information unit.

34. The apparatus of claim 33 wherein the processor provides display formats which specify browser interaction tools, the interaction tools useable by a system user to modify or approve information displayed on the display.

35. The apparatus of claim 34 wherein the interaction tools include icons and pull down windows.

36. The apparatus of claim 27 wherein the apparatus is capable of providing more than one target address for a single information unit.

37. The apparatus of claim 27 wherein the input device and collection device communicate in a computer language and the output device provides the target addresses in the computer language.

38. The method of claim 5 wherein the collection device is used by a specific user and, prior to transmitting, the method includes the step of adding a user identifier to the information unit.

39. A method for use with a network system including a remote data collection device, an input device and a network device linked to the input device, the collection device including a collector, a memory, a processor and an output device and for remotely collecting information units and providing the units to the input device, the input device equipped to receive information including information units and network device target addresses associated with information units, the input device also capable of transferring the received units to associated target addresses, the method for remotely collecting information and providing the collected information to target addresses on the network device, the method comprising the steps of, using the collection device:

(i) collecting at least one information unit;

(ii) providing a target address for the collected information unit;

(iii) transmitting the information unit and target address to the input device; and

wherein the method is used to collect a plurality of information units and the method further includes the steps of providing a separate target address for each of the collected information units and transferring the collected units and associated target addresses to the input device.

40. A method for use with a network system including a remote data collection device, an input device and a network device linked to the input device, the collection device including a collector, a memory, a processor and an output device and for remotely collecting information units and providing the units to the input device, the input device equipped to receive information including information units and network device target addresses associated with information units, the input device also capable of transferring the received units to associated target addresses, the method for remotely collecting information and providing the collected information to target addresses on the network device, the method comprising the steps of, using the collection device:

(i) collecting at least one information unit;

(ii) providing a target address for the collected information unit; and

(iii) transmitting the information unit and target address to the input device; and

wherein the collection device further includes at least first and second target address indicating buttons linked to the processor, the first button indicating a first target address and the second button indicating a second target address and wherein the method includes the steps of, when the first button is selected, correlating the first target address and a collected information unit and when the second button is selected correlating the second target address and the collected information unit.

41. The method of claim 4 wherein a browser which communicates in a computer language is loaded onto the input device and the method formats information units and target addresses in the computer language prior to transmitting to the input device.

42. The method of claim 41 wherein the computer language is a markup language.

43. The method of claim 4 wherein the network device is a memory storage device and the target address specifies a specific network device address.

44. The method of claim 4 wherein the input device includes a display and a browser is loaded onto the input device and is capable, when a display format is provided, of displaying information on the display, the method further including the step of providing a display format for each information unit and transmitting the display format with the information unit to the input device.

45. The method of claim 44 wherein the step of providing display formats includes providing display formats which specify browser interaction tools, the interaction tools useable by a system user to modify or approve information displayed on the display.

46. The method of claim 45 wherein the interaction tools include icons and pull down windows.

47. The method of claim 18 wherein an information packet includes at least an information unit and a target address and the input device can receive the information packet and identify each of the information unit and the target address and wherein, prior to transmitting the information unit and the target address, the step of correlating includes the step of combining the information unit and the associated target address to form an information packet and the step of transmitting includes the step of transmitting the information packet to the input device.

48. The method of claim 18 further including a specifier apparatus which provides both an information unit and an associated target address as an information packet to be collected by the collection device wherein, the method including the steps of, using the specifier apparatus, providing an information packet to the collection device, using the collection device, storing the information packet and thereafter transmitting the information packet to the input device and, using the input device transferring the information unit to the target address.

49. The method of claim 18 wherein the collection device is used by a specific user and the method includes the step of, using the collection device and after the step of collecting, including the user identifier in the information unit.

50. The method of claim 18 further including the step of, prior to transmitting, interrogating the ICD to determine if an ICD user is a valid system user and only allowing transmission if the user is a valid user.

51. The method of claim 18 wherein a browser which communicates in a computer language is loaded onto the input device and the method includes the step of, using the collection device, formatting the information units and target addresses in the computer language prior to transmitting to the input device.

52. The method of claim 18 wherein the system also includes a display and wherein the method further includes the step of, prior to transmitting an information unit and after an information unit is received, displaying at least a portion of the information unit information on the display for acceptance by a user.

53. The method of claim 52 further including the step of, during displaying, allowing a user to modify the displayed information unit information or accept the information unit information.

54. The method of claim 18 further including the steps of providing a user identifier to the input device and modifying the information unit by adding a user identifier to the unit prior to transmitting the information unit.

55. The method of claim 18 wherein the system also includes a temporary storage device and wherein the method further includes the steps of, when information units and associated target addresses are received by the input device, storing the units and addresses on the temporary storage device and providing a user the option to review the stored units at a subsequent time.

56. A method for use with a remote data collection device, a network system and a specifier apparatus, the system including an input device and a network device, the input device equipped for receiving and transmitting information units to network device addresses, the collection device for remotely collecting information units and providing the information units and associated network device target addresses to the input device wherein the target addresses indicate where collected information is to be transmitted, the method for providing target addresses to the collection device, the collection device including a collector, the method comprising the steps of, using the specifier apparatus:

identifying an address specifier indicating a target address for information to be subsequently collected; and

transferring the target address to the collector for storage by the collection device.

57. The method of claim 56 wherein the network device is a memory storage device, the specifier apparatus is linked to the memory storage device and the method further includes the step of, when an information unit is stored at a memory storage device target address, identifying that the information unit has been stored.

58. The method of claim 57 wherein the specifier apparatus includes an indicator and a timer and wherein an event associated with an information unit is to occur within a specific time period and the method further includes the steps of, using the specifier device, monitoring the specific time periods and, wherein, when a time period expires prior to an information unit associated with the event being stored, indicating that the event did not occur within the specific time period via the indicator.

59. The method of claim 56 wherein the specifier apparatus is a first apparatus in the system and the system includes other specifier apparatus and the method includes the step of, after transferring the target address to the collector, transferring an information unit form another of the specifier apparatuses.

60. The method of claim 56 wherein the method also provides the collected information unit and the method includes the step of, prior to transferring, correlating the information unit with the target address forming an information packet and the step of transferring includes transferring the information packet to the collection device.

61. The method of claim 56 wherein the input device includes a display and a browser is loaded onto the input device and is capable, when a display format is provided, of displaying information on the display, the method further including the steps of, prior to transferring, providing a display format for each information unit.

62. The method of claim 57 wherein the step of providing display formats includes the step of providing display formats which specify browser interaction tools, the interaction tools useable by a system user to modify or approve information displayed on the display.

63. The method of claim 57 wherein the input device and collection device communicate in a computer language and the specifier apparatus provides the target addresses in the computer language.

Description

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

BACKGROUND OF THE INVENTION

The present invention relates to computer systems for the management of information distributed across a plurality of electronic system devices. More particularly, the invention relates to a system which includes a plurality of network servers, interface terminals, remote data collecting devices and other smart devices to facilitate information collection, approval, editing and storage such that the network server storage location of specific information can be specified using a remote collecting device. The invention also relates to record verification methods.

As an initial matter, in the interest of simplifying this explanation and unless indicated otherwise, the description which follows describes the invention in the context of a medical facility. However, it should be recognized that the invention should not be so limited and clearly has applications which are outside a medical facility, only some of which are specifically discussed hereinafter.

In many industries a need exists for remote information collection and information storage which facilitates easy subsequent information retrieval. For example, in medical facilities there is a need, for purposes of patient protection, quality control, record keeping, billing, and forensics, to monitor, control, and record access to medicine dispensation, medicine administration, IVs, blood transfusions, and other treatments as well as the collection, administration, and testing of blood and tissue samples. These events have traditionally been controlled and monitored manually by doctors, nurses and other facility personnel (hereinafter "physicians" generally).

Unfortunately the increasing specialization and complexity of medical care has vastly increased both the types and amount of routine record keeping that is required to track all events which occur in a facility. Advantageously, rapid growth of computer technologies has provided tools which can be used to store and retrieve specific information from a vast quantity of medical records. In particular, Internet technology is now routinely used to create hospital Intranets, link discrete hospital databases and make their data, images, and audio video records commonly accessible.

Most medical facility Intranet systems include a plurality of network servers disposed in either one central information systems department or at various locations throughout the facility, a plurality of computer terminals located throughout the facility and a data bus which links all of the servers and computers together. Software is loaded onto each computer to facilitate information entry and specify server addresses for information retrieval and storage.

The first Intranet systems were used for only very few applications and therefore were not extremely complex. However, over time, as Intranet applications became more numerous and their use as information management tools became more widely recognized, single server systems could no longer meet the information management needs of even a single medical facility. This information management capacity problem has been exacerbated by prolific mergers and acquisitions among medical groups such that many medical groups now have several locations and vast amounts of information to manage.

To facilitate information management on such a huge scale Intranet systems have evolved over time. In most cases, so as to increase management capability without wasting existing capability (i.e. without completely replacing existing servers and computers), instead of replacing entire Intranet systems, additional servers and computers are simply added to an existing Intranet network.

While this piecemeal approach to Intranet enhancement minimizes hardware costs, this approach results in an extremely complex system wherein it is often relatively difficult to direct information to known electronic memory locations (i.e. server storage addresses) which are later easily accessible. While such storage addresses could be manually provided, providing such addresses manually is particularly cumbersome as many addresses are complex and difficult to specify. This is because a single facility or related facilities may employ many different servers and each server may have access to several different memory devices. Addressing schemes have been further exacerbated by the Internet where there may be several thousand servers and it would be impractical for a user to attempt to manually enter every server address used for storage.

To overcome the addressing problem most Intranet servers are equipped to automatically assign server addresses to specific types of user provided information. To this end, a browser is typically loaded onto each Intranet capable computer which communicates with system servers. When a user contacts a server to interact therewith (i.e. to provide information thereto or receive information therefrom), the server sends instructions to the browser indicating what should be displayed on the computer screen. Typically the screen indicates the server which originated the browser instructions, includes hyperlinks to various related server addresses, includes some instructions on how to use the server via the browser and provides blanks for entering information which is to be returned to the server for storage or processing.

In addition the server provides addresses to displayed hyperlinks and for information which is to be entered by a user. Typically the server provided addresses are held in computer memory and not displayed. After the physician indicates that information has been entered or selects a hyperlink, the browser software transmits the information to the server or contacts the server indicated by the hyperlink address.

Where information is sent to a server, when the server receives information the server may do any of a number of different things including storing the information at a server address or some type of processing and sending additional instructions to the browser. Where a user selects a hyperlink the server indicated by the hyperlink address responds to the selection by providing a different set of browser instructions for configuring the browser screen.

For example, in the hospital environment a first browser screen might display several user selectable hyperlinks for entering different types of information into the system and no blanks for entering information. For instance, a first hyperlink may be to a pharmacy server to request a screen presentation to enter pharmacy information, a second link may be to a billing server, a third link may be to a patient history server and a fourth link might be to a prescription server. In this case, to enter information the user first has to select one of the hyperlinks.

When a hyperlink is selected, the server indicated by the hyperlink address provides instructions to the browser for configuring the browser screen. For example, a server used by a pharmacy may provide instructions to configure a screen including, along with instructions for filling in blanks, a first blank for entry of a patient's name, a second blank for entry of a physician's name, a third blank for entry of a dispensed drug and a quantity indicator and a fourth blank for entry of the dispensing date and time.

After a physician indicates that required information has been provided, the browser transmits the information to the pharmacy server. When the server receives the information the server stores or processes the information and then typically returns a message indicating that the information has been stored or processed.

After a pharmacy-record has been stored, when a pharmacist reviews records on the pharmacy server the pharmacist can verify, among other things, that a specific prescription was dispensed, the date and time of dispensing, which patient received the prescription and which physician dispensed the prescription.

To enter some other type of information such as billing information, using the first screen, a physician might select a second billing server hyperlink. When the second hyperlink is selected, the billing server provides screen configuration instructions and a return target address for information to be returned to the server for storage. The browser displays the billing input screen and waits for the physician to indicate that information has been provided. Thereafter the provided information is transmitted to the server at the target address and is either stored or processed. In this manner all information addressing and control is facilitated by the servers, not the system user.

While such information receiving and addressing systems can meet the information gathering needs of some facilities, such systems have a number of shortcomings. First, information gathering and entry into such a system is extremely time consuming and therefore is often thought of as an onerous task which is to be avoided. For example, in a medical facility, when a physician makes her rounds, the physician may visit with twenty or more patients, performing examinations and procedures, diagnosing illnesses and prescribing and administering drugs. Each visit requires information gathering related to symptoms, diagnosis, prescription, procedures and examinations performed and drugs prescribed and administered. When this information is gathered via a pen and clip board, the information must later be entered into the system and stored at a specific and accessible location,

Most physicians are not particularly adept at data entry. In addition, most physicians are extremely busy and therefore do not have the time to personally enter written information into a system via a browser. For these reasons either information is never entered into a system or a person specifically earmarked for data entry is required. While a data entry person may be expensive, the alternative (i.e. not entering the information into a searchable form) is not acceptable as information must be properly archived.

Second, even where a data entry person is provided, under the press of time many physician's have developed their own, personalized shorthand to expedite note taking during patient visits. In addition, often physician's writing styles are very different making it difficult at best to decipher hand written records during data entry. Shorthand and sloppy or varying writing styles make data entry by someone other than a physician extremely difficult.

Third, when information is entered into a system manually by someone other than a physician, the likelihood of mistakes is extremely high due to imperfect translation of handwritten notes, the fact that entry personnel typically are not trained in medical terminology and the fact that many medical terms are very similar, thereby increasing the likelihood that one term may be substituted for another.

Fourth, because tolerance for errors in medical records is extremely low, there should be some way to force physicians to check the accuracy of system records prior to allowing permanent storage. The present server/browser systems do not require physician approval of records prior to storage. In other words, in many cases a data entry person may enter a physician's notes and the physician may never check the notes for accuracy.

Fifth, even when someone other than a physician enters information into a system and a physician intends to revisit the information prior to permanent storage to check accuracy, despite the importance of record review, because of the press of time, record review by physicians is typically low on a physician's priority list. Where a physician allows even a few days to pass prior to reviewing information for approval, a physician's recollection of what transpired during a patient visit may not be accurate and information errors may result.

Sixth, even where a physician takes on the task of entering all information into a system to ensure quality control, the task of moving about from one browser screen to another to input information which is directed to correct server storage locations is onerous where many different records have to be entered and stored. For example, a physician may collect twenty different records while making rounds. Five of the records may have to be stored in patient record's on a patient history server, five records may have to be stored on a pharmacy server, five records may have to be stored on a billing server and the remaining five records may have to be stored on an inventory server. In this case, the physician would have to jump from one browser screen to another during data entry to enter the twenty records into the system. While this simple task might not be objectionable where there are only a few records, clearly, as the number of records which a physician is expected to make increase, the task of jumping among different browser screens becomes more taxing.

Seventh, in many cases some information may have to be provided to many different servers and therefore might have to be entered by a physician or a data entry person more than once. For example, where a drug is prescribed for a patient drug dispensation and administration information may have to be provided to many different servers for different purposes. A pharmacy server may require an administration record to ensure that a drug has been delivered, a billing server may require a record of dispensation for billing purposes, a patient record server may have to be updated to indicate that the drug was received, when the drug was received, the quantity of the drug received, the physician who administered the drug and so on, an inventory server may require an administration record to update an inventory list and automatically order drugs to meet anticipated requirements, etc. To provide all of these records to all of the servers, a physician would have to access four different browser screens, a separate browser screen for each server, and duplicative information would have to be entered to be delivered to each server.

Eighth, typical systems do not make any record of who approved information entered into a system and therefore there is no way to determine if an authorized physician approved a record or some clerical personnel accidentally approved a record before storage.

Various electronic devices have been developed to aid in the information gathering task. One handy information gathering device is the dictation device (DD) which can be used to record a physician's audio (i.e. voice) notes during a patient visit. To this end, a typical DD includes a processor, a memory (typically an electronic memory), a microphone, a speaker and some type of activation button. To take audio notes a physician positions the activation button in a record position and speaks into the microphone, the processor recording all voice notes in the memory. DDs often also allow audio review of oral notes and re-recording features to correct mistakes.

In facilities where physicians regularly use DDs, recorded notes are provided to data entry personnel who manually type audio records into an Intranet computer terminal for storage on a server. In the alternative, recently some software has been developed which can automatically convert audio records into text files for digital storage.

While DDs are preferred by some physicians, DDs do not overcome many of the shortcomings of manual (i.e. pen and paper) record keeping which are discussed above. For example, unless a system includes voice recognition software, data entry personnel are still required, physician shorthand causes transcription problems for both a data entry person and transcription software, mistakes may be made during transcription due to imperfect dictation and complex medical terminology, there is no procedure to ensure that information accuracy is checked or to indicate who approved information prior to permanent storage and it takes a large amount of time to enter information into the system.

Another handy information gathering device is a hand held device (HHD) which streamlines the information gathering process and the process of entering information into an Intranet system. To this end, a typical HHD may include a keyboard or the like, a processor, a memory and a transmitter. The board takes the place of a conventional clip board and is used to manually and remotely enter information which the processor stores in the memory. After information has been entered via an HHD, to provide the information to the system, the HHD transmitter is positioned in close proximity to a computer input device and the information is transmitted to the input device via a message including a series of signals.

To intelligibly receive a transmitted message and provide information contained therein to a browser for ultimate delivery to a server for storage or processing, a message receiving computer must be capable of translating the transmitted message into the language used by the server which is typically the hypertext markup language (HTML). This task is accomplished in one of two ways. First, the input device may include special dedicated hardware which converts the message into HTML, the hardware resembling a disk drive in the way it interacts with a browser. Second, the input device may simply provide the received message to the computer processor and software loaded onto the processor might be designed to translate the message into HTML.

Thus, HHDs can be used to eliminate physician's hand written notes thereby streamlining the data gathering/entry process. In addition, as a physician enters information into an HHD, the physician can approve entered information immediately eliminating the need to later revisit the information for approval.

While HHD technology goes a long way to solving many of the problems associated with remote information gathering, problems still exist. First, it is likely that physicians will object to having to manually enter information into an HHD for the same reasons that physicians object to entering information into regular computer terminals. In addition, with an HHD information entry is even more objectionable because most HHD keyboards are relatively small.

Second, patient's will likely object when they perceive that a physician's time during a visit is split between the patient and an HHD for information entry. This is particularly true in the case where it might be difficult to enter information into the HHD thereby requiring additional data entry time.

Third, even if there were some quick way to enter information into an HHD, transmission of the information from the HHD to a browser and ultimately to a server for storage or processing is a relatively complex task. For example, assuming five records are stored in an HHD for transmission to a browser and that each of the five records is different such that each record ultimately has to be stored on a different server. In this case, prior to transmitting each record to the browser, the physician would have to select the proper browser screen for data transmission. For example, if the first record is to be stored on a pharmacy server, the physician has to select the pharmacy browser screen prior to transmitting the first record. After the first record is transmitted to the browser the browser then provides the record to the pharmacy server which is associated with the screen. Next, assuming the second record is to be stored on the a billing server, the physician has to select the billing browser screen prior to transmitting the second record. After the second record is transmitted the browser provides the record to the billing server. Not only is this process cumbersome, but the HHD would have to have some mechanism which indicated to the physician which record is queued up for transmission so that the physician could select the proper browser screen and associated server address.

Fourth, conventional HHDs do not indicate who approved a record for ultimate storage.

Fifth, again, where duplicative information must be provided to several different servers, a physician has to separately select a browser screen associated with each server and transmit the information to be stored once for each server which is to receive the information. This is time consuming and therefore objectionable.

Some HHDs have been designed to facilitate a pseudo-addressing scheme whereby an ultimate server target address can be selected for some specific types of HHD information. For example, some HHDs allow a user to enter an E-mail address for a message to be delivered via an Intranet or Internet system.

At first blush an HHD which specifies a pseudo-address appears to overcome many of the problems associated with transferring information from an HHD to a server for ultimate storage. Thus, if server addresses can be specified, a single generic browser screen can be used as an intermediary between an HHD and servers, the HHD, not the servers, specifying where HHD information should ultimately be delivered for storage or processing.

Unfortunately, instead of simplifying the information management task, pseudo-address specifying HHDs add a new wrinkle of complexity to a browser system. To this end, while existing address specifying HHDs can provide both information (i.e. a message in the case of E-mail) and an ultimate target address, a dedicated "clearing house" server is required for a number of purposes. First, because the HHD cannot specify configuration of a browser screen, a clearing house server is required for screen configuration.

Second, because Intranet addresses are often extremely complex and difficult to manually specify, to simplify address specification, HHD provided addresses usually take a short hand form which in and of itself cannot be used by a browser to direct information to a specific server. The short hand address is provided to the clearing house server via the browser. Thereafter, the clearing house server uses the short hand address to formulate a more detailed target address specifying a different server for message delivery. Thus, the clearing house server must have some clearing house software for processing received information.

Third, in addition to providing browser screen configuration information, the clearing house server also has to specify the clearing house server address so that HHD information and the short hand target address are provided to the clearing house server for further distribution.

In short, even where an HHD can provide a pseudo-address for targeting information, a dedicated clearing house server with special processing software is required.

To appreciate the added wrinkle of complexity in systems which facilitate pseudo-address specification, consider an exemplary system including HHDs which can specify E-mail messages and associated pseudo-addresses. In this case, to provide an E-mail message to an Intranet, an HHD user must first select an E-mail browser screen via a computer. When the E-mail screen is selected, the computer communicates with an associated E-mail server which provides information to the browser including screen configuration information and the E-mail server address. The browser thereafter displays a properly configured screen for receiving information from the HHD.

Next, the HHD user positions the HHD in close proximity to a computer input device and transmits the E-mail message, including E-mail address, to the browser. The device provides the message and E-mail address to the browser which in turn transmits the message and E-mail address to the E-mail server specified by the server address associated with the screen. When the E-mail server receives the message and E-mail address, the E-mail server uses the E-mail address to form a relatively more complex address specifying the target for the E-mail message and then transmits the E-mail message to the more complex address and intended recipient. Clearly this system is more complex than a typical Intranet system as a dedicated clearing house server is required for both screen configuration and additional processing.

One advantage of conventional paper type reporting systems is that original documents can be authenticated simply via a personal signature. Thus, to determine authenticity an original document can be located and a signature examined.

Unfortunately, often original documents cannot be located for authentication. Because copies are easy to manipulate (e.g. signature cut and paste and general information modification), document copies usually cannot be relied upon for verification of their content. Usually, the only reason copies are relied upon is because original documents cannot be retrieved.

Document authentication problems are further exacerbated in the digital realm as document modification and signature picture cutting and pasting is relatively easy using standard computer functions. Thus, for example, where a document is transmitted from one computer to another and includes some type of signature picture, it would be advantageous to have some way to authenticate the content of the received document.

One solution to this authentication problem is described in U.S. Pat. No. 5,689,567 (the "'567 patent") which is entitled "Electronic Signature Method and Apparatus," which issued on Nov. 18, 1997. In the '567 patent, to enable document authentication of a digitally stored document which is subsequently accessed, prior to storing the document, a digital signature picture is encrypted as a function of the document content and is further encrypted as a function of a private (i.e. secret) key. The encrypted signature picture and document are stored.

Thereafter, when the document is reaccessed, the signature picture is decrypted using a public key and as a function of the document content thereby generating the document including a signature picture. Where the document is authentic, the resulting signature picture matches the original signature picture. Authentication is performed by visually comparing the resulting signature picture to the original signature picture.

While the '567 patent invention is useful, the '567 invention has a number of shortcomings. First, after a document is retrieved and decrypted, often it will be useful to store the document in a more accessible form such as in the form of a conventional word processor document, spread sheet, etc. In this case, after the initial decryption, there is essentially no way to subsequently authenticate a document. Thus, for instance, after a word processor document is generated and stored in decrypted or plain text form, the document may not again be accessed for a long time (e.g. years). The next time the document is accessed, because of the passage of time, it may be desirable to re-authenticate. The '567 reference does not facilitate re-authentication.

Second, it is often advantageous to generate a hard copy (i.e. paper) of a digital document for more conventional storage or conveyance to another party. Again, the '567 patent facilitates a first authentication by visual comparison but thereafter authentication is impossible. For example, after a paper document with a digital signature picture is generated, the paper document may be stored in a conventional binder-type file for a long time (e.g. 5 years). Thereafter, the paper document may be retrieved for review. When retrieved there is no way to authenticate the document. This problem is exacerbated by the fact that many documents are copied and copies of documents are copied and, as with an original paper document which is digitally signed there is no way to authenticate a copy.

Thus, it would be advantageous to have an information gathering system for remotely gathering information, reviewing and approving information, identifying who generated information and identifying who approved information prior to storing the information. In addition, it would be advantageous if such a system facilitated easy downloading of the information from an information gathering device to a browser for ultimate transmission to a server for storage or processing. Moreover, it would be advantageous if such a system could be used with a conventional Intranet and did not require a dedicated clearing house server or specialized server software. Furthermore, it would be advantageous to have a system which can authenticate either a hard copy or a digitally stored document by simply analyzing information provided on the document.

BRIEF SUMMARY OF THE INVENTION

The present invention relates to an information gathering system wherein an information collecting device (ICD) is equipped to remotely, automatically and electronically collect a large portion of the information that a physician may be required to provide during each of several different patient visits, information related to each visit forming a separate information unit. The ICD includes a processor, a transceiver and a memory. The ICD is to be used with other "smart" devices in a medical facility to collect information which describes facility events.

For example, one smart device may be an IV pump which includes a processor, a memory and a transmitter. During a patient's stay in a facility, if the IV pump is connected to the patient, the pump processor monitors all pump activity including type and amount of fluid dispensed and time of administration. Information collected by the pump is assembled into an information segment. When a physician visits the patient, the pump processor transmits the information segment to the physician's ICD.

Another smart device may include a medical container which includes an electronically locking lid, the lid includes a processor, a memory and a transceiver. In one example, a drug may be dispensed by a facility pharmacy into the container. A pharmacy computer provides administration information including the type and amount of drug dispensed, the patient for whom the drug is dispensed, the time period in which the drug should be administered and perhaps the physicians who are authorized to administer the drug. All of the administration information is stored in the container memory. When the container is opened, the container identifies the time and date. The administration information and opening time and date are assembled into an information segment. Then, after drug administration, the physician causes the container processor to transmit the information segment to the ICD processor for storage in the processor memory.

Yet another smart device may include a patient identification bracelet which includes a processor, a memory and a transmitter. Patient identifying information is stored in the bracelet memory as an information segment. When a physician visits a patient, the physician causes the identification bracelet to transmit the information segment which identifies the patient. The transmitted information segment is received by the ICD and stored as part of a collected information unit.

When several different information segments are received by the ICD during a single patient visit, the ICD may assemble one or several different information units from the segments, each information unit including at least one and possibly several information segments.

One object of the invention is to reduce the amount of manual data entry and simplify information management. To this end the inventive ICD facilitates automatic electronic retrieval of data gathered by smart devices including diagnostic and monitoring devices, electronic lock-lid containers, IVs, blood samples, etc. Moreover, the ICD may also facilitate automatic patient identification. Furthermore, the ICD processor may provide a time and date stamp indicating when an event which is related to an information segment occurred.

In addition, the ICD processor may also provide other information in information segment form which is appended to other information segments to form information units. For example, in a preferred embodiment the ICD also includes physician identifying information in its memory which an ICD appends as an additional information segment to information units. This feature further reduces the amount of manual record keeping required.

When an information unit is assembled by the ICD processor, the ICD processor provides a complete target server address for the information unit which is appended thereto to form an information packet. The information packets are transferred to an Intranet system for review, approval, modification and eventual storage at the specified target addresses.

An Intranet system which is suitable for use with the inventive ICD includes at least one and preferably several computer terminals, a plurality of network devices (i.e. memory storage devices or servers) and a network of information busses which links the computers to the network devices. An Intranet browser is loaded onto each of the computers. In addition, each computer includes a processor, a memory and some type of input device for receiving information packets from ICDs.

The computer processor receives information packets via the input device from the ICD, identifies the separate packet sections including the information units and associated target addresses, and stores associated units and addresses together in the computer memory for subsequent retrieval. Thereafter, the browser allows a physician to review and approve each information unit for delivery to a server identified by the target address. The browser may also allow a physician to edit information units or reject information units.

When a physician elects to approve an information unit, the browser sends the approved information unit to the associated target address (i.e. the target address specified by the ICD).

Another object of the invention is to provide an ICD which provides server addresses for information units. To this end the inventive ICD can generate server target addresses in any of several different ways. First, the ICD processor may receive the target address from a smart device via the ICD transceiver. For example, in addition to indicating the information indicated above, a smart medical container may also indicate a target address for associated information segments. For instance, the target address may indicate a pharmacy server address. When the ICD receives the target address the ICD appends the target address as a target address segment to the information unit in the information packet which is thereafter transferred to the browser.

Second, the ICD may receive a command from a user indicating a target address. To this end, while target server addresses are generally too long to manually enter into an ICD, where a facility only routinely uses a handful of servers, the ICD may be programmed so that each distinct server address is related to a separate address specifying task identifier in the form of an ICD button. For example, where a facility only uses five servers including a pharmacy server, a billing server, a patient records server, a inventory server and a physician records server, an ICD may be designed to have five separate buttons, each of which are uniquely earmarked to correspond to a server unique address (i.e. button 1 corresponds to the pharmacy server address, button 2 corresponds to the billing server address, and so on). Then, when an ICD receives an information unit, a physician can select one of the five buttons to indicate a desired server to receive the information unit. When a button is selected the associated server address is specified by the processor as the target address for a constructed information unit, the target address forms a target address segment and the target address segment is appended to the information unit forming the information packet to be provided to the browser.

Third, the ICD may be able to formulate a target address based on information received during information collection. To this end, when an information segment is collected, the ICD may be equipped to identify the general nature of the collected segment from which a proper target address can be surmised. For example, all information segments received from medical containers may have to be provided to a pharmacy server for review by a pharmacist. In this case, when an ICD receives an information segment from a medical container, the ICD can recognize the received information and identify the pharmacy server address as the target address. Thereafter, the ICD forms an information unit including the information segment from the container and perhaps other information (i.e. information from other received segments or information generated by the ICD) and assembles the information unit and target address into an information packet for transfer to the browser.

As another example, an ICD may be equipped to receive dictation when an activation button is pressed. In this case, the ICD may automatically identify received audio dictation as information to be provided to a transcription pool. Thus, the ICD automatically specifies a transcription pool server-address so that digitally recorded dictation can be directed to a transcription server when downloaded to the Intranet.

In addition to providing a complete server address to a browser, the inventive ICD also provides complete browser screen configuration information which is required to configure a browser screen for displaying information unit information. The configuration information is provided in a configuration segment which is appended to the information unit and the target address. Hereinafter, unless specified otherwise, an information unit will refer to all information in an information packet except the target address segment and configuration segment.

Having an ICD which provides specific target server addresses and browser configuration information is advantageous for a number of reasons. First, an address and configuration specifying ICD facilitates easy information transmission from the ICD to a browser and ultimately to desired servers for storage. Because the inventive ICD provides server addresses and browser screen configuration information, a generic browser can be employed to receive any information which is to be transmitted to any server. In other words, no information from a server or server processing is required to transmit ICD information units to target addresses (e.g. no clearing house server is required). Thus, any ICD information packet can be provided to a generic browser, the browser configuring the screen in accordance with the configuration segment information, displaying information unit information and storing the address specified by the target address segment for ultimate delivery of the information unit after approval. In effect, the ICD performs all of the front end tasks (i.e. tasks prior to permanent information storage) which are typically reserved for a browser and eliminates the need for clearing house processing.

Second, target address specification can be used to facilitate quality control. For example, when a drug is dispensed into a smart medical container as described above, the administration information can be provided by a pharmacy server (i.e. a specifier apparatus) upon dispensation. Among other things, the administration information can specify a target address on the pharmacy server for a subsequent information packet describing the administration event including time, date, patient, physician administering, amount and so on. When the container is opened, the container transmits the administration information in the form of an information segment to the ICD which assembles an information packet including the target address in the target address segment. Subsequently the packet is transmitted to the browser and, after approval, the information unit is transmitted to the target address which specifies the pharmacy server.

Advantages related to this loop closure possibility include the ability to track drug administration. Because the administration information originated with the pharmacy server and the information unit was returned to the pharmacy server, the pharmacy server can determine if all prescribed drugs and the proper doses have been administered at the right times to the right patients by authorized physicians.

Another advantage from loop closure is the ability to provide servers which automatically generate quality control reports. Servers which can close an information loop can be programmed to indicate all successful administrations, administrations which were not precisely as prescribed (i.e. were not during prescribed times, included other than a prescribed dose or other than a prescribed drug, were administered by other than an authorized physician, etc.) and administrations which were missed.

According to another aspect of the invention is an ICD may be programmed to provide more than one target address for a specific information unit. For example, where an information unit includes drug administration information, the unit may be required by each of a pharmacy, a billing department and an inventory department. In this case, whenever an information unit includes drug administration information, the ICD provides three target addresses including addresses specifying each of a pharmacy server, a billing server and an inventory server.

Thus, another object of the invention is to simplify the process of providing duplicative information to several different servers by enabling specification of several servers at one time.

In all cases the present invention contemplates that, prior to transmitting information packets to a browser, a physician must first log onto a computer via some procedure which identifies the physician and verifies that the physician is authorized to enter information packets into the browser or is authorized to approve information units prior to permanent storage. This log on procedure may be as simple as, in the case where the physician's ICD includes physician identifying information, transmitting the physician identifying information to a computer terminal via the computer input device, the computer processor thereafter performing a verification process. In cases where a physician's ICD does not include physician identifying information, a more traditional log-on procedure may be required wherein the physician enters a password which identifies the physician. In any case, the invention also contemplates a system wherein, when a physician logs onto a computer and transmits information packets to the computer browser for review, editing and approval, after approval, the computer includes what amounts to a digital signature in the information unit prior to storage at the target address. The digital signature is generated from the log-on information and identifies the physician who edited and approved the information.

Thus, another object of the invention is to provide a system wherein, prior to storing an information unit on a server, a physician reviews the information unit to affirmatively determine the accuracy of the unit and assures accuracy through her digital signature.

While a digital signature may be relatively simple, taking the form of a graphical representation of the physician's scripted signature (hereinafter "signature picture") which is appended to a document, the present invention also contemplates a "watermarked" signature picture wherein the watermark varies as a function of the content of the document to which the signature picture is appended. This type of watermarked signature picture facilitates subsequent signature picture authentication as well as document authentication. For example, after a document is generated, to check authenticity the watermark may be examined to, in effect, recreate the document content to determine if the signature picture was authentic.

One other object of the invention is to facilitate secure digital signatures which cannot be electronically copied from one document to another without detection. This is accomplished by providing document specific watermarked signatures.

Another aspect of the invention allows a browser to store information units on a dedicated server or on a computer hard drive for later review and approval. In this case, after an information unit is stored, at some later time, a physician may reaccess the information unit for editing and approval.

Thus, another object is to facilitate semi-permanent information unit storage for a reasonable amount of time so that a physician can approve or edit information units when convenient.

A related object of the claimed invention is to minimize the amount of training necessary to implement a comprehensive data collection, data security, and data management system for hospital and patient records. The inventive ICD and associated system is extremely simple to use for both information collection and review. In its simplest form collection amounts to causing smart devices to transmit collected information. Transfer to a browser for review amounts to causing an ICD to transmit all assembled information packets. Review amounts to using a single browser screen and a few commands to edit and then approve of information units after which units are automatically stored.

Yet another object is to, where possible, minimize time between data collection and data approval to cut down on errors attributable to faulty memory. Even a few days between data collection and approval can cause information errors. To this end, because the inventive ICD system is simple to use and information downloading is extremely easy, the review and approval procedure is appreciably short circuited.

Another object is to, where possible, provide information in a standard format so that virtually all commonly trained physicians can glean identical information from gathered information. To this end, information provided by smart devices is always provided in a specific format and is stored in a similarly specific format.

According to another aspect of the invention the ICD may be provided with some other type of input device so that a physician can specify nonstandard information for recordation. For example, a physician may identify a new and unexpected symptom which should be recorded and which is not indicated by a smart device. In this case, the ICD may include either a small keyboard or a dictation means for entering other information to be recorded.

Thus, another object of the invention is to, while providing a system which automatically generates much of the information required to be collected by a physician, allows the physician to record other information which should be recorded but is not automatically provided by the system.

One other problem with conventional information systems used in hospitals and other facilities which require large amounts of remote data gathering is that, besides a simple password interrogation system, in most cases nothing else stops an unscrupulous person from accessing a facility computer system to examine, add or modify information stored on the system. In fact, where an authorized person logs onto a terminal and leaves the terminal momentarily, another person could easily access the terminal and system information via the terminal under the guise of the authorized person.

The present invention overcomes this terminal security problem in several different ways including an identification system which ensures that a person who logs onto a system is authorized. To this end, in one embodiment, a person's ICD includes some type of body indicia identifier which can be used to identify an ICD user. For example, the indicia identifier may be a finger print reader which compares a users print to an ICD owners print. Where the ICD recognizes a user, the ICD participates in an interrogation by a proximate terminal to gain access to the terminal. Where the ICD fails to recognize the user, the ICD does not participate in an interrogation and therefore access to the network is blocked.

This indicia identifier concept has many applications outside the ICD art. For example, such an identifier could be placed on a credit card. In this case, when a user is identified, the card could enable a single charge to be made via the card. Thereafter, to make another charge the user would again have to present the user's print to the identifier to authenticate the user.

The inventive identifier has several advantages over prior art indicia identification systems. First, because the inventive identifier is personal to a single user, the identifier's memory need only store finger print characteristics for a single user. For this reason minimal memory is required. In addition because only one print has to be interrogated, a relatively simple processor can be used to interrogate a finger print and identify a user.

Second, the inventive identifier keeps personal information secret while still facilitating user identification. In many conventional person interrogating systems which identify body indicia a person's body indicia has to be "given up" to an interrogation system which is not controlled by the person. For example, to enter a building, an interrogation system may require a person to place her thumb on a finger print reader which identifies her print characteristic and then compares her characteristic to characteristics of prints associated with all people who are authorized to enter the facility. In this case the person's print would have previously had to have been provided to the system so that a comparison could be made. Providing personal indicia is viewed as intrusive by many persons and therefore is objectionable.

With one embodiment of the inventive indicia identifier, all indicia identification occurs on a device (i.e. ICD, credit card) which is controlled by the device owner at all times and therefore control of personal indicia is never forfeited. With another embodiment of the invention a person's indicia is provided to an external interrogation system only for interrogation purposes and is thereafter erased from the systems memory. According to this embodiment, for example, a person's fingerprint characteristics may be stored in an ICD memory, smart card or the like. To gain access to a computer network via terminal an interrogation must occur. To this end, an interrogation system includes a processor which can receive information from the ICD or smart card and which is linked to a print reader. During an interrogating process the person first enables print characteristic transfer from the ICD or card to the processor. Next the person places her thumb on the print reader which provides print characteristics to the processor. Thereafter the processor compares the prints (i.e. from the reader and the ICD or card) and allows access where the prints are identical but blocks access where the prints are different. Then the processor erases the prints from memory and may indicate so for the user's peace of mind.

The invention also includes a method and apparatus for checking authenticity of a digital or hardcopy document using only content provided on the document. To this end, assuming a document exists in a computer memory and can be displayed for approval on a computer display. A user may examine the document and, if the user approves the document, the user may indicate approval (e.g. via a key or icon selection). When approval is given, the computer performs two tasks. First, the computer provides some form of user or personal identifier to the document in a designated approval field or space. The identifier may take any of several different forms but preferably is a signature picture of the person who approved the document. This first task results in a "signed" document. Second, the computer uses the signed document content (i.e. the original document plus the signature picture) and uses a personal key which belongs to the approver to compute encryption codes, hash code, etc. The encryption code is then used to modify a standard water mark resulting in a watermark which is indicative of the signed document content. The watermark is appended to the signed document. When the document is stored or printed out the watermark is included therewith.

Subsequently, to authenticate the content and signature of the document, the watermark can be read from the document and decrypted using a public key which belongs to the person whose signature appears on the document (supposedly the original approver). At the end of the decryption process, the resulting document should match the signed document and can be compared either visually or automatically to authenticate the signature and the document content.

These and other objects, advantages and aspects of the invention will become apparent from the following description. In the description, reference is made to the accompanying drawings which form a part hereof, and in which there is shown a preferred embodiment of the invention. Such embodiment does not necessarily represent the full scope of the invention and reference is made therefor, to the claims herein for interpreting the scope of the invention.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a perspective view of a security badge capable of communicating with computer terminals and a plurality of smart devices;

FIG. 2 is a perspective view of a wrist bracelet to be worn by patients or other persons to provide identification through wireless communication with security badges or other smart devices;

FIG. 3 is a plan view of a computer terminal or workstation being operated by a system user where access is conditioned upon communications between the security badge and the computer terminal;

FIG. 4 is a plan view of a hospital patient room equipped with a variety of computerized monitoring, treatment, and information devices;

FIG. 5 is a perspective view of a medical container equipped with an electromechanical locking device controlled by communications through transceiver components;

FIG. 6 is a block diagram of various electrical components which are incorporated within an exemplary ICD;

FIG. 7 is a block diagram of a computer network according to the present invention, including a plurality of workstations and databases for data record retrieval and storage and a security verification system;

FIG. 8 presents the base memory contents of a security badge;

FIG. 9 presents the contents of the information transferred from a wrist bracelet according to the present invention to a security badge;

FIG. 10 presents the contents of the information transferred from a medical container according to the present invention to a security badge;

FIG. 11 presents the contents of a digital message record incorporating a dictated message and other information corresponding to the dictated message;

FIG. 12 is a list of information transferred from a patient monitoring or therapeutic device to a security badge;

FIG. 13A is a textual representation of a URL address of medical dispensation record formed in part from the patient's identification number and a time stamp;

FIG. 13B is a graphical representation of a medical dispensation record with HTML codes for displaying the information in a network browser;

FIG. 13C is a graphical representation of the record of FIG. 13B as it would be viewed by a system user through a network browser;

FIG. 14A is a graphical representation of a medical administration record with HTML codes for displaying the information in a network browser;

FIG. 14B is a graphical representation of the record of FIG. 14A as it would be viewed by a system user through a network browser;

FIGS. 15A-15F are a functional flow chart showing the steps a computer terminal executes in logging on a system user using a security badge for identification;

FIGS. 16A-16F are a functional flow chart showing the steps a security badge executes in logging on to a computer system, sending data, or signing a document;

FIGS. 17A-17C are a functional flow chart of the steps a security badge executes in establishing an association with a patient and acquiring data from other computerized devices;

FIG. 18 is a function flow chart of the steps a security badge follows to record and generate addresses for dictated messages;

FIG. 19 is a block diagram illustrating the general components of a smart device according to the present invention;

FIG. 20 is a perspective view of another embodiment of an ICD according to the present invention;

FIG. 21 is a perspective view of a video capable ICD according to the present invention;

FIG. 22 is an exemplary screen view used to implement the present invention;

FIG. 23 is a perspective view of a preferred embodiment of the badge illustrated in FIG. 1;

FIG. 24 is a screen view illustrating an initial screen according to the present invention;

FIG. 25 is a flow chart illustrating a portion of a digital signing process according to the present invention;

FIG. 26 is a flow chart illustrating a portion of a digital signing process according to the present invention;

FIG. 27 is a portion of an authentication method according to the present invention;

FIG. 28 is a second portion of an authentication method according to the present invention;

FIG. 29 is a view of an exemplary digital signature picture; and

FIG. 30 is a schematic view of an exemplary digitally signed and watermarked document according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention may be adapted for use in a wide variety of applications and is suitable for any environment in which numerous data records having one or multiple forms and/or formats are to be collected, stored, archived, retrieved, or translated. By way of illustration and not by way of limitation, unless indicated otherwise, the preferred embodiment is presented in the context of a medical facility environment in which typically there are numerous computer systems in use by various physicians (e.g. doctors, nurses, administrators, etc.) in several related hospitals, and each physician often desires to have access to patient records created by that physician or by other physicians who practice at one of the related hospitals. Throughout this specification, identical numbers represent similar components and symbols.

I. Hardware

Referring to FIG. 7, a simplified and exemplary embodiment of a system used with the present invention is illustrated as an electronic system referred to as computer network system 194. System 194 includes a plurality of personal computers or computer terminals comprising workstations 60 and 60' (designated "Workstation 1" and "Workstation M"), which may be located in patient rooms, at nurse stations, in doctor offices and administrative offices, a plurality of network devices including databases 158 and 162 (designated "Database 1" and "Database N") and servers including an Admit, Discharge, and Transfer (ADT) system or server 166, at least one laboratory system or server 170, various bedside treatment devices 116 and 116' such as ventilators and IV infusion pumps, patient monitoring devices 80 and 80', a pharmacy system or server 186, a security verification system or server 168, a billing system or server 171, a patient historical records system or server 173 and a unit dose medication dispenser 150.

For the most part, system 194 components communicate with each other via a communication network 190 which may comprise a combination of local and wide area networks, using ethernet, serial line, token ring, wireless, or other communication standards. Communication network 190 may also be arranged so as to be part of the Internet or as an individual Intranet. The functions performed by the various components of the preferred embodiment of system 194 may be divided among multiple computer systems or consolidated into fewer components.

Each of system servers 186, 166, 173, 168 and 170 has access to one or more databases 158, 162 for storing information including text and/or audio and visual data. As illustrated, some patient monitoring devices (i.e. 80) and treatment devices (i.e. 116) are hardwire linked to network 190 so that data from devices 116 and 80 can be provided directly to network 190. However, there are other monitoring devices 80' and treatment devices 116' which stand alone and apart from network 190 which, although capable of generating data, are not hardwired to network 190 to facilitate information interchange.

Referring to FIG. 3, an exemplary terminal 60 includes a computer 101, a display 103, an interactive device 105 and an input device 64. Computer 101 includes a processor 107, a random access memory 109 and an audible alarm 111. Processor 107 is linked to memory 109, alarm 111, input device 64, display 103, and device 105. In addition, processor 107 is linked to network 190 for two-way communication with other components of system 194 (see FIG. 7). Device 105 is illustrated as a keyboard but could be any of several different devices including a mouse or other similar pointing device.

A commercially available Internet browser 115 or similar display, entry and retrieval program using standardized formatting instructions is loaded onto processor 107. For the purpose of simplifying this explanation, while any type of entry, retrieval and display software may be used to implement the present invention, it will be assumed that browser 115 is a standard Internet browser. Generally, browser 115 operates as an interface mechanism between a physician and the servers (e.g. 186, 173 . . . ) of system 194. To this end, browser 115 configures various screens on display 103 providing information such as instructions, hyperlinks and blanks which facilitate interaction between a physician and the servers. Typically, where information is to be provided by a physician (e.g., through selection of a hyperlink or entry via device 105), a target server address for reception of the information is provided.

The target server address will typically take one of two basic forms. First, the target address may simply indicate a data base address on one of data bases 158-162 for storing received information. Second, the target address may specify a specific system 194 server and, when a server receives information, the server may determine how to proceed (i.e. process or store the received information).

Input device 64 is a transceiver which is capable of two-way communication with other devices described hereinafter. While device 64 may be equipped for wired communication, preferably, device 64 is capable of any of several different types of wireless communication. Because of its low cost, energy efficiency, minimally regulated status, and standardization by the Infrared Data Association (IrDA), infrared transmitter and receiver components supporting serial infrared communications links comprise the preferred transceiver 64. A variety of infrared communications devices, such as Hewlett Packard's HSDL-1001 transceiver components, may be used to implement the preferred communication means. Alternatively, other communication means (e.g. acoustic, radio frequency, or electromagnetic coupling) may be supported.

Referring to FIGS. 3 and 7, dispenser 150 may take any of several different forms but preferably is a terminal like terminal 60 including a processor 107, a browser 115, a memory 101, a specifier transmitter or output device 64, and an indicator 111. In addition, other useful functionality is provided by processor 107, for example, timing, counting, indicator and display control and so on. Dispenser 150 is in communication with pharmacy server 186. Thus, server 186 provides screen configuration information as well as server target addresses to dispenser 150 for interaction with a pharmacist who is responsible for dispensing drugs. In addition to dispensing drugs, dispenser 150 may also dispense target address information and browser configuration information to other system devices used for remote information collection and may perform some information tracking tasks described in more detail below.

In addition to the devices, systems, and servers identified above, the inventive system includes a series of other electronic devices which cooperate to remotely gather information within a medical facility and provide information to system 194 for storage and manipulation.

Referring to FIG. 1, a mobile information collecting device (ICD) is illustrated in one embodiment as a security badge 10 which may be clipped to a physician's clothing or worn by chain around a physician's neck. While this embodiment implements the invention in the context of an identification badge, the invention could be instantiated in other shapes, such as a ring, a personalized pointing device or a small hand held computer. In keeping with its preferred resemblance to a typical identification badge, ICD 10 is affixed with identification text 12 and graphic display 16. ICD 10 incorporates a wireless communication means or transceiver 14 (i.e., a receiver/transmitter) which operates as both a data collector and an output device, an audible alerting device 20, an activation button 18, a microphone and audio digitizer 22, and a dictation button 26. ICD 10 may also incorporate additional electronic identification means such as a magnetic strip (the general location illustrated at 30) and may also incorporate a small key pad (not illustrated) for entering additional information.

Referring also to FIG. 6, ICD 10 comprises a processor 250 which is linked to each of a battery 252, a real-time clock 254, a memory element 262, audible alerting device 20, transceiver 14, activation button 18, microphone 22 and dictation button 26. Display 16 of ICD 10 may be any of a variety of forms, including but not limited to a photograph, a light emitting diode array, a liquid crystal panel, and an active-matrix display. In addition, ICD 10 may include a display 258 such as a light emitting diode array, an LCD screen, or a passive or active matrix screen, which is linked to processor 250.

Referring to FIG. 8, exemplary information 300 which may be stored in memory element 262 is illustrated. Information 300 includes both "base contents" and "optional information". The base contents comprises the minimum information which should be stored in a personalized ICD such as identification ICD 10 and includes a physician's password or private/public digital security key information which can be used to log onto a computer terminal to provide information to, or review information thereon. The optional information includes other information which is descriptive of a badge owner including a user identifier such as a name, identification number, occupation, privileges and so on.

While personalized ICDs are preferred, the invention also contemplates other types of ICDs which are not personalized and can therefore be used by any facility personnel to collect information for entry into a facility computer system. In this case, however, prior to entering information into the system, it is contemplated that a physician would log on to a computer terminal in a more conventional manner via system 168 which would identify the physician for security purposes. For example, the physician might manually enter a personal identification number to gain access to the computer terminal for information entry and retrieval.

ICD 10 is to be used with a plurality of different "smart devices" for remotely collecting information. In addition to remotely collecting information, inventive ICD 10 is equipped to provide information packets to terminal input devices 64 which are formatted and addressed according to uniform standards in order to minimize the need for human intervention in categorizing and archiving patient records. Information packets are formatted and addressed according to conventions, such as Java or a markup language supporting interactive display by browser 115. While any standard format (e.g. HTML, Java . . . ) may be supported and it is contemplated that the present invention may be used with any computer language format, hereinafter, in the interest of simplifying this explanation, the invention will be described with reference to the HTML format only.

By formatting information packets in HTML format a receiving computer terminal 60 does not need additional programming or input to display or manipulate information in an information packet. In a preferred embodiment, formatting and addressing of information packets is done partially or entirely by ICD 10 itself, using time stamps, patient identification information, and the information or contents 300 (FIG. 8) incorporated in memory element 262 (FIG. 6) of ICD 10. In this manner all the information required to display information packet information and to send the information to an appropriate database or server is included in the information packet transferred from ICD 10. An exemplary information packet is described in more detail below.

Referring to FIG. 19, an exemplary smart device 75 generally includes a processor 77, a memory 79 linked to processor 77 and either a transmitter or a transceiver 81 (i.e. a receiver/transmitter). In addition, each smart device 75 may also include one or more activation buttons 83, some type of indicator (e.g. a light 85 or audible alarm in the form of a speaker 87) and a display 88. Smart devices like device 75 collect, generate, and/or are provided information which is assembled into information segments to be transmitted to ICD 10 for collection. Many smart devices 75 are contemplated by the present invention, however, in the interest of simplifying this explanation, only a small number of smart devices are described. Hereinafter when specific smart device components are referenced, the specific components will be referenced by the same numbers used in FIG. 19 followed by one or more "`" indicating components associated with specific devices as described hereinafter.

Referring now to FIG. 2, one smart device is a patient identification bracelet 40. An exemplary bracelet 40 is described in U.S. patent application Ser. No. 09/007,290, which is entitled "Identification Bracelet With Electronic Information", which was filed by the present inventor and is incorporated herein by reference. Bracelet 40 includes a flexible and extendible band 44, a securing clasp 48, a processing device 75' and a wireless communication means in the form of transceiver 81'. Bracelet 40 is similar to existing bracelets used to identify patients in hospitals, with the exception of the processing device 75' which includes transceiver 81'. Textual information (not illustrated) is typically affixed to band 44. Transceiver 81' is preferably similar to transceiver 14 of ICD 10 so that transceivers 81' and 14 can communicate back and forth. Like general device 75 (see FIG. 19), device 75' includes a processor and a memory element linked to the processor (not illustrated).

Referring also to FIG. 9, exemplary patient identification information 320 to be stored in the memory of device 75' is illustrated and includes, at a minimum, a patient identification number identifying the patient who wears bracelet 40. In addition, the identification information 320 may also include other descriptive information as indicated.

Referring to FIG. 5, another smart device is a medical container 200. U.S. patent application Ser. No. 08/955,475, entitled "System And Apparatus For Administering Prescribed Medication To A Patient", which was filed by the present inventor and is incorporated herein by reference, describes an exemplary medical container. Exemplary container 200, which may be used to transport and provide auditing and limited access for medications, blood or tissue samples, or other inventory, includes a lid 204, a securing latch 232, a latch release button 228, and an electronic identification or processing device 75". Textual identification 208 may be attached to lid 204. Processing device 75", like general smart device 75 (see FIG. 19) includes a processor which is linked to a memory, a battery, a transceiver 81", an activation button 83" and an audible alerting device 87".

Referring also to FIG. 10, exemplary information 340 which might be stored in the memory associated with processing device 75" is illustrated. Once again the information is divided into a minimum amount of information which should be stored and optional information. In the case of a drug to be administered, the minimum information includes medication name and medication quantity. Optional information may include, among other things, the name of a patient for whom the drug is dispensed, the date and time at which the drug should be administered and the names of physicians authorized to administer the drug. Other information would be provided in the case of a tissue sample, a blood sample, etc.

Referring again to FIG. 5, it is contemplated that latch 232 release may be conditioned on any of a number of different precise sequences of events. The events may include release within a time-window for treatment, the successful exchange of identification information between a physician's ICD and processing device 75", the successful exchange of identification information between a patient's identification bracelet processing device 75' (see FIG. 2) and processing device 75" and the manual depression of the latch release button 228. An example of a lid unlocking sequence is described in more detail below.

Referring to FIG. 4, an exemplary patient room 104 includes a computer terminal 60, a patient bed 88 and various other devices. The other devices include two smart devices including a patient monitor 80' and a patient treatment device 116', each equipped with a wireless transceiver input device 64 which is similar to transceiver 75' on band 40 (see FIG. 2) and transceiver 75" on container 200 (see FIG. 5). Monitor 80 and device 116 are smart devices meaning that each of those devices typically include the components illustrated in FIG. 19 (i.e. in addition to a transceiver, each device includes a processor, a memory, at least one activation button and some type of output device such as an LED or computer screen for visual indication or a speaker for audio indication). In this example, it will be assumed that each of devices 80' and 116' are not hardwired to network 194.

Also shown in FIG. 4 is an optional bedside communication device 96 which is equipped to communicate with wireless transceiver devices 64. Communication device 96 may be connected to an optional patient identification display 100 equipped with wireless transceiver device 64 or to a patient identification display 120 outside of room 104.

II. Operation of a Computer Terminal in Access Control

Generally, it is contemplated that a terminal used with an ICD 10 will be capable of, in addition to facilitating transfer of information packets from the ICD 10 to the terminal, facilitating use of other conventional computing programs (e.g. a word processor, a spread sheet, Internet access, . . . ). In enabling access to any facility application, security is extremely important.

In the preferred embodiment, authentication, interrogation and data security will be illustrated through the use of conventional "public key" cryptography, such as that implemented in RSA, though other well-known techniques for authenticating a user and securing transmitted data may be employed. In implementing public key cryptography, the security badges and computer terminals are equipped with "private key rings" of one or more private keys and a "public key ring" of one or more public keys. Depending upon their sophistication and the sensitivity of the information they contain, other smart devices in a medical facility, such as monitoring devices or medical instruments, may also be equipped with cryptographic means. The private keys of each ICD 10 are never transmitted or otherwise made accessible outside the ICD 10. For strong compression, each public and private key would typically be at least 128 bytes long. Today, the preferred implementation for smart card encryption capabilities utilizes the Advanced RISC Microprocessor (ARM), such as the ARM 6, the ARM 710, or a variety of customized chips integrating the ARM technology, such as the Mykronics Capstone or VLSI's VMS 210. A variety of other processors, including the Intel x86 processor, would also be suitable.

FIGS. 15A-15F describe the operation of a computer terminal 60 (FIG. 3) in interrogating, establishing and monitoring access by a physician wearing an ICD 10 (FIG. 1). Access is established by providing a substantially unobstructed signal path between the physical wireless communication means 14 (preferably comprising infrared transmitter and receiver components (see FIG. 1 )) of the ICD 10 and the wireless transceiver device 64 of the computer terminal 60. The establishment of an unobstructed signal path is facilitated by having the ICD 10 worn on, or attached to, the front of the physician attempting to log on the computer terminal 60. While it is not necessary that the ICD 10 be worn by or attached to the clothing of the physician, securing the ICD 10 to the physician minimizes the probability that it will be lost by the physician.

Commencing with FIG. 15A, in step 600 the computer terminal 60 transmits an interrogation signal, which is fashioned from a private key of the security verification system 168 (FIG. 7) of the computer network 194, a large random number, and other identification information unique to the security verification system 168. Provided a substantially unobstructed signal path exists between the wireless transceiver device 64 (FIG. 3) of the computer terminal 60 and the wireless communication means 14 (FIG. 1) of an ICD 10, the ICD 10 will intercept, process, and be operable to return a part of the interrogation signal in a re-encrypted form (according to the operation of the ICD 10 set forth in FIGS. 16A-16F, infra).

In step 604, the computer terminal 60 waits for a period sufficient to allow an ICD 10 to receive, process, re-encrypt, and re-transmit the interrogation signal. If no return response is received, in step 608 the computer terminal 60 waits for a predetermined period of time and, returning to step 600, transmits another interrogation signal. If a return response is received, in step 612 the format of the return response is evaluated. If the format is unrecognized, in step 608 the computer terminal 60 waits for a predetermined period of time and, returning to step 600, transmits another interrogation signal.

If a return response of a recognized format is received by the computer terminal 60, in step 616 it is decrypted or authenticated using the public key of the ICD 10 which returned the response. In a public key cryptographic system, encryption with a private key uniquely identifies the physician possessing that key (assuming the private key has not been stolen) because an encrypted message can only be decoded using the public key matching the physician's private key. Accordingly, the security verification system 168, which stores the public keys of each ICD 10 given access privileges to the computer network, attempts to decrypt the re-encrypted interrogation signal using the public keys it retains.

There are at least two ways in which the decryption procedure may be carried out. In one procedure, the security verification system 168 attempts to decrypt the response signal, one public key at a time, until either a successful decryption is achieved or all the public keys stored by the security verification system 168 fail. Preferably, however, the identification information will have been appended to the encrypted portion of the return response purporting to identify the ICD 10. The security verification system 168 then attempts to decrypt the return response using the public key corresponding to the appended identification information. A successful decryption identifies the ICD 10 that originated the return response. If the decryption is successful, a verification algorithm is used to compare the decrypted return response to the original, pre-encrypted interrogation signal.

It would, of course, be possible to program the computer terminal 60 itself to perform some or all the functions of the security verification system 168. A physically separate security verification system 168, however, will safeguard the computer network 194's private keys and the list of public keys of valid system users, preventing appropriation of the keys by one breaking into the computer terminal 60 itself.

As an additional precaution, the ICD 10 may be programmed to detect and eject interrogation signals that are short and probabilistically non-random. In other word, if an ICD received one or a series of consecutive interrogation signals which were not recognized as being in a valid form, the ICD 10 would reject the signal and fail to respond. This rejection process would frustrate a cryptanalyst's attempt to derive an ICD 10's private key by interrogating the ICD 10 with short messages and intercepting the re-encrypted response. This precaution is especially justified if the ICD 10 is adapted to communicate with devices and computer terminals foreign to the computer network 194 and its security verification system 168. This precaution may also limit the damage that could be imposed were a private key of the security verification system 168 compromised.

In step 620, if the decryption and verification failed to identify an ICD 10 having access privileges to the computer terminal 60, then the operation proceeds again-to step 608, where the computer terminal 60 waits for a predetermined period of time and, returning to step 600, transmits another interrogation signal.

Because an ICD 10 may be misplaced by or stolen from a physician, additional security measures are warranted. The security verification system 168 may be programmed to require that a physician manually enter a password at the beginning of each day. Alternatively, the system could require manual password entry at random times throughout the day, even while the physician is logged on, flagging possible theft and unauthorized use of the ICD 10 should the proper password not be detected. Further, a switch may be incorporated onto the ICD 10 to force it into a mode requiring password entry. More elaborate means, including voice identification or a fingerprint or retinal scan, could also be incorporated into the ICD 10 or at computer terminals 60 to reinforce such security. One example of a fingerprint interrogating ICD and its advantages is described in detail below. It is to be expected, however, that should a physician be dispossessed of an ICD 10, that he or she immediately notify the system security administrator to deactivate the access privileges of the ICD 10.

Provided an ICD 10 having access privileges to the computer terminal 60 has been identified, in step 624 the security verification system 168 determines whether or not to require the entry of a password to enable log on by the physician. This procedure provides a safeguard should the ICD 10 be stolen, deterring unauthorized log on attempts with the threat that the security verification system 168 will detect the breach and apprehend the violator.

If password entry is required, then in step 632 the computer terminal 60 prompts the physician for a password. Information that is entered may not only be processed by the computer terminal 60, but also transmitted to the ICD 10 in encrypted form in order to reset a flag maintained by the ICD 10 indicating that password entry is required. In step 636, the password is analyzed. If the wrong password has been entered, in step 640 a counter is incremented. If the wrong password was entered less than three consecutive times (step 640), the security verification system 168 returns to step 632 and again prompts the physician to enter the password. After three failed attempts (step 640), however, in step 644, the security verification system 168 disables recognition of the ICD 10, records the location of the failed attempt, and notifies the system administration to alert it to a possible attempted breach of the system. Other processes may be performed in the event of a failed interrogation. For example, where data is to be provided to a terminal after a successful interrogation, the terminal may block reception of transmitted data after a failed interrogation or series of interrogations.

If within the first three attempts, the correct password is entered, the operation advances to step 648, logging the physician onto the computer terminal 60 and providing access to program features and databases in accordance with the access privileges of physician. In step 652, the computer terminal queries the ICD 10 for the existence of data records to transfer to the computer network 194 and causes the ICD 10 to transmit them, if any, to the computer terminal 60 for database storage, in accordance with the operation detailed in FIGS. 16A-16F. This query for data records or information packets may be automatic or may simply be a function which periodically queries for records as described in more detail below.

After completion of the data transfer by the ICD 10 to the computer terminal 60 or, in the event no data is transferred but another terminal application (e.g. a wordprocessor) is employed by the physician, if warranted, the computer terminal 60 will continue to periodically poll the ICD 10 with recommitment signals. These recommitment signals may be specifically addressed to the physician's ICD 10 and may incorporate a different random number with each polling. Further, these recommitment signals may be encrypted with the ICD 10's public key stored by the security verification system 168, instead of or in addition to encryption by the security verification system's private key, so that they may only be intelligibly decrypted by the ICD 10 itself, using its own exclusively-guarded private key. By periodically polling the ICD 10, the user input and output devices of the computer terminal 60, including the monitor, keyboard, and mouse, can be disabled if the computer terminal ceases receiving response signals from the ICD 10. A physician may also be automatically logged out by means of periodic polling.

This process of periodic polling is illustrated in steps 656 through 692 of FIGS. 15C-15E. The computer terminal waits for a predetermined interval in step 656, transmits a recommitment signal in step 660, and probes for a response signal in step 664. If there is a recommitment response signal, in step 668 its content is evaluated. If the content of the recommitment response signal is accepted, the operation proceeds to step 696, discussed infra. If either there is no recommitment response signal in step 664, or if the content of the recommitment response signal is rejected in step 668, an idle/invalid link counter (not illustrated) maintained by the security verification system 168 and whose initial value relative to the log on event was zero, is incremented in step 672.

The idle/invalid link counter permits the physician to temporarily turn away from the transceiver device 64 of the computer terminal 60 or to otherwise interfere with the signal path. However, if the computer terminal 60 does not receive a recommitment response signal after several requests, the display of the computer terminal 60 is blanked, input from any keyboard or pointing device may be ignored, and other processing activities may be suspended. The computer terminal 60, however, continues to transmit recommitment signals. Should the physician's ICD 10 respond within a second period of time, the display will be restored to its previous condition and the keyboard, pointing device, and processor will resume normal operation. If the ICD 10, however, does not transmit a correct recommitment response signal during the second period of time, the physician is automatically logged off the computer network 194. When the user is logged off the computer system, a software program may also be used to remove any temporary files that have been stored on disk or in RAM memory, e.g. the cache file used by the network browser program. Furthermore, access by the computer terminal 60 to the computer network 194 may be terminated with the exception of the link between the computer terminal 60 and the security verification system 168, which may be preserved to determine if a new user is attempting to use the computer terminal 60 to log onto the computer network 194. In this manner a physician's access to the computer network 194 is restricted while logged off and enlarged while logged on.

This computer terminal access security operation is described more particularly in steps 676 through 692 of FIGS. 15D-15E. The value of the idle/invalid link counter is compared in step 676 to a predetermined disable I/O limit. If that value does not exceed the disable I/O limit, the periodic polling continues with step 656. If and when the value of the idle/invalid link counter does exceed the disable I/O limit, in step 684, the input and output devices of the computer terminal 60 are disabled, if they have not been previously disabled (step 680). In step 688, the value of the idle/invalid link counter is compared to a predetermined logout limit. Periodic polling is continued in step 656 if the value of the idle/invalid link counter does not exceed the logout limit. If and when this value is exceeded, in step 692 the physician is logged off the computer terminal 60 and information stored in memory or cache on the computer terminal by the user is overwritten.

If the content of the recommitment response signal is valid (step 668), in step 696 the security verification system 168 processes the signal through a verification algorithm, attempting to decrypt the signal with public keys and comparing the decrypted output with the original recommitment signal. If the decrypted output matches the original recommitment signal (step 700), then in step 704 the computer network 194 recognizes that the physician is still using the computer system. The idle/invalid link counter is reset and the display and other input and output functions of the computer terminal 60, if disabled, are restored. If the decrypted output does not match the original recommitment signal (step 700), then in step 708 the computer network 194 recognizes that another physician is nearby. If the value of the idle/invalid link counter exceeds a third limit (step 712), then the original physician is logged off, memory cache and temporary work space utilized by the original physician or applications executed by or through the original physician is deleted and/or overwritten, and the new physician is logged on to the computer terminal. If the value of the idle/invalid link counter has not yet exceeded a third limit (step 712), then the new physician is recognized but not logged onto the terminal, for the original system user has not been logged off for a sufficient period of time.

While the preferred embodiment is described above wherein a terminal initiates an interrogation process, the invention is not meant to be so limited and indeed includes systems wherein an ICD may initiate an interrogation either when an ICD is near a terminal (e.g. in the case where an ICD transmits interrogation signals at regular and frequent intervals) or when an initiation button is pressed on the ICD.

III. Operation of an ICD in Access Control

FIGS. 16A-16F describe the operation of an ICD 10 (FIG. 1) in responding to interrogation and recommitment signals transmitted by a proximately located computer terminal 60 (FIG. 3). In order to conserve power, the ICD 10 is preferably capable of alternating between sleep and wake states. During a sleep state, the ICD 10 is not responsive to signals transmitted by computer terminals 60 and other proximate smart devices, and may be essentially "invisible" to such devices. This alternating sleep/wake cycle is described in steps 724 through 732. In step 724, the ICD 10 maintains a wake state in which it is capable of receiving and transmitting signals through its wireless communication means 14. If in step 728, the time allotted for the wake state has expired and no signal has been received via the wireless communication means 14 of the ICD 10, then in step 732 the ICD is powered down for the allotted duration of its sleep state, before cycling back to the wake state of step 724.

If a signal is received during its wake state, however, the alternating sleep and wake-cycle is suspended in order to process and respond to the signal. In step 736, the ICD 10 processes and identifies the signal. If the signal is identified as a nonspecifically addressed signal (step 740) or as being addressed to the instant ICD 10 processing the signal (step 742), then further evaluation of the signal is performed, beginning with step 760, discussed infra.

A signal that is neither nonspecifically addressed (step 740) nor specifically addressed (step 742) to the instant ICD 10 is regarded as being extrinsically addressed to a second ICD 10. This situation may arise when two system users 68 with two security badges 10 are in the vicinity of the same computer terminal 60, one of them being logged onto the computer terminal 60. In step 744, the extrinsically addressed signal is evaluated to determine whether or not it is of a nature seeking an identification signal from the second ICD 10. If not, the instant ICD 10 ignores the extrinsically addressed signal and retires to wake state 724. If, however, the extrinsically addressed signal is of a nature requesting an identification signal, in step 752 the instant ICD 10 pauses to permit the second ICD 10 to transmit its identification signal. In step 756, the ICD 10 then transmits its own identification signal to the computer terminal 60 to indicate its presence, retiring afterward to wake state 724. This may allow the security verification system 168 to temporarily blank the screen to prevent unauthorized access to data by one physician through the access privileges of another physician. Alternatively, after repeated failures by the computer terminal 60 to receive a response signal from the second ICD 10, the second physician may be logged out and the instant physician logged in.

In the event that the signal was either nonspecifically addressed (step 740) or specifically addressed to the instant ICD 10 (step 742), the operation advances to step 760, where the signal is further evaluated to determine whether it is an interrogation or recommitment signal, in which case it would have been encrypted by a private key of the security verification system 168. If in step 760 it is identified as an interrogation or recommitment signal, then in step 764, a key ID tag appended to the signal is used to locate the public key stored in the memory element 262 (FIG. 6) of the ICD 10, with which it decrypts the signal.

In step 768, the decrypted signal is evaluated for information positively or probabilistically identifying the security verification system 168 as the source of the signal. This step implements the precaution of programming the ICD 10 to detect and reject interrogation signals that are too short or probabilistically non-random. If the decrypted signal is not distinguishable as originating from the security verification system 168, then in step 772, the ICD 10 stores and transmits an invalid message code, retiring to wake state 724. If the decrypted signal is recognized as originating from the security verification system 168 (step 768), then in step 774, the signal or a portion thereof is re-encrypted using the private key of the ICD 10 and transmitted, in step 776, to the computer terminal 60. Following this transmission, the ICD 10 retires to wake state 724.

Turning back to step 760, if the signal is not identified as an interrogation-or recommitment signal, in step 784 the signal is evaluated to determine whether it is prompting the ICD 10 to transmit stored data to the computer terminal 60, in which case in step 788 the data is transmitted before the ICD 10 retires to wake state 724. If the signal was not identified as a prompt for data transfer (step 784), then in step 794 the signal is evaluated to determine whether it is prompting the ICD 10 to delete specified data, in which case in step 796 the specified data is deleted before the ICD 10 retires to wake state 724.

If the signal was not identified as a request to delete specified data (step 792), then in step 800, the signal is evaluated to determine whether it is prompting the ICD 10 to digitally sign a document or data record using its private key. If the signal is not identified as a request to digitally sign a document, the signal is treated as an unspecified command, upon which the ICD 10 takes no action, instead retiring to wake state 724. If the signal is identified as requesting a digital signature (step 800), in step 804 the computer terminal 60 or the ICD 10, by means of its audible alerting device 20, prompts the physician to depress the activation button 18. In step 808 the ICD 10 waits for the physician to respond for a limited time period. In step 812, if the activation button 18 has not been depressed before the expiration of this limited time period, then in step 816 the ICD 10 returns a signal indicating that the signature has not been provided, retiring then to wake state 724. In this manner a digital signature will not be provided without the affirmative agreement and action of the physician. If in step 812, the activation button 18 had been depressed within the limited time period, in step 820 the document, a message digest or an information packet is encrypted in whole or in part and transmitted to the computer terminal 60, the ICD 10 afterward retiring to wake state 724.

Though not illustrated, the activation button 18 may be pressed for several seconds in order to suspend automatic log on access to a computer terminal 60 without being prompted to enter a password. The ICD 10 may emit an audible sound to indicate that automatic log on has been suspended.

In addition, while the preferred embod