1. Field of the Invention
This invention relates to computerized medical diagnosis and advice, and more particularly to allowing different diagnostic or evaluation strategies to be used.
2. Description of the Related Technology
Known medical diagnosis methods have a single method of diagnosis.
In one embodiment there is a computerized arbiter method utilized during an evaluation session in a medical diagnostic system having a computing device, the method comprising asking general questions associated with a list of candidate diseases of a patient using a high level mode of inquiry by use of a user interface associated with a computing device; selecting a set of most likely diseases based on the responses to the general questions; asking questions focused on the set of most likely diseases using a middle level mode of inquiry; selecting a most likely disease based on the responses to the questions from the middle level of inquiry; and asking questions focused on the most likely disease using a low level mode of inquiry, wherein a sequence of questions corresponds to one of a plurality of evaluation strategies, wherein the set of most likely diseases is divided into one class that is allowed to vote for the next best question which is to be asked of the patient or into another class that is not allowed to vote for the next best question, wherein the diseases that are in the class that cannot vote for the next best question add a weight to a disease score, the weight corresponding to a response for a question asked by another disease, and wherein questions are asked until a goal of the evaluation session has been reached.
One of the evaluation strategies may be intent modulation which eliminates the later stages of urgent diseases from the list of candidate diseases. The responses to the questions may be stored in a patient electronic medical record and may be used to establish patient health items (PHIs), and wherein each candidate disease may be associated with one or more PHIs, and each PHI may be associated with one or more questions. One of the evaluation strategies may be mean democratic sine which determines the next best question by a voting process wherein the sine status of a PHI and disease pair is factored into the voting strength of the diseases. One of the evaluation strategies may be a sequential synergy strategy which gives more voting strength of priority to those PHIs that complete or nearly complete a sequential synergy. The diseases that are in the class that are allowed to vote for the next best question may add a weight to a disease score. The next best question may be the question that advances the evaluation session to reach a correct diagnosis at the earliest point in time with the fewest number of questions. The number of questions asked of the patient may be reduced based on use of the middle level of inquiry where the class that is not allowed to vote for the next best question does not contribute potential questions to be asked of the patient. The questions corresponding to late stage PHIs of urgent diseases may be asked first so as to diagnose or exclude those diseases that have a limited therapeutic window of opportunity. A particular one of the plurality of evaluation strategies can be changed responsive to a clinical situation of the patient. A particular one of the plurality of evaluation strategies may be selected depending upon a past medical history of the patient as stored in the patient electronic medical record. A particular one of the plurality of evaluation strategies may be selected depending upon the patient's previous responses in a consultation. The method may additionally comprise selecting from the questions voted on by the diseases in diagnostic consideration. The method may not permit diseases of the class not allowed to vote of the set of most likely diseases to suggest questions to ask of the patient during the evaluation session.
In another embodiment there is a computerized medical diagnostic system, the system comprising a computer storage storing a list of candidate diseases, each candidate disease associated with one or more questions; a computing device in data communication with the computer storage, the computing device performing software instructions to ask general questions associated with the candidate diseases of a patient using a high level mode of inquiry; select a set of most likely diseases based on the responses to the general questions; ask questions focused on the set of most likely diseases using a middle level mode of inquiry; select a most likely disease based on the responses to the questions from the middle level of inquiry; and ask questions focused on the most likely disease using a low level mode of inquiry, wherein the set of most likely diseases may be separated into a first class that is allowed to vote for the next best question which is to be asked of the patient or into a second class that is not allowed to vote for the next best question, wherein the diseases that are in the second class add a weight to a disease score, the weight corresponding to a response for a question asked by another disease, and wherein questions are asked until a goal of the evaluation session has been reached.
The responses to the questions may be stored in a patient electronic medical record and may be used to establish patient health items (PHIs). The diseases in the list of candidate diseases may be separated into the first class or the second class based on at least the PHIs. The diseases in the first class may add a weight corresponding to a response for a question asked by another disease. A sequence of questions may correspond to one of a plurality of evaluation strategies. The separation of the diseases into the first class and the second class may be dynamic and may be based in part on a voting strength of each disease in the list of candidate diseases. The voting strength of a particular disease may be related to the changing probability that the particular disease is the diagnosis for the patient. The voting strength of a particular disease may be dependent upon the number of PHIs the patient has of the particular disease. The voting strength may depend upon aspects of the PHI being established for the patient. A particular disease may be dynamically transferred between the first and second classes upon reaching or exceeding a threshold. The system may not permit diseases of the class not allowed to vote to suggest questions to ask of the patient during an evaluation session based at least in part on the disease score. Each candidate disease may be associated with one or more patient health items (PHIs), and each PHI may be associated with one or more questions. The computing device may additionally perform software instructions to check the patient electronic medical record for responses to questions or PHIs prior to asking questions of the patient.
In another embodiment there is a computerized medical diagnostic system, the system comprising a computer storage storing a list of disease objects, each disease object associated with one or more questions; and a computing device in data communication with the computer storage, the computing device executing instructions associated with an arbiter object, wherein the arbiter object, in conjunction with a plurality of evaluation strategies, determines the selection of a next best question to ask of a patient.
The arbiter object may determine when the next evaluation strategy of the plurality of evaluation strategies is to be started. The determination of when the next evaluation strategy may be to be started is based on a rule set. The determination of when the next evaluation strategy may be to be started depends on the completion of the current evaluation strategy. The system may additionally comprise a patient ombudsman object that interfaces with the arbiter object and may suggest one or more general questions, wherein answers to the general questions causes a decrease in the number of questions asked of the patient. An evaluation strategy may be intent modulation in which the late stage of urgent diseases are established or ruled out before proceeding to other diseases. An evaluation strategy may be intent modulation in which critical curve patient health items (PHIs) of urgent diseases are established after evaluating late stage symptoms. An evaluation strategy may comprise excluding or establishing serious diseases before diagnosing other diseases. The evaluation strategies can be changed as often as after every question asked of the patient. Certain PHIs of a disease may be designated as late stage PHIs of a disease. Certain PHIs of a disease may be designated as critical curve PHIs. The arbiter object may not permit disease objects of a class not allowed to vote from the list of disease objects to suggest questions to ask of the patient during an evaluation session. Each disease object may be associated with one or more PHIs, and each PHI is associated with one or more questions. The arbiter object may interface the disease objects with the patient. Selected ones of the disease objects may suggest questions to ask of the patient, and wherein the arbiter object may select the next best question to ask the patient based at least on a voting strength of the selected disease objects. The arbiter object may select the next best question to ask the patient additionally based at least on a weight of the question, a sine status of a patient health item associated with the question, the diseases in diagnostic consideration, and data in an electronic medical record of the patient. The system may additionally comprise an interface in data communication with an output device to ask questions of the patient and with an input device to receive responses from the patient. The arbiter object can change the axis of inquiry based on certain criteria.
In another embodiment there is a computerized arbiter method associated with an evaluation session in a medical diagnostic system, the method comprising providing a plurality of modes of inquiry, each mode including at least one evaluation strategy, including one mode of inquiry wherein a plurality of disease objects are separated into a first class that is allowed to vote for the next best question which is to be asked of a patient or into a second class that is not allowed to vote for the next best question to be asked; and asking the next best question of the patient.
The method may additionally comprise asking general questions of the patient associated with a list of diseases using a high level mode of inquiry; selecting a set of most likely diseases based on the responses to the general questions; asking questions focused on the set of most likely diseases using a middle level mode of inquiry; selecting a most likely disease based on the responses to the questions from the middle level of inquiry; and asking questions focused on the most likely disease using a low level mode of inquiry, wherein the evaluation strategies include at least one diagnostic strategy, wherein each of the diseases that has not been excluded from diagnostic consideration adds a weight to a disease score based on a response to each question asked, and wherein questions are asked until a goal of the evaluation session has been reached. The evaluation strategies may include a non-diagnostic strategy. The method may not permit diseases of a non-voting class from the set of most likely diseases to suggest questions to ask of the patient during the evaluation session. A disease may be excluded if weights for the patient health items for which questions have not been asked yet and weights with associated synergies cannot cause the disease score to reach or exceed a diagnostic threshold.
In yet another embodiment there is a computerized medical diagnostic system, the system comprising a computer storage storing a list of candidate disease objects, each disease object associated with one or more questions; and a computing device in data communication with the computer storage, the computing device executing instructions associated with an arbiter object, wherein the arbiter object utilizes at least one of a plurality of evaluation strategies that help determine the selection of a next best question to ask of a patient, wherein the disease objects are separated into a first class that is allowed to vote for the next best question which is to be asked of the patient or into a second class that is not allowed to vote for the next best question. The arbiter object may determine when a next evaluation strategy of the plurality of evaluation strategies is to be started.
a is a block diagram of an embodiment of an example configuration of a medical diagnostic and treatment advice system.
b is a flowchart of an embodiment of an arbiter process performed by the medical diagnostic and advice system.
a is a diagram of an embodiment of a simplified example configuration of disease objects in a medical diagnostic and treatment advice system interacting with a patient.
b is a diagram of an embodiment of an example configuration of arbiter components in a medical diagnostic and treatment advice system.
The following detailed description of certain embodiments presents various descriptions of specific embodiments of the invention. However, the invention can be embodied in a multitude of different ways.
The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of certain specific embodiments of the invention. Furthermore, embodiments of the invention may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the embodiments herein described.
The system is comprised of various modules, tools, and applications. As can be appreciated by one of ordinary skill in the art, each of the modules may comprise various sub-routines, procedures, definitional statements and macros. Each of the modules are typically separately compiled and linked into a single executable program. Therefore, the following description of each of the modules is used for convenience to describe the functionality of the preferred system. Thus, the processes that are undergone by each of the modules may be arbitrarily redistributed to one of the other modules, combined together in a single module, or made available in, for example, a shareable dynamic link library.
The system modules, tools, and applications may be written in any programming language such as, for example, C, C++, C#, BASIC, Visual Basic, Pascal, Ada, Java, HTML, XML, or FORTRAN, and executed on an operating system, such as variants of Windows, Macintosh, UNIX, Linux, VxWorks, PalmOS, PocketPC, Symbian, Java-based or other operating system. C, C++, C#, BASIC, Visual Basic, Pascal, Ada, Java, HTML, XML and FORTRAN are industry standard programming languages for which many commercial compilers can be used to create executable code.
The present system and method allows many different modes of inquiry, which are in themselves dependent on the progress of the diagnostic process. Three modes or axes, Horizontal Axis of Inquiry (HAI), Diagonal Axis of Inquiry (DAI) and the Vertical Axis of Inquiry (VAI), permit a List-Based Engine or Arbiter object to vary its focus from the general, e.g., considering many possible diseases to the specific, e.g., considering one disease. In the early stages, the engine knows little about the patient and must ask the best general questions that quickly eliminate a large number of candidate diseases. But after applying the Horizontal Axis of Inquiry (HAI) for a while, if the scores or diagnostic momentum of some diseases reaches a specified level, the engine can then switch to the Diagonal Axis of Inquiry (DAI) to focus the diagnostic process on a subset of diseases and later into the Vertical Axis of Inquiry (VAI) to focus on a single disease, to the momentary exclusion of all other diseases. In addition, within each axis the engine may also employ multiple diagnostic strategies.
The Arbiter object facilitates the evaluation and switching of modes of inquiry based upon evaluation strategies designed to achieve a diagnosis in as few iterative steps as possible, or stated another way, to reach the diagnosis in as few questions as possible. In addition, the system allows the primary diagnosis to be performed by the software equivalent of a world-class expert in the disease that the patient has. In certain embodiments, evaluation strategies can include one or more diagnostic strategies and one or more non-diagnostic strategies. An example of a non-diagnostic strategy is a strategy that excludes the urgent or serious problems and then not pursuing the diagnosis either at all or to do it in a latter (reenter) consultation.
The Arbiter object has the ability to employ multiple diagnostic strategies based upon the purpose or goal of the consultation (e.g., diagnose, rule out worst case diagnoses), the stage of the consultation and the diseases in diagnostic consideration, how sensitive or how thorough the patient wants the evaluation to be, etc. Because of the modular nature of the Arbiter, evaluation strategies can be added and removed, yielding a “best fit” solution to most any given medical diagnostic requirements. The Arbiter object can change strategies or can change the axis of inquiry or can change both.
The Arbiter object is designed to “prune” execution to “least cost” (fewest data required to achieve solution) thereby maximizing the efficiency of the diagnostic process as a whole, and yielding lower costs, as diseases can be caught in earlier stages of progression, reducing the cost of treatment.
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. Referring to
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. Alternatively, the MDATA programs and databases reside on a single server 110 that utilizes network interface hardware and software 112.
The network 102 may connect (wired or wirelessly) to a user computer 116 or other computing device, 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 118. Alternatively, the browser 120 is not utilized when the MDATA programs are executed in a local mode on computer 116. An interface (not shown), such as a graphical user interface, is used to provide or ask questions of the user 114 (e.g., patient or patient proxy in certain embodiments) and receive answers from the user. A video camera 122 may be optionally connected to the computer 116 to provide visual input, such as visual symptoms. The arbiter method may be realized in a program format to be stored on a computer readable recording medium that includes any kinds of recording devices for storing computer readable data, for example, a CD-ROM, a DVD, a magnetic tape, memory card and a disk, and may also be realized in a carrier wave format (e.g., Internet transmission or Bluetooth transmission).
Various other devices may be used to communicate with the MDATA servers 108/110. 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 application entitled “Computerized Medical Diagnostic and Treatment Advice System,” U.S. Ser. No. 08/176,041, now U.S. Pat. No. 5,660,176, which is hereby incorporated by reference. Other connection devices for communicating with the MDATA servers 108/110 include a portable personal computer or other handheld computing device 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. The MDATA system is further described in U.S. Pat. No. 5,935,060, which is hereby incorporated by reference in its entirety.
An Arbiter object functions as a computerized patient intermediary between the disease objects which are involved in the process of diagnosing the patient. Software objects include software procedures and functions (methods) and encapsulated data, such as described in U.S. Pat. No. 6,468,210, which is hereby incorporated by reference in its entirety. In addition, it also recommends the best diagnostic strategy to employ depending upon a number of parameters including the diseases in diagnostic consideration, the stage of the consultation, and the goal of the consultation. A goal of the Arbiter may be said to be to find the next best question to ask the patient. In certain embodiments, the next best question is the question that advances a patient evaluation to get a correct diagnosis at the earliest point in time with the fewest number of questions. Working with an automated Medical Diagnostic and Treatment Advice system, the Arbiter represents a process enhancement with a design goal to achieve diagnostic threshold in as few steps as possible.
Get the right disease (diagnosis)
In a process environment analogy, there will be an auditorium with one hundred expert headache neurologists, for example. Each will be a world class expert in one disease causing headache. In certain embodiments, during the interaction, the neurologists may not speak to each other, but only to the Arbiter object or to the patient. Referring to
The symptoms or patient health items inside a disease object are stored in a table that can be sorted by a number of different parameters. The different sort options contribute to many of the intra-disease objects diagnostic strategies.
Referring to
In this analogy, the Arbiter object 1220 functions as the entity that will control interaction with the patient 1260 while the system remains in HAI or DAI modes. The Arbiter may ask one question at a time or may provide the patient a list of questions in which the patient may “check off” the symptoms that apply. Each list is either static (the list does not change as the patient checks the symptoms that apply) or dynamic. In a dynamic list, every time the patient selects one symptom, the other symptoms may change.
In this analogy, associated with the Arbiter 1220 is a Patient Ombudsman object 1250. The Patient Ombudsman object 1250 represents the patient 1260 and is always trying to reduce the number of questions that are asked of its client. This function is based on a proactive form of a Review of Systems (ROS) evaluation. The ROS questions are typically stem questions, e.g., the parent form of several different questions that can be evaluated as a group. In certain embodiments, the Patient Ombudsman object 1250 looks ‘backward’ in a hierarchical view of a patient health item and asks the most general or root PHI. The Patient Ombudsman object 1250 acts in the HAI, DAI and VAI modes.
For example, in the headache example, before the Arbiter 1220 asks for a particular eye sign or symptom, the Patient Ombudsman object 1250 will suggest a screening question to see if the patient has any eye or vision related complaints.
The Arbiter object 1220 will start an evaluation session process by looking at a consultation. If this is the first time for the Arbiter to interact with the patient on this particular consultation, then the Arbiter will take a moment and initialize any data and setup any functionality it requires, before asking its first question. In certain embodiments, it is important to note that by the time the Arbiter system is invoked, the patient has already gone through usually three layers of screening questions designed to exclude very critical situations, a patient electronic medical record will have been opened or created, and all information available about this patient will have been passed or pushed (such as read from the electronic medical record from a prior consultation or session and placed into memory) to the Arbiter 1220 and the disease objects 1210, portions of which are described in U.S. Pat. No. 6,468,210. In certain embodiments, the chief complaint object 1212 is invoked after the initial screening questions are asked of the patient, to be sure that this is not a medical emergency, e.g., major trauma such as if there is a medical emergency or major trauma. The chief complaint object 1212 identifies the chief complaint based on information stored in the database 1215 and patient answers. In certain embodiments, after the chief complaint is identified several problem screening questions associated with the particular complaint are asked of the patient to screen out particular problems before continuing with the consultation. The chief complaint object 1212 then assemble an initial differential diagnosis which is provided to the Arbiter 1220.
Once that is completed, the Arbiter object will ask the patient the first question, based upon the data it already has in hand concerning this patient and this consultation. That is, the Arbiter starts the interaction by asking the disease objects to submit votes for the question or questions they would like to ask next. As a side note, the Arbiter can become more efficient over time and consultations with a patient, as the patient will build up a medical history such in a patient electronic medical record which the Arbiter can look at prior to starting the process. This will yield more efficient evaluations in some venues. For example, if a patient has had a prior appendectomy or tonsillectomy, then certain ailments can be pruned from consideration, as they do not apply—irrespective of what the presenting Chief Complaints or symptoms might initially indicate. Furthermore, answers to questions can be obtained from the patient electronic medical record rather than asking the patient, as applicable, to minimize redundant questioning, for example.
Once the patient has responded to the first question, the Arbiter object will drop into the Disease Qualifying section of operation which is part of the evaluation process for the Arbiter.
In certain embodiments, by default, the Arbiter will employ an Intent Modulation strategy, described hereinbelow, but can employ many other diagnostic strategies to evaluate the information provided during the consultation. Once the evaluation strategy has been selected, the Arbiter will then look to the disease objects and assess the “voting strength” of each one in order to pick the next question to ask. Part of this process involves segregating or separating some of the candidate diseases. Voting strength is varied based upon how successful each disease object has been in questioning the patient. That is, the more PHIs the patient has of a particular disease, the more voting strength that disease will acquire.
The Arbiter object is continually evaluating the session to determine if a change of strategy would be beneficial to the diagnostic process. If so, the Arbiter executes the most beneficial evaluation strategy and re-evaluates its lists of disease candidates as described previously. This operation will continue until the Arbiter has exhausted its list of strategies to employ, or an external event requires it to leave this mode of operation, such as Switching Axis of Inquiry or Diagnostic threshold has been reached, or other goal for the evaluation session has been reached.
The Arbiter system can be paused at anytime and the disease objects can be polled as to why they believe they are or are not the correct diagnosis.
The purpose of Intent Modulation (IM) is a diagnostic strategy which is designed to eliminate the later stages of urgent diseases from the candidate list or, in the case of a patient who is in the later stages of an urgent disease process, to identify it as soon as possible and take the appropriate action(s).
Once the consultation has collected a sufficient amount of information, the Arbiter will invoke Intent modulation, which starts the qualification process with Late Stage Symptoms (LSS), of the disease(s) under consideration ranked by urgency, in certain embodiments. In certain embodiments, it should be noted that the Arbiter is by default in Horizontal Axis of Inquiry (HAI), unless otherwise noted.
Referring to
Referring to
Next the initial disease objects are gathered into a list at a state 204. The disease objects that will make up the integrated list are assembled at state 206 and the disease objects that will make up the segregated disease list are assembled at state 208. In certain embodiments, all disease objects in the list (state 204) are initially integrated. By allowing only the integrated diseases to vote for the next question, the number of questions that the patient is asked is decreased. Note that the segregation/integration process is a dynamic one. As described below, if a segregated disease reaches or exceeds integration threshold, it will be integrated and then vote for what question to ask the patient in the next iteration of the Arbiter loop. Proceeding to state 210, process 152 now checks the segregated disease list to ensure that, based on the little that is known about this patient (e.g., patient electronic medical record, initial screening question answers, problem screening question answers), any diseases that should immediately be integrated are integrated. Once this is complete, state 212 assigns a default voting strength to each disease. In certain embodiments, the default voting strength of all disease objects is one. Other values are possible based upon, for example, the user's desire to exclude urgent or serious diseases to a high degree of certainty. In this case, those diseases that meet a threshold of urgency or seriousness would be given a higher initial voting strength.
Continuing at a state 214, the details that have been gathered at this stage of the consultation and any relevant data from the patient's electronic patient medical record (collectively, patient health items (PHIs)) are sent to the disease objects where the information is processed.
State 216 then checks to see if there is any additional information that the patient may have provided to the process 150. Arbiter initialization is concluded at an end state 218 and flow returns to the process 150 in
Referring back to
The first task in the loop is to select a strategy at a process 156. Process 156 is further described in conjunction with
Referring to
Referring back to decision state 302 of
In another example, in certain embodiments, the patient may have specified in their electronic medical record the degree of sensitivity or thoroughness that they preferred the system to function in. That is, some patients prefer a very “sensitive” workup in the sense that they want all possible diseases considered and do not mind spending several hours if necessary to diagnose their problem.
In another example, the patient's past use of the system may have reached a “meta” threshold for worry. For example, if the patient had too many problems all caused by infection, but in different organ system, the patient system, such as shown in U.S. Pat. No. 6,468,210 and U.S. Pat. No. 5,724,968, would make a “meta” recommendation and suggest that there may be a problem with the immune system. If the patient's HIV status is unknown, a recommendation for an HIV test could be made. If the patient were HIV+, a CD-4 count or viral load test would be suggested.
The patient may also, at any time, change the goal of the consultation in real time. For example, the patient may start a consultation with the intention of trying to arrive at a clinical diagnosis of their problem. If, for some reason, the patient needs to shorten the consultation, the goal can be changed for this consultation to exclude the urgent or serious causes of the problem and leave the diagnostic part for later.
If the patient has a medical record of diseases that may make the patient susceptible to other diseases, this information will be considered in the workup. From a Cause Disease Effect (CDE) view, the diseases which this patient's disease may cause have their prevalence increased in the diagnostic process. In addition, those diseases can be added to the differential even if, the patient's complaint(s) alone would not warrant that. For example, Diabetes predisposes the patient to a number of problems including atherosclerosis and kidney failure, and these will always be considered in the diagnostic session. Lupus makes the body's coagulation system much more likely to form clots. So diseases like acute coronary syndrome or pulmonary embolus must always be considered.
Advancing to a decision state 304 of
Each disease object has a default sequence of questions for both VAI and HAI mode. In addition, each disease object contains the sequence of questions to be answered for different strategies including excluding the disease as quickly as possible. In the current example, the answer to the decision state 304 would also be “No”, and process 156 moves to state 308 and instructs the system to continue with the current strategy, Intent Modulation. Process 156 then moves to an exit function state 310 to end this task and returns to process 150 in
On
Referring to
Referring to
Beginning at a start state 500 of
Returning to decision state 502 of
Returning to decision state 514 of
Voting strength is not shown explicitly in
Referring to
Advancing to a decision state 908 of
Referring to
In certain embodiments, the Arbiter requests the first sequential synergy in a disease timeline, after the urgent diseases have been excluded. If the patient does have the other PHI involved in the sequential synergy, then the voting strength is increased. Beginning at a start state 1000, process 408 advances to state 1002 and requests that the disease objects vote only for PHIs that are part of sequential synergies. Advancing to state 1004, process 408 then adds voting strength to diseases who have voted for a PHI that completes a sequential synergy. Moving to state 1006, process 408 adds voting strength to diseases that have voted for PHIs that are near to completing a synergy. Proceeding to state 1008, process 408 selects the elected PHI based on the vote and then completes at an end state 1010.
Referring to
Referring back to
Referring to
Continuing at state 608 of
Referring to
Referring back to
Referring to
Proceeding to a decision state 810, process 162 checks to determine if the current disease is integrated or segregated. If the disease is segregated, process 162 advances to state 814 where the integration threshold is calculated. There are several parameters that affect the segregation and integration of diseases. First, the score of a disease expressed as a percentage determines whether the disease is integrated so as to allow it to ask questions. A disease is integrated when the diagnostic score reaches or exceeds a threshold, typically a percentage of the score required to have a clinical diagnosis. Note that this threshold depends on the sensitivity factor set. If sensitivity is set high, more diseases are integrated. In addition to the score itself, the first derivative of the score, that is, the rate at which the score is increasing is used to integrate diseases, just as it is used to switch the Axis of Inquiry. In addition, the disease object contains within itself a table that lists the combination of PHIs that should integrate the disease. This is typically some number of sine qua non PHIs or combinations of sine qua non major and minor PHIs. In addition, the voting strength of diseases is also used to establish the integration threshold. The voting strength of a disease again reflects how much “attention” the Arbiter gives that disease object. Typically, if the patient is answering all of the questions in the affirmative, that is, the patient has all of the symptoms of the disease, then the voting strength is increased. This again tends to reduce the number of questions that patient has to answer. Thus the decision to integrate a disease object can be based on the score, the diagnostic momentum, or the combination of sine qua non major or minor PHIs specified by the author.
Continuing at a decision state 818 of
Returning to decision state 810 of
Referring back to
In any case, once the loop completes at state 164, process 150 advances to state 166 and takes an appropriate action based on the cause and condition of the system upon completion of the Arbiter loop. Examples of the appropriate action could be calling an emergency telephone number (e.g., 911), scheduling a reenter consultation, stopping to perform a self or assisted physical examination maneuver, or stopping to perform a home lab test. Process 150 concludes at an end state 168, and control then passes back to the main diagnostic system.
Referring to
Referring to
Referring to
When the computing device 1610 is connected with the server(s) 1650, the web site may optionally provide updates on new disease information or about new laboratory tests, special studies, imaging modality of choice and treatment of choice. In addition, the computing device 1610 can optionally be linked to the network 1640 to allow instantaneous reporting of and downloading information about, for example, possible epidemics or the use of weapons of mass destruction (WMD). In another embodiment, the computing device 1610 runs only when connected to the server(s) 1650.
The computing device 1610 includes a processor 1612, a display 1614, and one or more input devices 1616. The processor 1612 is in data communication with a data storage 1618 for storing one or more databases having medical data used by the system. In certain embodiments, the data storage 1618 stores patient medical records, such as a patient electronic medical record. System software 1620 is executed by the processor 1612. The system software 1620 can include an application graphical user interface (GUI). The application GUI can include a database interface to the data storage 1618 of the computing device. In certain embodiments, the software is loaded from the data storage 1618. In embodiments where the computing device 1610 communicates with a web site, the processor utilizes browser software in place of or in addition to the software 1620.
In computer software terms, an object is combination of data and processes that manipulate the data. The data are said to be “encapsulated,” meaning that the data is hidden, so that a user of the object only sees processes that can be invoked. Using an object's processes, one can then manipulate the data without having to know the exact location and format of the data. When more than one copy of the object is required, one can make copies of the data, but use the same process set to manipulate each of the copies as needed. This set of processes can then be thought of as an “engine” that controls or represents the objects' behavior, whether there are 10 or 10,000 object copies, for example.
This section describes a diagnostic paradigm that uses software objects to establish a broad, generalized software environment for medical diagnosis, which is used to define and develop the programming elements of medical diagnosis. The objects are then used to guide and control the diagnostic process, to conduct the patient interview, to perform related analytical tasks, and to generate diagnoses. A software object is a fundamental software structure that can be used to organize the processes and data of a computer program in such a way as to make possible very complicated applications. This description will discuss novel uses of object oriented programming (OOP) in medical diagnosis, such as the use of software objects for the purpose of fully automated medical diagnosis, the entire/overall method of dynamically assembling the components of diagnosis in the form of objects, and then letting the objects interact to compute a result such as a diagnosis.
Defining and creating software objects is well-known to any programmer trained in object-oriented programming. Using an OOP-capable compiler, the programmer defines the data that represent the object and the actions that the object can perform. At run time, the program creates an object, supplies the data that define the object, and then manipulates the object using the object actions. The program can create any number of objects as needed. Each object can be independently initialized, manipulated, and destroyed.
In an object-based (OB) method, software objects are used as active, intelligent agents that represent all of the functionality and all of the data in suitably organized roles. It is important to note in this metaphor that all of the disease objects, which are virtual “specialists” for a single disease, are allowed to monitor the questions and answers of other objects. Each object may get a turn at evaluating the patient data in terms of its own symptom pattern.
As an actual patient symptom set is built up, disease objects judge themselves and return a probability that they are the correct diagnosis. The emergent effect is a patient interview and a diagnostic evaluation that, by design, constantly stays focused on the most likely set of diseases of the patient. Carefully focused questions are used to eliminate or reduce the likelihood of diseases, to promote others into the “realm of suspicion,” and to expand the search in a promising direction, based on the data being obtained from the patient.
A software “object” is basically a data structure plus associated processes that can do things with, for or to the data. An important property of an object is that the object's data can be hidden behind the object's processes, so that the outside user of the object can only see and use object processes that can be invoked to access the data. The object is said to “hide” data; it provides the powerful ability of decoupling the world that uses an object from the object itself.
While specific blocks, sections, devices, functions and modules may have been set forth above, a skilled technologist will realize that there are many ways to partition the system, and that there are many parts, components, modules or functions that may be substituted for those listed above.
While the above detailed description has shown, described, and pointed out the fundamental novel features of the invention as applied to various embodiments, it will be understood that various omissions and substitutions and changes in the form and details of the system illustrated may be made by those skilled in the art, without departing from the intent of the invention.
This application claims the benefit of U.S. Provisional Application No. 60/915047, filed Apr. 30, 2007, which is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
60915047 | Apr 2007 | US |