Hi Team,
I am working on problem where waiting patient can be reassigned to provider based on schedule. I am able to model it but I think there may be better approach since it is checking schedule for waiting patient every 0.1 min which is making model running slow.
@Felix Möhlmann @Jason Lightfoot
Thank you!
Hi @Ankur A3, was Felix Möhlmann's answer helpful? If so, please click the "Accept" button at the bottom of their answer. Or if you still have questions, add a comment and we'll continue the conversation.
If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always unaccept and comment back to reopen your question.
What you could do is measure the time until the assigned provider is no longer available and use that value as the maximum wait time in the Pull from List activity.
That way, the token only enters the re-assign activity once per provider change.
You also need to handle the case in which no provider is available for the 'WaitingHour' value (once provider C goes off schedule)
Currently you would get an error, when the query doesn't return a row. The 'else' case could involve setting the provider value in a way, that the token is send to a sink by a Decide activity, for example.
Table result = Table.query(...);
if(result.numRows > 0)
{
return result[1][1];
}
else
...
Hi @Felix Möhlmann,
I am ok with your approach. Definitely, I will try it at my end.
Just to fix it quickly, I have also got some idea but it is not working well. I would like to understand what is going wrong here since it seems little easy. Since provider schedule is changing every hour, I am using wait for event activity to let the token wait up to next schedule. But, wait for event is not working as it is expected to work. Also, it is not pulling next assigned provider if it works too some time.
Can you help me to debug it? I am not able to upload model due to technical issue going on.
Thank you!
I assume you mean the Wait for Event is not working as expected?
I would guess that because you first assign the provider once the token fails to pull it and then wait for up to one hour, the assigned provider will be the one from the previous slot.
Example: The token could not pull provider A and is send to 'For Waiting Patient' block. Because at that time provider A is still active (but busy), the token is still assigned to A. It then waits until the next full hour, at which point provider A becomes inactive, so it can't be pulled anymore. So the token is send to the be assigned a new provider again but has to wait for the next hour and so on.
The Wait for Event probably works correctly but, depending on the simulation speed, the token has completed the loop before you see it even move.
This is why I proposed the above solution. I don't think it makes to ever have the token wait outside of the Pull from List activity because a provider might become available during that wait time.
A different way to achieve that would be the 'Release Token' activity. The tokens push themselves onto a list before they enter the Pull from List activity (Wait Time 0, Leave On List On Early Release). If they successfully pull a provider they pull themselves off that list (use 'token' in the query field).
The hourly token can then use this list to first pull all tokens ('Leave Entries On List', the list is just used to get references) and move them all to the reassign block with 'Release Token'.
I have 1 question in last approach you are shown here.
In the right most flow, there is flow from "push to token list" to "pull provider". What is the significance of it once tokens are pushed to "token list"?
Thank you!
15 People are following this question.
FlexSim can help you understand and improve any system or process. Transform your existing data into accurate predictions.
FlexSim is a fully 3D simulation software environment. FlexSim can be used to simulate any process in any industry.
FlexSim®, FlexSim Healthcare™, Problem Solved.®, the FlexSim logo, the FlexSim X-mark, and the FlexSim Healthcare logo with stylized Caduceus mark are trademarks of FlexSim Software Products, Inc. All rights reserved.
