Executive summary
Health data occupies the most protected legal category of personal information, yet healthcare has led every industry in data-breach costs for thirteen consecutive years. This paper examines why protection and access are both failing, and what a non-profit infrastructure changes.
- Regulation built to protect patients has, in early implementations, narrowed the research it was meant to make safe. Finland, the first country to fully implement secondary-use rules, saw approved research permits fall an estimated 47% below projected levels in 2023; registry studies under HIPAA recorded steep declines in patient follow-up and recruitment.
- The gap is widest in women's health. The three largest menstrual apps have been downloaded more than 250 million times, 20 of the 23 most popular women's mHealth apps share data with third parties, and the female-specific conditions that make up 14% of the women's-health burden received under 1% of 2019–23 research funding.
- The answer this paper argues for is structural: a neutral Swiss non-profit foundation acting as Data Controller, holding patient data under explicit, revocable consent on open-source infrastructure. Swiss foundation law makes that mission permanent. The statutes put patients' fundamental rights and their control over their own data at the centre, treat health data as a common good that is neither bought nor sold, limit its use to clinical care and approved research, and give the Foundation no profit-making purpose.
- Clinics, researchers, and app developers who partner with HDS inherit the consent, audit, and compliance machinery instead of building it alone, and work with consented, research-grade data from the moment of collection.
State of the Art
In law, health data occupies the most protected tier of personal information: the European General Data Protection Regulation (GDPR) places it among the “special categories” whose processing is prohibited but for narrow and explicitly justified conditions, and in the United States protected health information is governed by a dedicated federal regime under HIPAA. Practically, health data should be considered a debt for institutions: a liability that becomes an asset only when the processing creates value for the data subject.
Healthcare has been the most expensive sector for data breaches for thirteen consecutive years, and the vulnerabilities of centralised clinical databases have come to be understood as structural properties of those systems rather than incidental lapses. The records that describe a person's body are generated in vast volume, dispersed across dozens of mutually incompatible systems, and, for the most part, remain inaccessible to the very people they concern.
To this is added a second failure, less visible but no less consequential. There is growing evidence that the regulatory architecture built to protect patients can, in its implementation, narrow the very research it was meant to render safe: where secondary-use rules have been operationalised at scale, the volume of approved research permits has fallen sharply, and registry-based research under the HIPAA Privacy Rule has recorded steep declines in patient follow-up and in trial accrual. This evidence is still partial, drawn from particular jurisdictions and early measurement windows, and it shows association more than settled cause. Even so, set beside the security record it describes a system at once over-restricted for those who would use it responsibly and under-protected against those who would not, and it is this double bind that the present paper takes as its point of departure.
Two regulatory frameworks define the terms of this problem. The first is HIPAA, the Health Insurance Portability and Accountability Act, enacted in the United States in 1996. HIPAA's Privacy Rule requires written patient authorisation before a covered entity — a healthcare provider, health plan, or clearinghouse — may use or disclose protected health information for research purposes. The second is the European Health Data Space (EHDS), Regulation (EU) 2025/327, which entered into force on 25 March 2025.
HIPAA established an important baseline. Its architecture has also created a compliance culture that systematically "errs on the side of caution," with institutions placing blanket restrictions on data sharing that go well beyond what the law requires. Critically, HIPAA does not apply to consumer health applications: the FemTech apps used by tens of millions of women to track their cycles, hormones, and symptoms operate outside its scope entirely. And even within its scope, HIPAA's central mechanism for enabling research — stripping identifiers so records can be shared as “de-identified” — is an imperfect safeguard: a systematic review of re-identification attacks on health data found that records stripped of identifiers can still be re-identified when quasi-identifiers are combined.
The EHDS is more ambitious. It creates a common framework for both primary use (individual care) and secondary use (research, policy, regulatory decisions) of health data across all EU Member States, with mandatory interoperability standards, secure processing environments, and a "data altruism" pathway for patient contributions to research. Its obligations apply only gradually — most of them four years after entry into force: the Commission is to adopt the detailed implementing acts and Member States to establish Health Data Access Bodies by 2027; the core primary-use exchange (patient summaries, e-prescriptions) and the secondary-use rules for most data categories apply from March 2029; and the remaining categories follow in March 2031.
The Research Access Problem
Early outcomes have not matched good intentions. In Finland, the first country to fully implement secondary-use health data rules, the volume of approved research data permits fell by an estimated 47% in 2023 against projected levels, and 79% of medical-doctor respondents found the data-permit process more complex than before. One early case is not a verdict on regulation everywhere, but it is a warning worth heeding. The compliance tax it reflects is better established: administrative overhead, ethics review, consent management, and legal architecture consume a substantial and growing share of clinical research budgets, leaving proportionally less for the science.
HIPAA compliance has measurable costs for research specifically. Studies of registry-based research under the Privacy Rule documented sharp decreases in patient follow-up and accrual, with recruitment time and cost rising relative to pre-HIPAA baselines. Protected health information (PHI) breaches reported to the US federal regulator have affected more than one billion individuals cumulatively since 2009, yet the dominant response has been to tighten access controls further, compounding the research access problem rather than addressing its structural causes, even though the security weaknesses of centralised health-records databases are well documented as structural rather than incidental.
The security picture is equally stark. Healthcare has been the most costly sector for data breaches for 13 consecutive years, averaging $6.64 million per incident in 2026, the highest of any industry, and down 10.5% from $7.42 million in 2025 even as the global average rose to a record $4.99 million. The mean time to identify and contain a breach rose to 247 days in 2026, reversing a five-year decline.
The problem is not only external attacks. Consumer health apps, including cycle-tracking apps used by millions of women, have systematic privacy failures. A peer-reviewed scoping review of the 23 most popular women's mHealth apps found that 20 of them shared data with third parties and that current practices do not comply with the GDPR. Several major cycle-tracking apps have shared user data with advertisers, and at least one was investigated by regulators for disclosing sensitive reproductive information. The apps that collect the most intimate data about women's bodies are, structurally, among the least accountable.
An enormous volume of women's health data exists, yet almost none of it is research-grade, consented, or interoperable. Tighter regulation appears to have reduced research access in early implementations without resolving the underlying governance failure.
The EHDS: Ambition and Implementation
The clearest test of whether regulation helps or hinders research is now arriving as the European Health Data Space. Its ambition is real: a common framework that lets approved researchers reach health data across every Member State could expand sample sizes in a way that matters most for rare diseases and for the cross-border epidemiology no single country can power. Whether it delivers depends less on the text than on how it is built, and the early analysis points to several challenges that land directly on clinical research teams.
The first is a change in how access is authorised. The EHDS moves much of secondary use away from individual consent toward a permit model, in which national Health Data Access Bodies grant researchers access to defined datasets while patients keep a right to opt out. This can lighten the work of tracking consent across long studies, yet it also creates a moving target, since a dataset's contents shift as patients withdraw, and it places the legitimacy of the whole arrangement on bodies and procedures that are still being built.
The second is distance from the data. Analysis is meant to happen inside secure processing environments, isolated from the institutions that produced the records. That protects privacy, but it can sever the link between the researcher and the clinician who entered the data, and without that context a lab value or a coding choice is easy to misread. Quality compounds the problem: clinicians record data to treat patients, not to meet research standards, and the framework gives data holders little to fund the upkeep of research-grade datasets. Harmonising records that were never collected the same way remains, on the evidence of early cross-country pilots, genuinely hard.
None of this means the EHDS will fail; it means its value for research is not settled by the regulation alone. It turns on implementing acts still to come, on funding, and on infrastructure that preserves context and quality at the point of collection, with the secondary-use provisions phasing in only across the second half of this decade. This is the gap HDS is built to occupy. Data captured under explicit patient consent, structured and coded at source, and kept connected to the people and settings that produced it answers several of these problems directly, and a foundation acting as data controller can work inside the EHDS rather than against it.
Making Health Data a Common Good
Health data is the documentary record of a person's body, and the value it holds, whether for individual care, for research, or for public health, derives entirely from the trust of the people it describes. That value grows when data is shared under clear terms patients understand and control, and it erodes when data is used in ways patients never agreed to.
That trust is damaged every time data is sold without consent, used for purposes patients did not agree to, or withheld from the people who need it most: the patients themselves and the researchers working on their behalf. The neglect is structural rather than incidental: even health-technology assessment, the discipline whose purpose is to weigh a technology's full value, applies its "best available evidence" standard to clinical and cost data while rarely gathering evidence on patient experience, which few assessment bodies collect at all.
Patients regularly forget 40 to 80% of the medical information provided to them during consultations, and roughly half of what they remember is incorrect. The result is that every new encounter with the healthcare system begins from scratch: a reconstruction from imperfect memory, under pressure, with real consequences for diagnosis and treatment. Incomplete health histories are a primary driver of diagnostic error.
The argument for health data as a common good rests on a straightforward observation: data collected from patients, funded largely by public institutions, and essential to public health delivers its full value only when everyone with a stake in it, from patients and clinicians to researchers and industry, can put it to use on terms the patient has set. The conclusion this compels belongs to governance rather than to sentiment: because such data is collective in origin and largely public in funding, the terms on which it may legitimately be used must answer to the public interest, and no appeal to goodwill is required to establish as much. This is an applied principle rather than a novel one: the procedural, social, and epistemic-justice arguments now used to justify involving patients directly in health-technology decisions bear with equal force on the data those decisions rest upon.
What is a Data Controller?
A Data Controller is the legal entity that determines why and how personal data is processed. Under GDPR, HIPAA, and the Swiss Federal Act on Data Protection (nLPD), being a Data Controller means accepting full legal accountability for data governance. When HDS acts as Data Controller for the data held on the platform, it carries the governance accountability for how that data is stored, accessed, and used for research; for that processing, the partner's role is the narrower one of a Data Processor under GDPR Art. 28. This does not erase the partner's own duties. A clinic collecting data at the point of care remains responsible for how it gathers and secures that data before it reaches the platform, for verifying patient identity, and for the clinical-confidentiality and malpractice law that governs its own practice. What HDS removes is the burden of building and defending the secondary-use governance and access-control layer, not the partner's responsibility for its own front door.
The Swiss Foundation Model
Health Data Safe was established as a Swiss foundation under Swiss federal law, registered in the canton of Vaud on 10 October 2025. We chose the Swiss foundation structure deliberately, and its consequences are substantive: it places the organisation under permanent federal supervision, renders its mission legally binding rather than merely aspirational, and removes any mechanism by which it might later be converted to commercial ownership. Our founding statutes state the Foundation's purpose plainly: to act for public health, the quality of care, and scientific progress, with the fundamental rights of patients at the centre. They commit it to let each person keep complete control over their own data, to work in the service of human dignity, and, guided by subsidiarity and solidarity, to pursue together the individual good of persons, their collective good, and the common good of society. Health data is held as a common good on those terms: neither HDS nor the patients using the platform may buy or sell it, its use is confined to clinical care and ethically approved research, and the Foundation has no profit-making purpose.
“Patient ownership” is used in this paper in a precise sense, and it rests on the two commitments the Foundation was created around. First, the patient's fundamental rights are respected by design: in the architecture and the statutes, rather than by promise. Second, the patient holds the use and the full control of their record, deciding alone who may read it, for what purpose, and whether it is amended, exported, or deleted; what the model removes is the economic yield of the data itself, which belongs to no one. Taking that yield out of the economic model is what turns the relationship into one of common good, in Jean Tirole's sense of institutions designed to align each actor's incentives with the collective interest: the value of health data is realised as better care and better science shared by all.
These commitments are not internal policies that a board might revise at will; they are provisions of Swiss foundation law that no board can change on its own. Under Articles 85–86 of the Swiss Civil Code, a foundation's organisation or purpose may be amended only by the competent supervisory authority, and only under the narrow conditions the law allows. In a sector whose most frequent failure is the mission-driven venture that is later sold to a commercial acquirer, it is precisely this legal entrenchment that separates a binding guarantee from a statement of intent.
That rigidity applies to the mission, not to the technology. A partner cannot change what HDS is permitted to do with patient data; that is the point. But connecting to the platform is deliberately light: the consent, audit, and compliance machinery lives in the Open-Pryv layer (the open-source personal-data platform the HDS infrastructure runs on, described in Section 3) rather than in each partner's own stack, so a clinic or an app integrates through a public, open API and inherits that machinery instead of rebuilding it. The technical integration is close to immediate. What takes time is the part worth taking time over: understanding the partner's real need, and the legal groundwork — scoping the data, signing a business associate agreement — that any serious health-data relationship requires. The governance is fixed precisely so the engineering does not have to be.
The foundation derives no revenue from patient data, and none from access requests. It funds its work through grants and philanthropy. That funding model is what lets HDS offer partners something a commercial vendor cannot: infrastructure with no incentive to monetise the data flowing through it, and no route by which the platform could later be sold to an acquirer. For a clinic, a research group, or an industry sponsor, that neutrality is the product. Donations and grants pay for the compliance, consent, and data infrastructure that each partner would otherwise have to build, staff, and defend alone, which is what makes a substantial contribution an investment rather than a gift.
A fair question is whether philanthropy can sustain infrastructure that grows with every patient and partner it serves. The core of the model is economics, not charity. A clinic, an app, or a research sponsor that integrates gains the data-controller role, the user trust that comes with it, and access to a research-services capability that HDS is building toward the standard of a contract research organisation (CRO), in step with its partners' needs. The calculation is concrete: a partner that integrates does not build and certify its own compliant data store, appoint and staff a data protection officer, or maintain the consent and audit infrastructure regulators now expect, which for most organisations is the larger share of what a data programme costs. Partners support the foundation because that support costs them far less than the alternative, and because their own work comes to depend on the platform continuing. As that advantage compounds across a growing network, the organisations that depend on the platform acquire a direct stake in keeping it funded, and the means to do so. Grants and philanthropy carry the early stage; at scale, the partners who benefit most become the foundation's most committed donors. Alongside this runs a second, independent stream. Like the Wikimedia Foundation, HDS asks the people who use the platform to support it directly. Users experience HDS as their own health record and application, not as a compliance layer, which is what makes that appeal realistic; many small contributions can keep the core service running whether or not any company donates in a given year. That floor keeps the foundation from depending on any single funder, and independent of the partners it serves. The Swiss structure adds a backstop the commercial model lacks: the mission, and the infrastructure partners rely on, cannot be sold out from under them.
The Economic Logic of the Common Good
Jean Tirole, in Économie du bien commun (2016), identifies the conditions under which markets fail: information asymmetry, unpriced externalities, and incentives that diverge from collective welfare. Health data satisfies all three. Patients cannot know the full value of the data they generate. The costs of poor health-data governance — missed diagnoses, replicated studies, ineffective treatments — are borne diffusely by healthcare systems and by individuals, not by the data controllers who created those conditions. And the platforms that hold most personal health data today were built first to put it to commercial use, with data protection added afterward rather than designed in from the start.
The common-good framework resolves this by removing profit from data governance. The Foundation has no financial stake in expanding data use beyond what patients authorise. It has a legal obligation, enforced by Swiss federal supervision, to ensure that every access to patient data serves the purpose the patient approved. Such an arrangement follows from the structure of the problem rather than from preference: when the party that holds the data also profits from widening its use, respecting the limits of consent and widening that use pull against each other. Separating data governance from any profit motive removes that particular tension, which is why HDS holds the controller role rather than the partners building on top of it.
That same logic applies with particular force to health conditions where data is scarcest and unmet need is greatest. Eve's Ark, a US initiative preserving women's health data as a foundation for scientific discovery, frames it directly.
"AI does not fill gaps. It scales what already exists. If the data is incomplete, the future built on top of it will be incomplete too."Eve's Ark Foundation
A solidarity-based allocation of data infrastructure makes sure the conditions most in need of evidence are served, not only those with the largest commercial markets.
None of this sets HDS against the organisations that serve patients today. The foundation is built to work with clinics, researchers, app developers, and industry sponsors, not around them. It takes on the data-controller role, the compliance burden, and the consent infrastructure so its partners can concentrate on care and discovery. Everyone HDS serves gains the same thing: health data they can trust and actually use, on terms patients have agreed to.
Where Evidence Ends and Judgement Begins
Much of this paper is empirical. The women's health data gap, the cost of breaches, the decline in registry research, the fragmentation of fertility data: these are measured facts, and each carries a citation. The paper also makes claims of a different kind. That health data should be treated as a common good, that non-profit governance better protects a mission, that patient ownership is the right answer to fragmentation, that removing profit from data governance aligns incentives: these are not findings. They are arguments about how health data ought to be governed, and no quantity of data settles them on its own, because the question of who should hold power over a person's medical record is a question of values and institutional design, not only of measurement.
We make these arguments deliberately, and we hold that they are right. A paper that refused any normative position on health-data governance would not be neutral; it would leave the existing arrangement, in which commercial incumbents set the terms, unexamined. Deciding how to govern sensitive data is unavoidably a choice about values. The honest course is to argue for ours in the open, and to mark where the case rests on evidence and where it rests on judgement.
Each of these positions has a serious objection, and each deserves a hearing. "Common good" can be read as a licence to use data against an individual's wishes; we reject that reading, which is why HDS makes individual consent the gate and treats the common good as a limit on use rather than a permission for it. Non-profit status guarantees neither competence nor good conduct; foundations can be captured or badly run, and the safeguard here is specific, namely the legal entrenchment of the mission under Swiss supervision, not virtue inferred from a label. Patient ownership does not by itself merge scattered records; interoperability standards and a working conversion layer do that, and ownership is what makes consolidating the data lawful and consented rather than what technically achieves it. Removing the profit motive from data governance removes one well-documented source of misaligned incentives, but not every incentive problem: a foundation must still resist mission drift, donor pressure, and its own institutional interests. The claim is that the model corrects a specific failure, not that it is incorruptible.
None of this weakens the case; it states it at the right strength. The empirical claims should be judged on the evidence. The normative claims should be judged as arguments, against their alternatives, on whether they produce a more trustworthy settlement for the people whose data is at stake. We hold that they do, and the reader is equipped to disagree.
Strategic Creation of a Non-Profit Clinical Research Organisation
Clinical research infrastructure is dominated by a small number of large commercial contract research organisations (CROs) that sit between industry sponsors and patient populations.
They recruit, they manage consent, they maintain data systems, and they charge accordingly. The result is that the cost of running a clinical study includes, as a significant fixed cost, the margin of a commercial intermediary whose interests are not necessarily aligned with the research outcomes. HDS was designed as the non-profit alternative to that model: a clinical research infrastructure built on patient ownership and open-source technology, where the data-controller role is held not by a commercial entity extracting value but by a foundation legally obligated to serve patients and science. Whether that model fills a real gap or simply restates a known problem is a fair question; Appendix A sets HDS against twenty existing platforms so the claim can be checked rather than taken on trust.
Why Open-Pryv
Most health data platforms organise information around processes: rows in a relational schema built for the organisation's operational needs. A patient appears as a record in a hospital system structured around appointments, diagnoses, and billing. The patient does not own a column. When a regulator asks to see all data about a specific individual, the answer requires a custom query and results that must be manually verified for completeness. Consent records live in a separate CRM. Audit trails are maintained as spreadsheets. This is the standard pattern, and it is the reason GDPR Art. 30 compliance is a recurring manual exercise for most healthcare organisations rather than a built-in capability.
Open-Pryv inverts the model. Every piece of data belongs to a user account first, organised within named context streams second, for example health/vitals/temperature or fertility/cycle. No process can read any data without first resolving through an Access object: a token specifying exactly which streams, at which permission level, for which declared purpose, granted explicitly by the user. Access control sits as a structurally separate enforcement layer between every caller and the data store, so that no process can reach the data except by passing through it, and an application built on the platform cannot grant itself access the user has not authorised, because the check sits below the application layer rather than inside it.
This is a property of the software primitive, not a claim of total security. The access layer cannot be bypassed in code, but a misconfigured host, a leaked partner credential, or a compromised clinic endpoint can still expose data. Operational security — infrastructure hardening, key handling, endpoint integrity — is a responsibility HDS and its partners share, and the platform's design narrows that attack surface rather than removing it.
Standard platform
Open-Pryv
Regulatory obligations map directly onto platform primitives instead of being retrofitted as procedures. GET /accesses combined with the audit log is the records-of-processing register.
The practical consequence is that the GDPR Art. 15 right of access is a standard stream-export call; GDPR Art. 17 erasure and Art. 20 portability follow the same pattern. The audit log — which captures every API call against every user account at write time with a method, access reference, and integrity hash — cannot be disabled. It is invariant, not a configuration option. When HDS's partner institutions integrate with the platform, they inherit this architecture: a small research group has the same legally auditable consent infrastructure as a major hospital network, because the compliance layer is the platform, not the institution's own implementation.
This shape is not generic by accident; it fits the kind of data women's health generates particularly well. Cycle and fertility data is longitudinal, many-typed, and irregular: a cervical-fluid observation, a basal body temperature, a quantitative hormone reading from a Mira device, a symptom note, and a medication entry can all land on the same day, each with its own structure, and the signal that matters is in how they move together over months. A relational schema built for hospital billing models these as rows in fixed tables and strains under them. The stream model stores each observation as a typed event under the patient's account, so adding a new biomarker is a new stream rather than a schema migration, and a researcher pulls a consented longitudinal series in a single export. The platform is general-purpose by design, but women's health is where that design pays off first, which is why HDS started there.
Open-Pryv was certified as a UN Digital Public Good by the Digital Public Goods Alliance on 19 April 2024, meeting the DPGA Standard across open licence, open standards, privacy compliance, platform independence, and alignment with the UN Sustainable Development Goals. HDS has adopted Open-Pryv as the technological foundation of its platform and is, in Pryv's words, “fully committed to the open-source development of Pryv.io”.
The 12 Structural Privacy Defaults
Open-Pryv ships twelve privacy-protective behaviours that cannot be misconfigured away: default-deny permissions; invariant audit logging; TLS enforcement; per-user data-residency pinning; no public-read tier; JSON-Schema validation at ingest; zero mandatory subprocessors; credential redaction from logs; and a withdrawal API always available to patients. These are not settings; they are what the platform is.
Technical Architecture
The platform is built on Open-Pryv, co-created by Pierre-Mikaël Legris, HDS's Chief Technical Officer and the founder of Pryv SA. It is licensed under BSD-3-Clause and is fully self-hostable. There is no vendor lock-in: any operator can run, audit, and migrate the full stack independently, without permission from or payment to the original vendor. In health data this matters acutely: lock-in can trap patients' records with a provider indefinitely, obstruct continuity of care, and constrain compliance with evolving regulation.
The HDS data model covers 251 health data-point types (August 2026 publication), and more on request from our partners; all standardised to SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms), HL7 FHIR (Fast Healthcare Interoperability Resources), RxNorm, and the WHO Anatomical Therapeutic Chemical (ATC) classification. Data arrives already structured and coded, which removes the formatting and schema-reconciliation work that usually consumes the first stage of any study. It does not remove the need for clinical validation: input error, device-to-lab calibration differences, and outlier detection still call for scientific judgement. What the model eliminates is the syntactic clean-up, not the semantic. The model is organised in fourteen domain streams, from Fertility, Body, and Medication to Symptoms, Conditions, Nutrition, Activity, Profile, and Family.
The critic who says semantic validation is ninety percent of the cost is right, and it is the part HDS directly addresses. The platform gives healthcare providers the ability to send validated, standardised questionnaires directly to patients, including internationally validated patient-reported outcome measures such as the EQ-5D (EuroQol 5-Dimension questionnaire). A patient-reported outcome collected through a validated instrument, administered under healthcare professional (HCP) supervision and recorded directly into the structured data model, is semantically clean by construction: the response options are defined, the coding is fixed, and the instrument's psychometric properties are established in the literature. This is not self-reported freetext and it is not a minor clinic pushing unchecked records. It is the same data-collection standard that academic clinical trials use, made routinely available through the platform's questionnaire infrastructure rather than requiring a custom implementation for every study. No architecture removes the obligation to choose the right instrument, or to interpret its output correctly, but HDS removes the structural barrier that has historically made validated PRO collection impractical outside well-resourced trial settings.
Production-deployed integrations as of June 2026. Each connection is mediated by an Access object: no data flows without a corresponding, time-limited, purpose-specific consent record.
Interoperability & Consent
As of June 2026 the platform includes production-deployed integrations with Mira (quantitative hormone monitoring), athenahealth (EHR integration via SAML SSO), and cycle-data file imports for FEMM, Cyclefeminin.net, and Read Your Body; the REDCap bridge is in active deployment. The platform's Compliance Matrix, published in June 2026, records in plain language how each obligation under HIPAA, GDPR, the Swiss nLPD and the SOC 2 Trust Services Criteria is met, and who meets it. For every obligation it states what the open-source platform does by design, what HDS adds as operator, and what remains for the implementer, any organisation that chooses to build on HDS. Each entry states its position, explains the reasoning, and cites the evidence behind it. The matrix is a living record rather than a certificate. It is reviewed continuously, and it says plainly when an obligation rests with the implementer rather than with HDS.
The four frameworks, in plain terms
GDPR. The General Data Protection Regulation is the European Union's data protection law, in force since May 2018 and binding in every EU and EEA country, and on any organisation anywhere that handles the data of people in Europe. It treats health data as a special category: using it is forbidden unless the law allows it, for example with the person's explicit consent, for their care, or for research under safeguards. It gives each person enforceable rights to see their data, have it deleted, and take it elsewhere. National data protection authorities enforce it, with fines that can reach 4% of a company's worldwide turnover.
Swiss nLPD. Switzerland is not in the EU and has its own law. The revised Federal Act on Data Protection has been in force since 1 September 2023. It is known in French as the nLPD and in English as the FADP. It follows the same logic as GDPR and is recognised by the EU as offering equivalent protection. Health data is “sensitive” data, and consent to use it must be explicit. The Federal Data Protection and Information Commissioner supervises it. One feature is unusual. Its criminal fines fall on the responsible individuals, not only on the organisation. As a Swiss foundation, HDS is directly subject to this law.
HIPAA. The Health Insurance Portability and Accountability Act is the United States' federal health privacy law, from 1996. Unlike GDPR, it does not cover health data wherever it is. It binds particular actors. Health-care providers, health plans and clearing houses are called covered entities, and the companies that handle data for them are called business associates. Three rules matter here. The Privacy Rule says who may see or share health information and for what. The Security Rule sets the safeguards for that information in electronic form. The Breach Notification Rule requires patients and the authorities to be told when data has been exposed. When a US clinic uses HDS, HDS acts as its business associate under a signed agreement, and these rules bind HDS as well.
SOC 2. SOC 2 is not a law. The American Institute of Certified Public Accountants publishes it as a standard that describes how an organisation should protect the systems and data it runs for others. It covers five areas, which are security, availability, processing integrity, confidentiality and privacy. An independent audit firm examines the organisation's controls and issues a SOC 2 report, either on their design at one point in time or on how they operated over a period of months. US hospitals and health companies routinely ask their suppliers for one. The Compliance Matrix maps HDS's controls to these criteria so that an implementer can see where HDS stands before any such audit. The formal report is a separate step.
Where HDS stands. HDS is compliant by design, and it goes further than any of these four frameworks requires. Each of them allows some use of health data without the person's consent, for care, for billing, or for research under safeguards. On HDS, data can be seen by or shared with anyone else only if the person it describes, the patient who is the HDS user, has explicitly consented to it. The Compliance Matrix adds no protection of its own. It records how exactly HDS meets each obligation of the strictest health data regulations in the world, and says for each one whether the open-source platform, HDS as operator, or the implementer building on HDS carries it.
| Patient right / obligation | Legal basis | Platform primitive | Carried by |
|---|
This table shows a selection of patient rights, drawn from this paper and the live Compliance Matrix. The complete record covers every obligation across the platform, HDS and implementer layers. It is published at compliance.datasafe.dev and kept current.
Consent in HDS is granular, revocable, and auditable by design. When a clinician or researcher requests access, the patient receives a plain-language explanation of what is requested, for what purpose, and for how long, and approves or declines with a single action. Every access event is logged with a timestamp, the accessor's identity, and the scope of data accessed.
HDS's architecture makes it structurally impossible to use data without a consent record, because the technical access control and the consent record are the same object.
The EHDS's secondary-use framework is built on the same logic: standardised, auditable consent pathways that make research legally publishable across jurisdictions. HDS was designed from inception for alignment with the EHDS: its consent, audit, and interoperability choices track the regulation's requirements as they now stand, with the implementing acts that will fix the detail still to come, so no compliance can yet be claimed by anyone. The aim of that readiness is that research conducted through the platform can be published and reproduced in European and international contexts without the retroactive consent renegotiations that have derailed studies built on older data infrastructure.
There is more than one way to protect privacy in research. A growing field focuses on privacy-enhancing technologies: methods that let scientists learn from health data without ever seeing the identifiable records behind it. HDS takes a complementary route: rather than disguising data after it has been collected, it protects privacy at the source, by making each patient the owner of their data and requiring explicit consent before anyone can read it. The two approaches are not in competition: a study running inside the EHDS could pair HDS's consent layer with these technologies.
Because consent and access control are the same object, the audit trail required for publication is generated as a by-product of the pipeline rather than reconstructed after the fact.
What Architecture Cannot Do
It would be a mistake, and a common one, to read the preceding section as a claim that architecture solves the problem. It does not. Good architecture removes a specific class of failure: it makes consent enforceable, audit automatic, and portability routine. The harder problems sit outside the code.
Recruiting participants and keeping them engaged over years, securing ethics approval for each study, persuading busy clinics to change how they work, reconciling data-protection regimes that genuinely conflict across borders, and turning real-world inputs into research-grade evidence are all harder than the platform, and most are not engineering problems at all. HDS has a working answer to some. Adoption is driven by liability offload and patient-side portability rather than goodwill, and ethics review is built into the model at the project level. Others are only partly addressed: cross-border legal conflict is reduced by holding data under Swiss controllership and a single consent architecture, but reduced is not dissolved. Long-term engagement, and the slow work of earning clinical trust, stay genuinely hard, and we treat them as such rather than pretending the technology disposes of them.
None of this is free. Built to its full ambition, across enough partners and territories to matter, infrastructure of this kind will take sustained investment, and HDS is candid that architecture and goodwill alone will not carry it there. That makes the path forward a strategic choice for the field rather than a technical one. Clinical research today pays a great deal for data and analytics from a small number of large commercial intermediaries, IQVIA chief among them; that spending is real, recurring, and growing. The same resources, directed into shared, consented, non-profit infrastructure, would lower the long-run cost of research for everyone who draws on it, while leaving the data with the people it describes. We state that saving for what it is: the HDS economic hypothesis, not yet a measured result, since no deployment at scale has tested it. The hypothesis itself is precise. In the current model, value is captured by controlling health data; in the HDS model, control of the data is withdrawn from the market and value moves to what remains legitimately priceable, the processing: structuring, validation, consent management, and analysis. If the shift holds, it does more than reduce cost. Patient populations that no intermediary today has a commercial reason to include can enter research directly; decentralised clinical trials become easier to run over consented, portable records; and each of those openings creates opportunities for every stakeholder, not for the data holder alone. Continuing with the commercial model is a reasonable choice. So is helping build a common alternative. HDS is built for the partners drawn to the second, and how far it travels will track how many of them choose it.
Application of the Principle of Subsidiarity
Subsidiarity holds that decisions should be made at the most local level capable of handling them effectively, with higher-level actors taking responsibility only for what cannot be managed below.
Applied to health data, it produces a clear architecture: the patient is the primary decision-maker about their own data; the institution accesses only what the patient explicitly permits; and the regulatory framework ensures that the patient's decision is legally enforceable and auditably documented.
The failure of most health data systems is that they invert this order. Data is collected at the institutional level, aggregated into systems owned by hospitals, insurers, or commercial platforms, and the patient's access to their own records is an afterthought. The result is a population contributing data to decisions made without them, appearing in systems they cannot see, coded as anonymised identifiers rather than as people with legal rights over their own information. The cost is practical, not only legal: when a person is reduced to an anonymised record, the knowledge they hold about their own body and history is thrown away, and that knowledge is often what prevents a missed diagnosis or keeps a participant enrolled in a study. The evidence gets stronger, and trials hold on to their participants, when patients help drive the record.
Patient-Controlled Data Sovereignty
HDS places the patient at the apex of the permission hierarchy. No doctor, researcher, or commercial partner can access a patient's data without explicit, time-limited, purpose-specific consent. HDS itself does not read patient data for any purpose the patient has not approved; the permission architecture enforces this limitation technically at every API call — each access is scoped to the streams the patient has explicitly granted, and every read is recorded in an audit log — and not merely as a matter of contract. The reason to enforce this technically, rather than to rely on an undertaking, is that consent taken on its own is an unreliable safeguard for the continuous data that wearables and health applications generate; legal scholarship has shown that consent regimes tend to individualise responsibility and to presuppose a parity of power between patient and data holder that rarely obtains, which is why HDS treats consent as one layer of a structural guarantee rather than as the guarantee in itself. Patient data sovereignty, understood concretely, amounts to a specific technical and legal guarantee rather than a general disposition in favour of privacy: the patient is the only party able to authorise access to their records, and the platform retains no independent capacity to grant such access on the patient's behalf.
HDS as the Subsidiary Infrastructure Layer
HDS occupies the layer between individual patients and the research and clinical institutions that need access to their data. By holding the data-controller role, HDS absorbs the GDPR, nLPD, and HIPAA compliance obligations that would otherwise fall on each partner institution individually. A clinic integrating with HDS does not need to build its own consent-management system, audit-logging infrastructure, or data-sovereignty architecture. It inherits HDS's.
This is subsidiarity in the other direction: HDS handles at the platform level what should not be duplicated across dozens of individual clinical and research environments. A small academic group can run a study with the same legal rigour as a large hospital network, because the compliance burden is carried centrally rather than replicated locally. The "Download My Data" module, deployed in June 2026, implements GDPR Articles 15 and 20, HIPAA §164.524, and Swiss nLPD Articles 25 and 28: the patient's right to access, receive, and transfer their complete health record, executable by any patient without institutional approval or legal process.
How Adoption Happens
Clinicians do not adopt new software out of solidarity; they adopt it when it removes work. HDS is built around that fact. For a clinic, the hook is not the mission but the offload: integrating means shedding the data-controller liability, the consent tooling, and the audit infrastructure it would otherwise have to build, staff, and defend. The technical step is light, because the API is public and open, so the real onboarding work is understanding the clinic's workflow and settling the legal terms, not a software project.
Adoption also pulls from the patient side. Because every patient can export and move their full record, a patient already on HDS can bring their history to a new clinic, and a clinic that wants that history has a reason to connect. Patient associations compound the effect: in rare disease, organisations like ASSEDEA, Raggiungere, and DysNet bring whole communities to the platform at once, rather than one clinic at a time. The growth path is therefore not a solidarity appeal made to five hundred clinics in turn, but a loop that compounds: each integrated partner lowers the cost, and raises the value, of the next one joining.
Application of the Principle of Solidarity
Solidarity means that a community's collective resources — including health data — should be organised to benefit those whose needs are greatest. In health data, the group with the greatest unmet need is clear.
HDS is a general-purpose health-data platform, not a women's health product. It is being proven in women's health first because this is where data fragmentation, commercial privacy abuse, and research neglect intersect most severely: a model that holds here, against the hardest version of the problem, transfers to any therapeutic area. The rare-disease work described later in this section is the first demonstration that it does.
Women have been consistently underrepresented in clinical trials and medical research. Key areas including menstrual health, reproductive ageing, and sex-disaggregated outcomes remain insufficiently studied. The consequences are clinical: diagnostic delays, ineffective treatments, and conditions affecting millions of women — PCOS, endometriosis, premenstrual dysphoric disorder, unexplained infertility — managed on incomplete evidence.
The cost of that gap is now quantified. A 2024 analysis by the World Economic Forum and the McKinsey Health Institute found that women spend, on average, about 25% more of their lives in poor health than men, and that closing the women's health gap could add at least $1 trillion to the global economy each year by 2040: the equivalent of roughly seven additional healthy days per woman, every year. The report traces much of the gap to a single root cause: women are understudied. Research too often fails to account for sex, and conditions that predominantly affect women remain underexamined. A standardised, consented, research-grade data infrastructure is a direct response to that diagnosis: the gap is, at its foundation, a data gap.
Digital health technologies have created an enormous amount of women's health data in the past decade. Cycle-tracking apps are used by hundreds of millions of women; wearable sensors measure temperature, heart-rate variability, and hormone levels continuously. None of this data is research-grade. Most of it sits with individual companies, each holding its own slice in its own format, with no shared standard and no straightforward route to combine it for research. This largest real-world menstrual dataset — hundreds of millions of app users — stays locked in profit-driven companies with no stewardship mechanism to open it for research; recent analysis calls for exactly such stewardship, or company–research collaborations, to be established. The loss is real, and the industry recognises it: on the pharmaceutical sector's own account, data from apps and wearables used by patients at home is a valued source of evidence for shaping research and demonstrating what treatments are worth. That value stays out of reach for as long as the data sits in separate, unconnected systems.
HDS does not close that gap by competing for those hundreds of millions of users. It closes it by becoming the layer they connect through. Because HDS holds the controller role and one interoperable data model, every platform that integrates adds its consented data to the same research-grade pool: the dataset HDS can offer a researcher is the sum of its partners, not its own sign-ups. The first integrations already cover several of the most widely used cervical-fluid data sources. And for the questions that matter here, a smaller dataset that is standardised, multi-method, and fully labelled trains a model better than a far larger one that is noisy, single-method, and unconsented; the conversion layer that maps six charting systems onto one scale is what turns scattered records into a sample a study can actually pool. Reaching the volume any given analysis needs then comes down to how many platforms connect, not to out-growing the incumbents.
The Women's Health Gap
The Cervical Fluid Data Gap
Cervical fluid is one of the most thoroughly documented biological markers of the fertile window. Peak Day of cervical-fluid discharge shows high agreement with other indicators of ovulation across multiple independent research protocols. Proteomic research has demonstrated that cervical-fluid composition changes systematically across the menstrual cycle, with protein-expression patterns that carry potential as non-invasive diagnostic biomarkers, with distinct proteomic signatures identified in endometriosis.
The problem is fragmentation. Fertility Awareness-Based Methods (FABMs) — the family of methods that teach women to observe and record cervical fluid — include at least six major systems, each using a different classification and scoring vocabulary. The Billings Observation uses a qualitative sensation-and-appearance scale; the Creighton Model charts standardised descriptions of the discharge (sticky, cloudy, tacky, clear, stretchy, lubricative) with a stamp system; FEMM uses a four-category classification of sensation and appearance. Each system produces data about the same biological phenomenon, recorded in a format incompatible with every other.
We have not found, in the platform landscape reviewed for Appendix A or in the published literature, a platform, research registry, or clinical database that makes research-grade, multi-method cervical-fluid data available to external researchers with full patient consent and a complete audit trail; nor, to our knowledge, has a unified conversion layer between the scoring systems of these methods previously been published or deployed. We state this as the result of a documented search, not as a proven negative, and would welcome a counter-example.
HDS's First Interoperability Model
HDS has built what is, to our knowledge, the first open, publicly documented conversion layer between the cervical-fluid scoring systems used by major FABM methods. The Cervical Fluid Model maps Billings, Creighton, FEMM, Marquette, and others — together with Mira's quantitative hormone readings — to a common HDS data model using a weighted distance function across nine clinical dimensions.
Data grounded in the HDS Cervical Fluid Model reference (15 methods → 9 weighted dimensions: threadiness 20%, stretchability 18%, lubricative 15%, transparency 12%, wetness 10%, fluidity 9%, sensation 7%, volume 5%, colour 4%). Live demo: healthdatasafe.github.io/model-cervical-fluid. Mapping levels here are simplified (none → low → mid → high → peak) for illustration; the production model uses continuous vectors.
Independent validation in progress
The Cervical Fluid Method Explorer and its underlying conversion model are fully operational, but their clinical reliability has not yet been independently confirmed. A peer-reviewed publication is in preparation, and the model is being submitted for evaluation by key opinion leaders in fertility-awareness medicine and reproductive science. Until that review is complete, it should be treated as an open research instrument rather than a clinically validated diagnostic tool.
Health Data Safe is a non-profit foundation: this work is funded by grants and donations. Contributions go directly to the validation study and to building what is, to our knowledge, the first openly consented, multi-method cervical-fluid research dataset.
The model is open source and allows any researcher to compare and standardise cervical-fluid observations across methods. It opens cross-method research that, to our knowledge, no published tool has supported before: a study can include participants using Creighton, Billings, and FEMM simultaneously, with their observations mapped to a shared representation that preserves the clinically relevant dimensions of each.
This has direct clinical applications. Cervical-fluid biomarkers have demonstrated utility in diagnosing and managing cycle disorders in PCOS and in developing non-invasive biomarkers for endometriosis. Wearable sensors measuring physiological correlates of cycle phase can predict fertile-window timing but cannot replace direct cervical-fluid observation. A standardised, multi-method dataset would allow these signals to be validated against each other at a scale not previously possible. HDS's initial partner integrations — Mira, FEMM, Cyclefeminin.net, and Read Your Body — cover the majority of FABM-compatible data sources currently in use. The research infrastructure to build the first ethically consented, multi-method, cross-platform cervical-fluid research dataset exists and is operational.
Building an integrated environment for a fertility-restoration clinic
The restoration of fertility is a clinical discipline that treats the underlying pathology of cycle disorders rather than suppressing their symptoms and operates through a dual-record system: structured patient charting of cervical biomarkers and associated symptoms across multiple cycles, and practitioner interpretation of that longitudinal record to guide diagnosis and treatment. The clinical value of this model depends entirely on the integrity and continuity of the underlying data; yet no dedicated digital infrastructure has existed to support it at the standard that sensitive health data requires.
HDS is developing, in collaboration with clinical partners in the United States and internationally, an integrated environment comprising a patient application for structured fertility tracking — incorporating on-demand biomarkers: cervical-fluid observations, basal body temperature, cycle annotations, symptom logs, and supplement and medication records — and a clinician dashboard providing practitioners with the consented longitudinal record, pre-consultation data forms, and shared documentation in the formats used by fertility awareness instructors worldwide. Several innovative and ambitious organisations are already partnering with HDS to build and deploy this infrastructure. HDS acts as data controller for all partner platforms, with granular patient consent governing every access event.
Health Data Safe is a non-profit foundation: this work is funded by grants and donations. Contributions go directly to building the patient application and the clinician dashboard.
Serving the Rare Disease Community
HDS began with women's health because the gap was largest and the infrastructure to address it most clearly missing. The platform's architecture is not specific to fertility: it is a general-purpose health-data governance infrastructure that can expand into any therapeutic domain.
The rare disease community faces a structurally analogous problem. Rare conditions — defined in Europe as affecting fewer than 1 in 2,000 people — are individually small populations whose clinical data is scattered across specialist centres, national registries that do not communicate, and patient-held records with no standardised format. Clinical trials in rare diseases are chronically underpowered because patient recruitment across borders requires consent frameworks that do not exist.
An international registry for limb malformations, owned by the families it describes
Limb malformations — congenital agenesis and dysmelia — affect approximately five in every 10,000 people worldwide, and no international patient registry records them. What exists sits in different hospitals in different countries, in systems that cannot exchange it. Of the 72 registries that record these conditions, 22 name a condition itself and the other 50 capture it only inside a broader group, so two national figures cannot honestly be set side by side. The cost of that fragmentation showed in France, where three clusters of transverse upper-limb agenesis came to light between 2007 and 2014, in Loire-Atlantique, Ain and Morbihan. The investigations led by Santé publique France with the regional registries found no common exposure, and families were questioned years after the birth, from memory.
DysNet, the international network of limb-difference associations, created the registry at its annual general meeting of 26 August 2026 and mandated Health Data Safe as its technical and operational partner. The registry belongs to the community it describes. Each person holds their own data account and consents study by study, and which research may be put to families at all is decided by the member associations and the DysNet board together. Buying the data, or receiving it in bulk without the consent of the people it describes, is excluded by design. Health Data Safe contributes its infrastructure in kind and takes on the data-controller role in full, so that volunteer associations run no servers and carry no legal or compliance burden. The data model maps onto ORPHAcodes and a shared minimum data set, so that French and Italian records form one comparable registry, and the registry will be declared in Orphanet’s European directory of rare-disease registries once it is live. ASSEDEA in France, which has supported families affected by limb agenesis for fifty years, and Raggiungere OdV in Italy, in its fortieth year in 2026, are the first two pilot associations.
DysNet states plainly that the registry does not exist yet, and that it has not yet earned the word: it will describe a community rather than count a population, it has no scientific committee for now, and data declared by families is not the same as data verified by a clinician. Earning the term is the roadmap, through a scientific committee, a written protocol, an agreed minimum data set and a published quality plan. What the network publishes is already open: a bibliography of 1,929 references, a teratogens register of 577 substances, the care-centre and researcher registers, and the epidemiology tables. The first pilots have been seeking funding since September 2026.
Health Data Safe is a non-profit foundation: this work is funded by grants and donations. Contributions go directly to building the patient application and launching the first pilots.
Why the HDS Model Applies
Rare disease patients are, as a group, among the most motivated and sophisticated contributors to their own health data. In a EURORDIS Rare Barometer survey of more than 2,000 patients and family members, 97% said they were willing to share their health data for research, while 80% wanted substantial or full control over how it is used: a combination of high willingness to contribute and a strong demand for control that maps precisely onto the HDS model. Many manage their conditions across multiple specialists, maintain their own records, and participate actively in patient-advocacy networks. The same Rare Barometer programme found that patients living with a rare disease wait on average close to five years for a diagnosis, frequently after consulting eight or more healthcare professionals. The HDS model, which couples full patient ownership and control with a decision to contribute to research that remains visible, auditable, and reversible at every stage, maps directly onto the behaviours of a population that already treats the management of its own health data as a personal responsibility. The compliance architecture built for women's health translates to this setting without modification, since FHIR-coded data, SNOMED-CT standardised events, bidirectional REDCap integration, and per-project ethics review are not specific to women's health at all; they are the properties of any platform designed to handle sensitive clinical data correctly, and they apply to rare-disease cohorts on the same terms.
A Better Economic Model for R&D
European orphan-drug regulation, established by Regulation (EC) 141/2000, rests on a recognition that rare disease patients have the same right to quality treatment as patients with common conditions. What the regulation also made visible is a genuine economic problem: rare conditions each affect so few people that development costs are hard to recover from the resulting market, so without support the research does not get funded. Market-exclusivity extensions and fee waivers help close that gap, and they have brought hundreds of orphan treatments to patients. They work on the cost-recovery side of the equation. What they do not yet address is the other side, lowering the cost and risk of the research itself, which is where shared, research-grade data infrastructure makes the difference. The same shift is now articulated from within the pharmaceutical industry: patient value should drive the entire medicine life cycle, end to end, with patient experience, increasingly captured from apps and wearables used at home, treated as evidence rather than anecdote.
Rigal (2017) argued, in doctoral research on European orphan-drug law, that resolving this tension requires a structural shift.
Tie the return on pharmaceutical research to the health value it creates for unmet needs, and even the smallest patient populations become worth investing in.Rigal (2017)
The practical implication is that rare disease research, at the transnational scale it requires, needs a foundation that commercial sponsors alone are unlikely to fund: shared infrastructure whose value to every participant does not depend on any one of them owning the data. That is precisely the model HDS has built for women's health. The rare disease data problem is, at its core, a fragmentation problem: patient populations that would be large enough for well-powered research if aggregated across borders are scattered across registries that cannot communicate. The HDS platform addresses exactly this: a single consent and data architecture that works across jurisdictions, with FHIR-coded, research-grade data that is structured and standardised from the moment of collection.
Current Development
HDS's current partnerships extend into rare disease contexts. The Foundation has designed its data model and consent infrastructure to accommodate condition-specific extensions, allowing rare disease research programmes to deploy custom data-collection forms, patient-reported outcome measures, and longitudinal tracking modules while inheriting HDS's compliance infrastructure. The first research cohorts under the HDS model will be in women's health and fertility, with rare disease cohorts following as the platform scales. The governance model — patient consent at the individual level, ethics-committee review at the project level, and federal oversight at the foundation level — remains the same across all domains. This mirrors a broader shift in how medical technologies themselves are now expected to be developed: with patients involved across the product life cycle, from initial concept through post-launch evaluation, rather than consulted only at the end.
Bibliography
I. Legislative & Regulatory Instruments ▾
II. Books & Doctoral Theses ▾
III. Journal Articles ▾
IV. Institutional Reports ▾
V. Online & Technical Sources ▾
Where HDS Sits: The Existing Landscape
A fair criticism of any paper written by the organisation it describes is that it can drift from showing a problem exists to asserting that its author is the answer. Those are different claims. This appendix is where the second one is held against the field.
This paper does not claim that HDS is the only credible health-data platform, or that it leads on every measure. It makes a narrower and checkable claim: the combination of properties it argues are necessary, namely individual ownership of the record, open cross-ecosystem interoperability, consent granular to each use and partner, storage under a sovereign jurisdiction beyond the reach of foreign data-access law, and an ethical user-controlled route into research, is not currently offered as a whole by any platform in wide use. HDS is built to occupy that gap.
The table below sets twenty operating platforms against those properties, from public information reviewed between May and August 2026. Most are strong on one or two axes and absent on the rest. Germany's ePA and France's Mon Espace Santé offer national interoperability and a sovereign jurisdiction, but the record is state-managed and research access is limited. Apple and Google reach hundreds of millions of people, yet consent is set at the app level and data sits under US jurisdiction. The consumer FemTech apps closest to HDS's domain rarely offer portability or any research pathway.
One route removes the operator altogether: an open-source personal record installed on the user's own hardware, so that no company holds a copy. Its most visible implementation, Fasten On-Prem, was archived as a read-only repository in July 2026, and the approach in any case does not supply custody and recovery, a data controller answerable in law, or a consented route into research. OpenEMR, the open-source clinic system, is filed with the institutional records below, because the instance belongs to the practice and not to the patient.
The closest existing peer is not a gap at all. Midata.coop, a Swiss non-profit cooperative, shares most of HDS's properties and has been live since 2015. The honest reading of this table is that HDS's distinct position is the combination of full individual sovereignty, a data-controller model that lifts liability off its partners, and a starting focus on the women's health data gap, rather than a claim to stand alone. One caveat on method: the comparison uses the criteria HDS itself argues for, so a reader who weights those criteria differently will rank the field differently. The table is offered so that judgement can rest on the evidence.
| Platform | Governance | Data ownership | Interoperability | Consent | Jurisdiction | Research |
|---|---|---|---|---|---|---|
| Health Data Safe ★healthdatasafe.org · in development | Non-profitSwiss foundation | User-ownedFull sovereignty | Open / FHIRCross-ecosystem by design | GranularPer use case & partner | Swiss vaultnFADP, no CLOUD Act | Yes: ethical opt-inUser-controlled |
| ▾ Closest: shared mission and data sovereignty | ||||||
| Midata.coopmidata.coop · Switzerland · live 2015 | Non-profit coopMembers own & govern | Member-ownedSwiss servers, multi-level encryption | FHIR / open sourceMIDATA Server (ETH / BFH) | Granular opt-inPer researcher & study | SwitzerlandYearly external audits | Yes: core mission |
| ▾ Close: FemTech-first or partial sovereignty | ||||||
| Ona FemTechona.health · live | For-profit | User dataApp-stored; no sovereignty framework | WearablesOura, WHOOP, Garmin; no FHIR | App-level | US-basedDelaware law; wearable data EU-first, copy on US servers | Limited |
| iYoni FemTechiyoni.app · live | For-profit | User dataClass I EU medical device | LimitedNo FHIR; 14 languages | App-level | EU / PolandCE-marked, GDPR | None stated |
| March Health FemTechmarch.health · live | For-profitTelehealth | User data | LimitedNo FHIR stated | App-level | US-basedDelaware inc.; California law; AWS & Hetzner hosting | None stated |
| Frame Your Future FemTechframeyourfuture.com · live | For-profitEmployer benefits (B2B2C) | User dataPlatform-managed | Limited | App-level | US-basedDelaware inc.; California law; CLOUD Act | None stated |
| Foundation 29foundation29.org · live · rare disease | Non-profitPatient-led | Patient-ownedNav29 | AI / document-basedNo FHIR stated | Patient-controlled | EU / SpainGDPR | Yes: clinical trials |
| ▾ Adjacent: partial overlap, different model | ||||||
| Function Healthfunctionhealth.com · US · live | For-profit | User-accessibleHosted by Function | Lab networkNo FHIR export | Membership-level | US serversCLOUD Act | Limited |
| Promtimepromtime.org · France · live | For-profitClinical platform | Patient-reportedPROM; clinician-mediated | PartialNo open FHIR | Clinical consent | France | Yes: core feature |
| Datanomia / Synomiadatanomia.ch · Switzerland · live | For-profitB2B for researchers | Anonymised / institutionalNo individual ownership | AI cohortsNo patient FHIR | Researcher-facingNo patient consent layer | Switzerland | Yes: core purposeReal-world evidence |
| IQVIAiqvia.com · US · global · live | For-profitNYSE-listed; world's largest health-data firm & CRO | Licensed / institutionalDe-identified data from claims, pharmacies, providers; no individual ownership | Proprietary analyticsNot patient-facing; no individual FHIR export | No patient consent layerSourced under vendor agreements | US-basedCLOUD Act; global operations | Yes: core businessRWE, analytics & clinical trials (CRO) |
| Biocanicbiocanic.com · US · live | For-profitB2B practitioner | Practitioner-managed | 300+ labs, 15 wearablesNo FHIR stated | Practitioner-managed | US serversCLOUD Act | None stated |
| Seqsterseqster.com · US · live | For-profitSeqster PDM, Inc.; B2B enterprise platform | User-retained (stated)Users keep ownership of uploaded data; platform acts as agent under licence | FHIRFHIR-based retrieval; TEFCA IAS provider | App-levelPatient-mediated access | US-basedDelaware inc.; California law; CLOUD Act | Yes: core businessTrial-recruitment & evidence products; terms allow sale with consent |
| Galeongaleon.care · France · growing | For-profitToken model | Hospital + patient token | PartialNo cross-ecosystem FHIR | Opt-in researchToken-gated | FranceHDS certified | Yes: token incentive |
| ▾ Distant: national records, medical B2B, or closed | ||||||
| Fertil.ai FemTechfertilai.com · US · live | For-profitB2B, doctors only | Provider-held | Clinical integrationNo patient export | Provider-controlled | US serversCLOUD Act | None stated |
| ePA (Elektronische Patientenakte)gematik.de · Germany · live | Public / Stategematik | State-managedOpt-out since 2025 | FHIR / nationalMandatory | PartialEmergency override | GermanyDSGVO | LimitedOpt-in pools |
| Apple Healthapple.com/ios/health · live | For-profitUS corporation | On-deviceiCloud E2E with ADP | iOS-onlyFHIR inbound; no Android | App-level only | Device / iCloud (US)CLOUD Act on non-E2E | LimitedSeparate Research app |
| Mon Espace Santémonespacesante.fr · live | Public / StateCNAM | State-managedView & restrict | FHIR / national | PartialEmergency override | FranceHDS-certified hosting | LimitedAnonymised pools |
| ▾ Most distant: big tech and institutional EHR, no patient sovereignty | ||||||
| Google Health / Health Connecthealth.google · live | For-profitNo ad-use per policy | Google-heldSome aggregate use | Health ConnectPartial FHIR | MinimalBroad at signup | US serversCLOUD Act | No user opt-in |
| Hospital / Clinic EHREpic, Meditech, Cerner · dominant today | InstitutionalProvider-controlled | Provider-heldAccess, not control | SiloedInstitution-bound | MinimalBulk at admission | VariesBy country | No direct opt-in |
| OpenEMRopen-emr.org · open source · live 2002 | Open sourceGPL-2.0; practice-operated | Practice-heldThe clinic runs the instance, not the patient | FHIR REST APIUS ONC-certified line (v8; v7 certification retired Feb 2026) | MinimalClinic-side, as in any EHR | Wherever hostedHIPAA-capable by configuration, not certified | No direct opt-inNo patient-controlled route |
Strength Partial / conditional Limit Public / neutral For-profit / institutional · ★ = reference
Source: Health Data Safe Foundation (2026), Personal Health Data Platforms: A Landscape Comparison (v3, May 2026), compiled from each platform's public documentation. Jurisdiction entries were verified in August 2026 from each company's own legal documents (privacy policies, terms of service) and public registry filings. "FemTech" marks platforms whose primary focus is women's health. The self-hosted and open-source EHR entries, and the Seqster entry, were added in August 2026 from each project's public documentation.
The table lists only systems in operation at the review date. Platforms that have ceased operating are excluded, whatever their historical interest: Microsoft HealthVault was discontinued in 2019, and LunaDNA, a Delaware company whose members received ownership shares in exchange for their health and genomic data under an offering qualified by the US Securities and Exchange Commission, closed on 31 January 2024 citing a critical shortage of funds; what became of members' data is not documented in its public materials. Robyn, acquired by Tot Squad and at the review date a waitlist page ahead of a relaunch as an AI doula service, is excluded on the same ground. Two active initiatives are absent for a different reason: they are not personal health data platforms. France's Health Data Hub is a state research intermediary that grants researchers access to national health data under an opposition (opt-out) model rather than individual consent, and Our Future Health, a UK charity with more than 2.7 million consented volunteers, is a research cohort whose participants contribute data but do not hold or manage a record of their own. Both belong to the institutional research landscape rather than to the platform category compared above.
Foundations without a platform
The table compares operating platforms, and its six criteria presuppose one: a body that runs no infrastructure cannot meaningfully be scored on interoperability or the granularity of its consent. The landscape nonetheless includes a second category that a sceptical reader will want accounted for, namely non-profit organisations that advocate patient-owned health data without operating any platform, and it sits outside the table because scoring it against these criteria would be a category error, not because it does not matter. The clearest documented case is the Etheros HealthData Foundation, a United States 501(c)(3) private foundation registered in Massachusetts as Etheros Healthdata Foundation Corp (EIN 93-4296924) and tax-exempt since December 2023. Its published output is analytical rather than operational: a 2024 report on decentralised health data management, co-produced with the Crypto Valley Association's Sustainability Working Group, and a 2025 report, “Decentralized AI in Healthcare: From Theory to Practice”. Its sole public filing, for the financial year ending December 2024, reports total revenue of USD 11,300, expenses of USD 7,241, and year-end assets of USD 4,059, with unpaid officers and no compensated staff. No operating platform is documented in its public materials as of August 2026.
The instructive difference is one of principle, not of scale. Etheros states its mission as empowering individuals to “own, share, and derive benefits from their health data”, names “fair compensation for data value” among the challenges it addresses, and is profiled as pursuing that end through decentralised marketplaces and tokenised rewards, in which sharing may be recognised with tokens or discounted services. The approach is not hypothetical: LunaDNA, noted above, operated it at platform scale, issuing ownership shares in exchange for members' data, until its closure in 2024. Stated on its own terms, the position has a clear logic: if health data is valuable and the patient is its rightful owner, it can seem only just that the patient be paid when that value is realised. HDS begins from the same premise of patient control and reaches the opposite conclusion. Its statutes, described in Section 2, treat health data as a common good: within the platform it may not be bought or sold by anyone, the patient included, and its use is confined to clinical care and ethically approved research. The two models therefore diverge on a question that patient ownership alone does not settle: whether health data may be traded at all.
The comparison earns its place here because it isolates what an operating platform adds to a principle. The conviction that patients should own their health data can be declared by anyone, and every organisation that declares it widens the constituency for the idea. What separates HDS's position from a declaration of intent is not a stronger claim: it is a supervised legal form under Swiss federal oversight, statutes whose commitments cannot be voted away, and deployed, documented components. The Etheros material was reviewed in August 2026; the reader is invited to apply the same test to any organisation in this field, HDS included.
Acknowledgments
This white paper was researched and written by the author with drafting and editorial support from Claude (Anthropic) and Gemini (Google). All sources, figures, and positions were reviewed and verified by the author, who takes full responsibility for the final text.