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

Consentement et modèle d'accès

Qui voit quoi : isolation des projets, identifiants par paire, octrois, propriété d'écriture, provenance et ce que le patient voit de chaque application ayant accès.

Règle : avec le consentement du patient, une organisation voit l'intégralité du dossier — y compris ce que d'autres cliniques ont écrit — mais ne peut modifier ou supprimer que ce qu'elle a écrit elle-même. Chaque version de chaque ressource enregistre le projet qui l'a écrite et l'organisation pour le compte de laquelle elle a été écrite.

Qui voit quoi

• Un projet (clé API) voit les patients qu'il a créés. Sous une autorisation (jeton OAuth), une application voit exactement un patient, à travers tous les rédacteurs, limitée aux scopes accordés et aux filtres de catégorie. Tout le reste renvoie 404, jamais 403, de sorte que les identifiants ne peuvent pas être sondés.
• Identifiants par paire : chaque projet reçoit son propre identifiant pour la même personne ; les identifiants internes ne quittent jamais la plateforme. Les références aux patients en dehors de votre scope sont masquées par un jeton opaque, par projet.
• Annuaire (Organisation, Praticien, Rôle de praticien) : lisible par identifiant à travers le plan pour que les références se résolvent ; recherchable uniquement au sein de votre projet ; utilisable comme X-Anpheros-Acting-As / X-Anpheros-On-Behalf-Of uniquement lorsqu'il est le vôtre.
• Sandbox et production sont des bases de données différentes. Une clé sandbox ne peut physiquement pas accéder aux patients réels.

Écritures et propriété

• project_id sur chaque version de ressource = l'auteur. Mise à jour/suppression par un autre projet → 403 avec une explication ; écrivez votre propre ressource à la place.
• Provenance.agent.onBehalfOf = la clinique/organisation au moment de l'écriture : X-Anpheros-On-Behalf-Of, sinon l'organisation du PractitionerRole agissant, sinon l'organisation du projet.
• Chaque écriture produit une ressource Provenance et une ligne d'audit (qui, quoi, quand, sous quelle autorisation, quelle application, depuis quelle empreinte digitale source).

Ce que le patient voit

/me/patients/{id}/grants liste chaque application ayant accès, ses scopes et sa date d'expiration ; …/access-log liste ce que chaque lecture ou écriture a fait — sous le consentement et avec la clé propre du projet. La révocation prend effet à la prochaine requête ; l'application ne peut pas se réauthentifier. Avec format=fhir, le journal d'accès revient sous forme de Bundle de ressources FHIR R4 AuditEvent, structuré selon les IHE Basic Audit Log Patterns (type rest, l'interaction comme sous-type, l'application et la personne agissant à travers elle comme agents, le patient et la ressource comme entités, pas de données cliniques), de sorte qu'un autre système puisse le fusionner dans la vue de la personne sur qui a accédé à son dossier.

Ce qu'enregistre chaque ressource Provenance et comment la définir : Explication de la provenance des données médicales.

SMART Health Links (partage par QR code ou lien)

Une personne peut partager son dossier sans application intermédiaire : POST /me/patients/{id}/shl crée un SMART Health Link pour le sous-ensemble d'urgence (allergies, médicaments, problèmes, vaccinations — pas de résultats ni d'historique) ou le résumé patient international complet, avec un mot de passe et une date d'expiration optionnels. La réponse transporte l'URI shlink:/… (pour un QR code) et une adresse de visualisation sur /shl/view, qui l'ouvre dans n'importe quel navigateur. Quiconque le scanne publie sur l'URL du manifeste et reçoit le résumé sous forme de JWE (dir + A256GCM) chiffré avec la clé contenue dans le lien ; n'importe quel lecteur SMART Health Link fonctionne.

• Le contenu est généré à chaque ouverture (indicateur L, statut can-change), ainsi une carte conservée dans le téléphone reste à jour.
• Un mot de passe (indicateur P) est vérifié sur le serveur ; après 10 tentatives incorrectes, le lien cesse de fonctionner.
• GET /me/patients/{id}/shl liste les liens avec la fréquence et la date de chaque ouverture ; …/shl/{link}/revoke désactive un lien à la fois. Chaque ouverture est consignée dans le journal d'accès.
• L'identifiant interne de la personne ne quitte jamais la plateforme : le document les nomme par un pseudonyme du lien.

Les agents IA proposent, la personne décide

Sous réserve du consentement d'une personne, une écriture par un agent IA (une application enregistrée en tant qu'agent, par exemple un assistant connecté via MCP) ou toute écriture avec author_type ai n'est pas appliquée immédiatement. La plateforme la valide et répond 202 Accepted avec l'ID de la proposition (en-tête Anpheros-Proposal) ; rien ne change dans le dossier. La personne la voit dans GET /me/patients/{id}/proposals — ce que c'est, quelle application l'a envoyée — et l'accepte ou la rejette (…/proposals/{proposal}/accept ou …/reject). Une proposition acceptée est écrite exactement telle qu'envoyée, marquée comme écrite par IA (HL7 AI Transparency). Les projets qui peuvent voir le dossier reçoivent un webhook fin proposal.created. Les écritures effectuées avec la clé propre d'un projet, sur des dossiers créés par le projet, ne sont pas retenues.

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