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

Abstract

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.

Introduction

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.¹ 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.²

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.⁴ 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 standard⁵ and the HL7 GELLO standard⁶ 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).⁷ 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.⁴ SOAs for CDS have been proposed and shown to have significant promise by many investigators, including through the SAGE project,¹⁰ SEBASTIAN,^4,11 the DDS-KMR project,¹² and the CDS Consortium.¹³ 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.¹⁴

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,12–14 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.

Methods

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.¹⁷ 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.¹⁸ 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

Definitions

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 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.¹ 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.

Results

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 2.

Table 1.

Services hosted by a CIS that enable a SOA for CDS.

Service	Description, Example Use Case, and Relevant Standards
Event Subscription and Notification Service Source: HL7 CDS Work Group, literature14,20–27	Description: Publishes relevant CIS events, which can be listened to by a CDS system to trigger CDS. Allows systems to subscribe to specific types of event notifications. Use case: EHR system publishes events such as the entry of new labs into the clinical data repository, patients checking into appointments, and users logging into the system. CDS system subscribes to types of events that will trigger specific CDS processes. Relevant standards: CORBA event service and notification service28; WS-Notification29
Cohort Identification Service Source: HL7 CDS Work Group, literature11	Description: Identifies a patient cohort (i.e., population) matching search criteria. The result returned is typically a list of identifiers for matching patients. Use case: A population health management system identifies patients with diabetes, hypertension, and congestive heart failure using an EHR system’s cohort identification service. Relevant standards: None identified.
Entity Identification Service / Identity Cross-Reference Service Source: HL7 CDS Work Group, literature30	Description: Identifies whether there is an individual patient matching demographic search criteria (e.g., name, gender, date of birth). Also may be applied to identify other entities such as healthcare providers or facilities. Use case: A vaccine forecasting system identifies whether care organizations A, B, or C have data on a patient for whom a vaccine forecast has been requested. Relevant standards: HSSP19 Identity Cross-Reference Service standard.
Clinical Data Query Service Source: HL7 CDS Work Group, literature11,14,17,20–27,31–38	Description: Retrieves existing clinical data from clinical information system. Use case: Drug-drug interaction alert system retrieves patient medications from an EHR system. Relevant standards: HSSP19 Retrieve, Locate, Update Service standard. IHE Query for Existing Data profile.
Resource Query Service Source: HL7 CDS Work Group	Description: Retrieves data about local availability of material and human resources. Use case: Based on local availability of dialysis machine, refer patient to external dialysis facility. Relevant standards: HSSP19 Healthcare and Community Services Provider Directory Service standard; Wf-XML specification (http://www.wfmc.org/wfmc-wf-xml.html).
Data Acquisition Service Source: HL7 CDS Work Group, literature21,38	Description: Retrieves data directly from users. Use case: CDS system asks user if patient is pregnant. Relevant standards: HSSP19 Retrieve, Locate, Update Service standard.
Data Addition/Update Service Source: HL7 CDS Work Group, literature14,25,38	Description: Updates or adds data into a clinical information system. Use case: Health maintenance module updates EHR that patient had an influenza vaccine at grocery store on date X. Relevant standards: HSSP19 Retrieve, Locate, Update Service standard.
Order Placement Service Source: HL7 CDS Work Group, literature14,26,38	Description: Places a clinical order. Use case: CPOE CDS module places a pending order for lisinopril 5mg PO QD. Relevant standards: None identified.
User Communication Service Source: HL7 CDS Work Group, literature11,14,21-26,32,38	Description: Communicates CDS results with appropriate end users. Use case: A CDS system places a note in the EHR system’s alert inbox; CDS system provides a popup alert; physician is paged regarding urgent CDS finding. Relevant standards: None identified.
Task Management Service Source: HL7 CDS Work Group, literature39	Description: Allows tasks to be added, tracked, and retrieved. Use case: A population health management system is able to distribute the tasks from a care plan to the task lists of various users. Relevant standards: Wf-XML specification (http://www.wfmc.org/wfmc-wf-xml.html).

Table 2.

Capabilities provided by a CIS that enable a SOA for CDS.

Capability	Description, Example Use Case, and Relevant Standards
Use of Appropriate, Standard Information Models and Terminologies Source: HL7 CDS Work Group, literature11,14,17,20,27,34	Description: Appropriate, standard information models and terminologies are used to instantiate data in the payloads of various services. Use case: A Clinical Data Query Service uses a standard information model to represent the data it provides. Relevant standards: HL7 version 2 and 3 messaging standards; HL7 Virtual Medical Record standard; IHE profiles; HITSP standards; OpenEHR templates; Detailed Clinical Models; SNOMED CT; LOINC; ICD; CPT; various others.
Ability to Leverage a DSS Source: HL7 CDS Work Group, literature11,13,14,17,18,24,26,31,34–38,40–42	Description: The CIS is able to use a DSS to obtain patient-specific care assessments and recommendations. Use case: The disease management module of an EHR system uses a DSS to obtain diabetes care recommendations based on national guidelines. Relevant standards: HSSP19 Decision Support Service standard; IHE Request for Clinical Guidance profile.
Ability to Leverage a Terminology Service Source: HL7 CDS Work Group, literature11,24,37	Description: The CIS is able to use a service to fulfill terminology needs. Use case: A CIS uses a terminology service to convert internal laboratory codes into the LOINC codes required by a DSS. Relevant standards: HSSP19 Common Terminology Services 2 standard.
Ability to Leverage a Unit Conversion Service Source: HL7 CDS Work Group, literature38	Description: The CIS is able to use a service to convert units. Use case: A CIS uses a unit conversion service to convert laboratory units used by the local CIS into the different laboratory units required by a DSS. Relevant standards: The Unified Code for Units of Measure (http://aurora.regenstrief.org/~ucum/ucum.html).
Ability to Leverage a Data Transformation Service Source: HL7 CDS Work Group, literature11,24	Description: The CIS is able to use a service that maps data represented using one information model into data represented using a different information model. Use case: A CIS uses a data transformation service to convert data represented using one information model (e.g., CCD) into data represented using a different information model required by a DSS (e.g., vMR). Relevant standards: Various information model and terminology standards (see “Use of Appropriate, Standard Information Models and Terminologies” above).
Ability to Leverage a Data Presentation Service Source: HL7 CDS Work Group, literature4	Description: The CIS is able to use a service to render structured data into a human-readable format. Use case: The disease management module of an EHR system uses a data presentation service to convert an XML document representing diabetes care needs into an HTML diabetes management dashboard to be presented to a clinician. Relevant standards: W3C XSL Formatting Objects (http://www.w3.org/wiki/Xsl-fo).
Ability to Populate a Data Warehouse in Real-Time Source: HL7 CDS Work Group	Description: The CIS is able to populate an enterprise data warehouse in real-time, as opposed to nightly batches. Use case: A healthcare organization builds CDS functionality against the data warehouse. Relevant standards: None identified.
Maintenance of Audit Logs Source: HL7 CDS Work Group	Description: The CIS maintains an audit log of all service interactions. Use case: A CIS maintains an audit log of data provided to, and recommendations received from, an external CDS service. Relevant standards: Healthcare Information Technology Standards Panel (HITSP) SC109.

Identification of Relevant Available and Emerging Standards

The relevant standards identified are listed in Tables 1 and 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.¹⁹

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.

	Absolute Importance*			Relative Importance
Service or Capability	Mean	% 4 or 5	% 5	% Points Allocated
Event subscription and notification service	4.5	91%	61%	7.6%
Cohort identification service	4.0	77%	32%	4.4%
Entity identification service	3.9	73%	33%	4.5%
Clinical data query service	4.7	98%	74%	8.9%
Resource query service	3.5	54%	22%	3.3%
Data acquisition service	3.8	67%	22%	4.2%
Data addition/update service	4.2	82%	38%	4.6%
Order placement service	4.0	72%	41%	6.8%
User communication service	4.4	89%	60%	7.2%
Task management service	3.8	65%	26%	5.0%
Use of appropriate, standard information models and terminologies	4.6	93%	74%	14.5%
Ability to leverage a DSS	4.4	88%	58%	11.0%
Ability to leverage a terminology service	4.2	83%	46%	4.9%
Ability to leverage a unit conversion service	3.6	58%	22%	1.8%
Ability to leverage a data transformation service	3.8	68%	20%	2.0%
Ability to leverage a data presentation service	3.6	64%	20%	2.8%
Ability to populate a data warehouse in real-time	3.4	48%	11%	1.8%
Maintenance of audit logs	4.1	78%	46%	4.7%

^*5 = very important; 4 = important. Bold = top five, both for % of respondents identifying as very important and % of points allocated.

Discussion

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 taxonomy¹⁵ – 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.¹⁹ 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.

Conclusion

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.