FML resolve() in Bundle

[mrunibe]

Proof-of-concept to support resolve() in FML to resolve references within a Bundle.

Related zulip discussion: https://chat.fhir.org/#narrow/channel/379173-FHIR-Mapping-Language/topic/resolve.28.29.20references.20within.20a.20Bundle/with/508251737

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 12.90%. Comparing base (d643595) to head (8daa07d).
Report is 23 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1944      +/-   ##
============================================
+ Coverage     12.89%   12.90%   +0.01%     
- Complexity    34650    34694      +44     
============================================
  Files          2300     2300              
  Lines        699797   699807      +10     
  Branches     206239   206240       +1     
============================================
+ Hits          90231    90345     +114     
+ Misses       577681   577553     -128     
- Partials      31885    31909      +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mrunibe]

I simplified the PR further by just lazy caching the references in TransformSupportServices, no longer requiring modifictions in ValidationEngine.

[grahamegrieve]

I'm suspicious of this change for two reasons - the bundle resolution code is more complicated than this, I think (more ways to resolve than the simple one I see here)

But more importantly, this is just inside bundles? I think we need to agree what the spec should say should happen with resolve(), because in some use cases for FML, resolve() is a very significant problem - I think?

[mrunibe]

I'm suspicious of this change for two reasons - the bundle resolution code is more complicated than this, I think (more ways to resolve than the simple one I see here)

I agree. @oliveregger suggested to use the mechanism from the InstanceValidator.resolveReference() instead. It's now implemented in matchbox and I have changed this PR accordingly. FML would then use the same logic as validate.

But more importantly, this is just inside bundles? I think we need to agree what the spec should say should happen with resolve(), because in some use cases for FML, resolve() is a very significant problem - I think?

Indeed the spec does not say much about resolve() except referring to FHIRPath. The example in the tutorial seems incoherent, see related zulip discussion.

Now that we use InstanceValidator.resolveReference() it should be more generic. Additionally, if we would initialize it with:

validator.setFetcher(new StandAloneValidatorFetcher(pcm, context, this));

It even resolves external resource (I have successfully tested it locally).

[grahamegrieve]

so how does this PR compare to the discussion that we had on Zulip about this issue?

[mrunibe]

so how does this PR compare to the discussion that we had on Zulip about this issue?

This PR enables resolve() on the target variable using FHIRPath which can then be used in dependent rules:

src.prac as prac -> execute(prac.resolve()) as pracResource then { ... }

Participants of the discussion agreed this syntax is valid and should work.

The Zulip discussion was also whether resolve() should be possible on the source element (like src.prac.resolve()) which was dismissed (JIRA ticket closed). Consequently, the PR does not change that.