feature request: async support for FhirPath resolve()

[darena-antonw]

Is your feature request related to a problem? Please describe.

I would like the fhir path evaluation to resolve elements from a database / http call.

This is currently possible with: FhirEvaluationContext.ElementResolver

However the caveat is that I would have to introduce blocking in to my application, as the delegate can not be async.

Describe the solution you'd like

• new property AsyncElementResolver on FhirEvaluationContext of type Func<string,Task<ITypedElement>>
• new method Compile(string fhirPath, bool async) that evaluates to CompiledAsyncExpression
• new delegate type public delegate Task<IEnumerable<ITypedElement>> CompiledAsyncExpression(ITypedElement root, EvaluationContext ctx);

so in the end I can do the following:

var expression = compiler.Compile("entry.resource.ofType(MedicationRequest).medication.resolve().id", true);
var result = await expression(
    bundle,
    new FhirEvaluationContext
    {
        AsyncElementResolver = async (id) =>
        {
            // call to db or http
            return ...
        }
    }
);

Describe alternatives you've considered

it's possible with blocking via .GetAwaiter().GetResult()

Additional context

this was discovered during connectathon cds hooks testing.

[ewoutkramer]

This means we need to make the whole FP runtime async, since, as we know, async spreads. We've seen in the validator that this will be detrimental for performance for components that are mostly sync (like most FP is).

For the validator we decided that the cost for going async was not worth the cost of performance since validation is mostly compute, sync work, and I am leaning towards the same thing here. In fact, if we make FP async, then the validator needs to be async, which is really not what I want.

[darena-antonw]

@ewoutkramer think there is a reasonable solutions to this? or not going to do it?

There are work arounds, we can deconstruct the FP manually in to steps and evaluate the steps separately with custom logic for .resolve() like:

entry.resource.ofType(MedicationRequest).medication.resolve().id => ["entry.resource.ofType(MedicationRequest).medication", "resolve()", "id"]

feels a bit janky but it can be a wrapper around the current solution, don't know if you're willing to bake that in to the library.