Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

FHIR vs. une base de données médicale personnalisée

Vos propres tables ou HL7 FHIR R4 pour les données médicales : la même lecture stockée des deux manières, les compromis côte à côte, quand choisir l'un ou l'autre, et la séparation habituelle entre votre base de données et le dossier FHIR.

Une équipe qui lance un produit de santé est généralement confrontée au même choix tôt : concevoir ses propres tables pour les patients, les mesures et les diagnostics dans PostgreSQL ou une autre base de données, ou stocker les données médicales sous forme de ressources HL7 FHIR R4 dès le départ. Un schéma personnalisé est plus rapide dès le premier jour et s'adapte exactement à votre produit. FHIR coûte plus de réflexion initiale et est rentabilisé chaque fois que les données doivent quitter votre système, être auditées, partagées avec consentement ou lues par quelqu'un d'autre que vous. Cette page expose honnêtement les compromis, avec la même lecture stockée des deux manières, et indique quand chaque choix est approprié.

Ceci est une question différente de quel serveur FHIR utiliser. Pour cela, voir Comment Anpheros se compare aux autres serveurs FHIR.

La même mesure, deux approches

Une mesure de tension artérielle dans un schéma personnalisé :

CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);

Simple, rapide à interroger, exactement ce dont l'application a besoin. Puis viennent les questions auxquelles la table ne répond pas :

• Quel appareil ou quelle personne a produit la valeur ? A-t-elle été saisie par le patient, mesurée par un brassard, ou entrée par une infirmière ?
• Quelle était la valeur avant que quelqu'un ne la corrige, et qui l'a corrigée ?
• Comment un système de clinique, un laboratoire ou un assureur la lit-il ? Que signifie systolic dans leur système ?
• Comment le patient la partage-t-il avec l'application de son médecin et arrête-t-il de la partager le mois prochain ?
• Lorsque vous ajoutez le rythme cardiaque, le poids, l'HbA1c et 200 autres mesures, s'agit-il de 200 tables ou d'une table générique que vous concevez vous-même ?

La même mesure au format FHIR R4 :

{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}

Plus verbeux, mais chaque partie a une signification que tout système FHIR partage : LOINC indique ce qui a été mesuré, UCUM indique l'unité, meta.versionId démarre un historique, et la même forme Observation contient les 200 autres mesures. Avec Anpheros, une ressource Provenance enregistre également qui l'a écrite. Comment stocker des dossiers médicaux en utilisant FHIR R4 explique cela en détail.

Côte à côte

Quand un schéma personnalisé est la bonne solution

• Les données ne sont pas réellement médicales, ou ne concernent pas une seule personne. Plans d'entraînement, contenu, catalogue de produits : utilisez vos propres tables.
• Un prototype de courte durée pour tester l'intérêt pour le produit, avec des données synthétiques et un plan de migration.
• Les données ne correspondent pas bien aux modèles standards, par exemple une nouvelle mesure de recherche. FHIR peut toujours les transporter (Observation avec votre propre système de codes, ou Basic), mais une table personnalisée peut être plus claire.
• Analyse intensive. Même avec FHIR comme système d'enregistrement, la plupart des équipes copient les données dans un entrepôt de données, dans leur propre format, pour la génération de rapports.

Quand FHIR est l'appel approprié

• Les données constituent le dossier de santé d'une personne : mesures, diagnostics, médicaments, allergies, résultats de laboratoire, documents.
• Elles quitteront un jour votre système : pour le patient, un médecin, une clinique, un laboratoire, un assureur, un modèle d'IA ou un concurrent lorsque le patient déménage.
• Vous devez montrer qui a écrit quoi et ce qui a changé : audits, sécurité clinique, litiges.
• Les patients accorderont et révoqueront l'accès par application.
• Vous vendez dans l'Union européenne, où l'Espace européen des données de santé s'attend à ce que les dossiers soient échangeables dans des formats standard.

La voie médiane habituelle

La plupart des produits finissent par avoir les deux, divisés par type de données :

your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks

Votre base de données reste petite et adaptée au produit. Le dossier médical est standard, versionné et partageable, et vous n'avez pas eu à le construire. Backend et base de données d'applications médicales décrit cette séparation en détail, et Comment construire une API de santé avec TypeScript la met en œuvre.

Ce qu'il faut pour construire FHIR soi-même

Choisir FHIR ne signifie pas écrire un serveur FHIR. Vos options sont un serveur open-source que vous exécutez, le magasin FHIR d'un fournisseur cloud, une plateforme de santé open-source, ou une base de données de santé gérée comme Anpheros. Ils diffèrent quant à qui gère le consentement, l'audit, la provenance, la résidence et les intégrations, ce que Comment Anpheros se compare aux autres serveurs FHIR expose.

Questions fréquemment posées

FHIR est-il une base de données ?

Non. FHIR est une norme pour la structure et l'échange de données de santé : ressources, codes et une API REST. Un serveur FHIR ou une base de données FHIR gérée stocke les ressources et implémente l'API au-dessus d'une vraie base de données.

Puis-je stocker moi-même des ressources FHIR dans PostgreSQL ?

Oui, en tant que colonnes JSON avec vos propres index, et certains serveurs open-source font exactement cela. Le travail réside dans tout ce qui concerne le stockage : paramètres de recherche, gestion des versions, références, validation, contrôle d'accès par patient et provenance.

Puis-je commencer avec un schéma personnalisé et passer à FHIR plus tard ?

Vous le pouvez, et de nombreuses équipes le font, mais la migration est un projet de mappage : chaque table a besoin de codes, d'unités et d'auteurs qu'elle n'a jamais enregistrés. Stocker des données médicales au format FHIR dès la première fonctionnalité coûte moins cher que de les convertir plus tard.

Ai-je besoin de FHIR pour être conforme au RGPD ?

Non. Le RGPD n'exige pas de format particulier. FHIR facilite la satisfaction de plusieurs obligations : portabilité (le dossier est exporté dans un format standard), contrôle d'accès par objectif, et indication de qui a traité quelles données.

Liens connexes

• Schéma de base de données FHIR : comment les ressources FHIR sont stockées et indexées
• Comment stocker des dossiers médicaux en utilisant FHIR R4
• Plateforme FHIR
• Comparaison d'Anpheros avec d'autres serveurs FHIR
• Backend et base de données d'applications médicales
• API de santé

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card