Hospital health data warehouses and France's Health Data Hub: pipeline architecture for research

Direct answer

A French hospital health data warehouse (entrepôt de données de santé, EDS) pulls together EHR, PMSI hospital-discharge, laboratory and clinical-report data for research. It is set up under the CNIL's 2021 framework (a simple declaration of conformity when it rests on a public-interest mission) or under a specific authorisation, and every project that uses it needs its own formality. The Health Data Hub, legally the Plateforme des données de santé (PDS), is the access point for the national SNDS database; it is leaving Microsoft Azure for Scaleway, selected in April 2026, with migration announced for late 2026 to early 2027. On the technical side, the pattern that holds up is per-source ingestion, pseudonymisation at the door, OMOP standardisation and isolated project workspaces.

Two different things: the EDS and the SNDS

An EDS belongs to a hospital or hospital group. The SNDS is a national claims and administrative database. Pipelines, access rules and data granularity have little in common.

The SNDS site lists its components: the three historical databases, the planned addition of disability data from the departmental MDPH agencies and a sample of supplementary insurers' data, and a retention period of nineteen years on top of the collection year, followed by an archiving period.

On the hospital side, AP-HP went first: its warehouse received the first CNIL authorisation granted to an EDS in January 2017 and aggregates data from its 38 hospitals. Other university hospitals followed; many are now scaling up rather than starting from scratch.

The regulatory frame, seen from the pipeline

Setting up the warehouse. The CNIL adopted a framework for health data warehouses (deliberation no. 2021-118 of 7 October 2021). It only covers warehouses based on a public-interest mission (GDPR article 6(1)(e)). A compliant warehouse goes live on a declaration of conformity; one that departs from the framework needs an authorisation. The framework covers building the warehouse, not reusing it: every research project, study or evaluation on its data goes through a reference methodology (often MR-004 for research not involving human participants) or an authorisation.

Access to the SNDS. The SNDS documentation describes the access routes. Public-service bodies listed by decree have permanent access. Everyone else follows a four-step standard procedure: a file lodged with the PDS, which checks completeness; an opinion from CESREES, the scientific and ethics committee, on methodology and public interest (one month); CNIL authorisation (two months, renewable once); delivery into a project workspace (about two months). Health-product manufacturers and insurers get restricted access, with prohibited purposes.

SNDS reference methodologies. For the most common cases the CNIL has approved MRs that avoid an individual authorisation: MR-005 for public-interest processing and MR-006 for processing under legitimate interests, notably by manufacturers, on SNDS and emergency-department summary (RPU) data. MR-006 defines a "secure bubble": infrastructure that isolates extractions so they cannot be merged. That is an architecture constraint as much as a legal one.

Hosting: HDS, SecNumCloud and the PDS migration

The PDS has hosted its data on Microsoft Azure since 2019, a choice criticised from the start because of exposure to US law. After a tender launched in February 2026, the government selected Scaleway in April 2026. When the award was announced, Scaleway was still going through SecNumCloud qualification; the switch of the main SNDS database is expected between late 2026 and early 2027. Check ANSSI's list for the current status.

The legal context explains the choice. Article 31 of the SREN law and decree no. 2026-272 of 14 April 2026 require a cloud protected from extraterritorial laws for particularly sensitive data, and the PDS is among the entities covered. For a hospital EDS hosted by a third party, the legal baseline remains HDS certification, with storage exclusively in the EU/EEA since September 2026; see HDS health data hosting for software vendors.

Pipeline architecture, from source to project workspace

Splitting the pipeline into zones, each with its own access rights, keeps it auditable:

1. Landing zone (identifying). HL7 v2 ADT and ORU feeds from the EHR and the lab system, PMSI extracts supplied by the medical information department (DIM), DICOM metadata, clinical reports. Access limited to the integration team, short retention, no researcher access.
2. Pseudonymisation. Identifiers (IPP, NIR, INS) are replaced at entry with a pseudonym computed with a key held by a trust function separate from the warehouse team.
3. Standardised zone. OMOP model, standard vocabularies, quality checks.
4. Project workspaces. One extraction per authorised project, limited to the approved variables and period, with no way to join two extractions.
5. Outputs. Results checked before export (small cell counts, re-identification risk).

Pseudonymisation deserves code rather than a diagram. A keyed HMAC, rather than a plain hash, stops anyone from recovering an IPP by hashing every possible value. Both keys live in an HSM or KMS run by the trust function, never in the warehouse:

import datetime
import hashlib
import hmac

PSEUDO_KEY = load_key("eds-pseudo-v3")
SHIFT_KEY = load_key("eds-shift-v1")

def pseudo_id(ipp: str) -> str:
    return hmac.new(PSEUDO_KEY, ipp.encode(), hashlib.sha256).hexdigest()

def date_shift_days(ipp: str) -> int:
    # Stable per-patient shift in [-180, +180] days
    digest = hmac.new(SHIFT_KEY, ipp.encode(), hashlib.sha256).digest()
    return int.from_bytes(digest[:4], "big") % 361 - 180

row = {"ipp": "800000123", "birth_date": "1971-04-02", "loinc": "15074-8", "value": 5.4}
shift = datetime.timedelta(days=date_shift_days(row["ipp"]))
out = {
    "person_source_value": pseudo_id(row["ipp"]),
    "birth_date": (datetime.date.fromisoformat(row["birth_date"]) + shift).isoformat(),
    "measurement_source_value": row["loinc"],
    "value_as_number": row["value"],
}

Three decisions belong in the CNIL file. Date shifting protects identity but distorts seasonal analyses; many warehouses keep real dates inside the secure environment instead. Rotating the key changes every pseudonym, so version it. Free text contains names, addresses and phone numbers; it needs NLP de-identification, measured on an annotated sample, before any researcher sees it.

OMOP standardisation: what goes where

The OMOP common data model has become the default for European research networks. The OHDSI documentation gives CDM v5.5 as the current version; check which version your partners expect before freezing your scripts.

French codes are where the real work is: ATIH extensions to ICD-10, CCAM, national drug codes. Depending on the vocabulary release you load, some of them will need a local mapping, kept alongside the original code in the _source_value columns so it can be redone. FHIR then serves as the transport format between EHR and warehouse, OMOP as the analysis format; the details are in the FHIR to OMOP pipeline.

Governance: what the architecture must make possible

• Transparency. The CNIL framework requires informing patients, which in practice means a portal listing ongoing projects.
• Objection. A recorded objection must apply to every new extraction, including for projects already authorised. Keep an exclusion list at pseudonym level, applied at extraction time; the mechanics are covered in GDPR health data rights in integration.
• Traceability. Who accessed which project workspace, for which project, with which query.
• Catalogue. A current data dictionary with completeness rates per variable and per period. It saves researchers weeks, and the EHDS will require it.

What the EHDS will change

Regulation (EU) 2025/327 creates the European Health Data Space. Member states must designate their health data access bodies (HDABs) by 26 March 2027, and the secondary-use chapter applies from March 2029. The PDS sets out this timeline; the national strategy considers giving it that role, and a bill was announced for 2026. At the time of writing I found no official designation, so check before building a pitch on it.

For a hospital acting as data holder, the practical stakes are twofold: describing its datasets for a national catalogue, and being able to make them available under an HDAB permit. A warehouse already standardised on OMOP, documented and isolated per project starts well ahead. The EHDS guide covers the full timeline.

Common mistakes

• Treating pseudonymised data as anonymous. It is still personal data under GDPR.
• Storing the pseudonymisation key in the same cloud project as the warehouse.
• Opening free text without a measured evaluation of de-identification.
• Mapping once and forgetting: vocabularies change, so version your mapping tables.
• Copying extractions onto researchers' laptops instead of keeping computation inside the project workspace.

If your hospital or company is structuring an EDS or a research pipeline into OMOP, I can help with the design as part of healthcare data analytics.