FHIR Bulk Data

• Vous créez un client de données en masse qui doit déclencher des exports, interroger l'état d'avancement et télécharger des fichiers NDJSON depuis un serveur FHIR.
• Vous implémentez la prise en charge de $export côté serveur et devez comprendre les exigences de conformité, la structure des manifestes ou les déclarations CapabilityStatement.
• Vous devez filtrer des exports volumineux par type de ressource, plage de dates ou critères de recherche FHIR à l'aide de paramètres tels que _type, _since ou _typeFilter.
• Vous intégrez SMART Backend Services (informations d'identification client OAuth 2.0 + JWT) pour un accès en masse sécurisé de serveur à serveur.

• Vous avez uniquement besoin de récupérer des ressources FHIR individuelles via REST standard — utilisez plutôt une compétence FHIR générale.
• Votre cas d'usage implique une diffusion de données en temps réel ou quasi temps réel plutôt qu'une exportation par lots.
• Vous travaillez avec un format d'exportation en masse propriétaire qui ne suit pas l'IG HL7 Bulk Data Access.

Vous guide à travers chaque étape du cycle de vie de l'exportation en masse : requête de démarrage, gestion du 202 Accepted, interrogation de statut avec Retry-After et X-Progress, analyse du manifeste, téléchargement des fichiers et nettoyage via DELETE.

Couvre Patient/$export (tous les patients), Group/[id]/$export (limité à une cohorte) et [base]/$export (niveau système), notamment quand utiliser chacun et comment la portée influence les données en sortie.

Conseils détaillés sur tous les paramètres pris en charge : _outputFormat, _since, _until, _type, _elements, _typeFilter, includeAssociatedData, organizeOutputBy et allowPartialManifests.

Règles précises pour produire et consommer du JSON délimité par des sauts de ligne : une ressource par ligne, encodage UTF-8, terminaison de ligne correcte, pas de sauts de ligne incorporés, et type de média correct (application/fhir+ndjson).

Explique le flux de credentials client OAuth 2.0 avec assertion JWT requis pour l'accès bulk serveur à serveur, y compris la structure de la requête de token et l'utilisation du bearer token.

Aborde l'interprétation des OperationOutcome, la limitation de débit (429 Too Many Requests), l'expiration des jetons (401), les tâches manquantes (404), ainsi que les stratégies pour des clients d'interrogation résilients.

Implémentez un client qui initie une exportation, interroge l'URL de statut avec un backoff exponentiel, analyse le manifeste complet et diffuse les fichiers NDJSON pour un traitement en aval.

Configurez un serveur FHIR pour prendre en charge $export, retourner les réponses HTTP correctes à chaque étape du flux de travail, et déclarer la conformité via le CapabilityStatement.

Utilisez Group/$export avec les paramètres _type, _since et _typeFilter pour exporter uniquement les types de ressources et les plages de dates nécessaires à un cas d'usage analytique ou de recherche spécifique.

Diagnostiquez et résolvez les erreurs d'exportation en masse en interprétant les réponses OperationOutcome, en comprenant la sémantique des codes de statut HTTP, et en gérant les cas particuliers tels que les manifestes partiels et les sorties paginées.