È il primo lunedì del mese. Puoi mostrarmi il report di audit?
AGENTE · CLINICAL SYSTEM AUDIT
I sistemi clinici passano da audit periodico su privacy e tracciabilità.
Clinical System Audit esegue audit mensile dei sistemi clinici della struttura sanitaria (HIS, LIS, sistema RIS, integrazione FSE 2.0). Verifica privacy GDPR art. 9, tracciabilità delle decisioni cliniche, conformità MDR per software classificati come dispositivi medici. Decisione tracciata.
Clinical System Audit al lavoro.
Report audit ottobre 2025. Sistemi verificati: HIS, LIS, RIS, cartella elettronica, FSE 2.0. Anomalie: 2 accessi alla cartella fuori orario (infermieristico, 02:12 e 02:47). 1 configurazione encryption degradata su servizio LIS (AES-256 → AES-128, non autorizzata). 3 record FSE 2.0 con log incompleti. Criticità: 1 alta (LIS), 2 medie (accessi), 1 bassa (log FSE).
Avvio le procedure per le tre anomalie. Grazie.
Perché esiste.
I sistemi clinici di una struttura sanitaria mid-large sono molti: HIS, LIS, RIS, cartella elettronica, integrazione FSE 2.0, sistemi specifici per reparto. Ciascun sistema gestisce dati sensibili di categoria art. 9 GDPR e ha vincoli regolatori specifici. L'audit periodico richiesto da GDPR, MDR e regolamenti regionali è oggi un lavoro manuale coordinato fra IT, DPO e responsabile sanitario.
Come lavora ogni mese.
Clinical System Audit si attiva con schedulazione mensile (o più frequente per i sistemi critici). Per ciascun sistema clinico configurato legge i log di accesso, le configurazioni di sicurezza, confronta con le baseline dichiarate dal team compliance, identifica anomalie. Il volume e la complessità che rendono l'audit completo difficile da fare manualmente diventano gestibili.
La decisione resta al DPO e al responsabile sanitario.
L'agente esegue l'audit automatico periodico e identifica anomalie sulla base delle baseline configurate. La decisione di gestione delle anomalie — sanzioni interne, comunicazione al regolatore, rimedio tecnico — resta del DPO e del responsabile sanitario secondo le procedure della struttura.
DPO, responsabile sanitario e responsabile IT della struttura.
DPO della struttura sanitaria
Il DPO recupera il tempo dell'audit manuale dei sistemi clinici. La capacità si concentra sui casi che richiedono giudizio: le anomalie identificate, non la raccolta dei dati per identificarle. Le procedure di gestione partono da elenchi strutturati, non da analisi a campione.
Audit settimanale 4 sistemi
HIS · accessi OK
LIS · referti OK
FSE 2.0 · tracciabilità VERIFICA
RIS · privacy OK
1 anomalia · alert al responsabile AGENAS
Responsabile sanitario
Il responsabile sanitario vede in modo strutturato la qualità della gestione dei dati clinici. Il rischio di data breach o di non conformità GDPR/MDR passa da rischio diffuso a anomalie identificate, ciascuna con la baseline che le ha generate.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
Responsabile IT della struttura
Il responsabile IT riceve azioni di rimedio strutturate. La gestione delle vulnerabilità sui sistemi clinici entra nel flusso operativo mensile, non resta affidata a iniziative reattive post-incidente.
visita ambulatoriale · 18:24
«la paziente riferisce dispnea da sforzo da circa due mesi…»
I50.9 Insufficienza cardiaca, non specificata
R06.0 Dispnea
Cartella elettronica popolata · firma medico richiesta
Audit mensile di cinque sistemi clinici.
L'agente si attiva il primo lunedì di ogni mese.
Per un ospedale privato di medie dimensioni con 5 sistemi clinici principali (HIS, LIS, RIS, cartella elettronica, integrazione FSE 2.0), l'agente è schedulato il primo lunedì di ogni mese. Legge log e configurazioni dei 5 sistemi del mese precedente, confronta con la baseline dichiarata dal DPO e dal responsabile sanitario.
Tre anomalie, classificate per criticità.
L'agente identifica tre anomalie: 2 accessi alla cartella clinica fuori orario di servizio non motivati da reperibilità (personale infermieristico su pazienti non assegnati al turno notturno), 1 configurazione di encryption degradata su un servizio LIS (modifica non autorizzata dal team security), 3 record FSE 2.0 con log incompleti (manca il riferimento al medico autore per modifiche via integrazione automatica).
Il DPO avvia le procedure; l'evento resta nel registro audit.
La sintesi arriva al DPO e al responsabile sanitario il primo lunedì del mese sul canale di lavoro. Il DPO avvia le procedure: richiesta di motivazione al personale per gli accessi fuori orario, rimedio tecnico al team IT per l'encryption LIS, fix del sistema di integrazione FSE 2.0. L'evento completo resta nel registro audit del runtime per audit GDPR art. 9, MDR e ispezione AGENAS o regionale.
Baseline dichiarative, sistemi clinici in delivery.
Le regole di Clinical System Audit sono dichiarative. Il DPO, il responsabile sanitario e il responsabile IT della struttura definiscono in formato leggibile le baseline di privacy (pattern di accesso ammessi, autorizzazioni per ruolo), le baseline di sicurezza tecnica (encryption, autenticazione, schema log), i requisiti di tracciabilità (schema log FSE 2.0, schema log MDR). Le regole vivono nel repository del cliente, versionate, validate all'avvio dell'agente.
L'integrazione con i sistemi clinici (HIS, LIS, RIS, FSE 2.0) si realizza tramite adapter dedicato in fase di delivery dal team Exelab. I sistemi clinici sono molto eterogenei per struttura sanitaria — la fattibilità tecnica dell'integrazione per audit dipende dal sistema specifico e si definisce in fase di discovery.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, credential-detector, topic-guardrail, tool-rate-limit
- Canali nativi di consegna
- Slack, Telegram, HTTP OpenAI-compatible
- Integrazione sistemi clinici (HIS, LIS, RIS, FSE 2.0)
- adapter dedicato realizzato in fase di delivery (sistemi proprietari, soluzioni regionali, integrazioni FSE 2.0)
- Baseline privacy + sicurezza + tracciabilità
- dichiarative, versionate, scritte da DPO + responsabile sanitario + IT
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS sui pattern storici
- Registro
- immutabile, interrogabile con client SQL standard (audit GDPR art. 9, MDR, FSE 2.0 ispezionabile)
Domande frequenti sull'agente.
No. L'agente esegue l'audit automatico periodico e identifica anomalie sulla base delle baseline configurate. La decisione di gestione delle anomalie — sanzioni interne, comunicazione al regolatore, rimedio tecnico — resta del DPO e del responsabile sanitario secondo le procedure della struttura.
Quando l'anomalia rientra nei pattern che richiedono comunicazione formale al regolatore (data breach significativo ai sensi art. 33 GDPR), l'agente segnala il pattern con la procedura applicabile. La decisione di comunicare al regolatore resta del DPO secondo le procedure di gestione incidenti della struttura.
I sistemi clinici sono molto eterogenei: HIS, LIS, RIS e FSE 2.0 variano per struttura sanitaria (sistemi proprietari, soluzioni regionali, integrazioni con sistemi nazionali). L'integrazione si realizza tramite adapter dedicato in fase di delivery dal team Exelab. I pattern di integrazione più comuni vengono definiti in fase di discovery commerciale.
Il pattern tipico per Clinical System Audit è 14-20 settimane. Discovery 3-4 settimane, scrittura baseline e regole con DPO + responsabile sanitario + IT 5-7 settimane, integrazione sistemi clinici 5-7 settimane, hand-off 2-3 settimane.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Clinical System Audit si configurerebbe sul caso della struttura sanitaria. Quali sistemi clinici, quale baseline privacy e sicurezza, quale frequenza di audit.