Stream: questionnaire
Topic: enableWhen & partial dates or dateTimes?
Paul Lynch (Mar 02 2022 at 16:11):
Is there documentation for how enableWhen should handle comparisons of dates and dateTimes when one or both is a partial date or dateTime? I know that is documented in FHIRPath, but I didn't see it for enableWhen.
Brian Postlethwaite (Mar 02 2022 at 21:41):
This has become problematic as the updated fhirpath text now says you can't mix precisions, which makes this even more difficult to design as you don't have control over what the user is going to provide.
Lloyd McKenzie (Mar 03 2022 at 02:56):
Um, yeah. That seems like an unrealistic constraint. There are all sorts of situations where we're going to need to compare dates and dateTImes with differing precision. Where's the best thread to discuss this in FHIRPath?
Paul Lynch (Mar 03 2022 at 18:25):
@Brian Postlethwaite Is this text from https://hl7.org/fhirpath/#comparison what you are referring to, or is there a later revision?
For partial Date, DateTime, and Time values, the comparison is performed by comparing the values at each precision, beginning with years, and proceeding to the finest precision specified in either input, and respecting timezone offsets. If one value is specified to a different level of precision than the other, the result is empty ({ }) to indicate that the result of the comparison is unknown.
That permits comparison of partial DateTimes with differing precision, but returns empty {} if the comparison would be ambiguous. For example, 2018-02 > 2018-01 is true, but 2018-02 > 2018 should be {}. ("should be" because fhirpath.js currently has the second one wrong, I think).
Brian Postlethwaite (Mar 03 2022 at 20:24):
That's correct. If the precision is different, you get nothing. (And makes Brian sad :sad: )
Lloyd McKenzie (Mar 03 2022 at 20:26):
That's not helpful. If I say "Is 1982 < 1987-12-15?", the answer should absolutely be 'true'. The difference in precision only matters if I say something like "Is 1982 < 1982-12=15?"
Paul Lynch (Mar 03 2022 at 22:03):
And that is the case where you get empty. @1982 < @1987-12-15 will return true.
Lloyd McKenzie (Mar 03 2022 at 23:04):
Yes, but it would also return true if you said @2015 < @1987-12-15, would it not?
Paul Lynch (Mar 04 2022 at 00:30):
That is false. Try it at https://hl7.github.io/fhirpath.js/
The reason is that the precision only comes into play when components are equal. You compare dates starting with the lowest precision, year, then year+month if the years are equal, then year+month+day if the year+month was equal, and so on. So, in your example it compares 2015 with 1987, finds that 2015 < 1987 is false, and stops there.
Lloyd McKenzie (Mar 04 2022 at 00:50):
ah. That's the bit that wasn't clear to me. So, for dates that are equivalent except for precision, =, < and > all return true? That's probably acceptable. So using the FHIRPath rules for comparison would presumably be a reasonable clarification to add to the spec?
Paul Lynch (Mar 04 2022 at 00:54):
No. Maybe you meant "empty"? @2015 < @2015-05 is empty, and also for > and =. Yes, since FHIRPath went to the trouble to figure this out already, I think it is best if Questionnaire enableWhen just follows that.
Lloyd McKenzie (Mar 04 2022 at 01:21):
Right, but 'empty' would have to have a behavior for enableWhen - and my presumption is we'd say that "empty" = true for our purposes.
Lloyd McKenzie (Mar 04 2022 at 01:21):
I.e. if things aren't clear, turn it on.
Elliot Silver (Mar 04 2022 at 03:18):
It seems to me that the comparison would have been better defined using the something like "is the last instant of the first time before the first instant of the second time?"
Elliot Silver (Mar 04 2022 at 03:19):
But I guess it's too late for that now, and I'm sure there were plenty of reasons why it is defined the way it is currently defined.
Elliot Silver (Mar 04 2022 at 03:20):
Can the differing length issue be dealt with by truncating both dates to the length of the shorter of the two?
Brian Postlethwaite (Mar 04 2022 at 06:03):
empty does not evaluate as true...
Brian Postlethwaite (Mar 04 2022 at 06:04):
We want this to be the same as the invariant processing (and I don't like that empty doesn't do that - it's how the dotnet engine did it till a short time ago)
Lloyd McKenzie (Mar 04 2022 at 06:32):
Right - but enableWhen must evaluate to 'true' or 'false'. There's no room for an 'unknown'. So I'm asserting that, for our purposes, if the FHIRPath evaluation is empty, the element would be enabled.
Brian Postlethwaite (Mar 04 2022 at 07:35):
I'd really encourage us to have the same rules as validation here.
Lloyd McKenzie (Mar 04 2022 at 14:33):
Validation can spit out warnings. enableWhen can't really do that...
Brian Postlethwaite (Mar 07 2022 at 09:35):
That's the type of invariant, not from the expression itself.
Lloyd McKenzie (Mar 07 2022 at 19:40):
I don't follow... What do you mean by "type of invariant"? We're not talking about an invariant at all...
Brian Postlethwaite (Mar 07 2022 at 20:33):
We're talking about an expression that results in either a true or false value here.
I don't want there to be multiple interpretations of that for different places.
Lloyd McKenzie (Mar 07 2022 at 22:47):
Right. But you were saying that it would evaluate to true, false or empty - and we need to decide what 'empty' means, correct?
Brian Postlethwaite (Mar 08 2022 at 03:41):
And that should be the same regardless of where we do it is what I want.
Lloyd McKenzie (Mar 08 2022 at 04:58):
Ok, so what does 'empty' do in an invariant?
Brian Postlethwaite (Mar 08 2022 at 11:47):
Unfortunately that results as false.
Which the dotnet implementation didnt do till a few months ago (and was happy) then sometime said the Java is doing the other, and that's what was intended, so I was sad :pensive:
Lloyd McKenzie (Mar 08 2022 at 14:13):
Is there a place where this is discussed?
Brian Postlethwaite (Mar 08 2022 at 19:22):
On the fhirpath channel.
Paul Lynch (Mar 08 2022 at 19:29):
@Brian Postlethwaite Can you post a link to where it says {} in an invariant means false?
Brian Postlethwaite (Mar 08 2022 at 19:32):
And Grahame points to this part of the spec.
http://hl7.org/fhirpath/N1/#null-and-empty
Paul Lynch (Mar 08 2022 at 20:56):
That part doesn't mention "false".
Brian Postlethwaite (Mar 08 2022 at 21:57):
Problem is boolean evaluation in tri-state condition.
True else false
Or
False else true.
And null falls into else case.
I do need to find in the spec where the invariant case is documented.
Last updated: Apr 12 2022 at 19:14 UTC
