Not applicable.
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 xe2x80x9cphysiciansxe2x80x9d 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 xe2x80x9cclearing housexe2x80x9d 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 xe2x80x9c""567 patentxe2x80x9d) which is entitled xe2x80x9cElectronic Signature Method and Apparatus,xe2x80x9d 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.
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 xe2x80x9csmartxe2x80x9d 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 xe2x80x9csignature picturexe2x80x9d) which is appended to a document, the present invention also contemplates a xe2x80x9cwatermarkedxe2x80x9d 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 xe2x80x9cgiven upxe2x80x9d 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 xe2x80x9csignedxe2x80x9d 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.
USPTO Backgrounds
USPTO Backgrounds