Use of Retrieve and Query in a Parameter
See original GitHub issueThe expression.xsd
file describes a ParameterDef
as taking a possible default
attribute, which is defined as an arbitrary expression
. Things like
parameter IntParameter default 0
parameter DateTimeParameter default DateTime(2018, 1, 1, 0, 0, 0)
make enough sense, but the spec doesn’t seem to imply that a query or retrieve wouldn’t be acceptable. At least, they seem permissible to the compiler:
library Query version '1'
using FHIR version '3.0.0'
include FHIRHelpers called FHIRHelpers
parameter RetrieveParameter default [Condition]
parameter QueryParameter List<FHIR.Condition> default ([Condition] C where C.clinicalStatus = 'active')
context Patient
define GetRetrieveParameter: RetrieveParameter
define GetQueryParameter: QueryParameter
RetrieveParameter
appears to compile without any warning. QueryParameter
however, throws “Internal translator error” annotations starting at the default value, but still seems to compile into an AST just fine. Interestingly, if the type is removed from QueryParameter
, the query still compiles as well as if it was there, but another “semantic” annotation error is thrown saying that the compiler “Could not determine parameter type for parameter QueryParameter”, which seems anomalous since the AST appears to have gotten all the correct type information in the node resultTypeSpecifiers
.
The big question is that since parameters have no notion of their Context
, (assuming a Retrieve in a parameter is acceptable) it would seem we would only know whether it should pull all resources for one patient, or for all patients based on where the parameter is accessed. I suppose this would mean a single parameter could have two different meanings depending not on the way the value expression is declared, but depending on where that value expression is evaluated.
Since it also seems that parameters can reference previously defined parameters in their default values, this would seem to imply parameters would have to lazily evaluate, since their values in some instances are dependent on the calling context.
What are some of the expected semantics of Retrieves and Queries in parameter default values, and how should those expected to be evaluated against differing Contexts?
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (3 by maintainers)
Thanks for the response @cmoesel. I can’t personally think of a case where using a
retrieve
in a default value expression would be necessary, or at least any more desirable than the approach you lay out. My main concern was whether an implementation would have to support such expressions. If we don’t have to, then as you say, it’ll remove a major implementation concern.If @brynrhodes confirms your assumption, it might help to log a clarifying issue to STU that requests updated doc stating parameters’ default values can only be constructed from static values, or to perhaps even to log an issue to the CQL-to-ELM compiler that explicitly rejects
retrieve
in a parameter (just a suggestion on that one though, open to more discussion).That’s a great question, and a great analysis of the implications of having retrieves as default parameter values. @brynrhodes should confirm, but I don’t think we ever intended for retrieves to be used as default values. While the specification is not clear about this, I think that default parameter values are intended to be static values, with perhaps the exception of the system functions:
Today()
andNow()
.Is there a strong use case for using a retrieve as a default value? As you noted, supporting such a thing would introduce significant implementation burden. I believe that you could accomplish the same thing via other means. For example, see below for an alternate approach to accomplishing what you described above:
This approach works today (I was able to successfully compile it without errors).