Bug/Inconsistent behavior in handling Retrieve statements when using FHIR

[rdingwell]

There is an inconsistent behavior in translating CQL to ELM when using FHIR. Take the following setup for a library that defines codes and concepts that will be used in retrieve statements for filtering.

library mCODE version '1'

using FHIR version '4.0.0'
include FHIRHelpers version '4.0.0' called FHIRHelpers

codesystem "LOINC": 'http://loinc.org'

code "ECOG performance code": '89262-0' from "LOINC" display 'ECOG Performance Status [Interpretation]
code "Karnofsky performance code": '89245-5' from "LOINC" display 'Karnofsky Performance Status [Interpretation]

concept "ECOG performance score" : { "ECOG performance code"}
concept "Karnofsky performance score" : { "Karnofsky performance code"}

Depending on how the codes and concepts are used within retrieve statements in the library will produce different elm outputs.

First consider the case that the library only contains definitions that use the codes and not the concepts that wrap them such as the following:

define "ECOG Performance":
    [Observation:  "ECOG performance code"]

define "Karnofsky Performance":
    [Observation: "Karnofsky performance code"]

The resulting translation for each of theses is the following:

{
           "name" : "ECOG Performance",
           "context" : "Patient",
           "accessLevel" : "Public",
           "expression" : {
              "dataType" : "{http://hl7.org/fhir}Observation",
              "codeProperty" : "code",
              "type" : "Retrieve",
              "codes" : {
                 "type" : "ToList",
                 "operand" : {
                    "name" : "ECOG performance code",
                    "type" : "CodeRef"
                 }
              }
           }
        }, {
           "name" : "Karnofsky Performance",
           "context" : "Patient",
           "accessLevel" : "Public",
           "expression" : {
              "dataType" : "{http://hl7.org/fhir}Observation",
              "codeProperty" : "code",
              "type" : "Retrieve",
              "codes" : {
                 "type" : "ToList",
                 "operand" : {
                    "name" : "Karnofsky performance code",
                    "type" : "CodeRef"
                 }
              }
           }
        } 

This will produce a result with warnings contained within the annotations stating that "Could not resolve membership operator for terminology target of the retrieve." There is an annotation warning for each of the statements but there is also an elm expression for each as obvious from the output.

If the statements are defined as follows with the first retrieve using a code and the second using a concept

define "ECOG Performance":
    [Observation:  "ECOG performance code"]

define "Karnofsky Performance":
    [Observation: "Karnofsky performance score"]

This results in the following elm.

{
            "name" : "ECOG Performance",
            "context" : "Patient",
            "accessLevel" : "Public",
            "expression" : {
               "dataType" : "{http://hl7.org/fhir}Observation",
               "codeProperty" : "code",
               "type" : "Retrieve",
               "codes" : {
                  "type" : "ToList",
                  "operand" : {
                     "name" : "ECOG performance code",
                     "type" : "CodeRef"
                  }
               }
            }
         }, {
            "name" : "Karnofsky Performance",
            "context" : "Patient",
            "accessLevel" : "Public",
            "expression" : {
               "dataType" : "{http://hl7.org/fhir}Observation",
               "codeProperty" : "code",
               "type" : "Retrieve",
               "codes" : {
                  "type" : "ToList",
                  "operand" : {
                     "name" : "Karnofsky performance score",
                     "type" : "ConceptRef"
                  }
               }
            }
         }

In this case there is a single warning as described above for the first statement that is still using the code for filtering in the retrieve. So concept seems to work here as a replacement for code to work around warnings.

However, if you write the same statements as follows, with the concept filtering first and the code filtering after that things get a bit odd.

define "ECOG Performance":
    [Observation:  "ECOG performance score"]

define "Karnofsky Performance":
    [Observation: "Karnofsky performance code"]

This results in the following elm.

{
            "name" : "ECOG Performance",
            "context" : "Patient",
            "accessLevel" : "Public",
            "expression" : {
               "dataType" : "{http://hl7.org/fhir}Observation",
               "codeProperty" : "code",
               "type" : "Retrieve",
               "codes" : {
                  "type" : "ToList",
                  "operand" : {
                     "name" : "ECOG performance score",
                     "type" : "ConceptRef"
                  }
               }
            }
         }, {
            "name" : "Karnofsky Performance",
            "context" : "Patient",
            "accessLevel" : "Public",
            "expression" : {
               "dataType" : "{http://hl7.org/fhir}Observation",
               "codeProperty" : "code",
               "type" : "Retrieve",
               "codes" : {
                  "type" : "ToList",
                  "operand" : {
                     "type" : "ToConcept",
                     "operand" : {
                        "name" : "Karnofsky performance code",
                        "type" : "CodeRef"
                     }
                  }
               }
            }
         }

The first thing to note is that there are no annotation warnings in this case. You can also notice that the code filtering retrieve is now converted differently, there is a ToConcept type conversion for the CodeRef contained in this example that is not included in the previous examples.

This will also effect all code base filtering in retrieves that happen after the first concept based filtering in a retrieve. The basic situation appears that using codes in a retrieve will cause warnings for all statements before using a concept in a retrieve and thereafter will not produce warnings and will have a different elm conversion.

So if we had the following statements:

define "ECOG1":
    [Observation:  "ECOG performance code"]

define "ECOG2":
    [Observation:  "ECOG performance code"]

define "ECOG3":
    [Observation:  "ECOG performance score"]

define "ECOG4":
    [Observation:  "ECOG performance code"]

define "ECOG5":
    [Observation:  "ECOG performance code"]

In this case ECOG1 and ECOG2 would produce warnings and not contain the ToConcept conversion. The statements ECOG4 and ECOG5 that appear after the concept filtering in ECOG3 will not produce warnings and will contain the ToConcept conversion.

This also raises the question about the validity of the elm that is produced if concepts are not used. Will the resulting elm that does not contain the ToConcept conversion execute as intended. I understand that there are warnings associated with the conversion but it does still produce elm that can be executed. Whether the result is as expected is another question.

[brynrhodes]

@rdingwell , thank you for the detailed reproduction, it looks like the use of the concept is instantiating a conversion that is then available (because it's cached) for use when referencing the code. The behavior is definitely inconsistent and unexpected, I will track down why the use of code doesn't work to instantiate the conversion.

[brynrhodes]

Addressed in 1.4.9-SNAPSHOT

[rdingwell]

Hey @brynrhodes , will you be doing a formal 1.4.9 release sometime soon, it is still in SNAPSHOT?

[brynrhodes]

Yes, it is still a snapshot, we are working towards a release, We are trying to address all the critical outstanding issues, and there are a few more to address. Can you give me a sense for the urgency of having a release?

[brynrhodes]

Addressed in 1.4.9 release