Una volta effettuato il login il medico generico troverà il suo task iniziale di scelta all’esecuzione del quale comparirà la pagina mostrata in basso in cui quindi potrà scegliere quale azione intraprendere.
Figura 84 Pagina Scelta Iniziale Medico Di Medicina Generale
1. Flusso Prescrizione Esami (colore arancione)
Se il medico sceglie tra le opzioni disponibili Prescrivi Esami potrà eseguire come compito la prescrizione degli esami del sangue. Il flusso comprende la presentazione di due pagine.
100
Figura 85 Pagina Di Ricerca Pazienti A Cui Prescrivere Esami
La figura mostra la tabella contenente i pazienti che necessitano della prescri- zione degli esami del sangue in modo automatico e il medico può selezionare il paziente che gli interessa e avviare la procedura di prescrizione cliccando sul tasto Invia prescrizione al paziente.
Pagina relativa al task Prescrizione Esami (form in Figura 64)
Figura 86 Pagina Prescrizione Esame Ematochimici
La pagina mostra i campi nome e cognome completati in automatico dalla pagina precedente e il campo per l’upload del file con la prescrizione in for- mato pdf.
2. Flusso Visualizza Dati Paziente (colore blu)
Dalla pagina in Figura 84 il medico sceglie l’opzione Visualizza Dati e questo gli permetterà di cercare il paziente di cui vuole visualizzare i dati e avere acces- so a tutte le informazioni.
Pagina per l’esecuzione del compito Seleziona Paziente (modulo implementa- to in Figura 66)
101
Figura 87 Pagina Visualizza e Seleziona Paziente
La pagina mostra nella tabella i pazienti in cura dal medico generico che ha effettuato l’accesso, in questo caso sono stati inseriti dei pazienti fittizi per verificare il corretto funzionamento. A questo punto il medico seleziona il pa- ziente desiderato, inserisce il range di date e invia la richiesta per la visualiz- zazione cliccando sul tasto Visualizza Dati.
Pagina relativa al task Visualizza Dati Paziente Selezionato (form corrispon- dente in Figura 67)
La pagina presenta i dati relativi al paziente selezionato nella pagina prece- dente in formato tabellare ordinati per data. In figura è anche mostrata la fine- stra per il download del file pdf contenente il foglio di report dei suddetti pa- rametri.
Supponendo che il medico generico abbia dei dubbi sui parametri visualizzati e voglia chiedere un parere allo specialista, non deve fare altro che spuntare la voce corrispondente e inserire la motivazione in formato testuale. Tale moti- vazione sarà riportata nella mail allo specialista, come visibile in Figura 89.
102
Figura 88 Pagina Visualizzazione Dati Paziente Mmg
Figura 89 Ricezione Mail Dallo Specialista
3. Flusso Inserisci Parametri proveniente dalla lane Pazienti (colore verde)
Pagina corrispondente al task Visione Dati
Si tratta essenzialmente della stessa pagina mostrata allo specialista e visua- lizzabile in Figura 83.
Pagina rappresentativa del task richiesta Approfondimento
L’ultima pagina mostrata è quella in cui il medico generico può chiedere un approfondimento in merito ai dati inseriti dal paziente al paziente stesso o allo specialista riempiendo i campi presenti in Figura 90 e inviando il motivo via mail premendo sul tasto “Notifica richiesta”.
103
Figura 90 Pagina Richiesta Approfondimenti
4.4 “Costruzione” del Processo
Una volta effettuata la simulazione da Bonita Studio, con la visualizzazione su Boni- ta Portal delle pagine create, è possibile effettuare l’operazione di build del processo. Questa permette di ottenere un file .bar del processo implementato che può essere in- stallato direttamente sul portale senza passare per il tool Studio. E’ sufficiente acce- dere con profilo amministratore e aver preliminarmente importato l’organizzazione necessaria.
L’organizzazione può essere esportata sempre dal tool Studio in un file in formato .xml e poi importata nel portale nella sezione Organitation.
Terminate queste operazioni si passa nella sezione BPMProcesses e si installa il fi- le .bar del processo (Figura 91).
CONCLUSIONI
Il lavoro svolto si è basato sull’utilizzo del software Bonita BPM che, partendo dalla teoria dei processi di business, permette di modellare un insieme di attività svolte da una specifica organizzazione e di poter implementare attraverso dei Designer ognuna di queste attività per poter simulare il processo stesso. Il software nel nostro caso è stato utilizzato per la creazione di un portale di telemedicina rivolto a pazienti affetti da scompenso cardiaco, considerando come processo l’insieme delle attività svolte da tre gruppi di utenti che rappresenteranno la nostra organizzazione: pazienti, specialisti e medici di medicina generale. Il software Bonita, nonostante si tratti di un sistema non pensato per essere applicato in campo medico, si è dimostrato efficace per la creazione di un processo che permetta di avere una sequenza ordinata di azioni condivise tra i gruppi sopracitati.La creazione dell’applicativo ha visto essenzialmente tre fasi: la creazione del disegno del diagramma che rappresenta il processo in notazione BPMN, l’implementazione dei singoli task (azioni da svolgere), che implica la creazione di moduli contenenti tutte le informazioni che l’utente deve completare o visualizzare, e una fase di simulazione. La fase del disegno e dell’implementazione dei singoli task ha comportato delle difficol- tà sia per la necessità di dover coinvolgere ruoli diversi nello stesso processo che aves- sero un certo grado di indipendenza tra loro, sia per le limitazioni dovute all’utilizzo di una versione free del software. Questi “problemi” sono stati però superati sfruttando la possibilità di connessione a software esterni e di inserimento di codice java direttamente nei singoli task creati.
Nel processo sono stati considerati essenzialmente due aspetti: il monitoraggio di dati clinici inseriti dai pazienti e dal medico di medicina generale e l’interazione medico- paziente per permettere lo scambio di informazioni, effettuare cambi di terapie da parte del medico specialista e risolvere in modo veloce dubbi che invece avrebbero richiesto continue visite ambulatoriali con dispendio di tempo e costi. Una volta terminata la cre- azione del processo con l’inserimento di tutte le azioni che i gruppi di utenti devono o possono svolgere si passa alla fase di simulazione.
Per poter testare il processo sono stati utilizzati degli utenti di prova per i tre gruppi considerati, quindi sono stati inseriti quattro utenti per il gruppo dei pazienti, due per il gruppo dei medici di medicina generale e uno per quello degli specialisti. Questi tre gruppi corrispondono ai tre ruoli nell’organizzazione considerata e quindi a tre lane
105 (corsie) nel processo principale. Essendoci tre lane e avendo considerato che il processo possa partire da ognuno dei tre gruppi di utenti indicati, ci saranno più flussi di esecu- zione i cui task possono appartenere alle diverse lane. Questo significa che per comple- tare un certo flusso ci saranno alcuni compiti che devono essere svolti da un certo grup- po e alcuni da altri.
E’ stata quindi avviata la simulazione dal software che determina l’apertura del browser, indicato nelle impostazioni del programma, in cui saranno visualizzate tutte le pagine create relativamente al gruppo dell’utente che effettua l’accesso. Queste pagine corri- sponderanno ai singoli moduli creati in fase di implementazione sfruttando i sistemi di Designer forniti dal tool Bonita Studio. L’url a cui ci si collega in automatico è local- host:8080 perché nella fase di test l’applicativo comunica con lo stesso sistema su cui è in esecuzione.
Ogni compito affidato a ciascun gruppo è stato quindi simulato completando le pagine corrispondenti in modo da valutare il corretto funzionamento sia a livello di processo che dei connettori utilizzati, quindi le operazioni di inserimento-modifica su un database mysql creato per il progetto e la visualizzazione dei report di dati ottenuti utilizzando il software Jasper Report.
Per quanto riguarda la corsia dei pazienti, è stato possibile verificare che, una volta regi- strati, gli utenti appartenenti a questo gruppo sono inseriti nel portale e possono autenti- carsi e completare senza problemi i propri compiti. Al termine di questi, inoltre, è stato possibile riscontrare l’attivazione automatica di alcuni task nelle pagine principali del medico specialista e di quello di medicina generale di quel paziente. Questi rappresen- tano i compiti che un utente degli altri gruppi deve svolgere per permettere il completa- mento di un flusso di esecuzione.
La stessa verifica è stata applicata facendo iniziare il processo da un medico specialista e da uno di medicina generale e anche in questo è stato possibile osservare la corretta esecuzione dei singoli compiti assegnati a questi utenti nonché la corretta attivazione di task per utenti appartenenti agli altri due gruppi. Dunque è stato possibile dedurre che ciascun flusso sequenziale disegnato per le tre corsie è stato implementato in modo cor- retto.
In conclusione potrebbe quindi essere preso in considerazione l’utilizzo di un tale siste- ma per monitorare i pazienti affetti da scompenso cardiaco in quanto consentirebbe un rapido confronto paziente-medico, semplicemente collegandosi al Portale. Questo com- porterebbe molteplici vantaggi per il paziente in termini di riduzione dei rischi per la sa-
106 lute e di miglioramento della qualità della vita grazie alla possibilità di un continuo scambio di informazioni con i propri medici senza la necessità di doverli incontrare di persona. Allo stesso tempo un sistema di questo tipo permetterebbe al medico, sia spe- cialista che generico, di avere sempre una visione generale di ogni paziente potendone valutare l’andamento dello stato di salute nel tempo attraverso tabelle e grafici dei dati clinici fondamentali e di poter richiedere tempestivamente una visita ambulatoriale nel caso fosse necessario.
L’applicativo creato è ovviamente una prima versione il cui scopo principale è stato quello di valutare l’applicabilità di un sistema basato sul business process modelling per il monitoraggio di pazienti con scompenso cardiaco e verificarne la corretta esecuzione dal punto di vista tecnico. Il sistema per dimostrare la sua piena efficacia dovrebbe però essere testato con pazienti reali e messo in rete in modo da poter introdurre eventuali modifiche per renderlo maggiormente efficiente e vicino ai bisogni sia dei medici che dei pazienti stessi. Se anche il test su dati e pazienti reali dovesse produrre gli stessi ri- sultati ottenuti nella simulazione si potrebbe pensare di utilizzare una versione completa del software Bonita che permetta di avere una maggiore libertà nella modellazione del processo stesso e di estendere l’utilizzo di tale sistema anche a pazienti affetti da altre patologie.
107