New Results Structure

[patrickskowronekdkfz]

As mentioned in Issue #280 , we are considering changes to the results structure to improve processing efficiency and compatibility.

Background
Originally, our results were modeled directly based on the output of FHIR CQL queries from FHIR stores. However, as @timakro pointed out, this structure is not optimal for searching and indexing. Moving forward, we aim for a more universal approach, avoiding unnecessary constraints from the raw FHIR CQL format. The issue already outlines some requirements, and I’d like to add the following considerations:

Proposed Requirements
FHIR CQL Compatibility
While we will continue using FHIR CQL in many projects, having a default parser to convert FHIR CQL results into the new structure would be beneficial. Given how we build our stores, adding a parser between backend calls and the results store shouldn’t be too complex.

Clear documentation will be essential so users can adapt the structure for SQL or other query languages, rather than relying solely on predefined adapters. That said, we could integrate community-developed adapters in the future.

Flat Data Structure
A flatter structure, rather than a deeply hierarchical one, would make indexing and filtering significantly easier.

Should the result structure still start with a "site" and then contain the results for that site? This is something worth questioning.

Would love to hear your thoughts! Feel free to comment below.

Cheers,
Patrick

[patrickskowronekdkfz]

Also in addition to the post. I was asked if Lens could support comparing search results. This is something we should also consider with the new structure. There is also currently a bug, where results from an older query is set in the result store of a new query. We would need to address also the resource part, with search results of multiple megabytes it could run full very fast