Need the study ID in the study invitation

[bardram]

Right now we are storing the study id in the applicationData of the StudyInvitation. However, this is a hack and we would like to use application data for something else.

Therefore, studyId needs to be a property of either StudyInvitation or ActiveParticipationInvitation.

[Whathecode]

I don't really consider that a hack. If you look at the system decomposition, you see there is no dependency from the client to the studies subsystem, but only to the deployments subsystem.

We'd need strong reasons to introduce tighter coupling here, even if just through an ID. What is the exact use case the client needs the study ID for? If this is an application-specific use case, it really doesn't belong in core. If the use case is somehow related to core, we may need some other feature or communication which is mediated by the deployments subsystem.

we would like to use application data for something else

You can use a JSON object to store multiple fields in applicationData. The backend automatically parses this, so you don't have to escape JSON strings.

[bardram]

This is needed to get resources for the "study" (and not just the personal deployment).

I don't really consider that a hack. If you look at the system decomposition, you see there is no dependency from the client to the studies subsystem, but only to the deployments subsystem.

That's because you're looking at the wrong dependency - the one in play here is the one linking to the "Reource" sub-system (which is implemented in CAWS). Here it says "study" in the description of the link.

We'd need strong reasons to introduce tighter coupling here, even if just through an ID. What is the exact use case the client needs the study ID for? If this is an application-specific use case, it really doesn't belong in core. If the use case is somehow related to core, we may need some other feature or communication which is mediated by the deployments subsystem.

The current use case is to get study-specific "resources" like the informed consent text, onboarding participant information, general info about the study, news articles about the study, etc.

You can use a JSON object to store multiple fields in applicationData. The backend automatically parses this, so you don't have to escape JSON strings.

Yes - we are also considering this if you don't want to fix this issue.

[Whathecode]

This is needed to get resources for the "study" (and not just the personal deployment).

That makes sense. That's indeed why a "resources" subsystem in core was expected, and as you know is currently still missing. :) I think the right solution here is to start working towards adding that subsystem to core.

Resources: Contains a simple file store for resources (such as images, videos, and text documents) which can be referenced from within study protocols to be used during a study.

The reason I am hesitant to add studyId to StudyInvitation is because StudyInvitation resides in the deployments subsystem. And, this subsystem is designed to remain agnostic about "studies".

Similarly, the resources subsystem will likely benefit from being "studies" agnostic to keep things decoupled; at least, that was the original thinking behind the subsystem decomposition. If the client (through the deployments subsystem) receives resource IDs through the study protocol, there is no need to refer to studyID. Where and when study protocols can reference resource IDs is what needs to be carefully designed.

Consider that when a client retrieves resources from a "resources" subsystem using studyId, there is still coupling in the sense that the specific client doing so needs to know which resources to retrieve, or how to handle retrieved resources, as determined by the studies subsystem.

Some of the cases where this is needed may be "application-specific", and such assumptions can be hardcoded for a specific platform (outside of core, but through extensibility of core), but others may be generic CARP core use cases.

The current use case is to get study-specific "resources" like the informed consent text, onboarding participant information, general info about the study, news articles about the study, etc.

• Informed consent: This is expected to become a more integral part of core, in that we want to formalize end users accepting/revoking consent, which has an effect on ongoing data collection (and potentially already collected data). At that point, this is likely no longer a "resource", but a data type contained within StudyInvitation (currently, more or less encompassed by description). What format do you currently use for this? Until this is formalized in core, I would recommend to include this in StudyInvitation.applicationData: "This can be used by infrastructures or concrete applications which require exchanging additional data between the studies and clients subsystems, outside of scope or not yet supported by CARP core."
• onboarding participant information: This also sounds like a good fit for StudyInvitation.applicationData.
• general info about the study: This sounds like StudyInvitation.description ("A description of the study clarifying to participants what it is about."), but likely a simple string doesn't fulfill some other requirements you have?
• news articles about the study: This is more dynamic data than the original intent for the resources subsystem, which was there to contain files which are too big to be contained in the study protocol (videos, etc.). The original CARP requirements do list a need for 2-way communication between participants and researchers, which this seems to relate to. There may be some common core functionality to be extracted there, but it's not immediately clear to me whether "resources" would be the right place. It also raises questions such as: should users see news articles about the study which were posted before they started the study, etc.

Yes - we are also considering this if you don't want to fix this issue.

It's not about wanting, it's about finding out whether it belongs in core. :) I.e., what is the benefit of adding it to core instead of applicationData. If core doesn't act on that data in any way (yet, at least), that's a strong sign it doesn't belong there. It would simply introduce coupling to assumptions in specific extending platforms. Informed consent is a nice example of something which should more formally be handled by core (as it should have an impact on data collection), but then probably not through a "resource" or studyId.