How overlapping stays are adjusted about hospitalnetwork

[tjibbed]

Yes, indeed. Technically speaking there are the two types of overlaps *(type 1: partial overlap, type 2: full overlap).
It depends a bit on definitions what type of overlap it would be if t3 and t4 are the same day, but I generally consider that the first type (i.e partial overlap)

Type 2 is easy, these become the three admissions as you wrote them down, indeed.

[A......A]{B.....B}[A.......A]
t1____t2____t3_____t4

For type 1 we need to make a choice about which is leading, admission or discharge. I always assume admission, which would mean
[A.....A]{B....................B}
t1____t2____t3_____t4

Under the hood of the function the two types are actually treated equally. I think of it as an ordering of admission and discharge dates/times.

Type 1:
admA....admB....disA....disB
Type 2:
admA....admB....disB....disA

No matter what type, I create three records:

1. admA...admB (in hospital A)
2. admB...disB (in hospital B)
3. disB...disA (in hospital A)

If the overlap is type 1, record 3 has a negative length of stay (disB>disA), an is removed.

This only works (I think) if the admission is "leading".

[ClementMassonnaud]

Thank you, it's clear now
For type 1, I too would consider that the admission is leading. Although, it would be nice if we could be able to compute both, and let the users choose whether they want the admission or discharge to be leading. I'll try and see if I can figure something out.

Meanwhile, I'll also right specific tests to make sure the function work as expected.

[tjibbed]

I agree that we should give the user the choice.

However, taking the discharge as leading may not be straight forward, because you would have to actively separate type 1 from type 2, or otherwise a type 2 would result in following conversion:
from original
[A......A]{B.....B}[A.......A]
t1____t2____t3_____t4
converted to
[A...................................A]
t1__________________t4
, losing the inbetween admission.

But I might be mistaken there, maybe there is a way of defining them such that it works for both.

[ClementMassonnaud]

@tjibbed did you get a chance to look at the new version of the adjust_overlapping_stays() function I proposed with commit #50200db?

As I explained in the commit, the two versions give the same results on all the tests I wrote. Considering the current version though, I'm not sure to understand the purpose of the iterator and how it works. Because I created a fake database with all the types of overlapping stays I could think of, with overlapping stays nested multiple times, etc. And it seems that the function adjusts for those stays correctly with only one pass in the while loop... Maybe you can take a look at the tests and see if I'm missing something.

Anyway, the new function works quite similarly to the current one, but with a slight change that allows to adjust partial overlaps with either admission or discharge leading. Also, it's using a bit more of the useful data.table syntax which makes the function shorter.

If the new function is not missing anything important that I might have missed, I would propose to use it as a default, mainly for the two advantages I mentioned.

[tjibbed]

Sorry, haven't been able to look at it thoroughly yet. I've seen the code, but that's about it at the moment. I'm on the road for the rest of this week, but will try to prioritize for beginning of next week.

I will test it to some of the real data as well, to see if it produces the same results if I input the same assumptions.

[PascalCrepey]

Closing this question since it has been answered, and opening a new issue regarding the new implementation of overlap management.