---
{
  "title": "Comment exporter des données FHIR vers Databricks Delta Lake",
  "description": "Exportez des ViewDefinitions SQL on FHIR vers des tables Delta gérées par Databricks Unity Catalog en livraison continue ou en exportation ponctuelle.",
  "date": "2026-06-15",
  "author": "Sviatoslav Krivosheev",
  "reading-time": "8 min read",
  "tags": ["SQL on FHIR", "Analytics", "Aidbox", "Integrations", "Databricks"],
  "tldr": "Aidbox 2605 peut exporter des données FHIR vers Databricks Delta Lake sous forme de lignes SQL on FHIR aplaties. Utilisez [$viewdefinition-export](https://www.health-samurai.io/docs/aidbox/modules/sql-on-fhir/operation-viewdefinition-export) pour les instantanés, les remplissages rétrospectifs et les exportations incrémentielles, ou [AidboxTopicDestination](https://www.health-samurai.io/docs/aidbox/tutorials/subscriptions-tutorials/data-lakehouse-aidboxtopicdestination) pour la livraison continue avec exportation initiale automatique.",
  "utm-campaign": "analytics",
  "utm-content": "delta-lake-export",
  "hide-comments": true,
  "hero-image": "fhir-databricks-delta-export.svg",
  "hero-image-alt": "FHIR data export from Aidbox to Databricks Delta Lake",
  "hero-image-position": "before-tldr",
}
---

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.

```json
{
  "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 :

```http
POST /fhir/ViewDefinition/patient_flat/$materialize
```

Une ressource Patient :

```json
{
  "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 :

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

| id        | ts                   | gender | birth_date | family_name | given_name |
| --------- | -------------------- | ------ | ---------- | ----------- | ---------- |
| patient-1 | 2026-06-09T10:15:00Z | male   | 1990-01-15 | Smith       | John       |

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.

{% hint style="info" %}
Vous ne connaissez pas SQL on FHIR?

Lisez nos articles :

👉 [Qu'est-ce qu'une ViewDefinition](https://www.health-samurai.io/articles/what-is-a-viewdefinition)

👉 [SQL on FHIR : fonctionnement, avantages et cas d'utilisation](https://www.health-samurai.io/articles/sql-on-fhir-an-inside-look)
{% endhint %}

## Livraison continue de FHIR vers Databricks

Les [abonnements basés sur les sujets](https://www.health-samurai.io/docs/aidbox/modules/topic-based-subscriptions/aidbox-topic-based-subscriptions) 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 :

```http
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 :

```json
{
  "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](https://www.health-samurai.io/docs/aidbox/tutorials/subscriptions-tutorials/data-lakehouse-aidboxtopicdestination).

Créez un Patient :

```http
POST /fhir/Patient

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

Vérifiez dans Databricks :

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

| id        | ts                   | gender | birth_date | family_name | given_name | is_deleted |
| --------- | -------------------- | ------ | ---------- | ----------- | ---------- | ---------- |
| patient-1 | 2026-06-09T10:15:00Z | male   | 1990-01-15 | Smith       | John       | 0          |

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 :

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

{% hint style="info" %}
Pour en savoir plus dans la documentation d'Aidbox :

👉 [Exportation initiale pour Data Lakehouse AidboxTopicDestination](https://www.health-samurai.io/docs/aidbox/tutorials/subscriptions-tutorials/data-lakehouse-aidboxtopicdestination#initial-export)
{% endhint %}

## 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`.

```http
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 :

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

Vérifier le statut :

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

Lorsque l'exportation est terminée :

```json
{
  "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 :

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

| id        | ts                   | gender | birth_date | family_name | given_name | is_deleted |
| --------- | -------------------- | ------ | ---------- | ----------- | ---------- | ---------- |
| patient-1 | 2026-06-09T10:15:00Z | male   | 1990-01-15 | Smith       | John       | 0          |
| patient-2 | 2026-06-09T10:18:00Z | female | 1984-07-22 | Garcia      | Maria      | 0          |
| patient-3 | 2026-06-09T10:24:00Z | other  | 2001-03-08 | Chen        | Alex       | 0          |
| patient-4 | 2026-06-09T10:31:00Z | female | 1976-11-30 | Okafor      | Amara      | 0          |

## 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 :

```json
{
  "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

|                        | `AidboxTopicDestination`                                                          | `$viewdefinition-export`                                                                    |
| ---------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| **Livraison**          | Continue, pilotée par événements                                                  | Ponctuelle, exécutée à la demande                                                           |
| **Exportation initiale** | Automatique                                                                     | Manuelle                                                                                    |
| **Mises à jour**       | Quasi temps réel, par modification de ressource                                   | Par lot, par requête                                                                        |
| **Incrémentielle**     | Intégrée via les sujets d'abonnement                                              | Manuelle via `_since`                                                                       |
| **Meilleur usage**     | Pipelines de production maintenant les tables Databricks continuellement à jour   | Instantanés, remplissages rétrospectifs, tâches planifiées, récupération et rejeu           |

## Fonctionnement de l'exportation FHIR vers Delta Lake

![FHIR to Databricks Delta Lake export architecture using SQL-on-FHIR ViewDefinitions](aidbox-databricks-bulk.svg)

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](https://www.health-samurai.io/docs/aidbox/tutorials/subscriptions-tutorials/clickhouse-aidboxtopicdestination); pour BigQuery, consultez [BigQuery AidboxTopicDestination](https://www.health-samurai.io/docs/aidbox/tutorials/subscriptions-tutorials/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](https://www.databricks.com/blog/building-fhir-native-health-data-platform-databricks-lakebase) pour l'architecture, ou [Health Samurai + Databricks](https://www.health-samurai.io/partners/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](https://www.health-samurai.io/docs/aidbox/tutorials/subscriptions-tutorials/data-lakehouse-aidboxtopicdestination)
- [$viewdefinition-export](https://www.health-samurai.io/docs/aidbox/modules/sql-on-fhir/operation-viewdefinition-export)

{% hint style="info" %}
🤔 Vous avez une question?

Posez-la nous sur Zulip : https://connect.health-samurai.io/
{% endhint %}