I'm getting this result for all patients evaluating the DSF measure against (I think)

Pushed a <a href="https://github.com/DBCG/cqf-ruler/commit/283c430d482904da80dd434b375

Better, but now its throwing: <div class="snippet-clipboard-content notranslate po

Could it be as simple as reversing low and high in this? <code class

DSF Measure Failure about cqf-ruler HOT 12 CLOSED

cqframework commented on September 26, 2024

DSF Measure Failure

from cqf-ruler.

Comments (12)

jeffeastman commented on September 26, 2024

This logic works just fine (well, without errors) in my in-memory evaluator:

Measure = Measure/measure-dsf
	denominator = 363
	initial-population = 200
	numerator = 305

from cqf-ruler.

jeffeastman commented on September 26, 2024

The odd numerator and denominator counts are due to a defect in the FhirMeasureEvaluator that does not properly code the MeasureReportGroupComponents to handle multiple numerators, denominators, etc. See #28

from cqf-ruler.

jeffeastman commented on September 26, 2024

Converging on the cause. This blows up in JpaDataProvider line

low = new DateParam(ParamPrefixEnum.GREATERTHAN_OR_EQUALS, convertPathToSearchParam(dateLowPath != null ? dateLowPath : datePath));

because, I think, convertPathToSearchParam() is returning "effective-value" instead of the date. The dateLowPath is null. Digging into how this should work and why its not.

from cqf-ruler.

jeffeastman commented on September 26, 2024

DRR and DMS measures do not exercise this particular code, so the problem is DSF measure-specific. The failure is in a rather normal Numerator 1 CQL expression:

// Depression Screening
define "Numerator 1":
	"Initial Population"
	and
	exists (
		[Observation: "Depression Screen"] DepressionScreen
			where DepressionScreen.status.value in { 'final', 'amended' }
				and DepressionScreen.effective.value in "Measurement Period"
	)

that's compiled into:

               <operand localId="124" xsi:type="Query">
                  <source localId="110" alias="DepressionScreen">
                     <expression localId="109" dataType="fhir:Observation" codeProperty="code" dateProperty="effective.value" xsi:type="Retrieve">
                        <codes name="Depression Screen" xsi:type="ValueSetRef"/>
                        <dateRange localId="121" name="Measurement Period" xsi:type="ParameterRef"/>
                     </expression>
                  </source>
                  <where localId="117" xsi:type="In">
                     <operand localId="113" path="value" xsi:type="Property">
                        <source localId="112" path="status" scope="DepressionScreen" xsi:type="Property"/>
                     </operand>
                     <operand localId="116" xsi:type="List">
                        <element localId="114" valueType="t:String" value="final" xsi:type="Literal"/>
                        <element localId="115" valueType="t:String" value="amended" xsi:type="Literal"/>
                     </operand>
                  </where>
               </operand>
            </operand>

from cqf-ruler.

jeffeastman commented on September 26, 2024

Turns out, none of the other working measures exercise this code: BCS, CCS, COL and PVS don't either. @c-schuler , @brynrhodes any ideas while I'm floundering a bit here?

Looking at DateParam, it doesn't seem to be the right class to be using here as it expects a date.

from cqf-ruler.

brynrhodes commented on September 26, 2024

I'd have to dig into see what's actually going wrong with the filter there, but a possible workaround is to turn off the dateRangeOptimization in the translator. That will at least apply that filter after the retrieve, rather than as part of it, which is where the problem is happening.

from cqf-ruler.

c-schuler commented on September 26, 2024

Pushed a commit. Get the latest and try again.

from cqf-ruler.

jeffeastman commented on September 26, 2024

Better, but now its throwing:

Caused by: ca.uhn.fhir.parser.DataFormatException: Lower bound comparator must be > or >=, can not be le
	at ca.uhn.fhir.rest.param.DateRangeParam.validateAndThrowDataFormatExceptionIfInvalid(DateRangeParam.java:469)
	at ca.uhn.fhir.rest.param.DateRangeParam.setRangeFromDatesInclusive(DateRangeParam.java:321)
	at ca.uhn.fhir.rest.param.DateRangeParam.<init>(DateRangeParam.java:120)
	at org.opencds.cqf.providers.JpaDataProvider.retrieve(JpaDataProvider.java:112)
	at org.opencds.cqf.cql.elm.execution.RetrieveEvaluator.evaluate(RetrieveEvaluator.java:52)

Looks like the GREATERTHAN_OR_EQUALS and LESSTHAN_OR_EQUALS are the wrong flavor.

also, if you could add the null check in

			if (valueSet != null && terminologyProvider != null && expandValueSets) {
				ValueSetInfo valueSetInfo = new ValueSetInfo().withId(valueSet);
				codes = terminologyProvider.expand(valueSetInfo);
			}

it will resolve the other two issues #26 & #27

from cqf-ruler.

jeffeastman commented on September 26, 2024

Could it be as simple as reversing low and high in this?

rangeParam = new DateRangeParam(high, low);

I'm going to test it.

from cqf-ruler.

jeffeastman commented on September 26, 2024

That got me a bit farther to the next layer of the onion. Adding a try around getResources:

		try {
			resourceList = bundleProvider.getResources(0, 50);
		} catch (Exception e) {
			e.printStackTrace();
			throw e;
		}

throws this:

ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: Unknown search parameter effective-value for resource type Observation
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at ca.uhn.fhir.rest.server.exceptions.BaseServerResponseException.newInstance(BaseServerResponseException.java:301)
	at ca.uhn.fhir.jpa.search.SearchCoordinatorSvcImpl.verifySearchHasntFailedOrThrowInternalErrorException(SearchCoordinatorSvcImpl.java:419)
	at ca.uhn.fhir.jpa.search.PersistedJpaSearchFirstPageBundleProvider.getResources(PersistedJpaSearchFirstPageBundleProvider.java:56)
	at org.opencds.cqf.providers.JpaDataProvider.retrieve(JpaDataProvider.java:122)

from cqf-ruler.

c-schuler commented on September 26, 2024

There were a few issues. First, the CQL needed a small tweak to workaround a translation issue (Could not resolve code path medicationCodeableConcept for the type of the retrieve FHIR.MedicationDispense). So grab the newest Library resource. Second, the JpaDataProvider needed some work to resolve code and date paths correctly, including the reversal of low and high values like you stated above. I have tested these fixes with Patient-1138 to verify. Let me know if this is now operational for you.

from cqf-ruler.

jeffeastman commented on September 26, 2024

This measure is now working so closing the issue

http://localhost:8080/cqf-ruler/baseDstu3/Patient/Patient-1137/_history/1
http://localhost:8080/cqf-ruler/baseDstu3/Patient/Patient-6529/_history/1
	patient is in initial-population
	patient is in denominator
http://localhost:8080/cqf-ruler/baseDstu3/Patient/Patient-1132/_history/1
	patient is in initial-population
	patient is in numerator
	patient is in denominator
	patient is in denominator
http://localhost:8080/cqf-ruler/baseDstu3/Patient/Patient-6481/_history/1
	patient is in initial-population
	patient is in numerator
	patient is in denominator
	patient is in denominator

from cqf-ruler.

DSF Measure Failure about cqf-ruler HOT 12 CLOSED

Comments (12)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent