1. What “rehabilitation app sharing conflicts” means in Denmark

In Denmark, rehabilitation apps are widely used in:

• physiotherapy recovery (post-surgery apps)
• mental health rehabilitation (CBT and therapy apps)
• chronic disease management (diabetes, stroke, COPD apps)
• hospital discharge follow-up systems
• municipal health and welfare apps

These apps typically involve sharing sensitive health data between:

• hospitals (public healthcare providers)
• municipalities (rehabilitation services)
• private app developers (health tech companies)
• insurers or occupational health providers (in some cases)
• research institutions

The legal conflict arises under GDPR because:

Health data is “special category data” under Article 9 GDPR, requiring strict protection.

The main tension is:

When does sharing rehabilitation app data become lawful, and who is responsible when multiple actors access and reuse it?

2. Core sources of conflict in Denmark

(A) Multiple controller confusion

Rehab apps often involve:

• hospital → data input
• app developer → data processing
• municipality → rehabilitation monitoring

➡ unclear if they are:

• independent controllers
• joint controllers
• controller + processor relationship

(B) Secondary use of health data

Conflicts arise when data is reused for:

• clinical improvement
• AI model training
• service optimization
• research

➡ purpose limitation issues under GDPR Article 5

(C) Continuous data flow problem

Rehabilitation apps collect:

• step count
• mobility progress
• mental health logs
• medication adherence

➡ continuous sharing blurs consent boundaries

(D) Consent vs public health basis conflict

Denmark often relies on:

• Article 6(1)(e): public task
• Article 9(2)(h): healthcare provision

But private apps often rely on:

• consent (Article 6(1)(a))

➡ mismatch creates legal instability

3. Key EU Case Law shaping Danish rehabilitation app conflicts (6 cases)

Case 1: Nowak v Data Protection Commissioner (C-434/16)

Principle: Broad interpretation of personal data

• Even evaluation scripts were personal data.

Relevance to rehabilitation apps:

• rehab progress notes, therapist annotations, and app logs are clearly personal data

Conflict created:

• even “non-medical metadata” in apps may still be health data if it reveals condition or progress

Case 2: Breyer v Germany (C-582/14)

Principle: Identifiability depends on realistic means

• Data is personal if identification is reasonably possible.

Relevance:

• rehab app data (movement, recovery timelines) can re-identify individuals in small patient groups

Conflict:

• anonymization claims by app providers often fail due to linkage risk with hospital records

Case 3: Fashion ID (C-40/17)

Principle: Joint controllership in data collection

• embedding third-party tools creates shared responsibility.

Relevance:

• rehabilitation apps embedding third-party analytics or cloud services

Conflict:

• hospitals and app developers may both be responsible for data collection phase

Case 4: Wirtschaftsakademie Schleswig-Holstein (C-210/16)

Principle: indirect control is sufficient for controller status

• page operator responsible for analytics data.

Relevance:

• Danish hospitals using third-party rehab platforms still influence purposes (treatment monitoring)

Conflict:

• hospitals cannot fully delegate responsibility to app vendors

Case 5: IAB Europe (C-604/22)

Principle: system designers can be joint controllers

• organizations shaping consent frameworks are responsible.

Relevance:

• rehab app providers designing data-sharing architecture or consent flows

Conflict:

• app developers may be controllers even if they do not access medical data directly

Case 6: Jehovan Todistajat case (C-25/17)

Principle: organizational responsibility extends to distributed data collection

• individuals collecting data under organization’s instruction create controller responsibility.

Relevance:

• physiotherapists or municipal workers inputting rehab data into shared apps

Conflict:

• decentralized healthcare data entry still binds institutions legally

4. Specific rehabilitation app sharing conflict types in Denmark

(A) Hospital vs App Developer responsibility conflict

Issue:

• hospital provides medical data
• app processes and visualizes recovery data

Legal ambiguity:

• processor vs joint controller classification

Risk:

• unclear allocation of GDPR Article 9 responsibilities

(B) Municipality monitoring vs clinical treatment conflict

Issue:

• municipalities track rehabilitation progress for social services
• hospitals use same data for clinical decisions

Conflict:

• different legal bases for same dataset

(C) Secondary AI training conflict

Issue:

• rehab app data used to train AI models

Problem:

• original consent may not cover secondary processing

(D) Cross-border cloud storage conflict

Issue:

• Danish rehab apps often use EU/US cloud providers

Conflict:

• data transfer + shared responsibility issues

(E) Patient consent fatigue conflict

Issue:

• multiple consents required across hospital, app, municipality

Result:

• invalid or non-informed consent

(F) Real-time monitoring vs proportionality conflict

Issue:

• continuous tracking of rehabilitation progress

Legal tension:

• necessity vs excessive monitoring under GDPR minimisation principle

5. Danish regulatory approach (Datatilsynet practice)

Denmark applies strict interpretation:

1. Health data = highest protection level

• rehab app data is always special category data

2. Strong preference for controller clarity

• joint controllership must be explicitly defined (Article 26)

3. Purpose limitation enforcement

• strict separation between:
  • treatment use
  • administrative use
  • research use

4. Data minimisation expectation

• only essential rehabilitation metrics allowed

5. Security expectations

• encryption
• access logs
• role-based access control

6. Core legal takeaway for Denmark

Rehabilitation app sharing conflicts exist because:

1. Multiple actors simultaneously influence patient data

2. Health data triggers strict Article 9 GDPR protections

3. EU case law expands controller responsibility broadly

4. Data flows are continuous and multi-purpose

5. Consent is often fragmented or insufficient

Final conclusion

In Denmark, rehabilitation app ecosystems almost always create multi-layered GDPR responsibility conflicts, especially between:

• hospitals (medical duty of care)
• municipalities (rehabilitation monitoring)
• private app developers (data processing systems)

EU case law consistently pushes toward:

broader joint responsibility and stricter accountability, rather than narrow technical delegation