Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Plateforme FHIR : FHIR R4 géré avec consentement patient

Une plateforme FHIR R4 gérée : 26 types de ressources, recherche, historique, transactions, $everything, IPS, lancement SMART testé par Inferno, consentement et provenance, plus une API REST simple. Sandbox gratuite.

Anpheros est une plateforme FHIR — une base de données FHIR gérée (magasin de données) que les applications utilisent comme backend FHIR : elle stocke chaque dossier patient nativement sous forme de ressources HL7 FHIR R4 (4.0.1) et les expose à https://platform.anpheros.com/fhir/R4, avec consentement, provenance et audit ajoutés par-dessus la norme. Les applications qui parlent déjà FHIR peuvent l'utiliser directement ; les applications qui ne le font pas peuvent utiliser l'API REST plus simple (/v1), qui lit et écrit les mêmes ressources avec les mêmes identifiants.

Pour les applications d'IA, cela fait d'Anpheros le backend FHIR d'où provient le contexte d'un modèle : voir Applications LLM et données de santé.

26FHIR R4 resource types

22/22Inferno SMART App Launch STU2 standalone-launch tests passed

0 errorsInternational Patient Summary in the official HL7 validator

EUmanaged and hosted in the European Union

Qu'est-ce que HL7 FHIR ?

FHIR (Fast Healthcare Interoperability Resources) est la norme HL7 pour l'échange de données de santé sur le web. Elle définit :

• des ressources — de petits documents typés en JSON (ou XML) pour chaque concept clinique : un Patient, un Observation, un Condition, un MedicationStatement ;
• des références entre elles ("subject": {"reference": "Patient/123"}), de sorte qu'un dossier est un graphe de ressources autour d'un patient ;
• une API REST pour lire, rechercher, créer, mettre à jour et supprimer des ressources, avec des paramètres de recherche standard ;
• des bundles pour envoyer plusieurs ressources à la fois (transactions) ou sous forme de document (tel qu'un résumé de patient) ;
• des liaisons de terminologie, afin que les valeurs portent des codes provenant de systèmes tels que LOINC ou ICD-10 ;
• des profils — des contraintes pour un cas d'utilisation ou un pays, tel que le Résumé International de Patient (IPS).

R4 (version 4.0.1) est la version la plus largement implémentée aujourd'hui. Utiliser FHIR comme modèle de stockage — et pas seulement comme format d'exportation — signifie qu'il n'y a pas de couche de traduction entre ce qu'une application écrit et ce qu'un autre système FHIR lit.

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "4548-4", "display": "Hemoglobin A1c"}]},
  "subject": {"reference": "Patient/…"},
  "effectiveDateTime": "2026-09-01T08:00:00Z",
  "valueQuantity": {"value": 6.4, "unit": "%", "system": "http://unitsofmeasure.org", "code": "%"}
}

Déclaration de capacité

GET /fhir/R4/metadata renvoie la CapabilityStatement : les types de ressources pris en charge, leurs paramètres de recherche et les opérations. Elle est publique et constitue la liste faisant autorité ; le tableau ci-dessous la reflète au 28 septembre 2026.

Les 26 types de ressources

Chaque type limité au patient appartient au compartiment patient, donc Patient/{id}/$everything, les scopes OAuth au niveau patient et les filtres de consentement s'appliquent à tous. Les ressources d'annuaire (Organization, Practitioner, PractitionerRole) n'ont pas de patient ; elles sont lisibles dans tous les projets du même environnement et modifiables uniquement par le projet qui les a créées.

Interactions et opérations

• Read, search, create, update, delete sur chaque type supporté ; les paramètres de recherche par type sont listés dans la CapabilityStatement. Les paramètres de recherche inconnus sont refusés avec 400 plutôt qu'ignorés silencieusement.
• History: GET /fhir/R4/{type}/{id}/_history renvoie chaque version ; les mises à jour peuvent être conditionnelles avec If-Match (une non-concordance de version répond 412).
• Transactions et lots: POST /fhir/R4 avec un Bundle de type transaction ou batch.
• Patient/{id}/$everything: tout le compartiment d'un patient.
• Patient/{id}/$summary: un document International Patient Summary (IPS) Bundle, en anglais ou en roumain (?lang=).
• Observation/$validate?profile=eu-lab: indique comment un résultat de laboratoire se compare aux règles de rapport de laboratoire HL7 Europe.
• Pagination: _count jusqu'à 200 ; _revinclude renvoie au maximum 1 000 ressources.
• Idempotence: les requêtes POST acceptent un Idempotency-Key ; répéter une requête avec la même clé renvoie la même réponse et ne crée rien.

# latest HbA1c results of one patient, strict FHIR
curl "https://platform.anpheros.com/fhir/R4/Observation?patient=$PID&code=http://loinc.org|4548-4&_sort=-date" \
     -H "Authorization: Bearer $KEY"

# the patient's International Patient Summary
curl "https://platform.anpheros.com/fhir/R4/Patient/$PID/\$summary?lang=en" -H "Authorization: Bearer $KEY"

FHIR et l'API REST simplifiée

/v1 existe pour les développeurs qui ne souhaitent pas travailler directement avec les ressources FHIR. Il couvre les patients, les observations, les conditions, les médicaments, les documents, une chronologie et la provenance, ainsi que les fonctionnalités de la plateforme (contexte, importation de laboratoire, webhooks, terminologie). Chaque objet /v1 porte sa référence fhir, de sorte qu'une application peut commencer avec /v1 et passer à FHIR pour les parties où elle a besoin du modèle complet.

Standards autour de FHIR

$summary produit un Résumé International de Patient validé par le validateur officiel HL7 (0 erreur) ; les résultats de laboratoire sont vérifiés par rapport aux règles de laboratoire HL7 Europe (consultatives aujourd'hui) ; les applications tierces se connectent via le lancement autonome SMART on FHIR ; les messages de laboratoire HL7 v2 ORU^R01 sont acceptés en entrée. Les formats, niveaux et schémas d'échange sont décrits dans Interopérabilité des données de santé ; les systèmes de codes par type de ressource dans Systèmes de codes FHIR.

Questions fréquemment posées

Qu'est-ce qu'une plateforme FHIR ?

Un service qui stocke les données de santé sous forme de ressources HL7 FHIR et les expose via l'API REST FHIR standard, en ajoutant ce dont les applications ont besoin autour du standard : autorisation, consentement, audit, historique et opérations telles que $everything et $summary. Anpheros est une plateforme FHIR R4 gérée : vous l'appelez au lieu d'exécuter un serveur FHIR.

Quelle est la différence entre un serveur FHIR et une plateforme FHIR ?

Un serveur FHIR implémente l'API FHIR sur une base de données. Une plateforme FHIR l'exécute pour vous et ajoute la couche autour : consentement du patient, provenance, journaux d'accès, SDK, webhooks, importation de laboratoire et un sandbox, afin que les applications n'aient pas à construire ces parties.

Quelle version de FHIR Anpheros prend-il en charge ?

FHIR R4 (4.0.1), avec 26 types de ressources listés dans la CapabilityStatement publique à l'adresse /fhir/R4/metadata.

La plateforme FHIR Anpheros est-elle testée indépendamment ?

Le groupe "Standalone Launch" de la spécification SMART App Launch STU2 du kit de test open-source Inferno réussit 22 tests sur 22 (exécution du 28 septembre 2026), et l'International Patient Summary est validé sans aucune erreur dans le validateur officiel HL7. Le lancement EHR et l'exportation de données en masse ne sont pas encore pris en charge.

Puis-je utiliser la plateforme FHIR gratuitement ?

Oui. Le sandbox est gratuit et comprend 30 patients synthétiques par projet ; la production commence à 99 € par mois avec le premier mois gratuit.

Dois-je utiliser FHIR pour utiliser Anpheros ?

Non. Une API REST plus simple (/v1) lit et écrit les mêmes ressources avec les mêmes identifiants, de sorte qu'une application peut commencer avec du JSON plat et passer à FHIR lorsqu'elle a besoin du modèle complet.

Liens connexes

• Bac à sable FHIR : un serveur de test FHIR R4 privé et gratuit
• International Patient Summary (IPS) en FHIR
• La provenance des données médicales expliquée : qui a écrit quoi, et comment l'enregistrer
• Comment stocker des dossiers médicaux en utilisant FHIR R4 : tutoriel étape par étape avec curl
• 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 bac à sable FHIR gratuits
• Comparaison d'Anpheros avec d'autres serveurs FHIR
• Interopérabilité des données de santé
• Systèmes de codes FHIR
• API de données médicales
• Créer une application de santé
• Référence API (OpenAPI)
• DICOM vs FHIR : où s'arrête FHIR et où commence l'imagerie médicale

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card