See how a major hospital group reads in patient records to model overall patient flow. A template supplied by ProcessModel allows Patient record information to be converted into a simulation model. A model of the overall patient flow allows vision of when department will be overcrowded and by how much. With the problems identified, new strategies and tactics can be tested to eliminate problems before they actually happen.
Why Model Overall Patient Flow
Changes to our complex hospital system are easy to conceive but difficult to implement. There are so many dependencies that the only way we have been able to make changes, in the past, is by trial and error. The problem is our trial and error has been mostly wrong, causing patient delays, overcrowding and frustration for patients and staff. We wanted a better way to predict the outcome of changes without creating massive delays and frustration. One of our goals was to increase of the number of surgeries performed. But it was difficult to understand what types of surgeries we could increase consistently, and on which days, using our current analysis methods.
Having the goal to increase the number of surgeries by using a simulated model of the real system, to try changes in the computer before implementation, was our solution. We found that we could take actual patient data (department, length of stay and flow) and use that to create an accurate representation of what actually happened. If we had a representation of what happened, then we could try different ideas and show the potential result of what would have happened if we had implemented the change. We weren’t relying on predictive distributions to create the model but rather actual patient data. Using actual patient data has three major advantages:
- It is easy to understand — we know what actually happened, allowing easy verification of the model.
- The model is simple and quick to design — a ProcessModel template provides the structure and main components.
- The data can be gleaned and formatted quickly from the existing database.
We stripped the patient database to find all the points of entry by date and time. The three main entry points were ED, surgery and direct admit. For each of these entries points we captured all the departments visited with the associated start and end times. We were only interested the departments used as boarding areas. A patient may visit many departments during their stay, but main limitation is the capacity of the boarding areas. For example, a patient may be taken from the ED to radiology but the bed was not released. The limiting factor accepting another patient in the ED is the number of beds not the capacity of radiology. In a ward area, it is not unusual to have many departments visited without releasing that patient’s bed. The key is to look at the “in” and “out” time stamps of each department. If a time stamp is encompassed within a longer time stamp, then exclude the shorter department and times stamps from the analysis. The output from a patient record with only the boarding departments included is shown below:
With this data we know the entry point, entry time, length of stay and the next department. This provides all the information needed to move an entity (patient) through the model. When combined with the other patient records, we had a complete picture of what happened in the hospital over any selected period of time. This type of model can be easily checked by comparing actual census records against model census for the same date.
To import the information into ProcessModel the data had to be structured to fit a provided ProcessModel Excel template. To structure the data, each patient record needed to be translated to a single line and by converting the in and out time stamps into decimal hours for length of stay. The template below shows an example entry using the record above:
We used Excel to format and transfer all the patient records into the template. This template converts the data into a format that can be read into ProcessModel as a scheduled arrival. The attributes values listed on each row are transferred into the Action Logic of the arrival. for clarity, a single arrival is shown imported into the schedule arrival dialog below:
The attributes named a_loc1 tells the model the first location for this patient. The attribute a_Time1 tells the model the length of time the patient will stay in the first department. Linking this template to the model takes about 30 seconds. During the update process, thousands of lines of patient records can be read into a model in just a less than a minute.
To Model Overall Patient Flow Use the Model Template
Developing the model was easier than any model I have previously built. The structure of the model was provided in the ProcessModel model template. All we had to do is change the names of the activities to match our departments and add additional departments. A list of default descriptors are supplied in the model. We created a list of descriptors that matched our departments. Descriptors are used to represent the names of the departments. They are usually short names for the departments and must be unique from activity names. We just put a “m_” as a prefix on each each descriptor. The descriptors only need to added to the first attribute. The rest of the attributes descriptors could be left blank. This makes changing the descriptors really easy. The provided model template is show below:
Action logic needed to be modified in each of the “department” activities to use the new descriptors, but the provided action logic structure allowed an easy to follow example.
One of the vexing problems I have had in the past is how to implement discharge windows. This seemed to be an impossible modeling problem. This model template included a method creating discharge windows. Just by changing a distribution, the time at which a patient was discharged could be changed to a specified time window. This was very helpful to see the impact of opening capacity faster to allow for more surgical starts.
The only part of the model that was difficult and not included in the template was inserting new patients into the model. When we used the template to model overall patient flow we could recreate what happened, but new patients would need to to use probable paths and distributed times to predict what would happen with additional surgeries. We had to review statistics for many surgeries to determine the distributions for departments visited with associated times spend in each department. This allowed the model to be run with different types of added surgeries and see the predicted impact. We used daily pattern arrivals (this allows day of the week and time of arrival for the remainder of the model run) and included the class of surgery. When these new arrivals enter the model they go to a sub model where they receive all location attribute values and time values via distributions. We found it was easiest to break out types of surgeries into separate paths to cut down on the logic in each activity. This separate section of the model, which was used to generate the path and times for new patients, was put into a submodel to keep the main layout clean.
Model Overall Patient Flow to Identify Bed Capacity Opportunities
Creating a model of the overall patient flow allowed our hospital to immediately identify 4 new surgical opportunities per week without exceeding the capacity limits or reserve capacity limits required by the emergency department. We are working toward additional opportunities by discharging earlier. Moving the discharge times earlier in the day requires a cultural shift and will require additional projects and time. This project was valuable because it required low effort to find quick patient centered and financial returns. Additionally, the model helped the effected departments to see the capacity opportunities and issues. The technique used to model the overall patient flow can be transferred to other areas in the hospital and we have plans to use this to help make changes to the surgical center for our next project.
Leave a Reply