Le istanze sono state generate alla base del consuntivo visite fornitoci dal provider relativamente al periodo 01/01/2004 30/11/2008. Tali dati sono stati organizzati in un le Excel, consistente di 4 fogli di lavoro:
• Operatori Contiene informazioni dettagliate sugli operatori, quali livello di skill, appartenenza ai presidi e ore di lavoro settimanali. È presente inoltre un identi cativo che permette di classi care l'operatore come infermiere o addetto a svolgere altre mansioni.
• Anagra ca Pazienti Contiene informazioni quali anno di nascita, ses- so e comune di residenza. I pazienti sono suddivisi per presidio di appartenenza.
• Pro li Pazienti Qui vengono indicati il CP del paziente e le date di inizio e ne trattamento. Nel caso venga modi cato il CP di un paziente, viene chiuso il vecchio trattamento e ne viene aperto uno nuovo.
• Consuntivo Visite Consiste di un elenco delle visite svolte nel distret- to scelto. Per ciascuna visita vengono indicati il paziente, l'operatore e la data
Non sono state fornite informazioni relative alla durata degli interventi, ai quali abbiamo associato un valore standard di 30 minuti.
Per lo svolgimento delle prove è stato scelto il presidio di dimensione mag- giore tra quelli presenti, sia in termini di pazienti in cura che in termini di estensione territoriale.
Da tale presidio abbiamo selezionato gli operatori attivi sul presidio con identi catore 17, corrispondente agli infermieri. Sono dunque stati esclusi tutti gli operatori assegnati ad altri presidi e con quali che diverse da quella di infermiere.
L'insieme ottenuto consiste di 8 infermieri di skill 1 e 3 infermieri di skill 2. In alcuni casi questo numero è stato ridotto poichè nelle settimane selezionate qualche operatore era indisponibile e quindi non presente nello scheduling del consuntivo.
I pazienti vengono inizialmente ltrati in base al CAP, indicato nel foglio di lavoro Anagra ca Pazienti, controllando che il comune associato faccia parte dei 10 comuni del presidio.
Successivamente viene applicato un ltro al consuntivo visite, con lo sco- po di selezionare quelle eettuate esclusivamente nella settimana selezionata. Abbiamo operato considerando orizzonti temporali relativi ai soli giorni la- vorativi di una settimana, intervallo lunedì-venerdì, ma il modello prevede
intervalli di lunghezza essibile.
Questa prima fase è condivisa da tutti i test eettuati.
Riguardo la generazione delle richieste dei pazienti sono state intraprese due politiche, entrambe legate all'assegnazione delle richieste palliative:
• Tenendo conto del CP del paziente In una prima fase viene assegna- to un valore standard pari a 0 alle richieste (di skill 1 o 2) di ciascun paziente. A questo punto viene avviata una procedura che scorre ite- rativamente le visite contenute nel foglio di lavoro Consuntivo Visite e per ciascuna visita eettuata viene incrementato di 1 il numero di richieste (di skill 1) del paziente in questione.
Al termine di questa procedura viene controllato il CP di ciascun pa- ziente della lista. Se il paziente necessita cure palliative (CP 6,7,8) il valore di richieste di skill 2 viene determinato sottraendo dalle richieste di skill 1 la metà del suo valore arrotondato per eccesso ed assegnando tale valore al numero di richieste di skill 2.
• Tenendo conto delle skill dell'operatore Non tutte le visite di CP 6, 7 o 8 vengono nei casi reali eettuate da infermieri abilitati ad eettuare cure palliative.
Nella procedura utilizzata in questo caso viene considerato il valore di skill dell'operatore per determinare la skill necessaria alla richiesta. Per ciascuna visita analizzata scorrendo le visite del consuntivo se l'o- peratore ha skill 2 la visita corrispondente verrà considerata di tipo palliativo, e di conseguenza il valore delle richieste di skill 2 del pazien- te in questione sarà incrementato di 1. Analogamente si opera per le richieste di skill 1.
Per la creazione di alcune istanze sono state anche generate richieste in modo random. I test relativi alle istanze in questione richiedevano un certo numero di richieste palliative generato secondo un valore percentuale delle richieste totali, passato come parametro dall'utente. A questo scopo si opera come la procedura utilizzata nel primo caso, considerando inizialmente tutte le richieste come non palliative. Successivamente viene calcolato il numero totale di richieste e, in base alla percentuale desiderata, un certo numero di esse viene assegnato iterativamente alle richieste di skill 2.
Una volta determinati gli operatori e i pazienti, con le relative richieste, si passa alla generazione dei pattern.
È stata utilizzata una procedura a due fasi.
La prima fase consiste nello scorrere la lista di pazienti e nel contare il numero di occorrenze di una certa coppia di richieste. Viene dunque restitui- ta in output una tabella che riporta per ogni riga: il numero di richieste di
skill 1, il numero di richieste di skill 2 e il numero di occorrenze della coppia composta da tali valori.
La seconda fase scorre tale tabella e per ogni riga opera nel seguente modo.
Viene diviso il numero di occorrenze per un parametro. Se tale nume- ro non è intero viene arrotondato per eccesso. La scelta del parametro è legata alla struttura e alla dimensione dell'istanza. Nelle istanze testate è stato assegnato empiricamente il valore 4, ottenendo un buon compromesso tra numero di pattern generati e risolvibilità delle istanze. In base al valo- re ricavato vengono generati casualmente altrettanti pattern. Ad esempio, se la tabella ha la riga 1 1 7 possono essere generati i pattern (0,1,0,2,0) e (2,0,0,1,0). Nei casi in cui le richieste sono del tipo (1,0) o (0,1), cioè viene richiesta una sola visita, al massimo vengono generati 5 pattern per tipo, corrispondenti a una visita per giorno della settimana.
In aggiunta alla procedura sopra citata in alcune istanze, in particolare quelle con le richieste ricavate a consuntivo, i pattern sono stati creati a consuntivo. Dal consuntivo visite vengono ordinate le visite secondo il codice paziente. Scorrendo la lista derivata viene creato un nuovo pattern in base alle visite eettuate sul paziente esaminato.
Se, ad esempio, un paziente riceve 2 visite di tipo non palliativo il lunedì e il venerdi e una visita di tipo palliativo il mercoledì allora verrà creato il pattern (1,0,2,0,1).
Quando un nuovo pattern viene generato viene confrontato con gli altri generati alla stessa maniera. Se il pattern è già presente nella lista viene scartato, altrimenti viene aggiunto. La procedura continua iterativamente n quando tutti i pazienti sono stati esaminati.
L'ultimo passo per la generazione di un'istanza consiste nella stima dei tempi di spostamento.
Dai CAP dei pazienti viene creata una lista di comuni utilizzati.
Considerato n il numero di comuni dei pazienti dell'istanza viene creata una tabella di dimensione n2. Per ciascuna cella viene eettuata una chia-
mata a Google Maps tramite le Google APIs, allo scopo di calcolare una stima del tempo necessario per il tragitto dal comune relativo all'indice di riga al comune relativo all'indice di colonna.
Google Distance Matrix API è un servizio che fornisce la distanza e il tempo di viaggio per una matrice di origini e destinazioni. Le informazioni restituite si basano sui tragitti raccomandati tra locazioni di inizio e di ne, come calcolati dalle Google Maps API, e consistono di righe contenenti i valori di durata e distanza per ogni coppia.
Il servizio non fornisce alcuna informazione dettagliata sui tragitti. Essi possono essere ottenuti passando una singola origine e una singola destina- zione alle Google Direction API.
Per gli spostamenti intra-comune, cioè legati alle celle nella diagonale della tabella, è stata considerata una durata del valore di 3 minuti di default. Considerati due comuni qualsiasi, siano A e B, viene calcolato sia il tempo impiegato per giungere da A a B che da B ad A. Non sempre Google Maps restituisce lo stesso valore.
Una volta costruita la matrice dei tempi i valori associati ai CAP dei pa- zienti vengono sostituiti dagli indici corrispondenti nella tabella, per poterne ricavare i tempi una volta passata l'istanza al solver.
L'istanza vera e propria viene creata in un le testuale, di tipo .data strutturato nella seguente maniera:
• La prima riga indica il numero di pazienti (incluso il nodo deposito), di operatori, di comuni e di pattern.
• La tabella dei pazienti, dove ciascuna riga riporta: codice paziente, numero massimo di operatori associati (abbiamo considerato un valore default di 2), richeste di skill 1, richieste di skill 2, id del comune associato.
• La tabella degli operatori, in cui le righe riportano: codice operatore, skill, ore lavorative giornaliere.
• La matrice dei tempi di percorrenza, come descritta sopra.
• I pattern, organizzati in una tabella, in cui ciascun pattern rappresen- ta una riga e le 5 colonne riportano il valore del pattern nel giorno corrispondente.
Tale le è pronto per essere passato come input al programma scritto per generare il modello da passare poi al solver.