Design Concerns for Multiorganizational, Multistakeholder Collaboration: A Study in the Healthcare Industry

ABSTRACT

Multiorganizational, multistakeholder (MO-MS) collaborations that may span organizational and national boundaries, present design challenges beyond those of smaller-scale collaborations. This study opens an exploratory research stream to discover and document design concerns for MO-MS collaboration systems beyond those of the single-task collaborations that have been the primary focus of collaboration engineering research. We chose the healthcare industry as the first target for this research because it has attributes common to many MO-MS domains, and because it faces significant challenges on a global scale, like the recent COVID-19 pandemic, for which MO-MS collaboration could offer solutions, as, for example, evidenced by the rapid collaborative development and distribution of COVID-19 vaccines. To this end, we reviewed 6,609 articles to find 100 articles that offered insights about the design of MO-MS collaboration systems, then conducted 50 semi-structured interviews in two countries with expert practitioners in the field. From those sources, we derived an eleven-category set of design concerns for MO-MS collaboration systems and argue their generalizability to other MO-MS domains. We offer exemplar probe questions that designers can use to increase the breadth and depth of requirements gathering for MO-MS collaboration systems.

KEYWORDS:

• multiorganizational collaboration
• multistakeholder collaboration online collaboration
• design research
• collaboration engineering
• healthcare

Introduction

Over the last decades, organizational tasks have become more complex, calling for a diverse set of skills while at the same time requiring deep expert knowledge. Consequently, effective teamwork has become a necessity of organizational success in many areas. Collaboration engineering (CE) has emerged as an approach to designing collaborative work practices for high-stakes tasks, and transferring them to practitioners to execute for themselves without ongoing support from collaboration experts [21, 22]. In 20 years of scientific inquiry, the preponderance of CE research has focused on the design, implementation, and optimization of single collaborative work practices for distinct tasks in homogeneous organizational environments (e.g., [9, 21, 42]).

Today, we see a challenging class of collaboration emerging wherein multiple stakeholders who may be in multiple organizations must execute suites of interdependent collaborative work practices. Such multiorganizational, multistakeholder (MO-MS) collaborations happen in various areas including disaster relief [60], joint business ventures [45], the public sector [39], and healthcare [77]. Different stakeholders may have different, possibly conflicting interests, and each may take different roles in the different phases of different tasks. MO-MS collaboration often introduces differences of cultural expectations and norms, terminology, rules, standards, policies, regulations, laws, language, procedures, data models, politics, and time zone, to name but a few. This may magnify the challenges of, for instance, building shared awareness and shared understanding, which could in turn produce less-effective communication, worse decisions, and worse results. The added complexity of MO-MS collaboration may raise additional design concerns for collaboration engineers. It is therefore useful to discover and codify design unique to MO-MS collaboration.

In this study, we turn to the healthcare industry as a prime example for MO-MS collaboration as it yields high potential for MO-MS collaboration systems to play a major role in helping to mitigate global challenges. For example, across the world, the spread of Coronavirus disease 2019 (COVID-19) caused by the SARS-CoV-2 virus has led to a global pandemic accelerated by factors such as overpopulation and increased global travel. The COVID-19 pandemic posed several complex challenges to the global community that require solutions produced by MO-MS collaboration teams. In particular, highly effective vaccines were developed at a record time, which was only possible due to effective collaboration between various organizations such as research institutes, pharmaceutical companies, healthcare providers, and government institutions [77]. In addition, international collaborative clinical trials to find effective treatment for COVID-19 have been launched (e.g., the “Solidarity” trial includes 500 hospital sites in over 30 countries [76]). However, the healthcare industry faces other severe challenges beyond the current global pandemic that may be addressed by MO-MS collaboration. In the last years, we have seen a constant increase in the rate of chronic diseases due to aging populations [75] or more sedentary lifestyles [74]; one in three adults worldwide now lives with multiple chronic health conditions [34]. Furthermore, even as global demand for medical services increases, per-capita medical resources in many parts of the world are declining, leading to shortages of medical resources such as medicines and healthcare professionals [4]. Even though global spending on healthcare is expected to increase by more than 130 percent within the next 20 to 25 years [25], approximately half the world’s population will not have sufficient healthcare services [68]. MO-MS collaboration in healthcare, though, can help to tackle these challenges. For example, the London Cancer Alliance which consists of 14 health organizations in England reported substantial improvements in service availability by consequently performing collaborative work practices. In only two years, they were able to increase the number of completed holistic need assessments (i.e., a standardized procedure to identify a patient’s concerns and develop a personalized plan for care and support) for cancer patients within 31 days of diagnosis by more than 500 percent (from 487 to 2646) [17].

Extant research has widely acknowledged the inherent value of MO-MS collaboration and resulting partnership synergies in healthcare [47]. However, often a gap between policy visions and actual implementation exists [43]. The potential benefits of MO-MS collaboration are rarely realized, for example, due to a lack of infrastructure supporting the primary functions of collaboration (i.e., Coordination, Communication, Cooperation) [2, 58]. These and other deficiencies impede collaborative activities, causing serious consequences. Such consequences can include medical errors due to misunderstandings that result from incomplete information and inadequate communication [26]. To address these issues and guide designers of large-scale MO-MS collaboration systems, we seek to identify and formalize design concerns that are applicable to collaboration in MO-MS contexts. Thus, this study explores the following research questions:

Research Question 1 : What are the design concerns for MO-MS collaboration systems in healthcare?

Research Question 2 : To what extent can these design concerns be generalized to other MO-MS collaboration domains?

To answer our research questions, we relied on an exploratory qualitative research design. In the first phase, we derived an initial set of design concerns by systematically reviewing literature on MO-MS collaboration in healthcare. Subsequently, we conducted two rounds of semi-structured interviews to expand and validate our findings. The first round of interviews focused on cloud-based IT services because, although much of the current health IT infrastructure is still in-house, there is a strong trend toward cloud-based solutions [5, 27, 30, 32, 52]. In the second round of interviews, we expanded our scope to encompass interviewees working with in-house IT as well. The contributions of our work are manifold. By providing categories of design concerns, accompanying design questions, and answer checklists, our study contributes to a deeper understanding of the problems and solution spaces for MO-MS collaboration systems in healthcare and beyond. Thereby, our results reveal properties of MO-MS collaboration that require special attention compared to single collaborative work practices for distinct tasks. Our results can guide practitioners in designing effective MO-MS systems that support the execution of suites of interdependent collaborative work practices in heterogeneous organizational settings.

Background

Collaboration Engineering

As a scholarly discipline, CE emerged in the early 2000s in response to observations that the potential benefits of collaboration technologies such as Group Support Systems were seldomly realized in practice and typically only in small teams led by so-called collaboration experts [21]. However, access to collaboration experts is chronically difficult, as they are rare, expensive, and quickly move through organizational hierarchies due to their unique skill set. CE’s founding purpose, thus, was making it possible for non-experts to realize the benefits of collaboration technology without the support of such collaboration experts [21]. Today, CE is prevailingly defined as an approach to designing collaborative work practices for high-value, recurring tasks and deploying those designs for practitioners to execute for themselves without ongoing support from professional facilitators [21, 22]. Thereby, CE focuses on recurring tasks because the return on the resources devoted to the CE effort increases each time the work practice is executed [6]. If a task is only executed once, the efforts of conducting CE to support such onetime task would in most cases exceed the benefits of CE.

Over the past two decades, scholars from various disciplines have made manifold contributions to the CE discipline. The CE literature offers design methodologies [38], modeling conventions [73], technological innovations [9], and cognitive theories to explain and predict phenomena essential to the success of collaboration, such as creativity [59], idea quality [11], satisfaction responses [12], and willingness to change [10]. Because a comprehensive overview of these numerous contributions is beyond the scope of this article, we refer interested readers to a recent review by de Vreede and Briggs [21]. In the following, we introduce scholarly contributions to CE as a structured design approach, since this is where the focus of our study lies.

de Vreede and Briggs [20] were the first to provide a description of CE as a structured design approach, highlighting its five key elements along the Five Ways Framework (see Table 1). Especially the Way of Working (i.e., a nascent structured design methodology for designing collaborative work practices) has received much scholarly attention in the past. At the core of the CE approach are design patterns that represent codified professional collaboration expertise [19, 23]. When conducting CE, a collaboration engineer uses these design patterns to create and document a prescription for collaborative work practices and then subsequently transfers that prescription to practitioners [19, 21]. Thus, the CE approach consists of a design phase in which so-called thinkLets are used to design repeatable collaborative work practices, and a deployment phase, where the newly designed collaborative work practices are introduced into an organization.

Table 1. Five Ways Framework of CE^a.

Organizing principle	Description
Way of Thinking	Reflects the underlying philosophy of the CE approach. Defines key terms, and models key phenomena.
Way of Working	Describes the steps necessary to design collaborative work practices, as well as their interrelationships and deliverables.
Way of Modeling	Defines means to create representations of important aspects of collaborative work practices (e.g., the ThinkLets Notation Model, Facilitation Process Model).
Way to Control	Defines the project management aspects and techniques that need to be carried out in CE projects.
Way of Supporting	Describes tools and technologies that support collaboration engineers in designing collaborative work practices.

Notes: ^aBased on de Vreede and Briggs [22]. CE, collaboration engineering.

Next to research helping organizations identify CE opportunities [10] and make CE investment decisions [24], two main contributions to the CE design phase can be distinguished [21]. First, through a series of surveys, interviews, and field studies [40, 41], CE researchers have developed a design approach for the CE design phase, which provides collaboration engineers with step-by-step guidance to designing collaborative work practices [41]. It consists of the five steps task diagnosis (i.e., analyzing the task at hand, involved stakeholders, available resources, and practitioners), task decomposition (i.e., breaking down the collaborative task into an initial sequence of steps), thinkLet choice (i.e., mapping thinkLets to steps in the sequence), agenda building (i.e., describing additional activities besides the thinkLet sequence that need to be performed to implement a collaborative work practice), and validation (i.e., performing pilot testing, walk-throughs, simulations, or expert evaluations). Second, researchers have developed a CE reference model that offers an organized set of design concerns, which collaboration engineers must consider when designing collaborative work practices [8, 21]. Initially, the reference model consisted of seven layers but was later reduced to six layers, because anomalies in the seven layers model revealed that the two layers patterns of collaboration and techniques were elements of a more general procedures layer. The resulting six-layer model of collaboration (SLMC) consists of a collaboration goals layer, which considers the goals a group must meet in a collaborative task, a group products layer, which considers the products a group must create to meet these goals, a group activities layer, which concerns the activities a group must execute to create these products, a group procedures layer, which pertains to the patterns of collaboration and techniques necessary for guiding a group through each of the activities, a collaboration tools layer, which pertains to the design and configuration of tools needed for a group to implement their procedures, and a collaborative behaviors layer, which deals with constraints on what people should say and do on the lower layers. Within the SLMC, design choices at the higher layers confine design choices at the lower layers, such that the model is used to structure CE design activities. The separation of design concerns aims to reduce cognitive load for collaboration engineers and improve completeness of their collaborative work practices designs. Over time, the SLMC became an organizing structure for the multitude of constructs, metrics, theories, design concerns, and best practices in the CE domain [21].

Notwithstanding the important contributions that past research has made to the CE approach, to date the preponderance of CE research has focused on the design and deployment of single collaborative work practices for distinct tasks. By contrast, MO-MS focuses on designing suites of interdependent collaborative work practices for diverse tasks that may involve multiple organizations and multiple stakeholders. The added complexity of MO-MS collaborations likely raises additional design concerns for collaboration engineers that are not yet fully captured within the extant body of CE literature. The various stakeholders involved in MO-MS may each come with different perspectives, expertise, and interests. These stakeholders are associated with various organizational entities often from different cultural backgrounds which may introduce MO-MS collaborators with differences of cultural expectations and norms, terminology, specific local legal requirements, and specific company policies. This increases the complexity of conditions, constraints, and contingencies that the collaboration system must handle and amplifies the challenges of building shared awareness and shared understanding among MO-MS collaborators.

IT-Supported Collaboration in Healthcare

Collaboration in healthcare refers to activities in which multiple stakeholders within and outside of healthcare organizations work jointly to provide healthcare services to patients [38]. In many cases, a one-on-one doctor-patient consultation can be sufficiently simple such that participants require no special support. In more complex settings, however, such as the operation of a large regional hospital, people from multiple departments in multiple institutions, sometimes in multiple locations, may need to collaborate on a regular basis to provide good care. In extreme situations, like the recent COVID-19 pandemic, various stakeholders with diverse backgrounds, from a multitude of (healthcare) organizations must collaborate across national, temporal, and technological boundaries to provide effective and efficient care (e.g., the development of COVID-19 vaccines and antigen tests, clinical trials to find effective treatment).

Extant research has investigated how technologies may support collaboration in healthcare, focusing on the coordination of complex clinical workflows [49], standardization of communication tools to ensure quality of care [69], or the exchanging of health-related data for multidisciplinary healthcare services [29], [65]. To this end, health IT researchers have explored the use of diverse technologies to enable healthcare collaboration, including but not limited to telemedicine systems [1], Web 2.0 applications [62], smartcard technologies [13], or more recently, cloud computing [3], [27], [30], [31, 32], [63]. Both, the positive impacts of health IT (e.g., facilitate coordination of distributed work among co-located teams [29]), as well as their challenges (e.g., information overload for collaborators [56]) have been discussed in the literature. Moreover, key concepts, such as awareness (understanding of what is happening around collaborators [50]) and common ground (shared knowledge or understanding about a focus topic in collaboration [44]), have also gained the attention of researchers interested in IT-supported collaboration in healthcare.

Irrespective of the scope of collaboration, technologies used, and context-specific peculiarities, extant research proposes that healthcare collaboration has to support three essential collaboration functions, namely: Coordination, Communication, and Cooperation (see Table 2) [2, 15, 26, 28, 53].

Table 2. Essential collaboration functions and their relation to MO-MS collaboration.

Essential collaboration functions	Description	Impact of MO-MS healthcare collaboration
Coordination	The management of collaborators (e.g., healthcare professionals, patients, insurance and government officials, social workers, family members), their (care) activities, and (healthcare) resources.	Coordination in MO-MS collaboration is more intricate since it involves more and diverse collaborators, more and interdependent activities, and more resources.
Communication	The imparting or exchanging of (health-related) information (structured and unstructured) among all involved collaborators by means of speaking, writing, using body language, or other media.	Communication in MO-MS collaboration involves communicating information for multiple, different care activities, each of which may entail different kinds of information, norms, and communication mediums.
Cooperation	The joint operation of care activities by involved collaborators in shared workspaces such that the success of the overall care process is ensured.	Cooperation in MO-MS collaboration is more tangled because of the heterogeneous perspectives of involved collaborators, as well as possible imbalances of authority, limited understanding of others’ roles and responsibilities, and professional boundary friction.

Notes: MO-MS, multiorganizational, multistakeholder.

Coordination relates to the management of collaborators (e.g., healthcare professionals, patients, insurance and government officials, social workers, family members), their activities, and their resources. Because care-related collaborative activities require complex interactions among multiple stakeholders with different backgrounds, tools, and schedules, thoughtful coordination is essential [35]. Thoughtful coordination may be achieved through automated health IT applications that manage and coordinate healthcare processes [54]. Such applications tend to support reasoning, planning, and decision making for the coordination of healthcare processes based on predefined medical knowledge and organizational rules [54]. A typical example of IT-supported coordination in healthcare are automatic bed assignment systems, which automatically assign patients to beds and coordinate treatment activities by various internal stakeholders (e.g., nurses) and external stakeholders (e.g., remote specialists) [66]. Regarding MO-MS healthcare collaboration, coordination gets more intricate as it involves multiple, interdependent care activities that need to be coordinated, potentially across different organizations, different locations, and different time zones.

Communication pertains to collaborators imparting or exchanging health-related information as they work to solve the patient’s problems [26]. It includes the exchange of structured information among stakeholders, as well as the exchange of unstructured information like thoughts by speaking, writing, using body language, or any other medium [15]. The exchange of information is an important aspect of virtually any care-related activity, as they require the exchange of information about subjects like symptoms, diagnostic results, or the medical history of a patient to establish a common understanding among the involved stakeholders [67]. Thus, communication is another key aspect of IT-supported collaboration in healthcare [26, 53]. Representative examples of health IT applications that support the communication of structured information are electronic medical record systems or digital X-ray systems that transmit images to remote radiologists [68]. Examples of health IT applications in support of communicating unstructured information include teleconsultation systems that enable remote conversations and debates between physicians and patients (e.g., [70]). Relating to MO-MS collaboration, communication becomes a daunting task since it not only involves communicating information for a single care activity but for multiple, different care activities that are sometimes carried out simultaneously, and each of which may entail different kinds of information, norms, and communication mediums [51].

Cooperation describes the joint operation of individual care activities by involved collaborators in shared workspaces to ensure the success of the overall care process. Today, most care activities are to some extent performed collectively, requiring cooperation of healthcare professionals from diverse disciplines (e.g., a surgery involves not only the surgeons but also nurses, anesthetists, and perhaps other specialists) [64]. Common health IT applications that support cooperation include joint clinical decision-making [48] and documentation systems [72], or remote surgical systems that allow for a surgeon to operate remotely while cooperating with the operating room team [36]. In terms of MO-MS healthcare collaboration, cooperation becomes more tangled due to heterogeneous perspectives of involved stakeholders on the multitude of different care activities, their quality, and safety [78]. Furthermore, the large number of involved stakeholders in MO-MS collaboration may come with possible imbalances of authority, limited understanding of others’ roles and responsibilities as well as professional boundary friction [57, 60].

Research Approach

The goal of this exploratory [61], inductive study was to compile the design concerns for MO-MS healthcare collaboration systems reported in the literature and to discover additional design concerns in the field. To achieve this goal, we employed a three-stage research approach (see Figure 1), which consists of an extensive literature review, one round of exploratory, semi-structured expert interviews, and one round of confirmatory, semi-structured expert interviews.

Figure 1. Research approach overview.

This study is embedded in a multi-year research project on cloud computing in healthcare. Although (MO-MS) collaboration was not the main focus and starting point of that research project, collaborative care activities and collaboration in general quickly emerged as one of the primary value propositions for the adoption of cloud computing in healthcare. Moreover, we also noted during the research project that cloud computing entails implementation-specific peculiarities (e.g., the pooling of resources for multiple clients, or regulation regarding the storage and exchange of data via the cloud), which we thought might as well pose additional, cloud computing-related design concerns (although this hypothesis ultimately had to be rejected, see the Discussion section for more details). Consequently, we engaged with cloud computing throughout the different stages of our research project by, for example, also including healthcare cloud computing in our literature search, and making cloud-based collaboration systems in healthcare our first port of call for the exploratory interviews stage.

In the following, we first briefly outline our data collection approach for each of the three stages of our research, before we describe how we analyzed the data that was obtained across the three different stages.

First Stage: Literature Review

We began our research endeavor with an extensive review of the literature on healthcare collaboration that was guided by Webster and Watson [71] and Levy and Ellis [46]. To identify relevant studies, we queried eight pertinent scientific databases for research articles that matched the focus of this study. The queried databases were chosen such that they cover a wide range of journal articles and conference proceedings in the domains of information systems, computer science, and medical informatics. Accordingly, they comprised the ACM Digital Library, the AIS eLibrary, EBSCOhost, Emerald Insight, the IEEE Xplore Digital Library, ProQuest, PubMed, and ScienceDirect. A detailed overview of our search strategy is given in Table 3.

Table 3. Overview of the employed search strategy.

Aspect	Description
Search string	[(collaborat* OR cooperat* OR co-operat*) AND (e-health OR ehealth OR “health information system*” OR “healthcare information system*” OR “clinical information system*” OR “health information technology” OR “health IT” OR “healthcare IT”)] OR [(cloud OR “software as a service” OR software-as-a-service OR SaaS OR “platform as a service” OR platform-as-a-service OR PaaS OR “infrastructure as a service” OR infrastructure-as-a-service OR IaaS) AND (hospital* OR clinic* OR inpatient OR in-patient)].
Search fields	Title, abstract, keywords
Databases	ACM Digital Library (n=36), AIS eLibrary (n=14), EBSCOHost (n=1,732), Emerald Insight (n=288), IEEE Xplore (n=635), ProQuest (n=2,204), PubMed (n=1,352), ScienceDirect (n=1,547)
Exclusion criteria	The article is not in English The article is not a research article The article is off topic
Inclusion criteria	The article described the use of real healthcare IT systems in the field The article described an approach or process in health IT that facilitates collaboration The article described the requirements of healthcare collaboration systems The article described challenges and/or concerns regarding clinical collaborative activities The article described the technical features of a health IT system that supports collaboration

After removing duplicates (n = 1,199), our search strategy yielded a total of 6,609 unique publications. Two researchers screened these publications independent of each other, examining titles, abstracts, keywords, and full texts. Both researchers excluded any article that was not in English (n = 294), not a research article (n = 2,193), or not related to collaborative healthcare (n = 4,022), meaning that it did not meet at least one of the five inclusion criteria outlined in Table 3. The researchers compared and integrated their screening results and resolved differences through discussion. After the screening, 100 articles were found to meet the selection criteria (for a full list, see Online Supplemental Appendix 1).

Second Stage: Exploratory Expert Interviews

In stage two, to augment the results of the literature review and to discover concerns that might not yet be in the literature, we conducted semi-structured interviews with healthcare systems experts in the field. In this first round of interviews, the interviewees were employees of healthcare organizations or health IT vendors who used cloud computing services or health IT vendors that provided cloud computing services in China (n = 12) and Germany (n = 12) because we had access to healthcare professionals in these countries and we wanted to account for potential cultural peculiarities of CE design concerns that have been discussed in prior literature [14]. An overview of interview participants is given in Table 4.

Table 4. Overview of interviewees.

Round	#	Interviewee role (years of related work experience)	Location	Organization	Size
1	i1	CIO (8)	China	General hospital	≥1,500 beds, ≥2,500 employees
1	i2	Chief of the Information Center (18)	China	General hospital	≥1,500 beds, ≥2,500 employees
1	i3	Project Manager (12)	China	International health IT (HIT) provider	≥2,500 employees
1	i4	Staff of the New Media Department (6)	China	Specialized hospital	≥1,000 beds, ≥1,500 employees
1	i5	Chief of the IT Department (15)	China	District hospital	≥250 beds, ≥250 employees
1	i6	CEO (16)	China	HIT provider for dental hospitals	≥2,500 employees
1	i7	Senior IT Staff (12)	China	General hospital	≥1,500 beds, ≥2,500 employees
1	i8	IT Supervisor (17)	China	Governmental organization for the strategic development of public hospitals in a metropolis	≥50 employees
1	i9	Chief of the Information Center (11)	China	General hospital	≥500 beds, ≥1,000 employees
1	i10	Senior IT Staff (9)	China	General hospital	≥1,500 beds, ≥2,500 employees
1	i11	Vice Director (12)	China	District hospital	≥250 beds, ≥250 employees
1	i12	Head of IT (6)	China	General hospital	≥1,500 beds, ≥2,500 employees
1	i13	CMO (33)	Belgium^a	International HIT provider	≥5,000 employees
1	i14	Staff of the R&D Department (30)	Belgium^a	International HIT provider	≥5,000 employees
1	i15	Head of IT Applications (20)	Germany	University hospital	≥1,250 beds, ≥10,000 employees
1	i16	Technology Manager (10)	Belgium^a	International HIT provider	≥5,000 employees
1	i17	Head of IT Development (6)	Germany	Local HIT provider for hospitals	≥50 employees
1	i18	HIT Developer (6)	Germany	Local HIT provider for hospitals	≥50 employees
1	i19	Senior Manager (19)	Germany	Local HIT provider for hospitals	≥50 employees
1	i20	Head of IT (17)	Germany	University hospital	≥1,000 beds, ≥5,000 employees
1	i21	IT Staff (10)	Germany	University hospital	≥1,000 beds, ≥5,000 employees
1	i22	IT Team Leader (19)	Germany	University hospital	≥1,000 beds, ≥5,000 employees
1	i23	CIO (12)	Germany	District hospital	≥500 beds, ≥2,000 employees
1	i24	Head of IT Infrastructure (31)	Germany	University hospital	≥2,000 beds, ≥5,000 employees
2	i25	(Health) IT Product Consultant (6)	Germany	IT provider with a focus on cloud computing	≥ 300 employees
2	i26	Assistant Ophthalmologist (3)	China	General hospital	≥1,500 beds, ≥2,500 employees
2	i27	Gynecologist (4)	China	General hospital	≥4,000 beds, ≥4,000 employees
2	i28	Project Manager (7)	China	Startup HIT infrastructure provider	≥15 employees
2	i29	Dermatologist (5)	China	University hospital	≥1,500 beds, ≥2,000 employees
2	i30	Obstetrician (11)	China	General hospital	≥4,000 beds, ≥3,500 employees
2	i31	Orthopedist in Charge (7)	China	District hospital	≥1,500 beds, ≥2,500 employees
2	i32	HIT Developer (9)	China	International IT consulting company	≥5,000 employees
2	i33	Ophthalmologist (5)	China	Medical center	≥1,000 beds, ≥1,000 employees
2	i34	Associate Chief Neurologist (15)	China	Medical center	≥1,000 beds, ≥500 employees
2	i35	IT Developer (4)	Germany	Software provider for the public sector	≥150 employees
2	i36	Information Systems Researcher (6)	Germany	Research university	≥5,500 employees
2	i37	Registered Nurse (3)	Germany	Local skilled nursing facility	≥50 employees
2	i38	HIT Researcher (2)	Germany	Research university	≥2,000 employees
2	i39	Senior IT Consultant (5)	Germany	Local IT consulting company	≥100 employees
2	i40	HIT Consultant (8)	Germany	International IT consulting company	≥20,000 employees
2	i41	HIT Manager (25)	Germany	International IT consulting company	≥20,000 employees
2	i42	HIT Strategy Principal Director (19)	Germany	International IT consulting company	≥35,000 employees
2	i43	IT Engineer (3)	Germany	Local business intelligence company	≥75 employees
2	i44	HIT Software Engineer (5)	Germany	International software provider for the public and the healthcare sector	≥3,000 employees
2	i45	HIT Founder & Director (26)	Germany	Startup software provider for healthcare organizations	≥5 employees
2	i46	Registered Nurse (18)	Germany	District skilled nursing facility	≥135 employees
2	i47	Health Insurance Supervisor (20)	Germany	Institution for policy making for healthcare insurance	≥200 employees
2	i48	Head of HIT Consulting (10)	Germany	International IT consulting company	≥5,000 employees
2	i49	Partner Healthcare & Pharmacy Consulting (20)	Germany	International management consulting company	≥20,000 employees
2	i50	Senior Manager eHealth & mHealth Consulting (10)	Germany	International management consulting company	≥20,000 employees

^aWhile the interviewee’s location was Belgium, their organization provide HIT to the German market. Accordingly, the interviews focused, where necessary, on the German HIT market. CIO, chief information officer; IT, information technology; HIT, health information technology.

During the semi-structured interviews, we first asked the experts to enumerate all the computing services in healthcare with which they were familiar, including those used by their own organizations. Next, we asked the interviewees to describe the purposes of each computing service and the key characteristics of each, with a special focus on how they were used to support collaboration. A full list of interview questions for this stage is included in Online Supplemental Appendix 2.

We audio recorded all interviews and created verbatim transcripts right after each interview. Afterward, interview transcripts were sent to the respective interviewees for comments and final approval. Overall, the interviews in the first round ranged in length from 32 to 87 minutes, with an average duration of 51 minutes. In keeping with the standards of rigor for exploratory research, we ended the first round after 24 interviews when we reached conceptual saturation (i.e., the last few interviews revealed no new concepts) [61].

Third Stage: Confirmatory Expert Interviews

Following the exploratory expert interviews in stage two, we conducted a second round of semi-structured expert interviews to validate the results from the previous steps and, if possible, discover further categories of design concerns in stage three. The interviewees in the third stage were not only health IT experts but also other stakeholders in healthcare (e.g., physicians, nurses) who were regular users of health-related collaboration systems (see Table 4). The second-round interviews began by asking what functions a collaboration system would be required to have to support their collaborative healthcare activities. Next, we asked the interviewees to describe the capabilities that an ideal healthcare collaboration system should possess. Subsequently, we presented the ten categories derived in the first and second stage and asked the interviewees to evaluate whether, how, and why/why not these categories of concerns were important for collaboration in healthcare (i.e., facilitate and ease collaboration in healthcare in a positive way). We also asked whether the ten categories omitted any key design concerns that should be considered. Note, that we did not consider the SLMC-based foundational category at this stage, since it is not specific to MO-MS collaboration and well-researched. Lastly, we used the second-round interviews to validate the three essential collaboration functions for MO-MS collaboration (coordination, communication, and cooperation) from the literature (see the Background section). We asked open-ended questions about the interviewees’ understanding of IT-supported collaboration in healthcare and what IT functions they observed in the field. A full list of questions for this interview round is included in Online Supplemental Appendix 2.

Similar to the first round of interviews, we audio recorded all interviews, created verbatim transcripts and afterward sent the transcripts to the respective interviewees for comments and final approval. The interviews in the second round ranged in length from 36 to 82 minutes, with an average duration of 58 minutes. After 26 interviews, we reached conceptual saturation (i.e., all design concerns were verified by multiple interviewees across organizational and cultural boundaries) and ended the second round. No interviewees from the first round of interviews participated in the second round. Thus, a total of 50 interviews with 50 interviewees from 38 different organizations participated in the stages two and three of our study.

Data Analysis

To analyze the rich data the that we obtained during the three, previously outlined, stages of data collection, we relied on inductive reasoning throughout all stages. Statements made about collaboration in healthcare were coded by means of open coding [16], which resulted in codes encapsulating design concerns for MO-MS collaboration in healthcare. Subsequently, analysis of these codes revealed several first-order concepts [33]. Eventually, by evaluating the similarities and differences between the various first-order concepts, more abstract second-order themes (i.e., the design concerns presented in this work) began to emerge. An example of this analysis process is provided in Figure 2.

Figure 2. Example from the coding process.

To begin the sense-making process, we started with the analysis of the relevant literature (stage 1). Two of us worked independently to read all 100 articles and to extract statements related to general (in-house) and cloud-based information systems that were used to support healthcare collaboration. Upon completing our work, we compared and aggregated our codes and resorted to the process previously described, to derive six categories of design concerns for MO-MS healthcare collaboration systems (i.e., Role Variety, Service Perimeter, Response Times, Device Integration, System Interoperability, and Data Integration). Additionally, throughout our literature review statements emerged that could be related to general design concerns in collaboration that could be linked to the SLMC. As such, we decided to also take one deductive step and augment our set of design concerns with a foundational category called Collaborative Work Practices which was derived based on the six layers presented in the SLMC.

Next, two researchers analyzed the transcripts of the exploratory expert interviews (stage 2) and extracted useful statements. Again, both researchers coded those statements using open coding, compared and aggregated their codes, and used the described process to derive more abstract second-order themes in the form of four additional categories of design concerns for MO-MS healthcare collaboration systems (i.e., Process Adaptability, Data Integration, Richness of System Cues, and Concept Clarity). In total, the first and second stage of our research process yielded eleven categories of design concerns (seven from the literature review, including the foundational SLMC-based category, and four from the first-round interviews).

Finally, to analyze the transcripts of the second-round, confirmatory interviews (stage 3), we applied the same process as in the previous two stages. Thus, both researchers read through all 26 transcripts and used open coding to extract codes about collaboration in healthcare. Afterward, the researchers compared and aggregated their categories, to develop higher-order themes. While this yielded no new categories of design concerns, the second-round interviews confirmed the relevance of all ten included categories of design concerns for MO-MS healthcare collaboration systems. Moreover, most of the interviewees referred to the three primary functions of collaboration to justify each category of design concerns, and we discovered no additional essential functions.

Design Concerns for Multiorganizational Multistakeholder Collaboration Systems in Healthcare

This section specifies each of the categories in the set of design concerns (for a complete overview, see Online Supplemental Appendix 3). The first category (Category 0) addresses general concerns based on the SLMC because these concerns pertain to collaboration systems of any scale, including MO-MS. Furthermore, the category serves as an entry point for the design process. The subsequent categories provide additional, more specific concerns pertaining to the design of MO-MS collaboration systems. Table 5 summarizes the design concerns for each category. We also present exemplary quotes from the interviewed experts about the necessity of the category, and exemplary probe questions that designers of MO-MS collaboration systems can use to improve the breadth and depth of the system requirements they derive.

Table 5. Overview of design concerns.

#	Design concern	Focus	Stage^a
			Lit.	I1	I2
0	Collaborative work practices	General design concerns in collaboration	D
1	Role variety	Different roles involved in collaboration	D		C
2	Service perimeter	External entities	D		C
3	Response times	Events to which a collaboration will respond	D		C
4	Device integration	Data-active devices used by different users	D		C
5	System interoperability	IS that the collaboration system has to interoperate with	D		C
6	Process adaptability	Variety of conditions for collaboration		D	C
7	User awareness	User’s knowledge about own role and whole collaboration environment	D		C
8	Data integration	Sources, from which data for collaboration is gathered		D	C
9	Richness of system cues	Richness information cues provided to the users		D	C
10	Concept clarity	User’s understanding of concepts (e.g., medial, technical)		D	C

^aLit., Stage 1, literature review; I₁, Stage 2, exploratory expert interviews; I₂, Stage 3, confirmatory expert interviews; D, design concern was derived in this stage; C, design concern was confirmed in this stage.

Category Zero: Collaborative Work Practices

The collaborative work practices category addresses general design concerns that arise when people make a joint effort toward a group goal. The six layers of design concerns in the SLMC are: Collaboration Goals, Group Deliverables, Group Activities, Group Procedures, Collaboration Tools, and Behaviors. We extended the SLMC to include Task Data, pertaining to the data required to achieve the goals. The Category 0 questions are prerequisites for the questions in the subsequent categories. With respect to the SLMC as design concerns, Interviewee i45 (software provider for nursing work), for example, explained, “Without ground rules and without a definition of collaboration tasks, it (collaboration in healthcare) will never work … Before we start collaboration, our number one question is always whether all goals, rules, processes, activities, and so on have already been clearly defined.” The probe questions for this category of design concerns are as follows:

0.1 What goals do collaborators seek to achieve?

0.2 What deliverables must collaborators create to achieve each goal?

0.3 What work packages must collaborators complete to create each deliverable?

0.4 What procedures must collaborators follow to complete each work package?

0.5 What technological support will collaborators require to execute each procedure?

0.6 What information and data do collaborators require to execute each procedure?

0.7 What must collaborators say and do with which system capabilities and under what constraints to instantiate each procedure?

Category One: Role Variety

Role variety concerns the assortment of roles involved in the collaboration, the specific work practices in which each role must participate, and the capabilities the system must afford to support each role’s involvement in these processes. In MO-MS healthcare, a wide variety of stakeholders, each with different expertise and interests, must collaborate. The interviewees reported that this category of concerns is sometimes neglected in health collaboration system designs. For instance, they noted that systems often precluded the involvement of patients. For example, Interviewee i26 (assistant ophthalmologist) said, “Even for communication between doctors, I think it is important to involve patients. Because otherwise, for example, the information passed between physicians is just not accurate. It’s second-hand.” Other interviewees reported that the participation of family, friends, and social workers and other essential partners in the collaboration are not accommodated by some system designs. This category of concerns is useful because a collaboration system will fail if it excludes even one class of success-critical stakeholders.

The design questions for this category aim to identify the range of roles involved and to discover role-based privileges and restrictions that should be offered by a collaboration system (e.g., role-based enforcement of privacy policies for patient records), depending on differences in their rights, responsibilities, and interests. In the context of this set of design concerns, an event is an episode where two or more stakeholders make a joint effort toward improving a patient’s medical outcomes. The exemplar probe questions for Category 1, are as follows:

• 1.1 What are the roles involved in each class of collaborative processes the system will support, and what are their interests and goals with respect to those processes?

• 1.2 In which steps of each collaborative process does each role have a vested interest?

• 1.3 In which steps of each collaborative process should each role be allowed to participate?

• 1.4 From which steps should each role be excluded?

• 1.5 For each step in each collaborative process, what actions should each participating role be permitted to take before/during/after each event with respect to which information and data and under what conditions?

• 1.6 For each process, what data and information are preferred by each participating role, in what formats and delivered via what media?

Category Two: Service Perimeter

This category concerns the variety of external entities that will collaborate with stakeholders in a given organization. The findings suggest that, in some cases, a collaboration system should be able to accommodate entities in different geographical areas, with differing cultural, political, and regulatory conditions, and it should accommodate participation by people from different industries because “People should try get rid of or blur [boundaries] pertaining to laws, rules, or cultural stuff for different organizations” (Interviewee i32, health IT developer). Collaboration in healthcare often occurs among different organizations across different boundaries, as explained by Interviewee i36 (information systems researcher): “I know someone who is a doctor [in Germany] but has patients in Dubai and Qatar … He often works [in Germany] together with his patients there and, of course, with their local hospitals. I believe the boundaries don’t have to exist.” Although such boundaries will persist, a well-designed collaboration system should make them all but invisible to the participants. The designer must discover and understand the boundaries to design a system that transcends them. The exemplar probe questions in Category 2 assist designers in identifying and addressing these possible boundaries and the related barriers to collaborative activities:

2.1 What outside entities are involved in each collaborative work package, what are their roles in each work package, and what are their interests/goals?

2.2 What are the differences in legal requirements, standards, or restrictions that each outside entity must follow based on its geopolitical location?

2.3 What are the differences in legal requirements, standards, or restrictions that collaborators in different industry sectors must follow?

2.4 What differences in organizational, regional, and national culture must be considered to work with these outside entities?

Category Three: Response Times

Category 3 concerns the variety of events to which the collaboration system will respond, and the capabilities the collaboration system must provide to attain the minimum necessary response times for each class of stakeholders involved in a given event, and the capabilities the system must provide to support their involvement.

Timeliness is one of the most critical indicators of success for collaboration in healthcare: “To do everything in a timely manner is the basis of collaboration in healthcare. … Imagine you have something like WhatsApp in healthcare: Where is the value if you get your message on the next day? Why don’t we go back to the age [of posting letters]?” (Interviewee i34, associate chief neurologist).

The interviewees suggested that prompt responses in a collaboration system would reduce the cognitive load associated with unnecessary wait times. For example, Interviewee i46 (registered nurse) told us, “I followed the instructions in our system for our [collaboration] process. If there is a delay because of the system, then I have to wait, and then, the next colleague has to wait, and then, the whole team. It’s annoying. … It’s always beneficial if everything can be assigned as soon as possible so that we don’t have to waste our valuable time or make compromises just because of the IT system.” The Interviewees stressed that collaborative activities that are often based on the exchange of data should always be as close to real time as possible (i.e., the quicker, the better). Interviewee i48 (head of health IT consulting) said, “As a whole, it [data exchange] is interlocking. Data go through the whole chain. The data you need right now might depend on the [availability of] data from earlier steps or other collaborators. So, the truth is that we always have to keep data exchange in real time because the data might actually be needed in the next emergency situation.” Category 3 offers four exemplar questions to probe for concerns about the minimum latency allowed for each class of collaborative activities:

• 3.1 What is the minimum response latency allowed for each class of data/information used in each collaborative event?

• 3.2 What steps of each collaborative procedure should be carried out in real time (e.g., synchronous vs. asynchronous)?

• 3.3 In what situations and in which events can predefined minimum latency standards be allowed to vary and by how much?

• 3.4 How should collaborators respond if the predefined latency standards do not hold?

Category Four: Device Integration

Device integration concerns the variety of data-active devices that participating roles should be allowed to use to participate in collaborative activities (e.g., wearable sensors, smartphones, tablets, and no-barrier devices) and the capabilities the system must afford to accommodate their use.

Device integration gives collaborators ubiquitous collaboration capabilities, as explained by Interviewee i34 (associate chief neurologist): “I am usually involved in several medical cases at the same time. … Our system was on my PC before. Then, I had to go back to my office to check the system so that I would not miss states or instructions. I went to the ward or emergency room and then turned back to check my PC, again and again. … Now that they have given me an iPad, it’s better but still annoying because I now have to carry so many things: medical devices, paper stuff, and so on. … I told my hospital that I need a smart watch.”

Moreover, device integration enables unobtrusive participation (e.g., data exchange through wearable sensors instead of manual measuring or entering), as described by Interviewee i44 (health IT software engineer): “I see this as the future [of collaboration] from a data perspective. Because it’s not only about an unobtrusive way of using IT but also about giving people the possibility to automatically bring their own data into healthcare with sensors anytime, anywhere, without using cables. Such data are even more important than what you can collect in hospitals. … Even at home, we would have Wi-Fi to enable our patients to upload their daily data to a server or data center by using sensors, which was impossible or unimaginable before.” This category offers four probe questions about the variety of user devices for supporting collaboration:

• 4.1 What kinds of devices should participants be able to use to access which capabilities of the systems before, during, and after which collaborative work packages?

• 4.2 What capabilities must the system provide to accommodate the access devices supported?

• 4.3 What specific events should each class of devices support and under what conditions?

• 4.4 What data-related actions should each class of supported devices be allowed to take in each procedure and under what conditions? [e.g., read, add, edit, move, delete]

Category Five: System Interoperability

Category 5 concerns the variety of internal and external information systems with which the collaboration system must interoperate—both at the time the collaboration system is deployed, and in the future—and the capabilities that the system must afford to accommodate these interoperations. The focus of this category is on collaboration systems’ capability of interoperating with heterogeneous digital systems (e.g., medical, legal, social) that are not necessarily built to common standards. Interviewee i38 (health IT researcher) said, “In a perfect world, we would use the same standards everywhere [in healthcare], and people wouldn’t have to worry about the interoperability problem because we would always have a standard. … In the real world, different [healthcare] systems have different ways of exchanging, which means you should also take those nonstandard systems into consideration.”

We found that collaboration system designers must also pay attention to legacy tools or systems, including noncomputerized paper-based tools. In many situations, legacy tools in collaborative activities are still common and cannot easily be replaced. For example, Interviewee i37 (registered nurse) tells the following story: “Our team also uses tools we invented ourselves. … For the patient assignment, we use a whiteboard in our office. We just write down the names there, although we already have an IT system for that. The reason is that our team leader is an old lady who learned the whiteboard approach from her leader, I don’t know, 30 years ago. And she said it’s a best practice … Once, I asked my friend from another hospital; they have a similar situation! … So, my point is that you just cannot ignore traditional tools. They have become an integral part of our (collaboration) work.” The probe questions that belong to this category help designers identify system requirements that are relevant for the system’s interoperation with heterogeneous systems and other different (digital and/or nondigital) approaches.

5.1 What data will stakeholders need for each collaborative work package?

5.2 What is the data model of the data needed for each collaborative work package?

5.3 What are the sources and repositories for each kind of data?

5.4 How will the collaboration system use each type of data from external sources, and what data access privileges should the system have for those data?

5.5 What are the internal or external legacy capabilities with which the system needs to interoperate?

5.6 How should the system interoperate with the legacy capabilities?

Category Six: Process Adaptability

Process adaptability concerns the variety of conditions under which stakeholders must collaborate and the capabilities the system must afford so that it can be adapted to that range of conditions. For example, some patients may have no insurance, some may have one insurance policy, and others may have multiple policies with multiple types of insurance. The system would have to be sufficiently flexible to accommodate all these conditions. Similarly, many insurance companies provide patients with a standard insurance card, but some companies do not. The system would have to be designed to accommodate both conditions.

This category is relevant for two reasons. First, although the healthcare industry strives to define all conditions or situations for collaboration in an exhaustive manner, unpredictable occurrences and exceptions often appear (e.g., a new variant of a certain disease/symptom for which a predefined collaborative treatment process is not appropriate). Interviewee i30 (obstetrician) stated, “People think that healthcare processes are very well defined, but it’s not really the case because it’s too difficult to completely define everything … Everyone thinks that we have already defined all possible situations clearly … they think that no matter what happens, there will always be a solution, a path for it. But it’s not one hundred percent. There are always exceptions that we have never encountered before. So, IT is still not flexible enough, at least from the medical perspective. … It would be great if we could adjust the [collaboration] process a little bit on the fly.” Second, even small adaptations of organizational policy or industry regulations can affect the ways in which collaboration works in healthcare. Interviewee i37 (registered nurse) told us, “Next year, we will change from four levels to five levels of nurses because insurance companies want it. So, we have to reorganize some [collaboration] processes again, which we already did last year.” Interviewee i48 (head of health IT consulting) also stated, “In the U.S., for example, you had Obamacare, and then, something [about the collaboration process] had to change. Several years later, the next president wants to eliminate it, and something [about the collaboration process] will have to change again.”

Category 6 offers five questions pertaining to process adaptability:

6.1 Under what variety of operating conditions must each work package be executed?

6.2 In what ways are the operating conditions for each work package likely to change over time, how quickly, and by how much?

6.3 How should the collaboration system accommodate the variety of operating conditions that may manifest?

6.4 What formal rules, e.g., standards, norms, laws, mandates, or restrictions affecting each work package are likely to change over time and in what ways?

6.5 How should the collaboration system accommodate changes to formal rules?

Category Seven: User Awareness

User awareness concerns the degree to which users can know a) with whom they are collaborating (identities and roles); b) what the people in each role are expected to do (rules about what each role should do under what constraints using what capabilities); c) what aspect or part of the system each person is currently using; d) what each person is doing; e) who executed each action; f) the current states of activities in progress; and g) the current states of the system and the environment. This category aims to increase not only a collaborator’s understanding of their own role, rules, tasks, and responsibilities but also the collaborator’s cognitive transparency with regard to the whole collaboration environment. Interviewee i27 (gynecologist) stated, “When a patient is in our hospital, it is very, very important for the next department that will receive him to know what stage he is currently in … for example, to manage the bed situation, the availability of doctors and nurses, and so on. This would provide buffer time for us and increase the efficiency of coordinating the team.”

The interviewees further argued that increased transparency improves collaboration from a data perspective: “There is an IT platform for patient data exchange in Austria; it is a centralized electronic patient record system. … The patient has to define and decide ‘What doctors have what kinds of access to what part of my data?’ The data can not only be shared but also be withdrawn if something changes. Of course, we are also talking a bit about the topic of data privacy, but I view this topic more as transparency. And I believe that transparency has to be the precondition if data exchange can be realized at all in healthcare. So, we have to use high art to design our system so that it can support this transparency. … Increasing user awareness could act as such a high art to dynamically inform users about everything in their environment that is important to them and to calm them down. … This is a kind of guarantee that the whole [collaboration] based on data exchange will work.” (Interviewee i48, head of a health IT consultancy).

The design questions in this category focus on the different kinds of information a collaboration system will need to offer to increase user awareness:

7.1 What are the defined objectives, rules, individual responsibilities, and available resources for each work package that should be used to support collaborators?

7.2 For each work package, what will participants need to know about one another’s work progress, and how will the system provide that information?

7.3 Which roles will need to know what information about collaborators’ behaviors, and how will the system provide that information?

Category Eight: Data Integration

This category concerns the variety of sources from which the relevant data for collaboration must be gathered, the completeness of data, and the capabilities the system must afford to integrate these sources. In healthcare, patient data are the most essential data for collaborative activities. Patient data are often decentralized and fragmented, and therefore, they sometimes have limited availability (e.g., Otte-Trojel et al. [55]). Interviewee i38 (health IT researcher) stated, “Without patient data, cooperation in healthcare, which is always about patients, is impossible or limited.” Interviewee i33 (ophthalmologist) explained, “It’s always necessary to collect all relevant data about a patient … I am an eye doctor, but I also want to know the patient’s other detailed information, like when was her last period or has the patient ever paid for sex. … Patient data are often not complete. Maybe they have been collected, but I don’t know where they are. So, I have to collect them again … In the end, data are a description of a patient, like a specification or a manual for him: the more detailed, the better. Also, if I transfer data to another doctor, I am sure he prefers the detailed manual, not just a part of it.” The design questions in Category 8 aim to identify relevant system requirements that increase the completeness of data that are essential for collaborative activities:

8.1 What internal and external data are necessary for each work package, and how will the system provide them?

8.2 What data from outside the system will be necessary for each work package, and how should the system gather them?

8.3 What data will each work package create, and how should the system store and present them?

8.4 What data may be produced or acquired from external sources by the system in the future, what might their sources be, and how should the system be designed now to accommodate them later?

Category Nine: Richness of System Cues

Category 9 concerns the variety of media richness associated with the information cues the system provides to users (e.g., explanations, patient records, human communication) and the capabilities the system must afford to present that variety. This category prompts designers to consider the degree of media richness appropriate to help users understand relevant data during collaboration with the minimum cognitive load. Abstract information and/or data for collaboration are sometimes hard for some stakeholders to interpret without assistance. Interviewee i42 (health IT strategy principal director) gave an example: “My mother is 82 years old, and she went to see doctor. It took two hours for the doctor to finally understand where the problem was. So, this is actually one of the biggest challenges in healthcare collaboration. … Without using, for example, video technologies, it is difficult to use normal language to express everything. … Let’s be more innovative, you can build a model of the human body, with which you can show where exactly the problem is or simulate what movement would cause what hurt. … It’s much more intuitive than organizing language, and also for understanding because you can just show it.”

Interviewee i31 (orthopedist in charge) explained how media richness can help collaborators reduce their cognitive load: “Pictures and texts are not enough. Before, we had to use a series of pictures for the movement of a joint, for example. It was like you read these pictures and used your brain to imagine the movement, like lantern slides. It was tiring. … I also had to use text to describe everything to let others know what I did and found, which took a lot of time and nerves. … Now, you can shoot videos or create an animation instead of writing a textual description. People can see what it actually was. It’s straightforward.”

The design questions in this category consider the required variety of presentation formats for the information that the collaborators will use:

9.1 For each kind of information cue, which human senses could be used to increase the understanding of collaborators in each role while minimizing the cognitive load?

9.2 For each kind of information cue, what media could the system use to deliver the cue to increase the understanding of people in each role while minimizing the cognitive load?

Category Ten: Concept Clarity

Concept clarity concerns the degree to which people in various roles must understand the variety of concepts—medical, technical, and otherwise—for successful healthcare collaboration, and the capabilities the system must afford to ensure that people gain sufficient shared understanding of these concepts. As pointed out by the interviewees, collaborators do not necessarily possess sufficient knowledge that enables them to fully understand all the information or data in a collaboration setting (e.g., medical data). Even for collaborators with a medical background, assistance from the system might help them understand nonmedical external information or data more precisely and thus prevent misunderstandings. For example, Interviewee i27 (gynecologist) stated: “data are sometimes not easy to understand because there are too many different organizations. Different hospitals could have different interpretations of the same concept. That’s why we do not really take all information for certain [medical examination] items because some other small hospitals have their own interpretation that is totally wrong. … I also had a patient who did some examinations in a foreign country. … People there used [English] abbreviations that I never saw, and I had to guess. … Also, a doctor from another area might sometimes not understand the terms in my data or the meaning of them. I think you should try to describe or specify your data to the greatest extent so that people will have a consistent understanding.”

The design questions in this category prompt the designer to identify which stakeholders will require explanations and clarifications and how the system should provide them:

10.1 In each work package, what concepts, statements, or parameters will people in each participating role need to understand?

10.2 For each work package, what should the system do to clarify or interpret the necessary concepts for the people in each participating role?

10.3 What are the target user groups for the definitions or interpretations of each concept or parameter (e.g., medical value), and what value will they derive from that knowledge?

Discussion

This study was motivated by the observation of the emergence of a challenging class of collaboration—MO-MS collaboration—that is concerned with suites of interdependent collaborative work practices for diverse tasks, involving multiple organizations and multiple stakeholders. By conducting a systematic literature review followed by two rounds of semi-structured interviews with MO-MS collaboration stakeholders from healthcare organizations operating in Germany and China, we identified ten novel categories of MO-MS collaboration design concerns and one foundational category (Category 0) that was derived based on the SLMC [8, 21]. Online Supplemental Appendix 3 presents the complete set of design concerns, related probing questions, and, where questions are closed-ended, checklists of possible answers for the collaborative healthcare domain. Our results reveal peculiarities of MO-MS and thereby, contribute to a deeper understanding of MO-MS collaboration in healthcare and beyond. We argue that our design concerns come with two major implications: First, although derived from the healthcare context only, each category of design concerns appears to be generalizable to other MO-MS domains. Second, although the ten novel categories of MO-MS design concerns might apply to some small-scale collaborations as well, each represents a class of concerns that becomes much more challenging for MO-MS collaboration. We discuss both implications in the following.

Generalizability of the Design Concerns Across MO-MS Collaboration Domains

We phrased the ten categories in general terms and not only specific to healthcare, because we argue that they should generalize to other MO-MS domains as well. Reasons for this are manifold. First, MO-MS collaboration, per definition, involves a wide variety of different stakeholders, each with different perspectives, expertise, and interests. These stakeholders are associated with various (organizational) entities often from different geographical areas with differing cultural, political, and regulatory conditions. Many of these organizations come with specific local legal requirements and specific company policies which will increase the complexity of conditions, constraints, and contingencies that the collaboration system must accommodate. Accordingly, we argue that role variety (Category 1), service perimeter (Category 2), and process adaptability (Category 6) should be of concern to all MO-MS contexts. The large number of different stakeholders in MO-MS collaboration also makes user awareness (Category 7) a matter of concern across contexts since to enable cooperation among users of MO-MS collaboration systems, they need to be aware of who their counterparts are and what responsibilities they take. Naturally, the attentional resources of MO-MS stakeholders are limited, which can make creating a shared understanding among people who are not co-located very challenging. Thus, richness of system cues (Category 9) is relevant for MO-MS in general since it aims to ensure sufficient variety of media richness associated with information cues and the system’s capabilities to present that variety to users. It is, thus, a key factor in enabling media rich communication. MO-MS collaboration, in general, requires large coordination efforts which may jeopardize the production of timely collaboration outcomes and makes response time (Category 3) a matter of concern. In addition, different organizations and organizational units tend to establish differing, incompatible technology standards, which produce information that is required for collaborative activities but is often not owned by a single entity or centrally managed. These data silos may hold data with probably conflicting data models or features (e.g., formats for dates, differences in entities, attributes, and relationships, differences in data quality and completeness), which reveals itself as a problem when data is to be exchanged in collaborative activities. Thus, we argue that device integration (Category 4), system interoperability (Category 5), and data integration (Category 8) are relevant across all MO-MS domains. Finally, we think that concept clarity (Category 10) should also generalize across MO-MS domains because the great variance of organizations and stakeholders involved in any MO-MS domain may come with great differences in languages, education, cultures, backgrounds, traditions, and terminologies. It is inevitable that such differences will lead to challenges in the understanding or interpretation of key concepts.

Peculiarities of the MO-MS Collaboration Design Concerns

Some of the ten categories of MO-MS design concerns might also apply to small-scale collaborations concerning distinct tasks in homogeneous organizational environments. However, we argue that each category represents a class of concerns that becomes increasingly relevant when collaboration takes place within heterogeneous organizational settings with a large number of stakeholders that aim to collaborate on suites of interdependent work practices. For example, for collaboration within a joint venture (a typical MO-MS collaboration domain), the variety of different necessary stakeholders is manifold and may include investors, shareholders, employees, consultants, customers, suppliers, trade associations, media, labor unions, lawyers, civil society organizations, governments, and policy makers. Within such contexts that yield many different stakeholders with various roles, design concerns regarding role variety (Category 1) become particularly challenging as the differences in roles can lead to conflicting levels of authority, responsibility, social status, or vested interests (e.g., the interests of investors may conflict with the interests of labor unions in a joint venture). The multitude of different stakeholders and roles also influences the relevance of user awareness (Category 7). The more stakeholders are involved in a MO-MS collaboration, the less clear will be the understanding that a collaborator has of other stakeholders’ expectations and activities as well as their impacts on their own activities. The number of involved stakeholders also affects the relevance of richness of system clues (Category 9). As more stakeholders are being involved in the MO-MS collaboration, more information may be produced and consumed. System designers can aim to optimize the media richness of various cues to clarify meaning while minimizing the cognitive load for collaborators. For instance, police and firefighters at a disaster scene may communicate best with terse, lean radio codes (e.g., we have a 1097 at 202 Beach St.), while paramedics might use rich audio-video to communicate the nature of a severe physical injury quickly and clearly.

Another special characteristic of MO-MS that influences some of the categories is the number of different organizations that are being involved. For example, higher numbers of involved organizations increase the likelihood that people must collaborate under different organizational goals, cultures, compliance standards, working conditions, time zones, working languages, local laws, local religions, etc. The broader the service perimeter (Category 2) is, the more complex will be the range of conditions, constraints, and contingencies that the collaborative work practices will have to accommodate (e.g., different local legal requirements, different company policies) and the more relevant will be design concerns of process adaptability (Category 6). The differences in organizational characteristics are furthermore potential risks to the timeliness of collaborative activities and, thus, make response time (Category 3) even more relevant in large scale MO-MS collaboration. As stated before, different organizations may come with incompatible technologies. For example, a disaster relief MO-MS collaboration might involve public administrations, nonprofits, industry, and private citizens, bringing together people with vast differences in resources, power, authority, education, and income, which may manifest in different technological preferences and possibilities. Thus, the greater the number of organizations involved, the greater the importance of attending to device integration (Category 4) will be. Different technologies may also foster the emergence of data silos with conflicting data formats due to the lack of unified standards. This may require collaborators to collect data as “puzzle pieces” to complete the data picture and enable collaborative value creation. By way of example, criminal investigations often draw data from across local, state, and federal jurisdictions, each with different data models. Designers of (MO-MS) collaboration systems will have to address the integration of data from each unique data silo which makes system interoperability (Category 5) and data integration (Category 8) even more relevant for large scale MO-MS collaborations. Finally, design concerns regarding concept clarity (Category 10) also scale with the number of organizations and stakeholders involved. The higher the number of organizations, stakeholders, and roles involved in large-scale MO-MS collaborations will be, the more the differences in language, educational backgrounds, perspectives, terminologies etc. will impede shared understanding. Thus, designers of MO-MS collaboration systems will need to find ways of fostering the understanding of key concepts among all stakeholders.

Contributions to Research and Practice

Our study yields some key contributions to research and practice that can be classified according to the Way of Thinking and the Way of Working of the CE approach [20]. We summarize these contributions in Table 6.

Table 6. Summary of key contributions.

Five Ways Framework	Previous gap in research	Key contributions
Way of Thinking	The preponderance of research in CE has focused on collaboration systems for distinct collaborative tasks in homogeneous organizational environments [22]. As of yet, we know only little about the peculiarities of collaboration systems in settings where multiple stakeholders across multiple organizations collaborate on suites of interdependent work practices such as in disaster relief [60], joint business ventures [45], the public sector [39], and also healthcare [77].	We introduced to CE research the distinct concept of MO-MS collaboration. MO-MS collaboration focuses on designing suites of interdependent collaborative work practices that may involve multiple organizations and multiple stakeholders. It requires particular considerations with regard to the design, implementation, and organization of collaboration systems.
Way of Working	Two main contributions to the CE design phase can be distinguished [22]. First, CE researchers have developed a design approach for the CE design phase, which provides its five necessary steps to design collaborative work practices [41]. Second, researchers developed the SLMC [11, 22], which became a high-level organizing structure for the multitude of constructs, metrics, theories, design concerns, and best practices in the CE domain [22]. However, contributions to the CE design phase have primarily been made for the design of distinct collaborative tasks [22]. We still lack concrete guidance for collaboration engineers (e.g., design concerns) when it comes to designing MO-MS collaboration systems.	We derived ten categories of design concerns that are important for MO-MS collaboration systems in healthcare. Thereby, our results reveal properties of MO-MS collaboration that require special attention compared to single collaborative work practices for distinct tasks. In addition, we draw on the broad applicability of the SLMC to derive the Category 0. The categories may serve as an entry point for the design process of MO-MS collaboration systems
		For each category of design concerns, we present probe questions that designers of MO-MS collaboration systems can use to improve the breadth and depth of the system requirements they derive.

Notes: CE, collaboration engineering; MO-MS, multiorganizational, multistakeholder; SLMC, six-layer model of collaboration.

By providing a rigorous definition for MO-MS collaboration and introducing specific examples from healthcare and other areas, we provide CE research with a new perspective on collaboration systems in settings where multiple stakeholders within and across multiple (globally distributed) organizations work on suites of interdependent work practices. By introducing this novel perspective, we contribute to CE literature that has been concerned with developing the Way of Thinking for the CE approach (i.e., research that laid the foundation and defined the design philosophy of the CE approach [20, 21]). Our main argument is that MO-MS collaboration requires separate scholarly inquiry due to various facets (e.g., differences of cultural expectations and norms, terminology, rules, standards, policies, regulations, laws, language, procedures, data models, politics, and time zone) that magnify the challenges of building shared awareness and shared understanding.

We derived and validated ten categories of MO-MS design concerns (and one foundational category based on the SLMC). For practice, our set of design concerns provides collaboration engineers with an entry point for the design process of MO-MS collaboration systems. We illustrate this in Online Supplemental Appendix 4, where we take a process perspective and provide an exemplary application of our design questions in the first two steps (i.e., task diagnosis; task decomposition) of the collaboration design phase. Furthermore, the descriptions as well as the derived probe questions can be used to improve the breadth and depth of requirements when designing such systems. Note that we only derive exemplar probe questions without claim to completeness. In general, designers can consider using all exemplar probe questions as provided. As argued above and shown in Online Supplemental Appendix 5, logic suggests that practitioners may apply our set of design concerns in MO-MS collaboration contexts beyond healthcare. A key issue in CE literature has been the question to what extent CE is culturally bound [22] and whether the influence of CE on the collaboration outcome is similar in different cultural backgrounds [14]. Some research, for example, suggests that Asian cultures show higher reluctance and lower diffusion rates than western cultures [22]. To counteract a potential cultural bias of the design concerns, we conducted interviews with MO-MS collaboration stakeholders in Europe and Asia which are regions that strongly differ with regard to cultural characteristics (e.g., power distance, individualism, and long-term orientation) [18, 37]. For MO-MS collaboration practitioners this is especially important since MO-MS collaboration is often global and includes multiple organizations from various countries with differences of cultural expectations and norms. Our approach enabled us to derive and confirm design concerns that hold for both cultural settings since the design concerns were validated with interview partners from both cultural backgrounds. Although we derived the set of design concerns to support collaboration engineers and stakeholders in designing new IT-supported collaboration systems, they may also be useful for other purposes, such as deriving criteria for the certification of health information systems or structuring content for medical education on the topic of collaborative healthcare. Overall, the set of design concerns builds on and contributes to existing CE literature that has focused on the design phase of CE [7, 8, 41,] to support the Way of Working within the Five Ways framework [20]. For research, our study also demonstrates the suitability of healthcare as a collaboration context for exploratory CE research inquiries that produce well generalizable results.

Limitations and Future Research

Our study is subject to limitations that open avenues for future research. First, we conducted the two rounds of semi-structured interviews only with professional stakeholders from healthcare—health IT experts and healthcare practitioners. Especially our first-round interviews had a strong focus on cloud-based collaborative care due to our assumption that the implementation-specific peculiarities of cloud-based health IT might yield specific design concerns. Although this assumption ultimately turned out to be false, we instead were able to compile a set of MO-MS design concerns in the healthcare domain that, as we outlined above, should generalize to other MO-MS collaboration domains as well. Nonetheless, future research should conduct further explorations with nonmedical stakeholders (e.g., insurance companies, suppliers, policy makers, patients, and their families). In this regard, it may be possible to discover and validate other classes of design concerns not uncovered by this study. It may also be useful to explore the degree to which our proposed set of design concerns can be adapted to other MO-MS domains by creating new domain-specific checklists of answers for the closed-ended and semi-closed questions. Second, our study has solely focused on MO-MS collaboration that is concerned with suites of interdependent collaborative tasks in heterogeneous organizational environments. Although it also seems likely that some or all of the design concerns reported here may be useful in the context of the smaller, more homogeneous contexts reported in prior CE research [21], further research will be necessary to explore that conjecture. Third, as we proposed MO-MS collaboration as a new challenging class of collaboration and aimed at identifying an initial set of design concerns our research was primarily exploratory in nature. It is upon future studies to investigate the usefulness of our results for CE practitioners and explore the degree to which the use of the design concerns can enhance the thoroughness with which system designers and stakeholders explore the problem and solution spaces of their MO-MS domains. Fourth, although we explicitly asked interviewees about the design concerns related to the three essential functions of collaboration, no clear picture emerged from our data. Thus, future research may be interested to further investigate this question and reveal potential causalities. Finally, this study examined MO-MS collaboration only in Germany and China. While we were able to validate our results for these two countries, which are highly different with regard to cultural characteristics, more may be learned by exploring design concerns for MO-MS in other countries as well. For example, North America has been a key driver of CE research and practice before and yields some cultural peculiarities in comparison to Germany and China that may be relevant to MO-MS collaboration (e.g., high levels individualism and very low levels of long-term orientation) [37].

Conclusion

In this study, we introduced the concept of MO-MS collaboration which focuses on designing suites of interdependent collaborative work practices that may involve multiple organizations and multiple stakeholders. While the concepts reported in the prior CE literature that have been derived to support smaller, more homogenous groups, are also essential to the design of MO-MS collaboration systems, MO-MS collaboration presents additional design concerns. In this exploratory study, we turned to the literature and conducted semi-structured interviews with practitioners from the field to derive a set of design concerns, design questions, and checklists for improving the breadth and depth of design requirements for IT-supported MO-MS collaboration systems. The set of design concerns should be a useful foundation for developing structured methodologies for collaboration engineers working in MO-MS contexts, and it may also be used as a conceptual foundation for developing certification standards for MO-MS collaborative healthcare systems and medical education content on healthcare collaboration. The set of design concerns provides a steppingstone for further research on the unique challenges of MO-MS collaboration.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Supplemental Data

Supplemental data for this article can be accessed online at https://doi.org/10.1080/07421222.2023.2172771.

Additional information

Funding

This research was partially funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation), Grant number: 442171588.

Notes on contributors

Scott Thiebes

Scott Thiebes ([email protected]) is a postdoctoral researcher at the Department of Economics and Management of the Karlsruhe Institute of Technology, Germany, where he also received his Ph.D. His primary research interests include emerging technologies in healthcare, information privacy and security, and persuasive health technologies. In his recent research, he explores the design and implications of trustworthy artificial intelligence in healthcare settings. Dr. Thiebes’s works have appeared in such journals as Electronic Markets, Business and Information Systems Engineering, ACM Transactions on Management Information Systems, the Journal of Medical Internet Research, JMIR mHealth, and others.

Fangjian Gao

Fangjian Gao ([email protected]) has been leading various international IT projects and initiatives at Bayer AG. He holds a Ph.D. in Information Systems from the University of Cologne, Germany. Dr. Gao’s research interests include Collaboration Engineering, health IT and cloud computing.

Robert O. Briggs

Robert O. Briggs ([email protected]; corresponding author) earned his Ph.D. in Information Systems from University of Arizona. He is the inventor of Computer Assisted Collaboration Engineering. Dr. Briggs researches the cognitive foundations of collaboration and uses his findings to create new collaboration systems and new collaborative organizational work practices. He is co-founder of Collaboration Engineering, co-inventor of the ThinkLets design pattern language, and co-developer of the six-layer model of collaboration. He has published more than 250 peer-reviewed papers related to economic, social, political, cognitive, emotional, and technological aspects of collaboration.

Manuel Schmidt-Kraepelin

Manuel Schmidt-Kraepelin ([email protected]) is a research associate at the Department of Economics and Management of the Karlsruhe Institute of Technology, Germany. His primary research interests include gamification and emerging technologies in healthcare. In his recent research, he focuses on the foundations of narratives in gamified information systems and their impact on health behavior change. His research appeared in such journals as Journal of Medical Internet Research, JMIR mHealth and uHealth, IEEE Access, Electronic Markets, and Nature Scientific Reports, as well as in the proceedings of the leading information systems conferences.

Ali Sunyaev

Ali Sunyaev ([email protected]) is Professor at the Karlsruhe Institute of Technology, Germany. His research interests include reliable and purposeful information systems within the scope of critical infrastructures, cloud computing services, information security solutions, trustworthy AI, auditing/certification of IT, and innovative health IT applications. Dr. Sunyaev’s research has appeared in such journals as Journal of Management Information Systems, Journal of Information Technology, Journal of the AIS, The Journal of Strategic Information Systems, European Journal of Information Systems, ACM Computing Surveys, and others. His research work has been featured in a variety of media outlets.