Frequently asked questions

EnaResearch is an end-to-end research data platform for research teams and organizations. It works in five layers: it collects raw data with its source; standardizes it and flags its quality; adds clinical context from hospital stays, clinical events and manual measurements; produces versioned datasets, variables and pre-approved statistical analyses; and an optional AI assistant interprets results but never computes.

Study management and approval, participant registration and matching, participant access without accounts, the ingestion pipeline and metric catalog, data quality, clinical records and manual entry, datasets and exports, variables and statistics, and the optional AI assistant are available. The iOS and Android apps are built and await store release; the Chileaf wearable integration is in development.

For hospitals, universities, research centers, labs, research groups, departments, clinics and independent researchers. It is designed for research teams and organizations in Türkiye, Germany, the United Kingdom, the Netherlands and Switzerland; an organization can also be a single researcher.

No. EnaResearch is not a medical device, a clinical decision-support system or a real-time patient monitoring system, and it makes no claim about the clinical accuracy of measurements. Statistics and the AI assistant are for research, not for clinical decisions. It does not replace a hospital information system.

The iOS and Android apps are built; their App Store and Google Play release and real-device acceptance testing are pending. The apps will be announced on this site once they are published in the stores.

No. A participant starts with a 6-character code and an activation card with a QR code from the researcher, and sets a 6-digit PIN during activation. Web sign-in requires the code and PIN; the code alone never signs anyone in.

The system searches your organization for an existing person record, first by the person identifier and otherwise by name and date-of-birth similarity. Candidates are shown to the researcher masked; the decision to link is the researcher’s. Nothing is merged automatically, and each study only sees its own data.

The organization’s own record number or a hospital information system record number, NHS number, BSN, AHV/AVS number, KVNR, a Turkish ID or foreigner ID number, or another code your organization defines. The identifier is not stored in clear; a keyed hash and the last 4 characters are kept.

In the participant web area, participants see their studies, connected data sources, last sync time, a daily summary of the last 7 days and their sessions, and can change their PIN. Identity details and clinical records are not shown to participants.

When recording the withdrawal, the researcher chooses whether to keep or delete the data, and the choice is audited. Deletion covers only that participation’s data window and never touches the person’s data in other studies.

The participant can be marked “lost to follow-up”. Participation statuses are active, completed, withdrawn and lost to follow-up. Warnings appear for participants who are not connected or have sent no data for more than 7 days.

No, participants do not receive automatic notifications. The researcher hands over the code and the activation card.

Apple Health (HealthKit), Health Connect and Chileaf wearables (through the phone or a hub). The ingestion pipeline and metric catalog are live; the iOS and Android apps await store release and the Chileaf integration is in development. Huawei Health is out of scope, and Samsung Health data is collected only through Health Connect.

Invalid values are rejected at ingestion. Suspicious values (out of range, sudden jump, source conflict, low wear time) are flagged but never changed. Completeness per participant and metric is shown on the study’s data quality page, and flags are included in exports as quality.csv.

Raw device payloads are kept for 90 days. Standardized measurements are kept for the term of the license by default; the organization can set a shorter period counted from the study’s final closure. The study team receives an email 30 and 7 days before deletion.

Per participation: hospital stays (admission and discharge), clinical events such as surgery, procedures and complications (with Clavien–Dindo for complications), and manual measurements: pain and fatigue NRS (0–10), Borg (6–20), hemoglobin, CRP, leukocytes, creatinine and albumin. Corrections are kept as revisions with a reason.

Yes, as CSV or a FHIR R4 Bundle. A dry run comes first; rows with errors are listed and nothing is saved during the dry run. Identity fields are not read.

No. Clinical records provide research context; EnaResearch is not a hospital information system or an electronic health record and does not replace them.

Measurement datasets are exported as CSV with a manifest, with clinical events in events.csv and quality flags in quality.csv. Variable datasets come as variables.csv, missing.csv and codebook.csv, plus Excel, labeled SPSS (.sav) and an R script. Parquet is not supported.

Dataset definitions are versioned, and every export is made from a version. The window is a calendar range or anchored to an event (day 0 = the event). Files are deleted after 30 days and can be regenerated from the same version; downloads are audited.

Yes. The same definition and the same data cut-off produce output with the same SHA-256 hash. A value that cannot be computed is never filled with zero or an estimate; it is left missing with a reason.

No. Exports contain only the pseudonym (P001), sex and age at start; names, identifiers and birth dates are never included.

First the analysis plan (test, variables, significance level, hypothesis) is approved; approval freezes the dataset version and cut-off. Tests are computed deterministically with established open-source libraries such as SciPy and statsmodels; the input checksum and library versions are stored. Approved plans never change.

No. Only aggregated context goes to the provider: variable definitions, counts (small counts as “<5”) and test output. Participant rows, pseudonyms, names and birth dates are never sent. Every request is written to the assistant history and the audit trail.

No. The assistant suggests suitable tests for a research question, interprets approved results and drafts report sections; it never creates, approves or runs analyses and never computes. Every number in a reply is checked against the statistics output; replies that cannot be verified are rejected.

No. The assistant is off by default; the organization can turn it on in system management. Before using it with real patient data, the organization needs its own legal review. The assistant is for research, not for clinical decisions.

No. Each organization runs in a separate environment with its own application stack, database and database user.

EnaResearch is designed to support obligations under regulations such as GDPR, UK GDPR, the Swiss FADP and KVKK. The product makes no compliance claim; the legal basis, consent, ethics approval and controller and processor roles remain the organization’s responsibility.

The hosting region or country is agreed with the organization at setup and written into the contract.

Researchers work only in studies whose team they are on. The organization owner approves studies and is responsible for governance; in studies whose team they are not on, owners do not see participant data. Every permission is checked on the server and sensitive actions are written to a chained audit trail.

Fill in the demo request form. We listen to your research program and data sources, show the product live and share the roadmap for features in development.

The organization code is a short code used to find your organization’s EnaResearch environment. On this site’s sign-in page, entering the code takes organization users to the admin panel and participants to the participant area. The code is only used for routing and grants no access.

Because the scope of a deployment differs by organization, we share pricing after a conversation. Reach us through the contact or demo form.