Computerized medical diagnostic system including re-enter function and sensitivity factors5594638Abstract 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. Claims What is claimed is: Description MICROFICHE APPENDIX
______________________________________
Voice DTMF
______________________________________
yes 1 Useful for answering yes/no questions.
no 2
backup # Causes the system to back up to the
"predecessor" message (see below), then
resume playback.
help * Plays helpful information: either the
node's help message list, or the DTMF
command explanation message.
operator
0 Causes the system to transfer the caller
to a live person.
pause 7 Transitions to pause mode. The system
default pause period is 30 seconds.
quit 9 Quits the current algorithm, and takes
the caller to node 110, which asks the
caller if (s)he wishes to select another
algorithm.
repeat 3 Repeats the current node's play message
list. If this command is given in the
middle of a long play list, then
playback restarts with the first message
in the list.
Pause Mode Commands
yes 1 Extends the pause period by one default
pause interval (30 seconds).
continue
2 Ends pause mode. If this occurs at a
Yes/No node, the system will repeat the
question. If this occurs at a Link
node, the system will resume playback
with the "current" message. The system
resolves the DTMF digit "2" ambiguity,
"no" versus "continue", by examining the
pause mode flag.
______________________________________
FIG. 2 illustrates how speech files are created. A person programming medical algorithms uses speech messages to communicate with the person seeking medical advice. As previously mentioned, these speech messages are of variable length. The programmer typically writes a script for the speech message. Then using the handset of the telephone 110, a speakerphone feature, or other voice-input device, e.g., a microphone, the programmer reads the script into the voice-input device which is connected to the VP board 122. The VP board converts the speech into a digital format and records the digitized speech to a file that is stored on the hard drive 152. In the presently preferred embodiment, a subdirectory named vox contains the system speech files, and subdirectories for each medical algorithm. System speech files are of the form sysxxx, where xxx is some arbitrarily assigned number. The system messages are used by the "fixed" parts of the system, e.g., greeting, login process, registration process. There are a few speech files of the form msgxxx. These are the past medical history questionnaire messages, and response acknowledgements. There are additional speech files of the form msgxxxx in each of algorithm subdirectories, where xxxx generally matches the node number, which will be explained hereinbelow. Node messages include information, question, menu and help messages. III. Operating Features of the MDATA System One of the MDATA system's main objectives is to bring together highly-qualified medical experts, encode their knowledge in a central location, and make it available to everyone. A new and unique authoring language is used by the MDATA system to help accomplish this objective. Each day, specialists perform the same tasks over and over. They enact the same diagnostic ritual of solving a familiar problem. At the same time, however, primary care physicians attempt to find the best path through the diagnostic maze of an unfamiliar problem. This process is inefficient and fraught with error. In medicine, there is generally one best way to do things. Instead of physicians spending valuable time duplicating tasks, the MDATA system utilizes medical experts from each medical specialty who write detailed algorithms for the treatment of the 100 or so most commonly encountered complaints in family practice and emergency medicine. These algorithms are carefully and specifically designed to elicit historical data and physical findings over the telephone, rather than in face-to-face interactions. Several experts could work together to thoroughly research one particular complaint as well as to anticipate the full spectrum of possible problems and patient responses. These experts could also provide and maintain the MDATA system treatment table as well as the imaging modality of choice and laboratory test of choice tables. These concepts will be described hereinbelow. Carefully crafted questions, used in the taking of a medical history, are the main tools that the MDATA system uses to assess the problems of patients. The key to getting a good history is to ask the right questions. In a sense, in the diagnostic process questions are like tests. It is important to note that the right questions are basically always right; they don't change. Although they may be refined over time, in general, once excellent and well-crafted questions are developed they are good for a very long time. Of course, as new diseases are discovered, e.g., toxic shock syndrome and AIDS, new sets of diagnostic questions are developed that are disease specific. The questions used by an earlier generation of physicians, who did not have any of the latest imaging modalities (types or methods), are far more sensitive and precise in diagnosing a patient's problem than the questions used by doctors today. The MDATA system makes use of fine nuances of language to diagnose patients as well as to determine when certain tests or imaging studies are necessary. The MDATA system's statistic generating capabilities enable the system to analyze the effectiveness of the questions used in the diagnostic process. As a result, physicians benefit from the immense amount of statistical information that is gathered regarding the wording of questions asked in taking medical histories. For example, exactly what percentage of patients who answer "yes" to the question, "Is this the worst headache of your life?" actually have a subarachnoid hemorrhage? Although this is a classic description of this problem, the exact probability of having this kind of brain hemorrhage after answering "yes" to this question is not presently known. Currently, doctors can only estimate the probability of certain conditions based on history. By applying the statistical information that is generated, the MDATA system not only provides the patient with advice that is continually improving, but it will also be able to pass along these probabilities to the entire medical community. To function optimally, the MDATA system tries to gain as much medical information about its patients as possible. Although a first-time caller is given excellent advice, more specific advice can be given if the system has more information. Therefore, the MDATA system asks patients for their complete medical history. The MDATA system can either obtain the patient's medical record over the telephone or it can mail or fax a detailed questionnaire to each patient. The patient can then gather the necessary information at their convenience. The MDATA system will always be available to telephone to clarify any questions the patient may have. The MDATA system uses the "International Classification of Diseases" (ICD.box-solid.9.box-solid.CM) codes to help summarize the information it has about a patient. This world standard is a comprehensive numerical system used to classify the entire spectrum of medical diseases. ICD.box-solid.9.box-solid.CM codes are also used to classify specific procedures performed (e.g., appendectomy) as well as the morphology of neoplasm (i.e., tissue diagnosis of a cancer). In addition, the MDATA system 100 uses ICD.box-solid.9.box-solid.CM "E-Codes" to classify environmental events, circumstances, and conditions as the cause of injury, poisoning, and other adverse effects. These codes are particularly helpful for storing information about what drugs the patient has taken or is currently taking, as well as the context (e.g., therapeutic use, accident, poisoning, suicide attempt) in which they were or are being taken. For example, E942.1 is the code for the therapeutic use of digoxin. Medications are also cross-categorized according to the classification done by the American Hospital Formulary Service List (AHFS) Numbers. The MDATA system 100 also uses "V-Codes" to classify other types of circumstances or events such as vaccinations, potential health hazards related to personal and family history, and exposure to toxic chemicals. It is estimated that the alphanumeric component of a patient's medical history will not exceed 1,000 atoms or pieces of information. An atom is considered herein to be a separate identifiable data item or point. With this assumption, the medical records of every person on the planet could currently be stored on approximately 1,000 optical disks. While a patient interacts with the MDATA system, the system is constantly determining what questions to ask, based upon the information it has about the patient. Just as a physician gathers relevant pieces of information from his or her dialogue with a patient, the MDATA system flags and later stores all pertinent pieces of information that it learns from each interaction with its patient. Therefore, certain questions, because their answers remain the same, need not be repeated. For example, if the MDATA system learns that a patient's mother has suffered from migraine headaches, it will never have to ask for this information again. Again, the more information the MDATA system has about a patient, the more specific is its advice. It is not uncommon for the MDATA system to give different advice to different patients calling for the same complaint. In other words, the advice given is patient-specific. Not only can the MDATA system's advice be different for different patients, but there are times when the advice given to the same patient (calling for the same complaint but at different times) is different. For example, one of a group of functions called "meta" keeps track of the number of times the MDATA system has been consulted for the same problem. Once a threshold is reached, the MDATA system advises the patient that the number of consultations alone, for the same complaint, may signify a problem. The system then makes an appropriate recommendation. Before the MDATA system stores any information, the system verifies its accuracy. To accomplish this task, "confirmation loops" are used. Any piece of information that will become a part of the patient's medical record is sent through a confirmation loop where the system asks the patient to verify the accuracy of the information that the system has collected. The confirmation loop enables the system to verify new patient information and make corrections before it enters this information into the patient's medical record. IV. Authoring Language The MDATA system uses a new authoring language that is specifically designed to allow medical knowledge to be encoded into a usable computer program. The presently preferred voice response or telephony version of the MDATA system is written in object-oriented Microsoft C.backslash.C++ version 7.0. This allows the MDATA system to easily interface with industry-standard database programs, including those that are SQL-based, as well as to be portable to other operating systems. The operating system is transparent to the user. Before the development of the MDATA system's authoring language, there was no practical way for medical experts to encode their knowledge into a meaningful, useful, and accessible structure. Although other computer languages have been used to build medical expert systems, they have almost always required a knowledge engineer and a programmer to be involved. Quite often, the knowledge encoded in these systems could only be accessed and fully understood by physicians. Typically, the programmer would try to translate the doctor's diagnostic skills and treatment rules into computer code. This separation of the physician's knowledge from the encoded treatment recommendations often engendered anxiety in the physician and has, at times, led to inaccurate treatment recommendations. The MDATA system's authoring language, however, is designed to allow physicians to transfer their knowledge into a computer program that can be directly accessed by non-medically trained personnel. Recursive and iterative techniques are used to acquire the knowledge from the expert and assemble it in a way that allows it to be immediately transposed into the MDATA system's algorithms. Because of the simple interface of the language, and because a formula for writing the algorithms has already been developed, physicians who are not computer literate can encode their knowledge as well as understand exactly how that process takes place. The MDATA system's authoring language allows flat information to be restructured into a hierarchical or layered format in which the arrangement of the knowledge conveys meaning. Thus, a textbook description of a disease can be transposed into a form that allows useful treatment recommendations to be made. The new language also allows the formation of a structure in which multiple overlays of screening questions, combined with the application of recursive techniques, sequentially exclude some diagnoses while at the same time reaching treatment recommendations. The MDATA system's simplicity and elegance would not be possible without the new language. The MDATA system's authoring language allows an algorithm programmer to retrieve information from a patient's medical record, request additional information from the patient, and guide the flow of algorithm execution based on medical history and the patient's responses. The language allows the programmer to implement an algorithm in a natural scripted style. The course of an algorithm is determined by caller responses to questions that the MDATA system asks. For simple "yes/no" questions, the flow of interaction can be described by a binary tree. Multiple-choice questions (e.g., menus) provide multiple branches in the tree. Each question can be considered a node, and the acceptable responses to this question are branches leading to the next question (node). Using this abstraction of an algorithm, one can draw a directed graph (also known as a node map) of the nodes and branches of an algorithm, beginning with the initial question, and ending with all possible terminal points. The node table is built in this manner: 1. An author develops an algorithm. 2. The algorithm is broken up into separate nodes. 3. A directed graph is drawn up, which is a flow chart of the algorithm's operation. 4. Each node's definition is entered into the MDATA system, either by: a. using an ednode utility to write each node's definition into the system's machine readable node table, or b. using an xlat utility to translate an ASCII file of human-readable node definitions into the system's machine readable node table. Several example node maps are included in the attached Microfiche Appendix. Referring to FIG. 3, a process for translating a medical algorithm written in the authoring language will be described. FIG. 3 illustrates an ASCII (American Standard Code for Information Interchange) format text file 170 as an input to a translation utility 172. An ASCII file can be created by use of a text editor or a word processing program (may need to export to the ASCII format). The ASCII file 170 contains node definitions conforming to the syntax briefly described hereinbelow and more thoroughly described in the attached Microfiche Appendix. An example node definition text file 170 for Headache is included in the Microfiche Appendix. The purpose of the ASCII node definition translator utility 172 (xlat.exe, along with functions in pars.c and util.c) is to convert a human-readable document into a machine readable format that the MDATA system reads at run time to process an algorithm. This utility 172 may be considered to be a preprocessor; the translation must be accomplished prior to run time. The translation utility 172 is listed in the Microfiche Appendix. The output of the utility 172 is a set of binary (NOD.sub.-- BLK) records written to a node table 174 (filename of node.fos), and a set of binary list files 176 (in a subdirectory .backslash.list.backslash.listxx.backslash.xxyy, where xx is the first two digits of the node number, and yy are the last two digits). Four list files 176a-176d are shown as an example. Each "list" file, e.g., 176a, contains a "next" table (i.e., the `next node after this one`), a message play list for this node, and a "work" list (i.e., one or more "things to do" at this node before beginning speech playback). The binary record written to the node table 174 (node.fos) has fields containing the node number (which is redundant; the record's position in this file also indicates the node number), the node's "type" attribute (Menu, Link, Prompt, Yes/No, Return, Hangup) and a parent node number. The node table 174 is a table of 10,000 NOD.sub.-- BLK records. This table 174 is indexed by a node number, e.g., the fiftieth record corresponds to node 50. The contents of the individual node records may be viewed by selecting "Display Node" while running the ednode utility. The node records are modified by either using the ednode utility, or when translating node definitions from ASCII to the node file with the xlat utility. One of the following keywords is necessary as the first item on each line, but only one keyword is accepted per line; any excess information will be discarded. Node The Node keyword denotes the beginning of a new node and defines the node number. Parent The Parent keyword defines the parent of the node being defined. Type The Type keyword defines the class of the node being defined. Acceptable type names are: Menu This node presents a multiple choice question. YesNo This node presents a simple Yes/No type question. Link No caller response is required at this node, algorithm processing will continue at a predetermined node. Prompt This node requests some numeric information from the caller. The information is placed in a DTMF buffer which is then stored in the next node. Return Returns from a subroutine call (e.g., after configuring a past medical history object). Hangup The system will release this caller after it finishes speech file playback, or if the caller interrupts playback with a DTMF key press. Wait nn This node will play the message list, then pause for the specified nonzero number of seconds before continuing. The @ keyword defines the action to be taken for a response to either a Menu or YesNo type node. Digits The Digits keyword is used in conjunction with Type Prompt to indicate the maximum number of DTMF digits to collect from the caller. Play The Play keyword defines a play list of one or more messages to be played at this node. Help The Help keyword defines a play list of one or more messages containing useful hints for interacting with the system. These messages provide helpful instructions for a new or confused caller. Next The Next keyword defines the next node to jump to after the node being defined. It is used in conjunction with node types Link and Prompt. Work The Work keyword indicates a sequence of one or more operations to perform when arriving at the node being defined. This processing occurs before speech playback begins. A select set of math functions, relational operators, and nested if-then-else statements are supported. A pound sign (`#`) or a hyphen (`-`) in the first position on a new line will cause the translator to skip over the rest of the line. This is useful for inserting comments, or delimiting between individual node definitions. The translator also disregards blank lines. In order for a node to be properly defined, a minimum number of keywords must be present for each node, and other keywords must be included depending on the node type. The minimum keyword set for a properly defined node is: Node, Parent, Type, and Play. Dependency rules: (1) The Menu type requires at least an @ 1 line and an @ 2 line. (2) The YesNo type requires an @ 1 and an @ 2 line (@ 3, etc. are ignored). (3) The Link type requires a Next line. (4) The Prompt type requires a Digits line and a Next line. The first keyword in a node definition must be Node. The other keywords may be given in any order. The next occurrence of the Node keyword will invoke a completeness test. If the completeness test is successful, then the node definition is saved in machine readable (binary) format, and translation continues with the new Node line. A set of reserved language keywords is listed in Table 1.
TABLE 1
______________________________________
Reserved language keywords (case insensitive):
______________________________________
@ link return
and menu test
digbuf meta then
digits next type
else node wait
essf parent write
flush play work
hangup pop xor
help prompt yesno
if push
keep reenter
______________________________________
V. Run-Time Operation Referring to FIG. 4, the run time interaction among the hardware and software components of the MDATA system 100 will be described. As previously mentioned, algorithm processor 160 includes the parser and supporting functions that manipulate the memory variable symbol table and the run time stack. For a selected medical algorithm, a node record is read from the node table 174 and a list file is read from the plurality of list files 176. The algorithm processor also interacts with the Vpro voice recognition (VR) board 124 for speech recognition and with the Dialogic voice processing (VP) board 122 for speech playback and DTMF detection. The VP board 122 further is interconnected with a set of speech files 180 that are stored on a portion of hard disk 152 and with one of the telephone lines 106 that connects via the telephone network 108 (FIG. 1) to the patient's telephone 110. The VR board 124 further connects with the voice print vocabularies 182, previously described, also stored on a portion of hard disk 152. The algorithm processor 160 utilizes the speech recognition, speech playback, and DTMF detection resources as directed by the medical algorithm that is retrieved from the node table 174 and the list files 176. Referring to FIGS. 4, 5a and 5b, several data structures are utilized at run time. These data structures are described as follows: A. Port Status Block (PSB). A port status block is created at run time for each VP board 122 channel. The PSB contains flags, buffers and tables that hold the state information of the channel, retain responses from the caller, and keep track of where to transfer control in response to voice recognition and telephony events. The PSB keeps track of whether the caller prefers to use spoken or touch tone responses, the caller's last response, the number of consecutive errors the caller has made, and other context sensitive parameters. B. Node Block. This structure 196 contains the node number, the type attribute (link, menu, yes/no, hangup, prompt, wait, return) and pointers to: a. Help list--a Play list of help information; b. Play or Message list--a list of one or more messages or speech files to play in sequence at each node; c. Next table or list--contains entries for each possible response to a yes/no or menu node that are evaluated at run time to determine the next node to branch to; and d. Work list--things to do before message playback starts. The load.sub.-- node() routine 194 in util.c builds the node block structure 196 in memory by first reading in a node record 190 from the node table 174. Then linked lists are attached to the pointers help, play, next and work. These lists come from the list files 176, in subdirectory path .backslash.list.backslash.listxx.backslash.xxyy, where xxyy is the node number, wherein each list file 192 is associated with a unique node. C. Symbol Table. Each patient has their own associated symbol table. A portion of a symbol table 212 is shown in FIG. 5b. The symbol table is loaded at run time with memory variables that hold patient specific data (age, sex, and items from medical history) and algorithm specific data. The items in the symbol table can be flagged for storage to the patient's medical history. D. Run Time Stack (RTS). Each Dialogic VP board 122 channel has a RTS associated with it. The RTS is used by the parser. The algorithm programmer can push to and pop from the RTS, e.g. to temporarily store a value of a variable. The work list has the non-playback tasks that are performed at each node. There is one work list for each node, and it is identified with the work keyword in the ASCII node definition file. The work list may be empty. Each time the system transits to a new node, it will execute the work list. If the patient repeats a node, the system will not execute the work list again; it will simply replay the message(s). If the patient requests the system 100 to back up the node map, the system will execute the work list of the node it backs up to. Typical tasks in the work list involve manipulating objects on the run time stack or in the symbol table, testing for the presence of memory variables, configuring past medical history or current medical condition objects, or writing database records. An example of a complex work list follows: "Test OBJECT2; Phone=DIGBUF; Push Age" This example tests for the presence of a patient record object labelled "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, press 1; if no, press 2." Menu node: the response number and the table index are the same. Even though the actual data structure has a `0` index in the C programming language, this index is not used in the next table because a `0` response is reserved for operator assistance. Following is an example of a next list: "If Male and Age>55 then 100 else 200" is interpreted as: If the patient is both male and over 55 years old then go to node 100 else go to node 200. Speech files 180 may be of an arbitrary length. A message may be informational, a list of menu options, or a yes/no question. A "two paragraph" or "under one minute" limit has been adopted as a style convention for the presently preferred embodiment. Typically, a node is programmed as a sequence of Yes/No nodes, with "informational" Link nodes interspersed as needed. When there is a lengthy discussion, the speech is recorded in multiple files. To simplify algorithm programming and enhance readability (viz., eliminate long chains of link nodes), the Link node's play list may contain up to ten message numbers. Upon arrival at a Link node, the system positions a "current message" pointer at the beginning of the play list (trivial case: single message play list; interesting case: multiple message play list). As playback proceeds, the current message pointer moves down the play list. After the system plays the last message on the list, it moves on to the next node. If the caller issues a "backup" command, the system will move the current message pointer back one message, and resume playback. If the pointer was at the beginning of the list (e.g., trivial case), the system backs up to the previous node and places the current message pointer at the beginning of the play list. If there is more than one message in the list, the system cues the pointer to the last message in the list. The system then resumes playback. In the "pause" mode, when the caller issues the "continue" command, the system will resume playback at the current message. The MDATA system 100 uses three basic operating modes: A. Real Mode--involves an actual medical problem. In this mode the system 100 loads the past medical history, saves new past medical history objects, and writes a meta record for each algorithm consulted. The medical algorithm programmer is responsible for providing code to jump past meta analysis in Information mode. B. Information Mode--involves a "what if" scenario. In the Information mode the system 100 disregards past medical history, does not save newly configured past medical history objects, does not write a meta record for each algorithm consulted, and does not perform meta analysis. The patient has an option in Information mode to change the age and sex parameters to emulate a hypothetical patient. C. Pending Mode--handles the situation when a patient's voice sample does not match the patient's reference sample. Pending mode is utilized also when an assistant is interacting with the MDATA system 100 on behalf of a patient and both the assistant's and the patient's voice samples fail the voice printing test. In the case where the assistant's voice sample fails the voice printing test but the patient's voice sample passes the test, Pending mode is not utilized. In Pending mode, the MDATA system 100 considers the patient's medical history and performs meta analysis during this consultation. However, a meta record is not written for this consultation and any new medical information gathered on this patient will not be written to the patient's medical record. The new medical information is written to a "Pending" file. The Pending file is verified off-line by a system administrator or staff person, and then is added to the patient's medical record only if the information can be verified. One of the drawbacks of the traditional doctor-patient relationship is the short amount of time that physicians are able to spend with patients. The MDATA system 100, however, allows patients as much time as they wish to learn about their problem as well as to obtain information on any number of other medical topics. Through the "Information mode" feature of the MDATA system 100, callers can learn about a disease process, an illness or the latest treatment for any disease, without adding any information to their personal medical record. Although the system 100 keeps track of the interaction, it is labeled as an "Information mode session." The record of the caller's path through the system is not used as the basis for any future advice, nor is it considered in generating system statistics. The Information mode is not limited to complaints for which the MDATA system 100 offers medical advice. Information about early detection and treatment of many other diseases as well as the latest advances in medicine can be made available through the Information mode. Referring to FIGS. 5b through 5g, as an example, a run time sequence of steps of how a patient may traverse a main menu node map several steps into a chest pain algorithm node map will be described. A portion of the main menu node map with associated script, and of the chest pain algorithm node map with associated script is included in the Microfiche Appendix. Six nodes with a portion of an associated symbol table will be discussed. At FIG. 5b, the algorithm processor 160 loads the first node #100, represented by node block 210. The variables for Age, Sex, and Real mode were loaded into the symbol table 212 during the login process (which will be described hereinbelow). Throughout this example, the help list is empty, i.e., no help information is played for the patient. The work list sets the Problem variable of the symbol table 212 to be Menu. Then the system 100 begins playback of message#100. This message gives the patient a menu of choices to choose from. The Digits entry equal to one means that a one digit response is expected from the patient. The patient may respond by pressing a touch tone (DTMF) key on the telephone or speak the choice response into the telephone handset microphone. In this example, the patient selects menu option "1". The parser evaluates the Next list based on the patient selection and branches to node #101. At FIG. 5c, the algorithm processor 160 loads node #101, represented by node block 214. The work list is empty, so the system 100 goes right to playing back message#101 which presents another menu of choices to the user. The Next list has four nodes for possible branch points. In this example, the patient selects menu option "1" for a chest pain complaint. The parser evaluates the Next list based on the patient selection and branches to node #2200. At FIG. 5d, the algorithm processor 160 loads node #2200, represented by node block 218. The work list command is to update the value of Problem in symbol table 220 to CCHP (chest pain). Then the system 100 begins playback of message#2200. No response is required from the patient for a Link type node. The Next list has two nodes for possible branch points depending on the value of symbol table variable Real. The parser evaluates the If expression in the Next list for the value of Real and, in this example, branches to node #2201. At FIG. 5e, the algorithm processor 160 loads node #2201, represented by node block 222. The work list command is to write a Meta consultation record for future use by a Meta function. The play list is empty so no message is played. No response is required from the patient for a Link type node. The main purpose of this node is to write the Meta consultation record (because the system is currently in Real mode for this patient). The Next list has only one node so no decisions are necessary by the parser which, in this example, branches to node #2205. At FIG. 5f, the algorithm processor 160 loads node #2205, represented by node block 226. The work list is empty in this node so the system 100 goes right to playing back message#2205 which presents a yes/no type of question to the user. The Next list has two nodes for possible branch points depending on the response of the patient. In this example, the patient responds "no", and the parser evaluates the Next list based on the patient selection and branches to node #2210. At FIG. 5g, the algorithm processor 160 loads node #2210, represented by node block 230. The work list is empty in this node so the system 100 goes right to playing back message#2210 which presents a yes/no type of question to the user. The Next list has two nodes for possible branch points depending on the response of the patient. If the patient answers "yes" to the question, the parser branches to node #2211, but if the patient answers "no" to the question, the parser branches to node #2215. VI. Software Structure Referring to FIG. 6, the system utilizes eight principal, separate processes and seven related databases. A patient login process 250 is used by the system 100 to identify a patient who has previously registered into the system by prompting for a patient identification number (PIN). An assistant login process 272 is used by the system 100 to identify an assistant who has previously registered into the system by prompting for an assistant identification number (AIN). An assisted patient login process 276 is used by the system 100 to identify a patient who has previously registered into the system by prompting for the patient identification number. If the caller is the patient, a patient registration process 252 is used by the system to register new or first-time patients. If the caller is not the patient, an assistant registration process 274 is used by the system to register new or first-time assistants. Then, if the patient is not already registered, an assisted patient registration process 278 is used by the system to register the patient. These processes will be further described hereinbelow. Once a caller has logged in or registered, the system provides a choice of two other processes in the current embodiment. The first of these processes is the evaluation process 254 that performs a patient diagnosis. The second of these is a treatment table process 256 to obtain current treatment information for a particular disease or diagnosis. In another embodiment, other choices are added to access other medical information processes. Associated with these eight processes are a patient and assistant enrollment database 260, a consultation history database 262, a patient response database 264, a medical history objects database 266, a patient medical history database 268, a pending database 269, and a patient medication database 270 that are described as follows: A. The master patient and assistant enrollment database 260 is created at run-time by one of the registration processes 252, 274, or 278. This database 260 is read by the patient login process 250 or the assisted patient login process 276 to validate a patient's identity at login time and by the assistant login process 272 to validate an assistant's identity at login time. The database 260 is essentially a master file of all registered patients and assistants indexed by their patient ID number or assistant ID number, respectively. The patient ID or assistant ID, date of birth and gender fields are entered by the on-line registration process; the system administrator manually enters the name of the patient or assistant in an off-line manner. The patient and assistant database 260 contains one record for each patient or assistant. This database 260 is indexed by the identification number. The system appends the enrollment database 260 after a caller is successfully registered. The "next ID number" is stored in a binary file, config.fos, and is incremented after each successful registration. Each record has the following fields:
______________________________________
Field Name
Data Type Width Usage
______________________________________
ID Numeric 10 ID number
TYPE Character 1 User type: "P"--patient,
"A"--assistant
ASST.sub.-- PERM
Boolean 1 Permanent assistant
flag
ASST.sub.-- EXP
Date 8 Expiration for
permanent assistant
RELATIONS Pointer 20 Pointers to related
patients/assistants
ORGZTN Character 8 Organization
alphanumeric code
NAME Character 20 Patient/Assistant name
SEX Character 1 Gender
YEAR Numeric 4 Year of birth
MONTH Numeric 2 Month of birth
DAY Numeric 2 Day of birth
ACCESS Date 8 Last access
RV.sub.-- PATH
Character 20 Path name of recorded
voice file
______________________________________
B. The consultation history or meta database 262 is created at run-time by the evaluation process 254. A consultation record contains alpha-numeric codes for the patient's complaint, the affected anatomic system and the diagnosed cause of the patient's complaint. When the meta function is invoked at run-time, it compares alphanumeric strings provided by the evaluation process with the fields of all the patient's meta records that fall within a time window specified by the evaluation process. The meta function returns the number of matches found, and an indication of the frequency of the patient's complaint. Each patient has an individual meta file that is part of the consultation history database 262. At the conclusion of the evaluation process and dependent on the run-time operating mode flag, the system will create a new meta record, populate its fields with the information gathered during the evaluation process, and append this record to either the consultation history database 262 or the Pending file 269. For example, information used in the new meta record may come from a "Write Meta" command in a node Work list. Each record 45 has the following fields:
______________________________________
Field Name
Data Type Width Usage
______________________________________
DATE Date 8 Date stamp
PROBLEM Character 5 Patient
complaint/symptom
SYSTEM Character 5 Anatomical system
affected
CAUSE Character 5 Diagnosed cause of
complaint
______________________________________
C. The patient response database 264 is created at run-time by the evaluation process 254. The response database 264 is an audit trail: each record is time stamped and registers the patient's response to each question. This database 264 can later be analyzed off-line with a database program such as FoxPro/FoxBase to reveal how the patient responded to questions during the evaluation process 254, or a database program can be developed to gather response patterns and statistics and generate appropriate reports. Each patient has a response trace file that is part of the patient response database 264. The system 100 appends this response trace file with a response record every time the patient answers a question or provides algorithm-requested data. For human readability, the system also inserts "Begin Call" and "End of Call" records in this file. Each record has the following fields:
______________________________________
Field Name
Data Type Width Usage
______________________________________
DATE Character 8 Date stamp MM/DD/YY
TIME Character 8 Time stamp HH:MM:SS
NODE Numeric 6 Current node number
TYPE Character 5 Response type: DTMF
or VOICE
RESP Character 5 Response command or
digit string
MODE Character 1 Consultation
operating context
VERSION Character 20 Version or
Begin/End call
comment
SENS.sub.-- FACT
Character 20 Current sensitivity
factor settings
______________________________________
D. The medical history objects database 266 is an auxiliary database that supports a key feature of the MDATA system 100: past medical history. The medical history objects database is a catalog of unique alphanumeric codes, each code corresponding to a medical condition or diagnosis that is not expected to change during the life of the patient (e.g., a diagnosis for asthma is coded as "RWHZAST"). In addition to the alphanumeric codes, the MDATA system 100 uses the "memo" field in a Foxpro database to store binary objects. Currently, these binary objects are clinical sounds obtained from the patient over the telephone. It is anticipated, that as database technology gets more sophisticated (moving toward multi-media and so forth), it will allow storing of larger and more complicated binary files such as the following: a digitized x-ray, a digitized CAT scan, a digitized MRI scan. In addition, as video-telephone technology advances, it is anticipated that the system 100 will store video images or even holographic images of the patient. For every past medical condition there is a record in the medical history objects database that contains the attributes of the medical condition, and contains a pointer into the past medical history questionnaire. The attributes of a medical condition include its data type (e.g., boolean or numeric) and the number of digit positions needed to store the value of a numeric value associated with this condition (not applicable to boolean type). The pointer field is useful for obtaining medical history at run-time. If a patient has an incomplete medical history questionnaire on file with the MDATA system 100, then the pointer field allows the evaluation process to momentarily suspend the evaluation, go to the medical questionnaire and ask an individual question, collect and verify the patient's response, and then resume the evaluation process. This "ask-when-you-need-it" approach relieves the new patient of going through an exhaustive medical history questionnaire before the first consultation of the diagnostic process. Each record of the medical history objects database has the following fields:
______________________________________
Field Name
Data Type Width Usage
______________________________________
LABEL Character 8 Object code name
TYPE Character 1 Object data type
DIGITS Numeric 3 Maximum number of
digits in response
CALL Pointer 6 Identifies
question(s) to be
asked to configure
this object
AUDIO Binary N/A Voice print
IMAGERY Binary N/A Face print
RFU Character 20 (For future use)
______________________________________
E. The patient medical history (PMH) database 268 is created at run-time by the evaluation process 254 or by use of a past medical history questionnaire. The PMH database 268 is read by the evaluation process during run-time. This database 268 contains each patient's individual medical history. A new patient has an option to go through the entire medical questionnaire at one time, thereby configuring all the past medical history objects listed in the objects database 266. Alternately, the new patient can bypass the questionnaire and go right into the diagnosis of a medical complaint. Then, if a medical algorithm requires a past medical history object that has not yet been configured, the evaluation process 254 invokes a past medical history function before it continues with the algorithm. Each patient has their own past medical history file, which is part of the PMH database 268, that contains records which describe medical events or conditions from the patient's life. The system 100 appends a record to this file each time a past medical history object is configured for the patient. The contents of this file are installed in the symbol table when the patient logs in to the system 100. The medical algorithm programmer is responsible for using a TEST command to verify that necessary items are present in the symbol table before algorithm execution. A side effect of a negative TEST result is that the system 100 prompts the patient to provide that information. The system 100 flags any new or modified items, and asks the patient to confirm these values during an Exit Confirmation Loop which will be described hereinbelow. Each record has the following fields:
______________________________________
Field Name
Data Type Width Usage
______________________________________
LABEL Character 20 The object's label
TYPE Character 1 Object data type
VALUE Character 10 Object's configured
value
CERT Numeric 3 Certainty of
object's value
DATE Date 8 Object
configuration date
ICD9A Float 5 First ICD-9 code
.linevert split.
.linevert split.
.linevert split.
.linevert split.
ICD9E Float 5 Fifth ICD-9 code
______________________________________
F. The "Pending" database file 269 holds medical information gathered during Pending mode for offline verification. The Pending database record structure is the same as that used for the past medical history (PMH) database 268. The evaluation process writes to the Pending database at run-time when it configures a new past medical history object for a patient during a Pending mode interaction. The contents of the Pending database are reviewed off-line by a staff person, and if the information is verified, the staff person appends the information to the patient's past medical history file. G. An optional patient medication database 270 contains a file for each patient containing information about medication they are taking, or have taken in the past. The medication database 270 is created by the evaluation process 254 at run time. A "Write Drug" command builds a record and fills its fields with same-named memory variables from the symbol table. The evaluation process 254 may read the medication database 270 during run time as needed. The treatment table 256 optionally reads the medication database 270 to determine the medication(s) being used by the patient.
______________________________________
Field Name Data Type Width
______________________________________
GENERIC.sub.-- NAME
Character 20
TRADE.sub.-- NAME1
Character 20
TRADE.sub.-- NAME2
Character 20
TRADE.sub.-- NAME3
Character 20
ICD-9-CM.sub.-- CODE
Character 10
ICD-9-CM.sub.-- ECODE
Character 10
ICD-9-CM.sub.-- VCODE
Character 10
OTHER Character 20
DOSAGE Character 20
ROUTE.sub.-- OF.sub.--
Character 10
ADMINISTRATION
FREQUENCY Character 10
USE Character 20
START.sub.-- DATE Date 8
STOP.sub.-- DATE Date 8
OTHER1 Character 20
OTHER2 Character 20
______________________________________
VII. Top-Level Flow Referring to FIGS. 7a, 7b, 7c and 7d, the top level flow 300 of the MDATA system 100 software will be described. The telephone number used to access the MDATA system 100 may vary in various embodiments of the system. If the sponsoring agency or hospital wishes to provide access to the MDATA system 100 at no cost to the caller, then a toll-free 800 service number can be used. If the sponsoring agency or hospital wishes to recover the costs of running the MDATA system 100 from the caller, it may use a pay-per-call or premium charge number (e.g., 900 service). "Current Procedural Terminology" (CPT-4) codes are available to describe and bill third party payers for telephone consultations. They are a listing of the descriptive terms and identifying codes for reporting medical services and procedures. CPT-4 codes are the most widely accepted nomenclature for reporting physician services to insurance companies. Beginning at a start state 302, a person 112 (FIG. 1) desiring medical advice calls the telephone number for the MDATA system 100 on a telephone line 106. The caller may be the patient or may be an "assistant", e.g., parent, relative, or friend, that is helping the patient. Moving to state 304, the system 100 answers the call automatically and greets the caller 112 with an introductory greeting message by playing back a speech file stored on the hard drive 152 by use of the VP board 122. Proceeding at state 306, the MDATA system 100 asks each patient who calls the system a series of "initial screening questions." These questions are designed to identify patients who are critically ill; they are not designed to identify the patient's problem. The initial screening questions enable the system to filter out patients who require immediate medical attention. Moving to decision state 308, any patient found to be critically ill is instructed to dial the emergency response telephone number "911" at state 309 or will be automatically connected to the nearest emergency medical services system in the patient's area. The telephone call is terminated by the computer 102 at state 310. The following are examples of initial screening questions: IS THIS A MEDICAL EMERGENCY? ARE YOU HAVING DIFFICULTY BREATHING? ARE YOU EXPERIENCING SEVERE PAIN OR PRESSURE IN YOUR CHEST? If the system determines that the patient is experiencing a medical emergency, it may provide the patient with a menu of emergency medical procedures at state 311. In situations where the patient or the caller for the patient is far from the nearest emergency help, e.g., a rural setting, the caller may need to initiate emergency procedures immediately. The menu of emergency medical procedures provides several choices to the caller. If the caller presses touch tone key "1" or speaks the word "one" into the telephone mouthpiece, the computer 102 branches to state 312 wherein well known CPR (cardiopulmonary resuscitation) information is recited. If the caller has a speakerphone capability associated with the telephone 110 being used, the caller may be able to listen to and perform the instructions given by the system 100 in a hands-free manner away from the telephone. If the caller presses touch tone key "2" or speaks the word "two" into the telephone mouthpiece, the computer 102 branches to state 313 wherein well known Heimlich Hug information for choking is recited. At the completion of either state 312 or state 313, the telephone call ends at state 314. If the patient is determined at state 308 not to have a medical emergency, i.e., the MDATA system 100 is satisfied that no immediately life threatening condition is present, the computer 102 moves to a decision state 315 to determine if the caller is the actual patient. If so, the computer 102 proceeds to a decision state 316 to determine if the patient has previously registered or ever consulted with the system 100, i.e., is not a new or first-time caller. If so, the system 100 verifies the patient's identification and retrieves their medical record at the patient login process 250, which will be further described hereinbelow. At the completion of process 250, the computer 102 proceeds through off-page connector C 317 to state 344 (FIG. 7d). If the patient is not registered, the MDATA system 100 proceeds to the patient registration process 252 for a new patient, which will be described hereinbelow. At the completion of process 252, the computer 102 proceeds through off-page connector C 317 to state 344 on FIG. 7d. If the caller is not the patient, as determined at state 315, the computer 102 proceeds through off-page connector A 318 to state 320 on FIG. 7b. There will be times when the patient may not be able to use the MDATA system 100 directly, e.g., due to injury, weakness or altered level of consciousness. In these cases, an "assistant" may interact with the system on behalf of the patient. An assistant registers with the system through the assistant registration process 274 which will be described hereinbelow. The assistant registration record is identical to the patient registration record in structure, but three fields have special significance for an assistant: ASST.sub.-- PERM, ASST.sub.-- EXP, and RELATIONS. The ASST.sub.-- PERM field is a boolean flag that can only be set true off-line by the system administrator who has verified, through separate means, that a relationship exists between a patient and an assistant. The relationships are one-to-many, i.e., a patient may have one or more assistants, and an assistant may be related to more than one patient. The ASST.sub.-- PERM flag may also be constrained by the ASST.sub.-- EXP field, which contains a timestamp for the expiration of the ASST.sub.-- PERM attribute. If the ASST.sub.-- PERM flag is true, then the RELATIONS pointers will point to one or more patient records for whom this assistant is a "permanent assistant;" otherwise the RELATIONS field will be empty. The medical information gathered during an assisted consultation is written to the patient's medical record only if the following three conditions are met: (a) the assistant's ASST.sub.-- PERM flag is True (b) the ASST.sub.-- EXP timestamp has not been reached (c) the assistant has a relationship pointer to the patient record If any of these conditions are not met, then any new medical information gathered on this patient will be saved to the Pending file 269 for off-line verification by the system administrator. The system 100 establishes at state 315 whether the caller is the patient, or an assistant. If the caller is not the patient, then the system asserts that the caller is an assistant and, at a decision state 320, determines if the assistant is registered. If the assistant is not already registered with the system, the system enrolls the new assistant at the assistant registration process 274. If the assistant is already registered with the system 100, the computer 102 performs the assistant login process 272. At the completion of either process 272 or process 274, the computer 102 advances to a decision state 321. If the patient is not already registered with the system 100, as determined at decision state 321, then the system allows the assistant to register a new patient at the assisted patient registration process 278. However, if the patient is already registered with the system 100, as determined at state 321, the computer 102 performs the assisted patient login process 276. At the completion of process 278 or process 276, the computer 102 proceeds through off-page connector B 327 to a decision state 334 on FIG. 7c. At decision state 334, the computer 102 determines if the patient's date of birth is in the patient's medical record. If so, the computer proceeds through off-page connector C 317 to state 344 on FIG. 7d. If not, the system 100 attempts to get the patient's date of birth. Moving to state 335, the system 100 asks the assistant if the patient's date of birth is known. If so, the computer 102 advances to state 336 to request the patient's date of birth. At state 337, the system 100 recites the patient's date of birth obtained at state 336. At a decision state 338, the assistant determines if the date of birth is correct as recited by the system 100. If not, the computer 102 loops back to state 336 to request the patient's date of birth again. If the patient's date of birth is correct, as determined at state 338, the computer 102 flags the date of birth for saving in the patient's medical record at state 339, and proceeds to state 344 on FIG. 7d. If the patient's date of birth is not known, as determined at state 335, the computer 102 proceeds to state 340 wherein the system requests the assistant to provide an approximate age of the patient. The age is an important parameter used in the evaluation process 254 and treatment table 256. At state 341, the system 100 recites the patient's approximate age obtained at state 340. At a decision state 342, the assistant determines if the age is correct as recited by the system 100. If not, the computer 102 loops back to state 340 to request the patient's approximate age again. If the patient's approximate age is correct, as determined at state 342, the system 100 advises the assistant at state 343 to get the patient's actual date of birth before the next consultation, and proceeds to state 344 on FIG. 7d. The system 100 uses the approximate age in the consultation during the evaluation process 254 and the treatment table 256. At state 344 on FIG. 7d, the system 100 presents the caller with a system selection menu. Here, the caller is asked to select from among four choices: diagnostic system, treatment table, a future process/function, or end call as described below: A. Diagnostic System: The system starts the evaluation process 254 at a menu, where it asks the patient to begin identification of the complaint. B. Treatment Table: The system takes the patient to the treatment table process 256 at a menu, where it asks the patient to select a treatment selection method. C. Future Process/Function: A future process or function 280, undefined in the present embodiment, that reads and/or writes the databases shown in FIG. 6. D. End Call: The system performs several steps and then terminates the telephone call. In either process 254 or 256, the computer 102 functions as an interpreter as performed by algorithm processor 160 in following the node map created by the algorithm programmer. At the exit point of the evaluation process 254, the system 100 gives the patient the option of selecting another complaint. At the end of the treatment table process 256, the system gives the patient the option of selecting another treatment. At the completion of the evaluation process 254, treatment table process 256, or future process 280, the system 100 loops back to state 344 and recites the system selection menu to the caller. If the caller chooses the End Call selection at state 344, the MDATA system 100 moves to a decision state 345. At decision state 345, the system 100 determines if process 254, process 256, or process 280 did not occur in Information mode, i.e., did occur in either Real mode or Pending Mode, and examines the patient's symbol table to determine if any of the configured memory variables are past medical history conditions that need to be saved to the patient's medical history file. If both conditions are true at state 345, the system 100 advances to a decision state 346 to determine if the consultation is being performed in Real mode. If not, the consultation is being performed in Pending mode, and the system 100 then writes any new patient information obtained during the consultation to the Pending file 269. If state 346 proves to be true, i.e., Real mode, for each past medical condition that needs to be saved, the MDATA system 100 asks the patient at state 348 to grant permission to save the datum to the patient's medical history file and to confirm that the datum is correct. For example, during a consultation for cough, the MDATA system 100 learned that the patient has been diagnosed as being HIV positive. The system 100 will ask, "May I record the information about your HIV diagnosis in your medical record?" If the patient responds "yes", then the system 100 will ask, "Please verify that your diagnosis for HIV was positive, is this correct?" If the patient responds "yes", then the system 100 writes this fact to the patient's medical history file. After confirmation, each data item is stored in the patient's file in the patient medical history database 268 (FIG. 6). At the completion of either updating the history database 268 at state 348, state 345 proves to be false, or at the completion of state 347, the system 100 moves to a decision state 349. Before the MDATA system 100 ends the consultation with the patient, it presents a summary of all the advice it has given. The patient is asked to write down and repeat back the key points. The MDATA system 100 then gives the patient the option of receiving a summary of the consultation session and specific recommendations provided by the system by either facsimile or first class mail. If a fax is desired, the system 100 asks the patient for a fax number at state 350. The patient also has the option to send a summary of the consultation to his or her health care provider or specialist. Proceeding to state 351, the computer 102 adds the transcript of the current telephone session to a fax queue for subsequent transmission. At the completion of state 351 or if the system 100 determined at state 349 that the session transcript was not to be faxed, the telephone call is terminated at state 352. VIII. Login Process Referring now to FIGS. 8a and 8b, the patient login process 250 defined in FIG. 7a will be described. This process 250 is called if the patient has previously called and registered with the system 100. Beginning at a start state 358, the computer 102 moves to state 359 and initializes a match flag to true. The match flag is checked later in this process 250 in conjunction with setting the mode of the consultation. Proceeding to state 360, the computer 102 prompts the patient for the patient ID (identification) number (PIN) that is assigned during the registration process. The patient registration process 252 will be described in conjunction with FIGS. 9a and 9b. Proceeding to a decision state 361, the computer 102 determines whether the PIN is valid. If not, the computer 102 determines, at a decision state 362, if less than three tries at entering the PIN have been attempted. If so, the computer 102 loops back to state 360 to repeat the request for the PIN. However, if three attempts at entering the PIN have been made, as determined at state 362, the computer 102 plays a polite message that advises the patient that the login attempt failed and terminates the call at state 363. The computer 102 reports the failed login attempt to the system administrator at the sponsoring agency, hospital or other organization. The patient is allowed to reregister as a new patient, however, to permit access to the needed medical information. The system administrator resolves this type of situation off-line. If the patient has correctly entered a valid PIN, as determined at state 361, the computer 102 moves to a decision state 364 to determine if the patient identified by the PIN has a voice print or sample voice waveform on file in the system 100. If not, the computer 102 proceeds to state 365 to record the voice print of the patient, e.g. the patient's pronunciation of his or her full name. The patient's voice print may not be on file, for example, if the patient could not provide a voice print during the assisted patient registration process 278 in a prior consultation. At the completion of recording the voice print at state 365, the computer 102 advances to state 366 wherein the match flag is set to false to indicate that the patient's voice print was recorded during the current login. If the patient identified by the PIN has a voice print on file in the system 100, as determined at state 364, the computer 102 proceeds to state 367 and prompts the patient to pronounce his or her full name. Moving to a decision state 368, the computer 102 determines whether the voice sample obtained at state 367 passes the matching criteria. If not, the computer proceeds to state 369 and recites a message that the current voice sample does not pass the matching criteria. In the presently preferred embodiment, the current voice sample is compared to the reference voice sample recorded during the patient registration process 252 or the assisted patient registration process 278. Because the voice samples did not match, as determined at state 368, the computer 102 sets the match flag to false at state 370. In this case, the match flag is set to false to indicate that one of the security checking methods has failed. However, the process 250 continues at state 372 after the match flag is set to false at either state 366 or 370. If the voice sample passed the matching criteria at state 368, the computer 102 advances to state 371 and recites a message that the current voice sample passed the matching criteria. This security check condition is now satisfied, and the match flag remains set to true. At the completion of state 371 the computer 102 moves to state 372. At state 372, the computer 102 verifies the sex and age of the patient by reciting the sex and age, as stored in the enrollment database 260 (obtained during the patient registration process 252), to the patient. At a decision state 373, the patient responds to the correctness of the recited information. If the sex or birth date information is not correct, the computer 102 moves to state 374 to request the correct information. The computer 102 then proceeds back to state 372 to verify the information received at state 374. If the result of the decision state 373 is true, i.e., the sex and age are correct, the computer moves through off-page connector A 375 to a decision state 376 on FIG. 8b to determine if the patient desires to conduct the telephone session in Real mode or Information mode. If Information mode is desired, the computer 102 moves to a decision state 377 to determine if the patient's sex and age are to be used during the Information mode consultation. If not, the computer 102 moves to state 378 to request an age and sex to use in a hypothetical situation during the Information mode session. Moving to a decision state 379, the computer 102 recites the sex and age obtained at state 378, and asks the patient to confirm that this information is correct. If not, the computer 102 moves back to state 378 to request the age and sex again. When decision state 379 is true or the patient's age and sex are to be used during this consultation, as determined at state 377, the computer 102 moves to state 380 and sets the operating mode to be Information mode. If decision state 376 is determined to be Real mode, the computer 102 moves to a decision state 381 to check if the match flag is true. If not, the system 100 advises the patient, at state 382, that the current consultation is to be performed in Pending mode. The operating mode is set to be Pending mode at state 383. If the match flag is true, as determined at state 381, the computer 102 sets the operating mode to be Real mode at state 384. At the completion of setting the operating mode at either state 380, state 383, or state 384, the computer moves to a decision state 386. At decision state 386, the computer 102 determines if the patient desires to review the touch tone commands described during the registration process. If so, the computer 102 advances to state 388 and recites the touch tone commands. At the completion of state 388 or if the patient did not wish to review the touch tone commands, the computer 102 proceeds to a decision state 390 wherein the computer 102 determines if the patient desires to review the voice keywords described during the registration process. If so, the computer 102 advances to state 392 and recites the voice keywords. At the completion of state 392 or if the patient did not wish to review the voice keywords, the computer 102 proceeds to a decision state 394 wherein the computer 102 determines if the patient desires to enable prompting. If so, the computer 102 advances to state 396 and enables prompting. If not, prompting is disabled at state 398. To "enable prompting" means that the patient would like to be prompted for responses. This is referred to as "hard" prompting, since this will remain in effect for the duration of the call. If hard prompting is off, and the system 100 has difficulty recognizing patient responses, the computer 102 turns on "soft" prompting. After the next successful recognition, the computer 102 turns off soft prompting. At the completion of state 396 or 398, the computer 102 returns at state 400 to the top level flow (FIG. 7). Referring now to FIGS. 12a and 12b, the assistant login process 272 defined in FIG. 7b will be described. This process 272 is called if the assistant has previously called and registered with the system 100. Beginning at a start state 940, the computer 102 moves to a state 942 and prompts the assistant for the assistant ID (identification) number (AIN) that is assigned during the registration process. The assistant registration process 274 will be described in conjunction with FIGS. 14a and 14b. Proceeding to a decision state 944, the computer 102 determines whether the AIN is valid. If not, the computer 102 determines, at a decision state 946, if less than three tries at entering the AIN have been attempted. If so, the computer 102 loops back to state 942 to repeat the request for the AIN. However, if three attempts at entering the AIN have been made, as determined at state 946, the computer 102 plays a polite message that advises the assistant that the login attempt failed and terminates the call at state 948. The computer 102 reports the failed login attempt to the system administrator at the sponsoring agency, hospital or other organization. If the assistant has correctly entered a valid AIN, as determined at state 944, the computer 102 proceeds to state 950 and prompts the caller to pronounce his or her full name. Moving to a decision state 951, the computer 102 determines whether the voice sample obtained at state 950 passes the matching criteria. If not, the computer proceeds to state 952 and recites a message that the current voice sample does not pass the matching criteria. In the presently preferred embodiment, the current voice sample is compared to the reference voice sample recorded during the assistant registration process 274. Because the voice samples did not match, as determined at state 951, the computer 102 sets the operating mode to Pending at state 953. In this case, Pending mode is set to indicate that one of the security checking methods has failed. However, the process 272 continues at state 960 on FIG. 12b after Pending mode is set at state 953. If the voice sample passed the matching criteria at state 951, the computer 102 advances to state 954 and recites a message that the current voice sample passed the matching criteria. This security check condition is now satisfied. Next, three additional checks are performed on the assistant identified by the AIN obtained at state 942. At a decision state 955, the computer 102 determines if the permanent assistant flag is true, as stored in the patient and assistant enrollment database 260. If so, the computer 102 advances to a decision state 956 to determine if the expiration date for the permanent assistant is in the future, i.e., the expiration date has not been reached yet. If so, the computer 102 advances to a decision state 957 to determine if a relationship exists between the assistant and a patient, i.e., the assistant has a relationship pointer to the patient record. If so, the operating mode is set to Real at state 958, and then the computer 102 advances through off-page connector A 959 to state 960 on FIG. 12b. However, if any of the decision states 955, 956, or 957 prove to be false, the computer 102 moves to state 953 wherein the operating mode is set to Pending. States 960 through 964 are similar to states 372 through 374 of the patient login process 250 (FIG. 8). Because of this similarity, only significant differences are discussed in the interest of avoiding repetitiveness. States 960, 962 and 964 verify the assistant's age and sex, rather than the patient as in states 372, 373 and 374. States 966 through 980 are similar to states 386 through 400 of the patient login process 250 (FIG. 8b). The main distinction is that states 966-980 pertain to the assistant and states 386-400 pertain to the patient. Referring now to FIGS. 13a and 13b, the assisted patient login process 276 defined in FIG. 7b will be described. This process 276 is called if both the patient and the assistant have previously called and registered with the system 100. This process allows the patient flexibility by permitting the assistant to provide help during the login and subsequent consultation. Beginning at a start state 990, the computer 102 moves a state 992 and prompts the assistant for the patient ID (identification) number (PIN) that is assigned during the registration process. As previously defined in FIG. 7, the assisted patient registration process 278 is called if the patient is not already registered. Process 278 will be described in conjunction with FIGS. 15a and 15b. Proceeding to a decision state 994, the computer 102 determines whether the PIN is valid. If not, the computer 102 determines, at a decision state 996, if less than three tries at entering the PIN have been attempted. If so, the computer 102 loops back to state 992 to repeat the request for the PIN. However, if three attempts at entering the PIN have been made, as determined at state 996, the computer 102 plays a polite message that advises the caller that the login attempt failed and terminates the call at state 998. The computer 102 reports the failed login attempt to the system administrator at the sponsoring agency, hospital or other organization. If the assistant doesn't know the PIN and the patient cannot provide it, the assistant is allowed to reregister the patient as a new patient at process 278 to permit access to the needed medical information. In this case, the assistant may have to estimate the age of the patient if the patient has, for example, an altered state of consciousness. The system administrator resolves the record-keeping in this situation off-line. If the assistant has correctly provided a valid PIN to the system 100 at state 994, the computer 102 moves to a decision state 993 to determine if the patient identified by the PIN has a voice print or sample voice waveform on file in the system 100. If not, the computer 102 moves to a decision state 1003 to determine if the patient can provide a voice sample. If not, the computer 102 proceeds through off-page connector B 997 to state 1008 on FIG. 13b. If the patient can provide a voice sample, as determined at state 1003, the computer 102 moves to state 995 to record the voice print of the patient, e.g. the patient's pronunciation of his or her full name. The patient's voice print may not be on file, for example, if the patient could not provide a voice print during the assisted patient registration process 278 in a prior consultation. At the completion of recording the voice print at state 995, the computer proceeds through off-page connector B 997 to state 1008 on FIG. 13b. If the patient identified by the PIN has a voice print on file in the system 100, as determined at state 993, the computer 102 proceeds to state 999 and asks whether the patient can provide a voice sample to the system. If not, the computer 102 proceeds through off-page connector B 997 to state 1008 on FIG. 13b. States 1000, 1002, 1004, 1006 are similar to states 367, 368, 369, 371, respectively, of the patient login process 250 (FIG. 8). Because of this similarity, only significant differences are discussed in the interest of avoiding repetitiveness. At the completion of state 1004, i.e., the patient's voice sample does not pass the matching criteria, the computer 102 proceeds through off-page connector B 997 to state 1008 on FIG. 13b. At the completion of state 1006, i.e., the patient's voice sample does pass the matching criteria, the computer 102 proceeds through off-page connector A 1001 to state 1005 on FIG. 13b. At the completion of state 995, i.e., the patient's voice print is recorded, state 999 or state 1003, i.e., the patient cannot provide a voice sample, or state 1004, i.e., the voice sample match fails, the system continues process 276 at state 1008 on FIG. 13b. For the three situations just described in this process 276, the computer 102 sets the operating mode to Pending at state 1008. The system 100 then advises the caller at state 1009 that new patient information will not be saved to the patient's medical record because the consultation is in Pending mode until the information is verified off-line. At the completion of state 1006, i.e., the voice sample passes, the computer 102 continues process 276 at state 1005 wherein the operating mode is set to Real. The system 100 then advises the caller at state 1007 that new patient information will be saved to the patient's medical record. At the completion of state 1009 or state 1007, the computer 102 moves to state 1010. States 1010, 1012 and 1014 verify the patient's age and sex, similar to states 372, 373 and 374 (FIG. 8). States 1016 through 1030 are similar to states 386 through 400 of the patient login process 250 (FIG. 8). The main distinction is that states 1016-1030 are directed to the assistant and states 386-400 are directed to the patient. IX. Registration Process Referring now to FIGS. 9a and 9b, the patient registration process 252 defined in FIG. 7a will be described. This process 252 is called if the patient has not previously called and registered with the system 100. During the first consultation, the MDATA system 100 obtains the patient's age and sex. This is the minimum amount of information that the MDATA system requires in order to give medical advice. The more information the MDATA system has about a patient, however, the more specific is its advice. The MDATA system 100 assigns each of its patients a unique patient identification number. In addition, when a patient initially registers, the patient's own pronunciation of his or her name is recorded, digitized and saved to their medical record. Then, when the patient calls back, the previous recording is retrieved and the patient is asked to repeat their name exactly as they did during registration. The two recordings are then compared to see if they match. This use of "voice printing" helps to further ensure the security and confidentiality of a patient's medical record. Beginning at a start state 420, the computer 102 proceeds to state 422, requests the sex of the patient, and verifies by repeating the response given by the patient. Moving to a decision state 424, the patient responds by indicating to the system 100, via touch tone key or a voice response, whether the repeated information is correct. If not, the computer 102 loops back to state 422 to request the information again. When the information is correct at state 424, the computer 102 proceeds to states 426 and 428 to request and verify the birth date of the patient in a similar fashion to states 422 and 424. When the decision state 428 is determined to be true, the computer 102 proceeds to state 427 and requests the patient to pronounce his or her full name. Moving to state 429, the full name is digitized and stored in a subdirectory on the hard drive 152 (FIG. 1) indexed by a Patient Identification Number (PIN). File names are of the form: <PIN>.vox. The computer 102 accesses a file to retrieve the next available PIN. The path name to the recorded voice file is saved in the patient's record in the enrollment database 260. In subsequent telephone sessions with the system 100, the patient's voice waveform will be compared to the recorded voice waveform for security and other optional purposes. When the voice waveform is stored, the computer 102 moves to state 431 and provides the PIN to the patient. The patient is informed of the importance to save the PIN for use in future consultations with the system 100. At the completion of state 431, the computer 102 moves to a decision state 430 to determine if the patient has a MDATA system user pamphlet available. If so, the computer 102 moves to state 436 and requests the patient to turn to the pamphlet page that documents the touch tone keys, voice keywords, and modes. If not, the computer 102 moves to a decision state 432 to determine if the patient would like the system 100 to pause to enable the patient to get paper and a writing instrument for writing user instructions. If so, the computer 102 pauses at state 434 for 30 seconds. At the completion of the pause at state 434, if the user did not desire a pause at state 432, or after the patient is instructed to turn to the proper page of the pamphlet, the computer 102 proceeds to state 440 of FIG. 9b via the off-page connector A 438. At state 440, the system 100 provides an explanation of the touch tone keys to the patient. These keys were described above in relation to the discussion on Voice Keywords and DTMF Command Keys. Moving to state 442, the computer 102 asks if the patient desires to hear the explanation of keys again. If so, the computer 102 repeats state 440. If not, the computer 102 advances to state 444 wherein an explanation of the voice keywords is provided to the patient. These keywords were previously described above. Moving to state 446, the computer 102 asks if the patient desires to hear the explanation of keywords again. If so, the computer 102 repeats state 444. If not, the computer 102 advances to state 448 wherein an explanation of Real and Information modes is provided to the patient. These modes were previously described above. Moving to state 450, the computer 102 asks if the patient desires to hear the explanation of the modes again. If so, the computer 102 repeats state 448. If not, the computer 102 advances to state 452 wherein a summary of new user information is recited to the patient. The summary includes a recap of the two methods of controlling the system: | ||||||