# Schéma de base de données FHIR

> Comment stocker les ressources FHIR : tables normalisées vs JSON avec index de recherche vs graphe, le schéma PostgreSQL utilisé par Anpheros (ressources, historique, index typés, projections) et les règles importantes.

Source: https://developers.anpheros.com/fr/guides/fhir-database-schema

**Une base de données FHIR stocke les ressources HL7 FHIR afin qu'elles puissent être lues, recherchées et versionnées via l'API FHIR ; le schéma le plus courant conserve chaque ressource sous forme de JSON et remplit des tables d'index séparées pour les paramètres de recherche, au lieu de répartir chaque élément dans des tables relationnelles normalisées.** Cette page explique les trois conceptions habituelles, le schéma qu'Anpheros utilise dans PostgreSQL, et quand vous ne devriez pas en construire un vous-même.

## Trois façons de stocker FHIR

<!-- visual:schema-compare -->

Les ressources FHIR sont profondes, optionnelles et extensibles : une Observation seule a des dizaines d'éléments, des types de choix (`value[x]`), des codages répétitifs et des extensions. Normaliser cela en colonnes relationnelles signifie une migration chaque fois qu'un profil ajoute un champ. Conserver la ressource sous forme de JSON stocke tout ce qui est valide sans modification ; les tables d'index la rendent interrogeable.

## Le schéma Anpheros

<!-- visual:schema-stack -->

| Table | Une ligne par | Colonnes clés |
|---|---|---|
| `fhir_resources` | version actuelle d'une ressource | `resource_type`, `id`, `patient_id`, `version`, `json` (la ressource complète), `last_updated`, `deleted`, plus les colonnes de provenance |
| `fhir_history` | chaque version jamais écrite | `resource_type`, `id`, `version`, `json`, `last_updated` |
| `idx_token` | valeur de recherche codée ou identifiée | system, code — pour `code`, `category`, `identifier`, `status` |
| `idx_string` | valeur de recherche textuelle | texte normalisé — pour les noms et le texte libre |
| `idx_date` | valeur de recherche de date | début et fin de la plage — pour `date`, `onset-date`, `birthdate` |
| `idx_reference` | valeur de recherche de référence | type et id de la cible — pour `patient`, `subject`, `encounter` |
| `idx_quantity` | valeur de recherche de quantité | value, system, unit — pour `value-quantity` |
| `proj_observations`, `proj_conditions`, `proj_medications` | ressource, aplatie | les colonnes sur lesquelles l'API REST simple filtre |

À chaque écriture, la plateforme valide la ressource, écrit la nouvelle version dans `fhir_resources` et `fhir_history`, remplace ses lignes d'index et ses projections, et enregistre la provenance. Une recherche telle que `Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01` devient des jointures sur `idx_reference`, `idx_token` et `idx_date` ; le résultat renvoie le JSON stocké tel qu'il a été écrit.

## Règles de conception importantes

- **Indexez uniquement les paramètres de recherche déclarés**, et refusez ceux qui sont inconnus avec `400` plutôt que de les ignorer silencieusement.
- **Ne mettez jamais à jour sur place sans historique** : les corrections doivent conserver ce qui était connu auparavant.
- **Suppression logique** : une ressource supprimée disparaît des lectures et des recherches, mais ses versions restent pour l'audit.
- **Colonne de compartiment patient** : stocker `patient_id` sur chaque ressource rend les `$everything`, les filtres de consentement et l'isolement par patient peu coûteux.
- **Validez avant de stocker** : un JSON invalide dans le magasin casse tous les lecteurs par la suite.

## Questions fréquemment posées

### Quelle est la meilleure base de données pour FHIR ?
La plupart des serveurs FHIR en production utilisent une base de données relationnelle telle que PostgreSQL, avec la ressource stockée en JSON (JSONB) et les paramètres de recherche indexés dans des tables séparées. Cela combine un stockage flexible avec une recherche rapide et standard.

### Dois-je normaliser les ressources FHIR en tables relationnelles ?
Généralement pas pour le stockage principal. Les tables normalisées conviennent au reporting ; conservez-les sous forme de projections construites à partir des ressources stockées, comme le fait Anpheros pour son API REST plus simple.

### Comment HAPI FHIR stocke-t-il les ressources ?
Le serveur JPA de HAPI FHIR stocke également chaque version de ressource sous forme de JSON sérialisé et conserve les paramètres de recherche dans des tables d'index séparées. La conception d'Anpheros suit le même principe.

### Dois-je créer ma propre base de données FHIR ?
Uniquement si vous avez besoin d'un contrôle total sur les profils et les types de ressources. Sinon, une plateforme FHIR gérée vous offre stockage, recherche, historique, consentement et audit sans avoir à gérer le schéma.

<!-- visual:cta-schema -->

## Liens connexes

- [FHIR vs. une base de données médicale personnalisée](https://developers.anpheros.com/fr/guides/fhir-vs-custom-database)
- [Comment stocker des dossiers médicaux en utilisant FHIR R4](https://developers.anpheros.com/fr/guides/store-medical-records-fhir)
- [Base de données FHIR et bac à sable gratuits](https://developers.anpheros.com/fr/guides/free-fhir-database)
- [Comment Anpheros se compare aux autres serveurs FHIR](https://developers.anpheros.com/fr/guides/fhir-server-comparison)
- [Plateforme FHIR](https://developers.anpheros.com/fr/guides/fhir)