TITLE OF THE INVENTION
A METHOD AND SYSTEM FOR PROVIDING HEALTHCARE INFORMATION
CROSS-REFERENCE TO RELATED APPLICATIONS
This patent application is related to U.S. Pat. No. 6,240,394 and U.S. Pat. No. 6,067,524, and the entire contents of U.S. Pat. No. 6,240,394 and U.S. Pat. No. 6,067,524 are incorporated herein by reference.
BACKGROUND OF THE INVENTION Field of the Invention
This invention relates to a method and system for providing targeted medical information to patients and health care providers, particularly physicians, in their office.
Discussion of the Background
In healthcare environments, staff is required to maintain and update patient information and provide patient care. U.S. Pat. No. 5,822,544 discloses a system for managing and communicating patient healthcare information, and its disclosure is herein incorporated by reference.
Direct to Consumer advertising is defined to be a communication from the manufacturer or provider that has been personalized for a specific customer.
The present inventors recognized that there is a need for a system that automatically provides targeted information at the point of care in a format suitable for delivery to the patient or the physician. When used herein, reference to physicians means physicians and related health care providers that either diagnose or prescribe, or both.
SUMMARY OF THE INVENTION
One object of the invention is to provide the healthcare provider and the patient with useful targeted information based, at least in part, on the patient's medical record, a diagnosis of the patient, the drug(s) prescribed for the patient, or the physician's prescribing behavior. .
Another object of the invention is to provide formatted messages concerning patient information when data in a patient's medical record meets triggering criteria.
It is another object of the invention to accomplish these goals as part of the patient's medical care while maintaining the confidentiality of the patient's medical records. Accordingly, these and other objects are provided by a novel computer program product, computer network implemented method, and computer network system. The system includes a system server and a doctor's computer system, in which the system server receives patient information from the doctor's computer system, accesses in a system database a patient database record associated with a patient, updates the patient database record with the patient information to produce an updated patient database record, determines information based upon contents of the updated patient database record, and transmits the determined information to at least the doctor's computer system. The system server, in updating the patient database record, may connect to at least one third party database upon a determination that the updated patient database record is not complete, access third-party information in the at least one third party database, and assimilate the third-party information into the patient database record. The information transmitted from the system server to the doctor's office may be transmitted in response to the patient's data meeting set targeting criteria. Alternatively, instead of or in addition to transmitting the information to the doctor's office, the information may also be transmitted to pharmacies, pharmacists, medical testers, and medical testing offices.
The present invention further includes a management system including a novel database aggregated from a plurality of medical archives preferably including a first field for storing a patient identification label and at least one second field for storing patient information received from a doctor's office. This database may include additional fields for storing patient information received from other medical providers and other third parties.
The database preferably includes at least one third field for storing triggering flags and at least one fourth field for storing specific messages. The specific messages are messages that are intended to be embedded in a targeted message and to be sent, based on the existence of stored triggering flag valued. The triggering flag values will have been set depending upon the medical condition presented by the patient.
BRIEF DESCRIPTION OF THE DRAWINGS
A more complete appreciation of the invention and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:
Figure 1 is a system schematic showing the implementation of the present invention on a computer system;
Figure 2 is a schematic illustration of a computer system programmed to perform one or more of the special purpose functions of the present invention;
Figure 3 is a schematic illustration of an exemplary patient table in a database according to the present invention;
Figure 4 A is a schematic illustration of an exemplary reference table in a database according to the present invention;
Figure 4B is a schematic illustration of an exemplary auxiliary table in a database according to the present invention;
Figure 5 is a schematic illustration of an exemplary hospital-patient table in a database according to the present invention; Figure 6 is a schematic illustration of an exemplary clinic-patient table in a database according to the present invention;
Figure 7 is a schematic illustration of an exemplary pharmacy-transaction table in a database according to the present invention;
Figure 8 is a schematic illustration of an exemplary insurance-transaction table in a database according to the present invention;
Figure 9 is a schematic illustration of an exemplary message table in a database according to the present invention; and
Figure 10 is a flowchart showing a method of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
Referring now to the drawings, like reference numerals designate identical or corresponding parts throughout the several views.
Figure 1 is a system schematic showing the implementation of the present invention on a computer system. In Figure 1 , a patient data entry/display device 10 is utilized by a doctor, nurse, receptionist or other clinical professional at a doctor's office, test laboratory, or hospital to enter patient information such as, for example, an appointment time, the latest diagnosis, vital signs, prescription changes, a date of next appointment, etc. The patient data entry/device 10 communicates via a data connection to a doctor's computer system 20 via a wireless or wired mechanism. The doctor's computer system 20 includes a patient database 22 which may store patient records including diagnoses, treatments, and prescriptions as well
as other pertinent information necessary for the doctor to conduct his business. This information may include insurance plan information and formulary (i.e. trade names of prescriptions and generic substitutes) of drugs. The doctor's computer system 20 is
preferably connected to a printer 24 for producing hard copies of patient's records for storing in the physical files at the doctor's office.
According to the present invention, the doctor's computer system 20 is connected, preferably via the Internet 30, to a system server 32. The system database 34 includes patient information available from the doctor's office contained in the patient database 22 of the doctor's computer system 20. The system database 34 also preferably includes information pertaining to the patient available from other sources such as the patient's insurance company, clinics, medical test laboratories, and hospitals. This additional information can include the patient's age, gender, previously issued prescriptions, insurance plan, doctor's drug enforcement agency (DEA) number, location, etc.
According to the present invention, the system server 32 is connected to third party servers. The third party servers include but are not limited to a third party hospital server 40 located at a hospital, a third party test lab server 44, and a third party pharmacy server 48. The third party hospital server 40 includes a hospital database 42 (to be discussed later). The third party test laboratory server 44 includes a test laboratory database 46 (to be discussed later). The third party pharmacy server includes a pharmacy database 50 (to be discussed later). Accordingly, the system server 32 may connect directly to a pharmacy, hospital, test lab, or to a network interfacing to these locations. The information gathered from these locations can include recent prescriptions, laboratory tests required, results from previous tests, hospital requirements, etc.
According to the present invention, the doctor's patient data entry/display device 10 is preferably a hand-held device and is provided with the listing of the information being issued by the system server 32 for the patient.
It is to be understood that the system in Figure 1 is for exemplary purposes only, as many variations of the specific hardware and software used to implement the invention will be readily apparent to one having ordinary skill in the art. These implementations and other implementations of computer systems are described in greater detail in one or more of U.S. Patents 4,723,212; 4,910,672; 5,173,851; 5,612,868; and 6,026,370 which are all hereby incorporated herein by reference. To implement these variations as well as other variations, a single computer (e.g., the control computer of Figure 1) may be programmed to perform the special purpose functions of two or more of any of the devices shown in Figure 1. On the other hand, two or more programmed computers may be substituted for any one of the devices shown in Figure 1. Principles and advantages of distributed processing, such as redundancy and replication, may also be implemented as desired to increase the robustness and performance of the system, for example.
Figure 2 is a block diagram of an exemplary computer 202 that may be programmed to perform one or more of the special purpose functions of the present invention, such as for example the functions executed by the system server 32 shown in Figure 1. The computer 202 is a personal computer, a portable computer, a computer workstation with sufficient memory and processing capability, or any device configured to work like a computer. In one embodiment, the computer device 202 is a device diagrammaticaUy shown in Figure 2. In this embodiment, the computer 202 includes a central processing unit 204 (CPU) that communicates with a number of other devices by way of a system bus 206. The computer 202 includes a random access memory (RAM) 208 that stores temporary values used in implementing the print job.
The central processing unit 204 is configured for high volume data transmission for performing a significant number of mathematical calculations in processing the print jobs Multiple processors and workstations may be used as well.
The ROM 210 is preferably included in a semiconductor form although other read only memory forms including optical medium may be used to host application software and temporary results. The ROM 210 connects to the system bus 206 for use by the CPU 204. An input control 212 connects to the system bus 206 and provides an interface with various peripheral equipment including a keyboard 214 and a pointing device such as a mouse 216 settles to permit user interaction with graphical user interfaces A disc controller 218 is in the form of an IDE controller and connects via driving cables to a removal media drive 220 which may be implemented as a floppy disc drive, as well as a hard disc drive 222 and a CD-ROM drive (not shown). A communication controller 224 provides a connection to a network LI . An input/output controller 230 also provides connections to the external components such as an external hard disc drive 232, a printer 234, for example, by way of an RS 232 port and a CSI bus. A display controller 236 interconnects the system bus 206 to a display device, such as a cathode ray tube (CRT) 238.
System database 34 stores patient information, such as for example, patient names, postal addresses, telephone numbers, a chronological log of transactions, debits to the client, credits to the client, web addresses, secondary contacts, diagnoses, and treatments. This information is stored in one or more memories such as a hard disk, optical disk, magneto- optical disk, and/or RAM. One or more databases, such as for example the patient database 22, hospital database 42, the test laboratory database 46, the pharmacy database 50, and the insurance company database 54 may each store some relevant information. These databases are organized using data structures (e.g., tables and arrays, records and fields, trees, and/or
lists) contained in one or more memories, such as the memories listed above or any of the storage devices listed in the discussion of Figure 2.
According to the present invention, a first one of the databases can include at least one of the following: patient age, patient gender, issued prescriptions, insurance plan information, doctor DEA number, and location of previous treatments. A second one of the databases can include at least one of the following: prescriptions, formulary information on prescription drugs, changes to the formulary information on prescription drugs, changes to insurance plans, promotions, Direct to Consumer advertising and additional health related information. A third one of the databases can include a list of messages which may be selected for transmission based upon satisfaction of certain triggering criteria. Typically, the triggering criteria depend upon patient record data values.
Figures 3-9 depict exemplary data structures used in storage media of the present invention. The data structures are depicted in a relational table format whereby information stored in one column (i.e., field) of a table is mapped or linked to information stored in the same row (i.e., record) across the other column(s) of the table. These data structures are used by the databases controlled by the doctor's computer system 20, the system server 32, and any of the third party servers 40, 44, 48, or 52 to facilitate transfer of up-to-date patient data.
Figure 3 is an exemplary patient data table 301 which may be stored in the patient database 22. The patient table 301 includes a field 303 for storing a patient identification number, a field 305 for storing patient contact information, a field 307 for storing a chronological log of medical diagnoses, a field 309 for storing a chronological log of prescriptions, and a field 311 for storing insurance information. The patient table 301, created by the doctor computer system 20, includes patient records.
Figure 4A is an exemplary table 401 stored in the system database 34. The table 401 preferably includes a field 403 for storing the patient identification number, a field 405 for
storing patient age or birth date, a field 407 for storing patient gender, a field 409 for storing a list of previously issued prescriptions, and a field 411 for storing insurance plans associated with the patient, a field 413 for storing a doctor's name and DEA number, and a field 415 for storing a doctor's location. The table 401, created by the system server 32, is updated by input from either the doctor's computer system 20 or any of the third party servers 40, 44, 48, or 52.
Figure 4B is an exemplary auxiliary table 451 which may be stored in the system database 34 or the patient database 22 or both. The auxiliary table 451 includes a field 453 for storing the patient identification number, a field 455 for storing a chronology of Rχ's (i.e. prescriptions) from other doctors, a field 457 for storing drug name and formulary information, a field 459 for storing third party promotions, and a field 461 for storing changes to insurance plans. The auxiliary table 451, created by the system server 32, is updated by input from either the doctor's computer system or any of the third party servers.
Figure 5 is an exemplary hospital-patient table 501 which may be stored in the hospital database 42. The hospital-patient table 501 includes a field 503 for storing a patient name :,, a field 505 for storing patient contact information, a field 507 for storing a chronological log of medical diagnoses, a field 509 for storing a chronological log of prescriptions, and a field 511 for storing the name of the attending physician who made the diagnosis and issued the prescription, a field 513 for storing patient admittance date, and a field 515 for storing patient discharge date. Figure 6 is an exemplary test lab-patient table 601 which may be stored in the clinic database 46. The test lab-patient table 601 includes a field 603 for storing a patient name, a field 605 for storing patient contact information, a field 607 for storing a chronological log of medical diagnoses, a field 609 for storing a chronological log of medical tests, and a field 611 for storing the name of the attending physician who ordered the medical tests.
Figure 7 is an exemplary pharmacy-transaction table 701 which may be stored in the pharmacy database 50. The pharmacy-transaction table 701 includes a field 703 for storing a patient name, a field 705 for storing patient contact information, a field 707 for storing a chronological log of prescriptions, and a field 709 for storing insurance company information. Figure 8 is an exemplary insurance-transaction table 801 which may be stored in the insurance company database 54. The insurance-transaction table 801 includes a field 803 for storing a patient name, a field 805 for storing patient contact information, a field 807 for storing a chronological log of medical diagnoses, a field 809 for storing a chronological log of medical treatment prescriptions, and a field 811 for storing payments by the insurance company.
Figure 9 is an exemplary message table 901 stored in the system database 34. The message table 901 includes a field 903 for storing a medical alert condition, a field 905 for storing a triggering flag associated with the medical alert condition, and a field 907 for storing a selected message. The record structures shown in Figures 3-9 are exemplary for purposes of illustration, and those skilled in the art will understand that different data structures may be used.
Records in the patient database and the third-party database contain fields together with a set of conventional utility operations for searching, sorting, recombining, and other database functions. One or more of U.S. Pat. Nos. 5,832,457; 5,649,114; 5,430,644; and 5,592,560 describe techniques for collecting and archiving information in databases such as the patient database, the system database, or any of the third-party databases, for example, and the entire contents of these patents are incorporated herein by reference.
Figure 10 is a flow chart showing a preferred method of the present invention. At step 1010, the user enters patient data into a patient data entry device 10. The user could be a doctor, nurse, or other clinical personnel. The doctor can generate a Rx and update
the patient information through the patient data entry device. In one preferred embodiment, the doctor provides this input via a handheld device, not restricting the doctor to a specific physical location. The doctor used the hand-held device to receive information while moving around his/her workplace. At step 1020, the doctor's computer system transmits the newly input patient data to the system server 32. The system server 32 receives the updated information and, in a later step, returns updated information back to the doctor's handheld or other office computer device where the information can be displayed in a human understandable form. The returned information may display to the doctor a more complete log of this patient's past medical treatment. Such information is invaluable in today's medical world where a patient frequently receives medical help from multiple doctors, not necessarily within the same group or in the same geographic region. This information may include medical records from other doctor's offices.
At step 1030, the system server 32 determines if a patient database record is complete. At step 1040, the process of the present invention branches according to the determination in step 1030. If yes, the process continues to step 1050. If no, the process continues to step 1070.
At step 1050, the system server 32 determines target information to be transmitted. The target information can either be transmitted to the user through the doctor's computer system or, if appropriate, can be transmitted to a third party, such as for example, a doctor or clinical professional at a hospital, a doctor or clinical professional at a clinic, a pharmacist at a pharmacy, or an agent at an insurance company. In determining target information to be transmitted, the system server 32 processes information in the system database, first to see if there should be any triggering flags set in the database fields, then the system server 32
determines which specific messages are associated with the triggering flag and therefore should be transmitted.
At step 1060, the system server 32 transmits the targeted information (e.g. the specific message) to the doctor's computer system 20 for conveyance to the patient entry/display device 10. Alternatively, the system server 32 can transmit the targeted information to appropriate third parties computer systems, such another doctor or medical professional's computer system in the same practice as the first doctor, or in consultation role at other clinics, hospitals, and pharmacies. In one aspect of the present invention, the doctor may direct (via a suitably programmed interface) the targeted messages to also be sent to alternative locations, such as a local pharmacy or to the patient. The targeted messages can be set to a printer, a facsimile, personal computer, a network address including an email address, or a hand held device at the doctor's office or the alternative locations.
Meanwhile, at step 1070, upon determination that the patient database record is not current, the system server accesses third-party servers such as servers 40, 44, 48, and 52 third party databases such as databases 42, 46, 50, 54 to obtain current information from the third party databases.
At step 1080, the system server 32 updates the system database 34 with current information obtained from any one of the third party databases. Access to these databases occurs via well known networking and Internet protocols.. At step 1090, the system server 32, having now obtained the current information (i.e. third-party information) similar to step 1050, determines the target information to be transmitted. As in step 1050, in doing so the system server 32 determines where to send the target information and the specific targeted messages to be sent.
At step 1100, the system server 32 having now determined the target information similar to step 1060 now transmits the target information. As in step 1060, in doing so the
system server 32 transmits the targeted information (e.g. the specific message) to the doctor's computer system 20 for conveyance to the patient entry/display device 10 or can transmit the targeted information to appropriate third parties such as another doctor or other medical professionals in the practice or in consultation at clinics, hospitals, and pharmacies. Step 1010 can include the step of the user entering patient information including, for example, a patient identification number via a wireless device including a phone, a pager, a hand-held device or a wired device including a personal or lab-top computer.
Step 1020 can include the step of processing the received patient information and the retrieved database records to update the patient records list, and formatting the patient records list into a standardized format. The doctor's computer system 20 preferably transmits to the system server 32 at least one of the following: a patient's age, a patient's gender, issued prescriptions, insurance plan information, a doctor's drug enforcement agency (DEA) number, and a location of previous treatments.
Step 1070 preferably includes the step of accessing with the system server 32 records in databases for a pharmacy, a hospital, or a test lab, or an insurance company
Step 1080 can include the steps of assimilating additional information into the system database 34 and transferring updated records to the doctor's computer system 20 for updating the patient database 22. The additional information can include at least one of the following: Rx's from doctors, formulary information on prescription drugs, changes to the formulary information on prescription drugs, changes to insurance plans, promotions, Direct to
Consumer advertising and additional health related information. Accordingly, in one aspect of the present invention, the system server 32 determines, based on additional information available for the patient, whether to contact third parties' servers and request data from them. For example, the system server 32 could request insurance information on a patient from a third party insurance server 52. The system server 32 preferably connects via the Internet 30
to third party servers to gather additional patient information. The system server 32 then updates patient records with third party information. The system server 32 can also connect to other third party servers to obtain additional information, which includes Rxs (i.e. medical treatments) by the doctors, formulary information, changes to insurance plans, and other third party promotions, etc.
Once the system server 32 receives information from all of the determined sources, the system server 32 transfers the information from the system server 32 to the doctor's computer system 20. Preferably, the doctor considers this information as part of a treating criteria. In one aspect of the present invention, the system server 32 provides updated information to the doctor's computer system 20 which updates the patient records contained in the patient database 22.
In another aspect of the present invention, whenever the system server 32 determines that a medical alert situation exists, such as, for example, when prescriptions from separate doctors conflict with the patient's medical history, the system server generates a selected message to be transmitted to the user. For example, a doctor or a pharmacist can be informed when a cautionary condition exists such as, for example, when a patient allergic to penicillin is diagnosed with an infection and a pharmacy is about to fill a prescription without knowledge of the patient's background allergy to penicillin. The system server may identify a medical alert situation by storing triggering flag values in the patient's record, and then determining when the values indicate a medical alert condition exists. For example, upon receiving data indicating that a patient has just recently been diagnosed as lethargic and unresponsive, and having stored data indicating that the patient is diabetic, the system server 32 sets a triggering flag associated with sending a specific message alerting the patient's doctor of the patient's diabetic history. The system server 32 reads the trigger flag field
values and transmits to the doctor the specific messages associated with trigger fields having values indicating that their associated messages should be transmitted.
For example, the system server 32 recognizing that the patient has just been diagnosed with a broken bone accesses the third party server at the hospital to determine if the patient was treated at the emergency room prior to his/her visit to the doctor's office. For example, if the doctor has no prior experience with a patient, the system server 32 may choose to contact local hospitals to determine if that patient's medical history is available. For example, if the system server 32 determined that another doctor (perhaps at a local hospital) has changed a medical treatment plan, the system server 32 can prompt the doctor to contact a nursing care facility where the patient resides to update the medical staff at the nursing care facility of the latest treatment schedule.
Preferably, a plurality of system responses are programmed into the system server 32 based on knowledge of medical situations encountered by those skilled in the medical sciences and medical professions. In another aspect of the present invention, the system server 32 compares the information retrieved and the information in existence in the system database to determine if a target message selected from a message database (to be discussed in more detail later) should be sent to the doctor via the doctor's computer system. The message database is included in the system server 32 and contains messages which are selected and printed based on selected treating criteria programmed into the system server 32.
In another aspect of the present invention, the system server 32 after selecting the target message(s) then formats the message(s) for printing at the doctor's office, pharmacy, hospital, test lab, or for distribution to a patient directly via mail, e-mail, fax, web access or to a patient's hand held device or any other suitable contacting device.
System server 32 and the data stored in database 34 are not accessible to parties that do not have consent of the patient whose record is stored therein, thereby ensuring patient confidentiality while enabling the patient's doctor to have the benefit of all information relevant to the patient. This invention can be conveniently implemented in a general purpose digital computer or a network of general purpose digital computers and/or microprocessors programmed to implement the methods of the present invention.
Obviously, numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.