# Applicazioni sanitarie basate sull'IA

> Cosa richiedono le applicazioni sanitarie basate sull'IA dal loro data layer — dati strutturati, pertinenza, fonti, consenso, responsabilità — e come Anpheros lo fornisce senza ospitare modelli.

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

**Un'applicazione sanitaria basata sull'IA utilizza un modello di machine learning — tipicamente un modello linguistico di grandi dimensioni — per aiutare le persone o i clinici con informazioni sanitarie: rispondere a domande sul record di una persona, riassumere risultati, preparare una visita, individuare tendenze.** La sua qualità dipende dal contesto del paziente che il modello riceve, e la sua affidabilità dalle regole che circondano tale contesto. Anpheros fornisce il data layer medico per tali applicazioni: accesso con consenso al record HL7 FHIR R4 di un paziente, un API di contesto che prepara la parte pertinente di esso per un modello, e un audit di ciò che l'IA ha letto.

Anpheros non ospita né esegue modelli di IA e non ha integrazioni ufficiali con alcun fornitore di IA. La tua applicazione chiama il modello che scegli.

## L'architettura

```
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
```

## Quale database o backend dovrebbe utilizzare un'applicazione sanitaria AI per i dati dei pazienti?

Anpheros può essere quel livello. È un data store HL7 FHIR R4 gestito — un backend FHIR per le cartelle cliniche dei pazienti — accessibile tramite API, con consenso del paziente, provenienza, un registro degli accessi e un'API di contesto AI integrati. Non è un database SQL generico e non è una piattaforma AI: la tua applicazione mantiene i propri utenti, impostazioni e dati non medici nel proprio database, memorizza e legge i dati medici dei pazienti tramite l'API Anpheros e chiama il modello che preferisci.

## Cosa necessita un'applicazione sanitaria AI dal suo data layer

| Necessità | Perché | In Anpheros |
|---|---|---|
| Dati strutturati e codificati | i modelli ragionano meglio su "HbA1c 6.4 % (LOINC 4548-4), 2026-09-01" che su un PDF | Risorse FHIR R4 con LOINC, ICD-10, ATC, UCUM |
| Rilevanza all'interno di un budget | un intero record non rientra in un prompt e i dati irrilevanti diluiscono le risposte | API di contesto con `task`, `question`, `needs` e `budget_tokens` |
| Fonti per ogni fatto | il modello — e l'utente — devono conoscere un risultato di laboratorio da una nota digitata | `author_type` e `source` su ogni elemento; `omitted` elenca ciò che è stato omesso |
| Separazione dell'output AI dai fatti | i riassunti AI precedenti non devono diventare "fatti" nei prompt successivi | Valori scritti dall'AI mantenuti separati sotto `ai_notes` |
| Consenso | il paziente decide se una funzionalità AI può leggere il proprio record | Concessioni OAuth; un contesto richiede l'accesso in lettura a osservazioni, condizioni, farmaci e allergie |
| Responsabilità | i pazienti dovrebbero vedere che un assistente ha letto i propri dati | Ogni richiesta di contesto appare nel log di accesso del paziente, con un ID manifest |

## Architettura di esempio: un'applicazione sanitaria AI su Anpheros e FHIR

Un'app companion per l'ipertensione: le persone registrano la pressione sanguigna e i farmaci, un laboratorio invia i risultati e un assistente spiega cosa è cambiato. Ogni chiamata di seguito fa parte dell'API pubblica.

```
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
```

Il gestore delle richieste dell'assistente nel tuo 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 };
}
```

Cosa possiede ogni parte:

| Parte | Possiede |
|---|---|
| La tua app e il tuo backend | utenti, interfaccia utente, prompt, regole di sicurezza, la scelta del modello |
| Anpheros | i dati medici del paziente (FHIR R4), il consenso, la provenienza, il log di accesso, l'API di contesto, l'importazione di laboratorio, i webhook |
| Il modello | comprensione del linguaggio e la formulazione della risposta — mai le credenziali |

Una versione eseguibile del passaggio context-plus-model è negli esempi pubblici: [ai-context-llm](https://github.com/anpheros/anpheros-sdk/tree/main/examples/ai-context-llm).

## Tipi di applicazioni supportate

- **Assistenti rivolti ai pazienti** che rispondono a domande utilizzando il record della persona nel contesto. → [Come creare un chatbot medico con dati strutturati](https://developers.anpheros.com/it/guides/ai-medical-assistant)
- **Agenti** che eseguono attività multi-step su un record: preparazione di un riepilogo di visita, riconciliazione di un elenco di farmaci, verifica delle modifiche dall'ultima revisione. → [Agenti AI e dati medici](https://developers.anpheros.com/it/guides/ai-agents-medical-data)
- **Funzionalità LLM all'interno di software esistenti**, con un modello ospitato o locale. → [Applicazioni LLM e dati sanitari](https://developers.anpheros.com/it/guides/llm-healthcare-data)
- **Software medico scritto con strumenti di codifica AI**, in cui il codice generato dovrebbe basarsi su un'API di dati medici testata. → [Anpheros per sviluppatori AI](https://developers.anpheros.com/it/guides/ai-developers)

## Limiti per cui dovresti progettare

- La risposta di un modello non è una decisione clinica. Presenta gli output come informazioni, mostra le fonti e indirizza al clinico qualsiasi cosa che assomigli a una diagnosi o a una modifica del trattamento.
- Anpheros non rivendica certificazioni come dispositivo medico o altre approvazioni normative; se la tua funzionalità AI è regolamentata dipende da ciò che dichiara di fare, e tale valutazione spetta a te.
- Se utilizzi un modello ospitato, il contesto lascia la tua infrastruttura per quel provider; il tuo testo di consenso e gli accordi di elaborazione dei dati devono coprirlo. Con un modello locale, il prompt rimane sulla tua infrastruttura.
- Anpheros non fornisce oggi un server Model Context Protocol (MCP).

## Correlati

- [Come creare un'app sanitaria AI con un backend FHIR](https://developers.anpheros.com/it/guides/build-ai-healthcare-app): tutorial passo-passo in TypeScript
- [Come concedere a un agente AI l'accesso alle cartelle cliniche](https://developers.anpheros.com/it/guides/ai-agent-access-medical-records): tutorial passo-passo in Python
- [Agenti AI e dati medici](https://developers.anpheros.com/it/guides/ai-agents-medical-data)
- [Applicazioni LLM e dati sanitari](https://developers.anpheros.com/it/guides/llm-healthcare-data)
- [Come creare un chatbot medico con dati strutturati](https://developers.anpheros.com/it/guides/ai-medical-assistant)
- [Anpheros per sviluppatori AI](https://developers.anpheros.com/it/guides/ai-developers)
- [Infrastruttura dati medica](https://developers.anpheros.com/it/guides/medical-data-infrastructure)
- [Cure virtuali e medici AI: i dati del paziente di cui hanno bisogno](https://developers.anpheros.com/it/guides/virtual-care-ai-data)