Ratio, episode-based measure observation results being returning as object instead of numeric value

[nmorasb]

For one set of observation results on an episode we are seeing a non-numeric result being returned. Instead, an Uncertainty object is being returned:

We were expecting the result to be either integer, decimal, or quantity. Measure bundle and patient JSON bundle are attached to help in reproducing this issue. The Uncertainty is returned on the last observation in the episodeResults for the only episode.

Is this valid and expected output that we'll need to code around?

ratio-encounter-object-obs-result.zip

[mgramigna]

Hmm interesting. ~On first glance, this doesn't look like valid and expected output~ (EDIT: see below comment). This could be an issue with underlying cql-execution engine and not fqm-execution, but will require more investigation. We will look into it, thanks!

[mgramigna]

Hi @nmorasb, I dug into this more with @cmoesel, and here is what we found:

TL;DR: Either add millisecond precision to patient data, or handle the Uncertainty.

This issue is happening due to the lack of millisecond precision present on the Encounter resource on the patient bundle you provided:

"period": {
  "start": "2012-01-16T08:00:00+00:00",
  "end": "2012-02-15T09:00:00+00:00"
}

Since there is no millisecond precision specified, cql-execution needs to provide the whole hour duration for the shortest possible and the longest possible duration based on the period provided:

The start of the period could be anywhere between 2012-01-16T08:00:00.000 and 2012-01-16T08:00:00.999. Similarly, the end of the period could be anywhere between 2012-02-15T09:00:00.000 and 2012-02-15T09:00:00.999. cql-execution needs to account for both the shortest and longest possible durations

• Shortest possible: 2012-01-16T08:00:00.999 - 2012-02-15T09:00:00.000 -> 720h 59m 59s 1ms -> 720 whole hours
• Longest possible: 2012-01-16T08:00:00.000 - 2012-02-15T09:00:00.999-> 721h 0m 0s 999ms -> 721 whole hours

Hence, the Uncertainty is created to represent either of these possible bounds. The "easiest" fix in this case is probably to add millisecond precision to the patient data:

"period": {
  "start": "2012-01-16T08:00:00.0+00:00",
  "end": "2012-02-15T09:00:00.0+00:00"
}

@cmoesel and I also looked through the CQL spec to see if there was clear language about this kind of case. One part to point to is https://cql.hl7.org/09-b-cqlreference.html#duration, which indicates that a duration expression must return "whole calendar periods for the specified precision" (see also https://cql.hl7.org/04-logicalspecification.html#durationbetween). So even though 720h 59m 59s 1ms is almost as close as you can get to 721 hours, it's still only 720 whole hours. Therefore, we believe the engine is actually behaving as expected here.

[nmorasb]

I think this makes sense, and we'll need to update MADiE to handle this appropriately. We're talking through how we want to handle this internally but from your examples and the linked docs I have to agree with you. Thanks for looking into this!