Turn Resource capacity on and off but allow queue

[Ian Darbey]

Hi,

I've 3 entry points to my system, emergency bed (A&E dept), elective bed (scheduled / planned procedure) and emergency elective bed (scheduled procedure that gets top priority i.e. a cancer surgery etc). They then all progress to an acute bed with no timeout based on emergency elective being top priority, emergency next and elective last.

I have a global attribute that tracks the number of days a hospital is overcapacity i.e. if a queue greater than X is formed for the acute bed (which is the next step for all 3 of these) for a number of days in a row then the elective bed capacity switches to 0. If the hospital is back undercapacity for a number of days the capacity switches back on for elective bed.

This works somewhat as planned with 1 key exception. When the capacity for the elective bed is turned off it appears to no longer allow a queue to form.

Elective demand is still present and the intent here is to demonstrate the build up in unmet demand when hospitals operate over capacity.

Is there a better way to work this? I did it based on the concepts I saw of queueing networks but perhaps I've missed a simple trick.

[Iñaki Ucar]

On Mon, 27 Jun 2022 at 21:56, Ian Darbey <iand...@gmail.com> wrote:

Hi,

I've 3 entry points to my system, emergency bed (A&E dept), elective bed (scheduled / planned procedure) and emergency elective bed (scheduled procedure that gets top priority i.e. a cancer surgery etc). They then all progress to an acute bed with no timeout based on emergency elective being top priority, emergency next and elective last.

I have a global attribute that tracks the number of days a hospital is overcapacity i.e. if a queue greater than X is formed for the acute bed (which is the next step for all 3 of these) for a number of days in a row then the elective bed capacity switches to 0. If the hospital is back undercapacity for a number of days the capacity switches back on for elective bed.

This works somewhat as planned with 1 key exception. When the capacity for the elective bed is turned off it appears to no longer allow a queue to form.

Elective demand is still present and the intent here is to demonstrate the build up in unmet demand when hospitals operate over capacity.

Do you have a minimal example of the issue? Capacity has no influence on the queue. If arrivals keep coming, and the queue is not full, it will continue growing. The only issue I can think of is that you may have a select() procedure and the policy you are applying does not consider a closed resource, so it is not selected anymore. Then the solution is to change or fix such a policy.

Iñaki

 

Is there a better way to work this? I did it based on the concepts I saw of queueing networks but perhaps I've missed a simple trick.

--
You received this message because you are subscribed to the Google Groups "simmer-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simmer-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/simmer-devel/697162ea-7def-4de8-96d8-0aff9fd01190n%40googlegroups.com.

--

Iñaki Úcar

[Ian Darbey]

I create the 52 resources with  add_resource(paste0("elective_bed_", c(1:52)))

use the elective_bed_reqequest function to select the right resource (the previous set attributes give me the model_id which is a number.

elective_bed_request <- function() {paste0("elective_bed_",get_attribute(ISM,"model_id"))}

the elective bed is selected and then seized in the Elective_Patient pathway. Is this where I should set the policy? At the moment I've no policy set so not sure what it's defaulting to. Would explicitly setting it to "shortest-queue" be enough?

Elective_Patient <- trajectory("Elective path") %>%
  set_attribute(keys = c("model_id","specialty", "age_band", "surgical_flag", "LOS" , "Pathway"),
                values =  function() elective_patient_sample()) %>%
  set_attribute("CHO", function(){identify_CHO(get_attribute(ISM, "model_id"))}) %>%
  simmer::select(resource = function() elective_bed_request()) %>%
  seize_selected(1) %>%
  simmer::select(resource = function() acute_bed_request()) %>%
  seize_selected(1, post.seize = elective_bed_release, continue = TRUE) %>%
  timeout(function() acute_elective_length_of_stay()) %>%
  join(pathways) %>%
  release("home")

The idea is that I've 3 doorways in to each Model_ID / hospital and I just want to be able to close this door but still have a queue form behind it.

Would simmer::select(resource = function() elective_bed_request(), policy = "shortest-queue") solve it? i.e. just being sure not to select one of the 'available' policies?

[Iñaki Ucar]

On Mon, 27 Jun 2022 at 23:04, Ian Darbey <iand...@gmail.com> wrote:

I create the 52 resources with  add_resource(paste0("elective_bed_", c(1:52)))

use the elective_bed_reqequest function to select the right resource (the previous set attributes give me the model_id which is a number.

elective_bed_request <- function() {paste0("elective_bed_",get_attribute(ISM,"model_id"))}

the elective bed is selected and then seized in the Elective_Patient pathway. Is this where I should set the policy? At the moment I've no policy set so not sure what it's defaulting to. Would explicitly setting it to "shortest-queue" be enough?

No, I mean, if you provide a function, then policies don't apply. The function provided is the policy. So, if your elective_bed_request function does return the resource that is closed, then the queue should build up. If that's not happening, it may be a bug, and then a small reproducible example would help debug it.

Iñaki

 

To view this discussion on the web visit https://groups.google.com/d/msgid/simmer-devel/8eeb6521-583d-483c-9b4e-beb8e3ada136n%40googlegroups.com.

--

Iñaki Úcar

[Ian Darbey]

Thanks for this.

In abstracting a reproducible example I actually discovered it was my mistake as I'd turned on some but not all of the demand so the queue wasn't getting a chance to form regardless of capacity switching.

In a related note..... I'd like to cap the admissions through the doorway to a realistic amount each day (based on prior trends in available historic data).

My initial thinking is an outer resource that each day gets reset to the upper limit reading from a set global key and then dwindles down (capacity reduces by 1 for each admission).

That way my current entry point controlling resource will still switch on and off and prevent admissions completely when necessary but the number of patients that can go through the trajectory will be limited by the upper limit of the outer door. Does that make sense / is a valid approach?

I'm already producing results comparable to our current proprietary product using simmer and with another but of work I'll have replicated all our existing features but added a lot more parameter controls for how patients travel through the system.

[Iñaki Ucar]

On Wed, 29 Jun 2022 at 19:17, Ian Darbey <iand...@gmail.com> wrote:

Thanks for this.

In abstracting a reproducible example I actually discovered it was my mistake as I'd turned on some but not all of the demand so the queue wasn't getting a chance to form regardless of capacity switching.

In a related note..... I'd like to cap the admissions through the doorway to a realistic amount each day (based on prior trends in available historic data).

My initial thinking is an outer resource that each day gets reset to the upper limit reading from a set global key and then dwindles down (capacity reduces by 1 for each admission).

That way my current entry point controlling resource will still switch on and off and prevent admissions completely when necessary but the number of patients that can go through the trajectory will be limited by the upper limit of the outer door. Does that make sense / is a valid approach?

Sure, sounds good to me. The other option would be to put that restriction directly into the generator function. Whatever works best for you.

 

I'm already producing results comparable to our current proprietary product using simmer and with another but of work I'll have replicated all our existing features but added a lot more parameter controls for how patients travel through the system.

Nice! :) :)

Iñaki

 

To view this discussion on the web visit https://groups.google.com/d/msgid/simmer-devel/0a26bb11-6ef0-4089-acb4-b3f080a6d3b1n%40googlegroups.com.

--

Iñaki Úcar