Plateforme FHIR en tant que backend : ce qu'un backend FHIR en tant que service vous apporte, et ce qu'il n'apporte pas

Un serveur FHIR stocke et distribue des ressources FHIR. Une plateforme FHIR est ce dont vous avez réellement besoin pour lancer un produit de santé : le serveur, plus l'identité, le consentement, la provenance, l'isolement entre les clients, les webhooks, les documents, la terminologie et quelqu'un qui le maintient opérationnel sous le RGPD. Ce guide expose la différence et décrit comment Anpheros Platform comble chaque lacune, afin que vous puissiez décider de construire dessus ou de gérer le vôtre.

Version technique pour les développeurs : Plateforme d'API de soins de santé · Comparaison des serveurs FHIR sur developers.anpheros.com, avec les requêtes, les réponses et les limites. Cette page est la version en langage clair.

Serveur versus plateforme

Les serveurs FHIR open-source (HAPI, par exemple) sont excellents pour la partie FHIR : ressources, recherche, validation, historique. Ce qu'ils vous laissent, c'est tout ce qui l'entoure :

Si vous avez une équipe d'exploitation, un responsable de la conformité et six mois, gérer votre propre serveur est un bon choix. Si vous avez un produit à lancer, une plateforme est plus rapide.

Comment Anpheros Platform est construite

Un enregistrement FHIR R4 par patient. 26 types de ressources, codés avec LOINC, ICD-10 et ATC, validés à l'écriture. L'API FHIR stricte se trouve à /fhir/R4, avec une CapabilityStatement à /fhir/R4/metadata, et une API REST simple à /v1 sert les mêmes données avec les mêmes identifiants.

Isolation du projet et identifiants par paire. Un projet (une clé API) ne voit que les patients qu'il a créés. Chaque projet reçoit son propre identifiant pour la même personne ; les identifiants internes ne quittent jamais la plateforme. Les références aux patients en dehors de votre portée sont masquées par un jeton opaque, par projet.

Le consentement décide des lectures, la propriété décide des écritures. Avec le consentement du patient, une organisation voit l'intégralité du dossier, y compris ce que d'autres cliniques ont écrit, mais ne peut modifier ou supprimer que ce qu'elle a écrit elle-même. Chaque version de chaque ressource enregistre le projet qui l'a écrite ; une écriture par un autre projet est refusée avec une explication.

Provenance et audit à chaque écriture. Provenance.agent.onBehalfOf nomme la clinique ou l'organisation au moment de l'écriture ; une ligne d'audit enregistre qui, quoi, quand, sous quelle autorisation, depuis quelle application. Le patient peut lire son journal d'accès, également sous forme de ressources FHIR AuditEvent.

Webhooks fins et signés. Les événements transportent des identifiants et des versions, jamais de contenu clinique ; vous lisez la ressource via l'API. Les livraisons sont signées avec HMAC-SHA256 et réessayées avec backoff jusqu'à 24 heures.

Sandbox et production sont des bases de données séparées. Une clé sk_test_ ne peut pas atteindre un vrai patient. La sandbox est gratuite et en libre-service.

Résidence UE. Cloud Run dans europe-west4, avec un accord de traitement des données pour les organisations de production.

Ce qui n'est délibérément pas là

• Pas de support de décision clinique. La plateforme stocke, code et partage ; elle ne diagnostique ni ne recommande de traitement.
• Pas de base de données complète de médicaments avec interactions. Les médicaments sont codés avec ATC, et un sous-ensemble groupé ATC et LOINC est disponible pour la recherche, mais la vérification des interactions est votre composant ou un service sous licence.
• Pas de bus de messagerie HL7 v2 de niveau hospitalier. Il existe une importation HL7 v2 ORU^R01 pour les rapports de laboratoire ; il n'y a pas de gestion ADT ou de commandes.

Connaître ces limites à l'avance permet d'économiser une semaine de découverte.

Quand gérer votre propre serveur à la place

• Vous devez héberger à l'intérieur de votre propre réseau hospitalier, sans processeur externe.
• Vous avez besoin de FHIR R5 ou de profils que la plateforme n'implémente pas.
• Votre produit est le serveur FHIR lui-même.

Dans tous les autres cas, commencez sur la sandbox, mesurez et décidez avec des données. La première heure est décrite sur developers.anpheros.com/guides/first-hour ; la référence API complète est sur platform.anpheros.com/docs.

Questions fréquentes

Anpheros est-il un serveur FHIR ?

Il en contient un : une API FHIR R4 avec 26 types de ressources, recherche, historique, opérations $everything, $summary, $validate et terminologie. Autour, il y a le consentement, la provenance, l'isolation, les webhooks et l'hébergement, ce qui en fait une plateforme.

Quelle version FHIR ?

FHIR R4 (4.0.1), la version requise par la réglementation européenne et américaine et implémentée par la plupart des systèmes. La conformité a été vérifiée avec Inferno ; voir les notes de conformité IPS.

Plusieurs cliniques peuvent-elles partager le dossier d'un patient ?

Oui, c'est le but. Avec le consentement du patient, chaque clinique lit l'intégralité du dossier et écrit ses propres ressources, chacune marquée de sa provenance. Aucune clinique ne peut modifier ce qu'une autre a écrit.

Existe-t-il un backend FHIR gratuit pour le développement ?

Oui. La sandbox est gratuite, en libre-service, et est livrée avec 30 patients synthétiques par projet. Voir Serveur FHIR gratuit : la sandbox.

Comment puis-je migrer si j'en ai besoin ?

Tout est FHIR R4 et exportable : Patient/{id}/$everything renvoie l'intégralité du dossier d'un patient sous forme de Bundle. Il n'y a pas de format propriétaire à démêler.