Stream: implementers
Topic: Definition of $lastn
Niek van Galen (Mar 02 2020 at 16:09):
Looking at the Last N Observations Query I am confused about the definition of 'last'. In clinical context, it seems logical to think of last being the latest observation e.g. last measured blood pressure.
However, reading the STU3 specification this is not mentioned anywhere where I would expect to see something like 'sorted from most recent to the oldest using the effective[x] element'. For instance, one could also think of using the meta.lastUpdated element to determine the latest observation.
The vague sentence 'they are passed to a server algorithm of some kind that uses them to determine the most appropriate matches' also kind of worries me: how should this work?
In R4 this seems to be a bit more clear because the phrase 'effective times' is mentioned. But still: a bit vague.
Can someone explain further and clarify this?
Lloyd McKenzie (Mar 02 2020 at 16:28):
It is indeed expected to be the "most recent". We should probably also exclude 'predicted' values (those where the effective time falls after the time of the Observation). Feel free to submit a change request for us to further clarify in R5.
Ardon Toonstra (Mar 02 2020 at 17:33):
Just to be sure: "most recent" as in clinically based on effective time? Or based on a _lastUpdated thing? We expect the first.
Lloyd McKenzie (Mar 02 2020 at 18:18):
Should be based on effective time I think
Alexander Henket (Mar 02 2020 at 19:18):
Done: J#26428
Ardon Toonstra (Aug 19 2020 at 07:28):
We went forward with the $Lastn operation based on effective[x] but run into difficulties.
In FHIR-26428 @Eric Haas commented, the $Lastn definition needs to clarify how it should work with ( period vs datatime vs timing). This is exactly where we run into problems with our implementation.
What would be the correct behaviour of a $lasnt operation with max = 1 when there is/are:
- only 1 observation without an effective[x] --> return it or not?
- multiple Observation have no effective[x] --> return them all or none?
- multiple Observation, some with an effective[x] and some without. --> return only the latest with an effective[x]?
- multiple Observations with an effectivePeriod. Some have a period.start and no period.end. Do they need to be returned over a 'closed' period?
Niek van Galen (Aug 20 2020 at 06:04):
@Lloyd McKenzie can you shed some light on this?
Eric Haas (Aug 20 2020 at 16:31):
What would be the correct behaviour of a $lasnt operation with max = 1 when there is/are:
taking these one at time...
how often is an operation dateless? That IMO is not very useful
only 1 observation without an effective[x] --> return it or not?
not - since this is a time based operation.
multiple Observation have no effective[x] --> return them all or none?
none
multiple Observation, some with an effective[x] and some without. --> return only the latest with an effective[x]?
Yes
multiple Observations with an effectivePeriod. Some have a period.start and no period.end. Do they need to be returned over a 'closed' period?
Yes
added a comment to document all this.
ryan moehrke (Aug 20 2020 at 18:10):
multiple Observations with an effectivePeriod. Some have a period.start and no period.end. Do they need to be returned over a 'closed' period?
Eric, what are you interpreting this as? resources without a period.end should not be returned as if they had no effective[x] at all? or some other reading into the 'closed' period that I'm not getting?
Eric Haas (Aug 20 2020 at 18:15):
no period end means is current so that would be the most recent - right? Could always add some new parameters to the operation to interpret it differently ... lets ping the lastn expert @Jenni Syed
ryan moehrke (Aug 20 2020 at 18:16):
ah, that makes a lot more sense, thanks
Jenni Syed (Aug 20 2020 at 19:21):
I think it would likely go by the "begin" to compare, but also can confirm if we have this scenario in our internal system or not today. I can see the argument for "it didn't complete yet, so it's more recent" but the "it didn't complete yet" part is worrisome for "most recent"
Lloyd McKenzie (Aug 23 2020 at 22:40):
No period end only really makes sense for a predictive observation - one where the observer is asserting that the value is expected to hold 'forever'.
ryan moehrke (Aug 24 2020 at 14:35):
so if a resource has effective[DateTime or Instant] compare by that value, else if it has effectivePeriod.end compare by that value, else if it has effectivePeriod.start compare by that value. And any resources without an effective value are ignored for the purposes of $lastn, correct?
Also I don't think Ardon needs it but how would effectiveTiming be handled? just the most recent of the timing.events?
Eric Haas (Aug 24 2020 at 17:06):
for timing follow this guidance:
Timing the specified scheduling details are ignored and only the outer limits matter. For instance, a schedule that specifies every second day between 31-Jan 2013 and 24-Mar 2013 includes 1-Feb 2013, even though that is on an odd day that is not specified by the period. This is to keep the server load processing queries reasonable.
Ardon Toonstra (Aug 26 2020 at 13:19):
Thanks all for the input. I agree with the 4 answers that @Eric Haas gave and I believe @ryan moehrke summarizes it quite well. So first DateTime or Instant, then Period.end and lastly by Period.start. Can we get this documented/clarified in the FHIR spec?
To check my understanding: theoretical speaking if you have Observations grouped by one code, with some having an effectivePeriod that is ongoing while others have a effectiveDateTime: the Observation with the latest effectivePeriod.start and no end date should be returned over a Observation with a more recent effectiveDateTime. Correct?
Ardon Toonstra (Aug 26 2020 at 13:22):
I now see that Eric has made a comment in the FHIR-26428 ticket, hopefully, that will suffice :)
Eric Haas (Aug 26 2020 at 16:51):
It will be as part of the above mentioned tracker
Last updated: Apr 12 2022 at 19:14 UTC
