A quale medico può essere attribuita una prescrizione registrata in un gestionale sanitario? La risposta richiede di comprendere il significato dei campi del database e il funzionamento concreto della struttura.
Il medico curante del paziente, l’utente che inserisce una ricetta e il professionista indicato come prescrittore possono essere persone diverse. Confondere questi ruoli può produrre una lettura errata anche quando l’estrazione dei dati è tecnicamente corretta.
Una consulenza tecnica di parte su un sistema informativo sanitario mostra come affrontare il problema attraverso l’esame del gestionale, la raccolta dei backup, le verifiche di integrità delle copie e l’elaborazione di query SQL.
Il caso è descritto in forma anonimizzata. Sono omessi riferimenti personali, territoriali, commerciali e temporali puntuali. Le attività illustrate appartengono alla consulenza documentata e al contesto tecnologico dell’epoca.
L’incarico: analizzare le registrazioni delle prescrizioni
La consulenza era stata richiesta dalla difesa di un medico nell’ambito di un’indagine relativa a presunte condotte illecite connesse alla prescrizione di determinati integratori.
Si trattava di una consulenza tecnica di parte, finalizzata a estrarre e interpretare dati utili alla difesa. La relazione non costituisce una decisione giudiziaria e non documenta l’esito del procedimento.
Le richieste riguardavano due insiemi di prodotti: quelli specificamente oggetto di attenzione e un insieme più ampio individuato mediante i codici di classificazione presenti nel gestionale.
Per ciascun insieme occorreva distinguere le registrazioni riferibili al medico interessato da quelle dell’intera struttura, considerando anche le prescrizioni effettuate da altri professionisti per pazienti affidati alle sue cure.
Il sopralluogo e l’esame del sistema informativo
L’attività iniziava con un sopralluogo presso la struttura e con la verifica dell’ambiente informatico.
Il gestionale utilizzato era Millewin, in configurazione client-server, con database Sybase e connessioni ODBC. Il sistema operava su Windows XP.
L’esame comprendeva il server, le modalità di accesso e la disponibilità dei backup. Venivano inoltre raccolti manuali applicativi, documentazione sulle integrazioni del software, classificazioni dei prodotti e prospetti dei turni dei medici.
Questi documenti servivano a interpretare le registrazioni alla luce delle funzioni dell’applicativo e dell’organizzazione del lavoro.
Nel caso esaminato, la relazione precisava inoltre che le ricette considerate erano ricette bianche, non trasmesse attraverso il flusso regionale descritto per le prescrizioni del Servizio sanitario nazionale.
La raccolta dei backup e il confronto MD5
La relazione documenta il prelievo dei file del database da un backup recente e da un backup precedente, individuato sul sistema.
Per il materiale copiato venivano calcolate e confrontate le impronte MD5. Le schermate allegate riportano l’utilizzo di WinMD5Free e l’esito positivo dei confronti tra sorgente e copia.
Questo controllo sosteneva la corrispondenza dei file trasferiti rispetto a quelli selezionati per l’acquisizione.
È necessario distinguere tale verifica dalla valutazione della storia del database: il confronto delle impronte non dimostra, da solo, che i dati contenuti nel backup non fossero mai stati modificati prima della raccolta.
La procedura documentata riguardava file di backup del database. Non viene descritta un’acquisizione bit-a-bit dell’intero disco del server.
Un ambiente virtuale per le prove
Per analizzare il sistema senza interferire con l’attività della struttura, il consulente predispose un ambiente separato su macchina virtuale.
La relazione descrive un’installazione client-server del gestionale su Windows XP, realizzata mediante VMware Workstation. Su copie di lavoro del database venivano svolte simulazioni e verifiche.
Questa separazione consentiva di studiare il comportamento dell’applicativo e di effettuare prove di modifica senza operare direttamente sui dati di produzione.
Il test di cancellazione: una verifica importante sui limiti delle tracce
Tra le attività documentate figura un test di alterabilità.
Il consulente effettuò prove di cancellazione attraverso il gestionale e direttamente su una copia del database. Secondo quanto riportato, le prescrizioni eliminate dall’applicativo risultavano rimosse fisicamente dal database, senza che fosse stata rilevata una traccia dell’operazione nei log o nel database esaminati.
Il risultato aveva un’implicazione precisa: la disponibilità del database non assicurava, da sola, la possibilità di ricostruire tutte le eventuali cancellazioni precedenti.
La possibilità tecnica di cancellare un dato non dimostra però che una cancellazione sia realmente avvenuta nel caso concreto. Il test descriveva il comportamento osservato nelle condizioni provate.
La relazione riferisce anche il confronto dei dati dell’anno oggetto di interesse presenti nei due backup, con lo scopo di verificare eventuali alterazioni intervenute nell’intervallo tra le copie. Questo controllo offriva un ulteriore riscontro, ma il documento non presenta un prospetto analitico completo delle differenze dal quale ricavare autonomamente una garanzia assoluta di integrità storica.
Tre ruoli da distinguere
Il nucleo interpretativo della consulenza riguardava tre informazioni registrate dal gestionale.
| Informazione | Significato descritto nella relazione |
|---|---|
| Utente di inserimento | Account utilizzato al momento della registrazione della ricetta |
| Medico titolare | Medico curante dell’assistito al momento della prescrizione |
| Medico prescrittore | Professionista indicato come prescrittore nel gestionale |
La struttura operava secondo un modello di medicina di gruppo. Un paziente poteva rivolgersi al proprio medico oppure essere seguito dal medico di turno.
Il personale di segreteria e infermieristico poteva inoltre inserire e stampare determinate prescrizioni ripetitive secondo le regole organizzative descritte, mentre il medico veniva indicato nel parametro del prescrittore.
Di conseguenza, una ricetta destinata a un assistito del professionista interessato non era necessariamente una prescrizione attribuita a quel professionista.
Va mantenuta anche una distinzione ulteriore: il campo del gestionale identifica il prescrittore registrato. La lettura di quel valore non equivale, da sola, a una verifica autonoma della firma sul documento cartaceo.
Le query SQL e le diverse viste dello stesso fenomeno
Il consulente progettò query SQL per collegare le tabelle delle ricette, delle relative righe, delle terapie, dei pazienti e degli utenti.
Le estrazioni comprendevano informazioni sui prodotti, quantità, prezzi disponibili, date e ruoli associati alle registrazioni. I risultati venivano esportati in Excel e utilizzati per costruire tabelle e grafici.
L’analisi distingueva:
- prodotti specificamente oggetto di attenzione;
- prodotti compresi nelle classi selezionate;
- prescrizioni attribuite al professionista;
- prescrizioni rivolte ai suoi assistiti;
- volumi complessivi della struttura e andamento nel tempo.
Gli insiemi dovevano essere interpretati con attenzione: alcune elaborazioni per classificazione comprendevano anche i prodotti oggetto di attenzione, mentre altre risposte consideravano separatamente i prodotti alternativi.
L’appartenenza alla stessa classe veniva utilizzata come criterio di raggruppamento dei dati. Non rappresentava una dimostrazione di equivalenza clinica tra i prodotti.
I risultati riportati nella consulenza
Nel periodo esaminato, la relazione individuava una presenza sporadica delle prescrizioni attribuite al professionista interessato per i prodotti selezionati.
Per il sottoinsieme specificamente oggetto di attenzione risultava una sola confezione associata al suo ruolo di prescrittore. La registrazione riportava come utente di inserimento un account del personale non medico e riguardava un assistito di un altro professionista.
Separatamente, venivano individuate prescrizioni degli stessi prodotti rivolte ai suoi assistiti ma attribuite ad altri medici.
La distinzione modificava quindi il significato del conteggio: raggruppare i dati per medico curante avrebbe risposto a una domanda diversa rispetto al raggruppamento per prescrittore.
Nelle conclusioni, il CTP sottolineava la marginalità delle prescrizioni riferite al professionista rispetto ai volumi della struttura e la continuità, nel periodo successivo, delle registrazioni di prodotti appartenenti alle classi considerate, a fronte dell’assenza dei prodotti specificamente selezionati nell’estrazione relativa all’anno successivo.
Si tratta delle valutazioni formulate nella consulenza sui dati esaminati. Non consentono, da sole, di ricavare un esito processuale.
Qualità dei dati e cautele nei riepiloghi
La relazione segnalava alcune limitazioni concrete.
Per alcuni prodotti mancava il prezzo nel sistema: le quantità erano incluse nei conteggi, mentre la valorizzazione economica non ne comprendeva il contributo. Un importo nullo nel prospetto non significava quindi necessariamente gratuità del prodotto.
In alcune righe mancavano inoltre i nominativi associati agli utenti. Il documento riconduceva questa situazione alla cancellazione dal sistema di utenti non più operativi.
Anche gli identificativi delle righe richiedevano attenzione: la relazione descriveva una numerazione condivisa tra tabelle, per cui eventuali intervalli nella sequenza di una singola tabella non costituivano automaticamente prova di cancellazioni.
La lettura congiunta della relazione e della sintesi evidenzia infine incongruenze tra alcuni conteggi e importi. Inoltre, alcune query stampate riportano un intervallo di estrazione più ampio rispetto al periodo indicato nei quesiti.
Per questo i riepiloghi non devono essere trasformati in nuove statistiche senza riconciliare filtri, unità di conteggio e dati originari. I valori monetari elaborati descrivono la valorizzazione delle registrazioni secondo i prezzi disponibili: non documentano acquisti effettivi, incassi della struttura o compensi del professionista.
Il contributo dell’analisi informatica
Questo caso mostra che una perizia su un database richiede più della produzione di un elenco.
Occorre comprendere come vengono generati i dati, quali ruoli rappresentano, come possono essere modificati e quali informazioni storiche rimangono disponibili.
Il contributo della consulenza consisteva nell’aver distinto le registrazioni per prescrittore da quelle per medico curante, documentato le modalità di raccolta delle copie e verificato alcuni limiti di tracciabilità dell’applicativo.
È proprio questa relazione tra dato, funzionamento del software e organizzazione del lavoro a rendere l’analisi informatica utile alla ricostruzione dei fatti.
