|Home | About | Journals | Submit | Contact Us | Français|
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,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.
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.
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 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).
In the example just described, the required CIS services and capabilities are as follows:
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.
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 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).
In the example just described, the services and capabilities provided by the CIS are the following:
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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).