— 18 mai 2026 · 8 min de lecture

FHIR Bulk Data Export : pattern et outils

FHIR R4 (octobre 2019) a publié l'Implementation Guide Bulk Data Access pour répondre à un besoin que les APIs RESTful FHIR seules ne couvraient pas : exporter de gros volumes de données patient ou population de façon asynchrone et efficace.

Le problème de l'export massif en FHIR

L'API REST FHIR classique répond très bien à « donne-moi le patient 12345 et ses 500 ressources cliniques liées ». Elle est mal taillée pour « donne-moi tous les patients vus en 2025 par mon réseau de 800 médecins, soit environ 4 millions de Bundles ». La pagination FHIR (Bundle entry next) fonctionne, mais en pratique le client doit faire des milliers de requêtes synchrones — coût réseau, latence cumulée, charge serveur, échecs partiels difficiles à reprendre.

Bulk Data Export résout ce problème par un pattern asynchrone classique en deux temps : kickoff (le client demande l'export, le serveur répond 202 Accepted avec un Content-Location pour suivre le statut), polling + download (le client interroge ce URL périodiquement jusqu'à readiness, puis récupère N fichiers NDJSON pré-générés, un par ResourceType).

Phase 1 : kickoff

Trois endpoints standard : POST [base]/$export (export system-level, tout le contenu), POST [base]/Patient/$export (export de tous les patients accessibles), POST [base]/Group/[id]/$export (export d'un groupe pré-défini de patients). En-tête obligatoire : Accept: application/fhir+json et Prefer: respond-async.

Paramètres courants : _type (filtre par ResourceType, ex. Patient,Encounter,Observation), _since (incremental sync depuis une date), _typeFilter (filtres FHIR Search avancés, support optionnel). Réponse type : 202 Accepted avec Content-Location pointant vers l'URL de polling du job.

Phase 2 : polling et download

Le client interroge l'URL de polling avec GET à intervalles raisonnables (le serveur peut retourner Retry-After en header pour suggérer la cadence). Pendant l'export, réponse 202 Accepted avec X-Progress indiquant l'avancement humain-lisible.

Quand l'export est prêt, réponse 200 OK avec un manifeste JSON contenant transactionTime, request (l'URL kickoff), requiresAccessToken (true/false), et un tableau output listant les fichiers : chaque entrée a type (ResourceType) et url (URL signée à télécharger). Les fichiers sont en NDJSON (Newline-Delimited JSON) — une ressource FHIR par ligne, faciles à streamer.

Autorisation : SMART Backend Services

L'IG Bulk Data spécifie l'usage de SMART Backend Services Authorization (un sous-ensemble de SMART on FHIR pour les contextes machine-to-machine sans utilisateur). Le client s'authentifie via JWT signé avec sa clé privée, le serveur vérifie via la clé publique enregistrée (JWKS endpoint). Les scopes utilisés : system/Patient.read, system/*.read, etc. Pas d'utilisateur final, pas de consentement individuel — le contexte est un échange entre systèmes établis.

Pourquoi NDJSON et pas un Bundle géant

Le choix du format NDJSON (chaque ligne est un JSON FHIR autonome) au lieu d'un Bundle FHIR géant est délibéré. NDJSON se streame ligne par ligne sans charger le fichier en mémoire — essentiel pour des exports de plusieurs Go. Il est trivial à découper, à reprendre après échec (offset par ligne), à parser en parallèle avec des workers indépendants. Un Bundle FHIR unique forcerait à parser tout le document avant le premier traitement.

Le coût : NDJSON n'est pas un format FHIR « normatif » avant l'export, ce qui crée parfois confusion. Les bonnes implémentations vérifient que chaque ligne est une ressource FHIR valide avant d'utiliser.

IPS (International Patient Summary) en bulk

L'IG International Patient Summary (HL7 normative depuis 2024, publié en coopération avec ISO 27269:2021) définit un sous-ensemble structuré du dossier patient — allergies, médications, problèmes actifs, résultats labo récents — pour échange transfrontalier. Bulk export d'IPS pour un réseau : combiner $export?_type=Bundle&_typeFilter=Bundle?type=document, ressource Composition profilée IPS. Cas d'usage typique : alimenter un Patient Summary Service européen (cross-border eHealth via eHDSI) depuis une nation membre.

Outils de référence en 2026

• Reference Implementation Bulk Data Server (smarthealthit.org) — référence de la SMART team, idéale pour tests interopérabilité.
• HAPI FHIR JPA Server — bulk export natif depuis HAPI 6.x, supporte system, patient, group exports avec SMART Backend Services.
• Smile CDR — distribution commerciale d'HAPI, scale bulk export sur cluster.
• IBM Linux for Health FHIR Server — supporte bulk export depuis 2020, cible enterprise.
• Firely Server — implémentation .NET supportant bulk export.
• bulk-data-client (sandbox SMART) — CLI client de référence pour tester un serveur, télécharger en parallèle, gérer reprise.

Conclusion : un pattern, plein d'outils

FHIR Bulk Data Access n'est ni révolutionnaire ni complexe : c'est un pattern asynchrone classique, bien spécifié, bien outillé. Il résout le besoin précis « extraire un grand volume de données patient » sans réinventer FHIR. À l'heure des données de santé exploitées massivement pour la recherche, l'IA clinique et le reporting réglementaire, c'est devenu une compétence de base pour toute équipe FHIR. Pour le contexte global, voir notre page introduction à FHIR.