Undici funzioni che lavorano dentro le entità che già usate — PAI e PRI, scale, diario, eMAR, agenda SSN, flussi regionali — e producono bozze con la fonte citata. Nessun output diventa dato senza la revisione e la firma di un utente abilitato.
Non un modello migliore: una posizione diversa. L'IA di SanIA nasce dentro un modello dati condiviso tra ospedale, RSA, riabilitazione e territorio, e obbedisce a tre principi senza eccezioni.
Ogni output nasce in stato di bozza e diventa dato clinico o amministrativo solo con la revisione e la firma di un utente abilitato. Il diff tra bozza e versione firmata resta nel registro. Nessuna decisione automatica con effetti sull'assistito (art. 7 L. 132/2025, art. 22 GDPR).
Le funzioni più utili attraversano i confini: la dimissione ospedaliera che diventa il primo PAI in RSA, lo scarto di flusso evitato prima dell'invio, il benchmark tra strutture. L'unità di valore è il percorso dell'assistito, non il reparto.
Ogni frase, codice o alert rimanda al record sorgente. Ogni chiamata registra modello, versione del prompt e revisore. Ogni modulo pubblica le proprie metriche — tasso di accettazione, omissioni rilevate — con metodologia dichiarata.
Per OSS, infermieri, fisioterapisti, coordinatori, medici, uffici flussi e direzione. Ogni funzione è attivabile per modulo e per struttura, e si ferma sempre un passo prima della firma.
Alla dimissione, dal ricovero pseudonimizzato nascono insieme la bozza di lettera CDA2 per il FSE 2.0, la scheda di passaggio con terapia riconciliata e scale, e la bozza del primo PAI se la struttura ricevente è su SanIA. Il medico dimettente rivede, completa e firma; l'équipe ricevente approva il PAI.
ApprofondisciAlla presa in servizio, una bozza con le sole variazioni dell'ultimo turno per nucleo: caduta notturna, terapia rifiutata, glicemia fuori soglia, nuova lesione segnalata dall'OSS. Ogni frase apre la voce di diario sorgente. Il coordinatore legge, annota, conferma e firma: solo allora la consegna diventa documento archiviato.
ApprofondisciAlla scadenza o dopo un evento sentinella, una bozza da Barthel, Braden, Tinetti, FIM, diario e piano precedente: obiettivi misurabili, interventi per figura, codici ICF con la frase sorgente. Un motore di regole segnala le incoerenze, come Braden 12 senza superficie antidecubito. L'équipe discute, modifica e firma.
ApprofondisciLettere di dimissione, referti e impegnative in PDF diventano campi strutturati proposti, con pagina e riga citate. Il confronto con la terapia attiva mostra nuovi, sospesi e dosi cambiate, riga per riga; le interazioni restano al database del prontuario. Il medico di struttura accetta o rifiuta ogni riga: nulla si aggiorna da solo.
ApprofondisciPrima dell'invio di FAR, SIAD, SDO o EMUR, i record a rischio scarto con il motivo probabile, la specifica citata e la correzione proposta: data valutazione UVM successiva all'ingresso, codice ASL mancante. L'ufficio flussi rivede e corregge record per record o in blocco; nessun invio automatico.
ApprofondisciDomande in italiano sui vostri dati: minuti OSS per ospite nel nucleo Alzheimer rispetto allo standard regionale, saturazione dei letti per UO. Risposte con formula, tabelle citate e SQL visibile, nei permessi della vostra UO. Nessuna azione automatica; benchmark anonimo tra strutture solo con adesione esplicita.
ApprofondisciRequisiti regionali, tariffari e specifiche dei flussi in un corpus curato e versionato, interrogato sui vostri record: PAI oltre scadenza, contenzioni senza rivalutazione a 7 giorni, BLSD scaduti, quota ASL per classe SOSIA. Ogni rilievo cita requisito e record. Il responsabile qualità valida e assegna le azioni correttive: è un supporto, non un parere legale.
ApprofondisciUn agente WhatsApp che si dichiara IA legge il NRE dalla foto dell'impegnativa, verifica prestazioni ed esenzione su Sistema TS e propone il ciclo di sedute nei tempi PNGLA con lo stesso terapista. Non decide la priorità: la legge dalla ricetta. Ogni conversazione è trascritta; i dubbi passano all'operatore.
ApprofondisciDa erogato, prenotato e stagionalità, la previsione mese per mese della saturazione dei tetti per regime e sede, con una proposta di riallocazione degli slot tra SSN, privato e convenzioni. La direzione rivede e approva; le agende non cambiano da sole e nessun assistito viene selezionato.
ApprofondisciChatbot della struttura su sito, WhatsApp e totem: reparti e orari, prenotazioni sulle agende vere, referti e indicazioni per arrivare dalle planimetrie. Si dichiara automatico, non fa triage e passa all'operatore quando serve.
ApprofondisciTotem fisico all'ingresso: check-in con tessera sanitaria o QR, eliminacode, mappa del piano con percorso al reparto e assistente vocale. Stessi dati di agenda, organizzazione e planimetrie della piattaforma.
ApprofondisciIl layer di governance è costruito prima delle funzioni, non dopo. Ogni modulo IA lo eredita: per questo è presentabile in una gara pubblica e leggibile dal vostro DPO.
Tutte le chiamate passano da un unico gateway. Prima dell'invio, CF, nomi, date di nascita e telefoni sono sostituiti in modo deterministico e reversibile lato database: il modello lavora su identificativi, non su persone. Il testo libero del diario è verificato a campione.
Per ogni tenant e modulo: finalità, base giuridica, livello di rischio AI Act, stato MDR, DPIA precompilata, metriche pubblicate. Stampabile per le gare e per il DPO, con interruttore on/off per modulo e struttura.
Ogni esecuzione registra modulo, finalità, modello e versione, hash dell'input, output, costo, revisore e data, collegati all'AuditEvent della cartella. Conservazione secondo la vostra policy; l'audio delle dettature è cancellato dopo la firma.
L'inferenza è progettata per endpoint europei con accordi di trattamento dei dati (DPA), oppure per modelli open eseguiti nel perimetro del tenant per chi richiede un'IA sovrana. Nessun chatbot generalista, nessuna API senza DPA.
Ogni output resta bozza finché un utente abilitato non lo rivede e lo conferma. Le modifiche apportate prima della firma vengono registrate: sono la prova della revisione e la base per misurare la qualità nel tempo.
Per ogni funzione un set di casi di riferimento con tasso di accettazione, omissioni e precisione per campo, ricalcolati a ogni cambio di modello o prompt. Nessun claim di accuratezza senza metodologia dichiarata.
Progettata per il decalogo del Garante sull'IA in sanità (2023), per l'art. 7 della L. 132/2025 (decisione sempre rimessa al professionista, informazione all'assistito) e per gli obblighi di trasparenza dell'art. 50 dell'AI Act.
Sei confini scelti per proteggere assistiti, professionisti e struttura. Per ognuno c'è un'alternativa che funziona e resta dentro le regole.
Le bozze riguardano documentazione, organizzazione e interventi assistenziali. Il giudizio clinico resta al medico: un claim diagnostico farebbe del software un dispositivo medico, e la decisione è per legge del professionista.
Nessun alert su cadute, sepsi o riammissione del singolo assistito nella prima release. Gli indicatori sono organizzativi e aggregati; eventuali modelli predittivi maturano in modalità silente, con un percorso di qualificazione MDR o un partner certificato.
L'agente di front-office prenota, sposta e ricorda; non valuta sintomi e non assegna priorità. Legge la classe dalla ricetta e passa all'operatore ogni richiesta ambigua, dichiarandosi sempre come IA.
Alert su interazioni, allergie e farmaci LASA vengono solo dal database del prontuario, deterministico e tracciabile. L'IA si limita a estrarre e confrontare, mai a valutare una combinazione di farmaci.
Il modello no-show alimenta soltanto promemoria mirati e liste di recupero degli slot liberati. Nessun assistito viene selezionato o condizionato nell'accesso alle prestazioni: lo vieta l'art. 7 della L. 132/2025.
Le bozze di aggiornamento per le famiglie passano sempre da un operatore che legge ogni parola prima dell'invio, con etichetta di assistenza IA. La comunicazione di dati sanitari a terzi resta una responsabilità umana.
No. Ogni output nasce come bozza e diventa dato solo con la revisione e la firma di un utente abilitato: medico, coordinatore, fisiatra, responsabile qualità o direzione a seconda della funzione. Nessuna decisione automatica ha effetti sull'assistito, come richiedono l'art. 7 della L. 132/2025 e l'art. 22 del GDPR.
L'architettura prevede endpoint nell'Unione europea con accordi di trattamento, dopo la pseudonimizzazione di CF, nomi e date lato database. Per gli enti che richiedono un'IA sovrana, SanIA è predisposta a eseguire modelli open dentro il perimetro del tenant. Nessun dato clinico passa da chatbot generalisti.
Le nove funzioni a catalogo producono bozze di documentazione, sintesi, estrazioni e previsioni amministrative, senza claim diagnostici né raccomandazioni terapeutiche: sono progettate per restare fuori dal perimetro MDR. Le eventuali funzioni di supporto decisionale clinico sono progettate come moduli separati con un proprio percorso.
Sì. Ogni funzione ha un interruttore per modulo e per struttura nel Registro IA. Potete partire da Ask SanIA e dal Guardiano dei flussi, che trattano dati aggregati o amministrativi, e attivare le funzioni sulla cartella dopo la DPIA con il vostro DPO.
Ogni funzione ha un set di casi di riferimento con metriche di omissione, accettazione e precisione per campo, ricalcolate a ogni cambio di modello o prompt. Le metriche sono pubblicate nel Registro IA insieme alla metodologia. Non dichiariamo percentuali di accuratezza senza questa base.
Raccontateci setting, Regione e volumi: prepariamo una demo sul vostro caso reale, con i moduli e i flussi che usate davvero.
