Service Oriented Architecture for Clinical Decision Support: A Systematic Review and Future Directions

Abstract

The use of a service-oriented architecture (SOA) has been identified as a promising approach for improving health care by facilitating reliable clinical decision support (CDS). A review of the literature through October 2013 identified 44 articles on this topic. The review suggests that SOA related technologies such as Business Process Model and Notation (BPMN) and Service Component Architecture (SCA) have not been generally adopted to impact health IT systems’ performance for better care solutions. Additionally, technologies such as Enterprise Service Bus (ESB) and architectural approaches like Service Choreography have not been generally exploited among researchers and developers. Based on the experience of other industries and our observation of the evolution of SOA, we found that the greater use of these approaches have the potential to significantly impact SOA implementations for CDS

1. Introduction

1.1. Service Oriented Architecture in Health Care

Service-oriented architecture (SOA) can be defined as “an open, agile, extensible, federated, composable architecture comprised of autonomous, Quality of Service (QoS)-capable, vendor diverse, interoperable, discoverable, and potentially reusable services, implemented as Web services” [1]. SOA has been generally accepted as an enterprise information technology (IT) architecture approach and is being increasingly adopted by various enterprises according to a recent report published by Gartner [2].

Although there is an increasing trend in adoption of SOA in other sectors of the economy, its implementation in health care has been relatively slow. According to a survey of 2,165 companies conducted by Forrester Research, SOA adoption in healthcare and public sectors remains low, whereas utilities, financial institutions and insurance companies show a high rate of acceptance and implementation [3]. An example of the high impact of SOA in other industries is the Banking Industry Architecture Network (BIAN), which is a worldwide not-for-profit organization with more than 30 technology and banking members that have adopted SOA as a strategy to face the challenges of a dynamic, competitive and globalized market [4].

Despite its slow start, pioneering healthcare organizations have adopted SOA as an integration strategy [5]. These organizations have recognized that by integrating and automating their systems, they can reduce costs and improve quality of service. Some other benefits that the SOA approach provides to healthcare organizations include interoperability, increased accuracy of medical data and compliance with new regulations [6]. Recognizing the importance of SOA, a number of organizations and governments have undertaken initiatives to support its advancement in health care. A prominent effort in this area is the Healthcare Services Specification Project (HSSP), which is a joint effort between Health Level 7 (HL7) and the Object Management Group (OMG) that focuses on service specification standards based on SOA principles [7]. HL7 is an international authority on standards for interoperability of health information technology [8] and OMG is an international authority on computer standards for a wide range of industries [9]. There are several national efforts worldwide aimed at advancing and leveraging SOA-based health IT architectures. Of note, Canada Health Infoway is an effort to accelerate the adoption of Electronic Health Records (EHR) across Canada that leverages SOA as a core architectural foundation [10].

1.2. Clinical Decision Support

Health care is a heterogeneous environment consisting of different types of information systems and domains. Examples of information systems in health care include electronic health record (EHR) systems, picture archiving and communication systems (PACS), laboratory information systems (LIS) and clinical decision support systems (CDSS).

Clinical decision support (CDS) provides clinicians, patients, or other individuals with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care [11]. CDS is an important driver for health information technology (HIT) because it can support clinical decision making, improve patient outcomes, reduce unnecessary mistakes and expenses, and increase efficiency [12].

Indeed, improving and creating new CDS modules is often an important IT initiative for many healthcare organizations. The importance of CDS has also been emphasized by a number of initiatives. For example, maturity models focusing on the management of information system technologies in health care such as the Electronic Healthcare Maturity Model (eHMM) developed by Quintegra [13], the Electronic Health Record Adoption Model (EHRAM) established by the Healthcare Information and Management Systems Society (HIMSS) [14, 15] and the Electronic Patient Record (EPR) maturity model established by the United Kingdom National Health Service (NHS) [16] all identify CDS as an essential aspect of achieving advanced HIT capabilities. Similarly, the Institute of Medicine (IOM) recognized CDS as an important strategy for improving the quality of patient care [17].

Despite the benefits offered by CDS to improve health and healthcare, most clinical decisions are made without the assistance of computerized CDS [11, 18], and only a limited number of organizations are implementing advanced CDS functionalities [19]. Research on this subject suggests a number of barriers to the adoption of CDS [11, 12, 20], with one critical obstacle being the tight coupling of many CDS functionalities to specific software systems [11, 21]. This makes it difficult to transfer clinical knowledge across applications. SOA has been proposed as a potential solution to this problem [22–24]. Other benefits that a SOA approach provides CDS include the following:

• Facilitate knowledge maintenance: CDS content can be centralized, thereby reducing maintenance efforts [23, 25]. For example, specialized medical organizations can develop and maintain clinical guidelines and expose their services to healthcare organizations [23].

• Reduce costs: SOA allows cost reduction by reusing existing CDS services, thus minimizing time of software development and simplifying software maintenance [22, 23, 25].

• Improve agility: SOA allows implementation of new CDS functionalities in a timely manner [7].

Despite the potential of SOA to provide a transforming approach to enabling CDS at scale, there has been no comprehensive summary and analysis of the relevant literature on SOA for CDS. Thus, in order to accelerate progress in this field, this manuscript reviews the relevant literature, highlights gaps in research, and provides recommendations to move this field forward. The scope of the review is to describe and assess recent progress regarding the use of SOA in the context of CDS.

This manuscript encompasses a review of (1) current implementations of SOA for CDS, (2) associated architectural approaches, and (3) relevant health IT standards. We believe that this manuscript will serve as a useful guide for future research and implementation of SOA in CDS.

2. Methods

The systematic review was conducted following the process proposed by Kitchenham [26] and in accordance with the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) [27]. The process consisted of three phases: planning, conduction and reporting. In the planning phase, the research questions and systematic review protocol were defined. During the conduction phase, primary studies were identified, selected, and evaluated according to the inclusion and exclusion criteria previously defined. Data were extracted and synthesized for each selected study using data extraction forms developed at the planning phase. Finally, in the reporting phase, the final report was created and presented.

2.1. Data Sources and Searches

The electronic bibliographic databases screened included the Association for Computing Machinery (ACM) Digital Library, Compendex, IEEE Explore, Science Direct, Springer, Web of Science, and Scopus (through 20 October 2013). The first six databases are considered efficient for conducting a systematic review in the context of software engineering [28]. We added Scopus since it is considered the largest database of abstracts and citations [29]. Scopus encompasses approximately 4600 health science titles, includes 100% MEDLINE and EMBASE coverage [30], and provides coverage of medical journals.

“Service oriented” and “clinical decision support” were used as the main keywords for the search, along with the following related terms:

• service oriented: “service-oriented”, “service based”, “service-based”, “service orientation”, “service-orientation”, “SOC” and “SOA”

• clinical decision support: “CDS” and “CDSS”

The following search string was applied and adapted to each publications database:

(“service oriented” OR “service-oriented” OR “service based” OR “service-based” OR “service orientation” OR “service-orientation” OR “SOC” OR “SOA”) AND (“clinical decision support” AND “CDS” AND “CDSS”)

The exact search method for each database is showed in Appendix A.

2.2. Study Selection

Only publications written in English were included in this systematic review. The following inclusion and exclusion criteria were used:

Inclusion criteria (at least one required):

• The study proposes or reports on the design and development of service-oriented CDS.

• The study proposes or reports on a new technology for developing service-oriented CDS systems.

• The study proposes or reports on a process, method, technique, or reference architecture that supports either the design or the development of service-oriented CDS systems.

• The study proposes or reports on a healthcare standard that supports either the design or development of service-oriented CDS systems.

Exclusion criteria:

• The study proposes or reports on the design of CDS systems without using service orientation.

• The study presents contributions in areas other than CDS.

• The study is a table of contents, short course description, tutorial, copyright form or a conference or workshop agenda.

The study selection was performed by one of the authors (SR) in two stages. In the first phase, all potentially relevant studies were selected based on titles, abstracts, and keywords and in consideration of the inclusion and exclusion criteria. In the second phase, each of the studies selected from the previous stage were read in full and analyzed again according to the inclusion and exclusion criteria. In addition, the related works cited by these studies were evaluated and included in the review if they were considered relevant to the search area.

2.3. Data Extraction and Quality Assessment

Data extraction and quality assessment were undertaken by one author (SR) and confirmed by another (VH). Data related to architectural approach, technology adopted, healthcare standards implemented, and challenges and potential solutions were extracted and categorized.

2.4. Data Synthesis and Analysis

The extracted data was tabulated and summarized, any disagreement was resolved by discussion and, when necessary, by involving a third reviewer. The extracted data was grouped into the following topics: publications per year, architectural approach, healthcare standards, and challenges and lessons learned. In the architectural approach, the review focused on categorizing what architectural approaches have been adopted for the implementation of SOA in the CDS domain. In terms of healthcare standards, we extracted from the reviewed articles which medical standards were adopted to achieve semantic interoperability. Finally, we summarized challenges and lessons identified in the reviewed articles.

3. Results

Figure 1 shows the study process selection. The search strategy yielded 138 unique studies. After title and abstract screening of those studies, 42 studies were selected for full text analysis. Eight studies were excluded during the full text review and an additional 10 related works cited by the reviewed studies were added into the reviewed set. In the end, a total of 44 studies were included in the final systematic review (see Figure 1). Appendix B lists all included articles.

Fig. 1.

Study selection process

3.1. Publications per year

In order to identify the research activity in the area of service oriented CDS, we classified the studies by year of publication (Figure 2). It is important to note that only studies available as of October 2013 were considered in the systematic review. Figure 2 suggests that articles describing the use of SOA for CDS first appeared in the literature in 2004. The volume of articles peaked in 2009 with a slight decline in 2011 and 2013.

Fig. 2.

Number of publications per year

3.2. Architectural approach

There are a number of possibilities for architectural approaches when implementing SOA based systems [31]. We identified six general architectural themes that are evident in the use of SOA-based CDS: (1) point to point, (2) enterprise service bus (ESB), (3) service registry, (4) clinical guideline engine, (5) rule based engine, and (6) service choreography and orchestration. Figure 3 shows the number of publications addressing each architectural approach. Some studies adopted more than one of these approaches and are therefore counted in multiple categories.

Fig. 3.

Number of publications per architectural approach

These categories were based on topic analysis of all reviewed articles as well as prior literature that described architectural approaches that were most commonly presented when adopting SOA for CDS systems [31–35].

When comparing which architectural approach is most commonly used, the results suggest that point-to-point communication is the most popular architectural approach whereas service choreography seems to be the least explored (Figure 3). We comment on each approach in the following subsections, with sections on guideline engine and rule based engine combined into a single subsection because they are closely related.

3.2.1. Point-to-point communication

The results suggest that point-to-point communication is the most common approach used in the development of SOA-based CDS systems. None of the articles explain the rationale for choosing this approach. However, we assume that it is a natural first step in evolving the integration of services. As discussed in section 3.2.2, ESB provides a more flexible communications approach. In the point-to-point communication approach, each interaction between the applications (e.g., service provider and service consumer) is individually designed, implemented, and administered. Thirty five publications suggested or reported the use of this approach, which represents 79.5 % of the articles included in the review. These studies show that Simple Object Access Protocol (SOAP) seems to be the communication technology of choice to facilitate point to point communication. Table 1 shows in detail the system name, communication approach and clinical implementation area. One critical factor in selecting a communication technology for point to point communication is security, due to the need to transfer and use confidential medical data. SOAP is based on OASIS standards and has in-built security features. However, SOAP does consume more bandwidth when compared to another communication technology, Representational State Transfer (REST). Whilst REST has some advantages, it requires significant effort to make secure data communications.

Table 1.

Publications that adopted or suggested a point to point communication approach

Communication approach	System name	Clinical implementation area	Publication reference
SOAP	OPNI-Web	Neonatal intensive care unit	[36]
SOAP	NewGuide	Homecare-based pressure ulcer prevention, acute ischemic stroke treatment, heart failure management	[37]
SOAP	GLEE	Childhood immunization, cough	[38]
SOAP	SAGE	Immunization	[39]
SOAP	ARTEMIS	Not specified	[40]
SOAP	--	Not specified	[41]
SOAP	--	Chronic disease management	[42]
Not specified	--	Pediatric immunization	[43]
SOAP	--	Asthma, drug-drug interaction checking	[44]
SOAP	--	Not specified	[45]
SOAP	--	Not specified	[25]
SOAP	DDSOnt	Collaborative diagnosis decision making among physicians	[46]
SOAP	EGADSS	Not specified	[22]
SOAP	EGADSS	Not specified	[47]
SOAP	SANDS	Drug interaction checking, syndromic surveillance, diagnostic decision support, inappropriate prescribing in older adults, information at point of care, personal health record	[23]
Not specified	--	Translational medicine	[48]
Not specified	--	Childhood immunization	[49]
Not specified	OncoTheraper	Pediatric oncology	[50]
Not specified	TRIACS	Diabetic retinopathy screening and research	[51]
SOAP	SAPHIRE	Hospital and homecare environment	[52, 53]
Not specified	DeGeL/Gesher	Preeclampsia/eclampsia toxemia guideline	[54]
Not specified	MATE	Cancer multidisciplinary meeting	[55]
SOAP	--	Medication management	[56]
Not specified	--	Intensive care unit	[57]
SOAP	--	Not specified	[24]
Not specified	--	Hypertension guideline	[58]
SOAP	--	Detection and automated monitoring of hospital-acquired infections	[59]
Not specified	HealthFlow	Osteoporosis	[60]
SOAP	CBPsp	Neonatal intensive care unit	[61]
SOAP	--	--	[62]
Not specified	--	Palliative care	[63]
SOAP	--	Colon cancer screening	[64]
SOAP	--	Hypertension, chronic care management	[65]
SOAP	--	Diabetes	[66]

3.2.2. Enterprise Service Bus (ESB)

The ESB is another architectural approach which aims to provide loose coupling for applications with a universal bus that can accept all data formats from any source and integrate data flows into the appropriate applications. An ESB separates the integration logic into manageable pieces and is highly scalable [34]. There is a large spectrum of ESB systems offering different levels of functionality. We identified six articles that proposed or used this architectural pattern. In contrast to the point-to-point communication approach, the messages pass through the ESB, which serves as an intermediary between the service provider and service consumer. Some of the advantages of using an ESB include the ability to support message routing, event triggering, data transformation, security, monitoring and management [67].

In our review, we identified which ESB functionalities are commonly used for the development of service oriented CDS. The most common features are listed in table 2. Table 2 suggests that protocol bridging and data transformation are the main features exploited, whereas only one study suggests using an ESB’s event-driven functionalities to provide CDS services.

Table 2.

ESB based features used or proposed in the analyzed studies

ESB features used	System name	Implementation or proposed services	Publication reference
Event-driven functionalities	Infoway	Identify patterns of interactions such as spread of epidemics, distribution patterns of patients in particular regions or distribution patterns of particular health services	[68]
Protocol bridging, data transformation	HEARTFAID	Intensive care unit	[53, 69]
Protocol bridging, data transformation	COSARA	Intensive care unit	[70, 71]
Protocol bridging, data transformation	SOCBeS	Chronic disease prevention	[72]
Protocol bridging, data transformation	SCP	Multiple morbidities	[73]

3.2.3. Service registry

The service registry supports different strategies in SOA-based systems such as standardization of service contracts, metadata centralization and notification of service contract changes to consumers [32]. The service registry is a system component that stores information related to each service (e.g., description, policies, contract location, and versions). Thus, service consumers can find the services that fulfill their requirements by querying the service registry.

Table 3 suggests that the provision of service descriptions is the main feature exploited from the service registry.

Table 3.

Architectures that include a service registry

System name	Service registry feature used	Publication reference
DDSOnt	Provide service descriptions	[46]
SAPHIRE	Store ontologies, advertise and discover Web services	[52, 53]
Infoway	Provide service descriptions	[68]
--	Provide service descriptions	[58]
SANDS	Provide service descriptions	[23]

3.2.4. Clinical guideline engine and rule engine

In addition to point to point communication, ESB and service registry, a fourth important architectural approach in the context of SOA-enabled CDS is the use of a clinical guideline engine or a rule engine. We considered a clinical guideline engine to be a program capable of interpreting clinical knowledge expressed in a computerized format [74], whereas we considered a rule engine to be a software system that is designed to manage and enforce business rules expressed in a specified format such as if-then formats [75].

Table 4 presents an overview of which clinical guideline engines and rule engines were employed, as well as the guideline or rule languages used by these systems.

Table 4.

Systems that suggest or adopt guideline engine or rule engine

System name	Rule/guideline engine	Language	Publication reference
GLEE	GLEE	GuideLine Interchange Format (GLIF)	[38]
SAPHIRE	GLEE	GLIF	[52]
NewGuide	--	Flow-chart like approach with strong connection with Petri Nets	[37]
SAGE	SAGE	SAGE guideline model	[39]
--	ActiveBPEL	Business Process Execution Engine (BPEL)	[41]
--	Collaxa BPEL Engine	BPEL	[44]
BJC Healthcare	--	BPEL	[45]
--	SEBASTIAN	Rule-based	[42]
--	Jess	Rule-based	[44]
HEARFAID	Jena	Rule-based	[69]
EGADSS	C Language Integrated Production System (CLIPS)	Rule-based	[22, 47]
--	iLog Rules	Rule-based	[48]
--	--	Rule-based	[49]
--	SEBASTIAN	Rule-based	[56]
--	SEBASTIAN	Rule-based	[24]
--	--	Rule-based	[58]
--	Arden Syntax engine	Arden Syntax	[59]
--	--	Rule-based	[65]
SCP	OpenCDS	Rule-based	[73]
TRIACS	Triana	Triana workflow language	[51]
DeGeL/Gesher	Asbru engine	Asbru	[54]
MATE	Tallis	PROforma	[55]
COSARA	--	BPEL	[71]
--	--	SAGE guideline model	[58]
HealthFlow	Shark	XML Process Definition Language (XPDL)	[60]
--	--	BPEL	[64]

We identified a number of standards for presenting clinical guidelines, also referred to as guideline-modeling methodologies, namely GLIF, NewGuide, SAGE, Asbru, PROForma, Arden Syntax and rule-based standards (rule-based standards can be further refined by various rule languages – see table 5). We also found that BPEL and XPDL, which are typically used for businesses other than healthcare, are also used as a representation language in these systems. The systems listed in table 4 show different trends in adopting the use of the above mentioned guideline representation standards. This is shown in Figure 4.

Table 5.

Rule language used and publication reference

Rule language	Publication reference
Jess	[44]
Jena	[69]
CLIPS	[22, 47]
iLog	[48]
Drools	[73]
Not specified	[49]
Java	[24, 42, 56]
Not specified	[58]
Not specified	[65]

Fig. 4.

Number of systems per language type

It can be seen in Figure 4 that rule-based engines are popular among the developers and that the Business Process Execution Language (BPEL) is beginning to be adopted at a higher rate than clinical guideline representation languages. Additionally, table 5 shows that there is not a clear preference for a specific rule language.

3.2.5. Service choreography and orchestration

The final architectural approach from the reviewed studies that is evident in SOA based CDS is service choreography. In Web service choreography, each participating service defines its part in the interaction and services can interact directly with one another. Architecture closely related to Web service choreography is Web service orchestration. Unlike service choreography, in Web service orchestration (e.g., BPEL), the logic is specified by a single participant which is referred to as the orchestrator [35]. Web service choreographies describe the observable interactions between services from a global perspective, and none of the participants control the interaction. The survey suggests that choreography was only adopted by one research project (OpenKnowledge) [76, 77].

It can be inferred from the studies that all the architectural approaches described above can exist in multiple combinations within a SOA based CDS implementation. For example, in a setting where several healthcare organizations or units have to interact, service choreography can be used to describe the message-based interactions from a global point of view and service orchestration can be used to control the internal processes of each organization. Figure 5 describes a hypothetical scenario where all of these approaches can coexist among organizations A, B, and C. The SOAP-based interactions between the organizations are defined by the Web Service Choreography Description Language (WS-CDL) [78]. Organization C uses an orchestrator engine to deploy processes that define clinical pathways. These clinical pathways are developed based on clinical guidelines and according to the resources available in the organization. The ESB provides connectivity with other systems and monitors service interactions in order to detect health-specific patterns. Additionally, clinical knowledge is captured in the form of rules in the rule engine. The rules have the form: IF conditions THEN conclusion. These rules are integrated in the clinical pathways as tasks on the processes deployed in the orchestration engine. The private service registry contains information on each of the services available inside the organization and also provides a subscription mechanism in order to notify service consumers when a service is modified or updated. The public service registry maintains information about the services available between communicating organizations.

Fig. 5.

Example scenario: co-existence of multiple architectural patterns

3.3. Healthcare standards

It is a very well established issue that semantic interoperability is essential for SOA architectures [1]. Without semantic interoperability, service providers and service consumers cannot make use of the data exchanged. For example, a service that requires past patient diagnoses using a standard terminology will not be able to properly process diagnoses provided using local proprietary codes or free text. Thus, achieving semantic interoperability is an important goal when implementing SOA for CDS.

In order to obtain an accurate picture of how semantic interoperability is accomplished, we extracted and categorized all healthcare standards adopted or suggested by the reviewed studies. The overview below describes the standard categories, and table 6 lists the individual standards identified in the specific articles. The healthcare standards identified were categorized as follows:

Table 6.

Healthcare standards referenced by included studies

Focus	Name	Publication reference
Clinical guideline representation	GLIF (Guideline Interchange Format)	[38, 52, 68]
	NewGuide	[37]
	SAGE (Standards-based Sharable Active Guideline Environment)	[39, 58]
	Asbru	[54]
	PROforma	[55]
	Arden Syntax	[22, 47, 59]
	GELLO (Guideline Element Language, Object Oriented)	[41]
Patient information	vMR (Virtual Medical Record)	[23, 37–39, 41, 45, 62, 65, 66, 73]
	CCD (Continuity of Care Document)	[65, 73]
	OpenEHR	[40, 57, 66]
	CDA (Clinical Document Architecture)	[22, 40, 44, 47, 66, 68]
	CEN EN 13606-1	[40, 52, 66]
	HL7 v2.x and HL7 v3	[23, 57, 65, 73]
Web services and exchange of clinical documents	HSSP Decision Support Service standard	[24, 25, 42, 56, 62, 73]
	HSSP Retrieve, Locate, and Update Service standard	[24, 25, 62]
	HSSP Common Terminology Service standard	[24, 25, 62]
	HSSP Identity Cross-Reference Service standard	[62]
	HSSP Healthcare and Community Services Provider Directory Service standard	[62]
	Healthcare Information Technology Standards Panel (HITSP) SC109	[62]
	IHE XDS (Integrating the Healthcare Enterprise, Cross-enterprise Document Sharing) profile	[52]
	NHIN (Nationwide Health Information Network) standards	[23]
	IHE Query for Existing Data profile	[62]
	IHE Request for Clinical Guidance profile	[62]
Medical terminology	SNOMED CT (Systematized Nomenclature of Medicine - Clinical Terms)	[39, 40, 62, 65, 66]
	LOINC (Logical Observation Identifiers Names)	[37, 39, 40, 62, 65]
	ICD (International Classification of Diseases)	[37, 44, 62]
	CPT (Current Procedural Terminology)	[62]
	UMLS (Unified Medical Language System)	[62]
	HL7	[62]
	RxNorm	[62, 65]
Medical devices	ISO/IEEE 11073-10101 (Health informatics - point-of-care medical device communication - part 10101: nomenclature)	[52]

• Patient information standards: The objective of these standards is to document important patient information such as diagnoses, medications, and lab results. The HL7 Virtual Medical Record (vMR) was specially designed to integrate patient information with CDS systems [79].

• Medical terminology standards: These standards define a common terminology and vocabulary to be used in a healthcare domain. Some of these standards, such as the International Classification of Diseases (ICD) for diagnoses and LOINC for laboratory results, have been adopted internationally, whereas other standards, such as drug descriptions, have been adopted in specific regions (e.g., RxNorm in the United States and Anatomical Therapeutic Chemical (ATC) in Europe).

• Standards for Web services and exchange of clinical documents: Standards used for exchange of clinical information were grouped in this category. The HSSP Web service standards have been developed specifically to support SOA architectures. The HSSP project is a joint activity between HL7 and OMG [7].

• Standards for medical devices: These standards focus on the communication between medical devices and external systems.

• Clinical guideline representation standards: Most of these standards have been influenced by workflows and are based on XML syntax. Some of them allow the creation of XML-based clinical guidelines using a graphical editor. Comprehensive comparative reviews of some of these standards have been published elsewhere [74, 80, 81].

In summary, a large number of organizations have taken initiatives to develop and promote standards. This finding indicates a relative consensus on the need for organizations implementing SOA-based CDS to adhere to relevant standards in order to achieve semantic interoperability.

3.4. Challenges and lessons learned

In addition to the architectural and standards analysis, we also analyzed reported challenges and lessons learned during the development and implementation of SOA-based CDS systems. It is important to note, however, that many of the reviewed articles described planned future architectures and could not comment on actual deployment.

Lobach et al. reported an excessive time for data retrieval from the data repository, which slows down the CDS service considerably. They suggested introducing performance-enhancing strategies including multi-threaded data retrieval and pre-caching of patient data [42].

Wright and Sitting highlighted the problem of duplicate and conflicting data distributed in different systems [23]. They solved data inconsistencies, such as different values on vital signals, height, and weight, by using only the most recent observation. Other data points, such as medication lists, were semi-automatically reconciled.

Cucino and Eccher pointed out the lack of mechanisms for defining interactions with people within the BPEL process language [64]. They suggested using BPEL4People [82] in their future work in order to overcome this limitation. The authors of the HealthFlow system highlighted the difficulty in representing complex algorithms in graphical-based representations, such as the XPDL language [60]. The authors proposed two strategies to alleviate this problem and to simplify complex process flowcharts. First, they suggested adopting a hierarchical arrangement of scenarios where a node in a higher lever flowchart expands into a sub-flow, which may consist of multiple steps. Secondly, the authors suggested moving some of the logic into single rule-based nodes which call a comprehensive rule base or other expert system.

Paterno et al. reported that the main limitation of SOA-based CDS systems evaluated in their article is the long time required to receive a CDS response [65]. For future work, the authors suggest optimizing dependent services to speed up service response times and monitoring processes across hardware and software platforms to identify and study latency issues between services.

In summary, the reviewed articles reported the typical challenges of distributed applications. However, time of response seems to be the most critical aspect for SOA-based CDS systems. Some high risk clinical scenarios have little tolerance for latency.

4. Discussion

One of the main goals of the review was to identify the technologies and architectural approaches adopted for the development of SOA based CDS environments. We identified 44 studies that suggested or implemented service oriented CDS. The first studies in this area were published in 2004, with the most publications published in 2009. We discuss further aspects of our findings below.

4.1. Software architecture and development techniques

Point-to-point communication appears to be the current architectural approach of choice, whereas service choreography has been explored in only one project. A comparison of service choreography and service orchestration approaches revealed important results. In choreography, the services interact directly with one another, resulting in less overhead and delay. Using the orchestration approach, the interaction is controlled by one of the participant systems, thus increasing the time for communication [83]. It is important to understand this issue, as the speed of CDS result delivery has been identified as a key aspect in successfully implementing CDS in the clinical workflow [65]. However, orchestration allows simple Web services to perform their function without knowing they are participating in a high level functionality of the application. ESB is the architectural approach that is mainly used to integrate disparate applications, but only one study in our reviewed set [68] identified the event-driven features of ESB as a mechanism to provide CDS services. We believe that CDS should also exploit other features provided by the ESB, such as load balancing, service version selection, service selection based on message data, access control, and exception handling [32].

Similarly, the service registry has not been fully exploited. The main functionality of the service registry is to provide service descriptions, but it can also provide other useful functionalities, such as dependency management, event notification, access control, policy management, and federation [32].

Interestingly, none of the studies reported or suggested the use of Service Component Architecture (SCA), which is a set of OASIS [84] specifications specially designed to build distributed applications based on SOA. The SCA effort was started in 2005 by a group of vendors that includes IBM, Oracle, SAP, and others and handed over to OASIS in 2007. SCA represents the next step in the evolution of SOA, raising the level of abstraction and addressing two issues of software development: complexity and reuse [85]. Additionally, SCA hides the complexity of specifying security, reliability and other quality of service from the application code. Some of the open source SCA implementations include Apache Tuscany [86], Fabric3 [87], FraSCAti [88] and Red Hat Switchyard [89]. The use of SCA would facilitate developers of CDS solutions to follow SOA principles and best practices.

4.2. Business process languages and Web service specifications

Although there are several executable clinical guideline standards that are specific to the medical field, it appears that general-purpose business process languages, such as BPEL, are being used more often for executing simple clinical guideline logic. Interestingly, BPMN 2.0 [90], which has become the preferred standard for business process modeling [91], has not been used by any of the systems we reviewed. Unlike the BPEL language, BPMN supports human tasks, which was one of the reported challenges [64].

An essential aspect of SOA is semantic interoperability, without which service providers and consumers cannot make use of the data exchanged [1]. Efforts such as the HSSP project that provide Web service specifications that can be used to implement CDS represent a major step forward for achieving SOA for CDS. Examples of such HSSP services are the HSSP Decision Support Service, the HSSP Common Terminology Service, and the HSSP Retrieve, Locate, and Update Service.

4.3. HL7 initiatives supporting SOA use in CDS

We believe that providing common building blocks across various software vendors would greatly enhance current CDS capabilities of healthcare systems. Such common building blocks would enable greater use of SOA principles in CDS development. HL7 has a working group devoted to facilitating interoperable CDS that in the past helped developed several CDS standards, such as the Arden Syntax. In 2012, this workgroup identified 10 services and 8 capabilities as being desired for clinical information systems (CIS) to offer SOA-based CDS capabilities [62]. Examples of services identified as being desired are event subscription and notification, cohort identification and entity identification services; table 7 provides the complete list. As for the CDS capabilities identified as being desired, examples include use of standard information models and terminologies, the ability to leverage a DSS and the ability to leverage a unit conversion; table 8 provides the complete list. It is unlikely that current systems can support all of these capabilities and services. In both table 7 and table 8, we have included the SOA architectural approach identified in this review as an additional column that could enable this capability or service. We believe that these services and capabilities could be implemented combining SOA strategies such as ESB and business process management (BPM). We have extended the workgroup description of services with SOA patterns that could fulfill these requirements.

Table 7.

Services required from CIS to enable SOA for CDS identified by HL7 CDS working group (first and second columns [62] ) and SOA architectural approaches that can fulfill these requirements (third column)

Service or capability	Description, example use case, and relevant standards	SOA architectural approach that could enable this capability or service
Event subscription and notification service	Description: Publishes relevant CIS events, which can be listened to by a CDS system to trigger CDS. Allows systems to subscribe to specific types of event notifications. Use case: EHR system publishes events such as the entry of new labs into the clinical data repository, patients checking into appointments, and users logging into the system. CDS system subscribes to types of events that will trigger specific CDS processes. Relevant standards: CORBA event service and notification service; WS-Notification	ESB: The ESB facilitates integration of legacy systems and can provide content/topic-based routing capabilities which can be based on standards such as WS-Notification or WS-Eventing [92]. Examples of commercial and open source ESBs that support these standards: WS-Notification: Apache ServiceMix, IBM WebSphere, SwitchYard ESB WS-Eventing: WSO2 ESB
Cohort identification service	Description: Identifies a patient cohort (i.e., population) matching search criteria. The result returned is typically a list of identifiers for matching patients. Use case: A population health management system identifies patients with diabetes, hypertension, and congestive heart failure using an EHR system’s cohort identification service Relevant standards: None identified	ESB: The ESB provides adapters for several communication protocols and mechanisms to access databases. If the CIS does not support Web services, the ESB can provide this capability or directly query databases and return the list of identifiers for the matching patients.
Entity identification service	Description: Identifies whether there is an individual patient matching demographic search criteria (e.g., name, gender, date of birth). Also may be applied to identify other entities such as healthcare providers or facilities. Use case: A vaccine forecasting system identifies whether care organizations A, B, or C have data on a patient for whom a vaccine forecast has been requested. Relevant standards: HSSP Identity Cross-Reference Service standard	ESB: The HSSP identity Cross-Reference Service standard is based on XML, which is highly supported by the ESB. Therefore, legacy systems can provide this service through the ESB.
Clinical data query service	Description: Retrieves existing clinical data from clinical information system. Use case: Drug-drug interaction alert system retrieves patient medications from an EHR system. Relevant Relevant standards: HSSP Retrieve, Locate, Update Service standard. IHE Query for Existing Data profile.	ESB: These standards are based on XML which is supported by the ESB. Therefore, legacy systems can provide this service through the ESB.
Resource query service	Description: Retrieves data about local availability of material and human resources. Use case: Based on local availability of dialysis machine, refer patient to external dialysis facility. Relevant standards: HSSP Healthcare and Community Services Provider Directory Service standard; Wf-XML specification (http://www.wfmc.org/wfmc-wf-xml.html)	ESB: These standards are based on XML, which is supported by the ESB. Therefore, legacy systems can provide this service through the ESB.
Data acquisition service	Description: Retrieves data directly from users. Use case: CDS system asks user if patient is pregnant. Relevant standards: HSSP Retrieve, Locate, Update Service standard. Description:	ESB: These standards are based on XML, which is highly supported by the ESB. Therefore, legacy systems can provide this service through the ESB.
Data addition/update service	Description: Updates or adds data into a clinical information system. Use case: Health maintenance module updates EHR that patient had an influenza vaccine at grocery store on date X. Relevant standards: HSSP Retrieve, Locate, Update Service standard.	ESB: These standards are based on XML, which is supported by the ESB. Therefore, legacy systems can provide this service through the ESB.
Order placement service	Description: Places a clinical order. Use case: CPOE CDS module places a pending order for lisinopril 5mg PO QD. Relevant standards: None identified	ESB: The ESB provides adapters for several communication protocols and mechanisms to access databases. If the CIS does not support Web services, the ESB can provide this capability or directly query databases and return the list of identifiers for the matching patients.
User communication service	Description: Communicates CDS results with appropriate end users. Use case: A CDS system places a note in the EHR system’s alert inbox; CDS system provides a popup alert; physician is paged regarding urgent CDS finding. Relevant standards: None identified	ESB: The ESB provides adapters for several communication protocols and mechanisms to access databases. If the CIS does not support Web services, the ESB can provide this capability or directly query databases and return the list of identifiers for the matching patients.
Task management service	Description: Allows tasks to be added, tracked, and retrieved. Use case: A population health management system is able to distribute the tasks from a care plan to the task lists of various users. Relevant standards: Wf-XML specification (http://www.wfmc.org/wfmc-wf-xml.html).	BPM: This capability can be provided by a business process management systems based on workflow languages such as BPMN, which allows modeling of different sets of processes such as orchestration and collaboration and also extends the definition of human interactions[90]. ESB: The results of the BPM can be distributed to legacy systems through the ESB.

Table 8.

Capabilities required from CIS to enable SOA for CDS identified by HL7 CDS working group (1st and 2nd columns [62] ) and SOA approaches that can fulfill these requirements (3th column)

Service or capability	Description, example use Case, and relevant Standards	SOA architectural approach that could enable this capability or service
Use of appropriate, standard information models and terminologies	Description: Appropriate, standard information models and terminologies are used to instantiate data in the payloads of various services. Use case: A Clinical Data Query Service uses a standard information model to represent the data it provides. Relevant standards: HL7 version 2 and 3 messaging standards; HL7 Virtual Medical Record standard; IHE profiles; HITSP standards; OpenEHR templates; Detailed Clinical Models; SNOMED CT; LOINC; ICD; CPT; various others.	ESB: Mapping technologies such as XSLT are highly supported by ESB and can be used to map proprietary CIS terminologies and models using an external terminology server such as UMLS. BPM: The interaction between the CIS and the terminology service can be orchestrated using a business process management system based on business process languages such as BPMN.
Ability to leverage a DSS	Description: The CIS is able to use a DSS to obtain patient-specific care assessments and recommendations. Use case: The disease management module of an EHR system uses a DSS to obtain diabetes care recommendations based on national guidelines. Relevant standards: HSSP Decision Support Service standard; IHE Request for Clinical Guidance profile. Description:	ESB: The ESB provides adapters for several communication protocols and mechanisms to access databases. If the CIS does not support Web services, the ESB can provide this capability or directly query databases.
Ability to leverage a terminology service	Description: The CIS is able to use a service to fulfill terminology needs. Use case: A CIS uses a terminology service to convert internal laboratory codes into the LOINC codes required by a DSS. Relevant standards: HSSP Common Terminology Services 2 standard	ESB: The ESB provides adapters for several communication protocols and mechanisms to access databases. Thus, if the CIS is not able to call an external terminology service, the ESB can be used to deploy a micro flow that could perform the terminology Web service call and transform the request according to the requirements of the CDS service. BPM: The interaction between the CIS and the terminology service can be orchestrated using a business process management system based on business process languages such as BPMN.
Ability to leverage a unit conversion service	Description: The CIS is able to use a service to convert units. Use case: A CIS uses a unit conversion service to convert laboratory units used by the local CIS into the different laboratory units required by a DSS. Relevant standards: The Unified Code for Units of Measure (http://aurora.regenstrief.org/~ucum/ucum.html).	ESB: The ESB can be used to consume external services and convert the response to the data format and communication protocol supported by the CIS. BPM: The interaction between the CIS and the unit conversion service can be orchestrated using a business process management system based on business process languages such as BPMN.
Ability to leverage a data transformation service	Description: The CIS is able to use a service to render structured data into a human-readable format. Use case: The disease management module of an EHR system uses a data presentation service to convert an XML document representing diabetes care needs into an HTML diabetes management dashboard to be presented to a clinician. Relevant standards: W3C XSL Formatting Objects (http://www.w3.org/wiki/Xsl-fo)	ESB: The ESB can be used to consume external services and convert the response to the data format and communication protocol supported by the CIS. BPM: The interaction between the CIS and the data transformation service can be orchestrated using a business process management system based on business process languages such as BPMN.
Ability to leverage a data presentation service	Description: The CIS is able to use a service to render structured data into a humanreadable format. Use case: The disease management module of an EHR system uses a data presentation service to convert an XML document representing diabetes care needs into an HTML diabetes management dashboard to be presented to a clinician. Relevant standards: W3C XSL Formatting Objects (http://www.w3.org/wiki/Xsl-fo).	ESB: Data model transformation is one of the main functionalities of the ESB. Thus, this transformation can be performed inside the ESB using technologies such as XSLT.
Ability to populate a data warehouse in real-time	Description: The CIS is able to populate an enterprise data warehouse in real-time, as opposed to nightly batches. Use case: A healthcare organization builds CDS functionality against the data warehouse. Relevant standards: None identified.	ESB: The CIS can perform this task using the different database communication protocols supported by the ESB. BPM: The interaction between the CIS and the data warehouse can be defined using a business process management system based on business process languages such as BPMN.
Maintenance of audit logs	Description: The CIS maintains an audit log of all service interactions. Use case: A CIS maintains an audit log of data provided to, and recommendations received from, an external CDS service. Relevant standards: Healthcare Information Technology Standards Panel (HITSP) SC109.	ESB: Audit logs of service interactions are often part of the monitoring and management tools provided by the ESB [32]. Additionally, other technologies such as Business Activity Monitor (BAM) and Complex Event Processing (CEP), which are commonly used on SOA architectures, can also be implemented for this purpose [93].

5. Limitations

The search was limited to English-language articles published until the end of October 2013. Also, our review is based on published literature only, whereas there could be additional relevant CDS implementations that have not yet been described in the literature.

6. Conclusion

The great promise of SOA for CDS can be achieved more rapidly if best practices identified in other industries such as finance are adopted. Several technologies and methodologies have been developed around the concept of SOA, and they have the potential to enable a new range of opportunities for CDS. These include BPMN for optimizing clinical pathways and SCA for Web service composition. We also recommend that service choreography be further explored for use in SOA based CDS implementations.

Future work

One recommended focal area for future work is studying other industries and applying best practices from those industries when implementing SOA-based CDS. Another critical aspect that needs further investigation is improvement in the overall response time for real-time CDS. For integrated systems dealing with large amounts of patient data, improved response times could potentially be achieved through the incorporation of systematic approaches for estimating and planning for computational resource requirements based on prior utilization data. Furthermore, performance optimization techniques identified in this review, such as multi-threaded database queries and pre-caching of patient data, could be systematically applied to further optimize service response times and to enable real-time CDS.

Appendix A. ACM Digital Library

The search in the ACM Digital Library was performed on October 16, 2013 and four studies were obtained. Because of the options available in this database the search string had to be divided into the following two substrings:

ACM Digital Library

The search in the ACM Digital Library was performed on October 16, 2013 and four studies were obtained. Because of the options available in this database the search string had to be divided into the following two substrings:

Table. 1.

Search strings used on the ACM Digital Library database

Search string	Number of publications obtained
(Abstract:”service oriented” OR Abstract:”service-oriented” OR Abstract:”service based” OR Abstract:”service-based” OR Abstract:”service orientation” OR Abstract:”service-orientation” OR Abstract:”SOC” OR Abstract:”SOA”) AND (Abstract:”Clinical Decision Support” OR Abstract:”CDS” OR Abstract:”CDSS”)	3
(Title:”service oriented” OR Title:”service-oriented” OR Title:”service based” ORTitle:”service-based” OR Abstract:”service orientation” ORAbstract:”service-orientation” OR Title:”SOC” OR Title:”SOA”) AND (Title:”Clinical Decision Support” OR Title:”CDS” ORTitle:”CDSS”)	1

Compedex

The search in the Compendex database was performed on October 16, 2013 and 80 studies were returned. The search was conducted in the subject, title and abstract of all the databases available. The result was filtered by language, considering only studies written in English. The defined search is presented in the following table.

Table. 2.

Search string used on Compendex

Search string	Number of publications obtained
(((“service oriented” OR “service-oriented” OR “service based” OR “service-based” OR “service orientation” OR “service-orientation” OR “SOA” OR “SOC”) WN KY) AND ((“clinical decision support” OR “CDS” OR “CDSS”) WN KY)), English only	80

IEEE Explore

Since IEEE Xplore does now allow searching in the abstract and title in the same string, the search string was divided into the following two substrings. The search was performed on October 16, 2013 and 13 studies were returned.

Table. 3.

Search string used on IEEE Xplore

Search strings	Number of publications obtained
( “Abstract”:”service oriented” OR “Abstract”:”service-oriented” OR “Abstract”:”service based” OR “Abstract”:”service-based” OR “Abstract”:”service orientation” OR “Abstract”:”service-orientation” OR “Abstract”:”SOC” OR “Abstract”:”SOA”) AND ( “Abstract”:”Clinical decision support” OR “Abstract”:”CDS” OR “Abstract”:”CDSS”)	13
( “Document Title”:”service oriented” OR “Document Title”:”service-oriented” OR “Document Title”:”service based” OR “Document Title”:”service-based” OR “Document Title”:”service orientation” OR “Document Title”:”service-orientation” OR “Document Title”:”SOC” OR “Document Title”:”SOA”) AND ( “Document Title”:”Clinical decision support” OR “Document Title”:”CDS” OR “Document Title”:”CDSS”)	0

ScienceDirect

The search in ScienceDirect was performed on October 17, 2013. The title, abstract, and keywords were included and 12 studies were returned. The following table shows the search string and number of publications retrieved.

Table. 4.

Search string used on ScienceDirect

Search strings	Number of publications obtained
TITLE-ABSTR-KEY(“service oriented” OR “service-oriented” OR “service based” OR “service-based” OR “service orientation” OR “service-orientation” OR “SOC” OR “SOA”) and TITLE-ABSTR-KEY(“clinical decision support” OR “CDS” OR “CDSS”)	12

Scopus

The search in Scopus was performed on October 17, 2013 and 79 studies were retrieved. The following table shows the string used in this database.

Table. 5.

Search string used on Scopus

Search strings	Number of publications obtained
TITLE-ABS-KEY((“service oriented” OR “service-oriented” OR “service based” OR “service-based” OR “service orientation” OR “service-orientation” OR “SOC” OR “SOA”) AND (“clinical decision support” OR “CDS” OR “CDSS”))	79

Springer

The search in Springer was performed on October 17, 2013. The following table shows the string used in the Springer search engine.

Table. 6.

Search string used on Springer

Search strings	Number of publications obtained
(“service oriented” OR “service-oriented” OR “service based” OR “service-based” OR “service orientation” OR “service-orientation”) AND (“clinical decision support”)	118

We removed the terms “CDS” and “CDSS” from the search string because we obtained several not related studies (393). This is because Springer does not provide a search tool that could limit the search to the abstract and title; it does search in the whole content of the studies.

Web of Science

The search in Web of Science was performed on October 17, 2013 and a set of 48 articles was obtained. Since this database does not allow searching by abstract, the search was performed using the title and “topic”. The defined search string is presented in the following table.

Table. 7.

Search string used on Web of Science

Search strings

Number of publications obtained

Topic=((“service oriented” OR “service-oriented” OR “service based” OR “service-based” OR “service orientation” OR “service-orientation” OR “SOC” OR “SOA”) AND (“clinical decision support” OR “CDS” OR “CDSS”)) OR Title=((“service oriented” OR “service-oriented” OR “service based” OR “service-based” OR “service orientation” OR “service-orientation” OR “SOC” OR “SOA”) AND (“clinical decision support” OR “CDS” OR “CDSS”))

48

Total of search results

The following table shows the total of articles before and after removing the repeated studies.

Table. 8.

Combined search results

Database or search engine	Number of search results
ACM Digital Library	4
Compendex	80
IEEE Explore	13
ScienceDirect	12
Scopus	79
Springer	118
Web of Science	48
Combined studies	354
Repeated studies	216
Total of studies after removing repeated results	138