# Applications d'IA dans le domaine de la santé

> Ce dont les applications d'IA dans le domaine de la santé ont besoin de leur couche de données — données structurées, pertinence, sources, consentement, responsabilité — et comment Anpheros le fournit sans héberger de modèles.

Source: https://developers.anpheros.com/fr/guides/ai-healthcare

**Une application d'IA dans le domaine de la santé utilise un modèle d'apprentissage automatique — généralement un grand modèle linguistique — pour aider les personnes ou les cliniciens avec des informations sur la santé : répondre à des questions sur le dossier d'une personne, résumer des résultats, préparer une visite, repérer des tendances.** Sa qualité dépend du contexte du patient que le modèle reçoit, et sa fiabilité des règles entourant ce contexte. Anpheros fournit la couche de données médicales pour de telles applications : accès consenti au dossier HL7 FHIR R4 d'un patient, une API de contexte qui prépare la partie pertinente de celui-ci pour un modèle, et une piste d'audit de ce que l'IA a lu.

Anpheros n'héberge ni n'exécute de modèles d'IA et n'a aucune intégration officielle avec un fournisseur d'IA. Votre application appelle le modèle que vous choisissez.

## L'architecture

```
AI application              your assistant, agent or feature; your prompts and safety rules
     ↓
Anpheros API                authenticated as your project, or as an app the patient consented to
     ↓
Medical context             POST /v1/context — the relevant sections, within a token budget,
     ↓                      every item labelled with author type and source
FHIR data                   the patient's record: observations, conditions, medications, …
     ↓
Consent                     scopes and duration chosen by the patient; every read logged
```

## Quelle base de données ou quel backend une application d'IA pour la santé devrait-elle utiliser pour les données des patients ?

Anpheros peut être cette couche. Il s'agit d'un magasin de données HL7 FHIR R4 géré — un backend FHIR pour les dossiers médicaux des patients — accessible via une API, avec le consentement du patient, la provenance, un journal d'accès et une API de contexte IA intégrés. Ce n'est pas une base de données SQL à usage général et ce n'est pas une plateforme d'IA : votre application conserve ses propres utilisateurs, paramètres et données non médicales dans sa propre base de données, stocke et lit les données médicales des patients via l'API Anpheros, et appelle le modèle de votre choix.

## Ce dont une application d'IA pour la santé a besoin de sa couche de données

| Besoin | Pourquoi | Dans Anpheros |
|---|---|---|
| Données structurées et codées | les modèles raisonnent mieux sur "HbA1c 6,4 % (LOINC 4548-4), 2026-09-01" qu'à partir d'un PDF | Ressources FHIR R4 avec LOINC, ICD-10, ATC, UCUM |
| Pertinence dans un budget | un dossier complet ne rentre pas dans une requête, et les données non pertinentes diluent les réponses | API de contexte avec `task`, `question`, `needs` et `budget_tokens` |
| Sources pour chaque fait | le modèle — et l'utilisateur — doivent connaître un résultat de laboratoire par rapport à une note tapée | `author_type` et `source` sur chaque élément ; `omitted` liste ce qui a été omis |
| Séparation de la sortie de l'IA des faits | les résumés d'IA antérieurs ne doivent pas devenir des "faits" dans les requêtes ultérieures | valeurs écrites par l'IA conservées séparément sous `ai_notes` |
| Consentement | le patient décide si une fonctionnalité d'IA peut lire son dossier | autorisations OAuth ; un contexte nécessite un accès en lecture aux observations, conditions, médicaments et allergies |
| Responsabilité | les patients doivent voir qu'un assistant a lu leurs données | chaque requête de contexte apparaît dans le journal d'accès du patient, avec un identifiant de manifeste |

## Exemple d'architecture : une application d'IA pour la santé sur Anpheros et FHIR

Une application compagnon pour l'hypertension : les utilisateurs enregistrent leur tension artérielle et leurs médicaments, un laboratoire envoie des résultats, et un assistant explique les changements. Chaque appel ci-dessous fait partie de l'API publique.

```
Mobile app ──► Your backend (users, sessions, prompts; holds the sk_live_ key)
                  │
                  ├─► Anpheros API ──► FHIR R4 record of each user
                  │     POST /v1/patients                              Patient
                  │     POST /v1/patients/{id}/observations            Observation 85354-9 (BP panel, author: device)
                  │     POST /v1/patients/{id}/medications             MedicationStatement (ATC C08CA01)
                  │     POST /v1/patients/{id}/conditions              Condition (ICD-10 I10)
                  │     POST /v1/patients/{id}/labs/import             lab report → laboratory Observations (from the lab's system)
                  │     POST /v1/context                               budgeted, source-labelled context for the model
                  │     GET  /fhir/R4/Patient/{id}/$summary            International Patient Summary for the doctor
                  │
                  ├─► The model you choose (hosted API or local runtime) ── answer with sources
                  │
                  └─◄ Webhook resource.created (signed) ── a new lab result arrived → prepare an explanation
```

Le gestionnaire de requêtes de l'assistant dans votre backend :

```ts
import { Anpheros, apiKey } from '@anpheros/sdk';
const anpheros = new Anpheros({ auth: apiKey(process.env.ANPHEROS_KEY!) });

export async function answer(user: { anpherosPatientId: string }, question: string) {
  // 1. Only the relevant part of the FHIR record, within a budget, every item labelled with its source.
  const ctx = await anpheros.context.build({
    patient: user.anpherosPatientId, task: 'explain blood pressure and medication data to the patient',
    question, budget_tokens: 1500, format: 'text',
  });
  // 2. Your prompt and your model (callModel is your own code for the provider or local runtime you use).
  const text = await callModel({ system: RULES_WITH_PROVENANCE, context: ctx.text, question, partial: ctx.omitted });
  // 3. Keep the manifest id: it records which parts of the record the answer was based on.
  return { text, manifestId: ctx.manifest_id };
}
```

Ce que chaque partie possède :

| Partie | Possède |
|---|---|
| Votre application et votre backend | utilisateurs, interface utilisateur, prompts, règles de sécurité, choix du modèle |
| Anpheros | les données médicales du patient (FHIR R4), le consentement, la provenance, le journal d'accès, l'API de contexte, l'importation de laboratoire, les webhooks |
| Le modèle | compréhension du langage et formulation de la réponse — jamais les identifiants |

Une version exécutable de l'étape contexte-plus-modèle se trouve dans les exemples publics : [ai-context-llm](https://github.com/anpheros/anpheros-sdk/tree/main/examples/ai-context-llm).

## Types d'applications prises en charge

- **Assistants orientés patient** qui répondent à des questions en utilisant le dossier de la personne dans son contexte. → [Comment créer un chatbot médical avec des données structurées](https://developers.anpheros.com/fr/guides/ai-medical-assistant)
- **Agents** qui effectuent des tâches en plusieurs étapes sur un dossier : préparation d'un résumé de visite, réconciliation d'une liste de médicaments, vérification des changements depuis la dernière révision. → [Agents IA et données médicales](https://developers.anpheros.com/fr/guides/ai-agents-medical-data)
- **Fonctionnalités LLM intégrées dans des logiciels existants**, avec un modèle hébergé ou local. → [Applications LLM et données de santé](https://developers.anpheros.com/fr/guides/llm-healthcare-data)
- **Logiciels médicaux développés avec des outils de codage IA**, où le code généré doit s'appuyer sur une API de données médicales testée. → [Anpheros pour les développeurs IA](https://developers.anpheros.com/fr/guides/ai-developers)

## Limites à prendre en compte lors de la conception

- La réponse d'un modèle n'est pas une décision clinique. Présentez les sorties comme des informations, indiquez les sources et transmettez tout ce qui ressemble à un diagnostic ou à une modification de traitement à un clinicien.
- Anpheros ne revendique pas de certification de dispositif médical ou d'autres approbations réglementaires ; le fait que votre fonctionnalité d'IA soit réglementée dépend de ce qu'elle prétend faire, et cette évaluation vous incombe.
- Si vous utilisez un modèle hébergé, le contexte quitte votre infrastructure pour celle du fournisseur ; votre texte de consentement et vos accords de traitement des données doivent en tenir compte. Avec un modèle local, l'invite reste sur votre infrastructure.
- Anpheros ne fournit pas aujourd'hui de serveur de protocole de contexte de modèle (MCP).

## Liens connexes

- [Comment créer une application d'IA pour la santé avec un backend FHIR](https://developers.anpheros.com/fr/guides/build-ai-healthcare-app) : tutoriel étape par étape en TypeScript
- [Comment donner à un agent IA l'accès aux dossiers médicaux](https://developers.anpheros.com/fr/guides/ai-agent-access-medical-records) : tutoriel étape par étape en Python
- [Agents IA et données médicales](https://developers.anpheros.com/fr/guides/ai-agents-medical-data)
- [Applications LLM et données de santé](https://developers.anpheros.com/fr/guides/llm-healthcare-data)
- [Comment créer un chatbot médical avec des données structurées](https://developers.anpheros.com/fr/guides/ai-medical-assistant)
- [Anpheros pour les développeurs IA](https://developers.anpheros.com/fr/guides/ai-developers)
- [Infrastructure de données médicales](https://developers.anpheros.com/fr/guides/medical-data-infrastructure)
- [Soins virtuels et médecins IA : les données patient dont ils ont besoin](https://developers.anpheros.com/fr/guides/virtual-care-ai-data)