Stream: cql
Topic: CQL Parameters
Corey Sanders (Feb 04 2021 at 22:05):
We are trying to figure out the recommended way to render parameter data on Library resources that will be used by a Measure and then how to retrieve them for display on an application configuration screen. Is it true that each Library independently manages the definition of its own parameter set? And to determine which parameters to configure for a Measure we should walk the entire dependency tree? As an alternative, we've considered forcing users to declare all the parameters used by the measure in the "primary" library resource that is directly linked to the Measure.
I remember a similar conversation coming up at connectathon around ValueSets and the data-requirements operation. There was concern that when mining the ValueSets that might be used by a measure based on the depends-on relationships in all the Libraries in the dependency graph, then you would potentially be identifying more ValueSets than will actually be used at runtime. My understanding is that the current state-of-the-art for data-requirements uses the greedy, slightly dumb approach.
Speaking of parameters, it isn't clear what we would do in the Java engine if two underlying libraries had the same parameter name defined with potentially different semantics. Right now, all parameters are passed in via a global namespace. Has there been any consideration for how to deal with namespaced parameters?
JP (Feb 04 2021 at 23:32):
Is it true that each Library independently manages the definition of its own parameter set?
Yes
And to determine which parameters to configure for a Measure we should walk the entire dependency tree?
Yes, and that's the intent of the $refresh-generated-content operation
My understanding is that the current state-of-the-art for data-requirements uses the greedy, slightly dumb approach.
Yes, and the intent is for the analysis to be as "static" as possible, even if it picks up ValueSets that may not be used for a specific execution. Bryn can elaborate on that a bit more, but my understanding is that, in general, pruning the data-requirements for the evaluation of a specific expression in a set of libraries is a non-goal at this point (a lot of permissions issues arise when going down this path - If a cql-based decision support service is deployed it's commonly the case that it must be pre-approved for a set of resources and can't elevate permissions as needed, so you want the whole possible set up front - so you need additional context such as a PlanDefinition or Measure to determine which expressions are used).
Right now, all parameters are passed in via a global namespace. Has there been any consideration for how to deal with namespaced parameters?
Yes, but we've not come to any specific resolutions that I can remember. The spec leaves this behavior undefined, so there's currently no "right" solution.
JP (Feb 04 2021 at 23:53):
Whoops, I meant $data-requirements operation.
Bryn Rhodes (Feb 05 2021 at 02:22):
We are in the process of writing tooling now that computes the "effective" data requirements, parameters, and terminology usage of a Measure based on dependencies traceable from expressions referenced by the Measure. That information will be persisted in the form of extensions in the measure, see the CQFMComputableMeasure for what that will look like, on track to ballot this May.
Corey Sanders (Feb 05 2021 at 14:32):
Thanks, guys. Is the "effective requirements" tooling you are developing in the open? Maybe in the cqf-tooling project? I'm not sure if this is an area where my team can assist, but we'd be happy to look into it.
Bryn Rhodes (Feb 05 2021 at 14:37):
Yes, the code will be extending the CqlProcessor in the CQF-Tooling: https://github.com/cqframework/cqf-tooling/blob/develop/src/main/java/org/opencds/cqf/tooling/processor/CqlProcessor.java
Last updated: Apr 12 2022 at 19:14 UTC
