How to use the LWBS function without getting exception errors

[jim_montgomery]

[ FlexSim HC 5.1.0 ]

ed-ver-29.fsmThis question is in followup to a question asked by Fenia Tseligka on Jul 24, 2016 and found at the following link:

https://answers.flexsim.com/questions/25270/different-types-of-patient-need-to-leave-waiting-r.html

The questioner was supplied a technique for generating LWBS patients, but it created a series of exception errors.

I would like to know if anyone was able to work out the bugs experienced by the questioner when using the FlexSim LWBS capability inherent in the patient location “Patient Condition”?

Following the example from the answer in the link above, I inserted the following into the Patient Condition table of my waiting room:

Likewise, this technique seems to work as far as sending LWBS patients to the exit, but just like for the questioner, it generating a series of exception errors. Certain resources appear to freeze for no apparent reason.

Did anyone find a solution or can someone please offer a new solution?

Thanks,

Jim

[Matthew_Gillespie]

It looks like that question was eventually resolved in a separate private question. The main issue is that the patient may have started an activity and possible allocated staff by the time they choose to leave early. The Patient Condition Changes code was slightly modified to better handle this scenario:

First, the condition field now checks if the patient has allocated any staff. So include the int StaffAllocated line at the top and then throw the !staffAllocated && expression at the start of the condition field.

Second, the terminate activity line was added near the end of the code to stop whatever the patient's current activity is.

Here is the code used in the picture above so you can copy it:

...

/**Determine whether a patient will leave early \n*/
/**\nEarly Exit Condition: */

int PASS = true;
int staffAllocated = getobjecttype(getrequiredresource(patient,getvarnum(patient, VAR_ActivityRow),STAFF,1)) == OBJECT_Staff;
double waitingTime = time() - getentrytime(patient);
int PCI = getlabel(patient, "PCI");
int condition = /**/!staffAllocated && ( (PCI == 1 && waitingTime > uniform(120,180,1)) || (PCI == 2 && waitingTime > uniform(90,240,1)) );


if(condition == false)
	return 0;


if(condition)
{
	...
	if(!connected)
	{
		contextdragconnection(current, lwbs_obj, "A");
		openallip(lwbs_obj);
	}
	terminateactivity(patient, getvarnum(patient,VAR_ActivityRow));
	// Change the patient's current activity's type to "Patient Travels Unattended" (regardless of what activity type
	...
}
...

[jim_montgomery]

matthew-please-check-script.pdf

Thanks, Matthew. I inserted your script. The good news: resources are no longer freezing. The bad news: patients are not leaving LWBS. I have attached my Patient Condition Changes FlexScript. Would you please review it and tell me what I did wrong?

Thanks,

Jim

[Matthew_Gillespie]

That looks fine to me. I've attached a sample model where I used that code in the Waiting Room and it works great (I modified the condition to work for this model). Three patients walk in at the start of the model. The first is escorted out by the nurse before the LWBS time is up. The LWBS time is then up when the other two patients are in the waiting room. The 2nd patient doesn't leave because he has allocated the staff member who is walking back to escort him (so we can see the staffAllocated check is working and this patient won't throw exceptions). The 3rd patient, however, gets up and leaves because he waited more than 3 minutes without being seen and hadn't yet acquired a staff member. Make sure your condition is correct for your model - Is PCI 3 correct? Is 500 too long? Make sure the Evaluate Patients Every __ minutes field is set to an appropriate value. Is it firing at the right time- when patients have waited too long, but haven't been seen yet?

[jim_montgomery]

ed-ver-30.fsm

Hi Matthew,

Thanks for confirming the FlexScript is correct and for building a demo model to check the code.Now that you have validated that the LWBS code works, I am perplexed as to why the same code still does not work in my model. Despite making adjustments, reducing “Evaluate Patients Every” value from 50 to 30 min and reducing the “getcreationtime(patient) >” value from 500 to 400 and then to 300, patients are still waiting as long as 880 min to get into the exam room. See chart below:

Additionally, my counter and dashboard both show no LWBS patients exited.

I have attached the model. Can you please take a look and figure this bug out for me?

Thanks,

Jim

[Matthew_Gillespie]

The staff allocated check doesn't work if the staff requirement is defined as a specific staff member. For example, a lot of patients are in the waiting room on activity 55 - Walk to Trauma. The staff requirement for that activity is Reg_CA_1 and so the staffAllocated check always fails since it returns that Reg_CA_1 is allocated. If you switch the requirement to Any Member of the Reg_CA group, then the staffAllocated check doesn't fail unless the patient has actually acquired a specific staff member.

[jim_montgomery]

ed-ver-30.fsm

Thank you, Matthew. The good news: That fixes the LWBS issue. Now patients leave LWBS correctly. Yeah!! The bad news: The fix contributes to two new errors: First I get this error:

Then a waiting room segment goes into holding mode causing the following error:

Can you please help me to debug these new issues?

Thanks,

Jim

[jim_montgomery]

Matthew,

Did the software developers ever come up with a solution to these error messages?

Thanks,

Jim

lou.keller@flexsim

matthew.gillespie@flexsim

[cliff_king]

Jim,

I noticed you were kicking off activity 141 twice (once with a predecessor and once with a next activity). After removing the Next Activity from activity 140 in the attached model, I do not see any errors. See if it's doing what you expect now.

ed-ver-30-ck.fsm

p.s. as for LWBS modeling, you might want to make contact with @Lou Keller regarding his famous "impatience curve" approach. It uses an explicit activity for removing the patient from the model after they run out of patience for waiting. I think it is a better approach than to use the fields we provide on waiting rooms, but I'll let him try to sell you on it... 😉

[lou_keller]

Thanks, Cliff, for the "Impatience Curve" endorsement! In fact, I've attached a written explanation of how it can be used and a demo model that shows the Impatience Curve in operation. If anyone needs a more detailed explanation, send me a note!

lwbs-using-an-impatience-distribution-v5.zip

[jim_montgomery]

Hi Cliff,

Thanks for pointing out my stupid mistakes with predecessors/next activity. After removing the self-inflicted bug, the new model version fixes the first error (#738). However, I am still plagued with a set of waiting room chairs that go into hold mode for no apparent reason. The following error occurs in Scenario 2, Replication 1:

Also, thanks for advising me on Lou's work in this topic. I have studied his technique, and like the method by which it processes the LWBS patient. Unfortunately, the error above was still present when I applied his method.

Thanks,

Jim

ed-ver-32b-w-lwbs-function.fsm

[cliff_king]

Jim,

Your waiting room is "going into hold" because it gets reserved by a patient (ESI Level 3_ID1561) who happens to be in the waiting room for 1) a Nurse Assess between 05:22:30.00 and 05:22:39.85, and 2) an MD Assess between 05:22:39.85 and 05:22:46.46, and ultimately try to receive an X-Ray at time 05:23 which either will cause an error about an invalid staff member (because the required staff for Zap_Patient is based on patient's current location) or if a staff member is called, the patient will reserve the waiting room when he leaves it.

I assume you do not wish to have patients receive care in the waiting room, so you will want to look over your track to see why a patient is sometimes serviced in the waiting room. A good place to start would be to run Scen 2, Rep 1 up till just before patient ID1561 receives a Nurse Assess at time 05:22:30.

I've attached a screen shot of the Activity Table for patient ID 1561 in case it can give you any useful clues. Let me know if you can't figure out how it is possible for patient ID 1561 to be in the waiting room while receiving care (assuming of course that this is not what you expect), and I'll see if I can help you out.

[jim_montgomery]

Thanks, Cliff, for identifying the problem patient (ID1561). I could not figure out the solution, but I noted several quirks, and was hoping you could solve the puzzle from here. One significant issue is that, in spite of progressing through the track receiving care, the patient is assigned the label of a_LWBS. Thus, he should have left but stayed.

Oddity 1 - Patient pulls the resource physician to the waiting room for an assessment (below). An additional oddity is the fact that this physician comes from a different zone and group that the patient was assigned to.

Oddity 2 - Patient pulls more resources to the waiting room (below), as seen here receiving blood draw and X-ray

Oddity 3 - Patient is seen sneaking out of the model (below) without completing the X-ray activity.

Oddity 4 - Waiting room is reserved for patient just as a bed is reserved for a patient when transported to X-ray

Oddity 5 - In spite of the fact that the patient moves through the track receiving care, he is a LWBS patient (as seen below: a_LWBS = 1). This label was assigned at the waiting room location when he met the “Patient Condition…Patient Leaves Early” criteria.

[cliff_king · Accepted solution]

Jim,

It turned out to be a rather tricky problem. I believe I resolved it with a slight modification of the LWBS code on the waiting room objects. On line 56 of the code, there was the following statement that is intended to terminate a patient's ongoing activity before having the patient leave the model early.

terminateactivity(patient, getvarnum(patient,VAR_ActivityRow));

Under certain circumstances (e.g. the circumstances surrounding patient ID1561) the timing of events is such that the terminateactivity command ends up terminating the event to leave early. I believe I have fixed this problem by delaying the termination by 0.1 minutes by using the following statement instead

terminateactivity(patient, getvarnum(patient,VAR_ActivityRow),0,0.1);

[jim_montgomery]

Thanks, Cliff. You seem to have solved this problem.