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

Agenți AI și date medicale

Acces controlat pentru agenți AI la fișele pacienților: scopuri OAuth, instrumentele de care are nevoie un agent, audit și proveniența a ceea ce citește și scrie, și agenți bazați pe evenimente.

Un agent AI este un program în care un model lingvistic decide, pas cu pas, ce acțiuni să întreprindă — ce date să citească, ce instrument să apeleze, ce să scrie — pentru a finaliza o sarcină. Atunci când sarcina implică dosarul medical al unui pacient, agentul are nevoie de acces controlat: ar trebui să acceseze doar înregistrările permise, doar părțile de care are nevoie, să lase o urmă a ceea ce a citit și să marcheze ceea ce a scris ca fiind generat de AI. Anpheros oferă acest acces controlat prin API-ul său; framework-ul agentului și modelul sunt ale dumneavoastră.

Anpheros nu are un runtime de agent încorporat, nici un server Model Context Protocol (MCP) și nicio integrare oficială cu vreun framework de agent sau furnizor de modele. Agenții îl folosesc așa cum o face orice aplicație: prin API-ul REST și FHIR sau prin SDK-uri.

Arhitectura

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

Modelul propune acțiuni; runtime-ul dvs. le execută cu credențialul pe care îl deține. Modelul în sine nu deține niciodată o cheie sau un token Anpheros.

Acces controlat

• Înregistrările cui. Cu o cheie API, agentul vede pacienții creați de proiectul dumneavoastră. Pentru a acționa asupra unei înregistrări existente a cuiva, este necesar un grant OAuth de la acea persoană — pentru un pacient, pentru 30 până la 365 de zile.
• Ce date. Scope-urile limitează tipurile de resurse și acțiunile, opțional la o categorie: patient/Observation.rs?category=laboratory permite unui agent să citească și să caute rezultate de laborator și nimic altceva. Pentru a construi un context, grantul trebuie să permită citirea observațiilor, condițiilor, medicației și alergiilor (de exemplu patient/*.rs).
• Doar citire implicit. Acordați scope-uri de scriere doar atunci când agentul este destinat să înregistreze ceva.
• Revocabil. Persoana poate revoca grantul în orice moment; următorul apel al agentului este refuzat.

Instrumente de care un agent are, de obicei, nevoie

Specificația OpenAPI (https://developers.anpheros.com/openapi.json) descrie fiecare endpoint și poate fi transformată în definiții de instrumente; SDK-urile TypeScript și Dart pot fi încapsulate direct ca instrumente.

Exemplu: un agent de pregătire a vizitei cu consimțământul pacientului

Un pacient care deține deja o înregistrare în Anpheros solicită unui asistent terț să pregătească întrebări pentru o vizită la cardiologie. Agentul are nevoie de acces de citire la înregistrare pentru o perioadă limitată – nimic mai mult.

1. Consimțământ (OAuth 2.1 + PKCE, SMART v2 scopes). Asistentul trimite persoana la pagina de consimțământ cu cele mai restrânse scope-uri care permit totuși un context (observații, afecțiuni, medicamente și alergii):

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. Instrumente. Runtime-ul agentului expune câteva funcții modelului; fiecare este un apel API real efectuat cu token-ul de acces:

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 }),
};

Descrieți-le modelului în orice format de instrument sau de apelare a funcțiilor pe care API-ul modelului dvs. îl utilizează; modelul propune un apel, runtime-ul dvs. îl execută și returnează JSON-ul. Modelul nu vede niciodată token-ul.

3. Ce impune platforma. Token-ul ajunge doar la înregistrarea acelei persoane și doar la tipurile cu scope; orice altceva răspunde 403 (un tip în afara scope-urilor) sau 404 (un alt pacient). Fiecare apel – inclusiv fiecare solicitare de context, cu manifest_id – apare în jurnalul de acces al persoanei pentru această aplicație. Dacă persoana revocă accesul, următorul apel răspunde 401 și agentul trebuie să se oprească; token-ul de reîmprospătare nu îl poate readuce.

4. Rezultat. Agentul returnează întrebări pentru medic, împreună cu sursele pe care le-a utilizat. Nu scrie nimic înapoi, deoarece nu i s-a acordat un scope de scriere.

Audit și proveniență

• Fiecare apel pe care agentul îl face este o accesare a înregistrării și apare în jurnalul de acces al pacientului pentru aplicația dvs. — inclusiv fiecare solicitare de context, care stochează, de asemenea, un manifest al secțiunilor și surselor utilizate.
• Tot ceea ce scrie agentul este înregistrat ca fiind autorat de AI în Provenance. Atunci când un context este construit ulterior, valorile scrise de AI sunt listate sub ai_notes, separat de faptele clinice, astfel încât un agent să nu ajungă să-și citeze propria ieșire anterioară ca dovadă.

Pornirea agenților din evenimente

Webhooks permit unui agent să ruleze atunci când ceva se schimbă — un nou rezultat de laborator (resource.created), un nou consimțământ (consent.granted) — în loc să facă polling. Evenimentele transportă doar ID-uri; agentul citește apoi ce permit scopurile sale. Webhooks

Reguli de design de reținut

1. Acordați agentului cele mai restrânse permisiuni (scopes) care completează sarcina.
2. Începeți dintr-un context, nu din citiri brute de volum mare; respectați omitted și warnings.
3. Afișați sursele de date ale pacientului în răspunsul agentului.
4. Nu permiteți niciodată agentului să prezinte un diagnostic sau să schimbe un tratament pe cont propriu; direcționați astfel de ieșiri către un clinician.
5. Înregistrați manifest_id al fiecărui context alături de răspunsul agentului, astfel încât o persoană să poată vedea ulterior pe ce s-a bazat răspunsul.

Conexe

• Cum să acordați unui agent AI acces la dosarele medicale: tutorial pas cu pas în Python
• Server FHIR MCP pentru agenți AI
• Aplicații AI în domeniul sănătății
• Aplicații LLM și date din domeniul sănătății
• Cum să construiți un chatbot medical cu date structurate
• Model de consimțământ și acces
• Autentificare și OAuth
• Date despre medicamente pentru aplicații de sănătate și agenți AI: lista pacientului vs. surse de cunoștințe despre medicamente

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