Support Nested Lists

[Lucas0T]

IS:

Currently Torch converts the element id from the crtdl directly into fhir path which returns a list of found elements.
When handling list subelements the relation inside this list is not guaranteed.
E.g. Observation.component.intepretation and Observation.component.code would be separated in the current version.

SHOULD:

TORCH should copy elements while keeping the relationships or grouping of subelements in place.

• Build tree with each node being the fhir path to the next field.

• execute fhir path along the tree i.e. recursive copy:

  1. Extract node element with Fhir Path
  2. If node has children recursively extract them with subfhirpaths
  3. return element

Considerations: Slicing discriminators work strictly "downward" i.e. on a relative path starting at element level.

Note that its possible to have a reference resolve and on top choose the reference as normal field / include it from a different attribute.

e.g.

{
                        "attributeRef": "Encounter.diagnosis",
                        "mustHave": false,
                    },
{
                        "attributeRef": "Encounter.diagnosis.use",
                        "mustHave": false,
                    },
{
                        "attributeRef": "Encounter.diagnosis.condition",
                        "mustHave": false,
                        "linkedGroups": ["diags"]
                    }

[Lucas0T]

Old related issue #15

[Lucas0T]

Idea:

• Build tree with each node being the fhir path to the next possible branching point. (Is structure definition enough here?)
  Options:

1. Branch at every point -> easy potentially performance issues
2. Only at possible Branching points i.e. max cardinality >1: issue what is the ground truth for that structure def, base resource?

The Question is

• execute fhir path along the tree i.e. recursive copy:

  1. Extract node element with Fhir Path
  2. If node has children recursively extract them with subfhirpaths
  3. return element

Considerations: Slicing discriminators work strictly "downward" i.e. on a relative path starting at element level.