FHIR Chat · ValueSet Typing · cql

Stream: cql

Topic: ValueSet Typing

---

Michael Ryan (Jan 28 2021 at 20:25):

Hi all,
We are running into an execution issue when attempting to pass value sets into functions, and would like to see if anyone has any input on our current predicament.

I've attached a Word document with screenshots; references below.
Value-Set-Testing-Examples.pdf

Current specs:
cql-execution v2.1.0
cql-exex-fhir v1.5.0
cql v1.4.9

Intellisense seems to think that the return of a value set should be a List<System.Code>, see Figures 1 & 2.

However, when executing the same CQL from Figure 1, we are left with a return consisting of an array of "oid", "version", and "codes". See Figure 3.

This is causing issues when calling value sets from functions where the value set is a parameter with a type of List<System.Code>, as seen in Figure 4.

The elm builds just fine for the code found in Figure 4, but will not execute.

However, the same code but with an explicit call to “URI”, runs just fine and as expected. Refer to Figure 5.

So, it seems that there’s a discrepancy with typing for both IntelliSense and cql-to-elm 1.4.9, as compared to v2.1.0 of the engine.

Is there a suggested workaround or solution that would allow us to pass value sets as function parameters?

Also tagging in @Bryn Rhodes .

Thanks in advance,
Michael

Bryn Rhodes (Jan 30 2021 at 17:12):

Hmm.... that seems like it should work, but I'm more familiar with the Java-based engine than with the JavaScript one. Have you tried a focused repro in the Atom plugin?

Brian (Feb 18 2021 at 17:10):

Bryn - problems actually start with ELM generation and proceed from there. Here's a minimal example:

CQL:
image.png

ELM generated for "Test1" -- notice the "InValueSet" type:
image.png

ELM generated for "Test2" -- notice the "In" type
image.png

Bryn Rhodes (Feb 18 2021 at 17:52):

That's the correct ELM generation for that pattern in CQL 1.4. The translator explicitly detects ValueSetRef when used with In to output an InValueSet, this is to ensure that the engines understand when they're being asked to do value set membership so they can pass it to a terminology service to perform.

Bryn Rhodes (Feb 18 2021 at 17:53):

Calling it in a function like that results in a direct evaluation of a ValueSetRef, which my guess is that is not supported by the JavaScript engine. Tagging @Chris Moesel for thoughts here?

Chris Moesel (Feb 18 2021 at 18:14):

Correct -- that JavaScript engine does not yet support that. In fact, I thought that the ability to pass value set references around as function arguments wasn't introduced until CQL 1.5. Was it actually introduced in CQL 1.4? Is it normative?

Chris Moesel (Feb 18 2021 at 18:16):

Also, sorry I did not notice this thread until now...

Bryn Rhodes (Feb 18 2021 at 18:33):

Passing ValueSetRefs as arguments is allowed in 1.4 (and all versions, really, it's always been a possibility), but it is discouraged since it is effectively asking the engine to perform a value set expansion at that point.

Bryn Rhodes (Feb 18 2021 at 18:33):

In 1.5 we introduced ValueSet as a first class type (along with CodeSystem) so that you could pass them by reference and avoid the expansion.

Bryn Rhodes (Feb 18 2021 at 18:34):

It still has the significant downside that it inhibits static analysis of data requirements though.

Chris Moesel (Feb 18 2021 at 18:36):

Ah right. That's what I was thinking of in 1.5. ("ValueSet as a first class type"). As for supporting ValueSetRefs as arguments to functions (requiring expansion), I'd have to look at that more closely to determine how difficult (or not) it would be to support it in the JS engine.

Bryn Rhodes (Feb 18 2021 at 18:44):

Seems worthy of a specific CQL capability: https://github.com/cqframework/clinical_quality_language/issues/602

Brian (Feb 18 2021 at 19:22):

@Bryn Rhodes so Test1 is correct in ELM, but Test2 in the example is using the "In" type so it is interpreted as a List In(https://cql.hl7.org/09-b-cqlreference.html#in-1) rather than a ValueSet "In"(https://cql.hl7.org/09-b-cqlreference.html#in-valueset). Consequently in Test2, care has to be made to normalize valueset comparisons as list comparisons.

Provided the ELM is changed to be "InValueSet" for both Test1 and Test2, the change in the CQL engine is straightforward. Just need a check for OperandRef and an exec to resolve. I thought about doing a pull request, but prob not worthwhile because of the CQL 1.5 changes coming.

It's also worth mentioning that since the v1.5.1 cql-to-elm transpiler already implements System.Valueset, but the engine doesn't, this scenario simply doesn't work on latest releases. Should the v1.5.0 and v1.5.1 cql-to-elm and corresponding packages be marked as betas?

Bryn Rhodes (Feb 18 2021 at 19:24):

There is a 1.5.1 translator release, but it is not a complete implementation of 1.5 support (specifically, support for trial-use capabilities is still being finalized)

Brian (Feb 18 2021 at 19:32):

Right. Folks may not realize this is a breaking change from v1.4 to v1.5, the Atom extension is already using it, and CQL written in Atom against it won't run in the engine.

https://github.com/cqframework/atom_cql_support/blob/master/package.json
image.png

Bryn Rhodes (Feb 18 2021 at 20:10):

I don't see that as a breaking change from the perspective of the language. To get the new capability you have to use the newly defined terminology types, so the library as written would still translate the same way (using a ValueSetRef) in 1.5. That particular capability of 1.4 is not supported by the JavaScript engine, but it's not a breaking change in the language, right?

Bill Baar (Jun 09 2021 at 16:15):

Tagging @Michael Ryan

I'm still stuck on a solution. I have this code:

define function "VS Cast Function"(VSet List<System.Code>):
( ( cast { "VSet", 1 }[0]as Tuple {
codes List<System.Code>,
oid System.String,
version System.String
}
).codes ) VSetCodes
return System.Code { code: VSetCodes.code, system: VSetCodes.system }

And we've revised it to this:

define function "VS Cast Function"(VSet System.ValueSet):
( ( cast { "VSet", 1 }[0]as Tuple {
codes System.ValueSet,
oid System.String,
version System.String
}
).codes ) VSetCodes
return System.Code { code: VSetCodes.code, system: VSetCodes.system }

The fellow next to me gets now errors but I am stuck with this message: Member code not found for type System.ValueSet. We're both using Atom, CQL 1.5 and FHIR 4.0.1 and the code came from https://github.com/cqframework/ecqm-content-r4-2021. The solution suggested here is to change the ELM to InValueSet?

Michael Ryan (Jun 09 2021 at 17:58):

Bill,

I tried to mock up what I think should be your solution, it requires the below modification to the Claims library function "Medical Claims With Diagnosis":
image.png

A caveat being that I cannot test this in my environment, which is why we created the "VS Cast Function" in the first place.

You should also modify NCQA_AdvancedIllnessandFrailty to:

1. Comment out "Advanced Illness ValueSet" definition.

2. Replace all instances of "Advanced Illness ValueSet" with "Advanced Illness".

I think that would work, but again I cannot verify.

@Bryn Rhodes and @Brian feel free to weigh in or correct my response.

Thanks,
Michael

Vasyl Herman (Jun 17 2021 at 17:27):

Hi, @Michael Ryan
I did modification to the Claims library "Medical Claims With Diagnosis" as you are suggesting:
image.png
Then modified NCQA_AdvencedIllnessandFrailty. Unfortunately it doesn't work:
image.png
I have got an Could not resolve call to operator Medical Claims With Diagnosis with signature (list<FHIR.Claim>,System.ValueSet).

Vasyl Herman (Jun 17 2021 at 17:36):

Still no support for JS Engine? or should work now?

---

Last updated: Apr 12 2022 at 19:14 UTC