In most use cases DataSHIELD tables are meant to be patient-level, i.e. each row represents one individual. And it is very important for this rule to be respected to ensure not violating the data disclosure mechanisms. dsBase functions will fire an error if there are ever multiple rows with the same (patient) id.
What I am curious to learn about is how packages like dsSurvival work? If I understand correctly, the functions in this package expect event-level tables, i.e. each row represents an event and the same individual can appear multiple times. Is this just custom behaviour because dsSurvival is a community package?
The existing functions in dsSurvival do study-level meta analysis. So for example a cox regression is applied in each study separately and study-specific estimates are then combined with meta-analysis methods. In that case the event-level tables are not send to the client. Also data anonymisation is applied for the survival curves. You can have a look on these papers:
I am now working on the development of a pooled version of the cox regression (not released yet) where in that case event-level tables should be sent from each study to the client in order to be combined across all studies. In this case, i plan to use the same disclosure checks that we have in ds.table function, i.e. the number of unique time intervals is less than a pre-specified threshold (this can be either specified as a proportion of the individual-level data from each study or by a fixed value) and also that each time interval has more events than a pre-specified threshold.
About the community packages you are right that some of them might not take into account main disclosure controls. This is one of the reasons that the Governance Theme has produced a draft of the process needed for packages audit: DataSHIELD package audit process | DataSHIELD Community Wiki. This will be discussed and finalised in the DataSHIELD conference this year so any feedback is welcome!