FHIR Bulk Data Access ($export)

FHIR Bulk Data Access, aussi appelé « Flat FHIR », est un guide d'implémentation de HL7 International basé sur FHIR R4^[1]. Il existe parce que les API FHIR ordinaires fonctionnent bien pour de petites quantités de données, mais peuvent exiger des centaines de milliers de requêtes pour de grands exports ; le guide standardise l'exportation de données en masse d'un serveur FHIR vers un client préalablement autorisé^[1]. Un usage typique est celui d'une organisation de soins qui transfère périodiquement des données cliniques mises à jour d'un DPI vers une base de données de recherche^[1].

L'opération d'export. L'opération $export lance de manière asynchrone la création d'un fichier d'export pour tous les patients, pour un groupe défini de patients ou pour toutes les données FHIR du serveur^[2]. « Asynchrone » signifie que le client demande l'export et récupère les fichiers plus tard, au lieu d'attendre une réponse. Le serveur doit pouvoir fournir la sortie au moins en Newline Delimited JSON (NDJSON, une ressource FHIR par ligne) et peut proposer d'autres formats en plus^[2].

Accès. Pour le contrôle d'accès, le guide recommande (SHOULD, donc pas une obligation) OAuth 2.0 selon le profil SMART Backend Services^[2]. Ce profil issu de SMART App Launch est conçu pour fonctionner avec Bulk Data, mais sert aussi pour d'autres API FHIR^[3] ; il autorise une application automatisée sans utilisateur^[4].

Version et statut. La version publiée actuelle est la 3.0.0 (STU 3)^[1]. Dans l'historique des publications, elle figure comme trial use, basée sur FHIR 4.0.1, datée du 11 décembre 2025 et marquée comme version actuelle^[5].

Ballot STU 4 : Bulk Submit et Bulk Publish

Le 7 août 2026 est parue une version de ballot 4.0.0-ballot (STU 4), elle aussi basée sur FHIR 4.0.1^[5]. Il s'agit d'une prépublication ; la version officielle reste la 3.0.0^[6]. Le ballot définit trois opérations en masse, chacune pour une relation différente entre le système qui détient les données et le système qui en a besoin : Bulk Export, Bulk Submit et Bulk Publish^[6]. Avec Bulk Submit, un fournisseur de données pousse un jeu de données convenu au préalable vers un destinataire spécifique^[6]. Un cadre juridique pour le partage de données (comme des accords de traitement ou d'utilisation des données) et l'échange en temps réel sont hors du champ d'application^[6].

Le guide vise l'échange en masse à des fins d'analyse, de recherche et de rapportage, comme l'export périodique de données du DPI vers une base de données de recherche^[1] ou un entrepôt de données qui analyse une population de patients^[3].

Aucune utilisation de Bulk Data n'a été trouvée dans les spécifications ou services belges, y compris les guides d'implémentation FHIR belges (Guides d'implémentation FHIR belges) ; la lacune figure dans le registre. Il n'a pas non plus été trouvé si des registres belges ou des DPI utilisés en Belgique prennent en charge $export.

Bulk Data est pertinent pour un hôpital qui souhaite transférer des données du DPI vers un entrepôt de données ou une base de données de recherche sans envoyer de requêtes patient par patient^[1]. Bulk Submit, encore en ballot, décrit l'inverse : pousser un jeu de données convenu au préalable vers un seul destinataire^[6]. Le guide ne règle pas les accords juridiques pour un tel partage de données^[6]. Aucune obligation belge n'a été trouvée.

Recommandation : lors du choix d'un DPI, demandez si $export (au niveau du système, du patient et du groupe) est proposé avec SMART Backend Services, et traitez Bulk Submit et Bulk Publish comme un ballot tant que STU 4 n'est pas publié.

• Le ballot STU 4 n'est pas une release ; le contenu et le calendrier du STU 4 définitif peuvent encore changer^[6].
• Il n'a pas été trouvé si des registres belges ou des DPI hospitaliers utilisés en Belgique proposent $export ; la documentation des fournisseurs n'a pas été examinée.