-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"type": "Equivalent" Should not contain a localId #1279
Comments
It looks to me like the Emits
Emits
Does NOT emit
Does emit
So, I actually think the bug is the opposite of what you've posted. For some reason the @brynrhodes what are your thoughts? |
@JPercival , I was wondering that as well when we were looking at this. It appears that cqm-execution and fqm-execution are ironically providing the anticipated behavior for coverage calculation when the localId is missing for "Equivalent" first-class operator. But I think that's because the localId for the "Equivalent" expression is not in the annotations. Annotation from CMS137-v12-0-001-QMD-5-6.json (from CMS137-v12-0-001-QDM-5-6.zip starting around line 3083): But the localId is present within the related expression block as @RohitKandimalla noted (starting around line 3262). As a result, there is nothing to tie 211 back to, and coverage is impacted. |
I agree that localIds should be being emitted, and I think you're right @JPercival , that the fact that it's not being emitted for Equivalent is actually a bug. However, I think what Stan is pointing out is that the annotations aren't consistent, in that they are referencing a localId that doesn't exist. So I think there are two issues here to be addressed. |
I tagged with md impact tracking (because this is affecting coverage calculation) and with engine impact (because it impacts how annotations and localIds are being output which affects coverage calculation). |
I would think implementers of cql-to-elm are free to assign local IDs to all elements. It is a property of the Element type in the schema. |
Also related #1295 |
For fqm-execution, we also encountered the coverage calculation behavior noted in the original post in projecttacoma/fqm-execution#287. In that ticket, the third measure - CMS69 - uses a
The need for both test cases is the reason why 100% isn't achieved:
Having the localId for To address needing two test cases when using Note: fqm-execution is only for FHIR measures. The original issue in this ticket looks like it is for a QDM measure. I haven't verified that QDM measures needed both test cases like the FHIR measures do, but the behavior sounds the same. |
Hello Team,
BonnieMAT team received a help desk ticket where user is unable to achieve 100% test coverage. After investigating we found out that the ELM generated for that particular measure is including a localId property for "type": "Equivalent" when followed by a "NOT" (negation). Ideally localId should not be added as it is causing issues downstream.
Original HelpDesk ticket : BONNIEMAT-1658
Original Measure bundle exported from MAT, it contains the CQL for the measure library as well as all included libraries.
CMS137-v12-0-001-QDM-5-6.zip
CQL definition where it is used
Corresponding ELM
As we can see in the ELM, Equivalent operator is followed by a negation ( NOT ), in this case having a localID ("localId": "211") for Equivalent object is causing issues downstream.
Note: When CQL is modified to check equal condition instead of equivalent
PsychosocialVisit.id != FirstSUDEpisode.id
then the ELM generated doesn't contain a localID and hence the code coverage is not effected.Please let us know if you need any additional information, Happy to provide !!
The text was updated successfully, but these errors were encountered: