Una migrazione non è la copia di un database
Cambiare gestionale veterinario significa trasferire il contesto con cui la clinica lavora: proprietari, pazienti, cartelle, allegati, appuntamenti, listini, documenti amministrativi e informazioni di magazzino. Copiare righe e file senza preservarne i collegamenti può produrre un archivio numericamente completo ma inutilizzabile.
Prima di chiedere tempi e costi, occorre definire quali informazioni devono essere operative il giorno dell'avvio, quali possono restare consultabili come storico e quali non devono essere importate. Il progetto dovrebbe avere un referente della struttura, un referente tecnico, criteri di accettazione e una procedura per i record che non possono essere convertiti automaticamente.
La pagina sul servizio di migrazione dati VetDesk descrive l'analisi preliminare offerta dal team. Questa guida, invece, serve a preparare inventario, test e domande prima di scegliere il fornitore: i due contenuti rispondono a intenti diversi.
1. Fare l'inventario prima di esportare
Elenca gli archivi effettivamente presenti: proprietari, animali, specie, razze, microchip, anamnesi, diagnosi, terapie, prescrizioni, referti, immagini, consensi, appuntamenti, ricoveri, preventivi, fatture, pagamenti, giacenze, lotti, scadenze e listini. Per ogni gruppo annota formato disponibile, volume, periodo storico, responsabile della verifica e necessità d'uso nel nuovo sistema.
Conviene separare almeno tre classi:
- dati operativi: devono essere ricercabili e modificabili dal primo giorno;
- storico consultabile: deve restare leggibile e collegato al paziente, senza necessariamente diventare un campo modificabile;
- dati esclusi: duplicati, prove, record senza valore o informazioni la cui conservazione non è giustificata.
Questa classificazione evita di trasformare la nuova cartella clinica veterinaria in un deposito disordinato e riduce il rischio di portare nel nuovo ambiente dati non necessari.
2. Chiedere un export leggibile e documentato
Un backup proprietario non equivale a un'esportazione utilizzabile. I file strutturati dovrebbero avere intestazioni comprensibili, codifica dichiarata e identificativi stabili; gli allegati dovrebbero essere collegabili al record corretto. Prima di qualsiasi trasformazione conserva una copia originale protetta, con data, provenienza e controllo d'integrità.
Verifica nel contratto chi prepara l'export, quali formati sono disponibili, se allegati e log sono inclusi, quali tempi e costi si applicano e come viene consegnata la documentazione dei campi. Se la struttura usa più strumenti — gestionale, PACS, laboratorio, fogli di calcolo — l'inventario deve includere anche i collegamenti tra sistemi.
3. Non confondere l'export tecnico con il diritto alla portabilità
L'articolo 20 del GDPR riconosce alla persona interessata, quando ricorrono le condizioni previste, il diritto di ricevere i dati personali che ha fornito in un formato strutturato, di uso comune e leggibile da dispositivo automatico. Non è una regola generale che obbliga un fornitore a convertire ogni dato aziendale, configurazione o documento nel formato preferito dalla clinica.
Le linee guida sulla portabilità, approvate dal Comitato europeo per la protezione dei dati, chiariscono ambito, condizioni e rapporto con i diritti altrui. Per una migrazione occorre quindi distinguere il diritto degli interessati dagli obblighi contrattuali e tecnici tra clinica e fornitori. Ruoli privacy, base giuridica, conservazione e accesso allo storico vanno valutati sul caso concreto, coinvolgendo il consulente privacy quando necessario.
4. Costruire il mapping dei campi
Il mapping stabilisce dove finisce ogni informazione. “Cliente” può significare proprietario, pagatore o referente; “data visita” può indicare prenotazione, apertura o chiusura; una nota libera può contenere dati che nel nuovo sistema hanno campi separati. Per ogni campo documenta origine, esempio, destinazione, trasformazione, valore predefinito e regola di esclusione.
Richiedono particolare attenzione le codifiche di specie, sesso, stato del paziente, prestazioni, aliquote, sedi e utenti. Normalizzare non significa cancellare le differenze: ogni conversione deve poter essere spiegata e ripetuta. Le correzioni manuali eseguite durante il test devono diventare regole, non eccezioni invisibili.
5. Provare un campione rappresentativo
Prima della migrazione completa, importa un campione che contenga casi semplici e difficili: pazienti con molti anni di storia, omonimi, più proprietari, record incompleti, allegati voluminosi, ricoveri, fatture e documenti con date differenti. Il team deve verificare non solo quanti record sono arrivati, ma se la storia è comprensibile e utilizzabile.
Definisci controlli misurabili: conteggi per archivio, record senza identificativo, confronti di somme dove appropriato, apertura degli allegati e verifica manuale di un campione casuale. Controlla ricerca, cronologia, collegamenti, ordinamento delle date e associazione tra proprietario e paziente. Ogni anomalia deve produrre una correzione del mapping e un nuovo test.
6. Proteggere i dati durante trasferimento e collaudo
I principi dell'articolo 5 del GDPR richiedono, tra l'altro, minimizzazione, esattezza e integrità e riservatezza. L'articolo 32 richiede misure tecniche e organizzative adeguate al rischio. In pratica, il progetto deve stabilire chi può accedere ai file, come vengono trasferiti e cifrati, dove restano le copie temporanee, come vengono registrate le attività e quando i file di lavoro vengono eliminati in sicurezza.
Non inviare esportazioni cliniche tramite canali improvvisati o account personali. Utilizza ambienti autorizzati, accessi nominativi e privilegi limitati. Se interviene un fornitore che tratta dati per conto della clinica, verifica anche accordi, istruzioni e responsabilità coerenti con il ruolo svolto.
7. Pianificare il cutover senza bloccare la clinica
- stabilire data e ora di congelamento delle modifiche sul vecchio sistema;
- eseguire l'export finale e conservarne la copia originale;
- importare con le regole già approvate nel collaudo;
- validare pazienti, agenda, documenti e casi essenziali prima dell'apertura;
- comunicare al team da quale momento usare il nuovo sistema;
- mantenere un piano di ritorno o consultazione se emerge un problema critico;
- assegnare anomalie e richieste a un referente unico nei primi giorni.
La finestra di passaggio va scelta in base a turni, urgenze, agenda e disponibilità di chi deve verificare. Un fine settimana non è automaticamente la soluzione migliore. Prima dell'avvio, il team dovrebbe provare accessi, ruoli e procedure essenziali; la guida su come scegliere il software veterinario aiuta a collegare la migrazione alla valutazione complessiva del sistema.
8. Verificare dopo l'avvio
Nei primi giorni controlla ricerche, anagrafiche duplicate, documenti mancanti, allegati non apribili, appuntamenti futuri, saldi e record senza collegamento. Registra ogni anomalia con priorità, proprietario e stato. Il vecchio ambiente non dovrebbe essere dismesso finché i criteri di accettazione non sono soddisfatti e la modalità di accesso allo storico è definita.
La chiusura del progetto richiede un verbale o un riepilogo: perimetro effettivamente importato, controlli completati, eccezioni note, destinazione delle copie temporanee e responsabilità residue. Questo documento evita che mesi dopo nessuno sappia quali informazioni siano state escluse o trasformate.
Checklist operativa
- archivi, volumi e priorità inventariati;
- formati di export e dizionario dei dati disponibili;
- copia originale protetta e verificata;
- mapping approvato con anomalie note;
- campione rappresentativo testato;
- conteggi e controlli di qualità documentati;
- accessi, trasferimento e copie temporanee gestiti in sicurezza;
- piano di cutover, comunicazione e ritorno definito;
- verifica post-avvio e modalità di accesso allo storico concordate.