Because a CDS module typically must communicate with other systems regarding health care concepts, it can be very difficult to create CDS resources that can be re-used across different conceptual representations of health care. In this light, knowledge sharing has two main forms: knowledge reuse and knowledge transfer. In knowledge reuse, CDS knowledge is employed for a different purpose or application than its original form within its original organization. For example, CDS knowledge that establishes that a patient has kidney failure may be reused within the same organization in a pharmacy system to establish a drug dose, in a radiology system with regard to iodinated contrast administration, and in a nursing documentation system to provide guidance about fluid administration. Knowledge also may be transferred across organizational boundaries for the same purpose. In both reuse and transfer, common information models are needed due to the significant challenges associated with mapping CDS knowledge to different, non-standard information models [16-19]. For example, if a CDS knowledge resource expects to have access to a problem list and laboratory data but a deployment context has neither, the CDS resource cannot be deployed in this context. Similarly, if a CDS knowledge resource expects to have access to a granular problem list encoded in the Systematized Nomenclature of Medicine (SNOMED) [20] but only has access to a more generic problem list encoded using the 9^th edition of the International Classification of Diseases (ICD9) [21], the CDS resource may not be usable because the level of granularity required and supported by SNOMED is not supported by ICD9.

Several types of standards can facilitate the implementation of CDS by providing a common framework for conceptualizing health care. Such enabling standards include standard terminologies and information models for representing health care data, as well as standards for the types of patient data that are expected to be available for CDS within specified contexts such as EHR systems [22]. Moreover, CDS implementations can be aided by the availability of standard approaches for obtaining terminology and ontology inferences, such as the mapping of concepts across terminologies and the identification of concept properties and semantic relationships [23,24].

At the core of a CDS implementation is the representation of clinical decision logic in a detailed, machine-executable format that can be used to drive automated CDS. As an important step in this knowledge creation process, CDS knowledge engineers must first create detailed, human-readable specifications of the knowledge based on clinical practice guidelines and other sources of clinical knowledge. This step is necessary because narrative clinical guidelines often lack the detail and algorithmic specificity required for easy translation into a machine-executable format [25].

The widespread use of a standard format for representing human-readable medical knowledge intended for translation into machine-executable knowledge would facilitate the development of CDS capabilities, as CDS developers would be able to develop processes and tooling to enable large-scale, replicable, collaborative, and decentralized knowledge development processes to support the several steps that precede the conversion of knowledge into a machine-executable format. For example, significant efficiencies could be gained if national guideline task forces and other creators of the original knowledge agreed to use the same format for specifying the underlying clinical decision logic at the level of detail required for converting the knowledge into a machine-executable format. Standardization in this area could leverage relevant work conducted both within and outside of the context of standards development organizations to ease the conversion of clinical guidelines from textual descriptions to computer interpretable specifications [10,26-29].

Following the specification of medical knowledge in a detailed, human-readable form, the clinical knowledge specification must be converted into a machine-executable format that can be appropriately interpreted and utilized by a CDS system. While various approaches are available for such machine-executable knowledge representation [30,31], these different formalisms generally have formalism-specific infrastructure needs that can require substantial resources and expertise to implement. Thus, the widespread use of one or more common knowledge representation approaches could substantially facilitate the use of the encoded knowledge to provide CDS.

In providing CDS, one of the most difficult challenges is leveraging machine-executable medical knowledge resources and electronic clinical data to deliver useful CDS interventions within the context of various health information systems. While this task can be manageable when interacting with a single health information system using a single type of knowledge resource, the heterogeneity of knowledge resources and health information systems makes it difficult to re-use a CDS implementation infrastructure developed for one clinical context within other applications and care settings. For example, a knowledge execution environment designed to leverage Arden Syntax Medical Logic Modules [32] cannot readily use executable medical knowledge encoded using the Guideline Interchange Format (GLIF) [10]. Similarly, a knowledge execution environment designed to work with one commercial EHR system cannot be easily interfaced with another commercial EHR system, or potentially even with the same EHR system deployed in a different health care setting, to conduct such necessary system-to-system interactions as obtaining relevant patient data from the clinical database or delivering alerts to relevant care providers. Thus, in order for knowledge resources to be usable in a scalable manner across various applications and institutions, standardized approaches are needed for how machine-executable, implementable knowledge resources are leveraged within health information systems to generate and deliver CDS interventions. For example, regardless of the underlying knowledge representation approach used, various knowledge resources could potentially be accessed through a standard system-to-system interface that is agnostic of the underlying knowledge representation formalisms in use [33-35]. Moreover, because CDS modules that leverage knowledge resources typically interact with other components of the health information system to generate and deliver the decision support intervention, there is a need for standards on how such CDS modules interact with health information systems to obtain required data and deliver needed interventions. For example, if various EHR systems provided common software service interfaces for retrieving the patient data needed for CDS and for delivering patient care recommendations to clinicians, these standard interfaces would significantly facilitate the scalable implementation of CDS using a common set of machine-executable knowledge resources.

Various standard terminologies are already well-developed [30]. Most of these terminologies are compiled in the National Library of Medicine’s Unified Medical Language System [36], which maps concepts from each of over 100 source terminologies to unique master concepts. Notable standard terminologies included in the Unified Medical Language System include the Systematized Nomenclature of Medicine-Clinical Terms (SNOMED CT) [20], the Logical Observation Identifiers Names and Codes (LOINC) [37], RxNorm [38], and the International Classification of Diseases (ICD) [21].

Currently, standard terminologies such as SNOMED CT [20], LOINC [37], and RxNorm [38] are available for CDS with relatively adequate breadth, depth, and granularity [24]. Thus, the challenge lies less with the lack of relevant standards, but more with the fact that multiple terminologies are in concurrent use, including many non-standard terminologies (e.g., vendor-specific laboratory terminologies). The concurrent use of these various terminologies is a significant challenge, as differences in the granularity of terminologies oftentimes prevent a concept from one terminology from being mapped one-to-one to an equivalent concept in another terminology. As a result, a CDS resource designed for use in one setting may not be readily usable in another setting that uses a different set of terminologies, even when similar concepts are being captured.

Standard information models are also available for supporting CDS in a scalable manner. Perhaps most prominent among these information models are the models used for HL7 version 2 messages, which are ASCII-encoded messages that communicate various information relevant to the care of a patient [39]. While easy to understand and widely adopted, these models have been the target of substantial criticism. In particular, HL7 version 2 information models have been criticized for their adoption of loose semantics that ultimately compromise interoperability, including the optional use of non-standard coded values and the use of “Z segments” that allows non-standard data elements to be represented in message instances. In response to a desire to improve the semantic interoperability of such messages, HL7 embarked on the creation of version 3 messaging standards in the mid-1990s that would be based on a unified, rigorously modeled set of information models all derived from a generic representation of health care known as the Reference Information Model [39]. Much of the ongoing work at HL7 focuses on the continued development of version 3 information models for various health care domains. Of note, however, HL7 version 2 information models are still much more widely adopted than version 3 information models in operational clinical systems, especially in the United States. Thus, for the foreseeable future, HL7 version 2 standards will likely need to be supported for the purposes of enabling standards-based and scalable CDS.

Beyond HL7, other standard information models include openEHR archetypes [40] and the ASTM International Continuity of Care Record [41]. Moreover, the clinical content of the Continuity of Care Record is now available in the Continuity of Care Document information model developed by HL7 and ASTM International [42].

Furthermore, work has recently begun within the HL7 CDS Work Group to establish a standard for a concept known as the virtual medical record (vMR) [43]. As originally proposed in the literature, a vMR consisted of a standardized definition of both (i) the semantics of information communicated between a CDS engine and a health information system and (ii) the functional capabilities of a health information system available to the CDS engine (e.g., to order a prescription or to deliver an alert) [44]. Currently, the HL7 vMR project is seeking to standardize the first of these two aspects of a CDS engine’s interaction with a health information system (i.e., the information models used to represent the patient data used by a CDS engine and the information models used to represent the inference results returned by a CDS engine) [43]. This project holds significant promise for standardizing how information is communicated between health information systems and CDS engines to generate patient-specific care assessments and recommendations.

Despite these promising standards, important gaps and challenges remain. First, current information models oftentimes lack sufficiently tight binding to terminologies. For example, a clinical information model may recommend the use of SNOMED CT to represent medical diagnoses but also allow the use of ICD9 or ICD10. Given the previously noted challenge with mapping concepts from different terminologies, this is a significant problem for implementing scalable CDS. Furthermore, as a second challenge, many of the current generation of information model standards – including many of the HL7 version 3 information model standards – entail much more flexibility and complexity than is required or desirable for CDS. For example, the HL7 version 3 information model for laboratory observations contains over fifty component classes, significant optionality, and several recursive relationships [45]. While this type of an information model does enable very sophisticated and complete clinical documentation, such extensive expressivity and flexibility make these information models much harder to understand and to implement in operational systems. This difficulty is exacerbated by a lack of tooling and other practical resources to support the widespread use of these information models by health information technology (IT) professionals. Moreover, much of the information captured in these models is largely irrelevant for CDS applications (e.g., who performed the laboratory test). At the same time, simplified patient information models appropriate for use as inputs by CDS systems have not yet been standardized, and standard information models for CDS outputs are largely non-existent. Finally, there is little alignment between these standard models and the logical structure or schemata of clinical data repositories in actual use. As a consequence of these various factors, there is currently very limited usage of standard information models within most operational CDS systems.

From the perspective of a CDS implementer, the standardization of the type of patient data expected to be available for use within a CDS application would significantly reduce the complexity of developing and implementing CDS capabilities. While it may be unrealistic to have a single standard which is universally adopted, it would be possible to have a small number of standards on expected data availability (e.g., one standard for a full EHR environment, another standard for an environment only with access to claims data, and a third standard for an environment with access to claims data and laboratory data). While the HL7 vMR project is working to address this issue, a significant challenge with this regard is that this project is still under development and that different health IT systems continue to collect data with different granularity and scope.

A critical CDS implementation need is the mapping of clinically relevant concepts to terms used within various health information systems. These terminology needs for CDS typically manifest in two forms: (i) the need to identify which concepts are subsumed by a parent concept, and (ii) the need to translate concepts across vocabularies. For example, consider a simple CDS scenario in which there is a need to identify whether a patient has diabetes, so that appropriate disease management guidance can be provided. If the underlying health information system uses SNOMED CT to capture problem list data, there would be a need to identify all of the SNOMED CT codes that could have been used to note that a patient has diabetes (i.e., all of the SNOMED CT codes that are subsumed by the parent code of 73211009 [diabetes mellitus], such as 44054006 [diabetes mellitus type 2] and 190392008 [diabetes mellitus – poor control]). Moreover, if the CDS resource has been encoded using SNOMED CT codes for problem data, whereas a health IT system used ICD9 for capturing problem data, there would then be a need to identify matching concepts for diabetes in ICD9 (e.g., by identifying all ICD9 codes that map to the SNOMED CT codes for diabetes previously identified, and then by further identifying all ICD9 codes that are subsumed by the mapped ICD9 codes for diabetes).

A terminology service can provide these types of terminology inferencing capabilities through a service interface. Standardization of such service interfaces can enable CDS implementations to leverage different terminology services based on their capabilities, rather than being locked into a single solution because of investments in proprietary system-to-system interfaces. Fortunately, the HL7 Common Terminology Services version 1 [46] and 2 [47] standards provide standard specifications for how various terminology inferencing capabilities can be obtained from a software service. Perhaps more importantly, significant tooling and resources are being developed to support the use of this standard. Most notably, the National Cancer Institute has funded the development of an open-source terminology server known as LexBIG that is compatible with the Common Terminology Services standard [48]. This initiative provides an excellent model of how a CDS-related standard, when adequately resourced, can be taken from specification to robust, implementable software.

Despite the promise of this domain of standardization, it is still the case that many terminologies remain semantically incompatible, regardless of the tooling available for inferencing between such terminologies. Consequently, the use of standard information models with a limited set of bound terminologies is still essential to developing CDS in a highly scalable manner.

Since 2002, the Guideline Elements Model (GEM) has been available as an ASTM International standard for the representation of the contents of clinical practice guidelines in a structured, non-executable format that is suitable for translation into an executable format [27]. Now in its second version (GEM II), this approach to knowledge modeling includes an XML Schema defining a structured format for extracting the relevant content of a clinical practice guideline, an object-oriented data model, and a freely downloadable tool for editing GEM guidelines known as the GEM Cutter.

A significant gap that exists in this aspect of the CDS standards continuum is that while GEM provides a relevant standard for the structured representation of individual clinical practice guidelines, significant medical knowledge exists outside of individual clinical practice guidelines (e.g., knowledge on drug-drug interactions). The absence of this knowledge from a published guideline can complicate its translation into an implementable or computable format [25]. Moreover, CDS applications often must integrate the guidance provided by multiple relevant clinical practice guidelines in a given domain, some of which may provide conflicting advice. Another important challenge is that the vast majority of guideline content producers continue to generate clinical practice guidelines in non-structured, non-standardized formats that must then be interpreted by an external group into a structured and potentially standardized format. Moreover, even when captured in a format such as GEM, there is still no clear path for moving medical knowledge from a non-executable format into an executable format that can be used in a scalable manner across multiple applications and care settings, although some groups have demonstrated translations of GEM to more computable formalisms such as the Arden Syntax [49].

Several standards are available for representing machine-executable clinical guidelines. These standards include two standards that can be used to represent machine-executable clinical rules. First, the HL7 Arden Syntax standard specifies various aspects of Medical Logic Modules, which include a specification of the following: knowledge meta-data; when the module should be triggered (e.g., the storage of a new potassium laboratory value in an EHR); how required data should be retrieved; how the input data should be used to generate a conclusion; and how that conclusion should be communicated to relevant end-users (e.g., as a text page) [8]. The Arden Syntax does have several challenges, however. While proprietary compilers have been developed for executing Arden Syntax Medical Logic Modules, there is a lack of a non-proprietary Arden compiler that works across applications and care settings. Furthermore, the current Arden Syntax specification lacks a standard model for representing input data (known as the “curly braces problem” because the data requirements are specified within curly braces in an implementation-specific manner). Despite the fact that the Arden Syntax is supported by several commercial EHR systems, there has not been much knowledge sharing among health care institutions using Arden. One exception to this limited sharing of Arden Syntax Medical Logic Modules has been knowledge sharing among institutions that are clients of the same CDS software vendor, as various implementations of the same core system can transfer knowledge with relatively less re-engineering [50].

GELLO is another HL7 standard for the representation of clinical rules in a machine-executable format [9]. Specified as an extension to the Object Management Group’s Object Constraint Language, GELLO provides a grammar for expressing the input data for clinical rules as well as how those data are to be manipulated to generate patient-specific inferences. As with the Arden Syntax, however, GELLO does not yet have a non-proprietary compiler that allows GELLO expressions to drive CDS across applications and care settings.

In addition to standards for representing clinical rules, standards are available for representing highly structured knowledge documents that can be used to drive CDS. One of these standards is the HL7 Structured Product Labeling standard [51], which is used by the U.S. Food and Drug Administration to provide medication labeling information in a structured format. Furthermore, the HL7 Order Set specification [52] enables the consistent exchange of information on order sets used within computerized provider order entry systems. This specification underwent successful balloting as a draft standard in September 2008 and is currently undergoing final enhancements based on peer review comments prior to being officially published as an HL7 draft standard. Also, the HL7 Health Quality Measures Format draft standard provides a standard format for representing quality measures that are primarily intended for quality reporting purposes but could also be leveraged for point-of-care CDS applications [53].

Despite these available standards, no standard is widely agreed upon for representing clinical practice guidelines in a machine-executable format. While the HL7 CDS Work Group has attempted in the past to specify and adopt a single, common model for representing clinical practice guidelines in a machine-executable format, attempts to date have been unsuccessful. Moreover, as is often the case with current standards within the health IT space, limited tooling and support is available for implementing CDS using many of these standards. Furthermore, in most cases, there is still limited availability of knowledge resources that are standards-compliant and easily available for use in CDS implementation efforts.

Distinct from the standardization of the representation of machine-executable medical knowledge is the standardization of how such knowledge is utilized. Two HL7 standards are currently available for accessing and utilizing machine-executable CDS resources through the calling of an external software service. First, the HL7 Decision Support Service draft standard [33] provides a standard approach to providing structured patient data and receiving structured, patient-specific inferences based on the use of Decision Support Service knowledge modules. This approach to providing CDS as a service is based on a services-based approach to CDS known as SEBASTIAN, which has been previously described [54]. Used in combination with other standard services within a service-oriented architecture, the use of Decision Support Services could help fulfill the strategic objectives of the Roadmap for National Action on CDS commissioned by the U.S. Office of the National Coordinator for Health IT [12]. As with other HL7 service standards, a detailed technical specification for the Decision Support Service has been developed and adopted by the Object Management Group (OMG) [34] through a joint HL7-OMG initiative known as the Healthcare Services Specification Project [55].

Furthermore, the HL7 Context-Aware Knowledge Retrieval (“Infobutton”) standard [56] provides a specification of how data on a patient, a clinical question, and the relevant clinical context can be passed to an external software service to retrieve back knowledge resources relevant for that specific situation as an attempt to help clinicians and patients fulfill their knowledge needs. The Infobutton standard has achieved rapid adoption among knowledge resource publishers and EHR vendors and has been selected by the Healthcare Information Technology Standards Panel (HITSP) as the recommended standard for retrieving context-relevant medical knowledge [57]. In addition, the HL7 Infobutton project is now developing a specification for service-oriented implementations of infobuttons as a profile within the HL7 Decision Support Service standard.

Despite these available standards, significant gaps and challenges remain. First, the semantics of service payloads for CDS are still undergoing standardization. The HL7 vMR project is expected to address this gap, but this work is still ongoing. Furthermore, no standard is available for identifying and retrieving machine-executable medical knowledge resources themselves (e.g., Arden Syntax Medical Logic Modules or HL7 Order Sets). Also, there is still work required on defining a commonly accepted meta-data model for knowledge resources.

Several standards are available to facilitate the scalable integration of medical knowledge resources within health information systems to enable CDS. The HL7 Retrieve, Locate, and Update Service draft standard [58] specifies a standard service interface for locating, retrieving, and updating patient health information, and the various terminology and information model standards discussed earlier are available for facilitating the communication of such information in a consistent manner. Furthermore, the HL7 EHR Functional Model [59] specifies the functions that should be available within compliant EHR systems, as does the Certification Commission for Health Information Technology [60].

Despite these important standards, significant gaps and challenges still remain for the standard delivery of CDS within health information systems. First, there is a lack of standards for the EHR services upon which many CDS implementations depend, such as for order placement or alert delivery. While the HL7 EHR Functional Model and the criteria set forth by the Certification Commission for Health Information Technology do encompass the capabilities that should be available within an EHR system, these specifications are functional in nature and not defined at the level of detail needed for semantic interoperability. The HL7-OMG Healthcare Services Specification Project is seeking to address this lack of standard service definitions in health care, and this initiative already has developed several relevant standards including the HL7 Retrieve, Locate, and Update Service draft standard [58] and the HL7 Decision Support Service draft standard [33]. However, much work still remains in this arena. Also, as discussed earlier, while the notion of a vMR has traditionally encompassed the standardization of EHR services, such standardization of EHR services is not within the scope of the current HL7 vMR project.

A further challenge to scalable CDS delivery is the lack of use in health care of standard business process modeling approaches [61]. If widely adopted within health care, standard business process modeling approaches would allow CDS implementers to specify, share, and adapt workflow specifications of human and computer actors relevant in the delivery of CDS.

Finally, a significant challenge to the standardized delivery of CDS is the enormous heterogeneity that currently exists, and is likely to continue to exist, in the health information system infrastructure available across different care settings [62]. Moreover, even if all EHR systems eventually supported standard interfaces and semantics for interaction with a CDS engine, such standardization would still leave significant gaps in the capacity for scalable CDS delivery if many clinicians continue to practice without the aid of EHR systems.