Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
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 sur lequel Anpheros s'exécute (ressources, historique, index typés, projections) et les règles importantes.
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
| Normalised tables | JSON + search indexes | Graph database | |
|---|---|---|---|
| Stores any valid resource unchanged | — | ✓ | ✓ |
| Standard FHIR search on any parameter | ◐ | ✓ | ◐ |
| New fields need a schema migration | ✓ | — | — |
| Easy SQL reporting | ✓ | ◐ | — |
| Used by mainstream FHIR servers | ◐ | ✓ | — |
◐ = possible with extra work. HAPI FHIR and Anpheros both keep the resource as JSON and index search parameters separately.
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
- APIFHIR R4 REST and the simpler /v1 REST API
- Current resourcesOne row per resource: type, id, patient, version, the full FHIR JSON (JSONB)
- Search indexesTyped tables filled on every write: token, string, date, reference, quantity
- HistoryEvery version of every resource, never overwritten
- ProjectionsFlat tables for the common REST views: observations, conditions, medications
- PostgreSQLOne database per environment; sandbox and production are separate
| 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
400plutô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_idsur 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.
Liens connexes
- FHIR vs. une base de données médicale personnalisée
- Comment stocker des dossiers médicaux en utilisant FHIR R4
- Base de données FHIR et bac à sable gratuits
- Comment Anpheros se compare aux autres serveurs FHIR
- Plateforme FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card