Open vitorpamplona opened 9 months ago
@JPercival looks like you changed these lines recently. You might be aware of this potential issue.
We have a couple DateTime bugs in-flight, one was resolved with https://github.com/cqframework/clinical_quality_language/pull/1259.
I'm going to take another look at this once https://github.com/cqframework/clinical_quality_language/pull/1269 lands.
@Capt-Mac - Can you take a look at this? DateTime fixes were merged into CQL.
Based on the spec here I'd say that the millisecond-level output is correct: https://build.fhir.org/operation-measure-evaluate-measure.html
Attention: 3 lines
in your changes are missing coverage. Please review.
Comparison is base (
ca6099b
) 53.30% compared to head (dfdb31b
) 53.30%.
Files | Patch % | Lines |
---|---|---|
...ir/cr/measure/dstu3/Dstu3MeasureReportBuilder.java | 0.00% | 3 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@vitorpamplona I took a look at your changes to R4MeasureReportBuilder.java
R4MeasureProcessor.buildMeasurementPeriod does correctly default interval to expected value, which is what the CQL will use to actually calculate results:
This matches spec definition https://build.fhir.org/operation-measure-evaluate-measure.html
"The end of the measurement period. The period will end at the end of the period implied by the supplied timestamp. E.g. a value of 2014 would set the period end to be 2014-12-31T23:59:59 inclusive"
MeasureReport.Period however has different requirements https://www.hl7.org/fhir/R4/datatypes.html#Period and R4MeasureReportBuilder.getPeriod does correctly assume period based on provided values to $evaluate-measure.
Though for clarity, I do think these values should match
whatever value is passed in gets put on https://www.hl7.org/fhir/R4/datatypes.html#dateTime
example: passed in => returned yyyy-mm-dd => yyyy-mm-ddT00:00:00, yyyy-mm-ddT23:59:59 => yyy-mm-ddT23:59:59
Something like this:
went from outputting
to
after the upgrade to 3.0.
After lots of debug, I believe the following lines set the precision to seconds without considering if the last day is closed or open, which causes the subsequent operations to be based on the 0 hour and the output to match that.