1 Introduction

The 2001 Institute of Medicine (IOM) study ‘Crossing the Quality Chasm—A New Health Care System for the 21st century’ described our current healthcare system as being inadequate for the level of care delivery needed in the forthcoming years. Ideally we need a healthcare system with high performing patient care teams that provide safe, effective, and personalized patient care across different sites and services (Institute of Medicine 2001). Increased use of information and communication technology (ICT) and reengineered care processes that facilitate collaboration across providers, diseases and locations will be key drivers of this new healthcare system. However that ideal vision for our healthcare system is challenging as the current healthcare system is still largely built around individual tasks and information usage, which is clearly inappropriate for coordinated care across distributed settings.

Interoperability is the means of integration of data and processes to support collaboration and other healthcare activities. Interoperability will therefore be a key driver of future healthcare delivery. However interoperability is a complex concept. Benson refers to three interoperability levels: technical, semantic and process (Benson 2009). Technical interoperability moves data across two computer systems without understanding the exchanged data. Semantic interoperability ensures the two computer systems have a common understanding of the exchanged data. Process interoperability coordinates work processes across different people so they can work together. To date much of the focus on interoperability has been on technical and semantic interoperability in order to enable two or more computer systems to communicate with one another. Although the ability of computer systems to exchange and interpret data is important, we must also consider interoperability among the various actors (i.e. healthcare providers and patients) and healthcare processes that interact with and use the computer systems. These processes include facilitating collaboration, the dissemination and use of evidence, and the social aspects of communication. Process interoperability ensures we have both interoperable computer systems and interoperable actors and processes using the systems.

The contribution of this paper is a mashup-based framework for multi-level healthcare interoperability. The framework serves as a model of how mashup technologies can facilitate multiple interoperability requirements between various healthcare settings and actors. We show how mashup patterns are able to play an important role for enhancing the interoperability and integration of healthcare services and applications, especially at the process level. For this purpose, we first present a healthcare case study and conceptual model to articulate interoperability requirements. We then describe our framework and use it to develop a mashup-based prototype as a proof-of-concept of how our framework implements the interoperability requirements from the case study.

The remainder of this paper is organized as follows. Section 2 reviews the background. Section 3 presents our research approach. Sections 4, 5 & 6 present our results. Section 4 describes a collaborative care case study and a set of interoperability requirements based upon a conceptual model from the case study. Section 5 details our mashup-based interoperability framework and the use of mashup patterns to implement the interoperability requirements within the framework. In Section 6 we provide proof-of-concept implementations of our framework using a collaborative care scenario. Section 7 is dedicated to a discussion, a summary of the paper’s contributions, and concluding remarks.

2 Background

2.1 Interoperability outside healthcare

To set the context of interoperability in healthcare we draw upon interoperability research in the supply chain management (SCM) domain. SCM represents the set of processes that integrate suppliers, manufacturers, distributors and retailers as a virtual organization in order to deliver products to a customer. SCM relies on process and information interoperability across the entire supply chain process, both internal and external to an organization. SCM uses the terms “digitization” or “digital enablement” to describe the replacement and integration of processes using ICT such as the internet (Lee 2000). A key feature of digitized SCM is the shift from connecting physical processes to information-based integration (Zhu et al. 2004). As digitized SCM systems evolved, some believed there was a disconnect between the theory and practice of digitization in that expensive ICT solutions were being implemented without understanding the underlying implementation needs and relevant processes used in SCM practice (Van Donk 2008). As a consequence, expensive ICTs did not result in enhanced SCM performance. Supply chains were able to succeed at interoperability by re-focusing digitization efforts on specific SCM processes, such as how human decision makers interact and exchange information, since those processes have been shown to have a great impact on ICT design to support supply chains (Van Donk 2008).

2.2 Healthcare interoperability

Healthcare is similar to SCM in that it is moving towards the design of digitally enabled systems that will replace physical processes and provide the means to conduct processes across disparate settings (Raghupathi and Kesh 2009). Healthcare is also struggling with the implementation of ICT systems as numerous healthcare ICT projects end up as failures (Avison and Young 2007). A large reason for these failures is that healthcare delivery, particularly via distributed collaborative teams, is challenging. While industries such as banking and manufacturing have succeeded in developing interoperable systems, it has been pointed out that healthcare is unique in its need to facilitate highly integrated yet personalized care via multidisciplinary teams located in differing settings (Avison and Young 2007).

Although the unique features of healthcare preclude the direct transfer of interoperability research from other domains, we do suggest that there are some key lessons that are transferable. Foremost is the need to understand interoperability at the processes level. A key message from business interoperability with financial, manufacturing and supply chain systems was the need for processes to be the driver of interoperability efforts. To date, much of the research on healthcare interoperability has been focused on technical interoperability and to a lesser extent on semantic interoperability. Technical interoperability has led to the development of interoperable systems using technologies such as Extensible Markup Language (XML), web services and Service Oriented Architectures (SOA), (Sartipi and Mohammad 2008) and interoperable systems using terminology standards such as HL7, SNOMED-CT, and reference model based architectures such as the openEHR archetypes (Garde et al. 2007). However a key shortcoming in existing healthcare interoperability research is that it has not, for the most part, focused on the underlying processes of healthcare delivery. Complex healthcare delivery, particularly collaborative team based care delivery, requires interoperability of data as well as the processes that act upon the data. Shortliffe and Blois stated that the key to understanding the automation of medical records such as through the electronic health record (EHR) is making sense of the underlying processes that use the EHR (Shortliffe and Blois 2006). They further suggest that we should not look at healthcare ICT as an object or product but rather as a set of processes. Campbell et al. (2006) and Ash et al. (2007) similarly showed that the key to understanding computer physician order entry (CPOE) systems was to understand the underling work processes and interactions of people who used the CPOE systems.

2.3 Technologies for supporting process interoperability

Although interoperable systems and data are important we need to remember that healthcare delivery is about people and processes. The different actors in healthcare delivery conduct processes as part of care delivery and it is processes that generate and use data. The aforementioned IOM healthcare system objectives of effective, efficient, safe, collaborative patient centered care (Section 1) are all macro level processes and thus the true test of interoperability will be how well it helps us implement those objectives. Therefore understanding and supporting process interoperability could be argued as the key to developing completely interoperable healthcare systems. We must also keep in mind that healthcare systems are socio-technical systems involving the interaction of people, policies, processes and technologies (Coiera 2004). In that context we need to design and evaluate ICT systems from the perspective of all levels of interoperability such as people, processes and technologies.

2.3.1 Collaborative technologies

Increased collaboration is one of the primary goals for healthcare system reform. Therefore we need increased focus on the design of technologies to support collaboration. Web 2.0 technologies, designated as Health 2.0 when applied to healthcare, can support collaborative care delivery because they allow collaboration across multiple providers and settings. Health 2.0 has the potential to improve healthcare delivery by providing improved access to information and support for healthcare interventions and team based care delivery (Juzwishin 2009; Senathirajah and Bakken 2009). However the use of Health 2.0 is still in the early stages. Research is needed to understand the specific processes, information and services needed by the different actors as part of collaboration and how all of those can be integrated by technologies such as Health 2.0.

2.3.2 Mashups

Integrating the processes, information and actors that are involved in healthcare delivery requires a framework to support interoperability in a controlled manner. Mashups are considered a fast-growing integration approach in the field of data management because of the flexibility and creativity involved in their development as well as the functionality they offer to users (Gasser and Palfrey 2007a, b). The aim of mashups is to dynamically reuse the existing data sources or web applications from heterogeneous sources and reconcile them into a single integrated application.

The idea behind the term mashup is not new and in fact the integration of disparate resources has always been an issue during software development where some data and functionalities are provided by external systems, and mechanisms are presented in order to integrate them properly (Koschmider et al. 2009). However mashups are gaining momentum because the number of applications on the web is growing rapidly and there is a need to combine these applications in order to meet users’ specific requirements (Abiteboul et al. 2008). Another advantage of mashups is that non-technical users are able to create new content and represent resources without much effort or knowledge of programming languages or other technical specifications (Koschmider et al. 2009).

The capabilities of mashups in the healthcare domain have been demonstrated by Greenshpan et al. who proposed a mashup-based patient-centric Extended Personal Health Record system (xPHR) in order to assess the potential of latent effectiveness in the mashup approach (Greenshpan et al. 2009). Their system includes three main classes of concepts: Medical, Personal, and Collaboration, and it is part of a larger system that provides personalized monitoring of patients with notification on anomalies to caregivers. They also suggested that mashups are an ideal technology for implementing the collaborative requirements of Health 2.0 since they provide great potential to improve the quality of care by delivering technological solutions that are patient-centered and easy-to-use (Greenshpan et al. 2009).

To date there is limited applications of mashups in healthcare and those that exist such as (Yu et al. 2007a, b) are mainly designed for integration and interoperability at the data level. We are not aware of any generic mashup-based framework specifically developed for the healthcare environment that supports interoperability at multiple levels including people, data and processes. Such a framework could encourage healthcare actors to collaborate with each other effectively, could enable healthcare applications to communicate with each other through standard technologies and open protocols, and it could also bridge the service delivery gap between healthcare providers and patients by providing a patient-centered environment.

3 Research approach

3.1 Method

Design science research was the overarching methodology used in this study. It uses a cyclical model of design, build, and evaluation of outcomes in order to develop constructs, models, or methods (Hevner et al. 2004). Outcomes from design science research can involve developing new research questions or the development of a model or framework which can be evaluated against the research objectives. Through design science we used an existing conceptual model from a collaborative care case study to develop a set of interoperability requirements. We then used these requirements to develop a framework and demonstrate proof-of-concept implementations.

Hevner et al. (2004) call for synergy between design science and behavioral science methods in order to leverage the strengths of both approaches. Design science creates technical artifacts while behavioral science articulates user needs and requirements. As such we supplemented the design science method with another method. We used content analysis, a method used to analyze data to identify patterns and trends. Data analysis using content analysis is focused on the characteristics of the data with particular attention to the content or contextual meaning of the text (Hsieh and Shannon 2005). The purpose of the content analysis was to analyze the collaborative concepts from the case study (described in Section 4) to identify interoperability requirements and to identify how mashup technologies could implement these requirements.

4 Case study and interoperability requirements

A case study of collaborative healthcare delivery serves as the conceptual model for our mashup-based interoperability research. Collaborative healthcare delivery provides a rich perspective of interoperability needs because it involves care delivery by multiple providers across multiple settings.

The case study looks at collaborative care delivery at an inpatient hospice described in detail elsewhere (Kuziemsky et al. 2009). The case study involved collaborative healthcare delivery by a palliative care team consisting of nurses, physicians, medical residents and fellows, coordinating administrative staff, personal support workers, volunteers, patients and patient family members. The study described how collaborative care was carried out by the different providers with an emphasis on the collaborative processes they engaged in. A significant challenge that arose was that the team often worked asynchronously. Communication and collaboration between the providers was challenging because they would come and go at different times (Kuziemsky and Varpio 2011).

The key result from the case study was the development of a model of the types of awareness needed by the different providers to support various aspects of collaboration. Awareness about the patient, care team, decision making process, and the environment where care delivery takes place were identified as four specific types of awareness needed to support collaboration (Kuziemsky and Varpio 2011). The different types of awareness were effectively the means of interoperability by different providers with data, other people, policy, and communication channels.

Therefore interoperability of data, processes and other factors such as policy are a key underpinning of collaborative care delivery. Although the awareness model extended our understanding about the needs of collaborative care delivery, the model is conceptual and has not been implemented technically. We looked to extend existing research by using the awareness model as the basis for defining and implementing detailed interoperability requirements for collaborative care delivery. To identify the interoperability requirements we used content analysis to analyze each type of awareness. Figure 1 shows our analysis process starting with the four awareness types and then the use of content analysis to identify interoperability requirements.

Fig. 1
figure 1

Analysis process to identify interoperability requirements

Full size image

From our content analysis we identified six unique interoperability requirements: data, team member and task, policy and procedure, collaborative, social, and knowledge exchange. Data is an essential requirement of healthcare delivery and all interoperability processes involve some aspect of data exchange. Therefore data is shown as a higher order interoperability type in Fig. 1. Because we were interested in identifying process interoperability needs, the remaining five interoperability requirements all support collaborative processes. In analyzing the processes we determined that process interoperability requirements must identify two things, the channels and context. Channels connect a sender and a receiver to facilitate the exchange of information as part of conducting a process. Channels can be between two or more people, between a person and a process, or between a person and an ICT. Context defines the specific needs or environment that is necessary for a process to take place.

We provide an example of our analysis using decision making awareness. The essence of decision making awareness is the need for providers to be able to participate in collaborative decision making across different dimensions of time or different settings (Kuziemsky and Varpio 2011). Therefore collaboration interoperability must define the channels to bring the different decision makers together but it must also provide the means to allow them to brainstorm ideas in order to come to a collective decision over a number of hours or even days. The context is significant in that part of the brainstorming will likely take place in an asynchronous fashion and thus much of the decision making process will be virtual.

Because our framework is intended to be implemented as a working system it will involve the electronic exchange of healthcare data. Therefore we also created a privacy and security interoperability requirement, which is shown in Fig. 1 as an overarching requirement for all the interoperability types. Any data exchange in healthcare must follow privacy and security legislation.

We describe each interoperability requirement below and briefly discuss it in the context of collaborative care delivery.

4.1 Data interoperability

The ability to exchange data to support collaborative care delivery is important for several reasons. Patient centered care means that care delivery is tailored to each individual patient and therefore all collaborative team members need to have data about the patient’s current status and detailed treatment plan(s). A large amount of collaborative activities such as rounds meetings or shift change are spent discussing and updating patient status and treatment plans. However collaborative patient cases can be very complex and require multiple data sources to be integrated and customized to support the different needs of the different providers.

4.2 Team member and task interoperability

Collaboration to support a patient case is not static but rather a healthcare team comes together depending on the specific needs of the patient and the capabilities of the healthcare providers. Channels are needed to allow teams to be assembled based on the skills sets of providers and the specific needs of a patient’s case (Kuziemsky and Varpio 2011). The context is important because different team iterations will require different information and support for team processes such as care planning, decision making or treatment provision.

4.3 Policy and procedure interoperability

Clinical processes are governed by policies and procedures at different care centres. Those policies can influence treatment and communication processes as well as other clinical decisions. For example, the case study had a policy against admission if patients were undergoing acute interventions such as chemotherapy or radiation (Kuziemsky and Varpio 2011). Policies and procedures will impact what providers can and cannot do and thus any technology we design must incorporate organizational policies and procedures with their applicable processes. Channels must clearly disseminate these policies and procedures so providers are aware of them. Data that is collected and used drive processes in systems such as electronic health record or order entry systems must be aligned with the policies so providers do not try to conduct a process that violates policy.

4.4 Collaboration interoperability

As described earlier, the asynchronous nature of healthcare delivery can make collaboration very difficult. Collaboration is challenging enough when care providers are in the same room. It is substantially more challenging when it takes place asynchronously. Team meetings are common decision making forums yet a challenge in asynchronous care delivery is that not all care providers can attend team meetings because of timing and other commitments. Part of collaboration interoperability is the ability to brainstorm ideas to allow a decision to evolve over time (Kuziemsky and Varpio 2011). Channels are needed to mimic a team meeting so care providers have a common place to see what decisions need to be made and who is involved in the decision. Channels also need to provide the means of contributing to the collaborative decision making process. Because decisions are often not made in the moment but rather over hours or sometimes days, the context of a decision needs to be communicated so that all providers are on the same page with respect to the collaborative process.

4.5 Social interoperability

Patient centered care is a key deliverable of any healthcare system. Social interactivity is a large part of healthcare delivery. Studies have shown that the ability of patients to discuss their illness socially can have positive implications on outcomes (Juzwishin 2009). Patients often receive social benefits when they are in care settings but they lose these benefits when they are at home. Channels need to connect patients and providers in a virtual manner. However a key contextual issue is the technological abilities of patients will vary. Context in this case is very much at the individual level. Social interoperability tools need to be designed with flexibility to enable a range of patients to benefit from the social activities disseminated through the channels.

4.6 Knowledge exchange interoperability

Evidence-based medicine (EBM) is the conscientious, explicit, and judicious use of current best evidence in making decisions about the care of individual patients (Sackett et al. 1996). Providers often require access to evidence as part of care planning for a patient. Access to evidence is particularly useful in complex patient care such as palliative care or for less experienced providers such as residents. The desire to have patients become active stewards of their own care will also require access to evidence. Appropriate channels must be in place to deliver the required evidence at the moment it is needed such as at the time of a diagnosis or treatment decision. However evidence must also be context specific. Upwards of 30,000 scientific articles are published annually (Choi 2005) and thus retrieving timely evidence that is relevant for a patient case is challenging.

4.7 Privacy and security

An overarching need for system interoperability of electronic health information is privacy and security. In Fig. 1 we show privacy and security as enveloping the other interoperability requirements. Privacy and security are always concerns when determining the optimal level of openness in an interoperability ecosystem. We looked at these issues in two perspectives: The first perspective is looking at the security and privacy of healthcare data and system in general. The second perspective is looking at these issues when they are applied in the context of interoperability and mashup technology.

In the general perspective, privacy issues can be addressed by applying role-based access control models made for healthcare systems that are constructed on interaction, role and organization (Wei and Doan 2009). In these security mechanisms, each role is associated with a set of security properties which describe the security constraints aiming at defining the actions and responsibilities that a role can assume within the healthcare environment and in any interactions with other roles (healthcare actors). Here the main idea for different roles is to operate in such a way that none of the security rules and constraints are violated in order to gain an optimum level of security and privacy.

In the specific perspective, where security and privacy affect all the identified interoperability requirements, technologies such as interoperable Digital ID and SSL (Secure Sockets Layer) are able to reap the benefits of mashup innovation while addressing privacy and security concerns (Gasser and Palfrey 2007a, b). Different models of digital ID systems—user-centric, federated, and centralized—provide an opportunity for users and/or organizations to have control over their data in a more secure and private manner.

Among the aforementioned models, the user-centric model would be the best specific fit for our proposed mashup framework as it is driven by privacy concerns aiming for leaving the control with the healthcare actor to when and how their data is given to other actors. In the user-centric model, the healthcare actors must initiate or approve any transfer of personal information before it takes place and this could be done either directly by the actors or indirectly through third party products (e.g. client/agent software) with predefined rules for the healthcare organization. The user-centric model allows the individual to provide minimal information and such a model can be used to verify the identity of the user where the user provides enough information to be identified accurately. According to the literature, interoperability between the user-centric and non user-centric models is possible (Gasser and Palfrey 2007a). Therefore, on top of the user-centric model, the role-based model can be used to set and control permissions to perform certain operations assigned to specific roles. These two models can be used together to address the needs of control and access.

In parallel to the abovementioned models, the SSL standard is able to help service providers to specify and assess the security constraints for data exchange among mashup components (Aghaee 2010).

5 Mashup-based framework for multi level interoperability

In this section our mashup-based framework for multi level interoperability will be presented. The framework can be considered as an architectural map for supporting the interoperability requirements identified in Section 4. We refer to the framework as a multi level interoperability framework because as seen in Section 4, there were multiple interoperability requirements including data, team task and member, collaboration, knowledge exchange and policies and procedures. We also described how privacy and security requirements must be an overarching consideration for all the interoperability requirements that involve electronic exchange of healthcare data.

Mashups were selected as the underlying application for our framework because as discussed in Section 2.3.2 they have the ability to reconcile multiple data sources or applications as well as the ability to evolve over time. Mashup technology provides a foundation for enhancing interoperability among healthcare actors, processes and applications due to the fact that mashups facilitate openness, data reuse and interoperability at their core (Anderson 2007). The delivery of healthcare services, particularly collaborative team based care delivery, is very dynamic. Communication or information dissemination channels need to be assembled to support varying contexts as described earlier. Mashups provide flexibility in that they can be assembled into different architectures to support different service delivery needs. Each user is able to convert his or her mashup from using one data source or service to another, and as a result, users’ needs are better satisfied in a timely manner (Gasser and Palfrey 2007a, b). Finally, mashups are also not limited to any specific technology which makes them more versatile for use across different settings.

Our multi level interoperability framework is a formalized architecture of the interoperability needs described in Section 4. The framework is made up of two main parts, the framework itself, and the mashup patterns that facilitate interoperability within the framework. Each part is discussed below.

5.1 Mashup-based interoperability framework

Our framework provides an environment for healthcare actors to directly communicate and collaborate with each other, and to personalize their healthcare environment according to their own needs. This is done by having healthcare applications work together (interoperate) by providing the information management channels to support actors in the various contexts of healthcare processes they engage in.

The mashup-based Interoperability Framework (Fig. 2) consists of four main components: healthcare actors, collaboration environment, integration/interaction mechanisms, and data resources. Each component is discussed below.

Fig. 2
figure 2

Mashup-based interoperability framework

Full size image

5.1.1 Healthcare actors

This part of the framework considers all the actors which are (or might be) required throughout the process of healthcare delivery. The main actors are identified and the relationships among them defined based on e-business relationships as specified in (Trites et al. 2005). Our framework uses patients and their informal care providers and support (e.g., family members, friends) instead of customers (C); health care providers (e.g. physicians, nurses, therapists) and insurers instead of businesses (B); and government regulators instead of government (G). Through mashup technologies, all the actors of the processes are provided with a set of Web 2.0 tools and technologies throughout the design and development processes enabling them to customize and tailor the web-based collaboration environment according to their specific and ongoing needs, while being able to directly communicate and collaborate with each other.

5.1.2 Collaboration environment

The center of the framework is the actual environment where different Web 2.0 tools and applications such as blogs, social networks, or wikis, are offered to healthcare actors in a way that they can utilize and customize them according to their needs and preferences. These tools serve as the channels for disseminating information or facilitating collaboration among the healthcare actors in order to achieve interoperability at the process level.

5.1.3 Integration/interaction mechanisms

At the bottom of the framework, integration or interaction mechanisms are located. These are applications intended for user-specific needs. Mashlets can have their own graphical user interface or be presented as web Services. Examples of mashlets are a “To do list” widget, an “Image viewer” widget, a “Medical Data Analyzer” widget, or even an Electronic Health Record (EHR) widget. Here, users are able to drag and drop widgets onto the mashup environment and configure them interactively.

5.1.4 Data resources

This part of the framework is used for interoperability at the data level. We considered all the possible data sources that could be used throughout healthcare processes. On the left side of the framework, data sources represent the suppliers of the mashup environment. As argued in (Cheung et al. 2008), optimal value will be gained when mashups can be created across the data resources. This means that to gain the maximum possible value from our framework we need to consider all the potential health data resources, particularly different health information systems (e.g., pharmacy systems, EHR systems, lab systems) and Internet-based Applications such as Patient Health Records (PHR) systems.

5.2 Mashup patterns

We augment our interoperability framework with a set of mashup patterns, which represent the tools to implement the interoperability requirements. Mashup patterns are organized into five main categories: Harvest, Enhance, Assemble, Manage, and Testing (Ogrinz 2009). Each category is described below.

  1. 1.

    Harvest patterns are a class of solutions based on obtaining data from sources previously viewed as not potential or outside the reach of current systems or tools.

  2. 2.

    Enhance patterns are aimed for extending and improving current systems, generally without the assistance of the original developers.

  3. 3.

    Assemble patterns show how new solutions can be provided by combining data and presentation from multiple sources.

  4. 4.

    Manage patterns help leverage existing assets more effectively, especially when the idea is not to build new solutions but rather to manage the ones we already have.

  5. 5.

    Testing patterns can be used to perform basic testing functions or requirements, such as user acceptance testing, before deploying a final solution.

After analyzing the abovementioned mashup patterns in the context of the interoperability requirements described in sections 4.1, 4.2, 4.3, 4.4, 4.5, 4.6 & 4.7, we identified the harvest, assembly and testing patterns as best fit for meeting the interoperability requirements. Our rationale for selecting those patterns is described below.

5.2.1 Harvest pattern

The harvest pattern is indicated for employing data from both structured and unstructured data sources. Examples of structured sources include RSS feeds and XML, while unstructured sources can be websites, spreadsheet files, and even free-form text. However, mashups that employ unstructured data sources are more fragile in comparison with those which use structured data sources; therefore, it is very important to first consider structured data sources in order to maintain the stability and sustainability of our mashup-based environment. The harvest pattern can be used for developing dissemination channels to address the requirements of data interoperability (Section 4.1). The harvest pattern provides the data transmission channel if there is a need to monitor a patient’s current status automatically and instantly via possible communication channels, such as RSS feeds.

5.2.2 Assembly pattern

The assembly pattern can be used in situations where there is an immediate need for a channel to address an issue. Historically healthcare systems design would require a user to go through the IT department and request a formal design and specification. The assembly mashup pattern provides an opportunity for the user (e.g., a nurse) to easily and quickly create ad hoc tools and data streams for taking care of an issue on an as-needed basis. This pattern is also referred to as integration on the glass, where the user can quickly mash a component for a particular purpose without needing to change the underlying functionality or the infrastructure (Rayns and Jensen 2010). This pattern can be used to meet the channel and context requirements of team member and task interoperability as well as collaboration interoperability (Sections 4.2 and 4.4), where team members with varying skill sets and possibly from different locations need to be assembled through a virtual space in order to make a collaborative decision about a patient case.

5.2.3 Testing pattern

The testing pattern is mainly for realizing whether one method of addressing an issue in a mashup-based environment will be possible and whether it will be accepted by users. In this case, mashup tools can be used for creating a prototype, possibly by requesting a service from the Internet, and testing will be performed for proofing the original concept or idea. The testing pattern is especially useful for situations where it is not practical or feasible to build a system from scratch; instead, existing applications and services can be partly used in the current or new system for addressing an issue or requirement (van der Aalst et al. 2003). The testing pattern can be used to meet the channel and context requirements of social interoperability (Section 4.5) in order to examine whether we can replicate the social environment of in-patient programs with an online health social network and whether it will support the different contexts of usage in order to have positive implications for patients. Channels can be established to connect patients and providers and to allow different contextual variations of social programs to be prototyped and tested.

5.3 Other interoperability requirements

We were not able to use mashup patterns to facilitate policy and procedure interoperability or knowledge exchange interoperability (Sections 4.3 and 4.6) in our framework. When we analyzed the mashup patterns against the interoperability requirements we realized those two types of interoperability would be challenging because of the volume of data and dynamic nature.

6 Proof-of-concept implementations

To illustrate how our mashup-based interoperability framework can address the interoperability requirements, we use a healthcare scenario in the IBM Mashup Center, which is a mashup platform designed for both nontechnical users and IT personnel (Hoyer and Fischer 2008). The healthcare scenario is based on the collaborative case study and interoperability requirements from Section 4. We set up our proof of concepts implementations in the following sections. First we describe system design challenges to implementing our framework. Second we describe a collaborative care scenario. Third we illustrate and describe three proof-of-concept implementations based on the scenario.

6.1 Implementation challenges

The core components of our interoperability framework (Fig. 2) together with the mashup patterns behind them are able to provide an interoperable framework for communications between people, data, processes and applications. However we identified several systems design challenges for implementing such an architecture. The primary challenge is that it requires flexibility in design since the collaborative needs of healthcare systems are complex and dynamic. Healthcare teams vary from case to case and the level of information exchange and collaboration that is necessary for care delivery will also vary. Therefore there will need to be multiple implementations of the framework depending on team needs. Similarly, patients will have different needs and that will also require system design flexibility.

In order to support systems design that allows flexibility of structure and features, an iterative and user-centered systems development method should be used. In order to streamline the development process, visual mashup development tools, like the IBM Mashup Center, could be provided to end-users where various features and simple composition approaches are available for selection. The usability of the mashup environment defines the skill set that a user needs to have in order to start using it (Beletski 2008) and therefore, user friendly mashup tools should be provided in order to improve usability, interactivity, and acceptance. As a result of involving the main actors of healthcare processes early in the design phase, a more effective and usable system can be implemented (Pilemalm and Timpka 2008). In such a bottom-up approach patients and other actors of the healthcare process are the actual creators of healthcare services and applications. Patients are considered as partners and other actors (e.g. physicians or nurses) are able to examine which applications are being incorporated by the patients in order to better understand and anticipate the patients’ needs in order to provide them with sufficient ways of performing a task or using a service.

6.2 Collaborative care scenario for proof-of-concept implementations

We developed a collaborative care scenario to demonstrate proof-of-concept implementations of our Mashup based framework. Our scenario involves a multi provider collaborative care team. Each morning the care team reviews the patient’s status and treatment plan and discusses each patient’s issues to come up with a plan to manage each issue including assignment of who should deal with each issue. The assignment of tasks needs to be based on provider skills. A challenge in care planning is that not all team members are able to be present during planning meetings. However collaboration is essential to make proper decisions and to ensure that all providers are able to contribute to the decision making process. Any providers who are not able to attend the meeting should be aware of any changes made to the patient’s care plan and should have the means to provide decision making input. Finally, when patients are discharged home they should have access to some of the same services and benefits they receive as inpatients in a hospital in order to preserve continuity of care.

From the above scenario we developed three implementations of our framework to demonstrate four of the interoperability requirements (collaboration, team member and task, data, and social) for collaborative care delivery. We also discuss privacy and security requirements throughout the implementations because as shown in Fig. 1 privacy and security must be considered in all types of healthcare interoperability.

6.2.1 Implementation and proof-of-concept of collaboration and team member and task interoperability

Our framework supports collaboration interoperability as follows. A collaboration widget is made available by one of the caregivers through a mashup tool, and then incorporated into a mashup-based environment (e.g., IBM Mashup Center); this is where the central component and the integration/interaction mechanism component of our framework are used by one of the healthcare actors. Invitations for an online meeting are then sent to all the care team members by e-mail prior to the actual meeting. In emergency situations, a contact widget displaying the list of care team members with online status information (Sire and Vagner 2008) can be incorporated by one of the care team members into the mashup-based environment and invitations for an online meeting can be sent immediately to those with an online status. In addition, the skill sets of care team members can be shown in front of their online status (like Nurse #1: Symptoms Management Specialist) in order to be able to assemble the care team based on patient needs. Here the name of each care team member can be hyperlinked to a dedicated blog for providing detailed information on their abilities and skill sets. That enables invitations to be sent to the care team members with the required skill sets (team task interoperability). The online meeting, or e-conference, provides an opportunity for care team members to discuss a patient’s issues and make a decision collaboratively.

A snapshot of the proof-of-concept implementation of this scenario is shown in Fig. 3. We describe the implementation of team member and task interoperability (Section 4.2) and collaboration interoperability (Section 4.4) by referring to the circled numbers in Fig. 3.

Fig. 3
figure 3

Implementation snapshot: proof-of-concept for achieving collaboration and team task interoperability

Full size image

(#1) The collaboration widget, called Portal, is incorporated (drag & drop) into the mashup environment and then the virtual online meeting, named IBM LotusLive, can be called by the Portal widget as an Internet-based service. (#2) The invitations for the online meeting are sent by the person who initiated the meeting (e.g., Nurse #1) to care team members. (#3) A list of care team members who have accepted the invitation and are participating in the online brainstorming meeting. This feature also facilitates the assembly part of a team based on abilities and skill sets. (#4) Participants can share and present files/documents which are relevant to the patient (e.g., an X-Ray scan of a patient’s chest), in order to further discuss his/her condition and make decisions collaboratively. (#5) Discussions among participants can be done through the chat functionality. (#6) In case of a need for video conferencing (e.g., when the physician wants to observe the patient’s facial expressions), a webcam can be used. (#7) Once the brainstorming session is completed and decisions are made, the team member who initiated the meeting (Nurse #1) documents and creates a list of tasks to be assigned to each care team member, and then the assigned tasks are sent by e-mail. The assembly mashup pattern was used for this scenario, where there was a need for an immediate virtual meeting with other care team members who are not located at the same place.

6.2.2 Implementation and proof-of-concept of data interoperability

Our framework can be used to meet the requirements of data interoperability (Section 4.1). A dedicated blog can be created for the patient where any changes in the status of his/her care plan together with relevant decisions made for the plan are posted by one of the caregivers (e.g., Nurse #1). By doing this, all the care team members are able to check the condition of the patient on a regular basis by referring to the patient’s blog, and they can even contribute by leaving their comments on the blog posts if needed. However, rather than making the different team members visit the patient’s blog for obtaining changes/updates in the patient’s care plan, RSS technology can be used so that team members can subscribe to a patient’s blog through RSS Feeds and then incorporate RSS Feed Reader/Viewer widgets into their mashup environment to automatically receive notifications as soon as the blog is updated. In the above example, the collaboration environment, the data source and the integration/interaction mechanism components of our framework are being employed. A snapshot of the implementation is depicted in Fig. 4.

Fig. 4
figure 4

Implementation snapshot: proof-of-concept for achieving data interoperability

Full size image

We describe the implementation of data interoperability by referring to the circled numbers in Fig. 4. The RSS Feed Viewer widget (#1) and RSS Feed Reader widget (#2) are incorporated in the IBM Mashup Center environment; the dedicated patient’s blog (www.psade077.wordpress.com) is the data source of these two widgets. (#1) Pulls various data from the patient’s blog and integrates them together in order to provide an overview of the patient’s condition in terms of his/her recent status in different dimensions (e.g., treatment plans, symptoms, etc.). This widget can be customized to meet the different needs of different providers; for example, the widget can be customized in a way that in case of any urgent/important conditions, the patient’s status is highlighted to attract the provider’s attention. (#2) Shows the concise overview of the patient’s condition and it can be customized such that in case of any changes in the patient’s blog, notifications are received immediately by the RSS Feed Reader widget (Karkalis and Koutsouris 2006). Through RSS technology, mashup-based environments are able to dynamically incorporate content from external information providers since RSS data feeds are created using a structured format (XML) and therefore mashups can easily consume them as a data source (Ogrinz 2009). This can also enhance interoperability at the data level. As a result of using blog and RSS technologies, care team members are able to observe the overall treatment process in real-time by seeing how the information is distributed among them; which may increase the transparency of the treatment process (Hoegg et al. 2006). The harvest pattern was used in this scenario with RSS feed as a communication channel for monitoring the patient’s current status.

For privacy and security considerations of data interoperability, private RSS feed readers, equipped with HTTP authentication combined with SSL encryption, can be used to ensure only authorized healthcare actors (e.g. the team members) are able to subscribe and receive the notifications in a private and secured mechanism. This would implement the user-centric model for proper authentication and identification of subscribers.

6.2.3 Implementation and proof-of-concept of social interoperability

The third scenario implements the requirements of social interoperability (Section 4.5). As described previously, patients should be able to replicate the social environment of in patient settings. For this purpose, health social networks can be a solution. They are primarily directed at patients but other healthcare actors can participate and have direct interactions with patients in order to provide them with further help and assistance if required. Figure 5 is a snapshot of the implementation of social interoperability using a health social network called PatientsLikeMe in the IBM Mashup Center. We describe the implementation and proof-of-concept of social interoperability by referring to the circled numbers in Fig. 5.

Fig. 5
figure 5

Implementation snapshot: proof-of-concept for achieving social interoperability

Full size image

In order for patients to have social interoperability in their mashup, they refer to the Collaboration tab, add the Portal widget (#1) into the IBM Mashup Center, and then invoke the PatientsLikeMe social network. This is where the central and integration/interaction mechanism components of our framework are utilized. (#2) enables the patient to create his/her profile. (#3) helps the patient to search for other patients with a similar condition, ask questions and share personal experiences in the forum, and browse treatment/symptom reports and advice. (#4) allows the patient to search for information on health conditions and treatments. (#5) shows the results of a customized search, where the patient sees those who are in similar conditions as him/her, and is able to contact them directly and view their profiles. (#6) is where the patient is able to interact with other caregivers in order to gain further support, and pose questions about his/her condition (Bos et al. 2008). The testing pattern was used for this scenario to implement social interoperability.

For privacy and security considerations of social interoperability, both user-centric and role-based models can be used in order to first identify the healthcare actors properly and then to assign them with permissions to perform certain tasks according to their specific roles. Prior to the identification of the healthcare actors, a pop-up window can be presented to them in order to clearly state the privacy policy of the services being offered and also to raise the awareness of them regarding when, how, and to what extent their information will be shared with other actors of the healthcare process. On the other hand, all the activities of the healthcare actors within the healthcare social network can be logged in order for an authorized entity (e.g. administrator or privacy commissioner) to audit and ensure that only the right information are shared with the right actors according to their roles and responsibilities.

7 Discussion and conclusion

Interoperability will become a key driver of healthcare delivery. As more care delivery is provided via collaborative teams it will increase the need for integration of data, people and processes across different settings. To date much of the research on healthcare interoperability has focused on technical and to a lesser extent semantic interoperability, while process interoperability has been largely ignored. However healthcare delivery takes place at the process level and we need to understand and support interoperability from the perspective of healthcare processes and most importantly, the people who conduct the processes.

To provide insight on that challenge, this paper has extended existing research on healthcare interoperability by studying collaborative care delivery and the processes that take place within it. We used a conceptual framework from a collaborative care case study to identify a set of interoperability requirements that were focused on the processes needed to support collaborative care delivery. We then used these requirements to develop a mashup based framework for multi level healthcare interoperability. The framework facilitates flexible, useful and effective interaction and management of different data sources, actors and healthcare processes. Therefore, it can be seen as a real collaboration framework specifically designed for healthcare environments. We believe that our framework provides the foundation for supporting process interoperability by consolidating Web 2.0 technologies, communication channels and data sources in a single environment. Finally, we introduced mashup patterns for facilitating interoperability within the framework. We also implemented three scenarios to provide proof-of-concept of how our framework and mashup patterns can be used for developing a collaborative healthcare environment.

The innovation in our work resides in the fact that not enough attention has been paid to process interoperability and how to achieve it. This paper is the first research that has used mashup technologies to achieve interoperability at the process level. We suggest that understanding the interoperability requirements we identified will trigger new ways of thinking about interoperability and how we can build new solutions to support it. The key message from this paper is that designing technological artifacts for healthcare requires interoperable systems and interoperable people and processes who will use the systems. Therefore, a shift from a technology-driven implementation to an implementation driven by an understanding of how people, technology and processes interact is needed. As a result, in order to design an interoperable healthcare environment, we should have a thorough understanding of the technology, in our case mashups and their patterns, and how that technology can address unmet interoperability requirements at all levels including data, team, social and collaborative levels.

This paper has also extended interoperability research by providing a methodology for identifying interoperability requirements in collaborative healthcare settings, and then developing an architecture to implement these requirements. There are several models that describe aspects of collaborative care delivery, similar to the awareness model used in this paper. However there are few studies that have looked at how to design information systems to implement these models. Content analysis allowed us to use an existing conceptual model to make sense of the complexity of collaborative care delivery and the interoperability requirements that are needed to support it. Our research approach provided a practical tool to build on existing research in order to understand the technical and behavioral (i.e., process, collaborative, social) aspects of interoperability.

This paper also provided a set of six interoperability requirements that focused on process interoperability. These requirements can be used as a starting point for identifying process interoperability requirements in other settings. The requirements also demonstrate the breadth of processes that are part of collaborative care delivery. Through our mashup based framework we provided proof-of-concept implementations of four of the six interoperability requirements. As described earlier, policy and procedure and knowledge exchange interoperability were not implemented because of the challenge posed by the dynamic nature of those two types of interoperability. Further research is needed to develop solutions for facilitating policy and procedures and knowledge exchange interoperability.

In addition, although we discussed privacy and security requirements in our proof of concept implementations we did not articulate in detail the security and privacy interoperability requirements. These requirements will be formalized and used when implementing and evaluating our framework in clinical settings to protect the confidentiality of sensitive medical data. The two perspectives of privacy and security requirements identified in Section 4.7 need to be followed. Attention also must be paid to region specific privacy and security legislation. Our research takes place in Canada where the applicable privacy legislation is the federal Personal Information Protection and Electronic Documents (PIPEDA) act. Electronic exchange of healthcare data must abide by PIPEDA.

Although we used proof-of-concept implementations to demonstrate our framework we have not done any formal evaluation of the framework. Evaluation is a next stage of our research. Interoperability evaluation is complex and we suggest evaluation needs to take place at the micro and macro levels. The micro level will evaluate the framework from the perspective of the care providers and patients who would use the system. That evaluation would include qualitative evaluation approaches such as usability testing by providers and patients to ensure the applications developed from our framework are useful and useable. Micro level evaluation could also include patient and provider satisfaction with the various interoperability processes. For example, we need to ensure that collaboration interoperability actually enhances asynchronous collaboration between providers and that social interoperability provides tangible benefits to patients. Micro level evaluation must ensure that the applications we design facilitate interoperable processes and interoperable people. Macro level evaluation would look at the impact of our research on health systems issues such as the IOM objectives described in the introduction. That would include evaluating the extent we our research provides access to safe, effective, and personalized patient care across multiple providers and settings. Access to services is a key evaluation consideration. Our aging population will require more healthcare services to be provided in patients’ homes or smaller healthcare settings rather than traditional delivery settings such as hospitals or hospices. Virtual collaborative environments such as the one presented in this paper could become very significant for supporting different modes of healthcare service delivery.

Limitations of our paper are that the interoperability requirements and mashup based framework were based on a case study in one setting. Other interoperability requirements and the mashup based technologies to support these requirements may emerge in other settings. Another limitation is we implemented our framework using one specific mashup tool (IBM Mashup Center) and other tools exist for developing mashup based environments. Future research will also involve implementing our framework using other mashup tools.