One study in several trial

[cpommier]

Currently, trial has many studies and one study belong to a single trial.
As mentioned, trial can be mapped to other concepts in other systems, and in particular to project and dataset.

In those cases, a study can belong to several trial/datasets. There is therefore a need to update trial<-->study to many to many

[Gabriel-Besombes]

Isn't there a similar issue with program and trial?

[BrapiCoordinatorSelby]

Putting down some thoughts, this is pretty simple to solve from a technical point of view, but will add more complexity to the spec.

New Parameters will be added, to search for programs and trails based on study
GET /programs?studyDbId=xyz&trialDbId=abc
GET /trials?studyDbId=xyz
Technically, this would be enough. with these parameters you can find all the studies per trial and all the trials per study.

Optionally, we can add arrays to all the entities
"studies": [{ "studyDbId" : "xyz", "studyName" : "XYZ" }]
"trials": [{ "trialDbId" : "abc", "trialName" : "ABC" }]
"programs": [{ "programDbId" : "123", "programName" : "P123" }]
all three arrays could be added to all three entities, or useful subsets

[Gabriel-Besombes]

Adding the new parameters would only fix the issue in the search queries, not in the post/put ones if I'm not wrong.

[daveneti]

When we were implementing GraphQL for BrAPI we weighted up the merits of adding parameter to search queries and/or updating the response. In GraphQL you have the option of defining what fields are returned in the response, which is not possible in OpenAPI. So adding for example arrays of studies, trials, programs etc in the case of many to many relationships can lead to performance hits if you always need to do the join to return these. In some parts of BrAPI you have the includeXXX parameter which allow the response to to different. Also you have the 'sub-query' option, for example you could have the endpoint GET /studies/{studyId}/trials instead of adding a trials array to study. I think this is a better way to manage many to many relationships in OpenAPI, but then there is an additional enpopint to implement. Also, what if you have many studies to query. In that case you have to use the studiies search enpoint with a trial filter parameter.

So in summary for many to many relations (and one to many relations that have lot of results), I would propose

• Add the parameter to the GET and the search endpoint, e.g add studyDbId to GET /trials and add studiesDbIds to trials search.
• But don't add the mapping in the entity.
• and don't use the sub-query approach in Open API, e.g. dont add /studies/{studyId}/trials