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:
- Improving situation assessment, e.g., determining when a patient needs to be put on medication, or have his medication switched.
- Prescribing a course of action, e.g., determining which drug is best for a patient in a particular circumstance.
- Improving event planning, e.g., determining whether a patient can be scheduled for a procedure given the medication that he is currently taking.
- Assisting professional education, e.g., determining how to customize training materials for residents with widely different levels of knowledge.
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:
Automatically generated rules (Decision Support use case)
Decision making in Health Care(Decision Support use case; part of the synthesized Decision Support use case)
Distributed e-Learning(Decision Support use case; part of the synthesized Decision Support use case)
Fuzzy Reasoning with Brain Anatomical Structures (Decision Support use case)
Organizing a Vacation with Friends (Decision Support use case)
Product Compatibility (Decision Support use case; part of the synthesized Decision Support use case)
Situation Assessment and Adaptation (Decision Support use case; referred to in the discussion below)
Personalisation and Uncertainty -- Representing some levels of fuzzy rules with the help of datatype built-ins (Decision Support use case)
It is also closely connected to other cases proposed by the RIF WG, including such cases in the Policy-Based Transaction category as
Automated Trust Establishment for Accessing Medical Records (will need something like this for scenario in which different medical personnel access a patient's records)
and
Scoped negation, Encapsulation (for formulation of queries relating to medical event/drug interaction)
(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.
- Predictive Model Markup Language (work by Data Mining Group) (for Automatically Generated Rules)
- Triple (for Distributed e-Learning)
- XChange (for Organizing a Vacation with Friends)
6. Benefits of Interchange
- Interoperability across ontologies in different domains (diseases, drugs, medical events, anatomical structures).
- Interoperability across different systems and knowledge bases (general medical knowledge bases, hospital patient data base, hospital system tracking medical events; hospital system tracking drugs that are prescribed; drug interaction data bases, etc.).
- Allow use of existing knowledge bases, such as medical knowledge bases and pharmaceutical knowledge bases.
7. Requirements on the RIF
These requirements have been aggregated and synthesized from the various use cases in the Decision Support category:
- Compatibility with OWL.
- Reasoning with ontologies and rules.
- Tagging for various rule dialects.
- Capability for relatively easy transformation of rules for various purposes (ontology mapping, distributed inferencing)
- Support for basic numeric computations and aggregate functions.
- Representation for logical information, such as cardinality constraints, existential quantification, disjointness, etc.
- Declarative semantics; operational semantics.
- Human readable syntax.
- Meta-reasoning capabilities.
- Distributed Inferencing.
- Representation of probabilistic and uncertain information, including representation of degrees of truth.
- Representation of different kinds of rules (deductive, normative, and reactive).
- Ability to manage rule sets dynamically under changing conditions.
8. Breakdown
8.1. Actors and their Goals
(Synthesized and slightly modified from the various use cases)
- Patient - wants to get the best treatment for his situation
- Various medical personnel (internist, neurologist, radiology tech, radiologist, neurology residents and fellow; see narrative below for details) - want to diagnose the patient’s medical condition and prescribe the treatment optimal for the patient
- Various medical personnel (as above) - want to avoid any adverse medical events
- Data gatherer (for automatically generating rules) - wants to collect the data needed for learning rules
- Automated Learner (as above) - wants to transform the data collected into rules according to some criteria
- Reasoner (as above) - wants to derive answers to queries from the rules
- Evaluator (as above) - wants to evaluate the rules
- Consumer (medical personnel) - wants to apply the rules to a patient’s specific case
- Human Learner - wants to retrieve learning material or learning paths to reach some learning goal
- Learner Agent - wants to act on behalf of learner to obtain materials suited to Human Learner, based on personal profile containing already learned material and personal preferences
- Learning Material Provider - wants to offer learning material, some of which may involve payment, to Human Learner
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
- the pharmaceutical knowledge base, described above.
- the patient data bases, which gives the patient record, including the medications a patient is currently taking.
- the hospital medical event protocol knowledge base, which details the protocol used for different medical procedures.
In this case, MEDIC uses all three sources, and pulls up the following information:
- Metformin is contraindicated with contrast dye.
- Bob is taking Metformin.
- The contrast MRI requires as one of its steps injecting the patient with contrast dye.
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.