🌐 Patient Data Cooperative Governance Voting Simulator

Member-Owned Data Cooperatives — An Alternative to Extractive Data Brokerage

A health data cooperative inverts the standard platform relationship: instead of a company collecting patient data and monetizing it unilaterally, patients pool their records as member-owners of a jointly governed trust. MIDATA (Switzerland, founded 2015 as a non-profit cooperative spun out of ETH Zurich and EPFL) and Salus Coop (Spain, founded 2017, Barcelona) are the two most cited operating examples: members donate structured health data — wearable streams, EHR extracts, patient-reported outcomes — into a shared repository, and only cooperative governance, not a corporate board, decides how that pool may be used for research or given commercial access.

• 2015: MIDATA founded (Switzerland; ETH Zurich spin-off)
• 2017: Salus Coop founded (Barcelona, Spain)
• 1 member = 1 vote: Governance model (cooperative bylaws, not shareholding)
• Non-profit cooperative: Legal form (member-owned, not investor-owned)

The cooperative structure and its legal distinction from commercial data trusts

A health data cooperative is a member-owned legal entity — typically incorporated as a cooperative society or non-profit association — in which the "shareholders" are the individual patients who contribute data. This differs fundamentally from three adjacent models:

1. Commercial data broker: a for-profit company purchases or licenses patient data; patients are data subjects with no ownership or governance stake, only the consent rights granted by applicable law (GDPR Art. 6/9, HIPAA authorization).

2. Data trust (fiduciary model): proposed by the Open Data Institute (ODI, UK, 2018-2020 pilot programme) and referenced in Sidewalk Labs' Toronto Quayside proposal (2019, later abandoned in 2020 partly over data-governance objections). A trust appoints independent trustees with a fiduciary duty to beneficiaries — legally closer to a pension trust than a cooperative; members do not vote directly, trustees decide on their behalf under a mandate.

3. Data cooperative (this simulation's model): members ARE the governing body. Bylaws specify voting rights, board election, and the conditions under which pooled data may be licensed. MIDATA's model: members download and control a personal data account, elect a cooperative board, and vote on "usage rules" — categories of research access the cooperative will permit in aggregate.

Enrollment mechanics: • Member signs a cooperative membership agreement (distinct from a mere consent form) establishing both data-sharing terms AND governance rights • Typical enrollment fee: nominal (CHF 10-20 for MIDATA) — symbolic of genuine membership, not a paywall • Data contribution: EHR import via patient portal API, wearable device sync, or manual patient-reported outcome entry • Membership register: maintained off the public ledger for privacy, but membership COUNT and voting-weight class are publicly auditable

Why cooperative governance matters for health data specifically: health records are GDPR Article 9 "special category" data requiring heightened lawful basis. A cooperative structure lets patients exercise Article 9(2)(a) explicit consent collectively informed by peer deliberation, rather than each patient parsing a lengthy commercial terms-of-service individually — while still preserving each member's Article 7(3) right to withdraw consent at any time, layered on top of the collective governance decision.

Encoding a Data-Use Request as a Machine-Readable Governance Proposal

Before any vote can occur, an access request — from an academic researcher, a pharmaceutical sponsor running a post-marketing observational study, or a public-health agency — must be translated from a plain-language ask into a structured proposal the cooperative can evaluate and, eventually, encode as an enforceable contract. This translation step is where vague requests ("we'd like access to diabetes data") become auditable governance objects with explicit scope boundaries.

• 7+: Required proposal fields (purpose, scope, retention, fee, re-ID ban…)
• 14–30 days: Typical review period (member deliberation window)
• ~40%: Proposals reaching a vote (rest rejected at board pre-screen)
• 8–15: Avg. proposals per year (mid-size cooperative, ~2-5k members)

Anatomy of a governance proposal and pre-vote board screening

A well-formed data-use proposal, in the MIDATA/Salus Coop tradition, specifies:

1. Requesting party & purpose: named institution, named study/product, and a specific research question — "open-ended future use" proposals are categorically rejected by most cooperative bylaws.

2. Data scope: exact fields requested (e.g., HbA1c trend, medication list, BMI) — proposals must enumerate fields, not request "full record" access.

3. Cohort definition: inclusion/exclusion criteria determining which members' data would be included if approved (e.g., "members with a type-2 diabetes diagnosis code, age 40-75").

4. De-identification standard: which anonymization/pseudonymization method applies before data leaves cooperative infrastructure — commonly HIPAA Safe Harbor de-identification or expert-determination equivalent, or k-anonymity with k≥5 for aggregate release.

5. Retention & deletion: how long the requester may retain extracted data and the contractual deletion deadline.

6. Re-identification prohibition: an explicit contractual and often technical (via query-only compute-to-data access) bar on attempting to re-identify individuals.

7. Benefit-sharing / fee terms: whether the requester pays an access fee, and how that fee is distributed — cooperative operating costs, member dividend, or reinvestment in cooperative research infrastructure.

8. Governance encoding hooks: which of the above terms will become enforceable smart-contract parameters if approved (Stage 4) versus which remain procedural/legal commitments enforced by ordinary contract law.

Board pre-screening: before a proposal reaches the full membership for a vote, a rotating member-elected review board checks it against baseline exclusion criteria — no law-enforcement access, no re-sale to third-party brokers, no uses inconsistent with the cooperative's founding charter. Roughly 60% of submitted proposals are refined or rejected at this stage before ever reaching a formal vote, reducing member deliberation fatigue on clearly non-compliant requests.

One-Member-One-Vote, Quadratic Voting, and Stake-Weighted Models Compared

How a cooperative counts votes shapes who effectively controls data-use policy. Three mechanisms dominate real-world and proposed data-cooperative governance design, each trading off simplicity, resistance to capture by motivated minorities, and fairness to members who contribute more data or have been enrolled longer.

• Most common: 1-member-1-vote adoption (MIDATA, classic co-op law)
• 2018: Quadratic voting origin (Weyl & Posner, "Radical Markets")
• 25–40%: Typical quorum threshold (of enrolled voting members)
• 60–66%: Typical supermajority bar (for special-category data proposals)

Three voting mechanisms and their governance trade-offs

1. One-member-one-vote (1M1V): • Each enrolled member casts exactly one vote regardless of data volume contributed or tenure • Legally the default under classical cooperative statutes in most jurisdictions (e.g., Swiss Genossenschaft law underlying MIDATA) • Strength: maximal democratic legitimacy, resistant to wealth/data-volume capture • Weakness: does not weight intensity of preference — a member mildly indifferent counts the same as one strongly opposed

2. Quadratic voting (QV): • Proposed by Glen Weyl and Eric Posner (Radical Markets, 2018); piloted in Colorado state legislature caucuses and some DAO governance systems • Members are allocated a "voice credit" budget; casting n votes on a single proposal costs n² credits (1 vote = 1 credit, 2 votes = 4 credits, 3 votes = 9 credits) • Effect: members can express intensity of preference (spend many credits on issues they care most about) while the quadratic cost curve prevents any single member from dominating by dumping all credits on one proposal • Health-data relevance: lets a small subgroup of members with a strongly-held condition (e.g., a rare-disease cohort) register proportionally stronger preference on proposals directly affecting their data, without granting them outsized control over unrelated proposals

3. Stake-weighted voting: • Votes weighted by a defined "stake" — commonly data volume contributed, tenure in the cooperative, or a hybrid formula • Rationale: members who contribute richer/longer longitudinal records bear more of the "cost" (privacy exposure) of a data-use decision and arguably should have proportionally more say • Risk: can recreate the extractive dynamics cooperatives are designed to avoid — members with the most data (often the sickest, most engaged patients) could be outvoted by a majority of lighter contributors, or conversely come to dominate governance themselves • Used sparingly in practice; most operating health cooperatives (MIDATA, Salus Coop) favor 1M1V specifically to avoid this dynamic

Quorum and supermajority design: • Quorum (minimum turnout for a vote to be valid) typically 25-40% of enrolled voting members • Supermajority thresholds (60-66%+) are commonly required specifically for proposals touching special-category health data, mirroring the heightened protection GDPR Article 9 gives such data over ordinary personal data • A proposal failing quorum is void regardless of approval percentage among those who voted — protects against a small, motivated faction pushing through policy on behalf of an inattentive majority

Encoding Governance Outcomes On-Chain While Preserving Individual Consent Layers

A collective "yes" vote is necessary but not sufficient to grant a requester data access — individual member consent remains a distinct, layered gate. This is the central governance tension of the cooperative model: majority rule determines cooperative POLICY (what categories of use the cooperative permits in principle), while each member retains an individual, granular right to exclude their own record from any specific approved use. Smart contracts operationalize both layers simultaneously.

• Permissioned ledger: Contract platform pattern (Hyperledger Fabric / Corda-style)
• Per-proposal: Consent flag granularity (not blanket opt-in/out)
• 8–15%: Typical opt-out rate (of otherwise-eligible cohort)
• Compute-to-data: Query access mode (raw records never leave custody)

How the governance contract reconciles collective approval with individual withdrawal

When a proposal passes its vote, the approved terms (scope, cohort definition, retention period, fee split) are written into a governance smart contract deployed on the cooperative's permissioned ledger. The contract does not itself grant blanket access — it defines the ELIGIBLE population and the query interface a requester may use against it.

Execution sequence:

1. Cohort resolution: the contract evaluates the approved cohort definition (e.g., "type-2 diabetes diagnosis, age 40-75") against the member database, producing a candidate list.

2. Individual consent filter: for EACH proposal, every candidate member has an individual consent flag — default state is defined by cooperative bylaws (commonly opt-out: members are included unless they actively decline THIS specific proposal, distinguishing it from blanket pre-authorization). The contract subtracts any member who has filed a specific objection to this proposal, or who maintains a standing "no pharma-sponsored research" preference tag.

3. Compute-to-data query execution: rather than exporting raw records to the requester, the contract instantiates a scoped, time-boxed query interface — the requester submits statistical queries (counts, means, regression coefficients) executed against cooperative-held infrastructure; only aggregate results with minimum cell-size suppression (e.g., no result derived from fewer than 5 underlying members) are returned.

4. Immutable event logging: every query executed, its timestamp, requesting identity, and result cardinality is written to the ledger as a permanent record, independent of whether the underlying health data itself is stored on-chain (it is not — only proposal terms and access-event metadata are, following common privacy-by-design practice of keeping raw PHI off any blockchain).

Why the two layers can conflict: a supermajority of the cooperative may approve a category of research use in good faith, while a specific minority of affected members (e.g., those with a stigmatized diagnosis, or distrustful of a particular sponsor) reasonably wish to be excluded from that specific instance. GDPR explicitly protects this: Article 7(3) guarantees the right to withdraw consent at any time, and this right cannot be legally overridden by a cooperative bylaw or majority vote — the smart contract's per-member consent filter exists precisely to make that legal right technically enforceable rather than merely a policy promise.

This layered design means cooperative governance sets the OUTER BOUNDARY of permissible use (what the cooperative as a body will countenance), while individual consent sets the INNER BOUNDARY for each member's own record. A proposal can pass 68% approval and still execute against a materially smaller cohort than the full eligible population once individual opt-outs are subtracted — this gap between "approved population" and "actual accessed population" is itself logged as a governance transparency metric.

Immutable Governance Logs, Minority Dissent, and the Right to Exit

A functioning cooperative must remain accountable to the minority that lost a vote, not only to the majority that won it. The final stage of the governance cycle is a permanent, member-auditable record of what was decided, how it was decided, and what recourse dissenting members retain — most importantly, the right to withdraw their data from future pooled uses (data portability) without losing benefits already accrued from past approved uses.

• Permanent: Governance log retention (append-only, member-readable)
• 30–90 days: Exit notice period (typical cooperative bylaw)
• GDPR Art. 20: Portability standard referenced (right to data portability)
• Per-vote tally: Dissent recorded (yes/no/abstain published, not just outcome)

Audit trail design, exit rights, and reconciling minority dissent with cooperative legitimacy

Immutable audit trail contents: • Full proposal text and its board pre-screening notes • Vote tally by mechanism (1M1V count, or QV credit totals, or stake-weighted sum) — published in aggregate, never linking a specific vote to a specific identifiable member, preserving ballot secrecy while keeping the OUTCOME fully auditable • Quorum and supermajority calculation, showing the arithmetic that determined pass/fail • Every subsequent query executed under the resulting contract (Stage 4), with timestamp and aggregate result cardinality • Any post-hoc member complaints or dispute filings and their resolution

Minority dissent and recourse mechanisms: 1. Right to individual opt-out (already exercised at Stage 4) — the most immediate recourse, exercised proposal-by-proposal. 2. Right to exit the cooperative entirely: a member may terminate cooperative membership on notice (commonly 30-90 days per bylaws), at which point no FUTURE proposal may include their data. 3. Right to data portability: modeled on GDPR Article 20, an exiting member can request their contributed dataset in a structured, commonly-used, machine-readable format for transfer elsewhere — critically, exit does not retroactively unwind uses already validly executed under a past approved proposal while they were a consenting member, but it does end all future inclusion. 4. Benefit-sharing continuity: bylaws commonly specify that any dividend or fee-share earned from uses that occurred while a member was enrolled remains payable even after exit — exit is not treated as forfeiture, avoiding a chilling effect that would otherwise discourage members from ever leaving a proposal they disagree with. 5. Governance recall: persistent minority grievances (e.g., a pattern of proposals systematically disadvantaging a patient subgroup) can trigger a bylaws-defined recall vote on cooperative board members, distinct from any single data-use proposal vote.

Why full auditability matters for legitimacy: unlike a commercial data broker's internal, unreviewable decision to sell data, a cooperative's decisions are legitimate specifically because losing voters can verify the process was followed correctly even when they disagree with the outcome — the log does not need to make everyone happy, only demonstrably fair and procedurally correct.

The essential design principle across MIDATA, Salus Coop, and ODI-style data trust proposals is the same: collective governance decides what the cooperative as an institution will permit, but no governance vote — however large the majority — can substitute for a specific individual's Article 7(3) right to withdraw their own consent. Systems that conflate "the cooperative approved it" with "every member's data may be used" are not GDPR-compliant regardless of how democratic the vote was.