This is an archive of an inactive wiki and cannot be modified.

This is one of the possible Use Cases.

1. Abstract

Decision Support systems aid in the process of decision making, especially decision making that relies on expertise. The use cases in the Decision Support category are concerned with supporting the creation of , use of, and reasoning with rules that are needed to enable this expert decision making.

For complex decision support systems, it is expected that rules will be furnished by a variety of different knowledge bases and expert systems. For example, medical decision support systems, such as the ones discussed in the narrative below, might use rules from pharmaceutical knowledge bases, data bases giving laboratory results, and patient data bases, among others. Rules interchange is therefore of paramount importance.

This is an abstraction and analysis of the use cases in the Decision Support category. It also contains a relatively large use case (in the domain of medical decision making) that is a synthesis of some of the posted use cases.

Rules interchange plays an important role for the following functionalities:

This synthesized case, described in more detail in Section 9, incorporates elements of the following use cases: Decision Making in Health Care, Product Compatibility, and Distributed e-Learning. Since the use case of Distributed e-Learning was somewhat high-level, the synthesized case adds some concrete detail to this use case.

2. Status

This synthesis/abstraction/analysis was written by Leora Morgenstern, based on use cases proposed by Igor Mozetic, Christine Golbreich, Ian Horrocks, Michael Sintek, Giorgos Stamou, Sandro Hawke, Deborah Nichols, and Rewerse.

It is currently in draft form.

3. Links to Related Use Cases

This is based on the Use Cases in the Decision Support Category, and is thus related to the following use cases:

It is also closely connected to other cases proposed by the RIF WG, including such cases in the Policy-Based Transaction category as


(e.g., credit card processing, automated trust establishment for accessing medical records, etc.)

4. Relationship to OWL/RDF Compatibility

It is expected that the knowledge in the various domains could and probably would be expressed in OWL and/or RDF, and that OWL/RDF compatibility is therefore necessary.

5. Examples of Rule Platforms Supporting this Use Case

The following platforms support specific individual use cases and/or part of the synthesized larger use case.

6. Benefits of Interchange

7. Requirements on the RIF

These requirements have been aggregated and synthesized from the various use cases in the Decision Support category:

8. Breakdown

8.1. Actors and their Goals

(Synthesized and slightly modified from the various use cases)

8.2. Main Sequence

See narrative.

8.3. Alternate Sequences

Various permutations of the steps in the narrative are possible.

8.3.1. (Title of Alternate Sequence)

9. Narratives

9.1. The Case of the Forgetful Diabetic

Bob, 62 years old and reasonably healthy, has been going to his internist, Dr. Rosen, for several years for control of his Type II diabetes. Originally his diabetes was controlled through diet and moderate exercise. However, eventually, Bob’s blood glucose level began to rise, even under this regimen. Dr. Rosen used the AutoDoc system to help him decide when to switch to medications and which drugs to prescribe. The AutoDoc system uses two sources when making its recommendations: a laboratory database and a knowledge base giving guidelines for the use of pharmaceuticals.

The laboratory database includes specific results for patients, e.g., such as fasting blood glucose levels for Bob. It also contains rules specifying when test results are outside of the normal range:

IF FastingBloodGlucoseLevel(patient) > 126 mg/dl 
THEN BloodGlucoseControlled(patient) = false.

The pharmaceutical knowledge base contains comprehensive information about drugs, including dosage, indications, contraindications, side effects, and clearance times. An example of a rules expression a contradiction for a drug is

IF  ContrastDye(x)  
   THEN Contraindicated(Metformin, x).

AutoDoc uses the rules from these two sources, along with its own rules, such as:

IF  (BloodGlucoseControlled(patient) = false and OnDietExerciseRegimen(patient) = true) 
THEN NeedPrescribe(GlucoseControlMeds, patient) = true.

Other examples of rules: If a patient is on a glucose control medication, and his blood glucose level is uncontrolled, that he needs to be switched; medications with less severe side effects and less frequent side effects are preferred, etc.

These rules are used, together with the rules obtained from the laboratory data base and the pharmaceutical knowledge base, to determine the appropriate course of treatment for Bob.

Rules interchange is a prerequisite for AutoDoc, since it uses rules from two different sources, in addition to its own rules. Reasoning with rules from all sources is enabled if the rules from all sources can be mapped to a RIF.

In this case, AutoDoc alerted Dr. Rosen when diet and exercise were no longer sufficient, and recommend Diamicron (80 mg., tid) for Bob. When that no longer controlled his glucose levels, it recommended switching to Metformin (70 mg., tid).

Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI. When asked about current medication, Bob told Dr. Cervello that he was taking Diamicron to control his diabetes, forgetting that he had been switched to Metformin. This was potentially problematic, since Metformin should not be taken close to the administration of a contrast injection.

Fortunately, when Bob went to the lab to schedule his MRI, the medical receptionist pulled up MEDIC (Medical Event and Drug Interaction Consultant), the hospital’s new automated system, which checks for incompatible medical events and/or drugs (e.g., liposuction scheduled during pregnancy, blood thinners prescribed before surgery, etc.).

MEDIC uses a variety of sources in its reasoning, including

In this case, MEDIC uses all three sources, and pulls up the following information:

MEDIC therefore determines that Bob should not be taking the contrast MRI.

For MEDIC to work, the rules from these different sources must be mapped to a unified interchange format.

The medical receptionist tells Bob that there is a problem scheduling the MRI. She talks to the radiologist, Dr. Bild, who explains to Bob that he needed to discontinue the Metformin for a few days before taking the MRI. The MRI is rescheduled for a few days later, after which time Bob begins taking Metformin again. The day after the MRI is performed, Dr. Bild goes over the MRI scan and determines that Bob may have suffered some mild damage due to his recent concussion. Unfortunately, the brain anatomical changes that he has seen also indicate that Bob may be suffering from mild Alzheimer’s disease.

Dr. Bild transmits his report to Bob’s neurologist Dr. Cervello. The next morning, Dr. Cervello gives a short summary of his and Dr. Bild’s findings to his fellows and residents and asks them how they would treat Bob. For various reasons (missing lectures on brain anatomy due to the flu; transferring from different residency programs; slept through most of medical school), most can’t follow his brief presentation, and can’t respond to Dr. Cervello’s questions. None of them are familiar with medical protocols for treating mild Alzheimer’s. Dr. Cervello tells them that they had better be better prepared the next day. That evening, they hunker down in the residents’ lounge and, each on a separate laptop connected to the internet, use the hospital’s new e-learning system TrainADoc to prepare themselves for the next day’s encounter. Each starts TrainADoc by answering a short questionnaire that assesses their knowledge or lack thereof of various subareas of neurology. The TrainADoc searches the internet for various learning sources to customize a program for each student based on his profile. Each learning source includes a set of courses, each of which has attached to it rules specifying the prerequisites for the course and the skills/knowledge learned once the course has been completed.

TrainADoc has general rules specifying that a student can take a course only if he has completed the prerequisites or his profile indicates that he already has the requisite knowledge.

Using the rules attached to the various learning sources, the profiles that the students have completed, and its own rules, TrainADoc customizes a set of materials for each student. It then brings back the materials that will fill in their gaps of knowledge. The students each spend several hours going through their materials. The next day, they are able to answer Dr. Cervello’s questions.

Having a RIF is a prerequisite for TrainADoc: The rules of each of the learning sources that is found on the internet must map onto the RIF in order for TrainADoc to customize each resident’s learning program.

The RIF is used in this use case to enable interchange between general knowledge bases (pharmaceutical knowledge bases, medical protocol knowledge bases), specific data (patient records, lab results, profiles of medical residents), and decision support systems.

10. Commentary

This use case takes place in the medical domain. It should be emphasized, however, that the principles illustrated carry over to many other domains. For example, situation assessment is a critical part of military decision making: one needs to evaluate a specific situation to determine whether reinforcements are needed. It is also important for investment applications, where the first step is determining the financial situation of a customer, and then determining his needs (for investments, for tax relief). The analogies carry over to the other functionalities discussed, including prescribing courses of action, and professional education.

In all these domains, it is to be expected that rules will be culled from a variety of sources. For example, for situation assessment in the military domain, data comes multiple sources, including data bases, human observation, and automated sensors; policies, expressed as rules, come from upper management; operating procedures come from middle management. For situation assessment in the investment banking domain, data comes from records of financial transactions kept in multiple data bases; banking regulations come from individual banks, as well as the government. Having a unified rules interchange format so that a decision support system can reason with rules from these multiple sources is thus a prerequisite for these domains as well.