Medical Decision Support Systems and Knowledge Sharing Standards

Abstract

This topic discusses about the concept of medical decision support system and the knowledge sharing standards among medical decision support systems. The author discusses the evolution of decision support in the healthcare arena, the characteristics and components of a medical decision support system, the medical decision support problem domains, and the popular medical decision support systems. Furthermore, a unique challenge in the healthcare arena—sharing of knowledge among medical decision support systems is discussed. The author discusses about the need for knowledge sharing among medical decision support systems, the evolution of various knowledge sharing standards, and the application of the knowledge sharing standards by the medical decision support systems. Finally, interesting aspects about the future trends in the medical decision support systems, its awareness, its usage and its reach to various stakeholders are discussed.

introduction

The healthcare industry has been a pioneer in the application of decision support or expert systems capabilities. Even though the area of medical informatics and decision support has been around for more than four decades, there is no formal definition for a medical decision support system. Wyatt & Spiegelhalter (1991) describes a medical decision support system as a computer-based system using gathered explicit knowledge to generate patient specific advice or interpretation. The healthcare industry has witnessed a phenomenal growth and advances both in the areas of practice and research. This rapid growth of medical science has made the practice of medicine both challenging and complex. To address these challenges, the recognized medical standards organizations developed medical practice guidelines to simplify the research findings to practical applications in order to improve the overall healthcare quality and delivery. Despite such initiatives, it has been difficult for the physicians to keep up with the guidelines and to tune it to their practice settings. A clear gap began to develop between developing of practice guidelines and the implementation of the same. Grimshaw and Russell (1993) identified that the knowledge dissemination and implementation strategies are critical to the impact the developed guidelines will have on the physician behavior.

The natural evolution was to develop paper-based decision support workflow or protocols. Paper-based decision support models were developed and are widely used at most physician practices to apply the guidelines into practice. Paper-based decision support models, while effective, are also error prone. For example, dose recommendation models could require tedious calculations and can be error prone when performed manually. Such errors could defeat the purpose of using a decision support model. Also, paper-based models require education and training to the personnel performing those calculation and require an additional layer to review the calculations. Most paper-based models are used by the medical personnel as a batch work flow process.

Thus computer-based decision support systems were developed to provide accurate guideline compliance and to enhance physician performance (Hunt, Haynes, Hanna, & Smith, 1998). Computerized decision support system can be extremely valuable for treatment or diagnosis support and compliance accuracy when used at the point of care (Lobach & Hammond, 1997). This feature of computerized medical decision support system is a key differentiator that makes the paper-based decision support models inferior. A well designed computerized medical decision support system can be used to provide patient specific support at the desired time and location with the adequate content and pace. When decision support systems are blended into the day-to-day practice workflow, these systems have the potential to function as a valuable assistant and also as an educational tool (Thomas, Dayton, & Peterson, 1999).

The computerized decision support systems make decisions based on the clinical practice guidelines. Clinical practice guidelines are the rule-based knowledge that guides the decision makers in a medical setting. These guidelines have been developed over the years to reduce the variations among medical practices with a common goal to provide cost effective and high quality healthcare services (Field & Lohr, 1992). The availability of several decision support systems and the use of common knowledge and rules triggered the need for a common method of sharing the knowledge. This technique can save the cost of developing the same medical practice guidelines for multiple decision support systems.

While it is common among organizations to share the data and information between computer systems, sharing the knowledge was a challenge. The medical arena rose to the occasion and various associations were involved in development of a standard way of sharing the medical knowledge and clinical practice guidelines among systems. After reading this topic, the reader should be able to:

• Understand the complexity involved in medical decision making process

• Identify the commonly used decision support techniques in medical decision support systems

• Identify the characteristics of medical decision support systems

• Identify the various phases of the decision making process

• Identify the components involved in the development of a medical decision support system

• Analyze the various decision support functions addressed by medical decision support systems

• Know about the popular medical decision support systems in use around the world

• Understand the importance of knowledge sharing standards in the medical decision support arena

• Know about the popular medical knowledge sharing standards

• Understand the future trends in decision support in the field of medicine

background

The invention of computers resulted from the dream of creating an electronic brain. This quest to artificial intelligence has driven several technological advances in various industries. The potential of intelligence and decision support in the area of medicine was set forth more than four decades ago by Lusted and Ledley (1959). While several computer systems have been developed to improve the administrative efficiency and medical records access, the significant challenges have always been in the development of medical decision support systems. Knowledge-based decision support systems acquire, formalize, and store the expert knowledge in a computer system and infer the represented knowledge in a problem area by modeling the decision process of experts.

One of the first expert systems developed is in the field of medicine. This expert system called MYCIN, provides decision support to physicians on treatment related advices for bacterial infections of the blood and meningitis. The basic structure of the MYCIN expert system is to present a question and answer dialog to the physician. After collecting the basic information about the patient, it asks about the suspected bacterial organisms, suspected sites, presence of relevant symptoms, laboratory results and recommends the course of antibiotics (Buchanan & Shortliffe, 1984). Even though this was a primitive expert system, it brought out the power of such decision support tool in the area of medicine and the potential for more growth in the area of artificial intelligence in medicine. After the introduction of MYCIN in the field of medicine, various decision support systems were introduced and have been successfully used. The commonly used decision support techniques in medical decision support systems are intelligent agents, rule-based engines, heuristics, and decision algorithms.

The use of an intelligent agent or softbot (intelligent software robot) is a popular decision support technique that has the potential to become one of the most important in the next decade (Turban & Aronson, 2000). There are several definitions of an intelligent agent, but the general concept is that the agent carries out a set of operations with some degree of autonomy (Murch & Johnson, 1999). To perform these tasks, an intelligent agent should contain some knowledge. The key characteristics of an intelligent agent are that it should be autonomous, goal-oriented, collaborative, and flexible (Brenner, Zarnekow, & Wittig, 1998). For example, an appropriate task for an intelligent agent would be to use a patient’s history and problem list to assist the physician with diagnostic coding during the order entry process.

A heuristic is a rule of thumb that is used primarily to arrive at a “good enough” solution to a complex problem. This technique is used primarily when input data are limited and incomplete. When the problem or the reality is extremely complex and optimization techniques are not available, a heuristic may be used. Heuristics do not yield definitive solutions, but assist decision makers in arriving at provisional solutions (Camms & Evans, 1996). For example, the determination of the choice of initial doses of both medication and dialysis treatment for a renal patient relies on population-based pharmacokinetic and solute kinetic heuristics, respectively. Subsequent dosing does not require heuristic reasoning, but may be calculated on the basis of measurements of the individual patient’s response to the initial dose (Raghavan, Ladik, & Meyer, 2005).

Rule-based decision support systems primarily store knowledge in the form of rules and problem solving procedures. In expert systems, the knowledge base is clearly separated from processing. Inputs may come from the user, or may be collected from various other programs. Rules are applied on the data collected using an inference engine, decisions are suggested, and explanations supplied (Turban & Aronson, 2000). For example, DARWIN, a renal decision support system, uses rule-based reasoning to advise dialysis technical staff regarding the response to bacteriologic monitoring of fluids used during hemodialysis. Another example of a rule-based or expert system is the use of clinical protocols to generate suggestions regarding anemia treatment using erythropoietin and iron protocols. On the basis of knowledge of new and historical laboratory results and medications, the expert system can suggest the modification of drug doses or the discontinuation of a medication. The inference engine can also provide an explanation of the basis of the recommendation in the protocol.

A decision algorithm is a set of instructions that is repeated to solve a problem. Highly intelligent algorithms include the capability to learn and to perform several iterations of the algorithm or of parts of the algorithm until an optimal solution is reached (Turban & Aronson, 2000). A very simple decision algorithm may alert physicians on receipt of out-of-range laboratory results. If the decision algorithm verifie s the patient’s history and decide s if the standard abnormal range is indeed abnormal for the patient, the algorithm can be classified as an intelligent decision algorithm.

In the next sections, we will discuss about the characteristics of a medical decision support systems, generic components, problem areas in which decision support systems are used and knowledge sharing standards.

characteristics of medical decision support systems

To understand the characteristics of a medical decision support system, it is important to analyze the medical decision making process. A clear understanding of the medical decision making process is essential to appreciate the value and the characteristics of a medical decision support system. Decision making in medicine is not a single point event. It is an extremely complex sequence of inter related and differentiated activities that occur over a period of time. The vastness of the knowledge area presents itself infinite paths to reach a decision. Thus, the importance of finding an optimal path is extremely important in the decision making process. Any assistance in this critical step can be of immense value to the medical decision makers. Hastie (2001) identifies three components to a decision making process. The first component is the choice of options and courses of actions. The second is the beliefs and opinions about the objective states, and the processes including input and outcomes states. The third is the values and consequences attached to each outcome of the event-choice-action combination.

The decision support literature classifies problems into three major categories: structured, semi-structured, and unstructured (Gorry & Morton, 1971). Structured problems are routine and repetitive: solutions exist, are standard, and pre-defined. Unstructured problems are complex and fuzzy; they lack clear and straight-forward solutions. Semi-structured problems combine the features of the two previous categories; their solution requires human judgment as well as the application of standard procedures (Simon, 1971).

Thus the complexity involved in a decision making process can be grouped as a knowledge gathering process, knowledge storage, knowledge retrieval, and information processing. The literature categorizes the decision making process into four distinct phases: intelligence, design, choice, and review (Stohr & Konsynski, 1992).

During the intelligence phase of the decision making process, the need for a decision making (or the trigger) event is recognized and the clinical problem or opportunity is properly identified and defined. This is done by eliciting two different types of knowledge domains: public and private. Private knowledge generally is heuristic and experience-based knowledge that usually comes from the clinical practitioners. Public knowledge can be gathered from standards, guidelines, text books and journals. The office oftechnology assessment (1995) suggests usage of the following questions in identifying the problems and opportunities for medical decision support.

1. Can the solution to the problem/opportunity assist in diagnosing a patient’s condition?

2. Can the solution to the problem/opportunity assist in determining what the proper drug dosage level should be?

3. Can the solution to the problem/opportunity remind the appropriate care giver about the preventative services to be administered to a patient or to patient care related function?

4. Can the solution to the problem/opportunity assist in carrying out diagnostic procedure by recommending specific treatments or tests?

5. Can the solution to the problem/opportunity assist in carrying out medical procedures by alerts regarding potential adverse events?

6. Can the solution to the problem/opportunity assist in providing cost effective medical care by reminding previous orders, results, frequency rule checks, and schedule of treatment or procedure?

During the design phase, the problems or opportunities identified during the intelligence phase are further analyzed to develop possible courses of actions to construct decision models.

A thorough search for ready made solutions, customized off the shelf solution, or a decision to custom solution development is made. Modeling of a decision problem involves identification of variables, identification of the relationship between those variables, and developing an abstraction into quantitative or qualitative forms.

During the choice phase, the actual decision to follow a certain course of action is made. If a single option results from the design phase, the choice phase is a simple acceptance or rejection of the option. If multiple courses of actions are identified in the design phase, then the decision makers are challenged in choosing from multiple conflicting objectives. Some decision rules for multivariable problems have applied strategies like holistic evaluation methods, heuristic elimination, and holistic judgment.

During the review phase, the outcomes of the decision making process are reviewed for validity and applicability for the case in hand. Any deviation and changes to these outcomes could very well become an expert knowledge that can be fed back into the knowledgebase to help future decision making cases.

Several studies were performed to identify the characteristics and functions of a medical decision support system. Turban and Aronson (2000) and Beatty (1999) have performed extensive research in this area of medical decision support system. Turban and Aronson (2000) summarizes the characteristics into few categories as listed below.

1. Support decision makers in semi structured and unstructured situations by bringing medical expert judgment and computer knowledgebase together.

2. Support decision making when the problem area consists of various inter-dependent and/or sequential paths.

3. Should be adaptive and flexible in nature. This allows new learning, adjustments to current knowledge and knowledge pattern recognition.

4. User friendliness is a key for success. Even a great decision support system can be useless if the users are challenged by its interface. This is particularly true in the case of healthcare arena. The system should be easy, fast, and require few mouse clicks by physicians.

5. Allow decision makers to construct simple decision constructs.

6. Should provide both automated and interactive decision support depending on the nature of the problem/opportunity.

7. Should provide complete control to the medical decision maker and should not attempt to replace the clinician’s judgment.

Beatty (1999) conducted an empirical study about the characteristics and functions of a medical decision support system. This study provided several interesting findings on what support do medical decision makers expect during a decision making process. Similar to Turban and Aronson (2000) study, Beatty’s (1999) finding also indicates that the decision makers favored characteristics in a decision support system that advised or guided rather than controlled. Thus, medical decision makers prefer to be in total control during the decision making process and would use the computerized system as a support or assistance during the process.

Beatty’s (1999) finding also differentiated between the expectations of a medical user from a non medical user in medical decision making. This is an important variation in a medical setting as several non medical people perform various routine functions in a medical setting and medical decision support systems could assist their functions as well. The interesting finding is that the non medical users prefer to give more control and trust to the decision support system while the medical users prefer to keep control.

Medical decision support systems should be capable to operate in both an offline mode and a real time mode. This allows the system to be used as an educational tool during offline mode and as an advisor during the real time mode. Beatty (1999) indicates that the users prefer a detailed advice about a medical problem, treatment option, and so on, preferably through flow diagrams or case studies but a real time support should be clear, precise, alarms, and very sophisticated. The knowledge base for the decision support systems should be gathered from literature, case studies, and wide group of experts.

Turban & Aronson (2000) used a schematic view to describe the components of a decision support system. This view was used as a guideline to develop a schematic view to identify the components of a medical decision support system. As depicted in Figure 1, a typical medical decision support system consists of a medical decision support model database, a medical data management component, a medical decision support engine, third party objects including medical databases and rules, decision support sub systems, and a decision support user interface. The decision support model database contains all the tables and data needed to support the decision support models. The data needed for development of rules engine, prediction models, and protocols are stored in the model database.

The medical data management component is the critical part of the medical decision support system. This interfaces with the databases external to the decision support system to allow the decision support engine and third party interfaces to apply model database rule on the medical data to arrive at intelligent decisions.

The medical decision support engine is a set of programs that constitute the model for decision support. It was important to develop a flexible engine that could be data-driven. Several day-to-day decisions in patient care are based on changing regulations and practice guidelines. These guidelines are periodically reviewed and changed. In order to expedite such decision rule changes, it is important to maintain the rules themselves in databases, thus making the model database a meta-database.

Figure 1. Components of a medical decision support system

There are a few decision support processes that are available commercially. These third party objects may or may not include the model database bundled within the object. If they are bundled, it would become a direct interface with the decision support subsystem and the data management system. If they are not bundled, then the data is carefully placed either in the model database or in the medical database as appropriate.

Decision support subsystems are independent decision support systems that can interface with any external subsystem directly or through the decision support user interface. The medical decision support system generally consists of both automated and interactive subsystems. The automated decision support subsystems may use the automated engine to integrate the automated decision making capabilities with existing automated functions. For decision support functions that require user interaction, the decision support system flexible interface is called from the user interface layer and presented to the decision maker.

In the past four decades, numerous medical decision support systems were developed using a wide range of techniques such as automated reasoning, natural language processing, game playing, automatic programming, robotics, machine learning, and expert systems. These decision support systems generally address the medical decision support functions listed in Table 1 (Raghavan, Ladik, & Meyer, 2005). These functions are generic in nature, while the knowledge base of the decision support systems is generally specific to a medical domain area like oncology, nephrology, pediatrics, and so on.

The most common decision support function found in medical decision support systems is alerts and reminders. In a real time environment, these decision support functions are attached to the monitoring devices to provide immediate alerts as and when the trigger condition occurs. For example, the oxygen and blood pressure monitors in an acute setting can alert the nurses if the patient’s condition goes beyond the set threshold value. In a chronic setting, a simple scan of laboratory results and an email or pager alert to the corresponding decision maker are valuable decision support functions. A few medical decision support systems can provide image recognition and interpretation functions. These are extremely helpful in large hospitals where various radiology reports can be interpreted and alerts can be generated to gain the attention of the experts.

Table 1. Decision support functions and clinical problems

Diagnostic support is a key function that several medical decision support systems attempt to offer to help the physicians in detecting the problem based on symptoms and etiology. Such systems are commonly used to detect rare diseases and also as an aid for inexperienced practitioners. A few medical decision support systems offer care plan critiques by looking at data inconsistencies, errors, and omissions against practice guidelines.

In the next section, the problem domain, and the decision support functions provided by various popular medical decision support systems will be discussed. While there are close to hundred known medical decision support systems in use, the most popular medical decision support systems based on the existing literature and usage will be discussed in this topic.

medical decision support systems help (Health Evaluation through Logical processes)

This is the most successful and popular medical decision support system in the United States. The HELP system of the Latter Day Saints Hospital in Salt Lake City is a hospital-based medical information system that gives practitioners a comprehensive patient record with decision support capabilities. HELP is a comprehensive medical information system with full fledged medical records, physician order entry, charges, radiology, pharmacy, ICU monitoring, laboratory, and robust decision support functions (MedEx-pert-HELP, 2004).

The success of HELP information system was due to the fact that the decision support functions were integrated with the hospital information system. The availability of required data and the knowledge base makes this a powerful system. The decision support capabilities made available to the decision makers at the point of care made this an effective product. This system has also been implemented at more than twenty hospitals.

The HELP information system supports the following decision support functions: alerts and reminders, decision critiquing, patient diagnosis, care suggestions, and protocols. The integrated laboratory information system allows automatic monitoring and alerts for abnormalities or out of range values. The critiquing feature is integrated within the transfusion ordering module to critique the reason provided against the strict guidelines. The system also includes modules such as automated surveillance system that uses various data elements to diagnose nosocomial infections. As an extension of this module, the antibiotic assistant recommends the antibiotics that can produce optimal benefit to the patient.

Dxplain

Dxplain is a diagnostic decision support system that is owned by Massachusetts General Hospital and can be licensed and accessed over the internet as well. DXplain is a powerful diagnosis decision support system used in general medicine. The power of DXplain is its knowledge base that can diagnose close to 2000 diseases emphasizing the signs and symptoms, etiology, pathology and prognosis. This system was developed during the early 1990s by Massachusetts General Hospital and has been used by thousands of physicians and medical students.

DXplain uses a set of signs, symptoms, and laboratory results to produce a ranked list of diagnoses which might explain the clinical manifestations. DXplain uses Bayesian logic to derive the clinical diagnosis interpretation (MedExpert- DxPlain, 2004). It is important to note that the system only provides sugge stion and not definitive conclusions. Since this system is in production and licensed as a product, the knowledge base should be continually updated.

DXplain system provides about 10 appropriate references for each suggested diagnosis. The user interface for the DXplain system is very intuitive with graphical user interface requiring only clicks from the lists to drill down to the recommendations. This is one of the main reasons suggested for the success of this product.

RMRS

Regenstrief Medical Records System (RMRS) is one of the oldest, popular, and commonly cited decision support system in the United States. RMRS, developed at Indiana University, is a hospital-based medical information system with decision support capabilities like preventive care reminders and advice regarding cost- effectiveness details during physician order entry.

As early as 1974, RMRS began to deliver paper generated automatic reminders to the physicians the night before a patient’s visit. This intelligent system reviewed the patient’s medical record against the set of pre-defined protocols to generate reminders about the patient’s condition and to suggest corrective actions. In 1984, this report-based decision support system was programmed into an interactive Gopher-based system to break the long list of reminders into logical groups, allowing physicians to step through the reminders during the physician order entry process. The success of RMRS system was due to the fact that the decision support functions were integrated with the hospital information system. The availability of required data and the knowledge base makes this a powerful system. The decision support capabilities made available to the decision makers at the point of care made this an effective product.

In the past decade, RMRS went through a lot of developments and has included various decision support techniques such as pattern recognition and intelligent agents to help physicians assess the patterns of care and identify patients with particular risk factors and adverse outcomes. This system is used at more than 40 inpatient and outpatient facilities and the commercial version is marketed internationally.

Prodigy

PRODIGY (Project prescribing rationally with Decision support In General practice study) is a prescribing decision support system that offers evidence-based, cost effective general practice prescribing. The Sowerby Center of Health Informatics at Newcastle University was approached by the English National Health Service Executive during 1995 to develop a medical decision support system to guide UK general practitioners on therapeutic actions covering prescribing. While developing PRODIGY, the research team realized the importance of integration with already existing general practice software used by the general practitioners. Hence integration with all the five major general practice software in the UK was performed to make PRODIGY a powerful medical decision support system.

While several medical decision support systems assist in diagnosing the problem, PRODIGY starts after the diagnosis is made by providing medical advice and therapeutic recommendations (MedExpert-Prodigy, 2004). The system also stores patient information leaflets containing information about the disease in simple terms. The trigger for decision support within PRODIGY is the input of diagnosis code. Once the physician enters the diagnosis code in their general practice system, it activates PRODIGY decision support to check if suitable medical recommendations are available. The decision maker at that point has the option to explore the recommendations or ignore it. When explored, the decision maker will be presented with therapy scenarios, evidence-based prescribing, and availability of patient information leaflets along with justification and references for the recommendations. PRODIGY medical decision support system has been successfully implemented nation wide at all general practitioners in the UK.

XADlAG – II (computer Assisted Diagnosis)

CADIAG – II is a hospital-based medical decision support system developed by the Department of Medical Computer Sciences at University of Vienna. CADIAG decision support system has been integrated with the medical information system of the Vienna General Hospital.

CADIAG decision support system focuses on the colon diseases, rheumatic diseases, gall bladder, pancreatic diseases, and bile duct diseases (MedExpert-Cadiag, 2004). This medical decision support system provides online consultation support for the physician to assist in diagnosis of the diseases given the signs, symptoms, etiology, and laboratory results. This system contains a very strong knowledge database in the specialty areas of colon diseases and rheumatic diseases.

NeoGanesh

NeoGanesh is a widely cited knowledge-based decision support system that is used primarily to manage the mechanical ventilation in Intensive Care Units. This decision support system is one of the very few automated and controlled system with very limited human intervention. This real time medical decision support system checks for the real time data and controls the mechanical assistance provided to the patients suffering from lung diseases in a pressure supported ventilation mode (Dojat, Pachet, Guessoum, Touchard, Harf, & Brochard, 1997). The other interesting feature of the system is to develop a therapeutic strategy to respond to the patients and evaluate the capacity to breathe. This system is used at Henri Mondor Hospital in France. This system is being planned to be released for commercial purpose as well.

medical decision support knowledge sharing overview

The field of medicine has been a pioneer in the introduction of decision support systems. One of the first expert systems to be developed was in the field of medicine. The complexity of decision making in the field of medicine and the challenge of keeping up to date with the new findings and research has been a key motivator for the usage of medical decision support systems. As discussed in the previous sections, numerous medical decision support systems exist in the market. The knowledge for most of these medical decision support systems are acquired from the clinical practice guidelines issued by various government and medical associations. Clinical practice guidelines are the rule-based knowledge that guides the decision makers in a medical setting. These guidelines have been developed over the years to reduce the variations among medical practices with a common goal to provide cost effective and high quality healthcare services (Field & Lohr, 1992).

Healthcare organizations historically have focused more on the development of the clinical practice guidelines compared to the implementation of the guidelines (Grimshaw & Russell, 1993). Past research studies have proved that the computerized medical decision support systems when integrated with the clinical workflow can improve the practitioners’ compliance with clinical practice guidelines and outcomes (Johnsons, Langton, Haynes & Mathieu, 1994). Thus, it was clear that the medical decision support systems are best vehicles to promote compliance. The availability of several decision support systems and the use of common knowledge and rules triggered the need for a common method of sharing the knowledge. This technique can save the cost of developing the same medical practice guidelines for multiple decision support systems.

While it is common among organizations to share the data and information between computer systems, sharing the knowledge was a challenge. While knowledge sharing could be considered as losing competitive advantage, the healthcare industry was one of the few industries where several guidelines are common as they are generally developed by government agencies or medical associations. The medical arena rose to the occasion and various associations were involved in development of a standard way of sharing the medical knowledge and clinical practice guidelines among systems. In the following sections, the various prominent clinical practice guideline models and knowledge sharing standards are discussed.

ARDEN syntax

ARDEN Syntax is an ASTM (American Society for Testing and Materials) and ANSI (American National Standard Code for Information Interchange) standard a hybrid knowledge representation format that was created with the main aim to address the ability to share, reuse, and understand the medical knowledge base. It is first introduced in 1989 at the Columbia University’s Arden homestead conference. The initial idea for the conference was to create a knowledge representation format that can facilitate the definition of knowledge bases and thus could result in an effective implementation of new knowledge consistently (Hripcsak, Pryor & Wigertz, 1995). The development of knowledge bases is the biggest challenge faced by the ever changing medical field and introducing a knowledge representation format was thought to be of significant help to allow various institutions to share their knowledge among medical decision support systems.

The ARDEN syntax was largely derived from the logical modules used by the HELP and RMRS medical decision support systems. The concept of the ARDEN syntax is to develop rule-based modular logical rules called medical logical modules (MLM). The medical decision support system that is based on Arden Syntax polls for the occurring events and executes the MLM’s out of its knowledge base that has defined the occurring event as the triggering condition.

In ARDEN syntax, the MLM’s are composed of slots that are grouped into three categories called maintenance, library, and knowledge. Each category has a set ofpredefined slots. The slots are broadly classified as textual slots, textual list slots, coded slots, and structured slots. The maintenance category contains the slots that specify general information about the MLM like title, mlmname, arden syntax version, mlm version, institution, author, specialist, date, and validation. The library category contains slots about the knowledge base maintenance that is related to the module’s knowledge. This category contains the relevant literature, explanation, and links that were used in defining the MLM. The library category slots are purpose, explanation, keywords, citations and links. The knowledge category contains the slots that specify the real knowledge of the MLM. The knowledge category dictates the triggering event of the MLM and the logic of the MLM. The knowledge category slots are type, data, priority, evoke, logic, action, and urgency.

Example

Let us look at a simple anemia management protocol for a renal patient as an example. On receipt of new hemoglobin laboratory result, if the value is greater than 13.3, and if the patient is on Eryth-ropoietin dose, then recommend discontinuation of the dosage. The MLM for this simple rule is given in Box 1.

ARDEN syntax-based decision support systems are widely in use. Since this syntax became an ANSI standard, it was embraced by several medical information system vendors to provide decision support capabilities. Vendors who have developed ARDEN compliant applications include: Cerner Corporation, Healthvision, McKesson, SMS, and Micromedex.

Asbru

Asbru is a knowledge representation language to capture the clinical guideline and protocols as time oriented skeletal plans. The development of Asbru was part of the Asgaard project developed by the Technical University of Vienna, Stanford Medical Informatics, University of Newcastle, and University of Vienna. The goal of the As-gaard project is to develop task specific problem solving methods that perform medical decision support and critiquing tasks (Seyfang, Miksch, & Marcos, 2002).

Asbru is a difficult language to be understood by a physician and hence a graphical knowledge acquisition tool is used to gather the knowledge or guideline and then output that into Asbru syntax behind the scenes for computer interpretation. The graphical tool used is called Protege. The Asbru output created by Protege can be shared with other medical decision support systems that are compliant with Asbru format.

Box 1.

maintenance:

title: Screen for anemia management (triggered by hemoglobin storage);;

filename: renal_anemia_Hemo_Epo;; version: 1.00;;

institution: Sample Institute; Sample Medical Center;;

author: Sri Raghavan, PhD.;;

specialist: ;;

date: 2004-03-01;;

validation: testing;;

library:

purpose:

Warn the patient care personnel of the level of hemoglobin and EPO dosage.;; explanation:

Whenever a hemoglobin blood result is stored, it is checked for anemia management. This simple protocol checks if the value is greater than 13.3, and if EPO is administered to the patient, then an alert is generated to recommend the practitioner to discontinue the dosage.;;

keywords: anemia; hemoglobin; renal; Erythropoietin;;

citations: ;;

knowledge:

type: data_driven;;

data:

/* evoke on storage of a hemoglobin result*/ storage_of_hgb := EVENT {storage of hemoglobin};

/* read the potassium that evoked the MLM */ hgb:= READ LAST {hemoglobin level};

/* get the last active Erythropoietin order */ epo_order := read last epo order};

evoke:

/* evoke on storage of a hemoglobin */ storage_of_hemoglobin;;

logic:

/* exit if the hemoglobin value is invalid */ if hemoglobin is not number then

conclude false; endif;

/* exit if there hemoglobin is <=13.3 */ if hemoglobin <= 13.3 then

conclude false; endif;

_/* exit if Erythropoietin order cannot be found */_

Box 1. continued

if (epo_order is null) then

conclude false; endif;

/* send an alert */ conclude true;

action:

write “The patient’s hemoglobin level on (” ||time of potassium|| “) is” ||hemoglobin|| “. The patient is currently on Erythropoietin dosage. As per clinical guideline, it is recommended to discontinue the Erythropoietin dosage.”;

urgency: 90;; end:

eon

EON is a clinical guideline modeling system developed by Stanford University for creating guideline-based decision modules. The EON guideline model system was developed to address the problem of modeling clinical guidelines and protocols to provide patient specific decision support. This modeling system allows creating a knowledge engineering environment for easy encoding of clinical guidelines and protocols. EON guideline model allows association of conditional goals with guidelines. It provides three criteria languages to allow the medical practitioners to use and express their decision making complexities: a simple object oriented language that medical practitioners can use to encode the decision criteria, a temporal query type language, and a predicate logic.

EON also uses Protege as the medical knowledge acquisition tool to help medical practitioners provide medical decision criteria. The EON language is generated at the back end by the Protege tool. This code is platform independent and can be shared between decision support systems that are EON compliant.

EON is widely used in European countries and one of the major decision support system that uses EON is PRODIGY. The decision support system ATHENA, which provides hypertension related advices, also uses the EON guideline model as its decision support architecture.

GEM (Guideline Elements Model)

GEM, an XML- (Extensible Markup Language) based guideline document model was introduced in 2000 by Yale center of medical informatics. This initiative is intended to facilitate the translation of medical guideline documents to a standard computer interpretable format. The key difference between the other techniques and GEM is that it uses the industry standard XML for knowledge transfer purposes. GEM’s XML hierarchy is made up of 100 discrete tags and 9 major branches. These branches are identity, developer, intended audience, target population, method of development, testing, review plan, and knowledge components (Shiffman, Karras, Agrawal, Chen, Marenco, & Nath, 2000). Several of these branches appear identical to the slots of ARDEN syntax. While the goal of all of these knowledge transfer techniques is the same, they differ in their implementation strategies.

The strength of this model is that it encodes both the recommendations and adequate information about the guideline recommendations, including its reason and quality of evidence (Shiffman et al., 2000). GEM was accepted as an ASTM standard in 2002. Knowledge extraction in GEM is a simple document markup rather than a programming task. GEM uses a knowledge acquisition tool called GEM Cutter to interactively gather he knowledge data and store it in a XML format.

GLARE (Guide Line Acquisition Representation and Execution)

GLARE is a medical domain independent guideline model system for acquiring, representing, and executing clinical guidelines. GLARE was introduced in 1997 by the Dipartimento di Informatica, Universita del Piemonto Orientale , Alexandria, Italy. This system boasts a modular architecture with acquisition and execution modules. The GLARE Knowledge representation language is designed to satisfy both the complexity and expressive rules. The format is limited but focused set of primitives. It consists of plans and atomic actions that can be queries, decisions, work actions, and conclusions (Open Clinical-Glare, 2004).

GLARE knowledge acquisition system is an easy to use graphical user interface with syntactic and semantic verifications to check the formulated guidelines. Artificial intelligence temporal reasoning techniques are applied to weed out inconsistencies. The GLARE system goes one step ahead and also incorporates a decision support system for knowledge execution purposes. GLARE system has been tested for applicability in medical domains like bladder cancer, reflux esophagitis, and heart failure at the Laboratorio di Informatica Clinica, Torino, Italy. The commercial version of this product is still under development.

future trends

While medical decision support systems have been around for the past four decades, its usage among clinicians is still questionable. Several variables play a role in a success of a medical decision support system and it is important to address these to move ahead from where we stand now. Issues like physician reluctance, intimidating systems, proprietary interests, local practice, technological factors, and outdated knowledgebase are all limiting factors for the growth and acceptance of computer-based decision support systems. In addition to these limitations, the decision making functions are no longer limited to the physicians. The patients, healthcare administrators, insurance carriers, healthcare professionals, policy makers, risk analysts, and the government at large are all stakeholders in this medical decision making process. It will be extremely limiting to tie down these requirements to local proprietary computer systems.

While the field of medicine pioneered the knowledge sharing techniques among decision support systems, the introduction of several sharing standards segmented market as a net result defeated the purpose of such standard. The growth, availability, and accessibility of the Internet opened the door for development of a new model for sharing medical knowledge and decision support systems across networks. Internet-based decision support systems with focus on a particular medical domain will be prevalent in the future.

The various knowledge sharing standards are naturally meeting a common merger. For example, several medical guideline modeling languages are using a common interface for knowledge acquisition purposes. Protege is the most commonly used tool to acquire the knowledge and then formulate the output in various modeling languages. This converging trend will begin to happen at the knowledge representation and knowledge execution modules as well. This will give raise to a true acceptance of a common knowledge sharing technique.

The next key area of medical decision support systems is the unique characteristics of its users. Great medical decision support systems when seldom used solves no purpose. Most users get intimidated by the complexities and challenges posed by the user interface. While medical decision making is not a simple process, the decision support systems should help reducing the complexity and not increasing them. Past studies indicate that the complexity of customizing the knowledge or a simple rule forces the physicians to refrain form using the system. Training clinicians in usage of complex decision support process is a worthy investment. The benefits of the usage of medical decision support systems outweigh the costs incurred in development, implementation, and maintenance of such products.

Topic summary

Medical decision support systems, when used along with the clinical information systems at the point of care can improve the quality of care provided. Despite evidence of the benefits of decision support, and despite endorsement by a national patient safety panel (Kohn, Corrigan & Donaldson, 2000), computerized clinical decision support has not achieved wide diffusion. A recent survey found that such systems were used in less than five percent of all healthcare facilities (Wong, Legnini, Whitmore, & Taylor, 2000). When the user interface, availability, and accessibility issues of the medical decision support systems are properly addressed, the usage of the systems will grow multi fold! When such medical decision support systems are blended into the day-to-day practice workflow, then these systems are destined to succeed!