Expert system & Clinical Decision Support Systems

Expert system & Clinical Decision Support Systems

 Tursunova Madina Amonovna

20 22

Artificial Intelligence in Medicine (AIM)

From the very earliest moments in the modern history of the computer, scientists have dreamed of creating an ‘electronic brain’. Of all the modern technological quests, this search to create artificially intelligent (AI) computer systems has been one of the most ambitious and, not surprisingly, controversial.

Medical artificial intelligence (AIM) is primarily concerned with the construction of AI programs that perform diagnosis and make therapy recommendations.

Unlike medical applications based on other programming methods, such as purely statistical and probabilistic methods, medical AI programs are based on symbolic models of disease entities and their relationship to patient factors and clinical manifestations .

From the very earliest moments in the modern history of the computer, scientists have dreamed of creating an ‘electronic brain’. Of all the modern technological quests, this search to create artificially intelligent (AI) computer systems has been one of the most ambitious and, not surprisingly, controversial.

It also seems that very early on, scientists and clinicians alike were captivated by the potential such a technology might have in healthcare.

With intelligent computers able to store and process vast stores of knowledge, the hope was that they would become perfect ‘doctors in a box’, assisting or surpassing clinicians with tasks like diagnosis. With such motivations, a small but talented community of computer scientists and healthcare professionals set about shaping a research program for a new discipline called Artificial Intelligence in Medicine (AIM). These researchers had a bold vision of the way AIM would revolutionize healthcare, and push forward the frontiers of technology.

Clinical Decision Support Systems (CDSS)

Clinical (or Diagnostic) Decision Support Systems (CDSS) are interactive computer programs, which directly assist physicians and other health professionals with decision making tasks1980s.

For medical diagnosis, there are scopes for ambiguities in inputs, such as history, and laboratory tests.

For medical diagnosis, there are scopes for ambiguities in inputs, such as history (patients description of the diseased condition), physical examinations (especially in cases of uncooperative or less intelligent patients), and laboratory tests (faulty methods or equipment). Moreover, for treatment, there are chances of drug reactions and specific allergies, and patients' non-compliance of the therapy due to cost or time or adverse reactions.

In all these areas, computers can help the clinician to reach an accurate diagnosis faster. Another new branch of medicine pharmacogenomics is the product of breeding between information technology and biology, leading to individualized treatment.

The basic components of a CDSS include a dynamic (medical) knowledge base and an inferencing mechanism (usually a set of rules derived from the experts and evidence-based medicine). It could be based on Expert systems or artificial neural networks or both (Connectionist expert systems).

Types of CDSS (Clinical Decision Support System)

• Architecture

• Stand alone program Decision support component
• Stand alone program
• Decision support component

• Target domain

• Large Scale Focused CDSS
• Large Scale
• Focused CDSS

• Target users

• physicians Non-physicians (nurses, patients, other)
• physicians
• Non-physicians (nurses, patients, other)

Purpose of systems

• Hospital information systems

• Only electronic patient record information management.
• Only electronic patient record information management.

• Notification Systems

• Specific reminders at particular clinical situations.
• Specific reminders at particular clinical situations.

• Acute Care Systems

• Help to assess faster all the parameters when a quick estimation and decision has to be made.
• Help to assess faster all the parameters when a quick estimation and decision has to be made.

• Laboratory Systems

• Support the work with ordering laboratory tests and assessing the results
• Support the work with ordering laboratory tests and assessing the results

• Drug therapy systems

• Support drug choosing, dosing, preventing adverse drug effects. Reviewing latest information on drugs.
• Support drug choosing, dosing, preventing adverse drug effects. Reviewing latest information on drugs.

• Quality Assurance and Administration Systems

• Support the heath care management at the hospital level. Focusing on the whole health care system rather then on a particular patient. Cost analysis.
• Support the heath care management at the hospital level. Focusing on the whole health care system rather then on a particular patient. Cost analysis.

• Educational Systems

• Intended for the use by medical students or young doctors in education.
• Intended for the use by medical students or young doctors in education.

• Research Systems

• Clinical Trials and other medical research support
• Clinical Trials and other medical research support

Critical Mass problem (Miller)

The CDSSs can be used at several stages of treating of a patient:

• establishing the correct diagnosis for the patient coming with certain complains
• choosing the best therapeutic strategy according to the situation and patient’s preferences
• monitoring the therapy
• assisting at the choosing the best drug from a specified drug-group, drug dosing and observing the possible drug-drug interactions
• preventive medical examinations and tests
• browsing the knowledge base of the CDSS

Expert system

An expert system is a class of computer programs developed by researchers in artificial intelligence during the 1970s and applied commercially throughout the 1980s.

Expert systems are computerized tools designed to enhance the quality and availability of knowledge required by decision makers in a wide range of industries.

Expert system Types of problems solved by expert systems

E-commerce

Decision Support

Business

Engineering

Military

Marketing/Sales

Agriculture

Medical

Web Design

Human Resources

Computer Sciences

Legal

Science

Construction

Transportation

Research &Development

Environmental

Typically, the problems to be solved are of the sort that would normally be tackled by a human "expert“ a medical or other professional, in most cases.

Generally expert systems are used for problems for which there is no single "correct" solution which can be encoded in a conventional algorithm” one would not write an expert system to find shortest paths through graphs, or sort data, as there are simply easier ways to do these tasks.

Simple systems use simple true/false logic to evaluate data, but more sophisticated systems are capable of performing at least some evaluation taking into account real-world uncertainties, using such methods as fuzzy logic. Such sophistication is difficult to develop and still highly imperfect.

Expert system

• Specifically, the goals of developing expert systems for medicine are as follows
• to improve the accuracy of clinical diagnosis through approaches that are systematic, complete, and able to integrate data from diverse sources;
• to improve the reliability of clinical decisions by avoiding unwarranted influences of similar but not identical cases ;
• to improve the cost efficiency of tests and therapies by balancing the expenses of time, inconvenience against benefits, and risks of definitive actions ;
• to improve our understanding of the structure of medical knowledge, with the associated development of techniques for identifying inconsistencies and inadequacies in that knowledge ;
• to improve our understanding of clinical decision-making, in order to improve medical teaching and to make the system more effective and easier to understand.

Expert system Mycin

The system was designed to diagnose infectious blood diseases and recommend antibiotics, with the dosage adjusted for patient's body weight the name derived from the antibiotics themselves, as many have the suffix "-mycin".

Mycin operated using a fairly simple inference engine, and a knowledge base of ~500 rules. It worked by querying the physician through a long series of simple yes/no or textual questions, at the end of which, it provided a list of possible culprit bacteria, its confidence in each diagnosis, the reasoning (referring to individual questions and answers) behind each diagnosis, and its recommended course of drug treatment.

Mycin was an expert system developed over 5 or six years in the early 1970s at the Stanford University, written in Lisp, by Edward Shortliffe under Bruce Buchanan and others; it derived from Dendral, but considerably modified it. The system was designed to diagnose infectious blood diseases and recommend antibiotics, with the dosage adjusted for patient's body weight the name derived from the antibiotics themselves, as many have the suffix "-mycin".

Mycin operated using a fairly simple inference engine, and a knowledge base of ~500 rules. It worked by querying the physician through a long series of simple yes/no or textual questions, at the end of which, it provided a list of possible culprit bacteria, its confidence in each diagnosis, the reasoning (referring to individual questions and answers) behind each diagnosis, and its recommended course of drug treatment.

In fact, Mycin was never actually used in practice. This wasn't because of any weakness in its performance — in tests it outperformed members of the Stanford medical school. It was as much because of ethical and legal issues related to the use of computers in medicine — if it gives the wrong diagnosis, who can be held responsible? Issues with whether human experts would find it acceptable to use arose as well.

A difficulty that arose during the writing of this and subsequent expert systems has been the extraction of the knowledge from human experts into the rules, the so-called knowledge engineering.

Research conducted at the Stanford Medical School found MYCIN to have a correct diagnosis rate of about 65%, which was better than most physicians who were not specialists in diagnosing bacterial infections, and only slightly worse than those physicians who were themselves experts in the field (average correct diagnosis rate of about 80%).

Expert system CADUCEUS

CADUCEUS was a medical expert system developed in the mid-1980s. Their motivation was an intent to improve on MYCIN - which focussed on blood-borne infectious bacteria - to focus on more comprehensive issues than a narrow field like blood poisoning; instead embracing all internal medicine. CADUCEUS eventually could diagnose ~1000 diseases.

CADUCEUS was a medical expert system developed in the mid-1980s (but first begun in the 1970s- it took that long to build the knowledge base) by Harry Pople (of the University of Pittsburgh), building on Pople's years of interviews with Dr. Jack Meyers, one of the top internal medicine diagnosticians and a professor at the University of Pittsburgh. Their motivation was an intent to improve on MYCIN - which focussed on blood-borne infectious bacteria - to focus on more comprehensive issues than a narrow field like blood poisoning (though it would do it in a similar manner); instead embracing all internal medicine. CADUCEUS eventually could diagnose ~1000 diseases.

While CADUCEUS worked using an inference engine similar to MYCIN's, it made a number of changes (like incorporating abductive reasoning) to deal with the additional complexity of internal disease- there can be a number of simultaneous diseases, and data is generally flawed and scarce.

Expert laboratory information systems

A  Laboratory Information Management System  (LIMS), sometimes referred to as a Laboratory Information System  (LIS) or  Laboratory Management System  (LMS), is a  software -based  laboratory  and information management  system  that offers a set of key features that support a modern laboratory's operations. 

Laboratory expert systems usually do not intrude into clinical practice. This systems embedded within the process of care, and with the exception of laboratory staff, clinicians working with patients do not need to interact with them. For the ordering clinician, the system prints a report with a diagnostic hypothesis for consideration, but does not remove responsibility for information gathering, examination, assessment and treatment. For the pathologist, the system cuts down the workload of generating reports, without removing the need to check and correct them.

Expert laboratory information systems Pathology Expert Interpretative Reporting System (PEIRS)

A more general example of Expert laboratory information systems is Pathology Expert Interpretative Reporting System. During its period of operation, PEIRS interpreted about 80–100 laboratory reports a day with a diagnostic accuracy of about 95%. It accounted for about 20% of all the reports generated by the hospital’s chemical pathology department. PEIRS reported on thyroid function tests, arterial blood gases, urine and plasma catecholamines, hCG (human chorionic gonadotrophin) and alfafetoprotein (AFP ), glucose tolerance tests, cortisol, gastrin, cholinesterase phenotypes and parathyroid hormone-related peptide (PTH-RP).

Expert system

Expert systems differ from conventional applications software in the following ways:

• The expert system shell, or interpreter.
• The existence of a "knowledge base," or system of related concepts that enable the computer to approximate human judgment.
• The sophistication of the user interface.

Expert system Individuals involved with expert systems

There are generally three individuals having an interaction with expert systems.

Primary among these is the end-user .

In the building and maintenance of the system there are two other roles:

• the problem domain expert knowledge engineer
• the problem domain expert
• knowledge engineer

Expert system The end user

The end-user usually sees an expert system through an interactive dialog.

As can be seen from this dialog, the system is leading the user through a set of questions, the purpose of which is to determine a suitable set of restaurants to recommend. In expert systems, dialogs are not pre-planned. There is no fixed control structure. Dialogs are synthesized from the current information and the contents of the knowledge base. Because of this, not being able to supply the answer to a particular questions does not stop the consultation. In expert systems, dialogs are not pre-planned. There is no fixed control structure. Dialogs are synthesized from the current information and the contents of the knowledge base. Because of this, not being able to supply the answer to a particular questions does not stop the consultation.

It is very difficult to implement a general explanation system (answering questions like Why and How) in traditional systems. The response of the expert system to the question WHY is an exposure of the underlying knowledge structure. It is a rule; a set of antecedent conditions which, if true, allow the assertion of a consequent. The rule references values, and tests them against various constraints or asserts constraints onto them. This, in fact, is a significant part of the knowledge structure. There are values, which may be associated with some organizing entity. For example, the individual diner is an entity with various attributes (values) including whether they drink wine and the kind of wine. There are also rules, which associate the currently known values of some attributes with assertions that can be made about other attributes. It is the orderly processing of these rules that dictates the dialog itself.

Expert system The knowledge engineer

Knowledge engineers are concerned with the representation chosen for the expert's knowledge declarations and with the inference engine used to process that knowledge.

Expert system The knowledge engineer

Knowledge engineers are concerned with the representation chosen for the expert's knowledge declarations and with the inference engine used to process that knowledge. There are several characteristics known to be appropriate to a good inference technique.

1. A good inference technique is independent of the problem domain.

In order to realize the benefits of explanation, knowledge transparency, and reusability of the programs in a new problem domain, the inference engine must not contain domain specific expertise.

2. Inference techniques may be specific to a particular task, such as diagnosis of hardware configuration. Other techniques may be committed only to a particular processing technique.

3. Inference techniques are always specific to the knowledge structures.

4. Successful examples of rule processing techniques include:

(a) Forward chaining

(b) Backward chaining

Rule-based expert systems

In an expert system, the knowledge is usually represented as a set of rules. The reasoning method is usually either logical or probabilistic. An expert system consists of three basic components :

● a knowledge base , which contains the rules necessary for the completion of its task;

● a working memory in which data and conclusions can be stored;

● an inference engine which matches rules to data to derive its conclusions.

Rule-based expert systems

For a task like interpreting an ECG, an example of a rule that could be used to detect asystole might be:

RuleASY1:

If heart rate 0

then conclude asystole

If the expert system was attached to a patient monitor then a second rule whose role was to filter out false asystole alarms in the presence of a normal arterial waveform might be:

Rule ASY2:

If asystole

and (ABP is pulsatile and in the normal range)

then retract asystole

In the presence of a zero heart rate, the expert system would first match rule ASY1 and conclude that asystole was present. However, if it next succeeded in matching all the conditions in rule ASY2, then it would fire this second rule, which would effectively filter out the previous asystole alarm. If rule ASY2 could not be fired because the arterial pressure was abnormal, then the initial conclusion that asystole was present would remain.

Expert system The Inference Rule

An understanding of the " inference rule " concept is important to understand expert systems. An inference rule is a statement that has two parts, an if-clause and a then-clause .

IF

It is raining

THEN

You should wear a raincoat

An expert system's rulebase is made up of many such inference rules. They are entered as separate rules and it is the inference engine that uses them together to draw conclusions. Because each rule is a unit, rules may be deleted or added without affecting other rules (though it should affect which conclusions are reached). One advantage of inference rules over traditional programming is that inference rules use reasoning which more closely resemble human reasoning.

Expert system The Inference Rule

With Exsys CORVID, these rules are very similar to the form that you would use to explain the heuristic using English and algebra. For example, “If the investment customer has a high risk tolerance and requires rapid growth to reach their objectives, Mutual Fund X would be a good choice.” In a rule this would become:

IF

The customer has high-risk tolerance

AND

Meeting objectives requires rapid growth

THEN

Mutual Fund X is a good choice

This rule includes a small amount of syntax, but it is still very easy to read and understand what it means. If you built similar rules for each of the heuristics in the decision-making process, you would have the logic for the expert system.

Expert system Arden syntax

The Arden syntax supports the generation of rules for alerts or reminders.

Arden syntax - A standard language for writing situation-action rules that can trigger alerts based on abnormal clinical events detected by a clinical information system .

Expert system Arden syntax

To detect a low potassium level and to identify thiazides as a possible cause, the following MLM is created:

DATA: POTAS-STORAGE := event {serum potassium}

POTAS := LAST {serum potassium}

THIAZIDE-US E := {current prescription for thiazides}

EVOKE:

POTAS-STORAGE

LOGIC:

IF POTAS

ELSE CONCLUDE FALSE

ACTION:

SEND "Patient is hypokalemic. This condition could be caused by thiazides."

This Panel provides an example of how to write rules in the Arden syntax that monitor potassium levels in patients treated with a thiazide diuretic.

Thiazide diuretics may cause a decrease in potassium levels. If the serum potassium level decreases during a treatment with a thiazide diuretic, the clinician wishes to receive a warning indicating the diuretic as a possible cause. In addition, when starting treatment with thiazides, the clinician wants a baseline measurement of the serum potassium level.

In the example, only the medical logic of the medical logic modules (MLMs) is defined; other slots in the MLM, such as author and maintenance, are omitted. Braces are used in the Arden syntax to identify institution-specific components of the MLM (such as queries to a patient database). To detect a low potassium level and to identify thiazides as a possible cause, the following MLM is created:

Expert system Arden syntax

This MLM will be executed each time that a serum potassium level is stored in the database (the EVOKE slot). The patient data required are the last serum potassium value and whether the patient uses thiazide diuretics (the DATA slot). If the last potassium level is less than 3 (the LOGIC slot), an alert is sent to the clinician (the ACTION slot). The following statements specify that the potassium level must be measured when treatment with a thiazide is initiated:

DATA:

THIAZIDE-START := event {start of prescription for thiazides}

POTAS := LAST {serum potassium}

EVOKE:

THIAZIDE-START

LOGIC:

IF POTAS OCCURRED WITHIN 2 MONTHS PRECEDING NOW THEN CONCLUDE FALSE

ELSE CONCLUDE TRUE

ACTION:

SEND "When starting a treatment with thiazides, obtain a baseline measurement of the potassium level."

This MLM will be executed each time a patient is started on thiazide diuretics (the EVOKE slot). The patient data required involve the last serum potassium value (the DATA slot). If the last potassium value is older than 2 months (the LOGIC slot), an alert is sent to the clinician (the ACTION slot).

Expert system THE EXPERT SYSTEM SHELL

An expert system shell provides a layer between the user interface and computer operating system to manage the input and output of data. It also manipulates the information provided by the user in conjunction with the knowledge base to arrive at a particular conclusion.

While any conventional programming language can be used to build a knowledge base, the expert system shell simplifies the process of creating a knowledge base. It is the shell that actually processes the information entered by a user; relates it to the concepts contained in the knowledge base; and provides an assessment or solution for a particular problem. Thus, an expert system shell provides a layer between the user interface and computer operating system to manage the input and output of data. It also manipulates the information provided by the user in conjunction with the knowledge base to arrive at a particular conclusion. The structure of the shell is very similar to that of an interpreter or a front-end to a database program. The shell also manages the user interface, performing functions that range from the validation of numeric values entered on the screen to management of the mouse and the representation of graphical objects.

The shell is often sold as an end-product, allowing the purchaser to encode a knowledge base from scratch the same way a user would purchase a database management system. On the other hand, knowledge bases can be sold as products--where a shell or interpreter may be an incidental part of the package--in the same way a user might buy data.

Expert system THE USER INTERFACE

For the last several years, interface designs for expert systems have hinged on graphical capabilities and unconventional methods of entering data into the system . Graphical interfaces can supply information in any number of forms: simple text "dressed up" in windows, pop-up menus, or actual graphical objects.

Recently, many of those formats have been integrated into conventional applications, but they are of particular use in expert systems. An expert system may express an idea, solution, or explanation using more complex conventions than rows of numbers, pie charts, or brief messages.

Expert system THE KNOWLEDGE BASE

The main purpose of the knowledge base is to provide the guts of the expert system--the connections between ideas, concepts, and statistical probabilities that allow the reasoning part of the system to perform an accurate evaluation of a potential problem.

THE KNOWLEDGE BASE

The main purpose of the knowledge base is to provide the guts of the expert system--the connections between ideas, concepts, and statistical probabilities that allow the reasoning part of the system to perform an accurate evaluation of a potential problem. Knowledge bases are traditionally described as large systems of "if then" statements, but this description is misleading because knowledge bases may not contain definitive rules at all, but may contain only associative relationships among different concepts, statistical information about the probability of certain solutions, or simply large databases of facts that can be compared to one another based on simple conventions intrinsic to the expert system.

Expert system Prolog

Prolog is a logic programming language. Prolog is used in many artificial intelligence programs and in computational linguistics Prolog is based on first-order predicate calculus, however it is restricted to allow only Horn clauses.

Prolog is a logic programming language. The name Prolog is taken from programmation logique (French for "logic programming"). It was created by Alain Colmerauer and Robert Kowalski around 1972 as an alternative to the American-dominated Lisp programming languages. It was an attempt to make a programming language that enabled the expression of logic instead of carefully specified instructions on the computer. In some ways Prolog is a subset of Planner, e.g., see Kowalski's early history of logic programming. The ideas in Planner were later further developed in the Scientific Community Metaphor.

Prolog is used in many artificial intelligence programs and in computational linguistics (especially natural language processing, which it was originally designed for). Its syntax and semantics are considered very simple and clear. (The original goal was to provide a tool for computer-illiterate linguists.) A lot of the research leading up to modern implementations of Prolog came from spin-off effects caused by the fifth generation computer systems project (FGCS) which chose to use a variant of Prolog named Kernel Language for their operating system (but this area of research is now actually almost mortified).

Prolog is based on first-order predicate calculus; however it is restricted to allow only Horn clauses. Execution of a Prolog program is effectively an application of theorem proving by first-order resolution. Fundamental concepts are unification, tail recursion, and backtracking.

Expert system Prolog

Prolog Programming in Prolog is very different from programming in a procedural language. In Prolog you supply a database of facts and rules; you can then perform queries on the database. The basic unit of Prolog is the predicate, which is defined to be true. A predicate consists of a head and a number of arguments. For example:

cat(tom) .

This enters into the database the fact that 'tom' is a 'cat'. More formally, 'cat' is the head, and 'tom' is the single argument. Here are some sample queries you could ask a Prolog interpreter basing on this fact:

is tom a cat?

?- cat(tom).

yes.

what things are cats?

?- cat(X).

X = tom;

yes

Expert system EON/Protege

• EON is a new architecture for second generation component based Clinical Decision Support Systems developed at Stanford University
• Protege is a set of software tools (developed by the same group) for building components for a CDSS
• Therapy Helper (AIDS), Breast Cancer, Hypertension

• http://protege.stanford.edu

Expert system R1

The R1 program was a production-rule-based system written in OPS5 by John P. McDermott of CMU in 1978 to assist in the ordering of DEC's VAX computer systems by automatically selecting the computer system components based on the customer's requirements.

The R1 (later called XCon, for eXpert CONfigurer) program was a production-rule-based system written in OPS5 by John P. McDermott of CMU in 1978 to assist in the ordering of DEC's VAX computer systems by automatically selecting the computer system components based on the customer's requirements. XCON first went into use in one of DEC's plants in Salem, New Hampshire in 1980 after the joint effort between CMU and DEC in 1978 began working on adapting R1 (this effort succeeded two previous unsuccessful efforts to write an expert system to aid DEC, in FORTRAN and BASIC). It eventually had about 2500 rules in it. By 1986, it had processed 80,000 orders, and achieved 95-98% accuracy. It was estimated to be saving DEC $25M a year by reducing the need to give customers free components when technicians made errors, by speeding the assmbly process, and by increasing customer satisfaction.

XCON's success on the factory floor led DEC to rewrite XCON as XSEL- a version of XCON intended for use by DEC's salesforce to aid a customer in properly configuring their VAX (so they wouldn't, say, choose a computer too large to fit through their doorway or choose too few cabinets for the components to fit in). Location problems and configuration were handled by yet another expert system, XSITE. Legendarily, the name of R1 comes from McDermott, who supposedly said as he was writing it, "Three years ago I wanted to be a knowledge engineer, and today I are one."

McDermott's 1980 paper on R1 won the AAAI Classic Paper Award in 1999.

Integration Decision Support Systems to Hospital Information System

Decision support systems need not be ‘stand alone’ but can be deeply integrated into an electronic medical record system. Indeed, such integration reduces the barriers to using such

a system, by crafting them more closely into clinical working processes, rather than expecting workers to create new processes to use them.

The HELP system is an example of this type of knowledge-based hospital information system. It not only supports the routine applications of a hospital information system including management of admissions and discharges and order-entry, but also provides a decision support function. The decision support system has been actively incorporated into the functions of the routine HIS applications. Decision support provides clinicians with alerts and reminders, data interpretation and patient diagnosis facilities, patient management suggestions and clinical protocols. Activation of the decision support is provided within the applications but can also be triggered automatically as clinical data are entered into the patient’s computerized record.