How do you model patient care units that open and close per a daily schedule?

Question

question

Lou Keller asked Oct 7, '16 Cliff King edited Oct 28, '16

How do you model patient care units that open and close per a daily schedule?

A client has written, "In the attached ED model, patients leave a Fast Track location to go to X-ray, but while they are gone, the Fast Track Location goes 'Off Schedule', and they are stuck in X-ray, thus bottle-necking the X-ray process. Also as a result, they never return to the Fast Track area." The client's first solution was to insure patient traffic into the Fast Track was governed by table lookup “based on simulation time,” thus allowing Fast Track patients enough time to enter the Fast Track, get an X-ray and return to their bed prior to the Fast Track going “Off Schedule”. Evidently this worked until further requirements negated the solution's value.

So, the obvious "technique" question is, "How can a patient preempt a location's off-shift state to return the patient's reserved bed?"

crmh-ed-ver-18a.fsm

@[email protected]

Software Version:

FlexSim HC 5.1.0

priorities offschedule location schedule offshift patient unit schedules

crmh-ed-ver-18a.fsm (7.7 MiB)

Answer 1 · 2016-10-11T17:20:42Z

Cliff King answered Oct 11, '16 Cliff King edited Oct 13, '16

The client had the right idea. Use decision logic for whether the patient should go back to their reserved Fast Track location or go somewhere else instead. If the patient goes somewhere else, it is important to unreserve the patient's reserved location.

Rather than put the decision logic in the Patient Destination field of the X-ray return activity, you may want to use a Decision Point activity that decides between an activity that returns the patient to Fast Track and another activity that has the patient go somewhere else. You can then use the Activity Started Trigger of the activity that has the patient going somewhere else to unreserve the patient's original Fast Track location.

Although there is a pick list option for unreserving a location, there are a couple weaknesses with the option I just discovered: 1) it doesn't provide an easy way to reference the location currently reserved by the patient, and 2) it doesn't change the state of the location to something other than "HoldingForPatient" after unreserving it.

You can use the following statement for the Location reference to address the first weakness:

tonode(get(first(getvarnode(patient, VAR_PatientDestination))))

And although you may not need to do anything to address the second weakness because the state of the FastTrack location has probably already changed from "HoldingForPatient" to "OffSchedule", if you do want to change the state of the unreserved location in the future, you would need to insert a statement similar to the following after line 22 in the code of the pick list option:

setobjectstate(location, STAT_Vacant);

· 4

Lou Keller commented · Oct 11, 2016 at 05:31 PM

@[email protected]

0 ·

Cliff King commented · Oct 11, 2016 at 08:50 PM

Here's an example model demonstrating how I typically like to model an area that is only opened part of the day. There is dashboard widget in the model explaining it.

0 ·

Lou Keller Cliff King commented · Oct 11, 2016 at 09:09 PM

Cliff, As usual you're in tune with exactly what's needed to solve a problem! Thanks for your work, your support and your creativity in the design of great solutions to complex healthcare problems!

@[email protected]

0 ·

Cliff King commented · Oct 12, 2016 at 09:26 PM

I was just informed that the example model I uploaded earlier wasn't working. The model appears to have been corrupted somehow. Not sure how, but as I was looking into the problem, I discovered that the model wasn't working quite the way I had described, so I made some improvements to it. Here is the new model: modeling-emergency-care-units-with-scheduled-open.fsm

0 ·

modeling-emergency-care-units-with-scheduled-open.fsm (153.9 KiB)

Answer 2 · 2016-10-28T17:05:28Z

Cliff King answered Oct 28, '16 Cliff King edited Oct 28, '16

Here is another example model that demonstrates a solution to the problem of modeling different patient types assigned to different areas within an ED and some of the areas are closed during specific times of the day. If you have many different patient types, many different areas, and many different schedules, then this example will appeal to you more. Here's the description that I also include on a dashboard within the model, so you can learn about the model before downloading and opening it.

Model Description

There are three different patient types: PCI 1, PCI 2 and PCI 3.

There are three different areas of the ED: Pod A, Pod B and Pod C.

PCI 1 patients are typically placed in Pod A, PCI 2 patients in Pod B, and PCI 3 patients in Pod C; however, patients can be placed in other pods as needed. The global table named PodPrefs provides a list of pods ordered by preference for each patient type.

The arrival pattern of patients differ by time of day and type of patient. A close examination of the arrival table in the model reveals that PCI 1 patients rarely arrive between the hours of 11pm to 11am, and PCI 2 patients rarely arrive between the hourse of 2am to 7am. Therefore, the ED has decided to close Pod A during the hours from 11pm to 11am, and to close Pod B during the hours from 2am to 7am. In the model, each of these pods has been assigned their own Shift Schedule which closes the inputs to the bed locations within the pod.

To place a patient in the first available pod found in their preferentially ordered list of pods, we take advantage of a powerful feature of the "Based on destination status" option. Take a look at this option on the Patient Destination field for the 40_Bed Placement activity, and you'll see that there is only one entry for the "List of destinations to evaluate" and that it contains the following expression:

tablerow(PodPrefs, getlabel(patient,LABEL_PCI))

Rather than use multiple entries in those pick list options asking for a list of entries to define objects such as destinations, staff or whatever, we are allowed to reference a single row of a table that contains an ordered list of objects. The tablerow() command accepts two params: the table name, and the row number in the table. Notice that I have used the patient's PCI label value to define the table row number!

A couple other handy pick list options were used in this model. Check out the "Based on patient's destination" option used to define the staff requirement for the 40_Bed Placement activity. By using this option we are able to have a nurse working within the pod the patient happens to get assigned to during the model run, escort the patient to the pod!

In a similar fashion, the "Based on patient's location/area" option used to define the staff requirement for the 90_Discharge Process activity, ensures that a nurse working within the patient's pod will conduct the discharge process. Alternatively, if the same nurse who initially placed the patient in the pod should be the one to discharge the patient, then I could have simply chosen the "Used in earlier activity" option instead.

Another important pick list option was used to define the Patient Destination for the 70_Return to Bed activity. This option I adapted from the frequently used "Location reserved by patient" pick list option. Because it is possible for the pod to close before or after a patient leaves the pod to get an X-Ray, I needed to be able to force the patient to return to their reserved location even though the reserved location is inside a closed area. I plan on including this adaptation in the next release of the software (v 5.1.1), but for now, you'll need to copy the option from this model, if you want this behavior in your own model.

multi-pod-ed-model-demonstrates-use-of-tables-to-d.fsm (227.8 KiB)

question