1. Introduction

This paper is related to the e-health domain and in particular to ICT applications to support care management in healthcare sector. Care management can be defined as a cyclic process of planning, coordination, management and review of person’s assistance in healthcare field selecting options and services that answer to his/her needs. The aim is to optimize self-care reducing the fragmentation of treatments and the hospital stay, improving the care quality thanks to the continuous supervision of a professional and promoting the effective use of the resources so as to improve the patient’s quality of life. The professional that makes such an objective possible is the Care Manager (CM) who represents the new professional figure for educating and coaching the patient and his family and relatives.

Care manager’s role is to facilitate and coordinate the care process determining objectives and duration of hospital stay and managing and guiding the assistance out of the hospital. The core concept at the basis of care management is to provide personalized treatments based on a care plan about service provision. Currently, such a plan is developedin collaboration with the patient; in fact an important goal assigned to the CM is to obtain confidence, trust and communication in the relationship with the patient. This goal is achieved by means of further refinements in the patient relationship management, where each cycle is based on the results of the previous one. In such a context, Information Technology assumes a crucial role for care managers, because it provides tools to support their de- cisions and to improve their interaction and communication with the patient. Some software applications already exist to support care management process. In this paper we analyze the results and the software used in a care management project developed in the Italian Apulia Region. This project, named “Leonardo”, represents the first phase of a care management initiative, applied to a local group of patients affected by chronic diseases (metabolic syndrome, cardi- ovascular disease).

The second phase of the project (which will be named “Galileo”) is planned to start at the end of 2011, so our res- earch effort has been addressed towards the identification of tools allowing a critical analysis of the results of the Leo- nardo phase in order to improve the Galileo one.

According to this idea we have tested Business Process Modeling, and in particular a modified version of the OMG standard Business Process Modeling Notation (BPMN), as the tool used for the detailed modeling of the care management process, and for further analysis of the results of the first run, developed in collaboration with the Regional Healthcare Agency.

The paper starts with the description of the state of the art about current techniques and methodologies for process modelling in Healthcare and their use to gather software requirements (chapter 2), then it continues with the description of the Leonardo Project (chapter 3). In chapter 4 we discuss the proposed approach to assess the results of the Leonardo Project through the BPM model of the AS IS and the TO BE care management process. At the end conclusions and references are presented.

2. Background

Research literature presents a large collection of diagrammatic representations of medical processes and computer interpretable guidelines ([1-3] among others). In[4] authors deal with the applicability of software engineering techniques to medical process definition and analysis using the Little-JIL process definition language. PROforma[1] represents guidelines in a logic/constraint based formalism. Each node represents a task (an action, a decision, and so on), while constraints (logical, temporal, …) link different tasks. Asbru[2] is a language that explicitly represents the intentions underlying a set of schematic plans which is the representation of a guideline. Besides representing actions (i.e. prescribe diuretics), Asbru contains primitives to represent goals (i.e. maintain blood pressure below 140). Guidelines written in Asbru are a set of hierarchical plans which associate actions with goals. GLIF [3] is a more generic representation language that combines aspects of the Arden Syntax, to represent decisions, with a flow diagram to represent actions flows. The GLIF model was not computer-executable until a recent version [4], when an interpretation abstraction level to the representation language has been added. Contributions[5] and[6] compare the representation concept against guidelines systems, whereas[7] and[8] compare the systems according to other aspects. Prodigy 3[9,10] developed at the University of Newcastle, models guidelines using states, which are called patient scenarios, and transitions. Noumeir has also pursued similar goals, but using a notation like UML to define processes[11]. Others (e.g.[12]) view medical processes as workflows and use a workflow-like language to define processes and drive their execution.

A recent research study has tried to define a full-scale healthcare business-process reference model in order to standardize processes taking into account both a business and an information systems perspective[13].

None of the analyzed process definition approaches, however, seems able to support process definitions that are both sufficiently clear and sufficiently broad and precise. The main problems with these approaches include inadequate specification of exception handling, weak facilities for controlling concurrency, lack of resource management, and inadequate specification of artifact flows.

In order to overcome these weaknesses and according to the idea that a business process approach can be particularly useful not only for business modelling but also to gather requirements for the development of software systems, we have initially chosen BPM to model the process associated to care management in Leonardo Project and then we have observed that BPM helps also to highlight indications about system requirements. In particular we illustrate how analyzing a care management project with tools borrowed from other domains can help to show weaknesses to be overcome in the design of the second generation’s tools.

Our idea is also supported by other authors and studies. Recently, in fact, a novel approach was proposed, called Use Process [14], which combines Business Process Modelling Notation (BPMN) and UML Use Case Diagrams in order to model requirements. The research position of these authors takes into account that the successful operation of the enterprises is based on their business processes, so they state that a Business Process-oriented approach to gather requirements can lead in a strong involvement of the customer in the requirements definition, and as a result a successful project. They developed the Use Processes (UP) approach to gather requirements, which consists of a Use Process Diagram (UPD) based in notation elements of the BPMN v2.0 and the Use Case Diagrams (UCD) of UML v1.5. Also they presented a set of templates to describe the elements of a UPD. The purpose of the UPD is to present a general view of the functionalities that a system must provide within the activities of a BP.

According to[15] using a business process-oriented approach to gather requirements can lead in the customer and user satisfaction because it allows their participation in the requirements definition. This is very important because the main customers of the software applications are business people who are usually very comfortable in working with visual representations of business processes.

3. The Leonardo Project

All The 24 months’ Leonardo Project started in 2006, promoted by the local healthcare agency in Lecce (Italy) in collaboration with Apulia Regional Healthcare Agency and Pfizer Italy, and involved about a hundred patients. It was the winner of the “Educating to the Health” category award at “Forum P.A. 2007” in Rome. The project aimed to introduce a new professional, the Care Manager (CM), in the context of local healthcare for chronic diseases according to a model imported from United States. Thanks to this pilot project several activities have been developed to improve the results. In the care process of the chronic diseases, CM is a professional useful to facilitate the communication between patients and Family Doctors.

The Chronic-degenerative diseases managed by CMs involved in Leonardo Project are three: Cardiovascular diseases, metabolic disease and diabetes.

The role of CM consists of relieving the Family Doctor from the routinely activities and of supporting the patient and his relatives in self care management. In particular he takes care of patients’ education, prevention, counselling, monitoring and assessment. In Leonardo Project the care manager uses InformaCare software as supporting tool for operational activities, purposely developed by Pfizer.

In the organization of healthcare services, Care Management (CM) is a new model for the treatment of chronic diseases and Leonardo project was one of the first implementations. To be effective, such a model needs gradual refinements in a continuous improvement perspective.

The research group working at Innovation Engineering Department of University of Salento was involved at the end of the Leonardo Project to assess it, analyzing its performance and the software InformaCare in order to identify its weaknesses for future reengineering to be applied in the further care management project called Galileo.

4. The Enterprise Modelling to Assess the Leonardo Project

The approach adopted by the research group to assess the Leonardo project was based on the following phases: first we have modeled the care management process as implemented in Leonardo Project (AS IS model) using BPM. Then we have analyzed the software package InformaCare supporting the care management process by identifying user profiles and functionalities; then we have analyzed the Key Performance Indicators identified by Pfizer for the care management process and finally we have conducted targeted interviews and questionnaires to CMs regarding the process and Informacare, in order to trace a new Business Process model associated to the improved process (TO BE model), elicit the new tool’s requirements and define performance indicators in order to control the whole system.

This approach is depicted in the following figure, which represents the iterative approach associated to the design of “purposely built systems”.title and author details must be in single-column format and must be centered.

Figure 1. Purposely built systems: iterative approach

In the design of a purposely built system, the inputs to be considered are the requirements and a complete analysis of the context in which the system has to run. These inputs allow building a model of the system. This model has to be analyzed comparing the expected results with the measured results (Key Performance Indicators) through a refinements cycle.

This approach is well suited to define the underlying model of the Care management process.

In the organization of healthcare services, Care Management (CM) is, in fact, a new model for the treatment of chronic diseases. To be effective, such a model needs gradual refinements in a continuous improvement persp- ective.

In our work we have experimented that Business Process Modelling tools are able to support these refinements. In particular, we have used a slightly modified version of the standard Business Process Modelling Notation (BPMN) to model the AS IS and the TO BE care management process. The slight modification consisted in changing the orientation of the swimlanes because, as a result of interviews with the CMs, this modification showed greater readability and ease of understanding.

BPMN is an OMG standard notation traditionally used to model enterprise business processes and not software systems. It was developed by the Business Process Management Institute to provide a modelling notation that is understood by all process modelers, users, analysts, etc. A standard Business Process Modelling Notation provides businesses with the capability of understanding their internal business procedures in a graphical notation and gives organizations the ability to communicate these procedures in a standard manner[14]. Furthermore, the graphical notation facilitates the understanding of the performance collab- orations and business transactions between the organizations. This ensures that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly.

Performances have been evaluated according to a stakeholders focus method, called HIGO. It is briefly described in the following section, because we consider a major improvement the use of a systematic tool for evaluating the performance of the system.

4.1. The HIGO Grid

Before to start any redesign project, it should be clear which performance aspects of the whole system are targeted for improvement. A useful conceptual framework for this purpose is the stakeholder oriented grid called HIGO® , which is shown in Table 1 and fully described in[16]. HIGO distinguishes three main performance dimensions along which the effects of redesign can be measured (cost, flexibility and speed, quality and satisfaction) and three stakeholders perspectives, namely (a) Managers who plan and control processes, (b) Customers who request a service and receive the output, and (c) Operators who work on the process. For each stakeholder, performances are measured by usual cost, quality and service metrics. Cost addresses process efficiency in terms of resources productivity, Quality addresses output in conformity with expected value. Service addresses responsiveness and flexibility. As shown in Table 1, Key Performance Indicators (KPI) are grouped in cells, as intersection of stakeholders (rows) and performance domains (columns).

Performances are referred to any series of activities executed by process stakeholders. So, the cost to manager can be referred to the whole series of the process activity (total cost) or to a specific activity subset (partial cost). The KPIs selected by the analyst will feed the business process / service cockpits of each stakeholder.

In most circumstances, it would be ideal if a redesign of a business process decreases the time required to handle cases, decreases the required cost of executing business process, improved the quality of the service delivered and improves the flexibility in order to better react to variation. The nasty, yet realistic, property envisioned in[16] is that, in general, improving upon one perspective or dimension may have a weakening effect on another. For example, reconciliation tasks may be added to a business process to improve the quality of the delivered service, but this produce negative effects on the timeliness of the service delivery. For each project and for each business process, it will be necessary to formulate how the various performance dimensions will be measured to establish and determine the goals of the redesign effort.

Table 1. The HIGO Grid COST FLEXIBILITY &SPEED QUALITY & SATISFACTION Manager Production unit costProductivityUsage/ workload Process durationActivity timelinessResource flexibility Technology dependabilitySpec conformity of service and products Customer Customer access/ Acquisition unit costCustomer use cost Response timeResponse timelinessVendor flexibility Expectation conformity of the serviceService dependabilityCustomer satisfaction Worker Execution unit costPreparation effort Technology response timeTechnology timeliness Activity & technology flexibility Expectation conformity of work /work environmentTechnology dependabilityEmploee satisfaction

4.2. AS Is Model of the Care Management Process

As highlighted in the background section, none of the currently used approaches to process modelling seems able to sufficiently support healthcare process definitions due to their lack of flexibility. So in this work we propose to borrow tools from Enterprise modelling to model healthcare process. We propose BPM and in particular a BPMN-like notation in a novel way because, according to the iterative approach for the design of “purposely built systems”, as we have stated above, the results of the model is used to define guidelines for a next phase of the process and for defining requirements in order to realize a new version of the software.

So at first we have made a context analysis and analyzed the process related to care management, as implemented in Leonardo Project and then we have represented such a process at gross granularity, using these diagrams to discuss with the stakeholders involved in the process and complementing them with textual descriptions (Figure 2).

Figure 2. BPMN-like model of Care Management Process in Leonardo Project (AS IS)

This process involves, at different level, three stakeholders: the patient, the care manager and the physician who generally is a General Practitioner (GP), even if in some care management activity he could be a Specialist.

Swimlanes with grey header mean that a software support is provided to the user through InformaCare.

The process starts following the expression of a need from a patient affected by a chronic disease. On the basis of the symptoms declared by the patient, the CM and the physician contextually execute a Multidimensional assessment taking into account both clinical and lifestyle parameters.

Following the multidimensional assessment, a personalized care plan definition process starts in which all the stakeholders are involved: the patient expresses his preferences about food, habits etc. This information is used by the physician to define a customized therapy; consequently the care manager defines an action plan in order to support the patient in the right execution of the physician’s recommendations.

Then the personalized care management process starts; it involves the following actions: the patient shares his agenda with the care manager in order to schedule meetings. The patient and the CM are also involved in the communication management. In particular, the CM communicates by phone or mobile with patients to remember them the therapy to be done, to check their clinical condition and to suggest any habits to prevent clinical issues. On the other hand patients can communicate to CM any difficulties in the course of treatment. In this way the CM puts in action his role of counsellor.

During the planned appointment, the CM provides treatments and operations related to the care path and he makes the necessary periodical follow up checking all the clinical parameters. In this process, the physician is involved in the continuous monitoring and in the progress check of patients collaborating with the CM. Then, because of its cyclic nature, the care management process can stop or continue depending on the results of the previous phase.

According to the Higo methodology we have analyzed the Key Performance Indicators of the care management process evaluated in the Leonardo project. The only available indicators were measured by Pfizer at the end of the project processing the data collected by InformaCare (Figure 3).

Figure 3. The patient related key performance indicators

Mapping these indicators on the HIGO Grid, we have noticed that they are regarding only to the patient point of view.

Thanks to the TO BE model described in the next paragraph we were be able to extend the set of the indicators necessary to a complete evaluation of the process performance.

4.3. Analysis of the Software Package for CMs

According to the proposed approach, in order to assess the results of the care management process in the Leonardo project, we have analyzed the software package used by the CMs to support their activities.

The package adopted in Leonardo Project was Infor- maCare. It is the most important industrial ICT solution to support the care management process[17], owned by Pfizer Health Solutions.

InformaCare is a software supporting integrated disease management and conceived in order to support CMs in the management of patients affected by chronic diseases. Integrated disease management involves a set of coordinated activities addressed to groups of people with pathological situations, where the engagement of patients in self assistance is fundamental.

InformaCare is a Web based application and contains functionalities to manage patient’s clinical data and documentation about symptoms in the electronic patient folder, to administer questionnaires to patients and to update and to print reports (clinical, ad hoc, ..).

It considers three different user profiles:

Care manager: it is accessible to the CMs who assist the Family Doctor in the coordination with the healthcare attendance;

Family Doctor: it is accessible to the doctor who is in charge of the patient and coordinates care managers activities;

System administrator: it is accessible to the user who carries out typical administration activities related to InformaCare system (es. account creation) but also to coordinate the activity of the CMs scattered in several medical studies (es. shipment of messages containing useful suggestions and indications, etc).

InformaCare has contributed to support an innovative organizational model in healthcare service, but some weakness points have to be removed in order to make the care management process more efficient and effective.

As described in the next section, the BPM model of the TO BE process will provide useful directions for the reengineering of Informacare in a novel platform more fitting to stakeholders.

4.4. To Be Model of the Care Management Process

After the modelling phase of the AS IS process, we have carried out targeted interviews and questionnaires to CMs. On the basis of the results of these questionnaires we have traced a new BPM model related to the TO BE process (Figure 4).

As we can see in the Figure 6, the main difference with the AS IS model, is the presence of more stakeholders (gray headers) in the process and the necessity for all to have a software support.

These elements have been particularly useful to identify a more complete set of KPIs associated to the care management process and to reengineer the InformaCare software. After the TO BE modelling of the care management process we have, in fact, mapped the InformaCare functionalities with the phases of the process according to a reverse engineering approach. This analysis has been lead through informal interviews to the CMs involved in the Leonardo Project, that have provided their feedbacks while they directly operated on the InformaCare software.

From the analysis of InformaCare functionalities according to the phases of the process, some missing and innovative opportunities appear according to a continuous improvement perspective.

First of all, it appears clearly visible the necessity to foresee in the software other users profiles in order to allow all process actors to use the proper functionalities.

Figure 4. BPMN-like representation of Care Management Process (TO BE)

In particular, in developing a new information system supporting the care management, it would be useful to introduce and specialize other user profiles: Physician (Family Doctor, Specialist Doctor), Patient, Relatives, Healthcare Manager.

For each of these profiles, the functionalities to be introduced are described in the following table.

These requirements have been shared, through ad hoc interviews, with samples of the identified stakeholders (relatives, healthcare manager, etc.) who accepted them and are offered for user tests of the next platform.

So, in other words, we can say that the proposed approach starting from the BP model of the process allowed to identify new requirements, which were not covered by InformaCare. The next cycle of the care management process, represented by the Galileo Project, will be supported by a novel open-source workflow platform to be customized for care management of chronic diseases which will be more fitting stakeholders.

Table 2. New user profiles and functionalities User profile Functionality Healthcare Manager Web access to an advanced reporting area in order to check the success of care process not only from a clinical point of view but also from a managerial perspective (ex. What if analysis in order to support planning and resources allocation for disease management). Doctor Web access to the system in order to record data related to chronic diseases (medical report, clinical data, etc.);Retrieval of data from legacy systems (existing electronic health record software). Relatives Web access to the system in order to visualize patient information and collaborate with CM to take care of their relative;Access to a Web 2.0 community area to support communications between patients relatives with similar disease and with CMs community. Patient Web access to the system in order to visualize his own clinical situation and to share calendar and activities with CM;Access to a Web 2.0 community area to support patient-to-patients or patients-to-CMs communications.

Table 3. The KPIs according to the stakeholders perspective Stakeholders Metrics Possible measures Healthcare Manager Patients identified and recruited for participation in the Care management program % eligible to participate;% of patients invited to participate;% of patients who have consented;% of patients who have declined. Costs of care for participating patients Overall disease-related costs;Disease-related; hospitalization costs. CM Productivity Caseload per care manager by severity;Contacts per patient;Duration of member contacts;Tasks completed on schedule. Doctor The proportion of participating patients who meet their clinical goals Blood pressure values;Cholesterol values;Body Mass Index. Relatives Satisfaction towards local health services Education materials;Program services;Program staff. Patient Satisfactionabout the CM program, program staff, and services. Access to care;Quality of care;Program staff;Program services;Patient education materials;Referrals to community services.

Moreover, the gathering of new requirements from the BPM model and in particular the identifying of new stakeholders in the care management process allowed to extend the KPIs set taking into account all the stakeholders point of view and not only the patient’s one, according to the HIGO methodology.

In particular, the KPIs that could be added to those identified by Pfizer for a systematic evaluation of the care management process performance in the next Galileo Project are reported in the following table.

5. Conclusions

The objective of the present paper has been to assess the use of the Enterprise modelling and in particular BPM to critically analyze the results of a first phase in a cyclic care management process in order to extract knowledge from the run of a previous project (AS IS) and to use this knowledge as input for the reengineering of the process (TO BE) and its adoption in a new care management project. Starting from the representation of the BPM model, it is very simple to define also the impact of process reengineering on the software support in terms of new requirements and functionalities to be provided and in terms of KPIs to be measured for the evaluation of the process performances.

Thanks to its expressive strength, such a systematic approach can be extended and generally used to facilitate process definition in healthcare and to assess the coherence between process and software support. Moreover it can be extended also to include the collaboration concept, according to the recent research trends in the field of BPM[18,19].

REFERENCES