FHIR Bulk Data

• Sie entwickeln einen Bulk-Data-Client, der Exporte anstoßen, den Status abfragen und NDJSON-Dateien von einem FHIR-Server herunterladen muss.
• Sie implementieren serverseitige $export-Unterstützung und müssen Konformitätsanforderungen, die Manifest-Struktur oder CapabilityStatement-Deklarationen verstehen.
• Sie müssen große Exporte nach Ressourcentyp, Datumsbereich oder FHIR-Suchkriterien filtern, wobei Sie Parameter wie _type, _since oder _typeFilter verwenden.
• Sie integrieren SMART Backend Services (OAuth 2.0 Client Credentials + JWT) für sicheren Server-zu-Server-Massenzugriff.

• Sie müssen nur einzelne FHIR-Ressourcen über Standard-REST abrufen — verwenden Sie stattdessen einen allgemeinen FHIR-Skill.
• Ihr Anwendungsfall beinhaltet Echtzeit- oder Nahzeit-Daten-Streaming anstelle von Batch-Export.
• Sie arbeiten mit einem proprietären Bulk-Export-Format, das nicht dem HL7 Bulk Data Access IG entspricht.

Führt Sie durch jede Phase des FHIR Bulk Data-Export-Lebenszyklus: Kick-off-Anfrage, Verarbeitung von 202 Accepted, Status-Polling mit Retry-After und X-Progress, Manifest-Parsing, Dateidownload und DELETE-Bereinigung.

Behandelt Patient/$export (alle Patienten), Group/[id]/$export (kohortenbezogen) und [base]/$export (Systemebene), einschließlich wann jeder verwendet werden sollte und wie die Abgrenzung die Ausgabe beeinflusst.

Detaillierte Anleitung zu allen unterstützten Parametern: _outputFormat, _since, _until, _type, _elements, _typeFilter, includeAssociatedData, organizeOutputBy und allowPartialManifests.

Präzise Regeln für die Erzeugung und Verarbeitung von Newline Delimited JSON: eine Ressource pro Zeile, UTF-8-Kodierung, korrekte Zeilenterminierung, keine eingebetteten Zeilenumbrüche und korrekter Medientyp (application/fhir+ndjson).

Erklärt den OAuth 2.0 Client-Credentials-Flow mit JWT-Assertion, der für den serverseitigen Bulk-Zugriff erforderlich ist, einschließlich der Token-Anforderungsstruktur und der Verwendung von Bearer-Tokens.

Behandelt die Interpretation von OperationOutcome, Rate Limiting (429 Too Many Requests), Token-Ablauf (401), fehlende Jobs (404) sowie Strategien für resiliente Polling-Clients.

Implementiere einen Client, der einen Export initiiert, die Status-URL mit exponentiellem Backoff abfragt, das vollständige Manifest analysiert und NDJSON-Dateien für die nachgelagerte Verarbeitung streamt.

Konfigurieren Sie einen FHIR-Server zur Unterstützung von $export, geben Sie in jeder Workflow-Phase korrekte HTTP-Antworten zurück und deklarieren Sie die Konformität über das CapabilityStatement.

Verwenden Sie Group/$export mit den Parametern _type, _since und _typeFilter, um nur die Ressourcentypen und Datumsbereiche zu exportieren, die für einen bestimmten Analyse- oder Forschungsanwendungsfall benötigt werden.

Diagnostizieren und beheben Sie Fehler beim Massenexport, indem Sie OperationOutcome-Antworten interpretieren, die Semantik von HTTP-Statuscodes verstehen und Sonderfälle wie unvollständige Manifeste und paginierte Ausgaben behandeln.