Transitive reference to contained resources

Question

We have a query regarding referencing resources contaiend in another. Assume the scenario,

ResourceA
  |- contains
       |- ResourceB
       |- ResourceC

And ResourceB has a reference to ResourceC.

In above case, is it mandatory for ResourceA to contain direct reference to both Resource B and C? Or is it suifficient for A to refer to B, as there is a tarnsitive reference to C already (A->B->C)?

Our intepretation of the FHIR spec is latter (i.e. transitive reference is sufficient), reading below statement from https://www.hl7.org/fhir/references.html#contained

A contained resource SHALL only be included in a resource if something in that resource (potentially another contained resource) has a reference to it.

However there is also another note under same documentation which is causing us a confusion, mainly as the example only demonstrates reference from current().

Implementation Note: Contained resources are still a reference rather than being inlined directly into the element that is the reference (e.g. "custodian" above) to ensure that a single approach to resolving resource references can be used. Though direct containment would seem simpler, it would still be necessary to support internal references where the same contained resource is referenced more than once. In the end, all that it would achieve is creating additional options in the syntax. For users using XPath to process the resource, the following XPath fragment resolves the internal reference:

ancestor::f:[not(parent::f:)]/f:contained/*[@id=substring-after(current()/f:reference/@value, '#')]

Could you please help clarify this. Thanks.

Answer 1

Your interpretation is definitely correct.

I believe the xpath expression is fine, substring-after(current()/f:reference/@value, '#') extracts the Reference.reference.value field from the current node and strips the leading #. This is relative to the reference field, not the contained resource or container. The path ancestor::f:*[not(parent::f:*)] can traverse multiple steps up the ancestors to find the contained resources so it is indifferent to whether they're in the same resource or a container. It uses the constraint that contained resources can't contain more contained resources, otherwise it could be ambiguous.

Answer 2

The intention is that what you're doing should be allowed. However, the way the invariant is currently defined, it doesn't work - in either XPath or FHIRPath (the latter being more important). To be honest, we haven't figured out how to fully express it properly because what we're looking for is that there is a reference chain from the containing resource to all contained resources or a reference chain from the contained resources to the containing resource. There's no simple FHIRPath or XPath expression that allows for a recursive checking of this. (XPath's 'ancestor' only works on the instance, not the logical reference hierarchy.) So - what you're doing is technically non-conformant with R4. It (hopefully) won't be non-conformant in R5. And it's certainly in the spirit of what we'd intended to allow in R4...