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

Applications LLM et données de santé

Utilisation de grands modèles linguistiques avec des données de santé : requête et réponse de l'API de contexte, modèles cloud et locaux, systèmes agentiques, récupération versus contexte, et prompting avec provenance.

Une application qui utilise un grand modèle linguistique avec des données de santé doit résoudre un problème que le modèle ne peut pas : quelle partie du dossier d'un patient insérer dans le prompt, et comment l'étiqueter afin que le modèle puisse distinguer les faits des notes. Anpheros le résout du côté des données avec une API de contexte : étant donné un patient, une tâche et un budget de tokens, elle renvoie les sections pertinentes du dossier HL7 FHIR R4 du patient, chaque élément étant étiqueté avec sa source. Votre application envoie ce contexte au modèle que vous choisissez — hébergé ou local.

Comment connecter un LLM aux données médicales FHIR ? Conservez les dossiers dans un magasin FHIR auquel le modèle ne peut pas accéder directement — avec Anpheros, le dossier HL7 FHIR R4 du patient — demandez-lui un contexte budgétisé et étiqueté par source (POST /v1/context), et insérez ce contexte dans le prompt du modèle que vous choisissez. Le modèle ne reçoit jamais d'identifiants de base de données ou d'API ; votre application effectue les appels, dans le respect du consentement du patient.

Anpheros n'exécute pas de modèles et n'a aucune intégration native avec un fournisseur de modèles ou un runtime local.

Le modèle

1. your app  ── POST /v1/context {patient, task, question, budget_tokens, format} ──►  Anpheros
2. Anpheros  ── sections + text + omitted + warnings + manifest_id ──────────────────►  your app
3. your app  ── system prompt + context + user question ─────────────────────────────►  the model
4. the model ── answer ───────────────────────────────────────────────────────────────►  your app
5. your app  ── optional write-back with author_type "ai" ──────────────────────────►  Anpheros

La requête de contexte

curl -X POST https://platform.anpheros.com/v1/context -H "Authorization: Bearer $TOKEN" -H 'content-type: application/json' -d '{
  "patient": "'$PID'",
  "task": "medication review before a cardiology visit",
  "question": "How did blood pressure evolve over the last 3 months?",
  "budget_tokens": 1500,
  "format": "text"
}'

La réponse de contexte

• sections — par exemple une carte récapitulative, des conditions, des médicaments, des allergies, des immunisations, des résultats de laboratoire, des signes vitaux avec tendances hebdomadaires et marqueurs avant/après traitement, des symptômes, une chronologie et des documents. Chaque élément porte author_type et source.
• omitted — ce qui n'a pas été inclus dans le budget ; indiquez au modèle que son contexte est partiel.
• warnings, provenance_note.
• text — lorsque format est text.
• manifest_id — l'enregistrement des sections et des sources utilisées, lié au journal d'accès.
• une section ai_notes — les valeurs écrites précédemment par une IA n'apparaissent que là, marquées comme non vérifiées, jamais mélangées aux sections cliniques.

Modèles Cloud

Avec un modèle hébergé — d'OpenAI, Anthropic, Google, xAI ou d'un autre fournisseur — votre backend place le contexte dans l'invite et appelle l'API du fournisseur. Le contexte quitte votre infrastructure pour ce fournisseur, donc :

• assurez-vous que le consentement du patient et votre avis de confidentialité couvrent l'envoi de données ;
• ayez un accord de traitement des données avec le fournisseur qui convient aux données de santé ;
• envoyez uniquement ce dont la tâche a besoin — le budget de tokens et les needs explicites aident.

Modèles locaux

Avec un modèle que vous exécutez vous-même — par exemple via Ollama ou un autre runtime local — le seul appel réseau transportant des données patient est celui entre votre backend et Anpheros ; le prompt et la réponse restent sur votre infrastructure. Les modèles locaux plus petits ont des fenêtres de contexte plus petites : des budget_tokens plus faibles en conséquence et préfèrent format: "text".

Systèmes agentiques

Lorsque le modèle décide des appels à effectuer, donnez-lui des outils (contexte, recherche, chronologie) au lieu d'identifiants bruts, maintenez des portées restreintes et enregistrez chaque manifest_id à côté de la réponse. Agents IA et données médicales

API de contexte ou votre propre récupération ?

Un pipeline de récupération sur texte libre (intégration de fragments de documents et recherche de ceux-ci) est utile pour les notes non structurées. Pour les données médicales structurées, l'API de contexte est généralement plus simple et plus sûre : elle fonctionne sur des ressources FHIR codées, conserve la provenance, connaît les tendances et les périodes de traitement, respecte le consentement et est auditée. Les deux peuvent être combinés — par exemple, le contexte d'Anpheros plus des passages récupérés de documents que vous gérez.

Inviter avec la provenance

Conservez les étiquettes dans l'invite et expliquez au modèle ce qu'elles signifient :

The context below comes from the patient's record. Each item is labelled with its author type
(patient, practitioner, device, import, derived) and source. Items under ai_notes were written by an
AI earlier and are not verified. Say which items your answer relies on. If the context is marked as
partial, say so. Do not give a diagnosis or change a treatment; suggest discussing it with a clinician.

Liens connexes

• Applications d'IA dans le domaine de la santé
• Agents d'IA et données médicales
• Comment créer un chatbot médical avec des données structurées
• Sécurité, confidentialité et résidence des données

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