Computerized medical diagnostic and treatment advice system

Abstract

A system and method for providing computerized, knowledge-based medical diagnostic and treatment advice. The medical advice is provided to the general public over a telephone network. Two new authoring languages, interactive voice response and speech recognition are used to enable expert and general practitioner knowledge to be encoded for access by the public. “Meta” functions for time-density analysis of a number of factors regarding the number of medical complaints per unit of time are an integral part of the system. A semantic discrepancy evaluator routine along with a mental status examination are used to detect the consciousness level of a user of the system. A re-enter feature monitors the user's changing condition over time. A symptom severity analysis helps to respond to the changing conditions. system sensitivity factors may be changed at a global level or other levels to adjust the system advice as necessary.

Description

RELATED APPLICATIONS

This application :, .

• • This example tests for the presence of a patient record object labeled “OBJECT2”, loads the contents of the digit buffer into memory variable Phone, and pushes the value of memory variable Age onto the run time stack.

Each node has the “next” table or list. The next list indices range from 1 to 9, inclusive. The next list contains either a single node number, or an if expression. For all node types, except the Hangup node, there will be at least one next list:

• • Link and Prompt nodes: the next node is stored at table index 1.
  • Yes/No node: the next node for the Yes response is stored at table index 1, and the No response is stored at index 2. This corresponds to the prompt, “if the answer is yes.

    Two types of analysis are performed by the meta function:

    • • i. Pattern Matching
      • ii. Time density
        i. Pattern Matching

    In pattern matching analysis, the meta function compares the input strings with the record fields in the patient's consultation history database 262. The use of the ‘*’ wildcard character in the input string will cause the meta function to ignore the corresponding character position in the record field, thereby enabling the meta function to examine only the fields of interest. By providing input strings that are either general or specific, the fields of interest for analysis are selected. For example,
    Meta(“NHDA”, “****”, “**********”, T₁, T₂)
    will cause the meta function to only consider past consultations for the problem of headache, regardless of the anatomic system and cause involved.

    Through the use of a common syntax, the meta process supports four types or modes of pattern matching analysis, shown here through examples:

    • (a) Problem Analysis:
      Meta(“NHDA”, “****”, “**********”, 06/01/93, 12/31/93)

    Here the meta function will find the number of complaints of headaches that occurred between Jun. 1, 1993 and Dec. 31, 1993.

    • (b) Anatomic System Analysis:
      Meta(“****”, “D***”, “***********”, 06/01/93, 12/31/93)

    Here the meta function will find the number of complaints involving the gastro-intestinal system between Jun. 1, 1993 and Dec. 31, 1993. For example, if a patient consulted the MDATA system 100 once for abdominal pain, once for vomiting, and once for diarrhea, but each on a different occasion, the system would recognize that these are all problems involving the gastrointestinal tract.

    • (c) Cause Analysis:
      Meta(“****”, “****”, “IB*********”, 06/01/93, 12/31/93)

    Here the meta function will find the number of complaints that were found to be caused by bacterial infection between Jun. 1, 1993 and Dec. 31, 1993. The problems (complaints) caused by bacterial infection could be in different parts of the body.

    • (d) Combination Analysis:
      Meta(“NHDA”, “****”, “I**********”, 06/01/93, 12/31/93)

    Here the meta function will find the number of complaints of headache that were found to be caused by infection between Jun. 1, 1993 and Dec. 31, 1993.

    ii. Time Density

    If the pattern matching analysis finds at least three matching records in the patient's consultation history database 262, then the meta function performs a time density analysis. Time density refers to the amount of time between each consultation. If the amount of time between consultations is getting shorter, then the frequency of consultation suggests that the nature of the complaint is getting worse. Time density analysis reveals when a problem is getting better, and when it is getting worse.

    Time density analysis uses the meta records that matched the pattern matching criteria. The computer designates the most recent meta record ‘n’, the next most recent is record ‘n−1’, and the second most recent is record ‘n−2’. The time stamp of each meta record is examined, and two time difference values, X and Y, are determined according to the formula:
    X=time difference(n−2, n−1)
    Y=time difference(n−1, n)

    The ratio of these time differences produces the time density ratio (TDR):
    Time Density Ratio=X/Y

    The significance of the time density ratio value can be seen through the following examples:

    EXAMPLE 1

    Time between Consultations is the Same

    Consultation Date of Consultation
    
    n-2          Jun. 1, 1993
    n-1          Jun. 8, 1993
    n            Jun. 15, 1993

    
    Calculate:
    X=time difference(06/01/93, 06/08/93)=7 days
    Y=time difference(06/29/93, 06/15/93)=7 days
    Time Density Ratio=7 days/7 days=1.0

    EXAMPLE 2

    Time between Consultations is Getting Shorter

    Consultation Date of Consultation
    
    n-2          Jun. 1,1993
    n-1          Jun. 22,1993
    n            Jun. 29,1993

    
    Calculate:
    X=time difference(06/01/93, 06/22/93)=21 days
    Y=time difference(06/29/93, 06/22/93)=7 days
    Time Density Ratio=21 days/7 days=3.0
    When consultations are occurring at even intervals, then the TDR value is close to unity. If the frequency of consultations is decreasing, then the TDR value will be less than 1.0. This would be typical of a problem that is resolving itself. If the frequency of consultations increases, then the TDR value will be greater than one. In the second example, the TDR value of 3.0 indicates a consultation rate increase of three times during the analysis period. This would be typical of a problem that is rapidly getting worse.
    Return Values

    After the meta function returns, two local memory variables are installed in the symbol table and contain the results of the meta analysis:

    • • i. Match Counter (MC)—an integer that contains the number of meta string matches found within the time window.
      • ii. Time Density Ratio (TDR)—a floating point value that expresses whether the frequency of meta string matches is increasing or decreasing.

    After calling the meta function, the algorithm author can then make decisions based upon the values returned in these two memory variables.

    For example:
    Meta(“NHDA”, “****”, “**********”, 06/01/93, 12/31/93)
    If MC>=3 then 100 else 101

    The meta function counts the number of complaints of headache between Jun. 1, 1993 and Dec. 31, 1993. If the number of complaints found (MC) is greater than or equal to 3
    If TDR>=2.0 then 200 else 201
    The meta function is invoked to count the number of diagnoses attributed to a cause of infection. If the infection caused diagnoses found have a time density ratio greater than or equal to 2.0, then the evaluation process branches to node 200; otherwise it branches to node 201.

    Referring again to FIG. 11a, the meta function 500 initializes at state 540 by popping the input parameters off the run-time stack and storing them in local memory variables: PS for problem string, SS for anatomic system string, CS for cause string, T₁ for the beginning date and T₂ for the ending date. After the start state 542, the computer moves to state 544 and initializes the pattern match counter to zero.

    The computer 102 then moves to state 546 wherein it begins the pattern matching analysis. The computer 102 reads the first meta record in the patient's consultation history database 262 and moves to a decision state 548 wherein it examines the record's timestamp. If the timestamp falls within the time window established by the input parameters T₁ and T₂, then the computer will move to state 550; otherwise it moves to state 554. At state 550, the computer 102 compares the contents of the meta record problem field with the input string PS, the meta record anatomic system field with the input string SS and the meta record cause field with the input string CS. If all these fields match the respective input strings, then the computer moves to state 552 wherein the match counter MC is incremented, and then the computer moves to state 554. If there is any mismatch between a meta record field and its respective input string, then the computer moves to state 554 and does not increment MC.

    At decision state 554, the computer 102 determines if there are more meta records to process. If so, the computer 102 moves to state 556 wherein it reads the next record and then moves back to state 548 to perform the time window determination. The meta function iterates through this pattern matching until all of the meta records have been read. When there are no more meta records to be processed, the computer moves through off-page connector A 558 to a decision state 560 on FIG. 11b wherein a determination is made if the value of the match counter MC is greater than or equal to 3. If so, then the computer moves to state 564 wherein it begins the time density analysis.

    At state 564, the computer 102 locates the three most recent meta records whose fields matched the input strings. The computer designates the most recent meta record ‘n’, the next most recent is record ‘n−1’, and the second most recent is record ‘n−2’. The computer then moves to state 566 wherein it calculates X, the time difference between the timestamps of records n−2 and n−1, and Y, the time difference between records n−1 and n. The computer 102 then moves to state 568 wherein it calculates the time density ratio (TDR) as the time X divided by time Y.

    If the computer 102 determined at state 560 that there were less than three matches, then it would move to state 562 wherein it sets the value of the time density ratio (TDR) to 0.0, which indicates that the time density analysis could not be performed. At the completion of establishing the value of TDR at either state 562 or 568, the computer 102 moves to terminal state 570 wherein the meta process terminates, returns the match counter MC and the time density ratio TDR, and returns control to the evaluation process 254 (FIG. 10).

    The interaction of the meta analyses for cause and for anatomic system can be conceptualized by means of a simple geometric metaphor. Consider a two dimensional array in which the causes of disease (trauma, infection, allergy/immune, and so forth) are placed on the “Y” axis, or ordinate, and the anatomic systems of the body (cardiac, respiratory, nervous system, and so forth) are placed on the “X” axis or abscissa. Disease then can be represented by, or is produced at, the intersection of the lines drawn from the applicable cause and the anatomic system.

    As a very simple illustration, consider the two-dimensional array shown in Table 3 (FIG. 24). The array of Table 3 shows an infection in the central nervous system represented at the intersection of the cause of disease (infection) and the anatomic system involved (the nervous system).

    Of course, each cause of disease can be further divided into subcauses. For example, infection would be broken down (or subdivided) into bacterial and viral, and bacterial would be further broken down into gram positive and gram negative, and gram positive would be further yet broken down into streptococcus and so on. The anatomic systems could be broken down in a similar way.

    As a patient uses the system 100, and as the meta analyses for cause and for anatomic system attribute causes to disease processes and record the anatomic systems involved, a three-dimensional cube (a “meta cube”) is produced composed of these stacked two-dimensional arrays. The “Z” axis coordinate of each layer is the time of the patient's consultation obtained from the system clock (i.e., the moment that the actual intersection of the cause and anatomic system occurs indicating the diagnosis).

    The “meta cube” then represents a summation of the patient's interaction with the system 100 through time. Although much of the patient's past history is stored using ICD-9-CM codes as well as conventional text strings in fields of the patient's medical record, the “meta cube” technique allows very useful analyses to be done.

    Using the same modeling metaphor, the “Z” axis coordinate can be used to represent the practice of medicine. Here the “Z” coordinate is again time, but in this representation, time refers to a spectrum of ages from pediatrics to geriatrics. Thus, each coronal plane represents specialties by time, e.g., pediatrics, adolescent medicine, adult, geriatric. A vertical plane describes a specialty by anatomic site, such as neurology or cardiology, while a horizontal plane describes a specialty which practice is bounded (subsumed) by (on) cause, such as oncology or infectious disease. To further this metaphor, the rapidity with which intervention is necessary could be a fourth dimension of the model, and the frequency of an occurrence of a disease is the fifth dimension. Ethical and moral responsibility could be a sixth dimension of the model.

    Node Map Traverse Analysis

    The MDATA system 100 uses a “neural net emulator” program to determine if patterns produced by patients, as they traverse down the nodes (creating “node tracks” of the algorithms in the course of a consultation, may be early predictors of disease. Somewhat like the “meta cube,” the “node tracks” can be superimposed, rather than stacked, upon one another to create a two-dimensional array. This time, however, the pattern produced represents the sum of the patient's previous consultations. In the MDATA system 100, this is called a “node track traverse analysis.”

    For example, the MDATA system 100 may discover that the pattern that is produced when a patient consults the system, at different times, for episodes of diarrhea, cough, and oral candidiasis may be predictive of AIDS. Or, that the pattern produced when a patient consults the system for increased frequency of urination and weight loss may be predictive of diabetes mellitus.

    XII. Mental Status Examination

    Referring to FIGS. 16a and 16b, the mental status examination function 508 defined in FIG. 10b will be described. The mental status examination is a series of questions used to assess the patient's orientation that allows the system 100 to determine the patient's ability to respond to questions and to follow advice. The examination is automatically incorporated into the dialogue of any problem whose presentation could include an altered level of consciousness. If an operator or nurse monitoring a telephone consultation at any time feels there may be a problem with the caller's ability to understand or respond to questions, the mental status examination may also be manually invoked.

    If the MDATA system 100 determines that the patient is not sufficiently oriented based on the results of the mental status examination, the system 100 will ask to speak to someone other than the patient. If no one else is available, the MDATA system 100 can contact the emergency medical services system in the patient's area if the system knows the patient's present geographic position.

    Beginning at a start state 680 of FIG. 16a, the computer 102 initializes the value of a variable Score to be zero. Moving to state 682, the computer asks the patient Question #1. In the presently preferred embodiment, the question is “what day of the week is it?” If the person answers the question correctly, as determined by a decision state 684, the computer 102 increments the value of Score by one. After Score is incremented or if the patient did not answer the first question correctly, the computer 102 moves to state 688 wherein the computer 102 asks the patient Question #2. In the presently preferred embodiment, the question is “what month of the year is it?” If the person answers the question correctly, as determined by a decision state 690, the computer 102 increments the value of Score by one. After Score is incremented or if the patient did not answer the second question correctly, the computer 102 moves to state 694 wherein the computer 102 asks the patient Question #3. In the presently preferred embodiment, the question is “who is the President of the United States?” If the person answers the question correctly, as determined by a decision state 696, the computer increments the value of Score by one. After Score is incremented at state 698 or if the patient did not answer the third question correctly, the computer 102 moves through off-page connector A 699 to a decision state 700 on FIG. 16b.

    At decision state 700, the computer 102 compares the score to the mental status exam threshold at a decision state 700. If the score meets or exceeds the threshold, then the mental status exam returns to the evaluation process at state 701 and the diagnostic evaluation continues. If the score does not reach or exceed the threshold value, the computer 102 moves to state 702 wherein the operating mode flag is set to Pending. The MDATA system 100 will then ask, at a decision state 703, if someone else is available to continue the consultation. If no one else is available, any new information gathered up to this point in the session is saved to Pending file 269 at state 704 and then, at state 705, the telephone call with the patient is transferred to a medical staff person. If someone else is available, as determined at state 703, and is able and willing to continue the evaluation process of the patient, as determined at state 706, the computer 102 asks the person if he or she is a registered assistant at state 707. If the person responds “yes”, the computer 102 invokes the assistant login process 272 at start state 940 on FIG. 12a. If the person is not a registered assistant, the computer 102 invokes the assistant registration process 274 at start state 1050 on FIG. 14a. After assistant registration or login, the computer 102 moves to terminal state 708 wherein the mental status examination process terminates and the evaluation process 254 resumes. At the end of the evaluation process 254, any new information gathered during the session will be written to the patient's past medical history file at state 348 or to pending file 269 at state 347 on FIG. 7d, depending on whether the session continued in real or pending mode. In the presently preferred embodiment, the value of Score could be zero, one, two, or three. Of course, in other embodiments, different questions to be asked of the patient may be utilized in the mental status exam function 508.

    XIII. Semantic Discrepancy Evaluator Routine

    Referring to FIG. 17, the semantic discrepancy evaluator routine (SDER) 510 defined in FIG. 10b will be described. The SDER 510 uses one or more questions that ask for the same information at different times, and in other embodiments, in different ways. The answers given by the patient are then compared within the system 100 to help determine the mental status of the patient.

    Beginning at a start state 712, the computer 102 moves to state 716 and recites a message to the patient. In the presently preferred embodiment, the message is “remember this three digit number . . . NUMBER”, where the computer generates a random three digit number (i.e., in the range 100 to 999 inclusive) as NUMBER which is kept in a session memory variable.

    Then, after a predetermined time interval at state 718, the computer 102 moves to state 720 and recites a request of the patient. In the presently preferred embodiment, the request is “please tell me the three digit number.” The computer 102 then compares the number given by the patient in response to state 720 against the NUMBER kept in the memory variable at a decision state 722. If the numbers match, the computer 102 returns at state 724 with a status of pass to the evaluation process (FIG. 10b). If the numbers do not match, the computer 102 returns at state 726 with a status of fail to the evaluation process. In the presently preferred embodiment, if the return status of the SDER 510 is “fail”, the evaluation process 254 automatically invokes the mental status examination function 508.

    XIV. Past Medical History Routine

    Referring to FIG. 18, the Past Medical History Routine (PMHR) 512 defined in FIG. 10b will be described. The contents of a patient's past medical history file, which is part of the PMH database 268, are loaded to the symbol table when the patient logs in to the system 100. During the evaluation process 254, a TEST is performed by the computer 102 before a particular medical algorithm is initiated to verify that necessary items are present in the symbol table. The effect of a negative TEST result is that the system 100 prompts the patient to provide the missing past medical history information via the PMHR 512.

    The PMHR 512 uses an input parameter “condition label” (L) as indicated at State 740. The “Condition label” is unique, e.g., PMHRLTB1 corresponds to the first PMH object tested in the croup (RLTB) algorithm: diagnosis for croup in children. The label is passed so that PMHR 512 knows what questions to ask. The ability of the system 100 to ask a past medical history question in the middle of the evaluation process 254 is a feature that saves the patient from having to answer the entire PMH questionnaire during the registration process. The Boolean result, or scalar value, is stored in the symbol table under this label (PMHRLTB1), and the algorithm can use it in decision making, e.g., If PMHRLTB1=True Then 4310 Else 4320.

    Beginning at a start state 742, the computer 102 moves to state 744 and prompts the patient for the missing medical condition data. Moving to state 746, the computer 102 repeats the information provided at state 744 and asks the patient if the repeated information is correct. Moving to a decision state 748, the patient responds by indicating whether the repeated information is correct. If the data is not correct, the computer 102 proceeds to state 750 to determine if the patient would like to attempt the data entry step again. If so, the computer 102 loops back to state 744 and prompts the patient for the data again. If not, the computer 102 returns at state 754 to the evaluation process (FIG. 10b).

    If the newly-entered data is correct, as determined at state 748, the computer 102 advances to state 752 and installs the condition label (L) and the data value in the symbol table for the patient. The computer 102 then returns at state 754 to the evaluation process 254.

    XV. Physical Self Examination

    Referring to FIG. 19, the Physical Self Examination function 514 defined in FIG. 10b will be described. A physical examination can actually be done by the patient under the direction of the MDATA system 100. The MDATA system 100 is designed to function primarily based upon responses to carefully crafted questions, i.e., history, and physical findings elicited from the patient. There are times, however, when the addition of certain laboratory tests can increase the accuracy of the diagnosis as well as help determine the appropriate treatment recommendations. For this reason, a MDATA system Home Diagnostic and Treatment Kit is available for use by patients. If the patient has the Home Diagnostic and Treatment Kit, including visual field cards, Snelling chart, and possibly the MDATA system's “tele-stethoscope” to assess intracranial or carotid bruits, this information will be used in the diagnostic process as well.

    The MDATA system 100 is also able to play tones of different frequencies and intensities to emulate audiometric testing for hearing acuity. This allows, for example, the MDATA system 100 to detect the unilateral decrease in hearing caused by an acoustic neuroma.

    Beginning at a start state 770, the computer 102 branches to one or more physical self examination procedures depending on the current problem and what equipment if any is available for use by the patient. These procedures include: home diagnostic tests 772, vital signs 774, observable physical signs 776, clinical sound recording 778, and tele-stethoscope 780.

    A variety of home diagnostic tests 772 are available for use by the patient. New advances in biotechnology, including a new generation of urine dipsticks such as a “Multistix 8 SG” produced by Ames and monoclonal antibody tests such as “ICON® STREP B” produced by Hybritech®, allow an entire spectrum of laboratory tests to be performed at home by the patient under the direction of the MDATA system. For example, urine dipsticks can be used to check for blood, nitrites, leukocytes, or leukocyte esterase indicating cystitis or a bladder infection.

    In order to use much of the monoclonal antibody technology, however, a small amount of blood must be obtained by using a fingertip lancet. This is already successfully being done by diabetics at home who use a glucometer to measure their blood sugar after pricking their finger to get a small sample of blood.

    The MDATA system Home Diagnostic and Treatment Kit also contains equipment to allow the patient, or someone else, to measure the patient's vital signs 774. A blood pressure cuff and thermometer are included with instructions for their use as well as instructions to measure pulse and respiratory rate.

    The patient may be directed by the system 100 to observe various physical signs 776. For example, a headache patient will be asked to palpate their temporal artery area, and to look at themselves in the mirror to identify the ptosis and tearing of a cluster headache or to identify the steamy cornea that may occur with acute narrow angle glaucoma.

    As an example of how the MDATA system Home diagnostic and Treatment Kit could be helpful, consider a woman who (using the MDATA system's urine pregnancy test based on ICON® II HCG ImmunoConcentration™ Assay, produced by Hybritech®) finds out that she is pregnant. This is her first pregnancy. Later, when consulting the system for headache, a urine dipstick indicates protein in her urine and the measurement of her vital signs shows a significant rise in her blood pressure. This is a classic presentation of preeclampsia.

    Instead of going to a doctor's office, patients could also use the MDATA system's Home Diagnostic and Treatment Kit to collect samples at home and then send them to a designated lab for analysis as needed. This saves time for the patient and is especially useful if the patient has difficulty in traveling. Costs should also be minimized in this type of laboratory analysis.

    The MDATA system 100 records clinically relevant sounds 778 of a patient such as the cough of bronchitis, the seal bark cough of croup or the inspiratory stridor of epiglottitis. These sounds are digitized and stored in the patient's medical record. Then.
    where X denotes the recommendation to go to the hospital and Y denotes a different branch point. Following is the same example, but including sensitivity factors:
    If temp>(102*S1*S2*S3*S4*S5*S6*S7*S8*S9*S10) then X else Y

    The use of the sensitivity factors permits anticipation of change. Tuning the initial product of the sensitivity factors from “1.00” to “0.95” would decrease the temperature at which the system recommends a trip to the hospital. Each threshold calculation or other use of the sensitivity factors may use any number of (e.g., two factors) and any combination of the factors. Additionally, any combination of factors may be modified from the initial 1.0 value in any particular threshold calculation.

    Age criteria are also modified by use of the sensitivity factors. For example: If Age>45*S1*S4 then X else Y.

    Examples of areas the system 100 could be tuned follow:

    • • Anatomic system (e.g., cardiovascular)—the system is missing too many heart attacks;
      • Cause (infection)—the system is missing too many injuries (trauma);
      • Problem specific (e.g., headache)—the headache algorithm is missing too many cases of meningitis or subarachnoid bleeds;
      • Question specific (each question in an algorithm can be modified)—this would change the “weight” of a question in a series of weighted questions like the migraine screening questions;
      • Patient specific—one patient might want to be VERY careful while another might say, “in general I don't go to the doctor until I'm really sure something is wrong with me”;
      • Organizational (e.g., Kaiser patients)—Kaiser hospital management may say that the system is missing too many cases of meningitis and may request to be more careful with their patients (send them in with a lower temperature).

    The sensitivity factors affect the following system 100 functions:

    • (a) Re-enter Feature—the sensitivity factors affect the re-enter horizon, i.e., the amount of time after which the system 100 considers a repetition of the same complaint to be a new problem. If sensitivity increases, the re-enter horizon becomes sooner.
    • (b) Meta Function—the sensitivity factors affect the matching and time density ratio thresholds. By reducing the values of the system-wide and problem sensitivity factors, e.g., from 1.0 to 0.9, the matching threshold and the time density ratio are decreased:
      • Example 1 Without Sensitivity Factors
        Meta(“NHDA”, “****”, “*********”, 06/01/93, 12/31/93)
        If MC>=3 then 100 else 101
      • Example 1 With Sensitivity Factors
        Meta(“NHDA”, “****”, “**********”, 06/01/93, 12/31/93)
        If MC>=(3*S1*S4) then 100 else 101
      • Example 2 Without Sensitivity Factors
        Meta(“****”, “****”, “I********
        If TDR>=2.0 then 200 else 201
      • Example 2 With Sensitivity Factors
        Meta(“****”, “****”, “I*********”, 06/01/93, 12/31/93)
        If TDR>=(2.0*S1*S4) then 200 else 201
      • Thus, there is no necessity to change the algorithms themselves. In other words, the factors can be modified rather than changing the algorithms.
    • (c) Problem Questions—To take the headache example previously used, the sum of the scores of the screening and confirmation questions (and sometimes the questions themselves) is multiplied by the sensitivity factors. The questions are also weighted, of course, depending upon how important each question is to the diagnosis. The sum of the weighted scores is compared against the threshold value that will result in either making the diagnosis of say migraine (in response to the migraine screening questions) or confirming the diagnosis of migraine in response to the migraine confirmation questions.

    Thus, if we wanted to increase the sensitivity of diagnosing subarachnoid hemorrhage, we would not have to write another algorithm, but rather, simply multiply the screening and confirmation scores by the sensitivity factors.

    For example, if the threshold for the MDATA system 100 to make a diagnosis of subarachnoid hemorrhage based on the sum of the weighted subarachnoid screening questions threshold is set at, say 75%, then that percentage of the sensitivity variable would make this diagnosis with a smaller score and, thus, pick up more cases. Thus, individual diagnoses within an algorithm can be “tuned” independently, and in some cases, this even applies to the individual questions themselves.

    • (d) Symptom Severity and Symptom Severity Trend Analysis—the sensitivity factors alter the absolute value, the first, second and third slope thresholds. With increased sensitivity, a more gently sloping line triggers an earlier medical evaluation. In the algorithm, when the system 100 makes use of any quantitatable parameter to make a decision, all of these are joined, influenced or multiplied by the sensitivity factors. As a very simple example, if the MDATA system 100 would normally make a recommendation, partly based on the age of the patient (e.g., if you are male and you are over 50 and . . . ), the decision can be triggered if the patient is 49 or 48 and so on.
    • (e) Home Diagnostic and Treatment Kit—if the patient has a MDATA system treatment kit or a blood pressure cuff, the level at which a fever or blood pressure effects a decision can be changed.
    • (f) Mental Status Examination—the mental status examination can be modified at a system, or problem (algorithm) level.
    • (g) Clinical Sound Library—the pattern matching process (as in the clinical sound library) is quantifiable by modifying the sensitivity factors.

    XIX. Video Imaging Of the Patient

    There are four main types of video imaging: static black and white, static color, video black and white and video color. Each of these main types is now discussed.

    Images as basic as static black and white images can provide useful information to the system 100. Static black and white imaging is used with neural net pattern matching. This process permits analyzing for example, facial features to aid in the detection of certain diseases, such as the characteristic facies of Cushing's syndrome or the exophthalmos of Graves disease.

    Color static imaging allows color frequency analysis to detect diseases that are not as readily detected with static black and white imaging, such as cyanosis of respiratory failure or the scleral icterus of hepatitis. Color thus provides an incremental benefit in the level of disease detection.

    Real time black and white video imaging allows for the evaluation of physical signs such as pupillary responses, extra ocular muscle function, lid lag, and nystagmus. Cranial nerve function can be remotely evaluated, along with, for example, the distinction between central and peripheral VII nerve function.

    Color video imaging, especially using fiber optics, adds much more capability in the evaluation of a patient's condition. For example, color video imaging is very useful in evaluating capillary refill or monitoring the response of a patient with cyanosis to supplemental oxygen. Another embodiment of the system 100 may employ inexpensive laser sources to perform real time holographic imaging.

    XX. Benefits of the MDATA System

    It is rare when the humanitarian and entrepreneurial interests of a venture overlap. The confluence of purpose that exists in the MDATA system is striking. It is a “win-win” proposition from every perspective.

    Not only will the MDATA system 100 substantially reduce the overwhelming costs of our current health care system, but for the first time in history, every person can have access to high quality, 100%-consistent and affordable medical advice and information. No matter from what perspective one views the MDATA system 100, its benefits are substantial.

    The health care consumer obviously gains the most. Now, whenever he or she has a medical problem, or any member of their family, an immediate consultation can be obtained. The knowledge that the best health care information and medical advice is only a telephone call away can assuage the anxiety of everyone from new mothers to elderly patients confined to their homes.

    By endorsing the MDATA system 100, federal, state and local governments could discharge their obligation to provide a universal and affordable level of health care for all of their citizens. In addition, the MDATA system 100 helps care for patients who cannot pay, thus relieving primary care physicians of the necessity to provide care without reimbursement. For the first time, Health Maintenance Organizations and Managed Care Plans will be able to effectively screen patients by telephone in order to ensure that patients are best matched with the services they need.

    Specialists can use their talents, not on the repetition of familiar rituals, but will be free to concentrate on those more challenging problems that cannot easily be resolved by the MDATA system 100. They will also benefit from an increased number of patient referrals as well as having a well-constructed patient history when a consultation is sought.

    Physicians themselves can access the MDATA system 100 in order to stay informed about new information and technological advances in the medical field. This is particularly true with the treatment, imaging, and laboratory test databases.

    Medical information is a continually renewable resource because it is not consumed in its dissemination. The opportunity exists, through the MDATA system 100, for the United States to provide much needed medical information to the world and, at the same time, bring capital into this country. In the process, this country could maintain its leadership in innovation, technology, and software development.

    The United States and the world are facing a health care crisis so monumental that it is difficult to comprehend. There are diseases that threaten our very survival as a species. All of us know the apprehension and bewilderment we feel when an illness strikes. When this occurs, we need answers to specific medical questions, answers that are absolutely up-to-date, instantly available, and affordable.

    The key is information: information about prevention, early detection of disease, and about its most efficient treatment. The MDATA system 100 can provide this information through the simple use of the telephone, to nearly every inhabitant of the planet. In addition, the MDATA system 100 converts and explains complicated medical terminology and concepts into language easily understood by everyone.

    People do not have to be ill to consult the MDATA system 100, just curious. Patients do not have to schedule appointments, they can simply pick up the telephone. Although many patients will later be seen by a physician, the MDATA system 100 can provide immediate help for everyone. The MDATA system 100 at once establishes egalitarian access to health care information. Although many patients in this country receive state-of-the art medical care, there is a large segment of the population that is deprived of one the most basic health care and medical information. The MDATA system 100 begins to close this enormous gap.

    The MDATA system 100 begins to effect a restructuring of the health care delivery system in which both health care consumers and providers participate in the improvement of the system itself. The MDATA system 100 and its patients will be in partnership to provide the most current, economical, and concise treatment available. The upside potential is unlimited. Whether one believes health care is a right or a privilege, there can be no doubt that it is fundamentally necessary. Whether one believes we have a civic responsibility or a moral obligation to care for one another, it must be done. The fundamental simplicity of the structure of the MDATA system 100 belies its power as a highly useful tool in the delivery of health care.

    XXI. Optional System Configuration

    A second embodiment of the MDATA system entails a major shift of how the questions and responses are delivered to the patient. Rather than the use of a telephone, the voice processing and voice response technology, the system software is published via media such as floppy disks, CD ROM, or PCMCIA cards for use on a patient's personal computer. This second embodiment is referred to as the screen version or the (Stand-Alone) SA-MDATA system. The computer could be, for example, a desktop computer, a laptop or notebook computer, or a handheld, pen-driven computer. The system questions are displayed on a display screen that is part of the computer or is connected to the computer. The patient uses a keyboard or a pointing/writing device connected to the computer to respond to the questions. The patient files are maintained and updated within the computer or on removable storage devices. The diagnosis, advice, and treatments can be displayed on the screen and also printed in hardcopy form on a printer (if available). New versions of the SA-MDATA system are either mailed to subscribers are available via modem. These new versions may include updates of the treatment table for new treatments. Another embodiment of the SA-MDATA system may include using specialized receiver devices that receive encoded FM signals on a demand basis when an event (a new treatment) triggers the device, such as described in U.S. Pat. No. 5,030,948.

    A unique and separate authoring language (called File Output or FO) was used to develop the medical algorithms used in the screen version embodiment of the system 100. Through the use of FO, the contents of text files are presented online to users, and then the users respond to questions and directions issued by the text files.

    FO is designed as a typical, generalized authoring language, in which commands are embedded into text files (herein called FO files) to perform specific screen and keyboard functions. FO files are in effect programs written in the FO “language” that communicate (via FO) with the user online.

    FO adds no text of its own. In fact, FO does not need to know what text file content it is executing. The programmer or author of a FO file is in complete control of the text content and the sequence in which it is presented. Using the various commands described in the Authoring Language Syntax, the author can display text, format the screen, ask the user questions, input responses from the user, select different text files for execution, and generally control and direct the entire session.

    This version of FO is intended as a development version that gives the user much freedom at the keyboard. The user can interrupt a presentation and edit the FO file being presented. The assumption here is that the user is in fact the author or an alpha tester charged with verifying and correcting file content.

    A FO file is any standard sequential ASCII text file with variable-length lines terminating with a Carriage Return (ASCII 13). Any line with a period in column one is treated as a command. A line without a leading period is treated as a print command.

    The FO program processes a FO file by reading it one line at a time into memory. If the line is a text line, it is printed and the next line is loaded. If the line is a command line, the command is executed. If the command involves a wait on the user (such as a .M command), FO continues loading the FO file behind the scenes until it has been completely loaded. In this manner, FO executes the FO file as it is loading it. Once loaded, the FO file remains entirely in memory.

    The system software for the screen version embodiment is written in Borland Turbo Pascal version 3.0. A second version of the system software for the screen version embodiment of the system 100 is written in Microsoft G.W. Basic and is run in interpretive mode.

    In yet other embodiments, other databases/files or algorithms can be used. The general system, method and procedures would remain the same. For example, a specialty field such as sports medicine could be added to the system.

    The MDATA system 100 described herein finds application in many environments, and is readily adaptable for use therein. For example, the system finds use in any application that is step-oriented and can be algorithmically described. For example, the system could give car diagnostic services over the phone to a caller. Then, when the car is brought to a service facility for repairs (treatment), the caller will be informed and have a good idea of what the problem is and probable repairs will be. Accordingly, the claims are to be interpreted to encompass these and other applications of the invention within their scope and are not to be limited to the embodiments described herein.

    XXII. Summary of Advantages of the Present Invention

    One of the main problems of the health care crisis is the limited access to health care information when it is needed. The MDATA system provides up-to-date medical information and advice that is instantly available twenty-four hours a day. The advice that is given is 100% consistent.

    The quality of the advice is much better if a physician can stop, research, and anticipate all possible causes of a problem and then systematically go about dealing with all of these possible causes. In medical practice, a physician just does this from memory.

    No humans are necessary to actually give the medical advice. The MDATA system is automated which helps to bring down the cost of health care.

    An exact record of the questions asked and the answers given is stored in the patient's database. The MDATA system time-and-date stamps the responses to the questions (as transaction records) so that an exact reconstruction of the patient's interview(s) can be generated for use by a physician or other health care professional. The system also keeps a record of what version of an algorithm has been consulted as well as the sensitivity factor set for that consultation. At the conclusion of the interaction, the MDATA system can tell the patient how long the consultation has taken and what charges have been incurred, if any.

    When possible, the MDATA system 100 takes into account the past medical history of the patient, especially those pieces of information learned from past consultations with the MDATA system 100, before advice is given. In addition, the advice given is different depending upon the age and sex of the patient. The “meta” functions provide another advantage by allowing the MDATA system 100 to evaluate a problem in the context of the patient's prior consultations with the system.

    While the above detailed description has shown, described and pointed out the fundamental novel features of the invention as applied to various embodiments, it will be understood that various omissions and substitutions and changes in the form and details of the device illustrated may be made by those skilled in the art, without departing from the spirit of the invention.

Claims

1. A computerized method of providing information related to any one of a plurality of patients for use in an automated medical advice system, the method comprising:

selectively executing at least a portion of medical diagnostic code, wherein the portion of medical diagnostic code:

accesses a patient medical history during an evaluation process, wherein the patient medical history comprises a plurality of records, each patient being associated with at least one unique record, wherein the patient medical history is persistently stored;

determines medical advice particular to a medical condition associated with the portion of the medical diagnostic code through communication with a selected one of the patients and with information stored in the patient medical history; and

provides the medical advice to a selected recipient.

2. The method defined in claim 1, wherein the selected recipient is the selected one of the patients.

3. The method defined in claim 1, wherein the selected recipient is a health care professional associated with the selected one of the patients.

4. The method defined in claim 1, additionally comprising generating a diagnosis during the selective execution of the portion of the medical diagnostic code.

5. The method defined in claim 4, wherein the diagnosis comprises a single disease.

6. The method defined in claim 4, wherein the diagnosis comprises a differential diagnosis list.

7. The method defined in claim 1, additionally comprising storing the medical advice in a patient consultation summary during the selective execution of the portion of the medical diagnostic code.

8. The method of claim 7, wherein a health care professional accesses and uses the patient consultation summary through the automated medical advice system to make a diagnosis.

9. The method defined in claim 8, additionally comprising storing the diagnosis in the patient medical history.

10. The method defined in claim 8, additionally comprising providing the diagnosis to the selected one of the patients through the automated medical advice system.

11. The method defined in claim 4, additionally comprising:

storing a treatment table in a medical advice system;

accessing the treatment table based on the diagnosis so as to select a treatment; and

communicating the selected treatment to the selected one of the patients.

12. The method defined in claim 1, additionally comprising protecting a medical history of the selected one of the patients against unauthorized access.

13. A method of providing information to a patient for use in a medical diagnostic advice system comprising a computerized device including an input and an output device, the method comprising:

transmitting information to the patient by the output device;

receiving information from the patient by the input device;

processing the received information;

selectively executing at least a portion of medical diagnostic code based on at least a portion of the received information;

scoring at least a portion of the processed received information; and

diagnosing a medical condition associated with the executed portion of the medical diagnostic code based upon a comparison of the score and a threshold.

14. The method defined in claim 13, additionally comprising communicating medical advice to the patient via the output device if the score does not reach or exceed a threshold.

15. The method defined in claim 14, wherein the medical advice comprises instructions to consult with the medical advice system at a later time.

16. The method defined in claim 13, additionally comprising communicating the diagnosed medical condition and the score to the patient via the output device.

17. The method defined in claim 16, additionally comprising communicating information about a treatment associated with the diagnosed medical condition to the patient via the output device.

18. The method defined in claim 13, additionally comprising communicating the diagnosed medical condition and the score to a physician via the output device.

19. The method defined in claim 18, wherein the diagnosed medical condition comprises a differential diagnosis list.

20. The method defined in claim 13, additionally comprising associating the portion of the medical diagnostic code with one or more medical conditions.

21. The method defined in claim 13, wherein the portion of the medical diagnostic code is selectively executed on a processor in the computerized device.

22. A method of providing patient information for use in a medical diagnostic advice system comprising a computerized device, including an input and an output device, the method comprising:

transmitting information to a patient via the output device;

receiving information from the patient via the input device;

processing the received information;

selectively executing at least one portion of a plurality of medical diagnostic code portions based on at least a portion of the received information;

scoring at least a portion of the processed received information; and

diagnosing a medical condition associated with the executed portion of the medical diagnostic code portions based upon a comparison of the score and a threshold.

23. The method defined in claim 22, additionally comprising communicating the diagnosed medical condition and the score to a physician via the output device.

24. The method defined in claim 23, wherein the diagnosed medical condition comprises a differential diagnosis list.

25. The method defined in claim 24, additionally comprising receiving a selected diagnosis from the differential diagnosis list.

26. The method defined in claim 25, additionally comprising providing the selected diagnosis to the patient.

27. A computerized method of providing medical information related to any one of a plurality of patients for use in an automated medical advice system, the method comprising:

accessing a patient medical history during an automated evaluation process, wherein the patient medical history comprises a plurality of electronic medical records, each patient being associated with at least one unique record, wherein the patient medical history is persistently stored;

determining medical advice particular to a medical condition associated with the automated evaluation process through communication corresponding to a selected one of the patients and with information stored in the patient medical history; and

providing the medical advice to a selected recipient.

28. The method defined in claim 27, wherein the selected recipient is the selected one of the patients.

29. The method defined in claim 27, wherein the selected recipient is a health care professional associated with the selected one of the patients.

30. The method defined in claim 27, wherein the patient selected recipient is a proxy for the patient the selected one of the patients.

31. The method defined in claim 27, additionally comprising storing the medical advice in a patient consultation summary during the evaluation process.

32. The method of claim 31, wherein a health care professional accesses and uses the patient consultation summary, through the automated medical advice system, to make a diagnosis.

33. The method defined in claim 32, additionally comprising storing the diagnosis in the patient medical history.

34. The method defined in claim 32, additionally comprising providing the diagnosis to the selected one of the patients through the automated medical advice system.

35. The method defined in claim 27, wherein the communication comprises information obtained during a consultation.