---
{
  "title": "Nous avons normalisé l'accès aux données de santé. Nous n'avons jamais normalisé ce qu'un agent peut en faire.",
  "description": "FHIR a réglé la question de qui peut lire le dossier d'un patient. Il n'a jamais réglé ce qu'un agent d'IA peut faire de ce dossier par la suite. Voici l'écart, et un exemple Aidbox exécutable qui en comble une partie.",
  "date": "2026-08-24",
  "author": "Eugene Vestel",
  "reading-time": "12 min read",
  "tags": ["AI / Agents", "Compliance", "FHIR Standard", "Aidbox"],
  "tldr": "Le modèle d'autorisation de FHIR répond aux questions d'accès : ce client peut-il lire cette ressource? Il n'a aucun vocabulaire pour les questions d'utilisation — le lecteur peut-il conserver une copie, l'envoyer à un fournisseur de modèle, s'en servir pour l'entraînement, agir sur une inférence? Les instructions ne sont pas de la mise en application, donc les contrôles doivent s'exécuter côté serveur : expurger à la lecture, auditer chaque appel, hausser le niveau d'authentification pour les écritures, et exiger une approbation hors bande pour tout ce qui est irréversible. HealthClaw Guardrails est un mandataire sous licence MIT qui met en œuvre ces quatre contrôles; cet article explique comment l'exécuter devant Aidbox.",
  "utm-campaign": "ai",
  "utm-content": "agent-guardrails"
}
---

> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt).
> Use it to discover all available pages before guessing URLs.

---

Une femme que je connais souffre de trois maladies chroniques, a quatre prescripteurs et des dossiers dans six systèmes. Avant chaque nouveau rendez-vous, elle accomplit le même travail : se connecter à trois portails, faire des captures d'écran de sa liste de médicaments, retranscrire ses antécédents sur un formulaire à pince, et espérer que la réceptionniste les saisisse correctement. Elle fait cela depuis onze ans. Ce n'est pas une mauvaise patiente. Elle effectue un travail d'intégration non rémunéré parce qu'aucun autre acteur du système n'est en mesure de le faire.

Voilà le goulot d'étranglement. Pas le diagnostic, pas l'accès aux données au sens juridique. La patiente est la seule partie qui dispose de l'image complète et la seule partie sans aucun outil pour agir sur celle-ci.

Un agent d'IA est la première chose qui puisse plausiblement combler cet écart. Il peut lire à travers six systèmes, réconcilier une liste de médicaments, remplir le formulaire et relancer l'aiguillage. Ce n'est pas spéculatif. Connectez un client MCP à un serveur FHIR, donnez-lui une URL de base et un jeton, et la démo fonctionne du premier coup.

C'est précisément le problème. La démo fonctionne, et rien dans la pile n'indique à la patiente ce que cet agent peut faire de ce qu'il vient de lire.

## Ce que FHIR a été conçu pour répondre, et ce qu'il n'était pas

Le modèle d'autorisation de FHIR a été conçu pour un monde où le client était une application et où un être humain se trouvait derrière. Ce monde a débuté vers 2011, s'est consolidé à travers Argonaut et SMART on FHIR, et est devenu loi à travers les règles d'API de la 21st Century Cures. Il a résolu un vrai problème, et il l'a bien résolu. Un patient peut désormais obtenir ses données.

Regardez ce que les portées d'autorisation indiquent réellement. `patient/Observation.rs` signifie que ce client peut lire et rechercher des Observations pour ce patient. C'est une question d'accès, et FHIR y répond avec précision.

Maintenant, posez les questions qu'un agent soulève :

- Ce lecteur peut-il conserver une copie après la fin de la session?
- Peut-il envoyer la charge utile à un fournisseur de modèle dans une autre juridiction?
- Le fournisseur peut-il la conserver dans un cache d'invite?
- Peut-elle servir à entraîner un modèle que quelqu'un d'autre vend?
- Le lecteur peut-il inférer un diagnostic et agir sur cette inférence dans un lieu que le patient ne voit jamais?

FHIR ne répond à aucune de ces questions, parce qu'aucune n'est une question d'accès. Ce sont des questions d'utilisation, et l'utilisation était le problème de quelqu'un d'autre au moment où la spécification a été rédigée. `Consent` s'en approche le plus : elle exprime une permission de divulguer, avec des dispositions sur la finalité d'utilisation et les acteurs. Elle décrit tout de même une permission accordée à la frontière. Rien dans la ressource ne voyage avec la charge utile, et rien chez le destinataire ne l'applique. R6 introduit `Permission` avec une opération `$evaluate`, ce qui est un véritable progrès et qui est encore en phase de scrutin.

Ainsi, l'énoncé honnête de l'écart : la norme régit qui peut lire. Elle ne régit pas ce que le lecteur peut faire par la suite, et elle ne dispose d'aucun vocabulaire pour un lecteur qui est un modèle plutôt qu'une personne.

Ce n'est pas une critique de FHIR. Grahame et tous ceux qui l'ont bâti résolvaient le problème de 2014, et ce problème était réel. C'est un constat sur ce que 2026 nécessite et qui n'existe pas encore.

## Personne ne construit le côté patient de cette équation

Il se passe de véritables travaux ici, et ils méritent d'être nommés. La CARIN Alliance a un code de conduite pour l'échange dirigé par le consommateur. Les SMART Health Links de Josh Mandel ont donné aux patients un mécanisme authentique pour partager un dossier selon leurs propres conditions. Le Consent IG existe. Les groupes de travail HL7 sont mobilisés.

Mais regardez par qui et pour qui les outils de gouvernance de l'IA sont construits. Les fournisseurs intègrent la sécurité des agents dans leurs propres produits, limitée à leur propre responsabilité. Les établissements de santé rédigent des politiques d'IA qui régissent les agents de l'établissement à l'intérieur de la frontière de l'établissement. Les deux sont rationnels. Ni l'un ni l'autre ne produit quoi que ce soit que le patient contrôle.

L'asymétrie est au cœur du problème. Quand un établissement de santé déploie un agent, c'est l'établissement qui décide de la politique d'expurgation, qui détient la piste d'audit et qui fixe les règles d'approbation. Quand un patient utilise un agent sur ses propres dossiers, le patient ne décide d'aucune de ces choses. Il accepte ce que le fournisseur de l'application a choisi, généralement sans le voir, et le fournisseur de l'application n'a aucune incitation à choisir de manière prudente.

Nous sommes sur le point de donner aux patients l'outil le plus puissant qu'ils aient jamais eu pour naviguer dans ce système, sans couche de gouvernance qu'ils contrôlent. Cela mérite d'être inconfortable.

## Ce que vaut vraiment la copie

Voici pourquoi ce n'est pas une préoccupation abstraite. Lorsqu'une ressource FHIR entièrement identifiée quitte l'entité couverte et atterrit chez un fournisseur d'IA polyvalent, HIPAA cesse généralement de s'appliquer. Il n'y a pas d'accord de partenariat commercial avec un agent conversationnel grand public. Ce qui régit les données là-bas, c'est l'application par la FTC et un patchwork de lois étatiques, ce qui constitue un régime plus faible pour l'individu.

Quatre choses peuvent arriver à cette copie.

**Elle est vendue.** Le courtage de données de santé est un marché établi. Les acheteurs comprennent des annonceurs, des spécialistes du marketing pharmaceutique et des fournisseurs de recrutement pour essais cliniques qui paient pour des cohortes au niveau des pathologies. Les actions de la FTC de 2023 contre GoodRx et BetterHelp impliquaient toutes deux des données de santé atteignant des plateformes publicitaires d'entreprises qui avaient dit aux utilisateurs que cela n'arriverait pas. Aucun hôpital n'était impliqué dans l'un ou l'autre cas.

**Elle parvient à un souscripteur.** La loi ACA interdit aux assureurs maladie de souscrire sur la base de maladies préexistantes. Elle n'interdit pas aux assureurs vie, invalidité ou soins de longue durée, qui souscrivent bel et bien sur l'historique de santé. L'exposition des employeurs passe par les programmes de bien-être et l'administration des régimes autofinancés, où la séparation entre les données du régime et les données de l'employeur est plus mince que la plupart des employés ne le supposent. GINA et l'ADA contraignent certains de ces aspects. Aucune des deux n'a été rédigée en pensant aux pathologies inférées à partir d'une transcription de clavardage.

**Elle vous place dans une cohorte.** Une fois qu'un tiers peut inférer vos diagnostics, vous pouvez être placé dans un programme de sensibilisation auquel vous n'avez jamais adhéré, ou vous voir proposer un éventail de fournisseurs plus restreint que ce qui existe. La question de savoir si l'orientation se produit à grande échelle aujourd'hui est discutable. L'incitation, elle, ne l'est pas, et le patient n'a aucune visibilité dans un sens ou dans l'autre.

**Elle entraîne un modèle.** Selon les conditions du fournisseur, les entrées peuvent devenir des données d'entraînement, et les offres grand public diffèrent fortement des offres entreprise sur ce point précis. C'est le seul élément de la liste qui ne peut pas être annulé. La copie d'un courtier peut être supprimée. Les paramètres d'un modèle ne peuvent pas être désappris.

Rien de tout cela n'exige que quiconque agisse de mauvaise foi. Ce sont les comportements par défaut d'un système où le patient a accordé un accès en lecture et où rien en aval n'est contraint.

## Les instructions ne sont pas de la mise en application

La réponse habituelle est de rédiger de meilleures instructions. Mettre les règles dans l'invite système. Dire à l'agent d'expurger les identifiants, de consigner ses actions et de demander avant d'écrire.

Une invite est une demande, pas un contrôle. Le modèle décide de l'honorer ou non, et quiconque peut mettre du texte devant le modèle a son mot à dire. Les notes cliniques, les documents numérisés et les messages du portail sont tous des textes qu'un attaquant peut influencer. Un contrôle que l'agent peut contourner par le discours n'est pas un contrôle.

La mise en application doit s'exécuter là où l'agent ne peut pas l'atteindre. En pratique, cela signifie le serveur, et cela signifie quatre choses.

**Expurger à la lecture.** Supprimer les champs de classe d'identifiant avant que la ressource n'atteigne le modèle. Les noms réduits aux initiales, les identifiants masqués, les adresses supprimées, les dates de naissance tronquées à l'année. L'agent obtient le contenu clinique et non l'identité. C'est un contrôle compensatoire, pas une détermination légale de dé-identification, et il devrait être décrit ainsi. Cela ne rend pas un dossier avec un diagnostic rare et une séquence de dates inhabituelle impossible à relier. Ce que cela change, c'est le comportement par défaut, et le comportement par défaut est actuellement « tout transmettre ».

**Tout auditer.** Chaque lecture et chaque écriture génère un enregistrement durable nommant le locataire, l'agent, la ressource et l'heure. Un journal des requêtes n'est pas cela. Quand un responsable de la conformité demande quel agent, agissant pour quel patient, a lu quelles ressources, un journal d'accès portant une identité de compte de service partagé ne peut pas répondre. Deux règles de conception sont importantes : la piste est en ajout seul, et le détail de l'audit est exempt de RPS, de sorte que l'enregistrement remis à un réviseur peut être transmis en toute sécurité.

**Hausser le niveau d'authentification pour les écritures.** Au niveau du protocole, un jeton qui peut faire `GET /Observation` peut généralement faire `POST /Observation`. Le transport ne distingue pas « résume mes analyses » de « enregistre une tension artérielle de 190/120 ». Exiger un justificatif d'identité distinct à courte durée de vie pour les écritures n'arrête pas à lui seul un attaquant déterminé. Cela fait des écritures une classe d'événements distincte et auditable plutôt qu'un effet secondaire d'une session bavarde.

**Exiger une approbation hors bande pour tout ce qui est irréversible.** Pour une écriture clinique, bloquer jusqu'à ce qu'un humain confirme. Pour une action dans le monde réel — un appel, un message texte ou un formulaire soumis — le seuil est plus élevé : valider ne devrait que soumettre l'action, l'exécution étant conditionnée à une approbation que la propre chaîne d'outils de l'agent ne peut pas produire. Si l'agent peut fournir l'artefact représentant le consentement humain, il n'y a pas d'humain dans la boucle.

L'objection évidente : les portées SMART et `Consent` font déjà une partie de cela. Partiellement vrai, et c'est là où ce modèle devrait finalement résider. Les portées contraignent ce qu'un client peut demander. Ce qu'elles ne peuvent pas faire, c'est contraindre la forme de la réponse, produire un enregistrement d'audit attribué à l'agent, ou retenir une écriture jusqu'à ce qu'une personne appuie sur approuver. Ce sont des comportements d'exécution, et aujourd'hui aucun serveur ne les effectue par défaut.

## Une mise en œuvre, construite ouvertement

HealthClaw Guardrails est un mandataire sous licence MIT entre tout agent d'IA et tout serveur FHIR. Il expose un serveur MCP avec 29 outils et une façade REST, et applique les quatre contrôles ci-dessus ainsi que l'isolation des locataires. La règle de conception est qu'aucune propriété de sécurité ne dépend du comportement du client.

```mermaid
flowchart LR
    A[AI Agent] --> B[MCP Server]
    B --> C[Guardrail Proxy]
    C --> D["Any FHIR Server<br/>(Aidbox, HAPI, Epic, ...)"]
    C -.- E["PHI redaction<br/>Audit trail<br/>Step-up auth<br/>Human-in-the-loop<br/>Tenant isolation"]
```

Deux détails sont là où ce modèle fuit habituellement.

**Le chemin d'écriture.** `fhir_propose_write` valide et prévisualise sans valider. `fhir_commit_write` exige un jeton de niveau supérieur et renvoie HTTP 428 jusqu'à ce qu'un humain confirme. Pour les actions dans le monde réel, `action_commit` renvoie `202 awaiting_confirmation` et ne fait rien d'autre; l'exécution consomme un justificatif à usage unique à travers un chemin d'approbation distinct, réclamé de manière atomique pour qu'il ne puisse pas être rejoué. Une version antérieure conditionnait cela avec un en-tête de requête `X-Human-Confirmed`. Nous l'avons retiré du rail d'action, parce qu'un en-tête peut être usurpé par l'appelant qui le définit. Cet en-tête conditionne toujours les écritures FHIR cliniques aujourd'hui, et nous le documentons comme un contrôle compensatoire plutôt qu'une preuve qu'un humain a agi. Être précis sur quelles garanties sont cryptographiques et lesquelles sont des conventions représente l'essentiel de la valeur ici.

**Réécriture de l'URL amont.** Les réponses sont réécrites de sorte que l'URL de base du serveur d'appui n'atteigne jamais le client. Un agent qui apprend le vrai point de terminaison tentera de contourner le mandataire.

## Exécuter devant Aidbox

L'exemple complet, incluant `docker-compose.yaml`, les données d'amorçage et un parcours scripté, se trouve à [aidbox-integrations/healthclaw-guardrails](https://github.com/Aidbox/examples/tree/main/aidbox-integrations/healthclaw-guardrails) dans le dépôt d'exemples Aidbox.

Obtenez une licence Aidbox gratuite sur [aidbox.app](https://aidbox.app), puis :

```bash
git clone https://github.com/Aidbox/examples
cd examples/aidbox-integrations/healthclaw-guardrails
cp .env.example .env          # paste AIDBOX_LICENSE, set STEP_UP_SECRET
docker compose up -d
./scripts/seed-aidbox.sh      # one Patient, three Observations, one Condition
```

Trois services démarrent : Aidbox sur 8080 comme système d'enregistrement, le mandataire de garde-fous sur 5000, et le point de terminaison MCP sur 3001 auquel l'agent se connecte. Aidbox est configuré avec une `AccessPolicy` limitant le client du garde-fou au point de terminaison FHIR, et le mandataire y est pointé :

```yaml
healthclaw:
  environment:
    FHIR_UPSTREAM_URL: http://aidbox:8080/fhir
    STEP_UP_SECRET: ${STEP_UP_SECRET}
    READ_AUTH_ENABLED: "true"
```

Rien du côté d'Aidbox n'est inhabituel. C'est délibéré. La couche de garde-fous est additive, et le serveur FHIR en dessous continue de se comporter comme un serveur FHIR.

### La même lecture, avec et sans gouvernance

Directement vers Aidbox, le dossier est entièrement identifié, comme il se doit :

```bash
curl -u "$AIDBOX_CLIENT:$AIDBOX_SECRET" \
  http://localhost:8080/fhir/Patient/pt-demo
```

```json
{ "resourceType": "Patient", "id": "pt-demo",
  "name": [{"given": ["Maria"], "family": "Alvarez"}],
  "identifier": [{"system": "urn:mrn", "value": "MRN-88214"}],
  "birthDate": "1974-03-11",
  "address": [{"line": ["221 Baker St"], "city": "Pittsburgh"}] }
```

Par le mandataire, même ressource, même Aidbox :

```bash
curl -H "X-Tenant-ID: demo" \
  http://localhost:5000/r6/fhir/Patient/pt-demo
```

```json
{ "resourceType": "Patient", "id": "pt-demo",
  "name": [{"given": ["M."], "family": "A."}],
  "identifier": [{"system": "urn:mrn", "value": "***masked***"}],
  "birthDate": "1974",
  "meta": {"tag": [{"code": "redacted"}]} }
```

Aidbox détient toujours le dossier complet. L'expurgation est une propriété du chemin que l'agent emprunte, pas une modification des données.

### La lecture a laissé un enregistrement

```bash
curl -H "X-Tenant-ID: demo" "http://localhost:5000/r6/fhir/AuditEvent?_count=1"
```

Renvoie un `AuditEvent` nommant le locataire, l'agent, `Patient/pt-demo` et l'horodatage, sans RPS dans le détail. `$export` émet la piste sous forme de NDJSON pour un SIEM.

### Une écriture, bloquée deux fois

Demandez à l'agent d'enregistrer une tension artérielle. Première tentative, sans jeton de niveau supérieur, renvoie 401. Créez un jeton et réessayez, et il renvoie 428 en attente de confirmation humaine. Ce n'est qu'après confirmation que l'Observation atteint Aidbox. Vérifiez qu'elle est arrivée en interrogeant Aidbox directement, en contournant le mandataire :

```bash
curl -u "$AIDBOX_CLIENT:$AIDBOX_SECRET" \
  "http://localhost:8080/fhir/Observation?subject=Patient/pt-demo&code=85354-9"
```

La ressource est là, et la piste d'audit enregistre qui l'a proposée, qui l'a approuvée et quand. Cette séquence est l'argument entier. L'agent a accompli un travail utile. Il ne pouvait pas terminer seul.

### Évaluer le déploiement

```bash
curl "http://localhost:5000/r6/fhir/\$conformance?format=text"
```

```text
HealthClaw Guardrail Conformance — http://localhost:5000 [tenant=demo]
  Grade: A   (7/7 properties)

  [PASS] PHI Redaction            [PASS] Human-in-the-Loop
  [PASS] Immutable Audit Trail    [PASS] Tenant Isolation
  [PASS] Step-Up Authorization    [PASS] Medical Disclaimers
  [PASS] Error Fidelity
```

La fidélité des erreurs est la propriété la moins évidente : les paramètres de recherche inconnus et les modificateurs non pris en charge doivent être rejetés ou signalés, jamais abandonnés silencieusement. Un filtre qui disparaît discrètement élargit une requête, et une requête élargie sur un dossier patient est une divulgation. Le même harnais s'exécute en IC comme porte de fusion, de sorte qu'une régression apparaît comme un changement de note plutôt que comme un incident. Une affirmation de sécurité que vous pouvez exécuter vaut plus qu'une que vous pouvez lire.

## Ce que cela apporte au patient

Revenons au formulaire à pince. Dans CareAgents, l'application grand public construite sur cette couche, la demande est : « Je vais voir un nouveau médecin la semaine prochaine, remplis mon formulaire d'admission à partir de mes dossiers. » L'agent remplit le formulaire en utilisant SDC `$populate`, puis s'arrête.

Chaque médicament et chaque allergie requiert une confirmation individuelle du patient. « Aucune allergie connue » requiert une attestation explicite et n'est jamais inférée d'une liste vide, parce qu'une liste vide et un vrai négatif sont des énoncés cliniques différents. Le serveur redérive la liste d'éléments au moment de la soumission, de sorte qu'une requête fabriquée ne peut pas sauter une ligne. L'approbation produit un PDF estampillé de provenance derrière un lien signé et à expiration.

Onze ans de retranscription deviennent une révision et approbation. L'agent fait le travail. Le patient conserve chaque décision. Le serveur rend cette division non négociable plutôt qu'une promesse dans une politique de confidentialité.

## Pourquoi cette couche doit être ouverte

**Une propriété de sécurité que vous ne pouvez pas inspecter est une affirmation marketing.** Chaque fournisseur dit que son agent est sûr avec les RPS. Le code source ouvert transforme cela en quelque chose qu'une équipe de sécurité hospitalière peut lire, exécuter et attaquer. C'est un type d'assurance différent et c'est le seul qui survive au contact d'une révision de sécurité.

**Les normes de santé numérique sont gagnées par des implémentations de référence ouvertes.** FHIR s'est répandu parce que HAPI, les serveurs de test publics, Synthea et les connectathons ont rendu l'adoption bon marché et la simulation difficile. La gouvernance des agents se normalisera de la même façon ou pas du tout.

**Le modèle de menace est plus grand que n'importe quelle équipe.** Injection d'invite à travers des documents cliniques, bogues d'isolation des locataires, paramètres de recherche abandonnés silencieusement. Ces problèmes sont trouvés par de nombreux lecteurs adversariaux ou ils ne sont pas trouvés. Nous publions les nôtres : une défaillance d'écriture d'audit qui annulait la transaction de l'appelant tout en renvoyant un succès, et une entrée de connexion qui tronquait les codes à 8 chiffres à 6. Dans un produit fermé, ce sont des correctifs discrets. Ici, ils sont devenus des tests de régression.

**Une couche destinée à survivre à tous les fournisseurs de modèles ne devrait pas appartenir à un seul.** Les API de pointe et les modèles locaux à poids ouverts sont de plus en plus interchangeables derrière un seul adaptateur. Ce qui persiste à travers les générations de modèles, c'est la couche de gouvernance. Si elle appartient à un fournisseur, les garanties du patient expirent quand le modèle d'affaires de ce fournisseur change.

## Ce que la communauté devrait faire ensuite

Trois choses, et aucune n'est un produit.

**Rédiger le profil manquant.** Nous avons besoin d'un moyen d'exprimer, en FHIR, ce qu'un lecteur peut faire d'une ressource après l'avoir reçue. Pas seulement la permission de divulguer, mais la rétention, la redivulgation, l'inférence et l'entraînement. R6 `Permission` est le bon endroit pour commencer la conversation. Apportez-le aux groupes de travail.

**S'entendre sur un contrat de conformité pour l'accès des agents.** Expurger, auditer, hausser le niveau d'authentification, approbation humaine, isolation des locataires, préservation de la fidélité des erreurs. Débattez de cette liste. Remplacez-la par une meilleure. Mais convenez de quelque chose par rapport à quoi un déploiement peut être évalué, afin que « notre agent est sûr » cesse d'être une phrase infalsifiable.

**Faire du patient celui qui détient la politique.** En ce moment, la règle d'expurgation, la piste d'audit et la porte d'approbation appartiennent toutes à celui qui a écrit l'application. C'est à rebours pour l'échange dirigé par le consommateur, et y remédier est un problème de conception que la communauté n'a pas sérieusement abordé.

Les données de santé devraient être faciles à obtenir. Ce combat est largement gagné. Le prochain consiste à les rendre sûres à utiliser, avec le patient qui tient les commandes plutôt que d'en lire la description après coup.

HealthClaw Guardrails est sous licence MIT et suffisamment petit pour être lu en un après-midi : une façade FHIR en Python, un serveur MCP en TypeScript, environ 1 170 tests Python et 112 tests Node, et le harnais de conformité qui conditionne l'IC. C'est une implémentation de référence et un argument, pas un produit. Si vous utilisez Aidbox, clonez l'exemple et essayez de le briser. La chose la plus utile que vous puissiez nous envoyer est une charge utile qui passe outre un contrôle qu'elle ne devrait pas.

Exemple : [github.com/Aidbox/examples](https://github.com/Aidbox/examples/tree/main/aidbox-integrations/healthclaw-guardrails) · Dépôt : [github.com/aks129/HealthClawGuardrails](https://github.com/aks129/HealthClawGuardrails) · Conformance en direct : [app.healthclaw.io/r6/fhir/$conformance](https://app.healthclaw.io/r6/fhir/$conformance) · Application grand public : [careagents.cloud](https://careagents.cloud)

*Eugene Vestel écrit sur FHIR IQ et anime le balado* Out of the FHIR*. Health Samurai développe Aidbox, une plateforme FHIR pour les équipes de soins de santé.*