eminder systems in medicine.

A.Hasman,
Dept. of Medical Informatics,
University of Maastricht,
The Netherlands.

�@

�@

Governments and insurance companies increasingly press physicians to work still more efficiently than they already do. Moreover an increased efficiency should not lead to a decrease in quality. In order to cope with these pressures diagnostic and treatment guidelines were introduced. Some years ago many physicians did not accept guidelines and protocols, the use of which they denoted as cookbook medicine, indicating that such an approach would not lead to an optimal management of the individual patient. This situation has changed. More and more evidence-based medicine is practiced. This means that only those treatments are used for which there exists scientific evidence (for example from RCT studies) that the treatment really works. The use of evidence-based protocols and guidelines therefore is no longer regarded as cookbook medicine. I use the term guideline to indicate a statement (rule) that something should be (not) done in a certain situation, whereas a protocol for me is equivalent to a clinical algorithm. A protocol contains a number of statements telling what to do with a patient as a function of time and depending on the outcome of tests or on treatment results. An example of a guideline is that for children under the age of 12 years an X-ray for sinusitis should not be carried out. An example of a protocol is the hypertension protocol. It contains a definition of hypertension and states which lifestyle changes should be advised; which drug should be prescribed, taking other diseases of the patient into account; in case the prescribed drug does not work which other drug should be prescribed, etc.
The use of guidelines and protocols can be supported by decision support systems. In fact, the IOM (Institute of Medicine, USA) has stated that decision support tools are very important for the dissemination of protocols and guidelines. Yet today not many decision support tools are widely implemented. Most of them did not leave the prototype phase. The ones that survived were shown to be effective, however.
We discern passive and active decision support systems. Passive decision support systems cannot reason with the knowledge they contain. The user has to search for the information. The user accesses the relevant knowledge usually via some index. A bibliographic database and an Internet browser are examples.
Active decision support systems can reason with their knowledge. Pro-active decision support systems for example ask the physician for data about the patient and on that basis provide suggestions about diagnosis or treatment. Expert systems are examples of pro-active systems. Usually physicians do not like this so-called 'Greek oracle approach'. They want to be in charge themselves. The re-active approach was more successful. In this approach the physician is in charge. Only when his/her diagnosis or therapy is not according to the rules, the decision support system warns the physician by issuing reminders. The HELP system developed by Homer Warner (Utah, USA) and the Regenstrief system developed by Clem McDonald (Indianapolis, USA) are examples of re-active systems. These systems look over the shoulder of the physician and only interfere when some decision is not according to given rules. The re-active decision support systems are also called feedback or reminder systems.
Designing decision support systems is a costly job. The domain knowledge has to be elicited from the experts and problem-solving methods have to be programmed. One can ask oneself the question whether domain ontologies and problem-solving methods cannot be reused for different applications in the same domain, in which case the domain knowledge could be reused or for similar applications in other domains, in which case the problem-solving method could be reused.
In Stanford, USA, Mark Musen and colleagues have developed the Protég�Esystem with the goal to make the re-use of domain knowledge or problem-solving methods possible. With Protég�Ethe concepts and relations between concepts of a certain domain can be defined. This is called domain ontology. With Protég�Eone can define for example the class of Medications, the subclass of Medications used for the Circulation, etc. Also one can state that certain classes of medication interact with other classes of medications. In the same way classes of diseases can be defined. Protég�Ealso contains a number of problem-solving methods, defined in such a way, that they are domain independent (the classes of the problem-solving method have some general names). The user of Protég�Ecan choose a problem-solving method and map classes of the domain ontology to the input and output classes of the problem-solving method. The output of Protég�Eis a file, written in the frame-based CLIPS language (this language was developed by NASA). The output file of Protég�Econtains both the domain ontology and the problem-solving method. Since the domain ontology only contains the names of the concepts and relations between concepts that are always true, more knowledge still has to be elicited in order that the problem-solving method can work. After constructing a general framework for a knowledge base editor, this editor can be transformed into a knowledge base editor for just the application in mind by reading the Protég�Eoutput file. The knowledge base editor now for example shows a window containing the domain ontology as it was defined via Protég�E The physician can use this knowledge base editor to enter the additional knowledge required by the decision support system. The physician drags concepts from the ontology window and drops them in another window to compose his knowledge. The way this knowledge is represented depends on the problem-solving task. After the knowledge has been entered it can again be outputted as a file, to be used by an empty decision support system. After compiling this knowledge the decision support system can perform the task it was designed for.
One thing has still to be taken care of. The patient data necessary for the decision support system has to be obtained from an information system. This can be done by the decision support system by reading the data directly from the database of the information system, or the information system supplies the decision support system with information as soon as new data is entered. The latter system is usually based on events. Each data entry is considered an event and the information system appends a certain tag to the message it sends to the decision support system. The tag determines what type of decision support is needed (which task has to be executed). If for example in an intensive care information system a new drug is entered, the information system sends this information to the decision support system, together with an event tag, indicating the fact that a new drug was prescribed. In this particular case the decision support system has to carry out two tasks (determine possible contra-indications for the drug or determine possible interactions with drugs already prescribed to the patient). The task that determines whether a newly given drug has a possible interaction with drugs already taken by the patient is the following:

For each drug newly prescribed to the patient

determine the drugs with which this drug has an interaction

For each drug out of the interactions list

find out whether the patient is getting one or more of these drugs

For each of these drugs report the interaction to the physician.

The system could also be rule-based. Then the task is straightforward: if the if-part of the rule is true, present a reminder to the physician. In this case the physician only has to specify the if-part and the text of the reminder during the knowledge acquisition phase.
In Maastricht we have used this type of approach to build a number of decision support systems, for example for monitoring the adequacy of GP test requests, for monitoring the quality and completeness of data entry in intensive care systems and for constructing a protocol system for hypertension. During the presentation we will present some information about the quality of the systems.