Dans notre livre blanc FHIR, nous expliquons pourquoi le sujet devient concret pour les éditeurs de logiciels santé : le marché n’attend plus seulement des connecteurs spécifiques. Il attend des API standardisées, sécurisées, réutilisables et capables de s’intégrer dans des environnements logiciels hétérogènes.
L’expérience Posos illustre précisément ce basculement. Le sujet n’est pas de “faire du FHIR” pour cocher une case technique. Le sujet est plus direct : quel flux métier faut-il rendre plus fiable, plus rapide et plus réutilisable ? Dans le cas de Posos, ce flux est clair : la retranscription automatisée des traitements médicamenteux dans le dossier patient informatisé.
Ne partez pas du standard. Partez du flux métier.
Le cas présenté par Posos part d’une situation très concrète : admission d’un patient, passage aux urgences, consultation préopératoire. Dans ces contextes, les informations sur les traitements peuvent venir de sources multiples : documents papier, PDF, images, scans, voire enregistrements vocaux. Leur qualité varie. Leur structure aussi.
En face, les professionnels de santé ont peu de temps. Ils doivent lire, vérifier, corriger, décider. L’objectif n’est donc pas d’automatiser sans contrôle. L’objectif est d’automatiser autant que possible, tout en gardant l’humain dans la boucle.
Pour un éditeur, c’est ici que le sujet devient stratégique. La valeur ne vient pas seulement de l’OCR, de l’IA ou de l’interface utilisateur. Elle vient aussi de la capacité à renvoyer l’information au logiciel hospitalier dans le format le plus structuré possible, avec le document d’origine et les détails nécessaires autour de la prescription. Autrement dit : l’intégration n’est plus un sujet périphérique. Elle devient une partie du produit.
Une prescription n’est pas un simple champ texte
La prescription médicamenteuse montre bien pourquoi FHIR devient utile. Un traitement, ce n’est pas seulement un nom de médicament. C’est une structure de données complexe : identifiant médicament, dose, quantité, fréquence, durée, forme, unité, voie d’administration, séquences, alternatives, répétitions.
Cette structuration n’est pas un détail technique. Elle conditionne ce que le logiciel pourra ensuite faire de la prescription : analyser la sécurité du traitement, détecter des incohérences ou des risques, établir un plan d’administration, transmettre une information exploitable par le dossier patient et faciliter la continuité du parcours de soins. Si cette complexité est mal structurée, elle finit par réapparaître ailleurs : dans des champs libres, des règles spécifiques, des adaptations locales, des connecteurs difficiles à maintenir ou des erreurs d’interprétation d’un environnement DPI à l’autre. C’est souvent là que la dette technique commence.
Dans la trajectoire présentée par Posos, certains éléments de cette complexité sont structurés à l’aide de ressources FHIR comme Dosage, MedicationRequest ou RequestGroup. L’export peut ensuite prendre la forme d’un FHIR Bundle, transmis vers un repository FHIR, puis adapté au modèle interne du logiciel hospitalier cible. Ce point est essentiel : FHIR ne supprime pas la réalité des systèmes existants. Il aide à créer un langage commun entre le produit de l’éditeur et les environnements dans lesquels il doit s’intégrer.
FHIR ne vaut que par l’architecture qui l’entoure
L’expérience Posos rappelle aussi une réalité souvent sous-estimée : réussir avec FHIR ne consiste pas à “brancher une API”. Lors de leur première itération, les équipes Posos n’avaient jamais travaillé avec FHIR. Leur partenaire côté DPI non plus. L’équipe ne disposait pas encore d’une structure dédiée à l’interopérabilité. Et le délai était court.
Cette situation parlera à beaucoup d’éditeurs : un cas d’usage clair, une opportunité de démonstration ou de déploiement, mais peu de temps pour construire une architecture idéale.
La leçon n’est pas de tout refondre. La leçon est de commencer avec un périmètre maîtrisé, puis d’itérer vers un modèle plus robuste. Cela suppose de choisir le bon premier cas d’usage.
Souvent, il se repère à trois signaux simples : c’est le flux qui génère le plus d’adaptations spécifiques, le plus d’erreurs manuelles, ou le plus de temps d’intégration à chaque nouveau client.
C’est aussi ce qui rend le choix du serveur FHIR important. La conformité FHIR R4, la possibilité de s’auto-héberger, la scalabilité, la qualité du support et la maîtrise de l’infrastructure ne sont pas des détails. Ce sont des conditions pour transformer une première expérimentation en capacité durable.
Pour un éditeur, le risque n’est pas seulement d’échouer avec FHIR. Le risque est de recréer du spécifique sous une apparence standardisée.
La vraie question pour les éditeurs
Ce que montre Posos, ce n’est pas que FHIR serait une solution magique. C’est plus utile que cela.
FHIR devient pertinent lorsqu’il répond à un problème produit précis : comment transformer une donnée métier complexe en flux structuré, exploitable, réutilisable et intégrable dans plusieurs environnements logiciels. La bonne question n’est donc pas : “faut-il faire du FHIR ?”
Elle est : où FHIR peut-il réduire la friction d’intégration dans votre produit ? Si la réponse est claire, FHIR peut devenir un levier d’ouverture produit. Si elle ne l’est pas, FHIR risque de devenir une couche supplémentaire dans une architecture déjà complexe.
Commencer ciblé. Structurer vite. Penser réutilisable.
L’un des enseignements les plus concrets de l’expérience Posos tient en quelques mots : ne pas commencer trop grand. Choisir un flux métier précis. Structurer correctement la donnée. Tester l’intégration. Garder l’humain dans la boucle. Puis itérer vers des modèles plus complexes.
C’est une approche pragmatique. Et c’est probablement la plus utile pour les éditeurs qui veulent avancer sur FHIR sans recréer une nouvelle dette technique.
Le guide FHIR pose le cadre : FHIR devient utile lorsqu’il aide un éditeur à ouvrir son produit sans multiplier les connecteurs spécifiques. L’expérience Posos montre ce que cela signifie sur un flux métier concret : la retranscription des traitements médicamenteux dans le dossier patient.
Pour comprendre comment cette approche a été mise en œuvre avec InterSystems IRIS for Health, découvrez le témoignage complet de Posos.
