Interoperable support for collaborative, mobile, and accessible health care

Abstract

E-Health systems, through their use of Internet and wireless technologies, offer the possibility of near real-time data integration to support the delivery and management of health care. In practice, the wide range of choice in technologies, vendors, protocols, formats, and information representations can make even simple exchanges of information between systems problematic. Much of the focus on healthcare interoperability has been on resolving interoperability issues of system to system information exchanges. But issues around people to people interactions and people to system interactions are just as important to address from an interoperability point of view. In this paper, we identify interoperability deficiencies in collaborative care delivery and develop a methodology in two parts. In the first part, an ontology is developed to represent collaborative care delivery. In the second part, the ontology is used to design an architecture for interoperable clinical information system design. We then use a case study in palliative care to provide a proof of concept of the methodology. The case study provides an inventory of the interoperability requirements for palliative care and a perspective on the design and implementation of a people oriented clinical information system that supports collaborative health care delivery in palliative care.

1 Introduction

The Institute of Medicine (IOM) has described how our current healthcare system delivers inadequate care for several reasons including: the growing complexity of science and technology; increases in chronic conditions, which are now the leading cause of illness, disability, and death; a poorly organized delivery system; and constraints on exploiting the revolution in information technology (IOM 2001).

The predominate implication of our aging population and the increased prevalence of chronic illness is that the healthcare system and the way we currently deliver healthcare services are unsustainable (Coiera and Hovenga 2007; WHO 2010). A sustainable healthcare system is one that has the necessary resources to meet current objectives but also has the ability to adapt to future needs (Coiera and Hovenga 2007). The IOM study has stated we need to strive for a healthcare system that provides efficient, effective, timely, safe, and equitable patient centered care that is provided via collaborative teams (IOM 2001). While no one would dispute the above IOM objectives, the ultimate challenge is how to operationalize them as actual elements of healthcare delivery. Those objectives must be transformed into architectures and models to support the design and evaluation of health information technology (HIT). However, designing HIT to achieve those objectives in the context of collaborative care delivery is challenging as it requires the integration of multiple health care providers across different locations, care processes, and information formats over extended periods of time. Further, care delivery is no longer solely provided in hospitals or care centres but rather is expanding to communities and patient’s homes. Thus, supporting collaborative healthcare delivery will require a variety of technologies such as electronic health records, decision support systems, collaborative tools, mobile technologies and applications to support a range of processes including information sharing, communication, treatment provisioning and the retrieval of clinical guidelines and research evidence.

Implementing the IOM objectives in the context of collaborative care delivery requires the integration of people, data, technology and processes. Interoperability is the driver for achieving those objectives and the true test of interoperability will be how well it helps us achieve those objectives. However a challenge is that interoperability is complex and can have many facets to it including technical, semantic and process interoperability (Benson 2010). Although a substantial body of research exists on healthcare interoperability, much of it is focused at the technical level to resolve issues of system to system information exchanges. As healthcare delivery moves from a single provider setting to collaborative care delivery with multiple providers, settings, information types and technologies, we will need to expand our perspective of interoperability. We need to consider the people, technology and clinical processes as part of interoperability. Interoperable computer systems are not beneficial if the people using the systems and the business processes they engage in are not interoperable with the technology.

In this paper we take a people oriented perspective on healthcare interoperability for the design and implementation of HIT to support collaborative care delivery. We emphasize the need for interoperability of people, care processes, technology and the information used in healthcare delivery. The paper has seven sections. In section 2, we provide background information on e-health and health information technology, interoperability, and collaborative care. In section 3 we describe the approach used in this study. In section 4 we define our problem statement in terms of architectures and technology to support collaborative care delivery and then use the problem statement to develop a methodology based on an interoperability, ontology, and architecture. In section 5, we implement the methodology using a case study in palliative care. In the case study, we identify interoperability needs and potential technologies to address collaboration between organizations and providers. We also address integration of other technologies (including mobile devices) across different locations, and accessibility of the right information, in the right format, for the right process, at the right time. Section 6 provides an evaluation of our research. We conclude with a discussion of our findings and future research arising from the paper.

2 Background

2.1 E-health and healthcare information technology

Although E-health can be broadly defined as the application of information and communication technology in the health care sector, multiple definitions of the term do exist. A 2005 systematic review found definitions for the term E-Health that included tools to enable a process, function or service to assist or enhance healthcare delivery (Oh et al. 2005). A common aspect of many definitions was the emphasis that E-Health tools enhance or support human activities but do not replace them.

One of the key recommendations from the 2001 IOM report was that health information technology (HIT) would be a key enabler of integrated, collaborative healthcare delivery across multiple sites and providers. However, to date the widespread implementation of HIT has been challenging with large numbers of HIT projects being designated as failures (Avison and Young 2007). A key lesson learned from these HIT failures is the need to understand the underlying processes and contexts of how the HIT is used. For example, in their evaluation of computerized physician order entry (CPOE) systems, Ash et al. identified a number of unintended consequences with CPOE usage including workflow, changes in power structures, and communication issues (Ash et al. 2007). It is important to point out that the CPOE systems functioned as required, meaning they facilitated order entry, and thus were successful from a technical perspective. However the CPOE systems were not interoperable from a workflow, business process, and human and social system perspective.

2.2 Healthcare interoperability

Healthcare interoperability can be looked at from different perspectives including technical, semantic and process (Benson 2010). Technical interoperability is the exchange of messages across two computer systems without understanding their meaning and includes XML, web services, and service oriented architectures (SOA). Semantic interoperability is a more advanced messaging that includes common information models and terminology (Blobel and Pharow 2009). Semantic interoperability includes clinical terminologies such as the Systematic Nomenclature of Medicine (SNOMED), International Classification of Diseases (ICD), Logical Observation Identifiers Names and Codes (LOINC), and The Canadian Classification of Health Interventions (CCI). Clinical terminologies provide a controlled vocabulary to provide more structured and shareable data then free text (Park and Hardiker 2009). A more advanced type of semantic interoperability development is the HL7 Reference Information Model (RIM), an object oriented model based on UML that represents clinical data as acts, entities, roles, and participation (Schadow et al. 2006). Other advanced semantic interoperability efforts include EHR interoperability archetypes to enable the exchange of data across EHR systems, an example being the data archetypes for the openEHR (Garde et al. 2007).

Process interoperability refers to interoperability of the people and work processes that interact with the technology (Benson 2010). Even if computers are able to exchange and understand data it does not mean the people using the systems are interoperable. Prinejad et al. point out the need to make a distinction between interoperable systems and interoperable people (Pirnejad et al. 2008). That distinction is consistent with the concept of E-Health tools enhancing but not replacing human activities.

2.3 Collaborative care delivery

Collaborative care delivery is advocated as beneficial for complex patient cases owing to the contribution of multiple providers. Palliative care is an excellent domain to study collaborative care delivery as it a complex domain of medicine that addresses the physical, psychological, social, and spiritual needs of individuals with chronic or terminal illnesses (Ferris et al. 2002). The aging population and patients surviving longer periods with chronic illnesses will greatly increase the need for palliative care in the forthcoming years. Designing HIT to support palliative care delivery is one way of ensuring that we can maintain a sustainable palliative care system in order to provide quality services to a growing population of patients (Carstairs 2005). Although some research exists around HIT design to support palliative care, much of it has taken place in inpatient settings such as hospices or has focused on the design of very specific systems such as pain management or consultation (Kuziemsky et al. 2008; Demiris et al. 2008). As the need for palliative care services increases, more of these services will need to be provided outside of hospitals in community clinics, long term care centres, and patient’s homes. Management of other chronic illnesses such as cardiac disease is also collaborative in nature and is also shifting towards community based care delivery.

The key message from the above literature is the need to expand interoperability to include the interaction between people, processes and technology and not just data and technology. Coiera has pointed out that health systems are socio-technical systems, involving the interaction of people and technology and that we cannot design technical systems without a thorough understanding of how to make all the parts interoperate smoothly (Coiera 2004). We believe a key shortcoming in existing interoperability research is that it has focused on syntactical and to a very limited extent semantic interoperability. Interoperability of processes and how actors, information, and technology integrate with processes is an under researched area. This paper attempts to address that shortcoming.

3 Approach

Our methodology is grounded in design science research (Hevner et al. 2004). Design science research uses a cyclical model of design, build, and evaluation of outcomes in order to develop constructs, models, or methods. Outcomes from design science research can be a model or framework to address a problem or it can develop new research questions to facilitate further studies.

This study reports on our analysis of a palliative care consultation team as part of requirements engineering for a palliative care information system (PAL-IS). We followed the iterative nature of design science. The three parts of our results: problem statement, methodology for designing an interoperability ontology and clinical information system architecture for collaborative care delivery, and case study, evolved over several months and several iterative discussions with different palliative care providers including physicians, nurses and administrators. We would meet with the providers to gather requirements and then analyze those requirements to understand data, process and technology interoperability requirements necessary for the design of PAL-IS. In obtaining and analyzing the requirements for PAL-IS we identified several interoperability requirements that are necessary to support collaborative care delivery. Those interoperability requirements are the basis for the results in this paper.

4 Results

Our results are presented in two sections. In section 4.1, we describe our problem statement of developing interoperability architectures and technologies for collaborative care. Section 4.2 presents our methodology for developing a conceptual framework for interoperable collaborative care delivery. The framework consists of an ontology and architecture for a clinical information system to implement the ontology.

In section 5 we demonstrate proof of concept by implementing the methodology using a case study of palliative care.

4.1 Problem statement—interoperability architectures and technologies for collaborative care

Collaborative care delivery is challenging as it requires integration of healthcare processes across many different actors, technologies, information formats and settings. Although interoperability standards exist at both the technical and semantic levels, to date there is no comprehensive architecture for interoperability to support collaborative care. There are several interoperability concepts that need to be considered for collaborative care.

One concept is the range and different means by which clinical processes take place. First, there are a number of different processes that exist. Assessment, decision making, care planning, and therapy provision are just some of the processes involved in care delivery. Second, team based healthcare delivery is often provided asynchronously and thus the above processes are frequently separated by time and space. Third, the different processes will be conducted by different actors, each of whom will have their own unique needs with regard to conducting the processes. For example, nurses predominately collect and input patient data in written format while physicians frequently dictate oral data.

Another concept is the different technologies that are used to support processes. Electronic health records, clinical decision support systems, video, e-mail and handheld point of care computers (e.g. smartphones) are just some of the technologies that can support palliative care (Pereira 2009). A key consideration with respect to technology is that providers are becoming more mobile as part of care delivery, particularly as they move across multiple settings. The reason providers like the paper based chart is they can carry it with them and input and access data in different locations. HIT need to be designed to give providers the same mobile functionality they get from the paper chart. As patients become more involved in their own care delivery we need to remember they are often also similarly mobile and they will also require different technologies to support their care delivery. We need to ensure that data is appropriately gathered and disseminated without disrupting the mobility of the various actors (Kalagiakos and Ikonomou 2009).

Related to the technology concept are the modalities of how data is collected and communicated as part of healthcare delivery. That concept is very much about interoperability at the person to person and person to technology level. For example, much of the palliative care patient population is of increased age and the level of comfort and/or access to technology can vary. Although applications such as web based patient portals can be helpful for facilitating care delivery we cannot assume that all patients have the comfort, desire or means to use such applications. As we design interoperability architectures and technology to implement them we need to consider interoperability at the lowest common denominator to ensure that processes are interoperable for all relevant actors. Designing HIT solutions that use cutting edge technology is not always the best solution if the actor using the technology is not at the same level.

Finally, the formatting and presentation of information must be considered. Healthcare is an information intensive domain and information management is a key part of care process delivery. Although the use of clinical evidence is advocated for safe healthcare delivery, it is difficult to implement. Clinical practice guidelines (CPGs) are one way of incorporating evidence into clinical practice to support healthcare delivery (Shiffman et al. 1996). However it is estimated that approximately 30,000 scientific articles are published annually (Choi 2005) and thus the access and filtering of evidence requires significant time and effort on behalf of the information seeker.

We also need to consider the volume and format of the different information sources. As the volume of healthcare information increases so does the potential for information overload which can cause cognitive overload, knowledge overload, and communication overload on the users of the information (Eppler and Mengis 2004). Aside from the volume we must also consider the format of the information. Providers who conduct healthcare processes may require access to data across many different settings and technologies. We must ensure that information is accessible and interoperable across those settings and technologies.

4.2 Methodology to represent collaborative care delivery

An informatics saying is that before we can informate something we must model it (Berg and Toussaint 2003). A challenge in addressing the problem statement is that there does not exist a formalized way to model the multiple concepts used as part of collaborative care delivery. Thus we present a methodology that has two parts. First is the development of an ontology to represent collaborative care delivery. Second, the ontology is used to design an architecture for interoperable clinical information system design. Each part of the methodology is described below.

4.2.1 Ontology to represent collaborative care delivery

As a first step towards addressing the interoperability needs for collaborative care delivery we developed an interoperability ontology. Numerous definitions exist for ontologies. We subscribe to Musen’s definition that an ontology is a theory that represents the domain concepts (the ontology) and the algorithms that must be applied to those domain concepts to solve problems in the domain (i.e. the problem-solving approach) (Musen 2002). Ontologies are commonly used to model domain areas for information systems design or for generating and validating information system components (Fonseca 2007).

We designed an ontology as a first step in our research for two reasons. First, there currently is not an overall model for representing interoperability needs to support collaborative care delivery. Our ontology represents the range of concepts and complexity of interoperability issues that need to be solved in order to support collaborative care delivery. Second, is the reusability factor. The true value of an ontology is that they are not specific to any one setting and thus can be used as a methodology for assessing and modeling collaborative care needs in other settings.

Figure 1 shows our interoperability ontology for collaborative care delivery. The ontology is not specific to any collaborative domain but rather is a general ontology for collaborative care delivery. In developing the ontology there are two key tasks that need to be done. The first task is identifying the concepts within the ontology and the second task is defining the relationships between the concepts. We discuss each task below.

Fig. 1

Interoperability ontology (first level concepts are grey boxes, second level concepts are rectangles with rounded corners, cross concept relationships are broken lines)

For task one, there are two levels of concepts in our ontology, first and second level concepts. First level concepts are general concepts and they should draw upon existing ontologies whenever possible. In our ontology there are five first concepts that need to be defined: actors, technology, information, guidelines and processes. These concepts are shown as grayed boxes in Fig. 1. The first level concepts are similar to concepts in other biomedical ontologies such as the Unified Medical Language System as well as in other formal models such as Business Motivation Model (www.BusinessRulesGroup.org). The difference with our ontology is we are modeling the concepts specifically to represent collaborative care interoperability.

Second level concepts provide specificity to make the ontology relevant for collaborative care delivery. For example, care planning, case manager and auxiliary provider are concepts that are specific to collaborative care delivery. Second level concepts are shown as rectangles with rounded corners and have a IS-A relationship with the first level concepts. Some second level concepts have sub-concepts that represent more specific second level concepts and are designated with Type-of relationships.

The remainder of task one involves modeling all the ontology concepts. The actor concept includes patients, providers and administrators. For providers we make a distinction between medical providers (e.g. physician, nurse) and auxiliary providers such as a case manager. That distinction is because the process, technology and information will be different for those two types of providers. The technology concept includes input/output technologies (i.e. e-mail, computer systems, telephones, faxes), mobile tools (i.e. smartphones), alert and monitoring systems, groupware systems, as well as different modalities of technology such as interactive voice response (IVR) or voice recognition systems. The technology concept also includes the Internet and application services such as Web Services. Processes can be clinical tasks such as assessment, diagnosis, therapy or care planning, or administrative tasks such as workforce planning, performance management, or calculating wait times or other quality indicators. Information can include clinical data specific to a patient, general research evidence intended for multiple patients, or aggregated administration information for performance management or quality improvement tasks. The information concept also includes data and terminology standards to support interoperability of information across different systems. The guideline concept represents clinical practice guidelines and other guideline based formalisms of information. Guidelines format and manage information to ensure the right information is available for the right process at the right time and perhaps most importantly, in the right format. Cardiology, palliative care and oncology are shown as specific examples of guidelines. Overall the ontology represents the breadth and depth of interoperability challenges as any combination of two or more of the five ontology concepts can represent an interoperability challenge.

Task two involves defining the relationships between the concepts. This task is analogous to defining the problem solving approaches for the ontology as the relationships bring concepts together to solve collaborative care interoperability problems. In Fig. 1 we have outlined several interoperability relationships across all the ontology concepts using broken lines. We refer to the relationships as interoperability synchronization points where an interoperability issue needs to be analyzed and solved. For example, an actor ‘engages in processes’ and is ‘supported by’ technology that ‘collects and processes’ information. The multiple interoperability relationships in the ontology illustrate how complex interoperability is for collaborative care delivery and how much of that interoperability is for concepts other than data.

Our ontology provides a comprehensive perspective on healthcare interoperability. Existing interoperability research has largely focused on the technology concept with some progress on information and guideline interoperability. Actor and process interoperability have been largely ignored. To achieve true interoperability we need to consider different variations of the ontology and the integrated relationships between the ontology concepts.

4.2.2 Architecture for interoperable clinical information system

The second part of our methodology involves using the ontology concepts to design a clinical information system (CIS) architecture to support collaborative care interoperability. The CIS architecture implements the solutions to solve the collaborative care interoperability problems defined in the first part of the methodology.

This generic CIS architecture shown in Fig. 2 is not functionally complete, but rather focuses on interoperability. It is layered according to the five first level ontology concepts (Actors, Processes, Guidelines, Information, Technology as labeled on the right in Fig. 2):

• The layer implementing the Technology ontology concept includes Mobile Computing (Smartphones, Laptops, etc.), Voice Recognition and Interactive Voice Response (IVR) system for a Patient Portal, Groupware technology to set up video-conferences between care team members and share documents. There is also a Data Mediation function used by the Information ontology layer. Finally, the SOA infrastructure and the Communications middleware enable the physical interoperability with other systems.

• The layer implementing the Information ontology concept includes:

• ○ The patient Database and Data management

• ○ The interfaces to the EMR/EHR with which the clinical information system shares patient data

• ○ The interface to Disease registries (i.e. Diabetes, Heart Failure, etc.) and to Treatment registries (i.e. Cardiology).

• ○ The interface to Dictionaries and Terminology servers (i.e. SNOMED)

• ○ The interface to other clinical information systems (i.e. Laboratory Information Systems, Diagnostic Imaging Information Systems, Computer Physician Order Entry systems)

• ○ The interfaces to the healthcare service provider management information systems, including healthcare analytics systems.

• The layer implementing the Processes and Guidelines ontology concept. This layer is the core of the clinical information system as it drives the completion of processes and the implementation of guidelines to support care delivery. The implementation of this layer is very specific to the domain where the clinical information system is being designed (i.e. cardiology or palliative care).

• The layer implementing the Actors ontology concept with IS functionality to conduct processes such as the patient portal, and graphical user interfaces for clinicians and administrators.

Fig. 2

Generic architecture of interoperable clinical information system

5 Case study

We now use a case study to illustrate proof of concept of our methodology. We use our ontology to illustrate interoperability requirements at different levels, particularly people to people interoperability, based on Medical guidelines, Care Processes, and Information Systems. In particular, we follow the scenario of a cancer patient transitioning to palliative care at end of life. Our study was done in collaboration with a palliative pain and symptom management consultation services (PPSMCS) team. This team provides consultative services to Family Health Teams (FHT) who are primary care physicians referring their palliative care patients to PPSMCS. Initial consultations take place in person with follow-ups occurring in person or by telephone. Consultations often involve suggestions by the PPSMCS team for pain and symptoms management that are acted upon by the patient’s FHT. At the same time, many of the palliative care patients are also cancer patients who also visit the cancer center for treatment by an oncologist.

To develop the necessary infrastructure to support the above organization of care delivery, we need to look at interoperability from several perspectives. First is the need for collaboration between multi-disciplinary team members. Second is the need for data integration, process interoperability, and guideline compliance which support the collaboration. Third is the need for different information systems and technologies which enable the collaboration.

5.1 Cancer patient journey in palliative care

Figure 3, shows the various health care organizations that collaborate while supporting a cancer patient through palliative care at the end of life. In the figure, thick arrows represent the patient journey through the palliative care system while thin arrows represent support or resources provided to the patient during the journey. We will analyze a particular scenario using a patient with lung cancer, John, who has been identified as palliative, and who is starting the journey in the palliative care system.

Fig. 3

Collaborative care of palliative cancer patient

• 1. John is followed by his primary care physician in the Family Health Team (FHT), who is using the consulting services of the Palliative Pain and Symptom Management Consultation Service (PPSMCS) team.

• 2. John’s condition is identified as suitable for home care. He is referred to the Community Care Access Center (CCAC) who assigns him a case manager

• 3. The CCAC case manager coordinates the delivery of care to John at home with a variety of providers. In this case, they include a homecare nurse, a social worker, a psychologist, a spiritual counselor, and a personal services worker.

• 4. While in homecare, John may need to go to the Cancer Center where he is followed by his oncologist for some symptomatic treatment.

• 5. If acute care is required, John would go to the hospital. It is an objective for the palliative care system to minimize such acute care hospitalization.

• 6. In the last few weeks of life, if John’s condition becomes too complex for homecare, he may be referred to a hospice. However, many patients prefer to die in their home.

5.2 Interoperability ontology for palliative care

The first step in understanding the interoperability requirements for palliative care was to use the interoperability ontology from section 4.2 to model the interoperability requirements for palliative care. The palliative care ontology becomes an ‘inventory’ for palliative care interoperability and represents a specific instantiation of the ontology from Fig. 1. The ontology was developed in an iterative manner through the ongoing meetings we had with the palliative clinicians in our study.

The following is the non-exhaustive interoperability ontology for palliative care showing the concepts for the five first level ontology concepts.

5.2.1 Actors

• Patient @ Home

• Primary Care Physician @ Family Health Team (FHT)

• Palliative Pain and Symptom Management Consultation Service (PPSMCS) Consultant

• Case manager @ Community Care Access Centre (CCAC)

• Oncologist @ Cancer Center

• Homecare Provider (Homecare Nurse, Social Worker, Physiotherapist, Psychologist, Dietitian, Spiritual Counselor, Pharmacist, Personal Services Worker,…)

5.2.2 Processes

• Patient Discharge from Cancer Center or Hospital

• Patient Consultation with Primary Care Physician

• Consultation with PPSMCS

• Patient Admission to Homecare by CCAC

• Case Management by CCAC

• Patient Consultation with Oncologist

• Collaborative care Planning

• Patient self-management

• ○ Use of PC assessment tools

• ○ Access to PC resources and information

• Documents

• ○ Hospital Discharge Summary

• ○ Care Plan

• ○ Prescriptions

• ○ Test results

• ○ Do not resuscitate (DNR) form

5.2.3 Guidelines

• Palliative care

• ○ Pain Management

• ○ Symptom Management

• Assessment Tools: Edmonton Symptom Assessment Scale (ESAS), Palliative Performance Scale (PPS)

• Cancer care

5.2.4 Information

• Patient demographics

• Patient medical history

• Current Prescriptions

• Test results

• Imaging results

• Recommendations from PPSMCS consultants

• Care Plan

• Hospital Discharge Summary

5.2.5 Technology

• Communications: phone, pager, fax, internet access, email

• Dictation Systems

• Groupware: audio-videoconferencing, document sharing

• Electronic Medical Records

• Internet: Web Sites and Web Services

• Alerting and Monitoring

• Voice Enabled Technologies: voice recognition, interactive voice response (IVR)

• Mobile Computing (smartPhone, laptop, etc.)

In the context of palliative care this ontology does several things. First, it provides the conceptual framework for analyzing the requirements for people-people and people-system interoperability, analyzing the requirements for process interoperability and information integration, and for analyzing the requirements for facilitating guideline compliance and interoperability. Second, it provides the interoperability architecture for designing and evaluating the technology needed to support palliative care delivery.

Each of the above interoperability requirements are described in the following sections.

5.3 Requirements for people-people and people-system interoperability

We focused on the collaboration requirements of the primary care physician at the FHT in analyzing people-oriented interoperability because they are on the front line of service delivery to the patient. Their main collaboration-based tasks in this case study are:

• Consultations with PPSMCS for their palliative care patients

• Referrals of palliative care patients to CCAC for homecare

• Planning and coordination of care with CCAC case manager and other palliative care team members

• Keeping cancer center oncologist informed on patient treatments

• Follow-up and monitoring of patient pain and symptoms

The above tasks have been analyzed, using the ontology conceptual framework, in order to understand what would facilitate the collaboration between the tasks them. The analysis showed that team members first need the standard communications tools (phone, pager, fax, internet, email), the ability to set up audio-videoconferencing sessions on demand, the ability to electronically share documents, and the ability to access data remotely. It is important that these tools are usable anywhere and at any time, not just from their individual offices. The individuals themselves are often not at their office during the day but rather at different locations. As well, it must be possible to respond and interact outside office hours when the patient is in need. Healthcare service delivery is a 24/7 process. The required technologies are available and it is simply a matter of putting in place the physical channels and tools for communications.

Then, another level of communications also needs to be enabled, more at the process and information level, with the objective to facilitate compliance to medical guidelines. This semantic interoperability has to be tightly integrated into the care processes of each team member in order to be as non-disruptive as possible; otherwise we run the risk that the team members end up not using the clinical information system. This is detailed in the next section.

5.4 Requirements for process interoperability, information integration, and for facilitating compliance with medical guidelines

Accreditation Canada specifies process guidelines and quality of care indicators (Accreditation Canada 2010) for the palliative care patient consultation process that the PPSMCS Consultant follows with the primary care physician which includes filling in forms for the following information:

• 1. Current patient condition

• 2. Medical history

• 3. Allergies

• 4. Medication profile at time of visit

• 5. Social history

• 6. Physical examination

• 7. Symptom analysis, Assessment, Recommendations

• 8. Proposal for Place of care and Goals of care

• 9. Follow up plan

On the other hand, the oncologist and the CCAC case manager follow a slightly different process and fill out a collaborative care plan as defined by Cancer Care Ontario (Cancer Care 2009). The collaborative care plans define the activities, interventions and expected patient outcomes that should occur for patients requiring palliative services based on their functional performance as defined by the Palliative Performance Scale (PPS). They are aligned with the Canadian Hospice Palliative Care Association model (Ferris et al. 2002) which identifies six essential and basic steps during a patient encounter, and 8 domains of issues associated with palliative care.

The six essential and basic steps during a patient encounter are:

• 1. Assessment

• 2. Information sharing

• 3. Decision making

• 4. Care planning

• 5. Care delivery

• 6. Confirmation

The eight domains of issues are:

• 1. Disease management

• 2. Physical

• 3. Psychological

• 4. Social

• 5. Spiritual

• 6. Practical

• 7. End-of-life care/death management

• 8. Loss, grief

Despite the fact that the palliative care team members may be following different care processes in different care settings, they are all complying with the palliative care guidelines (or best practices) on pain and symptom management. For the team members to easily collaborate while performing their interventions, their clinical information systems have to provide synchronization points for people-people communications, based on a semantic understanding of the care processes using the ontology, reinforced by a semantic understanding of the palliative care guidelines. A detailed example is given in section 5.7.

5.5 Available technologies for supporting palliative care

The key technologies we have explored relevant to the scenario are:

• A web-based clinical information system, supporting the care processes of the primary care physician at the FHT, and the PPSMCS Consultant.

• A dictation system that allows physicians to dictate their notes and have them transcribed.

• The management of alerts and reminders to support and promote guideline compliance

• The automated collection of ESAS scores from patients, using voice-enabled technologies like Interactive Voice Response

• Groupware technology for setting up audio-videoconferencing and for sharing documents.

• Integrated access to patient data that is stored at electronic medical records (EMR) at the various institutions.

The clinical information system, being web-based is accessible from anywhere provided that either Internet connectivity or wireless Internet connectivity (via cell phones) is provided. Since clinicians do not always have access to a desktop computer in an office, mobile devices (smartphone, laptop) are supported to access the clinical information system.

We are also working on a Voice Recognition system used in the mobile devices in order to promote voice as the main input media instead of a keyboard. That type of input would support elderly patients whom might be less comfortable with technology. Voice recognition would also replace the dictation system used by the clinicians to fill in their consultation forms.

5.6 Interoperability architecture for a ‘people-oriented’ clinical information system

The different technologies described in the previous section are not disparate technologies but rather they must be integrated into an architecture that provides the appropriate technology for the appropriate actor, process and information. We refer to that as ‘people oriented’ interoperability. The architecture of the clinical information system enabling ‘people-oriented’ interoperability is illustrated in Fig. 4. We describe the components of the system below the figure.

Fig. 4

Interoperability architecture of palliative care clinical information system

The clinical information system is composed of the following modules:

• The application supporting the palliative care processes and guidelines has Decision support capabilities. It is in charge of managing and processing the electronic forms implementing the care processes.

• The patient database

• The alert and reminder management module which has a built-in knowledge of palliative care guidelines, and can generate events to the attention of the users in order promote and facilitate compliance with guidelines (for instance, when the ESAS score goes above a threshold, or when the PPS goes below a level necessitating to start End-of-Life care).

• The module enabling the attachment of transcriptions, prescriptions and lab results to the patient records

• The interface to the Electronic Medical Records and Clinical Management Systems of the FHT, PPSMCS, Cancer Center, CCAC

• The Interactive Voice Response module in charge of managing the collection of ESAS scores from the patient, and monitoring the evolutions of these scores

• The groupware module in charge of setting up audio-videoconferencing sessions and sharing documents

• The module for performance reporting and feedback to the clinicians.

• The web-based graphical user interface for presentation to the care team members

5.7 Example of collaborative care

We now illustrate how the many facets of interoperability are addressed by looking at the example of collaborative care planning for our patient. John’s condition has degraded during the last few days. His PPS level has now come down to 30%, and he is experiencing frequent delirium episodes. John’s primary care physician, following up on the latest consultation, is at step 8 and 9 of the palliative care patient consultation process. The physician’s clinical information system also directly supports the palliative care collaborative care plans and palliative care guidelines, and detects that a PPS of 30% could be a trigger for starting the process of End-of-Life care. It automatically displays the relevant information to the physician. She decides to call for a meeting with the palliative care team members in order to make a team decision.

She sets up an on demand video-conference with the palliative care team members, based on their availability, in order to decide and then act on the decision. This can be done simply by pointing and clicking on her clinical information system which directly supports the consultation process, and hence integrates the groupware technology with the process flows. The PPSMCS consultant and the CCAC case manager are available and hence join the video-conference. A recording of the meeting will be sent to the oncologist and other care team members who were not available.

The physician shares her assessment of the patient’s condition with the consultant and the case manager. The team decides to start the End-of-Life care process. Another decision then arises about the care setting: should John remain at home, which is his wish, or should he be transferred to a Hospice. Based on the available information that the physician shares with the team, they decide to keep John at home.

Then, the team has to build a follow-up plan with action items. The physician’s clinical information system automatically displays the collaborative care plan for the End-of-Life stage, with the suggested steps and domains of issues. She shares these with the team, and they quickly complete the follow-up plan for John.

6 Evaluation

The key message from this paper has been that healthcare interoperability is complex and all of the ontology concepts and the relationships across the concepts must be considered. We evaluate our research using the concepts from the interoperability ontology. In keeping with the design science research method, the evaluation demonstrates how our research has provided new insight to a problem and a new framework for understanding the problem. The evaluation is not an empirical evaluation but rather intended to show how our research has provided utility over other approaches (Hevner et al. 2004)

Table 1 shows our evaluation matrix. The matrix examines the ontology concepts against the interoperability issues from the problem statement (i.e. current practice) and the collaborative care example (i.e. ideal practice). Column 1 shows the ontology concepts, column 2 shows the interoperability issues of current practice (from the problem statement—section 4.1) while column 3 describes the ideal practice where the interoperability issues are solved using the ontology.

Table 1 Evaluation matrix

The evaluation matrix provides insight on the complexity of interoperability to support collaborative care delivery. All five ontology concepts must first be modeled and then the relationships must be defined across all the concepts in order to understand all the interoperability types (person to person, person to technology, process to information, information to guideline, process to technology etc.). Further, certain concepts have deeper levels of complexity. For example, the person to technology relationship needs will change depending on the actor. Clinicians may prefer a desktop PC for certain processes but require a mobile PC for other processes. Patients will also have different technology needs depending on their level of comfort and access to technology.

To address the aforementioned complexity we have provided a technical architecture based on the ontology to support the interoperability needs for collaborative care delivery. The case study and collaborative care planning example showed how the architecture can be used to design technology to support the many types of interoperability in collaborative care delivery. For example, a clinical information system integrating groupware technology with the care processes and medical guidelines can facilitate and promote person-to-person and person-to-guideline interoperability.

7 Discussion and conclusion

The importance of healthcare interoperability as the driver of an integrated and sustainable healthcare has been repeatedly described but to date much of the interoperability research has focused on technical and semantic interoperability. As more healthcare delivery is provided by collaborative teams we will need to understand interoperability at all levels including people and process interoperability. Although technical and semantic interoperability is important for ensuring that computer systems can exchange and understand data there is little point in designing interoperable systems if the people and process interacting with the systems are not interoperable. Technology is only one concept of interoperability and we suggest that healthcare interoperability must begin with ‘people oriented interoperability’. Technology must be examined in the context of the people, processes and information that use the technology.

We have also provided the means of modeling the various aspects of collaborative interoperability. To date there is no comprehensive model for healthcare interoperability. This paper provides an ontology for modeling the interoperability needs of collaborative care delivery. The ontology contains five concepts (actor, technology, process, information and guideline) and can act as a meta-model for obtaining interoperability requirements and for understanding the multiple relationships that exist between the concepts. As proof of concept we used the ontology to develop an inventory of the interoperability requirements to support palliative care delivery and then to design an architecture for a people-oriented clinical information system to support palliative care delivery. We also described how the ontology concepts can be used for evaluation by providing a matrix that can be used to visualize interoperability issues in current practices.

The three key contributions from this paper are:

• 1. Identification of the interoperability deficiencies in current collaborative care practices at multiple levels including actor, process, information and technological deficiencies

• 2. A methodology based on an interoperability ontology to model interoperability concepts and the relationships across those concepts, and an architecture for an interoperable clinical information system.

• 3. Implementation of the methodology using a palliative care case study in order to design an interoperability inventory for palliative care and a technical architecture that supports collaborative care delivery

Shortcomings of our paper are that the methodology has only been implemented in one case study from one domain (palliative care). Variations on the ontology concepts and the technical architecture may arise in other settings. Another shortcoming is we have not formally evaluated our palliative care ontology or the technical architecture developed from the ontology. Future research will involve evaluation of the ontology using formal ontology modeling principles such as those outlined by Zhang and Bodenreider (2006) and design and implementation of the technical architecture as a palliative care information system (PAL-IS).