RetrieveEvaluator doesnt pass on valueset version to DataProvider/RetrieveProvider
The retrieve evaluator has access to the valueset version when it resolves the valuesetRef here: https://github.com/cqframework/clinical_quality_language/blob/dfafdb933f23ab54ce750c4ed1d6d1bf910e9bed/Src/java/engine/src/main/java/org/opencds/cqf/cql/engine/elm/executing/RetrieveEvaluator.java#L46-L47
As that code shows, it then extracts ONLY the id when passed to the DataProvider below: https://github.com/cqframework/clinical_quality_language/blob/dfafdb933f23ab54ce750c4ed1d6d1bf910e9bed/Src/java/engine/src/main/java/org/opencds/cqf/cql/engine/elm/executing/RetrieveEvaluator.java#L76-L88
This leads to a situation where it is ambiguous what version of the valueset is to be used by the retreive/data provider.
It is NOT ambigious when referenced as part of an expression: https://github.com/cqframework/clinical_quality_language/blob/542c919aa271fcb393be2b803814355763ab7633/Src/java/engine/src/main/java/org/opencds/cqf/cql/engine/elm/executing/InValueSetEvaluator.java#L30-L52
It seems the simplest solution would be to pass the ValueSet object in place of the valuesetId string, the retreiveprovider can strip it down to just the id if that is desired.
Yes. This is a change we'd like to the DataProvider API.
My current thinking on this is to convert the long list of method arguments into a RetrieveParams object:
class RetrieveParams {
get/set context,
get/set contextPath,
etc..
}
List<Object> retrieve(RetrieveParams params);
Same for the terminology where applicable. That will make it easier to expand and/or modify the parameters going forward, and to add a batch/multi retrieve overload:
List<List<Object>> retrieve(List<RetrieveParams> params);
Probably wouldn't literally use a list of lists. That's just conceptual. But the point is that we could batch data requests to the underlying platform for fewer round-trips.
Being able to batch those could really benefit my use case's performance, I like that a lot.