MED. INFORM. (1993), VOL. 18, NO. 2, 131-142
`
`Decision support for drug prescription integrated with
`computer-based patient records in primary care
`
`R. LINNARSSONt
`Department of Medical Informatics, University, Linkoping
`and Kronan Health Centre, Sundbyberg, Sweden
`
`(Received October 1992)
`
`Abstract. A conceptual model of an information system that integrates a controlled
`vocabulary, a patient database, and a knowledge base is described. Methods, design and
`components for the implementation of the system are discussed. I t is argued that the key
`issue for the successful introduction of computer-based decision support in primary care
`today is integration with a computer-based patient record. Also important is that the
`knowledge acquisition process is based on the general practitioner’s real needs. This has
`been achieved by, first, providing general practitioners with real patient data from a series
`of retrospective database studies; and second, letting a panel of general practitioners select,
`discuss and decide which computer reminders to implement. A hybrid representation
`scheme was chosen for the knowledge base. The combination of a standard procedural
`representation (the so-called Arden syntax) for the reminder knowledge with a semantic
`net representation for the medical factual knowledge facilitates knowledge sharing with
`other systems and knowledge reuse within the system.
`
`Keywords: Computerized medical records systems; Decision support systems; Drug therapy,
`computer-assisted; Primary health care.
`
`1. Introduction
`In an overview, Shortliffe defines a clinical decision support system as ‘any
`computer program designed to help health professionals make clinical decisions’
`[l]. This means that any computer system that deals with clinical data or medical
`knowledge, in a sense, is intended to provide decision support. According to
`Shortliffe, decision support systems may be divided into three categories: (1) tools
`for information management (e.g. hospital information systems, bibliographic
`retrieval systems); (2) tools for focusing attention (e.g. laboratory systems that flag
`for abnormal values, pharmacy systems that detect drug interactions); and (3) tools
`for patient-specific consultation (systems that give advice based on patient-specific
`data). The third category is what many people in the first place would call decision
`support systems, but the limits between these categories should not be considered
`as distinct. On the contrary, one important reason why few of these systems have
`come into practical use is lack of integration between these three categories.
`Only when the physician is using the computer routinely to store and review data,
`and when the same computer system can give patient-specific advice based on those
`data, will decision support systems become widely accepted.
`Also within the domain of drug therapy, there are these different categories of
`decision support systems and the same problems of lack of integration. Pharmacy
`information systems have been in use for many years both in hospitals and in
`t Address correspondence to: R. Linnarsson, Virdcentralen Kronan, S-172 83 Sundbyberg,
`Sweden.
`
`0307-7640/93 510.00 0 1993 Taylor & Francis Ltd.
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0001
`
`

`

`132
`
`R. Linnarsson
`
`community pharmacies. Controlled studies have shown that computerized drug
`monitoring systems can improve prescribing behaviour of clinicians [2]. Some of
`these systems have decision support functions belonging to the second category
`above, e.g. screening for drug interactions [3-51. Most of these programs are
`intended for use at hospitals by pharmacists. Some programs have also been
`developed for use in primary care by the prescribing physician [6]. These programs
`typically take as an input a list of drugs entered by the user, search their database
`for possible interactions within each drug pair in the input list, and give an output
`list that specifies pairs of drugs that potentially interact. Few of these programs
`give any advice about the clinical significance of the interactions and how to
`manage the potential adverse effect of the interaction, or indicate which patients are
`at high risk for being harmed by the interacting drugs. Probably the most serious
`shortcoming of these drug interaction computer programs is that they are not
`integrated with computer-based medical records systems [7].
`Obviously, a system that can give the decision support automatically, retrieving
`interaction data from the drug knowledge base and prescription data from the
`patient database, would be much more useful for the prescribing physician.
`The positive impact of such systems has been shown in controlled studies [8, 91.
`Lack of standardization and compatibility, and unwillingness of the vendors to
`allow access to their drug databases, are some factors that have made integration
`with patient records difficult until now [lo].
`In a series of retrospective database studies the real need for decision support
`in primary care has been investigated at a health centre in suburban Stockholm,
`the Kronan Health Centre. The practice has seven general practitioners and two
`doctors on vocational training, and it has been using computer-based patient
`records since 1984.
`One study [l 11 showed that potential drug interactions occur in 12%) of patients
`at risk (those receiving two or more concurrent drugs), and that 1.9% of all
`drug prescriptions result in a potential drug interaction. In particular, the rate of
`potential drug interactions for elderly patients was very high, suggesting that
`adverse drug reactions may be a serious health problem among the elderly.
`T h e results are comparable with those reported by others. In three studies from
`primary care the rates of potential drug interactions for patients receiving two
`or more drugs were 29.5, 24.3 and 42.0%), respectively [12-141. Another study
`reported 2.2% prescriptions of adversely interacting drugs in relation to all
`prescriptions [ 151.
`Another database study, performed at the Kronan Health Centre, showed that
`several drugs excreted by the kidneys were prescribed to elderly people with
`impaired renal function. Out of a list of 24 generic drugs that should be avoided or
`given in reduced dosage to patients with impaired renal function, 11 drugs had been
`prescribed to patients having an estimated creatinine clearance, calculated from the
`serum-creatinine value, < 50 ml/min. Altogether 249 patients were involved during
`a 6-year period.
`The results of these studies have several implications for the design of a
`drug-prescription decision support system. First, it is obvious from the results that
`there is a need for decision support. Second, the decision support system should not
`only identify drug problems, but also give some advice about the clinical
`significance of these problems and give some recommendations of what kind of
`actions are appropriate to take, to avoid adverse effects. Third, the decision support
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0002
`
`

`

`Drug decision support and computer-based records
`
`133
`
`should focus on drug treatment of elderly people with multiple drugs. The system
`should consider the functional and metabolic alterations that accompany ageing,
`such as decreased hepatic and renal function. Recommendations of dose
`adjustments according to these alterations should be included. Fourth, the decision
`support system should be integrated with the patient information system used.
`An integration of the drug knowledge base with the patient database makes it
`possible to automate the interaction control and to give the physician alerts or
`computer reminders when potential interactions or other drug problems occur.
`Based on the experiences of these studies we have developed a decision support
`system for drug prescription in primary care. The system is data-driven and
`integrated with the computer-based patient records. A knowledge base has been
`developed in which the factual medical knowledge is separate from the knowledge
`of alerts and reminders. T h e factual medical knowledge covers all drugs, their
`potential interactions, etc., while the reminder knowledge has been focused on the
`needs of the prescribing physicians according to the results of the database reviews.
`
`2. A drug decision support scenario
`During the consultation the physician decides to prescribe amiloride to a patient
`suffering from heart failure. When he starts prescribing the drug from his video
`terminal in the consulting room, the medication list of the patient is displayed on
`the screen. In this situation he may want to check the drug interactions among the
`current medications on the list, before or after he has chosen the new drug to
`prescribe. Furthermore, if the patient has impaired renal function he wants to be
`reminded of the potential risk to prescribe amiloride.
`So, besides ordinary information about drugs such as generic name, synonyms,
`package size and price, the prescription system provides more sophisticated
`decision support which integrates information about the patient with knowledge
`about the drugs. First, the decision support system must be able to screen a
`medication list in the medical record and compare it with facts stored in the
`knowledge base of the system. Second, the system must be able to retrieve certain
`information from the patient database (about renal function here) related to the
`drug prescribed, apply some knowledge stored in the knowledge base, and if certain
`criteria are fulfilled give a reminder to the physician on the screen.
`
`3. Conceptual model of the system
`We will in the following present a conceptual model of the integrated decision
`support system. According to that model the system has three main components:
`the patient database, the data dictionary (controlled vocabulary) and the knowledge
`base. T h e basic component of the data dictionary is the medical term, the basic
`component of the patient database is the medical event, and the basic components
`of the knowledge base are the medical fact and the medical logic module (figure 1).
`The data structures and representation schemes that have been defined for these
`basic components are outlined in @3.1-3.3. One or two practical examples have
`been chosen to show the structures: one medical term, ‘amiloride’, which is a
`cardiovascular drug; one medical event, ‘prescription of amiloride’; and two
`pieces of medical knowledge, the medical fact that ‘amiloride’ is contraindicated in
`‘kidney failure’, and a medical logic module which is a reminder about this
`contraindication. A frame-like (object-orientated) representation scheme was
`chosen for the data structures for medical terms and medical events. The knowledge
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0003
`
`

`

`134
`
`R . Linnarsson
`
`Figure 1 . A conceptual model of a system that integrates a controlled vocabulary (data dictionary),
`a patient database and a medical knowledge base. The principal components are the medical
`terms, the medical events, the medical facts, and the medical logic modules.
`
`base has two kinds of representation schemes: a semantic net for factual
`knowledge, and a frame-like representation according to the Arden syntax [16]
`for the reminders.
`
`3.1. Controlled vocabulary
`T h e controlled vocabulary of the system contains all medical terms needed
`to represent clinical data in the patient database and medical knowledge in the
`knowledge base. T h e medical terms of the system represent a subset of the entire
`medical nomenclature. In particular the controlled vocabulary of this system will
`comprise a subset of a national Swedish medical terminology database, which is
`under development. For that terminology database a structure has been proposed,
`which includes 10 main categories of medical terms (anatomy, organisms, medical
`history, symptoms, physical examination, diagnostic procedures, diagnoses,
`medications, therapeutic procedures, health care), and a standard record format
`which includes the following fields: unique identifier, preferred term, status,
`source, date, revision date, semantic type/category, description/definition, lexical
`variants, synonyms, related
`terms, mappings
`to national or
`international
`classifications and coding systems, and translation to other languages.
`
`Sample MEDICAL TERM
`identifier:
`(unique id: term-id)
`preferred name:
`(amiloride)
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0004
`
`

`

`Drug decision support and computer-based records
`
`135
`
`(Milorid, Midamor)
`synonyms:
`semantic category: (cardiovascular drug)
`mappings:
`(ATC: C03DBO1)
`
`3.2. Patient database
`A medical event represents a medical action taken by a provider for a patient at
`a certain time, e.g. a diagnosis, a drug prescription, or a laboratory test. According
`to the model an event is regarded as a relation between three entities: the patient,
`the contact, and the medical term. A contact can be an encounter, a telephone call,
`or any other notation of a contact between a provider and a patient. The attributes
`of the contact (provider, date, site, type) specifies the context in which the medical
`action takes place.
`
`Sample MEDICAL EVENT
`identifier:
`(unique id: pat-id,event-id)
`patient:
`(unit number: 111111-1111)
`(date: 25 September 1992)
`contact:
`(site: Health Centre)
`(type: scheduled visit)
`(provider: Dr NN)
`(drug prescription)
`type:
`medical term: (dictionary term: amiloride)
`(problem: no 1 = heart failure)
`attributes:
`(time: 2:OO PM)
`(route: tabl)
`(dose: 5mg)
`(frequency: 1 tabl daily)
`(quantity: 100)
`(iteration: 4)
`(comments: ‘heart strengthening’)
`
`The particular event is characterized by a set of properties (attributes) such as the
`time when it occurred and the value (numeric, textual or other). The corresponding
`data structure will be stored in the database as a separate unit. Conceptually,
`the medical record can be regarded as a collection of events, which are specified
`according to patient, source (provider), time and problem. Different documents in
`the medical record, such as medication list, laboratory report, and progressive
`notes, correspond to different views of the database of events.
`
`3.3. Knowledge base
`There are two separate parts in the knowledge base corresponding to two
`different types of knowledge: the factual medical knowledge and the knowledge
`about how the medical knowledge should be applied to a particular clinical
`situation. The latter type of knowledge will be called situation knowledge.
`For the representation of factual knowledge we have chosen a declarative
`representation form, namely a semantic net. The semantic net has nodes and links,
`which denote objects and their relations. Possible nodes are medical concepts
`expressed as medical terms in the controlled vocabulary of the system, the data
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0005
`
`

`

`136
`
`R. Linnarsson
`
`dictionary. The possible links are a set of defined relations between those medical
`concepts. The following example shows the structure of the representation:
`
`drug #l+INTERACTS-WITH+drug
`
`#2
`
`Here ‘interacts-with’ is the link and ‘drug#l’ and ‘drug#2’ are the nodes. These
`nodes correspond to elements in the data dictionary. In particular the following
`links are needed to express the knowledge in the drug domain to support drug
`prescribing:
`
`is-a
`treats, is-indicated-in
`is-contraindicated-in (modifier: relative, absolute)
`is-excreted-by
`has-adverse-effect (modifier: common, uncommon, rare)
`has-interaction-with (modifier: major, moderate, minor)
`causes
`is-associated-with
`
`Sample MEDICAL FACT
`start-node: (dictionary term: digoxin)
`link:
`(type: interaction)
`end-node: (dictionary term: verapamil)
`
`For the representation of situation knowledge (the data-driven reminders) we have
`chosen a procedural representation form, namely the frame-like representation in
`modules according to the Arden syntax [16]. These modules are called M I A
`(medical logic modules). Each M L M is broken into slots in three categories:
`maintenance, library, and knowledge slots. The knowledge category contains those
`slots that really specify what the module does. The data slot defines the medical data
`that will be used in the logic slot, the evoke slot defines the criterion for executing
`the M L M , and the action slot defines what should be done if the logic slot evaluates
`to true. In the example are shown the knowledge slots of a sample M L M , whose
`purpose is to remind the physician, prescribing amiloride to a patient, of the risk of
`hyperkalaemia when the patient has impaired renal function.
`
`Sample MEDICAL LOGIC MODULE
`name:
`amiloride-and-impaired-renal-function;;
`......
`type:
`data:
`
`data-driven;;
`arni: = read
`{input patient; set [current-meds] = null; when
`code = amiloride, status is active;
`set [current-meds] = amiloride};
`cre: = read
`{input patient; when code = serum-creatinine;
`for most recent event; set [last-creatinine] = result};
`amiloride-storage: = event {store amiloride prescription} ;;
`am ilo ride-s to rage; ;
`if arni and ere > 130 then conclude true else conclude false;;
`
`evoke:
`logic:
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0006
`
`

`

`Drug decision support and computer-based records
`
`137
`
`action: write ‘Caution: amiloride may cause hyperkalaemia in patients with
`impaired renal function. Consider withdrawal of amiloride and/or
`check serum level of potassium.’;;
`Those parts of the M L M that are enclosed in curly brackets ‘{...}’-are
`institution-specific references to the patient database. Such a reference may be
`a query {input patient ...} or may refer to the storage of data in the database
`{store amiloride prescription}.
`
`4. Knowledge acquisition
`Several sources and methods have been used to create the drug knowledge base.
`One part of it has been provided by the Swedish drug company, Apoteksbolaget,
`and another part comes from the Swedish drug catalogue company, LINFO.
`All information about the drugs needed for the prescription-such
`as generic and
`trade names, chemical components, dose and recommended frequency, package
`size etc.-is
`provided on floppy disks monthly. The drug files have to be converted
`to the format required by the patient records system. The drug interaction database
`is updated once a year; it comprises all interactions mentioned in the drug catalogue
`including a free text comment for each interaction with recommendations on checks
`that should be done, alternative therapy, clinical significance, and bibliographic
`references. T o convert this database to a format possible to integrate in the patient
`record system has been an extensive work, because the file structure of the
`interaction data is complex and not made for integrated decision support.
`The recommendations about choice of drugs for certain diseases, issued by
`the regional drug committee once a year, have been entered into the drug
`database manually.
`The MLMs are developed at the health centre according to a particular method
`(figure 2). A panel of seven experienced general practitioners in the area selects,
`discusses and decides which MLMs to use. Using a special form for each MLM,
`they write down the essential facts of the knowledge part of the MLM, mainly
`evoking criteria, database criteria, and actions. Medical concepts referring to
`patient data are formulated in terms from the controlled vocabulary. After the panel
`has decided about the M L M it is manually translated to a database query and tested
`within the real patient database to see that it has the intended function. It will then
`be integrated in the prescription module so that it can be triggered when the
`evoking criterion is fulfilled, usually the prescription of a certain drug.
`
`Figure 2. T h e knowledge acquisition procedure. Reminders selected by a GP panel are transformed
`to the standard medical logic module (MLM) format, implemented using the MQL query
`language, tested in the real database, and validated by the GP panel.
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0007
`
`

`

`138
`
`R. Linnarsson
`
`5. System implementation
`The computer-based patient record system has been implemented and is in
`routine use at Kronan Health Centre. This system, named Swede-star [17], is
`originally based on COSTAR 11181. The medical record is common to district
`physicians, district nurses, assistant nurses, and physiotherapists. The system is
`problem-orientated, and it serves as the sole medical record for the physicians at the
`health centre. No paper records are used.
`Besides the medical record module, the system has modules for administrative
`functions like time scheduling and care planning. It has communication with the
`hospital, including electronic transfer of results of bacteriological tests. It also has
`communication with
`the local pharmacy and electronic transfer of drug
`prescriptions. There are modules for database searches, report generation and
`database querying [19]. Technically the system is implemented on an IBM RS6000
`machine with 64 terminals. The operating system is AIX and the application is
`written in Micronetics Standard Mumps.
`
`5.1. Controlled vocabulary
`The system has a controlled vocabulary of medical terms covering all essential
`parts of primary health care and general practice. The vocabulary has about 6000
`medical terms. It includes mappings to commonly used national classifications:
`(1) reason for encounter: a Swedish classification;
`(2) diagnoses: a Swedish version of
`ICHPPC2-defined (International
`Classification of Health Problems in Primary Care);
`(3) drugs: ATC (Anatomical Therapeutic Chemical Classification);
`(4) procedures: IC-Process-PC (International Classification of Process in
`Primary Care).
`
`5.2. Patient database
`The patient database of the system comprises in September 1992 (8 years after
`the CPR system had been introduced) about 22000 medical records, 230000
`encounters/contacts, and 3.2 million medical events. This means that the
`average record has about 10 encounters and the average encounter has about 14
`medical events.
`
`5.3. Computer-based drug prescription
`Drugs are prescribed by the physicians on video terminals in their offices
`and electronically transferred to the computer system in the local pharmacy.
`The prescribing system is integrated with the computer-based patient records so
`that the prescriptions are automatically stored in the record and in the medication
`list. Decision support is included in the system on several levels:
`( 1 ) on-line access to part of the Swedish drug catalogue with data on drugs,
`trade names, size of drug packages, doses and routes;
`(2) on-line access to the medical records with information about the problems
`of the patients, and about previous drug prescriptions;
`(3) on-line recommendations from the local drug committee on choice of drugs
`and trade names;
`(4) on-line information about the local therapy tradition and recommendations
`on choice of drug therapy for certain diagnoses;
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0008
`
`

`

`Drug decision support and computer-based records
`
`139
`
`(5) on-line check of the patient’s medication list for potential interactions;
`(6) data-driven
`reminders about potential drug interactions and other
`drug problems.
`
`The decision support system is based on the integrated function of the three
`basic components: the clinical patient database, the controlled vocabulary and the
`knowledge base. Implementation of the decision support system, in particular
`the reminder system, within the medial record system required the creating of
`program modules to interconnect the patient database, the vocabulary, and the
`knowledge base [20]. The MLMs have been implemented using the query language
`of the system as interconnecting module. MLMs are implemented through a
`three-step procedure. First, they are written on forms by the GP panel.
`Second, they are translated to Arden syntax format by a GP familiar with the Arden
`syntax. Third, they are translated to an MQL query by a computer specialist.
`An inference engine module is connected to the drug prescription module so that
`the prescribing of a drug may trigger the MLM, which has the prescribing of
`that drug as evoking criterion. The corresponding MQL query checks the patient
`database according to the logic of the MLM. If the logic evaluates to true, the
`appropriate message will be directed to the display of the prescribing physician.
`The knowledge base comprises now approximately 5000 medical facts, mainly
`drug-drug interactions. Several reminders are under development by the GP panel.
`In the first place, reminders will be implemented concerning cardiovascular drugs
`and their contraindications, appropriate tests to be checked, and reduction of
`dosage for certain drugs due to impaired renal function.
`
`6. Discussion
`Several studies have shown that the physician’s information needs are not being
`met to a sufficient extent during consultation [21-231. The problems are often about
`clinical management, in particular drug therapy. Computer-based decision support
`systems are considered by many to be the main solution to the information needs
`of the practising physician in primary care. We argue that the key issue concerning
`decision support systems today is their integration with computer-based patient
`records. Based on that presumption we have developed a conceptual model of an
`integrated medical information system for primary care and implemented the
`model in a working system in one health care centre.
`
`6.1. Terminology-related problems
`One important problem when developing an integrated decision support system
`is related to terminology, namely the need to express and represent the knowledge
`in the knowledge base in a format that is consistent with the content of the medical
`records and the patient database [24]. The reminders must be evoked when, and
`only when, it is relevant to evoke them. Terms used in the knowledge base must be
`unambiguous in relation to the patient database.
`This problem is even more important when you want to share knowledge in
`MLM format with others, which is exactly what that standard format is intended
`for. When you transfer MLMs from one system to another it is necessary to go
`through a validation process which includes (1) mapping between the systems of the
`medical terms used in the MLM, and (2) validation of the MLM in relation to the
`database in the receiving system.
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0009
`
`

`

`140
`
`R. Linnarsson
`
`is of course the key factor to solving
`The controlled vocabulary itself
`this problem. The controlled vocabulary serves as the most important integrating
`component between the knowledge base and the patient database. But sharing
`knowledge with other institutions using other controlled vocabularies requires
`reliable mechanisms for the mapping of terms between the two vocabularies.
`Several solutions to the mapping problem have been suggested. The U M L S project
`offers the approach of term-to-term translation [25]. A different approach has been
`taken by the European AIM project Galen, which aims at creating an interlingua
`based on the semantical decomposition of terms [26].
`
`6.2. Knowledge representation
`One drawback with the procedural representation used by the Arden syntax
`is that factual medical knowledge can only be represented implicitly, and therefore
`not be reused easily. The general problem of choosing the appropriate kno\vledge
`representation formalism has been described as the declarative/procedural
`controversy 11271. For decision support systems based on the Arden syntax different
`solutions to this problem have been proposed [28-301. We have chosen to use a
`mixed or hybrid representation scheme, combining the Arden syntax for MLMs
`with a semantic net representation for the factual knowledge. The query language
`is used not only to implement the MLMs but also to make queries about factual
`knowledge, such as 'which are the contraindications of drug X' or 'which drugs
`have an interaction with drug X'.
`
`6.3. Eoaluation of the system
`Evaluation of a system like this involves several different aspects [31].
`It is important not to base the evaluation on decision-making accuracy only.
`Besides medical textbook knowledge and medical expertise the knowledge base
`must reflect local factors such as demographic and epidemiological data, therapy
`traditions, etc. T o consider these aspects we will involve a GP panel also in
`the validation of the decision support modules. Another important aspect is
`the integration of the system with the user's environment. In our case the
`computer-based patient records are very well integrated with the routine practice
`at the health centre. The decision support module has to be adapted to that
`environment, improving the computer aid further without allowing it to deteriorate
`in other respects. For example, giving reminders or alerts to the physicians too
`often would be disturbing, and could reduce the attention to the reminders.
`According to the results of the previous database studies referred to above, giving
`alerts for all major and moderate drug interactions would correspond to one alert
`in every 75 drug prescriptions. Whether this is an acceptable level has to be
`evaluated. On the other hand, excluding the data-driven reminders and only gi\ing
`decision support on demand (for example letting the user decide if he wants
`to screen for interactions on the patient's medication list) u i l l , according to our
`experience, seriously reduce the positive impact of the decision support system on
`quality of care.
`
`References
`1 . SIIOI~'I'I,II~I~I,:,
`I<. ti. ( 1 990) Clinical decision-support systems. In .Vlrdiro/ I,/.fr,viiitr/ii.s--('o,irpic/rr.
`Applirotioirs i,r Heo//h C(IIC. 1;. Shortliffe. 1,. Perreaiilt, G . \I'irderhold and I,. 1:agan
`(eds)
`(I<rading. hIA: Addison-\Yesley), pp. 466-502.
`
`Inform Health Soc Care Downloaded from informahealthcare.com by Julie Forbes on 04/06/15
`
`For personal use only.
`
`CFAD VI 1021-0010
`
`

`

`Drug decision support and computer-based records
`
`141
`
`2. SII.:(;I.:L, C., AI,F:SASDliR, M. J., DIXGACZ, Y. D., and FISCHI'.R, S. (1984) Evaluation of a
`computerized drug review system: impact, attitudes, and interactions. Computers and Biomedical
`Research, 17, 419-435.
`3. SWASSOS,
`D. S., BROEKI.:MI~IER, R. L., and ASDERSOS, M. W. (1982) Hospital pharmacy computer
`systems-1982. American Journal of Hospital Pharmacy, 39, 2109-21 17.
`4. SHISS. A. F., SHREWSBCRY, R. P., and ANDERSON, K. W. (1983) Development of a computerized
`drug interaction database (Medicom'"')
`for use in a patient specific environment. Drug Information
`Journal, 17, 205-210.
`5 . HAUISCHII.D, M. J., WARD, E. S., BISHOP, J. M., and HAVSISCHILD, M. S. (1987) Pharmacy-based
`computer system for monitoring and reporting drug interactions. American Journal of Hospital
`Pharmacy, 44, 345-348.
`6. Fos, G. N. (1991) Drug interactions software programs. Journal of Family Practice, 33, 273-280.
`7. KINSEY, E. L. (1986) Expert system detection of drug interactions: results in consecutive inpatients.
`Computers and Biomedical Research, 19, 462-467.
`8. MCDON.AI.D, C. J. (1976) Protocol-based computer reminders, the quality of care and the
`non-perfectability of man. New England Journal of Medicine, 295, 1351-1 355.
`9. MCDOSAI.D, C. J., WILSON, G . A., and McCABI.:, G. P. (1980) Physician response to computer
`reminders. Journal of the American Medical Association, 244, 1579-1 581.
`10. Do~.rs, R. H. (1992) Interfacing a commercial drug-interaction program with an automated medical
`record. M D Computing, 9, 11 5-1 18.
`retrospective dat