CHAPTER 6

Health Operating Management Process Design

The fourth type of design, Level v, is for the processes that perform the day-to-day management of resources, including their scheduling. This corresponds to the last level of detail of the Hospital Architecture in Figure 2.7 and concerns the procedural detail of the realization of the activities for each of the subprocesses of processes, such as the ones presented in Figures 4.9 to 4.11 of the “Operating Room Capacity and Assignment” case, presented in Chapter 4 for subprocesses that allow demand prediction and capacity analysis. In all these cases the activities of the subprocesses deal with assignment and scheduling of resources, such as resources that are needed to provide a certain capacity.

In the case of hospitals, we start with a given configuration and capacity design, which was possibly determined in the previous design levels, and try to use the available resources in the best possible way to improve service (fairness) and efficiency. In public hospitals, there is usually excess demand, which means that patients have to wait long times before service. Hence, the value that can be generated for patients at this level of detail is to improve the service in terms of waiting time and providing the right service (fairness and quality). So this is an example of the projects that should be promoted by health central authorities for systematically improving hospitals that perform poorly, as proposed in the section “Innovation Resource Assignment in the Public Sector” of Chapter 4. It is also clear that the Business Pattern behind this type of design is BP6, “Optimum resource usage.”

The given resources to be managed are, typically, human–doctors, nurses, paramedics, and the like—and facilities and equipment, such as surgical operating rooms (ORs), beads, and attention boxes. Hence, detail processes that perform activities to do such managing are to be designed. Such detail must show the sequence of the activities involved, the logic of the flow, and the Analytics and computer applications supporting each activity. In advanced applications it is also feasible to introduce Analytics-based logic for determining medical actions. At this level, the modeling style changes to full formal Business Process Management Notation (BPMN) models, in order to make possible their simulation and eventually their execution with, for example, a Business Process Management System Suite (BPMS). Two cases are presented to illustrate how to make designs for improving service and optimizing the use of resources and, also, the possibilities of process execution. Other two cases that illustrate innovative logic for supporting medical decisions are summarized.

Operating Room Scheduling

As a first case of operation management we will consider ORs, which are one of the key resources in a hospital. For the process of managing OR the pattern given in Figure 2.11 is proposed; the process starts with “Demand Analysis” that, in this case, corresponds to prioritizing the patients’ waiting list in order to decide the order of surgery execution. Then, in “Operating Room Scheduling,” selected patients are sequenced on several OR, typically at least for a week ahead, making sure that, for a given patient, the right doctor and other resources are available at the chosen time in the room in which he is to be operated, and, at the same time, trying to make the best possible use of facilities. Finally, in “Surgery Resource Scheduling,” given an OR schedule, other resources, such as medical supplies, are determined in order to assure that they are available during the operation time.

Some details of the logic for prioritizing the patients’ waiting list are given, since this is the key variable that affects fairness, one of the objectives that are pursued. Currently, patients are, in general, attended according to the time they record in the waiting list and this is how such lists are generated. Obviously, this is very unfair since it does not consider the risk the patient has according to the pathology involved and other factors. Hence, a formal way for prioritizing patients is proposed, which is similar to the logic proposed in the case “Operating Room Capacity and Assignment” of Chapter 4. The priority is defined in terms of the characterization of each surgical specialty based on the maximum waiting times (MWTs) for surgery allowed for categories A, B, C, D, and E. These categories are defined in terms of the risk the patient faces if it is not operated: A is maximum risk and E is minimum risk. Certainly, the MWT allowed before surgery should be low for A and high for E. This time is determined based on medical factors by doctors and also depends on aggravating factors such as age and general health of a patient.

In what follows in this case, we assume that the outlined prioritizing logic has been implemented, which is the situation of the hospital where this case was developed. In fact, the team that designed the scheduling process was the one that first put into practice the prioritizing logic as we will present later.

More detail is given for the “Operating Rooms Scheduling” subprocess, which is a complex activity; it influences the number of patients operated, their waiting time, and performance of the whole hospital. Hence, there is the need to use good processes supported by powerful Analytics and appropriate computer system support.

Complexity of scheduling relates to the great variety of surgical interventions, the variability of operation time, patient priority, scarce available capacity, doctors’ schedule, and many other factors. What is needed is to design a process that reduces cost and manages capacity with efficient use of resources and provides fairness in the access and quality of service for patients, particularly, in opportunity of surgical procedures required. In this case the value is increased by giving timely attention to patients on the basis of medical criteria, resulting in the reduction of waiting time, especially for patients who are unable to wait.

A simplified version of the design of the OR scheduling process is shown in Figure 6.1, where a BPMN diagram is presented. Key ideas of the design are that the scheduling should be based on the current state of resources, priorities based on medical diagnosis and criteria calculated with current patient information, and an algorithm that meets all requirements for surgery and maximizes the number of relevant patients included. The System that manages data and performs the analytical support is explicitly shown in the diagram.

Next we describe the logic used by the key activity of this subprocess: “Calculate patients priority and schedule OR.” On the basis of medical criteria, patients’ priorities must be determined. This starts, in previous subprocesses, with a medical examination that determines how acute is the disease that originates the need for surgery, assigning the patient to a class among five alternatives, already described, that go from mild to very acute (A to C), and aggravating factors, such as age and other conditions that make the operation more urgent. Then, based on criteria extracted from medical knowledge and experience, an MWT for surgery is determined according to the classification and aggravating factors, which determines a dynamic priority by comparing the date in which the patient should be operated (date of diagnosis plus MWT) and current date. This is a formal logic that originates an algorithm that is run by the System. Then prioritized patients are scheduled, for a given week, taking into account the following factors:¹

Figure 6.1 “Operating Room Scheduling” design

1. A patient cannot be operated twice in a week.

2. Detailed schedules of personnel availability, in particular, doctors.

3. Load should be balanced among doctors within a week.

4. The programmed times of operation for each OR.

5. Special patients are considered; their condition determines a particular timing for surgery.

6. Priority can be violated because of patient limitations.

7. Two doctors should be assigned for each operation.

8. Specification of the operations a doctor can perform.

9. Patients can be prioritized for certain times within a day for reasons other than type of surgery.

10. OR operating working times can be violated within certain limits to increase utilization.

Two methods have been developed for scheduling. First alternative is an Integer Linear Programming (ILP) model that defines constraints for each of the conditions stated earlier and others for logical consistence, and sets an objective function that establishes the maximization of the number of patients operated and the satisfaction of the order defined by the priorities defined previously;² this model was implemented and results of its use are given in the following. Second possibility is a heuristic that first decides the day on which a patient is to be operated and then the sequence within the day.

The heuristic proposed for this problem consists of a backtracking algorithm for a week scheduling of patients selected from a large group of prioritized patients, which executes the following steps, presented in a simplified way:

1. Search for feasible solutions, within lists of all the available time modules (half days), during the week, in which a given surgical operation for a patient can be alternatively performed, taking into account its length, availability of a doctor who can perform the operation, and considering if the operation is “special” or ambulatory.

2. Create combinations of feasible solutions by patient aggregation, taking into account that such combinations do not occupy more time than the one available in each time module, feasibility of aggregation and that no more than two special patients are included in each day; several linked lists are generated with the combinations that contains the maximum numbers of different patients that can be operated, in the order of priority, using all the time modules defined for a week.

3. In general, patients are selected in the priority order, but when it is not feasible to add a given one to a combination, the next patient with highest priority is selected.

4. More than one feasible solution can be generated, due to the large number of patients from which to select, so an evaluation is made to select the best one using additional criteria not included previously, such that more urgent patients should be included at the beginning of the week and that certain patients should be operated earlier during the day.

5. The patients selected for a given day are then ordered setting first the ones that are “special” and then by age, according to criteria given by doctors.

The heuristic and the ILP were tested in two hospitals with the following results. The testing was done for realistic scenarios with real data defined in terms of number of patients, available OR shifts, and surgical intervention times. For each one of these scenarios, an evaluation of the quality of the schedule in terms of priority satisfaction and use of available OR time was made. For one particular representative scenario for 100 patients in a prioritized waiting list for the Urology specialty, the relative priority satisfaction for the heuristic (AB), and several variations of the ILP (MPE) are given in Figure 6.2.

Figure 6.2 Quality index of priority satisfaction for different scheduling methods

The quality index indicates that there is a high satisfaction of patients’priorities and the heuristic perform as well as the ILP alternative variations; this was confirmed with several other scenarios. Hence, the heuristic is a good tool for scheduling patients according to priorities. There is no possible comparison with current methods, as they do not use priorities.

Now the use of available capacity is analyzed. The use of an OR is measured as the percentage of time assigned for patients’ interventions with respect to the amount of minutes available. One of the objectives that motivate this work is to obtain an improvement in the use of the OR. For the evaluation of this objective, several representative scenarios were considered using the same parameters defined earlier. A large number of situations with variety of patients, duration of patients’ interventions and available shifts were evaluated. In summary, the result showed that for most of the normal cases the use of OR is close to 100 percent for the heuristic and the ILP. However, the more interesting comparison is the performance of these models as compared to that of the current scheduling. To evaluate this, schedules generated with the heuristic and ILP were compared with the schedules generated with the current procedure. One of the comparisons that were made corresponds to a given week where the schedule generated by a hospital for the Urology specialty is shown in Table 6.1, which details how the OR time is assigned to patients.

Next, the schedules generated with the heuristic and two of the ILPs, which produced the same results, are presented in Table 6.2. The table also lists the doctor who was assigned in the schedule. For the scheduling it was considered that the doctor who operated a patient in the current schedule (Table 6.1) was also assigned in the proposed schedule and that the patients who were first in its day in the current schedule were also assigned first in the proposed schedule. This is to make the comparison more realistic, since in this way feasibility of doctors’ assignment is assured and patients with special characteristics are scheduled first.

Table 6.3 presents the schedule for the same week, eliminating the constraints that the first doctor who was scheduled to operate the patient in Table 4.1 is assigned for this patient and that the first patient is maintained. As it should be, the elimination of constraints gives more flexibility for assignment and improves results, as it is clear in Table 6.4, where all the schedules are compared.

Table 6.4 shows that less restrictive rules positively impact the use of the OR and that using the methods proposed in this case can significantly increase the use of the surgical facilities.

Another test of the proposed methods reinforce the conclusions, since doing a similar experience in other hospital, scheduling OR during three weeks, results in Table 6.5 were obtained.

These results are very consistent with the one in Table 6.4, and confirm that there is every possibility of increasing OR utilization, considering that the current use for the specialty is taken into account, which is of the best managed hospital, is 82.6 percent.

In conclusion, use of optimization techniques, according to the results presented, can increase the number of operations significantly, without the need to increase the costs associated with the used resources. Since approximately 40 percent of the costs of the hospital are associated with surgical operations, improvements in OR use can significantly impact the economic results of the hospital (efficiency). Hence, from the patients’ point of view, increase in the number of interventions generates a reduction in the waiting times of all the patients in the waiting list (fairness). Besides, use of prioritization policies that consider the severity of the diagnosis and the delay time of the patient allows giving the right treatment at the right time (quality).

Table 6.1 OR scheduling with current method

Pabellon 3
Lunes		Martes		Miércoles		Jueves		Viemes
Paciente 1	305	Paciente 7	270	Paciente 15	270	Paciente 18	230
Paciente 2				Paciente 16		Paciente 19
				Paciente 17		Paciente 20
Tarde		Tarde		Tarde		Tarde		Tarde
		Paciente 8	165
		Paciente 9
		Paciente 10
Pabellon 4
Lunes		Martes		Miércoles		Jueves		V iemes
Paciente 3	275	Paciente 11	185			Paciente 21	330
Paciente 4		Paciente 12				Paciente 22
Paciente 5		Paciente 13
		Paciente 14
Tarde		Tarde		Tarde		Tarde		Tarde
Paciente 6	95					Paciente 23	60

Table 6.2 Schedule generated by heuristic and ILP models

Pabellon 3
Lunes		Martes		Miércoles		Jueves		Viemes
Paciente: 1; Doctor1: 1, Doctor2: 4, Paciente: 2; Doctor1: 1, Doctor2: 14	305	Paciente: 7; Doctor1: 3, Doctor2:10, Paciente: 4; Doctor1: 3, Doctor2:10	285	Paciente: 15; Doctor1: 7, Doctor2: 8, Paciente: 16; Doctor1: 7, Doctor2: 8, Paciente: 17; Doctor1: 8, Doctor2:4	270	Paciente: 18; Doctor1: 2, Doctor2: 4, Paciente: 8; Doctor1: 5, Doctor2: 2, Paciente: 53; Doctor1: 5, Doctor2: 2, Paciente: 20; Doctor1: 2, Doctor2:4	280
Tarde		Tarde		Tarde		Tarde		Tarde
		Paciente: 31; Doctor1: 10, Doctor2: 13, Paciente: 30; Doctor1: 10, Doctor2: 13	115
Pabellon 4
Lunes		Martes		Miércoles		Jueves		Viemes
Paciente: 3; Doctor1: 3, Doctor2: 5, Paciente: 9; Doctor1: 5, Doctor2: 3, Paciente: 10; Doctor1: 5, Doctor2:3	320	Paciente: 11; Doctor1: 6, Doctor2: 13, Paciente: 19; Doctor1: 6, Doctor2:13, Paciente: 13; Doctor1: 6, Doctor2:13, Paciente: 12; Doctor1: 6, Doctor2:13, Paciente: 14; Doctor1: 6, Doctor2:13	265			Paciente: 21; Doctor1: 9, Doctor2:10, Paciente: 23; Doctor1: 9, Doctor2:10, Paciente: 34; Doctor1: 10, Doctor2: 9	250
Tarde		Tarde		Tarde		Tarde		Tarde
Paciente: 6; Doctor1: 3, Doctor2: 5, Paciente: 28; Doctor1: 3, Doctor2: 5, Paciente: 5; Doctor1: 3, Doctor2: 5	195					Paciente: 22; Doctor1: 9, Doctor2:10	170

Table 6.3 Alternative schedule generated by heuristic and models

Pabellon 3
Lunes		Martes		Miércoles		Jueves		Viemes
Paciente: 2; Doctor1: 1, Doctor2:14, Paciente: 8; Doctor1: 1, Doctor2:14, Paciente: 71; Doctor1: 7, Doctor2:1, Paciente: 24; Doctor1: 1, Doctor2:14, Paciente: 14; Doctor1: 1, Doctor2:14	270	Paciente: 3; Doctor1: 3, Doctor2:10, Paciente: 9; Doctor1: 10, Doctor2:3, Paciente: 10; Doctor1: 10, Doctor2:3	320	Paciente: 1; Doctor1: 4, Doctor2: 8, Paciente: 20; Doctor1: 8, Doctor2:4	310	Paciente: 15; Doctor1: 7, Doctor2: 2, Paciente: 18; Doctor1: 2, Doctor2:4	285
Tarde		Tarde		Tarde		Tarde		Tarde
		Paciente: 19; Doctor1: 13, Doctor2:10, Paciente: 30; Doctor1: 10, Doctor2:13	205
Pabellon 4
Lunes		Martes		Miércoles		Jueves		Viemes
Paciente:4; Doctor1: 3, Doctor2: 5, Paciente: 7; Doctor1: 3, Doctor2: 5	285	Paciente: 62; Doctor1: 6, Doctor2:13, Paciente: 26; Doctor1: 6, Doctor2:13, Paciente: 11; Doctor1: 6, Doctor2:13, Paciente: 13; Doctor1: 6, Doctor2:13, Paciente: 12; Doctor1: 6, Doctor2:13, Paciente: 16; Doctor1: 6, Doctor2:13	295			Paciente: 21; Doctor1: 9, Doctor2:10, Paciente: 23; Doctor1: 9, Doctor2:10, Paciente: 17; Doctor1: 10, Doctor2: 9	280
Tarde		Tarde		Tarde		Tarde		Tarde
Paciente: 6; Doctor1: 3, Doctor2: 5, Paciente: 28; Doctor1: 3, Doctor2:5, Paciente: 5; Doctor1: 3, Doctor2: 5	195					Paciente: 22; Doctor1: 9, Doctor2:10	179

Table 6.4 Results and comparison for different schedules

	Used minutes	Available minutes	Use percentage	Improvement
Current schedule	2185	2820	77.5%	-
First schedule	2455	2820	87.1%	9.6%
Second schedule	2624	2820	93.0%	15.6%

Table 6.5 Results for three weeks OR scheduling

	Total time available (min)	Scheduled time [min]	Use percentage
Week 1	1120	1010	90.2%
Week 2	1120	1045	93.3%
Week 3	810	770	95.1%
Average			92.8%

Both methods explained earlier generate better schedules than today’s practices, since they are: (a) feasible, by doctor’s evaluation, (b) of better quality in terms of satisfying all the constraints, which are difficult to assure by nonformal methods, and (c) better in terms of capacity use, increasing occupation by at least 15 percent and up to 20 percent in certain cases.

The method implemented in the System lane activity “Calculate patient priority and schedule OR” of the process in Figure 6.1 is the heuristic, because it furnishes results close to the optimization model and is more stable in terms of always giving results. This is not true for the ILP that sometimes runs long times without getting a solution, due to the particular form of the objective function that includes weights to favor schedules that process priority patients. Then the heuristic is embedded within the System support of the process.

Waiting List Management for Ambulatory Patients

Here we present another case of resource scheduling in hospitals, which has the innovative characteristic that a formal process model is designed that allows its execution with software of the BPMS (Business Process Management Suite) type. Such execution avoids writing most of the code needed for process support. We select “Ambulatory Elective Care Service” of Figure 2.8, and concentrate on managing the incoming patients to such services, with an emphasis on waiting list prioritization to increase fairness and efficiency due to better use of resources. Incoming patients to hospital outpatient service can occur from two sources: referrals of patients from primary care to the hospital, commonly known as interconsultations, or from medical check-ups for patients who have already been previously attended because of certain symptoms.

The case will focus on improving the problem of waiting lists for interconsultations.³ As shown in Figure 6.3, the number of patients who remained in waiting lists for interconsultations during 2011 fluctuated between 1,000 and 2,500 patients, while in the first half of 2012 registered an increase to 3,500 patients.

Figure 6.3 reveals interesting information. First, it provides evidence of the number of patients who remain without service, which is not less than 1,000 patients and that tends to remain around 2,500. Second, certain behaviors of the hospital, which are highlighted in the preceding graph, are clear. As it can be seen, the hospital attends to a larger number of patients on certain days, with the purpose of meeting the goal of importantly reducing the number of patients in the waiting list, but it is a reactive action, possibly motivated by authorities’ pressure, and with no apparent periodicity. Furthermore, the behavior of the waiting lists for the different specialties is not encouraging. Indeed, the indicator number of incoming over outcoming patients shows that they cannot eliminate their waiting lists; on the contrary, they will remain constant or growing. By way of example, for every 3.4 patients that joined the Neurology waiting list during the first half of 2011, only 1 patient was attended. This concludes that there are medical specialties that keep a constant number of patients on the waiting list, others that grow moderately, and, finally, some medical specialties that have serious capacity problems, as is in the case of Neurology and Dermatology. Thus, all this indicates the need of a formal process for the management of waiting lists.

Figure 6.3 Number of patients waiting for interconsultations

The problem of waiting lists can be handled by three different strategies:

1. Increase capacity adds to the medical resources in terms of hiring more staff, and possible increases in enabling infrastructure.

2. Improve productivity serves a larger number of patients subject to current capacity constraints (efficiency) in terms of the objectives established in Chapter 2.

3. Opportunity of attention: Use available medical resources for meeting the opportunity care criteria related to each patient’s illness (fairness).

Considering these facts, the question is how to address the problem of outpatient waiting lists. In this regard, the international experience shows that increasing capacity is not an effective strategy; in effect, countries such as Canada and Denmark have concluded that the resolution of the waiting lists crisis in health through increased resources has not proven to be an effective strategy. Likewise, countries such as Australia, United States, and the United Kingdom provide more international experience on the initiatives of increasing resources, which have failed to reduce the number of patients on waiting lists.⁴

Canada is one of the countries with greater advances in waiting lists in the health system. Canadian experts have concluded that one of the central aspects in this quest to better manage them and assure patients timely access is to focus on optimizing installed capacity, by improving the quality of the management of the available resources. Enhanced coordination and teamwork inside the organization of health care providers, assisted by improvements in information technologies, makes possible avoiding unnecessary delays between the different stages of treatment of patients.

Western Canada Waiting List Project is one of the best examples of multidimensional approach to improve the management of timeouts in Canada. This project that began in 1998, with the agreement of several regions as well as medical associations and health authorities, seeks to improve justice and fairness in the delivery of medical services, prioritizing treatments, including concepts of emergency care, and improving the management of waiting lists.

On the basis of the international experience reported, the approach used in this case is to manage the opportunity of attention. This means securing an MWT to attend a patient, subject to its medical complexity. In this sense, patient’s attention is opportune when MWT is not exceeded. This is similar to what it was proposed in the previous case of priority determination for OR scheduling and also in OR capacity assignment.

The current situation is that, for example, in the Neurology specialty, the one with more unsatisfied demand, patients with reduced complexity tend to be served first than others with more priority. This situation is the product of the first-in first-out (FIFO) approach that underlies the medical hours booking process, which originates disparity in waiting time between patients and that evidently does not consider the opportunity for care. This is not the only specialty with problems, since Traumatology has also similar behavior.

Given the aforementioned findings, it is concluded that the care of patients waiting for interconsultation is not governed by an approach based on opportunity, but rather on access. The enforcement of health indicators is privileged, such as the number of patients waiting, instead of ensuring the fulfillment of individualized MWT for each patient. In this sense, the motivation of this work is to develop criteria to categorize and prioritize patients in outpatient waiting list to deliver a timely health care according to the current hospital capacity restrictions. In designing a service process to accomplish this, first “Ambulatory Elective Care Services” of Figure 2.8 is decomposed in Figure 6.4, following the same pattern as in Figure 2.11, but specialized to ambulatory services.

The “Demand Analysis” process studies the behavior of ambulatory patients. One variable that can be analyzed is absenteeism of the patients, which currently varies between 20 and 30 percent of the medical hours reserved, situation that has a negative impact on the capacity of public hospitals. The idea behind a behavior analysis of absenteeism is to detect patients who are usually absent from their medical hours, with well-differentiated characteristics. With this information, categories (clusters) of patients could be defined and differentiated by absenteeism rate, which could feed a process to control such patients and possibly define an over-citation rate to use the capacity that such absent patients would not use, which obviously generates a better use of resources. We did not include this option in our design because of lack of information, but it could be easily added to the process to be detailed later.

Figure 6.4 “Ambulatory Elective Care Service” decomposition

Next “Ambulatory Service Scheduling” of Figure 6.4 is decomposed in Figure 6.5, which relates to waiting patients. There are two types of patients admitted to the hospital: new and current patients. Patients are considered new when they request a medical evaluation for a particular medical condition, where the diagnosis of the patient is determined. On the other hand they are considered “in course” when it is required that the patient comes again to the hospital for a second time or more occasions to controls in order to observe the evolution of his or her disease. Note that a new patient may change to “in course,” and when in this condition he or she may have several interactions with the hospital until the patient is discharged.

New patients are admitted to the hospital through consultations from primary care (interconsultations). The hospital is currently facing a high demand for interconsultations, which generates waiting lists for new patients. This situation is the main problem to be solved by the service process design we have developed. In terms of current patients, the hospital also manages waiting lists; however, they are much smaller than those of new patients. Indeed, reservations of medical controls have an inherent waiting time, determined by the attending physician. Such time is needed to let the health condition of the patient evolve, to be subsequently evaluated in a medical control. As a consequence, the controls’ waiting lists are relatively low and do not pose a problem for the hospital. Given the types of patients, new and controls, the planning of services for waiting patients should be treated differently, as shown in Figure 6.6.

The aim of the “New patient scheduling” process in Figure 6.6 is to generate a single prioritized hospital waiting list, which will serve to make reservations of medical hours for patients.

As shown in Figure 6.6, the first subprocess generates a waiting list with interconsultations and applies a logic, that will be presented later, to categorize and prioritize new patients, whose product is a waiting list of patients sorted in descending order according to severity and priority. In the second subprocess, medical hours are programmed, according to priorities determined in the first subprocess, for patients awaiting reserves; for this the design specifies that hospital administrative personnel routinely contact the waiting patients to notify the medical time assigned to them.

Figure 6.5 “Ambulatory Service Scheduling” decomposition

Figure 6.6 “New patient scheduling” decomposition

Information of patients on waiting lists is provided to hospitals by a centralized information system of the health care network. Each primary attention unit directs their patients to the hospitals in the public sector; while doing this it registers the interconsultation in the system. The total number of interconsultations make up the waiting list for new patients. While the system provides a platform for the entry of the interconsultations, they are usually not well recorded, that is, they do not follow the technical standard of registration of waiting lists, using, for example, medical specialties that are not declared in the technical standard. It is therefore required to debug the waiting lists so that the information is adequate for prioritization.

Figure 6.7 shows the process to determine new patients’ waiting lists. This activity is performed by the “Head Patient Management,” for which he has access to the waiting list that is exported from the previously described system. The waiting list must be loaded to the “System” developed for this case, which is responsible for performing the debugging explained earlier. In some cases, manual cleaning is made by the “Head Patient Management,” since the “System” does not recognize some fields. When performing a manual cleaning of the waiting list, the “System” saves the criteria that were used, with the purpose to include them in the automatic debugging later. Prolonged use of the process should eventually eliminate the manual debugging. Once the waiting list is corrected, it is saved in the database of the “System,” which records the interconsultations that are not already registered in the database. This process that replaces the existing one, mostly done manually, will reduce updating of waiting lists from at least two weeks to daily.

Now the logic used to categorize and prioritize interconsultation patients in the design in Figure 6.7 is detailed. First, some ideas proposed in the literature are reviewed.

The linear formulation of Edwards⁵ is one of the well-known and currently used methods for prioritization. It proposes a score for the patient given by

Figure 6.7 “Build categorized and prioritized waiting lists for new patients” design

where P is the priority score and S_i is the score for factor i, and

i = 1 rate of progression of the disease, valued 1–4,

i = 2 pain (1–4),

i = 3 disability or dependency (1–4),

i = 4 occupation lost (1–4),

i = 5 parameterized waiting time (0–4),

w_i is the relative weight of the S_i factor.

The age-old formulation of Edwards is still used widely today. It is the case of the prioritization of patients system on waiting list for cataract surgery and hip replacement used in Spain since 2004.⁶

Other weighted scoring methods correspond to those presented by Lack,⁷ which is a variation of the one by Edwards and Dennett,⁸ whose formulations are the following:

Where t is the patient’s waiting time and m is the largest waiting time a patient has; A_i and B_j are clinical and social attributes, respectively.

In this case, a method that categorizes patients according to the diagnosed sickness gravity is proposed, which results in a category and an MWT, as it was presented in a case in the section “Operating Room Capacity Assignment” in this chapter. Once all patients are categorized, they are sorted according to priority in the waiting list. This is done by a simple rule that considers the waiting time the patient has suffered with respect to his maximum allotted time. From this, two scenarios are possible: that the patient stays in normal wait, because he has not attained the MWT, or that the patient is overdue, given that he has exceeded the MWT. Then the proposed ordering is based on the calculation of the number of days remaining to reach MWT for patients not yet overdue. For patients that are overdue, the days since the expiration of the MWT is the relevant figure and the larger it is for a patient, he should go higher on the waiting list; and, of course, before people who are not overdue. Furthermore, it is proposed that a patient with expired MWT should leverage (multiply by a factor) his waiting time, in order to reflect that the waiting days after maximum allotted time have greater impact on the perception of the patient. Indeed, if the hospital failed to deliver the service at the agreed time, it is considered that the patient’s health will be significantly worse for each additional day of waiting post expiration.

Then the situation of patients waiting is described by means of the function E(t), where t is defined as the chronological days of waiting since attention was requested for him by means of interconsultation. Then the days of waiting leveraged is defined as:

where T_max corresponds to the MWT associated with the medical diagnosis, and α is a leverage factor.

Another way to describe the waiting function is through the attribute “waiting days remaining to Tmax,” E(d_r):

It remains to specify the calculation of the leverage factors. Notice that there is a direct relationship between the days of waiting for each category; for example, if the highest category has an MWT of 5 days, and the lower-priority 90 days, then a waiting day for patients of high category is equivalent to 18 days of waiting for low category patients (90/5 = 18 days). Similarly, another category can have a maximum time of waiting for 60 days, so every waiting day equals 1.5 days of the low category (90/60 = 1.5 days). These examples suggest a way to calculate the leverage factors, which consists of measuring how much each waiting day for a category weights in relation to the lowest category. Thus, it is concluded that the leverage of the category of priority factor p is obtained as:

where Tmax,i is the MWT of the category i. With this, the category p waiting function E(d_r , p) is summarized as:

The priority rule proposed is that patients are placed in the ascending order of E(d_r , p). Thus, Figure 6.8 shows the waiting function for each category; where it is clear that the higher categories increase their priority faster than lower ones.

Now a particular feature of this case is presented, which is the implementation approach of the proposed design, including the development of the “System” support specified in Figure 6.7. For this, a process execution approach is used, which will be illustrated with the model in such figure. In doing this, a tool of the BPMS type is needed, which in this case was integrated with several open components. This was done to minimize cost, since public hospitals in Chile cannot pay the cost of commercial high-end technology of this type. So the idea was to show that the advantages of process execution—fast development, minimum code, flexibility for changes in the process, and the code and reuse of services—can be obtained at a reasonable cost.

In particular, after testing several low-cost alternatives, Activiti was chosen as the core of the execution. Activiti is an open framework for the implementation of a business process modeled in BPMN 2.0, developed in Java, and owned by the company Alfresco.⁹

Activiti is not really a BPMS, because there are some missing components in the framework to be considered as such. The main component of the Activiti framework is a Process Engine, which has the necessary features to execute business process designed with BPMN 2.0, standard that it fully incorporated. This obviously favors portability of the designs to other eventual alternatives.

Figure 6.8 Waiting function

Activiti has a number of components that allow managing business processes, which are classified in Design Tools, Process Engine, and Support Tools. Unlike the Process Engine, the rest of the components of activities are considered Add-ons (accessory) to the framework. Some of the components are:

1. Activiti Engine: Main component of the framework, which provides all the functionality of execution to the Process Engine.

2. Activiti Modeler: Web application that allows business-oriented BPMN 2.0 process modeling.

3. Activiti Designer: Corresponds to a plugin for the Eclipse development environment. Activities Designer is currently the only functional process modeler of the framework and is purely focused on process execution.

4. Activiti Explorer: Web application that allows running and visualizing the graphical user interfaces involved in business processes. Activities Explorer is a solution for the design of simple displays and does not support dynamic web interfaces. So, in order to build system support for complex activities, an interface designer component is needed.

5. Activiti REST: Web application that allows to remotely executing business processes through web services (alternative of the well-known SOA protocol).

This set of components enables to build a BPMS solution, with the Activiti Engine being the most robust solution of the framework. The rest still lacks sufficient maturity to adopt them as a final solution. Given this, only the Activiti Engine was used in this case and for other requirements, available open tools were integrated with the engine.

One of the basic features a BPMS must have is the ability to run processes, which in terms of design corresponds to link the graphical display environment with the process engine. That is, from an action in the graphic environment, the execution of an activity of the process should be triggered. Activiti process engine has an API of seven interfaces developed to control it from an external application. In particular, there is the Run time Service interface that allows initiating processes. This interface can be used from a controller class, which receives instructions to run specific processes. For the purposes of design, such controller class will be called Instance Service, since its work is to instantiate processes. The Instance Service class should be invoked from the graphical display environment. When a user interacts with a graphical interface, he specifies a requirement for process execution. The graphical interface captures the process identifier, invokes the class Instance Service and this initiates the process through the Run time Service interface. This simple dynamics is nothing more than a specification of the model view. For simplicity, the graphical display is described as a generic package of classes, since each developer could design a GUI according to his preferences.

We examine now how the facilities provided by Activiti just described relate to BPMN.

BPMN 2.0 UserTask activities, by the standard definition, do not support any programming code. The only activities in BPMN 2.0 that support code are ScriptTask and ServiceTask explained in Table 6.6. In connection to our BPMN design models, as in Figure 6.7, the first activity of such a table is in a user lane, as the “Head Patient Management” in such a figure, and the last two in a “System” Lane.

A very important aspect of the Activiti Engine is that ServiceTask activities execution can be delegated to classes outside Java classes, in order to process complex logic.

So, in summary, we have the Activiti Engine that has interfaces for integrating with tools that allow building complex graphical user interfaces, as the ones needed by the “UserTask” of Table 6.6, and with tools to program complex logic as the ones that may be required by “ServiceTask” of the same table. So, open tools do these jobs and integration with Activiti is required, as described later.

For the development of the graphical interfaces, Google Web Tool-kit (GWT) was selected. Google has defined a mechanism for using object-oriented applications for graphic interfaces in web applications. They released an open framework called the GWT in 2006, allowing to design object-oriented web Java interfaces, which the web browser interprets as traditional web interfaces, that is, as programmed in HTML, CSS, JavaScript, AJAX, among other techniques. GWT is a tool that has been widely adopted and most of the applications developed by Google are programmed in GWT.

Table 6.6 Elements of BPMN 2.0 Activiti

Activity BPMN 2.0	Technical characteristics
	UserTask: It does not support programming code; therefore, forms or views assigned to this activity must be provided by the environment BPMS as one particular solution of each one. UserTask activity is technically only a pause in the process assigned to a specified user, which must be terminated when the activity is completed.
	ScriptTask: System activity that allows validating data or performing low complexity arithmetic. It supports programming in Groovy and JavaScript code, both adopted by the object Management group (OMG) as languages for BPMN 2.0 standard.
	ServiceTask: System activity that supports complex programming logic. Used to consume web services or execute code in groovy or JavaScript language.

Although the graphical interfaces of the BPMS system developed in this work were programmed in GWT, we used a particular framework called Vaadin. Examples of interfaces follow:

1. Interface to determine new patient waiting list: Figure 6.9 shows how the interface supports the activities that are performed in this process to determine the new patient waiting list, such as files validation, automatic debugging of waiting list, manual debugging of lists and consolidation, and updating of database. It also shows the status of the activity and also the elapsed time. This interface is the one used by the first activity of “Head Patient Management” in Figure 6.7.

2. Interface to see the new patient prioritized waiting list: Figure 6.10 shows the result of cleaning and prioritization of patients, which is evaluated by the “Head Patient Management.”

Figure 6.9 Interface to determine new patient waiting list

Figure 6.10 Interface to see prioritized waiting list

Then, as explained earlier, there is the need to program and insert in the execution of the process the logic for waiting list prioritization. For this task another tool was used, which is the Spring framework. Spring is an open-source framework for developing web applications in Java. The advantages of using the Spring framework are that it proposes the concept of container objects (factory objects). This means that there is a repository that instances and keeps the objects used in an application. The developer must set the object container in a single file, which specifies classes (objects) and their relationships. The advantage of having an object’s container is that future changes to the software are only made in one file, without compromising excessive code. Then all the logic imbedded in the activities in the “System” of Figure 6.6 was coded using Spring.

The physical layer of the “System” corresponds to the communication with databases and, in particular, with the Activiti database and the database that store hospital’s information. Typically, under an object-oriented programming approach, communication with databases is performed by means of class entities, which have SQL queries inside to be processed in the databases. Such an approach has been widely questioned by developers; in fact, class entities have inside SQL code and Java code (or another programming language). This duplicity of languages generates problems of system’s maintenance; hence, SQL code should be separated of the Java code, in such a way that entities classes only maintain the information and do not process SQL queries.

Then, operations carried out by the entity classes, such as setting or capturing information (methods, Setters, and Getters) materialize directly on the databases, without programming SQL code inside such classes. This is called the “Principle of Data Persistence.”

There are multiple frameworks that implement data persistence in Java. One of them is Java Persistence API (JPA), as also Hibernate¹⁰ and Ibatis.¹¹ For the purposes of the BPMS of this work, Hibernate and Ibatis were used as follows.

Ibatis is an open source framework developed by the Apache Foundation, the same organization that developed the well-known Apache Tomcat application server. Ibatis uses an XML file in which SQL queries should be programmed; each inquiry must be registered with a logical name. As a result, Ibatis delivers a repository of SQL queries that are used by entities classes when necessary. Then, Ibatis allows separating programming in Java code of programming in SQL code, so cleaner and more maintainable applications are obtained.

Moreover, the Hibernate framework was also used to manage databases. This is owned by the JBoss organization that is also known for its application server that receives the same name (JBoss Application Server). The communication that Hibernate establishes with databases is more direct that the one made by the Ibatis Framework. Hibernate is a pure data persistence framework, that is, entities classes are directly related to the database tables, so the operations that are performed with the entity classes automatically materialize on the databases. Unlike Ibatis, Hibernate does not use intermediate files and also does not require that the SQL queries are scheduled. Indeed, Hibernate performs the operations carried out in entity classes as SQL queries later reflected on transactional operations on databases. Using Ibatis Framework in the BPMS environment is because the database management of Activiti’s processes is originally made with this framework. As the project added more functionality to the process engine, which are reflected in operations on the Activiti database, Ibatis Framework was needed. On the other hand, Hibernate was used to operate on the database of the hospital, which keeps information required by the processes that are performed in the BPMS environment.

The prototype was developed in a few weeks with the tools just described and implements the process “Build categorized waiting lists for new patients” specified in Figure 6.6. We show some results for this application next.

The prototype enables the “Manager Patient Service” to determine a single, consolidated, and refined waiting list, incurring a computing time of one to two minutes. Today, the same process in its manual version, performed by a clerk, takes between one and three days. The process current version is performed every two weeks, so patients have a further two-weeks’ wait only by administrative considerations. In this line, the prototype allows to determine the waiting list every day and, in consequence, eliminate unnecessary waiting time. Finally, the process is supported by a database, which stores information refined and structured according to a formal data model. Thus, the prototype leaves the hospital a source of useful information for upcoming projects, which is a plus, given that the majority of technological projects requires a structured data layer, and that was nonexistent for this project.

The prototype uses a well-defined and medically supported logic to categorize and prioritize patients. Such logic requires that the prototype has the equivalences between the diagnostics used by the primary attention units and the ones used for the hospital, work that was done for the specialties of Nutrition and Neurology to test the results.

The process and system developed can be easily adapted to other hospitals. In particular, the integration of primary attention and hospitals in a given zone can be done by means of the approach to waiting-list integration and prioritization proposed and tested in this work, since today the implicit rule for attending patients is FIFO, which is absolutely in contradiction with the fairness objective proposed at the beginning of this chapter.

Other Cases

We summarize other cases emphasizing novel features of health service design.

Diabetes Management in a Private Hospital

We present a real case of this type developed in a large private hospital,¹² which centers on preventive health services for diabetes patients.

The Strategy that motivates this case is integral services to users, changing from a reactive approach, where a patient has to request a health service, to one where the hospital continuously monitors patient’s data to discover possible health problems and discover crisis before they occur, advising the patient on preventive treatments. So the Business Model is to provide value to the patient by avoiding the consequences of such crisis, which in diabetes’ patients can go from member amputation to death. Also value is provided to society by increasing useful life for patients.

Then Capabilities needed are to have useful medical historical data to be able to develop diabetes predictive models; to have practices that allow for continuous patient health monitoring; and a good process to proactively act on patient to prevent crisis. So an Intelligent Structure II is needed for model development and action taking and as a consequence a Business Pattern 1, “Client’s Knowledge-Based Selling,” is needed. Selling can be a little offensive in health services, so one may use “Offering” instead.

In this case we are in “Ambulatory Elective Care Service” of the architecture in Figure 2.8, from which a decomposition, similar to the one in Figure 6.4, tells us the subprocceses to be designed. We concentrate on “Ambulatory Services Scheduling” but do not give detail by decomposing it. Instead we emphasize the logic that it executes based on a predictive model that is detailed in the following.

The predictive model is based on Data Mining, by analyzing historical data for chronic diabetes patients; first, variables that are statistically correlated to risk for diabetes patients were determined based on such data. The ones that are relevant, with data from 1,487 cases, are the ones in Table 6.7. With selected variables a Classification, as explained in section “Analytics” of Chapter 2, is done, from which the binary tree in Figure 6.11 is generated.

Table 6.7 Selected variables for Classification

Figure 6.11 Decision tree for diabetes data

The tree clearly shows which combinations of variables with what values define cases with medium (medio) and high (alto) risk. Then patients which fit the values that define a case can be classified in a risk level and action defined for them accordingly. So, for example, patients which values that mean high risk can be subjected to preventive treatments.

Operation of Services for Patients at Home

The Strategy analysis and Business Model for this case was presented in Chapter 3; also Intelligent Structure IV and Business Pattern 2, “Creation of New Streams of Service,” were determined as the proper ones; the main idea being to proactively provide customized services for patients at home using large amounts of data about medical variables monitored online. It was concluded that this solution needs a new Value Stream. Then what is done here is to provide a design for the operation of such stream. We start by locating the new stream as contained in the process “Hospitalization Service” in the architecture of Figure 2.8. Then the pattern that defines this stream is based on Macro1’s processes for service management and execution, which is presented in Barros;¹³ it is the same used to model “Ambulatory Elective Care Service” in Figure 6.4 and the specialization for this case is in Figure 6.12. The mapping of the Business Design in Figure 3.5 to this process design is as follows:

1. Besides the Macro1 structure emphasized in Figure 6.12, there is the need of a Macro2 that takes care of the continuous development of “Design criteria for at home services” and “Design of improved or new Value Stream “of Figure 3.5, since the dynamics of the situation, in particular new historical data, requires the revision of the models and related criteria and, also, of the Value Stream for its adaptation to such revision. Macro2 is present providing inputs to the structure in Figure 6.12 and requires other processes that are not given here.

2. “Predictive model processing and crisis detection” relates to “Definition of patients with access to service” and the model application part of “Service operation management” of Figure 3.5.

3. The other subprocesses in Figure 6.12 are part of the Value Stream that operates the service.

Figure 6.12 Service for patients at home

In what follows we concentrate on the logic that is executed in “Predictive model processing and crisis detection.” Such logic is based on predictive models that permit criteria generation for crisis detection, which we now explain.¹⁴

Logic stars with patients clustering that, due to lack of historical information previous to this project, is made using age groups based on medical expert opinion: 0 to 1 month; 1 to 6 months; 6 to 24 months; and more than 24 months. Then the possibility that key variables that define the situation of a patient, such as oxygen saturation, temperature, cardiac frequency, and respiratory frequency, may have a distinct behavior for different pathologies in each group is considered, in order to refine segmentation.

For the predictive model for each preceding segment, the possible variables to be considered are evaluated by means of correlation; variables are the ones already considered in the segmentation plus the period of a day-day or night-in which they are taken. The conclusion of the correlation analysis is that cardiac frequency appears to be the best predictor, besides oxygen saturation and time of the day. For such variables, fuzzy membership functions are applied; for example, oxygen saturation was modeled with a Gaussian function in diffuse intervals for low saturation and normal saturation.

The static risk in the model is determined using the following groups of input variables:

• Group A: Vital signs

  • Temperature

  • Cardiac frequency

  • Respiratory frequency

  • Arterial pressure

• Group B: Oxygenation

  • FIO2

  • Oxygen saturation

• Group C: Visual

  • Secretions color

  • Secretions quality

  • State of awareness

Last group of variables are categorical and informed by patients’ relatives; rules for the normality of such variables are given by doctors.

Then the rules to determine static risk, from Level 1 (stable) to Level 4 (abnormal), take, topically, the following form:

1. Assign Level 1 if any of the following conditions apply:

   1. All indicators are in normal ranges.

   2. Only one indicator, different from the ones in Group B, present a moderate deviation from normal.

2. Assign Level 2 if any of the following conditions apply:

   1. Temperature and cardiac or respiratory frequency are in abnormal levels.

   2. If visual variables are not at normal level.

3. Assign Level 3 if any of the following conditions apply:

   1. Visual variables present a clear deviation from normality.

   2. Vital sign are as a whole far from normal.

4. Assign Level 4 if any of the following conditions apply:

   1. Oxygenation presents alteration.

   2. Vital signs and visual signs are clearly abnormal.

There is also a dynamic risk that is determined by the temporal behavior of the previous variables.

These rules are preliminary and should be refined, using the Macro2 in Figure 6.12, by their experimental application that permits validation. The ongoing pilot implementation of the hardware and software that allows monitoring will generate the data to do this.¹⁵