Received 9 November 2015; accepted 9 January 2016; published 12 January 2016
1. Introduction
Clinical Decision Support System (CDSS) consists of five basic elements-hardware, software, data, procedure, and stakeholder [1] -[3] . The first element, hardware, has shown phenomenal growth and is not a barrier anymore due to ever-increasing computing speed and memory at the lowest price [2] [3] . We can see CDSS to be available, at a variety of high-speed computing devices, such as desktop, laptop, personal digital assistant, mobile, and dedicated CDSS enabled device [4] [5] . The second element, software refers inference engine of CDSS [3] . In the last four decades, tremendous effort has been made to develop highly powerful and complex inference engines [3] [6] . The third element, data refers to input, output and knowledge base, which undoubtedly is seeing a revolutionary era of Big Data [7] [8] . Likewise, the fourth element, procedure to use, operate, and maintain the CDSSs has made significant progress and sufficient attention [9] -[11] .
Overall, we can see a proper amount of attention, as well as progress from the perspectives of hardware, software, data, and procedure. However, stakeholder’s perspective of CDSS has always been overlooked. Any system, whatever it may be, is considered as successful or challenged if it meets or does not meet the stakeholders’ need, and the same applies for the CDSS. The stakeholders are diverse and have different interests [12] . They compete for each other to safeguard their interest. Indeed, a stakeholder may be sufficiently concerned at the possibility of being exploited by the other stakeholder whom he/she chooses not to enter a deal [13] . Therefore, we argue, CDSS being several stakeholder’s systems; a good understanding of various stakeholder’s interests is utmost crucial to its success. The next section describes the CDSS from various stakeholder perspectives.
2. Stakeholder’s Perspective of CDSS
As shown in Figure 1, CDSS stakeholders typically include: 1) end-users (physician, nurse, laboratory technologist, pharmacist, patient), 2) sales and marketing team, and 3) CDSS product development and maintenance team (system administrator, system developer, system architect, project manager, and system maintenance staff).
2.1. CDSS Product Development and Maintenance Team
CDSS product development and maintenance team typically involve product owner, project managers, system architect, system designers, system developers, system administrators, and system maintenance team.
2.1.1. Product Owner
The CDSS product owners’ goal is centered around feature, cost, and schedule of CDSS product. They are further explained in the following paragraphs.
Features: two criteria that need proper consideration while developing CDSS is: 1) to identify features of CDSS that are critical to improving clinical practice, and 2) to make sure the CDSS product does not miss the desired feature. These criteria determine the acceptance and use of CDSSs in clinical practice. According to Standish Survey Research Group, out of 2000 projects, only 28 percent projects succeeded outright, 23 percent were canceled, and the remainders were substantially delayed, over budget, lacking features, or very often, all of those issues combined [14] . Lacking product features is a very common phenomenon in the past, customers of CDSS must verify feature before they accept it.
Cost: development costs associated with clinical decision-support programs are substantial. The recent data shows that despite several years of research and huge expenditures on medical diagnostic systems, we cannot find many CDSS in use [14] -[16] . It becomes crucial for a product owner to identify and quantify the tangible and intangible benefits of the CDSS product before its development. Product owner performs cost/benefits analysis (return on investment, break-even point) before any investments. Unlike other systems, CDSS cost/ benefits analysis is not as easy as intangible benefits are more than tangible benefits. People have tried to quantify these tangible and intangible benefits utilizing various indirect means, such as reduction in length of stay in hospital, number of outpatient visits, unwanted adverse quality outcomes (mortality rates, morbidity rates, infection rates, and readmission rates), adverse drug events, waiting times for service, and so on.
Schedule: developing CDSS within a time schedule is not so easy due to the dynamic nature of some of its components, such as knowledge base, rule engine, and so on. Knowledge base evolves in years as clinical decision support (CDS) systems must rely on knowledge that originates from a variety of changing sources. Selecting the sources and integrating this knowledge into a functional system are not trivial tasks [15] [16] . It becomes utmost difficult to predict the schedule in such a case.
2.1.2. System Architect
Major factors that limit the full adoption CDSS are 1) lack of a common and portable base of clinical knowledge, and 2) CDSS interventions that can be easily and widely used in Electronic Health Records (EHR) and Clinical Information System (CIS). Largely, non-standardized and independent approaches to creating and presenting clinical knowledge and CDSS interventions severely limit incorporation, reusability, and interoperability in clinical information systems [17] . There is no an explicit central vision for a suite of CDSS-related standards that will lead to the widespread and effective use of CDSS interventions. The available CDSS standards (for example, Arden Syntax) are neither widely deployed, nor address pertinent implementation challenges [18] [19] . Therefore, CDSS architect is the highly responsible stakeholder in determining success or failure of CDSS. The earlier CDSS architecture, such as MYCIN of the 1970s was complex to use, and monolithic in structure [20] . Monolithic systems are: a) unique to clinical domains and are costly to develop and maintain, b) closed loop that is not designed for easy integration with other systems, c) tightly-bound to the requirements of the clinical domain that they service. It would be easier to write an entirely new application than to reapply the functionality [21] .
To surmount the monolithic CDSS problems’ maintainability, reusability, flexibility clinical decision support systems, developers started resorting to the layered architecture. They started the use of standards to represent, encode, store and share clinical knowledge (one layer) and separate it from the code that implements the clinical information system (second layer), thereby provides a method for sharing the content of decision support. However, this standards-based approach has some inherent limitations, and disadvantages. First, there are often too many standards to choose from several dozen standards are available to represent simple alerts and reminders. Second, any encoding standard inherently constrains what a user can encode in the standard to that, which the standard writer intended and included in the scope of the standard.
In recent years, ICT people have come up with one more architecture called Service Oriented Architecture (SOA). It seems that modularity of SOA will allow all the benefits of monolithic and standard based layered architecture without their inherent limitations of non-portability and limited range of representable knowledge. The research shows that SOA has possibly a number of advantages over monolithic and layered architectures of CDSS.
2.1.3. Project Manager, System Designer, and System Developer
Project manager, system designer, and developer work closely as a team in consultation with CDSS architect. The project manager tracks the project that includes schedule, productive use of resources, and budget. The system analyst/designer gathers CDSS requirement and develops a conceptual model of the CDSS. The developers are responsible for CDSS implementation and testing. All these people, most of the time, lack healthcare domain knowledge. The CDSS products produced by the development team do not meet the end-user requirements. As the healthcare domain is a complex system, explicit expression of CDSS requirements is an overwhelming task. Therefore, it is highly desirable that one person in the development team should have the medico-techno background to bridge the gap between end-users’ requirement and product design. However, getting a person with a medico-techno background in the team is a challenge.
2.1.4. System Administrator
The system administrator is concerned with the administration, and tools to aid monitoring CDSS. The duties of a system administrator vary from organization to organization. System administrators are supposed to install, support, and maintain servers and other computer systems. They are also expected to respond to service outages and other problems.
2.1.5. System Maintenance Team
The maintainer is concerned with 1) a comprehensible, consistent, and documented design, 2) the ease with which modifications can be made, 3) how the knowledge underlying the rule will be maintained and updated, 4) how the rule will be encoded or interfaced with the application that will use it, 5) how it relates to other rules, 6) how it can be deployed in other applications or other system platforms with different programming languages, architectures, and developer’s convention, and 7) how knowledge and CDS approaches, which are found to be effective can be broadly disseminated and used.
2.1.6. Sales and Marketing Team
The CDSS marketing team is mainly concerned with product, price, promotion, and place along with affecting environmental factors, including social, cultural, economic, technology, competition, ecological, political and legal. Though the decision support system has been implemented across various application areas, however, a successful decision support system implementation is still nascent. CDSS market is still emerging and undergoing through the trial phase. The failed deployment in the past has deterred the adoption of the CDSS [22] . Clinical decision support has become an integral part of healthcare delivery. Healthcare stakeholders need to monitor this sector closely if they wish to gain competitive advantage.
Marketing personnel have to understand the CDSS products, its need, features and their position with other products if they want to penetrate the market. For example, they need to understand what kind of CDSS products are being used by doctors, shortcomings of the existing product, and so. They, somehow, need to prove that a new upcoming product is superior to the existing products. Customers, especially medical professionals, are very reluctant to change due to highly busy life. Moreover, newly software products need a considerable time to learn. Whenever a new CDSS product comes to the market without significant changes in features, as well as prices, very few chances exist that customers will accept the new CDSS product. Therefore, marketing personnel have to decide the competitive price and approach to pricing, for example; some firms believe in a subscription model, while others have chosen a one-time pricing strategy that covers the buyer for a fixed period [23] [24] . At times, it happens that CDSS with useful features at a reasonable cost may not get accepted by the users as they are so used to existing product, even though existing product might have fewer features and higher the new arrival in the product line. In such case, various promotion strategies like coupons, sample, partnerships, and sponsors are adopted by CDSS marketers. The CDSS product needs to be customized as per the place. CDSS developed in Europe will have different features than the USA. Marketing guys also decide the mode of delivery. The preferred mode is to upload to server and client download from its site using the Internet.
2.1.7. End-User
Physician, nurse, laboratory technologist, pharmacist, and patient are the primary users of the CDSS. All of them have their expectation with CDSS-some met and some unmet. CDSS should behave as per user expectation. Users want a product that does what they need to be done [25] . One out of five ICT (Information and Communication Technology) projects is likely to bring satisfaction, which is very true in the case of CDSS [26] . In July 2007, the head of the National Health Service Department in Britain stated that he was ashamed of some of the ICT systems developed during his period. The developed systems were unusable because they were built without listening to what end-users want. The computer science domain lacks the methods and tools to represent the complexity of user tasks, the contexts and sets of information and knowledge that must be harvested for context relevant information push and pull in health care. Further, health ICT system vendors lack the skills, tools, and probably the financial resources to create truly useful systems for clinicians. As physicians are awfully busy people in this world, they cannot give much time to learn things that seem to be out of the track from their routine work. Therefore, CDSS should have an appeal to understand or know it immediately without needing much thinking and learning.
Usability is important component demanded by the end-users. Medical computer systems that take usability into consideration allow users to improve clinical productivity effectively and efficiently while promoting positive feelings of satisfaction. CDSS shares similar usability issues as other applications and raises unique user concerns [27] . In other words, very simple and intuitive user interface is very much desirable. The history of CDSS reveals that the poor interface design is one of the leading causes of the failure or low adoption of CDSS. In the CDSS, the outcome of the system is directly related to the user interface. A successful CDSS should offer a user-friendly interface to clinicians to get the most proper consultation results [28] .
The performance of CDSS is non-functional expectation of the end-users. For example, if a CDSS takes a longer time than the users’ willing to wait, the system is considered as failed to perform even though it eventually gives a support. Similarly, other non-functional expectation from the CDSS is reliability. The reliability of a system is commonly defined as the ratio of the amount of time the system is truly available (during the time it is expected to be available) to the amount of time; the system is supposed to be available. Less than 99% reliable are typically considered as bad. For example, suppose a system is functional for a year with 99% reliability, it was down, on average over eighty-seven hours annually [26] . This system would be considered as non-reliable. Over the past few years, we can see increased awareness of the data privacy and security in the healthcare sector. Healthcare decision support systems comprise of large volumes of sensitive data; therefore, a high degree of data protection should be ensured. Protection of highly confidential patient data is subject to international regulations. Issues of privacy, software regulation and ethical and legal aspects of data processing in healthcare may build primary sources of conflicts [29] .
3. Conclusion
CDSS has been accepted as a revolutionary idea in the field of medicine. However, to date, their success is not encouraging despite pumping in a huge effort, as well as money. Several challenges along with potential reasons have been identified. We found that CDSS involved diverse competing stakeholders. And CDSS challenges have risen because these various stakeholders have different interests and asymmetric information―some having more interest or information than others. Moreover, their interests are not aligned with a common goal. Therefore, before embarking on any CDSS development, stakeholders need to be considered seriously, and interests of various stakeholders can be brought into line with CDSS objectives.