PDF
ePub
Citation
Print
I. Introduction
Although in healthcare post-treatment service is generally important, patients with post-treatment conditions often have limited access to physicians due to location, time, and availability constraints. Lack of time during a visit to a doctor and the infrequency of subsequent visits to the doctor are perceived as important barriers to communication and effective healthcare outcomes, particularly regarding chronic diseases and satisfaction [123] implying a need for more effective post-treatment follow-up services. Likewise, public health crises, such as opioid addiction and antibiotic ineffectiveness, can result from excessive or unnecessary repeat prescriptions and uninformed self-medication choices, resulting not just in poor healthcare outcomes, but in poor value from a cost–benefit perspective [4]. In countries where treatments are not fully insured or covered by national policies, lower-income patients may drop out of necessary treatment regimes, or they may be unaware of lower cost alternatives.
Mobile health (m-Health) broadly refers to a mobile service or application for providing effective healthcare support to anyone, anytime, and anywhere [56]. Utilising mobile phone, GPRS and Internet technologies, m-Health provides health professionals, patients, clinicians and other relevant users with support services to manage, disseminate, collect, administer, control, and monitor healthcare information and improve health service delivery and quality-of-care support. In this study, to ensure the potential usage of healthcare data, a follow-up support is designed utilising a contextual view that integrates perspectives of who, what, where, and when, in that ‘who’ defines the target patients/users (to deliver patient-specific care support), ‘what’ defines a patient's conditions (representing what disease or medical conditions the patient has), ‘where’ defines the geographic location of a patient, and ‘when’ represents the times and dates that are important for maintaining the follow-up support service. Our objective can be informed through the “smart environment in the health context” defined in the STARR Project in which the aim is to interact and exchange information with users to provide them with automated, customised, and comfortable services [7].
The service provided by various m-Health information systems (IS) applications, eliminates geographical and temporal constraints, while enhancing coverage, quality, and cost savings [8]. As a sub-class of IS, Clinical Decision Support Systems (CDSS) are a type of specialised DSS application that directly aids in clinical decision making in which the characteristics of individuals are matched to a computerised knowledge base for the purpose of generating patient-specific recommendations [9]. Combining these, mobile-based decision support applications have been developed for supporting decision making in clinical and non-clinical settings.
In follow-up care, systems addressing a number of other specific chronic diseases, such as human immunodeficiency virus (HIV) and cancer, have been developed. These have involved approaches such as virtual interviews [10], and web-based medical records analysis, along with specific systems for breast cancer follow-up [11] as well as the management of cardiac conditions, HIV, and tuberculosis [12]. Piette et al. [13] investigated automated calls for diabetes monitoring, while Singh et al. [14] and Green et al. [15] focused on systems for cancer screening follow up. More widely, Epping-Jordan and her colleagues introduced the Innovative Care for Chronic Conditions (ICCC) framework for designing healthcare systems at patient, organisation, and policy levels, and internationally effective models for the ongoing management of pharmacotherapy were considered by Bjorkhem-Bergman et al. [16], including tools for following up the use of medicines along with communication and education strategies.
Although an abundance of m-Health tools are available to increase the health literacy of users, there is a lack of theory-based m-Health tools to increase users' engagement [17]. While the Internet as a platform is useful for altering the ways that people manage their health issues, the low health literacy of people becomes a barrier to understanding the medical information given and subsequently following instructions. Effective m-Health applications have great potential to improve users' health literacy and thus improve patient health. Studies have shown that, through the use of m-Health tools, additional communication and support for those who have low health literacy can enhance confidence and quality of life while improving their self-management ability for better health outcomes [18].
Despite the individual value of specific tools, there is little evidence of attention to design of appropriate DSS, or of any framework to inform such a design. Design science research implies that a mobile-based decision support development design, if researched and reported as such, can suggest general principles to inform similar designs. To the extent that chronic diseases require ongoing management, albeit with the unique characteristics of each, there is a need for a solution framework that can guide the rigorous development of effective decision support systems that are relevant to real physician and patient needs.
II. Methods
A socio-technical design philosophy is appropriate for accommodating the design reality in this study. Socio-technical design enables a complex process that includes interaction between the technical and social systems to encompass the design contexts and real requirements of user groups [19]. From a critical perspective, Carlsson [20] argued that information system artifacts can be described as ‘socio-technical systems‘ rather than just ‘technology oriented systems‘ and that design research should develop practical solutions and relevant knowledge. It is important that any design study should follow holistic analysis for capturing the context and relevance of artifacts explicitly. This motivates our general research question: How can we better conceptualise a new artifact (follow-up DSS) to effectively accommodate its contextual usage?
Orlikowski and Iacono [21] restored a focus on the IT artifact, and they suggested five meta-categories covering its various information systems conceptions, namely, tool view, proxy view, ensemble view, computational view, and nominal view. Of these the ‘ensemble view‘ focuses on ‘interactions between people and technology‘ [21], which comprises technologies embedded in the system of use. This view of an information system solution artifact establishes a significant trend on information system solution development research as Orlikowski and Iacono observed (p.131). This is because most IT artifacts are inevitably embedded in a physical or social setting.
Following this artifact design view, we outlined the below design process following the design science research (DSR) paradigm described by Hevner et al. [22]. The framework balances both knowledge-based rigour and contextual or problem environmental relevance. We followed a cyclical iterative strategy for the evaluation of our findings with health professionals (specifically, doctors). Furthermore, we engage in theory-building to develop a design model [23] based on the developed artifacts and the applied research process. In accordance with Gregor and Jones's [23] vision, we approach artifact and design theory as complementary outcomes of design science research. The design science research setting and its interrelated research cycles are depicted in Figure 1.
To begin, the relevance cycle connects the artifact development of the design cycle with its intended environment. It enables researchers to gather requirements to describe and later solve relevant problems and also to introduce artifacts to the environment. The rigour cycle relates the design cycle to the existing body of knowledge. Therefore, it informs the design activities and eventually enables the assimilation of the research findings by the knowledge base. Finally, the design cycle is the central part of design science research, and it consists of the iteration of artifact development and evaluation. An artifact is iteratively constructed and evaluated, culminating with the output of a solution for the problem.
Our overall DSR process therefore consisted of three design science research iterations as summarised in Table 1. These culminate in an evaluated and relevant IT artifact and a rigorously documented theory, which becomes part of the body of knowledge and practice, potentially informing subsequent design/research projects. Details of these iterations are presented in the following subsection.
1. Artifact Design Iteration
In the relevance cycle, several interviews with doctors and patients provided the validity of the problems and possible impacts on patients' benefits from the proposed solution. In the rigour cycle we identified knowledge relevant to the development of an innovative approach to communicate and follow-up patients during the post-treatment period. We determined that adoption and acceptance is a general issue and sought a solution approach that would address this. The literature reviewed in this cycle [24] suggested care quality improvement can be driven by publishing doctor ratings in user-friendly terms, and if done by hospitals themselves, it helps build trust and obviates third-party rating services, whose methodology may not be appropriately contextualised and may not allow the right of reply. In the design cycle, we constructed the follow-up CDS, and then constructed the health professional rating system (HPRS) to incentivise physicians based on ratings, and aimed at motivating physicians to adopt. Although doctor-rating systems are now beginning to emerge (e.g., California's CPHI [25]), which help patients to choose among doctors, we found no studies around incentivising physicians based on reputation ratings. Therefore, the idea of a user-based HPRS emerged as a possible starting point to motivate physicians to provide better service and to motivate patients to actively seek involvement in effective ongoing care.
To evaluate the initial concept, we held a workshop as part of the relevance cycle. The participants of the workshop were two managing directors of a hospital, two employees of the IT department of the same hospital, two physicians, two patients/users, and two of the authors. The workshop followed the general brainstorming method, consisting of two phases.
(1) Generation phase: In this phase ideas about requirements were collected. Each participant formulated ideas, and each idea was gathered without judgment.
(2) Evaluation phase: The gathered ideas were discussed, categorised, and merged when appropriate. Ultimately, the participants collectively came to an agreement on a finalised list of requirements.
The brainstorming process was applied using two different questions:
(1) What requirements for a follow-up CDS could effectively solve the problem of limited time to discuss or clarify medical information in any depth in the post-treatment period?
(2) What follow-up CDS requirements could motivate and incentivise physicians to provide better service?
In total, five general requirements were identified for the follow-up CDS (Table 2). Therefore, we started with a rigour cycle to identify input knowledge for follow-up CDS development. We then analysed different data analysis methods for the HPRS to be implemented within the follow-up CDS. To verify that the requirements of the adapted concept and the follow-up CDS were fulfilled, we held a second workshop with the same participants. In due course, the concept and the follow-up CDS were substantiated to have fulfilled all previously defined requirements, allowing for continued engagement of the third iteration of our DSR process. This design sequence is detailed further in Section IV.
2. Iteration 3: Evaluation and Publication
For the follow-up CDS it is important to evaluate artifacts in a real-world environment, i.e., in their intended fields of application. Therefore, we carried out a field test in the relevance cycle. We implemented the follow-up CDS and tested its information dissemination feature for patients/users. Overall, the follow-up CDS showed improvements in time and effort by patients to discuss or clarify medical information in the post-treatment (follow-up) period. Subsequently, we addressed the iterative design theory building process within our overarching design science research process.
Having outlined our methodology we now turn to the specific artifact details themselves.
III. Results
1. Solution Artifact Design and Evaluation
Our artifact, the follow-up CDS system, is a particular class of DSS, i.e., a communication-driven DSS [26], which simultaneously provides direct advice/answers and incidentally increases health literacy. There is, however, debate on how far m-Health apps conform with the requirements to provide the best communication experience to users [27]. In designing an m-Health platform, two-way communication and personalized contents were found to be useful for improving user engagement [28]. Following the CDSS fundamentals [29], the proposed CDS artifact handles the exchange of electronic suggestions regarding such topics as drug doses, routes, and frequencies. Decision support performing drug allergy checks, drug-to-drug interaction alerts and any other alerts, such as alerts for sugar checks, or drug guidelines has been considered vital for various specialisation fields of treatments, such as cardiology. The proposed CDS artifact is designed to capture patients' specific details and test results for storage and subsequent presentation to physicians at the appropriate time. The system also generates various patient-specific, evidence-based reminders and alerts for physicians. However, despite these potential benefits, the proposed CDS in the form of a communication CDSS would not be providing patient-specific recommendations.
The proposed CDS is based on an m-Health technique that adopts a HPRS to be used by patients/users to motivate physicians to provide better service via incentives or bonuses as a key input. The HPRS concept was developed as part of the follow-up CDS development. The HPRS makes the follow-up CDSS more reliable because more ratings by patients/users provide more incentive to the physicians to establish a good reputation and more validity to inform other patients' choices. The proposed model of the follow-up CDS consists of three parts (Figure 2): the follow-up CDS, software coding, and the HPRS. Figure 3 shows screenshots from the prototype interface.
The initial input for the follow-up CDS is an input screen (Figure 3) where the user asks question (input data) or starts a communication. Based on the question category, an index of recommendations of health professionals or physicians is shown from which the user starts communication for decision support.
The index of recommendations shows who has better ratings for providing post-treatment service. The rating is done by the patients/users after the physicians submit data for information dissemination for decision support. The user employs four parameters (empathetic, punctual, listening, and explaining) to rate a response by a health professional or physician. Eventually, a user is able to choose available physicians based on the total recommendations generated by rating points.
As seen in Figure 2, the proposed CDS solution utilised a back-end system for communication through a cloud-based web server for data processing and data storage. The emergence of cloud computing enables an affordable, configurable, and scalable information service platform that offers better e-Health solutions and possible connectivity, for example, by linking medical information and practitioners who are geographically located in different places as well as enabling online communication about medical issues, diagnosis, and treatment [303132]. Cloud computing goes beyond the traditional ICT service model by providing online computing services on-demand for customers over any network in a self-service fashion, which is suitable to healthcare needs. For example, Hu and Bai [33] mentioned that cloud computing adopts a service-oriented architecture for the functionalities of an integrated e-Health system as a number of interoperable software services.
In our last research cycle, the follow-up CDS was evaluated within its intended field of application using the DSR principles. Although the core functions of design science are based on design and evaluation knowledge, the evaluation methods and its relevant knowledge have not been developed at a similar scale of design conceptualisation and related knowledge. Some studies have focused on evaluation matters specifically in design science. Extending the original paper by Pries-Heje et al. [34], Venable et al. [35] presented a framework for evaluation in design science (FEDS) to assist researchers in developing a strategy for artifact evaluation. The FEDS helps explore answers of why, when, how, and what to evaluate in a DSR project. Using this framework, we evaluated the prototype of the follow-up CDS through criteria such as efficacy, understandability, ease-of-use or simplicity, consistency, and fit to organizational context. When implementing the follow-up CDS for a targeted hospital patient group, the main aim of our proposed evaluation strategy was to capture views of patient and healthcare professionals as users in receiving and providing on-demand service (e.g., consulting with patients). According to DSR literature, a solution artifact must be evaluated, particularly for software use, by end users to demonstrate its value with evidence addressing a set of relevant criteria, such as the validity of the artifact as well as its efficacy, benefits, and efficiency [36]. To conduct as evaluation involving experts, more insights for further development can be achieved; through interviews with users, it is possible to gain insights regarding system usability. Therefore, we utilised unstructured questionnaires, informal observation, system logs, and/or alternative approaches to gain insights from the targeted user group.
We utilized the protocols of the convergent interview technique [37] for conducting interviews with five physicians before conducting two confirmatory focus group sessions (using the procedures of Tremblay et al. [38]). These discussions assured us of meeting the respective demands. According to Osterle et al., [39], acceptance or rejection of an artifact depends on how it has been justified or judging the implementation outcome. Therefore, we conducted two-stage acceptance testing to ensure sufficient research attention on artifact evaluation. The convergent interview outcome can be viewed as positive indicators, shown in Table 2.
The comments (Box 1) indicate that the proposed CDS solution is a physician-led but patient-oriented approach for healthcare support service. Table 3 presents an example focus group outcome.
Based on the comments from the expert physicians it can be concluded that the perceived value of the proposed CDS artifact is high, and it has good potential for future operationalisation. To evaluate the fulfilment of RQ1, RQ2, RQ3, and RQ4, we analysed user feedback and monitored the number of users and health professionals using the mobile version of the follow-up CDS. Regarding RQ5, the expert interview findings showed that health professionals are interested in receiving incentives through achieving more ratings from users.
IV. Discussion
This paper described a new IT artifact design and its evaluation using a socio-technical methodological design view, which incorporated system, technology, people, and their interactions. A need was identified to improve the provision of follow-up care to patients in a climate of fewer doctors and reduced time for in-depth consultations and advice. This need was substantiated as relevant to healthcare practitioners and patients, and operationalised into general requirements for a decision support system. This research was based on the premise that m-Health technology enables patients to become more informed, empowered, and active participants in the process of clinical decision making, thereby helping improve their health condition, and creating a stronger, more user-centred patient–doctor relationship. A mobile platform was seen as the basis for an innovative solution, involving an app designed to provide ongoing advice and education to patients on-demand, saving time for patients and doctors alike. An easy-to-use rating system was incorporated, which was designed to inform patient choice, and to incentivise adoption by practitioners. The system was prototyped, refined, and released publicly before evaluation. The results confirmed increased efficiency in reducing the time of patients/users to start a consultation or communicate in the post-treatment period, and positive evaluation by doctors for incentivization provided by the ratings system. User friendliness was a guiding design principle because patients may have poor health literacy and poor skill in analysing ratings reports [24].
Our user-generated data are hosted in a rented cloud, which acts as a platform-as-a-service (PaaS). This platform provides us freedom of application design, application development, testing, deployment, hosting, application service integration, database integration, security, data scalability, storage, data backup, data conversion, and persistence. To ensure ‘data security’ the cloud provider employs redundant servers and routine data backup processes; however, we also keep routine backup from our side. On the other hand, the cloud provider also ensures ‘data integrity’, which means that our data are protected from unauthorised deletion and modification as well as misinterpretation. Data integrity ensures that the intended data is correctly retrieved by the intended users whenever required. Together with hospital policies on the security and privacy of patient data, the cloud platform ensures scalability and potentially global usage.
In this paper, we attempted to further apply our previous DSS design understanding in the public healthcare domain. Some of the limitations to this work suggest directions for further research. The prototype was developed and tested in Bangladesh, which has a critical shortage of doctors. Although many other regions have similar issues, cross-cultural testing and design adaptation should be investigated. Although operational viability has been established, more systematic evaluation on a larger scale will suggest further refinements to the design as well as useful functions that may be added, such as location analytics, video consultation, and perhaps text mining to establish common questions, model responses, and the like that can be partially automated or used to filter queries intelligently.
XML Download