Source: https://insight.rpxcorp.com/pat/US7092891B2
Timestamp: 2020-04-09 20:50:20
Document Index: 298255072

Matched Legal Cases: ['art 2802', 'art 2804', 'art 2806', 'art 2802', 'art 2804', 'art 2806', 'art 2900', 'art 2900', 'art 2802']

Patent US 7,092,891 B2
A secure medical records maintenance system including a first server that stores patient identification information indexed by patient identification numbers (PINs) and a second server that stores patient medical data indexed by medical record identification numbers. For security purposes, the medical data maintained in the second remote server cannot be correlated to the associated patient identification information maintained in the first server based on the information contained in the servers. A correlation table uniquely associating each medical record identification number with a particular one of the patient identification numbers is used to allow correlation of the databases. The correlation table for a particular patient typically resides on a patient'"'"'s removable memory storage device (smartcard). The correlation table for a practaioner'"'"'s patients may also reside on the practitioner'"'"'s computer, which is associated with the licensed medical practitioner having an assigned professional registration number
US 20100132033A1
PATIENT DIABETES DATA INTERCHANGE WITH ELECTRONIC MEDICAL RECORDS
US 20100076784A1
US 7,850,910 B2
US 20090162248A1
Smartcard Accessed Secure Electronic Data Storage System
US 20090282192A1
SYSTEMS AND METHODS FOR CONTROLLING ACCESS BY A THIRD PARTY TO A PATIENT'S MEDICAL RECORDS ON A MEDICAL INFORMATION CARD
US 20080126729A1
LOGICAL INTERFACE FOR MEDICAL RECORD DATA MINING
US 20080208633A1
CENTRALIZED MINING OF REMOTE MEDICAL RECORDS DATABASES
US 20080208914A1
System and Method for Providing a Personal Internet of Objects and Information
US 20080306772A1
Personal Infonet Incorporated
Portable veterinary medical record apparatus and method of use
US 20060074718A1
Kofi Nelson-Owusu, Yves Attiogbe Vimegnon
Automated system and method for evaluating insurable risks at point of sale
US 20050108062A1
Smartcard accessed dual server electronic data storage system
US 8,239,627 B2
IndentityTruth Inc.
US 8,583,455 B2
Tokenization of multiple-field records
US 8,620,882 B2
US 8,725,540 B2
US 10,593,004 B2
US 10,592,982 B2
NEHDC INC.
VITAL HEART SYSTEMS INC.
the first and second remote servers can be accessed by the practitioner computer through encrypted communications secured by an application procedure comprising validation of the practitioner'"'"'s registration number.
6. The secure medical records maintenance system of claim 5, wherein the application procedure comprises issuance of a client certificate ensuring that access to the first and second remote servers occurs from the practitioner'"'"'s computer.
This situation persists because of the high cost and inconvenience presently involved in obtaining cholesterol information. To obtain this information, most people go to a physician'"'"'s office, have blood drawn, and wait for the return of the blood chemistry analysis. Often, obtaining the results involves a second trip to the physician'"'"'s office. This is expensive and time consuming; the average cost is about $83 for each office cholesterol consultation, and the average wait for the results is several days.
In addition, there is a need for a medical records maintenance system, not only for blood cholesterol tests but for many types of medical information that can be obtained outside of the hospital environment. This need will increase with increases in the availability of remote health monitoring devices in the future, such as blood pressure measuring devices, blood sugar testing devices, blood cholesterol testing devices, AIDS testing devices, heart monitoring devices, sleep respiration monitoring devices, reproductive cycle and pregnancy monitoring devices, epileptic and other types of seizure monitoring devices, and a wide range of other remote health monitoring devices that may be developed in the future. As the availability of the remote health monitoring devices increases, users will have an increasing need for securely storing the tests results in electronic format. The current system of hard-copy and electronic medical records maintained in doctors'"'"' offices will become increasingly obsolete and inconvenient as the availability of electronically-stored medical data increases. Because a patient'"'"'s medical records are highly confidential, there is a need for a highly secure and permanent medical records maintenance system under the control of individual patients and their doctors.
The present invention meets the needs described above in a health monitoring and diagnostic device referred to as a LIFESTREAM cholesterol meter. This meter is configured as a self-contained testing and diagnostic unit in a clam-shell type case. One side of the case includes a biological sample gathering device, such as spring-loaded finger stick, and a compartment for carrying one or more packages of disposable items, typically including a test strip, a needle for the finger stick, and an alcohol swipe. The other half of the case includes a test strip reader, a user input device such as a key pad, and a display device such as a liquid crystal display. The meter reads a test strip carrying a biological sample, such as a droplet of blood, and within minutes displays test results, such as total cholesterol levels, on the meter'"'"'s display.
The hand-held LIFESTREAM cholesterol meter drastically reduces the costs and inconvenience associated with obtaining cholesterol tests by performing total cholesterol tests in virtually any location, including a physician'"'"'s office, a pharmacy, a clinic, or in the privacy of the patient'"'"'s home. The meter produces the test results within minutes using on-board circuitry and programming. The meter also includes an on-board diagnostic program that prompts for additional diagnostic information, such as the patient'"'"'s age, gender, weight, family history of heart disease, blood pressure, and so forth.
The meter then translates this diagnostic information, along with the test results, into diagnostic results that may be more meaningful to the user than the test results alone. For example, the meter may use a well-known methodology, such as the Framingham Medical Study, to produce diagnostic results including the user'"'"'s cardiac age (as compared to chronological age), recommended weight loss, 5-year risk of heart attack, 10-year risk of heart attack, an assessment of stroke risk, and other results that will be easily and immediately understood by the patient. Like the test results themselves, these more meaningful diagnostic results are displayed on the meter within minutes.
The health report server typically works in concert with the patient'"'"'s physician or pharmacist, who may provide additional diagnostic information to the server, such as a newly-prescribed drug therapy, other currently-prescribed drugs for the patient, exercise and dietary recommendations, and so forth. Within minutes, the health report server assembles a comprehensive health report including a data sheet for the newly-prescribed drug, cross-reaction information for the newly-prescribed drug and the other currently-prescribed drugs, weight and total cholesterol goals, exercise and dietary recommendations, any food or activity warnings associated with the overall therapy package, and recommendations for on-going monitoring using the meter. This provides a complete written record of the patient'"'"'s current condition, the therapy prescribed by the physician and filled by the pharmacist, and a roadmap for monitoring the patient'"'"'s progress during the ensuing therapy.
The meter also includes a number of advantageous security features. For example, the meter cannot be activated until a user enters a proper activation code. This typically requires that the user call the manufacturer, which provides an opportunity to verify the meter'"'"'s authenticity, set up a data file for the meter in the health report server, and tell the user how to update the meter software, if necessary. If a software update is indicated, the user may be instructed to activate the meter, initialize a smartcard, load the smartcard into a computer station, and establish a network connection with the health report server. The server can then download the new software (e.g., new version of an existing software module or a new software module) to the smartcard, which, in turn, can be placed back in the meter. The new software can then be uploaded to the meter.
The meter may also require each smartcard to be initialized with a personal identification number (PIN). Patient-specific PINs allow multiple patients to use the same meter, and also allows each patient'"'"'s data to be secure to that patient. That is, only the patient or someone authorized by the patient (i.e., knowing the patient'"'"'s PIN) can read the medical data stored on the smartcard. In this manner, each patient controls his or her own medical data, which can be a particularly important attribute for highly sensitive medical data, such as AIDS tests, cancer tests, and the like.
To provide activation verification, the meter may receive an activation code through the user input device, compute an activation code based on the current date and instructions contained in an activation routine stored within the meter, and activate the meter only if the computed activation code corresponds to the received activation code. In addition, to provide security to a patient'"'"'s medical data, the meter may determine whether a PIN has been previously stored on the removable memory storage device. If a PIN has not been previously stored on the removable memory storage device, the meter prompts the user to enter a PIN and stores the received PIN on the removable memory storage device. Alternatively, if a PIN has been previously stored on the removable memory storage device, the meter prompts the user to enter a PIN, compares the stored PIN to the received PIN, and writes the test results to the removable memory storage device only if the stored PIN corresponds to the received PIN.
To provide an opportunity for the proprietor of the health monitoring device to collect revenue based on use of the device, the removable memory storage device may be utilized as a type of “debit card” or payment'"'"'source for use with the health monitoring device. That is, the removable memory storage device may be purchased with a monetary value, or it may have a monetary value that is replenishable over the Internet using a bank credit or debit card or other conventional payment source. The health monitoring device may then deduct the cost of performing particular services from the monetary value represented by the monetary balance stored on the removable memory storage device. In other words, the health monitoring device may be configured to activate for the performance of a service upon deducting a charge for the service from a monetary value stored on a removable memory storage device inserted into the device.
The invention also includes a secure medical records maintenance system. Although this system is specifically adapted for use with the health monitoring device described above, it may be used to store any type of electronic data including a wide variety of medical records, and is particularly convenient for storing a wide range of electronic medical data generated remotely from the hospital or doctor'"'"'s office environment. The secure medical records maintenance system includes a number of removable memory storage devices, which are each operable for storing medical data for an associated patient. Each removable memory storage device also stores a patient-specified personal identification number (PIN), a medical records identification number secured by the PIN, and a patient identification number secured by the PIN.
To allow correlation of the data stored in the two servers, the secure medical records maintenance system includes a correlation table uniquely associating each medical records identification number with a particular one of the patient identification numbers. The correlation table for a particular patient typically resides on the patient'"'"'s removable memory storage device. The correlation table for a practitioner'"'"'s patients may also reside on the practitioner'"'"'s computer, such as a doctor'"'"'s or pharmacist'"'"'s computer, that is associated with a licensed medical practitioner having an assigned professional registration number. For further security, the first and second remote servers are accessed by the practitioner'"'"'s computer through encrypted communications secured by an application procedure that includes validation of the practitioner'"'"'s registration number. The application procedure may be further secured by receipt and validation of a practitioner-supplied PIN. Moreover, the application procedure typically includes issuance of a client certificate insuring that access to the first and second remote servers occurs from the same practitioner'"'"'s computer and browser that initiated the application procedure.
Because the data on the servers is separate and secure from each other, access may be granted to either server without identifying any particular patient'"'"'s medical data. For example, access may be granted to the first remote server, but not to the second server, for the purpose of generating a mailing list of patients without divulging any medical data associated with the patients. Similarly, access may be granted to the second remote server, but not to the first server, for the purpose of conducting investigative analyses involving the medical data without divulging any patient identification information associated with the patients.
The second compartment 16 houses the electronic components of the meter 10, including a test strip reader 32, a display device 34, a user input device 36, and one or more memory reading devices 38a–d. Each of these memory reading devices is configured to receive a corresponding memory device 40a–d. The second compartment 16 also includes an instructional label 42 located adjacent to the display device 34. Internally, the second compartment 16 houses a motherboard, an analyzer board, and a data drive that control the functionality of the meter 10. These internal components are described with reference to FIG. 3, and the functionality of the meter 10 is described with reference to FIGS. 4–13. Additional functionality of the meter 10 for use with a debit-card type payment system is described with reference to FIGS. 30–31.
The memory reading devices 38a–d may be romkey sockets, and the memory devices 40a–d may be romkeys that removably insert into the sockets. As shown in FIG. 1A, the meter 10 preferably includes four romkey sockets. Nevertheless, the meter 10 could also be configured with only one socket because the romkeys themselves are removable. The romkeys, which store identification, expiration, and calibration data for a corresponding lot of test strips 28, are desirable because they are small, may be easily packaged with the corresponding test strips, and have an adequate amount of computer-readable memory. But the romkey sockets may be replaced by a magnetic card reader, an optical reader, or another reader suitable for use with a memory storage device that can be easily shipped with a corresponding lot of test strips 28 and has an adequate amount of computer-readable memory.
To use the meter 10, a patient first opens the meter and removes the finger stick 20 and the package of disposable items 26. The patient then opens the package, installs the needle 29 in the finger stick 20, and wipes the alcohol swipe 30 on the area of the finger to be stuck with the needle. The patient also inserts the correct romkey for the test strip 28, represented by the romkey 40d, into a corresponding romkey socket 38d and manipulates the keypad 44, 46 to indicate to the meter 10 which romkey socket contains the correct romkey. The patient then sticks the selected finger with the finger stick 20, places a droplet of blood 44 on an indicated area of the test strip 28, and inserts the test strip 28 into the test strip reader 32.
FIG. 1B is a rear view of the meter 10, which shows the outside of the meter. The outside of the first compartment 14 includes the manufacturer'"'"'s name, Lifestream Technologies, Inc., and the meter'"'"'s trademark, LIFESTREAM. The outside of the second compartment 16 includes a data drive 50, which includes an opening 52 for receiving a removable memory storage device 54. For example, the data drive 50 may be a smartcard drive, such as an STM IC: MC33560ADW manufactured by Motorola, and the removable memory storage device 54 may be a smartcard usable with this drive. This smartcard typically includes an electrical contact 56 for reading and writing data and a small microprocessor 58, which typically controls security aspects of the smartcard. Specifically, the smartcard includes a PIN-protected secure memory and an unsecure memory. The microprocessor 58 controls the PIN and any other functionality resident on the smartcard.
Once the medical data arrives at the computer station 108, it establishes a network connection with the health report server 102, typically over the Internet 110. The medical data is then transmitted to the health report server 102, which may also prompt the user for additional diagnostic and health report information. Specifically, the health report server 102 typically works in concert with the patient'"'"'s physician or pharmacist, who may provide additional diagnostic information to the server, such as a newly-prescribed drug therapy, other currently-prescribed drugs for the patient, exercise and dietary recommendations, and so forth. Within minutes, the health report server 102 assembles a comprehensive health report 112 that is transmitted back to the computer station 108, where it may be printed on a local printer 114. User access procedures and a menu-driven user interface system for generating the health reports is described with reference to FIGS. 17–29.
The comprehensive health report 112 typically includes a data sheet for the newly-prescribed drug, cross-reaction information for the newly-prescribed drug and the other currently-prescribed drugs, weight and total cholesterol goals, exercise and dietary recommendations, any food or activity warnings associated with the overall therapy package, and recommendations for on-going monitoring using the meter. This provides a complete written record of the patient'"'"'s current condition, the therapy prescribed by the physician and filled by the pharmacist, and a roadmap for monitoring the patient'"'"'s progress during the ensuing therapy.
The Internet 10 allows a wide variety of users to access the health report server 102, which allows meters to be deployed in a variety of settings. For example, the accessing computer stations may include a physician'"'"'s computer station 116, a pharmacist'"'"'s computer station 118, an individual'"'"'s computer station 120, and many others. This will allow meters to be effectively deployed for multi-patient use in clinics, physicians'"'"' offices and pharmacies, as well as for individual patient or family use in the privacy of their own homes.
FIG. 3 is a functional block diagram of the health monitoring and diagnostic device 10, which is also referred to as a meter. The meter includes an analyzer board 150, a mother board 152, a memory reading device 154 including the romkey sockets 38a–d and corresponding romkeys 40a–d, and a user interface 156 including the display device 34, the speaker 35, and the input device 36. The memory reading device 154 and the user interface 156 were described with reference to FIG. 1A. Although the analyzer board 150 and the mother board 152 may be configured as two separate integrated circuit boards, alternatively they may be -combined into a single integrated circuit board, or deployed on more than two integrated circuit boards.
The analyzer board 150 may be part of the GLUCOTREND Basic TIM (test instrument module) assembly No. 1739905-741 manufactured by Boehringer Mannheim, Roche Diagnostics GmbH. This board includes the test strip reader 32, which was described with reference to FIG. 1A, a test instrument module 158, and a romkey driver 160. The test strip reader 32 reads the test strip 28 carrying the blood sample 44. The romkey driver 160 reads the calibration data for the test strip 28 from a corresponding romkey, such as the romkey 40d, and the test instrument module 158 computes the test results from the test strip reading and the calibration data. These test results are then passed to the motherboard 152.
To verify test strips, the romkey driver 160 reads a code number from a romkey, such as the romkey 40d, installed in the meter 10. The code number typically includes the lot number for the corresponding test strips and a test type ID stored on the romkey by the manufacturer of the meter 10. The test strip 28 has an associated test strip identification number 172 that is mathematically derived from the code number and printed on the test strip itself, the packaging for the test strip, or a tag packaged with the test strip. The meter 10 prompts the user to enter the test strip identification number 172 into the meter using the keypad 46.
The meter 10 also reads the code number from the memory device, mathematically derives a test strip identification number corresponding to the code number, compares the received test strip identification number to the derived test strip identification number, and activates the meter for use with the test strip only if the received test strip identification number corresponds to the derived test strip identification number. The romkey 40d also stores an expiration date for the corresponding test strip 28. The meter 10 reads the expiration date and activates for use with the test strip 28 and the romkey 40d only if the expiration date is prior to a current date read by the meter from the internal clock 164.
FIG. 4 is a logic flow diagram illustrating a routine 400 for activating the meter 10. This routine requires that a user enter a proper activation code to activate the meter 10. This typically requires that the user call the manufacturer, which provides an opportunity to verify the meter'"'"'s authenticity, set up a data file for the meter in the health report server, and tell the user how to update the meter software, if necessary. If a software update is indicated, the user may be instructed to activate the meter, initialize a smartcard, load the smartcard into a computer station, and establish a network connection with the health report server. The server can then download the new software (e.g., new version of an existing software module or a new software module) to the smartcard 54, which, in turn, can be placed back in the meter 10. The new software can then be uploaded to the meter.
Step 906 is followed by routine 908, in which the meter 10 prompts the user for additional diagnostic information. Routine 908 is described below with reference to FIG. 10. Routine 908 is followed by routine 910, in which the meter 10 computes immediate diagnostic results. Routine 910 is described below with reference to FIG. 11. Routine 910 is followed by step 912, in which the meter 10 displays the diagnostic results on the display device 34. Step 912 is followed by step 914, in which the meter 10 stores the test results, the diagnostic information, and the diagnostic results (and also stores the meter'"'"'s serial number) on the smartcard.
FIG. 10 is a logic flow diagram illustrating routine 908 for obtaining cholesterol-related diagnostic information for the meter 10. Routine 908 begins following step 906 shown on FIG. 9. In step 1002, the meter 10 prompts for and receives the patient'"'"'s gender. Step 1002 is followed by step 1004, in which the meter 10 prompts for and receives the patient'"'"'s ethnicity. Step 1004 is followed by step 1006, in which the meter 10 prompts for and receives an indication of the patient'"'"'s family history of heart disease. Step 1006 is followed by step 1008, in which the meter 10 prompts for and receives an indication of the patient'"'"'s personal history of heart disease.
Step 1014 is followed by step 1016, in which the meter 10 prompts for and receives an indication of the patient'"'"'s height. Step 1016 is followed by step 1018, in which the meter 10 prompts for and receives an indication of the patient'"'"'s weight. Step 1018 is followed by step 1020, in which the meter 10 prompts for and receives an indication of the patient'"'"'s age. Step 1020 is followed by step 1022, in which the meter 10 prompts for and receives an indication of the patient'"'"'s blood pressure. Step 1022 is followed by step 1024, in which the meter 10 prompts for and receives an indication of the patient'"'"'s fitness. Step 1024 is followed by the “RETURN” step, which goes to routine 910 shown on FIG. 9. It will be appreciated that the preceding list of diagnostic information is only illustrative of the type of information that may be gathered, and that less data, different data, or more data could be gathered, if desired.
Step 1112 is followed by step 1114, in which the meter 10 calculates and displays a cardiac age (to compare against the patient'"'"'s chronological age). Step 1112 is followed by step 1114, in which the meter 10 calculates and displays an extended cardiac age (e.g., cardiac age compared to chronological age for five, ten, fifteen, etc. years into the future). Step 1116 is followed by step 1118, in which the meter 10 calculates and displays a medical risk index associated with stroke, such as “very high,” “high,” “moderate,” “low,” or “very low.” Step 1118 is followed by the “RETURN” step, which goes to step 912 on FIG. 9. It will be appreciated that the preceding list of diagnostic results is only illustrative of the type of information that may be generated, and that less data, different data, or more data could be generated, if desired.
FIG. 14 is a functional block diagram of a system for using the meter 10 in connection with a secure medical records maintenance system 1400. The meter 10 stores a patient'"'"'s test results and diagnostic information on a removable memory storage device, such as the smartcard 54. A conventional interface 106 may then be used to interface the smartcard 54 with a conventional desktop, laptop or other type of computer 108, which in turn communicates with other computers over a network-based computer system, such as the Internet 110. As discussed previously, this Internet link may be used to produce a printed health report booklet 112 including a health assessment based on a patient'"'"'s test results and diagnostic information, which a health-care provider typically provides to the patient.
Although this secure medical records maintenance system 1400 is specifically adapted for use with the meter 10, it may be used to store any type of electronic medical records, and is particularly convenient for storing a wide range of electronic medical data generated remotely from the hospital or doctor'"'"'s office environment. In addition, the secure medical records maintenance system 1400 may read medical data stored on memory storage devices other than the smartcard 54, and may operate over computer networks other than the Internet 100.
The secure medical records maintenance system 1400, which is presently known as the “PRIVALINK” system, operates in connection with a software module 1402 installed on the accessing computer 108. This software is presently known as the “PRIVALINK” user site software. The server-side “PRIVALINK” system 1400 includes a first remote server 1404 that stores patient identification information, a second remote server 1406 that stores patient medical data, an encryption/decryption module 1408 that implements encryption and other security-related functions, and a booklet generation module 1410, which produces printed health report booklets 112 based on the information stored in the servers 1404, 1406. The patient identification information and medical data are maintained in separate, secure servers 1404, 1406 to prevent correlation of a specific patient'"'"'s medical data with the associated patient identification information.
Because the data on the servers 1404, 1406 is separate and secure from each other, access may be granted to either server without identifying any particular patient'"'"'s medical data. For example, access may be granted to the first remote server 1404, but not to the second server 1406, for the purpose of generating a mailing list of patients without divulging any medical data associated with the patients. Similarly, access may be granted to the second remote server 1406, but not to the first server 1404, for the purpose of conducting investigative analyses involving patient medical data without divulging any patient identification information associated with the medical data.
FIG. 16 a functional block diagram illustrating security aspects of the secure medical records maintenance system 1400. The secure medical records maintenance system 1400 preferably includes a large number of smartcards 54a–n, which operate in concert with a large number of meters 10a–n. Although each smartcard 54a–n is preferably used to store medical data for an associated patient, each card could be used to store medical data for multiple patients. Each smartcard 54 also stores a patient-specified personal identification number (PIN), and may store PINs for multiple patients if the smartcard is configured to store medical data for multiple patients. Each PIN is used to gain access to a secure storage area on the smartcard 54, which stores an associated patient identification number and medical records identification number, which are assigned by the secure medical records maintenance system 1400.
For security purposes, the medical data maintained in the second remote server 1406 cannot be correlated to the associated patient identification information maintained in the first remote server 1408 based on the information contained in the first and second remote servers. To allow correlation of the data stored in the two servers 1404, 1406 the secure medical records maintenance system 1400 includes a correlation table 1600 uniquely associating each medical records identification number with a particular one of the patient identification numbers. The correlation table 1600 for a particular patient typically resides in the PIN-secured storage area on the patient'"'"'s smartcard 54. The correlation table 1600 for a practitioner'"'"'s patients may also reside on the practitioner'"'"'s computer 108, such as a doctor'"'"'s or pharmacist'"'"'s computer, that is associated with a licensed medical practitioner having an assigned professional registration number (DEA number). Each practitioner'"'"'s correlation table 1600 is preferably encrypted and maintained in a secure file. The proprietor of the secure medical records maintenance system 1400 may also maintain a complete back-up correlation table 1600, typically in a secure encrypted file located on a separate file server.
For further security, the first and second remote servers 1404, 1406 are accessed by the practitioners'"'"' computers 108a–n through encrypted communications secured by an application procedure that includes validation of the practitioner'"'"'s registration number (DEA number). This access will be limited to medical records and patient identification information associated with the accessing practitioner. In other words, each practitioner will only have access to his or her patients'"'"' medical records and patient identification information.
Similar access procedure may be implemented for individual patients, except that access will be limited to that particular patient'"'"'s medical records and patient identification information. For example, individual patients may register in advance with the proprietor of the system 1400, which will issue each patient a unique registration number. In this case, the first and second remote servers 1404, 1406 may accessed by computers operated by the individual patients through encrypted communications secured by an application procedure that includes validation of the patient'"'"'s registration number.
Those skilled in the art will appreciate that the data distribution system implemented by the secure medical records maintenance system 1400 includes many aspects of data security. For example, a patient'"'"'s medical records identification number cannot be obtained from the patient'"'"'s smartcard 54 without access to the patient-assigned PIN. In addition, while the patient'"'"'s medical data is indexed by the patient'"'"'s medical records identification number in the second server 1406, the patient'"'"'s name and other identification information cannot be retrieved from the first server 1404 using this data. Similarly, a hacker obtaining assess to one or both of the servers 1404, 1406 cannot correlate patient identification information with patient medical data. In addition, the correlation data for the entire secure medical records maintenance system 1400 is distributed among the various smartcards 54a–n and practitioner computers 108a–n registered for use with the system. Thus, a hacker cannot obtain the correlation data for any single patient, much less the entire database, through access to the centrally-maintained data servers 1404, 1406.
For further security, the secure medical records maintenance system 1400 cannot be accessed from the a medical practitioner'"'"'s computer 108 without knowledge of the proper practitioner-assigned PIN. And all communication between the practitioner'"'"'s computer 108 and the secure medical records maintenance system 1400 are encrypted for transmission security. Furthermore, each correlation table 1600, which provides the link between patient identification numbers and medical records identification numbers for a particular practitioner, may itself be encrypted, with the key to this encryption stored in a separate location. For example, this encryption key may be a practitioner PIN or GUID stored on a PIN-secured area the practitioner'"'"'s computer 108 or on a smartcard 54 assigned to the practitioner.
Step 1802 is followed by step 1804, in which the PRIVALINK software 1402 displays an application screen and receives client input including the practitioner'"'"'s professional registration number, typically a DEA number. Step 1804 is followed by step 1806, in which the PRIVALINK software 1402 receives a certification request including selection of an encryption type. This is typically associated with completion of the data-entry fields of the application screen and selection of a “submit” control item. Step 1806 is followed by step 1808, in which the PRIVALINK software 1402 downloads an encryption program module from the server-side encryption/decryption module 1408, such as an “ACTIVE X” control or applet, to the client'"'"'s computer 108. This encryption program module typically includes a “key” or nugget of information to be stored in the accessing browser. The server-side encryption/decryption module 1408 can later check an accessing computer for the presence of the “key” to ensure that the accessing computer and browser is the same as the one going through the application procedure.
If the “key” is properly validated, step 1814 is followed by step 1816, in which the server-side encryption/decryption module 1408 transmits a “server root CA” and a “client certificate” to the PRIVALINK software 1402 on the client'"'"'s computer 108. Step 1816 is followed by step 1818, in which the PRIVALINK software 1402 links the applicant to a secure area of the encryption/decryption module 1408, which validates the presence of the server root CA. If the server root CA is properly validated, step 1818 is followed by step 1820, in which the PRIVALINK software 1402 prompts the user to identify the client certificate for use in the transaction. If the client certificate is properly validated, step 1820 is followed by step 1822, in which the PRIVALINK software 1402 links the applicant to a login screen. Step 1822 is followed by step 1824, in which the encryption/decryption module 1408 saves the transaction documentation for the client'"'"'s application procedure. Step 1824 is followed by the “CONTINUE” step, which returns to routine 1704 shown in FIG. 7.
FIG. 19 is a logic flow diagram illustrating a routine 1704 for logging into the secure medical records maintenance system 1400. Routine 1704 begins following routine 1702 shown in FIG. 7. In step 1902, the PRIVALINK software 1402 displays a login screen on the client'"'"'s computer 108. Step 1902 is followed by step 1904, in which the PRIVALINK software 1402 loads the client'"'"'s registration number, which was obtained during the application procedure described with reference to FIG. 18, into the login screen. That is, an accessing client does not have an opportunity to enter the login procedure without having first having gone through the application procedure described with reference to FIG. 18, which requires the applicant to provide a valid registration number, which typically may be a DEA number for a licensed medical practitioner or a registration number issued by the proprietor of the secure medical records maintenance system 1400 for an individual patient.
Step 1904 is followed by step 1906, in which the PRIVALINK software 1402 receives the practitioner'"'"'s personal identification number (PIN). Step 1906 is followed by step 1908, in which the encryption/decryption module 1408 validates the practitioner'"'"'s personal identification number (PIN) for use with the received professional registration number. Step 1908 is followed by step 1910, in which the encryption/decryption module 1408 determines whether the received PIN is a new PIN for use in connection with the received professional registration number. If the received PIN is a new PIN for use in connection with the received professional registration number, the “YES” branch is followed from step 1910 to step 1912, in which the PRIVALINK software 1402 prompts the user to complete the interface screens 2000–2007 (FIGS. 20–27). Step 1912 and the “NO” branch from step 1910 are followed by step 1914, in which the client is linked to the interface screens 2000–2007 (FIGS. 20–27). Step 1914 is followed by “CONTINUE” step, which returns to step 1706 shown on FIG. 7.
Step 1708 is followed by step 1710, in which the PRIVALINK software 1402 displays an “address” user interface 2100. FIG. 21 is an illustration of a typical “address” user interface 2100. The interface 2100 includes a first field 2102 for entering a practitioner registration number, typically a DEA number, and a second field 2104 for entering a practitioner-assigned PIN. The interface 2100 also includes a number of other fields for entering the practitioner'"'"'s contact information, such as address, phone number, and so forth. The interface 2100 also includes an “address” tab 2106, a “billing info” tab 2108, and a “cover letter” tab 2110 displayed adjacent to the user interface 2100. These tabs allow the user to toggle among corresponding user interface screens. As noted above, the interface 2100 initially appears in a “default” mode with the “address” tab 2106 selected.
Step 1716 is followed by step 1718, in which the PRIVALINK software 1402 displays a “patient information” user interface 2500. FIG. 25 is an illustration of a typical “patient information” user interface 2500. This interface includes a number of fields for entering patient identification information, such as address, phone number, and so forth. As described previously with reference to FIG. 16, this patient identification information is typically indexed by the patient identification number and stored in the first server 1404, whereas the patient'"'"'s medical data is typically indexed by the patient'"'"'s medical records identification number and stored in the second server 1406.
Step 1720 is followed by step 1722, in which the PRIVALINK software 1402 displays a “generate reports” user interface 2700. FIG. 27 is an illustration of a typical “generate reports” user interface 2700. This interface includes a number of fields for selecting items to be included in a patient'"'"'s health report booklet, such as cover letter, summary, evaluation, and so forth. The interface includes a number of fields for selecting therapy items to be prescribed for the patient and reflected in the patient'"'"'s health report booklet, such as lifestyle therapy, lipid drug prescription, blood pressure drug prescription, and so forth.
FIG. 28 is an illustration of typical health report charts generated by the secure medical records maintenance system 1400 for inclusion in a patient'"'"'s health report booklet. These charts include a “coronary risk factors” chart 2802, a “personal health consequences” chart 2804, and an “extended health assessment” chart 2806. The “coronary risk factors” chart 2802 includes test results and diagnostic information along with ideal ranges and patient goals for these items. The “personal health consequences” chart 2804 includes interpretive data, such as pounds overweight, cardiac age, and stroke risk. The “extended health assessment” chart 2806 includes a projection of future interpretive data, such as a projected comparison of the patient'"'"'s chronological age and cardiac age.
FIG. 29 is an illustration of an additional health assessment chart 2900 generated by the secure medical records maintenance system 1400 for inclusion in a patient'"'"'s health report booklet. This chart includes a pictorial representation of cardiac risk factors, such as gender, smoker, personal history, and so forth. The health assessment chart 2900 typically presents a pictorial assessment of the “coronary risk factors” shown in chart 2802.
LifeNexus, Inc. (Orangehook, Inc.)
Moody, James L., Nesbitt, Kenn A., Clegg, Kenneth D., Maus, Christopher T., Coad, Craig A., Connolly, Jackson B., Coad, Noah M.
422/68.1, 600/309, 600/310, 705/2, 705/13, 436/811, 709/217, 709/219, 709/203
A61B 5/4261 : Evaluating exocrine secreti...
Y10S 436/811 : Test for named disease, bod...
Health Monitoring And Diagnostic Device And Network Based Health Assessment And Medical Records Maintenance System
Sponsoring Entity: Lifestream Technologies Inc.
Current Assignee: Orangehook, Inc.
Sponsoring Entity: LifeNexus, Inc. (Orangehook, Inc.)
Sponsoring Entity: Polymer Technology Systems Incorporated (Polymer Systems Incorporated)
US 8,310,368 B2
Current Assignee: Clemson University
Sponsoring Entity: Clemson University