Every study with its own protocol, team and rules

In data-collecting research, a common problem is that it later becomes unclear which protocol, period and permission a piece of data belongs to. In EnaResearch, every research project is opened in your organization’s environment as a study with a code starting with ST. The study is defined with its title, protocol number, planned dates, retention period, the metrics to collect and the pre-enrollment and late-data windows.

Researchers only pick metrics; the study’s permitted sources are derived on the server from the sources that can technically collect the selected metrics. A protocol that needs device consistency can restrict the source list by hand. The data model is study-centered: measurements are stored against the person and the source, and a study sees them filtered by the participation range and its own permitted metrics.

A study is created as a draft; a draft has no participants or data and can be deleted. When preparation is done, the PI submits the study for approval and can withdraw it while it is pending. The organization owner approves the study or requests changes with a reason. An approved study becomes scheduled or active depending on its start date.

Dates move the status forward automatically: the study becomes active on its start day and moves to closing at the end of its end day. From then on no new participants are registered and data for the period after the end is not accepted; late data for the period before the end is accepted for the window set on the study (14 days by default, up to 30 days). When the window ends, the study is closed for good; reading and exports remain available.

When needed, the PI or the organization owner can end a study early with a reason; an early end takes effect immediately. A study that has not started yet is closed directly.

After approval the PI can freely edit the title, protocol number, description and notes. If a date shift exceeds 30 days in total compared with the last approved dates, or the data scope changes (metrics, sources, pre-enrollment or late-data window), a change request with a reason is opened and waits for the organization owner’s approval. The start date cannot change once the study has started.

Recruitment is opened and closed separately from the study status: the PI can open or close recruitment while the study is scheduled or active. You do not have to end a study to stop taking new participants.

For a similar study, an existing study can be copied: the data scope, windows and team carry over to a new draft; dates, internal notes and participants do not.

The PI is responsible for the study: manages the team, submits the study for approval, opens change requests and opens and closes recruitment. Co-investigators work with the study’s participants and data as team members. The PI role can be handed over.

In studies where they are not on the team, the organization owner has a governance role: they see the metadata, team, timeline and counts of submitted studies, approve them, decide on change requests and can end a study early with a reason (for example after an ethics committee decision). Participants, data and datasets are visible to them only in studies where they are on the team.

Organization users sign in through the Logto identity platform; participants have no organization account.

The admin panel has two layers. The home layer holds the overview, studies and the data catalog, plus system administration, users and logs for owners. Inside a study, the sidebar switches to the study layer: sections such as dashboard, protocol, participants, team, datasets and history belong to that study.

The overview and the study dashboard show participant and record counts, participants who are not sending data and items waiting for approval. If the study keeps clinical records, the dashboard includes an event-anchored cohort chart: the daily median and interquartile range of a selected metric around an anchor event. Days with fewer than 5 participants with data are hidden.

A study defines in its protocol which clinical record categories it keeps (for example hospital stays, surgeries, complications) and its inclusion and exclusion criteria. After approval, these also change through a change request. How clinical records and participant eligibility are handled is described on the clinical context page.

Hiding a menu is not authorization. Every protected request is checked on the server against the user’s identity, role, organization, study team and the action requested, and the default is deny. Attempts to reach another study’s resources by address are tried in automated tests. Cross-study data sharing is off.

Every status change is written to the timeline on the study’s History page and to the HMAC-chained audit trail. Submissions and requests are emailed to owners, and decisions to the PI. Sensitive identity details and the person identifier are never written to the audit trail in clear.