Privacy-First Research with OpenSAFELY • Eli Holderness & Hannes Lowette

OpenSAFELY is built on a foundational philosophy: instead of moving sensitive data out of its secure environment, the analysis must be taken to the data. This principle is realized through a set of tools and a rigorous process designed to protect patient privacy while enabling vital public health research on a dataset of approximately 58 million patient records in the UK.

The OpenSAFELY Model: Taking Code to the Data

The core of the OpenSAFELY model is to prevent researchers from ever having direct access to the raw, sensitive patient data. The workflow is designed around security and reproducibility:

1. Code Development: Researchers write their analysis code in a public GitHub repository. They can test their code locally against dummy data, ensuring the logic is sound before submission.
2. Job Submission: The code is submitted to the OpenSAFELY jobs server, which schedules it to be run inside a highly secure environment where the real patient data resides.
3. Secure Execution: The code, including queries written in a specialized language, runs within the secure backend. Even the OpenSAFELY team has very limited telemetry and no direct access to the data.
4. Output Checking: Before any results are released to the researcher, they are scrutinized by trained “output checkers.” These individuals examine the aggregated outputs (like tables and graphs) to ensure they are not “disclosive”—meaning they cannot be used to identify an individual or a small group. This human-in-the-loop process is a critical privacy-preserving step.

ehrql: The Domain-Specific Language for Healthcare Records

To facilitate this process, the Bennett Institute developed ehrql (Electronic Healthcare Record Query Language), a Domain-Specific Language (DSL) built on Python.

• Abstraction and Consistency: ehrql provides a consistent way to query disparate healthcare datasets. It abstracts away the specific database schemas of different electronic healthcare record providers (like TPP or EMIS).
• Backend Agnostic: A researcher writes a query once in ehrql. The toolchain then compiles this into the appropriate SQL dialect for the target database (e.g., MySQL for TPP’s system). This ensures that research is portable and not locked into a single provider’s data structure.
• Security by Design: The compilation process from ehrql to SQL involves intermediate steps (like serializing to JSON) that allow for verification. This helps enforce rules to prevent disclosive queries, such as those that would return results for only a single patient.

Enforcing Rigorous and Reproducible Science

The OpenSAFELY model inherently changes the research methodology, introducing what some might see as constraints, but which ultimately foster better science.

• Hypothesis-Driven Approach: The longer feedback loop and lack of direct data access prevent “p-hacking,” where a researcher might repeatedly tweak parameters to force the data to support a hypothesis. Instead, it compels researchers to form a clear, upfront hypothesis and a corresponding analysis plan.
• Transparency and Reproducibility: A key requirement is that any code used for a published paper must be made public. This transparency allows peers to review the methodology, question analytical choices (e.g., why certain patient groups were excluded), and reproduce the results, which is a cornerstone of the scientific method.

Working with Real-World Clinical Data

A significant challenge is that the data was not collected for research; it was collected by General Practitioners (GPs) for providing primary care.

• Data Granularity: The level of detail may not be what a researcher would ideally want. For example, a GP might record a prescription for a general medication like “ibuprofen,” whereas a researcher might be interested in a specific formulation or brand. This is a practical limitation of using operational data for research.
• Incentives: There is no incentive for GPs to record data in a more granular, research-friendly way, as it would complicate their primary job of patient care. The system must work with the data as it is.

The Centrality of Patient Trust

The entire system is predicated on maintaining patient trust.

• The Risk of Erosion: The data belongs to patients, and its use is a privilege. If patients lose trust that their data is being handled responsibly, they can opt-out of its use for research purposes. A significant rise in opt-outs would devalue or even destroy the viability of the dataset for scientific study.
• Public Engagement: To mitigate this risk, OpenSAFELY has a dedicated Patient and Public Involvement and Engagement (PPIE) team to address concerns and ensure the public good of the research is clear.

The Future: A Blueprint for Responsible Data Research

The vision for OpenSAFELY extends beyond healthcare. The philosophy of taking the code to the data is a powerful blueprint for any domain dealing with sensitive information. There is potential to create similar “OpenSAFELY” models for pensions, education, and other areas, making it the standard for conducting secure, transparent, and reproducible research that benefits society.

• Tags:
• OpenSAFELY
• Ehrql
• Data Privacy
• Reproducible Science
• Healthcare Data
• Trusted Research Environment
• Python
• DSL