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

Agents IA et données médicales

Accès contrôlé pour les agents IA aux dossiers patients : scopes OAuth, les outils dont un agent a besoin, audit et provenance de ce qu'il lit et écrit, et agents événementiels.

Un agent IA est un programme dans lequel un modèle linguistique décide, étape par étape, quelles actions entreprendre — quelles données lire, quel outil appeler, quoi écrire — pour accomplir une tâche. Lorsque la tâche implique le dossier médical d'un patient, l'agent a besoin d'un accès contrôlé : il ne doit accéder qu'aux dossiers qu'il est autorisé à consulter, uniquement aux parties dont il a besoin, laisser une trace de ce qu'il a lu et marquer ce qu'il a écrit comme généré par l'IA. Anpheros fournit cet accès contrôlé via son API ; le framework de l'agent et le modèle vous appartiennent.

Anpheros n'a pas de runtime d'agent intégré, pas de serveur Model Context Protocol (MCP) et aucune intégration officielle avec un framework d'agent ou un fournisseur de modèle. Les agents l'utilisent comme n'importe quelle application : via l'API REST et FHIR ou les SDK.

L'architecture

Patient ── grants access (OAuth scopes, duration) ────────────────┐
                                                                  ▼
Agent runtime (your code, any framework) ── tools ──► Anpheros API ──► the patient's FHIR record
      │   ▲                                   │
      │   └── context, search results ◄───────┘      every call: scope checks + access log
      ▼
The model you choose (hosted or local) ── plans the next step

Le modèle propose des actions ; votre runtime les exécute avec les identifiants qu'il détient. Le modèle lui-même ne détient jamais de clé ou de jeton Anpheros.

Accès contrôlé

• À qui appartiennent les dossiers. Avec une clé d'API, l'agent voit les patients que votre projet a créés. Pour agir sur le dossier existant de quelqu'un, il a besoin d'une autorisation OAuth de cette personne — pour un patient, pendant 30 à 365 jours.
• Quelles données. Les scopes limitent les types de ressources et les actions, éventuellement à une catégorie : patient/Observation.rs?category=laboratory permet à un agent de lire et de rechercher des résultats de laboratoire et rien d'autre. Pour construire un contexte, l'autorisation doit permettre la lecture des observations, des conditions, des médicaments et des allergies (par exemple patient/*.rs).
• Lecture seule par défaut. N'accordez des scopes d'écriture que lorsque l'agent est censé enregistrer quelque chose.
• Révocable. La personne peut révoquer l'autorisation à tout moment ; le prochain appel de l'agent est refusé.

Outils dont un agent a généralement besoin

La spécification OpenAPI (https://developers.anpheros.com/openapi.json) décrit chaque endpoint et peut être transformée en définitions d'outils ; les SDK TypeScript et Dart peuvent être directement encapsulés comme outils.

Exemple : un agent de préparation de visite avec le consentement du patient

Un patient qui tient déjà un dossier dans Anpheros demande à un assistant tiers de préparer des questions pour une visite de cardiologie. L'agent a besoin d'un accès en lecture au dossier pendant une durée limitée — rien de plus.

1. Consentement (OAuth 2.1 + PKCE, scopes SMART v2). L'assistant redirige la personne vers la page de consentement avec les scopes les plus restreints qui permettent toujours un contexte (observations, conditions, médicaments et allergies) :

import { Anpheros, OAuthAuth, OAuthFlow, generatePkce } from '@anpheros/sdk';

const flow = new OAuthFlow({ baseUrl: 'https://platform.anpheros.com', clientId: CLIENT_ID, redirectUri: REDIRECT_URI });
const pkce = await generatePkce();
const url = flow.authorizeUrl({
  scopes: ['patient/Observation.rs', 'patient/Condition.rs', 'patient/MedicationStatement.rs',
           'patient/AllergyIntolerance.rs', 'offline_access'],
  state, pkce, purpose: 'treatment',
});
// … the person chooses the record and the duration (30–365 days) and allows; on the callback:
const tokens = await flow.exchange(code, pkce);
const anpheros = new Anpheros({ auth: new OAuthAuth({ tokens, onRefresh: flow.refresh }) });
const patient = tokens.patient!;   // this application's own (pairwise) id for the person

2. Outils. Le runtime de l'agent expose quelques fonctions au modèle ; chacune est un véritable appel API effectué avec le jeton d'accès :

const tools = {
  // POST /v1/context — relevant sections, within a budget, labelled with author type and source
  get_context: (a: { question: string }) =>
    anpheros.context.build({ patient, task: 'prepare a cardiology visit', question: a.question, budget_tokens: 2000, format: 'text' }),
  // GET /v1/patients/{id}/observations?category=laboratory&code=…&from=…
  list_lab_results: (a: { code?: string; from?: string }) =>
    anpheros.observations.list(patient, { category: 'laboratory', code: a.code, from: a.from, limit: 20 }),
  // GET /v1/patients/{id}/timeline?from=…
  get_timeline: (a: { from: string }) => anpheros.timeline.list(patient, { from: a.from, limit: 50 }),
};

Décrivez-les au modèle dans le format d'appel d'outil ou de fonction que votre API de modèle utilise ; le modèle propose un appel, votre runtime l'exécute et renvoie le JSON. Le modèle ne voit jamais le jeton.

3. Ce que la plateforme applique. Le jeton n'atteint que le dossier de cette personne et uniquement les types scopés ; tout le reste répond 403 (un type hors des scopes) ou 404 (un autre patient). Chaque appel — y compris chaque requête de contexte, avec son manifest_id — apparaît dans le journal d'accès de la personne pour cette application. Si la personne révoque l'accès, le prochain appel répond 401 et l'agent doit s'arrêter ; le jeton de rafraîchissement ne peut pas le rétablir.

4. Sortie. L'agent renvoie des questions pour le médecin avec les sources qu'il a utilisées. Il n'écrit rien en retour, car il n'a pas reçu de scope d'écriture.

Audit et provenance

• Chaque appel effectué par l'agent constitue un accès au dossier et apparaît dans le journal d'accès du patient pour votre application — y compris chaque requête de contexte, qui enregistre également un manifeste des sections et des sources utilisées.
• Tout ce que l'agent écrit est enregistré comme étant rédigé par l'IA dans Provenance. Lorsqu'un contexte est construit ultérieurement, les valeurs rédigées par l'IA sont listées sous ai_notes, séparément des faits cliniques, afin qu'un agent ne finisse pas par citer sa propre sortie antérieure comme preuve.

Démarrage des agents à partir d'événements

Les webhooks permettent à un agent de s'exécuter lorsqu'un événement se produit — un nouveau résultat de laboratoire (resource.created), un nouveau consentement (consent.granted) — au lieu d'interroger périodiquement. Les événements ne transportent que des identifiants ; l'agent lit ensuite ce que ses scopes autorisent. Webhooks

Règles de conception à respecter

1. Donnez à l'agent les portées les plus restreintes qui accomplissent la tâche.
2. Commencez à partir d'un contexte, pas de lectures brutes en masse ; respectez omitted et warnings.
3. Affichez les sources de données du patient dans la réponse de l'agent.
4. Ne laissez jamais l'agent présenter un diagnostic ou modifier un traitement de sa propre initiative ; transmettez de tels résultats à un clinicien.
5. Enregistrez le manifest_id de chaque contexte à côté de la réponse de l'agent, afin qu'une personne puisse voir ultérieurement sur quoi la réponse était basée.

Liens pertinents

• Comment donner à un agent IA l'accès aux dossiers médicaux : tutoriel pas à pas en Python
• Serveur MCP FHIR pour agents IA
• Applications de santé basées sur l'IA
• Applications LLM et données de santé
• Comment construire un chatbot médical avec des données structurées
• Modèle de consentement et d'accès
• Authentification et OAuth
• Données médicamenteuses pour les applications de santé et les agents IA : la liste du patient vs les sources de connaissance des médicaments

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