INCLUSIONE DI APPLICATIVI MEDICALI NEI SISTEMI INFORMATIVI AZIENDALI - XVI CONVEGNO NAZIONALE AIIC
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
INCLUSIONE DI APPLICATIVI
MEDICALI NEI SISTEMI INFORMATIVI
AZIENDALI
Autori:
Mario Fregonara Medici, Michela Pepe, Giovanni Poggialini
AIIC associazione
italiana
ingegneri clinici
XVI CONVEGNO
NAZIONALE AIIC
Bari - Anno 2016
2 Corso C3 - 2016 | www.aiic.it
presidente aiic
Ing. Lorenzo LEOGRANDE
Come oramai consuetudine, e con estrema soddisfazione, mi accingo anche quest’anno
a presentarvi questo lavoro, risultato tangibile dell’importanza che AIIC dedica alla
formazione.
In occasione della XVI edizione, tenutasi a Bari presso la Fiera del Levante dal 7 al 9
Aprile 2016, abbiamo organizzato ben 10 corsi di formazione, ciascuno della durata di
cinque ore, con la partecipazione di docenti di prim’ordine provenienti da tutta Italia e,
in un caso, anche da Oltre Oceano.
Grazie alla collaborazione con l’Ordine degli Ingegneri della Provincia di Bari e con il Politecnico di Bari,
tutti i corsi sono stati accreditati con 5 CFP (Crediti Formativi professionali) e con 1 CFU (Crediti Formativi
Universitari) per i dottorandi del Politecnico di Bari, il tutto a sottolineare, se ancora ve ne fosse bisogno,
l’importanza ed il peso formativo dell’iniziativa.
Questo “libretto” (così mi piace sinteticamente chiamarlo) è da intendersi come una vera e propria
dispensa che raccoglie, nella maniera più fedele possibile, i contenuti divulgati durante il corso specifico
cui è dedicato.
Non è e non può essere un’opera esaustiva ma piuttosto uno strumento rivolto a tutti coloro, soci e non,
che, interessati agli argomenti trattati, vogliano arricchire le proprie conoscenze e, soprattutto, trovare
spunti di approfondimento.
L’auspicio è che sia uno strumento semplice e utile, da consultare all’abbisogna per ricercare spunti o per
trovare risposte alle piccole quotidiane domande che sorgono durante la nostra vista lavorativa.
Con un occhio alla prossima edizione dei corsi AIIC (Genova 6 – 8 Aprile 2017) colgo infine l’occasione
per un forte e sentito ringraziamento a tutti coloro che, mossi unicamente dalla comune passione per la
professione, hanno lavorato duramente e gratuitamente alla realizzazione del libretto.
ingegneri clinici
associazione
AIIC
italiana
Corso C3 - 2016 | www.aiic.it 3
Presentazione
lini
an ni Poggia
Ing. Giov
la Pepe
ed ici Ing. Miche
. M a r io Fregonara M
Ing
Presidente del Comitato
Collaboratrice del Corso Corsi
----------------------------------- -----------------------------------
Responsabile Scientifico Maturità Tecnica di Perito Dopo la laurea magistrale
del Corso Aziendale Corrispondente in in Ingegneria Biomedica
----------------------------------- Lingue Estere. Collaboratore
conseguita presso il Politecnico
Amministrativo Professionale
Laurea Magistrale in Ingegneria di Milano, inizia immediatamente
presso “Farmacia” e “Informatica
Elettronica e Master 2° liv. Ingegneria a lavorare come consulente
& Telematica” in A.O.U.
Clinica. Responsabile Informatica Maggiore della Carità, prima ingegnere clinico e biomedico,
& Telematica in A.O.U. Maggiore Assistente Amministrativo presso ruolo che tutt’ora ricopre per
della Carità, prima Resp. Servizi “Informatica & Telematica” e diverse aziende sanitarie e non.
Informativi Sanitari in Direzione “Direzione Sanitaria di Presidio” E’ Iscritto all’Albo degli Ingegneri
Sanità - Regione Piemonte, Resp. in A.O.U. Maggiore della Carità. della Provincia di Biella
Tecnologie Sanitarie in A.O.U. Attualmente Segretaria unica del dall’anno 2005 e componente
Careggi, Ricerca e Sviluppo in Tavolo di Lavoro CCIE (Cartella delle commissione sanità
Mortara Rangoni Europe. Socio Clinica Integrata Elettronica) FIOPA dall’anno 2012. E’ socio
ordinario in associazioni biomedicali in A.O.U. Maggiore della Carità ordinario AIIC dall’anno 2005,
(AIIC, ANTEV) e informatica (AISIS), e prima della Commissione
referente regionale AIIC per
GTB (Governo delle Tecnologie
membro in comitati tecnici le regioni Piemonte e Valle
Biomediche) in Direzione Sanità
(CEI, Uninfo), iscritto all’Albo d’Aosta dall’anno 2010 e co-
- Regione Piemonte e della
dei C.T.U. Tribunale Novara per Commissione VABST (Valutazione fondatore del GdL Health
apparecchiature elettromedicali. Acquisizione Beni, Servizi, Project Management nell’anno
Relatore di tesi Laurea e Master, co- Tecnologie) in A.O.U. Maggiore 2014.
autore in articoli, oratore invitato, co- della Carità. In precedenza
autore di relazioni e poster inerenti Referente di Progetto per la
ingegneria clinica, informatica sostituzione degli applicativi di
sanitaria e telemedicina. ADT, Lista d’attesa Ricoveri e CUP
in A.O.U. Maggiore della Carità.
4 Corso C3 - 2016 | www.aiic.it
SOMMARIO
1. PREMESSA 07
2. Scenario delle tecnologie nel contesto sanitario 08
2.1 Evoluzione delle tecnologie 08
2.1.1 Evoluzione delle tecnologie informatiche 09
2.1.2 Evoluzione delle tecnologie biomediche 10
2.2 Classificazione delle tecnologie 12
2.2.1 Classificazione delle tecnologie biomediche 13
2.2.2 Classificazione delle tecnologie informatiche 14
2.3 Caratteristiche dei sistemi medicali 15
3. Direttive, Leggi, Linee Guida e Standard 17
3.1 Le direttive sui Dispositivi Medici 18
3.2 Dispositivi Medici e non Dispositivi Medici 20
3.2.1 Le App sono Dispositivi Medici ? 21
3.3 Percorsi di certificazione dei Dispositivi Medici 22
3.3.1 Dispostiti Medici “Border Line” 23
3.4 Responsabilità dell’uso improprio dei Dispositivi Medici 24
3.5 Classificazione del Software Medicale 24
3.6 Norma CEI EN 80001-1 29
4. LA TECNOLOGIA DELLA LOGISTICA 31
4.1 Cos’è un sistema informativo 31
4.2 Le motivazioni della necessità di un S.I.O. 34
4.3 Implementare un nuovo applicativo nel S.I.O. 39
4.4 La sicurezza dei dati 42
4.5 Consigli utili per i nuovi progetti I.T. 44
5. Case Study: installazione di sistemi nei blocchi operatori 45
5.1 Scenario di integrazione, accessibilità e didattica nei blocchi operatori 45
5.2 Il nuovo ruolo dell’informatica nel processo di cura 47
5,3 Interfacciamento tra apparecchiature 49
5.4 Interfacciamento tecnologico in sala operatoria 53
5.5 Tecnologie video in sala operatoria 53
5.6 Gestione della sicurezza in sala operatoria 56
5.6.1 Integrazione degli applicativi per la prevenzione del rischio clinico 59
5.6.2 Integrazione degli applicativi per il Nucleo Operativo Gestionale 59
5.7 Corretta gestione delle sale operatorie 61
5.8 Le azioni da imparare 62
6. Conclusioni 65
7. Immagini della realizzazione di blocchi operatori 68
Corso C3 - 2016 | www.aiic.it 5
indice delle figure
Figura 2 1: Evoluzione delle tecnologie informatiche 10
Figura 2 1: Evoluzione delle tecnologie biomediche 11
Figura 2 1: Classificazione delle tecnologie in funzione della criticità 12
Figura 2 2: Tipologia dei sistemi informativi 13
Figura 2 3: Classificazione dei sistemi medicali per caratteristiche info-telematiche 14
Figura 2 4: Criticità dei Sistemi Medicali (non solo S.D.M.) 16
Figura 2 5: Problematiche e criticità dei sistemi medicali 16
Figura 2 5: Anche Sistemi Informativi sono complessi 17
Figura 3 1: Direttive Europee sui Dispositivi Medici ed Impiantabili Attivi 18
Figura 3 2: Confronto tra le Direttive sui Dispositivi Medici: 93/42/CEE e 2007/47/CE 18
Figura 3 3: Definizione completa di Dispositivo Medico 19
Figura 3 4: Dispositivi Medici e dispositivi non medici: tapis roulant 20
Figura 3 5: Dispositivi Medici e dispositivi non medici: software di gestione immagini 21
Figura 3 6: Dispositivi Medici e dispositivi non medici: App 21
Figura 3 7: Percorsi di certificazione dei Dispositivi Medici 22
Figura 3 8: Percorsi di «certificazione» dei non Dispositivi Medici 23
Figura 3 9: Dispositivi Medici «borderline» 23
Figura 3 10: Responsabilità nell’uso improprio dei Dispositivi Medici 24
Figura 3 11: Linea Guida MEDDEV 2.1/6 – Modularità del software 25
Figura 3 12: Linea Guida CEI 62-237 25
Figura 3 13: Linea guida CEI 62-237 – Definizioni (1) 26
Figura 3 14: Linea guida CEI 62-237 – Definizioni (2) 27
Figura 3 14: Linea guida CEI 62-237 – Identificazione del software 28
Figura 3 15: Linea guida CEI 62-237 – Identificazione del software (1) 28
Figura 3 16: Linea guida CEI 62-237 – Identificazione del software (2) 29
Figura 3 17: IEC 80001-1 – Ruoli e responsabilità 29
Figura 3 18: IEC 80001-1 – Scenari di ruoli e responsabilità 30
Figura 3 19: IEC 80001-1 – Responsabilità Agreement 30
Figura 3 20: IEC 80001-1 – Proprietà Chiave 31
Figura 4 1: Schema di un Sistema Informativo 32
Figura 4 1: Modello organizzativo aziendale 32
Figura 4 2: Modello a “livelli aumentati” del Sistema Informativo 33
Figura 4 3: I dei rischi dei Sistemi Informativi complessi 33
Figura 4 4: Le difficoltà dei progetti di Sistemi Informativi 34
Figura 4 4: Cos’è il S.I.O. 35
Figura 4 5: Componenti applicative di un S.I.O. 36
Figura 4 6: Modello di architettura del S.I.A.(1) 36
Figura 4 7: Modello di architettura del S.I.A. (2) 37
Figura 4 8: Modello di architettura del S.I.O. 37
Figura 4 9: Il contesto delle regole 38
Figura 4 10: Cos’è un Applicativo Dispositivo Medico 38
Figura 4 10: Implementare un nuovo applicativo nel S.I.O. (1) 39
Figura 4 10: Implementare un nuovo applicativo nel S.I.O. (3) 40
Figura 4 10: Implementare un nuovo applicativo nel S.I.O. (7) 40
6 Corso C3 - 2016 | www.aiic.it
indice delle figure
Figura 4 10: Implementare un nuovo applicativo nel S.I.O. (9) 41
Figura 4 10: La sicurezza dei dati come fattore critico 42
Figura 4 10: Garantire la privacy 43
Figura 4 10: Le deleghe 43
Figura 4 10: Principio di inerzia 44
Figura 4 10: La complessità tecnologica … 45
Figura 4 10: … al fine di migliorare il sistema ! 46
Figura 4 10: Criticità in sala operatoria 47
Figura 5 1: Le nuove esigenze della chirurgia 47
Figura 5 3: Le nuove necessità tecnologiche 48
Figura 5 2: Le nuove necessità operative 49
Figura 5 4: Interfacciamento tra apparecchiature (1) 50
Figura 5 5: Interfacciamento tra apparecchiature (2) 50
Figura 5 6: Interfacciamento tra apparecchiature (3) 51
Figura 5 7: Interfacciamento tra apparecchiature (4) 52
Figura 5 8: Interfacciamento tra apparecchiature (6) 52
Figura 5 8: Interfacciamento tra apparecchiature (7) 53
Figura 5 10: Interfacciamento tra apparecchiature (10) 54
Figura 5 10: Interfacciamento tra apparecchiature (11) 55
Figura 5 10: Interfacciamento tra apparecchiature (12) 55
Figura 5 10: Raccomandazioni perla sicurezza in sala operatoria 57
Figura 5 10: Azione 3. - Progetto sicurezza in sala operatoria 58
Figura 5 10: Azione 3. - Flusso dei dati da considerare in una nuova progettazione 59
Figura 5 10: Codice Barcode 60
Figura 5 10: La gestione del programma operatorio 61
Figura 5 10: Flusso dei dati da considerare in una nuova progettazione 62
Figura 5 10: Concludendo in una nuova progettazione ? (1) 63
Figura 5 10: Concludendo in una nuova progettazione ? (2) 63
Figura 5 10: Approccio ad un progetto integrato (1) 64
Figura 5 10: Approccio ad un progetto integrato (2) 64
Figura 5 10: Le missioni di I.C. I.T. 66
Figura 5 10: I.T. I.C. T.L.C. 67
Figura 5 10: Insieme per il sistema 68
Figura 5 10: Conclusioni del Corso C3 68
Figura 5 10: Immagini realizzazione di un blocco operatorio modulare (1) 69
Figura 5 10: Immagini realizzazione di un blocco operatorio modulare (2) 69
Figura 5 10: Immagini realizzazione di un blocco operatorio modulare (3) 70
Figura 5 10: Immagini realizzazione di un blocco operatorio modulare (4) 70
Figura 5 10: Immagini realizzazione di un blocco operatorio modulare (5) 71
Figura 5 10: Immagini realizzazione di un blocco operatorio modulare (6) 71
Figura 5 10: Immagini realizzazione di un blocco operatorio materno-infantile (1) 72
Figura 5 10: Immagini realizzazione di un blocco operatorio materno-infantile (2) 72
Figura 5 10: Immagini realizzazione di un blocco operatorio materno-infantile (3) 73
Figura 5 10: Immagini realizzazione di un blocco operatorio materno-infantile (4) 73
Corso C3 - 2016 | www.aiic.it 7
1. PREMESSA
Nell’era dell’informazione la generazione, l’archiviazione, l’elaborazione, la gestione, la diffusione, la
consultazione e la condivisione dei dati in formato digitale sono una prerogativa ed un requisito ormai
irrinunciabile nelle moderne organizzazioni.
Per usufruire appieno di tali opportunità e potenzialità è però necessario che, anche in ambito sanitario, le
informazioni generate dalle tecnologie biomediche e gestite attraverso software dedicati siano integrate
con i sistemi informativi delle Aziende Sanitarie e, successivamente, con quelli regionali o nazionali.
L’osservanza degli obblighi derivanti da direttive, leggi, linee guida e standard sull’inserimento e sull’utilizzo
dei software medicali nel contesto sanitario risulta di difficile attuazione e non sempre agevole, come
peraltro l’inserimento di un applicativo sanitario in un sistema informativo richiede l’interazione con gli
altri software di processo e l’interoperabilità con i sistemi amministrativo-gestionali e l’allineamento con
le banche dati aziendali centrali.
La dispensa, indirizzata in particolare agli Ingegneri Clinici quali responsabili della gestione delle
apparecchiature biomedicali all’interno delle Aziende Sanitarie, si propone di fornire le principali
conoscenze sulle problematiche applicabili all’argomento e di approfondire un approccio di visione
multidisciplinare necessario per affrontare con successo l’inserimento di un applicativo sanitario in un
sistema informativo aziendale.
In questo documento sono analizzate le criticità in relazione alla regolamentazione del software come
dispositivo medicale, all’inserimento dell’applicativo medicale in una rete informatica sanitaria,
all’interoperabilità tra software sanitari ed i sistemi informativi aziendali, all’integrazione con i sistemi
amministrativo-gestionali, all’allineamento delle informazioni con le banche dati centrali, alla conformità
delle normative di sicurezza informatica dell’applicativo medicale ed al rispetto dell’applicativo medicale
alle prescrizioni per il trattamento dei dati personali e sensibili.
Inoltre sono indicate modalità operative o metodologie organizzative che agevolano, se adottate
preliminarmente in maniera collegiale, il superamento delle suddette criticità già durante le fasi di
progettazione, installazione ed integrazione, al fine di non incontrare delle difficoltà di complessa
risoluzione durante le successive fasi di attivazione, formazione, gestione e mantenimento di sistemi
tecnologici biomedicali o di applicativi sanitari inseriti nei sistemi info-telematici di un’Azienda Sanitaria,
pubblica o privata.
In tutte le suddette attività l’Ingegnere Clinico ricopre un ruolo fondamentale nelle Aziende Sanitarie,
pubbliche o private, in quanto rappresenta l’interfaccia appropriato tra le professionalità sanitarie e gli
interlocutori tecnico-informatici avendo le competenze multidisciplinari adeguate sia sulle problematiche
dell’operatività delle professioni sanitarie, sia sull’utilizzo delle tecnologie biomediche e sia sulle
aspettative di integrazione con i sistemi informativi aziendali.
La dispensa si sviluppa iniziando dall’illustrazione del quadro normativo italiano, europeo ed internazionale
di riferimento per le attività di progettazione, installazione, integrazione, attivazione, formazione, gestione
e mantenimento di applicativi medicali (denominato Software Dispositivo Medico) inseriti nei sistemi info-
telematici di una Azienda Sanitaria.
Seguirà la descrizione delle problematiche legate all’introduzione di software sanitari nei sistemi
informativi aziendali: l’integrazione con gli applicativi di processo, l’interoperabilità con i sistemi
amministrativo-gestionali, l’allineamento con le banche dati centrali, la conformità delle normative di
sicurezza informatica ed il rispetto delle prescrizioni per il trattamento dei dati personali e sensibili.
8 Corso C3 - 2016 | www.aiic.it
Infine sarà illustrato un case-study relativo all’esperienza di integrazione, di interoperabilità, di accessibilità
diffusa e di utilizzo per la didattica dei sistemi informatici/vi presenti nei blocchi operatori di un’Azienda
Ospedaliero-Universitaria e, quindi, impiegati per la gestione delle attività mediche, per l’organizzazione
quotidiana da parte degli operatori sanitari e per la formazione degli studenti.
Nella dispensa saranno anche evidenziati le responsabilità ed i ruoli dell’Ingegnere Clinico rapportate
a quelli delle altre figure tecnico-professionali aziendali coinvolte nelle fasi di analisi, progettazione,
valutazione, installazione, collaudo, attivazione e gestione di sistemi complessi con tecnologie biomediche
ed informatiche interoperanti e/o integrate.
2. Scenario delle tecnologie nel
contesto sanitario
In questo capitolo sono descritti gli scenari e le evoluzioni delle tecnologie biomediche, informatiche e di
telecomunicazione che sono coinvolti nell’informatizzazione delle Aziende Sanitarie, pubbliche o private.
2.1 Evoluzione delle tecnologie
Le tecnologie biomediche, informatiche e di telecomunicazione sono state ambiti originariamente
separati con professionalità diverse e percorsi formativi differenti, che si sono sviluppate negli anni fino
al raggiungimento congiunto di prestazioni sorprendenti in tutti tre i settori (soprattutto non in ambito
sanitario):
• telecomunicazione: tecnologie che consentono la trasmissione di dati digitali ad una velocità
sempre maggiore con una distribuzione sempre più capillare;
• informatica: tecnologie per la gestione, l’archiviazione, la comunicazione e la condivisione in
tempo reale di qualsiasi tipologia di informazione;
• biomedicali: tecnologie per analisi ed indagini mediche sempre più precise e puntuali oppure per
il monitoraggio continuo di dati con sensori miniaturizzati.
Tutti questi settori hanno avuto, negli ultimi 50 anni, enormi evoluzioni dal punto di vista delle prestazioni
funzionali (di cui sinteticamente di seguito ripercorriamo le principali “milestone” evolutive) che ora sono
maggiormente evidenti grazie alla naturale convergenza, interoperabilità ed integrazione tecnologica
che si sta realizzando in questi ultimi anni e che tutti noi possiamo “sfiorare con le dita”, soprattutto per
l’ambito dell’informatica e delle telecomunicazione.
In ambito sanitario la disponibilità di queste evoluzioni tecnologiche ha favorito l’integrazione e
l’accessibilità delle informazioni sanitarie (accurate, tempestive ed anche multimediali) a tutti gli attori
del settore indipendentemente dalla localizzazione geografica.
Corso C3 - 2016 | www.aiic.it 9 2.1.1 Evoluzione delle tecnologie informatiche Originariamente l’informatica si occupava solo di pochi applicativi, isolati tra loro, di mainframe, terminali e stampanti. Con l’introduzione dei Personal Computer e di diverse periferiche che digitalizzano le informazioni analogiche è iniziata l’epoca dell’Information Technology (I.T.). Ugualmente la telecomunicazione iniziale si è evoluta nella telematica principalmente attraverso l’introduzione della comunicazione digitale e l’utilizzo diffuso degli apparati di rete attivi (modem, hub, switch, router, etc) che hanno consentito di realizzare, facilmente ed economicamente, non solo le connettività a grande distanza, ma anche quella all’interno di uno stesso edificio o comprensorio. A seguito di queste prime evoluzioni che hanno consentito l’estensione massiva degli applicativi nella gestione delle diverse attività nelle organizzazioni produttive, c’è stata un’importante convergenza dell’informatica e della telematica nell’I.C.T. (Information and Communication Technology), seguita più recentemente da quella con la fonia fissa (VOIP – Voice Over IP). L’I.C.T. ha posto le basi tecnologiche per soddisfare l’esigenza e la necessità nelle organizzazioni produttive di un vero o proprio Sistema Informativo (S.I.), il quale consente di elaborare, archiviare, comunicare, diffondere e condividere documenti ed informazioni in maniera trasversale. Le potenzialità di tale evoluzione hanno fatto sorgere l’esigenza di una maggiore interoperabilità ed integrazione tra i diversi applicativi o S.I.. Dagli anni novanta, la sempre crescente disponibilità della fruizione di Internet ha originato una significativa maggiore richiesta di diffusione e di utilizzo dei S.I., che ha conseguentemente determinato un’ulteriore spinta per lo sviluppo tecnologico. Tale evoluzione, in Sanità denominata e-Health, è ha coinvolto soprattutto le funzioni di comunicazione, accessibilità e diffusione delle informazioni, dando realmente inizio al difficile “cammino” per la definizione e l’attuazione dell’interoperabilità e dell’integrazione tra gli applicativi attraverso la definizione di protocolli e/o standard dedicati (in ambito sanitario: DICOM, HL7, IHE, etc). In questi ultimi anni la recente convergenza tra I.C.T. e la connettività mobile assicura un’accessibilità anche dagli apparati mobile (notebook, tablet, smartphone) ad un connettività dati con velocità di trasmissione sempre crescenti (ormai paragonabili a quelle delle reti cablate) che consente di utilizzare con questi dispositivi le funzionalità di elaborazione, di accessibilità e di diffusione delle informazioni proprie delle postazioni informatiche fisse. In Sanità tale evoluzione, denominata m-Health, ha consentito di ampliare ulteriormente la generazione, la condivisione e la fruizione dei dati sanitari con nuove modalità e potenzialità.
10 Corso C3 - 2016 | www.aiic.it
Figura 2‑1: Evoluzione delle tecnologie informatiche
2.1.2 Evoluzione delle tecnologie biomediche
Per decenni l’evoluzione dagli elettromedicali alle tecnologie biomedicali è stata focalizzata
sull’industrializzazione delle apparecchiature medicali, sulla ottimizzazione e miniaturizzazione delle
componenti elettroniche, sull’incremento della qualità e dell’accuratezza nell’acquisizione di dati o
segnali, sul miglioramento delle prestazioni di analisi ed elaborazione delle informazioni, sull’innovazione
di nuove metodologie e metodiche diagnostiche e sull’ampliamento del loro utilizzo nell’ambito della cura
e terapia dei pazienti ed anche della sicurezza degli operatori.
Con l’avvento dell’I.T. si è verificata una prima convergenza che ha portato all’introduzione dei sistemi
biomedicali, nei quali la parte applicativa di controllo, elaborazione, archiviazione e gestione dei dati
clinici e medici in formato digitale è generalmente preponderante.
Contemporaneamente è iniziata a svilupparsi la telemedicina (soprattutto come cura e assistenza
sanitaria a domicilio), come convergenza tra i sistemi biomedicali e la telematica, con la finalità di
consentire agli attori sanitari di migliorare la cura o la terapia a domicilio dei pazienti, attraverso l’accesso
e la condivisione da remoto delle informazioni sanitarie acquisite a domicilio, e di supportare i servizi
socio-sanitari domiciliari, attraverso un maggiore coinvolgimento dei pazienti e dei familiari direttamente
presso le abitazioni. La telemedicina consente la continuità di rilevamento di dati, allarmi, segnalazioni
sulle condizioni di salute del paziente, il conseguente miglioramento delle informazioni che sono rese
disponibili – anche in tempo reale – a tutti gli attori coinvolti, la riduzione del disagio derivante da una
lunga terapia soprattutto per i pazienti cronici, la diminuzione complessiva dei costi, diretti del sistema
sanitario ed indiretti dell’ambito sociale, necessari per la cura dei cittadini.Corso C3 - 2016 | www.aiic.it 11
L’ulteriore evoluzione è avvenuta con i sistemi biomedicali integrati i quali utilizzano le potenzialità della
trasmissione, anche in tempo reale, delle immagini e dei video, e che hanno iniziato anch’essi il difficoltoso
percorso per l’attuazione dell’interoperabilità e dell’integrazione inizialmente con gli altri applicativi
medicali.
In questo ultimo decennio si è molto sviluppata la tecnologia dei sensori biomedici indossabili (chiamati
wearable disposable) che, tenuti a contatto diretto con il corpo del paziente, consentono la misurazione ed
il monitoraggio costante (24 ore su 24, tutti i giorni) di parametri fisiologici (ad esempio: la glicemia, il livello
di ossigeno nel sangue, la frequenza cardiaca, etc) o dell’ambiente circostante all’utente (esposizione alla
luce solare, il livello di ossigeno, etc) utili per misurare fenomeni clinici oppure per il controllo della salute
della persona. Tali dispositivi indossabili possono essere facilmente collegati ad un apparato mobile (in
particolare tablet o smartphone) che assume la funzione di interfaccia utente, di archivio e di trasmissione
- anche bidirezionale - di dati, informazioni, allarmi, segnalazioni sulle condizioni di salute del paziente
verso un presidio sanitario di controllo.
La recente convergenza tra e-Health ed i sensori biomedici indossabili - denominata p-Health – ha
consentito di ampliare ulteriormente l’ambito di applicazione delle tecnologie biomediche attraverso la
generazione, la condivisione e la fruizione dei dati sanitari con nuove modalità e potenzialità.
Figura 2‑1: Evoluzione delle tecnologie biomediche12 Corso C3 - 2016 | www.aiic.it
2.2 Classificazione delle tecnologie
Gli elettromedicali e dei sistemi informatici possono essere classificati in funzione della loro criticità nelle
attività svolte all’interno delle Aziende Sanitarie come:
• Business Critical: applicativi per la gestione delle attività e dei processi dell’ambito amministrativo,
economico o logistico;
• Operational Critical: applicativi per la gestione delle attività e dei processi dell’ambito medico o
clinico indispensabili per il funzionamento dell’organizzazione sanitaria;
• Mission Critical: applicativi o sistemi per la gestione delle attività e dei processi dell’ambito
diagnostico, terapeutico, interventistico indispensabili;
• Life Critical: dispositivi o sistemi o applicativi sono vitali per la salute del paziente e la qualità della
cura.
Figura 2‑1: Classificazione delle tecnologie in funzione della criticità
I domini dei sistemi informativi e dei sistemi biomedicali ormai hanno ambiti di sovrapposizione sempre
più ampi derivanti dall’incremento di utilizzo dell’informatica nelle tecnologie biomedicali e dalla
sempre crescente pervasività dei sistemi informativi nell’operatività quotidiana nel contesto sanitario e
nell’esecuzione delle prestazioni cliniche. Ciò ha portato a suddividere i sistemi informativi nelle seguenti
tipologie in funzione della loro complessità, criticità e condivisione di dati in sistemi organizzativi e sistemi
medicali.
Proprio dalla consapevolezza dell’importanza, della criticità e della complessità dei software presenti
nei sistemi biomedicali appartenenti alla fascia Mission Critical si è definito la tipologia dei Software
Dispositivi Medici (S.D.M.), per i quali è stata estesa la necessità della marcatura CE, in similitudine con
i Dispositivi Medicali (D.M.), e quindi sono state definite precise regole (di seguito illustrate brevemente)
che queste tipologie di applicativi devono rispettare.Corso C3 - 2016 | www.aiic.it 13
Figura 2‑2: Tipologia dei sistemi informativi
2.2.1 Classificazione delle tecnologie biomediche
Da quando le apparecchiature elettromedicali sono evolute nei sistemi biomedicali (cioè hanno iniziato
ad usare degli applicativi informatici come loro parte integrante) si è cominciato a parlare di integrazione
ed interoperabilità tra i due ambiti. Una classificazione dei sistemi medicali può essere data in base alle
caratteristiche informatiche del sistema, come di seguito definita:
• Embedded: software integrato nel D.M. (es.: pompe infusione, ECG, etc);
• On-Board: software installato sul D.M. che è in realtà un PC dedicato (es.: ecografi, etc);
• Accoppiato: software installato su PC collegato direttamente al D.M. per il controllo del dispositivo
e/o per l’elaborazione e l’archiviazione dei dati (es.: microscopio, etc);
• Console: workstation di refertazione, essa stessa D.M., di un sistema S.D.M. (es.: sistema di
refertazione radiologico, emodinamico, etc);
• Terminale: software installato su PC fisso, il quale è connesso via rete ad un sistema medicali per
refertazione o elaborazione dei dati (es.: sistema di refertazione cardiologico, etc);
• Remoto: software installato su PC portatile, il quale è connesso attraverso una rete virtuale protetta
(V.P.N. - Virtual Private Network) alla rete aziendale ed ad un sistema medicali per refertazione o
elaborazione dei dati (es.: sistema di telerefertazione, etc);
• Mobile: software installato su tablet o smartphone, il quale è connesso attraverso un portale
aziendale ad un sistema medicali per visualizzazione dei dati (es.: sistema di teleconsulto, etc).14 Corso C3 - 2016 | www.aiic.it
Figura 2‑3: Classificazione dei sistemi medicali per caratteristiche info-telematiche
2.2.2 Classificazione delle tecnologie informatiche
Una altra classificazione dei sistemi medicali in base alle caratteristiche telematiche è di seguito indicata:
• Stand-Alone: tecnologia medicale che utilizza un software senza essere connesso alla rete aziendale
(es.: microscopio, etc);
• Isolati: sistemi con postazioni connesse tra loro tramite una rete dati “isolata” (es.: monitoraggio
terapia intensiva, etc);
• Intranet: sistemi connessi tramite la rete aziendale (es.: C.I.S., U.I.S., P.A.C.S., etc);
• Didattica: sistemi che inviano video e dati ad una rete universitaria;
• Private-cloud: sistemi connessi ad un server aziendale ma in cloud (cioè al di fuori della rete
aziendale);
• Internet: sistemi connessi ad un server esterno alla rete aziendale via Internet (es.: sperimentazioni,
ricerche farmacologiche, etc);
• Wireless: S.D.M. connessi alla rete aziendale con una connessione wireless (es.: monitor paziente
di PS, etc).
Il recente sviluppo delle tecnologie informatiche e di telecomunicazione sta trasformando a tutti noi il
modo di accedere alla informazioni ed anche in Sanità questa evoluzione sta velocemente modificando le
tipologie di necessità degli utilizzatori, chiedendo ai fornitori di applicativi medicali la convergenza verso
sistemi classificati come Private-cloud, Internet e Wireless.
Questa “tumultuosa e rapida” evoluzione sta avvenendo senza affrontare e contemporaneamente risolvere
le criticità tipiche dei sistemi medicali ancora presenti nelle Aziende.Corso C3 - 2016 | www.aiic.it 15
2.3 Caratteristiche dei sistemi medicali
I sistemi medicali stanno evolvendo velocemente dal punto di vista tecnologico, ma ad oggi la maggioranza
presenta ancora le seguenti criticità:
• “Solitari”: sono sistemi non integrati o interoperanti con gli altri applicativi dei sistemi informativi
aziendali;
• “Abiti sartoriali”: sistemi fortemente personalizzati per ogni specifica struttura operativa e quindi
hanno grandi difficoltà nella gestione evolutiva garantendo la retro-compatibilità;
• “App for dummies”: sistemi con limitate caratteristiche di consistenza e di garanzia di continuità
operativa;
• “Users’ friendly”: sistemi senza autenticazione dell’operatore, senza profili di operatività, senza
tracciabilità sulle operazioni eseguite;
• “Windoze1 Designed”: sistemi non stabili e sicuri dal punto di vista strettamente informatico
considerando che sono basati sul sistema operativo Windows;
• “Handmade”: applicativi spesso “verticali” sviluppati da Piccole Media Imprese che possono dare
limitate garanzie di continuità, stabilità e permanenza sul mercato ed anche di aggiornamento
tecnologico;
• “Bolliti”: sistemi tecnologicamente obsoleti e non evoluti, poiché ormai datati;
• “Open-data”; sistemi nei quali sono assenti sistemi di protezione dei dati e accorgimenti per
garantire la tutela della privacy in maniera adeguata alla normativa vigente;
• “Back-doors”: sistemi nei quali spesso non è consentita l’installazione di sistemi antivirus e quindi
rappresentano poi possibili pericoli ed accessi non controllati per i sistemi di sicurezza informatica
aziendale;
• “Tifosi”: sistemi dipartimentali estremamente “verticali” sviluppati da entusiasti dell’informatica
(solitamente dipendenti del reparto interessato), che non possono dare garanzie di continuità,
stabilità e di aggiornamento tecnologico.
Per le suddette motivazioni i rischi potenziali sono numerosi, gravi e verosimili tanto che si è reso necessario
richiedere per i S.D.M. il rispetto di requisiti tecnico-qualitativi analoghi ai Dispositivi Medici, e similmente
si è aperto un confronto negli enti tecnici normativi se estendere questi obblighi anche agli applicativi
della categoria Sistemi Medicali.
1 “Windoze” è un termine dispregiativo nello slang usato in Internet che identifica i sistemi basati sul sistema
operativi Microsoft-Windows16 Corso C3 - 2016 | www.aiic.it
Criticità Sistemi Medicali (non solo SDM)
Corso C3 – H.I.T.
Mario Fregonara
Medici
Molti dei Sistemi Medicali hanno le seguenti criticità:
• "Solitari" (non integrati o interoperabili)
• "Abiti sartoriali" (configurazioni non standard)
• "App for dummies" (affidabilità carente)
• "Users’ friendly" (scarsa tracciabilità)
• "Windoze Designed" (a rischio instabilità)
• "Handmade" (garanzia limitata - fatti da P.M.I.)
• "Bolliti" (tecnologicamente obsoleti)
• "Open-data" (protezione scarsa)
• "Back-doors" (per l’intero S.I.A.)
• "Tifosi" (sviluppati da entusiasti dell’informatica)
I rischi potenziali sono numerosi e, quindi, è necessario che
siano adottati dei requisiti tecnico-qualitativi simili ai DM
7
Figura 2‑4: Criticità dei Sistemi Medicali (non solo S.D.M.)
I sistemi medicali sono ormai notevolmente complessi e complicati e, come i sistemi informativi, sono
affetti dalle seguenti molteplici problematiche ed elevate criticità che potrebbero causare gravi rischi o
danni:
• combinazioni di errori praticamente illimitate;
• problemi sempre nuovi con conseguenze imprevedibili;
• guasti in componenti che generano problemi a catena;
• “barriere difensive” che difficilmente arginano gli errori imponderabili o che riescono a contenerne
i danni derivanti;
• difficoltà a garantire dei livelli minimi di affidabilità, di continuità operativa e di sicurezza funzionale.
Figura 2‑5: Problematiche e criticità dei sistemi medicaliCorso C3 - 2016 | www.aiic.it 17
I S.I. hanno ormai un elevatissimo livello di complessità che deriva, principalmente, dalla presenza di
molti fornitori diversi degli applicativi presenti, i quali creano enormi problemi di integrazione tra loro ed
è proprio per questa motivazione che si è voluto definire, a livello internazionale ed europeo, delle regole
finalizzate a “creare ordine”.
Figura 2‑5: Anche Sistemi Informativi sono complessi
3. Leggi, Linee Guida e Standard
In questo capitolo sono descritte le principali direttive, leggi, linee guida e standard sull’utilizzo dei
software nel contesto sanitario ed i relativi contenuti.
La Commissione Europea ha iniziato a disciplinare la materia di ingegneria clinica iniziando dagli
impiantabili attivi, con la direttiva 90/385/CEE, e proseguendo con i dispositivi medici, con la direttiva
93/42/CEE, i cui regolamenti sono stati successivamente aggiornati, armonizzati ed unificati, con la
direttiva 2007/47/CE, introducendo anche importanti novità.18 Corso C3 - 2016 | www.aiic.it
Figura 3‑1: Direttive Europee sui Dispositivi Medici ed Impiantabili Attivi
3.1 Le direttive sui Dispositivi Medici
Nella 93/42/CEE il Dispositivo Medico viene definito come qualsiasi strumento, apparecchio, impianto,
sostanza o altro prodotto usato da solo o in combinazione, compreso il software informatico impiegato per
il corretto funzionamento e destinato dal Fabbricante ad essere impiegato nell’uomo a scopo di …
Nella successiva 2007/47/CE invece si parla di software “… destinato dal Fabbricante ad essere impiegato
nell’uomo a fini di:
• diagnosi, prevenzione, controllo, trattamento o attenuazione di malattie,
• diagnosi, controllo, trattamento, attenuazione o compensazione di una ferita o di un handicap,
• studio, sostituzione o modifica dell’anatomia oppure di un processo fisiologico,
• controllo del concepimento, …”.
La parola software prima era a corredo dell’apparecchio, mentre ora è considerata da sola alla pari di uno
strumento, apparecchio, impianto, sostanza o altro e quindi ora esso è divenuto un Software Dispositivo
Medico.Corso C3 - 2016 | www.aiic.it 19
Figura 3‑2: Confronto tra le Direttive sui Dispositivi Medici: 93/42/CEE e 2007/47/CE
Con la 2007/47/CE si introduce la possibilità di certificare come D.M. anche il software stand- alone, cioè un
software non legato ad una specifica apparecchiatura medicale.
Figura 3‑3: Definizione completa di Dispositivo Medico20 Corso C3 - 2016 | www.aiic.it
3.2 Dispositivi Medici e non Dispositivi Medici
La differenza tra un D.M. e un’attrezzatura appare evidente se consideriamo un cutter seppur professionale
ed un bisturi chirurgico, il quale è evidente a tutti che è l’unico che può essere utilizzato sui pazienti perché
entrambi sono stati progettati e realizzati nell’ambito sistemi di qualità organizzativi aziendali ma per il
secondo sono state fatte, prima della commercializzazione, prove e verifiche di funzionamento al fine di
poterlo utilizzare sul paziente.
Se mettiamo a confronto un trapano professionale con marchio CE e un trapano chirurgico in entrambi
i casi sono stati progettati e realizzati nell’ambito sistemi di qualità e sono state rispettate le norme
specifiche, ma nel secondo caso sono state fatte, prima della commercializzazione, prove e verifiche di
funzionamento di funzionamento al fine di poter utilizzare lo strumento in modo sicuro sul paziente.
Lo stesso accade su un tapis roulant usato in una palestra e quello usato dal medico con il paziente,
hanno entrambi lo stesso utilizzo, sono stati progettati e realizzati nell’ambito sistemi di qualità e sono
state rispettate le norme specifiche, ma il secondo è stato soggetto, prima della commercializzazione, a
verifiche di sicurezza e a prove di funzionamento e quindi è un Dispositivo Medico che può essere utilizzato
dai pazienti.
Figura 3‑4: Dispositivi Medici e dispositivi non medici: tapis roulant
Quando invece si parla di software per archiviazione e refertazione di immagini non si può parlare di sola
archiviazione, poiché la funzionalità che rende l’applicativo un D.M. è quella di refertazione.Corso C3 - 2016 | www.aiic.it 21
Figura 3‑5: Dispositivi Medici e dispositivi non medici: software di gestione immagini
3.2.1 Le App sono Dispositivi Medici ?
Un altro tema molto discusso in questo recente periodo in ambito dei D.M. riguarda l’utilizzo delle App in
ambito medico. La maggior parte di queste non sono certificate e quindi non risultando classificate come
D.M..
E’ indubbio il vantaggio dell’utilizzo delle App quale dello strumento nelle attività quotidiane in mobilità,
poiché l’alternativa sarebbe o un portatile (con maggiori ingombri ed altre problematiche tecniche)
oppure il foglio di carta utilizzato ancora oggi nelle corsie con altissime probabilità di imprecisioni, ma
quando di una App non è chiaramente identificato il Fabbricante, la responsabilità di eventuali errori o
malfunzionamenti non è associabile e riconducibile a nessuno e quindi senza un Fabbricante non c’è un
D.M..
Figura 3‑6: Dispositivi Medici e dispositivi non medici: App22 Corso C3 - 2016 | www.aiic.it
3.3 Percorsi di certificazione dei Dispositivi Medici
Il Fabbricante decide che la destinazione d’uso del suo prodotto rientra nella definizione di D.M. della
direttiva 2007/47/CE e gli attribuisce una classe di rischio da 1 a 3, dove la classe 3 riduce il rischio al
massimo perché fa più controlli.
Dopodiché interviene l’Organismo Certificante, il quale verifica la correttezza delle procedure di
progettazione, di realizzazione e di prove, e generalmente approva la classificazione proposta oppure
talvolta abbassa la classe che è stata proposta oppure da indicazioni che sia rivista oppure in rarissimi casi
non approva e quindi non certifica il prodotto come D.M..
Figura 3‑7: Percorsi di certificazione dei Dispositivi Medici
In alternativa il Fabbricante decide che la destinazione d’uso del suo prodotto NON rientra nella definizione
di D.M. della direttiva 2007/47/CE e quindi non è obbligato a seguire il percorso di certificazione.Corso C3 - 2016 | www.aiic.it 23
Figura 3‑8: Percorsi di «certificazione» dei non Dispositivi Medici
3.3.1 Dispostiti Medici “Border Line”
Ci sono alcuni prodotti che si possono definire “borderline”, ad esempio i prodotti cosmetici, i prodotti
medicinali non farmacologici, i prodotti biocidi, i prodotti per autopsia, etc.
La seguente immagine presenta alcuni prodotti medicinali non farmacologici molto simili tra loro di
cui però solo 1 su 3 è certificato come D.M., poiché in questo caso il Fabbricante ha deciso di seguire la
procedura di certificazione, di individuare la destinazione e la classe di rischio, mentre negli altri casi
questo non è avvenuto.
Figura 3‑9: Dispositivi Medici «borderline»24 Corso C3 - 2016 | www.aiic.it
3.4 Responsabilità dell’uso improprio dei Dispositivi
Medici
Per commercializzare qualsiasi bene nella Unione Europea deve essere rispettata la normativa sulla
sicurezza generale dei prodotti, infatti il D.Lgs. n.172 del 21/5/2004 in attuazione alla direttiva n. 2001/957CE
relativa alla sicurezza cita:
“Il produttore adotta misure proporzionate in funzione delle caratteristiche del prodotto fornito per consentire
al consumatore di essere informato sui rischi connessi al suo uso e per intraprendere le iniziative opportune
per evitare tali rischi, compresi il ritiro del prodotto dal mercato, il richiamo e l’informazione appropriata ed
efficace dei consumatori.”
La norma dispone di intervenire e, se necessario, anche ritirare dal mercato il prodotto non sicuro.
Figura 3‑10: Responsabilità nell’uso improprio dei Dispositivi Medici
3.5 Classificazione del Software Medicale
Ai fini della classificazione medicale dei Software in ambito medico sono state introdotte delle linee guida
da diversi organismi tecnici, di cui le principali sono:
• LINEE GUIDA MEDDEV 2.1/6;
• LINEE GUIDA CEI 62-237.
Nelle Linee Guida MEDDEV 2.1/6 è definito il software stand-alone come D.M. in sé non incorporato in
un altro dispositivo, mentre la Sezione 4 introduce la possibilità di avere all’interno di un software solo
alcuni moduli certificati come D.M.. Se il modulo certificato non è “solitario” all’interno di un sistema
applicativo, il Fabbricante deve comunque fare l’analisi del rischio dell’intero sistema ed analizzare il
rischio complessivo di errori.Corso C3 - 2016 | www.aiic.it 25
Figura 3‑11: Linea Guida MEDDEV 2.1/6 – Modularità del software
Le Linee Guida CEI 62-237 forniscono uno strumento tecnicamente robusto, sostenibile ed applicabile
nella pratica reale, per l’identificazione e la gestione del software nelle reti I.T. medicali, cioè quelle a cui è
connesso almeno un D.M..
Figura 3‑12: Linea Guida CEI 62-23726 Corso C3 - 2016 | www.aiic.it
Nel documento viene definita l’Organizzazione Responsabile che può essere un Ospedale, un singolo
medico o una persona inesperta. Inoltre viene definito lo scopo sanitario come un’azione eseguita con
l’obiettivo di avere degli effetti anche indiretti sullo stato di salute, fisico, sociale o mentale di un individuo
o un gruppo di individui.
Figura 3‑13: Linea guida CEI 62-237 – Definizioni (1)
Un prodotto software ha quindi uno scopo sanitario se il Fabbricante ne ha previsto l’utilizzo in un’azione
a scopo sanitario. Il software può essere sanitario o generico, nel primo caso viene utilizzato nel contesto
sanitario e può avere effetti sugli effetti sulla salute, mentre nel secondo caso svolge la sua funzione in
ambiti applicativi e contesti d’uso differenti.Corso C3 - 2016 | www.aiic.it 27
Figura 3‑14: Linea guida CEI 62-237 – Definizioni (2)
I seguenti fattori sono rilevanti per la corretta identificazione della classificazione del software:
• destinazione d’uso: scopo per il quale un prodotto è stato realizzato (informazioni rese
obbligatoriamente dal Fornitore per i S.D.M.);
• contesto di destinazione:, dichiarazione (facoltativa del Fabbricante) relativa all’ambiente
particolare per cui il prodotto è destinato, ad esempio: ambiente industriale, sanitario, domestico,
...;
• uso effettivo: utilizzo reale del prodotto da parte dell’utilizzatore nella specifica organizzazione,
indipendentemente dall’eventuale destinazione d’uso o dalle istruzioni fornite dal fabbricante;
• contesto d’uso: contesto di utilizzo del prodotto da parte dell’utilizzatore, se diverso dal contesto
di destinazione;
• possibili effetti sulla salute e sulla sicurezza di pazienti ed operatori: capacità o utilizzo del prodotto
di influire, in modo diretto o indiretto, sulla salute o sulla sicurezza degli individui.28 Corso C3 - 2016 | www.aiic.it
Figura 3‑14: Linea guida CEI 62-237 – Identificazione del software
La Linea Guida CEI fornisce una indicazione relativa al processo di identificazione del software da introdurre
in una rete I.T. medicale per valutare a quale gruppo, secondo le figure seguenti, dovrà essere associato.
Pertanto l’Organizzazione Responsabile potrà distinguere le casistiche in cui deve occuparsi di valutare
il rapporto rischio/beneficio, cioè di verificare la destinazione d’uso, di esaminare l’uso effettivo e di
analizzare l’impatto sulla salute, al fine di assumere le conseguenti azioni amministrative, tecniche,
operative ed organizzative relative al livello di attenzione corrispondente.
Figura 3‑15: Linea guida CEI 62-237 – Identificazione del software (1)Corso C3 - 2016 | www.aiic.it 29
Figura 3‑16: Linea guida CEI 62-237 – Identificazione del software (2)
L’Organizzazione Responsabile, nella quale viene introdotto un software a scopo sanitario (appartenente
al Gruppo D, che nella dispensa abbiamo definito come Software/Sistema Medicale), deve occuparsi di
recuperarne la documentazione annessa, verificarne la destinazione d’uso, esaminarne l’uso effettivo,
analizzarne l’impatto sulla salute e valutarne il rapporto rischio/beneficio (documento redatto dal
Fabbricante nel caso di S.D.M.), e quindi assumere le conseguenti azioni amministrative, tecniche,
operative ed organizzative relative al livello di attenzione corrispondente.
3.6 Norma CEI EN 80001-1
La norma definisce ruoli e responsabilità nell’ambito della gestione del rischio di reti I.T. che incorporano
dispositivi medicali (rete I.T. medicale).
Figura 3‑17: IEC 80001-1 – Ruoli e responsabilità30 Corso C3 - 2016 | www.aiic.it
La responsabilità è distribuita e condivisa tra tutti gli attori coinvolti però deve essere identificato un
responsabile principale che si assume il rischio più grande.
Figura 3‑18: IEC 80001-1 – Scenari di ruoli e responsabilità
La norma definisce anche il “Responsibility agreement”, in base al quale l’Organizzazione Responsabile
deve determinare, quando un D.M. è incorporato in una rete I.T., la necessita di stipulare uno o più accordi
di responsabilità documentati che definiscano la responsabilità di tutte le parti interessate e coinvolte.
L’accordo può interessare uno o più progetti di una o più reti I.T. definendo tutte le responsabilità per tutto
il ciclo di attività del D.M. incorporato.
Figura 3‑19: IEC 80001-1 – Responsabilità AgreementCorso C3 - 2016 | www.aiic.it 31
La gestione del rischio dovrebbe essere utilizzata per affrontare le “proprietà chiave”, cioè le caratteristiche
fondamentali e necessarie, di una rete I.T. che incorpora un D.M.:
• Assenza di rischio inaccettabili di lesione fisica o di danni alla salute di persone;
• Efficacia, capacità di produrre il risultato previsto per il paziente e per l’Organizzazione Responsabile;
• Sicurezza dei dati e del sistema informatico/vo.
Figura 3‑20: IEC 80001-1 – Proprietà Chiave
4. Introduzione di software in
un sistema informativo
Introduzione di software in un sistema informativo
In questo capitolo viene descritto sinteticamente un sistema informativo al fine di poter comprendere
maggiormente le principali caratteristiche e complessità e, conseguentemente, le criticità e le problematiche
che ne derivano, anche connesse all’introduzione di un S.D.M..
4.1 Cos’è un sistema informativo
Il Sistema Informativo è basato su tecnologie info-telematiche e rendono disponibili a ciascun attore
dell’organizzazione le informazioni e i dati necessari per svolgere le sue attività, in base alle richieste che
riceve, sia all’interno che dall’esterno dell’organizzazione.32 Corso C3 - 2016 | www.aiic.it
Figura 4‑1: Schema di un Sistema Informativo
L’organizzazione di un’azienda è rappresentata come un modello gerarchico a più livelli, i quali si scambiano
informazioni in “orizzontale» e/o «verticale” ed interagiscono tra loro, agevolati e supportati dai sistemi
informativi, al fine di svolgere tutte le tipologie di attività da quelle operative e di produzione, fino a quelle
direzionali e di pianificazione.
Figura 4‑1: Modello organizzativo aziendaleCorso C3 - 2016 | www.aiic.it 33
Il modello di un S.I. si può derivare estendendo il modello piramidale del “Knowledge Management”,
applicato alle organizzazioni complesse in cui alla base si trova il livello “Operativo”, che si occupa della
gestione e delle procedure operative, salendo fino al livello della “Programmazione”, che si occupa delle
strategie e politiche aziendale, aggiungendo un ulteriore livello delle “Infrastrutture”, che consente
la diffusione e l’integrazione dei dati, delle informazioni e della conoscenza che sono gestiti dai livelli
superiori.
Figura 4‑2: Modello a “livelli aumentati” del Sistema Informativo
I S.I. possono essere molto complessi, le informazioni sono tante, a volte disperse e non sempre di dati che
vogliamo sono quelli disponibili o completamente attendibili.
Figura 4‑3: I dei rischi dei Sistemi Informativi complessi34 Corso C3 - 2016 | www.aiic.it
I S.I. sono progetti molto complessi e difficoltosi per i quali è necessaria la correlazione con la parte dei D.M.
e l’interazione tra ciò di cui si ha necessità, quello che propone il commerciale, quello che ha progettato
l’analista e quello che i tecnici hanno fatto.
I S.I. sono progetti molto complessi e di difficile realizzazione, per i quali è necessario tener conto non solo
dell’integrazione con i D.M., ma anche della difficoltà nel riuscire a far coincidere ciò di cui si ha bisogno,
con ciò che propone il commerciale, con quello che progetta l’analista, con quello che realizzano i tecnici
e con ciò che sarà collaudato dall’informatico.
Figura 4‑4: Le difficoltà dei progetti di Sistemi Informativi
4.2 Le motivazioni della necessità di un S.I.O.
Il Sistema Informativo Ospedaliero (S.I.O.) - sottoinsieme ospedaliero del Sistema Informativo Aziendale
(S.I.A.) che supporta anche le attività sanitarie territoriali - è definito come:
un sistema che organizza e gestisce in modo efficace ed efficiente le informazioni necessarie per
perseguire uno o più scopi mediante applicativi medicali, clinici e/o sanitari.
Le principali componenti tecnologiche del S.I.O. sono la rete, i server, i data base, i sistemi operativi, gli
applicativi, le postazioni di lavoro informatiche, etc e pertanto possiamo equipararlo e ricondurlo ad un
ecosistema.Puoi anche leggere
