InValueSet on non-Code types
See original GitHub issueBoth of the following expressions seem to be accepted by the CQL2ELM translator, where C is an alias for a FHIR 3.0.0 Condition:
C.category.coding[0].code in "Problem"
C.category.coding[0] in "Problem"
Specifically, they are translated into an InValueSet node, where the immediate child is a FHIRHelpers.toString and a FHIRHelpers.toCode call respectively. The InValueSet definition in clinicalexpression.xsd does seem to allow any Expression:
<xs:complexType name="InValueSet">
<xs:annotation>
<xs:documentation>The InValueSet operator returns true if the given code is in the given value set.
Note that this operator explicitly requires a ValueSetRef as its valueset argument. This allows for both static analysis of the value set references within an artifact, as well as the implementation of valueset membership by the target environment as a service call to a terminology server, if desired.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="Expression">
<xs:sequence>
<xs:element name="code" type="Expression"/>
<xs:element name="valueset" type="ValueSetRef"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Passing any arbitrary expression doesn’t make sense to me though. For example, asking if a DateTime is in a valueset would be nonsensical.
The July 2017 CQL specification indicates that InValueSetRef “Tests a string, code, or concept for membership in a valueset”.
I’m basically looking for clarification of the expected semantics here. If I simply use the code ID String should the InValueSet node return “true” if it is in the valueset for any code system? Alternatively, is this an oversight in the spec and/or the CQL2ELM translator? Perhaps CQL2ELM actually should fail in this instance and the spec just hasn’t been updated accordingly.
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
@WilliamParker After discussion with the CDS WG, the comment was resolved to indicate that a run-time error is the best behavior because attempting to use a string overload with a value set that contains multiple code systems is ambiguous.
The former, the determination can be made entirely within the context of the In evaluation.