528822 research-article2014

JHI0010.1177/1460458214528822Health Informatics Journal X(X)Winge et al.

Article

The coordination hub: Toward patient-centered and collaborative care processes

Health Informatics Journal 2015, Vol. 21(4) 284­–305 © The Author(s) 2014 Reprints and permissions: sagepub.co.uk/journalsPermissions.nav DOI: 10.1177/1460458214528822 jhi.sagepub.com

Monica Winge, Paul Johannesson, Erik Perjons and Benkt Wangler Stockholm University, Sweden

Abstract The organization and processes of today’s health and social care are becoming ever more complex as a consequence of societal trends, including an aging population and an increased reliance on care at home. One aspect of the increased complexity is that a single patient may receive care from several care providers, which easily results in situations with potentially incoherent, uncoordinated, and interfering care processes. In order to describe and analyze such situations, the article introduces the notion of a process conglomeration. This is defined as a set of patient-care processes that all concern the same patient, that are overlapping in time, and that all are sharing the overall goal of improving or maintaining the health and social well-being of the patient. Problems and challenges of process conglomerations are investigated using coordination theory and models for continuous process improvement. In order to address the challenges, a solution is proposed in the form of a Coordination Hub, being an integrated software service that offers a number of information services for coordinating the activities of the processes in a process conglomeration.

Keywords Care processes, health care, home care, processes coordination, social care

Introduction Today’s health and social-care systems face a number of challenging trends that contribute to their increased complexity. One trend is that the population in developed countries is aging, which results in more people suffering from multiple diseases.1,2 Many of these people are being cared for in their homes due to both individual preferences and need for cost containment. This adds to complexity as health and social care at home typically requires that many care parties with different specialties are involved, private as well as public ones.3–5 Not only is health care required but also

Corresponding author: Monica Winge, Department of Computer and Systems Sciences, Stockholm University, SE-164 40 Kista, Stockholm, Sweden. Email: [email protected]

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

285

Winge et al.

social care with assistance for daily living.6,7 Furthermore, informal care parties such as family members and neighbors obtain a more prominent role for support and mediation.8 In this complex care environment, multiple care parties are hence engaged in concurrent and asynchronous processes for investigating, treating, and assisting a patient. The complex environment results in situations where care is provided through an aggregation of potentially incoherent, uncoordinated, and interfering processes.3–5,7 In order to represent and analyze these emergent aggregations of processes, we introduce the notion of a process conglomeration consisting of separate and more or less independent care processes. In a process conglomeration, the patient may experience problems such as multiple care parties visiting at the same time, different care parties prescribing conflicting treatments, or care parties neglecting their responsibilities. In order to overcome the problems and challenges of process conglomerations, multiple complementing solutions are needed. Some solutions aim at improving administrative and organizational structures and processes, while others focus on attitudes and behaviors among personnel. There are also solutions that address reimbursement models and incentive structures. In this article, we focus on information and communication solutions that enable multiple care parties and patients to collaborate effectively. The main goal of the article is to propose the functionality of a Coordination Hub, an integrated software service offering a set of information services, which can facilitate effective and seamless communication between care parties in process conglomerations, thereby supporting patient-centered collaboration. The structure of the article is as follows. Section “Related work in health-care informatics” covers related research in health-care informatics and outlines how our work adds to the existing body of knowledge. Section “Theoretical foundations” introduces foundations that are used to explicate the notion of process conglomerations and to design solutions for their management. Section “The process conglomeration challenge—an analysis” introduces and discusses a number of challenges occurring in process conglomerations. Section “The coordination hub—solution outline and requirements” outlines a solution to these challenges in the form of a Coordination Hub offering information services for process coordination and identifies key requirements on these services. Section “The coordination hub—information model and information services” describes and classifies the information services based on an underlying information model. Section “Challenges and benefits” investigates challenges and benefits of the Coordination Hub and discusses its feasibility. Section “Concluding remarks” concludes the article by summarizing its results, drawing conclusions, and suggesting directions for future work.

Related work in health-care informatics Mettler and Raptis9 identified three main areas of research in health-care informatics. The area that has received most attention is e-health and clinical systems, including their design, implementation, and use. This area has an emphasis on interdisciplinary research in the intersection within and between health-care organizations as well as between health-care organizations, the service industry, and government. The second area is personal health and independent living, which investigates the use of information technology outside health-care organizations with a focus on nonmedical professionals, for example, social-care personnel as well as informal care parties and patients. The third area explores cross-sectional topics including educational, societal, economic, and behavioral aspects of health information systems. Our work is situated within the areas of e-health and clinical systems, as well as personal health and independent living. The Collaboration Hub proposed in this article builds on results from the areas of Business Process Management (BPM) and of Coordination Theory. Most work on BPM in health-care informatics has been carried out within the area of e-health and clinical systems, thereby focusing on

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

286

Health Informatics Journal 21(4)

improving organizational performance, medical effectiveness, and knowledge exchange within and between care institutions.10 An example of such work is the study by Abraham and Reddy,11 which investigated challenges to coordination between clinical and nonclinical staff in the patient transfer process based on a field study at a major academic hospital. Much less work on process management has been carried out within the area of personal health and independent living. In particular, no work has, to the best of our knowledge, addressed the problems that arise when several similar, interdependent, and concurrently ongoing processes are carried out by independent health and social-care providers. Several researchers have addressed the issue of success factors and barriers to collaboration in health care, where trust, status concerns, information sharing, and security are recurring themes. Van Eyk and Baum12 studied interagency collaboration among health-care organizations and found that the factors most important in collaboration were personal contact and networking, mutual respect and credibility, accessibility, and the sharing of information. Lichtenstein et al.13 studied the effect status differences have on individual members in cross-functional teams, and they hypothesized that the suppression of participation among low status team members leads to poor crossfunctional team functioning. Åhlfeldt14 derived, based on interviews with health-care staff and patients, a set of information security–related problems in connection with collaborative care. Most of these are related to administrative routines and policies and not to technology. In this article, we have focused on information sharing and identified a set of knowledge deficiencies that causes problems in process conglomerations. Health information technologies have been suggested as a means for improving collaboration, as information sharing is key for successful collaboration. The most commonly used technology for this purpose is electronic medical records (EMRs). However, it has been argued that EMRbased systems are not able to adequately support collaboration. O’Malley and Pham15 argued that EMRs are able to facilitate within-office care collaboration, but that they are less able to support collaboration between clinicians across organizational settings. Furthermore, managing information overflow from EMRs is, for clinicians, a challenge. It is also argued that current EMRs cannot adequately capture the medical decision-making process and future care plans to support collaboration. Thus, there is a need to move beyond EMRs and make use of care plans,15 as proposed in the design of the Coordination Hub. Various architectures have been proposed for realizing systems and services that support collaboration in care. Raghupathi and Kesh16 proposed a service-oriented architecture for EMR design. Davis and Blanco17 suggested for clinical workflow systems an agent-oriented architecture, where so-called compliance agents ensure that activities are carried out according to plan. To ensure compliance, the agents may issue reminders and alerts. The architecture makes use of various artifacts, in particular documents such as care plans and assessments. This work is similar to ours, as it moves beyond EMRs and recognizes the importance of care plans. However, it focuses on architectural issues including the construction of the workflow system, while our work focuses on the communication needs of care parties, that is, the functionality of the Coordination Hub. There is also work that investigates nonfunctional requirements on systems supporting patient care, for example, Russ et al.18 investigated characteristics of workflow systems that support patient-care processes. They concluded that key requirements concerned trustworthiness and reliability, effective display, ubiquitousness, and adaptability to work demands.

Theoretical foundations This section introduces models, theories, classification frameworks, and standards for process and service management, which are used as foundations for problem analysis and solution design.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

287

Winge et al.

A process is here defined as a partially ordered set of activities that are to be carried out in order to achieve some particular goal.

Continuous process improvement—Plan–Do–Check–Act cycles In order to realize high-quality care, patient-care processes need to include assessment, reflection, and change in continual iterations. A promising candidate for modeling patient-care processes is, therefore, the Plan–Do–Check–Act (PDCA) cycle, which has been used in many organizations for the control and continuous improvement of products and processes.19 The PDCA cycle is reminiscent of the scientific method with its steps of hypothesis, experiment, and evaluation. The steps included in the PDCA cycle are as follows: •• Plan—this step is to establish goals and plan activities in order to achieve desired results. •• Do—this step is to carry out the planned activities. The step is also to collect data for subsequent analysis in the check and act steps. •• Check—this step is to investigate actual results and compare them to expected ones in order to identify differences. •• Act—this step is to analyze differences between actual and expected results to determine root causes. It is also to identify possible changes, that is, acts, in particular process modifications. There exist several variants of the PDCA cycle in the literature, and in this article, we will introduce a variant that includes an explicit Assess step for judging the social and health status of a patient.

Coordination theory In order to work smoothly, activities in processes need to be coordinated. A broad definition of coordination is “the act of working together harmoniously.”20 One way of making this more precise is to note that processes concern common goals and that the process participants should respect dependencies that may exist between the activities of processes. Thus, Malone and Crowston20 suggest the following definition of coordination: “the act of managing interdependencies between activities performed to achieve a goal.” Such dependencies may give rise to conflicts and need to be detected and resolved. There are three main kinds of activity dependencies: •• Flow dependencies. A flow dependency between two activities occurs when one of the activities needs to be carried out before the other one, often because the first activity produces some resource required by the other one. An example is that contrast fluid needs to be injected before a patient is X-rayed. •• Share dependencies. A share dependency occurs when two activities at the same time try to obtain exclusive access to the same resource. An example is when two physicians want to use the same X-ray machine at the same time, or when two actors need to have access to a patient at the same time. •• Fit dependencies. A fit dependency occurs when two activities modify the same resource and need to ensure that the modifications are consistent and coherent, taking into account the overall needs and constraints of the resource. An example is when a patient is given two medicines that interfere with each other.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

288

Health Informatics Journal 21(4)

Classification of information services Supporting the communication among actors in a process conglomeration will require a number of different information services. Structuring and organizing these services can be facilitated by means of a classification framework for information services, such as the one proposed by Bordewijk and Van Kaam.21 This framework does not classify information services based on their technical properties, but instead focuses on the social relationships among actors in a communication network, in particular with regard to the control of information resources and the initiation of communication. Starting from the assumption that there is an information service center and a set of information service consumers who need to communicate with each other, Bordewijk and Van Kaam21 identify four communication patterns: allocution, consultation, conversation, and registration. Allocution.  Allocution means that the center distributes information to consumers based on its own initiative. The information is controlled by the center as well as the topic and timing of the communication. An example is an information service center reminding a care provider about an activity that has not yet been carried out. Consultation.  Consultation means that a consumer searches for and receives information from the center. The consumer has control over the timing and topic of the communication, but the center controls the information. An example is a specialist physician searching for and retrieving existing care plans from an information service center. Conversation.  Conversation means that two or more consumers communicate directly with each other, without the center being involved. The consumers control the timing and topic of the communication as well as the information being transferred. An example is two care parties calling or sending mails to each other to address a share dependency, where the two parties require simultaneous access to a patient. Registration.  Registration means that the center requests, receives, and collects information from the consumers. Thus, registration can be seen as the opposite of consultation. The center controls, at least to some extent, the timing and topic of the communication, but the information being collected originates with the consumers. An example is a home-care provider registering the planned weekly activities for a patient. The four communication patterns are summarized in Figure 1.

Health-care standards The concepts introduced in this article are, to a large extent, based on the health-care standard CONTSYS, which is an International Organization for Standardization (ISO) standard representing both the content and context of health-care services. CONTSYS includes concepts covering actors, health-care issues, clinical and administrative health-care processes, responsibility, and record and data management.22 In this article, we have used and adapted the CONTSYS standard. We have only included concepts from CONTSYS needed for our purposes. Some relations between concepts have also been changed. When concepts needed have not been found in CONTSYS, new concepts have been introduced, mainly based on results from the Supporting Collaboration in Health Care (SAMS) project,23 which investigated patient-centered collaboration between care parties in health and social care.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

289

Winge et al. Communication initiated by the center

Communication initiated by consumers

Information controlled by the center

Allocution

Consultation

Information controlled by consumers

Registration

Conversation

Figure 1.  A classification of information services.

Figure 2.  A classification of actors involved in health and social care.

The process conglomeration challenge—an analysis This section introduces the notion of process conglomerations as well as the challenges they give rise to. Before addressing these issues, a classification of the actors involved in health and social care is introduced, see Figure 2. A health/social-care party (also referred to as care party) is a person or organization that is involved in health/social care. There are three kinds of care parties: patient, health/social-care provider, and health/social-care third party. A patient is a care party that receives or can receive health/ social care. Note that a patient also can perform care activities to support himself or herself. A health/social-care provider (also referred to as care provider) is a person or organization that provides health/social care professionally. A health/social-care third party (also called informal care party) is a person or organization that supports care services and is not a professional health/socialcare party. An example could be a relative or a neighbor to a patient performing some of the care activities needed for taking care of the patient. Finally, a care provider can be of two types: health/ social-care organization or health/social-care professional. A health/social-care organization (also

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

290

Health Informatics Journal 21(4)

Check

Assess

Do

Plan

Figure 3.  The patient-centered care process.

referred to as care organization) is a private or public organization providing care as its main service, while a health/social-care professional (also referred to as care professional) is a person providing care in her professional role.

The patient-centered care process The work carried out by one care provider for one patient can be described as a variant of the PDCA cycle, see Figure 3, depicting the patient-centered care process (PCCP). A PCCP is initiated by a care request from a health-care party, for example, a patient, to a care provider, for example, a general practitioner. The PCCP describes the process steps of the care provider, called the provider of the PCCP. The process contains the steps Assess, Plan, Do, and Check, which are carried out iteratively. The main difference from the original PDCA cycle is that we rename the Act step as Assess and let the process start with this step. This is required in a patient-centered process, as understanding a patient’s current situation is needed as a prelude to taking investigative or interventionary action. Assess.  In the Assess step, the care provider of the PCCP identifies the patient’s care status, that is, anamnesis, symptoms, and ongoing treatments, and determines the patient’s problems. Thereafter, the care provider decides on the needs of the patient and the goals of the care to be provided. The goals are typically about affecting the patient’s health and social situation through intervention activities, or increasing the knowledge about the situation through investigation activities. The patient is involved in the discussions and the decisions together with the care provider. Plan.  In the Plan step, the care provider, together with the patient, aims at creating a care plan for addressing the patient’s problems and achieving the goals that have been decided in the Assess step. The Plan step determines which care activities are to be carried out and outlines a time plan for their execution. Do.  In the Do step, each activity in the care plan needs to be performed by either the care provider of the PCCP or another care party. If the activity is performed by the care provider of the PCCP, it will both schedule the activity and then perform it. If the activity is to be performed by another care party, a care request is sent to this party asking it to be responsible for the activity. The receiving party checks whether it can take responsibility for the activity and, if so, sends a commitment to the requester. The receiving party then needs to start another PCCP to carry out the activity, since it needs to assess the patient, plan the activity before carrying it out, and also check its result. This

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

291

Winge et al.

Figure 4.  A process conglomeration, that is, a set of individual although interdependent care processes around a patient.

PCCP is nested within the first one. When the receiving party has carried out the nested PCCP, it sends an activity completion message to the requester. Check.  In the Check step, the care plan is evaluated. This is done by investigating the outcomes of the performed care activities of the plan, as they have been recorded in the Do step. Differences between actual and expected outcomes are identified and recorded. The care provider also analyzes the outcomes in order to identify the causes for deviations from the care plan. Based on these causes, suggestions for changing the care goals and care plan can be generated. These are then used in subsequent iterations of the PCCP. In summary, the Check step aims at evaluating a care plan, while the Assess step focuses on the patient status, problems, and goals.

The process conglomeration A single patient is often involved in several PCCPs at the same time. One reason for this is that one PCCP can be nested within another as a consequence of one care party requesting another care party to carry out some activities. Another reason is that a patient can be subject to a number of more or less independent PCCPs, each being conducted by a separate care party. This may happen when the patient suffers from and is treated for multiple problems. A set of independent PCCPs around a patient will form a process conglomeration, see Figure 4, which includes activities that are potentially incoherent, uncoordinated, and interfering. More precisely, we define a process conglomeration as a set of PCCPs that all concern the same patient, that are overlapping in time, and that all have the goal of improving or maintaining the health and social well-being of the patient. Process conglomerations give rise to coordination problems that go beyond those encountered in single or nested PCCPs. In a single PCCP, the activity dependencies are known beforehand as the activities are carried out by the same care party. In nested PCCPs, several care parties are involved, but they know with whom to communicate in order to manage activity dependencies. In conglomerations, however, the activity dependencies may occur unexpectedly for the care parties involved, who may have limited knowledge about each other. An example is a patient with multiple diseases who is treated by several health- and social-care parties, including relatives and neighbors, that are only partially aware of each others’ activities. While each PCCP is internally coordinated in the form of a PDCA-like cycle with a clear structure and distribution of responsibilities, there is no corresponding coordination across the PCCPs in a process conglomeration. Thus, dependencies between

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

292

Health Informatics Journal 21(4)

activities of different PCCPs may easily be neglected, which may cause worries and inconveniences for the patient as well as ineffective and inefficient care. Furthermore, as many parties are involved in a process conglomeration, responsibility issues may arise. In general, there is a limited understanding of how a process conglomeration should be turned into a patient-centered and collaborative process ensemble. Based on coordination theory and previous work,24 we have identified four main categories of problems in a process conglomeration: •• Share negligence. Two or more care parties undertake to provide care to a patient at the same time. In other words, the parties try to carry out activities between which there exists a share dependency. For example, a patient may be busy with her physiotherapist when a nurse shows up to plaster a leg ulcer. •• Flow negligence. Two care parties carry out activities in the wrong order. In other words, there is a flow dependency between activities that is not respected by the care parties. For example, a nurse first plasters the leg ulcer of a patient, and then the home-care personnel gives the patient a shower, while these activities ought to be carried out in the reverse order. •• Fit negligence. Two activities are carried out although they may conflict with each other. In other words, there is a fit dependency between activities that is not respected. For example, a patient is prescribed a medication at the hospital that is not suitable in combination to another ongoing medical treatment prescribed by primary care. •• Responsibility negligence. A health-care party who is responsible for a task does not carry it out or carries it out in an unsatisfactory way. For example, a nurse may not distribute prescribed medication to a patient, although this is her responsibility. If responsibility distribution is unclear, or shared between several parties, there is a risk that each one thinks that some other party performs the care action, and hence, it may not be carried out at all. The underlying causes to these problems may vary, including deficiencies in organizational structures and gaps in personnel competence. However, in a process conglomeration, a main cause for the problems is lack of information, knowledge, and shared understanding due to inadequate communication. The lack of knowledge and shared understanding may vary from complete unawareness of issues to minor discrepancies between assessments. Based on the activities of the PCCP as well as previous work in Winge,25 we have identified seven categories of knowledge deficiencies that cause problems in process conglomerations: 1. 2. 3. 4. 5. 6.

Lack of knowledge and shared understanding about the problems and status of patients; Lack of knowledge and shared understanding about care goals and their priorities; Lack of knowledge about planned activities; Lack of knowledge about ongoing and performed activities; Lack of knowledge about care plan evaluation; Lack of knowledge about activity dependencies between planned, ongoing, and performed activities; 7. Lack of clearly allocated responsibilities and knowledge about them.

The coordination hub—solution outline and requirements In order to address the information and communication problems of process conglomerations, we suggest a solution in the form of a Coordination Hub, which is an integrated software service with the responsibility to support coordination in a process conglomeration. The Coordination Hub

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

293

Winge et al.

offers a number of information services to the participants of the conglomeration that support them in exchanging information, building shared understandings, distributing responsibilities, and managing activity dependencies. In order to deliver the services, the Coordination Hub carries out a number of information processing tasks with a focus on comparing assessments done by different care providers, detecting activity dependencies, and monitoring that evaluations are carried out, registered, and checked. In the following, a number of requirements are identified that the information services of the Coordination Hub need to fulfill in order to effectively address the conglomeration problems. The requirements (abbreviated R) are structured according to the problem causes they address.

Lack of knowledge and shared understanding about the problems and status of the patient In a process conglomeration, different care parties will make different assessments of the problems and status of a patient depending on their specialties and perspectives. Therefore, the information services should enable exchange of information about these assessments as well as discussions and negotiations about them: R1: Care parties shall be able to communicate about their assessments on the problems of a patient. R2: Care parties shall receive support for detecting, discussing, and negotiating differences in their assessments of the problems of a patient. R3: Care parties shall be able to communicate about their views on the status of a patient. R4: Care parties shall receive support for detecting, discussing, and negotiating differences in their views on the status of a patient.

Lack of knowledge and shared understanding about care goals and their priorities In a process conglomeration, different care parties may have different views on care goals even if they agree on the problems of a patient. Therefore, the information services should enable communication about goals as well as mechanisms for detecting and managing different views on goals: R5: Care parties shall be able to communicate about the care goals for activities carried out by care parties. R6: Care parties shall receive support for detecting and managing care goal conflicts, that is, goals for a patient that cannot all be fulfilled at the same time.

Lack of knowledge about planned activities In a process conglomeration, several care parties plan and carry out activities that other care parties need to know about. Therefore, the information services should enable exchange of information about planned activities: R7: Care parties shall be able to communicate about planned care activities. R8: Care parties shall receive support for discussing and negotiating differences in their views on activities to be planned.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

294

Health Informatics Journal 21(4)

Lack of knowledge about ongoing and performed activities In a process conglomeration, several care parties carry out activities that other care parties need to know about. Therefore, the information services should enable exchange of information about ongoing and performed activities. R9: Care parties shall be able to communicate about ongoing and completed care activities.

Lack of knowledge about care plan evaluation In a process conglomeration, several care parties evaluate their care plans as well as the program of care of a patient (see section “Coordination hub information model”). Therefore, the information services should enable communication about plan evaluations so that care parties can adapt their work accordingly. R10: Care parties shall be able to communicate about plan evaluations. R11: Care parties shall receive support for detecting, discussing, and negotiating differences in their views on plan evaluations.

Lack of knowledge about activity dependencies between planned, ongoing, and performed activities In a process conglomeration, dependencies often exist among its activities. Therefore, the information services should enable detection and management of activity conflicts due to activity dependencies. R12: Care parties shall receive support for detecting and managing activity conflicts.

Lack of clearly allocated responsibilities and knowledge about them In a process conglomeration, the borders of responsibility may be fuzzy. Therefore, the information services should support care parties in clearly communicating about the distribution of responsibilities. R13: Care parties shall be able to communicate about the responsibilities of care providers. R14: Care parties shall receive support for detecting and managing responsibility negligence as well as other responsibility conflicts.

The coordination hub—information model and information services This section describes the foundations, contents, and use of a Coordination Hub. The first subsection introduces an information model for structuring the information to be managed by the information services of the Hub. The second subsection describes the basic information services offered by the Hub and shows how they address the requirements of the previous section. The third subsection discusses how these basic information services can be combined with each other in different health-care scenarios.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

295

Winge et al.

Coordination hub information model The proposed information model for the information services of the Hub is described below and shown as a unified modeling language (UML) class diagram in Figure 5. The information model focuses on care planning and activity coordination among care parties involved in a process conglomeration. The description of the model is structured according to the requirements of section “The coordination hub—solution outline and requirements”. The first group of requirements in section “The coordination hub—solution outline and requirements” demands that the information services be able to manage information about the problems and status of patients. To handle this, the information model includes the class health/social issue (sometimes abbreviated issue). A health/social issue is a need for health/social care for a patient as defined by a care provider, often expressed as a diagnosis. A health/social issue is either an atomic issue or a combination of issues, called issue complex. The latter notion is useful as patients often experience a number of related issues, which can be effectively addressed by the same care plan. The information model also includes the class health/social status (sometimes abbreviated status), which contains a description of a patient’s symptoms. The health/social status also includes anamnesis and descriptions of earlier relevant treatments in the patient’s care history. The third, fourth, and sixth groups of requirements demand that the information services be able to manage information about activities and activity dependencies. To handle this, the information model includes a class activity with subclasses care activity and management activity. A care activity is an activity that delivers care to a patient and is consciously carried out with the intention to fulfill the care goals of a plan. Around a care activity, various care parties carry out management activities that can be seen as driving the care activity forward. In order to represent these, we introduce a class management activity. A management activity is an activity that results in a commitment or obligation for some care activity. An example could be a patient who visits her general practitioner and complains about back pains. The doctor finds that an X-ray should be carried out. She then initiates a management activity together with a local hospital by checking for available time slots and booking one of them. This results in an obligation for the hospital to X-ray the patient. There exist a number of subclasses to management activity: •• A care decision is a decision taken by a care professional that a certain care activity is to be carried out. A care decision is primarily an obligation for the care organization of the healthcare professional toward a patient stating that the organization is responsible to see to it that the care activity is carried out. However, it may be undecided who is actually to plan and perform it. •• A care request is a management activity where one care party asks another care party to take on the responsibility for a care activity. •• A care commitment is a commitment by a care party, who has received a care request, that it takes on the responsibility for the care activity. The commitment is directed at the requesting care party. •• An activity scheduling includes a commitment by a care party to start carrying out a care activity at a point in time. •• An activity initiation includes a declaration by a care party that a care activity has started. •• An activity cancellation includes a declaration that a care activity has been aborted before completion and that no further work on it is planned. •• An activity pending includes a declaration that a care activity has been aborted before completion as well as a commitment that it is to be restarted. •• An activity completion includes a declaration that a care activity has been completed as intended.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

Health Informatics Journal 21(4)

Figure 5.  An information model representing the information needed by the services.

296

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

297

Winge et al.

To represent activity dependencies, the information model includes associations for flow dependency, fit dependency, and share dependency. In practice, these dependencies often occur between activities defined in different plans. To handle planned activities, the information model includes the class plan. A plan can be seen as an agreement between a patient and one or several care parties about goals and activities addressing a health/social issue. If the plan involves only one care provider, it is called a care plan. If several care providers are involved, it is called a program of care. A plan is always established for the benefit of one patient and is based on his or her status. A plan addresses a single health/social issue, but this can be an issue complex as described above. The second group of requirements demands that the information services be able to manage information on care goals. To handle this, the information model includes the class health/socialcare goal (sometimes abbreviated care goal). Each plan is related to one or several of these goals. Care goal conflicts are represented by an association conflicts. The information model is also able to represent evaluation results, that is, how well the enactment of a plan has fulfilled the care goals, thereby addressing the fifth group of requirements. The seventh group of requirements demands that the information services be able to manage information about responsibility allocation. Responsibilities may concern both plans and activities. For a plan, there is exactly one care organization responsible for it, but other care parties may also participate. Furthermore, for each plan, there is exactly one care professional responsible for it. For care activities, it is possible that different care parties may have different responsibilities for the same care activity. For example, one care party can decide that a certain care activity is to be carried out, while another care party can accept to actually perform it. From a coordination perspective, it is of interest to monitor care activities that are open in the sense that there exists an obligation for a care provider to act upon them. More precisely, an open activity is a care activity for which there exists a care request but as yet no care commitment, or for which there exists a care commitment but no activity completion or activity cancellation.

Coordination hub information services The Coordination Hub is to offer a number of information services to the participants of a process conglomeration. These services are not limited to coordination in a narrow sense, that is, only managing dependencies between activities. In addition, the Hub supports collaborative decision making and sensemaking among care providers. Sensemaking is, here, taken to be the process of arriving at situational awareness and understanding of complex and uncertain situations, typically with the goal of providing a basis for making decisions. Collaborative sensemaking occurs when multiple actors with different views and goals try to jointly assess a situation in order to arrive at a common understanding. As discussed by Jordan et al.,26 sensemaking through conversation is a key instrument for succeeding with intervention efforts in health care. Collaborative sensemaking plays a main role in managing process conglomerations, as they are highly complex and as common views on patient problems and needs are critical for providing adequate care. The Coordination Hub services proposed should support communication among the Coordination Hub and the care parties. Therefore, it is helpful to classify the services according to the framework by Bordewijk and Van Kaam,21 which clarifies the roles played by the Hub and the care parties in a service. The services should also support all the steps of the PCCP. By combining the framework by Bordewijk and Van Kaam21 and the steps of the PCCP, the Hub services can be organized in the matrix shown in Figure 6. In addition to the services offered by the Hub, the matrix also includes a column (named “Internal processing task”) specifying a number of information processing tasks

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

298

Health Informatics Journal 21(4) Internal processing task (supporting the internal activities of the Hub)

Allocution services (supporting the Hub in informing and governing the participants)

Consultation services (supporting the participants in obtaining information from the Hub)

Conversation services (supporting the participants using the Hub as a medium for dialogue)

Registration services (supporting the participants in providing information to the Hub)

Assess

- Detect care goal conflicts and differences in the assessment of status and problems

- Notify about status, problems, and care goals (R1, R3, R5) - Inform on differences in views on status and problems as well as care goal conflicts (R2, R4, R6)

- Pose and answer questions about status, problems, and care goals (R1, R3, R5)

- Create common views on status and problems, and resolve care goal conflicts (R2, R4, R6)

- Register status, problems, and care goals (R1, R3, R5)

Plan

- Detect activity conflicts

- Notify about activity conflicts (R12)

- Pose and answer questions about care plans and activity conflicts (R7, R12)

- Create common views on activities to be planned (R8) - Resolve activity conflicts (R12)

- Register care plans and planned activities (R7)

Do

- Detect open activities - Detect activity conflicts

- Notify about open activities and activity conflicts (R12, R14)

- Pose and answer questions about performed activities, open activities and activity conflicts (R9, R12, R13, R14)

Resolve activity conflicts Address open activities (R12, R14)

- Register care activities and management activities (R9)

Check

- Analyze care activity outcomes and detect deviations from plan - Identify causes for deviations

- Notify about care activity outcomes, deviations from plan, and causes for deviations (R10, R11)

- Pose and answer questions about care activity outcome and causes for deviations (R10)

- Create common views on activity outcomes and causes for deviations (R11)

- Register care activity outcomes and causes for deviations (R10)

Figure 6.  Coordination Hub information services.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

299

Winge et al.

performed internally by the Hub. The requirements addressed by the services are specified within parentheses. The first row of the matrix contains tasks and services that are to support the coordination of activities in the Assess step. An internal task performed by the Hub is to detect differences and conflicts in the assessments made by the care providers in the PCCPs of the process conglomeration. These assessments concern the status of the patient, her problems and needs, as well as the goals of the care to be provided. One service, an allocution service, is to notify some or all participants of the PCCPs about patient status, issues, and care goals as well as about significant differences and conflicts in the assessments of these. There are also services for consultation, where PCCP participants can ask questions about assessments and get them answered by the Hub. Furthermore, the Hub provides conversation services for supporting sensemaking among the PCCP participants with regard to patient status, issues, and care goals. These services may offer chat and video conference sessions as well as support for asynchronous communication. This does not mean that the Hub will replace face-to-face meetings but rather complement them with other forms of communication. Finally, the Hub requires and enables the PCCP participants to register information about their assessment of patient status, issues, and care goals. The second row of the matrix contains tasks and services that are to support the coordination of activities in the Plan step. An internal task is to detect conflicts among the planned activities in the process conglomeration. Such conflicts are due to activity dependencies, for example, if two PCCPs plan treatments that are contraindicated. One service, an allocution service, is to notify PCCP participants about activity conflicts in which they are involved. There are also services for consultation, where PCCP participants can ask questions about planned activities as well as activity conflicts and get them answered by the Hub. The Hub offers conversation services through which PCCP participants can discuss and resolve activity conflicts. The Hub also requires and enables the PCCP participants to register information about planned activities, including changes in plans. The third row of the matrix contains tasks and services that are to support the coordination of activities in the Do step. An internal task is to detect open activities as well as activity conflicts due to activity dependencies. There are also allocution services for notifying PCCP participants about open activities and activity conflicts that have been identified. The Hub offers services for consultation, where PCCP participants can ask questions about planned activities, open activities, and activity conflicts. Furthermore, the Hub provides conversation services for resolving activity conflicts and addressing open activities. Finally, the Hub requires and enables the PCCP participants to register information about activities that have been carried out. The fourth row of the matrix contains tasks and services that are to support the coordination of activities in the Evaluate step. An internal task of the Hub is to identify significant deviations from plan, as indicated by PCCP participants. An allocution service notifies other PCCP participants about such deviations. The Hub also offers consultation services for answering questions about evaluation results, including deviations. The Hub provides conversation services through which PCCP participants can discuss and reason about evaluation results in order to arrive at a common understanding. Finally, the Hub requires and enables the PCCP participants to register evaluation results, in particular deviations from plan. The Coordination Hub is depicted in Figure 7 including the various kinds of services it can provide. In addition to the above services, the Hub offers consultation services by which PCCP participants can view the logs of communication that have taken place through the above services. For example, they can view questions to and answers by the Hub as well as conversations among other PCCP participants. These consultation services will contribute to improved sensemaking, as care

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

300

Health Informatics Journal 21(4)

Figure 7.  The Coordination Hub and the kinds of services it offers.

providers can view and track how other care providers have discussed and reasoned about the status, issues, and care goals of a patient.

Coordination hub scenarios The proposed information services of the Coordination Hub can be used in isolation but they can also be combined with each other or used in conjunction with other services. The use of the Hub services for a number of scenarios is given below, which also demonstrates the feasibility of the Hub. Open activity detection.  The Coordination Hub can detect open activities, that is, care activities for which there exists a care request but as yet no care commitment, or for which there exists a care commitment but no activity completion or activity cancellation. For example, there exists an open activity if a care provider, such as primary care, has requested a care activity from a specialist care provider (in the form of a referral), but the specialist has not committed to carry it out. The Coordination Hub can then inform both the primary care and the specialist care provider about the lack of a care commitment. This message can, if needed, be repeated after some predefined time. The Coordination Hub can also provide both the care providers with conversation services, so they can start to communicate with each other about managing the open activity. Dependency detection.  The Coordination Hub can detect flow, share, or fit activity dependencies. For example, if one care provider adds a dentist examination to a patient’s plan, this can be registered at the Coordination Hub. If this activity is scheduled some days before a minor surgery that requires a few days rest as a preparation, the Coordination Hub can inform the care provider about

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

301

Winge et al.

this fit dependency conflict. The care provider can then reschedule the dentist appointment and record this using registration services. She can use consultation services by posing questions about planned activities in the patient’s near future. The care provider can also use conversation services to contact the care party that planned the surgery in order to better understand the preparation requirements for the surgery. Care goal conflict detection.  The Coordination Hub can help detect care goal conflicts among the care providers of a patient, that is, goals for a patient that cannot all be fulfilled at the same time. For example, suppose that one care party has stated the goal that a patient should be able to dress herself, while another care party has stated the goal that the joints of the patient should not be strained. These two goals may be in conflict, and the Coordination Hub can then inform the care parties about the potential conflict. The Coordination Hub can also provide conversation services so that the care parties can contact each other to create a common view on the patient’s goals and status. Program of care establishment.  The Coordination Hub can support the establishment of a program of care for a patient. First, a consultation service can be used for identifying all care parties involved in the care of the patient. Second, conversation services for creating common views on activities to be planned can be used to establish the program of care. Third, a registration service can be used to publish the program of care. Finally, the Coordination Hub can detect activity and care goal conflicts as well as differences in views on patient problems and status. It can then notify the care parties about these through an allocution service.

Challenges and benefits The Coordination Hub offers a number of benefits to different stakeholders, that is, patients as well as care providers and informal care parties. Patients will receive benefits like safe and efficient care, improved information about their health status and care activities, and a hassle-free interaction with care providers. Care organizations will receive benefits in terms of reduced cost and risk exposure, improved care results, legal compliance, and improved learning through smooth cooperation with other care parties. Care professionals will obtain a better understanding of their role in the whole, which in turn will result in increased professionalization. Informal care parties will also benefit in ways similar to those of patients. Although the Coordination Hub can offer substantial benefits for all involved stakeholders, these benefits can be unevenly distributed among them. The costs for developing and governing the Hub can be unevenly distributed as well. Therefore, there may exist stakeholders who have strong incentives to support a Coordination Hub introduction while others do not. This may hamper investing in a Coordination Hub, despite the fact that the total benefits for all stakeholders would by large exceed the total costs. A solution to overcome this problem is that the government and care insurance companies become aware of imbalances in cost–benefit distributions and are prepared to remedy these through specific incentive programs. Another issue is interoperability between the Hub and other systems. It should be noted that the Hub primarily provides a set of services to support common care planning and follow-up, and hence the coordination of care actions. It could, therefore, be implemented and used as a standalone tool having its own structured database and user interfaces, thereby also making its services available in a mobile setting. Implementing the Hub in this way should be straightforward. It may, however, force users to enter certain data twice, that is, once into the Hub and then again into an EMR or other systems that the care provider or the patient use.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

302

Health Informatics Journal 21(4)

In addition to EMR systems, systems for keeping track of one’s own personal health record (PHR) become ever more important, as the patient and his or her relatives and friends are key actors in the patient’s own care process. New tools to help doing this appear regularly. In other words, personal health information management (PHIM) systems as discussed by Civan et al.27 would also benefit from interacting with the Coordination Hub. As a consequence, the Coordination Hub needs, in the long run, to be interfaced to existing systems in such a way that while maintaining the programs of care in local storage, it updates or retrieves the information that is relevant in other systems. At the same time, it may also serve as a single point of entry into all systems. The integration may, however, be done in a stepwise manner by letting, for example, existing EMR or PHIM systems be interfaced one by one, mapping their data and functionality onto the hub. Doing this may be a complex undertaking but can be facilitated by careful use of standards such as CONTSYS when building the Hub. Precisely which information needs to be exchanged between the Hub and other systems is a matter for further research. To protect privacy and integrity, availability to the Coordination Hub services need to be controlled through standard authentication and authorization procedures, such that read/write rights in each case can be restricted to precisely those actors in need of the specific information. However, elaborating this further is outside the scope of this article. Another issue to be addressed is the one of user acceptance in a real-world setting of hospitals, advanced home-care units, primary care centers, and municipal social care. For example, if the Hub requires that users need to perform a number of extra tasks, there is a risk that it will not be used. Technology acceptance theories emphasize that a novel technology will more likely be used if users think that it is easy to use, and actually helps them to perform their tasks. These theories also claim that if social influence is strong, that is, there is a strong expectation from others on a user to use the technology, he or she will be more likely to use it.28 Furthermore, change management models emphasize the need for providing support and reward structures for users when introducing a new system.29 Therefore, a well-designed introduction process is key for the successful use of the Hub. The Hub should be introduced in a stepwise manner, involving just a few parties to begin with, and then adding more as resources and time allow. Training and motivating the users are also important in making them understand the benefits offered by the Hub. Another concern for the feasibility of the Coordination Hub is the issue of organizational responsibility. The Hub will help monitor and coordinate PCCPs by seeing to it that activities are carried out in an orderly manner, and that conflicts between the PCCPs are resolved. However, the Hub, being solely a software artifact, only has the power to notify care professionals when some issue needs to be resolved. To actually make any suggested actions happen is the responsibility of the care professionals caring for the patient. This gives rise to a key question: Will the use of a Coordination Hub by all involved care providers around a patient in itself be sufficient to turn a fragmented process conglomeration into a well-coordinated, collaborative, and patient-centered process ensemble? We believe that the answer to this question is likely to be no, as the Coordination Hub does not have the power to distribute responsibility and to solve responsibility issues. To fully overcome the challenges of a process conglomeration and make the Coordination Hub feasible in practice, one care provider needs to take the overall coordination responsibility. This conglomeration leader may be one of the involved care providers, or a separate organizational function, and it should have the power of seeing to it that 1. A planning conference involving representatives of all involved care parties is initiated, including the patient himself or herself or his or her representatives. The conference is supported by the Hub conversation services and may be never-ending and at times

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

303

Winge et al.

2. 3. 4. 5.

synchronous and otherwise asynchronous. The planning conference is to result in a program of care. A program of care including the overall patient-care goals is developed and when needed changed according to new assessments of the patient status. Overall assessments of the patient status are done according to the program of care and based upon previous care evaluations. Overall evaluations of the patient status and results of care activities are carried through as planned. Activity conflicts and open activities are addressed.

Thus, the coordination function is responsible for the overall coordination of a conglomeration. The authorities of the coordination function may vary. In one extreme, the function may have the right to unilaterally decide how to resolve any conflicts among the PCCPs in the conglomeration, which includes prioritizing between activities as well as delaying or cancelling them. In the other extreme, the powers of the coordination function may be restricted to informing process participants about tasks to be carried out as well as potential conflicts and suggesting ways of resolving them. We envisage that the latter alternative will be more attractive in most care settings. However, precisely what are the alternatives for the coordination function and how it could be organized is outside the scope of this article.

Concluding remarks In this article, we have investigated how care activities and processes are organized in today’s complex health- and social-care landscape. The main theoretical contribution of the article is the notion of process conglomeration, which is used to capture the emergent nature of care provisioning in an environment of independent care parties. Providing seamless and well-coordinated care in a process conglomeration poses a number of challenges, in particular for patients with multiple diseases. The article also provides a practical contribution in the form of a proposal for a Coordination Hub that offers a set of information services aiming to overcome the challenges of process conglomerations. A key benefit of the Coordination Hub is that its services can be used for creating and maintaining an overall program of care for the patient. This facilitates identifying and overcoming problems with contraindications and goal conflicts. Furthermore, patient-centered goals formulated as part of the program of care make it possible to evaluate the complete patient situation. This evaluation in turn can be used to assess and fine-tune the patient-care plan, thus making the process of conglomeration work as a well-coordinated ensemble of processes, which together aim to improve the status of the patient. Our work has been carried out according to the design science framework, which is also reflected by the structure of the article that follows the methods proposed by Peffers et al.30 and by Johannesson and Perjons.31 Our work so far has focused on problem analysis, requirements definition, and solution design. The next step will be to implement and evaluate a prototype of the Coordination Hub. Some of the proposed services have already been developed and evaluated in a health-care setting,32 although not in the frame of the Coordination Hub, the theory of coordination, and the concepts of process conglomerations. Our experience and reflections from this empirical work have heavily influenced the present solutions, meaning that our work to a large extent has been carried out according to the guidelines of action design research, as suggested by Sein et al.33 In order for the Coordination Hub to work efficiently and effectively, it is required that care providers actually work according to the PCCP. In particular, implementing the Hub will then not

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

304

Health Informatics Journal 21(4)

require much additional information management. This is because the bulk of the information needed by the Hub is produced in the already-existing PCCPs, which structure the internal work of a care provider and its interactions with a patient. Declaration of conflicting interests The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The research presented in this article has received support from Vinnova—Swedish Governmental Agency for Innovation Systems in several projects.

References 1. Bodenheimer T, Chen E and Bennett HD. Confronting the growing burden of chronic disease: can the U.S. health care workforce do the job? Health Aff 2009; 28(1): 64–74. 2. Gibson TB and Blumenthal D. Multiple chronic conditions: prevalence, health consequences, and implications for quality, care management, and costs. J Gen Intern Med 2007; 22(3): 391–395. 3. Bodenheimer T. Coordinating care—a perilous journey through the health care system. N Engl J Med 2008; 358(10): 1064–1071. 4. Reid RJ and Wagner EH. Strengthening primary care with better transfer of information. CMAJ 2008; 179(10): 987–988. 5. Smith PC, Araya-Guerra R, Bublitz C, et al. Missing clinical information during primary care visits. JAMA 2005; 293: 565–571. 6. Cameron A, Lart R, Bostock L, et al. Factors that promote and hinder joint and integrated working between health and social care services. Research Briefing, Social Care Institute for Excellence, 41, May 2012. 7. Rigby M. Integrating health and social care informatics to enable holistic health care. In: Proceedings of the 9th international conference on wearable micro and nano technologies for personalized health, Porto, 26–28 June 2012, pp. 41–51, IOS Press. 8. Levine C. Rough crossings: family caregivers’ Odysseys through the health care system. New York: United Hospital Fund, 1998. 9. Mettler T and Raptis DA. What constitutes the field of health information systems? Fostering a systematic framework and research agenda. Health Informatics J 2012; 18(2): 147–156. 10. Lenz R and Reichert M. IT support for healthcare processes—premises, challenges, perspectives. Data Knowl Eng 2007; 61(1): 39–58. 11. Abraham J and Reddy MC. Moving patients around: a field study of coordination between clinical and non-clinical staff in hospitals. In: Proceedings of the 2008 ACM conference on computer supported cooperative work (CSCW ’08), San Diego, CA, 8–12 November 2008, pp. 225–228. New York: ACM. 12. Van Eyk H and Baum F. Learning about interagency collaboration: trialling collaborative projects between hospitals and community health services. Health Soc Care Community 2002; 10(4): 262–269. 13. Lichtenstein R, Alexander JA, Mccarthy JF, et al. Status differences in cross-functional teams: effects on individual member participation, job satisfaction, and intent to quit. J Health Soc Behav 2004; 45(3): 322–335. 14. Åhlfeldt RM. Information security in a distributed healthcare domain: exploring the problems and needs of different healthcare providers. PhD Thesis, University of Skövde, Skövde, 2006. 15. O’Malley AS and Pham HH. Are electronic medical records helpful for care coordination? Experiences of physician practices. J Gen Intern Med 2010; 25(3): 177–185. 16. Raghupathi W and Kesh S. Interoperable electronic health records design: towards a service-oriented architecture. e Serv J 2007; 5(3): 39–57.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

305

Winge et al.

17. Davis JP and Blanco R. Analysis and architecture of clinical workflow systems using agent-oriented lifecycle models. In: Silverman DBG, Jain DA, Ichalkaranje DA, et al. (eds) Intelligent paradigms for healthcare enterprises (studies in fuzziness and soft computing, Book 184). Berlin: Springer, 2005, pp. 67–119. 18. Russ AL, Saleem JJ, Justice CF, et al. Electronic health information in use: characteristics that support employee workflow and patient care. Health Informatics J 2010; 16(4): 287–305. 19. Walton M. The Deming management method. New York: Perigee Books, 1988. 20. Malone TW and Crowston K. The interdisciplinary study of coordination. ACM Comput Surv 1994; 26(1): 87–119. 21. Bordewijk J and Van Kaam B. Towards a new classification of tele-information services. In: McQuail D (ed.) McQuail’s reader in mass communication theory. London: SAGE, 2002, pp. 113–124. 22. CONTSYS. ISO EN-13940–13941:2007. Health Informatics—systems of concepts to support continuity of care. Part 1: basic concepts. 23. Gustafsson M and Winge M. SAMS Konceptuell Informationsmodell. 2004, http://winge.blogs.dsv. su.se/files/2014/04/Sams-Konceptuell-Informationsmodell4.pdf 24. Winge M, Johansson L-A, Nyström M, et al. Need for a new care model—getting to grips with collaborative home care. Stud Health Technol Inform 2010; 160: 8–12. 25. Winge M.CO-CARE—collaborative health and social care. In: Proceedings of the 13th international symposium for health information management research, Auckland, New Zealand, 20–22 October 2008, New Zealand: Massey University, pp. 113–124. 26. Jordan ME, Lanham HJ, Crabtree BF, et al. The role of conversation in health care interventions: enabling sensemaking and learning. Implement Sci 2009; 4: 15. 27. Civan A, Skeels MM, Stolyar A, et al. Personal health information management: consumers’ perspectives. AMIA Annu Symp Proc 2006; 2006: 156–160. 28. Venkatesh V, Morris MG, Davis GB, et al. User acceptance of information technology: toward a unified view. MIS Quart 2003; 27(3): 425–478. 29. Sharma R and Yetton P (2003) The contingent effects of management support and task interdependence on successful information systems implementation. MIS quarterly, 533–556. 30. Peffers K, Tuunanen T, Rothenberger MA, et al. A design science research methodology for information systems research. J Manage Inform Syst 2007; 24(3): 45–77. 31. Johannesson P and Perjons E. A design science primer. CreateSpace Independent Publishing Platform, Charleston, South Carolina, 2012. 32. Gustafsson M and Winge M. SamS-projektet: Process—och begreppsmodellering—delrapport (in Swedish).2003. http://winge.blogs.dsv.su.se/files/2014/04/SamS-delrapport-process-begrepp2.pdf 33. Sein M, Henfridsson O, Purao S, et al. Action design research. MIS Quart 2011; 35(1): 37–56.

Downloaded from jhi.sagepub.com at University of Victoria on November 15, 2015

The coordination hub: Toward patient-centered and collaborative care processes.

The organization and processes of today's health and social care are becoming ever more complex as a consequence of societal trends, including an agin...
637KB Sizes 2 Downloads 3 Views