Pourquoi la performance est importante
La performance a une incidence directe sur l'expérience utilisateur et les coûts opérationnels. Les utilisateurs finaux ont besoin d'un accès rapide aux données tout au long de leur parcours de soins — chaque milliseconde de délai s'accumule sur des milliers d'interactions quotidiennes, ce qui influe sur l'efficacité clinique et les résultats pour les patients. Au-delà de l'expérience utilisateur, la performance détermine les coûts d'infrastructure : la taille de la base de données et des sauvegardes, les ressources de calcul et la charge de maintenance croissent tous avec le volume de données.
Lors du choix d'un serveur FHIR, la performance est l'un des facteurs les plus importants. Chaque système construit sur FHIR — solutions DSÉ/DPS, CDR, plateformes d'analytique — présente des profils de charge de travail différents et exige des caractéristiques de performance distinctes. Cependant, pour un serveur FHIR générique, trois charges de travail fondamentales sont universelles :
- CRUD — créer, lire, mettre à jour et supprimer des ressources individuelles
- Traitement par lots — importation en masse, échange de données et scénarios d'intégration
- Recherche — interrogation des ressources selon divers paramètres
Les API de traitement par lots FHIR sont couramment utilisées pour l'échange et l'intégration de données — par exemple, la migration de données depuis des systèmes patrimoniaux vers un serveur FHIR. Les opérations CRUD et de recherche alimentent les charges de travail OLTP : la création de systèmes DSÉ/DPS, d'applications destinées aux patients et d'outils d'aide à la décision clinique.
Ce que nous évaluons
Nous allons comparer plusieurs serveurs FHIR populaires à code ouvert et les mesurer face à Aidbox.
Pour chaque serveur, nous mesurons :
- Le débit — opérations par seconde sous charge soutenue
- La latence — temps de réponse au p99
- La consommation de ressources — utilisation du processeur, de la mémoire et des entrées/sorties
- L'utilisation du disque — quantité de stockage requise par chaque serveur pour le même jeu de données
Nous avons conçu la suite de tests pour observer le comportement de la performance aussi bien sur une base de données vide qu'après un volume de données significatif. C'est crucial — de nombreux serveurs se comportent bien sur de petits jeux de données, mais se dégradent à mesure que les données croissent.
Étape 1 : Base de données vide
En partant d'une installation initiale :
- Mesurer la performance de référence des opérations CRUD
- Importer par lots 1 000 dossiers de patients synthétiques (générés avec Synthea)
- Évaluer la performance de différentes opérations de recherche
Cela établit la référence — le meilleur cas possible pour chaque serveur.
Étape 2 : Chargement de 100 000 patients
Importer 100 000 dossiers de patients synthétiques et mesurer :
- La durée totale de l'importation
- La taille de la base de données sur disque
- La consommation de ressources pendant l'importation
Cela simule un déploiement réaliste de taille moyenne et révèle comment chaque serveur gère une pression d'écriture soutenue.
Étape 3 : Tests de charge incrémentaux
Avec 100 000 patients déjà présents dans la base de données :
- Relancer les opérations CRUD — comparer avec la référence de la base de données vide
- Importer 1 000 dossiers de patients supplémentaires en plus des 100 000 existants
- Relancer les opérations de recherche — mesurer l'évolution des performances des requêtes avec le volume de données
L'écart entre l'étape 1 et l'étape 3 révèle la vérité : dans quelle mesure la performance se maintient-elle à mesure que les données croissent ?
Restez à l'affût
Nous publierons l'ensemble des évaluations comparatives, des scripts de test et des résultats bruts dans les prochains articles. Suivez-nous sur LinkedIn pour ne pas manquer les mises à jour.
Vous avez des questions sur la performance des serveurs FHIR ? Communiquez avec nous — nous optimisons Aidbox pour les déploiements à grande échelle depuis plus d'une décennie.
