You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While looking at the ELM of CMS130FHIR-v0.1.000 from the January 2024 Connectathon bundles, we noticed a peculiar translation of a retrieve on MedicationRequest.
The AdvancedIllnessandFrailty 1.8.000 CQL Library has the following define statement:
define "Has Dementia Medications in Year Before or During Measurement Period":
exists (( ([MedicationRequest: "Dementia Medications"]).isMedicationActive()) DementiaMedication
where DementiaMedication.doNotPerform is not true and
CMD."MedicationRequestPeriod" ( DementiaMedication ) overlaps day of Interval[start of "Measurement Period" - 1 year,
end of "Measurement Period"]
In this define statement the [MedicationRequest: "Dementia Medications"] appears to be translated into ELM with extra logic to handle MedicationRequests which reference a Medication resource to grab the actual code for the medication.
[MedicationRequest: "Dementia Medications"]
union ([MedicationRequest] MR
with [Medication] M
such that M.id = Last(Split(MR.medication.reference, '/')) and code in "Dementia Medications")
There is a bit of a bug here that would prevent it from working in the case of referencing a Medication. The InValueSet expression seen towards the end of the ELM snippet compares against a Property expression that does not have a scope or source defined. This would not return any value or error out and will not be able to compare the Medication type. This should have a scope of M. Making the equivalent CQL M.code in "Dementia Medication"
There is also a concern with the efficiency of this logic. It currently is asking for EVERY MedicationRequest and with each MedicationRequest it is asking for EVERY Medication and then looking for the one with the matching id. Since we know the referenced id it could be used to directly fetch the Medication resource with the id field of the Retrieve expression. There doesn't appear to be a way do do this in CQL at the moment.
The text was updated successfully, but these errors were encountered:
Regarding the efficiency, there is a feature of analyzeDataRequirements that will establish relationships between data requirements that can be used to convert this type of retrieve into an include. There's work to be done in the provider layer though to handle this type of request (since it wouldn't be a separate request for Medication, the related resources would come back in the same bundle and the provider layer needs to be able to separate the bundled resources out into the different retrieves).
While looking at the ELM of CMS130FHIR-v0.1.000 from the January 2024 Connectathon bundles, we noticed a peculiar translation of a retrieve on
MedicationRequest
.The AdvancedIllnessandFrailty 1.8.000 CQL Library has the following define statement:
In this define statement the
[MedicationRequest: "Dementia Medications"]
appears to be translated into ELM with extra logic to handle MedicationRequests which reference a Medication resource to grab the actual code for the medication.In CQL this looks like:
There is a bit of a bug here that would prevent it from working in the case of referencing a Medication. The InValueSet expression seen towards the end of the ELM snippet compares against a Property expression that does not have a
scope
orsource
defined. This would not return any value or error out and will not be able to compare the Medication type. This should have ascope
ofM
. Making the equivalent CQLM.code in "Dementia Medication"
There is also a concern with the efficiency of this logic. It currently is asking for EVERY
MedicationRequest
and with eachMedicationRequest
it is asking for EVERYMedication
and then looking for the one with the matchingid
. Since we know the referencedid
it could be used to directly fetch theMedication
resource with theid
field of the Retrieve expression. There doesn't appear to be a way do do this in CQL at the moment.The text was updated successfully, but these errors were encountered: