We regularly hear from researchers who are planning digital phenotyping studies. They want to collect mobile sensing data from participant cohorts to better understand behavioral and affective patterns and are looking for the right platform to support their research. CARP is designed precisely for this kind of research, but it’s not a one-size-fits-all tool. Depending on your team’s technical capacity, institutional requirements, and data governance needs, there are three distinct ways to adopt CARP. This post walks through each option and addresses the regulatory considerations you’ll need to weigh before getting started.
Option 1: Use the CARP Hosted Service at DTU
The quickest path to launching a study is through the CARP hosted service, running on DTU Computerome, Denmark’s national high-performance computing facility for life sciences. This fully managed environment handles infrastructure, security, and data storage on your behalf.
Who it’s for: Research teams who want to focus on their science, not server management. No prior technical or DevOps experience is required beyond familiarity with research study design.
What you can do:
- Design and configure a study by creating a study protocol (in JSON).
- Use the CARP Web Portal to upload protocols, create studies, recruit participants, deploy studies, and manage ongoing studies.
- Ask participants to install the CARP Studies App directly on their Android or iOS devices and join the study.
- From the CARP Web Portal, download the collected data in JSON format for offline analysis in R, Python, or your statistical tool of choice.
Get started:
- Read about the CARP Hosted Service and the Privacy Policies.
- Reach out to the CARP Team at info@carp.dk to set up an account in CARP.
Option 2: Self-Host CARP Using the Open-Source Components
If your institution requires full control over where data resides – for example, due to national data residency rules, hospital IT policies, or ethics committee requirements – you can deploy your own instance of CARP using our open-source components.
CARP’s server-side stack consists of two independently deployable blocks (CAWS and the Portal) and the CARP Studies app:
| Component | Description | GitHub |
|---|---|---|
| CARP Web Services | The core backend: REST APIs, data storage, study management, and participant management | carp-webservices-spring |
| CARP Web Portal | The browser-based researcher interface for designing studies and monitoring data collection | carp-portal |
| CARP Studies App | The cross-platform Flutter app deployed to participants for passive and active data collection | carp_study_app |
All three components are open source and available under permissive licenses.
Who it’s for: Research teams with access to IT infrastructure and DevOps or software engineering support. Typical deployments run on institutional servers, university cloud environments, or national research compute facilities.
What you need:
- A server environment capable of running containerised applications (Docker / Kubernetes)
- A managed database (PostgreSQL)
- Familiarity with configuring authentication and networking
Option 3: Build a Custom App Using CARP Flutter Packages
For teams who need something beyond what the standard CARP Studies App offers – custom user interfaces, novel sensing modalities, proprietary data pipelines, or deep integration with existing clinical systems – CARP provides a comprehensive library of Flutter packages and plugins that you can use to build your own mobile application from scratch.
The flagship package, CARP Mobile Sensing (CAMS), provides a domain model and runtime for defining, executing, and managing sensing protocols on Android and iOS. You can mix and match packages to collect exactly the data your study requires.
Note that you can write your own custom data manager and point CAMS to use any server endpoint you control, including a self-hosted CARP backend, a hospital data warehouse, or a custom cloud storage solution.
Selected packages include:
carp_mobile_sensing– Core sensing framework and domain modelcarp_context_package– Location, activity, and weathercarp_audio_package– Audio and speechcarp_health_package– HealthKit / Google Fit integrationcarp_polar_package– Collection of heart rate data (HR/ECG) from Polar devicescarp_backend– CARP Web Service connectivity
Who it’s for: Teams with Flutter / Dart development capacity who need a tailored sensing application, or who are building a commercial or clinical-grade product on top of CARP.
Get started:
- CARP Mobile Sensing Documentation – docs.carp.dk/carp-mobile-sensing
- All available CAMS packages – github.com/carp-dk/carp.sensing-flutter
- All available CARP Flutter plugins – pub.dev/publishers/carp.dk/packages
Regulatory Considerations: GDPR and Data Governance
Regardless of which option you choose, collecting health and behavioural data from human participants – particularly clinical populations – carries significant regulatory obligations. Here is a summary of the key considerations for each model.
General GDPR Obligations (All Options)
Under the EU General Data Protection Regulation (GDPR), mobile sensing data collected from research participants is typically classified as personal data, and in clinical contexts (e.g., mental health diagnoses, physiological signals) frequently constitutes special category data under Article 9. This imposes heightened obligations on researchers, including:
- A lawful basis for processing – in academic research this is typically either explicit informed consent (Art. 6(1)(a) + Art. 9(2)(a)) or a public interest / scientific research basis (Art. 9(2)(j)), depending on your national implementing legislation.
- A Data Protection Impact Assessment (DPIA) is likely required given the sensitive nature of health-related sensing data and the scale of collection.
- Clear data subject rights must be upheld: the right to access, rectify, erase, and port their data.
- A formal data processing agreement (DPA) must be in place with any third-party data processor (including a cloud hosting provider).
Option 1: Hosted at DTU
Using the CARP hosted service means DTU acts as a data controller. Key points:
- DTU Computerome is a Danish national facility operating under Danish and EU law, meaning data stays within the EU/EEA by default – an important consideration for cross-border research collaborations.
- If researchers outside of DTU need access to the collected data, selected data items can be disclosed (Danish: “Vidergivet”) to research partners. In this case, a small contract is made between DTU and the research partner, which governs how this data can be used and deleted.
- You, as the researcher, bear responsibility for obtaining participant consent, informing participants of their rights, and ensuring your study protocol is ethically approved.
Note that currently, DTU cannot act as a data processor on behalf of a non-DTU data controller.
Option 2: Self-Hosted
When you deploy CARP on your own infrastructure, your institution is both data controller and data processor. This gives you maximum control but also maximum responsibility:
- Data residency is entirely determined by where you deploy, ensuring compliance with any national restrictions is your team’s responsibility.
- You must implement and document appropriate technical and organisational measures (TOMs): encryption at rest and in transit, access controls, audit logging, and breach response procedures.
- Multi-institutional studies require a joint controller agreement or sub-processor agreements depending on the arrangement.
- The self-hosted model is often preferred by ethics committees in countries with strict data localisation requirements.
Option 3: Custom App with CARP Packages
Using CARP packages to build a custom app gives you full flexibility over the data pipeline, which means regulatory responsibility falls entirely on your team:
- You choose where data is sent – you must ensure your backend infrastructure meets GDPR requirements, regardless of its location.
- If you upload to a third-party cloud (AWS, Azure, GCP), you must have Standard Contractual Clauses (SCCs) or equivalent in place if that infrastructure is located outside the EU/EEA.
- If you integrate with existing clinical systems (e.g., hospital EHRs), additional frameworks such as MDR (Medical Device Regulation) may apply if the app constitutes a medical device.
- Custom apps published to the App Store or Google Play must comply with those platforms’ health data policies in addition to GDPR.
Choosing the Right Path
| Hosted (DTU) | Self-Hosted | Custom App | |
|---|---|---|---|
| Technical skill needed | Low (JSON) | High (DevOps) | High (SW Engineering) |
| Time to first study | Days | Weeks–Months | Months |
| Data control | DTU-managed, EU | Full institutional control | Full control |
| Customisation | Standard app | Standard app | Fully custom |
| GDPR responsibility | DTU (data is “disclosed”) | Your institution | Your institution |
| Best for | Clinical research teams | Institutions w. strict data control | Product development |
If you’re unsure which option is right for your study, get in touch with the CARP team. We’re happy to advise on study setup, data governance, and the appropriate deployment model for your context.