Support QI Core negation w/ notDoneValueSet extension

[cmoesel]

Asserting that something was not done can be challenging in FHIR. It's relatively easy to say that a specific thing (with a specific code) wasn't done, but harder to say that a general category of things was not done (e.g., "I did not do any heart procedures").

The QICore team has proposed that this can be said by using a special extension to indicate a valueset that represents what was not done. In the ELM, this comes across as a retrieve property. While supporting this behavior would ideally be done in the data source (i.e., cql-exec-fhir), that is not possible due to the current architecture of cql-execution. Instead, we'll likely had to build special support into cql-execution.

For more details, see: https://github.com/cqframework/CQL-Formatting-and-Usage-Wiki/tree/master/Source/Cooking%20With%20CQL/67

[hossenlopp]

This is something thats now coming to fruition with more conversion of QDM measures to QICore. In QICore 4.1.1 Communication.reasonCode.notDoneValueSet and QICore 5.0.0 Communication.topic.notDoneValueSet a url to a ValueSet may be provided in the patient data.

In CQL/ELM when this is used, it results a search for the extension which returns the canonical ValueSet URL which is then passed into FHIRHelpers.ToValueSet which simply creates an empty CQL system ValueSet with the id being the URL. This constructed "ValueSet" is then used as a valuesetExpression in InValueSet.

cql-execution currently does not know how to handle valuesetExpression. It is also unclear how it should work when the "ValueSet" passed in only has an id. There are a few questions we need to answer to be able to properly implement this.

1. Should this valuesetExpression usage mean that we should expect only an id and the engine will need to resolve the actual ValueSet to run the InValueSet operation?
2. What should happen when the ValueSet cannot be resolved in the valueset db (or other method) that was passed in when execution was started? Return null or throw an error?
3. Should we expect the cql-execution user to pull ValueSets referenced by patient data into the valueset db before executing?
4. OR should we expect the PatientSource to be able to provide these patient data referenced ValueSets?

[mgramigna]

FYI, see https://github.com/cqframework/clinical_quality_language/issues/1153#issuecomment-1572772833

[JSRankins]

FYI - I have experimented to see if given the following caveats a patient would be included in a measure population, and the patient is:

• CQL library using base FHIR and the notDoneValueSet extension for Communication
• a corresponding patient bundle that leverages the respective base FHIR Communication resource and asserts the notDoneValueSet extension with the respective value set URL

I could be wrong about this (open to conversation), but I'm thinking that nothing would need to be expanded, since the data provider is asserting through the provision of the value set URL in the extension that nothing in the value set was performed, ordered, etc. depending upon the resource in use.

So maybe this is an ELM issue when using something like QI-Core?

[mgramigna]

@JSRankins I do think that in the specific case of the syntax brought up by https://github.com/projecttacoma/fqm-execution/issues/222, the ValueSet would need to be expanded since that syntax is checking if a specific direct reference code exists within the expansion of the ValueSet referenced by that qicore-notDoneValueSet extension.

I do also think there might still be an ELM issue with doing this on reasonCode for a Communication. I just posted an update here: https://github.com/cqframework/clinical_quality_language/issues/1168#issuecomment-1607599666

[JSRankins]

@mgramigna - Just now seeing this, since I was out for a little while due to surgery. Regarding...

@JSRankins I do think that in the specific case of the syntax brought up by projecttacoma/fqm-execution#222, the ValueSet would need to be expanded since that syntax is checking if a specific direct reference code exists within the expansion of the ValueSet referenced by that qicore-notDoneValueSet extension.

I do also think there might still be an ELM issue with doing this on reasonCode for a Communication. I just posted an update here: cqframework/clinical_quality_language#1168 (comment)

I'm not sure I understand your comment. The following is my understanding for the use of the notDoneValueSet extension: none of the codes for the value set are present in the data for the related FHIR resource. To cite what @cmoesel stated earlier:

Asserting that something was not done can be challenging in FHIR. It's relatively easy to say that a specific thing (with a specific code) wasn't done, but harder to say that a general category of things was not done (e.g., "I did not do any heart procedures")

Putting a single code in the JSON from the value set does not meet the notDoneValueSet requirement, especially for those value sets that have more than one code. I assume an argument could be made for only including a code from the value set if the value set only had one code, but that's a different issue and one I'm not sure should be solved, since it would encourage an anti-pattern.

[p9g]

see also https://github.com/cqframework/CQL-Formatting-and-Usage-Wiki/wiki/Authoring-Patterns---QICore-v4.1.1#communication-not-done

[JSRankins]

Good afternoon. We wanted to check on the status of this ticket. We are concerned that the discussion related to Communication.reasonCode may have overshadowed the broader issue related to notDoneValueSet extension. CommunicationNotDone had a particular issue related to cardinality issue for its associated primary code path. However, that should be divorced from the bigger issue related to notDonevValueSet support, which is much bigger.