API de santé pour l'IA : un contexte patient labellisé par provenance dans un budget de tokens

Une recherche FHIR renvoie tout ce qui correspond. Un modèle linguistique a besoin d'autre chose : les faits importants, d'abord, chacun indiquant qui les a enregistrés, dans une taille qui convient à la requête. Construire cela à partir de ressources brutes est un projet en soi, et se tromper signifie un modèle qui traite la supposition d'un patient comme un résultat de laboratoire. L'API de contexte Anpheros effectue ce travail sur la plateforme, sous le consentement de la personne, de sorte que le modèle que vous choisissez commence par un résumé défendable.

Version technique pour les développeurs : LLM et données de santé · Accès des agents IA aux dossiers médicaux sur developers.anpheros.com, avec les requêtes, les réponses et les limites. Cette page est la version en langage clair.

La requête

curl -X POST "$BASE/v1/context" \
     -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
     -d '{"patient": "'$PID'", "budget_tokens": 2000, "task": "pre-visit summary", "format": "text"}'

budget_tokens est la taille que vous pouvez vous permettre dans la requête. task et une question optionnelle orientent quels éléments viennent en premier ; needs nomme les types de données que vous souhaitez ; window_days limite la période de recherche ; format choisit des sections structurées ou un bloc de texte rendu. Chaque appel est consigné dans le journal d'accès de la personne en tant que lecture de contexte.

Ce qui revient

Des sections étiquetées par provenance (ou, avec format: "text", un bloc rendu prêt à être collé dans une requête), plus tokens_used, une liste omitted nommant ce qui n'a pas pu être inclus, warnings et une provenance_note. Les éléments sont classés par pertinence clinique et coupés selon le budget : problèmes actifs et allergies d'abord, puis médicaments actuels, mesures et résultats récents, symptômes récents, puis historique plus ancien. Chaque élément contient :

• author_type : patient, praticien, appareil, importation ou dérivé ;
• source : l'application ou l'organisation qui l'a écrit ;
• la date, le code (LOINC, ICD-10, ATC) et la valeur avec son unité ;
• pour les éléments dérivés, de quoi ils ont été dérivés.

La note de provenance dans la réponse dit la même chose en mots, de sorte qu'un modèle qui lit le bloc de texte apprend également à pondérer les éléments. Un diagnostic enregistré par un praticien et un "Je pense que j'ai..." tapé par un patient sont tous deux présents, et ils sont étiquetés différemment.

À quoi ça sert

• Un résumé pré-visite pour un clinicien, généré par le modèle en lequel vous avez confiance, à partir de faits avec leurs sources.
• Un assistant destiné aux patients qui répond à "qu'ont dit mes derniers résultats" avec les chiffres et les dates réels.
• Le triage ou le routage à l'intérieur de votre produit, où le modèle a besoin du dossier mais ne doit pas voir plus que ce que la personne a autorisé.
• Les questions sur les tendances ("qu'est-ce qui a changé depuis le printemps"), pour lesquelles le moteur de tendances de la plateforme et les outils compare_periods et get_series fournissent des preuves plutôt que des conclusions.

Ce qu'il refuse d'être

L'API de contexte n'est pas un système d'aide à la décision clinique et la plateforme n'appelle pas de modèle pour vous. Elle renvoie des faits étiquetés ; ce que le modèle dit relève de la responsabilité de celui qui le déploie. L'API n'inclut pas non plus les éléments que le consentement de la personne exclut : si l'autorisation couvre les observations et les médicaments mais pas les documents, le contexte n'a pas de documents.

Sous consentement, toujours

Le jeton dans la requête appartient à la personne, obtenu via OAuth 2.1 avec les scopes et la durée qu'elle a choisis. Une clé de projet ne voit que les patients créés par le projet. Une application enregistrée en tant qu'agent IA peut lire sous consentement et ne peut proposer que des écritures, que la personne approuve ou rejette.

Le même contexte est disponible pour les assistants MCP en tant qu'outil get_patient_context sur platform.anpheros.com/mcp, de sorte que Claude, ChatGPT ou votre propre agent le lisent sans aucun code de votre côté. Voir Intégration EMR avec les assistants médicaux IA.

Questions fréquentes

Quel modèle la plateforme utilise-t-elle ?

Aucun. La plateforme construit le contexte ; vous l'envoyez au modèle que vous choisissez, hébergé ou privé. Le dossier ne quitte jamais l'UE du côté de la plateforme.

Comment le budget est-il appliqué ?

Les éléments sont classés par pertinence clinique et inclus jusqu'à ce que le budget soit atteint ; la liste omitted dans la réponse nomme ce qui a été omis, de sorte que le modèle sait que le contexte est partiel.

Puis-je demander seulement une partie du dossier ?

Oui, de trois manières : les scopes du consentement de la personne limitent ce qui peut être lu du tout, needs et window_days affinent la requête, et le budget coupe le reste. Pour un contrôle brut, utilisez plutôt search_fhir ou les points de terminaison /v1.

La sortie est-elle déterministe ?

Pour le même dossier, consentement et budget, oui. Les nouvelles entrées le modifient, ce qui est le but : le contexte reflète le dossier tel qu'il est actuellement.

Où puis-je l'essayer ?

Le bac à sable est gratuit et ses 30 patients synthétiques ont six mois d'historique codé. Obtenez une clé et appelez le point de terminaison de contexte sur l'un d'eux : developers.anpheros.com/guides/first-hour.