Comment exporter des données FHIR vers Databricks Delta Lake

Les ressources FHIR sont optimisées pour l'interopérabilité, tandis que les plateformes d'analyse comme Databricks fonctionnent mieux avec des tables. Les équipes d'analyse en santé se heurtent constamment à cet écart — elles ont besoin des données FHIR dans Databricks pour la production de rapports, la recherche, l'apprentissage automatique et l'analyse de la santé des populations, mais les données arrivent sous forme de JSON imbriqué plutôt que de lignes.

Depuis Aidbox 2605, vous pouvez combler cet écart directement : exportez des ViewDefinitions SQL on FHIR directement vers des tables Delta gérées par Databricks Unity Catalog. Cet article montre comment construire ce pipeline en utilisant :

• $viewdefinition-export pour les instantanés et les remplissages rétrospectifs
• AidboxTopicDestination pour la livraison continue avec exportation initiale automatique

Pourquoi Databricks pour l'analyse FHIR?

FHIR est un bon format pour l'échange de données de santé, mais ce n'est pas une forme pratique pour l'analyse. Les équipes d'analyse souhaitent interroger des cohortes, créer des tableaux de bord, joindre des données cliniques avec des données opérationnelles, et préparer des jeux de données pour la recherche ou l'apprentissage automatique — et Databricks leur offre une plateforme lakehouse conçue exactement pour cela :

• Tables Delta Lake pour le stockage analytique
• Unity Catalog pour la gouvernance
• Databricks SQL pour les requêtes
• Notebooks et Jobs pour le traitement des données
• Flux de travail d'apprentissage automatique et d'IA sur les mêmes tables

La pièce manquante est la transformation FHIR vers table, et c'est précisément ce que fournissent les ViewDefinitions SQL on FHIR : elles définissent comment les ressources FHIR deviennent des lignes analytiques avant que celles-ci n'arrivent dans Databricks.

Convertir des ressources FHIR en tables analytiques

Les ressources FHIR sont du JSON imbriqué, mais la plupart des charges de travail analytiques ont besoin de tables relationnelles. Cette inadéquation est généralement là où les difficultés commencent — quelqu'un construit un pipeline ETL, quelqu'un d'autre le maintient, et six mois plus tard le pipeline est devenu un produit en soi.

Aidbox résout ce problème avec SQL on FHIR : définissez une ViewDefinition et les ressources FHIR se transforment en lignes.

{
  "resourceType": "ViewDefinition",
  "id": "patient_flat",
  "resource": "Patient",
  "select": [
    {
      "column": [
        { "name": "id", "path": "id" },
        { "name": "ts", "path": "getAidboxTs()" },
        { "name": "gender", "path": "gender" },
        { "name": "birth_date", "path": "birthDate" },
        { "name": "family_name", "path": "name.where(use = 'official').family.first()" },
        { "name": "given_name", "path": "name.where(use = 'official').given.first()" }
      ]
    }
  ]
}

Ce que cela fait

Cette ViewDefinition prend des ressources Patient et les transforme en lignes analytiques aplaties.

• resource: Patient sélectionne le type de ressource FHIR source.
• id, gender, birth_date, family_name et given_name deviennent des colonnes de table.
• getAidboxTs() ajoute une colonne d'horodatage utilisée pour les exportations incrémentielles.
• Après matérialisation, Aidbox expose le résultat sous sof.patient_flat.

Matérialisez la vue :

POST /fhir/ViewDefinition/patient_flat/$materialize

Une ressource Patient :

{
  "resourceType": "Patient",
  "id": "patient-1",
  "gender": "male",
  "birthDate": "1990-01-15",
  "name": [
    {
      "use": "official",
      "family": "Smith",
      "given": ["John"]
    }
  ]
}

devient une ligne que vous pouvez interroger :

SELECT id, ts, gender, birth_date, family_name, given_name
FROM sof.patient_flat;

Aidbox expose le résultat sous forme de vue PostgreSQL sof.patient_flat, qui devient la source pour les exportations par lot et la livraison continue.

Livraison continue de FHIR vers Databricks

Les abonnements basés sur les sujets d'Aidbox constituent la couche d'événements derrière la livraison continue — sémantique de livraison au moins une fois, cible en ajout seul. Vous définissez un AidboxSubscriptionTopic pour les modifications de ressources qui vous intéressent, puis vous y attachez un AidboxTopicDestination qui détermine où ces événements doivent être envoyés. Dans ce cas, la destination n'est pas un webhook ni une file d'attente — c'est un enregistreur Data Lakehouse qui prend des lignes de la ViewDefinition SQL on FHIR et les livre à Databricks.

Créez un sujet qui écoute les modifications des Patient :

POST /fhir/AidboxSubscriptionTopic

{
  "resourceType": "AidboxSubscriptionTopic",
  "url": "http://example.org/subscriptions/patient-updates",
  "status": "active",
  "trigger": [
    {
      "resource": "Patient",
      "supportedInteraction": ["create", "update", "delete"]
    }
  ]
}

Créez une destination Data Lakehouse :

{
  "resourceType": "AidboxTopicDestination",
  "id": "patient-databricks",
  "topic": "http://example.org/subscriptions/patient-updates",
  "kind": "data-lakehouse-at-least-once",
  "parameter": [
    // ... databricks params ...
    { "name": "viewDefinition", 
      "valueString": "patient_flat" 
    },
    { "name": "batchSize", 
      "valueUnsignedInt": 50 
    },
    { "name": "sendIntervalMs", 
      "valueUnsignedInt": 5000 
    }
  ]
}

Ce que cela fait

Cette destination envoie des lignes SQL on FHIR à Databricks chaque fois qu'une ressource FHIR correspondante est modifiée.

• topic — le sujet d'abonnement à écouter.
• viewDefinition — la forme de table aplatie à envoyer.
• batchSize — le nombre de lignes incluses dans un lot de livraison.
• sendIntervalMs — la fréquence à laquelle les lignes en attente sont vidées.
• // ... databricks params ... — champs de connexion spécifiques à Databricks, omis pour la clarté. Voir Data Lakehouse AidboxTopicDestination.

Créez un Patient :

POST /fhir/Patient

{
  "name": [
    {
      "use": "official",
      "family": "Smith",
      "given": ["John"]
    }
  ],
  "gender": "male",
  "birthDate": "1990-01-15"
}

Vérifiez dans Databricks :

SELECT id, ts, gender, birth_date, family_name, given_name, is_deleted
FROM aidbox_export.fhir.patients;

Le moteur d'exportation ajoute une colonne is_deleted à la table cible afin que les requêtes en aval puissent filtrer les ressources supprimées sans perdre leur historique.

L'exportation initiale FHIR est incluse d'emblée

La plupart des systèmes contiennent déjà des données avant le démarrage du premier flux. Lorsque AidboxTopicDestination démarre, il exporte automatiquement l'état actuel de chaque ligne de la ViewDefinition avant de passer à la livraison en direct — aucune tâche d'amorçage distincte, aucun script de migration personnalisé, aucun pipeline double. Les lignes historiques constituent le point de départ, et les nouvelles mises à jour continuent par le flux en direct.

C'est le comportement par défaut. Si vous souhaitez uniquement les nouvelles données à partir du moment où la destination est créée, ajoutez skipInitialExport: true au tableau parameter de la destination :

{ "name": "skipInitialExport", "valueBoolean": true }

Exportation par lot de FHIR vers Delta Lake

Vous avez besoin d'un instantané ponctuel plutôt que d'un flux continu? Utilisez $viewdefinition-export.

POST /fhir/ViewDefinition/$viewdefinition-export
Prefer: respond-async

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "view",
      "part": [
        { 
          "name": "name", 
          "valueString": "patient_flat" 
        },
        {
          "name": "viewReference",
          "valueReference": {
            "reference": "ViewDefinition/patient_flat"
          }
        }
      ]
    },
    {
      "name": "kind",
      "valueString": "data-lakehouse"
    }
    // ... databricks parameters ...
  ]
}

Exportation ponctuelle

Utilisez $viewdefinition-export lorsque vous avez besoin d'une tâche par lot contrôlée plutôt que d'une livraison continue.

Cas d'utilisation typiques :

• instantanés ponctuels
• remplissages rétrospectifs
• exportations planifiées
• tâches de récupération
• boucles d'exportation incrémentielle avec _since

L'opération s'exécute de façon asynchrone et renvoie une URL de statut dans l'en-tête Content-Location.

Réponse :

202 Accepted
Content-Location: /fhir/ViewDefinition/$viewdefinition-export/status/<export-id>

Vérifier le statut :

GET /fhir/ViewDefinition/$viewdefinition-export/status/<export-id>

Lorsque l'exportation est terminée :

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "status",
      "valueCode": "completed"
    },
    {
      "name": "output",
      "part": [
        {
          "name": "location",
          "valueUri": "databricks-uc:aidbox_export.fhir.patients"
        }
      ]
    }
  ]
}

Interrogez la table résultante depuis Databricks SQL :

SELECT id, ts, gender, birth_date, family_name, given_name, is_deleted
FROM aidbox_export.fhir.patients;

Exportations FHIR incrémentielles

Vous avez besoin d'une exportation incrémentielle nocturne plutôt que d'un flux continu? Utilisez _since. Aidbox filtre les lignes selon la colonne d'horodatage de la ViewDefinition générée par getAidboxTs(), de sorte que l'exportation ne contient que les lignes modifiées après la borne temporelle que vous fournissez. Réutilisez la même requête $viewdefinition-export présentée ci-dessus et ajoutez un paramètre supplémentaire :

{
  "name": "_since",
  "valueInstant": "2026-01-01T00:00:00Z"
}

Pour exécuter des exportations incrémentielles selon un calendrier, avancez _since après chaque exécution :

1. Exécutez $viewdefinition-export avec _since.
2. Attendez que le statut de l'exportation devienne completed.
3. Lisez exportEndTime dans la réponse complétée et conservez-la.
4. Utilisez cette valeur comme _since lors de la prochaine exécution.

Cela vous permet d'effectuer des exportations incrémentielles planifiées sans avoir à construire un pipeline distinct de suivi des modifications.

AidboxTopicDestination vs $viewdefinition-export

Fonctionnement de l'exportation FHIR vers Delta Lake

L'exportation initiale d'AidboxTopicDestination et $viewdefinition-export utilisent toutes les deux le même moteur d'exportation, qui :

1. Lit les lignes depuis la vue PostgreSQL matérialisée sof.<view>.
2. Divise l'exportation en plusieurs blocs.
3. Écrit des tables Delta intermédiaires dans S3.
4. Exécute une opération finale MERGE INTO sur la table gérée par Unity Catalog.

Le résultat est une table Databricks Delta Lake que vous pouvez interroger depuis Databricks SQL, des notebooks, des tableaux de bord ou des outils d'analyse en aval.

Pour les exportations volumineuses, les blocs peuvent être traités en parallèle sur plusieurs pods Aidbox.

Autres destinations d'analyse FHIR

Databricks n'est pas la seule destination d'analyse prise en charge. Si vous utilisez ClickHouse, consultez ClickHouse AidboxTopicDestination; pour BigQuery, consultez BigQuery AidboxTopicDestination. Les deux destinations utilisent la même approche par ViewDefinition SQL on FHIR et le même modèle de livraison continue.

Au-delà des exportations

Pour une intégration plus étroite, Aidbox peut s'exécuter nativement sur Databricks Lakebase — consultez Building a FHIR-native health data platform on Databricks Lakebase pour l'architecture, ou Health Samurai + Databricks pour les détails du partenariat.

Conclusion

Les ressources FHIR sont optimisées pour l'interopérabilité et Databricks est optimisé pour l'analyse. Les ViewDefinitions SQL on FHIR comblent cet écart en transformant les ressources FHIR en tables analytiques. Utilisez $viewdefinition-export lorsque vous avez besoin d'instantanés, de remplissages rétrospectifs ou d'exportations incrémentielles, et AidboxTopicDestination lorsque vous avez besoin de livraison continue et d'un chargement initial automatique. Dans les deux cas, Databricks Delta Lake reçoit des lignes analytiques aplaties plutôt que du JSON FHIR imbriqué.

Pour aller plus loin :

• Data Lakehouse AidboxTopicDestination
• $viewdefinition-export