Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Comparaison d'Anpheros avec d'autres serveurs FHIR
Serveurs FHIR auto-hébergés, banques de données FHIR cloud, plateformes de santé open-source et Anpheros côte à côte : qui autorise l'accès, consentement, provenance, résidence, tarification, et quand choisir chacun.
Les équipes choisissant un backend FHIR pèsent généralement quatre types d'options : un serveur open-source qu'elles hébergent elles-mêmes, un stockage FHIR géré par un fournisseur cloud, une plateforme de santé open-source avec une édition hébergée, ou une base de données de santé gérée comme Anpheros. Ce guide décrit les points forts de chaque type et la position d'Anpheros, sur la base de la documentation publique en date d'octobre 2026. Pour tout produit nommé ici, consultez sa propre documentation ; les fonctionnalités évoluent.
Les quatre types
| Serveur FHIR auto-hébergé (ex. HAPI FHIR) | Stockage FHIR dans le cloud (ex. Google Cloud Healthcare API, Azure Health Data Services, AWS HealthLake) | Plateforme de santé (ex. Medplum) | Anpheros | |
|---|---|---|---|---|
| Qu'est-ce que c'est | un serveur FHIR que vous exécutez | un stockage de données FHIR au sein d'un compte cloud | une plateforme d'application native FHIR avec authentification, workflows et une édition hébergée | une base de données de santé gérée : enregistrement FHIR R4 par patient, consentement, API, audit |
| Qui autorise l'accès | ce que vous construisez autour | l'IAM du cloud, par projet ou jeu de données | les politiques d'accès de la plateforme, configurées par vous | le patient (consentement OAuth 2.1) ou l'organisation (clé API) |
| Consentement et audit côté patient | non | non | constructible avec son modèle de politique | intégré, visible par le patient |
| Provenance à chaque écriture | si vous l'ajoutez | si vous l'ajoutez | pris en charge par FHIR ; vous l'appliquez | requis et automatique |
| Isolation des identifiants entre applications | non | non | non | identifiants par paire par application |
| Importation de laboratoire (HL7 v2) | outils séparés | partiel (mappage v2 vers FHIR dans certains stockages) | intégrations que vous écrivez | intégré, une requête |
| Résidence des données | où que vous l'hébergiez | les régions proposées par le fournisseur | dépend de l'hébergement | Union Européenne uniquement |
| Tarification | votre infrastructure et votre temps | basé sur l'utilisation (requêtes, stockage) | par plan ou auto-hébergé | par organisation, par patients stockés |
| Idéal pour | l'apprentissage, contrôle total, modèles de données inhabituels | les équipes déjà dans ce cloud qui construiront elles-mêmes la couche de santé | les équipes qui veulent construire sur une base de code ouverte et posséder la pile complète | les équipes qui veulent que la couche de santé soit prête et le produit comme leur travail |
API Cloud Healthcare de Google ou une plateforme gérée ?
Le produit de Google s'appelle littéralement Cloud Healthcare API, il apparaît donc en premier pour de nombreuses recherches "healthcare API". Il s'agit d'un magasin FHIR cloud (plus des magasins HL7 v2 et DICOM) au sein de votre projet Google Cloud : stockage, recherche FHIR et accès basé sur IAM, facturé à l'usage. Vous construisez le reste : consentement et audit orientés patient, isolation des applications, importation de laboratoires, SDK et un sandbox avec des données de test. Anpheros fournit ces parties et stocke les données dans l'UE ; il ne vous fournit pas de magasin FHIR au sein de votre propre compte cloud. Choisissez en fonction de qui doit posséder la couche de soins de santé : votre équipe (Cloud Healthcare API) ou la plateforme (Anpheros).
Serveur FHIR open-source ou géré ?
Les serveurs open-source tels que HAPI FHIR s'exécutent partout (des images Docker sont disponibles) et prennent en charge la spécification FHIR complète, avec vos propres profils et extensions. En exécuter un en production signifie gérer vous-même la base de données, les mises à niveau, la sécurité, les sauvegardes et la couche d'accès. Une plateforme gérée échange une partie de cette liberté (Anpheros stocke 26 types de ressources) contre le fait de ne pas l'exécuter. Voir Schéma de base de données FHIR pour ce qu'un tel serveur stocke en interne.
Quand Anpheros est le bon choix
- Vous développez un produit destiné aux patients, aux cliniques, aux laboratoires ou à l'IA, et vous souhaitez écrire le produit, pas le dossier.
- Le consentement du patient et un audit que le patient peut lire sont des exigences, pas des options souhaitables (Article 9 du RGPD, EHDS).
- Vos données doivent rester dans l'Union Européenne.
- Vous souhaitez FHIR R4 mais aussi une vue REST simplifiée, des SDK et des webhooks, provenant d'un seul fournisseur.
- Vous souhaitez commencer gratuitement, dans un bac à sable avec des patients synthétiques réalistes, et passer à la production sans réécrire.
Quand une autre option est préférable
- Vous avez besoin de types de ressources FHIR, de profils ou d'extensions en dehors des 26 pris en charge par Anpheros, ou d'un modèle de données entièrement personnalisé : un serveur auto-hébergé vous offre cette liberté.
- Votre organisation exige que tout soit contenu dans un seul compte cloud pour des raisons de conformité : un magasin FHIR cloud correspond à cette politique.
- Vous souhaitez posséder et modifier l'intégralité de la pile, y compris le serveur d'autorisation et les composants d'interface utilisateur : une plateforme open-source est conçue pour cela.
- Vous avez besoin aujourd'hui des lancements EHR, de l'exportation de données en masse ou des scopes
system/: Anpheros ne les propose pas encore (voir Comment implémenter le consentement du patient avec SMART on FHIR).
Une approche équitable pour décider
Comptez les parties de la couche de soins de santé dont votre produit a besoin : consentement, provenance, audit, identifiants, importation de laboratoire, stockage de documents, résidence, et estimez les mois nécessaires pour construire et maintenir chacune d'elles selon l'option que vous préférez. Comparez ensuite cela avec le travail produit auquel ces mois auraient pu être consacrés. Anpheros est la bonne réponse lorsque le second nombre est plus important.
Liens connexes
- Plateforme d'API de santé : ce qu'elle inclut et comment la choisir : les questions à poser à tout fournisseur
- FHIR vs. une base de données médicale personnalisée : quand concevoir vos propres tables et quand utiliser FHIR
- Base de données et sandbox FHIR gratuits
- Plateforme FHIR
- Backend et base de données d'applications médicales
- Startups dans le domaine de la santé
- Sécurité, confidentialité et résidence des données
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card