Is this implemented in the FHIR server or in a client?

[mjtrac]

Sorry if this is an unusually dumb question, but is the idea here that the server can transmit, as a table, only some elements of a set of resources, or is this a way to extract data from resources that a FHIR server must still transmit to me as a Bundle?

[dkapitan]

@mjtrac no worries, happy help where I can. Now I don't consider myself a full expert but what I do know is that SQL-on-FHIR is intended to create flattened views on single resources. If you want a table that contains columns that are joined across resources, you still need to add joins on top of the views for each resource.

You also ask how that works for a Bundle, I don't know for sure. But this could actually be a mechanism through which you can join resources in one go.

Imagine you have an International Patient Summary Bundle. If you flatten that with a single SQL-on-FHIR view, you can mimic the join on the Patient ID since all resources in the bundle pertain to that same patient.

But in the most generic case, you need to join views by hand still.

Hope this helps.

[mjtrac]

Thank you. Do you know whether the FHIR server itself generates and transmits the table to clients (which would then join them as appropriate)?

[dkapitan]

That depends on the specific implementation I guess. In theory, if the server implements a SQL-on-FHIR runner, it should be able to expose the resulting table via an API.

Failing that, it is relatively easy to run your on runner with open source tools like Pathling.

[mjtrac]

Thanks again. My issue is seeking to reduce the bandwidth to that necessary to retrieve some elements, not (much larger) full resources.

[bashir2]

As @dkapitan mentioned, currently the context in which ViewDefinition is defined, is a single resource. For example, this is our implementation where the input is a single resource and the output is a RowList.

Regarding your comment about FHIR-server support and reducing bandwidth, there has been some discussions about having a "view API" in FHIR servers but I think we are far from it becoming a standard (some FHIR-servers may have implemented it as a custom API). Currently a common pattern is to fetch the [full] resources from the FHIR-server and then apply a ViewDefinition on them one by one, creating flat tables/views.

[mjtrac]

Thanks, Bashir.