ModelInfo issue with MedicationRequest

[chubert-sb]

A issue occurs when a filter is used for a MedicationRequest profile retrieval in QI-Core. The MedicationRequest resource cannot be found even though the test case JSON contains the MedicationRequest resource, relevant meta.profile and uses the medication element either as a CodeableConcept or referenced Medication resource. For example, when provided the following CQL and correct test case JSON, the case passes:

CQL

define "Has ACEI or ARB or ARNI Ordered":
exists ( 
  [MedicationRequest] ACEIOrARBOrARNIOrdered
    where (
      ( ACEIOrARBOrARNIOrdered.medication as Concept ) in "ACE Inhibitor or ARB or ARNI"
        or ( ACEIOrARBOrARNIOrdered.medication as Reference ).reference.getId() in ( [Medication: "ACE Inhibitor or ARB or ARNI"] ACEIOrARBOrARNI return ACEIOrARBOrARNI.id )
         )
      and ACEIOrARBOrARNIOrdered.isOrderedDuringHeartFailureOutpatientEncounter()
           )

However, when the CQL is updated to use the primary code path for the MedicationRequest, the test case that was passing now fails:

updated CQL

define "Has ACEI or ARB or ARNI Ordered":
exists ( 
  [MedicationRequest: "ACE Inhibitor or ARB or ARNI"] ACEIOrARBOrARNIOrdered
    where ACEIOrARBOrARNIOrdered.isOrderedDuringHeartFailureOutpatientEncounter()
         ) 

Based on a brief review of the QI-Core 4.1.1 Model Info file, I'm speculating that the issue is stemming from it. The primary code path for MedicationRequest is provided as 'medication', but medication is a choice type:

<typeInfo xsi:type="ClassInfo" baseType="QICore.DomainResource" namespace="QICore" name="MedicationRequest" identifier="http://hl7.org/fhir/us/qicore/StructureDefinition/qicore-medicationrequest" label="MedicationRequest" retrievable="true" primaryCodePath="medication">
.....
  <element name="medication" target="FHIRHelpers.ToValue(%value)" description="..." mustSupport="true">
     <elementTypeSpecifier xsi:type="ChoiceTypeSpecifier">
        <choice namespace="System" name="Concept" xsi:type="NamedTypeSpecifier"/>
        <choice namespace="QICore" name="Reference" xsi:type="NamedTypeSpecifier"/>
     </elementTypeSpecifier>
     <binding description="Prescribable medications" strength="Extensible"/>
  </element> 

[brynrhodes]

The terminology target must be code-valued, so when it is used with the medication element, that resolves to the CodeableConcept choice, and there is no expectation that the retrieve would apply through the reference choice. In other words, when using the terminology target of the retrieve if the MedicationRequest.medication element is a reference, it would not be addressable through the retrieve. I've added a test to validate the MedicationRequest with a terminology target translates with the codeableconcept choice.

[JSRankins]

@brynrhodes, I understand your explanation above. The patterns page for Medication ordered uses this same approach - asserting medication as a CodeableConcept. But this makes me wonder if that limitation should be forced at the profile level, since the current profile (for QI-Core 4.1.1 and 5.0.0) allows the medication to be either a medicationCodeableConcept OR a medicationReference. Based on the profile, a compliant instance of MedicationRequest could be provided with a medicationReference, but that creates an execution issue. Is the patterns page just a recommendation or a requirement? Should the patterns page be addressing medication as either a medicationCodeableConcept OR a medicationReference? Thoughts?

[brynrhodes]

@JSRankins , it would make sense to address this in the patterns page, but I'm hesitant to enforce it at the profile level since it is still possible to address (and we'll need to be able to since there are systems that do both). I'll add this as an item to address in the patterns.

[jenseeman]

Reference: https://oncprojectracking.healthit.gov/support/browse/CQLIT-373

[brynrhodes]

Proposed update to the patterns to address retrieving when medication requests are represented as references:

library MedicationRequestTest

using QICore version '4.1.1'

include FHIRHelpers version '4.2.000'
include QICoreCommon version '1.3.000'

valueset "Antithrombotic Therapy": 'http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1110.62'

context Patient

define "Antithrombotic Therapy at Discharge":
  ["MedicationRequest": medication in "Antithrombotic Therapy"] Antithrombotic
    where (Antithrombotic.isCommunity() or Antithrombotic.isDischarge())
      and Antithrombotic.status in { 'active', 'completed' }
      and Antithrombotic.intent = 'order'

// Proposed update to the pattern to address medications represented as references: https://github.com/cqframework/CQL-Formatting-and-Usage-Wiki/wiki/Authoring-Patterns---QICore-v4.1.1#medication-ordered-as-a-reference

define "Antithrombotic Therapy at Discharge (by Reference)":
  ["MedicationRequest"] Antithrombotic
    where Antithrombotic.medication().code in "Antithrombotic Therapy" 
      and (Antithrombotic.isCommunity() or Antithrombotic.isDischarge())
      and Antithrombotic.status in { 'active', 'completed' }
      and Antithrombotic.intent = 'order'

define fluent function medication(medicationRequest MedicationRequest):
  singleton from ([Medication: id = medicationRequest.medication.reference.getId()])

define fluent function medicationAlternate(medicationRequest MedicationRequest):
  singleton from ([Medication] M where M.id = medicationRequest.medication.reference.getId())

We should investigate whether it would make sense to support this more succinctly with the .resolve() function, and potentially as an implicit union by the translator when the terminology path is a choice of representations.

[brynrhodes]

It is possible to support this in the translator, however, full support for this capability will require additional information about the reference to be captured in the ModelInfo. The initial exploratory implementation only supports the MedicationRequest scenario, full support is in development.

[brynrhodes]

Included in release 3.2.0

[birick1]

Post 3.2.0 Issue

I tested Stan's example CQL by converting to ELM with translator version 3.4.0-SNAPSHOT. From there, I reproduced the reported error in the engine and worked to track down the root cause.

Root Cause (Translator version 3.4.0)

I believe the root cause is that the ELM being produced in version 3.4.0 is not correct.

The CQL at issue is:

When looking at the ELM, medication.reference needs to be converted to a CQL type (System.string) for the Split operator (red outline). In other words, there should be a .value and ToValue in the clause to handle the type conversion for the Split operator. Below is the ELM generated in 3.4.0 that results in an engine error:

Expected ELM

To get an expected version of the ELM, I created a CQL test case to replicate the operation sequence being performed.

Translating to ELM using v3.4.0, gives an expected form of ELM including a value and ToValue call. This output runs as expected in the engine.

Reference vs CodeableConcept choice

The CodeableConcept choice does not seem to be handled.

InValueSet Issue

Looking at the valueset part of the produced ELM, the code section does not have a scope or source property. The lack of scope is expected to lead to a engine error.