USL MODENA by fLr2wX

VIEWS: 20 PAGES: 16

									                                                             Servizio Sistema Informativo Aziendale
                                                               Servizio Ingegneria Clinica


Linee guida sul problema dell’anno 2000

Sommario
LINEE GUIDA SUL PROBLEMA DELL’ANNO 2000 ............................................................................................... 1
     SOMMARIO ...................................................................................................................................................................... 1
     OGGETTO......................................................................................................................................................................... 1
     SCOPO ............................................................................................................................................................................. 1
     STRUTTURA DEL DOCUMENTO ......................................................................................................................................... 2
     RIFERIMENTI ................................................................................................................................................................... 2
     CONTENUTO .................................................................................................................................................................... 3
       Introduzione alla compatibilità Y2K ........................................................................................................................... 3
       Responsabilità Oggettiva ............................................................................................................................................ 3
       Classi di Priorità ........................................................................................................................................................ 4
            Sistema Informativo ...................................................................................................................................................................4
            Apparecchiature Elettromedicali ................................................................................................................................................7
        Piano dei controlli .................................................................................................................................................... 11
            Sistema Informativo .................................................................................................................................................................11
            Apparecchiature Elettromedicali ..............................................................................................................................................11
        Protocollo di test di compatibilità Y2K .................................................................................................................... 12
            Sistema Informativo .................................................................................................................................................................12
               Hardware..............................................................................................................................................................................12
               Applicazioni e Librerie ........................................................................................................................................................12
               Interfacce .............................................................................................................................................................................13
            Apparecchiature Elettromedicali ..............................................................................................................................................14
     ASPETTI ORGANIZZATIVI............................................................................................................................................... 15
     APPENDICE 1 ................................................................................................................................................................. 15
     APPENDICE 2 ................................................................................................................................................................. 16


Oggetto
Il presente documento descrive le linee guida inerenti la compatibilità all’anno 2000
(Y2K) adottate dal Servizio Sistema Informativo Aziendale (SIA) e dal Servizio
Ingegneria Clinica (SIC) della A.U.S.L. di Modena per le attrezzature delle seguenti
categorie:
 sistemi di elaborazione dati, sistemi operativi e software di base, software
   applicativo;
 apparecchiature elettromedicali;
in uso presso gli stabilimenti ospedalieri e i distretti della A.U.S.L. di Modena.


Scopo
      Illustrare al personale tecnico dei Servizi SIA e SIC il concetto di ‘compatibilità
        all’anno 2000’ così come universalmente definito da enti ed organizzazioni
        tecniche del settore.
      Diffondere al personale tecnico dei Servizi SIA e SIC le problematiche ed i rischi
        connessi all’utilizzo di sistemi di elaborazione dati non compatibili all’anno
        2000.
      Definire una serie di linee guida atte a mettere in luce la compatibilità o meno
        all’anno 2000 delle attrezzature appartenenti alle categorie sopra elencate a più
        alto rischio ed individuare i percorsi atti ad evitare che da ciò derivino

                                                                 Azienda USL di Modena
                                             Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
     conseguenze negative (o minimizzare le conseguenze negative) per l’azienda o per
     i pazienti assistiti.
    Informare e formare il personale dell’azienda in merito al problema della 2000
     compatibilità in maniera che esso abbia gli strumenti culturali necessari per
     rapportarsi con le strutture del SIA e del SIC e con il paziente in maniera tale
     da evitare (o minimizzare) gli effetti negativi del “millenium bug”.
   Definire un protocollo standard di test di compatibilità all’anno 2000 da
     utilizzare per le apparecchiature elettromedicali a più alto rischio allo scopo
     di verificarne la potenziale pericolosità.
   Definire la modalità di gestione dei dati raccolti dai test effettuati sulle
     attrezzature biomediche.
    Adottare comportamenti sinergici fra SIA e SIC in merito al problema dell’anno
     2000.


Struttura del documento
Il documento dopo una parte introduttiva riportante l’oggetto della trattazione, i
riferimenti bibliografici, la definizione del problema e i riferimenti normativi in
materia di responsabilità oggettiva, descrive la definizione delle classi di
priorità, il piano dei controlli, e i protocolli di verifica della 2000 compatibilità
distinguendo se applicati al sistema informativo o alle apparecchiature biomedicali.
Il documento poi si chiude con alcune considerazioni comuni di tipo organizzativo
e con alcune appendici ad integrazione del testo.

Riferimenti
Di seguito si elencano alcuni riferimenti bibliografici relativi al problema della
compatibilità anno 2000 nel settore informatico:

   “Millenium BUG, Banca dati dell’informazione, edizione 98/99”, Presidenza del
     consiglio dei Ministri, Comitato anno 2000
   Direttiva Europea 85/374/EEC
    Il       sito        del       Gartner        Group       sull’anno        2000
     http://gartner12.gartnerweb.com/gg/static/itjournal/gspecial1.html
    Il sito della Associazione italiana Ingegneri Clinici http://www.aiic.it
    Microsoft, “CD Anno 2000, Resource Center”, Maggio 1999
    C.Ghezzi, A.Fuggetta, S.Morasca, A.Morzenti, M.Pezzè, “Ingegneria del Software,
     Progettazione, Sviluppo, Verifica”, Mondadori Informatica

Ulteriore materiale


    Microsoft MSDN;
Di seguito si elencano alcuni riferimenti bibliografici relativi al problema della
compatibilità anno 2000 nel settore delle apparecchiature elettromedicali:

   ‘The Y2K date issue starter kit for biomedical engineering departments’ – The
     Institution of Engineers, Australia, Biomedical College.
   ‘Medical Devices and the Y2K Problem’ – ECRI
   Direttiva Europea 85/374/EEC
   Manuale della Qualità del Servizio Ingegneria Clinica della A.U.S.L. di Modena
   Norma UNI-EN-ISO 9002 (’94)
   Norma UNI-EN-ISO 9000 (’94)




                                         Azienda USL di Modena
                   Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                     2/16
Contenuto

Introduzione alla compatibilità Y2K
Il problema anno 2000 (che nella letteratura anglosassone viene identificato con
l’acronimo Y2K – year 2 * 1000) può essere così sintetizzato: l’incapacità di una
attrezzatura (un sistema di elaborazione nelle sue componenti hardware e software
o una attrezzatura biomedica) di poter correttamente gestire le date posteriori al
31/12/1999.

Tali malfunzionamenti si originano principalmente a causa di tre distinti fattori:
1) memorizzazione degli anni a due cifre: in tutti i sistemi in cui gli anni sono
   memorizzati   a   due   cifre    sarà   di   fatto    impossibile   rappresentare
   contemporaneamente date di due secoli diversi;
2) problemi riconducibili ad errati algoritmi di calcolo dell’anno bisestile: un anno
   è bisestile se è divisibile per quattro, non lo è se è divisibile per 100, lo è
   se è divisibile per 400. Pertanto l’anno 2000 è bisestile;
3) uso di date con speciale significato: in alcuni contesti alcune date avevano un
   significato particolare, ad esempio 09/09/99 veniva usata come indicatore
   dell’ultimo record o di data non compilabile, ecc…

Tali considerazioni abbastanza ovvie e scontate per le attrezzature informatiche sono
ormai non di rado applicabili anche alle apparecchiature ellettromedicali.

Ogni apparecchiatura elettromedicale dotata di microprocessore ed operante grazie
ad un software è potenzialmente a rischio di errore o malfunzionamento dovuto al
cambio di data dal 31 Dicembre 1999 al 1 Gennaio 2000.
Tale problema è causato dalle applicazioni software e dai sistemi operativi che
memorizzano le date nel formato GGMMAA (giorno-mese-anno). L’utilizzo delle sole
ultime due cifre dell’anno (AA) può evidentemente condurre ad una errata
interpretazione delle date successive al 31 Dicembre 1999. Ad esempio la data
11-03-2001, memorizzata come 110301, potrebbe essere interpretata dal sistema come
11-03-1901, oppure come 11-03-19X1, dove X è la decade in cui l’apparecchiatura è
stata prodotta.
La gran parte delle apparecchiature elettromedicali attualmente commercializzate e
correntemente in uso è stata progettata con compatibilità Y2K o comunque non è affetta
da tale problema.
Altre, viceversa, potrebbero essere soggette ad errori e malfunzionamenti che, a
seconda della criticità della funzione svolta dall’apparecchiatura, risulterebbero
potenzialmente pericolosi per il paziente.
Le apparecchiature elettromedicali a maggior rischio di malfunzionamento sono quelle
destinate ad operare per un periodo di tempo prefissato, quelle che cessano di operare
in assenza di una manutenzione programmata e della produzione di relativo report,
quelle che registrano data e/o ora di eventi, computano variazioni e/o tendenze sul
periodo, stampano date e/o gestiscono dati storici.

Responsabilità Oggettiva
La Direttiva Europea 85/374/EEC “Responsabilità per danno da prodotti difettosi”,
recepita in Italia con D.P.R. 224/88, sancisce che nel caso di danno cagionato da
un prodotto difettoso la responsabilità ricada sul produttore/importatore, nel caso
di difetto originario, o su soggetti diversi qualora gli stessi abbiano effettuato
installazioni, riparazioni o si occupino della manutenzione del prodotto stesso.
In assenza di autodichiarazioni ufficiali dei produttori e dei fornitori che
certifichino la compatibilità Y2K dei loro prodotti o che comunque ne prevedano
l’aggiornamento, si dovranno adottare specifici comportamenti descritti nella
sezione denominata PIANO DEI CONTROLLI.




                                         Azienda USL di Modena
                   Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                     3/16
Classi di Priorità

Sistema Informativo
Il controllo sistematico di tutti i sistemi di elaborazione e di tutte le applicazioni
sarebbe da un lato impercorribile in termini temporali e di risorse, ma quello che
più importa sarebbe non opportuna.

Assai più ragionevole risulta essere la suddivisione dei sistemi e delle applicazioni
in classi di rischio, in maniera tale da poter definire quali controlli siano
prioritari e quali non prioritari o non necessari.

Una semplice definizione di classi di rischio e priorità può essere la seguente:



 Dispositivi ad        Dispositivi    (sistemi    di    elaborazione    ed    PRIORITÀ
  ALTO RISCHIO         applicazioni) il cui malfunzionamento impedisce,       MASSIMA
                       o comunque rende maggiormente difficoltosa,
                       l’erogazione di attività assistenziali (attività
                       sanitarie). Dispositivi (sistemi di elaborazione
                       ed   applicazioni)    il   cui    malfunzionamento
                       impedisce, o rende maggiormente difficoltose,
                       attività non differibili legate a servizi non
                       strettamente    sanitari    resi    al   cittadino
                       (attività non assistenziali, ma di servizio al
                       cittadino, la cui non erogazione causa disservizi
                       alla   comunità):    ad   esempio    servizio    di
                       prenotazione di prestazioni sanitarie, emissione
                       di certificati e rilascio di copie conformi di
                       documentazione sanitaria, ecc…
  Dispositivi a        Dispositivi    (sistemi     di    elaborazione    e PRIORITÀ MEDIA
  MEDIO RISCHIO        applicativi) il cui malfunzionamento causa
                       problemi che non hanno un impatto diretto
                       all’esterno dell’azienda, ma il cui perdurare può
                       portare ad un blocco della attività nel suo
                       complesso (compresa l’attività ricompresa nel
                       punto precedente). Rientrano in questa categoria
                       i sistemi e le applicazioni dei servizi di
                       supporto ed amministrativi (compresi i servizi
                       tecnici).
  Dispositivi a        Dispositivi    (sistemi     di    elaborazione    e PRIORITÀ MINIMA
  BASSO RISCHIO        applicazioni) il cui malfunzionamento non entra
                       nelle    due    categorie      precedenti.     Tali
                       malfunzionamenti tipicamente portano ad una
                       perdita complessiva di efficienza nei processi
                       aziendali, ma non ad un blocco della attività.
                       Rientrano in questa categoria gli applicativi di
                       tipo personale, i sistemi e le applicazioni non
                       essenziali.

Una classificazione di massima delle classi di rischio, comunque modificabile e/o
integrabile, è la seguente:

ALTO RISCHIO                        MEDIO RISCHIO                              BASSO RISCHIO




                                           Azienda USL di Modena
                     Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                       4/16
Sistemi ed applicazioni di supporto          Sottosistemi di rilevazione della
alla attività assistenziale: Anagrafe        attività resa (esclusa la parte di
degli assistibili e gestione della           gestione della refertazione già
Medicina di base, gestione movimento         ricompresa nella parte ad alto rischio),
degenti, gestione cartella clinica,
gestione sottosistemi diagnostici (parte
di refertazione esclusa la rilevazione
dell’attività resa), gestione di reparti e
servizi particolari (ad esempio
gestione di centro trasfusionale ed
emoteca, SERT, ecc…, la cui gestione
prevede prassi organizzative
particolari e talvolta somministrazioni
ai pazienti), Pronto Soccorso e
gestione delle chiamate in emergenza
(esempio gestione 118, gestione mezzi
di soccorso, ecc…), Gestione sale
operatorie e registro di sala operatoria,
                                                                                        Applicativi di tipo personale:
                                                                                        documenti di tipo personale che
                                                                                        utilizzino date, comprese piccole
                                                                                        banche dati, creati e gestiti con
                                                                                        strumenti di produttività personale
Sistemi ed applicazioni di sportello:
Centro Unificato di Prenotazione,
Sottosistemi di certificazione
(accettazioni amministrative per la
parte di rilascio di certificati e copie
conformi), Sottosistemi informativi
per il paziente (gestione dei ricoverati
di supporto alle portinerie e alle
direzioni sanitarie)
Sottosistemi che gestiscono                                                             Applicativi per il supporto
interscambi informativi con                                                             decisionale e DataWarehouse (se
l’esterno (ad esempio comunicazione                                                     non coinvolti nella fornitura di dati
delle schede nosologiche e prestazioni                                                  all’esterno dell’azienda);
ambulatoriali che vanno in
compensazione, e debiti informativi
regionali in genere)
Sottosistema di gestione degli
accessi e delle abilitazioni
                                             Sottosistemi di supporto ai servizi
                                             tecnici (gestione delle chiamate di
                                             intervento, Help Desk, …)
Gestione dell’assistenza domiciliare                                                    Gestione dell’assistenza domiciliare
(gestione dei dati sanitari e pagamento                                                 (gestione dei dati di attività )
dei medici di base)
Farmaceutica convenzionata (parte            Farmaceutica convenzionata (parte
che garantisce il pagamento alla             di rendicontazione della spesa)
farmacie convenzionate)
Gestione Protesica e Integrativa
Gestione consultori e screening
Gestione del Personale (trattamento          Gestione del Personale (stato
economico e rilevazione                      matricolare, pianta organica)
presenza/assenza)
Gestione Magazzino (procedura                Gestione Magazzino (gestione degli         Gestione Magazzino (funzioni di
ordini)                                      articoli di magazzino)                     inventario e scarico di dati alla
                                                                                        contabilità)


                                                 Azienda USL di Modena
                           Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                              5/16
Gestione Farmacia Interna                                                          Gestione Farmacia Interna (
(procedura ordini, gestione degli                                                  funzioni di inventario e scarico di dati
articoli di magazzino)                                                             in contabilità)
                                                                                   Gestione del patrimonio aziendale e
                                                                                   degli inventari
Sistema Informativo contabile e di
ragioneria
Gestione URP
                                        Gestione protocollo e delibere
Sottosistema di gestione del
Dipartimento di prevenzione
Sottosistema di gestione dei Servizi
Sociali (erogazione rette, sussidi,
ecc…)

L’elenco riportato va inteso semplicemente come indicativo della tipologia di sistema
e applicazione.

Nell’ambito degli interventi di verifica della 2000 compatibilità è bene operare una
distinzione fra gli applicativi multiutente e applicativi monoutente. Posto che gli
uni sono del tutto simili agli altri, in tema di 2000 compatibilità, assai diverso
risulta essere l’approccio organizzativo necessario per l’adeguamento. Infatti se
da un lato le applicazioni multiutente sono quasi sempre censite, catalogate per tipo
e caratteristiche e quasi sempre gestite da personale apposito normalmente afferente
ai CED, le applicazioni monoutente raramente sono così puntualmente catalogate e
ancora più raramente sono direttamente gestite dai CED.

Un’altra caratteristica particolarmente importante ai fini della 2000 compatibilità
delle applicazioni multiutente è che esse normalmente vengono eseguite su di un server
piuttosto che sul client. Vale quindi la pena di porre la seguente definizione:

si   definisce server centrica una applicazione che:
    viene eseguita sul server e acceduta da stazioni in emulazione terminale;
    oppure viene eseguita in ambiente Windows NT Terminal Server;
    oppure è un applicativo INTERNET o INTRANET la cui logica risiede sul server;
    oppure è un applicativo client/server a logica tripartita.

NOTA BENE: gli applicativi server centrici vengono eseguiti sul server e pertanto
non sono influenzati dalla non 2000 compatibilità del client.

In conclusione, per giungere ad una corretta assegnazione dispositivo classe di
priorità si faccia uso del seguente diagramma di flusso:




                                               Azienda USL di Modena
                         Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                           6/16
                 Diagramma di flusso per l’attribuzione della priorità di intervento
                              in applicazioni non server centriche
          Nota bene: si considerano solo applicativi certificabili 2000 compatibili o non 2000 compatibili,
          nel caso il fornitore non sia in grado di fornire tale certificazione sarà bene considerare:
          • non 2000 compatibili i programmi di alto e medio rischio;
          • compatibili i programmi di basso rischio che abbiano superato i test di 2000 compatibilità;
          • non compatibili i programmi di basso rischio che non abbiano superato i test.



                                             NO
                                                       Il sistema o applicativo sarà
                                    Stop                       in uso nel 2000
                                                                                                             Massima priorità



                                                                                                                       NO



                                                                                          SI
                                                      L’applicativo rientra in quelli                 L’applicativo è certificato 2000
                                                           di massimo rischio                                  compatibile



                                                                       NO                                               SI



                                                                                                          L’hardware su cui gira
         L’applicativo è certificato 2000             L’applicativo rientra in quelli
                                                                                                           il programma è 2000
                  compatibile                               di medio rischio                   SI                                        NO
                                                                                                                compatibile
    NO


                           SI                                                             Stop


             L’hardware su cui gira         SI                                                                                           NO
                                                      L’applicativo rientra in quelli                 L’applicativo è certificato 2000
              il programma è 2000
                                                            di basso rischio                                   compatibile
                   compatibile


                                                                                                                        SI
                          NO


                                                                                                 SI       L’hardware su cui gira
                                            Stop                                        Stop               il programma è 2000
                                                                                                                compatibile



                                                                                                                       NO


                 Media priorità                                                                               Bassa Priorità




Apparecchiature Elettromedicali

Lo sforzo richiesto per il controllo della compatibilità Y2K di tutte le
apparecchiature eletromedicali in uso nella A.U.S.L. di Modena è ovviamente non
                                                      Azienda USL di Modena
                                Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                                     7/16
sostenibile dal SIC. Assai più ragionevole risulta la suddivisione delle
apparecchiature in classi di rischio, identificando le necessità e le priorità dei
controlli.
Riferendoci a quanto già disponibile nella bibliografia mondiale viene qui illustrata
una semplice definizione di classi di rischio e priorità:



 Dispositivi ad ALTO RISCHIO             Dispositivi di supporto                     PRIORITÀ MASSIMA
                                         alla vita, rianimazione,
                                         monitoraggio critico o
                                         che comunque arrecano un
                                         grave danno al paziente
                                         in         caso        di
                                         malfunzionamento
 Dispositivi a MEDIO RISCHIO             dispositivi     con    un                       PRIORITÀ MEDIA
                                         significativo impatto ma
                                         che non arrecano un danno
                                         immediato al paziente in
                                         caso di malfunzionamento
 Dispositivi a BASSO RISCHIO             dispositivi che, anche in                       PRIORITÀ MINIMA
                                         caso                   di
                                         malfunzionamento,     non
                                         hanno un serio impatto
                                         sul paziente




                                        Azienda USL di Modena
                  Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                    8/16
Per giungere ad una corretta assegnazione dispositivo classe di priorità si faccia
uso del seguente diagramma di flusso:



                                    Il dispositivo sarà
                   NO
                                     in uso nel 2000?




                                                SI


                                       Il dispositivo             SI
                                        calcola età,
                                        tempi,etc.?



                                                 NO


                                       Il dispositivo             SI
                                     registra dati del
                                         paziente?




                                                NO


                                       Il dispositivo             SI
                                    riceve dati da altri
                                          sistemi?



                                                NO


                                    L'anno può essere
                                                                  SI
                                    immesso con due
                                          cifre?




                                                NO

                                                           SI           Il dispositivo ha
                                                                        meno di 3 anni?




                                                                                  NO




                                     Il dispositivo è di
                                    supporto alla vita,                SI             MASSIMA
                                  essenziale alla cura, di                            PRIORITA'
                                      monitoraggio,...



                                                 NO



                                     Il dispositivo è a            SI
                                      medio rischio?
                                                                                       MEDIA
                                                                                      PRIORITA'


                                                 NO
                                                                                       MINIMA
                                                                                      PRIORITA'




                                       Azienda USL di Modena
                 Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                           9/16
Una classificazione di massima delle classi di rischio, comunque modificabile e/o integrabile, è la seguente:

ALTO RISCHIO                             MEDIO RISCHIO                              BASSO RISCHIO
Unità di anestesia e vaporizzatori       Spettrofotometri                           Audiometri
Ventilatori da anestesia                 ECG e scanners ambulatoriali               Unità di diatermia
Glucometri                               Unità di plasma-aferesi
Sistemi di brachiterapia                 Flussimetri
Defibrillatori                           Emoanalizzatori di gas/pH
Diagnostiche radiologiche                Misuratori di flusso cardiaco (cardiac
(TAC,RMN,PET)                            output)
Monitor fetali                           Dispositivi di laboratorio clinico
                                         (analizzatori di cultura,spettrometri di
                                         massa,…)
Macchine cuore-polmone                   Sistemi di topografia corneale
Unità di emodialisi                      Sistemi di gestione dei dati
Sistemi di videolaparoscopia             Elettrocardiografi ,holters, anche in
                                         telemetria
Pompe infusione                          Elettroencefalografi
Acceleratori lineari                     Elettromiografi
Sistemi di medicina nucleare             Elettro-oculografi
Unità di dialisi peritoneale             Analizzatori di motilità esofagea
Monitors                                 Potenziali evocati
Unità radiografiche                      Citometri
Monitors O2,CO2 transcutanei             Sistemi informativi
Ventilatori polmonari                    Stampanti laser/film radiologiche
                                         Sistemi di archivazione/gestione delle
                                         immagini radiologiche
                                         Simulatori di radioterapia
                                         Ecografi e scanners ad ultrasuoni
                                         Sistemi di misura urodinamica
                                         Sistemi di videoendoscopia




L’elenco indicato è puramente indicativo e sicuramente non esaustivo. Eventuali modifiche ed integrazioni andrebbero
apportate utilizzando il metodo illustrato nel diagramma di flusso.




                                                Azienda USL di Modena
                          Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                           10/16
Piano dei controlli

Sistema Informativo

Possibili categorie di sistemi:
 Sistemi e applicativi compatibili (certificati dal fornitore);
 Sistemi e applicativi non compatibili (sui quali è stata condotta dal fornitore
   o da altri almeno un test con esito negativo), ma con problemi accettabili di
   funzionamento (secondo quanto dichiarato dal fornitore);
 Sistemi e applicativi non compatibili (sui quali è stata condotta dal fornitore
   o da altri almeno un test con esito negativo);
 Sistemi e applicativi in fase di test;
 Sistemi e applicativi non testati.

Un sistema (o un applicativo) si dice compatibile quando certificato da chi ne ha
curato il progetto e la realizzazione. Da ciò consegue che per tutti gli applicativi
e i sistemi commerciali la certificazione può essere fornita solo dal fornitore. Non
è infatti pensabile che le aziende siano in grado di effettuare un test funzionale 1
sufficientemente accurato da garantire il buon funzionamento di un sistema o di un
applicativo in tutte le possibili condizioni operative: di conseguenza
l’utilizzatore non è in grado di garantire la 2000 compatibilità attraverso test
diretti. I test condotti dall’Azienda USL possono tuttavia consentire di verificare
la NON COMPATIBILITÀ di determinate attrezzature: in quanto il non superamento anche
di un solo test può attestare la NON 2000 COMPATIBILITÀ.

Pertanto l’azienda USL di Modena eseguirà test di compatibilità solo per quei sistemi
per i quali non sia possibile reperire una adeguata documentazione o per i quali esista
un ragionevole dubbio che la certificazione del fornitore sia non corretta.

Inoltre l’azienda USL, qualora possibile, effettuerà delle simulazioni, fuori linea2,
di buon funzionamento di sistemi e applicativi.


Apparecchiature Elettromedicali
Il controllo di compatibilità Y2K è da ritenersi come necessaria integrazione dei
normali controlli di sicurezza elettrica e funzionalità e potrà essere effettuato
contestualmente a questi oppure nell’ambito di qualsiasi altro intervento.
Il piano dei controlli dovrebbe includere tutti i dispositivi privilegiando
cronologicamente, ove possibile, quelli appartenenti alla classe di priorità
massima.
Tra i dispositivi elettromedicali appartenenti alla classe di priorità più elevata,
si consiglia di controllare tempestivamente quelli sottoposti a contratto di
manutenzione esterna o sotto garanzia con scadenza entro il 31/12/1999; nel caso di
incompatibilità Y2K sarà più semplice ed economico richiedere alla ditta manutentrice
od al costruttore gli eventuali aggiornamenti nell’ambito del contratto vigente.


1
  “I criteri di test funzionali permettono di derivare dati di test a partire da
specifiche del programma, a prescindere dal codice: il programma è visto come una
scatola nera, di cui sono visibili i risultati dell’esecuzione per particolari dati
di ingresso, ma di cui si ignora la struttura o comunque qualsiasi informazione sul
codice che possa essere usata per derivare dati di test: per questo motivo i test
funzionali sono anche detti a scatola nera (Black box)” Tratto da “Ingegneria del
Software, Progettazione, Sviluppo, Verifica”, pag. 333.
2
  Tutti i test di compatibilità vanno condotti non su sistemi in produzione, quindi
o su sistemi “gemelli” in ambiente di prova, o sui sistemi reali ma in condizioni
di test, quindi su dati non reali.
                                            Azienda USL di Modena
                      Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                       11/16
Per dispositivi identici, ovvero stesso costruttore, stesso modello, stessa versione
software (quando identificabile), è sufficiente testare un solo dispositivo.
Il risultato di ogni test verrà raccolto in un unico elenco costantemente aggiornato
e disponibile per tutte le unità operative del Servizio al fine di evitare inutili
duplicazioni di controlli su apparecchiature identiche.
Ogni test, eseguito con il protocollo di seguito illustrato, richiederà al massimo
20 minuti di tempo.

Protocollo di test di compatibilità Y2K

Sistema Informativo

Livelli di criticità di un sistema di elaborazione:
1) Hardware;
2) Sistema Operativo;
3) Librerie di Runtime;
4) Applicazioni;
5) Programmi ah hoc;
6) Interfacce fra i sistemi.


Hardware
Problemi hardware: i problemi hardware più noti e conosciuti sono i problemi di BIOS.
Tali inadeguatezze sono in qualche modo compensate dai più recenti sistemi operativi:
Windows NT 3.51(sp5), Windows NT 4.0, Windows 98 e Windows NT 5.0. Sui sistemi nei
quali siano impiegati tali sistemi operativi è sufficiente verificare se la eventuale
non compatibilità del BIOS viene compensata dal sistema operativo.

Nei sistemi in cui non vengano utilizzati tali sistemi operativi occorre verificare
la compatibilità anno 2000 dell’hardware. Sui personal computer la componente più
critica è il BIOS. Fortunatamente con un numero sufficientemente delimitato di prove
può essere verificata la compatibilità di questo componente.

Prove da effettuare sul BIOS:
1. Effettuare un salto di data dal 31/12/1999 23:59:59 mediante roll over del BIOS;
   Verificare se la data di arrivo è Sabato 01/01/2000. Verificare tale comportamento
   sia a PC acceso che a PC spento.
2. Effettuare un salto di data dal 31/12/2000 23:59:59 mediante roll over del BIOS;
   Verificare se la data di arrivo è Domenica 01/01/2001. Verificare tale
   comportamento sia a PC acceso che a PC spento.
3. Effettuare un salto di data dal 28/02/2000 23:59:59 mediante roll over del BIOS;
   Verificare se la data di arrivo è Martedì 29/02/2000. Verificare tale
   comportamento sia a PC acceso che a PC spento.
4. Effettuare da DOS un date 01/01/2000; spegnere e riaccendere il PC e verificare
   se la data è stata mantenuta.
5. Impostare un giorno qualsiasi successivo al 29 Febbraio 2000 e verificare che il
   giorno della settimana segnalato sia coerente (per esempio il 30 Ottobre 2000 è
   un Lunedì).


Applicazioni e Librerie
La compatibilità 2000 delle applicazioni è accertabile, in linea generale, solamente
dal progettista e realizzatore delle stesse. Non è infatti individuabile una serie
delimitata di test che dia la garanzia di compatibilità in ogni condizione di
funzionamento.
Pertanto l’azienda USL dovrà procedere ad un CONTROLLO DOCUMENTALE di tutte le
procedure in uso: questo significa che dovrà reperire presso il fornitore (o
rivenditore) la necessaria documentazione che attesti la compatibilità o meno della
procedura.

                                            Azienda USL di Modena
                      Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                       12/16
Nei casi in cui non sia possibile recuperare tale documentazione si decide di adottare
un comportamento prudenziale riassunto nelle seguenti regole:
 si considerano NON 2000 COMPATIBILI i programmi di alto e medio rischio, di cui
   non sia stato possibile reperire la documentazione di compatibilità;
 si considerano 2000 COMPATIBILI gli applicativi a basso rischio che abbiano
   superato i test di 2000 compatibilità, NON COMPATIBILI gli altri.

Le applicazioni autocostruite internamente all’azienda vanno certificate tenendo
conto delle seguenti considerazioni:
 alcune applicazioni possono gestire un calendario interno, che può fare assunzioni
   non corrette sulle date, ad esempio può sbagliare a calcolare gli anni bisestili;
 l’applicativo deve usare date a 4 cifre;
 se l’applicativo consente l’immissione di date a 2 cifre, devono comunque essere
   gestite internamente a 4 cifre e devono essere validati gli algoritmi che da due
   cifre inferiscono il secolo di appartenenza;
 devono essere verificati gli algoritmi di calcolo degli anni bisestili;
 occorre verificare che non vengono usate date per usi specifici e con significati
   particolari;
 occorre verificare che il programma consenta l’utilizzo di date superiori al 2000,
   indicativamente almeno fino al 2035.

Per una più approfondita analisi del tema si veda anche l’appendice (1).

Tali verifiche possono normalmente esser condotte solo per ispezione diretta del
codice sorgente e delle banche dati utilizzate.

Per le librerie di RUNTIME valgono considerazioni del tutto analoghe alle
applicazioni: occorre che il fornitore certifichi la 2000 compatibilità delle stesse
e qualora non fosse possibile reperire tale documentazione dovranno essere fatte le
valutazioni prudenziali di cui sopra.

La 2000 compatibilità dell’applicativo è normalmente solo condizione necessaria ma
NON SUFFICIENTE a garantire la 2000 compatibilità della soluzione informatizzata nel
suo complesso: questo significa che un applicativo 2000 compatibile se eseguito su
un sistema di elaborazione NON 2000 COMPATIBILE può presentare problemi. Pertanto
andrà verificata contestualmente anche la 2000 compatibilità del sistema di
elaborazione.

Interfacce
Si definiscono interfacce i punti di confine di un sottosistema informatico
attraversati da flussi informativi. Saranno interfacce esterne quelle poste sul
confine aziendale, interne quelle poste fra un sottosistema e l’altro all’interno
del confine aziendale.

Occorre verificare che i dati scambiati attraverso le interfacce non inficino la 2000
compatibilità del sistema.

Alcune regole di tipo generale per il controllo dei dati scambiati sono le seguenti:
 il sistema inviante i dati deve essere certificato 2000 compatibile;
 qualora vengano scambiati dati che riportano date queste devono avere l’anno
   rappresentato a 4 cifre;
 non devono essere scambiate date per usi specifici e con significati particolari,
   ma devono essere previsti opportuni campi informativi in grado di codificare in
   maniera opportuna tali informazioni.




                                        Azienda USL di Modena
                  Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                   13/16
Apparecchiature Elettromedicali
Il test di compatibilità Y2K consiste nelle 8 prove da eseguirsi con l’ordine di
seguito illustrato:

1. Passaggio al 2000 / Acceso – (PY2K/on)
         Impostare l’ora alle 23:59 del 31 Dicembre 1999 ed attendere il passaggio
         al 2000 con il dispositivo acceso. Controllare che la data venga aggiornata
         correttamente. Per dispositivi che lo consentano verificare anche il
         salvataggio di files/dati e la correttezza del loro ordinamento nonché il
         funzionamento di eventuali accessori connessi al dispositivo.

2. Mantenimento della data 2000 allo spegnimento – (MY2K)
         Spegnere il dispositivo dopo aver effettuato la prova precedente. Attendere un minuto e riaccenderlo.
         Verificare che la data mantenuta sia 2000. Alcuni dispositivi potrebbero ritornare a date quali il 1980 o il
         1990; in tale caso reimmettere la data 2000 e ripetere la prova.

3. Passaggio al 2000 / Spento – (PY2K/off)
         Impostare l’ora alle 23:58 del 31 Dicembre 1999 e spegnere il dispositivo.
         Attendere almeno 3 minuti e riaccenderlo. Verificare che il dispositivo
         segnali uno o due minuti dopo la mezzanotte di Sabato, 1 Gennaio 2000 (alcuni
         dispositivi segnalano il 4 Gennaio 1980).

4. Bisestile – (BISE)
         Impostare l’ora alle 23:58 del 28 Febbraio 2000. Attendere 3 minuti e
         verificare il corretto passaggio al giorno successivo Martedì, 29 Febbraio
         2000 (alcuni dispositivi non riconoscono l’anno bisestile e segnalano il
         Martedì, 1 Marzo 2000).

5. Settimanale – (SETT)
         Impostare un giorno qualsiasi successivo al 29 Febbraio 2000 e verificare
         che il giorno della settimana segnalato sia coerente (per esempio il 30
         Ottobre 2000 è un Lunedì).

6. Passaggio al 2001 / Acceso – (PY2K1/on)
         Impostare l’ora alle 23:59 del 31 Dicembre 2000 e osservare il corretto
         passaggio al 2001 (il 01-01-2001 è un Lunedì.

7. Passaggio al 2001 / Spento – (PY2K1/off)
         Impostare l’ora alle 23:58 del 31 Dicembre 2000 e spegnere il dispositivo.
         Attendere almeno 3 minuti e riaccenderlo. Verificare che il dispositivo
         segnali uno o due minuti dopo la mezzanotte di Lunedì, 1 Gennaio 2001.

8. Date critiche – (DATE)
         Impostare successivamente le seguenti date critiche: 01/01/1999, 09/09/1999, 31/12/1999, 31/12/2000.
         Verificare che il dispositivo funzioni, per ognuna di esse, correttamente.
Il dispositivo oggetto del controllo di compatibilità Y2K non deve essere connesso
                                  in alcun modo al paziente.

L’esito positivo di tutte le prove consente di poter ragionevolmente dichiarare un
dispositivo ‘Y2K-compatibile’.
L’esito negativo di una o più prove può evidenziarsi con effetti catastrofici
(completa perdita di funzionalità del dispositivo), o con effetti più o meno rilevanti
(perdita parziale della funzionalità di un dispositivo).
L’esito di ogni prova va registrato nella apposita scheda fornita in allegato. In
essa è doveroso includere i seguenti dati:
       Data del test
       Produttore del dispositivo controllato
       Modello
       Tipo (es. Pompa infusione, Ventilatore polmonare,…)
                                              Azienda USL di Modena
                        Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                         14/16
         Versione del software (se disponibile dal visualizzatore o dal manuale
           d’uso)
         Esito delle singole otto prove
         Eventuali commenti sul funzionamento del dispositivo controllato (es.
           effetto catastrofico, funzionalità parziale,…)
         Codice del tecnico (TCL/TL) che ha eseguito i tests (in calce alla scheda)

Periodicamente le schede saranno ritirate per essere analizzate e per poter
eventualmente    ricorrere    a   provvedimenti    correttivi    sui    dispositivi
Y2K-incompatibili. Inoltre i dati contenuti nelle schede saranno resi di comune
accesso a tutte le unità operative tramite un unico elenco dei dispositivi testati.

Aspetti Organizzativi

Il problema della 2000 compatibilità coinvolge tante e tali verifiche da non poter
essere gestito in maniera completamente centralizzato e demandato unicamente ad un
ristretto gruppo di persone. Occorre che le varie strutture organizzative prendano
coscienza del problema (attraverso adeguati percorsi di formazione e informazione)
in maniera tale da poter operare tutte le misure organizzative necessarie quale
necessario complemento alla attività tecnica condotta dal personale specializzato
dei servizi deputati (SIA, SIC, altri Servizi tecnici, fornitori, ecc…).

A tal fine occorre predisporre le seguenti misure organizzative:

1) creazione di un gruppo di analisi (che il 31/12/99 e per un breve periodo del 2000
   si trasforma in un gruppo di crisi): definisce le linee guida in merito alle
   problematiche tecniche e organizzative; compito del gruppo è anche quello di
   produrre documenti di facile e rapida consultazione che favoriscano
   l’informazione degli utenti (intesi sia come utilizzatori del sistema
   informatico, che come pazienti che accedono ai servizi della azienda); tale gruppo
   riferisce direttamente al Direttore Generale in merito alle questioni strategiche
   di 2000 compatibilità; in tale gruppo devono essere rappresentate almeno le
   seguenti figure:
             rappresentante della Direzione Sanitaria aziendale;
             rappresentante della Direzione Amministrativa;
             rappresentante del SIA;
             rappresentante del SIC;
             rappresentante del SAT (Servizio Attività Tecniche);
             rappresentante del Servizio Legale;
             rappresentante dell’Economato/Provveditorato;
             rappresentante della Direzione Sanitaria di Presidio;
             rappresentante dei Distretti.

2) individuazione dei referenti anno 2000 nell’ambito delle principali strutture
   organizzative: tali figure fungono da referenti organizzativi presso le strutture
   e curano la predisposizione dei piani di contingenza da applicare nel caso di
   problemi sul sistema informatico e più in generale in caso di disastro (gestione
   delle problematiche di “Disaster Recovery”); tali figure sono anche responsabili
   della formazione/informazione degli utenti delle unità organizzative di
   pertinenza; i referenti riferiscono in merito alle questione di 2000 compatibilità
   e di recupero da disastro ai propri responsabili di struttura e al gruppo di
   analisi.

Appendice 1
Nel seguito, a titolo esemplificativo, viene riportato l’elenco dei test proposto
da Microsoft per la verifica di 2000 compatibilità degli applicativi.


                                         Azienda USL di Modena
                   Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                    15/16
Test Verification List:
In general there are some areas to consider when testing the Year 2000:
        When testing a platform verify its handling of BIOS errors related to the year 2000. Verify year
display in each decade of 2000-2099. If it knows time zones, verify operation when UTC is a different century
than local time (both + and - from UTC).
        Test an application with 2-digit date entry and 2-digit date display both before 2000 and after. And
when the entry / display is a date in the other century, both before and after.
        Verify entry / display of 4-digit dates.
        Verify sorting of dates where some are before 2000, some after.
        Verify day-of-week before 2/29/00, on 2/29, and after. On 2/1/01.
        Does your program do any "year ahead" calculations? Testing in 1999 may be critical.
        What happens if you're networked to a machine with the wrong year? Or different time zone?
        Can you backup before 2000 and restore afterwards?
        Do you ever select a date range? Can the range cross 2000?
        Did any previous version of the program store data in a file format where 00 or 99 meant something
special (e.g. never expire?)
        Find the limits to the date values the program accepts.
        Determine the special test issues for your product (long list).

Dates to verify:
Hardware and Software:
12/31/98,1/1/99,12/31/99,1/1/2000,2/28/2000,2/29/2000,3/1/2000
Applications:
12/31/98,1/1/99,1/4/99,9/9/99,12/31/99,1/1/2000,1/2/2000,1/3/2000,1/4/2000,1/5/2000,1/31/2000,2/28/2000,
2/29/2000,3/1/2000,3/31/2000,10/10/2000,1/2/2001
Additional Dates to consider:
10/1/1999: First day of fiscal year 2000 [for many including the US Government].
1/0/2000: To ensure this date is NOT processed [some spreadsheets and database applications do have this
problem and count January 0 as a day before the 1st]
1/10/2000: First 7 or 8 character date in YYY/M/DD format (2000/1/10 or 2000/01/10)
2/30/2000 and 2/31/2000: To ensure that this date is NOT processed [found in some PC applications]
10/10/2000: First 8 character date using a 2-digit month (2000/10/10)
December 31, 2000: 366th day of the year 2000. This could be a problem for systems that use Julian dates.
1/1/2001: First day in the 21st Century. This is the last leap year related date, testing the first day of January
2001 to ensure it can be set. Overflow for Tandem systems
1/1/2002: Or any other date past this day, to ensure no processing errors occur in backward calculations and
processing of dates in the 1980s and 1990s at this point in time
2/29/2001: To ensure that this date is NOT processed as a leap year
2/29/2004: To ensure that this date is processed as a leap year


Appendice 2
   3R02TY2K - Scheda di registrazione dei tests di compatibilità Y2K
   3E02TY2K   -  Elenco   dispositivi   già  testati   alla   compatibilità                                Y2K
     (Year_2000_Compliance_Testing)




                                              Azienda USL di Modena
                        Servizio Sistema Informativo Aziendale – Servizio Ingegneria Clinica
                                                         16/16

								
To top