Proposal for Fulfilling Strategic Objectives of the U.S. Roadmap for National Action on Decision Support through a Service-oriented Architecture Leveraging HL7 Services

Abstract

Despite their demonstrated effectiveness, clinical decision support (CDS) systems are not widely used within the U.S. The Roadmap for National Action on Clinical Decision Support, published in June 2006 by the American Medical Informatics Association, identifies six strategic objectives for achieving widespread adoption of effective CDS capabilities. In this manuscript, we propose a Service-Oriented Architecture (SOA) for CDS that facilitates achievement of these six objectives. Within the proposed framework, CDS capabilities are implemented through the orchestration of independent software services whose interfaces are being standardized by Health Level 7 and the Object Management Group through their joint Healthcare Services Specification Project (HSSP). Core services within this framework include the HSSP Decision Support Service, the HSSP Common Terminology Service, and the HSSP Retrieve, Locate, and Update Service. Our experiences, and those of others, indicate that the proposed SOA approach to CDS could enable the widespread adoption of effective CDS within the U.S. health care system.

Introduction

In October 2005, the American Medical Informatics Association (AMIA) convened a workshop to develop a national roadmap for improving care quality and health outcomes through the widespread adoption of effective clinical decision support (CDS) capabilities within the United States. This workshop was commissioned by the Office of the National Coordinator for Health Information Technology of the U.S. Department of Health and Human Services. Following additional feedback from groups including the American College of Medical Informatics, AMIA released A Roadmap for National Action on Clinical Decision Support in June 2006. ¹ The key findings of the report were presented to the Secretary of the Department of Health and Human Services and to the American Health Information Community in June 2006.

The fundamental problem addressed by the roadmap report is the limited extent to which CDS is being leveraged within the U.S. to improve care and health outcomes. The report identifies six strategic objectives as the mechanism for achieving the widespread use of effective CDS within the U.S. health care system. To facilitate achievement of these six strategic objectives, we propose in this manuscript a CDS implementation framework based on the principles of a Service-Oriented Architecture (SOA). Central to this proposed CDS framework is the use of standard services being specified by Health Level 7 (HL7) and the Object Management Group (OMG) in their joint Healthcare Services Specification Project (HSSP).

CDS Background

CDS Definition

CDS has been defined in various ways in the literature. ^2–6 For the purposes of this manuscript, CDS will be defined as the act of providing clinicians, staff, patients, or other individuals with knowledge and/or person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care. This definition is used in the AMIA CDS roadmap report. ¹

Need for CDS to Translate Knowledge into Practice

The need for CDS arises from a significant gap that exists between what is known to medical science and the care that many patients actually receive. This suboptimal application of medical knowledge results in lowered care quality and increased adverse outcomes. Within the U.S., a recent nationwide audit assessing 439 quality indicators found that American adults receive only about half of recommended care, ⁷ and the U.S. Institute of Medicine has estimated that up to 98,000 Americans die each year as the result of preventable medical errors. ⁸ Similar problems with suboptimal patient care have been reported in other industrialized nations as well. ^9,10

By providing the right information to the right people at the right point in the clinical workflow, CDS interventions can be highly effective at addressing this crisis in care quality. In a recent systematic review, for example, clinician-targeted CDS interventions possessing four critical features were found to significantly improve clinical practice in 94% of randomized controlled trials. ² These four features consisted of providing the CDS automatically as a part of the routine clinical workflow; delivering the CDS as an actionable, patient-specific recommendation; providing the CDS at the time and location of clinical decision making; and using a computer to generate the CDS. ²

Limited CDS Adoption

Despite the demonstrated potential for CDS to improve health and health care, the vast majority of health care decisions in the U.S. are made without the aid of CDS, ¹ and advanced CDS capabilities have been effectively implemented in only a small number of model organizations. ¹¹ Thus, with the notable exception of drug–drug and drug–allergy interaction screening using commercial medication knowledge resources, ^1,12 the potential for improving care through CDS remains largely a dream rather than a reality.

Roadmap for National Action on CDS: Strategic Objectives

The goal of the AMIA Roadmap for National Action on CDS is to realize the vision of a U.S. health care system in which “optimal, usable and effective clinical decision support is widely available to providers, patients, and individuals where and when they need it to make health care decisions.” The roadmap report identifies three core pillars for realizing the promise of CDS: the comprehensive availability of the best available clinical knowledge in formats that can be easily leveraged for CDS; the widespread use of these knowledge resources to provide CDS; and continuous improvement of both clinical knowledge and CDS methods based on lessons learned. These three pillars are associated with a total of six strategic objectives (▶): (1) standardized knowledge representation; (2) effective knowledge distribution; (3) removal of barriers and creation of enablers; (4) improved CDS adoption; (5) systematic learning from previous CDS experience; and (6) the advancement of care-guiding knowledge.

Table 1.

Table 1 Strategic Objectives of Roadmap for National Action on CDS

CDS Pillar	Corresponding Strategic Objective
Best Knowledge Available when Needed	1. Represent clinical knowledge and CDS interventions in standardized formats (both human and machine-interpretable), so that a variety of knowledge developers can produce this information in a way that knowledge users can readily understand, access, and apply it.
	2. Collect, organize, and distribute clinical knowledge and CDS interventions in one or more services from which users can readily find the specific material they need and incorporate it into their own information systems and processes.
High Adoption and Effective Use	3. Address policy/legal/financial barriers and create additional support and enablers for widespread CDS adoption and deployment.
	4. Improve clinical adoption and usage of CDS interventions by helping clinical knowledge and information system producers and implementers design CDS systems that are easy to deploy and use, and by identifying and disseminating best practices for CDS deployment.
Continuous Improvement of Knowledge and CDS Methods	5. Assess and refine the national experience with CDS by systematically capturing, organizing, and examining existing deployments. Share lessons learned and use them to continually enhance implementation best practices.
	6. Advance care-guiding knowledge by fully leveraging the data available in interoperable EHRs to enhance clinical knowledge and improve health management.

The roadmap report soberly notes that the current state of CDS in the U.S. is far from the desired CDS destination. Indeed, as noted in the report, CDS use in this country is very limited; CDS content is generally represented in non-standardized formats; existing CDS content is oftentimes difficult to re-use across organizations or even within different applications within the same organization; many health care organizations cannot make a business case for implementing CDS capabilities; existing approaches to CDS implementation are inadequate; we are still in the early stages of learning from past CDS experiences; and data in electronic health records (EHRs) are not being leveraged to advance clinical knowledge. ¹ In this manuscript, we propose a CDS implementation framework that could potentially overcome these challenges, facilitate fulfillment of the roadmap’s strategic objectives, and catalyze the nationwide use of effective CDS. This proposed CDS framework is based on the principles of a SOA.

Service-oriented Architecture (SOA): Key Properties and Benefits

In a Service-Oriented Architecture (SOA), core business capabilities are encapsulated within independent software services, and these services are leveraged by various front-end applications to fulfill business requirements. ^13–15 In recent years, enterprises in various industries have begun to re-organize their IT capabilities within a SOA. For example, a 2005 survey of 306 U.S. enterprises found that 84% of enterprises were in the midst of a SOA project or would be undertaking one within the next year. ¹⁶

While there is still some disagreement on the precise definition of a SOA, there is general consensus on key SOA properties. ^13–15 These properties include the use of business-oriented services; message-based interactions with “black-box” implementations; communication over a network; platform neutrality; service description and discovery; and loose coupling between system components (▶). At present, SOA services are typically implemented as Web services, in which services communicate with their clients using XML messages transmitted over the Internet. ¹⁷ Web service messages are often encoded using an XML-based protocol known as the Simple Object Access Protocol (SOAP), and Web service interfaces are typically described using the Web Service Definition Language (WSDL).

Table 2.

Table 2 Key SOA Properties

SOA Property	Details
Business-oriented services	Core IT capabilities are encapsulated within services whose scope and functionality are meaningful from a business perspective Services are typically relatively broad in scope, providing relatively few operations in conjunction with relatively large, complex service inputs and/or outputs
Message-based interactions with “black-box” implementations	Each service is defined in terms of the messages it exchanges with its clients Service implementation details, such as the programming language used and the structure of any underlying databases, are deliberately abstracted away
Communication over a network	Although not required, SOA messages are typically exchanged across a network, such as an intranet or the Internet
Platform neutrality	Messages are communicated using platform-neutral, standardized formats such as extensible markup language (XML) messages
Service description and discovery	Service interfaces are described using a platform-neutral description language Services are associated with a mechanism for discovering their existence
Loose coupling	Services are designed to be as independent as possible from other services as well as from front-end applications that invoke the service

A SOA requires the use of services. However, the use of services does not necessarily result in a SOA, because not all services fulfill key properties of a SOA. For example, if services are dependent on other services or system components, the services would be more difficult to re-use in new application contexts and would violate the SOA principle of loose coupling.

The use of a SOA is associated with many significant benefits. ^12,14 First, SOA allows for a simpler approach to software design and implementation. In a SOA, complex problems can be decomposed into smaller, more manageable problems that are addressed by individual services. Furthermore, the “black-box” nature of services allows service users to be shielded from potentially complex implementation details that exist underneath a service interface. A second important benefit is enhanced re-use of existing IT resources. In a SOA, software capabilities that already exist within legacy systems can be re-used by exposing the functionality through platform-neutral service interfaces. Also, a given service can be reused by multiple applications and by other services in order to meet various business requirements. A third core benefit of a SOA is the ability to adapt to changing business requirements in a flexible, agile manner. In a SOA, systems that lie underneath of service interfaces can be changed as needed, and new business requirements can be rapidly fulfilled by leveraging existing services and by creating new services as needed. Finally, an important benefit of a SOA lies in the potential for significant cost savings. Potential sources of cost savings include the ability to re-use existing IT assets to meet new business requirements; the flexibility with which new business requirements can be accommodated; and the simplification and modularization of the IT landscape, which can reduce the time and cost involved in designing, implementing, and maintaining individual IT systems.

HL7-OMG Healthcare Services Specification Project (HSSP)

Health care organizations could reap some of the benefits of a SOA even if individual vendors and institutions defined services in an organization-specific manner. However, in order to facilitate semantic interoperability and service re-use, the functionality and interfaces of health care services should be standardized where feasible and appropriate.

The Healthcare Services Specification Project (HSSP) is a project that aims to standardize the functionality and interfaces of software services important to the health care industry. ¹⁸ Initiated in 2005, the HSSP is being pursued as a joint initiative between HL7 and OMG. HL7 is the premier standards development organization within health care, whereas OMG is an open-membership, not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications. Within this partnership, HL7 identifies and prioritizes candidate services. Then, for each service designated for standardization, HL7 specifies the functional requirements of the service, the information model for the service payloads, and functional conformance criteria. The end result of this HL7 process is a computationally-independent functional specification of a service, which is referred to as a Service Functional Model (SFM). Once a SFM is adopted as a HL7 standard, it is refined within OMG to develop computationally-dependent service specifications (e.g., a SOAP Web service specification) as well as at least one commercial implementation.

One of the HSSP services is a decision support service (DSS) that uses patient data to make machine-interpretable inferences regarding patients. ¹⁹ The DSS SFM was adopted as an HL7 draft standard in September 2006. Given the central role of the DSS in the CDS framework proposed in this manuscript, the DSS is described in greater detail next.

HSSP Decision Support Service (DSS)

The purpose of the HSSP DSS project is to define a common service interface for fulfilling a core functional requirement shared by all CDS systems—that is, the need to draw conclusions regarding patients. ¹⁹ The DSS interface is based on the interface used by a CDS Web service developed by the authors known as SEBASTIAN. ²⁰ One of the authors (K.K.) is the project lead for the DSS initiative.

From a functional perspective, a DSS can be conceptually understood as the guardian of one or more modules of medical knowledge, wherein each DSS knowledge module (KM) is capable of utilizing patient data to arrive at machine-interpretable conclusions regarding the patient under evaluation. The scope of a typical DSS KM is the assessment of a single patient in a specified topic area. The topic area may be narrow (e.g., the need for a glycated hemoglobin test for a patient with diabetes) or broad (e.g., the existence of contraindications to any medications prescribed or about to be prescribed for a patient).

Each KM is defined by an extensible set of meta-data referred to as KM traits, a set of data requirements, and a specification of how evaluation results will be returned. KM traits can be used to facilitate searches for relevant KMs. Also, profiles can be defined and standardized for different types of KMs. For example, a profile can be defined for medication safety KMs that specifies the meta-data, data requirements, and evaluation result semantics that must be supported by KMs claiming conformance to the profile. As long as a DSS is capable of generating the evaluation results promised by a KM using the specified data, the DSS can use any method for fulfilling the evaluation needs of a KM.

When requesting a patient evaluation, a DSS client specifies the KMs to use for the evaluation, and the client also submits the patient data required by the KMs. In return, the DSS returns inferences regarding the patient in a format that has been pre-defined for that KM. ▶ provides examples of the types of inferences that can be made using a DSS KM. As noted in the table, in addition to providing patient-specific assessments or recommendations, a DSS KM can be used to provide intelligently filtered CDS interventions such as context-relevant reference materials, order sets, and documentation templates.

Table 3.

Table 3 Example Inferences That Can Be Made Using a DSS Knowledge Module

Sample Evaluation Input	Sample Evaluation Output
Patient age, gender, past health maintenance procedures	List of health maintenance procedures due or almost due
Patient age, gender, co-morbidities, allergies, past immunizations	List of vaccines for which patient is ineligible due to contraindications, list of vaccines for which patient is up-to-date, and list of vaccines for which patient is due
Medication identifier, age, gender, weight, serum creatinine level	Recommended maximum and minimum doses for medication given patient’s estimated renal function
Insurance provider, data relevant to a prescription	Whether the prior authorization criteria for prescribing the medication are met
User type (e.g., M.D.), user language, task context (e.g., lab result review), inquiry focus (e.g., hyperkalemia)	Context-appropriate reference materials
Age, gender, co-morbidities, chief complaint	Recommended admission order set in HL7 format
Age, gender, co-morbidities, chief complaint, symptoms	Recommended documentation template in HL7 format

In order to acquire patient evaluations in this manner, a DSS client must be able to identify the KMs that could be used to meet client CDS needs; to know what patient data must be submitted to the DSS in order to obtain an accurate evaluation; and to know the meaning and format of any results that will be returned by the DSS following a patient evaluation. A DSS provides supplemental operations for meeting these additional information needs.

Proposed CDS Implementation Framework

Based on our experience implementing CDS systems within a SOA framework ²⁰ as well as our active involvement in the HSSP, we believe a SOA approach to CDS that leverages HSSP services can facilitate CDS implementation and maintenance, address the strategic objectives of the AMIA Roadmap for National Action on CDS, and serve as a framework for CDS implementation that can be scaled nationwide. The six core elements of this proposed CDS implementation framework are as follows.

Use of SOA as Basic Implementation Framework

As discussed earlier, the use of a SOA simplifies software design and implementation, allows existing resources to be more readily re-used, facilitates adaptation to changing business requirements, and potentially reduces the costs of implementation. In order to harness these benefits, we propose that SOA be used as the basic framework for implementing CDS. In this framework, individual CDS applications are implemented by leveraging independent, business-oriented services with well-defined interfaces. To the extent possible, existing services are re-used across applications and organizations.

Initial Use of SOAP Web Services

Given the dominant position of SOAP Web services among current SOA implementation technologies, we recommend that this technology platform be initially adopted as the preferred communication protocol. Of note, all HSSP service specifications are expected to provide explicit support for SOAP Web services.

Use of HSSP DSSs to Collect, Organize, and Distribute CDS Content in a Centralized Manner

The encoding of medical knowledge in a machine-executable format suitable for CDS represents one of the most difficult and expensive aspects of implementing CDS. In order to minimize duplication of effort and to distribute the costs of creating and maintaining CDS content across a large user base, we recommend that CDS content be collected, organized, and distributed by large-scale, centralized DSSs. These DSSs could be provided by vendors, leading academic medical centers, professional associations, or government agencies. Significant economies of scale could be achieved through the use of a DSS to centrally manage CDS content for a health care system, geographic region, vendor client base, or even the nation as a whole. Moreover, because each DSS would use a standard interface, CDS implementers would be able to leverage CDS content from different DSSs in a “plug-and-play” manner.

Use of Other HSSP Services where Appropriate

HSSP services other than the DSS should also be leveraged when a CDS implementation calls for functionality that is addressed by an existing HSSP service. Fortunately, the HSSP is already in relatively advanced stages of defining standard specifications for a Common Terminology Service (CTS/CTSII) ²¹ and for a Retrieve, Locate, and Update Service (RLUS) ²² that allows clients to locate, retrieve, and update patient data. As the need to perform terminology operations (e.g., translation, subsumption) and the need to retrieve structured patient data are common requirements for providing CDS, ¹² these services could play an important role in many CDS implementations. Moreover, while the DSS is not dependent on RLUS, the DSS has been specified so that the patient data required by a DSS can be readily translated into data queries fulfilled by a RLUS. ¹⁹

Participation in Development of Other HSSP Services Relevant to CDS

When implementing CDS using a SOA, the need will inevitably arise for services not yet standardized by the HSSP. For example, in the course of implementing four distinct CDS applications within a SOA framework, ²⁰ we found it useful to instantiate a service that renders structured content into human-readable formats (e.g., PDF) and a service that communicates messages to end-users. Furthermore, many CDS designers have leveraged services that allow service clients to invoke various actions within a clinical information system (CIS), such as placing an order, prompting users for data entry, and displaying alerts and reminders. ^23–25 Of note, this CIS action brokering service, in conjunction with RLUS, provides the primary capabilities of what is known as a virtual medical record (vMR) service. ²⁶

In order to maximize the re-usability of these and other services, we recommend that CDS implementers utilize the HSSP to coordinate efforts to standardize the functionality and interfaces of services useful for CDS. We believe that services that should receive highest priority for standardization include services that have been demonstrated to be of value for implementing CDS in a variety of operational settings; services that are of value to the broader health IT community; services that require substantial resources to design, implement, or maintain; and services that are promising candidates for achieving industry-wide consensus on scope and functionality.

Description of CDS Architectures in Terms of Services and Service Orchestration

As noted in the AMIA roadmap report, an important barrier to learning from previous CDS deployments is the lack of a common approach to describing CDS implementation architectures. ¹ To overcome this barrier, we recommend that CDS designers using the proposed framework describe CDS architectures in terms of what services were used and how these services were orchestrated to provide the required CDS capability. An example of this type of service-based architectural description is provided below.

Sample CDS Architecture Using Proposed Framework

▶ provides a sample architecture for an outpatient care reminder module of a CIS that is implemented using the proposed CDS implementation framework. The services used for this system are a CTS, a DSS, RLUSs, an Entity Identification Service (EIS), and a CIS action brokering service (CABS). In this sample architecture, the care reminder module in Health System A is invoked by a message from the CIS indicating that a patient has checked into an outpatient clinic (arrow 1). The CDS module then uses Health System A’s RLUS to retrieve the data required for evaluating the patient using the DSS offered by Knowledge Vendor C (arrows 2 and 3). These data requirements were previously identified by the CDS module through use of the DSS’s operation for enumerating the data requirements for DSS knowledge modules.

Figure 1.

Sample SOA for providing outpatient care reminders within a CIS. CABS = CIS Action Brokering Service. DSS = HSSP Decision Support Service. EIS = HSSP Entity Identification Service. RLUS = HSSP Retrieve, Locate, and Update Service. RHIO = Regional Health Information Organization.

Next, the CDS module provides the patient’s identifying demographic data (e.g., name, birth date, address) to the EIS of a Regional Health Information Organization (RHIO B). Through this interaction, the module learns that the patient is registered in the RHIO and obtains the patient’s unique identifier within the RHIO (arrows 4 and 5). The CDS module then uses this identifier to retrieve the required patient data from the RHIO’s RLUS (arrows 6 and 7).

Following this retrieval of the required patient data, the CDS module provides the collected data to the DSS offered by Knowledge Vendor C and retrieves CDS inferences regarding the patient, such as recommendations for preventive health services or suggestions for medication changes to better control a chronic illness (arrows 8 and 9). Based on the CDS results obtained, the CDS module makes a request to Health System A’s CABS to perform appropriate actions (e.g., place pending orders within the order entry system and generate an alert that is visible when the clinician opens the patient’s record) (arrow 10). The CDS module also makes a request to Health System A’s RLUS to update the patient’s record to note relevant data regarding the CDS communications provided (e.g., when, why, and to whom any alerts were sent) (arrow 11). While not shown in the figure, a CTS could be used at various steps in this process to provide terminology support. For example, if DSS data requirements are specified using vocabularies that are not supported by a local clinical data repository, a RLUS could use a CTS to translate the data requirements into semantically equivalent concepts that utilize vocabularies supported by the local data repository.

Contextualization among Alternate Approaches

In evaluating the proposed CDS framework, it is instructive to contextualize the proposed approach among alternate approaches. While CDS implementation approaches could be classified in various ways, ▶ contextualizes the proposed approach using a classification scheme that we have developed that focuses on the role played by CDS knowledge resources within a CDS application. ¹²

Figure 2.

Contextualization of proposed CDS implementation framework among alternate approaches.

In this classification scheme, the first level of distinction hinges on whether CDS knowledge resources (e.g., decision rules, computerized guidelines) are maintained in a knowledge base that is independent of individual CDS applications. Among approaches in which knowledge resources are maintained in a separate knowledge base, some approaches utilize knowledge resources that dictate most aspects of CDS generation and delivery, such as when the knowledge resources are to be invoked within the clinical workflow, how required patient data are to be retrieved, how patient-specific inferences are to be generated using the retrieved data, and how patient-specific inferences are to be converted into context-appropriate interventions and communicated to end-users. Examples of this approach, which we refer to as a Knowledge Resource-Centric Knowledge Integration Architecture, ¹² include the Arden Syntax, ²⁷ the GLIF3 Guideline Execution Engine (GLEE), ²⁴ PRODIGY, ²³ and SAGE. ²⁵

In contrast, other CDS implementation approaches, which we refer to as Application-Centric Knowledge Integration Architectures, ¹² use knowledge resources primarily for generating patient-specific inferences and leave other aspects of CDS implementation to the application developer. Some of these approaches, such as commercial medication CDS frameworks offered by Cerner Multum ²⁸ and First DataBank, ²⁹ focus on specific medical domains. Other approaches, such as SEBASTIAN ²⁰ and the CDS framework proposed in this manuscript, provide support for diverse knowledge domains. A critical factor distinguishing the proposed framework from other approaches is the use of standard HSSP services.

Evidence Supporting Key Architectural Decisions

Based on our past experiences and our observations of CDS adoption patterns, we believe there is good evidence to justify three key decisions we have made regarding the proposed CDS implementation architecture. These key decisions entail the use of SOA as the foundation of the framework, the use of an Application-Centric Knowledge Integration Architecture, and the use of HSSP services.

First, with regard to the use of SOA as the underlying framework, we believe our decision is supported by the widespread acceptance of this software development approach across various industries. ¹⁶ Moreover, based on our experience implementing several operational CDS applications within a SOA framework, ²⁰ we have found that the use of a SOA simplifies CDS implementation and maintenance, facilitates the re-use of existing resources, and enables rapid adaptation of existing components to meet new CDS needs. In particular, the use of this approach has allowed us to leverage the same set of machine-executable medical knowledge within four distinct, operational CDS applications. One of these systems provides disease management capabilities within our health system’s EHR system, while the other three systems provide population health management capabilities for Medicaid patients residing in five counties in North Carolina. ²⁰

Second, with regard to the use of an Application-Centric Knowledge Integration Architecture, we believe the implementation flexibility afforded by this approach makes it easier to adopt than a Knowledge Resource-Centric Knowledge Integration Architecture. In particular, we believe the widespread use of commercial medication knowledge resources in the U.S. has resulted in part from the use of a flexible Application-Centric Knowledge Integration Architecture by these knowledge resources.

Finally, with regard to the use of HSSP services, we believe our decision is justified by the need for standardization to allow for semantic interoperability, the status of the HSSP as the primary locus of standardization activity related to health care services, and the domain and technical expertise offered by HL7 and OMG. Furthermore, we believe a crucial benefit of HSSP services is the OMG standardization process, which requires that at least one commercial implementation be available within one year of the adoption of an OMG technical specification. ³⁰ Thus, by the very nature of the standardization process, HSSP services will be available to interested health care organizations as commercial, vendor-supported products.

Fulfillment of Roadmap Objectives

As discussed earlier, the AMIA Roadmap for National Action on CDS identifies six strategic objectives as the mechanism for achieving widespread use of effective CDS within the U.S. Our proposed CDS implementation framework facilitates the fulfillment of each of these six objectives, as summarized in ▶ and described below.

Table 4.

Table 4 How CDS Framework Facilitates Achievement of Roadmap Report’s Strategic Objectives

Strategic Objective	How Proposed CDS Implementation Framework Facilitates Achievement of Objective
Represent clinical knowledge and CDS interventions in standardized formats (both human and machine-interpretable), so that a variety of knowledge developers can produce this information in a way that knowledge users can readily understand, access, and apply it.	Knowledge represented as DSS knowledge module (KM) Profiles can be defined for different types of knowledge Knowledge available in human-readable form as KM trait Knowledge developers able to contribute to KM pool using preferred knowledge representation formalism KMs can be easily understood, accessed, and applied CDS interventions easily accessed as KM output
Collect, organize, and distribute clinical knowledge and CDS interventions in one or more services from which users can readily find the specific material they need and incorporate it into their own information systems and processes.	Knowledge collected, organized, and distributed as KMs CDS interventions collected, organized, and distributed as KM outputs Relevant KMs can be readily identified and leveraged Relevant CDS interventions can be readily identified and used
Address policy/legal/financial barriers and create additional support and enablers for widespread CDS adoption and deployment.	Availability of standard services meeting core CDS needs facilitates CDS implementation and maintenance SOA approach to CDS reduces implementation costs
Improve clinical adoption and usage of CDS interventions by helping clinical knowledge and information system producers and implementers design CDS systems that are easy to deploy and use, and by identifying and disseminating best practices for CDS deployment.	Proposed CDS implementation framework simplifies and facilitates CDS deployment Proposed CDS implementation framework can be adapted for use in a variety of clinical and technical settings Best practices for CDS deployment can be described in a straightforward manner in terms of service orchestration
Assess and refine the national experience with CDS by systematically capturing, organizing, and examining existing deployments.	CDS deployment architectures can be described in a straightforward manner in terms of the services used and how services were orchestrated
Advance care-guiding knowledge by leveraging data in interoperable EHRs.	Data for clinical research can be obtained using RLUSs deployed as part of CDS implementation framework

First, with regard to the objective of representing clinical knowledge and CDS interventions in standardized formats that are easy to understand and to use, the proposed framework uses standard HL7 DSS knowledge modules (KMs) to represent knowledge. In addition, profiles can be defined and standardized for different types of knowledge, and a human-readable version of the knowledge can be made available as a KM trait. Also, because the DSS standard only specifies the interface requirements of a KM, various knowledge developers can contribute to the pool of available KMs using their preferred approach to knowledge representation.

Once created, KMs can be easily understood by DSS clients, because the clients are shielded from the complexities of how the conclusions are reached by the DSS. A DSS client can simply make a service call to obtain patient-specific inferences using a KM, and the client can apply the returned inferences as needed for meeting end-users’ CDS needs. Furthermore, standardized CDS interventions can be easily accessed as KM outputs. For example, as described earlier in ▶, a DSS client can provide the age, gender, co-morbidities, and chief complaint of a patient and receive back as the KM evaluation result the recommended admission order set for that patient in a standard HL7 format.

Second, with regard to the objective of service-based distribution of CDS content, clinical knowledge is collected and distributed as KMs via DSSs. In addition, CDS interventions such as order sets can be collected, organized, and distributed as KM outputs. Moreover, relevant KMs can be readily identified using DSS search operations, and a DSS client can easily leverage a KM by requesting patient evaluations using that KM.

Third, with regard to the objective of reducing barriers and creating enablers for widespread CDS adoption and deployment, the availability of standard HSSP services meeting core CDS needs facilitates CDS implementation and maintenance. In particular, the HSSP process guarantees the timely availability of one or more commercial, vendor-supported service implementations. Also, by facilitating re-use of existing IT assets, simplifying and modularizing implementation challenges, and enabling agile adaptation to changing business needs, the use of a SOA approach should reduce costs and thereby make it easier for organizations to make a business case for adopting robust CDS capabilities.

Fourth, with regard to the objective of improving clinical adoption and usage of CDS interventions, the proposed CDS implementation framework facilitates CDS adoption by simplifying the CDS deployment process and by providing standard services to meet core CDS deployment needs. Also, because SOA services have minimal dependencies and can be leveraged in a variety of situations, the proposed framework can be easily adapted for use in a variety of settings. Furthermore, best practices for CDS deployment can be more easily communicated due to the fact that CDS architectures can be described in a straightforward manner in terms of how services were orchestrated to meet a CDS need.

Fifth, with regard to the objective of assessing and refining the national experience with CDS, the proposed CDS implementation framework allows deployment architectures to be described in a straightforward and consistent manner in terms of the services used and how services were orchestrated. As a result, CDS implementers can readily learn how prior CDS systems were designed and deployed.

Finally, with regard to the strategic objective of advancing care-guiding knowledge by fully leveraging data available in EHRs, the proposed CDS framework could facilitate this goal through the central role played by RLUS. Once deployed as part of CDS implementations, RLUSs could be used by authorized clinical researchers to obtain individual and population-level patient data in standardized formats. The data thus obtained could then be used to advance medical knowledge and enhance CDS.

Assessment of Potential for Supporting CDS on National Scale

The proposed CDS implementation framework facilitates the achievement of all six of the roadmap report’s strategic objectives for achieving nationwide adoption of effective CDS. Moreover, as discussed earlier, we have demonstrated on a limited scale that a SOA approach to CDS can facilitate the implementation of a variety of CDS applications in heterogeneous technical and clinical environments. ²⁰ Also, our proposed approach is architecturally aligned with the approach used by commercial medication knowledge vendors (▶). Given that the CDS resources offered by these vendors have been widely adopted within the U.S. for providing basic medication-related CDS, ¹ we believe our choice of a similar architecture bodes well for successful scaling of our chosen approach.

Despite these promising indications, however, there are still many hurdles that must be overcome before the proposed framework can serve as the foundation for widespread CDS implementation at a national level. To begin, HSSP services including the DSS, RLUS, and CTS must be made available to the health care community as reliable, robust, and easy-to-use services. The HSSP process should facilitate the availability of such high-quality services, as the HSSP process ensures the availability of vendor-supported implementations of each service. Also, once the service infrastructure is available, a critical requirement for success will be the availability of comprehensive and accurate CDS content within DSSs. Developing such content will perhaps be one of the most challenging barriers to overcome because of the proverbial “chicken and egg” problem. Many knowledge vendors will want assurances of a large customer base for DSS content before investing significant resources to the creation of DSS-compatible CDS content, whereas many clients will want a large DSS content base to be available before utilizing this approach. If this situation arises, perhaps the government could intervene and facilitate the generation of an initial core set of DSS content.

Finally, as noted by the AMIA roadmap report, candidate frameworks for nationwide CDS implementation must be vetted, refined, and evaluated through large-scale demonstration projects. In recognizing the need for such validation, we are in active discussions with our colleagues at other health care organizations to demonstrate the utility of the proposed approach on a large, multi-institutional scale.

Disclosure of Potential Conflict of Interest Related to Commercialization

The authors are seeking to establish a commercial implementation of the HSSP Decision Support Service using the SEBASTIAN technology. As the authors’ employer was not interested in commercializing the SEBASTIAN technology and released the intellectual property to them, the authors have created a limited liability company known as Kedasys LLC to hold this intellectual property. The application for incorporation was submitted to the North Carolina Secretary of State in August 2006, and a patent application on the SEBASTIAN technology was filed in September 2006. The ruling on the claims in this patent application is still pending. At this time, Kedasys LLC has no revenues, no licensing agreements with other commercial entities, and no employees.

With regard to the work reported in this paper, the SEBASTIAN system represents just one of potentially many approaches for instantiating a HL7 Decision Support Service. SEBASTIAN is not the only way to implement this draft HL7 standard nor to fulfill the strategic objectives of the Roadmap for National Action on CDS.

Conclusions

The history of medical informatics is full of predictions of rapid progress that failed to materialize. However, we feel that the time is right for CDS to begin to fulfill its promise of transforming how health care is delivered in this country. A number of factors are now coming into place that have the potential of taking robust CDS outside the confines of a small number of model organizations. These enabling factors include the growing adoption of pay-for-performance by insurers ³¹ ; the increasing recognition that CDS must be disseminated outside model institutions in order to have the desired impact on health and health care ¹ ; a small but growing body of evidence showing that appropriately implemented CDS systems can reliably drive improvements in care ² ; and the increasing willingness of the federal government to fund large-scale projects aimed at improving the quality and efficiency of health care through information technology. ¹ Thus, if the right infrastructure and enablers are put into place, we believe that CDS can begin to play a much larger role in routine health care in this country within the next 10 to 15 years. In looking towards this future, we predict that the use of standard HSSP services within a SOA framework will play a central role in this transformative process.