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