Support for `candidateExpression` and a question about resource server queries

We are using @aehrc/smart-forms-renderer and would like to make use of the SDC candidateExpression extension. One of our use cases is to allow the user of the questionnaire to select diagnoses of the patient, so the candidates come from the patient record rather than from a value set.

We are happy to contribute to this project and open a merge request for candidateExpression support, if that is something you would welcome.

Before starting, we would like to check a few architectural points with you, so that we don't build something you would not want. :-)

What we found in the code suggests the work is less about the extension itself and more about how queries are routed.

The renderer is capable of making external requests through the renderer query client, and useTerminologyServerQuery shows how server-backed queries can be routed through the query provider. However, as far as we can tell, all resolved queries currently go to the terminology server. We did not find a path that reaches a resource server.

Questions

1. Is a resource server equivalent planned?

Do you have plans for something similar to useTerminologyServerQuery for the resource server? If not, is this something we could introduce as part of the candidateExpression work, or would you prefer to keep data access out of the renderer and have the host application supply resolved data instead?

2. Are there routing rules for x-fhir-query?

A candidateExpression using application/x-fhir-query may target either server, depending on the query itself:

Are there existing routing rules for this, or a convention we should follow?

3. Does this apply beyond candidateExpression?

Reading the specification, the routing question appears to be a property of the expression language rather than of any single extension. Every extension that permits application/x-fhir-query can address either server, which would include variable, initialExpression, calculatedExpression, answerExpression, enableWhenExpression, itemPopulationContext and contextExpression.

If that reading holds, the routing decision would belong in one shared place, and candidateExpression would simply be the extension where we happened to notice it. Does that match how you see it?

Start by reading the renderer query client and useTerminologyServerQuery, then trace how resolved queries are routed. Compare the existing path with the candidateExpression and x-fhir-query cases described here. This issue is not ready for implementation until maintainers decide whether resource-server routing belongs in the renderer and define the shared routing rules.