AdRem NetCrunch 5 XE. Monitoraggio delle reti ospedaliere. <<Il personale medico assiste i pazienti ogni giorno...chi li aiuta nel loro lavoro?

Transcript

1 AdRem NetCrunch 5 XE Monitoraggio delle reti ospedaliere <<Il personale medico assiste i pazienti ogni giorno...chi li aiuta nel loro lavoro?>> Autore: dott. Ing. Antonio Di Maio AdRem Sales Engineer sales@adremsoft.com

2 2008 AdRem Software, Inc. This document is written by AdRem Software and represents the views and opinions of AdRem Software regarding its content, as of the date the document was issued. The information contained in this document is subject to change without notice. ADREM SOFTWARE MAKES NO WARRANTS, EITHER EXPRESS OR IMPLIED, IN THIS DOCUMENT. AdRem Software encourages the reader to evaluate all products personally. AdRem Software and AdRem NetCrunch are trademarks or registered trademarks of AdRem Software in the United States and other countries. All other product and brand names are trademarks or registered trademarks of their respective owners. Web site:

3 Introduzione In una moderna struttura ospedaliera viaggiano ogni giorni in rete centinaia di migliaia di messaggi che trasportano informazioni mediche via HL7/DICOM; l importanza dei dati clinici è tale da richiedere alle applicazioni sviluppate per HIS, RIS, LIS un livello di affidabilità superiore alla norma e la capacità di garantire la corretta consegna dei messaggi inviati. Siete in grado di determinare con assoluta certezza lo stato di ogni interfaccia clinica del vostro ambiente? Sfortunatamente la risposta più frequente a questo tipo di domanda è <<.. fino adesso non ho ricevuto nessuna richiesta quindi tutto funziona correttamente.>> Per ottenere questo livello di confidenza è importante disporre di una console di monitoraggio unica, con visione globale su tutta l'infrastruttura della rete ospedaliera, così da raccogliere quei dati utili necessari a garantire un livello ottimale di funzionamento e per poter allo stesso tempo configurare un sistema di allarmi che avvisi tempestivamente il personale quando un intefaccia di rete tra due applicazioni cliniche è disattiva. Il personale medico deve poter contare su un sistema informativo ospedaliero affidabile che permetta loro di accedere alle informazioni condivise tra i reparti 24 ore su 24 e che sia in grado di mantenere sempre attiva la comunicazione tra le reti e i sistemi. L infrastruttura di rete dati è il mezzo attraverso il quale anche in ambito ospedaliero tutte le informazioni (richiesta di un esame, registrazione di un nuovo paziente, immagini DICOM, prenotazioni degli esami radiologici etc..) vengono instradate affinchè siano disponibili e condivise tra tutti i reparti di una moderna struttura ospedaliera. Per un reparto di Radiologia il processo di refertazione parte dalla prenotazione, o comunque dal primo approccio alla struttura da parte del paziente, per arrivare alla chiusura amministrativa delle attività effettuate e, a seconda del contesto ospedaliero, prevede diverse fasi: prenotazione, accettazione, agenda di sala, esecuzione o esplatamento, consumo e magazzino, refertazione e trascrizione, firma e stampa, consegna, ricerche e statistiche e rendicontazione; i protocolli HL7 e DICOM giocano un ruolo chiave nell integrazione di tutti gli anelli della catena. Il workflow di riferimento Segue uno schema di riferimento di cui vengono riportate le definizioni degli attori e delle componenti più importanti (fonte wikpedia):

4 Sistema Informativo Ospedaliero CUP: è uno strumento informatico utilizzato in ambito sanitario per gestire le richieste dei pazienti ed identificare in maniera veloce ed efficiente il primo posto disponibile (o uno alternativo in base alle esigenze dei pazienti stessi) per le prestazioni da erogare. A seconda del livello di integrazione con i sistemi informatici ospedalieri il CUP è in grado di trasferire le proprie informazioni a: Laboratory Information System Sistema informatico radiologico o RIS Hospital Information System o HIS LIS: è un sistema informatico utilizzato in ambito sanitario per gestire le richieste dei pazienti nonché processare e memorizzare le informazioni generate dai macchinari dei laboratori di analsi. RIS: sistema informatico radiologico, è utilizzato nelle Radiologie per gestire il flusso dei dati legati ai pazienti. Le funzionalità del RIS permettono di gestire il cosiddetto "processo di refertazione", cioè quella serie di azioni od eventi che portano dall'approccio del paziente con la struttura all'espletamento del referto, oggetto dell'indagine radiologica.

5 Diagnostiche del reparto di radiologia PAC: è l'acronimo di Picture Archiving and Communication System (Sistema di archiviazione e trasmissione di immagini). Consiste in un sistema computerizzato per l'archiviazione digitale delle immagini radiologiche e la loro trasmissione e visualizzazione su workstation dedicate, collegate mediante rete informatica. Al paziente, invece delle lastre, viene consegnato un CD-ROM contenente gli esami radiologici effettuati. Il PACS si integra con il sistema informatico radiologico o RIS (Radiology Information System) per l'immissione dei dati del paziente nel sistema informatico. Le immagini quando vengono elaborate sono memorizzate in un archivio on-line molto veloce (RAID, Redundant Array of indipendent disk). Poi la memorizzazione dei dati in un archivio intermedio è richiesta per legge per un periodo di 1 o 2 anni (juke-box e type-library). infine i dati vengono memorizzati in archivi più economici di lungo termine, solitamente su supporti CD-ROM o DVD, i quali vengono conservati per il successivo riutilizzo qualora se ne renda necessaria la visualizzazione. È necessario che il RIS si interfacci con il sistema informativo ospedaliero HIS (Hospital Information System) così da avere un unico codice identificativo ID che accompagni per sempre il medesimo paziente in qualunque iter diagnostico successivo alla originaria registrazione su HIS. Tomografia: in radiologia la tomografia computerizzata, indicata con l'acronimo TC o CT (dall'inglese computed tomography), è una metodica diagnostica per immagini, che sfrutta radiazioni ionizzanti (raggi X) e consente di riprodurre sezioni (tomografia) corporee del paziente ed elaborazioni tridimensionali.

6 L'immagine del corpo da studiare viene creata misurando l'attenuazione di un fascio di raggi X che attraversa tale corpo; l'emettitore del fascio di raggi X ruota attorno al paziente ed il rivelatore, al lato opposto, raccoglie l'immagine di una sezione del paziente; in un tomografo il lettino del paziente scorre in modo molto preciso e determinabile all'interno di un tunnel di scansione, presentando a ogni giro una sezione diversa del corpo. Le immagini prodotte vengono inviati ai sistemi PACs per la loro memorizzazione. Stazioni di Refertazione: i radiologi, esaminando le immagini e consultando i precedenti del paziente, effettuano la refertazione. La trascrizione del referto può essere effettuata manualmente o con strumenti di riconoscimento vocale dal Radiologo stesso oppure può essere dettata su dittafoni analogici o digitali (in questo caso il file audio può essere salvato dal RIS) e demandata alle dattilografe o a sistemi di riconoscimento vocale in differita. Tipicamente i referti vengono indicizzati per permettere la ricerca con keywords e vi vengono associate codifiche anatomopatologiche come l'acr o l'icd9cm. UPS: un dispositivo da collegare fra la rete elettrica e l'alimentazione del sistema informatico. L'UPS accumula energia in batterie ad esso collegati anche in caso di interruzione dell'energia elettrica sulla rete. HL7: Health Level Seven (HL7) è lo standard per la comunicazione di messaggi più diffuso al mondo nel settore dell'ict in sanità. DICOM: Lo standard DICOM (Digital Imaging and COmmunications in Medicine) definisce i criteri per la comunicazione, la visualizzazione, l'archiviazione delle immagine mediche prodotte dalle diagnostiche. Dischi RAID: Un Redundant Array of Independent Disks ("insieme ridondante di dischi indipendenti", RAID) è un sistema informatico che usa un insieme di dischi rigidi per condividere o replicare le informazioni. I benefici del RAID sono di aumentare l'integrità dei dati, la tolleranza ai guasti e/o le prestazioni, rispetto all'uso di un disco singolo. ACK: ogni messaggio HL7 deve essere riscontrato e verificato sia dalle applicazioni server che dalle interfacce; tipicamente questo viene ottenuto con dei messaggi di tipo ACK la cui struttura è MSH MSA [ERR], dove il segmento ERR è opzionale e contiene in caso di errori ulteriori informazioni. Il campo MSA-2 Acknowledgment code (ID) definisce un codice di identificazione che può assumere uno dei seguenti valori: AA AE Il messaggio è stato processato con successo dal server; viene generato un messaggio di risposta con il valore "AA" nel campo MSA-1. Errore nel processare il messaggio; viene creato un messaggio che informa l applicazione client del tipo di errore di sistema includendo il valore "AE" nel campo MSA-1. Il segmento ERR contiene altre informazioni.

7 AR CA CE CR Errore nel processare il messaggio per ragioni non correlate al contenuto o al formato del messaggio ma per indisponibilità del database, errori interni al sistema, ecc.; l'applicazione ricevente richiede alla applicazione mittente di rinviare il messaggio in tempi successivi con il valore "AR" nel campo MSA-1. Original mode: Application Reject Enhanced mode: Application acknowledgment: Reject Enhanced mode: Accept acknowledgment: Commit Accept Enhanced mode: Accept acknowledgment: Commit Reject ADT: messaggi di tipo HL7 per la gestione dei dati del paziente. LLP: LLP noto anche come MLLP (Minimal Lower Protocol) è lo standard assoluto per la trasmissione dei segmenti HL7 via TCP/IP. Approfondimenti sul protocollo LLP LLP noto anche come MLLP (Minimal Lower Protocol) è lo standard assoluto per la trasmissione dei segmenti HL7 via TCP/IP ( altre modalità di comunicazione fanno uso di protocolli più noti come FTP, SOAP e SMTP); è noto che TCP/IP invia pacchetti in rete sotto forma di flusso di byte ( streaming) ed i protocolli di wrapping come LLP rappresentano una valida soluzione per permettere alle applicazioni in rete di riconoscere l'inizio e la fine di ogni messaggio trasmesso. Alcune applicazioni mediche potrebbero non aderire al protocollo ed è importante in questi casi che le interfacce cliniche siano flessibili e fornite di strumenti integrati in grado di tarare le stesse interfacce per l operazione di wrapping. Ogni singolo messaggio HL7 deve essere racchiuso fra un header ed un footer, caratteri non visibili e che non fanno parte del messaggio. La tabella seguente mostra una tipica struttura di un messaggio HL7 trasmesso via LLP: Header Messaggio HL7 Footer Barra verticale (0x0B) MSH ^~\& ADT^A04 ADT P 2.1 PID LEVERKUHN^ADRIAN^C^^^ M Carattere di separazione (0x1C) Ritorno a capo Ritorno a capo (0x0D) Occorre assicurare inoltre che ogni intervallo termini con un ritorno a capo 0x0D; questo è di solito compito delle stesso standard, ma spesso i dati possono essere anche trasmessi via o FTP dove i separatori di intervallo vengono convertiti trasformati in caratteri di 0x0A, ecc. Messaggio ADT^A04 Ammissione paziente Introduzione al messaggio ADT Soffermiamoci un attimo al tipo di messsaggo ADT (Admission Discharge Transfer) contenente i dati anagrafici del paziente e altri dati simili e descriviamo brevemente il significato dei singoli segmenti:

8 1. Header MSH: Intestazione del messaggio; contiene il tipo di evento e le applicazioni, strutture ospedaliere e/o reparti coinvolti nella comunicazione. 2. EVN - Descrizione dell evento 3. PID - Identificazione del paziente 4. PV1 - Informazioni sulla visita Il messaggio che useremo anche per i test di questo tutorial è il seguente: MSH ^~\& NetCrunch_ADT XYZ_ADMITTING Listener_IS XYZ_HOSPITAL ADT^A P EVN EVN PID ^^^ADT1 ROSSI^MARIO M AI 7616 STANFORD AVE^^ST. LOUIS^MO^ PV1 E 5101^NELL^FREDERICK^P^^DR V1002^^^ADT che in formato ASCI e con le instestazioni ed i caratteri di coda per la compatibilità con LLP diventa: 0b4d53487c5e7e5c267c4e e63685f c58595a5f41444d e477c4c e65725f49537c58595a5f484f c7c7c7c e c c507c322e332e31 7c7c7c7c7c7c7c7c20da45564e7c7c c7c7c7c e7c7c c7c7c7c da c7c7c e5e5e c7c524f e4d f7c7c c4d7c7c41497c e464f e5e53542e204c4f e4d4f5e c7c7c7c7c7c7c c7c7c7c7c7c7c7c7c7c7c7c c7c7c7c7c7c7c7c7c7c7c7cda c7c457 c7c7c7c7c7c e4e454c4c5e b5e505e5e44527c7c7c7c7c7c7c7c7c7c7c e5e5e c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c7c c7c7c7c7c7c7c7c1c0d Sono riconoscibili le applicazioni sender (NetCrunch_ADT) e receiver (Listener_IS) nei campi del messaggio. Quando il client invierà una richiesta di registrazione al server CUP quest'ultimo riconoscerà il messaggio analizzerà i campi e ritornerà un ACK che nel caso di un riscontro positivo sarà del tipo: MSH ^~\& Listner_IS XYZ_HOSPITAL NetCrunch_ADT XYZ_ADMITTING ACK A P 2..1 MSA AA Obiettivi della guida Centinaia di migliaia di messaggi di tipo HL7 e DICOM viaggiano ogni giorno in una moderna rete ospedaliera; l importanza dei dati clinici è tale da richiedere alle applicazioni sviluppate per HIS, RIS, LIS un livello di affidabilità superiore alla norma e la capacità di garantire la corretta consegna dei messaggi inviati; da qui l importanza di disporre di una console di monitoraggio unica, con visione globale su tutta l'infrastruttura della rete ospedaliera, così da permettere allo staff tecnico

9 dell ospedale di raccogliere dati utili come: carenze di risorse (dischi RAID, processori, memoria e reti), mancata disponibilità delle applicazioni e dei protocolli medici installati sui server, carichi di lavoro, traffico di rete etc.. In questo tutorial ci occuperemo: 1. del monitoraggio dell affidabilità del CUP in particolare: verifica della presenza del segmento MSH nel messaggio ACK della verifica dei riscontri AA, AE, AR dei segmenti MSA ricevuti controllo di presenza del segmento MSA nel messaggio di ritorno controllo di coerenza dei campi MSH-5 del client con MSH-2 del server della verifica in tempo reale della disponibilità del protocollo HL7 2. della generazione della reportistica per: traffico di rete totale sull interfaccia del CUP distribuzione oraria e giornaliera dei tempi di monitoraggio del CUP disponibilità dell interfaccia dei nodi e del protocollo HL7 tasso di errore dei messaggi HL7 3. dell organizzazione del cruscotto per l analisi in tempo reale delle principali metriche e statistiche dei servizi e dei messaggi in particolare: RTT dei pacchetti HL7 Failure Rate dei pacchetti di HL7 Check Time dei servizi % Pacchetti HL7 persi % Pacchetti HL7 Inviati % Pacchetti HL7 Ricevuti % Disponibilità del servizio in rete 4. di definire per ogni singolo nodo un diario degli interventi di manutenzione esportabile come RDMS 5. di illustrare un caso di studio reale per il monitoraggio di siti ospedalieri 6. di costruire viste associando icone grafiche differenti ad apparati con funzionalità diverse (TAC, Stazioni di refertazione, PACs Web Server, Server di Storage etc..) 7. Configurare il sistema degli allarmi e delle notifiche a video e via Come configurare il server CUP di ascolto Listener_IS Per gli scopi di questo tutorial si è utilizzato il Listener HL7 fornito con il prodotto Chamaleon della interfaceware collezione di strumenti per la gestione e lo sviluppo di applicazioni compatibili con HL7 e disponibile all indirizzo Per configurare il server HL7: Selezionare dal menu Windows Avvio > Programmi > interfaceware > HL7 > Listener.

10 Nel campo Message Log field cliccare il bottone (...) e specificare il nome del file di log per il salvataggio dei messaggi in arrivo dai client. Spuntare l opzione Append to message log file per disattivare la sovrascritturare del log. Nel campo Port Number inserire la porta di ascolto del server per la connessione TCP. Lasciare tutte le altre opzioni inalterate e cliccare Start per avviare il Server. Il server con indirizzo di rete resterà in ascolto delle richieste del client NetCrunch 5 con indirizzo sulla porta 5000 come in figura: Un Server CUP in ascolto notare il messaggio di reply con campo AA Come configurare il client ADT_NetCrunch Controllo della presenza del segmento MSH nel messaggio ACK Per configurare questo controllo occorre: verificare che il messaggio di ritorno dal server inizi opportunamente con il segmento MSH, definire un nuovo servizio specificando nome, porta e protocollo di trasporto scelto. Selezionare dal menu Tools > Options Nel riquadro a sinistra portarsi su Monitoring > Network Services > e cliccare su New Service. Definire un nuovo servizio di rete con le seguenti proprietà dei campi: o Protocol/Service Name : MSH Missing o Protocol Type : TCP o Port : 5000 o Description : Il messaggio di reply dal CUP non inizia con il campo MSH

11 Portarsi sulla scheda Request ed incollare con ( CTRL+V) il messaggio di richiesta in formato ASCII prima convertito per la compatibilità con con LLP ( 0b4d53487c5...0d). Portarsi sulla scheda Response e selezionare dalla listbox la voce all of the patterns match. Cliccare sul bottone Add Pattern e selezionare per la listbox Format il valore Text. Definire la condizione come : o Start checking from 1 byte of response. Check if response contains value MSH. Process maximum 3 bytes of the response data. Ripetere la procedura per la definizione degli altri controlli come nella tabella seguente: Servizio Request Response Pattern Descrizione /Contro llo HL7 Nessuno Nessuno Verifica della disponibilità del servizio HL7 MSA AA MSA AR MSA AE MSH-2 Field Error MSH Missing Messaggio ADT^A04 di test Messaggio ADT^A04 di test Messaggio ADT^A04 di test Messaggio ADT^A04 di test Messaggio ADT^A04 di test Start checking from 83 byte of response. Check if response contains value MSA AA. Process maximum 94 bytes of the response data. Start checking from 83 byte of response. Check if response contains value MSA AR. Process maximum 94 bytes of the response data. Start checking from 83 byte of response. Check if response contains value MSA AE. Process maximum 94 bytes of the response data. Start checking from 10 byte of response. Check if response contains value Listener_IS. Process maximum 21 bytes of the response data. Start checking from 1 byte of response. Check if response contains value MSH. Process maximum 4 bytes of the response data. Controllo sul segmento MSA-2 Controllo sul segmento MSA-2 Controllo sul segmento MSA-2 Controllo di coerenza dei campi MSH-5 del client con MSH-2 del server. Il messaggio di reply dal CUP non inizia con il campo MSH Molte applicazioni HL7 usano il protocollo TCP/IP per trasmettere e ricevere i dati per questo motivo è importante determinare l indirizzo IP e la porta utilizzata. Lanciando il discovery NetCrunch 5 determinerà i nodi dell infrastruttura con ICMP/SNMP e da altre sorgenti dati come i gruppi di Windows, le edirectories e le Active Directory; dopo aver scoperto gli indirizzi IP correnti NetCrunch 5 determina automaticamente la tipologia dell'hardware : server, router, switch, stampanti etc.. Sia cliccando con il tasto destro sul nodo di una mappa sia dal menu avvio di Windows Tools-> itools and SNMP Tools è possibile eseguire lo strumento Connection per lanciare lo scanning delle porte utilizzate.

12 Indipendentemente dal tipo di messaggio il controllo del servizio HL7 (prima voce della tabella) dovrebbe essere monitorato per tutte quelle macchine che comunicano dati HL7; noi applicheremo per ora il controllo solo al nodo CUP. Aggiungere il protocollo HL7 sui tutti i nodi dell atlante Per aggiungere il protocollo HL7 per tutti i nodi dell atlante: Selezionare dal menu Tools > Options Nel riquadro a sinistra portarsi su Monitoring > Network Services Cliccare il Bottone Add New Service per aggiungere un servizio di default per tutti i nodi e selezionare HL7. Cliccare OK e confermare. Aggiungere al solo CUP il protocollo HL7 Come aggiungere i servizi al nodo CUP Per aggiungere i servizi per il singolo nodo: Portarsi sulla vista HIS in Atlas Maps Portarsi sul Server CUP ed aprire il menu di contesto con il tasto destro. Selezionare Monitoring > NetWork Services > Properties Dalla scheda Scheda NetWork Services cliccare il bottone Add New Service quindi selezionare i servizi configurati e personalizzare i campi della finestra (es. monitoring time) Confermare con OK. Nota: Per ogni singolo servizio è possibile specificare un tempo di polling diverso. Controllo dei risultati e dello stato dei messaggi Aggiunti i controlli al nodo CUP ed avviato il server, NetCrunch 5 mostrerà l'andamento ed i risultati dei test come: Nodi lampeggianti e finestra di stato Quando uno o più servizi non rispondono o non sono raggiungibili e/o se le risposte dal server non coincidono con i patterns preconfiguari (Unregonized Response) i nodi prendono a lampeggiare di colore giallo mostrando le etichette dei servizi interessati. Un doppio click sul nodo apre la finestra di Status che nella Scheda Network Service (fare riferimento alla guida fornita con il prodotto per il significato dei colori) mostra alcuni dei principali parametri dei segmenti MSH, MSA e del protocollo HL7 mentre portandosi sul nodo con la freccia del mouse sarà visualizzato un tooltip con un anteprima dei parametri principali del nodo:

13 Un Tooltip che mostra un'anteprima sullo stato del nodo AdRem NetCrunch 5.x

14 La scheda Network Services Dettaglio dei nodi della mappa HIS In forma di tabelle le stesse ed altre informazioni sono accessibili portandosi sul Scheda Details della mappa corrente come mostrato in questa immagine: Vista dei dettagli dei nodi della mappa Per accedere ai dettagli selezionare la scheda Details

15 Registrazione dei risultati ed invio delle notifiche Quando uno o più servizi non rispondono possiamo configurare degli eventi per la registrazione nel log di NetCrunch 5 e/o per inviare notifiche all'amministratore personalizzate. Come definire gli allarmi per la registrazione degli eventi del CUP Per impostare gli eventi per il CUP: Portarsi sulla vista HIS in Atlas Maps Portarsi sul Server CUP ed aprire il menu di contesto con il tasto destro. Selezionare Alerting > Edit Alerting Policy Restando sulla scheda Alerting cliccare il bottone Add per aprire la finestra di definizione degli eventi. La scelta del tipo degli eventi è ampia ma per gli scopi di questo tutorial portiamoci sulla scheda Services & Interfaces e dal gruppo NetWork Service State Event clicchiamo due volte su Selected Service is DOWN; comparirà la finestra per la personalizzazione dell evento Edit Event Definition. Dalla ListBox NetWork Service selezionare il servizio da monitorare precedentemente definito. Seguono alcuni screenshots di esempio: Il sistema di allarmi Per default sono impostate alcune azioni come la scrittura degli eventi nel database di NetCrunch 5 (la colonna Alert Action mostra un'azione di tipo <Write to Event Log>) ma altre possone essere personalizzate ( riga <Custom> per Service [HL7] is UP ) come l invio di un SMS, l'esecuzione di uno

16 script per il reboot di una macchina o per lanciare la deframmetazione dei dischi, l'invio di una etc.. La figura seguente mostra le entries degli eventi generati: Il log degli eventi Definire un azione di notifica personalizzata Per modificare il comportamento base delle azioni: Portarsi sulla vista HIS in Atlas Maps Portarsi sul Server CUP ed aprire il menu di contesto con il tasto destro. Selezionare Alerting > Edit Alerting Policy Selezionare il servizio per quale si vuole definire un'azione personalizzata ed aprire il menu di contesto con il tasto destro del mouse quindi portarsi su Edit Alert Action Cliccare sul bottone Add e selezionare Action to Run Immediatly Nella Scheda Basic portarsi sul gruppo Simple e cliccare su sarà visualizzata la finestra di configurazione:

17 Completare i campi e confermare con OK per ogni finestra. Ripetere la procedure per aggiungere altre azioni per lo stesso evento ed utilizzare l'opzione Run After per definire ritardi tra ogni singola azioni del gruppo definito. Organizzazione del cruscotto delle performance e delle statistiche HL7 Per definiere un cruscotto per la raccolta in tempo reale delle statistiche dei protocolli: Portarsi sulla cartella Performance View in Atlas Maps ed aprire il menu di contesto con il tasto destro del mouse Selezionare New > Blank Chart View Cliccare con il tasto destro in un punto qualsiasi della nuova vista creata per aprire il menu di contesto; Selezionare New > Chart Cliccare sul bottone (...) per selezionare il nodo e cliccare successivamente su Next Cliccare il bottone Add Counter e selezionare Network Service Performance Counter Selezionare il servizio per il quale creare i cruscotti quindi dalla finestra Counter i contatori; per ogni contatore scelto cliccare su Add Cliccare Close. In Performance Counters saranno mostrate le metriche selezionate Cliccare OK Cliccare con il tasto destro sul cruscotto e selezionare Properties per modificare le proprietà di visualizzazione. Seguono alcuni esempi:

18 Indicatori di statistiche pe MSA AA,AE e AR Vista per il controllo di coerenza dei campi MSH-5 del client con MSH-2 del server. Il supporto per la raccolta degli eventi e delle statistiche della rete fornisce un buon modo per costruire e gestire un archivio a lunga scadenza dei dati per la pianificazione di analisi e capacità. I responsabili della pianificazione delle capacità necessitano di informazioni per supportare decisioni strategiche e di appositi database in grado di fornirle. Il database di NetCrunch 5 è facilmente consultabile con queries personalizzate ed è accessibile per ogni nodo, mappa e per tutto l'atlante di

19 rete; ad esempio per la mappa denominata HIS cliccare con il tasto destro e selezionare Alerting quindi View Map Event Log. Esportare i dati in archivi esterni Una volta che i dati sono memorizzati nel database interno è possibile accedervi per la creazione di reports e per l analisi dell andamento dei parametri; potrebbe essere necessario esportare le informazioni sulle statistiche per l analisi della pianificazione delle capacità con tecniche di previsione come la regressione lineare. Per esportare i dati: Selezionare in Performance View il contatore da esportare Cliccare con il tasto destro sul cruscotto per aprire il menu di contesto relativo Selezionare Export to... Scegliere il tipo di distribuzione e cliccare su Next Se non è definita una connessione cliccare New Connection e completare con i dati di accesso. Confermare con OK Selezionare la stringa di connessione appena creata e cliccare OK Generazione delle reportistica del CUP Per generare la reportistica: Portarsi sulla vista HIS in Atlas Maps Portarsi sul Server CUP ed aprire il menu di contesto con il tasto destro. Selezionare Reporting > Edit Data Collection Policy Portarsi sulla scheda Service & Interface cliccare sul gruppo Network Service Report quindi due volte sul report Selected Service Availability Confermare con Ok Accedere alla reportistica per i nodi abilitati Per accedere ai report: Cliccare il bottone View Reports Portarsi su Node Reports > NetWorks Services Availability e selezionare il report desiderato ( compariranno sotto questa voce i reports abilitati precedentemente). Selezionare un report (es. [HL7] Availability Reports) e cliccare su Generate Reports al centro della pagina. Un diaro degli interventi Una gestione efficente delle attrezzature del reparto di radiologia e di tutti gli altri elementi di una struttura ospedaliera non può prescindere da un'attenta sorveglianza della loro manutenzione, non solo per disporre di apparecchiature che siano sempre in condizioni ottimali ma anche perchè un attenta analisi favorisce in maniera determinante il contenimento della spesa. Per creare un inventario per ogni singolo nodo della rete:

20 Portarsi sul nodo di interesse ed aprire il menu di contesto con il tasto destro del mouse Selezionare la voce Properties Portarsi sulla Scheda Notes e cliccare Add Node per aggiungere una nuova voce all inventario Confermare con OK Il diario del server CUP Personalizzazione delle icone degli apparati ospedalieri Per aggiungere un set di icone personalizzate: Selezionare dal menu Tools > Options Nel riquadro a sinistra portarsi su Map > Icons e cliccare su Add per aggiungere una nuova icona Cliccare OK e confermare. La figura vista in precedenza mostrava una vista con le diagnostiche del reparto di radiologia; sarebbe opportuno monitorare per questi apparati la disponibilità del protocollo DICOM, le statistiche come fatto per il server CUP e tutti gli altri aspetti necessari a garantire il loro funzionamento ottimale. Interpretazione dei risultati I messaggi di TEST MSA AE, MSA AR, MSH-2 Field Error e MSH Missing della scheda Network Services marcati di colore giallo (warning) e con Status Unregonized Response devono essere interpretati dal punto di vista dell amministratore come riscontri positivi. In effetti il servizio è attivo perchè NetCrunch 5 rileva che sulla porta 5000 il server risponde prontamente ma l analsi condotta

21 sulle intestazioni" dei messaggi mostra che gli stessi non coincidono con i patterns preconfigurati; per questo tipo di controlli sarebbe opportuno impostare azioni di notifiche per eventi di tipo Service [nome controllo] is UP come mostrato precedentemente in questo tutorial. Un messaggio correttamente riscontrato (messaggio ACK con campo AA) viene invece mostrato di colore verde con il 100% dei pacchetti ricevuti e senza alcun errore di trasmissione. Il servizio generico HL7 mostra invece il totale del traffico HL7 (ordini, registrazione etc..); la reportistica per questo servizio segnala le disponibilità e le statistiche dei pacchetti inviati, ricevuti, persi, RTT etc.. per ogni interfaccia clinica e può essere spedito regolarmente via . Un caso di Studio <<Netcrunch 5 si è dimostrato uno strumento indispensabile per chi lavora in ambienti di rete complessi quali uno o più ospedali collegati tra loro...>> Bruzzi Stefano Responsabile Integrazione Sistemi Informatici EbitAET Spa L'azienda EbitAET S.p.A. è un'azienda high-tech specializzata nella progettazione e produzione di soluzioni software dedicate alla gestione completa dell'iter diagnostico del paziente. Ha sviluppato un avanzato know how nella gestione ed elaborazione di dati ed immagini medicali, nella distribuzione delle informazioni sul territorio e nell'eliminazione dei supporti cartacei e pellicolari, ottenendo un'ottimizzazione del flusso di lavoro ospedaliero ed una sensibile riduzione dei costi di gestione e di esame. AdRem NetCrunch 5 per monitoraggio di presidi ospedalieri remoti La rete è distribuita su quattro siti ubicati geograficamente in luoghi differenti (Bussana IM, Imperia IM, Sanremo IM, Bordighera IM). I quattro siti sono collegati con rete TELECOM dedicata. All'interno dei siti vi è una LAN mista 100/1000Mb/sec mentre la struttura analizzata è quella della trasmissione di immagini in formato DICOM tra le modalità che le generano per motivi diagnostici e le Workstation che vengono usate per la loro refertazione/diagnosi. All'interno dell'infrastruttura esistono una serie di server che si occupano dell'archiviazione temporanea (server cache) o definitiva (server centrale) delle immagini stesse. SITO DI BUSSANA: 2 servers in configurazione cluster utilizzati come storage 2 servers in configurazione cluster utilizzati per la gestione dei DB 1 server utilizzato per la gestione della distribuzione delle immagini via Web 1 server per la gestione della Tape library. 1 switch Alcatel serie 6xxx per le connessioni in rame e fibra.