EP0912955A2 - Computerized medical diagnostic system utilizing list-based processing - Google Patents

Computerized medical diagnostic system utilizing list-based processing

Info

Publication number
EP0912955A2
EP0912955A2 EP97934919A EP97934919A EP0912955A2 EP 0912955 A2 EP0912955 A2 EP 0912955A2 EP 97934919 A EP97934919 A EP 97934919A EP 97934919 A EP97934919 A EP 97934919A EP 0912955 A2 EP0912955 A2 EP 0912955A2
Authority
EP
European Patent Office
Prior art keywords
script
symptom
disease
patient
symptoms
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP97934919A
Other languages
German (de)
English (en)
French (fr)
Inventor
Edwin C. Iliff
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
First Opinion Corp
Original Assignee
Edwin C. Iliff
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Edwin C. Iliff filed Critical Edwin C. Iliff
Priority to EP02075042A priority Critical patent/EP1280091A3/en
Publication of EP0912955A2 publication Critical patent/EP0912955A2/en
Ceased legal-status Critical Current

Links

Classifications

    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A61B5/0015—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by features of the telemetry system
    • A61B5/0022—Monitoring a patient using a global network, e.g. telephone networks, internet
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/41—Detecting, measuring or recording for evaluating the immune or lymphatic systems
    • A61B5/411—Detecting or monitoring allergy or intolerance reactions to an allergenic agent or substance
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/60—ICT specially adapted for the handling or processing of medical references relating to pathologies
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02A—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
    • Y02A90/00—Technologies having an indirect contribution to adaptation to climate change
    • Y02A90/10—Information and communication technologies [ICT] supporting adaptation to climate change, e.g. for weather forecasting or climate simulation

Definitions

  • the present invention relates to computerized medical diagnostic systems. More specifically, the invention is directed to a computerized system for time-based diagnosis of a patient's complaint by use of dynamic data structures. Description of the Related Technology
  • Health care costs currently represent a significant portion of the United States Gross National Product and are rising faster than any other component of the Consumer Price Index. Moreover, usually because of an inability to pay for medical services, many people are deprived of access to even the most basic medical care and information. Many people delay in obtaining, or are prevented from seeking, medical attention because of cost, time constraints, or inconvenience. If the public had universal, unrestricted, and easy access to medical information, many diseases could be prevented. Likewise, the early detection and treatment of numerous diseases could keep many patients from reaching the advanced stages of illness, the treatment of which is a significant part of the financial burden attributed to our nation's health care system. It is obvious that the United States is facing health-related issues of enormous proportions and that present solutions are not robust.
  • List-Based Processing is a method of diagnosing diseases that works by arranging diseases, symptoms, and questions into a set of nested Disease, Symptom, and Question (DSQ) lists in such a way that the lists can be processed to generate a dialogue with a patient.
  • Each question to the patient generates one of a set of defined responses, and each response generates one of a set of defined questions.
  • This establishes a dialogue that elicits symptoms from the patient.
  • the symptoms are processed and weighted to rule diseases in or out.
  • the set of ruled-in diseases establishes the diagnosis.
  • a List-Based Processing system organizes medical knowledge into formal, structured lists or arrays, and then applies a special algorithm to those lists to automatically select the next question.
  • the responses to the questions lead to more questions and ultimately to a diagnosis.
  • a computerized diagnostic method comprising the steps of providing to a computer a list of diseases, each disease associated with a list of symptoms, and each symptom associated with a list of questions; repetitively asking questions to elicit responses, the responses establishing symptoms, each established symptom contributing a weight to a disease; and determining whether the accumulated weights for a disease reach or pass a threshold so as to declare a diagnosis.
  • the medical advice system also includes a geographic-based list of differential diagnoses in the population in which the patient resides, which, when processed by the list-based processor, is turned into a patient specific differential diagnosis.
  • the system also includes a table in which the frequency of the diseases is kept to allow the system to evaluate the patient using the probabilities or incidence of diseases in the population in which the patient resides.
  • the system may also give patient specific and context sensitive recommendation(s) for the laboratory test(s) of choice and the imaging modality of choice to further help define a diagnosis.
  • the system may invoke a "re-enter” function to allow for the laboratory test(s) of choice and the imaging modality of choice to be performed and then the results to be conveyed to the patient, the patient's health care giver(s) and/or any other desired entity.
  • the system may invoke the "re-enter” function to allow a patient to perform physical examination maneuvers (on self or via an assistant) and re* consult the system to further refine the diagnosis.
  • FIG. 1 is a block diagram illustrating components of a presently preferred embodiment of the computerized medical diagnostic and treatment advice (MDATA) system of the present invention
  • Figure 1b is a block diagram illustrating components of the user/patient computer of the MDATA system shown on Figure la;
  • Figure 2 is a block diagram illustrating a set of processes, files, and databases utilized by the system of Figure l a;
  • Figure 3a is a diagram of an off line medical diagnosis script (MDS) generation process used in producing a script file for the MDS database shown in Figure 2;
  • Figure 3b is a diagram illustrating a possible hierarchy of the DSQ lists for a script at two different time intervals;
  • MDS off line medical diagnosis script
  • Figure 4a is a flow diagram of an assign diseases portion of the "collect and organize medical knowledge" process shown in Figure 3a;
  • Figure 4b is a flow diagram of a capture disease knowledge portion of the "collect and organize medical knowledge process" shown in Figure 3a;
  • FIG. 5 is a flow diagram of the "script compiler” process shown in Figure 3a;
  • Figure 6a is a block diagram showing a configuration used during operation of the diagnostic script engine
  • Figure 6b is a block diagram showing a set of structures and inputs used during operation of the script engine and the outputs produced by the MDATA system
  • Figure 7 is a top-level flow diagram of a user process for the MDATA system of Figure 1;
  • Figure 8a is a flow diagram of the "diagnostic script engine” process used in performing the on-line interview process shown in Figure 7;
  • Figure 8b is a flow diagram of the "distribute advice” process shown in Figure 8a;
  • Figure 9 is a flow diagram of portions of the "DSQ list script engine” process shown in Figure 8a for list-based processing;
  • Figure 10 is a block diagram showing a portion of the lists utilized during operation of the DSQ list script engine shown in Figure 8a;
  • Figure 11 is another flow diagram of the "DSQ list script engine” process shown in Figure 8a;
  • Figure 12 is a flow diagram of the "select symptom” (select symptom to be considered) process identified in Figure 11;
  • Figure 13 is a flow diagram of the "handle response" (process response from the user) process identified in Figure 11;
  • Figure 14 is a flow diagram of the "update disease lists" (update scores in disease temp list based on updated symptom list and eliminate diseases ruled-in or ruled-out) process identified in Figure 11; and
  • Figure 15 is a high-level flow diagram of an alternative embodiment for generating medical advice or a diagnosis in the MDATA system of Figure la. Detailed Description of the Preferred Embodiment
  • a Medical Diagnostic and Treatment Advice (MDATA) system is a computer system that conducts automated interviews of patients for the purpose of establishing a medical diagnosis. To conduct the interviews, MDATA uses a database of Medical Diagnostic Scripts (MDS). Each MDS contains the data and commands needed to interview a patient for a specific medical condition and to output a diagnosis. Scripts are supported by other MDATA databases of diseases, symptoms, treatments, medications, specialists - • in short, all information required for medical diagnosis and advice. Symptoms can be defined as a piece of historical information, a piece of information elicited from a physical examination, e.g., physical signs usually from a self-examination, the results of a laboratory test, or the results of an imaging modality of choice.
  • the MDATA system 100 includes a network "cloud" 102, which may represent a local area network (LAN), a wide area network (WAN), the Internet, or another connection service.
  • LAN local area network
  • WAN wide area network
  • Internet the Internet
  • the MDATA programs and databases preferably reside on a group of servers 108 that are preferably interconnected by a LAN 106 and a gateway 104 to the network 102.
  • the MDATA programs and databases reside on a single server 110 that utilizes network interface hardware and software 112.
  • the MDATA servers 108/110 store the disease/symptom/question (DSQ) lists described hereinbelow.
  • the network 102 may connect to a user computer 116, for example, by use of a modem or by use of a network interface card.
  • a user 114 at computer 116 may utilize a browser 120 to remotely access the MDATA programs using a keyboard and/or pointing device and a visual display, such as monitor 18. Alternatively, the browser 120 is not utilized when the MDATA programs are executed in a local mode on computer 116.
  • a video camera 122 may be optionally connected to the computer 116 to provide visual input, such as visual symptoms.
  • MDATA servers 108/110 may be used to communicate with various other devices. If the servers are equipped with voice recognition or DTMF hardware, the user can communicate with the MDATA program by use of a telephone 124. A telephonic embodiment is described in Applicant's copending application entitled "Computerized Medical Diagnostic and Treatment Advice System," U.S. Serial No. 08/176,041, which is hereby incorporated by reference.
  • Other connection devices for communicating with the MDATA servers 108/110 include a portable personal computer with a modem or wireless connection interface, a cable interface device 128 connected to a visual display 130, or a satellite dish 132 connected to a satellite receiver 134 and a television 136. Other ways of allowing communication between the user 114 and the MDATA servers 108/110 are envisioned.
  • a diagram of a presently preferred user/patient computer shows several possible interconnections to the network.
  • a Script Engine is used, which reads a MDS file and uses its codes to perform interview actions, such as outputting a question to a patient and inputting an answer.
  • the scripts also collect the answers from the patient, evaluate the answers, issue a diagnosis, and update the patient's medical record.
  • the script engine preferably resides in the user computer.
  • the script engine may be stored on the hard drive or CD-ROM, and is loaded into the main memory or a cache for execution.
  • the components of a presently preferred computer 116, utilized by a user 114 of the computerized MDATA system 100 of the present invention, are shown in Figure 1b.
  • the computer 102 includes a plurality of components within an enclosure 116.
  • a telephone line 106 interfaces the public telephone network 158 to the computer 116 via a modem 160.
  • the telephone network 158 may connect to the network 102, which has connections with the MDATA system server(s) 108/110.
  • the user may connect to the network 102 by use of a network interface card 164.
  • the words user and patient are used interchangeably. However, it will be understood that the user may be acting as a proxy for the patient. If this is the case, the user is registered as an assistant for the patient.
  • the hardware and system software are assembled with two basic concepts in mind: portability to other operating systems and the use of industry standard components. In this way, the system can be more flexible and will allow free market competition to continually improve the product, while, at the same time, decreasing costs. While specific hardware and software may be referenced, it will be understood that a panoply of different components could be used in the present system.
  • the computer 116 preferably is a personal computer with an Intel Pentium microprocessor 170.
  • Other computers such as an Apple Macintosh, an Amiga, a Digital Equipment Corporation VAX, or an IBM mainframe, could also be utilized.
  • the modem 160 or the network interface card 164 connect to an industry standard architecture (ISA) or a peripheral component interconnect (PCI) bus 162.
  • ISA industry standard architecture
  • PCI peripheral component interconnect
  • the bus 162 interconnects the microprocessor 170 with a plurality of peripherals through controller circuits (chips or boards).
  • the computer bus 162 has a plurality of peripherals connected to it through adapters or controllers.
  • a video adapter board 172 preferably at SVGA or better resolution, interconnects to a video monitor 118.
  • a serial communication circuit 176 interfaces with a pointing device, such as a mouse 178.
  • a parallel communication circuit may be used in place of circuit 176 in another embodiment.
  • a keyboard controller circuit 180 interfaces with a keyboard
  • a 500 Mb or greater hard disk drive 184 and an optional CD-ROM drive 186 are preferably attached to the bus
  • the hard disk 184 stores database files such as the patient files, other MDATA files, and binary support files.
  • the CD-ROM drive 186 also stores database files, such as files for the patients using the computer 116, and binary support files.
  • a main memory 190 connects to the microprocessor 170.
  • the computer In the presently preferred embodiment, the computer
  • the 116 preferably operates under the Windows 95 operating system 192.
  • the memory 190 executes a diagnostic script engine 194 and a disease/symptom/question (DSQ) list script engine 196.
  • the script engine software is written in
  • Borland Delphi Pascal version II. Referring to Figure 2, a set of processes, files, and databases utilized by the MDATA system 100 will be described. Except for the script engine process, the MDS database, the Imaging Modality database, and the Laboratory
  • a set of patient login processes 210 is used by the system 100 to identify a patient who has previously registered into the system in one of three ways: 1) by prompting for a patient identification number (PIN); 2) identify an assistant who has previously registered into the system by prompting for an assistant identification number (AIN); 3) identify a patient, having an assistant, who has previously registered into the system by prompting for the patient identification number.
  • a set of processes 212 are used to register a patient or assistant. If the user is the patient, a patient registration process is used by the system to register new or first-time patients. If the user is not the patient, an assistant registration process 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 is used by the system to register the patient.
  • the system provides a choice of processes.
  • the primary process of concern in the current embodiment is the Diagnostic process 220 that performs a patient diagnosis.
  • the evaluation process 220 accesses a laboratory test of choice and imaging modality of choice database to recommend the appropriate tests in this patient at this point in time and a treatment table 250 to obtain current treatment information for a particular disease or diagnosis.
  • other choices are added to access other medical information processes.
  • a patient and assistant enrollment database 240 Associated with these processes are a patient and assistant enrollment database 240, a consultation history database 242, a patient response database 244, a medical history objects database 246, a patient medication database 248, a pending database 252, a patient medical history database 254, a medical diagnostic scripts (MDS) database 256, an imaging modality database 258, and a laboratory test database 260.
  • a consultation history database 242 Associated with these processes are a consultation history database 242, a patient response database 244, a medical history objects database 246, a patient medication database 248, a pending database 252, a patient medical history database 254, a medical diagnostic scripts (MDS) database 256, an imaging modality database 258, and a laboratory test database 260.
  • MDS medical diagnostic scripts
  • a Medical Diagnostic Script is a programmed dialogue with a patient for the purpose of generating one or more diagnoses of the patient's condition.
  • Developing an MDS involves several steps such as capturing the medical diagnostic knowledge, expressing it in terms that a patient can understand, arranging it into a useful sequence, compiling it into a playable script, testing it, configuring it for a specific communication medium, embedding it into a collection of other scripts and support databases, and packaging it for use by the patient.
  • Writing a script is considered to mean the early steps of capturing the medical knowledge and processing it into a logical question stream that ultimately leads to a diagnostic conclusion. Obviously, only a physician experienced in diagnosing a specific set of diseases can perform these steps, and the MDATA system has developed several automated methods to support them.
  • the invention preferably utilizes one particular method, called "list-based processing," which begins with lists of diseases, symptoms, and questions. These lists are then processed into a playable script using a list-Jbased script development tool. Using the script development tool, the author can write and edit the source script, compile it into a playable script file, play the script back, and set various script options to exercise, evaluate, and fine-tune the script.
  • list-based processing begins with lists of diseases, symptoms, and questions. These lists are then processed into a playable script using a list-Jbased script development tool.
  • the author can write and edit the source script, compile it into a playable script file, play the script back, and set various script options to exercise, evaluate, and fine-tune the script.
  • a list-based script consists of a specially formatted text file in which the author provides the elements of the script in the form of several lists.
  • the top list is a list of diseases which the script will consider.
  • the script lists the symptoms and their weights.
  • the author provides a list of questions and their weights that will elicit the symptom.
  • the author provides multiple text objects, including a preamble text that introduces the question.
  • the next step is to "compile" the script, i.e. to convert it into a specially encoded script file that can be played back, or "run," for a patient.
  • the script development tool selects a suitable next disease and a suitable next symptom for that disease. It displays the question text and waits for a reply from the patient. Based on the patient's response, the script development tool updates the disease scores and continues with the next symptom. The script stops when some condition (set by the author) is reached, such as the first disease being ruled in as a diagnosis, or all diseases having been considered.
  • the script author can set various "options” that will change the way the script selects the next disease and the next symptom, and how long the script will run. This option feature lets the author experiment with the script to find the best settings.
  • the three main phases of a script therefore, are: 1) knowledge capture, 2) script generation and 3) script execution.
  • the script author utilizes all three phases in the creation and testing of a script.
  • a patient utilizes the script execution phase during run-time use of the MDATA system 100.
  • the knowledge capture phase includes all of the tasks needed to extract from a medical expert the knowledge about diagnosing a given disease and reducing that knowledge to some form useful in generating a script.
  • the phase typically begins with a director of script development expressing a need for a script for diagnosing a disease such as Malaria. It continues with tasks such as defining the scope of the script, researching medical texts, interviewing authors and other experts, formatting the question and response sets, establishing the question sequence, and, if an automated knowledge capturing tool is used, running the question flow in a test setting.
  • This phase ends with a set of source documents, possibly automated, that (at least) contains all of the information needed to write a script that can correctly diagnose the disease, e.g., Malaria/Not Malaria when it is fed test responses for a patient that does/not have Malaria.
  • a script that can correctly diagnose the disease, e.g., Malaria/Not Malaria when it is fed test responses for a patient that does/not have Malaria.
  • Nothing is known at this point about the ultimate form of the script, the platform on which it will run, or even the natural language it will be using to communicate with the patient.
  • the script is generated as a relatively small diagnostic algorithm captured in software.
  • the goal is to let the script be an automated representation of the author's approach to diagnosing a disease or other medical problem, such as Malaria.
  • the script contains data and processes to produce a good first question, to weigh the response, to use the response to generate another question, and so on until the script can finally tell its caller that the responses indicate Malaria or Not Malaria, and the associated level of confidence.
  • a script is not a stand alone program that can be run for a real patient.
  • the script preferably only knows about a single chief complaint, such as Malaria, and does not diagnose other medical problems such as Gout or Asthma.
  • This script is destined to become one of approximately 40,000 scripts in the Script Database, in much different form and format.
  • the script now has to be translated into the appropriate human language (German, Spanish), supplemented with appropriate error handling mechanisms, generated into the appropriate programming language (C+ +,
  • Java HyperText Markup Language
  • HTML HyperText Markup Language
  • the script undergoes extensive testing in a testbed that feeds the script various canned sets of patient responses, with known acceptable diagnoses, to verify that the script does generate the appropriate output.
  • the script is ready to be installed into a production system. It may be stored into a massive Script Database, or packaged into a set of scripts to be written to a CD ROM or shipped via the Internet to a hospital. Whatever the form of the script library used, the script will have to be indexed and registered will be with the Script Manager software. At the end of this phase, the script is at last part of an official, running medical diagnostic system that can be used on real patients for real diagnoses of real problems. 3. Script Execution
  • the script In the script execution phase, the script is actually executed, sooner or later.
  • a session with a patient does not start with a diagnostic script on Malaria.
  • a medical diagnostic system open to the general public obviously has a number of administrative tasks to perform before it gets down to any medical diagnosis.
  • the ER subsystem consists of a few dozen scripts that determine whether the patient has any life threatening condition that needs immediate "first aid" therapy or advice.
  • Scripts are not programs that run themselves. Scripts are data streams that are run by a "script engine” that searches the script for the next question to ask of the patient, and formats the question for transmission (to a screen, a telephone line, or an Internet site). The patient responses are also captured by the script engine, formatted for the script, and used to select the next question from the script. This interplay of the script and its script engine may consider the patient's medical record, the information provided so far during this session, and even some meta functions to determine the next question.
  • the process returns control to the Tropical Disease Routing Script and says, in effect, "this patient's responses indicate Malaria Falciparum with a weight of 1350 out of 1000," or "this patient's responses only add up to 420 out of 1000, so I rule out Malaria.”
  • the Routing script that called the Malaria script in the first place may now decide to access another diagnostic script, or may decide to return to its caller some response such as "the patient's responses indicate only a 275 / 1000 likelihood of having any tropical disease.”
  • SCRIPT FEATURES Time-Based Diagnostic Scripts The Time-Based Diagnostic Script concept extends the DSQ diagnostic scripts in the time dimension.
  • the script author now submits several scripts, e.g., one for each hour into the disease process. Scripts are generated at an elapsed time from the beginning of symptoms, according to the best judgment of the author. For example, a myocardiaf infarction script would use one hour or less as an interval, while malaria would not.
  • the diagnostic system uses the diagnostic script closest to the patient's case. The script has implied symptoms that add extra weight to diseases that match the predicted pattern.
  • the system asks the patient when the symptoms started, and, partially based on that information, selects the appropriate script from the time-based set of scripts. Once the right script is selected, the script is executed. That is, each script of a set of time-based scripts may have somewhat different symptoms and weights, so that the author sets up time-based symptoms with extra weights for those diseases whose time-pattern matches the patient's. These weights are automatically added by the script engine as it runs. Note that these time-based symptoms will be Implied Symptoms, described hereinbelow.
  • Implied Symptom is a symptom that is established based on the presence or absence of one or more other symptoms.
  • the Implied Symptom concepts allows the script author to tell the script engine that any given symptom (or set of symptoms) implies or denies one or more other symptoms. This lets the author embody real- world relationships into the List-Based script, which, in turn, lets the LB Engine make logical inferences that eliminate superfluous questions from the list and make the script more focused.
  • a patient who is a man does not have to be asked questions related to the female reproductive system. A human doctor knows this implicitly, but the script engine needs to be told.
  • the script author simply makes a list of symptoms in the form:
  • Implied Symptoms are listed in the source script as a table of "IF A THEN B" type statements. Whenever the engine receives a new symptom from the patient, it also checks the Implied Symptom table to see if any other symptoms are implied. Synergistic Symptoms
  • Synergistic Symptoms are symptoms that indicate that, in any given patient, a certain set of other symptoms is present that have special diagnostic significance when they occur together.
  • each symptom has a certain specific weight toward diagnosing a disease, but the presence of a certain set may lend extra weight toward a diagnosis.
  • Malaria is classically diagnosed starting with the presence of Chills, Fever, and Sweating (which are caused as the Malaria-causing agent goes through its reproductive cycle in the blood).
  • the presence of Chills or Fever or Sweating separately would probably not necessarily suggest pursuing Malaria as a diagnosis in a patient, but the assertion of all three of these symptoms should trigger an inquiry about Malaria.
  • the concept of Synergistic Symptoms supports this internal trigger with a statement such as:
  • Synergistic Symptoms also have an important use in defining a Syndrome, i.e., particular collections of symptoms that occur together so often that, to the lay public, they have their own name, such as AIDS.
  • the script author can use Synergistic Symptoms to define a Syndrome that is important to him/her.
  • the initial task of knowledge capture for a script is identifying the diseases to be included in the script, assigning a priority to each disease, and assigning medical specialists to develop the portions of the script for their assigned diseases. Each medical specialist then generates the appropriate lists needed for the diseases. This can be summarized as follows: define the scope of diseases to be covered; list the diseases and their symptoms- assign rankings, priorities, and weights to diseases and symptoms; design properly worded and weighted questions that will elicit the symptoms; format the disease, symptom, and question fists; pre-test the lists, using test tools specially developed for the purpose; and write the lists as text files, using any ASCII-capable word processor.
  • the list-based processing method begins with a set of coordinated lists that captures the elements of diagnosing a particular health problem.
  • medical experts record their diagnostic skills and techniques in the form of several lists.
  • the experts preferably can use any commercially available word processor software that is capable of generating an ASCII output file.
  • the ASCII lists for a script consist of three types of lists that are nested as follows: • one Disease List that identifies all the diseases the script will consider, and ranks them in the order they should be considered for diagnosis;
  • medical diagnosis data is organized into a hierarchical classification that is based on the general concept that diseases have symptoms, and symptoms are elicited from the patient by questions.
  • a "disease” is a health condition that requires treatment or attention such as illness, ailment, affliction, condition, state, problem, obstruction, malfunction, and so forth.
  • the MDATA system To diagnose a patient with a given complaint, the MDATA system begins with a list of possible diseases that exhibit the complaint and reduces this to a list of diagnoses, based on the patient's answers.
  • a "symptom” is any information that the MDATA system has about the patient. This includes:
  • patient identification e.g., name, address, HMO, age, sex
  • patient history e.g., prior illnesses, parental health information, recent travel to foreign countries
  • a list of symptoms is prepared. Each symptom is assigned a weight, which represents a likelihood that the patient has the disease, given the symptom.
  • the MDATA system uses a ruled-in threshold value of 1,000 to declare a disease as diagnosed, although other thresholds may be used. The system also utilizes a ruled-out threshold to officially declare that the patient does not have the disease. Both the ruled-in threshold and the ruled-out threshold may be modified by a sensitivity factor set. This permits customized threshold levels, for example, for individual patients. The sensitivity factor set will be further discussed hereinbelow.
  • the weight is a measure of the diagnosing physician's willingness to rule the disease in, given the symptom.
  • the weight can also be used as a Conditional Probability that the patient has the disease, given the symptom. This can be used, if convenient, to apply a Bayesian Probability analysis to the symptoms.
  • a symptom is elicited by a set of one or more questions, often interlaced with information and instructions on how to answer the question.
  • the set of nodes needed to elicit a symptom is called a "flow" because it typically involves a branching flow of questions, often drawn on a small flowchart, that describes how a dialogue with the patient might proceed.
  • a text file is used and a text file format was developed.
  • the ASCII character code is preferably utilized, but any well-defined text-character code, such as EBCDIC, could be used.
  • a script consists of several segments or data groups as follows:
  • the Header section contains data that applies to the entire script, such as script format, and the set of symptoms comprising the patient's chief complaint.
  • the Diseases section lists the diseases that can be diagnosed by this script, their symptoms, and the symptoms' weight toward a diagnosis.
  • the script development tool selects one of the diseases to consider next, and then selects one of that disease's symptoms to be considered next. Which disease and symptom is selected next depends on the Run Options that are selected by the author. The default sequence is the order in which the diseases and their symptoms are listed in this section.
  • DISEASE AME The disease name is a unique label for a disease, used to identify the disease. It is only used internally and will never be seen by the patient.
  • a symptom that is part of the diagnostic picture or "fingerprint" of the disease.
  • the symptom is defined in detail in the Symptoms Section.
  • a "symptom" is a specific, detailed fact about the patient that has been assumed, asserted, elicited, or inferred.
  • the author is free to define any data item(s) as a symptom. If it is useful to the author, symptoms may include non-medical facts such as name, rank, and serial number of the patient.
  • the intent here is to give the author freedom to express his/her medical experience by defining elementary symptoms and grouping them in any convenient way.
  • a symptom an author may imagine a set of weighted questions that would uniquely assert or deny the symptom. If this is no problem, the author defines the symptom (in the Symptom Section) in terms of its questions and answers. If the symptom turns out to be too complex, the author may break the symptom into parts, treat each part as a symptom, and ask questions about the part, The author may let the patient establish each part separately, and then use the inference mechanism of the Inference Section to establish the main symptom. SYMPTOM WEIGHT The amount that this symptom adds to the disease's total score. Technically, the amount can be any number . from -10,000 to + 10,000; realistically it tends to be a small positive integer.
  • the script engine treats weights as a way to "score" a disease.
  • the script engine adds the weight of the symptom to the total score of the disease.
  • the script engine rules the disease "in.” Simple arithmetic addition of weights may not express the specific way a symptom contributes or "indicates” the presence of disease.
  • One solution for the author is to make a first guess of the weights, run the script, observe how the disease scores change with each question and answer, and then go back to "rebalance" the symptoms.
  • a “synergistic symptoms” technique may be useful to the author in developing a strategy for the weights.
  • Symptom C has no associated questions; it is an internal "ghost" symptom that can be used only to add or subtract weights based on the presence or absence of other symptoms.
  • the Symptoms section lists and describes all of the symptoms mentioned in other parts of the script. For each symptom, this section identifies the Flow of questions used to elicit the symptom.
  • SYMPTOM AME The symptom name is a unique label for a symptom, and is used to identify the symptom in other parts of the script. The name is only used internally, and will never be seen by the patient.
  • flow is used to describe a specific set of weighted questions, asked in a specified sequence that can be drawn as a flowchart. Thus, a flow represents a single group of questions. Since one flow can elicit one of several symptoms, several symptoms will typically specify the same question flow to be used. Some symptoms ⁇ e.g., chief complaint symptoms) have no associated question flow. implications Section
  • the Implications section lists the logical inferences among symptoms, so that the script engine knows which symptoms imply other symptoms.
  • Each line of the section specifies one or more symptoms that together imply another symptom. That is, each line gives the parameters for a logic formula of the form: if symptom A and symptom B and symptom C then symptom D.
  • Symptom implications can be chained, so that one implied symptom can imply another symptom, alone or in conjunction with others.
  • This section could be to establish "syndrome” symptoms, so that a specific set of symptoms in a patient would automatically assert a single, collective symptom.
  • This combination symptom could also be used to add (or subtract) extra weight if a specific set of symptoms is present, i.e., to allow for the "synergy" of several symptoms present in the patient at the same time.
  • the Flows Section lists all flows in the script, and defines the sequence of questions and the symptoms that can be elicited by the flow.
  • a "flow” is short for "a question flowchart". It can be thought of as a complex question that will establish one of several symptoms. Readers familiar with branch-based scripts will recognize that the flow can serve to contain or call an entire branch-based script that returns one of several response codes. It is quite common that one needs to ask a patient several questions to elicit one specific symptom from the patient. For example, some preliminary questions (“Have you ever smoked?") may be needed to set the stage, followed by quite specific questions (“What is the total time, in years, that you smoked?) to define the patient's symptom precisely.
  • One entire flow may contain 20 questions about smoking and may elicit one of several symptoms such as: has never smoked; is a casual smoker; has smoked 20-pack years and still smokes; and smoked 10-pack years, then quit 10 years ago.
  • Every node in a flowchart is encoded according to the path from node one of the flow taken to get to the node. These paths are used to identify what action should be taken at each node.
  • Questions Section defines the details of the questions mentioned by name in the Flows section. The details include the Preamble, the actual Question, the keys that can be pressed by the patient (on a telephone keypad), and (for graphic interfaces) the button label to be used for each answer.
  • the Preamble is the text spoken or displayed to the patient before the question itself is asked. It may continue after a previous question, introduce a new subject, define some terms, and inform the patient why a question is about to be asked, and how to answer it. Only the name of the text is given here; the actual text is given in the Texts Section. If there is no preamble for a question, this is indicated with the digit zero as a place holder.
  • the Question text is the actual question. Whereas the preamble may be 10 or 100 lines long, the question is typically short, to the point, and calls for a very specific answer that can be indicated by pressing or clicking one of the keys. Only the name of the question text is given here; the actual text is given in the Texts Section. VAUDKEYS
  • a set of Valid Keys tells the script engine which keys the patient can press or click.
  • KEY1 ... KEYN These are key labels, used only in graphic display versions of the script. They tell the engine how to label each button, for example YES, NO, and NOT SURE. Texts Section
  • the Texts section lists the actual text of all text items referenced by name in other sections, such as Preambles, Key Labels, and Question Texts. By giving each text a unique name, and listing the text in the Texts section, the author can use the same text in several places.
  • Having all of the text that is intended for the patient in one place also simplifies automated processing of the script, such as recording the text for use in a telephone network or formatting the text for display on a screen.
  • a script could be translated into a foreign language, by replacing its Texts section text with the equivalent text in another
  • Process 284 has two portions. A first portion is typically performed by a script coordinator or supervising author for assigning diseases, and a second portion for capturing the disease knowledge for each disease in the script. The portion for capturing the disease knowledge is typically performed by a plurality of medical experts in their respective fields.
  • the assigned diseases portion of process 284 will be further described in conjunction with Figure 4a, and the captured disease knowledge portion of process 284 will be further described in conjunction with Figure 4b.
  • the output of process 284 is electronic text, such as an ASCII file. This electronic text is in the form of DSQ lists such as disease, symptom, and question lists 286.
  • the Appendix includes an exemplary script for malaria.
  • the script is one representation of a DSQ list.
  • FIG. 3b A graphical example of time-based DSQ lists for a script is shown in Figure 3b.
  • An exemplary script 320 for a time T, and a script 322 for a time T 2 are shown.
  • Each of these two scripts includes a list of diseases 324, a list of symptoms 326, and a list of questions 328.
  • This figure is intended to show the hierarchy of the disease, symptoms and question list, and is only exemplary. Note that a disease may refer to symptoms that are defined in other diseases, and a symptom may refer to questions that are defined in other symptoms. Thus, symptoms and their associated questions can be reused by the various medical authors.
  • process 280 moves to state 290, which takes the DSQ lists in electronic text format and processes them by use of a script data development tool.
  • a script compiler 292 works closely with the script data development tool to generate an MDS file.
  • the process 280 may utilize the script data development tool and the script compiler in an iterative fashion to generate a final MDS file.
  • the MDS file is written to an MDS database 300 by an MDS database manager utility 298.
  • the MDS file 296 is preferably in a binary format.
  • the MDS preferably includes a header data section, a master disease list section, a master system list section, a master flows section, a master question list section, and a master text list section.
  • the medical authors may write the scripts in a medical authoring language or as nodes and branches, as shown at state 302.
  • Other script tools which may include compilers, are shown at state 304 to generate an MDS 296.
  • the assign diseases process 350 of the collect and organize medical knowledge process 284 will now be described. Process 350 will typically be performed by a script coordinator, although other medical professionals utilized by the MDATA system may perform these tasks.
  • Process 350 preferably is not performed by a computer but by the script coordinator, who may utilize the computer to assist in the completion of the following steps. Beginning at a start state 352, process 350 moves to a state 354, wherein the chief complaint associated with the current script is defined.
  • the chief complaint includes the symptoms that a patient might initially provide to the system when describing the main problem that they are consulting for. Proceeding to state 356, the script coordinator determines a list of the diseases that are to be diagnosed by the current script. These diseases should provide a diagnosis of the chief complaint. Included in the list are the disease name, a descriptor, and an International Classification of Diseases (ICD-9) code for the disease.
  • ICD-9 International Classification of Diseases
  • the diseases are then ranked by probability of occurrence in the general population that the patient is in, e.g., country or region of a country.
  • the script coordinator assigns priorities to the diseases based on urgency and/or seriousness of the disease. Based on the assigned priorities, the script engine may be directed to check first the diseases that have an urgent or serious indication assigned to them.
  • the script coordinator partitions or assigns the diseases for the current script to one or more medical specialists for further development.
  • a computer network such as the Internet, and a DSQ lists database
  • multiple scripts can be developed in parallel. The disease authors can work in parallel by making questions and instructions available to all the other authors via the database and the network.
  • Process 350 ends at an end state 364.
  • Process 380 is also not typically performed by a computer, but is performed by a medical specialist or expert who may employ the use of a computer to actually capture the disease knowledge for a particular disease.
  • the following steps are performed by the disease specialist, as assigned by the script coordinator at state 362 in Figure 4a. Beginning at a start state 382, process 380 moves to a decision state 384, wherein the medical specialist determines if the script is best captured as a time-based script.
  • process 380 moves to state 386, wherein the time interval between scripts in the script family is determined. For example, the script author may decide to generate a script for every two hours for a 48-hour time period.
  • process 380 continues at state 388, wherein the medical specialist identifies a ruling-in threshold score and a ruling-out threshold score for each disease that is assigned to him or her.
  • the medical specialist identifies a set of relevant symptoms for each disease assigned to them.
  • the symptom list includes the symptom name, a descriptor, and at least one weight as described hereinbelow.
  • the medical specialist identifies any relevant post- response relationships and symptoms identified by these relationships.
  • the post-response relationships may include simultaneous or synergistic relationships where two or more symptoms occurring together may have more weight toward diagnosing a disease than the sum of the weights for the symptoms occurring separately.
  • a sequential relationship is where the symptoms occur one after the other, which may produce more weight toward diagnosing a disease then the sum of the weights of the individual symptoms occurring separately.
  • Implied relationships are wherein the presence of one symptom implies the presence of another symptom.
  • the medical author may also define relationships over time for the asserted symptoms and further post-response processed symptoms.
  • the post-response relationships may also involve symptom clarification processing, PQRST array analysis, or a symptom severity clarification.
  • the PQRST array is an N-dimensional array with different attributes or aspects of the symptom of pain assigned to one dimension. For example, the PQRST array may have twenty-two dimensions.
  • the medical specialist assigns a weight for each disease symptom. For symptoms having an associated range, such as a severity of pain or other type of symptom severity, the medical specialist may assign a range of weights associated with the severity of the symptom. Symptom weights are accumulated into a score for each disease having the symptom. Weights can be either positive or negative, which contributes to the production of a positive or negative score.
  • the medical specialist defines a flow of question nodes to elicit or determine the symptom. Some symptoms can be determined by a single question, but most symptoms may require a number of questions to elicit the symptom.
  • weights are assigned to the possible responses of the questions at state 397.
  • this type of symptom may have a range of associated weights.
  • the medical specialist writes text objects for the question node so as to provide an introduction or an explanation, instructions, advice and the actual questions for the patient.
  • the instructions may define the range of values that are requested (an answer set) or other ways of formatting the expected responses.
  • the introductions and explanations are to help the patient understand what the question is about, why the question is being asked, and sets the stage for the possible responses.
  • the author For each symptom the author will compose a question flow that is used to elicit the symptom.
  • the question flow that the author uses may be another physician's question flow. For example, let's say the symptom is depression.
  • depression_question_1 The author may find and look at depression_question_flow_2. This question flow is much more elaborate. In this flow, to answer the question, "Are you depressed?", this doctor has devised a 10-point list of questions. The sub-questions may even be other questions in the database. In this question flow, the patient is asked ten questions. Each question is weighted differently and, after answering all of the questions, the score is totalled, and if it reaches a threshold defined by the question's author, then this physician will say that the patient has the symptom of depression.
  • an author wants to ask a question about nausea for migraine.
  • the author examines the question bank. The author may find fifty different questions on nausea. One question says, "Are you nauseated?". This question is not acceptable to the migraine author.
  • Another author has a question flow that contains ten weighted sub-questions. If their score reaches that author's pre-defined threshold, that doctor calls his patient nauseated.
  • the migraine author likes it almost as is, but wants to change one of the weights of one of the weighted sub-questions. In this situation, the migraine author saves the new question with the revised weight as nausea_question_n+ 1. Now when the migraine author uses the new version or another version of nausea, it will of course be weighted differently in defining different diseases.
  • a medical specialist determines at a decision state 400 if another time interval for a time-based script is required. If another interval is not required or if the present script is not a time-based script, process 380 ends at a return state 402. However, if another interval is required in a time- based script, process 380 moves back to 388 to rerun the set of steps 388 to 400 for another time interval in the script family.
  • list-based medical diagnosis data is stored as scripts. These files are the diagnostic interface between the human doctor and the patient being interviewed.
  • a MDS file "runs" by driving a script engine, which is a generic program that loads MDS files and runs the script based on the data and instructions encoded in the file. Diagnostic data are stored in the form of disease, symptom, question, and text node lists.
  • the contents of a list-oriented MDS file mirrors the contents of the ASCII list file.
  • the major difference between them is that the text file data is stored as segments of text lines of character strings, whereas the MDS file data is packed into lists of binary integers.
  • a second difference is that the MDS file data is arranged and cross- referenced to support on-line access to the data.
  • the MDS file is preferably formatted as one very large array of 32-bit binary integers. This large array is then allocated into blocks of varying length that contain data. Since the location of a block in the file is itself a number, it can be used as a data item that connects one block to another block. Physically, these blocks are independent of any programming language or operating system and can be transported to any computer hardware that is capable of storing files of 32-bit numbers. Logically, these blocks can be nested and connected in arbitrary ways to form data structures such as linked lists, stacks, queues, trees, and networks.
  • the MDS file is formatted as several segment blocks called "master lists" as follows:
  • the ASCII list file is read and converted into a MDS file by the script compiler. This process consists of reading the ASCII text file line-by-line, compiling the appropriate segment of the corresponding MDS output file, and generating cross-reference lists to speed searches. Since some symbols may be used before they are defined, the conversion program must make two passes through the file. During the first pass, all lines are read in, converted into MDS file blocks, and their symbols are saved in a table. During the second pass, symbols are replaced by their actual block addresses. Of course, other methods of compilation may be used. The conversion program can, of course, perform any number of quality and consistency checks, such as detecting invalid formats, missing segments, duplicate symbols, unused symbols, typographical errors and so on.
  • the conversion program can let the script author make corrections in the ASCII list file and then rerun the conversion program again until it accepts the file. This editing cycle serves to catch fundamental source errors and typographical errors early.
  • the script author tests the script to determine whether it functions as intended.
  • the script author may, for example, adjust symptom/question weights, fine-tune words and phrases for the question nodes, and fix any logical and medical errors. The script author will then recompile and rerun the script until it runs as intended.
  • the script compiler 292 will now be described.
  • the DSQ lists that are in an electronic text format, such as ASCII, are collected by use of the script data development tool and then processed by the script compiler 292.
  • the script compiler processes the source script for completeness, consistency and uniformity. Syntax errors are identified at this state. After any problem areas are corrected, the compiler proceeds to state 424 and converts the script from the source format to the stored file format, which is a binary format.
  • the script compiler 292 augments the script for access to the various MDATA databases, shown in Figure 2, and the MDATA infrastructure or support system.
  • the script compiler completes at a return state 428.
  • V. Script Execution Details Overview When a patient accesses the MDATA system 100 for a diagnosis, the system manages the initial contact with the patient, identifies the patient, decides which service the patient needs, selects the correct MDS file, and starts up the script engine.
  • the script engine loads the MDS file and begins to obey its coded directions, one by one. The effect of obeying the coded directions is an interview with the patient. At the end of the interview, the script directs the engine to perform appropriate terminal actions (updating databases, closing files, logging the session) and ultimately returns computer control to the MDATA system 100.
  • the supporting operations required to access database files, output information to the patient, input the patient's responses, and print reports, is performed by the underlying operating system on which the script engine is running.
  • the run time mode of the List-Based Processing method generates a MDS file that is list-oriented. That means that, at each step, the disease, symptom, and question lists must be searched to determine the next question or action of the script.
  • the script engine has to do more work using the list-based method than a branch-based method.
  • the MOS file is, in essence, a medical encyclopedia of human diseases, stored in top-down order from a high- level list of diseases down to a single question that elicits one aspect of a symptom of one disease.
  • To run such a data structure as a script requires that the structure be "inverted," i.e., presented as a sequential question stream to the patient.
  • the script engine first searches the master disease list of the MDS file to select the next disease to be considered. Then the engine searches the list of symptoms of the selected disease to select the next symptom to ask about. Then the engine searches the question set for the selected symptom to select the next question to be asked.
  • the engine poses the question to the patient, obtains the answer, updates the various weighted lists, and repeats the process until it reaches a diagnosis or runs out of diseases.
  • the overall effect is to generate a diagnostic conversation between the script and the patient that concludes with a diagnosis.
  • the script maintains the patient's symptom set as a temporary dynamic list called a "temp" list. Every new symptom is recorded in this set, and is used to update the list of diseases being considered.
  • the patient's responses thus build a health profile that is used to select the next disease and symptom and question.
  • the profile serves a number of uses:
  • the script engine begins, it is given an on-line patient and a script (i.e., a MDS file).
  • the engine opens the MDS file to establish access to the coded lists of diseases, symptoms, and questions. It also opens the patient record to obtain the patient's medical history and the results of past sessions, if any, with the patient. From hereinforward, the MDS file drives the interview by directing the engine to a next interview step.
  • the script directs the engine to perform appropriate terminal actions (updating databases, closing files, logging the session) and ultimately returns computer control to the MDATA system.
  • the aspect of interest for this explanation of List-Based Processing is the algorithm used to question the patient and to build up a set of symptoms toward a diagnosis.
  • This algorithm consists of a main loop that analyzes and updates a set of patient symptoms until it reaches some condition that terminates the loop.
  • the main loop includes the following general steps:
  • the diagnostic script engine 190 interfaces with a MDATA support system 440 so as to get access to a plurality of databases 442 of the MDATA system and to have input and output capabilities with the various entities in the medical community.
  • the MDATA support system 440 includes the processes shown in Figure 2, including the login process 210, the registration process 212, and the diagnostic process 220.
  • the MDATA support system 440 utilizes the communication network 102, previously shown in Figures 1a and lb.
  • the databases 442 shown in Figure 6a include the databases previously shown in Figure 2 and also include other databases such as for human diseases, drugs and drug interactions, human anatomy, a regulatory ratchet table, and a geographic distribution of frequency of diseases.
  • the regulatory ratchet table is a table of regulatory and legal "rules" that let the system know how much information can be revealed to a patient.
  • a MDS 296 is selected from the MDS database 300.
  • the diagnostic script engine 190 is run on a patient's personal computer, local user data storage 184 may be accessed in place of the MDATA databases stored at a central location.
  • the MDS 296 is made available for the diagnostic script engine 190, which performs the patient interview.
  • the script engine 190 may write information received during the patient interview to either the central patient medical history database 254 or to the local user data storage 184.
  • medical diagnosis or advice 462 may be generated. This diagnosis or advice is preferably reported to the physician 464, output to the user 466 and stored in the central MDATA databases or the local user data storage 184. Other reports 468 may be generated as necessary. As will be described later, there are situations where the diagnosis may not be reported directly to the user, but may be sent instead to the physician for further reporting to the user at a later time.
  • Process 480 begins at a start state 481 and moves to state 482 to identify an emergency situation.
  • a set of initial "hard-coded" screening questions are utilized to identify the emergency situation. If an emergency situation is identified, appropriate advice, such as calling 911, is provided to the user.
  • State 482 and subsequent states 484, 486 and 488 are substantially described in Applicant's cope ⁇ ding application entitled "COMPUTERIZED MEDICAL DIAGNOSTIC AND TREATMENT ADVICE SYSTEM," U.S. Serial No. 08/176,041. If process 480 determines that there is no emergency situation, the process continues at state 484 and securely identifies the user.
  • the user may be the patient or an assistant for the patient. Passwords, identification numbers, voice prints or other types of identification methods may be utilized. If the patient has logged in properly, process 480 continues at a state 486 to perform any necessary administrative tasks. Proceeding to state 488, process 480 access the MDATA medical databases ( Figure 2) and the system files and software. Proceeding to process 490, an on-line interview with the user is conducted. The on-line interview preferably is performed by the diagnostic script engine process 490. However, other ways of performing the on-line interview may be utilized, such as running a program or executing a script. The user process 480 completes at an end state 492.
  • the script engine process 490 proceeds to state 494 to perform a script router function.
  • the script router selects an appropriate DSQ script based on input parameters such as: a patient's chief complaint symptoms, the time since the symptoms started, the patient's past medical history, results from any other scripts, or the results from the current script family from a prior time.
  • Identification of the patient's chief complaint is algorithmic.
  • the chief complaints can be categorized into the following classifications: an anatomic system involved, a cause of the patient's problem, e.g., trauma or infection, an alphabetic list of chief complaints, an ICD-9 number for their complaint, or a MDATA catalog number of their chief complaint.
  • process 490 continues at state 496 to retrieve the selected script from the script database 300 ( Figure 6b).
  • the diagnostic script engine process 490 invokes a DSQ list script engine 500 to utilize the DSQ lists in performing the interview with the patient.
  • the DSQ list script engine 500 will be further described in conjunction with Figures 9 and 11.
  • the diagnostic script engine process 490 post-processes the results of the DSQ script engine at state 502.
  • Various types of processing are performed at state 502, as exemplified by states 506 through 526 described hereinbelow.
  • One action that may be performed at state 502 includes determining a degree of certainty for diseases in the ruled-in disease list and in the ruled-out disease list. The degree of certainty for some or all the diagnoses in the ruled-in and ruled-out disease lists may be reported to the patient and/or physician. The diagnoses from the ruled-in and ruled-out disease lists and the associated degrees of certainty are compiled into a differential diagnosis list.
  • process 490 determines the degree of certainty for a diagnosis.
  • a degree of certainty look-up table or a sensitivity factor set Sensitivity factors were previously described in Applicant's issued patent, U.S. Patent No. 5,594,638, entitled "COMPUTERIZED MEDICAL DIAGNOSTIC SYSTEM INCLUDING RE-ENTER FUNCTION AND SENSITIVITY FACTORS.”
  • the next action performed by process 490 is dependent on the result type as determined at a decision state 504.
  • Various exemplary result types will now be described.
  • the diagnostic script engine process 490 refers the patient to another script, which is selected at state 494, as previously described.
  • process 490 generates appropriate medical diagnosis or advice.
  • the advice is distributed to the appropriate party. Function 510 will be further described in conjunction with Figure 8b. After the advice is distributed, process 490 ends at an end state 512.
  • process 490 performs a special meta analysis.
  • the diagnostic script engine studies how a specific symptom changes or grows over time in a given disease.
  • process 490 stores the results accumulated during the script into the patient's records.
  • process 490 forwards the patient to access a medical information library that is part of the MDATA system 100.
  • process 490 schedules a later continuation of a script that was adjourned temporarily. Typically, this occurs when a patient is not able to complete the entire script during a session.
  • the diagnostic script engine has the capability of providing a list of diseases that have the most weight in decreasing levels of probability to the patient.
  • process 490 could schedule a re-enter session to allow a length of time to pass and see if a diagnosis could be reached at a later time.
  • the re-enter feature is described in Applicant's copending application entitled "COMPUTERIZED MEDICAL DIAGNOSTIC AND TREATMENT ADVICE SYSTEM.”
  • process 490 requests the patient to have tests performed and to consult the system again. These tests may include self-exam maneuvers, imaging modality tests (258, Figure 2) or laboratory tests (260, Figure 2).
  • process 490 forwards any urgent results to a health care provider for immediate action.
  • Process 490 ends at the end state 512.
  • function 510 proceeds to state 512 wherein the results of the various lists are collated due to one or more diseases or diagnoses reaching threshold. Proceeding to state 515, function 510 checks the treatment table for the appropriate and current treatment for the diagnoses made by the system. Proceeding to state 517, function 510 determines who should be the recipient of the diagnosis or advice. This is partially accomplished by consulting a regulatory ratchet table 519. The regulatory ratchet table determines the type of information that can be told to the patient depending on various factors, such as what country the patient lives in.
  • the regulatory ratchet table 519 utilizes information available in the patient's record, such as the patient's zip code or telephone area code to identify their location.
  • process 500 begins at a start state 530, the process 500 proceeds to state 532 to access the selected DSQ list file passed to it by the diagnostic script engine. Proceeding to state 534, process 500 initializes the temp lists utilized by the script engine. Referring temporarily to Figure 10, process 500 initializes the symptom temp list 552 to be cleared and initializes the disease temp list 550 to have all of the diseases of the master disease list 324. At this point, process 500 selects one of the diseases to be processed and then selects a symptom to be asserted in the disease. To determine the presence or absence of the symptom in the patient, process 500 continues at state 536 to select the first question of the symptom to be asked of the patient.
  • process 500 asks the question of the patient.
  • process 500 receives the patient's response and checks for correctness of their response according to the asked question. The patient's response is used then to update the DSQ temp lists at state 542.
  • process 500 determines if a diagnosis or a terminus of the script has been reached. If it has not, process 500 proceeds to state 546 to select either the next question in the current symptom, or, if all the questions for the current symptom have been asked, to proceed to the next symptom for the current disease. If all the questions in the current disease have been asked, process 500 moves to the next disease and asks the questions necessary for that disease. Process 500 loops at states 538 through 546 until the end of the script is reached, a diagnosis is achieved, the user requests the script to be adjourned, or the script engine determines that the script should be terminated.
  • process 500 either returns the diagnosis at state 541, refers the patient to a different script at state 543, adjourns the current script at state 545, or terminates the current script at state 547.
  • Process 500 completes at a return state 548.
  • the script router 494 ( Figure 8a) of the diagnostic script engine 490 identifies a script to be passed to the DSQ list script engine 500.
  • the records of the current patient from the patient medical history 254 are also used by the script router 494.
  • the DSQ list script engine 500 accesses the master disease list 324.
  • the diseases in the master disease list are copied to a disease temp list 550.
  • symptoms from the master symptom list 326 of the current disease are selectively copied to the symptom temp list 552, as will be described in conjunction with Figure 12.
  • symptom weights and/or question weights for the symptoms will be added to the score for the current disease in the disease temp list 550.
  • the disease is moved to the ruled-in disease list 554.
  • the score for the current disease reaches the ruled-out disease threshold, the disease is moved to the ruled-out disease list 556.
  • the script engine process 500 proceeds to state 582, wherein the disease temp list 550 is initialized from the script master disease list 324 ( Figure 10).
  • the script engine process accesses patient data from current and/or previous patient sessions.
  • the script engine process 500 utilizes the MDATA support system 440 ( Figure 6a) and the databases 442 to get the patient data and any other data necessary. Alternatively, the patient data may be retrieved from the local user data storage 184 ( Figure 6b).
  • the script engine process 500 selects the disease to be considered.
  • Various methods may be utilized in selecting the order of the diseases to be considered. For example, the most urgent diseases may be considered first, followed by the serious diseases and then the common diseases. Alternatively, or in conjunction with the urgent/serious model, the first diseases to be considered may be the most prevalent in the population that the patient is in.
  • the script engine process may utilize the telephone number, postal zip code, or other sources of location information from the patient's history to identify the population group or location that the patient is in.
  • An alternative for selecting the disease order once the process has started is to use the disease with the highest total of symptom weights, i.e., the disease which is nearest to being diagnosed.
  • the script coordinator arranges the diseases for the current script in the order they are to be considered.
  • the script engine process 500 proceeds to the "select symptom to be considered" process 588.
  • Process 588 determines the symptoms to be considered for the current disease and will be further described in conjunction with Figure 12.
  • Script engine process 500 checks to see if a selected symptom null flag, which may be set during process 588, is asserted at decision state 590. If the selected symptom flag is null for the current disease, process 500 advances to a decision state 616 to determine if there are more diseases to consider. However, if the selected symptom flag is not null, script engine process 500 proceeds to state 592 to select the question flow to be presented to the patient.
  • a logic flow can be thought of as a "complex question," i.e., a question that consists of several questions and can produce one of several answers.
  • the question flow which contains, i.e., can generate as a response, the symptom which currently has the highest chance of ruling in the disease under consideration should be selected.
  • script engine process 500 executes the current flow node. Proceeding to state 596, script engine process 500 presents the question part of the flow node to the user. Every question preferably consists of a set of information text, instruction text, and a question. To present the question, the script first outputs the information text to the patient, then the instruction text, and finally the question text. The question text indicates to the patient that a response is expected at the present time.
  • the flow node preferably is one of three types: symptom, question, or program.
  • Script engine process 500 determines the flow node type at a decision state 600. If the node type is question or program, script engine process 500 moves to state 594 (question loop Q) to execute the next flow node. However, if the flow node type is of the symptom type, process 500 proceeds to state 602 to update the symptom temp list 552 ( Figure 10), based on the received response from the patient. Based on the response, a weight is assigned for the current symptom. Alternatively, if the current symptom utilizes multiple questions, some of which have associated weights, the weight (if present) for the current question is accumulated for the current symptom.
  • the DSQ script When the DSQ script has obtained a symptom, it updates all diseases that have the symptom. That is, a single answer from the patient can change the symptom weighing of all diseases being considered. This "promotes" one or more diseases to being closer to the diagnostic thresholds.
  • the script engine process 500 performs post-response processing to further update the symptom temp list 552.
  • Examples of post-response processing include if-then relationships, simultaneous relationships, sequencing relationships and other similar types of relationships. For example, if a symptom severity value is 9, then a weight of 75 might be added to the diagnosis of biliary colic, and a weight of 50 might be subtracted from the diagnosis of appendicitis. Other post-response relationships were previously discussed in conjunction with Figure 4b (capture disease knowledge). After the post-response processing has been completed, the script engine process 500 proceeds to the update disease lists process 606.
  • the script engine updates the scores in the disease temp lists based on the updated symptom temp list 552 and eliminates ruled-in or ruled-out diseases.
  • the update disease list process 606 will be further described in conjunction with Figure 14.
  • some diseases may be ruled in or ruled out, thereby reducing the length of the disease temp list 550 ( Figure 10).
  • the ruled-in threshold or the ruled-out threshold has not been reached, the disease is not removed from the disease temp list.
  • an updated disease temp list and an updated symptom temp list are left for the next iteration of checking symptoms for diseases.
  • the script engine process 500 determines if there are more symptoms in the symptom temp list 552 for the current disease. If so, the script engine process 500 selects the symptom with the largest weight, based on absolute value, associated with it at state 612 and then proceeds to state 592 (symptom loop S) to select the question flow for that new symptom. However, if there are no additional symptoms in the symptom temp list 552, as determined at decision state 610, the script engine process 500 proceeds to state 614 to delete the current disease from the disease temp list 550. Proceeding to the decision state 616, the script engine process 500 determines if the disease temp list 550 for the current script is empty.
  • the script engine process 500 moves to state 586 (disease loop D) to consider the next disease in the script. If the disease temp list 550 for the current script is empty, the script engine process 500 proceeds to a decision state 618 to determine the type of result of the script. At state 620, one of the possible results is that one or more diseases have been ruled in or have been ruled out. At state 622, another type of result is that the script engine has determined to reference another script or another service. The script engine process 500 completes at a return state 624 and returns to the diagnostic process 490 ( Figure 8a).
  • the select symptom process 588 Referring to Figure 12, the select symptom process 588, referenced in Figure 11, will now be described. Beginning at a start state 640, the select symptom process 588 proceeds to state 642 to clear the symptom temp list 552 ( Figure 10). Proceeding to state 644, the select symptom process 588 accesses the current disease in the script master disease list 324 ( Figure 10). Advancing to state 646, process 588 identifies the next symptom of the current disease. Continuing at a decision state 648, process 588 determines if the symptom's question flow has previously been executed for this patient. For example, the symptom may have been determined in another disease or even in another script for this patient.
  • process 588 proceeds to state 650 and adds the symptom to the symptom temp list. After adding the symptom to the symptom temp list, or if the symptom's question flow has been previously executed, process 588 moves to a decision state 652. At decision state 652, process 588 determines if there are more symptoms for the current disease. If so, process 588 moves back to state 646 to identify the next symptom of the current disease. If there are no more symptoms for the current disease, as determined at state 652, process 588 continues at a decision state 654 to determine if the symptom temp list 552 is empty. If it is, select symptom process 588 moves to state 656 to delete the current disease from the disease temp list 550.
  • the select symptom process 588 returns at state 658 will a null symptom flag.
  • decision state 654 if the select symptom process 588 determines that the symptom temp list is not empty, execution continues at state 660 wherein the symptom temp list is sorted by the absolute value of the weight. Proceeding to state 662, process 588 selects the symptom with the largest absolute value of the weight. The select symptom process 588 returns at state 664 to process 500 ( Figure 11) with the selected symptom. Referring to Figure 13, the handle response process 598, referenced in Figure 11, will now be described.
  • process 598 proceeds to state 692 to check the validity of a user response. Proceeding to a decision state 694, process 598 determines if the response is valid. If the response is not valid, process 598 proceeds to state 696 to repeat the output of the question text to the user and then moves back to state 692 to check the validity of the user response. A check for a time-out situation occurs during the handle response process 598. The time-out is evaluated to see if it could mean a possible loss of consciousness or a change in mental status. If so, a mental status subroutine could be invoked or emergency medical personnel may be called, for example.
  • process 598 proceeds to a decision state 698 to determine the type of node currently being processed by the DSQ script engine 500. If the node type is a symptom node, process 598 proceeds to state 700 to select the symptom value associated with the current flow node. A symptom node returns the symptom as the answer to the complex question. The symptom value is then returned at state 702 to the symptom script engine process 500 ( Figure 11). If the node type is a question node, process 598 proceeds to state 704 to convert the response to a path digit. Advancing to state 706, process 598 appends the path digit to the current flow node path name.
  • State 704 and 706 are used to identify the next question node to be executed.
  • process 598 proceeds to state 710.
  • process 598 executes the program indicated by the current node and gets a return digit.
  • process 598 appends the return digit to the current flow node path name.
  • state 710 and 712 are used to identify the next question node to be executed.
  • the program executed at state 710 may be a sub-script or other function or subroutine needed to elicit additional medical information from the patient.
  • process 598 returns at return state 708 to the DSQ script engine process 500 ( Figure 11). Referring to Figure 14, the update disease lists process 606, referred to in Figure 11, will now be described.
  • process 606 proceeds to state 732 to access the disease temp list 550 ( Figure 10). Continuing at a decision state 734, process 606 determines if there are more diseases in the disease temp list 550. If not, process 606 returns at a return state 736 to the DSQ script engine process 500 ( Figure 11). However, if there are more diseases in the temp list, process 606 proceeds to state 738 to access the next disease in the disease temp list 550. Proceeding to a decision state 740, process 606 determines if the current disease contains the symptom just answered by the patient or any of its post-response processed symptoms, such as determined at function 604 ( Figure 11).
  • process 606 moves to state 742 and adds the weight of the symptom just answered or the post-response process symptom to the score of the current disease. Proceeding to a decision state 744, process 606 determines if there are additional symptoms having weights that need to be added to the current disease score. This typically would happen if there are multiple post-response process symptoms. If so, process 606 moves back to state 742 to add the weight of these additional symptoms to the disease score. If there are no more symptoms that need to be processed, as determined at state 744, process 606 proceeds to a decision state 746. At decision state 746, process 606 determines if the disease score has reached or passed the ruled-in threshold.
  • the ruled-in threshold preferably has a value of 1,000, but other ruled-in threshold scores could be utilized. If so, process 606 proceeds to state 748 to add the current disease to the ruled-in disease list 554 ( Figure 10). Moving to state 750, process 606 deletes the current disease from the disease temp list 550 ( Figure 10) and then moves back to decision state 734 to determine if there are more diseases in the temp list 550. Returning to decision state 746, if the score has been determined to not reach or pass the ruled-in threshold, process 606 proceeds to a decision state 752. At decision state 752, process 606 determines if the disease score has passed or has reached the ruled-out threshold.
  • process 606 moves to state 754 to add the current disease to the ruled-out disease list 556 ( Figure 10). Advancing to state 750, process 606 deletes the disease from the disease temp list 550 and moves back to decision state 734 to check for additional diseases in the disease temp list 550. Returning to decision state 752, if the disease score is not less than or equal to the ruled-out threshold, process
  • process 606 moves back to decision state 734 to check for additional diseases in the temp list 550.
  • decision state 740 if the current disease does not contain the symptom just answered or any of its post-response processed symptoms, process 606 moves back to decision state 734 to check for additional diseases in the temp list 550.
  • the weight of a symptom can be given as a positive or negative number; two running scores are kept for each disease: one positive and one negative; positive weights are added to the positive score and negative weights to the negative score; weights are not subtracted; two threshold are used, a positive one (e.g. 1000 or 10000) to rule diseases in and a negative one (e.g.
  • the branch-based script process 780 proceeds to state 784 to open a branch-based medical diagnostic script file. Proceeding to state 786, process 780 sets up the patient data from either current and/or previous sessions with the patient. Script process 780 proceeds to state 788 and starts at a first question in the script. Advancing to state 790, script process 780 presents the current question to the user. Continuing at state 792, script process 780 waits for a valid user response. Moving to state 794, script process 780 records the user response. At state 796, script process 780 goes to the node corresponding with the user response.
  • script process 780 determines if the next node is an exit node. If not, process 780 continues at state 790 and presents the next question to the user. The script process 780 loops on states 790 through 798 according to the sequence of the predetermined script nodes until an exit node is reached. When the exit node is reached, script process 780 moves to a decision state 800 to determine the type of result of the script.
  • the branch-based script 780 may return a diagnosis at a return state 802, advice at a return state 804, or a reference to another script at a return state 806.
  • the List-Based Processing system provides advantages of speed, precision and completeness over other methods of medical diagnoses. Specifically, the List-Based Processing approach:
  • _ organizes medical knowledge into lists that others can process; _ presents diagnosis in a way that can be checked for correctness and completeness;
  • _ simplifies updating scripts as medical knowledge changes; allows testing by automated means; can be used as a callable function from branch-based scripts; _ is computer platform-, medium-, and language-independent;
  • d_vivax "084.1" "Vivax Malaria” s_tropics 200 s_lethargic 100 s_fever 200 s_chills 200 s_nochills -100 s_s eats 200 s_nosweats -100 s_cfsinorder 200 s_cfsnotinorder 100 s_2bouts_48 350 s 3bouts 48 450 s_pnotest 5 s_pnegative -700 s_pfalcip -700 s_p vivax 700 s_povale -700 s_pmalar -700 s_pmixed - 700
  • t_qcfs Did you have Chills, Fever, and Sweating? t_qcfsbouts How many bouts of C-F-S did you have? t_qcfsorder Did you have C-F-S in that order? t_qchills Do you have chills? t_qdlbout How long did that 1 bout last? t_qd2bouts What was the time between those 2 bouts? t_qd3bouts How far apart were these bouts? t_qfever Do you have fever? t_qlethargic Have you been tired or lethargic? t_qpfound What Plasmodia were found in blood? t_qptest Did you have a blood test for Plasmodia? t_qsweats Do you have sweating? t_qtropics Have you been in the tropics recently?

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Medical Informatics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Biomedical Technology (AREA)
  • Pathology (AREA)
  • Biophysics (AREA)
  • Physics & Mathematics (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Molecular Biology (AREA)
  • Surgery (AREA)
  • Animal Behavior & Ethology (AREA)
  • Veterinary Medicine (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Vascular Medicine (AREA)
  • Immunology (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Ultra Sonic Daignosis Equipment (AREA)
  • Telephonic Communication Services (AREA)
  • Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)
  • Medicines Containing Antibodies Or Antigens For Use As Internal Diagnostic Agents (AREA)
  • Measuring Pulse, Heart Rate, Blood Pressure Or Blood Flow (AREA)
EP97934919A 1996-07-12 1997-07-11 Computerized medical diagnostic system utilizing list-based processing Ceased EP0912955A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02075042A EP1280091A3 (en) 1996-07-12 1997-07-11 Computerized medical diagnostic system utilizing list-based processing

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US2161496P 1996-07-12 1996-07-12
US2161596P 1996-07-12 1996-07-12
US21614P 1996-07-12
US21615P 1996-07-12
PCT/US1997/012025 WO1998002836A2 (en) 1996-07-12 1997-07-11 Computerized medical diagnostic system utilizing list-based processing

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP02075042A Division EP1280091A3 (en) 1996-07-12 1997-07-11 Computerized medical diagnostic system utilizing list-based processing

Publications (1)

Publication Number Publication Date
EP0912955A2 true EP0912955A2 (en) 1999-05-06

Family

ID=26694895

Family Applications (2)

Application Number Title Priority Date Filing Date
EP97934919A Ceased EP0912955A2 (en) 1996-07-12 1997-07-11 Computerized medical diagnostic system utilizing list-based processing
EP97937972A Expired - Lifetime EP0912957B1 (en) 1996-07-12 1997-07-11 Computerized medical diagnostic and treatment advice system including network access

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP97937972A Expired - Lifetime EP0912957B1 (en) 1996-07-12 1997-07-11 Computerized medical diagnostic and treatment advice system including network access

Country Status (14)

Country Link
EP (2) EP0912955A2 (ja)
JP (2) JP4615629B2 (ja)
CN (2) CN1246942A (ja)
AT (1) ATE284558T1 (ja)
AU (2) AU728675C (ja)
BR (2) BR9712092A (ja)
CA (2) CA2260838A1 (ja)
DE (1) DE69731884T2 (ja)
EA (2) EA001835B1 (ja)
ES (1) ES2237801T3 (ja)
HK (1) HK1053178A1 (ja)
IL (2) IL127935A (ja)
NZ (2) NZ333718A (ja)
WO (2) WO1998002836A2 (ja)

Families Citing this family (100)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8073695B1 (en) 1992-12-09 2011-12-06 Adrea, LLC Electronic book with voice emulation features
US9286294B2 (en) 1992-12-09 2016-03-15 Comcast Ip Holdings I, Llc Video and digital multimedia aggregator content suggestion engine
US7168084B1 (en) 1992-12-09 2007-01-23 Sedna Patent Services, Llc Method and apparatus for targeting virtual objects
US9053640B1 (en) 1993-12-02 2015-06-09 Adrea, LLC Interactive electronic book
USRE43433E1 (en) 1993-12-29 2012-05-29 Clinical Decision Support, Llc Computerized medical diagnostic and treatment advice system
US5660176A (en) 1993-12-29 1997-08-26 First Opinion Corporation Computerized medical diagnostic and treatment advice system
US6206829B1 (en) 1996-07-12 2001-03-27 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US6108635A (en) * 1996-05-22 2000-08-22 Interleukin Genetics, Inc. Integrated disease information system
US6487277B2 (en) * 1997-09-19 2002-11-26 Siemens Information And Communication Networks, Inc. Apparatus and method for improving the user interface of integrated voice response systems
US20060193278A1 (en) 1997-10-15 2006-08-31 Wolfgang Theimer Mobile telephone for Internet applications
US6278999B1 (en) 1998-06-12 2001-08-21 Terry R. Knapp Information management system for personal health digitizers
AU2390000A (en) 1998-12-29 2000-07-31 Occulogix Corporation Rheological treatment methods and related apheresis systems
US7107253B1 (en) * 1999-04-05 2006-09-12 American Board Of Family Practice, Inc. Computer architecture and process of patient generation, evolution and simulation for computer based testing system using bayesian networks as a scripting language
US8473452B1 (en) 1999-09-20 2013-06-25 Ims Health Incorporated System and method for analyzing de-identified health care data
US6691134B1 (en) * 1999-11-24 2004-02-10 Ge Medical Technology Services, Inc. Image-based artifact troubleshooting for medical systems
US6602191B2 (en) 1999-12-17 2003-08-05 Q-Tec Systems Llp Method and apparatus for health and disease management combining patient data monitoring with wireless internet connectivity
GB2357675A (en) * 1999-12-24 2001-06-27 Ncr Int Inc A network of information resources
WO2001061616A2 (en) * 2000-02-14 2001-08-23 First Opinion Corporation Automated diagnostic system and method
US6383136B1 (en) * 2000-03-06 2002-05-07 Charlyn Jordan Health analysis and forecast of abnormal conditions
US7379885B1 (en) 2000-03-10 2008-05-27 David S. Zakim System and method for obtaining, processing and evaluating patient information for diagnosing disease and selecting treatment
IT1318584B1 (it) * 2000-06-19 2003-08-27 Tangram Odis S R L Sistema diagnostico integrato per il cavo orale.
JP2004507292A (ja) * 2000-07-27 2004-03-11 アイ−フロー　コーポレイション 患者を監視する方法および装置
EP1317207B1 (en) * 2000-09-13 2013-04-03 Richard A. Schmidt Diagnosis of lower urinary tract dysregulation
KR20020059802A (ko) * 2000-09-28 2002-07-13 니시무로 타이죠 정보제공 시스템, 정보제공방법, 정보취득방법 및정보제공 프로그램을 기록한 컴퓨터 독출가능한 매체
SG135048A1 (en) 2000-10-18 2007-09-28 Johnson & Johnson Consumer Intelligent performance-based product recommendation system
WO2002054947A2 (en) * 2000-11-06 2002-07-18 The Johns Hopkins University Method and system for outpatient monitoring
US7165221B2 (en) * 2000-11-13 2007-01-16 Draeger Medical Systems, Inc. System and method for navigating patient medical information
JP2002163359A (ja) * 2000-11-27 2002-06-07 Mediva:Kk 医療用診断・処置支援装置、医療用診断・処置支援システム装置および医療用診断・処置支援プログラム記録したコンピュータ読み取り可能な記録媒体。
AUPR432701A0 (en) * 2001-04-10 2001-05-17 Lions Eye Institute Of Western Australia Incorporated, The Virtual service system for client and service provider users and method therefor
US7793326B2 (en) 2001-08-03 2010-09-07 Comcast Ip Holdings I, Llc Video and digital multimedia aggregator
US7908628B2 (en) 2001-08-03 2011-03-15 Comcast Ip Holdings I, Llc Video and digital multimedia aggregator content coding and formatting
WO2003036539A1 (fr) * 2001-10-23 2003-05-01 Citizen Watch Co., Ltd. Systeme de gestion de sante et programme de gestion de sante
US20050033121A1 (en) * 2001-12-28 2005-02-10 Modrovich Ivan E. Diagnostic information systems
US20050144042A1 (en) * 2002-02-19 2005-06-30 David Joffe Associated systems and methods for managing biological data and providing data interpretation tools
US7908155B2 (en) * 2002-04-12 2011-03-15 Becton, Dickinson And Company System for collecting, storing, presenting and analyzing immunization data having remote stations in communication with a vaccine and disease database over a network
JP2004126981A (ja) * 2002-10-03 2004-04-22 Medifocus:Kk 診断装置、診断方法およびプログラム
EP1609425A4 (en) * 2003-03-10 2009-05-27 Hisaki Kamo SYSTEM FOR REALIZING TOPICAL NERVE DIAGNOSIS AND NEUROANATOMIC STUDY
US8060315B2 (en) * 2004-07-27 2011-11-15 Carefusion 303, Inc. Method for measuring the incidence of hospital acquired infections
US9081879B2 (en) 2004-10-22 2015-07-14 Clinical Decision Support, Llc Matrix interface for medical diagnostic and treatment advice system and method
WO2006093424A1 (fr) * 2005-02-28 2006-09-08 Obtshestvo S Ogranichennoy Otvetstvennostiu 'nauchno-Proizvodstvennoe Predpriyatie Zhivie Sistemi' Procede pour diagnostiquer et corriger a distance l'etat d'un humain et systeme de mise en oeuvre correspondant
US8652039B2 (en) 2005-03-02 2014-02-18 Siemens Medical Solutions Usa, Inc. Guiding differential diagnosis through information maximization
JP4866576B2 (ja) * 2005-07-11 2012-02-01 インフォコム株式会社 診療支援システム
US7818181B2 (en) 2005-10-31 2010-10-19 Focused Medical Analytics Llc Medical practice pattern tool
US20070156382A1 (en) * 2005-12-29 2007-07-05 Graham James L Ii Systems and methods for designing experiments
JP4931447B2 (ja) * 2006-03-17 2012-05-16 株式会社マザー＆チャイルド 診断及び保育支援システム
US7805385B2 (en) 2006-04-17 2010-09-28 Siemens Medical Solutions Usa, Inc. Prognosis modeling from literature and other sources
US20070299665A1 (en) * 2006-06-22 2007-12-27 Detlef Koll Automatic Decision Support
US8540517B2 (en) 2006-11-27 2013-09-24 Pharos Innovations, Llc Calculating a behavioral path based on a statistical profile
US8540516B2 (en) 2006-11-27 2013-09-24 Pharos Innovations, Llc Optimizing behavioral change based on a patient statistical profile
US8540515B2 (en) 2006-11-27 2013-09-24 Pharos Innovations, Llc Optimizing behavioral change based on a population statistical profile
US9355273B2 (en) 2006-12-18 2016-05-31 Bank Of America, N.A., As Collateral Agent System and method for the protection and de-identification of health care data
GB2452067A (en) * 2007-08-23 2009-02-25 Univ Plymouth Method for prediction and diagnosis of medical conditions
AU2008310575A1 (en) 2007-10-12 2009-04-16 Patientslikeme, Inc. Personalized management and monitoring of medical conditions
JP5342136B2 (ja) * 2007-12-13 2013-11-13 株式会社東芝 健診受診者支援装置及び健診受診者支援装置が支援する方法
DE102007061434A1 (de) * 2007-12-20 2009-07-02 Gesellschaft für Patientenhilfe DGP mbH Rechnernetzwerksystem zur Erfassung, Verarbeitung und Verwertung von patientenbezogenen Daten
JP2009059381A (ja) * 2008-11-07 2009-03-19 Fujifilm Corp 医療診断支援方法および装置並びに診断支援情報記録媒体
CA2758481C (en) 2009-04-30 2018-03-20 Patientslikeme, Inc. Systems and methods for encouragement of data submission in online communities
CN103180855B (zh) * 2010-08-24 2016-10-26 史密夫和内修有限公司 用于医疗设备之间的安全互操作性的装置
US20130339041A1 (en) 2010-10-29 2013-12-19 Vladimir Leonidovich Glotko Clinical information system
EP2645273A1 (en) * 2010-11-23 2013-10-02 Obschestvo s Ogranichennoy Otvetstvennostiu «Pravovoe Soprovojdenie Bisnesa» System for differentiation and analysis of recorded clinical data
EP2661849B1 (en) * 2011-01-05 2019-05-29 Koninklijke Philips N.V. System and method for distributing meaningful clinical alerts
JP5860905B2 (ja) * 2011-03-16 2016-02-16 コーニンクレッカ フィリップス エヌ ヴェＫｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ． 息切れの症状評価
SI2699587T1 (sl) 2011-04-22 2019-08-30 Wyeth Llc Sestavek, povezan z mutantskim clostridium difficile toksinom, in metode omenjenega sestavka
US9152764B2 (en) 2012-02-02 2015-10-06 Photon Medical Communications, Inc. Systems and methods for managing data
JP6214640B2 (ja) * 2012-06-01 2017-10-18 コーニンクレッカ フィリップス エヌ ヴェＫｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ． 新生児用の動脈血液ガステストの頻度を選択するための方法及びシステム
WO2013184127A1 (en) * 2012-06-08 2013-12-12 Hewlett-Packard Development Company, L.P. Patient information interface
CN103164616A (zh) * 2013-02-02 2013-06-19 杭州卓健信息科技有限公司 一种智能导诊系统和方法
ITPD20130026A1 (it) * 2013-02-07 2014-08-08 Medigenia Srl Sistema e metodo di controllo delle condizioni di salute di un paziente
EP2775412A1 (en) * 2013-03-07 2014-09-10 Medesso GmbH Method of generating a medical suggestion as a support in medical decision making
CA2927362A1 (en) * 2013-10-31 2015-05-07 Pau-San HARUTA Computing technologies for diagnosis and therapy of language-related disorders
KR102272194B1 (ko) * 2014-07-08 2021-07-01 삼성전자주식회사 인지기능 검사 장치 및 방법
CN104200069B (zh) * 2014-08-13 2017-08-04 周晋 一种基于症状分析和机器学习的用药推荐系统和方法
US9747654B2 (en) 2014-12-09 2017-08-29 Cerner Innovation, Inc. Virtual home safety assessment framework
CN104636622B (zh) 2015-02-12 2017-08-04 无锡海斯凯尔医学技术有限公司 基于弹性检测设备的健康状况分析方法及系统
DE102016110931A1 (de) 2015-06-15 2016-12-15 Herzog & Dietz GbR (vertretungsberechtigter Gesellschafter: Christian Dietz, 52351 Düren) System und computerimplementiertes Verfahren zur Unterstützung von Zahnärzten bei der Beratung ihrer Patienten sowie entsprechendes Computerprogramm
CN106308746A (zh) * 2015-07-02 2017-01-11 上海金仕达卫宁软件股份有限公司 临床智能诊断终端
CN105678066B (zh) * 2015-12-31 2019-02-22 天津迈沃医药技术股份有限公司 基于用户反馈信息完成数据训练的疾病自诊方法及系统
EP3223181B1 (en) 2016-03-24 2019-12-18 Sofradim Production System and method of generating a model and simulating an effect on a surgical repair site
RU167673U1 (ru) * 2016-04-20 2017-01-10 федеральное государственное бюджетное образовательное учреждение высшего образования "Северо-Западный государственный медицинский университет им. И.И. Мечникова" Министерства здравоохранения Российской Федерации Маска для видеонистагмоскопии
EP3475473A4 (en) 2016-06-26 2020-01-22 The Board of Trustees of the Leland Stanford Junior University BIOMARKERS FOR PROGNOSING MORTALITY IN SERIOUSLY ILL PATIENTS
CN106250690A (zh) * 2016-08-01 2016-12-21 上海质康医药科技有限公司 一种逻辑树型中医自诊知识学习的方法
WO2018062366A1 (ja) * 2016-09-28 2018-04-05 公益財団法人先端医療振興財団 認知症介護負担度判定装置、認知症介護負担度判定方法、認知症介護負担度判定プログラム、認知症治療効果判定装置、認知症治療効果判定方法、及び認知症治療効果判定プログラム
CN106777869A (zh) * 2016-11-17 2017-05-31 黄劲涛 一种基于智能医疗床的智能云医养系统
CN106384018A (zh) * 2016-11-17 2017-02-08 黄劲涛 一种基于智能医疗床的医疗系统
CN106709233A (zh) * 2016-11-17 2017-05-24 黄劲涛 一种中央医疗协同管理系统
CN106473722A (zh) * 2016-11-17 2017-03-08 黄劲涛 一种基于智能医疗床的健康监测系统
CN106777966B (zh) * 2016-12-13 2020-02-07 天津迈沃医药技术股份有限公司 基于医疗信息平台的数据互动训练方法及系统
RU2697412C2 (ru) * 2016-12-21 2019-08-14 Федеральное государственное бюджетное учреждение науки Институт молекулярной биологии им. В.А. Энгельгардта Российской академии наук Экспресс-тест на основе ПЦР, позволяющий предсказывать чувствительность опухоли головного мозга конкретного пациента к онколитическим вирусам
CN106874670A (zh) * 2017-02-14 2017-06-20 安徽通灵仿生科技有限公司 基于人工智能的儿科医生机器人装置
US20180293352A1 (en) * 2017-04-10 2018-10-11 COTA, Inc. System and Method for Decision-Making for Determining Initiation and Type of Treatment for Patients with a Progressive Illness
WO2019159007A1 (en) * 2018-02-18 2019-08-22 Cardio Holding Bv A system and method for documenting a patient medical history
KR102072292B1 (ko) * 2018-04-04 2020-01-31 고려대학교 산학협력단 어지럼증 스코어 계산 장치 및 방법
CN109346167A (zh) * 2018-08-03 2019-02-15 昆明理工大学 一种基于人工智能的诊断辅助系统
CN111239425A (zh) * 2018-11-29 2020-06-05 举康(上海)生物科技有限公司 基于循环肿瘤细胞检测的肿瘤辅助诊断系统
US11894139B1 (en) 2018-12-03 2024-02-06 Patientslikeme Llc Disease spectrum classification
JP7211161B2 (ja) * 2019-02-28 2023-01-24 日本電気株式会社 処理装置、処理方法及びプログラム
IT201900002889A1 (it) * 2019-02-28 2020-08-28 La Rondine Soc Cooperativa Sociale Metodo per il monitoraggio della terapia e l’accrescimento della compliance tra medici, pazienti e familiari
JP7211160B2 (ja) * 2019-02-28 2023-01-24 日本電気株式会社 処理装置、処理方法及びプログラム
WO2021001592A1 (en) * 2019-07-02 2021-01-07 Etsimo Healthcare Oy Automated and real-time patient care planning
CN113674857A (zh) * 2021-08-23 2021-11-19 深圳创维－Rgb电子有限公司 电视辅助疾病诊断装置及系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5572421A (en) * 1987-12-09 1996-11-05 Altman; Louis Portable medical questionnaire presentation device
EP0531889B1 (en) * 1991-09-11 1998-11-11 Hewlett-Packard Company Data processing system and method for automatically performing prioritized nursing diagnoses from patient assessment data
FR2691003B1 (fr) * 1992-05-11 1997-04-04 Dominique Boisseau Procede de consultation et de mise a jour de donnees specialisees et systeme de mise en óoeuvre de ce procede.
US5517405A (en) * 1993-10-14 1996-05-14 Aetna Life And Casualty Company Expert system for providing interactive assistance in solving problems such as health care management
US5486999A (en) * 1994-04-20 1996-01-23 Mebane; Andrew H. Apparatus and method for categorizing health care utilization
DE4430164C2 (de) * 1994-08-25 1998-04-23 Uthe Friedrich Wilhelm Verwendung eines interaktiven Informationssystems
US5633910A (en) * 1994-09-13 1997-05-27 Cohen; Kopel H. Outpatient monitoring system
US5619991A (en) * 1995-04-26 1997-04-15 Lucent Technologies Inc. Delivery of medical services using electronic data communications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9802836A2 *

Also Published As

Publication number Publication date
AU728675B2 (en) 2001-01-18
BR9712091A (pt) 1999-10-05
EA199900031A1 (ru) 1999-10-28
CN1230266A (zh) 1999-09-29
ATE284558T1 (de) 2004-12-15
EP0912957A1 (en) 1999-05-06
DE69731884D1 (de) 2005-01-13
WO1998002837A1 (en) 1998-01-22
EA001835B1 (ru) 2001-08-27
DE69731884T2 (de) 2005-12-15
IL127936A (en) 2004-05-12
AU3797397A (en) 1998-02-09
JP2000514938A (ja) 2000-11-07
JP4224136B2 (ja) 2009-02-12
CN1246942A (zh) 2000-03-08
EA199900030A1 (ru) 1999-08-26
AU4040397A (en) 1998-02-09
NZ333717A (en) 2000-10-27
CA2260836A1 (en) 1998-01-22
ES2237801T3 (es) 2005-08-01
WO1998002836A3 (en) 2000-11-23
WO1998002836A2 (en) 1998-01-22
NZ333718A (en) 2000-10-27
IL127936A0 (en) 1999-11-30
EP0912957B1 (en) 2004-12-08
IL127935A0 (en) 1999-11-30
CA2260838A1 (en) 1998-01-22
HK1053178A1 (zh) 2003-10-10
EA001861B1 (ru) 2001-10-22
AU753087B2 (en) 2002-10-10
AU728675C (en) 2001-11-08
JP4615629B2 (ja) 2011-01-19
JP2002511159A (ja) 2002-04-09
BR9712092A (pt) 1999-08-31
IL127935A (en) 2003-06-24

Similar Documents

Publication Publication Date Title
AU728675C (en) Computerized medical diagnostic and treatment advice system including list based processing
US6270456B1 (en) Computerized medical diagnostic system utilizing list-based processing
US7300402B2 (en) Computerized medical diagnostic and treatment advice system
US6206829B1 (en) Computerized medical diagnostic and treatment advice system including network access
US6022315A (en) Computerized medical diagnostic and treatment advice system including network access
US5711297A (en) Computerized medical advice system and method including meta function
US20040249778A1 (en) Computerized medical diagnostic and treatment advice system and method including mental status examination
USRE43433E1 (en) Computerized medical diagnostic and treatment advice system
EP1280091A2 (en) Computerized medical diagnostic system utilizing list-based processing
AU768052B2 (en) Computerized medical diagnostic and treatment advice system including list based processing
AU770435B2 (en) Computerized medical diagnostic and treatment advice system including network access

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19990215

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

RAX Requested extension states of the european patent have changed

Free format text: AL PAYMENT 19990212;LT PAYMENT 19990212;LV PAYMENT 19990212;RO PAYMENT 19990212;SI PAYMENT 19990212

17Q First examination report despatched

Effective date: 19990506

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: FIRST OPINION CORPORATION

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ILIFF, EDWIN C.

APBX Invitation to file observations in appeal sent

Free format text: ORIGINAL CODE: EPIDOSNOBA2E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20060407