Search tips
Search criteria 


Logo of procamiaLink to Publisher's site
AMIA Annu Symp Proc. 2012; 2012: 446–455.
Published online 2012 November 3.
PMCID: PMC3540445

Clinical Information System Services and Capabilities Desired for Scalable, Standards-Based, Service-oriented Decision Support: Consensus Assessment of the Health Level 7 Clinical Decision Support Work Group


A standards-based, service-oriented architecture for clinical decision support (CDS) has the potential to significantly enhance CDS scalability and robustness. To enable such a CDS architecture, the Health Level 7 CDS Work Group reviewed the literature, hosted multi-stakeholder discussions, and consulted domain experts to identify and prioritize the services and capabilities required from clinical information systems (CISs) to enable service-oriented CDS. In addition, relevant available standards were identified. Through this process, ten CIS services and eight CIS capabilities were identified as being important for enabling scalable, service-oriented CDS. In particular, through a survey of 46 domain experts, five services and capabilities were identified as being especially critical: 1) the use of standard information models and terminologies; 2) the ability to leverage a Decision Support Service (DSS); 3) support for a clinical data query service; 4) support for an event subscription and notification service; and 5) support for a user communication service.


A central rationale for investing in health information systems is to enable improved healthcare through clinical decision support (CDS). This entails providing clinicians, staff, patients, and other individuals with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care.1 CDS interventions have significantly improved clinical practice in close to 70% of randomized controlled trials, with the success rate rising to over 90% when computer-based CDS is automatically delivered to clinicians as actionable care recommendations within their routine clinical workflows.2

Despite significant promise, advanced CDS capabilities are not widely available.1,2 While there are many reasons for this limited availability, an important reason is that CDS capabilities are typically tightly coupled to individual software modules within specific clinical information systems (CISs).1,3 For example, an alerting capability may be tightly coupled to the computerized provider order entry (CPOE) module of a specific electronic health record (EHR) system. As the scope of potentially useful CDS clearly surpasses the scope of CDS that can be reasonably provided by any single vendor or healthcare delivery organization, it becomes imperative to establish an architectural framework in which CDS capabilities and content can be developed by multiple independent groups and utilized in multiple CISs.

In general, there are two complementary architectures for scaling CDS.4 In the first option, CDS knowledge is encapsulated using a standard formalism, and individual CISs develop execution environments which can utilize the knowledge. The Health Level 7 (HL7) Arden Syntax standard5 and the HL7 GELLO standard6 have been adopted as standards for representing clinical rules and guidelines, but challenges related to the local mapping of concepts and data elements have adversely affected knowledge transfer beyond the originating healthcare organization.

Moreover, the HL7 CDS Work Group has attempted in the past to develop an industry standard for representing executable clinical practice guidelines, for example based on the Guideline Interchange Format (GLIF).7 However, research, development, and implementation of GLIF have been relatively dormant for several years, and the prospect of achieving industry consensus around a single comprehensive knowledge representation standard for CDS remains unlikely for the foreseeable future.

A second option for scaling CDS is the use of a service-oriented architecture (SOA). A SOA can be utilized to provide a system in which independent services are coordinated to deliver the desired functionality.8,9 For example, a point-of-care disease management module of an EHR system can be efficiently implemented by leveraging software services such as a clinical data query service, a terminology service, a communication service, and a Decision Support Service (DSS) that takes in structured patient data and provides back patient-specific care guidance.4 SOAs for CDS have been proposed and shown to have significant promise by many investigators, including through the SAGE project,10 SEBASTIAN,4,11 the DDS-KMR project,12 and the CDS Consortium.13 Indeed, when coupled with the use of standard service interfaces, this approach could potentially fulfill the strategic objectives set forth in the U.S. Roadmap for National Action on CDS commissioned by the U.S. Office of the National Coordinator for Health Information Technology.14

While a variety of individual research groups have proposed the services and other capabilities desired from EHR systems and other CISs to facilitate a SOA for CDS,4,10,1214 there has to date been no community-wide attempt to establish industry consensus on these requirements. The HL7 CDS Work Group has previously sought to specify a component-based architecture for CDS, but the components were not defined as services, and they were specified as modules within a single, integrated CIS. Furthermore, although a taxonomy of desired CIS capabilities for CDS has been previously proposed based on the rich history of CDS within the Partners HealthCare System,15,16 that taxonomy does not specifically address what is needed to support a SOA for CDS. As a result, CIS developers do not have sufficient guidance to identify how to optimally support a SOA for CDS; CIS purchasers and users do not have a coherent set of specifications to serve as the basis of requests for proposals and for enhancement requests; and CDS developers do not have a clear sense of what services and other capabilities they can expect to be available for implementing CDS for various CISs.

In a series of strategic planning sessions conducted by the HL7 CDS Work Group in January 2012, the Work Group identified as a key strategic priority the establishment of community consensus on the services and other capabilities desired from CISs to enable a SOA for CDS. In particular, this problem represented a significant business need for member organizations planning next generation CISs, which needed a specification of these requirements to guide the development and requisition of their next-generation CISs. To address this need, the HL7 CDS Work Group conducted a formal study to inform such a specification. The results of this study are presented in this manuscript.


Architectural Assumptions

While there are many ways in which services can be orchestrated to enable CDS, we posit that a SOA for CDS will typically be instantiated using one of two general patterns.

Architecture 1: CIS-centric SOA

In the first general architecture, the software module orchestrating the CDS capability (henceforth referred to as the CDS controller module) is an embedded component within the CIS. This module communicates with various services provided by the CIS and by external systems to instantiate CDS capabilities (Figure 1).

Figure 1.
CIS-centric SOA for implementing CDS. DSS = Decision Support Service.

Figure 2 provides a simple example of a CIS-centric architecture, based on a chronic disease management system implemented at an academic medical center.17 In this example, when an EHR user requests a disease management dashboard for a specific patient (process 1 in the figure), the request is managed by the point-of-care disease management module of the EHR system (component A in the figure). This controller module then queries an external DSS to ascertain the clinical data required for running the DSS’s disease management rules (component C, process 2). The controller then retrieves the required data from the CIS through its clinical data query service (component B, process 3), and it submits these data to the DSS to obtain structured, patient-specific assessments and recommendations for managing the patient’s diseases (process 4). The controller module then submits the DSS’s XML output to a data presentation service to render the user interface in HTML (component D, process 5).

Figure 2.
Sample instantiation of a CIS-centric SOA for CDS.

In the example just described, the required CIS services and capabilities are as follows:

  • - Clinical data query service
  • - Ability to use a Decision Support Service (DSS)
  • - Ability to use a data presentation service

Some existing commercial EHR systems enable this type of CDS architecture by allowing customers to develop their own controller modules (e.g., component A in Figure 2) that are invoked at appropriate points in the clinical workflow and whose outputs are rendered within the native CIS user interface. For example, both Cerner® and McKesson provide mechanisms for customers to develop dynamic Web pages that are invoked through their CPOE systems. These custom CDS modules can consume Web services and are rendered within the native user interface.

Architecture 2: CIS-consuming SOA

This architecture includes CDS controller modules that are independent of the CIS and view the CIS primarily as a provider of relevant services (Figure 3). In this architecture, CIS services are exposed to be consumed by controller modules that are external to the CIS.

Figure 3.
CIS-consuming SOA for CDS. DSS = Decision Support Service.

Figure 4 depicts a population health management system in a health information exchange (HIE) that uses a CIS-consuming SOA for CDS.18 In this example, a population health management system (component A) is initiated on a scheduled basis (process 1). The controller module then identifies cohorts for population management from an EHR system’s cohort identification service (component B, process 2); identifies the clinical data required to execute relevant rules for that cohort from a DSS (component E, process 3); and collects required data for each patient in the cohort from the EHR system’s clinical data query service (component C, process 4). The patient data are submitted to the DSS to obtain patient-specific care recommendations, which are then compiled into CDS interventions such as care manager work lists, clinic feedback reports, and patient reminder letters (process 5). These interventions are represented in a computer-readable format such as XML and then rendered into human-readable format by a data presentation service (component F, process 6). In addition, notifications regarding the patient’s care needs are provided to end-users via a communication service (component D, processes 7 and 8).

Figure 4.
Example of a CIS-consuming SOA for CDS.

In the example just described, the services and capabilities provided by the CIS are the following:

  • - Cohort identification service
  • - Clinical data query service


For the purposes of this analysis, a CIS was defined as an information system designed to support the delivery of patient care, such as an EHR system or CPOE system. CIS services were defined as independent, reusable units of business functionality hosted by a CIS. Finally, CIS capabilities were defined as any other non-service functionality of a CIS, especially the ability to consume services.

Objectives and Scope

This study had three objectives. The first and primary objective was to identify the services and other capabilities that are desired from CISs to enable a SOA for CDS. Within the context of the overall architectural framework outlined in Figures 1 and and3,3, the services and capabilities of interest were those required from the CIS and CDS controller module in Figure 1, and from the CIS (but not the CDS controller module) in Figure 3. Moreover, it was assumed that if a CIS provides a particular service, it is also capable of consuming that service. The second objective was to prioritize the identified services and capabilities. Such prioritization was deemed to be important so that guidance could be provided regarding where to focus in a resource-constrained environment. The third objective was to identify the standards available for each of the identified services and capabilities.

The following were out of scope for this study but are being considered for future efforts by the Work Group: 1) the selection of preferred standards where multiple standards exist, 2) the development of new standards where needed, and 3) a formal assessment of CIS vendors’ current ability to meet the specified requirements and their level of interest in supporting the services and capabilities that they currently do not support.

Below, details are provided on the methodology used to achieve the three study objectives.

Identification of Desired Services and Capabilities

Multiple complementary methods were utilized to identify CIS services and capabilities to enable a SOA for CDS. This process was intended to be comprehensive in nature, with prioritization occurring in a subsequent phase. As an initial step, face-to-face and virtual meetings were held by the HL7 CDS Work Group to discuss required services and capabilities. These meetings were well-attended, with generally a dozen or more participants. As a complimentary method, prior relevant work was sought through a review of the medical and grey literature using MEDLINE and Google. The search strategies employed are shown in Box 1. Journal articles as well as presentations and standards specifications were included in this analysis.

Box 1:

Prior Work Search Strategy

  • MEDLINE search strategy (all 311 identified references reviewed)
    • ○ Decision support systems, clinical [MeSH] and Service [keyword]
  • Google search strategy (top 200 identified resources reviewed out of 18,800 results)
    • ○ “Clinical decision support” and (“service” or “SOA” or “Web service”)

Based on the information collected using these methods, an initial set of services and capabilities was developed by the project team and summarized in an editable Wiki page. Then, through the electronic mailing lists of the HL7 CDS and SOA Work Groups, colleagues with relevant expertise were invited to review the list of identified services and capabilities and to improve it by collectively editing the Wiki page. In determining the boundaries of services and capabilities (e.g., whether an order placement service should be enumerated as a separate service or merged with the concept of a data addition service), the project team made decisions through group consensus, with a goal of defining services and capabilities at a level of granularity that would be meaningful to business stakeholders.

Prioritization of Services and Capabilities

In the short and medium term, it is unlikely that any CIS vendor would be able to implement all of the services and capabilities identified. Thus, relevant stakeholders would benefit from a community assessment of the relative importance and priority of these services and capabilities. After a list of services and capabilities was created, an anonymous online poll was conducted. The study was approved by the University of Utah IRB, and study data were collected and managed using the REDCap electronic data capture tool. Invitations to participate were distributed through the electronic mailing lists of the HL7 CDS and SOA Work Groups, the American Medical Informatics Association CDS Working Group, and the Healthcare Information and Management Systems Society (HIMSS) CDS task force. Participation was open to all interested domain experts, defined as those individuals 18 years or older who had implemented, or were actively implementing, a CDS capability as defined by Osheroff et al.1 in an operational or research environment. Individuals who had created or were actively creating requirements specifications for a SOA approach to CDS were also eligible. Each participant was asked to briefly describe their experience implementing CDS or developing relevant specifications. We also asked each participant to categorize themselves as working for a knowledge vendor, EHR vendor, other vendor, healthcare organization, informatics research organization, and/or other organization.

For each service and capability, we asked respondents to rate the absolute importance of the service or capability on a symmetric 5-point Likert scale of 1 (very unimportant), 2 (unimportant), 3 (neither important or unimportant), 4 (important), and 5 (very important). Respondents were also allowed to note that they were unsure of the importance instead of rating an item. When that occurred, the respondent’s response was excluded from the analysis of the absolute importance of that item. Moreover, we asked each respondent to assign a pool of 100 points to the services and capabilities to reflect their judgment on the relative importance of the items. Likert scores were summarized descriptively, and the relative importance of each item was described in terms of the % of the total pool of points awarded. If a voter’s points did not add up to 100, the points were normalized for that voter so as to add up to 100.

Survey of Standards Landscape

For each service and capability, relevant available and emerging standards were identified by the project team members, many of whom are active not only in HL7 but in other standards development organizations such as the International Organization for Standardization (ISO), the European Committee for Standardization (CEN), and Integrating the Healthcare Enterprise (IHE). Moreover, as a part of the process utilized for identifying relevant CIS services and capabilities, a general call was made to the electronic mailing lists of the HL7 CDS and SOA Work Groups to solicit expert consultation on relevant available standards.


Identification of Relevant CIS Services and Capabilities

A total of ten CIS services and eight CIS capabilities were identified as enabling a SOA for CDS. These services and capabilities are described in detail in Tables 1 and and22.

Table 1.
Services hosted by a CIS that enable a SOA for CDS.
Table 2.
Capabilities provided by a CIS that enable a SOA for CDS.

Identification of Relevant Available and Emerging Standards

The relevant standards identified are listed in Tables 1 and and2.2. Many of these standards have been developed by the Healthcare Services Specification Project (HSSP), which is an effort by HL7 and the Object Management Group to specify standard service interfaces for healthcare.19

Absolute and Relative Importance of Services and Capabilities

A total of 46 individuals completed the initial section of the online survey, which pertained to the absolute importance of CIS services and capabilities. Among these individuals, 43 also completed the second section of the survey, in which the respondents rated the relative importance of the services and capabilities through the allocation of a pool of points. The survey respondents were affiliated with healthcare provider organizations (50%), informatics research organizations (28%), knowledge vendors (17%), EHR system vendors (17%), government agencies (13%), and other vendors (11%).

Table 3 summarizes the ratings of absolute and relative importance of each service and capability. As noted in the table, at least 48% of the respondents believed that every item was important or very important. Moreover, at least half of the respondents believed that the following items were very important: (i) a clinical data query service (74%); (ii) use of appropriate, standard information models and terminologies (74%); (iii) an event subscription and notification service (61%); (iv) a user communication service (60%); and (v) the ability to leverage a DSS (58%). When asked to rate the relative importance of the services and capabilities using a fixed pool of points, the respondents chose the same list of services and capabilities as their top five priorities: (i) use of appropriate, standard information models and terminologies (14.5% of total available points); (ii) the ability to leverage a DSS (11.0%); (iii) a clinical data query service (8.9%); (iv) an event subscription and notification service (7.6%); and (v) a user communication service (7.2%). These highest-priority services and capabilities are highlighted in bold in Table 3. Order placement services were also identified as being of high priority, receiving 6.8% of available points.

Table 3.
Domain experts’ judgment on the absolute and relative importance of CIS services and capabilities for enabling a SOA for CDS.


Key Findings

Through multi-stakeholder discussions, a literature review, and the consultation and surveying of domain experts, the HL7 CDS Work Group has identified and prioritized ten CIS services and eight CIS capabilities that can facilitate the implementation of scalable, standards-based, service-oriented architectures for CDS. All of the services and capabilities were identified as being important or very important by at least 48% of the domain experts completing the online survey. Six services and capabilities were identified as especially critical: the use of standard information models and terminologies; the ability to leverage a DSS; support for a clinical data query service; support for an event subscription and notification service; support for a user communication service; and support for an order placement service. These capabilities are consistent with the key components of the Partners CDS taxonomy15 – namely: triggers (event subscription and notification service), input data (clinical data query service), interventions (user communication service) and offered choices (order placement service). There are various relevant standards available, in particular through the work of the Healthcare Services Specification Project.19 However, there are also many services and capabilities for which no clear standards exist.

Study Strengths

This study has three important strengths. First, we leveraged a broad base of experts who are part of the HL7 and wider biomedical informatics communities, including domain experts on CDS, SOA, and health IT standards. Second, we augmented the identification of services and capabilities through a search of the literature. Third, through a survey of a relatively large number of CDS domain experts, we were able to quantify the perceived absolute and relative importance of the CIS services and capabilities. Thus, this study provides a practical foundation for pursuing future efforts in this area, for example with regard to standards development and the specification of functional requirements for system requisitions.

Study Limitations

This study has two main limitations. First, we did not conduct subset analyses of the survey data based on the respondents’ professional affiliations (e.g., EHR vendor vs. knowledge vendor vs. healthcare provider organization). However, we felt we lacked a sufficient sample size for conducting such subset analyses. Second, despite substantial vendor representation, the survey was dominated by individuals associated with healthcare provider organizations and informatics research organizations. However, we feel that the professional distribution in our survey is reflective of the types of individuals who are actively engaged in trying to achieve scalable, robust CDS through the application of SOA principles across clinical information systems.

Implications and Future Directions

By providing an evidence-based, expert-curated assessment of the CIS services and capabilities desired for enabling a SOA for CDS, the HL7 CDS Work Group hopes to have made an important contribution to the promise of scalable CDS. We plan to follow up on this work with an engagement of various stakeholder groups, including in particular the CIS vendors, to develop a roadmap for enabling a standards-based SOA for CDS that is anchored by the CIS services and capabilities identified and prioritized in this study.


There is a finite set of CIS services and capabilities needed for enabling a SOA for CDS, with a subset of these services and capabilities being particularly critical. Coupled with appropriate standards, support for these services and capabilities by CIS vendors could enable dramatic enhancements in the scalability and robustness of CDS. Moreover, vendor support for these services and capabilities could enable the distributed development of other next-generation functionality aimed at supporting the work of front-line clinicians and improving the efficiency and effectiveness of health care.


This study was supported in part by the University of Utah Department of Biomedical Informatics (KK) and by National Library of Medicine Training Grant T15LM007124 (JJ). Use of the REDCap survey tool was supported by Clinical and Translational Sciences grant 5UL1RR025764-02. GDF was supported by grant number K01HS018352 from the Agency for Healthcare Research and Quality (AHRQ).


1. Osheroff JA, Teich JM, Middleton B, et al. A roadmap for national action on clinical decision support. J Am Med Inform Assoc. 2007;14(2):141–5. [PMC free article] [PubMed]
2. Kawamoto K, Houlihan CA, Balas EA, Lobach DF. Improving clinical practice using clinical decision support systems: a systematic review of trials to identify features critical to success. BMJ. 2005;330(7494):765–8. [PMC free article] [PubMed]
3. Kawamoto K. Integration of knowledge resources into applications to enable clinical decision support: architectural considerations. In: Greenes RA, editor. Clinical Decision Support: the Road Ahead. Boston: Elsevier Academic Press; 2007. pp. 503–38.
4. Kawamoto K, Del Fiol G, Orton C, Lobach DF. System-agnostic clinical decision support services: benefits and challenges for scalable decision support. Open Med Inform J. 2010;4:245–54. [PMC free article] [PubMed]
5. Pryor TA, Hripcsak G. The Arden syntax for medical logic modules. Int J Clin Monit Comput. 1993;10(4):215–24. [PubMed]
6. Sordo M, Boxwala AA, Ogunyemi O, Greenes RA. Description and status update on GELLO: a proposed standardized object-oriented expression language for clinical decision support. Stud Health Technol Inform. 2004;107(Pt 1):164–8. [PubMed]
7. Boxwala AA, Peleg M, Tu S, et al. GLIF3: a representation format for sharable computer-interpretable clinical practice guidelines. J Biomed Inform. 2004;37(3):147–61. [PubMed]
8. Erl T. SOA: principles of service design. Crawfordsville, IN: Prentice Hall; 2008.
9. Krafzig D, Banke K, Slama D. Enterprise SOA: service-oriented architecture best practices. Indianapolis, IN: Prentice Hall PTR; 2004.
10. Johnson PD, Tu SW, Musen MA, Purves I. A virtual medical record for guideline-based decision support. AMIA Annu Symp Proc. 2001:294–8. [PMC free article] [PubMed]
11. Kawamoto K, Lobach DF. Design, implementation, use, and preliminary evaluation of SEBASTIAN, a standards-based Web service for clinical decision support. AMIA Annu Symp Proc. 2005:380–4. [PMC free article] [PubMed]
12. Distributed Decision Support Services and Knowledge Management Repository (KMR-II) Available from:
13. Middleton B. The Clinical Decision Support Consortium. Stud Health Technol Inform. 2009;150:26–30. [PubMed]
14. Kawamoto K, Lobach DF. Proposal for fulfilling strategic objectives of the U.S. roadmap for national action on decision support through a service-oriented architecture leveraging HL7 services. J Am Med Inform Assoc. 2007;14:146–55. [PMC free article] [PubMed]
15. Wright A, Sittig DF, Ash JS, et al. Clinical decision support capabilities of commercially-available clinical information systems. J Am Med Inform Assoc. 2009 Sep-Oct;16(5):637–44. [PMC free article] [PubMed]
16. Wright A, Goldberg H, Hongsermeier T, Middleton B. A description and functional taxonomy of rule-based decision support content at a large integrated delivery network. J Am Med Inform Assoc. 2007 Jul-Aug;14(4):489–96. [PMC free article] [PubMed]
17. Lobach DF, Kawamoto K, Anstrom KJ, et al. Development, deployment and usability of a point-of-care decision support system for chronic disease management using the recently-approved HL7 Decision Support Service standard. Medinfo. 2007:861–5. [PubMed]
18. Lobach DF, Kawamoto K, Anstrom KJ, et al. Proactive population health management in the context of a regional health information exchange using standards-based decision support. AMIA Annu Symp Proc. 2007:473–7. [PMC free article] [PubMed]
19. Kawamoto K, Honey A, Rubin K. The HL7-OMG Healthcare Services Specification Project: motivation, methodology, and deliverables for enabling a semantically interoperable service-oriented architecture for healthcare. J Am Med Inform Assoc. 2009 Nov-Dec;16(6):874–81. [PMC free article] [PubMed]
20. Cho I, Kim J, Kim JH, Kim HY, Kim Y. Design and implementation of a standards-based interoperable clinical decision support architecture in the context of the Korean EHR. Int J Med Inform. 2010 Sep;79(9):611–22. [PubMed]
21. Han D, Lee M, Park S. THE-MUSS: Mobile u-health service system. Comput Methods Programs Biomed. 2010 Feb;97(2):178–88. [PubMed]
22. Van Hoecke S, Decruyenaere J, Danneels C, et al. Service-oriented subscription management of medical decision data in the intensive care unit. Methods Inf Med. 2008;47(4):364–80. [PubMed]
23. Van Den Bossche B, Van Hoecke S, Danneels C, et al. Design of a JAIN SLEE/ESB-based platform for routing medical data in the ICU. Comput Methods Programs Biomed. 2008 Sep;91(3):265–77. [PubMed]
24. Clayton PD, Narus SP, Huff SM, et al. Building a comprehensive clinical information system from components. The approach at Intermountain Health Care. Methods Inf Med. 2003;42(1):1–7. [PubMed]
25. Hripcsak G, Clayton PD, Jenders RA, Cimino JJ, Johnson SB. Design of a clinical event monitor. Comput Biomed Res. 1996 Jun;29(3):194–221. [PubMed]
27. Weber-Janke J. Design of decoupled clinical decision support for service oriented architectures. International Journal of Software Engineering and Knowledge Engineering. 2007;14:52.
28. Catalog of OMB CORBAservices Specifications Available from:
29. OASIS Web Services Notification Technical Committee Available from:
30. The practical guide for SOA in health care: a real-world approach to planning, designing, and deploying SOA. Version 1.0. Available from:
31. Borbolla D, Otero C, Lobach DF, et al. Implementation of a clinical decision support system using a service model: results of a feasibility study. Stud Health Technol Inform. 2010;160(Pt 2):816–20. [PubMed]
32. Hristoskova A, Moeyersoon D, Van Hoecke S, et al. Dynamic composition of medical support services in the ICU: Platform and algorithm design details. Comput Methods Programs Biomed. 2010 Dec;100(3):248–64. [PubMed]
33. Ongenae F, De Backere F, Steurbaut K, et al. Towards computerizing intensive care sedation guidelines: design of a rule-based architecture for automated execution of clinical guidelines. BMC Med Inform Decis Mak. 2010;10:3. [PMC free article] [PubMed]
34. Wright A, Sittig DF. SANDS: a service-oriented architecture for clinical decision support in a National Health Information Network. J Biomed Inform. 2008 Dec;41(6):962–81. [PMC free article] [PubMed]
35. Liaw ST, Deveny E, Morrison I, Lewis B. Clinical, information and business process modeling to promote development of safe and flexible software. Health Informatics J. 2006 Sep;12(3):199–211. [PubMed]
36. Huang Y, Noirot LA, Heard KM, et al. Migrating toward a next-generation clinical decision support application: the BJC HealthCare experience. AMIA Annu Symp Proc. 2007:344–8. [PMC free article] [PubMed]
37. Socratic Grid project: clinical decision support subproject technical overview. Available from:,%20EMORY%20FRY.pdf/view.
38. Johnson P, Tu S, Jones N. Achieving reuse of computable guideline systems. Medinfo. 2001;10(Pt 1):99–103. [PubMed]
39. Worflow Management Coalition: Terminology and glossary technical document (TC-1011) Available from:
40. Zhu VJ, Grannis SJ, Rosenman MB, Downs SM. Implementing broad scale childhood immunization decision support as a web service. AMIA Annu Symp Proc. 2009;2009:745–9. [PMC free article] [PubMed]
41. Goldberg HS, Vashevko M, Pastilnik A, et al. Evaluation of a commercial rule engine as a basis for a clinical decision support service. AMIA Annu Symp Proc. 2006:294–8. [PMC free article] [PubMed]
42. Fehre K, Adlassnig K-P. Service-oriented Arden-Syntax-based clinical decision support. In: Schreier G, Hayn D, Ammenwerth E, editors. Proceeding of the eHealth2011 - Health Informatics meets eHealth - Continuity of Care; 2011 May 26–27, 2011; Vienna, Austria. 2011. pp. 123–8.

Articles from AMIA Annual Symposium Proceedings are provided here courtesy of American Medical Informatics Association