Teoria completa corso di progettazione di software medicali (PSM)

ESEMPIO:

Abbiamo un poliambulatorio dove si effettuano diversi tipi di esami, visite specialistiche, consulenza

nutrizionistica ecc… Noi vogliamo definire le specifiche di un software per gli esami ematochimici.

Facciamo delle ipotesi iniziali: il pz per poter usufruire delle prestazioni del centro deve essere nel database

dei pz del poliambulatorio, a questo punto può interagire con la piattaforma CENTRO (che è appunto la

piattaforma del poliambulatorio) la quale consente di registrarsi (creando o andando ad aprire una Cartella

Paziente), fare prenotazioni, caricare ricette e visualizzare referti. Ma noi NON gestiamo la parte in cui il

paziente viene registrato, bensì partiamo dallo step successivo.

Usano software che sono sì in grado di comunicare (vuol dire che scambiano i dati) tra loro, ma che non

hanno la stessa base dati, questo implica che alcuni dei dati del paziente si ripeteranno nelle varie

piattaforme. (Esistono degli strumenti che consentono di fare passare i dati da un sw A ad un sw B).

Nella cartella clinica (che rimane attiva per molti anni) vengono così a crearsi delle sottocartelle specifiche

per ogni evento.

Il processo che interessa a noi:

A questo punto inizio a costruire il synopsis mettendo al centro gli esami ematochimici che sono il nostro

punto di inizio:

Ciò che scaturisce l’inizio del processo è che il pz necessita di un controllo:

E poi si vanno a selezionare gli attori (persone, strumenti e software) sottintendendo nel nostro processo

che esista già un sw di laboratorio analisi, ovvero chi viene coinvolto nel processo:

A questo punto si inserisce lo stato finale (qui diamo per scontato che vada tutto a buon fine, ma

potrebbero esserci delle uscite diverse come ad esempio se le provette preparate non sono sufficienti o se

il paziente sviene e non ci consente di svolgere gli esami):

Ed infine inseriamo i dati (si intende i dati presenti nei sw(?)):

NB: bisogna specificare, nel caso in cui non abbiano tutti lo stesso software, a quale base dati ci si riferisce.

WORKFLOWS DIAGRAM

È usato per descrivere le azioni effettuate durante i processi ed è basato sulle reti di Petri che si basano su

due elementi: stati (place) e attività (transition) che sono collegati da un arco. Archi da uno stato ad uno

stato o da attività ad attività non sono permessi ma deve sempre esserci un’alternanza.

Stati e attività possono essere collegati in quattro modi:

1. Sequenza: i compiti devono essere eseguiti uno dopo l’altro.

2. Parallelo: i compiti possono essere svolti allo stesso tempo ed in qualsiasi ordine. Per far si che si

svolgano in parallelo bisogna inserire due task artificiali: AND-split e AND-join.

3. Selezione: (if o case) i compiti possono essere svolti in base a delle caratteristiche di un caso

specifico. (Dalla punta possono partire un numero ≥2 di casi). (All’interno del quadrato va scritta

anche la condizione e a valle del cerchio va scritto si o no). →

4. Iterativa: rappresenta un’esecuzione iterativa di un insieme di compiti cicli (li usiamo molto

raramente e comunque preferisce usarli nello swim lane).

→

REPEAT…UNTIL viene eseguito almeno una volta perché la condizione è posta dopo.

→

WHILE…DO potrebbe anche non essere eseguita perché la condizione viene controllata prima.

Nei workflow può essere necessario inserire un nuovo blocco:

viene chiamato processo e si tratta di una sottorete che include stati, attività, archi e sottoprocessi. Poiché

un processo può essere costituito da sottoprocessi che potrebbero avere ulteriori sottoprocessi, è possibile

strutturare un processo più complesso in modo gerarchico.

TRIGGERS

Vengono utilizzati spesso per attività che dovrebbero essere all’inizio ma che potrebbero essere ritardate

(es: devo fare accettazione ma chi me la deve far fare non c’è e ritardo).

Ne esistono di tre tipi:

▪ →

Attività attivate da una risorsa freccia larga rivolta verso il basso.

▪ →

Eventi esterni (come l’arrivo di una mail) simbolo busta.

▪ Dipendenti dal tempo (come la generazione di una lista di ordini alle 6 o come la somministrazione

→

di farmaci) simbolo orologio.

ESEMPIO:

Costruisco il workflow con lo stesso processo di prima (è bene tenere vicino il synopsis così da poterlo

controllare ed eventualmente variare qualcosa).

SWIM LANE ACTIVITY DIAGRAM

Sono stati creati per mostrare una sequenza di attività dove sia ben definito il ruolo di ogni attore tramite

l’organizzazione dell’attività in base alle responsabilità.

La riga spessa blu indica l’inizio del parallelo.

ESEMPIO:

Guardando lo stesso processo di prima ci accorgiamo che ci

→

sono troppi attori e che verrebbero fuori troppe colonne

tre possibilità: scrivere un sottoprocesso solo sul prelievo,

unire attori umani con sw o separare i sottoprocessi. →

Decidiamo di scrivere solo il sottoprocesso del prelievo

nuovo synopsis:

Costruiamo lo swim lane:

ESEMPIO:

Synopsis

Workflow Parallelo e selezione.

→

Anche in questo caso ci sono molti attori ci concentriamo solo sul processo della visita.

Il cardiologo ed il tecnico ECG sono messi a fianco del software perché sono gli attori che lo usano.

Nella realtà per essere più precisi bisognerebbe dare più dettagli (es: chiama pz potrebbe essere seguito da

pz entra, così come potrebbero esserci scritte più attività) e si dovrebbe anche gestire l’eventualità in cui la

prenotazione non venga trovata (cioè manca il percorso) e se si volesse mettere in evidenza il pz in certe

fasi bisognerebbe aggiungere un attore fittizio (tecnico + pz). (16.10.24)

ESEMPIO processo: →

L’evento che fa partire questo processo non viene detto in modo esplicito possono esserci due

condizioni:

La prof ha deciso i valutare due processi separati:

1. Richiesta ricovero;

2. Ricovero vero e proprio;

Nei dati di input abbiamo solo la cartella in cui c’è scritto se il letto è occupato o meno.

→

Ci sono tre stati finali nel workflow poi ci saranno delle selezioni che non verranno chiuse per

evidenziare le tre differenti uscite.

In questo workflow non si mettono due risultati perché i due rami sono in parallelo.

ALTRI POSSIBILI DIAGRAMMI

→

Flowcharts (non vanno bene) sono generalmente usati per descrivere una sequenza di attività. Non

possono gestire attività in parallelo.

Descrizione dell’organizzazione:

• →

Organigramma una struttura ad albero che illustra graficamente le relazioni di autorità: mostra

la struttura gerarchica delle posizioni all'interno di un'organizzazione.

• →

Diagramma delle ‘parti interessate’ mostra l’organizzazione gerarchica degli attori coinvolti nel

processo. stakeholder diagram

BPM+ Health: comunità nata nel 2019 che unisce BPMN (Business Process Management for Healthcare),

CMMN (Common Meta-Model and Notation for modeling) e DMN (precise specification of business

decisions and business rules) standards. Sono modi diversi di descrivere i processi uniti poi appunto nel HL7

BPM Community.

PROCESSO DI INDIVIDUAZIONE DEI REQUISITI

1. Osservazione dei processi e modellizzazione.

2. Validazione dei risultati dal process modeling.

3. Individuazione dei requisiti (requirements elicitation): dai processi che ho modellizzato prendo una

prima informazione per progettare il SW.

4. Report: è un report delle specifiche che viene usato per progettare realmente il SW.

Una volta effettuato tutto questo, grazie ai workflow e agli swim lane acritivity diagram, sono in grado di

analizzare come cambiano i processi con l’informatizzazione (viene fatta una comparazione tra i diagrammi

e come è uscito il SW).

REQUIREMENT ANALYSIS

UML

È uno standard, un linguaggio per la modellazione e la visualizzazione di sistemi software e sta per Unified

Modeling Language.

Lo sviluppo del sistema è un compito complesso che può essere visto come un processo con tre fasi

principali:

[Prima dell’OOP (object-oriented programming) nel caso in cui venisse scoperto e modificato un errore, non

→

si era sicuro che questo venisse sistemato dappertutto l’intento dell’OOP è di migliorare lo sviluppo dei

programmi per i computer. →

Prima della OOP, i programmi per computer si basavano sul concetto di una funzione o subroutine

linguaggi procedurali. Una funzione consente a un programmatore di suddividere un lungo elenco di

istruzioni in unità più piccole che possono essere eseguite ripetutamente. Idealmente, ogni funzione ha uno

scopo e un'interfaccia chiaramente definiti con altre funzioni nel programma. Poiché le strutture dei dati

possono essere accessibili da diverse funzioni in un programma, è importante che le modifiche alla

struttura dei dati si riflettano in tutte le funzioni che accedono alla struttura dei dati.

La programmazione orientata agli oggetti allevia il problema di mantenere la coerenza tra le strutture dati e

le funzioni che accedono a tali strutture. Con la OOP, la struttura dati e le funzioni che operano sulla

struttura dati sono localizzate in un oggetto. Il termine OOP indica che il software è organizzato come

oggetti piuttosto che come funzioni. Gli oggetti contengono sia la struttura dati che le funzioni.]

Lo sviluppo del sistema è un compito complesso che può essere visto come un processo di costruzione di

modelli. Il risultato del processo è una sequenza di modelli che consentono una migliore gestione sia dello

sviluppo che della manutenzione.

USE CASE DIAGRAM

Lo Use Case Diagram, o diagramma dei casi d'uso, è uno dei diagrammi comportamentali dell'UML (per

descrivere come gli elementi interagiscono tra loro durante l'esecuzione). Il suo scopo principale è

rappresentare le interazioni tra gli attori (chi o cosa interagisce con il sistema) e il sistema stesso attraverso

i casi d'uso (azioni o funzionalità principali che il sistema fornisce agli attori. Ogni caso d'uso rappresenta un

obiettivo che un attore vuole raggiungere interagendo con il sistema. Esempi comuni di casi d'uso

includono "Effettuare un pagamento", "Registrarsi" o "Inviare un messaggio".). (17.10.24)

Gli attori li troviamo nello swimlane e nel

synopsis.

Esistono sia attori “normali” che attori

“specializzati”, cioè che un attore che userà i casi

d’uso dell’utente ma ne avrà poi di suoi specifici.

Lo use case diagram è UNICO.

Il software non viene più considerato un attore, ma è il rettangolo all’interno della quale vanno i