PSM 22/23 Obiettivi e Introduzione PDF

PSM 22/23 Formento Moletta Nicolò/Garino Silvia OBIETTIVI DELL’INSEGNAMENTO Nel corso verranno trattati i software medicali che si possono suddividere in due grossi filoni: 1. Software Medicali standalone, ovvero utilizzati da...

PSM 22/23 Formento Moletta Nicolò/Garino Silvia OBIETTIVI DELL’INSEGNAMENTO Nel corso verranno trattati i software medicali che si possono suddividere in due grossi filoni: 1. Software Medicali standalone, ovvero utilizzati da soli (non legati ad uno strumento) 2. Software Medicali integrati nella strumentazione, diventata sempre più importante sia per aumentare le funzionalità della strumentazione stessa sia per aiutare a mantenere la strumentazione ad un corretto livello prestazionale (si vedano ad esempio i self test delle TAC). Quest’ultima funzionalità ha modificato sia il carico e la competenza di lavoro richiesti all’ingegnere clinico sia la stabilità temporale di corretto funzionamento dell’apparecchiatura (tutte le mattine si può autovalutare e, nel caso, sistemare eventuali problemi) L’informatizzazione dei processi clinici, ad esempio la cartella clinica oppure i processi clinici all’interno di un reparto, procede abbastanza lentamente in tutti i paesi europei e americani, Sb anche se alcune procedure sono già state informatizzate. Ciò a causa dello sviluppo del software (spesso progettato senza una reale conoscenza dei processi) e alla necessità di ob avere all’interno delle strutture delle figure professionali in grado di gestire questi software. Normalmente chi si occupa di informatica all’interno delle strutture ha una formazione più in vicina ai software di tipo gestionale ed è problematico perché i due tipi di software hanno delle problematiche di tipo differente: ad esempio se devo pagare la fattura oggi e il software e si blocca non è un problema critico al contrario se devo somministrare una terapia ad un G paziente devo essere sicuro che si faccia nel tempo indicato. Motivo per cui i software medicali che sono legati ad un processo di cura sono classificati come dispositivi medici e ra perciò devono sottostare alla normativa dispositivi medici. tu Alla fine dell’insegnamento si è in grado di collaborare allo sviluppo dei Software Medicali e ite collaborare alla gestione dei medesimi. PSM 22/23 Formento Moletta Nicolò/Garino Silvia INTRODUZIONE 1. BIOMEDICAL INFORMATICS Definizione: L’informatica medica è un campo di studio interdisciplinare che studia e persegue l’uso efficace dei dati biomedicali, dell’informazione e della conoscenza per indagini scientifiche, problem solving e decision making, con lo scopo di migliorare la salute umana. È l’ambito di riferimento del corso. Essa è un’area molto vasta, l’immagine rende conto degli ambiti sulla quale si sviluppa. L’informatica medica è un settore in sviluppo che di norma non si trova nell’ingegneria. L’obiettivo del corso è definire gli strumenti per un’analisi critica con l’occhio di un ingegnere: il ruolo sarà aiutare nelle fasi precedenti e successive alla scrittura del codice. L’informatica medica si collega a diverse scienze di tipo diverso riuscendo a dare Sb supporto a tutte. ob in e G ra tu ite In realtà all’inizio si chiamava Medical informatics, attualmente viene chiamata Biomedical informatics. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Questa branca non è nata negli ultimi dieci anni: nel 1977 si parlava di informatica nei processi medici (“MEDINFO”, conferenza che si teneva ogni tre anni all’inizio e oggi ogni due) e già agli inizi degli anni ‘80 c’erano degli ospedali interamente informatizzati (c’erano dei terminali che si collegavano ai calcolatori che erano grossi come una stanza). All’epoca l’attenzione era sull’applicazione dell’informatica alla medicina, le parole utilizzate erano legata alla scienza dei computer e la medicina non era centrale: era l’applicazione della lingua dei computer alla medicina. Andando avanti si passa dalla computerizzazione alla gestione dei dati dei pazienti per arrivare all’utilizzo di internet (con la possibilità di connessione da remoto). Al giorno d’oggi c’è una parte di strumenti utilizzabili in modo routinario, ma che devono essere validati per un loro utilizzo sicuro. 2. DIGITAL HEALTHCARE La sanità digitale è l’ultima frontiera a cui siamo attualmente arrivati, in particolare si parla di: Software che supportano processi clinici Telemedicina Sb APP (mondo molto ampio, DM/Wellness/tutt’altro genere, e difficile) Sistemi di aiuto alla decisione (Intelligenza artificiale), nella maggior parte dei ob casi questi sistemi non arrivano a rendere operativa una decisione, ma forniscono supporto a chi la deve prendere in (Esempio: il radiologo che deve rilevare la possibilità che ci sia una lesione maligna, il software potrebbe indicare delle aree in cui si possono trovare le suddette lesioni, e sarà il radiologo successivamente a scegliere) G Il discorso relativo all’analisi delle immagini è soggettivo: se l’analisi è fatta per il ra radiologo mi serve una determinata accuratezza spaziale (per lui è importante sapere se c’è o no); per il chirurgo prima dell’operazione è necessario essere più precisi tu (deve sapere la dimensione della lesione, per sapere cosa deve togliere). È quindi ite l’utente finale a definire le specifiche del software (in questo caso la definizione dei bordi della massa). Cosa si intende per salute? Definizione di salute: uno stato fisico, mentale e sociale di completo benessere e non solamente l’assenza di malattie. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Negli anni ‘50 si passa dal concetto di cura definita come il ripristino di uno stato di salute nel momento in cui arriva la malattia all’allargamento del concetto non più solo aspetto fisico ma anche quello mentale e sociale. L’aspettativa di vita in questi anni è aumentata (circa 80 anni), però l’aspettativa di vita in salute resta comunque bassa (circa 60 anni). Questo discorso fa riflettere su quanto sia necessaria l’assistenza alle persone tra i 70 e i 90 anni. L’utilizzo delle tecnologie ICT e software ha lo scopo di: Ridurre il carico di lavoro, specialmente considerando la richiesta crescente di monitoraggio (esempio: i pazienti oncologici diventano spesso pazienti cronici e perciò bisognosi di più attenzioni) Ridurre spesa sanitaria, anche se i costi relativi a strumentazione e medicinali non sono riducibili Facilitare accesso alle cure La cartella clinica digitale è la versione digitale della cartella clinica di ricovero ospedaliero oppure di una cartella clinica ambulatoriale specialistica. Essa non è semplicemente riportare i dati in modo digitale invece che tramite Sb scrittura manuale, ma consente di combinare e visualizzare i dati in modo diverso e quindi di supportare le decisioni cliniche. ob Vantaggi: in Accesso contemporaneo di più soggetti, mentre scrivevo su carta gli altri dovevano attendere che io finissi, adesso possono accedere e contemporaneamente infermieri e medici Evoluzione dei dati facilmente reperibile, è possibile graficare i dati (come G pressione) nel tempo per vedere l’evoluzione dei parametri vitali. ra E’ così più facile per il medico valutare l’evoluzione della terapia e quindi offrire un aiuto per le decisioni tu ite Definizione di telemedicina: applicazioni basate sulle tecnologie ICT che supportano l’erogazione “a distanza” delle attività di cura del paziente. Essa si è sviluppata soprattutto “grazie” al COVID. Un grosso problema prima era che le prestazioni erogate mediante telemedicina non avevano un rimborso da parte dello stato, perché non erano classificate. A causa di ciò diversi progetti sono stati sviluppati, ma sono rimasti inutilizzati. Con telemedicina non si parla di assistenza, ma di servizi tecnici che sono utilizzati per l’assistenza sanitaria: Assistenza domiciliare: prosegue per parecchi anni (telemonitoraggio, televisita) Dimissione protetta: prosegue per un periodo limitato nel tempo (telemonitoraggio, televisita) Radiologia: telerefertazione, teleconsulto Oncologia: teleoncologia, telemonitoraggio, televisita Terapia riabilitativa: teleriabilitazione Medici di medicina generale (MMG) e Pediatri di libera scelta (PLS): usano piattaforme per inviare ricette e consentire ai pazienti di caricare referti Pronto soccorso: triage dall’ambulanza PSM 22/23 Formento Moletta Nicolò/Garino Silvia Questo aspetto ha migliorato per esempio le prescrizioni dei farmaci per le persone croniche, facendo loro risparmiare tempo (non è più necessario fare delle ore in coda dal medico per la ricetta). Bisogna sottolineare che la telemedicina non è in grado di sostituire la medicina tradizionale e la televisita non sostituisce una visita tradizionale ma è uno strumento complementare in aggiunta alle modalità di interazioni consuete. Ad esempio, nell’ultimo DGR del 2020 della regione Piemonte nella quale si descrive la procedura per svolgere la televisita, si sottolinea che se durante la televisita dovessero emergere dei dettagli particolari, il medico può richiedere una visita tradizionale con il paziente e la prestazione è unica. Ciò vuol dire che per esempio un paziente oncologico che normalmente ha delle visite di controllo che si basano su esami fatti precedentemente (il medico valuta l’esito degli esami), esse si possono fare online nel caso dovesse andare tutto bene e ripetere in presenza nel caso contrario. 3. CARE DELIVERY MODELS Sb ob in e G ra Prima degli anni ‘80 l’esperienza aveva un ruolo fondamentale per il medico. Quello tu che è stato fatto prima dalle guide internazionali e dalle varie società scientifiche e ite successivamente dal percorso terapeutico assistenziale è stato individuare per ciascuna patologia le attività che devono essere portate avanti per alzare il livello minimo di assistenza. Se prima c’era parecchia disparità anche di tipo prognostico (ad esempio nelle malattie oncologiche: il paziente cercava disperatamente, anche spostandosi, un medico con parecchia esperienza che fosse in grado di capire la malattia, anche se quest’ultimo si trovava a chilometri di distanza), adesso si è riusciti a standardizzare le terapie garantendo così l’assistenza minima al 90% dei pazienti con la medesima problematica. Sicuramente l’esperienza gioca un ruolo fondamentale nei casi particolari, però è altrettanto importante garantire una cura standard per tutti. L’obiettivo è non solo avere l’informazione su come trattare al meglio un gruppo di pazienti che condividono determinate caratteristiche, ma anche andare a personalizzare quelli che sono i percorsi diagnostici/medici/assistenziali che mediamente vanno bene per tutta quella tipologia di pazienti. Si renderebbe infatti ancora più efficace la cura basandosi su quella che è la storia clinica del singolo paziente, delle sue caratteristiche genetiche (esempio: tumore alla mammella). PSM 22/23 Formento Moletta Nicolò/Garino Silvia Questa evoluzione la si deve grazie all’evoluzione di pensiero in ambito sanitario: dall’esperienza del medico alla tecnologia che fornisce delle informazioni in più per prendere delle decisioni maggiormente supportate dalle evidenze. Un po’ più complicato è il mondo delle App e dell’IA dove abbiamo la capacità di compiere delle azioni grandiose, ma bisogna capire come inserirle correttamente nei processi di cura. Sb È stato riportato uno schema organizzativo del sistema sanitario che non si rivolge solo a chi sta male, ma anche per la prevenzione e al benessere di una persona. Per ob un determinato gruppo di persone sono associati i cosiddetti CareGivers: persone che supportano e aiutano persone anche autosufficienti, ma che necessitano di aiuto (nella nostra società sono spesso familiari). Questi ultimi non sono da confondere in con la sola categoria dei badanti. e G ATT: Medicina ra personalizzata e medicina di precisione sono spesso tu utilizzati come sinonimi. ite “Precision medicine” è quando si agisce sulle variabili omiche (di carattere genetico). Definizione di sistema sanitario: Il sistema sanitario è responsabile di fornire servizi al fine di migliorare, mantenere o ristabilire la salute degli individui o delle comunità. Questo include la cura fornita dagli ospedali e dai medici di famiglia, ma anche obiettivi più nascosti quali la prevenzione e il controllo delle malattie trasmissibili, la promozione della salute, la pianificazione del personale sanitario e il miglioramento delle condizioni sociali, economiche o ambientali dove le persone vivono. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Ci sono vari tipi di cure ed esse non si effettuano più solo all’interno degli ospedali, dalle acuzie alla cronicità. I vari tipi di cura sono riassumibili in: Primary Care: Medicina generale, è il primo posto dove il paziente va per cure mediche. L’obiettivo principale è prevenire malattie attraverso esami fisici e screening. Se necessario, il dottore di primary care indirizza il paziente a uno specialista Specialty Care: Cure specialistiche (cardiologo, neurologo, ortopedico, …) Emergency Care: Cure che necessitano di un’azione immediata perché la situazione può portare alla morte (Pronto soccorso) Urgent Care: Cure che richiedono un trattamento velocemente, ma la vita del paziente non è a rischio (Pronto soccorso). In questo caso, le case della salute dovrebbero sostituire i pronti soccorsi nel trattamento dei codici meno gravi per alleggerire il carico sugli stessi. Long-term Care: lungodegenza, gestire il paziente anche per anni (esempio: malattie degenerative). Hospice Care: struttura dove vengono ricoverate le persone che non hanno una speranza di vita lunga per poter alleviare la loro sofferenza (cure Sb palliative). ob in e G ra I percorsi clinici (PDTA= percorso diagnostico terapeutico assistenziale) sono strumenti che, sulla base delle migliori conoscenze tecnico-scientifiche e in relazione tu alle risorse disponibili, permettono all'Azienda sanitaria di delineare, rispetto ad una ite patologia o ad un problema clinico, il miglior percorso praticabile all'interno della propria organizzazione per curare il paziente. Il patient journey sono gli effettivi eventi di cura forniti al paziente durante la diagnosi e il trattamento. Solitamente il patient journey coincide con il percorso clinico ma ci possono essere deviazioni (personalizzazione della cura). Gli strumenti di telemedicina possono agevolare la gestione del paziente, evitando magari che esso debba spostarsi da un luogo ad un altro. L’altra cosa fondamentale è che al giorno d’oggi i software sono sempre più presenti all’interno della strumentazione. Tempo fa i vari software non dialogavano tra loro e anzi era vietato che più di un software venisse installato su un pc. Al PSM 22/23 Formento Moletta Nicolò/Garino Silvia giorno d’oggi si cerca di mettere tutto in rete, causando dei rischi ulteriori sulla sicurezza. Durante la fase di progetto si devono portare questi rischi in una zona di sicurezza. Il fabbricante però agisce solo sul suo dispositivo: è necessario riuscire a far dialogare in sicurezza i vari dispositivi (cybersecurity). Si parla molto del trattamento dei dati personali, al contrario della sicurezza informatica di questi software che possono comportare un danno significativo al paziente. È necessario garantire l’integrità dei dati, non limitando il potere di interoperabilità dei software, ma analizzando criticamente la sicurezza. L’interoperabilità tra la strumentazione è fondamentale al giorno d’oggi. 4. MEDICAL DEVICE SOFTWARE Sb All’interno delle strutture sanitarie troviamo tre tipologie di software: Gestionali: servono per gestire i turni del personale, gli ordini della farmacia non ob si legano direttamente con i processi di cura Utilizzati per il funzionamento dell’apparecchiatura in Medicali e Gli ultimi due vengono classificati come dispositivi medici. Per il software posto all’interno dell’apparecchiatura che è un tutt’uno con essa, è necessario definirlo e G descriverlo in una parte specifica del fascicolo tecnico. In futuro si arriverà ad avere la strumentazione come componente accessorio di un software, il nucleo è la ra piattaforma di telemedicina a cui sono collegati sensori, App, strumentazione... tu Si definisce come dispositivo medico un software che è pensato per trattare i dati clinici di un paziente e per farne delle elaborazioni (anche di basso livello, ad ite esempio un grafico). Enti regolatori: FDA: i software ritenuti dispositivi medici sono tutti quelli che sono usati per scopi medici senza far parte dell’hardware del dispositivo medico EU: i software ritenuti dispositivi medici sono tutti quelli che sono usati con gli scopi definiti dal regolamento dei dispositivi medici Questi 2 spesso condividono aspetti in ambito normativo. L’FDA ha già pensato alla normalizzazione delle App, che si modificano molto più rapidamente rispetto alla strumentazione. PSM 22/23 Formento Moletta Nicolò/Garino Silvia FASI DELLA COSTRUZIONE DI UN SOFTWARE MEDICALE Un software nasce dalla definizione delle specifiche (step fondamentale), all’analisi di queste specifiche, che sono di contesto e di progetto e che diventano delle specifiche di tipo tecnico, allo sviluppo del software (fuori dal nostro ambito di lavoro), fase di testing per dimostrare la validità (abbassando la probabilità di errore) mediante dei piani di testing robusti (esaminando tutti i principali percorsi del software) e si arriva poi al deployment, fase in cui tutti gli attori iniziano ad utilizzare il software. Analisi dei processi: Sb 1 DEFINIZIONE DELLE SPECIFICHE In questa fase si devono mappare le attività e i dati che vengono utilizzati nel ob percorso medico. in e G ra tu Ad esempio per un paziente oncologico sottoposto a visita post-intervento (di ite controllo): viene rivista la storia pregressa, valutando l’evoluzione della sua situazione. Devo avere la possibilità di inserire ciò che il paziente racconta salvandolo nelle cartelle di degenza (dal ricovero alla dimissione) o nelle cartelle ambulatoriali (inizia dalla prima visita e si mantiene aggiornata nel tempo), i risultati degli esami che potrebbero essere già presenti nel caso di interoperabilità già attiva, la terapia. Un aspetto importante è che le varie attività non procedono con una sequenza predefinita, genericamente sono attività in parallelo. È fondamentale quindi che il software si adegui al processo nel quale si deve inserire. Se il software e il processo hanno una cronologia differente, il software deve permettere di poter seguire le tempistiche del processo (anche tornando indietro). È quindi fondamentale sapere quali sono le caratteristiche dei processi che devono essere informatizzati. Questo problema lo si eredita dall’informatica dove si riflette per dati e non per attività. Ci si basa su due criteri fondamentali per l’accettabilità di un software: sicurezza del buon funzionamento e adattabilità alle attività. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Il primo passo per questa fase è fare delle interviste, prendere i documenti che si hanno a disposizione e se possibile fare delle osservazioni. Quest’ultimo punto è fondamentale perché durante le interviste il medico racconta delle visite standard, senza raccontare però tutti i casi particolari, oppure danno una versione differente di quello che davvero è: il software deve essere in grado di adattarsi ai casi particolari. Quello che viene elaborato entra nel processo di process modeling mediato dall’esperienza. Quando parliamo di un modello esso risente dell’esperienza Sb e del background di chi lo codifica. Il risultato finale non dev’essere influenzato dall’esperienza di quest’ultimo. ob Poiché gli strumenti di modellizzazione sono di tipo grafico, bisogna rivedere con chi ha fatto la prima parte se si ritrova nel process modeling generato per evitare incomprensioni. Questo processo prende il nome di validazione. La in documentazione viene variata fino a che non passa la prova di validazione. e Un processo è una serie di attività portate avanti da degli attori, come medici G ma anche strumentazione e software. Per comodità si dividono umani e ra strumentazione nei diagrammi. Essi possono essere interni o esterni all’organizzazione, se esterni è necessario evidenziarlo poiché hanno bisogno tu di credenziali di accesso e si deve sottostare ad un GDPR. Molto spesso nei processi il paziente è un attore passivo, non agisce ite direttamente; altre volte va considerato attivo. Ci sono uno o più eventi che fanno partire il processo (es. ricovero del paziente). C’è un sistema dietro ai nostri processi (struttura sanitaria) ed esso passa attraverso un certo numero di stati evolvendo fino a quello finale/quelli finali. Ci sono inoltre dei dati che devo avere prima dell’inizio del processo, altri vengono prodotti durante il processo e che vengono scartati e altri che vengono acquisiti e mantenuti per i processi successivi. Un sistema è un insieme di elementi legati da più relazioni, due elementi possono essere legati tra loro da più relazioni. Possono esserci più rappresentazioni valide dello stesso modello in base all’obiettivo per cui è stato costruito o all’esperienza della persona che lo costruisce. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Esempio di modelli di sistema più (in alto a sinistra) o meno formali (in basso a destra). Sb 2 MODELLIZZAZIONE DEI PROCESSI ob La modellizzazione dei processi permette di rappresentare un certo processo in e presenta numerosi strumenti (normalmente di tipo grafico). Essa non si limita solo all’individuazione dei requisiti, ma possiede molte e applicazioni (come la creazione di indicatori, valutazione del patient journey e il miglioramento dell’organizzazione di un servizio). G Ci sono vari diagrammi che possono essere utilizzati ed è un settore ormai ra abbastanza standardizzato. Si possono modellizzare aspetti differenti con metodi differenti, in particolare ne andremo ad analizzare 3. I vari metodi tu possono essere supportati da vari programmi che offrono come tools gli ite elementi base; in altri casi, come per esempio PowerPoint, siamo noi a dover costruire gli elementi base per poi costruire la modellizzazione. Ci sono delle situazioni in cui ricercatori differenti hanno proposto delle metodologie che si basano su di un certo numero di diagrammi. Ci sono molti obiettivi che possono essere raggiunti attraverso la modellizzazione dei processi: Documentare i processi, descrivere e quindi formalizzare i processi per identificare le eventuali criticità Identificare i punti deboli del processo per andare a migliorarlo Valutare i miglioramenti che vengono fatti nei processi stessi Strumento di comunicazione, descrizione grafica del processo facilita la discussione Aiuta nell’automazione dei processi (non è il nostro interesse primario) Comunicare i processi agli stakeholder, utilizzarli per ottenere il consenso (spiegando come si inserisce il software nel processo) Facilita l’inserimento di nuovi dipendenti Devono essere soddisfatte alcune norme, bisogna essere accreditati, specialmente sulla funzionalità (come nel fascicolo tecnico) PSM 22/23 Formento Moletta Nicolò/Garino Silvia Sb Quando creo un diagramma è fondamentale definire gli elementi grafici che ob costituiscono il mio diagramma. Soprattutto all’esame! Di seguito sono rappresentati tre esempi dei diagrammi che verranno in impiegati. e G ra tu ite Il synopsis diagram non descrive le attività del processo, ma l’ambiente attorno al quale il processo si svolge. Quindi evidenzia gli attori, l’attività che fa iniziare il processo, quali sono il risultato (di norma più di uno) e i dati (in input e in output). Per descrivere le varie attività, quindi un processo nella sua interezza, usiamo un workflow diagram, basato sulle reti di Petri. Esse sono uno strumento utilizzato anche per simulare i processi e costituiscono un altro metodo di modellizzazione. Il problema di questo strumento è lo sviluppo orizzontale, quindi è poco adatto nella descrizione di processi con numerose attività. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Il motivo per cui viene introdotto lo Swim Lane activity diagram è risolvere la problematica di processi con numerose attività e mantenere la cronologia temporale (in verticale si sviluppa il tempo). Inoltre, permette di mettere in evidenza l’attore che svolge un’attività: ogni colonna definisce un attore o un insieme di essi. Usiamo il workflow per una visione di insieme e lo Swim Lane per avere una visione di dettaglio. 2.1 SYNOPSIS DIAGRAM Sb ob In questo caso il processo è identificato dall’ellisse centrale in cui noi in mettiamo un nome indicativo dello stesso. e Si inseriscono poi gli attori che partecipano al processo. In questa fase se noi G vogliamo costruire un software lo mettiamo tra gli attori (diversamente da ra quanto si farà poi per l’analisi delle specifiche). In generale, in molti casi, si fa una doppia rappresentazione: la prima senza tu software che vogliamo andare a costruire e una seconda in cui si inserisce il nuovo software. Nella realtà si fa una singola rappresentazione con il software ite perché si ha abbastanza idea di dove andrà utilizzato oppure perché si compie una descrizione migliore nel caso in cui il software sia già presente. Si inserisce il risultato (spesso più di uno). I dati di input sono i dati presenti nell’organizzazione. I dati che ha il paziente in generale non sono inclusi (il paziente di norma è esterno all’organizzazione) a meno ché non siano caricati nella base dati dell’organizzazione prima della visita online (a quel punto il paziente entra a far parte dell’organizzazione). Esempio: il paziente si porta una TAC fatta in un’altra clinica, quel dato non è presente; perciò, non è un dato di input, ma di output. Diventa dirimente, dal punto di vista informatico, quello che c’è nelle basi dati dell’organizzazione e cosa non c’è. L’organizzazione può essere l’ospedale, il servizio sanitario nazionale, un reparto, l’RSA,... (dipende su quale aspetto ci concentriamo). Essa non è mai data solo dall’insieme delle persone che offrono il servizio. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Esempio: studente -> Politecnico (Amministrativo, Didattico, Esami,...), Immatricolazione -> Segreteria. I dati di output sono tutti quei dati che vengono introdotti nella base dati durante il processo e che rimangono in seguito allo stesso. Cos’è la cartella clinica e perché non fa parte dei dati di input? Un classico errore è inserire la cartella clinica nei dati di output. Di norma la cartella clinica è quella del medico e può essere di degenza o ambulatoriale, mentre la cartella infermieristica è quella dell’infermiere (è presente tutta l’attività assistenziale). La cartella clinica è un insieme di documenti, quali: Anagrafica: in essa sono contenuti tutti i dati utili per definire il paziente, abbastanza standardizzata. I dati possono essere modificati eliminando i precedenti (ad esempio la residenza). Diario Clinico: è un insieme di note caratterizzate da una data e un’ora in cui, in linguaggio naturale, il medico o l’infermiere vanno a scrivere delle annotazioni. Sb Terapia: vengono descritte le prescrizioni, ovvero il farmaco, la posologia e l’orario di somministrazione, e le somministrazioni ob effettuate, confermate dall’infermiere. La terapia in una degenza viene revisionata ogni giorno oppure ad ogni visita nel caso ambulatoriale. in In caso dovesse variare la terapia non si elimina la precedente, è fondamentale avere uno storico delle somministrazioni sia per e questioni legali sia per questioni professionali (medico). Anamnesi: parte della cartella più difficile da digitalizzare. Sono G presenti moltissimi dati. Ci può essere l’anamnesi remota dove si ra analizza tutta la storia del paziente per punti salienti e quindi può essere strutturata. L’anamnesi recente o sintomi è riferita a quello che tu sente il paziente in quel momento. Essi possono variare nel tempo. ite Esami di laboratorio Si può mettere cartella clinica nei dati di output solo se si specificano gli elementi utilizzati della cartella clinica. Esempio: dato di output = cartella clinica (diario clinico e terapia) Di norma il diagramma synopsis è associato ad un altro tipo di diagramma perché non è in grado di fornire tutti i dettagli necessari. 2.2 WORKFLOW DIAGRAM Il workflow diagram descrive le azioni eseguite durante il processo. Si basa sulle reti di Petri e nasce a partire da due elementi di partenza: place e transition. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Place rappresenta lo stato del sistema e la transition rappresenta le attività del sistema. Questa rappresentazione mette in evidenza che una certa attività porta ad un cambiamento. Questo formalismo aiuta in determinate situazioni per l’analisi dettagliata e la gestione dei luoghi/spazi utilizzati. Attenzione che si inizia con un Place e si deve terminare con un Place (il sistema parte da uno stato e termina sempre con uno stato anche differente). Esempio: transition=accettazione place=paziente in sala d’attesa Sb ob in e G 4 costruzioni di base: ra Sequenza: le attività sono svolte una di seguito all’altra tu Parallelo: le attività sono svolte in contemporanea oppure senza un ordine di priorità. Di seguito gli elementi che definiscono l’inizio e la ite fine del parallelo: Ci sono attività che possono iniziare insieme ad altre (parallelo) e altre che possono iniziare solo quando termina un’attività (sequenza). Ad esempio gli esami del pre-ricovero, in parallelo, (RX Torace, Elettrocardiogramma, Analisi del sangue) devono essere terminati prima della visita pre-anestesiologica, in serie a quest’ultima. Selezione: un certo numero di attività in alternativa tra loro. La domanda che porta a definire la condizione della selezione viene scritta a parte e portata nel blocco mediante una lettera o un segno posto nel rettangolo a sinistra. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Si possono annidare le selezioni nei paralleli e viceversa. Non ha molto senso annidare troppo perché posso dettagliare nello Swim Lane. Cicli: esecuzione reiterata di un’attività finché non viene soddisfatta una condizione oppure verificare una condizione prima di eseguire un’attività. Posso gerarchizzare le attività mediante un blocco che ne condensi diverse Sb insieme chiamato sottoprocesso. Si sfrutta raramente, è meglio lo Swim Lane. Esso inizia e termina con un’attività perché i due place sono già definiti ob al margine nel diagramma principale. in e G ra tu ite I trigger sono necessari per definire delle attività in cui sia necessario l’impiego di una persona, di un evento esterno, a determinati orari o perché scatta un allarme. Ci sono anche attività che vengono effettuate ad orari predefiniti. Queste attività non sono attività direttamente successive alle precedenti, ma sono temporalmente definite. I trigger sono di 3 tipologie:  PSM 22/23 Formento Moletta Nicolò/Garino Silvia 1. Evento esterno (esempio: arrivo di una mail) 2. Attività che richiede una persona/risorsa (esempio: personale disponibile all’accettazione) 3. Segnale di tempo (esempio: somministrazione di farmaci ad un orario preciso) 2.3 SWIM LANE ACTIVITY DIAGRAM Sb ob in e G ra La caratteristica principale dello Swim Lane Diagram è la sua verticalità grazie alle sue colonne. tu La posizione delle colonne a volte è critica in quanto ci possono essere attività a ite cavallo tra 2 colonne (es: un attore usa il software). Possono essere presenti attività in parallelo e delle selezioni. I simboli di partenza e fine dello SL possono variare molto: -iniziale: pallino vuoto, scritta start -finale: pallino pieno In generale non è fondamentale. 2.4 ESEMPIO MODELLIZZAZIONE DEI PROCESSI: Ricorda: Spesso ci sono più rappresentazioni corrette, non c’è un unico modello.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Sb 2.4.1 SYNOPSIS DIAGRAM ob Suggerimenti: in - A volte l’evento trigger non viene messo nel workflow perché è considerato esterno e al processo. - Abbreviazioni: Paziente=PZ, Operatore=OP G - Se si fa il diagramma a mano, usare la matita per poter cancellare facilmente ra - Se le scritte da mettere nelle diverse forme del diagramma sono troppo lunghe, si può scrivere un richiamo (come una lettera “A”) e specificare in basso tu - Spesso vengono idee mentre si costruiscono gli altri diagrammi, è necessario ritornare sui diagrammi già fatti e riportare le modifiche. E’ consigliabile partire dal ite Synopsis Diagram perché è il più semplice, ma in realtà questi diagrammi sono costruiti in parallelo  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Nell’ellisse centrale c’è il nome del processo. Evento trigger: Dalla descrizione del processo: “Il paziente necessita di una visita per cui telefona al Centro Prenotazioni (CP)” sembra siano presenti 2 possibili eventi trigger: “Il paziente necessita di una visita” e “il paziente telefona al Centro Prenotazioni”. Entrambi gli eventi trigger vanno bene, dobbiamo però sceglierne uno. Preferiamo scegliere “il paziente necessita di una visita” perché precede logicamente e temporalmente l’altro. In questo modo la prima attività del WorkFlow sarà “il paziente telefona al Centro Prenotazioni”. Attenzione: A volte ci possono essere 2 eventi trigger equamente rappresentativi, in quel caso li mettiamo entrambi. In questo caso potremmo scrivere un risultato unico: “Prenotazione terminata”. Tuttavia, preferiamo mettere in evidenza le possibili situazioni finali: - Prenotazione effettuata con successo Sb - Prenotazione terminata con insuccesso: il paziente non ha trovato un appuntamento di suo gradimento ob In questo modo mettiamo in luce cosa succederà nel WorkFlow: avendo 2 risultati nel Synopsis Diagram avrò 2 uscite nel WorkFlow. in Notiamo che un altro possibile risultato è “la telefonata termina”, ma questo è uno stato meno significativo. e Attori: G -Paziente ra -Operatore -Software (prenotazioni) tu -Mail ite Per quanto riguarda la mail, essa è gestita da un servizio mail, non è il software che se ne occupa. È quindi un attore (anche se secondario). È consigliabile scrivere la parte dei dati contemporaneamente con il workflow. Prima di trattare i dati passiamo al WorkFlow (potrebbe essere modificata durante la costruzione degli altri diagrammi) Dati input -Agende: non scriviamo “Agenda” perché nel testo è scritto “l’operatore apre l’agenda corrispondente alla visita richiesta”, presupponendo che l’operatore abbia un insieme di agende (esempio: per neurologo, cardiologo, otorino ecc.). Nell’agenda sono presenti gli appuntamenti già prenotati e gli slot liberi. L’agenda nei software si presenta come un classico calendario dove ci sono slot già prenotati (rossi), gli slot liberi, cioè prenotabili (verdi), e gli slot in cui il medico non è disponibile (grigi). Quando si effettua la prenotazione, si richiede oltre che il tipo di visita (esempio: visita cardiologica) anche la preferenza su quale medico, nel caso ce ne fosse disponibile più di  PSM 22/23 Formento Moletta Nicolò/Garino Silvia uno (Esempio: cardiologo A o cardiologo B). Viene chiesto soprattutto se sono state effettuate altre visite in precedenza con un certo specialista e lo si vuole mantenere. Nel caso in cui si richieda uno dei due cardiologi, nell’agenda sarà visualizzata solo la parte relativa a quello. Se non ci sono preferenze, ogni cardiologo avrà un suo colore associato nel caso sia disponibile e ci sarà un altro colore nel caso siano disponibili entrambi. Questi sono aspetti importanti nella costruzione dell’interfaccia, che in quanto sistema di comunicazione deve veicolare informazioni chiaramente anche con colori o altri strumenti. -Dati pazienti: l’operatore può accedere ad una base dati dei pazienti che sono già stati al poliambulatorio. Dati Output Se l’appuntamento è stato trovato, nell’agenda ci sarà una nuova prenotazione. Si potrebbe scrivere “Agende” ma preferiamo scrivere “Dati prenotazione” per sottolineare che l’output è la prenotazione. Inoltre, pur avendo già una base dati paziente posso avere un nuovo paziente o potrebbe Sb essere necessario modificare i dati di un paziente già inserito nel database (es: indirizzo, numero di cellulare, ecc.). Per questo motivo preferiamo inserire “Dati paziente” anche ob nell’output. in 2.4.2 WORKFLOW DIAGRAM e Attenzione: G Quando andiamo a capo torniamo a sinistra, le attività devono essere sempre scritte in modo tale che siano in ordine leggendole da sinistra verso destra. ra tu ite 1. Nel WorkFlow non ha senso mettere “Il paziente necessita di una visita” perché non è un’attività o stato, la prima attività è “il paziente telefona”. 2. Le attività “operatore risponde” e “operatore chiede al paziente il tipo di visita” possono essere messe indifferentemente o insieme in un unico rettangolo o separatamente una di seguito all’altra. Per sintetizzare preferiamo metterli insieme. 3. Il paziente risponde  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Finora non abbiamo incontrato dati, abbiamo solo inserito attività. Solo quando l’operatore apre l’agenda utilizza il software. Possiamo così aggiungere anche al Synopsis Diagram il dato “Agende”. 4. L’operatore apre l’agenda (elettronica) Attenzione: il ciclo di proposta di appuntamenti non viene inserito nel workflow ma solo nello SwimLane. 5. Operatore propone una serie di appuntamenti. Questa attività ha 2 possibili risultati: -appuntamento non trovato: non si deve scrivere più nulla, la chiusura della telefonata è poco influente -appuntamento trovato: viene effettuata la prenotazione e il processo finisce 2.4.3 SWIM LANE ACTIVITY DIAGRAM Osservazione: Sb In questo esempio la posizione delle colonne non è critica. Poiché abbiamo 4 attori servono 4 colonne. ob Lo SL (=swim lane) parte dall’operatore che telefona, essendo che specifichiamo l’azione nella colonna dell’operatore basta scrivere “Telefona”. in Separiamo le attività di “Risponde” e “Chiede tipo di visita” dell’operatore. Invece di scrivere semplicemente che il paziente “Risponde”, è più corretto scrivere e “Fornisce informazioni sulla visita richiesta” (es: visita cardiologica tra 1 mese con un certo G medico). Mettiamo questa attività a cavallo tra paziente e operatore in quanto solitamente è una serie di domande e risposte, è quindi frutto dell’interazione tra questi 2 attori (es: PZ: “ho ra bisogno di una visita cardiologica”, OP: “ci sono 3 cardiologi che operano nel nostro centro, ha delle preferenze? Mattina o pomeriggio?”). tu L’operatore “Apre l’agenda”, “Propone un appuntamento” e inizia un ciclo: il rombo indica ite una selezione, in questo caso a 3 uscite: 1. se il paziente accetta si procede con il prossimo step 2. se rifiuta l’operatore gli propone un nuovo appuntamento 3. il paziente non trova un appuntamento che lo soddisfi e l’operatore “Chiude l’agenda” Se il paziente accetta, inizia la fase dell’inserimento della prenotazione. L’operatore “Apre la prenotazione”. Se il paziente è già stato nel poliambulatorio, i suoi dati sono già presenti. Se non è mai stato nel poliambulatorio è necessario che l’operatore gli chieda i dati. L’operatore, quindi, chiede al paziente se è già stato precedentemente nel poliambulatorio, il paziente “Risponde” e in base alla sua risposta si apre una selezione: -sì: l’operatore ricerca il paziente -no Si prosegue con un’attività a cavallo tra operatore, software e paziente “Inserisce/aggiorna i dati del paziente”. L’operatore “Conferma la prenotazione” seguita da ”Invio della mail” e dall’operatore che “Chiude l’agenda”. L’attività “Chiude l’agenda” è stata ripetuta in quanto era scomodo collegare con una freccia alla prima “Chiude l’agenda” lontana. In generale entrambi i modi sono accettati: sia ripetere l’attività che rimandare con una freccia. Si conclude lo Swim Lane con un pallino pieno. PSM 22/23 Formento Moletta Nicolò/Garino Silvia Sb ob in e G ra tu ite  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Una rappresentazione alternativa dello SL è il seguente. Sb ob Differenze: -non c’è mail in -non ci sono attività a cavallo (un’altra possibilità) e G 2.5 FLOWCHART ra I flowchart sono molto utilizzati per descrivere una sequenza di attività. tu Il flowchart non permette attività in parallelo (forte limitazione). ite Infatti, è un diagramma che nasce in ambito informatico (es: descrizione di un algoritmo software) dove la computazione parallela non è di default. Nel flowchart si possono fare: sequenze, selezioni e cicli. Il flowchart viene interpretato, possono quindi esserci rappresentazioni pittoriche. Vedasi figura:  PSM 22/23 Formento Moletta Nicolò/Garino Silvia 2.6 DIAGRAMMI PER LA DESCRIZIONE DELL’ORGANIZZAZIONE Esistono altri tipi di diagrammi per rappresentare l’organizzazione e il tipo di privilegi che sono associabili a certe figure professionali. Normalmente non ci sono grossi team con ruoli diversi e perciò utilizziamo poco questi diagrammi e li riporto solo a livello informativo. Ci sono 2 tipi di diagrammi: organizational chart: è una struttura ad albero che illustra graficamente le relazioni di autorità, cioè la struttura gerarchica delle posizioni in un’organizzazione Sb ob in e G stakeholder diagram: mostra come sono strutturate gerarchicamente le persone ra coinvolte nel processo. E’ possibile leggere il grafico sia dal basso che dall’alto. tu ite  PSM 22/23 Formento Moletta Nicolò/Garino Silvia APPLICAZIONI DEL PROCESS MODELING Sfruttando i diagrammi possiamo avere diversi tipi di applicazioni. 1 UNDERSTANDING ORGANIZATION Con “capire l’organizzazione” si intende la costruzione di un modello generale. Sb Esempio 1: ob Progetto per costruire un modello generale di assistenza sanitaria con lo scopo di aiutare le ditte partecipanti alla costruzione di un sistema di telemedicina. in I diagrammi Synopsis e WorkFlow sono stati costruiti per ognuno dei 4 servizi presenti parlando con i responsabili e tramite un questionario per raccogliere ulteriori e informazioni. G ra tu ite  PSM 22/23 Formento Moletta Nicolò/Garino Silvia 3 di questi servizi sono stati messi insieme per costruire un modello generale diviso in 3 parti (vedasi figura sopra). La 1° parte è relativa alla segnalazione: l’MMG o medici di un reparto ospedaliero segnalano un paziente che potrebbe beneficiare dei servizi. Prima della segnalazione il medico deve parlare con il paziente o il caregiver per vedere se il paziente è interessato a quel tipo di assistenza e solo dopo che il paziente è d’accordo avviene la segnalazione vera e propria. La 2° parte è relativa alla visita. Solitamente non è effettuata da un singolo medico ma è multidimensionale, cioè sono effettuate da più persone (es: assistente sociale, specialisti, ecc). La 3° parte è relativa alla assistenza, che deve essere organizzata in base alle necessità del paziente. In questa parte sono presenti selezioni per ogni tipo di servizio (es: visita giornaliera di un’infermiera, medicazioni, terapie, ecc.). Non tutti i servizi saranno inseriti nel piano assistenziale. Il medico di riferimento presenta il piano al paziente: egli può rifiutare tutto il piano o solo una parte. Periodicamente(es: 6 mesi/1 anno) o in seguito a particolari eventi si valuta se il piano sia ancora adeguato o se sia necessario modificarlo. Sb Esempio 2: Il processo si propone di evidenziare la mole di lavoro ob eccessiva delle dottoresse nel centro “Malattie trombotiche ed emorragiche” e in particolare l’insufficiente numero di in dottoresse per le richieste del centro stesso. e Prima di tutto sono state fatte interviste e si è poi costruita una scheda su cui venivano segnalati: numero e durata delle G visite, interruzioni per consulenze telefoniche (che ra allungavano i tempi della visita). L’osservazione diretta (della visita ambulatoriale) non è stata effettuata in quanto siamo tu più interessati al numero di visite e alla durata che al contenuto della visita stessa. Il lavoro delle dottoresse è ite stato monitorato per 4 settimane (20 giorni lavorativi). Per rappresentare il processo sono stati utilizzati i diagrammi di Synopsis e SwimLane. Si è usato una simulazione ad agenti per evidenziare le ore di lavoro eccessive: al giorno mediamente 9.6 ore (invece di 8). 2 CLINICAL PATHWAY VS PATIENT JOURNEY L’obiettivo è costruire un indicatore che intercetta la possibilità di avere un avvento avverso. Si è modellizzato con WorkFlow esteso temporalmente che si basa sul Workflow atemporale classico con l’aggiunta di informazioni relative alle tempistiche, come durate, ritardi e vincoli temporali.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia L’individuazione di situazioni anomale è stata effettuata con un indicatore formato da 5 indici diversi: 1) I1 = omissione dal pathway, cioè quante attività previste non sono state fatte 2) I2 = addizioni al pathway, cioè quante attività non previste in più sono state effettuate Sb 3) I3 = variazioni nella durata delle attività, quanto si sono allungate le tempistiche (es: invece di impiegarci 3 giorni ne sono serviti 5) ob 4) I4 = variazioni nella sequenza delle attività 5) I5 = documentazioni mancanti, cioè le attività non documentate (es: esame in effettuato ma manca il referto) e G ra tu ite Questi indici possono servire a capire se è il PDTA (=Percorso Diagnostico Terapeutico Assistenziale, descrive le attività che devono essere effettuate, come ricovero, intervento, post-intervento, ecc..) non è adeguato, ad esempio manca un pezzo. I dati sono stati acquisiti manualmente utilizzando un foglio Excel, l’analisi è stata alquanto lunga. L’indicatore è rappresentato da una colonna con vari colori, ognuno rappresentante un indice.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Non c’è nessun indicatore completamente a 0, infatti il PDTA è costruito in modo tale che sia il più generico possibile ma ogni paziente avrà delle sue necessità. Ci sono state situazioni in cui l’indice ha dei picchi, in particolare sono state individuate 3 situazioni di criticità, in cui era stato fatto un errore ma è stato individuato subito e corretto o in cui una certa operazione non era stata contemplata nel PDTA. L’indicatore è quindi riuscito effettivamente a intercettarlo. L’ideale sarebbe intercettare le criticità durante i processi, non dopo in quanto potrebbe essere troppo tardi. 3 MEDICAL SOFTWARE REQUIREMENT ELICITATION Sb Consiste nell’identificazione delle funzionalità e specifiche del software. ob 3.1 Osservazione e modellizzazione dei processi in e G ra tu Il primo step è l’analisi dei processi in cui il software verrà utilizzato. Questa analisi ite viene compiuta non solo all’inizio della progettazione del software ma anche quando si deve acquistare un software. È basata su: interviste, PDTA e osservazione. Le interviste e il PDTA coprono tutte le situazioni standard mentre l’osservazione ha il compito di individuare anche percorsi non standard in modo che il processo venga eseguito correttamente anche quando si riscontrano problemi meno frequenti. L’osservazione, quindi, integra e migliora ciò che era stato ottenuto da interviste e PDTA. 3.2 Validazione dei processi modellizzati È quindi un’analisi di quanto il modello effettivamente funzioni e in quali condizioni. La validazione avviene tramite interviste con più persone possibili per avere più punti di vista. Si continua a lavorare fin quando tutta la rappresentazione è approvata.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia 3.3 Identificazione dei requisiti Ottenuti i diagrammi approvati si possono individuare: utenti del software (ben visibili nello Swimlane ma identificabili anche nello Synopsis) dati Sb funzionalità (ben visibili nel Workflow) Esistono 2 tipi di approcci: l’approccio per processi e l’approccio per dati. ob 3.4 Report dei requisiti in e G ra tu ite Nel report sono riportate: descrizioni funzionalità diagrammi conclusioni tratte dai diagrammi Il report può essere utilizzato come parte del Fascicolo Tecnico. COME CAMBIANO I PROCESSI CON L’INFORMATIZZAZIONE? L’informatizzazione può portare a delle modifiche nei processi. Lo si nota analizzando i diagrammi Workflow e Swimlane: in alcuni casi si aggiungono dei processi che prima non esistevano in altri casi potrebbero esserci dei processi che non servono più È fondamentale che queste modifiche siano migliorative. Un classico errore è un software rigido che non si inserisce bene per le esigenze di chi agisce all’interno dei processi, il  PSM 22/23 Formento Moletta Nicolò/Garino Silvia software può rivelarsi inutile ed essere inutilizzato o può rivelarsi dannoso quando utilizzato, raccogliendo dati con elevato numero di errori (motivo per cui bisogna ragionare per processi). Nota sul laboratorio: L’obiettivo è presentare un caso verosimile. Si parte da situazioni realistiche e si decidono i processi ma purtroppo non si può fare la prima fase delle interviste e del raccoglimento dei dati, che occuperebbe troppo tempo. Per questo nel process modeling non è facile individuare i dati. Tuttavia non è stata ancora trovata un’alternativa. Sb ob in e G ra tu ite  PSM 22/23 Formento Moletta Nicolò/Garino Silvia SVILUPPO DEL SOFTWARE Occorre continuare a usare correttamente l’approccio ingegneristico per costruire prodotti robusti. Definizioni di software engineering: Sb 1 UML ob 1.1 Sviluppo del sistema Solitamente non sviluppiamo un solo software ma un sistema in cui ci sono più software che in scambiano dati tra di loro. Per questo parliamo di sviluppo del sistema, un compito e complesso diviso in 3 step principali: G ra tu ite Il design costituisce la progettazione, seguita dalla costruzione che è la scrittura del software e infine c’è la fase di testing. Solitamente le varie fasi non sono così scorrelate, si apportano modifiche e si rivede il progetto durante tutti gli step. Solitamente si utilizza la programmazione ad oggetti (OOP= Object-Oriented Programming). Fino agli anni ’90 la programmazione procedurale era la più utilizzata ma ora è caduta in disuso. Nella programmazione procedurale i dati e le procedure sono separati, mentre nella OOP questi sono tenuti insieme consentendo una migliore manutenzione del software e aumentando la riutilizzabilità del software. Nella OOP le strutture dei dati e le funzioni che operano su queste strutture sono collocate in un solo oggetto.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia 1.2 UML Il UML (=Unified Modified Language) è un linguaggio standard di modellizzazione per i software e lo sviluppo dei sistemi. È nato negli anni ’90 con la programmazione a oggetti. Ha subito un grande cambiamento quando è passato dalla versione 1 alla 2. C’è recentemente stata un’unione di più standard diversi. UML è uno standard molto utilizzato, esistono anche delle certificazioni. Anche nell’UML sono presenti dei diagrammi, che dobbiamo scegliere opportunamente. La modellizzazione permette agli sviluppatori di tenere traccia di quali componenti sono necessari, quali sono i loro compiti, come sono rispettati i requisiti dei clienti e di condividere il design con i colleghi per essere sicuri che le varie parti funzionino insieme. La modellizzazione permette di: gestire la complessità monitorare lo sviluppo documentare le attività L’UML può essere utilizzato come: sketch: si rappresentano solo i punti importanti Sb blueprint: è una fotocopia del software. Sono utilizzati nel Fascicolo Tecnico quando c’è bisogno di essere molto dettagliati. Fornisce specifiche (di tipo funzionale e ob tecnico) dettagliate di un sistema con i diagrammi UML. Utilizziamo i diagrammi per descrivere i fabbisogni e i componenti del software che verranno costruiti, cioè i requisiti e le procedure che dovranno essere presenti nel software in 1.3 UML 1.0 e Prima dell’UML erano state proposte 3 metodologie (Booch, OMT e OOSE) per il supporto di G software di programmazione a oggetti che sono state riunite sotto il nome di UML. ra L’UML 2.0 ha mantenuto la maggior parte dei diagrammi della versione 1. L’UML 1.0 ha un tu approccio al processo di sviluppo del software più immediata e chiara, perciò tratteremo anche l’UML 1.0 ite La rappresentazione dello sviluppo del sistema avviene attraverso 3 macro-processi: Analisi: prende come input il report dell’analisi dei fabbisogni e come output restituisce il modello dei requisiti e il modello dell’analisi. Questa fase non si lega in  PSM 22/23 Formento Moletta Nicolò/Garino Silvia modo specifico agli strumenti di costruzione del software (sistema operativo, ambiente sviluppo del codice e della base dati, ecc..), è quindi implementabile con diversi strumenti e sistemi operativi. Costruzione: è costituita da una fase di progetto e una di implementazione. La fase di progetto parte dalle specifiche tecniche e tiene conto dello sviluppo operativo e dell’ambiente di sviluppo. La fase di implementazione è la scrittura del codice. Testing: verifica che il software funzioni e dimostra che in una certa configurazione non ci sono stati malfunzionamenti attraverso la documentazione. In generale non è possibile garantire che funzioni sempre in tutte le possibili condizioni, ma dobbiamo garantire il corretto funzionamento nella maggior parte dei casi. Tutto quello che si è andato a costruire è utilizzato nella fase di testing, fornendo un’ulteriore garanzia. Attenzione ai costi: non si considerano solo i costi per avere la prima versione ma anche tutti i costi nel caso ci siano dei malfunzionamenti 1.4 UML 2.0 È la versione attualmente utilizzata. In generale non è facile aggiornare gli standard, i tempi trascorsi tra le 2 versioni successive sono decenni. Non ci sono state modifiche ufficiali da 12/2017. Sb ob in e G ra tu ite L’UML 2.0 è più slegato dai processi: anche se è possibile effettuare un percorso analogo a quello dell’UML 1.0 (dal progetto alla costruzione) spesso descriviamo il prodotto realizzato attraverso il diagramma delle classi. Al centro ci sono le funzionalità del software. Un diagramma UML è composto da elementi collegati tra loro. Esistono 2 grossi gruppi di diagrammi disponibili: Diagrammi della struttura: mostrano la struttura statica del sistema e le sue parti su diversi livelli di astrazione e implementazione e come sono collegate tra loro. Gli elementi del diagramma rappresentano concetti significativi di un sistema e potrebbero includere concetti astratti, del mondo reale o implementazioni. Diagrammi del comportamento: mostrano il comportamento dinamico degli oggetti in un sistema che possono essere descritti come una serie di cambiamenti del sistema nel tempo  PSM 22/23 Formento Moletta Nicolò/Garino Silvia 2 MODELLIZZAZIONE DEI REQUISITI Sb Il customer è l’utente, cioè chi utilizza il software. ob Il modello dei requisiti è composto da 3 componenti: in Casi d’uso, cioè le funzionalità del software Interfacce, cioè lo strumento di comunicazione tra il software e l’utilizzatore umano e ma anche tra 2 software G Oggetti (di controllo, sono il flusso delle istruzioni) ra tu 2.1 CASI D’USO ite Un caso d’uso è il modo specifico di utilizzo del sistema usando alcune parti della sua funzionalità. C’è un solo diagramma dei casi d’uso. Inoltre essi non hanno “interruzioni al loro interno” (non si possono variare gli utenti e non è possibile che ci siano delle interruzioni temporali al loro interno). Il diagramma d’uso è costituito da un rettangolo (=system boundary box) che rappresenta il software (su cui stiamo lavorando) e deve sempre essere messo, e al di fuori del rettangolo ci sono gli attori. Gli utenti umani per consuetudine sono messi a sinistra, mentre la strumentazione e i software a destra. Gli attori sono stilizzati con omini mentre il caso d’uso è indicato con un’ellisse al cui interno è messo il nome del caso d’uso.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Sb Nel diagramma sopra si osserva che sono presenti solo i rapporti tra i casi d’uso e non è ob presente nessuna descrizione aggiuntiva. in Non tutti gli attori inseriti nei diagrammi di Swimlane e Synopsis sono anche utenti. Esempio: a volte il paziente non interagisce direttamente con il software ma il medico fa da tramite. e Tra casi d’uso sono utilizzate 2 tipologie di relazioni: G Include: un certo caso d’uso è incluso in un altro caso d’uso. Viene usato quando si ra devono estrarre dei comportamenti comuni tra più casi d’uso in una singola descrizione. La notazione è una freccia a tratti dal caso d’uso che include al caso tu d’uso che è incluso. Può essere richiamato. Posso collegare più utenti a uno stesso caso d’uso se il caso d’uso funziona allo stesso modo per tutti gli utenti. ite Extend: un caso d’uso estende un altro caso d’uso. Questa relazione indica che il comportamento del caso d’uso di estensione potrebbe essere inserito sotto certe condizioni. La notazione è una freccia a tratti dall’estensione verso il caso d’uso che viene esteso. Difficilmente ritrovabile nella realtà in quanto non viene richiamato e viene effettuato non sempre. Esempio: al termine di una visita a volte viene prenotata la visita successiva. Al contrario dell’include, una volta terminato non si torna al caso d’uso che l’ha chiamato.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia A partire dalla descrizione dei processi si possono fare delle ipotesi per lo use case diagram. Normalmente usiamo il Workflow per una prima identificazione dei casi d’uso possibili (1 o più o tutto il workflow o una parte è un caso d’uso). 2.2 ESEMPIO 2 Gli esami ematochimici, attraverso un’analisi del sangue, controllano il funzionamento di sistemi fisiologici. Sb ob in e G ra Le ricette sono preparate con un software diverso da quello delle richieste degli esami. In un tu ambiente integrato il centro dovrebbe poter avere la possibilità di vedere le ricette, ma ciò non accade sempre. Ipotizziamo quindi che sia il paziente a inviare le ricette al centro. Nel ite laboratorio di analisi non c’è bisogno di qualcosa di manuale, avviene in automatico. Il referto viene validato dal medico nel caso ci siano valori totalmente anomali a causa di errori di strumentazione (es: reagente scaduto). Questo processo ha molti punti in cui sono presenti dei software. Noi vogliamo descrivere il software del centro. Si possono evidenziare in questo processo 3 sottoprocessi: 1. RICHIESTA Non coinvolge il centro se non per il fatto che alla fine di questa fase il paziente manda le ricette al centro. 2. ACCETTAZIONE - PRELIEVO Questi due processi si svolgono presso il centro e combaciano con la parte iniziale dell’analisi ematochimica. 3. ANALISI - REFERTO Ultima parte della visita.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia 2.2.1 Synopsis diagram Ci sono 2 possibili risultati: referto inviato o paziente legge il referto. La parte sui dati di input non è semplice: se ipotizziamo che il laboratorio analisi è esterno, nel centro non è presente il referto (ipotizziamo che sia interno) e nella descrizione non viene esplicitato se nel centro è presente un database dei pazienti (ipotizziamo che ci sia). Questi aspetti non sono definiti nella descrizione del processo, decidiamo cosa ipotizzare stando però attenti che tutto sia coerente. Ipotizziamo che quando il paziente arriva al centro le ricette siano già all’interno della base dati del centro, anche le ricette sono dati di input. Se il laboratorio è interno, tra i dati di input c’è anche il database del laboratorio di analisi. Se il laboratorio è esterno al centro ho 2 possibilità: il laboratorio manda direttamente al paziente il referto o il centro fa da tramite (così il referto diventa dato di output). Fondamentalmente per capire quali siano i dati sia di input sia di output è necessario andare a definire quella che è l’organizzazione. Infatti bisogna solo inserire quelli interni all’organizzazione. E’ più semplice andare ad inserirli man mano che si costruiscono gli altri diagrammi. Si prenda come organizzazione il centro per cui si deve andare a definire il software. Sb ob in e G ra tu ite Ci sono molti attori in questo processo. Oltre alle figure umane (in nero): il medico di medicina generale, il paziente, un operatore di accettazione (ad oggi si svolge attraverso un operatore), un infermiere e un medico; si hanno 4 software: il SW piattaforma PzMMG (esterno a quello che ci interessa descrivere, in blu), SW Centro (quello che dovremo andare a descrivere, in rosso), SW Laboratorio analisi (esterno a quello che ci interessa descrivere, in blu) e SW mail (a parte perché realizzata con strumenti general purpose, in giallo). Sono tanti e al contempo facilmente individuabili, ci sarà almeno ancora un altro attore che però si inserirà in seguito, il processo da diagrammare non è lineare e spesso è necessario tornare indietro. L’evento trigger è il paziente che necessita di un controllo 2.2.2 Workflow Diagram Il workflow deve fornire una visione delle attività ad alto livello. Poiché è importante definire con dettaglio la sola parte che riguarda il Software del centro, le parti estranee al centro verranno descritte con poche attività. Le singole attività devono essere raggruppate in macro  PSM 22/23 Formento Moletta Nicolò/Garino Silvia attività, ad esempio si può mettere insieme tutto insieme tutto ciò che succede alla richiesta da parte del Pz. Sb ob E’ stato possibile riassumere in una sola attività un livello di dettaglio elevato della descrizione. La busta non ha senso per la refertazione, perché il lavoro del medico non è su in richiesta (non riceve nessuna segnalazione). e 2.2.3 Requirements Model G Esso è composto dallo use case diagram e dalla descrizione degli oggetti entità (i dati), degli ra oggetti interfaccia (le interfacce) e degli oggetti controllo (il flusso delle macro istruzioni del software). Si hanno i processi e il passo successivo è la costruzione dello use case diagram, tu basata sugli use case principali (individuare utenti del software e casi d’uso principali). I casi d’uso principali sono quei casi che hanno direttamente collegato un attore oppure non ne ite hanno nessuno. Gli attori vanno presi dal synopsis, mentre i casi d’uso dal workflow. In questo caso noi siamo interessati a ciò che succede al centro, quindi tutto ciò che non lo riguarda può essere scartato (restano fuori l’invio della richiesta e la parte di ciò che avviene all'interno del laboratorio analisi). Capita spesso che nel software che si deve descrivere si inserisca in un processo più ampio. Quando devo poi fare lo use case diagram considero solo la parte coperta dalla piattaforma. Ci dobbiamo concentrare sul software del centro. L’invio delle provette ci definisce un ulteriore attore del processo (un tecnico) che svolge il compito di trasferire le provette al laboratorio di analisi. Si continua la costruzione descrivendo i casi d’uso principali mediante gli oggetti. Successivamente lo use case diagram viene completato mediante gli include e gli extend.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia 2.3 OGGETTI Ci sono tre tipologie di oggetti: Un Software è un insieme di istruzioni (oggetto di controllo) che comunicano con l’esterno (oggetti interfaccia, nel nostro caso sarà l’utente ad interagire con il software) e che memorizzano, leggono, elaborano dati (oggetti entità). 2.3.1 Oggetto interfaccia Le interfacce sono utilizzate dagli attori per comunicare con il sistema. Essa può essere impiegata come criterio per la completezza del software rispetto a tutte le specifiche richieste (anche simulando l’utilizzo). E’ utile mettere sempre il nome e Sb cognome del paziente per evitare possibili errori. Si parte sempre dalla home per costruire un’interfaccia grafica. ob I criteri impiegati per definire una bella interfaccia include: 1. L’usabilità (definita anche da una norma), costruire il software anche in base in al processo nel quale si deve inserire e 2. Il senso comune, quello che tutti considerano normale (es: verde = tutto bene, rosso = allarme), rende il software di immediata comprensione. I colori, G le icone devono essere pensati (es: icona a forma di casetta per tornare alla home). ra 3. L’analisi del rischio, serve a mettere in evidenza le interfacce più critiche. tu Elemento da considerare per l’input e l’output, soprattutto per l’output perché i dati vanno rielaborati (non è detto che si vogliano vedere tutti insieme). ite Per progettare un’interfaccia bisogna tenere in considerazione diversi fattori: A. SEMPLICITA’: l’interfaccia del sistema con l’utente deve essere semplice ed intuitiva, per facilitare l’utilizzo anche da parte di utenti senza una significativa esperienza nell’uso di strumenti informatizzati. B. GRADEVOLEZZA: deve essere realizzata un’interfaccia che sia graficamente accattivante C. USABILITA’: le informazioni devono essere organizzate e strutturate in maniera da garantire la massima fruibilità. L’interfaccia deve essere essenziale e l’informazione deve essere organizzata in modo tale che gli utenti siano in grado di realizzare i loro obiettivi in modo semplice e non ambiguo D. NAVIGABILITA’ E FLESSIBILITA’: l’accesso alle diverse informazioni deve essere possibile seguendo strade diverse. Tutte le funzionalità devono essere accessibili sia dall’interfaccia principale che da qualsiasi altra interfaccia. Altri suggerimenti utili per le interfacce: Presenza del tasto “Home” e tasto “Esci”  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Nome del paziente visibile in modo chiaro (per non scambiare i pazienti) divisione dell’interfaccia in aree logicamente coerenti uso di carattere sufficientemente grande uso di icone Come costruire interfacce: Sb ob 2.3.2 Oggetto di controllo in Gli oggetti di controllo descrivono il flusso delle istruzioni del software ad un macro e livello. Per rappresentare un oggetto di controllo possono essere impiegati due tipi di G approccio: ra ➔ Use case details, approccio non particolarmente utilizzato. Rende bene l’idea di come venga successivamente costruito l’Activity diagram tu (visualizzare tutti i possibili rami/percorsi del software). ➔ Activity Diagrams, presenti sia nella versione 1 sia 2 dell’UML. Mostrano le ite azioni ad alto livello per rappresentare un processo in un sistema. Descrive il percorso principale (quello più frequentemente impiegato dagli utenti) e i percorsi alternativi. Il problema è rilevare tutti i percorsi alternativi e riuscire a descriverli chiaramente. Simboli essenziali per la descrizione degli activity diagrams: E’ importante notare che nella selezione (a sinistra), la soluzione rappresentata è quella implementata nella versione numero 2. Se usiamo la versione 1 allora essa si chiudeva direttamente su di un’attività. Se la selezione è impiegata per rappresentare un ciclo la selezione va chiusa direttamente sull’attività.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Un altro simbolo importante è il simbolo a sinistra che viene impiegato per chiamare altre attività, in particolare un altro caso d’uso. Grazie ad esso siamo in grado di raffigurare i collegamenti con gli include e gli extend. Alcuni esempi generali. Dove c’è “object” si possono inserire dei dettagli sulla tipologia di dati, ma questo formalismo non verrà impiegato. La selezione in un caso si richiude direttamente su un’azione, nell’altro si chiude su un oggetto uguale. Ci può Sb essere una selezione tra due oppure tra quanti rami siano necessari (ad ob esempio un menù a tendina, in base a cosa clicca l’utente il programma si in comporterà di conseguenza). e G ra tu ite  PSM 22/23 Formento Moletta Nicolò/Garino Silvia 2.4 ESEMPIO COMMENTATO Sb ob in e Si inseriscono nel diagramma tutte le istruzioni del software, in particolare sia quello che svolge autonomamente sia l’interazione tra l'utente e il software. E’ necessario quindi G integrare l’activity diagram con l’interfaccia (a meno che non sia già stato descritto in un diagramma dedicato). In questo caso il primo passo è la visualizzazione di PV1 che è ra un’interfaccia. Contemporaneamente all’activity diagram è necessario costruire l’interfaccia, c’è un legame stretto tra le interfacce e le activity. Sugli oggetti entità si può lavorare in un tu secondo momento, dopo l’activity si può ragionare sugli stessi a posteriori (non sono ite strettamente legati) perché possono essere impiegati da activity differenti. Come seconda attività in realtà l’utente può fare cose diverse a seconda del tasto cliccato. Le varie opzioni definiscono dei percorsi e delle azioni differenti. Di norma è permesso un ritorno alla situazione iniziale con un tasto (ad esempio il tasto home), ma non sempre perché non bisogna sempre perdere i dati fino ad allora inseriti. Con un ragionamento analogo si definisce il tasto esci. Le richiesta di conferma non devono essere troppo numerose, bisogna utilizzarle con una certa attenzione perché potrebbe perdere di significato (rischio che la conferma diventi un automatismo per l’utente). La distribuzione dei percorsi non è critica: è a discrezione del diagrammatore. In questo caso molti percorsi si chiudono riportandoti al poter cliccare un’altra casella. Questo activity diagram corrisponde a un solo use case, ma si potrebbe pensare di suddividerlo in due utilizzando degli include o degli extend.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Sb L’include non deve necessariamente essere ad un livello ma può essere annidato, non ob necessariamente derivante da una selezione (spesso porta ad usare un’include). Ci sono tre modi di rappresentazione in sostanza. in N.B. Per ogni use case dobbiamo avere un’activity diagram (anche se si tratta di un include e o extend). Sfruttando lo Use Case details si può descrivere lo stesso activity diagram. Si sfrutta il G seguente template per schematizzare gli activity diagram. ra tu NOME DEL CASO D’USO Nome e identificativo del caso d’uso. ite OBIETTIVO Obiettivo da raggiungere mediante lo use case. ATTORI Coloro che sono coinvolti nello use case. TRIGGER Eventuali (ad esempio negli include). FLUSSO PRINCIPALE Interazioni tra gli attori e il sistema necessarie per raggiungere l’obiettivo. Con principale si intende il percorso più frequente (in questo caso la nuova prenotazione e non la cancellazione o la modifica). FLUSSI ALTERNATIVI Qualunque variazione nei passaggi di uno use case. FORMA Interfacce utilizzate.  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Questo è l’inizio del nostro use case details, è molto importante che sia scritto su due colonne cosa svolge il sistema e cosa l’utente, per evitare di dimenticare delle attività e per sottolineare l’interazione con le interfacce. Sb Nella seconda interfaccia è da notare la possibilità di tornare indietro con il tasto annulla. ob Lo USE CASE DETAILS è utile per vedere cosa succede di diverso nel caso di differenti percorsi scelti rispetto a quello principale. in Andando avanti si descrivono i vari percorsi alternativi. e G ra tu ite  PSM 22/23 Formento Moletta Nicolò/Garino Silvia Se i passi si ripetono posso recuperarli da un processo già definito (passi da n a m dello use case “nome”). Sb ob Questo tipo di in rappresentazione, use case details, è e molto pesante, ma G aiuta all’inizio degli activity diagram specialmente per la ricerca di errori. ra Riprendendo l’esempio degli esami ematochimici. I nostri casi d’uso saranno: tu ite INVIA RICETTE: E’ l’unico caso d’uso in cui il paziente usa il software  PSM 22/23 Formento Moletta Nicolò/Garino Silvia ACCETTAZIONE: E’ l'unico caso d’uso in cui l’attore è l’operatore PRELIEVO: E’ l’unico caso d’uso dell’infermiere TRASPORTO: E’ l’unico caso d’uso in cui compare il tecnico RICEZIONE REFERTO:Caso d’uso del software del laboratorio di analisi INVIO REFERTO: Caso d’uso del software delle mail L’ordine delle activity non dev’essere necessariamente cronologico. A seconda di come penso il software sono in grado di dare più use cases ad un singolo attore. Normalmente si pone vicino ad ogni utente tutti i casi d'uso; gli include non necessariamente sono posti vicini. Il criterio fondamentale deve essere la chiarezza espositiva del diagramma (si mette vicino ciò che è legato/condiviso). Il passo successivo è costruire le interfacce e descrivere gli use case diagram. Si parte dalla home, si costruisce una home per ogni attore e si costruiscono le interfacce dei vari casi d’uso. Riprendendo l’esempio, la prima cosa che è stata fatta è costruire lo use case diagram a partire da tutti i processi, individuando le parti di interesse. Successivamente bisogna andare Sb a definire i casi d’uso e la loro descrizione. Si parte creando una Home Page per ognuno degli utenti umani perché l’interazione tra i software non avviene mediante dei form, ma ob attraverso dei messaggi (si veda l’HL7), al contrario della comunicazione uomo-macchina. Un’ipotesi di interfaccia per i vari utenti potrebbero essere: in e G ra tu ite N.B. Nella definizione delle interfacce sono stati lasciati da parte i due software In realtà una parte del processo dell’esempio non ci interessa perché stiamo progettando il software del nostro centro. Quella parte ha delle interazioni, però non è da integrare nella  PSM 22/23 Formento Moletta Nicolò/Garino Silvia parte dei requisiti perché bisogna studiarli in base alle esigenze del software da implementare. In questo caso gli attori sono moltissimi, nel momento in cui faccio lo Swimlane mi accorgo che solo in alcune parti alcuni attori vengono richiamati a fare qualcosa. Le parti risultano essere quindi molto slegate tra loro. E’ possibile suddividere lo Swim Lane in varie fasi (anche temporalmente separate) aggiungendo al bordo una striscia colorata in modo da definire bene le varie fasi. Si possono costituire più Swimlane separati e alla fine di ognuno dovrà esserci il simbolo grafico della fine e iniziare con il simbolo di inizio seguito dall’attività successiva. Dal n