AI research started from automated reasoning. Computers can help us on many medical issues, e.g., medical decision making. But not enough applications have been seen so far. I am interested in representing human knowledge to computers (e.g., retrived from the web and structurally organized) and let them help medical personnel in clinical practice (e.g., confirming decisions or suggesting causes/solutions).
Medical Treatment Conflict Resolving in Answer Set Programming, AAAI-11, San Francisco, California
Medical reasoning (reasoning over medical domain problems, such as
making treatment decisions) can be a good application knowledge
representation and automated reasoning for the following reasons:
In contrast, computers have large memory and fast processing speed, and more important, the ability to collect and exchange volume information efficently. If we can implement an approach to easily represent the medical knowledge of many veteran physicans to the computer, it can help an unexperience physician to make decisions. It's like he/she is having a very ``smart'' and ``knowledgable'' assistant.
In building a reasoning system to solve a treatment conflicting problem, we have realized that how important non-monotonicity is for medical reasoning, and discovered the great expressive power of answer set programming, a non-monotoic logic programming paradigm. So we decide to study the non-monotonicity in medical reasoning and implement automated reasoning on certain problems that drive physicians nuts. We will also take a look at the application of ASP's extension, such as probablistic reasoning and (numeric) constraint solving, for reasoning over medical domain.
The medical information below is for computer science research only. It should NOT be used in any medical practice and/or as a reference, support or proof. Please consult professional medical personnel or formal medical publications. The authors hold NO responsibility for any consequence of using this information.
Reasoning for medical diagnosis has two interesting features. First, not all information is complete and change from time to time a lot. Sometimes the physician may know whether a patient is allergy to a medication. Sometimes, not. The reasoning system needs to be able to work correctly in both cases. We call this reasoning about knowledge. Second, medical knowledge has exceptions. Medication allergy is one kind of exceptions to the treatment of a symptom. But in most cases, physicians do according to some default procedures. Hence, the reasoning system needs to handle default reasoning.
The above two features requires non-monotonicity - when new information becomes available, the conclusion will be changed.
Let's take a look at an example, drug-based epilepsy treatment. Most epilepsy patients are treated using medication and can control epilepsy well in medication. But deciding the medication and the dose for each individual is an ``iterating'' process. The physician has to work with the patient closly to alternate the prescription over a long time. This is what you will see in chronological order:
1. The physician and the patient discuss a lot to determine whether
medication is needed - if the seizure is rare and mild, maybe the
physician will let you live with it.
Each step above requires non-monotonicity.
In the example above, much information (time-variant and patient-specified) needs to be entered by physicians to computers on field. This rises the ``user-friendly'' concern. The language/interface for physicians to pass information to computers has to be very simple, as close to natural language as possible. We do not want the physicians to struggle with semantics much.
Satisfying all above concerns, A-prolog, the language for Answer Set Programming (ASP), is a good candidate. ASP has a large user base with industry input. The ASP community has combined ASP with CSP and CLP to support both boolean and numeric constraints, and extended ASP for probabilistic reasoning. Either numbers and probabilities (a special kind of numbers) are frequently used in medical domain.
One case that computer-aided medical reasoning can be useful is resolving treatment conflict. Conflicts (e.g., two medication can generate toxic chemicals while each of them treats one symptom on the patient) happen a lot in medical reasoning. In this case, we need to tell computers which symptom is the priority, i.e., symptom priority ranking. With this information, an alternative compromising treatment can be made by focusing on the priority.
We use a simple running example to introduce our idea. There are two symptoms. Hemoptysis (i.e., coughing up blood) can be relieved by increasing blood coagulation whereas hypertension (i.e., high blood pressure) can be relieved by decreasing blood coagulation. We have two medications, A and B, such that A increases blood coagulation whereas B decreases blood coagulation.
It is very easy to decide the treatment for either one of the two symptoms. But it becomes difficult when the patient suffers both, because the treatments to the two symptoms, i.e., increasing and decreasing blood coagulation, conflict with each other.
To resolve treatment conflict, physicians can prioritize symptoms (e.g., according to life-threatening level) on field. The symptom priority ranking tells that relieving which symptom is the priority for the patient. Though priority ranking of symptoms is not textbook knowledge, it is an important criterion for physicians to make decisions. In our example, if hemoptysis is a higher priority, then the physician will still prescribe medication $A$ but in half of its normal dose. Ranking symptom priority has been studied in medical community for a while.
We can then represent the knowledge (pure knowledge, without any information about patients) as follows:
The knowledge above can be encoded into ASP as follows.
% knowledge 1-2/rules 1 and 2: should(increase, X) :- hemoptysis(X), not -should(increase, X). should(decrease, X) :- hypertension(X), not -should(decrease, X). % knowledge 3-5/rules 3 and 4: takes(X, a) :- should(increase, X), not takes(X, b), not -priority(hemoptysis, X). takes(X, b) :- should(decrease, X), not takes(X, a), not -priority(hypertension, X). % knowledge 6/rule 5: half_dose(X, a):- should(decrease, X), takes(X, a). % knowledge 7/rule 6: half_dose(X, b) :- should(increase, X), takes(X, b).
Now let's create a virtual patient, Tom, such that
hemoptysis(tom). hypertension(tom). priority(hemoptysis, tom). % rule p1 -priority(hypertension, tom). % rule p2
The answer set is
half_dose(tom,a) takes(tom,a) should(increase,tom) should(decrease,tom)
If we comment rules p1 and p2 (telling no priority information to the computer), an additional answer set pops up.
half_dose(tom,b) takes(tom,b) should(increase,tom) should(decrease,tom)
More ``killer'' applications of ASP in medical reasoning are coming.