Serveurs FHIR comparés : HAPI FHIR, Medplum, AWS HealthLake, Azure Health Data Services, Google Cloud et Firely

Réponse directe

Choisissez un serveur FHIR en posant trois questions, dans cet ordre : où les données doivent-elles résider, quelle version de FHIR et quels guides d'implémentation devez-vous servir, et qui exploitera la base de données à 3 heures du matin. En auto-hébergé open source, HAPI FHIR (Java) et Medplum (TypeScript) sont les deux options sérieuses, toutes deux sous Apache 2.0. En service managé, AWS HealthLake, le service FHIR d'Azure Health Data Services et Google Cloud Healthcare API couvrent bien R4, mais chacun laisse des trous à combler vous-même. Firely Server, Aidbox et InterSystems IRIS for Health sont des produits commerciaux pour les équipes qui veulent un support éditeur et des déploiements multi-versions ou très orientés profils.

Ce que fait réellement un serveur FHIR

Un serveur FHIR, c'est une base de données plus une API REST qui parle le modèle de ressources HL7 FHIR : création, lecture, mise à jour, recherche, historique, transactions, et un CapabilityStatement exposé sur /metadata qui déclare ce qui est supporté. Ce dernier point compte davantage que n'importe quelle page commerciale. Deux produits peuvent afficher « FHIR R4 » et différer pourtant sur la recherche chaînée, _include, les mises à jour conditionnelles, les Bundles de transaction ou les opérations disponibles.

Ceux qui cherchent une « base de données FHIR » veulent généralement la même chose : un entrepôt dont la forme native est le JSON FHIR, indexé pour la recherche FHIR. Sous le capot, tous les produits cités ici reposent sur une base classique (PostgreSQL, SQL Server, Oracle, MongoDB ou un stockage managé par le cloud). La couche FHIR, c'est l'index, le moteur de recherche, la validation et le modèle de sécurité posés dessus. Si l'API elle-même est nouvelle pour vous, commencez par le guide d'intégration FHIR.

Le tableau comparatif

Les éléments ci-dessous ont été vérifiés dans la documentation des éditeurs le 6 octobre 2026. Revérifiez le CapabilityStatement de la version exacte que vous déployez.

Open source auto-hébergé : HAPI FHIR et Medplum

HAPI FHIR est l'implémentation Java open source historique de FHIR : modèle de données, client, validateur et serveur JPA complet. Le serveur JPA tourne sur PostgreSQL, SQL Server ou Oracle ; MySQL et MariaDB sont dépréciés pour des raisons de performance. L'Instance Validator contrôle les ressources contre les StructureDefinitions et sait charger des packages de guides d'implémentation, ce qu'il faut pour US Core, les profils européens ou nationaux (FR Core, par exemple). Les Subscriptions supportent les canaux rest-hook, websocket et e-mail.

Ce que HAPI ne fournit pas, c'est un fournisseur d'identité. Sa documentation sécurité l'assume : elle propose des briques (intercepteurs d'autorisation, de consentement et de restriction des recherches) plutôt qu'une couche de sécurité unique. Concrètement, on l'associe à Keycloak ou à un service d'identité cloud et on traduit soi-même les scopes SMART en règles d'intercepteur. HAPI est maintenu par Smile Digital Health, qui commercialise Smile CDR comme distribution supportée.

Medplum est un monorepo TypeScript sous Apache 2.0 : un entrepôt FHIR R4 sur PostgreSQL, une authentification OAuth/OpenID/SMART intégrée, des Subscriptions, des « Bots » côté serveur, un SDK TypeScript et des composants React. Il supporte Bulk FHIR 2.0.0 sur /fhir/R4/$export. C'est davantage une plateforme applicative qu'un serveur nu, ce qui explique son succès auprès des équipes produit qui construisent une application de suivi ou un DPI sur mesure. La contrepartie : R4 uniquement, et l'adoption de son modèle de projets et de politiques d'accès.

Serveurs commerciaux : Firely, Aidbox, InterSystems

Firely Server (.NET) peut exposer des endpoints STU3, R4 et R5, tourne sur SQL Server ou MongoDB en production, et embarque Firely Auth pour SMART, un plugin Bulk Data Export, un outil d'ingestion massive et la validation de profils. C'est un choix naturel quand la conformité aux profils est le cœur du projet, par exemple pour un guide d'implémentation national. Vous pouvez l'essayer sur la sandbox publique ou avec une licence d'évaluation ; la production exige une licence commerciale.

Aidbox stocke les ressources en JSONB PostgreSQL, ce qui donne un accès SQL aux données FHIR à côté de l'API FHIR. La licence de développement est gratuite mais interdit les données patient réelles et plafonne la base à 5 Go ; la production nécessite une licence payante.

InterSystems IRIS for Health intègre un serveur FHIR (STU3, R4, R5) avec support SMART, échanges Bulk FHIR et validateur de profils, dans la même plateforme que HealthShare et de nombreux moteurs d'intégration hospitaliers. Si l'établissement exploite déjà IRIS, activer son entrepôt FHIR est souvent plus simple qu'introduire une nouvelle pile.

Cloud managé : HealthLake, Azure, Google

AWS HealthLake ne supporte que FHIR R4. Il propose SMART App Launch, l'export Bulk Data, l'import en masse depuis S3, un NLP médical intégré qui réécrit les entités extraites sous forme de ressources FHIR, un accès SQL via Athena et un Data Transformation Agent (en préversion) pour le C-CDA et le CSV. Surveillez les quotas : 500 ressources par Bundle, un seul job d'import et un seul job d'export concurrents par région.

Le service FHIR d'Azure Health Data Services supporte R4 4.0.1 et STU3 3.0.2, les transactions, $export, $import, $validate contre des profils et $convert-data pour convertir du HL7 v2 et du C-CDA, avec des scopes SMART sur Microsoft Entra ID. L'ancien Azure API for FHIR a atteint sa date de retrait le 30 septembre 2026 ; si vous l'exploitez encore, vous êtes sous demande d'extension et devriez être en pleine migration.

Google Cloud Healthcare API supporte des stores DSTU2, STU3, R4 et R5, impose à l'écriture les profils et guides d'implémentation configurés, et diffuse les changements vers Pub/Sub et BigQuery. Sa déclaration de conformité est franche sur les limites : l'export du store est un dump complet, « pas une implémentation » de la spécification FHIR Bulk Data, et les notifications Pub/Sub ne sont pas des Subscriptions FHIR. SMART on FHIR passe par le SMARTProxy open source et un serveur d'autorisation que vous opérez.

Les fonctionnalités qui font basculer un projet

Avant de présélectionner, lancez la même sonde sur chaque candidat :

curl -s https://fhir.example.org/fhir/metadata \
  | jq '{version: .fhirVersion, ops: [.rest[0].operation[]?.name], types: [.rest[0].resource[].type] | length}'
curl -s https://fhir.example.org/fhir/.well-known/smart-configuration | jq '.capabilities'

Testez ensuite une recherche réelle dont vous aurez besoin en production, par exemple une recherche chaînée sur Observation?patient.identifier= avec _include, et un Bundle de transaction à votre volumétrie réelle. La plupart des surprises apparaissent là, pas dans la matrice de fonctionnalités. Les détails SMART sont dans le guide SMART App Launch.

Résidence des données en Europe

Le lieu d'hébergement est une donnée d'entrée réglementaire, pas une préférence. Options régionales actuelles :

• Service FHIR Azure : France Central, Germany West Central, North Europe, West Europe, Sweden Central, Switzerland North, UK South et UK West, selon le tableau de disponibilité régionale. Le même tableau n'indique pas la fonctionnalité Events dans ces régions européennes, ce qui pèse sur les architectures événementielles.
• Google Cloud Healthcare API : europe-north1, europe-west2, europe-west3, europe-west4, europe-west6, plus une multirégion eu, selon sa page des emplacements.
• AWS HealthLake : Europe (Irlande) et Europe (Londres) uniquement ; aucune région en Europe continentale au moment de la rédaction.
• Auto-hébergé (HAPI, Medplum, Firely, Aidbox, IRIS) : là où vous le déployez, y compris chez un hébergeur certifié HDS en France ou dans le datacenter d'un établissement.

Le choix de la région ne règle pas à lui seul les questions de transfert au titre du RGPD ou des règles nationales d'hébergement, et certains programmes nationaux exigent un hébergement certifié. Pour le volet interopérabilité européenne, voir FHIR EU Core et la mise en œuvre de l'EHDS.

Guide de choix par scénario

Pièges fréquents en pratique

• Faire du serveur FHIR le moteur d'intégration. Il stocke et sert des ressources. Le routage, le parsing HL7 v2, les rejeux et le mapping se font ailleurs.
• Croire que « supporte R4 » signifie que vos requêtes fonctionneront. Recherche chaînée, _has, profondeur de _include et pagination varient. Testez avec des volumes de production.
• Oublier le plan terminologique. Valider contre des profils européens ou nationaux suppose de charger SNOMED CT, LOINC et les jeux de valeurs locaux quelque part.
• S'enfermer trop tôt dans les extras propriétaires. NLP, Bots, SQL sur JSONB et Pub/Sub sont utiles ; gardez votre contrat principal en FHIR standard pour qu'une migration reste possible. Les clients d'Azure API for FHIR viennent d'en faire l'expérience.
• Ignorer les limites d'export. Un seul job d'export concurrent par région sur HealthLake change la conception de vos traitements analytiques nocturnes.

Si vous choisissez ou migrez un serveur FHIR et souhaitez un regard indépendant sur les arbitrages, cela fait partie d'un accompagnement en intégration HL7 FHIR.