R

As

Aa

b

c

d

e

a

A

R

R

2

A

K

D

D

D

H

M

c

M

S

1d

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 641–649

journa l homepage: www. int l .e lsev ierhea l th .com/ journa ls / i jmi

eview

four-phase model of the evolution of clinical decisionupport architectures

dam Wrighta,b,c,∗, Dean F. Sittigd,e

Clinical Informatics Research and Development, Partners HealthCare, Boston, MA, United StatesDivision of General Medicine, Brigham & Women’s Hospital, Boston, MA, United StatesDepartment of Medicine, Harvard Medical School, Boston, MA, United StatesDepartment of Medical Informatics, Northwest Permanente, PC, Portland, OR, United StatesDepartment of Medical Informatics and Clinical Epidemiology, Oregon Health and Science University, Portland, OR, United States

r t i c l e i n f o

rticle history:

eceived 2 June 2007

eceived in revised form

6 January 2008

ccepted 30 January 2008

eywords:

ecision support systems, clinical

ecision making, computer-assisted

ecision support techniques

ospital information systems

edical records systems,

omputerized

odels, theoretical

a b s t r a c t

Background: A large body of evidence over many years suggests that clinical decision support

systems can be helpful in improving both clinical outcomes and adherence to evidence-

based guidelines. However, to this day, clinical decision support systems are not widely

used outside of a small number of sites. One reason why decision support systems are not

widely used is the relative difficulty of integrating such systems into clinical workflows and

computer systems.

Purpose: To review and synthesize the history of clinical decision support systems, and to

propose a model of various architectures for integrating clinical decision support systems

with clinical systems.

Methods: The authors conducted an extensive review of the clinical decision support litera-

ture since 1959, sequenced the systems and developed a model.

Results: The model developed consists of four phases: standalone decision support systems,

decision support integrated into clinical systems, standards for sharing clinical decision sup-

port content and service models for decision support. These four phases have not heretofore

been identified, but they track remarkably well with the chronological history of clinical deci-

sion support, and show evolving and increasingly sophisticated attempts to ease integrating

decision support systems into clinical workflows and other clinical systems.

Conclusions: Each of the four evolutionary approaches to decision support architecture has

unique advantages and disadvantages. A key lesson was that there were common limita-

tions that almost all the approaches faced, and no single approach has been able to entirely

surmount: (1) fixed knowledge representation systems inherently circumscribe the type of

be re

knowledge that can

patient data may be sprea

view of the patient, and (

from one site to another.

∗ Corresponding author at: Division of General Medicine, Brigham & Wtates. Tel.: +1 781 416 8764; fax: +1 781 416 8912.

E-mail address: awright5@partners.org (A. Wright).386-5056/$ – see front matter © 2008 Elsevier Ireland Ltd. All rights resoi:10.1016/j.ijmedinf.2008.01.004

presented in them, (2) there are serious terminological issues, (3)

d across several sources with no single source having a complete

4) major difficulties exist in transferring successful interventions

© 2008 Elsevier Ireland Ltd. All rights reserved.

omen’s Hospital, 1620 Tremont Street, Boston, MA 02120, United

erved.

642 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 641–649

Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6422. Phase 1: standalone decision support systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6423. Phase 2: decision support integrated into clinical systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6444. Phase 3: standards for sharing decision support content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6455. Phase 4: service models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6466. Conclusions and future directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646

. . . . .

. . . . .

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. Introduction

Clinical decision support has been defined in myriad ways,ranging from extremely precise and narrow definitions thatmay exclude broad categories of work to all-encompassingdefinitions. This paper will use a consensus definition ofclinical decision support: “Providing clinicians, patients orindividuals with knowledge and person-specific or populationinformation, intelligently filtered or presented at appropri-ate times, to foster better health processes, better individualpatient care, and better population health” [1].

Decision support systems have been used for a varietyof purposes, ranging from quality and safety to efficiency,and across a variety of clinical domains such as screening,diagnosis and therapy. A substantial body of evidence existsto suggest that decision support systems can be extremelyeffective [2–8]. A recent systemic review by Garg found thatin 100 studies of clinical decision support, “CDSS improvedpractitioner performance in 62 (64%) of the 97 studies assess-ing this outcome, including 4 (40%) of 10 diagnostic systems,16 (76%) of 21 reminder systems, 23 (62%) of 37 diseasemanagement systems, and 19 (66%) of 29 drug-dosing orprescribing systems” [4].

Despite their great potential, and a history of successes,clinical decision support systems have not found wide useoutside of a handful of mostly academic medical centers, theVeterans’ Health Administration (VA), and large, integrateddelivery systems such as Kaiser Permanente [9].

In this paper we review the history of clinical decision sup-port. We endeavored to cover the most influential and widelycited decision support systems throughout the history of thefield and, in particular, to trace the development of architec-tures for clinical decision support systems. By architectures,we mean the way in which decision support systems interact(or choose not to interact) with other related systems, suchas computerized physician order entry (CPOE) and electronichealth record (EHR) systems. Based on our review, we have for-mulated a model with four distinct architectural phases fordecision support:

1. Standalone decision support systems, beginning in 1959.2. Integrated systems, beginning in 1967.3. Standards-based systems, beginning in 1989.

4. Service models, beginning in 2005.

Fig. 1 shows a schematic of the model. These phasesare described in detail in the forthcoming sections. It is

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

worth noting that there are nearly limitless other axesalong which decision support systems can be catego-rized, and accordingly, models could be developed alongnearly any dimension. Other potentially fruitful axes mightinclude clinical intent (diagnosis, therapy, prevention, pub-lic health, telemedicine, etc.), mechanism of intervention(alerts, reminders, critiquing, information-based) or methodof reasoning (forward-chaining, backward-chaining, rule-based, NLP-based, etc.) [10–18].

The proposed architectural model is sequential and evo-lutionary: the phases happened in order and it is clear thatsystems in each phase learned from and were influenced byprior phases. That said, just as in other evolutionary models,the earlier phases have not necessarily faced extinction: thereare still viable Phase 1 systems being built today, even thoughthe architectural state of the art has evolved significantly.

2. Phase 1: standalone decision supportsystems

Pinpointing the beginning of the field of medical informaticsis challenging, but it is perhaps best to begin any discussion ofthe field with the 1959 paper “Reasoning foundations of med-ical diagnosis; symbolic logic, probability, and value theoryaid our understanding of how physicians reason” by Ledleyand Lusted [19]. Ledley went on to invent the whole-body CTscanner [20], and Lusted became a leader in the field of med-ical decision-making. Their 1959 paper, however, laid out aprobabilistic model for medical diagnosis, with grounds inset-theory and Bayesian inference. The article, published inScience, was a tutorial in statistical and probabilistic inferencefor clinicians. The paper proposed an analog computer usedto sort cards. These cards would contain a diagnosis, and aseries of punches which represented symptoms. By selectingthe cards which matched the symptoms present in a givencase, a clinician could develop a differential diagnosis. Thenumber of cards supporting a particular diagnosis representedthe likelihood of that diagnosis. The system could easily beupdated as new patients were seen—the clinician simply hadto fill out and punch a card for each new patient and diagnosis,and drop it into the sorter.

Two years after Ledley and Lusted published their paper,

Warner of the LDS Hospital and the University of Utah pub-lished a mathematical model for diagnosing congenital heartdefects [21]. This model used contingency tables to map symp-toms and signs to diagnoses, based on the frequency of

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 641–649 643

-pha

mdnt

mapgoctbwa

awddbmwIacbpf

tcut

Fig. 1 – A schematic drawing of the four

anifestation for each symptom or sign given an underlyingiagnosis. The system was evaluated by comparing its diag-oses with gold-standard surgical diagnoses, and was foundo compare favorably with experienced cardiologists.

Shortly after Warner, Collen developed a system for “Auto-ated Multiphasic Screening And Diagnosis” which was used

t Kaiser Permanente, and which Collen described in a 1964aper [22]. When a patient came in for an exam he or she wasiven a stack of cards each of which contained a symptomr a question. The patient would put the cards which indi-ated a symptom he or she was experiencing, or a questiono which their answer was affirmative, into a designated “Yes”ox, and the rest of the cards into a “No” box. These cardsere then run through a computer system which proposedn initial differential diagnosis.

In 1969 Bleich developed a system to suggest therapy forcid–base disorders [23]. This system was unique because itas the first system to suggest a therapy in addition to aiagnosis. The system would take in information useful foriagnosing acid–base disorders, such as the results of arteriallood gas tests, vital signs, and clinical findings. If any infor-ation needed for decision-making was missing, the systemould prompt the user to collect and enter that information.

f the information was complete the system would producen evaluation note, written in the same style as a human spe-ialist consultant, proposing a management plan for reviewy the physician providing care. Acid–base disorders were aarticularly apt clinical domain because their management isairly closed and algorithmic.

Two years later, in 1971, de Dombal built a probabilis-

ic model and computer system for diagnosing abdominalomplaints [24,25]. The system was significant because eval-ation showed it to be quite effective. When compared tohe final gold-standard surgical diagnosis, the computer’s

se model for clinical decision support.

preliminary diagnosis was accurate 91.8% of the time. By com-parison, a group of senior clinicians was correct 79.6% of thetime. Not only was the computer able to match the perfor-mance of senior clinicians, it actually improved significantlyon it—cutting the error rate in half.

In the 1970s, the field of artificial intelligence began toinfluence medical informatics. In 1975 Shortliffe applied therelatively new techniques of expert system modeling usingbackward chaining to the problem of antibiotic prescribingwith his system, MYCIN [26]. With MYCIN, a clinician wouldenter what was known about a patient’s infectious process.The system would then apply to these facts a series of rulesfrom its knowledge base. The system could then requestadditional information from the clinician, or suggest whatit considered optimal antibiotic therapy based on the factspresented. Early evaluation showed it suggested acceptabletherapy 75% of the time, and it got better as more rules wereadded.

Most of these early systems would, broadly, take inputof clinical parameters and make suggestions of diagnoses ortherapy. The ATTENDING system [27,28] by Perry Miller of Yale,however, took a different approach. The user of ATTENDINGwould, as with the other systems, input clinical parameters,but he or she would also enter a proposed plan. The sys-tem would then make comments and suggestions about theplan, and it would be up to the user to change the plan basedon these suggestions. This method of interaction was calledcritiquing, and critiquing systems were eventually developedfor ventilator management, hypertension, and other clinicaldomains.

The systems discussed heretofore all have one thing incommon: they are limited to one specific area of medicine,such as antibiotic prescribing, or congenital heart defects. TheINTERNIST-I system [29], developed by Randolph Miller et al. in

i c a l

644 i n t e r n a t i o n a l j o u r n a l o f m e d

the early 1980s attempted to provide diagnostic decision sup-port across the entire field of internal medicine. The system’sknowledge base comprised “15 person-years of work, 500 dis-ease profiles [and], 3550 manifestations of disease” [29]. It wastested on 19 standardized clinical exercises published in theNew England Journal of Medicine, and did about as well as anaverage doctor in proposing the correct diagnosis for the case,but not as well as the experts who wrote the cases up. Onekey intellectual contribution of the INTERNIST system was theway it abstracted the complex field of diagnosis into three con-cepts: evoking strength, frequency and import. Shortly afterINTERNIST, Barnett, and others, released the DXplain system[30]. Unlike INTERNIST, DXplain was designed to explain itsdiagnostic reasoning process. The DXplain system is still avail-able today, and has been updated with a web-interface [31].INTERNIST eventually evolved into the QMR system, thoughneither system is commercially available today.

All of the systems reviewed in this section fall into the cat-egory of standalone decision support systems. That is, theywere systems (usually, but not exclusively, computer pro-grams) which ran separately from any other system. To employone, a clinician had to intentionally and purposefully seek thesystem out, log into it, enter information about his or her case,and then read and interpret the results. Such systems haveseveral key advantages over other types of clinical decisionsupport systems. First, anyone with access to clinical knowl-edge and computing skills can make one. Doing so requires nospecial access to patient-specific clinical data or clinical sys-tems. There is no need to standardize on anything: completelyarbitrary systems can be used for terminology, input structure,output format and knowledge representation. Such systemsare also easy to share—the creator could simply mail a copyof the program to anyone who wished to use his or her system(or, in the modern analog, upload the system to a website).

Along with these advantages, though, standalone clin-ical decision support systems have some significant, andpotentially disqualifying, disadvantages. First and foremost,people have to seek the systems out, so the system cannotbe proactive. But the cause of many medical errors is lack ofknowledge—people do not know what they do not know. Asystem which is not proactive cannot be of assistance in sucha case. The other disadvantage is more practical; these sys-tems were extremely inefficient to use. It could take well overan hour to enter a case into the INTERNIST system, so its usewas, naturally, quite narrow. This limitation was especiallybothersome where systems were dealing with data, such aslaboratory results, that were likely available in electronic formin another system, but which still had to be manually entereddue to a lack of system integration.

3. Phase 2: decision support integrated intoclinical systems

To surmount the significant problems with standalone clin-ical decision support systems, developers began integrating

such systems into other clinical systems, such as CPOE andEHR systems. The HELP system [32], developed at the LDSHospital in Salt Lake City, Utah starting in 1967 was the firstexample of such integration. The system was first used in the

i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 641–649

cardiac catheterization laboratory and in the cardiac intensivecare unit. Subsequently, it was expanded to provide sophisti-cated clinical decision-support capabilities to a wide varietyof clinical areas such as the clinical laboratory, nurse chart-ing, radiology, pharmacy, respiratory therapy, ICU monitoring,and the emergency department to name just a few [32]. TheHELP system is currently operational in most of Intermoun-tain Health Care’s (IHC) over 30 hospitals. HELP had advancedBayesian decision support capabilities, and included modulesfor a variety of functions, including many of the functionsdescribed above. HELP also served as the substrate for manysuccessful projects in clinical decision support, such as Sit-tig’s COMPAS system [33] for ventilator management, a systemfor blood product ordering developed by Gardner [34,35] anda well-known antibiotic advising system developed by Evans[36] among many others.

In 1973, McDonald of the Regenstrief Institute in Indianawas developing the Regenstrief Medical Record System (RMRS)[37]. This system used a large base of rules to make sugges-tions about care. The system was evaluated in an experimentaltrial. In the first half of the trial, half of the users of the RMRSsystem received suggestions based on the database of ruleswhile half received no suggestions. Dr. McDonald found thatphysicians carried out the suggestions they received 51% ofthe time. However, when they did not receive suggestions,they carried out the appropriate care only 22% of the time[38]. Even more interesting, when the system was turned off,performance went back to baseline almost immediately—thephysicians who had been receiving the alerts, dropped downto pre-trial levels: there was no learning effect. In this land-mark paper, McDonald argued that medicine had become socomplex, and the amount of information required to practice iteffectively so expansive, that no un-aided human could pro-vide perfect care. Instead, some sort of ancillary aid, like acomputer, was needed.

In addition to HELP and RMRS, a variety of other clinicalsystems, mostly at academic medical centers, have been usedfor clinical decision support, beginning in 1980s and 1990s.The WizOrder system [39], in use at Vanderbilt, and now avail-able commercially as Horizon Expert Orders from McKessonhas been a fruitful development platform, as has the BrighamIntegrated Computing System (BICS) in use at the Brigham &Women’s Hospital [40,41]. BICS includes support for a varietyof CDS interventions including clinical pathways which canguide clinicians through data entry and ordering tasks accord-ing to a specific clinical purpose, as well as supplementaltime-based pathway support, such as reminding clinicians tocomplete orders relevant to a pathway which are not yet done.The Veterans Health Administration has also been a leaderin the field of clinical decision support with their Computer-ized Patient Record System (CPRS) [42], reporting spectacularoutcomes for even simple interventions, and quickly rocket-ing from a position as one of the lower-performing healthcaresystems, to a quality leader [43].

Integrating CDS into clinical information systems solvedsome problems, while creating others. Integrated systems

have two key advantages over standalone systems: first,the user does not have to reenter information which isalready stored electronically; and, second, such systems canbe proactive—they can alert a user to a dangerous drug–drug

a l i n

itidaituppctwhsebd

4s

IvdSdadbtc

McTsrtioets“advpsrsmwtctii

i n t e r n a t i o n a l j o u r n a l o f m e d i c

nteraction or a dosing error without the user seeking assis-ance. The major downside of integrated systems is that theres no easy way to share them or reuse their content. Stan-alone systems can be easily shared; often by simply mailingtape or emailing an executable program. In contrast, since

ntegrated systems are built directly into larger clinical sys-ems they cannot be directly shared with others who are notsing the same clinical system. Also, integrating decision sup-ort into a clinical system can create knowledge-managementroblems. It is hard to separate knowledge from code; if alinical guideline is updated, it may be necessary to reviewhe entire source code for a clinical system to find the placeshere this guideline is used. And finally, nearly everyone whoas been successful at developing integrated decision supportystems has also developed their own clinical system. How-ver, the vast majority of hospitals and doctors buy rather thanuild clinical systems so this limitation has kept this type ofecision support from seeing wide adoption.

. Phase 3: standards for sharing decisionupport content

n response to the inability to share decision support content, aariety of efforts have been undertaken to standardize clinicalecision support content. Foremost among these is the Ardenyntax [44–48]. The initial version of the Arden Syntax waseveloped at a 3-day consensus meeting in June of 1989 heldt the Arden Homestead in New York from which the stan-ard got its name. The standard combined the syntaxes usedy the HELP system and the RMRS system because these sys-ems were (and to an extent, still are) the two most prominentlinical systems. Both systems are discussed above.

Rules encoded in Arden Syntax are called Medical Logicodules. The Arden Syntax divides rules into three sections,

alled the “maintenance”, “library” and “knowledge” sections.he maintenance section contains meta-data about the rule,uch as who owns it, when it was created, when it was lasteviewed or updated, and its validation status. The library sec-ion contains meta-data describing the clinical role of the rule,ts purpose, an explanation, keywords, and a citation to theriginal source of the guideline or best practice that the rulencodes. The computable portion of the rule is encoded inhe knowledge section. The knowledge section contains sub-ections called “type”, “data”, “evoke”, “logic”, “action” andurgency”. In the current version of Arden Syntax, type islways set to “data-driven” because this is the only mode ofecision support offered. The data section is used to read dataalues, such as recent lab tests, medications lists, or clinicalroblems from the encompassing clinical system. The evokeection contains one or more triggers that might cause theule to fire, such as “new potassium value stored”. The logicection encodes the rule, generally as a series of if-then state-ents, and the action section encodes what the rule doeshen its logic section is satisfied—in general, Arden Syn-

ax has only been used to raise alerts. The urgency section

ontains a number between 1 and 100 to encode how impor-ant that rule is. The guidelines used to assign urgencies ismplementation dependent, and not fully defined in the spec-fication.

f o r m a t i c s 7 7 ( 2 0 0 8 ) 641–649 645

Arden Syntax has had some limited commercial suc-cess. Three clinical system vendors (Eclipsys, McKesson andSiemens), which together represent about a quarter of theoverall clinical information system market, offer some sup-port for the Arden Syntax, and a number of vendors, mostnotably Thomson Micromedex (Denver, CO) and Zynx (LosAngeles, CA) sell Medical Logic Modules.

Arden syntax has two key limitations: first, it can only beused to encode event-driven, patient-specific rules. For usecases such as drug–drug interaction checking, or panic labvalue alerting, this modality is sufficient. However, becauseArden Syntax is patient-specific, it cannot be used forpopulation-based decision support (such as a quality-of-caredashboard), and because it is event-driven, it cannot be usedfor point-of-care reference or information retrieval support.The other key limitation relates to vocabulary: Arden Syn-tax does not define a standard vocabulary for things like labtests, drugs or procedures. As a result, even if two clinical sys-tems support the Arden Syntax, if they use different clinicalterminologies, Arden Syntax rules from one system cannotbe used in the other system without modification. For exam-ple, if one hospital’s clinical system stored a blood test resultas “Serum Potassium” and another hospital’s clinical systemstored the same result as “K+” a human-guided mappingwould be needed. To assist in this mapping, Arden Syn-tax wraps system-specific terminological expressions in curlybraces, and automated tools exist to help the implementer dis-ambiguate these bracketed terms, but human intervention isstill required. This problem is so limiting and well-known thatit is referred to simply as the “curly braces problem.” The ArdenSyntax has been revised several times since it was first cre-ated in 1989, and its most recent version (Version 2.6) has beenaccepted as a standard by both the American National Stan-dards Institute (ANSI), and Health Level 7 (HL7), a healthcarestandards body [49].

Since the creation of Arden Syntax, numerous other stan-dards for representing and sharing decision support contentand knowledge have been created. Many of these efforts havestalled, but one effort in particular, the Guideline InterchangeFormat [50] (GLIF), developed over the past decade, has gainedsome traction. Unlike Arden Syntax, which is mostly designedfor Alerts and Reminders, GLIF focuses on more complexmulti-part guidelines, including complex clinical pathwaysthat take place in phases or over time. A general-purposeexecution engine for executing GLIF guidelines has beendescribed [51], but it has not yet been implemented in anycommercially available system.

Although GLIF is not currently available in any commercialsystem, it was pilot tested from 2000 to 2003 by a group of threeuniversities: Stanford, Columbia and Harvard, calling them-selves the InterMed Consortium [52]. The consortium receiveda grant to practice encoding and sharing rules in GLIF, and hadsome success in doing so. By pilot testing the standard, theconsortium learned many lessons about the scope and poten-tial of the language, and used many of these findings to refineand improve the language.

Many other standards for representing decision supportcontent in a standardized way exist. OpenClinical.org [53]provides an overview of guideline and knowledge modelingstandards, such as Arden Syntax, GLIF and GELLO. HL7 man-

i c a l

646 i n t e r n a t i o n a l j o u r n a l o f m e d

ages a number of these projects, including Arden Syntax, aDecision Support Service (DSS), which will be discussed in thenext section, and a promising new order set standard.

The use of standards to represent, encode, store andshare knowledge overcomes many of the disadvantages ofthe natively integrated decision support systems describedin Phase 2 above. It provides a method for sharing the deci-sion support content, and separates the code describing suchcontent from the code which implements the clinical infor-mation system. However, standards also have some inherentlimitations and disadvantages. First, there are often too manystandards to choose from several dozen standards are avail-able to represent simple alerts and reminders. The secondproblem is that any encoding standard inherently constrainswhat a user can encode in the standard to that which thestandard-writer intended and included in the scope of thestandard. At the time that Arden Syntax was developed,the goal was to develop a system for patient-specific event-driven decision support and, as such, this is the only typeof decision support that can be encoded in Arden Syntax.This limitation is not present in standalone or natively inte-grated decision support systems since their scope is limitedonly by the underlying capabilities of the programming lan-guages and data models used. Terminology issues have alsosignificantly limited the adoption of these standards—unlessclinical systems and decision support systems share a com-mon terminology standard, cumbersome mappings must beundertaken. Finally, even if there were a perfect standard forsharing decision support rules and guidelines, there are sig-nificant unanswered questions about where such guidelineswould be kept, how they would be owned, who would be liablefor them, how they would be evaluated, or who would keepthem up to date.

5. Phase 4: service models

More recent efforts have separated the clinical informationsystem and clinical decision support system components ofan integrated decision support system, and recombined themby using a standard application programming interface (API).The first effort along this front was the Shareable Active Guide-line Environment project (SAGE) [54,55]. SAGE placed an API infront of the clinical system. A properly designed SAGE rulecould interact with any clinical system that supported thisSAGE-compliant API. The approach that SAGE took, placinga standardized interface in front of the clinical system, hasbeen termed a Virtual Medical Record (VMR) approach [56].The principle advantage of this approach is that it solves thevocabulary problem—the SAGE virtual medical record speci-fies the vocabularies that will be used to access and processthe medical record, and to the extent that a clinical systemuses different terminologies, it is required to provide a suit-able mapping. Like Arden Syntax, SAGE requires a standardguideline format, necessarily constraining the type of decisionsupport that can be implemented in SAGE.

SEBASTIAN, a more recent system first described in 2005,has taken the opposite approach from SAGE [57]. It placesa standardized interface in front of clinical decision supportmodules, and makes only limited demands on the clinical sys-

i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 641–649

tem to store data in any particular way. In this model, anyclinical system which understands the SEBASTIAN protocolcan make queries of centralized Decision Support Services.SEBASTIAN maintains most of the same advantages of some-thing like the Arden Syntax, while freeing the user from therestrictions that statically defined knowledge representationformats impose. Moreover, since the modules are located onthe Internet, they can be shared by more than one hospital,allowing for greater efficiency. However, SEBASTIAN makessignificant demands of the consumers (i.e. clinical systems)of the services it provides. First, although SEBASTIAN is stan-dardized, each knowledge module is free to require any givenset of data, which the clinical system must fetch and pro-vide. Moreover, two SEBASTIAN knowledge modules may usedifferent vocabulary standards, forcing the consumer of theservice to provide the same data more than once in differentencodings (and necessitating that the clinical systems providesupport for all the vocabulary standards chosen). Also, SEBAS-TIAN requires that a service consumer move patient data tothe service, which some hospitals or providers may be reluc-tant to do. Further, because the amount of patient data neededmay potentially be large, performance issues may manifest,although in early testing to this point, performance has beenacceptable [57]. These limitations aside, the SEBASTIAN archi-tecture is promising. SEBASTIAN began as a Ph.D. studentproject, but progress is now continuing through HL7 [58] asthe HL7 DSS. The HL7 DSS uses the HL7 Version 3 ReferenceInformation Model (RIM) as its patient data model. If adopted,this would resolve the vocabulary challenges described above.Perhaps more concerning is a recent revelation that the cre-ators of SEBASTIAN have filed for a patent on their model[59–61], creating a degree of intellectual property and licensinguncertainty for other potential implementers of the approach.

Both of these interface-oriented systems provide signifi-cant advantages over the systems which require a standardrepresentation, and both are promising. However, each sys-tem constrains itself to fully standardizing only one of the twointerfaces at the junction between a clinical decision supportsystem and a clinical system, limiting their potential for suc-cess. Also, both systems principally look at only one clinicalsystem and one decision support system at a time, although,in the real world, knowledge about a patient (that is stored ina clinical system) and knowledge of medicine (that is storedin a decision support system) can be fragmented across manysites.

6. Conclusions and future directions

Although the four phases we describe here happed in roughlysequential order, it is important to note that decision sup-port systems are still being developed in all four of them.There appears to be some drift, over time, towards more use ofthe later phases (particularly integrated and standards-basedapproaches) and less use of entirely stand-alone systems, butthese later phases have not, yet, fully supplanted the earlier

ones. This is analogous to biological evolution, where evolu-tionarily favored variant alleles coexist with ancestral allelesfor quite some time until a point of fixation is reached. Wesuspect that the point of fixation for decision support archi-

a l i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 641–649 647

tee

sbtlownp[

scsfkc

sHwrsnbHCd

sHPegpgt

sataetbispfiohnWedso

Summary pointsWhat was known before this paper

• Clinical decision support systems can be effective toolsfor improving the quality of healthcare.

• A variety of such systems have been developed anddescribed in the literature, frequently yielding signifi-cant improvements in domains ranging from diagnosisto therapy and prevention.

• A common feature of many clinical decision sup-port systems is a mechanism for integrating suchsystems into clinical information systems such aselectronic health records and computerized physicianorder entry systems.

What is learned as a result

• In this work, the authors review the history of evolu-tion of clinical decision support systems from 1959 topresent with a particular emphasis on the mechanismthese systems used to integrate with clinical informa-tion systems.

• As part of the review, the authors propose a four-phase architectural model for how these mechanismsof integration have evolved, beginning with standalonesystems, and continuing through increasingly sophis-ticated levels of integration.

r

i n t e r n a t i o n a l j o u r n a l o f m e d i c

ectures is distant, and that all four models will continue to bemployed for quite awhile, and perhaps further models willmerge.

In the nearer term, we do expect to see increased use ofervice models (Phase 4) as their modularity allows for theenefits of integrated and standard-based systems withoutheir respective inherent limitations of non-portability andimited range of representable knowledge. As performancef, and access to, high-speed computer networks increasee expect this trend to accelerate. We are already begin-ing to see a trend towards wider use of service-orientedaradigms in clinical systems and clinical decision support

60–67], although others have expressed their concerns [61].Ongoing work in HL7 towards developing a standard for

ervice-oriented decision support is encouraging, and suc-essful adoption of such a standard in commercial clinicalystems would be a significant step forward. We are hope-ul for, but less optimistic about, wide-spread support of anowledge-representation standard such as Arden Syntax inommercial clinical systems.

Formal adoption of either a knowledge representationtandard (Phase 3) or a service protocol (Phase 4) through theealthcare Information Technology Standards Panel (HITSP)ould be helpful in this regard, as would addition of this as a

equirement for EHR certification by the Certification Commis-ion for Health Information Technology. While neither HITSPor CCHIT have announced any formal plans in this regard,oth have expressed an interest in this area. The Americanealth Information Community (AHIC)’s newly formed ad hocommittee on Clinical Decision Support may be an importantriver of these efforts going forward.

We expect that broader efforts to standardize data repre-entation formats and terminologies within EHRs, as led byITSP, will facilitate increased use of clinical decision support.hases 2–4 all depend on availability of patient data, and thesefforts have often been hampered by the variable terminolo-ies and data representation formats used across commercialroducts (and even across multiple implementations of a sin-le product). As these models are further standardized, theask of developing decision support becomes easier.

Each of the four evolutionary approaches to decisionupport architecture has had unique advantages and dis-dvantages, which are described in detail above. That said,here were some common limitations that almost all thepproaches faced, and that no single approach has been able tontirely surmount: first, fixed knowledge representation sys-ems inherently circumscribe the type of knowledge that cane represented in them, second, there are serious terminolog-

cal issues, third, patient data may be spread across severalources with no single source having a complete view of theatient, and fourth, and perhaps most significant, major dif-culties exist in transferring successful interventions fromne site to another. Although a small number of institutionsad great success with decision support, this success couldot be (or was not) widely replicated in community settings.e are hopeful that, as these models for decision support

volve and mature, and as new models emerge, these pastifficulties can be overcome and adoption of effective decisionupport interventions will increase across the entire spectrumf care.

Acknowledgements

Funding: This work was funded in part by NLM Training Grant1T15LM009461 and NLM Research Grant R56-LM006942-07A1.

e f e r e n c e s

[1] J.A. Osheroff, J.M. Teich, B. Middleton, E.B. Steen, A. Wright,D.E. Detmer, A roadmap for national action on clinicaldecision support, J. Med. Inform. Assoc. 14 (2) (2007)141–145.

[2] E.A. Balas, S. Weingarten, C.T. Garb, D. Blumenthal, S.A.Boren, G.D. Brown, Improving preventive care by promptingphysicians, Arch. Intern. Med. 160 (3) (2000) 301–308.

[3] M.D. Cabana, C.S. Rand, N.R. Powe, et al., Why don’tphysicians follow clinical practice guidelines? A frameworkfor improvement, JAMA 282 (15) (1999) 1458–1465.

[4] A.X. Garg, N.K. Adhikari, H. McDonald, et al., Effects ofcomputerized clinical decision support systems onpractitioner performance and patient outcomes: asystematic review, JAMA 293 (10) (2005) 1223–1238.

[5] J.M. Grimshaw, I.T. Russell, Effect of clinical guidelines onmedical practice: a systematic review of rigorousevaluations, Lancet 342 (8883) (1993) 1317–1322.

[6] D.L. Hunt, R.B. Haynes, S.E. Hanna, K. Smith, Effects ofcomputer-based clinical decision support systems onphysician performance and patient outcomes: a systematicreview, JAMA 280 (15) (1998) 1339–1346.

i c a l

648 i n t e r n a t i o n a l j o u r n a l o f m e d

[7] M.E. Johnston, K.B. Langton, R.B. Haynes, A. Mathieu, Effectsof computer-based clinical decision support systems onclinician performance and patient outcome. A criticalappraisal of research, Ann. Intern. Med. 120 (2) (1994)135–142.

[8] K. Kawamoto, C.A. Houlihan, E.A. Balas, D.F. Lobach,Improving clinical practice using clinical decision supportsystems: a systematic review of trials to identify featurescritical to success, BMJ 330 (7494) (2005) 765.

[9] B. Chaudhry, J. Wang, S. Wu, et al., Systematic review: impactof health information technology on quality, efficiency, andcosts of medical care, Ann. Intern. Med. 144 (10) (2006).

[10] R.A. Miller, Medical diagnostic decision supportsystems—past, present, and future: a threaded bibliographyand brief commentary, J. Am. Med. Inform. Assoc. 1 (1) (1994)8–27.

[11] J.M. Teich, M.M. Wrinn, Clinical decision support systemscome of age, MD Comput. 17 (1) (2000) 43–46.

[12] A. Wright, H. Goldberg, T. Hongsermeier, B. Middleton, Adescription and functional taxonomy of rule-based decisionsupport content at a large integrated delivery network, J.Am. Med. Inform. Assoc. (2007).

[13] I. Sim, P. Gorman, R.A. Greenes, et al., Clinical decisionsupport systems for the practice of evidence-basedmedicine, J. Am. Med. Inform. Assoc. 8 (6) (2001) 527–534.

[14] R.A. Miller, L.R. Waitman, S. Chen, S.T. Rosenbloom, Theanatomy of decision support during inpatient care providerorder entry (CPOE): empirical observations from a decade ofCPOE experience at Vanderbilt, J. Biomed. Inform. 38 (6)(2005) 469–485.

[15] J.A. Osheroff, E.A. Pifer, J.M. Teich, D.F. Sittig, R.A. Jenders,Improving Outcomes with Clinical Decision Support: AnImplementer’s Guide, HIMSS, Chicago, IL, 2005.

[16] J.K. Wang, M.M. Shabot, R.G. Duncan, J.X. Polaschek, D.T.Jones, A clinical rules taxonomy for the implementation of acomputerized physician order entry (CPOE) system, Proc.AMIA Annu. Symp. (2002) 860–863.

[17] T. Falas, G. Papadopoulos, A. Stafylopatis, A review ofdecision support systems in telecare, J. Med. Syst. 27 (4)(2003) 347–356.

[18] P.L. Miller, Critiquing: a different approach to expertcomputer advice in medicine, Med. Inform. (Lond.) 11 (1)(1986) 29–38.

[19] R.S. Ledley, L.B. Lusted, Reasoning foundations of medicaldiagnosis; symbolic logic, probability, and value theory aidour understanding of how physicians reason, Science 130(3366) (1959) 9–21.

[20] D.F. Sittig, J.S. Ash, R.S. Ledley, The story behind thedevelopment of the first whole-body computerizedtomography scanner as told by Robert S. Ledley, J. Am. Med.Inform. Assoc. 13 (5) (2006) 465–469.

[21] H.R. Warner, A.F. Toronto, L.G. Veasey, R. Stephenson, Amathematical approach to medical diagnosis. Application tocongenital heart disease, JAMA 177 (1961) 177–183.

[22] M.F. Collen, L. Rubin, J. Neyman, G.B. Dantzig, R.M. Baer, A.B.Siegelaub, Automated multiphasic screening and diagnosis,Am. J. Public Health Nations Health 54 (1964) 741–750.

[23] H.L. Bleich, Computer evaluation of acid–base disorders, J.Clin. Invest. 48 (9) (1969) 1689–1696.

[24] F.T. de Dombal, J.C. Horrocks, J.R. Staniland, P.J. Guillou,Construction and uses of a ‘data-base’ of clinicalinformation concerning 600 patients with acute abdominalpain, Proc. R. Soc. Med. 64 (9) (1971) 978.

[25] F.T. de Dombal, D.J. Leaper, J.R. Staniland, A.P. McCann, J.C.

Horrocks, Computer-aided diagnosis of acute abdominalpain, Br. Med. J. 2 (5804) (1972) 9–13.

[26] E.H. Shortliffe, R. Davis, S.G. Axline, B.G. Buchanan, C.C.Green, S.N. Cohen, Computer-based consultations in clinical

i n f o r m a t i c s 7 7 ( 2 0 0 8 ) 641–649

therapeutics: explanation and rule acquisition capabilitiesof the MYCIN system, Comput. Biomed. Res. 8 (4) (1975)303–320.

[27] P.L. Miller, Critiquing anesthetic management: the“ATTENDING” computer system, Anesthesiology 58 (4) (1983)362–369.

[28] P.L. Miller, Extending computer-based critiquing to a newdomain: ATTENDING, ESSENTIAL-ATTENDING, andVQ-ATTENDING, Int. J. Clin. Monit. Comput. 2 (3) (1986)135–142.

[29] R.A. Miller, H.E. Pople Jr., J.D. Myers, Internist-1, anexperimental computer-based diagnostic consultant forgeneral internal medicine, N. Engl. J. Med. 307 (8) (1982)468–476.

[30] G.O. Barnett, J.J. Cimino, J.A. Hupp, E.P. Hoffer, DXplain, Anevolving diagnostic decision-support system, JAMA 258 (1)(1987) 67–74.

[31] MGH Laboratory of Computer Science, DXplain, Availablefrom http://www.lcs.mgh.harvard.edu/dxplain.asp (cited onDecember 1, 2006) 2005.

[32] G.J. Kuperman, R.M. Gardner, T.A. Pryor, HELP: A DynamicHospital Information System, Springer-Verlag, New York,1991.

[33] D.F. Sittig, R.M. Gardner, N.L. Pace, A.H. Morris, E. Beck,Computerized management of patient care in a complex,controlled clinical trial in the intensive care unit, Comput.Methods Programs Biomed. 30 (2–3) (1989) 77–84.

[34] E.F. Lepage, R.M. Gardner, R.M. Laub, O.K. Golubjatnikov,Improving blood transfusion practice: role of acomputerized hospital information system, Transfusion 32(3) (1992) 253–259.

[35] R.M. Gardner, O.K. Golubjatnikov, R.M. Laub, J.T. Jacobson,R.S. Evans, Computer-critiqued blood ordering using theHELP system, Comput. Biomed. Res. 23 (6) (1990) 514–528.

[36] R.S. Evans, S.L. Pestotnik, D.C. Classen, et al., Acomputer-assisted management program for antibiotics andother antiinfective agents, N. Engl. J. Med. 338 (4) (1998)232–238.

[37] C.J. McDonald, R. Murray, D. Jeris, B. Bhargava, J. Seeger, L.Blevins, A computer-based record and clinical monitoringsystem for ambulatory care, Am. J. Public Health 67 (3) (1977)240–245.

[38] C.J. McDonald, Protocol-based computer reminders, thequality of care and the non-perfectability of man, N. Engl. J.Med. 295 (24) (1976) 1351–1355.

[39] A. Geissbuhler, R.A. Miller, Clinical application of the UMLSin a computerized order entry and decision-support system,Proc. AMIA Symp. (1998) 320–324.

[40] J.M. Teich, C.D. Spurr, S.J. Flammini, et al., Response to a trialof physician-based inpatient order entry, Proc. Annu. Symp.Comput. Appl. Med. Care (1993) 316–320.

[41] D.W. Bates, J.M. Teich, J. Lee, et al., The impact ofcomputerized physician order entry on medicationerror prevention, J. Am. Med. Inform. Assoc. 6 (4) (1999)313–321.

[42] T.G. Thompson, D.J. Brailer, The Decade of HealthInformation Technology: Delivering Consumer-centric andInformation-rich Health Care, US Department of Health andHuman Services, Washington, DC, 2004.

[43] A.K. Jha, J.B. Perlin, K.W. Kizer, R.A. Dudley, Effect of thetransformation of the Veterans Affairs Health Care Systemon the quality of care, N. Engl. J. Med. 348 (22) (2003)2218–2227.

[44] Health Level 7, Arden Syntax for Medical Logic Systems

Standard Version 2.5, American National StandardsInstitute, Washington, DC, 2004.

[45] G. Hripcsak, Arden Syntax for medical logic modules, MDComput. 8 (2) (1991) 76,8.

a l i n

i n t e r n a t i o n a l j o u r n a l o f m e d i c

[46] G. Hripcsak, P. Ludemann, T.A. Pryor, O.B. Wigertz, P.D.Clayton, Rationale for the Arden Syntax, Comput. Biomed.Res. 27 (4) (1994) 291–324.

[47] R.A. Jenders, G. Hripcsak, R.V. Sideli, et al., Medical decisionsupport: experience with implementing the Arden Syntax atthe Columbia-Presbyterian Medical Center, Proc. Annu.Symp. Comput. Appl. Med. Care (1995) 169–173.

[48] H.C. Karadimas, C. Chailloleau, F. Hemery, J. Simonnet, E.Lepage, Arden/J: an architecture for MLM executionon the Java platform, J. Am. Med. Inform. Assoc. 9 (4) (2002)359–368.

[49] Health Level 7, Arden Syntax for Medical Logic SystemsStandard Version 2.6, Health Level 7, Ann Arbor, MI, 2007.

[50] L. Ohno-Machado, J.H. Gennari, S.N. Murphy, et al., Theguideline interchange format: a model for representingguidelines, J. Am. Med. Inform. Assoc. 5 (4) (1998) 357–372.

[51] D. Wang, M. Peleg, S.W. Tu, et al., Design andimplementation of the GLIF3 guideline execution engine, J.Biomed. Inform. 37 (5) (2004) 305–318.

[52] M. Peleg, A.A. Boxwala, S. Tu, et al., The InterMed approachto sharable computer-interpretable guidelines: a review, J.Am. Med. Inform. Assoc. 11 (1) (2004) 1–10.

[53] OpenClinical, Summaries of guideline representationmethods, Available from http://www.openclinical.org/gmmsummaries.html (cited on May 3, 2006) 2006.

[54] C.G. Parker, R.A. Rocha, J.R. Campbell, S.W. Tu, S.M. Huff,Detailed clinical models for sharable, executable guidelines,Medinfo 11 (Pt 1) (2004) 145–148.

[55] P. Ram, D. Berg, S. Tu, et al., Executing clinical practiceguidelines using the SAGE execution engine, Medinfo 11 (Pt1) (2004) 251–255.

[56] P.D. Johnson, S.W. Tu, M.A. Musen, I. Purves, A virtualmedical record for guideline-based decision support, Proc.

AMIA Symp. (2001) 294–298.

[57] K. Kawamoto, D.F. Lobach, Design, implementation, use, andpreliminary evaluation of SEBASTIAN, a standards-basedweb service for clinical decision support, Proc. AMIA Symp.(2005).

f o r m a t i c s 7 7 ( 2 0 0 8 ) 641–649 649

[58] Health Level 7, Patient Evaluation Service Draft Standard,Health Level 7, Ann Arbor, MI, 2005.

[59] D. Lobach, K. Kawamoto, inventors, Clinical DecisionSupport System [provisional patent application], WorldIntellectual Property Organization, Available fromhttp://www.wipo.int/pctdb/en/wo.jsp?wo=2007030425 (citedon June 01, 2007) 2006.

[60] K. Kawamoto, D.F. Lobach, Proposal for fulfilling strategicobjectives of the U.S. roadmap for national action on clinicaldecision support through a service-oriented architectureleveraging HL7 services, J. Am. Med. Inform. Assoc. 14 (2)(2007) 146–155.

[61] P. Nadkarni, R. Miller, Service-oriented architecture inmedical software: promises and perils, J. Am. Med. Inform.Assoc. 14 (2) (2007).

[62] J. Lamont, Decision support systems prove vital tohealthcare, KMWorld, February 01, 2007.

[63] J. Glaser, S. Flammini, The Service-Oriented Solution forHealth IT, HHN Most Wired, November 09, 2006.

[64] HL7 Services Specification Project Workgroup, OMGHealthcare Domain Task Force, Healthcare ServicesSpecification Project: The Business Case and Importance ofServices (presentation), Available from http://hssp.wikispaces.com/space/showimage/2007-01 07 HSSPPublic Slide Deck Version 1.2.ppt (cited on February 09,2007) 2005.

[65] A. Wright, SANDS: an architecture for clinical decisionsupport in a National Health Information Network,Dissertation, Oregon Health & Science University; Portland,OR: 2007.

[66] V. Kashyap, A. Morales, T. Hongsermeier, On implementingclinical decision support: achieving scalability andmaintainability by combining business rules and ontologies,

AMIA Annu. Symp. Proc. (2006) 414–418.

[67] H.S. Goldberg, M. Vashevko, A. Pastilnik, K. Smith, N. Plaks,B.M. Blumenfeld, Evaluation of a commercial rule engine asa basis for a clinical decision support service, AMIA Annu.Symp. Proc. (2006) 294–298.