Engineering the Healthcare Collaboration Space

Engineering the Healthcare Collaboration Space Craig E. Kuziemsky Telfer School of Management University of Ottawa Ottawa, Canada kuziemsky@telfer.uottawa.ca Jens Weber-Jahnke, James Williams Department of Computer Science University of Victoria Victoria, Canada jens@uvic.ca, jamesbw@uvic.ca Abstract Healthcare delivery is highly collaborative work. Designing information and communication technologies to support collaboration is challenging due to the complex and dynamic nature of the healthcare collaboration space. In this paper we introduce collaboration engineering as a method for engineering the collaboration space that integrates Intentional Modeling and Interaction Design Theory. We use existing work to identify a set of intentions that define the healthcare collaboration space. We then use a case study to illustrate how our method would be used for engineering the healthcare collaboration space. Keywords-collaboration; engineering; systems design; common ground; intentional modeling; interaction design theory I. INTRODUCTION The healthcare system is increasingly based on collaboration and integration across multiple providers and settings. Accommodating this shift requires information and communication technologies (ICTs) that are able to support collaborative aspects of healthcare delivery. Although support for collaboration is sometimes considered in systems design, much of this work is ad-hoc, as it has not been based on any structured model of healthcare collaboration. ICT implementations in healthcare are frequently problematic, with a large source of these problems being collaborative issues related to communication, information exchange and process facilitation. We believe a key issue is that collaboration is complex and varies because of several factors including location, information sources, team structure, and setting. We suggest that collaboration must be engineered before we can design systems to support it. We introduce the term collaboration engineering to refer a method for engineering the healthcare collaboration space. II. BACKGROUND Healthcare delivery is highly collaborative work. To date the design of ICTs to support collaborative healthcare delivery has met with mixed results. Although there are examples of ICTs that support collaboration [1] it is more common for the introduction of ICTs into clinical settings to be problematic because it changes the nature of clinical processes. Implementation issues after ICT implementation include technology-induced errors [2], workarounds [3], power issues, and workflow disruptions [2-4]. These issues occurred because the systems were not properly engineered to support the collaborative interactions that are a major component of healthcare delivery. Although an ICT may be well engineered to support a specific task such as decision support or order entry, these tasks are part of a larger space. Coiera describes the communication space as being the sum of communication activities [15]. He suggests that to overcome the errors and other anomalies within this space we need to understand and at times reengineer it. We can make the same argument for collaboration. Collaboration care delivery is more than the task at hand; rather it is coordination of the task with the processes, information, protocols, provider skill sets and organizational policies that comprise the space. These activities and coordination points must be engineered as part of developing ICTs to support the collaboration space. Research at understanding the collaboration space can be put into two main categories. First are approaches for modeling collaborative activities. Examples of this work includes Collaborative Engineering (CE), which was developed to design collaborative work practices for high value recurring tasks, and to deploy those designs for practitioners to execute for themselves without ongoing support from professional facilitators [6]. CE is intended to support the design of tools to support collaboration processes by linking the implementation of collaborative patterns with specific outcomes [6]. Other modeling approaches are collaborative patterns and coordination protocols [7]. Patterns are generic and intended to design practice guidelines to provide structure to collaborative processes such as delegation and service assignment [7]. The second category of research are studies that have focused on specific collaboration tasks such as sense making, information retrieval and group decision making [8,9]. Despite these advances, the existing work on the collaboration space does have shortcomings. One is that research on sense making or information retrieval has focused on specific tasks of the larger collaboration space. Second, the research on modeling collaborative patterns, although useful for describing collaborative scenarios, is based on the premise of an ideal scenario of how a collaborative task should be laid out in flowchart form. For example, some of these patterns refer to contracts governing how individuals should interact with each other. These Patterns ignore the dynamic nature of collaboration and imply that rules and agreements for decision making already exist. Rather these factors are dynamic and may be evolving in an organization. Therefore they need to be engineered as part of systems design. 978-1-4673-1843-3/12/$31.00 c 2012 IEEE 51 SEHC 2012, Zurich, Switzerland

We believe the implementation of patterns in real healthcare settings will be plagued by the same issues as computer interoperable guidelines such as PROforma, Asbru and the Guideline Interchange Format (GLIF) in that they were useful for high level representation of healthcare delivery but did not scale down to the micro level of actual clinical work practices [10]. Patterns ignore key collaborative issues such as information reconciliation, group negotiation and decision making, and common goal setting. Collaborative care delivery has both static and dynamic components; both of these aspects must be considered as we engineer solutions to support collaboration. The use of patterns can be helpful, but rather than using predefined patterns we suggest that patterns need to be engineered to reflect the complex nature of collaborative care. The overall challenge to engineering the collaboration space is to be able to define the space while also considering the dynamic complexity of it. ICT in healthcare (and other domains) is not just technology. In addition to hardware and software, we must keep in mind the operating environment, including the agents (e.g., users, external systems) who interact with ICT in order to support a variety of new or existing business processes. In this spirit, we adopt an agentoriented perspective on engineering systems to support collaboration. In particular, this paper integrates two promising agent-based methods: (1) interaction design theory, and; (2) social requirements engineering. Coiera developed interaction design theory (ID Theory) to understand the relationship between agents and different types of interactions [5]. He challenges the practicality of arriving at an ideal system design because of the broad array of interactions where agents have to solve problems with imperfect resources. Although we cannot predict interactions at the level of a particular agent, (since each agent has her own constraints, goals, etc), Coiera believes that we can formulate of model of the various interactions involved in the system at a population level [5]. This model can allow systems designers to make predictions about how the system (including the agents) will respond to changes. Social requirements engineering methodologies seek to augment traditional systems engineering activities by focusing on the intentional aspects of information systems, As stated by Yu et al, [t]he central premise is that to arrive at systems requirements, that is, to conceive what systems to build, one should examine and understand the relationships among social actors Rather than focusing on the behavioural properties of software, as in a mechanistic system, we should raise the level of abstraction and ask how the system will advance the relationships that some actors have in relation to other actors [11]. The same authors state that it is infeasible to model the "what" and "how" in complex socio-technical systems to a large degree of precision [11]. However, they suggest that it is often feasible to model the intentions or motivations of a system to understand why it is being designed and the context the system needs to work within. The intention model becomes a meta-model on which other systems are designed. We believe we can improve the engineering of the collaboration space by combining Intentional Modeling with ID Theory. Intentions will help us understand the goals that collaborative care delivery needs to achieve, while the different types of interactions can help us predict where issues will occur in collaboration engineering. Our paper does three things. First, we use case studies and literature to identify a set of collaborative intentions to define the healthcare collaboration space. Second, we describe our integration of Intentional Modeling and ID Theory for engineering the collaboration space. Third, we provide proof of concept of our integrated method using a case study that focuses on communications channels. III. METHODS A. Data Sources Our data sources consist of several studies of collaboration and a literature review. One of the authors (CEK) has studied collaborative care in several settings including palliative care, pediatric care, acute care, and home care. These studies provide empirical perspectives on collaboration. We also did a literature review of collaborative care delivery. Collaborative care literature can be put into two broad categories. The first category consists of national or regional studies that identify broad outcomes for collaborative care delivery. [12]. The second category consists of studies that have analyzed specific settings, processes or technology to identify what needs to be done to support collaborative care delivery [13, 14]. B. Data Analysis We used content analysis to analyze the literature and concepts from the case studies to develop a list of collaborative concepts. The concepts identified the need for collaborative care delivery to be provided by high functioning teams that are well integrated across different providers and settings. In doing our analysis we first identified broad categories of collaborative concepts that were common in our data sources. We then did further analysis to identify specific collaborative intentions (i.e. information, communication) and then identified the goal and subject of each intention. C. Presentation of Findings Our results are presented in two sections. In section IV we present the results of our analysis from part B of section III as a set of collaborative intentions to define the collaboration space. We then introduce common ground to formalize the intentions. In section V we integrate interaction modeling and ID Theory to engineer the collaboration space based upon various types of common ground. In section VI we use a case study to illustrate our proposed integration of ID theory and intentional modeling. IV. COLLABORATION SPACE AND COMMON GROUND A. Collaboration Space and Intentions The result of our analysis from part B of section III was the identification of four specific collaborative intentions to define the healthcare collaboration space. Despite the vast- 52

TABLE 1. Collaboration Space Intentions Collaborative Goals (What) Subject (Why) Intentions Information Information infrastructure Ensure information is available for requisite task Interoperability and integration Provide care in teams and in distributed settings Communication Shared mental model Diversity of actors providing care Channel configuration for a task Multiple communication channels Team formation Configuration of collaborative team Appropriate resourcing for care delivery Skill set allocation for a Safe care delivery task Care delivery Goal development for each unique case Dynamic nature of collaborative care delivery -literature on healthcare collaboration, we identified four common collaborative intentions: information exchange, communication, team formation, and care delivery. Each intention has a goal (i.e. what we want to achieve) and a subject (i.e. why we need to achieve the goal). Table 1 shows the four collaborative intentions with its goals and subjects. B. Collaboration Space and Common Ground Our next step was to use the intentions as a basis for engineering the collaboration space. A fundamental concept in collaboration is the notion of common ground, which refers to shared meaning amongst agents that is needed to carry out a task [15]. Much of the early work on common ground focused on its role as a communication facilitator [15]. Subsequent studies have expanded the role of common ground to include information seeking [16], and as a facilitator of team communication processes [17]. Common ground is an ideal concept for framing collaborative intentions. As shown in table 1, collaboration is about integrating diverse actors, information, settings, and tasks. This integration can be looked at as different types of common ground including information, communication protocols, task and technology common ground. V. INTERACTION DESIGN THEORY AND INTENTIONAL MODELLING As described in the previous section, the collaboration space is a complex array of concepts that can be integrated through common ground. In this section we integrate ID Theory with intentional modeling to allow us to model that integration. ID theory and intentional modeling were both motivated by the propensity of traditional design methods to produce idealized models of the processes that govern complex socio-technical systems. In the two sections below we discuss intentional modeling and ID Theory, followed by our rationale for integrating the two approaches. A. Intentional Modelling Intentional modeling has its roots in the agent-oriented design community and is concerned with analyzing why agents carry out activities. This is in contrast to traditional approaches to process modeling, which primarily focus on what activities agents perform and how they perform them. Typical intentional modeling approaches use a goalbased paradigm, i.e., they model and decompose goals, desires and beliefs of social agents. The identification of goals can inform systems design in several ways, including: (a) identifying missing requirements; (b) identifying conflicts between the intentions of users and planned functional requirements, and; (c) providing context for the interpretation of requirements. Goals can also represent specific moments when common ground is needed. The i* (Intentional STrategic Actor Relationships modeling) method is perhaps the most widely adopted approach in this domain [11]. The two main type of i* models are strategic dependency (SD) models and strategic rationale (SR) models. SD models analyze how the various goals of actors depend on the participation of other actors, resources provided, or tasks performed by them. SR models analyze how tasks performed by actors are motivated by external strategic dependencies. The term actor is not restricted to humans, but may also refer to technology. SR models represent collaborative complexity through task decomposition and relationships between actors. Figure 1 provides an example SD model that shows strategic dependencies in a hospital setting. Each dependency is represented by a directed connection between two actors, which are depicted as circles. Each dependency also describes a dependum, which characterizes the nature of the dependency. The dependum is shown in the middle of the connection and can be one of the following types: A Goal dependency (dependum has oval shape) describes that the dependent requires the dependee s participation in attaining the specified goal. For example, the patient (dependent) depends on the provider (dependee) for treatment (goal), and a provider (dependent) may depend on another provider (dependee) to take over treatment (goal) in case of staffing changes (Fig. 1). A Soft goal dependency (cloud shape) specifies a goal that does not have a clear cut definition in terms of when it can be considered attained. For example the goal to gain contextual knowledge about a patient in our model does not have a clear-cut definition as to when it satisfied. A Resource dependency (rectangular shape) denotes that the dependee needs to provide a certain resource to the dependent. In our example model, the provider depends on the lab results (resource) being provided by the lab (dependee). A Task dependency (hexagon) specifies that the dependent requires the dependee to execute the specified task. In our model, the provider depends on the nurse to administer prescribed drugs. SD-models also specify how different goals contribute or conflict with each other. Since a full description of these contribution links is beyond the scope of this paper, we will limit ourselves to the description of examples. In Fig. 1, the arrow between the lab results resource and the gain 53

contextual knowledge soft goal represents a so-called means-end link, specifying that lab results provide a means that contributes to gaining knowledge about a patient case. Figure 1. SD-model. An example, where two goals are in conflict is marked by the break link between take over treatment and gain contextual knowledge. The latter case specifies the fact that handing over treatment to a new provider generally means that the new provider is (initially) not as familiar with the patient case as the former provider. Figure 2. SR-model. Fig. 2 exemplifies how the SD-model in Fig. 1 can be refined into a more detailed model showing how the tasks performed by the actors are motivated by strategic inter-actor dependencies. For that purpose, each actor s shaded bubble shows tasks performed. These tasks may be broken down into subtasks using and/or relationships. Tasks may also contribute to or conflict with other tasks. Note also how in Fig. 2 we have introduced three new computational actors to facilitate typical computer-supported interactions within hospitals, namely the writing of prescriptions (Computerized Provider Order Entry CPOE), the management of lab results (Laboratory Information System LIS) and a general patient chart (Electronic Medical Record EMR). These three new computerized actors refine and replace the dependums marked with ICT in Fig. 1. New strategic dependencies (i.e. common ground between people and technology) arise from the introduction of these computerized tools. Subsequently their introduction has caused the addition of a new soft-goal entitled gain knowledge of how to use ICT in Fig. 2. B. Interaction Design Theory (ID Theory) ID Theory is concerned with modeling and understanding the nature of interactions between actors (human or otherwise) [5]. ID Theory attempts to assess the impact of introducing ICT tools in actor-driven interaction processes, following a guiding principle as described by Winograd and Flores: In creating tools we are designing new conversations and connections [18]. Similar to intentional modeling, ID theory admits that it is generally infeasible to precisely model all relevant interactions in complex systems such as health care. However, Coiera states that while we cannot predict every specific interaction that will occur in the real work environment, the design process can model the typical interaction space within which any new system will be introduced. [5, pp 207]. Coiera discusses different impacts that interactions can have on each other. Interactions may: (1) compete with another interaction as a direct substitute; (2) compete with another interaction for the resources of an agent; (3) create new information transfer pathways, through a combination of interactions; (4) support another interaction by providing resources critical to its execution. [5] Key to understanding constraints on interactions is the notion of communication channels, which are used as vehicles to facilitate interactions (i.e. the formation and maintenance of common ground). Channels have limited bandwidth and may be subject to noise, interference and disruptions. The extent human actors adopt the use of channels available to them is determined by the individually perceived cost and benefit of associated with using them. Coiera provides a simple equation to estimate the resources (cost) required for interacting via a channel, namely: where C is the channel resource cost, m denotes the length of a message, t denotes the time duration allowed for the interaction and G E is called the grounding efficiency. Coiera notes that interactions are more efficient (terse) the more the communicating agents share common knowledge (common cognitive ground): Grounding efficiency is a measure of the resource requirements for an interaction between two agents, all else being equal, and can be thought of as the average length of messages sent between them divided by the true message length. [5, pp 212] Referring back to our example model in Fig. 2, we distinguish between two types of cognitive grounding, namely cognitive knowledge about a particular patient case (C-GROUNDING) and cognitive knowledge about proper usage of the deployed ICT (T-GROUNDING). We note that Coiera does not distinguish between technological grounding and problem-specific grounding. However, we feel that this distinction is useful in practice, since many safety-related incidents with health ICT are related to inappropriate use of those technologies. It may also be useful to model the grounding of health providers with respect to general medical knowledge (not case specific). For reasons of simplicity, we do not further explore this aspect in this paper. Coiera makes a central observation on ID Theory, namely that the use of channels for interactions is governed by laws that are similar to those economic laws that govern 54

supply and demand in free markets [5]. Actors will generally tend to minimize their interaction costs as long as the received benefits from the interaction are deemed acceptable. We will integrate this notion of ID Theory into intentional modeling in the following section and illustrate its application for the analysis of interactions in a real-world case study. C. Integrating ID Theory and Intentional Modelling Intentional modeling provides the approach for modeling the collaborative intentions from table 1. Intentional modeling represents the interaction between actors and information and how tasks such as communication or team member configuration occur to achieve goals (using SD and SR models). However the achievement of goals through interactions such as information retrieval, communication or team formation will depend upon common ground between the actors and dependencies. ID Theory complements intentional modeling in that identifies the specific factors that impact the formation of common ground, and provides a means for reasoning about how actors are likely to behave. VI. CASE STUDY We use a case study to illustrate our proposed integration of ID Theory and intentional modeling. In particular, we concentrate on the communications channels available, and how the actors would likely use them. This analysis provides a simple model of how to reason about collaboration in systems. Since we do not have space to enter into a thorough discussion of all the ways in which ID Theory can be used in the context of systems design, we restrict ourselves to working with the concepts of communications channels and common ground. Despite this limitation, we believe that our case study highlights the promise of our integrated approach. The case study itself is based on a serious medication error that occurred at the New York Prebyterian Hospital, as reported in detail by Horsky et al [19]. In terms of our collaborative intentions from table 1, the case study involves team based care delivery. On Saturday morning, the physician on duty at the pulmonary service unit (Provider A) examined routine laboratory test results of an elderly patient that showed a serum KCl of 3.1 meq/l and correctly diagnosed the patient as hypokalemic (low potassium value). She ordered an intravenous (IV) bolus injection of 40 meq of KCl (potassium chloride) to be delivered over 4 hours. Shortly after entering the order, Provider A realized that the patient already had an IV fluid line inserted and therefore decided to deliver the KCl as an additive to the currently running IV fluid, in order to make the interaction less painful for the patient. Consequently, she entered a new order to infuse 100 meq of KCl in 1 L of drip solution at the rate of 75 ml/hr. Intending to cancel the preceding order for an injection, Provider A inadvertently discontinued a similar order that was entered by another clinician two days ago. Later, Provider A received a call from the pharmacy, notifying her that the dose of the new drip order exceeded the maximum limit allowed by hospital policy. She consequently discontinued the drip order and wrote a new drip order for fluid medicated with 80 meq/l KCl. However, this order was not entered correctly: the intended volume limit of 1L was not properly specified in the order, which lead to a continued administration of KCl over 36 hours, delivering a total of 216 meq KCl (36 x 75 ml = 2.7 L; 2.7 x 80 meq = 216 meq). Including the first bolus of 40 meq KCl, the patient had inadvertently received a total of 256 meq KCl over 36 hours. On Sunday morning, Provider B took over the office from Physician A, who notified the incoming officer to check the patient s KCl level. Provider B reviewed the patient s most recent available serum potassium value, which was 3.1 meq/l. Even though the date and time (i.e., Saturday, the previous morning) of the result were displayed on the EMR screen, Physician B did not realize that the test result was in fact from before the last potassium repletion and acted as though the patient was hypokalemic. He ordered an additional 60 meq KCl to be given as an IV injection, even while the previous potassium drip was still running. Order entry logs also indicated that another 40 meq KCl IV injection was ordered by Provider B about 30 minutes later, but there is no clear evidence from other sources that it was in fact administered to the patient. As a result, the patient received a total of 316 meq KCl over 42 hours. On Monday morning, when the KCl laboratory values were checked, the patient was found to be severely hyperkalemic (serum K level at 7.8 meq/l). 1) Applying ID-Theory and Intentional Modelling The case study summarized above reflects the intentional SD and SR models in Fig 1 and Fig 2. Let us now consider how we can use ID Theory to understand some weaknesses of the collaboration space at New York Presbyterian Hospital that may have contributed to the medication error. For this purpose, we model the actors in our SR model in more detail, while also annotating the model with attributes from ID Theory. We refer to the resulting model as a strategic interaction (SI) model. Fig. 3 shows an SI model for our example. Since we have modified the notation in i*, several comments are in order: Green (solid) lines indicate dependency relations that are preferred by actors. In our simple construction, these can be thought of as the pathways that will be used. Red (dashed) lines indicate dependency relations that are not preferred by actors. In our simple construction, these can be thought of as the pathways that will not be used. Smeared lines represent dependencies with noise. Noise is an important consideration. Annotations detail the knowledge requirements. GrC denotes C-GROUNDING (cognitive knowledge about a particular patient case), while GrT denotes T-GROUNDING (cognitive knowledge about proper usage of the deployed ICT). Each is low, medium or high. 55

The SI model shows a more detailed refinement of the CPOE computational actor, which comprises two main prescription order screens: one for injection orders and one for drip medication orders. Each screen has an interface for entering structured (codified) data, as well as an interface for adding unstructured comments in free text. The CPOE also has a screen that provides a history of all orders. ICT resource dependencies such as the ones in Fig. 3 can be viewed as distinct potentially alternative, competing, conflicting or complementary, channels in the sense of IDtheory. The CPOE essentially adds a channel through which providers and nurses communicate prescription orders. (If prescriptions may also communicated out of band by telephone, email or personal communication, such a channel should be added to the SI model. Since many hospitals today require the use of a CPOE, we omit this alternative). We can see from Fig. 3 that providers have two main channels for communicating prescription orders to nurses: one for issuing injection orders and one for issuing drip fluid orders. Each channel can be seen as having two subchannels: one for structured information entry and one with unstructured (free text) entry. Referring to table 1, the CPOE supports information integration by integrating information with the task (i.e. order entry); however, communication integration suffers because of the alternative channels. B. Attributing channels with ID-Theory properties To understand how the multiple communication channels impact engineering of the collaboration space we now annotate the channels in the SI model with attributes from ID-theory. ID-theory will identify the grounding costs associated with the different channels to help us understand why a certain channel may be preferred over another one. To keep our example simple, we are using only three types of attributes: (1) the grounding requisite for the patient case (GrC); (2) the grounding requisite for the technology use (GrT), and; (3) the noisiness of the channel. A grounding requisite can be defined as a measure for the amount of cognitive knowledge that an actor must possess in order to communicate with the channel. Consequently, the grounding requisite can be defined as reciprocal to Coiera s grounding Figure 3 SI model for the NewYork Presbyterian Hospital Case Study efficiency measure. For the sake of simplicity, we are only considering qualitative values for GrC and GrT in our model (low, medium, high). Based on Horsky s report about the medical error, we made the following modeling decisions: GrC is generally higher for writing to the Drip Order channel, as the provider requires knowledge about the existence of a pre-existing drip line at the patient s site. GrT is lower for writing to the unstructured order channels, as they allow for free text input. On the receiving end of the CPOE channels, GrT is equally low for all channels, as data values are always interpreted according to the same, relatively simple schema. However, GrC is higher for receiving orders in unstructured (free text) format, as free text leaves room for interpretation and may contain diverse measurement units, terminologies and ambiguities. The Order History channel has low GrT and GrC at the input side (nurse) but high GrT at the output end (provider), because the channel provides significant noise (shown as a smeared line). All orders for the entire hospital are presented and the provider must know how to search for and filter the right order. A similar observation can be made with respect to the lab test interaction channel. An analysis of the collaboration space using the attributed SI model and the laws of ID theory indicates a problem in terms of a mismatch of the interaction channels: Providers with limited grounding in knowledge on how to use the CPOE (i.e. low information common ground) are more likely to use the unstructured information channels to communicate important details, while nurses are more likely to refer to the structured information channels with little attention spent on the free text comments. Providers with limited grounding in knowledge of a patient case, (e.g., providers who just took over a 56

patient case from another provider) are more likely to use the injection order interface. The receiving channels of the LIS and the CPOE order history are noisy and should not be relied upon for critical communication functions, unless proper grounding (technical and case specific) can be ensured for providers. VII. DISCUSSION Engineering the healthcare collaboration space is challenging for two main reasons. First, the space is a complex array of collaborative intentions including information, communication, team members and tasks. Second, these intentions are dynamic in nature. Static modeling approaches such as patterns will not accurately represent this aspect. This paper introduced collaboration engineering as a method for engineering the collaboration space. Our method consists of a set of collaborative intentions to define the space and the integration of intentional modeling and ID Theory to model the intentions. We also used the notion of common ground to understand how collaborative intentions are impacted by various interactions. For example, the workarounds and the other unintended consequences described in section II occurred because of a lack of common ground between the actors, the ICTs they were using and the tasks the actors were conducting. Our case study demonstrated that common ground also helps understand why actors may use particular communication channels over others. For example, providers with limited grounding knowledge on the CPOE system (T-Grounding) were more likely to use unstructured communication channels. The lack of T-Grounding can impact collaboration by altering how communication tasks take place. While we cannot predict per say what particular actors may do in different circumstances, we can gain an understanding of how they may use channels by: (a) modeling interactions; (b) determining the types of common ground needed to support the interactions, and (c) making use of a formalism to predict the behaviour of actors given the interactions and common ground requirements. Intentional modeling allows us to capture goals, relationships and dependencies, while ID theory (even in the simple form that we have presented) provides machinery for making predictions about how agents will behave at a population level. A limitation of the paper is that we only considered communications channels. Future work will extend our method by including other concepts in ID theory, and by using more sophisticated formal tools (e.g. game/decision theory or simulation) for providing a means of reasoning about the behaviour of actors. CASE tool support will likely be required. We also intend to use our method to design ICTs to support collaboration. A. Acknowledgment CEK acknowledges funding support from a discovery grant from the Natural Sciences and Engineering Research Council of Canada. REFERENCES [1] M.C. Reddy, M.M. Shabot and E. Bradner, Evaluating collaborative features of critical care systems: A methodological study of information technology in surgical intensive care units Journal of Biomedical Informatics, 41, 2008,479 487. [2] J.S. Ash, M. Berg, and E. Coiera, Some Unintended Consequences of Information Technology in Health Care: The Nature of Patient Care Information System-related Error J Am Med Inform Assoc, 11, 2004, 104 112 [3] J.S. Ash, D.F. Sittig, E.G. Poon, K. Guappone, E. Campbell, and R.H. Dykstra, The Extent and Importance of Unintended Consequences Related to Computerized Provider Order Entry J Am Med Inform Assoc, 14, 2007, 415 423 [4] R. Koppel, T. Wetterneck, J.L. Telles, and B-T Karsh, Workarounds to Barcode Medication Administration Systems: Their Occurrences, Causes, and Threats to Patient Safety Journal of the American Medical Informatics Association, 15 (4), 2008, 408-423 [5] E. Coiera, Interaction design theory International Journal of Medical Informatics, 69, 2003, 205-222 [6] R. O. Briggs, G. L. Kolfschoten, G. J. d. Vreede, and D. L. Dean, "Defining Key Concepts for Collaboration Engineering," in Americas Conference on Information Systems, Acapulco, Mexico, 2006, pp. 121-128. [7] M.A. Grando, M. Peleg, M.Cuggia, and D. Glasspool, Patterns for collaborative work in health care teams Artificial Intelligence in Medicine, 53, 2011, 139 160 [8] S.A.Paul, M.C. Reddy, and C.J. DeFlitch, Information and communication tools as aids to collaborative sensemaking 28th Annual CHI Conference on Human Factors in Computing Systems; Florence; 5 April 2008 through 10 April 2008 [9] M. Reddy, and P.R. Spence, Collaborative information seeking: A field-study of a multi-disciplinary patient care team Information Processing and Management, 44(1), 2008, 242 255 [10] F.A. Sonnenberg, and C.G. Hagerty, Computer-interpretable clinical practice guidelines. Where are we and where are we going? Yearbook Med. Inform, 2006, 145 158. [11] E. Yu, P. Giorgini, N. Maiden, and J. Mylopoulos, Social Modeling for Requirements Engineering: An Introduction 2011. MIT Press [12] Institute of Medicine. Crossing the quality chasm: a new health system for the twenty-first century.washington, DC: National Academies Press; 2001 [13] D.A. Dorr, S.S. Jones, and A. Wilcox, A framework for information system usage in collaborative care Journal of Biomedical Informatics, 40, 2007, 282 287 [14] D. D Amour, L. Goulet, J.F. Labadie, L. San Martin-Rodriguez, and R. Pineault, A model and typology of collaboration between professionals in healthcare organizations, BioMed Central Health Services Research, 8, 2008, 188. [15] E. Coiera, When conversation is better than computation J.Am. Med. Inform. Assoc, 7 (3), 2000, 277 286. [16] M. Hertzum, Collaborative information seeking: The combined activity of information seeking and collaborative grounding Information Processing and Management, 44, 2008, 957 962. [17] G. Convertino, H.M. Mentis, M.B. Rosson, J.M. Carroll, A. Slavkovic, and C.H. Ganoe, Articulating common ground in cooperative work: content and process Proceedings of 26th AnnualACMConference on Human Factors in Computing Systems. 2008:1637 46. [18] T. Winograd, and F. Flores, Understanding Computers and Cognition, Addison-Wesley, Boston, 1986. [19] J. Horsky, G. Kuperman, and V. Patel. Comprehensive analysis of a medication dosing error related to cpoe. Journal of the American Medical Informatics Association, 12(4), 2005, 377-382 57