API de données de santé : ce qu'il faut rechercher, et comment lire et écrire un dossier patient en une heure

"API de santé" couvre des choses très différentes : un flux HL7 v2 d'hôpital, un service national de prescription électronique, l'exportation d'un fournisseur de dispositifs portables, un serveur FHIR. Si vous développez une application de santé, un outil de clinique ou un assistant IA, ce dont vous avez besoin est plus spécifique : un backend qui conserve le dossier d'un patient dans un format standard, permet au patient de décider qui le lit, et vous offre une API claire. Ce guide indique quoi rechercher et montre, avec des appels réels, à quoi ressemble la première heure sur Anpheros Platform.

Version technique pour développeurs : API de santé · API de données médicales sur developers.anpheros.com, avec requêtes, réponses et limites. Cette page est la version en langage clair.

Ce qu'une API de données de santé doit faire

Cinq éléments distinguent une API de données de santé utilisable d'une base de données avec HTTP devant elle.

• Un format standard. HL7 FHIR R4 est le format utilisé par les hôpitaux, les systèmes nationaux et l'espace européen des données de santé. Un dossier stocké en FHIR peut être lu par d'autres systèmes sans pont personnalisé. Un JSON propriétaire ne le peut pas.
• Le consentement du patient comme objet de première classe. Qui peut lire quoi, pendant combien de temps, révocable, visible par le patient. Pas une case à cocher dans votre propre base de données.
• La provenance. Chaque valeur indique qui l'a écrite : le patient, un praticien, un appareil, une importation, un calcul dérivé. Un assistant IA qui ne peut pas distinguer un résultat de laboratoire d'une supposition auto-déclarée est dangereux.
• Un bac à sable avec des données réalistes. Vous ne pouvez pas tester avec de vrais patients, et vous ne devriez pas avoir à en inventer 30 synthétiques avec six mois d'historique vous-même.
• La résidence des données que vous pouvez nommer. Pour les utilisateurs européens, cela signifie des serveurs dans l'UE, sous le RGPD, avec un accord de traitement des données.

Deux façons d'accéder : REST et FHIR, mêmes données

Anpheros Platform expose le même dossier deux fois. Une API REST simple (/v1) pour le code produit, et FHIR R4 strict (/fhir/R4) pour tout ce qui doit communiquer avec le reste du système de santé. Les identifiants sont identiques dans les deux ; chaque objet v1 porte sa référence fhir.

export BASE=https://platform.anpheros.com
export KEY=sk_test_…

# patients que votre projet peut voir
curl $BASE/v1/patients -H "Authorization: Bearer $KEY"

# résultats de laboratoire, les plus récents en premier
curl "$BASE/v1/patients/$PID/observations?category=laboratory&limit=10" -H "Authorization: Bearer $KEY"

# médicaments actifs
curl "$BASE/v1/patients/$PID/medications?status=active" -H "Authorization: Bearer $KEY"

# tout sur une seule chronologie
curl "$BASE/v1/patients/$PID/timeline?from=2026-06-01" -H "Authorization: Bearer $KEY"

# les mêmes données, FHIR strict
curl "$BASE/fhir/R4/Observation?patient=$PID&code=http://loinc.org|4548-4&_sort=-date" -H "Authorization: Bearer $KEY"

Derrière ces appels se trouvent 26 types de ressources FHIR (Patient, Observation, Condition, MedicationStatement, AllergyIntolerance, Immunization, DocumentReference, Encounter, Consent, Provenance et plus), codés avec LOINC pour les mesures, ICD-10 pour les conditions et ATC pour les médicaments.

Obtenir une clé prend une minute

Le bac à sable est en libre-service et gratuit. Connectez-vous au tableau de bord sur platform.anpheros.com/dashboard, appuyez sur Obtenir une clé de bac à sable, et vous aurez une organisation, un projet de bac à sable et une clé sk_test_…. Le projet est livré avec sa propre copie de 30 patients synthétiques : adultes, enfants et personnes âgées de toute l'UE, avec des conditions, des médicaments, des allergies, des résultats de laboratoire et des signes vitaux sur six mois. Modifiez ou supprimez n'importe quoi ; une réinitialisation les ramène.

Les clés de production (sk_live_…) sont destinées aux organisations vérifiées avec un accord de traitement des données signé. Le bac à sable et la production sont des bases de données différentes : une clé de bac à sable ne peut physiquement pas atteindre un vrai patient.

Quoi d'autre est dans la boîte

• OAuth 2.1 avec PKCE et lancement autonome SMART sur FHIR, afin qu'une application puisse demander à une personne l'accès à son propre dossier.
• Consentement avec scopes, expiration et révocation, et un journal d'accès que le patient peut lire.
• Webhooks signés (HMAC-SHA256, retentés avec backoff) pour resource.created, consent.granted, consent.revoked, document.finalized.
• Une API de contexte IA qui construit un résumé étiqueté par provenance d'un patient dans un budget de jetons.
• Importation de rapports de laboratoire depuis CSV, HL7 v2 ORU^R01 ou JSON, mappé à LOINC.
• Résumé international du patient ($summary) et SMART Health Links pour le partage par QR.
• SDK pour Dart et TypeScript, une référence OpenAPI à /docs et une CapabilityStatement à /fhir/R4/metadata.

La visite guidée complète, avec les réponses, est disponible sur developers.anpheros.com/guides/first-hour.

Questions fréquentes

Existe-t-il une API de santé gratuite avec laquelle je peux commencer aujourd'hui ?

Oui. Le bac à sable Anpheros est gratuit et en libre-service : connectez-vous, obtenez une clé, et vous avez 30 patients synthétiques à lire et écrire. Les limites sont de 10 000 écritures de ressources par jour, 100 patients de votre propre projet et 250 Mo de documents par projet.

REST ou FHIR, lequel devrais-je utiliser ?

Utilisez /v1 pour votre propre code produit : il est plus simple et renvoie du JSON brut. Utilisez /fhir/R4 lorsqu'un autre système doit lire les données, lorsque vous avez besoin de la recherche FHIR, de _history, de $everything ou de $summary, ou lorsqu'une certification l'exige. Les deux voient le même dossier.

Comment le consentement du patient est-il géré ?

Une personne accorde à une application l'accès à son dossier via OAuth, en choisissant les scopes et une durée (30, 90, 180 ou 365 jours). L'autorisation peut être révoquée à tout moment, et le patient voit chaque lecture dans un journal d'accès. Détails dans le modèle de consentement.

Où sont hébergées les données ?

Dans l'Union Européenne (Cloud Run, europe-west4), avec la provenance et l'historique des versions sur chaque écriture. L'utilisation en production nécessite un accord de traitement des données signé.

Quel est le coût de la production ?

La production commence à 49 € par mois pour 2 500 patients stockés, avec le premier mois gratuit ; les plans supérieurs sont à 199 € et 799 € par mois. Le bac à sable reste gratuit. Voir tarifs.

Fonctionne-t-il avec les agents IA ?

Oui. Il existe une API de contexte IA avec des étiquettes de provenance et un budget de jetons, et un serveur MCP sur platform.anpheros.com/mcp auquel tout assistant compatible MCP peut se connecter. Voir Intégration EMR avec des assistants médicaux IA.