Contratto di fornitura di beni e servizi

AZIENDA OSPEDALIERA REGIONALE “SAN CARLO”

Via Xxxxxx Xxxxxxx – 85100 Potenza Telefono 0000000000 – Fax 0000000000

e-mail: xxxxxxxxxxxx@xxxxxxxxxxxxxxxx.xx Codice Fiscale e Partita IVA – 01186830764

Contratto ad esecuzione periodica e continuativa

Contratto di fornitura di beni e servizi

PROCEDURA APERTA PER TRE ANNI

PER LA FORNITURA DI UN SISTEMA INTEGRATO

DI ELETTROCARDIOGRAFIA DIGITALE PER L’A.O.R. “SAN CARLO”

ALLEGATO N. 1

CONFIGURAZIONE E CARATTERISTICHE TECNICHE, OPERATIVE E FUNZIONALI MINIME DEL SISTEMA

SOMMARIO

CONTESTO DEL PROGETTO 3

SPECIFICHE SULLE COMPONENTI DELLA FORNITURA 3

. Architettura generale del Sistema 3

. Stazioni di visualizzazione e refertazione 3

. Il Sistema di gestione degli esami 4

. Il Sistema CIS 5

. Integrazione CIS – Cardiografia 6

. Integrazione con gli altri applicativi aziendali 6

. Reti LAN e WAN – Connettività dei Sistemi 6

. Caratteristiche del Sistema server 7

. Attrezzature diagnostiche cardiologiche 7

. Conservazione sostitutiva, servizi di firma digitale e marcatura temporale 10

. Integrazione con la rete di emergenza/urgenza 11

. Telecardiologia 11

. Le licenze software 11

APPENDICE A 12

Scopo del documento 12

Specifiche di comunicazione: flussi di scambio dati 12

HL7 : Messaggistica utilizzata 13

Tavola Abbreviazioni 14

Data Types 15

Livelli ed ID 16

Message Control 17

Vincolo sui caratteri 17

Gestione di una richiesta di prestazione 17

Registrazione prenotazione / accettazione 18

Il segmento MSH 18

Il Segmento ORM 18

Cancellazione/aggiunta/modifica di un esame 23

Aggiornamento della richiesta da servizio 23

ORM^O01 – Esame Eseguito 23

ORM^O01 – Cancellazione di una Prestazione 25

ORM^O01 – Creazione di una nuova impegnativa

per aggiunta di una Prestazione 27

ORU^R01 – Invio del Referto 28

CONTESTO DEL PROGETTO

In Appendice al presente vengono riportati i dati utili per l’elaborazione e il relativo dimensionamento del Progetto.

Le Ditte partecipanti potranno acquisire ulteriori informazioni in relazione alla configurazione ed alle caratteristiche del Sistema Informativo Ospedaliero e dei suoi applicativi (configurazione ed architettura, progetti RIS-PACS Regionale, Sistema angiografico, LUMIR, CUP, ADT, etc.) presso l’Azienda Ospedaliera Regionale “San Carlo” - U.O. S.I.O.; inoltre, per le specifiche relative al Fascicolo Sanitario Elettronico, occorre far riferimento alla documentazione prodotta dal Tavolo di Sanità Elettronica – TSE.

In ogni caso deve essere previsto nel progetto ogni onere relativo ad eventuali adeguamenti del Sistema perché esso risulti rispondente ai requisiti e alle specifiche in via di definizione da parte del Ministero e del Garante in tema di Fascicolo Sanitario Elettronico.

SPECIFICHE SULLE COMPONENTI DELLA FORNITURA

. Architettura generale del Sistema

Il Sistema in rete si compone di stazioni di lavoro (client) con Sistema operativo Microsoft Windows che si avvalgono di un server di rete attraverso una rete locale/geografica.

Al server fanno riferimento tutti i client e le unità elettrocardiografiche con modalità WEB, terminal server o client server.

Oltre alle apparecchiature cardiografiche il Sistema deve essere aperto alla gestione di altre informazioni cardiologiche (interventistica e diagnostica) e cardiografiche rivenienti da prove da sforzo, holter e altre immagini gestite anche attraverso l’implementazione di una interfaccia DICOM 3.0.

Il workflow supportato dal Sistema deve consentire al medico dalla sua postazione di refertazione di ricevere le informazioni rivenienti dalle diagnostiche, refertarle, utilizzando tutti gli strumenti di ausilio alla refertazione messi a disposizione dal Sistema e rinviarli al mittente o ad altro Sistema, previa firma elettronica.

Tramite il Sistema dovrà essere possibile gestire anche i tracciati effettuati a distanza collegati con la cardiologia via rete locale/geografica.

. Stazioni di visualizzazione e refertazione

Per le Stazioni di visualizzazione si dovranno utilizzare i computer già in dotazione alle diverse Unità Operative integrati di eventuale ogni ausilio hardware e software ritenuto necessario.

Per ciò che riguarda il software per la visualizzazione, per ogni Unità Operativa dovranno essere previste almeno 3 licenze per il reparto ed 1 licenza per ogni ambulatorio.

Per motivi legati all’uso di particolari stazioni di lavoro per rispondere, ad esempio, a specifiche esigenze di refertazione, le Ditte dovranno offrire apposite stazioni di lavoro comprensive di stampante su carta comune che rispondano a tali esigenze.

Esse non potranno essere in numero inferiore a 16 (reparti cardiologici e ambulatori). Eventuali offerte in aumento verranno valutate in sede di istruttoria tecnica.

In ogni caso e con specifico riferimento al software, il numero delle stazioni di refertazione previste potrà essere ampliato dall’Azienda fino al doppio delle stazioni offerte in sede di gara.

Il software di visualizzazione dovrà consentire al minimo:

• di aprire e visualizzare in contemporanea più referti e relative immagini dello stesso paziente;

• di formattare ed effettuare la stampa degli ECG su carta comune;

• di stampare il referto;

Il software di visualizzazione e refertazione dovrà consentire al minimo:

• di visualizzare le informazioni preferibilmente anche su doppio monitor;

• di aprire e visualizzare in contemporanea più referti e relative immagini dello stesso paziente;

• di formattare ed effettuare la stampa degli ECG su carta comune;

• di stampare il referto;

• di gestire la memorizzazione automatica degli esami in collegamento con il Sistema per l’archiviazione dei tracciati;

• di supportare il processo di diagnosi e refertazione in tutte le sue fasi;

• di trasferire gli esami selezionati firmati digitalmente e rilasciati al Sistema preposto per la distribuzione o permetterne l’acquisizione/distribuzione/visualizzazione.

• di firmare digitalmente i referti prodotti.

. Il Sistema di gestione degli esami

Con il nuovo Sistema ogni UU.OO. verrà istruita all’utilizzo autonomo degli elettromedicali e renderà disponibili sulla rete gli esami effettuati.

I medici refertatori di Malattie Cardiovascolari riceveranno i dati relativi agli esami da refertare sui client disponibili presso il reparto e rinvieranno il referto validato e firmato digitalmente.

Analoga procedura verrà utilizzata per la diagnostica ambulatoriale.

Sempre sui client dovranno essere resi disponibili via rete gli altri esami ed i dati clinici dei pazienti.

Il Sistema di gestione e archiviazione digitale degli ECG deve essere correttamente dimensionato sulla base dei carichi di lavoro aziendali in quanto deve poter permettere di archiviare l’attività svolta presso tutte le Unità Operative interessate.

Il numero di esami effettuato dalle UU.OO. interessate al progetto nel corso dell’intero anno è il seguente:

ECG	24.000
TAC	1.500
XXX	000
ECO	12.000
ANGIO	500
MED. NUCL.	2.000
HOLTER	2.700
STRESS	2.500
DEFIBRILLATORI	2.600

La configurazione dell’archivio deve permetterne la gestione secondo i seguenti requisiti minimi:

TIPOLOGIA DI ESAME			FUNZIONALITÀ RICHIESTE	CAPACITÀ
Esami “in refertare	linea”	da	Richiamo immediato	>15 gg.
Esami “in linea”			Richiamo rapido dalle	>= 7 anni
archiviati relativi a			stazioni di refertazione e
pazienti già refertati			visualizzazione
Esami archiviati su			Richiesta sul Sistema	del	A vita
supporto legale			supporto richiesto	e
sostitutivo secondo le			richiamo dalle stazioni	di
normative vigenti in			refertazione	e
materia			visualizzazione

Ogni utente dovrà essere messo in condizione di accedere ai propri dati archiviati in maniera automatica e trasparente.

Dovrà essere garantita la possibilità di limitare l’accesso ai dati in base ad abilitazioni differenziate degli utenti e la possibilità di rendere riservato il trasferimento delle informazioni.

Deve essere prevista, tra l’altro, la possibilità di richiamare le informazioni relative a singoli pazienti e renderle immediatamente disponibili alla workstation di refertazione per eventuali confronti.

Il Sistema proposto, a protezione degli investimenti effettuati, dovrà risultare quindi espandibile nel tempo, senza sostituzione alcuna, a fronte dell’aumento dei carichi di lavoro, ed aggiornabile con l’evoluzione tecnologica.

Deve, inoltre, essere fornita garanzia dell’assoluta sicurezza, integrità e disponibilità dei dati archiviati come da normativa vigente in materia.

Il Sistema dovrà possedere le caratteristiche minimali di seguito indicate.

Le eventuali caratteristiche migliorative verranno valutate in sede di esame tecnico:

• il collegamento e l’integrazione del Sistema con le apparecchiature ECG;

• la gestione delle urgenze con assegnazione delle priorità di refertazione;

• la gestione ed archiviazione degli ECG a riposo, delle prove da sforzo, delle analisi relative ai potenziali tardivi (LPA) e variabilità della frequenza cardiaca (RRV), degli esami HOLTER ECG e pressori previa firma digitale degli stessi;

• possibilità di recupero delle indagini archiviate e invio alle workstation per rielaborazioni successive, senza limiti temporali rispetto all’esecuzione dell’esame;

• possibilità di esportazione in vari formati compressi (DICOM e/o TIFF e/o JPEG e/o altro) e produzione CD per la consegna ai pazienti;

• acquisizione con collegamento diretto delle apparecchiature diagnostiche con connessione in rete (locale e geografica) in modalità Wired e Wireless;

• possibilità di apertura e visualizzazione contemporanea di più esami e referti relativi allo stesso paziente o a pazienti diversi;

• archiviazione degli esami su supporto “sostitutivo” legale in accordo con le norme vigenti in materia.

. Il Sistema CIS

Il Cardiological Information System è finalizzato all’automazione dei processi diagnostici cardiologici ed è orientato alla loro corretta integrazione con le diagnostiche stesse, con il Sistema di gestione degli esami e con le componenti dei Sistemi informativi aziendali.

L’applicazione base CIS consentirà al minimo, garantendo nello stesso tempo l’integrazione di tutte le informazioni e l’autonomia operativa di ciascuna unità, la gestione delle seguenti fasi di lavoro e ambiti funzionali:

• richiesta esame tramite interfaccia con altro Sistema informatico aziendale;

• accettazione del paziente con possibilità di invio alla worklist selezionata;

• esecuzione degli esami;

• refertazione ed archiviazione degli esami;

• confronto automatizzato con esami pregressi per una migliore accuratezza clinica nei follow-up;

• misure automatizzate e misure manuali su tracciati ad alta definizione;

• supporto alla interpretazione dell’ECG con il riconoscimento dei tracciati normali e dei tracciati con probabili patologie;

• elaborazioni statistiche a livello aziendale e di U.O. sia di tipo amministrativo, sia sulla tipologia e modalità degli esami e degli esiti nonché per il regime (SSN, intramoenia, ambulatoriale interno ed esterno) sia per finalità normative, cliniche di didattica e di ricerca con esportazione dei dati in formato e con tracciati standard definiti con l’Azienda e, comunque, in accordo alle specifiche FSE;

• implementazione del record paziente ad indirizzo cardiologico completo (integrazione di Holter dinamici, Stress test, ECG, Monitoraggio, Imaging Dicom);

• integrazione con le apparecchiature diagnostiche finalizzato all’invio elettronico delle liste degli esami da eseguire (worklist) direttamente sull’elettrocardiografo e successiva ricezione.

Inoltre, il CIS dovrà essere dotato di funzionalità aggiuntive per la gestione:

✓ del trasferimento dei referti all’esterno;

✓ della distribuzione del referto in formato elettronico attraverso: visualizzazione su PC tramite web-browser, stampa su stampante connessa a PC e/o connessa in rete LAN, stampa sull’elettrocardiografo (se munito);

✓ archiviazione dei referti su supporto “sostitutivo” legale in accordo con le norme vigenti in materia.

I sottosistemi del CIS devono fornire al personale amministrativo, tecnico, medico e paramedico gli strumenti per supportare i flussi di lavoro e le attività di seguito descritte:

1. la richiesta degli esami deve essere possibile dall’Unità Operativa che ne abbia necessità o dall’esterno tramite operatore o interfacciando opportunamente il Sistema richiedente (esempio: centro prenotazioni unificato, Reparti, Pronto Soccorso, ecc…). Per quanto riguarda l’attività di emergenza, il Sistema deve gestire le urgenze, l’attività interna per le UU.OO. di diagnosi e cura, l’attività ambulatoriale per il S.S.N. e l’attività libero- professionale intramoenia;

2. il Sistema CIS deve inviare le liste di lavoro in forma elettronica alle diagnostiche mediante apposita funzionalità, il tecnico deve essere in grado di riconoscere ed accettare il paziente prenotato;

3. alle diagnostiche, il tecnico dovrà confermare l’avvenuta esecuzione dell’esame con notifica automatica a una o più postazioni refertanti;

4. le liste degli esami da refertare dovranno essere automaticamente rese disponibili in forma elettronica alle Stazioni di refertazione;

5. le Stazioni di refertazione permetteranno al medico di comporre il referto elettronico. Deve essere possibile permettere la contemporanea visualizzazione di ECG e referti attuali e precedenti;

6. la refertazione potrà opzionalmente avvenire per mezzo di riconoscimento vocale automatico del dettato a voce e/o con produzione diretta del testo scritto e/o con

scrittura del referto direttamente da parte del medico anche con l’ausilio di frasari predefiniti;

7. il referto elettronico sarà “chiuso” ed archiviato con “firma” digitale dal medico refertatore secondo le normative vigenti in materia;

8. il Sistema dovrà prevedere la conservazione e archiviazione su supporto legale sostitutivo dei referti che non limiti le normali attività operative;

9. i referti e gli ECG digitali opportunamente selezionati dovranno poter essere inviati, previa firma digitale, alle entità interne o esterne alle Aziende predisposte alla ricezione di tali informazioni in forma elettronica;

10. il Sistema deve prevedere particolari stazioni CIS preposte alla produzione automatica di CD (comprensivo di stampa label) contenente tracciati e referti visionabili con semplici programmi inseriti sugli stessi CD;

11. il Sistema deve essere dotato delle funzionalità necessarie alla produzione di reportistica statistica anche supportati da grafici su diverse parametrizzazioni ed indicatori specifici dell’attività diagnostica cardiologica;

12. il Sistema deve essere dotato delle funzionalità necessarie alla esportazione dei dati in DICOM verso i Sistemi di Data Warehouse aziendali.

L’identificazione dei dati gestiti dal Sistema CIS dovrà essere univoca e associata ad una unica entità anagrafica aziendale e/o regionale nei suoi successivi episodi diagnostici indipendentemente dal regime (di ricovero, ambulatoriale, SSN e Intramenia), in modo che sia garantito lo scambio delle informazioni tra Sistemi senza ambiguità. Tale univocità deve essere garantita anche nel collegamento tra i dati del CIS e i corrispondenti tracciati.

. Integrazione CIS – Cardiografia

In fase di refertazione, all’apertura del tracciato, dovranno essere rese disponibili le informazioni precedenti sul paziente quali ecografie, coronarografie, angiografie, interventistica ed i dati clinici in modo da poterli comparare.

Il CIS e il Sistema di gestione esami devono essere perfettamente integrati e resi omogenei per l’utilizzatore che deve ottenere una visione funzionale unica e trasparente.

In particolare, l’integrazione tra CIS e immagini deve essere finalizzata a:

• avere un unico punto di ingresso (single sign on) con identificazione forte dell’operatore;

• utilizzare un’unica anagrafica;

• visualizzazione contemporanea di ECG e referti;

• autocaricamento delle liste di lavoro governato da CIS:

le liste di lavoro, generate dalla prenotazione e/o accettazione anche interfacciando altro Sistema aziendale debbono essere trasmesse in automatico alle diagnostiche.

Sulle stazioni di lavoro debbono essere richiamati ed associati in automatico gli esami con i precedenti archiviati ed i relativi referti;

• distribuzione automatica referti e ECG nelle UU.OO. richiedenti:

non appena un esame è rilasciato, il tracciato ECG ed il relativo referto devono essere resi disponibili anche in modo automatico alla successiva distribuzione alla Unità Richiedente;

• possibilità di import/export di dati:

devono essere previste opportune funzionalità di importazione/esportazione di dati da/per altri Sistemi in modalità secondo lo standard “HL7” e “DICOM”.

. Integrazione con gli altri applicativi aziendali

In appendice A vengono riportate le specifiche di integrazione tra l’applicativo offerto e le procedure trasversali attualmente in uso presso l’Azienda Ospedaliera (CUP esterno, CUP interno, ADT, anagrafe assistiti, LUMIR, etc.).

Si specifica che i moduli software delle procedure trasversali sono già operativi e che ogni onere relativo alla piena messa a regime dell’interfaccia rimane, comunque, a carico dell’offerente che dovrà valutare eventuali modifiche e/o integrazioni che dovranno essere richieste direttamente alla Società Intema Sanità S.r.l. produttrice del software.

. Reti LAN e WAN – Connettività dei Sistemi

Sia il Presidio Ospedaliero di Pescopagano che quello di Potenza sono serviti da rete fast-ethernet/Giga-ethernet.

Tutti i reparti sono dotati di un congruo numero di prese RJ45 che assicurano la connettività di rete.

Il Presidio di Potenza è già dotato di una rete XX.XX. che copre tutte le aree di degenza. Nel medio termine anche il Presidio di Pescopagano sarà dotato di tale infrastruttura.

I due presidi sono interconnessi da due LINK di rete geografica:

• uno attraverso la rete regionale RUPAR;

• l’altro con connessione punto – punto ad alta velocità.

Attraverso l’uso della rete le Ditte dovranno indicare la modalità di trattamento ed il flusso delle informazioni tenendo conto che:

• tutte le informazioni dovranno essere custodite sul Sistema server ubicato presso la

U.O. S.I.O. – Presidio di Potenza;

• dovrà essere indicata la modalità con cui il Sistema può essere riconfigurato per inviare i dati da Pescopagano a Potenza attraverso le due possibili connessioni di rete.

. Caratteristiche del Sistema server

Si riportano in questo articolo le caratteristiche minimali dei Sistemi server con l’indicazione degli accessori ed altre attrezzature connesse.

Sistema Server con installazione in rack standard 19” e architettura in cluster di 2 nodi con medesimo marchio di fabbrica per i computer e lo storage raid condiviso di capacità adeguata per rispondere ai requisiti di archiviazione con tutte le parti ridondate e protette tali da garantire un funzionamento in continuità h24/365. Il DBMS proposto deve essere robusto ed allineato agli standard di mercato.

Ogni nodo del cluster deve avere la seguente configurazione minima:

• 2 processori;

• 8 Gb di RAM;

• Controller RAID (livelli RAID: 0, 1, 10, 5, 50, 6, 60);

• 4 hard disk 140 Gb 15k hot plug 3.5” (espandibili);

• 3 porte Gigabit Ethernet 10/100/1000 Mbps Full Duplex;

• Alimentatori ridondanti di tipo “hot swap” (2 unità);

• Ventole ridondate di tipo “hot swap”.

. Attrezzature diagnostiche cardiologiche

In appendice B viene riportato un elenco di apparecchiature elettrocardiografiche, Holter e Prove da Sforzo utilizzate in Azienda alla data per la diagnostica cardiovascolare.

Poiché tutte le apparecchiature cardiodiagnostiche dovranno essere utilizzate nell’ambito del progetto di cui al presente capitolato esse devono rispondere ai requisiti ed obiettivi indicati.

A tale scopo ogni offerente dovrà aggiornare e/o integrare e/o sostituire le apparecchiature tenendo conto che la dotazione finale dovrà essere la seguente:

• elettrocardiografi – non meno di 65;

• holter ECG – non meno di 25;

• xxxxxx xxxxxxxx – non meno di 15;

• prove da sforzo – non meno di 9.

In caso di sostituzione di apparecchiature l’offerente dovrà ritirare le apparecchiature sostituite indicando il valore di permuta che dovrà essere riportato a scomputo in sede di offerta economica.

Per ciò che attiene gli Holter cardiologici e pressori le ditte dovranno assicurare l’acquisizione dei dati sul Sistema proposto.

I Sistemi Holter aggiornati/sostituiti/integrati dovranno avere le seguenti caratteristiche minimali:

• SISTEMA ECG HOLTER CARDIACO: Unità di registrazione

Registratore avente le seguenti caratteristiche minimali

- registratore allo stato solido con memoria rigida interna, in grado di registrare fino a 3 canali per 24 – 48 ore senza compressione dati con cavi terminali che consentono la rilevazione di derivazioni bipolari;

- pulsante eventi – paziente;

- possibilità di scaricare i dati anche ad un dispositivo dedicato idoneo per l’interfacciamento ad una flash-card, al Sistema di analisi e al controllo del tracciato durante il monitoraggio al paziente;

- espansione con registrazione a 7 (sette) giorni.

• SISTEMA ECG HOLTER CARDIACO: Unità di lettura

- Ram da 2 GB;

- Masterizzatore DVD Dual Layer;

- 8 porte USB 2.0 (2 frontali);

- Scheda di rete 10BaseT/100Base-TX, 1000Base-T;

- Mouse, Tastiera;

- Smart card reader integrato;

- Software antivirus aziendale;

- Monitor LCD TFT da 19”;

- Stampante Laser a colori:

❖ formato A4

❖ velocità 16 ppm/mono

❖ velocità 12 ppm/colore

❖ interfaccia USB

❖ scheda di rete ethernet 10/100 base TX

❖ RAM 64 MB

❖ Cassetto da 250 fogli

Software avente le seguenti caratteristiche minimali

Il software di lettura deve consentire attraverso algoritmi validati e scientificamente documentati in maniera retrospettiva:

- riconoscimento e analisi della F.C., HR, dell’ST su 12 canali, analisi della variabilità RR nel dominio del tempo e nel dominio della frequenza, analisi della dispersione QT, analisi QT ed analisi T alternance post potenziali;

- valutazione del pace maker;

- valutazione per pazienti in età pediatrica, che consenta di adattare i parametri del ritmo alel diverse con protocolli di registrazione del paziente pediatrico;

- stratificazione automatica a colore del segnale ECG per una corretta identificazione dell’intervallo PR per i blocchi AV, l’intervallo QRS per i blocchi di branca (LBBB) e run VT;

- rilevamento automatico della Fibrillazione Atriale da parte del Sistema prima della lettura dell’operatore per i pazienti con sintomatologia cronica;

- identificazione delle regioni per classificare il Flutter Atriale, il livello di rumore e i singoli battiti;

- rilevamento e riconoscimento senza limiti di tutte le famiglie delle aritmie ventricolari e sopra-ventricolari registrate con accesso diretto alla funzione di estrapolazione quantitativa automatica – manuale (completo di grafico a colori) delle relative famiglie riconosciute;

- possibilità di accesso agli eventi significativi tramite trend ed istogrammi (specificare le varie configurazioni);

- report finale configurabile in base all’analisi dell’ECG effettuata dall’operatore;

- lettura ed analisi su 7 (sette) giorni.

• SISTEMA ECG HOLTER PRESSORIO: Unità di registrazione

Registratore avente le seguenti caratteristiche minimali

- dimensioni estremamente compatte completo di borsa per il trasporto e caricabatteria;

- metodo di misura oscillometrico, autonomia di acquisizione minimo 30 ore o 200 misurazioni, acquisizione dei valori, deflazione continua del bracciale, analisi della misurazione con rilevamento degli artefatti, gonfi aggio e sgonfi aggio del bracciale in automatico;

- minimo 3 protocolli di misura impostabili dal registratore e dal pc;

- funzionamento a batterie ricaricabili;

- dotazione di almeno due bracciali per bambino, adolescente e adulto.

• SISTEMA ECG HOLTER PRESSORIO: Unità di lettura

- Ram da 2 GB;

- Masterizzatore DVD Dual Layer;

- 8 porte USB 2.0 (2 frontali);

- Scheda di rete 10BaseT/100Base-TX, 1000Base-T;

- Mouse, Tastiera;

- Smart card reader integrato;

- Software antivirus aziendale;

- Monitor LCD TFT da 19”;

- Stampante Laser a colori:

❖ formato A4

❖ velocità 16 ppm/mono

❖ velocità 12 ppm/colore

❖ interfaccia USB

❖ scheda di rete ethernet 10/100 base TX

❖ RAM 64 MB

❖ Cassetto da 250 fogli

Software avente le seguenti caratteristiche minimali:

- gestione completa dei dati riferiti a pazienti ed esami;

- possibilità di produzione report personalizzabili;

- possibilità di inserimento di note accompagnatorie degli esami.

I Sistemi per le prove da sforzo aggiornati / sostituiti / integrati dovranno avere le seguenti caratteristiche minimali:

• SISTEMA PER PROVE DA SFORZO: Unità di registrazione e diagnosi

Registratore avente le seguenti caratteristiche minimali:

Il Sistema, composto di una workstation avente le medesime caratteristiche dei Sistemi Holter innanzi indicate, deve essere capace di gestire una o più diagnostiche con rilevazione e trasferimento dati wireless al Sistema in automatico consentendo la visualizzazione in tempo reale e in differita e l’analisi del segnale ECG sul monitor del PC in formato 6 o 12 canali:

- lo stress test;

- l’Holter pressorio ed ECG;

- l’ECG a riposo.

Il Sistema deve altresì permettere, sempre in connessione con il Sistema Informativo Ospedaliero, di gestire tutti i dati anagrafici dei pazienti e dei loro vari esami, incluse le diagnosi e le refertazioni.

Le funzioni minimali del Sistema dovranno essere le seguenti:

- registrazione del test da sforzo;

- registrazione multifunzione contemporanea programmabile come registratore Xxxxxx, come elettrocardiografo palmare, come unità di acquisizione per prove da sforzo, o una combinazione delle stesse registrazioni;

- analisi standard: STj, STj+x (X selezionabile e variabile in tempo reale), slope, area;

- analisi aritmie con classificazione e trend delle principali aritmie;

- controllo unità periferiche: cicloergometri, treadmill, misuratore di pressione ECG;

- xxxxxxx xxxxxxxxxxxxx: FC massima, aritmie ed eventi ST;

- elettrocardiografo “digitale integrato” con acquisizione simultanea dei segnali elettrocardiografici delle 12 derivazioni standard ECG senza compressione del segnale; 500 campioni al secondo per ogni canale.

• SISTEMA PER PROVE DA SFORZO: Unità Treadmill programmabile

avente le seguenti caratteristiche minimali:

Il Sistema Treadmill progettato per prove da sforzo anche in età pediatrica, dovrà essere collegato ed integrato alle apparecchiature elettrocardiografiche, al Sistema di controllo e verifica dell’attività motoria.

Il Sistema dovrà essere dotato di console digitale, fornita di display, con possibilità di utilizzazione anche come unità “stand-alone”, di visualizzazione e programmazione dei dati del paziente, della velocità, della durata del test e della pendenza regolabile elettronicamente direttamente dalla console con range regolabile elettronicamente tra

-5% e +20%.

Il Sistema dovrà essere completamente integrato ed interfacciabile al Sistema di registrazione e diagnosi consentendo così la effettuazione di esami in modalità completamente automatizzata. Tra le caratteristiche fisiche del tappeto si richiedono le seguenti:

- Dimensioni almeno 200x73 cm;

- Dimensioni utili di camminamento almeno 200x50cm;

- Nastro scorrevole in materiale e struttura antitrauma;

- Motore a velocità variabile HP 2.5, da 0 a 20 Km/h.

Le apparecchiature cardiografiche aggiornate/sostituite/integrate dovranno rispondere alle seguenti caratteristiche minimali:

• SISTEMA ECG

- monitor di visualizzazione con risoluzione 640x480 o superiore;

- 12 canali di acquisizione con visualizzazione contemporanea e stampa in formato A4 con relativi parametri principale (HR velocità e ampiezza);

- possibilità di selezionare le derivazioni e di verificare a monitor l’andamento delle prestazioni;

- possibilità di inserimento dei dati;

- Sistema di monitoraggio dell’impedenza degli elettrodi;

- Sistema di filtraggio e protezione da defibrillatore;

- porte: USB, SVGA, Lan RJ45 o WIFI a/b/g/n in dipendenza della singola specifica installazione (specificare se e come è possibile cambiare sulla diagnostica il tipo di connessione wired/wireless dopo la prima installazione);

- rapidità regolazione linea base dopo defibrillazione;

- alimentazione di rete ed a batteria con durata minima di 2h;

- corredato di carrello per trasporto, cavo paziente, cavi alimentazione, doppia batteria.

E’ titolo preferenziale per il carrello acquisire un dispositivo che abbia la possibilità di poggiare anche un Personal Computer portatile e/o una piccola stampante.

E’ obbligo della Ditta aggiudicataria procedere alla consegna di non meno di 10 elettrocardiografi entro 15 giorni dalla data di stipula del contratto.

Per ciò che riguarda l’acquisizione dei dati rivenienti da indagini ecocardiografiche, angiografiche, coronarografiche e quanto risultante dal collegamento ai poligrafi, ogni Ditta dovrà proporre la propria soluzione che verrà valutata in sede di esame tecnico del progetto.

. Conservazione sostitutiva, servizi di firma digitale e marcatura temporale

Sono compresi nel presente appalto i mezzi tecnici (badge, hardware, software, servizi) per la firma digitale, l'archiviazione elettronica dei documenti digitali e la loro conservazione sostitutiva; questa dovrà essere conforme alle Normative italiane.

La firma digitale del documento informatico (che dovrà essere presente in tutti i programmi) dovrà essere conforme alle Normative italiane ed europee.

Quanto sopra si intende eseguito in conformità alle eventuali successive modificazioni normative che dovessero intervenire tra la redazione del presente capitolato e l'aggiudicazione del presente appalto.

In conformità al nuovo Codice dell'amministrazione digitale ex D. Lgs. 235/2010 pubblicato nella G.U. 10/01/2011 n° 6 si richiede che l'intero Sistema offerto per il presente appalto sia conforme alle disposizioni ivi contenute.

L'aggiudicatario si impegna a verificare l'impatto sull'intero Sistema ad ogni eventuale variazione normativa durante il periodo contrattuale, in particolare a riguardo di firma digitale, marche temporali e conservazione sostitutiva proponendo le variazioni necessarie da apportare al Sistema affinché diventi, qualora non lo fosse, compatibile con la variazione normativa intervenuta.

I referti e tutte le altre informazioni testuali, numeriche e immagine, dovranno essere memorizzate e conservate sostitutivamente in un formato conforme agli standard, senza perdita di informazioni e tutte le immagini dovranno poter essere memorizzate per la conservazione in formato standard DICOM.

Alla fine del contratto, qualora non vi sia prosecuzione di rapporto, l'aggiudicatario produrrà e consegnerà quanto necessario per garantire la leggibilità, la rintracciabilità e la disponibilità di tutti i dati, con particolare riferimento a quelli conservati in modalità sostitutiva.

. Integrazione con la rete di emergenza/urgenza

La L.R. 1/7/08 n° 12 assegna all’Azienda Ospedaliera Regionale “San Carlo” funzioni di riferimento per le alte specialità e per le reti cliniche integrate dei Servizi ospedalieri.

Nell’espletamento di tali funzioni grande rilievo rivestono quelle relative alla rete dell’emergenza/urgenza in quanto, tra gli altri, presso L’Azienda è ubicata la Stazione di ricezione della rete di telecardiomedicina che è composta da dispositivi LIFEPAK 12 della Medtronic installati sulle ambulanze che sono in grado di registrare ed inviare elettrocardiogrammi a 12 derivazioni ed altri parametri vitali quali la misurazione non invasiva della pressione e la misurazione della concentrazione di ossigeno nel sangue.

I parametri vitali registrati dall’apparecchio LIFEPAK 12 inviati all’Azienda Ospedaliera Regionale “San Carlo” saranno identificati ed interpretati dando tutti i possibili suggerimenti medici del caso.

La proposta progettuale che si andrà a predisporre deve tenere conto di tali funzioni proponendo gli opportuni strumenti necessari all’interfacciamento dei Sistemi in modo da poter acquisire automaticamente le informazioni rilevate dai Sistemi dell’emergenza/urgenza nel Sistema aziendale CIS – Cardiografico. La proposta verrà valutata in sede tecnica nella sezione riguardante l’integrazione con la rete dell’emergenza/urgenza.

. Telecardiologia

Il progetto intende rendere possibile la refertazione remota delle prestazioni in modo da poter usufruire delle disponibilità di personale medico anche non presente al sito ove sono ubicate le diagnostiche.

Ad esempio, deve essere possibile refertare a Potenza un esame effettuato a Pescopagano.

Dovranno essere, altresì, proposte soluzioni progettuali che rendano possibile lo scambio di informazioni con analoghi Sistemi di altre Aziende attraverso la fornitura di apposite interfacce.

. Le licenze software

La fornitura comprende la licenza d’uso a tempo indeterminato di tutti i software di base, d’utilità ed applicativi e firmware presenti nel Sistema; i contratti di licenza originali della casa produttrice; nel caso in cui questo comprendesse delle clausole a sfavore dell’Azienda, le stesse non avranno alcun valore nel rapporto contrattuale tra l’Azienda e il fornitore.

Nel caso in cui il software fosse protetto da una cosiddetta chiave hardware, l’Azienda si impegna a custodirla ed a proteggerla da qualsivoglia comportamento illecito e deterioramento, ed in caso di sottrazione, a denunciare il fatto alla autorità giudiziaria competente; in caso di guasto/rottura l’Azienda si impegna a restituirla; in ogni caso, ferme restando le responsabilità dei singoli, il fornitore si impegna a riparare/sostituire o fornire una nuova chiave hardware e la reinstallazione senza alcun onere aggiuntivo per l’Azienda, in quanto la non disponibilità della chiave stessa non può costituire ipso facto la decadenza del contratto di licenza. Parimenti a riguardo dei dischi originari di installazione, l’ Azienda si impegna a custodirli con massima diligenza.

I software applicativi devono essere rispondenti alle leggi ed alle norme italiane ed Europee, in particolare devono rispondere ai principi ed essere compatibili con le misure minime di sicurezza del D. Lgs. 196/2003 e ss.mm.ii., intendendosi che di norma tutte le basi dati dei Sistemi informatici sanitari possono contenere dati sensibili; pertanto, i software applicativi dovranno essere in generale perfettamente aderenti/coerenti con/alle disposizioni di legge per le quali la Ditta aggiudicataria dovrà rilasciare apposita dichiarazione di conformità.

Il fornitore stesso assume l’obbligo di mantenere riservati i dati che venisse a conoscere o dovesse consultare in fase di installazione o assistenza, di non divulgarli e di non farne utilizzo diverso da quello, appunto, legato al funzionamento del Sistema (installazione o assistenza). Per assolvere tale obbligo il fornitore all’atto di sottoscrizione del contratto verrà nominato terzo responsabile del trattamento e, quindi, corresponsabile insieme all’Azienda rispetto ai trattamenti effettuati.

APPENDICE A

Specifiche di interfaccia

Scopo del documento

Il presente documento descrive le specifiche di comunicazione da implementare, secondo gli standard HL7 e XML/SOAP del CNIPA in merito all’interoperabilità applicativa dei Sistemi informatici sanitari, con particolare riferimento ai flussi di scambio-dati tra i Sistemi trasversali (CUP, ADT, PS, Refertazione, Contabilità e Magazzino) e altri Sistemi di terze parti di seguito indicati con il termine “servizi”.

Viene, inoltre, dettagliata la messaggistica utilizzata in conformità a quanto disposto dallo standard HL7 2.3.1 e dal framework IHE.

Specifiche di comunicazione: flussi di scambio dati

In generale la comunicazione tra i Sistemi trasversali ed i servizi si modella secondo un paradigma standard mostrato di seguito. Negli esempi si fa riferimento esplicito alle modalità d’interazione con un Sistema RIS, pertanto, presenta caratteristiche che sono peculiari di tale contesto, tuttavia può essere modellato (e quindi modificato) secondo le necessità di qualunque contesto applicativo.

Dal momento che la modalità di scambio preferita (sia per l’aderenza agli standard internazionali che per migliori performance tecniche e di sicurezza) è quella inerente a scambi XML/HL7 implementati su web services, si fa di seguito esplicito riferimento a tale modalità (vengono citati in parentesi per ciascun flusso i corrispondenti segmenti HL7 vers. 2.3.1).

Si descrivono, pertanto, le modalità di comunicazione, in particolare prendendo come riferimento un singolo flusso monodirezionale di dati tra due entità generiche: queste modalità si applicano su ciascuno dei processi di interazione in cui l’intero scambio si scompone.

Sono illustrati di seguito i flussi di dati ipotizzati.

Sistemi Trasversali Servizio

Terze Parti

1. Prenotazione - Apertura Contatto

2. Cancellazione Prenotazione

3. Modifica - aggiunta o cancellazione prestazioni

4. Prestazione eseguita

5. Refertato

In particolare nella fase n. 1 contestualmente alla prenotazione viene rappresentata l’apertura del contatto fra assistito e struttura sanitaria (che può essere effettuata, ad esempio, in regime di Pronto Soccorso, Ricovero programmato, Day Hospital, …).

• Le fasi 2-3 provvedono alle successive modifiche di eventi già prenotati dal CUP, ad esempio nel caso in cui, precedentemente all’erogazione della prestazione, sopraggiungano modifiche o cancellazioni da parte dell’assistito. In generale qualunque modifica viene comunicata mediante una cancellazione e una nuova apertura.

• Tutte le fasi corrispondono alla comunicazione della singola entità (elemento anagrafico, prenotazione prestazione, referto, ecc.) e non di liste di elementi: quindi, avvengono puntualmente e in modo sincrono in coincidenza dell’evento che le ha generate.

Tutti gli scambi avvengono mediante web service, e l’esposizione di metodi per la ricezione o per l’invio dei dati XML/HL7 (v.2.3.1).

In particolare la comunicazione prevede che l’entità ricevente esponga un web services, chiamato dall’entità trasmittente per l’invio dei dati.

Le funzioni esposte dal servizio trasversali sono le seguenti:

• Prestazione Eseguita

• cancellaPrestazione

• aggiungiPrestazione

• invioReferto

Viene prevista una stringa come input, contenente il messaggio HL7 in formato XML.

Per quanto detto è necessario realizzare una coppia di web service (uno trasversale e l’altro relativo al Sistema di servizio), e i metodi che in entrambi i casi rappresentino l’entità trasmittente, utilizzati per inviare al web service chiamato il file XML del singolo flusso.

Ciascuno dei web services deve essere corredato dei componenti (classi e metodi) di livello inferiore, utilizzati per elaborare il tracciato XML/HL7 ricevuto. Analoghi componenti vengono utilizzati dai metodi chiamanti (entità trasmittente) per le operazioni complementari.

In particolare tali componenti realizzano i seguenti processi:

Fase Trasmittente

1. chiamata ai metodi / oggetti che realizzano la connessione alla base dati dell’entità trasmittente e rilevazione dei dati da trasmettere per ogni particolare tipo di flusso;

2. organizzazione dei dati da trasmettere in una struttura XML secondo la specifica HL7 corrispondente al particolare flusso da implementare;

3. chiamata al web service ricevente per la trasmissione del flusso dati.

Fase Ricevente

1. ricezione del flusso dati (struttura XML/HL7);

2. parsing (lettura e interpretazione secondo la specifica HL7) della struttura XML e scomposizione della stessa nelle singole parti componenti;

3. rilascio dei dati nella base dati ricevente;

4. Ritorno Messaggio ACKNOWLEDGEMENT.

HL7 : Messaggistica utilizzata

In conformità a quanto esposto dallo standard HL7 2.3.1 e dal framework IHE si stabilisce di seguito il tipo di messaggistica utilizzata per:

❖ Gestione di una richiesta di prestazione;

❖ Gestione della richiesta direttamente effettuata presso il servizio;

❖ Inserimento nel Repository e Gestione cambiamenti di stato del referto; Registrazione diretta sul Sistema di servizio.

Tavola Abbreviazioni

I termini abbreviati e le loro definizioni usate nei segmenti sono le seguenti:

	Definition
SEQ	The sequence of the elements as they are numbered in the segment.
LEN	The length of the element.
DT	The data type of the element. The data types are described in 3.2 below.
OPT	The designations are: R Required. O Optional. C Conditional on the trigger event or on some other field(s). The field definitions following the segment attribute table should specify the algorithm that defines the conditionality for the field. X Not used with this trigger event. B Left in for backward compatibility with previous versions of HL7.
RP/#	Indicates if element repeats and number of times.
TBL#	Specific table reference. Tables are listed in Appendix B.
ITEM#	HL7 unique item number for each element.
Element Name	Descriptive name of element in the segment.

Data Types

I nomi abbreviati dei Data Types usati sono:

	Data Type
CE	coded element
CK	composite ID w/check digit
CQ	composite quantity w/units
CX	extended composite ID w/check digit
DLN	driver’s licence number
DT	date
EI	entity identifier
HD	hierarchic designator
ID	coded value
IS	sequence ID
NM	numeric
PT	processing type
SI	sequence ID
SN	structured numeric
ST	string
TQ	timing quantity
TS	time stamp
TX	text data
XAD	extended address
XCN	extended composite ID number and name for persons
XON	extended composite name and ID number for organizations
XPN	extended person name
XTN	extended telecommunications number

Livelli ed ID

Per semplificazione si riporta la tabella dei termini utilizzati dalle applicazioni nella identificazione degli item.

Tabella dei livelli :

IHE	Anagrafe	Intema CUP	Servizio
Paziente		ASL_Counter
PV1		Prenotazione
ORC		Appuntamento
OBR		Prestazione

Gli ID sono numeri univoci che permettono di trovare in modo inequivocabile il record nella lista.

Nome su IHE	Anagrafe	Nome su Intema CUP	Nome su Servizio
Patient ID		ASL_Counter
PV1.19		Nr. Prenotazione
ORC.4 Placer Group Number		Nr. Appuntamento
OBR.2 Placer Order Number		Nr Prestazione: -per i ricoverati : Nr. progressivo della richiesta -per gli esterni : Nr. Impegnativa seguito da un Nr. Progressivo

Message Control

XML

web service

I messaggi seguiranno il flusso seguente :

WebServer

CUP/ADT/ PS

Communication Server Servizio

Vincolo sui caratteri

Poiché HL7 fa uso dei seguenti caratteri speciali <CR>, | , ^ , & , ~ , \ , è evidente che essi possono essere utilizzati per altra motivazione nei messaggi fra applicativi trasversali e software terze parti solo se ‘incapsulati’ in opportuna sequenza di escape prevista dallo standard:

CARATTERE SPECIALE HL7	SEQUENZA DI ESCAPE XX0
x	\X\
&	\X\
x	\X\
~	\R\
\	\E\

L’utilizzo di eventuale DB Oracle nel software terze parti richiede, la sostituzione del carattere speciale ‘ (apice), utilizzato in genere come accento nei nomi di città o nazione, con il carattere ´ (accento acuto) per permetterne la ricerca automatica in SQL.

Gestione di una richiesta di prestazione

Un contatto effettuato al CUP/ADT consta, oltre del dato anagrafico che permette l’individuazione del contatto, delle informazioni relative agli appuntamenti ed alle prestazioni afferenti a questi ultimi.

Gli eventi, gestiti con messaggi di tipo ORM, che possono occorrere sono:

ORM – Registrazione /Accettazione

1

n

ORM - ORC – Appuntamento

1

n

ORM OBR– Prestazione

CUP/ ADT / PS

Servizio

Registrazione prenotazione / accettazione

Composizione del messaggio, in riferimento allo standard HL7 2.3.1, ed al Technical Framework versione 5.5 di IHE:

ORM O01	General Order Message
MSH	Message Header
PID	Patient Identification
PV1	Patient Visit
{ORC}	Common Order
{OBR}	Order Detail

Nota 1: in caso di più prestazioni nello stesso messaggio ORM il segmento ORC verrà ripetuto per ogni segmento OBR

Nota 2: in caso di prestazioni con quantità > 1 nell’ambito dell’appuntamento CUP (es. due RX Braccio) sarà presente nel messaggio una coppia ORC-OBR per ogni prestazione.

Il segmento MSH

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
1	1	ST	R		Field Separator	|
2	4	ST	R		Encoding Characters	^~\&
3	180	HD	O		Sending Application	CUP
5	180	HD	O		Receiving Application	destinatario
7	26	TS	O		Date/Time Of Message	yyyyMMddHHmm
8	40	ST	O		Security	Sec
9	7	CM	R		Message Type	es. ORM^O01
10	20	ST	R		Message Control ID	NumAppuntamento & tipoEvento(NW/CA) Identifica univocamente il messaggio
11	3	PT	R		Processing ID	P
12	8	ID	R	0104	Version ID	2.3.1
18	6	ID	O	0211	Character Set	8859/1

Il Segmento ORM

Il messaggio ORM, contenente i dati della prenotazione, conterrà, quindi, un segmento ORC per ogni segmento OBR; tale coppia di segmenti potrà essere anche relativa ad esami effettuabili in diagnostiche differenti, ma dovrà in ogni caso essere indicata sempre nel messaggio, nei campi sotto elencati, la data/ora della prenotazione e la diagnostica in cui dovrà essere effettuato l’esame.

ORM - PID attributes – (Prenotazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT	CONTENUTO
					NAME
3	16	ST	R		Patient ID (Internal ID)	Identificativo Paziente PID-3-1 =Identificativo Paziente PID-3-4= Fonte identificativo paziente PID-3-5= Codice tipo identificativo

						Es. valorizzazione 90100123717^^^INTEMA^PI
5	48	XPN	R		Patient Name	Cognome^Nome
7	8	DT	R		Date of Birth	Data di Nascita aaaammdd
8	1	IS	R	0001	Sex	Sesso
11	106	XAD	R		Patient Address	PID-11-1(1)=Indirizzo Residenza PID-11-3(1)=Descrittivo comune residenza PID-11-5(1)=CAP PID-11-6(1)=Cittadinanza PID-11-7(1)=L PID-11-9(1)= Codice Istat Residenza Indirizzo residenza^^ComuneResidenza^^CAP ^cittadinanza residenza ^L^^Istat Residenza PID-11-1(2)= PID-11-3(2)= Descrittivo comune nascita PID-11-5(2)= PID-11-6(2)= Cittadinanza PID-11-7(2)=BR PID-11-9(1)= Codice Istat comune Nascita ^^ComuneNascita^^CAP^cittadinanza^BR^^IstatNascita
13	40	XTN	R		Phone Number – Home	PID-13-1(1)= numero telefono residenza XXX-00-0(0)xXX XXX-00-0(0)xXX Xx. XxxxxxxxxXXxXX XXX-00-0(0)x numero telefono domicilio ( o secondario) PID-13-2(2)=CP PID-13-3(2)=CP Nr.Cellulare^CP^CP PID-13-1(3)= PID-13-2(3)=NET PID-13-3(3)=X.400 PID-13-4(3)=email xXXXxX.000xxxxxx@xxx.xx
18	16	CX	O		Patient Account Number	Codice Fiscale
19	16	ST	O		SSN Number – Patient	Tessera Sanitaria

ORM – PV1 attributes – (Prenotazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	1	IS	R		Patient Class	Tipo Paziente E/I/P E= Esterni P=Pronto Soccorso I=Interni
5	20	CX	O		Preadmit Number	Numero Prenotazione CUP
12	60	CE	O	0043	Ranger Code	Mese Gravidanza
14	3	IS	O	0023	Admit Source	Modalità di accesso E0=Esterni SSN, E1 = Esterni ALP
19	20	CX	R		Visit Number	PV1-19(1)= Nr. Nosologico per Interni oppure Nr. Accettazione per PS oppure Nr. Appuntamento per Esterni PV1-19(4)=Fonte di XX0-00(0) XX0-00(0)xXxxxx di PV1-19(1) 787788^^^PS^PS
20	50	CM	O	0064	Financial Class	Regime tariffario
21	2	IS	O	0032	Charge Price Indicator	Codice esenzione (CodEnte|Vers.Esenz|CodiceEsenz.)
44	26	TS	O		Admit Date/Time	Data dell’impegno

ORM - ORC – attributes – (Appuntamento)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
1	2	ID	R		Order Control	Tipo evento = NW / CA
2	22	EI	R		Placer Order Number	Questa chiave è ottenuta dalla concatenazione senza separatori di : nr. Impegnativa ,CodiceEsameCup Codice lateralità, ProgressivoPrestazione nell’impegnativa per un massimo di 22 caratteri Es. se l’impegnativa 12345678901 prevede RX del ginocchio DX e SX Avremo per il ginocchio DX ORC-2.1=OBR-2.1 = 12345678901100201611 ORC-2.2=OBR-2.2= CUP Avremo per il ginocchio SX ORC-2.1=OBR-2.1 = 12345678901100201622 ORC-2.2=OBR-2.2= CUP Nella cancellazione di una prestazione, l’ ORC-2.1 è opzionale mentre resta obbligatorio ORC-2.2
4	22	EI	R		Placer Group Number	ORC-4-1 = Nr. Appuntamento ORC-4-2= Fonte numero appuntamento 20028184279^CUP
9	26	TS	O		Date/Time of Transaction	Data ed ora della transazione yyyyMMddHHmm
12	120	XCN	O		Entered By	ORC-12-1= Codice medico richiedente ORC-12-2= Cognome medico richiedente ORC-12-3= Nome medico richiedente Codice^Cognome^Nome Medico Richiedente
16	200	CE	O		Order Control Code Reason	Operatore^Nota Operatore
17	60	CE	O		Entering Organization	Per interni ORC-17-1= Codice entità

richiedente

ORC-17-2= Descrizione entità richiedente

Per esterni

ORC-17-1= “CUP”

ORC-17-2= “CUP ESTERNI”

Pronto Soccorso

ORC-17-1= “PS”

ORC-17-2= “Pronto Soccorso”

✓ Il campo 9 “Data ed ora della transazione” si compone di :

<Start date/time (TS)> Data ed ora di quando il paziente ha avuto il contatto.

ORM - OBR – attributes – (Prestazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	11	EI	R		Placer Order Number	Vedi ORC-2
4	200	CE	R		Universal Service ID	OBR-4-1=Codice di trascodifica esame (CodPrestazioneCUP – lateralità) OBR-4-2=descrizione esame Codice prest^descriz. Prestazione^CUP
5	2	ID	O		Priority	Urgenza
18	60	ST	R		Placer Field 1	Centro di costo
21	60	ST	R		Filler Field 2 +	CodiceUnitaOperativa erogante È il codice dell’agenda
27	200	TQ	O		Quantity/Timing	Quantità^^^Data della prenotazione (yyyyMMddHHmm)
31	300	CE	O	0043	Reason for Study	Codice della patologia

Cancellazione/aggiunta/modifica di un esame

Le prenotazioni di pazienti sia esterni che interni possono essere variate nei seguenti modi:

✓ Cancellazione di una prestazione

✓ Aggiunta di una prestazione

✓ Modifica di una prestazione

In tutti e tre i casi i Sistemi trasversali effettuano la cancellazione di un appuntamento e la successiva creazione di uno nuovo.

Composizione del messaggio, in riferimento allo standard HL7 2.3.1, ed al Technical Framework versione 5.5 di IHE:

ORM O01	General Order Message
MSH	Message Header
PID	Patient Identification
PV1	Patient Visit
ORC	Common Order

Per la cancellazione di un appuntamento/prestazione verrà valorizzato il campo ORC.1 = CA, per l’aggiunta di un appuntamento/prestazione ORC.1 = NW.

Aggiornamento della richiesta da servizio

Un contatto effettuato ai Sistemi trasversali, per essere chiuso ed archiviato, bisogna che il paziente risulti essersi presentato presso l’unità di Servizio ed abbia eseguito la prestazione.

Gli eventi, gestiti con messaggi di tipo ORM, che possono occorrere sono:

ORM^O01 – Esam

Nel momento in cui il te estinato al Sistema tra

zione su Sistema trasve

d

A

viene generato un mes to eseguito.

,

a

ORM – Prestazione Eseguita

ORM – Cancellazione di una Prestazione

ORM – Creazione di un Impegno per l’aggiunta di una prestazione

ORU – Invio Referto

e Eseguito

cnico conferma la prestazione sul Servizio sversale in cui si sancisce che l’esame è s

rsale:

Servizio

CUP INTEMA

saggio

t

o La corrispondenza sul database del Sistema trasversale viene fatta con ORC.4.

o L’esame deve essere bloccato per la cancellazione.

ORM O01 General Order Message

MSH	Message Header
PID	Patient Identification
PV1	Patient Visit
{ORC}	Common Order
{OBR}	Order Detail

ORM - PID attributes

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
						Identificativo Paziente
3	16	ST	R		Patient ID (Internal ID)	PID-3-1 =Identificativo Paziente PID-3-4= Fonte identificativo paziente PID-3-5= Codice tipo identificativo
						Es. valorizzazione
						90100123717^^^INTEMA^PI
5	48	XPN	R		Patient Name	Cognome^Nome
7	8	DT	R		Date of Birth	Data di Nascita aaaammdd
8	1	IS	R	0001	Sex	Sesso

✓ Il campo 3 ”Identificativo Paziente “ proviene dall’Anagrafe Sanitaria

✓ Il campo 7 ”Data di nascita “ avrà il seguente formato aaaammdd

ORM – PV1 attributes – (Prenotazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	1	IS			Patient Class	Tipo Paziente E/I
5	20	CX	O		Preadmit Number	Nr. Prenotazione
19	20	CX	O		Visit Number	È quello trasmesso da CUP nello stesso campo nei messaggi ORM relativi alle nuove prenotazioni
44	26	TS	O		Admit Date/Time	Data dell’ impegno

ORM - ORC attributes (Appuntamento)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
1	2	ID	R	0119	Order Control	SC (Status changed)
2	22	EI	O		Placer Order Number	Vedi ORC-2 messaggi CUP-RIS per l’erogazione di prestazioni da CUP. Non valorizzato per le prestazioni aggiunte da RIS
3	22	EI	C		Filler Order Number	idprestazioneris^RISEBIT Es. 215656^RISEBIT

4	22	EI	R		Placer Group Number	Nr. Appuntamento
5	2	ID	R		Order Status	CM

ORM - OBR – attributes – (Prestazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	11	EI	R		Placer Order Number	Vedi ORC-2 tabella precedente
3	22	EI	C		Filler Order Number	idprestazioneris^RISEBIT Es. 215656^RISEBIT
4	000	XX	X		Xxxxxxxxx Xxxxxxx XX	CodPrestazioneCUP - lateralità^descriz. Prestazione
16	120	XCN	O		Ordering provider	Codice^Cognome^Nome Medico o Tecnico Esecutore
27	200	TQ	O		Quantity/Timing	1 ^Data della prenotazione (yyyyMMddHHmm)

ORM^O01 – Cancellazione di una Prestazione

Sul Sistema terze parti, questo evento viene generato quando il tecnico cancella la prestazione da eseguire.

Composizione del messaggio, in riferimento allo standard HL7 2.3.1, ed al Technical Framework versione 5.5 di IHE:

ORM O01	General Order Message
MSH	Message Header
PID	Patient Identification
PV1	Patient Visit
{ORC}	Common Order
{OBR}	Order Detail

Azione su CUP :

o La corrispondenza sul database del Sistema trasversale viene fatta con ORC.4.

o il messaggio genera il cambiamento di stato dell’esame che viene messa in uno “stato di non esecuzione”.

ORM - PID attributes

✓ Come capitolo “ORM – Prestazione Eseguita”

ORM – PV1 attributes – (Prenotazione)

✓ Come capitolo “ORM – Prestazione Eseguita”

ORM - ORC attributes (appuntamento)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
1	2	ID	R	0119	Order Control	OC (Order Canceled)
2	22	EI	O		Placer Order Number	Vedi ORC-2, OBR-2 descritti nel capitolo 5 non valorizzato per le prestazioni aggiunte da RIS
3	22	EI	C		Filler Order Number	idprestazioneris^RISEBIT Es. 215656^RISEBIT
4	22	EI	R		Placer Group Number	Nr. Appuntamento

ORM - OBR – attributes – (Prestazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	11	EI	O		Placer Order Number	Vedi ORC-2, OBR-2 descritti nel precedente paragrafo
3	22	EI	C		Filler Order Number	idprestazioneris^RISEBIT Es. 215656^RISEBIT
4	000	XX	X		Xxxxxxxxx Xxxxxxx XX	CodPrestazioneCUP - lateralità^descriz. Prestazione
27	200	TQ	O		Quantity/Timing	1 ^Data della prenotazione (yyyyMMddHHmm)

ORM^O01 – Creazione di una nuova impegnativa per aggiunta di una Prestazione

Composizione del messaggio, in riferimento allo standard HL7 2.3.1, ed al Technical Framework versione 5.5 di IHE:

ORM O01	General Order Message
MSH	Message Header
PID	Patient Identification
PV1	Patient Visit
{ORC}	Common Order
{OBR}	Order Detail

Azione su Sistema trasversale:

o La corrispondenza sul database trasversale viene fatta con ORC.4.

o il messaggio genera la creazione di una nuova impegnativa

ORM - PID attributes

Vengono descritti i contenuti informativi minimi che devono essere resi dal Sistema dipartimentale

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
3	16	ST	R		Patient ID (Internal ID)	Identificativo Paziente
5	48	XPN	R		Patient Name	Cognome^Nome
7	8	DT	R		Date of Birth	Data di Nascita aaaammdd
8	1	IS	R	0001	Sex	Sesso

✓ Il campo 3 ”Identificativo Paziente “ proviene dall’Anagrafe Sanitaria

ORM – PV1 attributes – (Prenotazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	1	IS	R	0004	Patient Class	Tipo Paziente E/I
5	20	CX	O		Preadmit Number	Numero nosologico solo per Interni
19	20	CX	O		Visit Number	Nr. Prenotazione CUP
44	26	TS	O		Admit Date/Time	Data dell’ impegno

ORM - ORC attributes (appuntamento)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
1	2	ID	R	0119	Order Control	SN (local order RIS)
2	22	EI	R		Placer Order Number
3	22	EI	C		Filler Order Number	idprestazioneris^RISEBIT Es. 215656^RISEBIT
4	22	EI	R		Placer Group Number	Nr. Appuntamento

ORM - OBR – attributes – (Prestazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	11	EI	R		Placer Order Number	Ridprestazioneris^RISEBIT Per le prestazioni aggiunte da RIS ad appuntamenti CUP Es. R215656^RISEBIT
3	22	EI	C		Filler Order Number	idprestazioneris^RISEBIT Es. 215656^RISEBIT
4	000	XX	X		Xxxxxxxxx Xxxxxxx XX	CodPrestazioneCUP - lateralità^descriz. Prestazione
21	60	ST	R		Filler Field 2 +	CodiceUnitaOperativa erogante È il codice dell’agenda
27	200	TQ	O		Quantity/Timing	1 ^Data prenotazione (yyyyMMddHHmm)

ORU^R01 – Invio del Referto

Sul Servizio questo evento viene generato alla convalida del referto.

Composizione del messaggio, in riferimento allo standard HL7 2.3.1, ed al Technical Framework versione 5.5 di IHE:

ORU R01	Structured Report Export
MSH	Message Header
PID	Patient Identification
PV1	Patient Visit
ORC	Common Order
OBR	Order Detail
{OBX}	Observation Results

o Viene gestita la molteplicità per il segmento OBX pertanto è possibile inviare in un unico messaggio il Referto in formato completo (RTF o PDF) ed il contenuto del referto (TXT) per la consultazione su Web.

o Viene generato un unico messaggio anche per un referto riferito a più esami

ORU - PID attributes

Vengono descritti i contenuti informativi minimi che devono essere resi nel PID dal Sistema dipartimentale

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
3	16	ST	R		Patient ID (Internal ID)	Identificativo Paziente
5	48	XPN	R		Patient Name	Cognome^Nome
7	8	DT	R		Date of Birth	Data di Nascita aaaammdd
8	1	IS	O	0001	Sex	Sesso
11	106	XAD	R	0001	Patient Address	^^^^CodiceComuneNascita^^BR

ORU – PV1 attributes – (Prenotazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	1	IS	R	0004	Patient Class	Tipo Paziente E/I
9	60	XCN	R	0010	Consulting Doctor	Codice Fiscale^Cognome^Nome medico refertante
19	20	CX	O		Visit number	È quello trasmesso da CUP nei messaggi ORM relativi alle nuove prenotazioni
44	26	TS	O		Admit Date/Time	Data della prenotazione

ORU - ORC attributes (appuntamento)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	11	EI	O		Placer Order Number	non valorizzato
3	22	EI	C		Filler Order Number	non valorizzato
4	22	EI	R		Placer Group Number	Nr. Appuntamento
12	120	XCN	O		Entered By	Codice^Cognome^Nome Medico Richiedente
17	60	CE	R		Entering Organization	Codice^Descrizione Entità Richiedente

ORU - OBR – attributes – (Prestazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	11	EI	O		Placer Order Number	non valorizzato
4	000	XX	X		Xxxxxxxxx Xxxxxxx XX	Codice esame fittizio^descriz. Prestazione fittizia Es. CODICEESAME^DESCRIZIONEESAME
27	200	TQ	O		Quantity/Timing	Data della prenotazione

ORU - OBX – attributes – (Prestazione)

SEQ	LEN	DT	OPT	TBL#	ELEMENT NAME	CONTENUTO
2	3	ID	R	0125	Value Type	ED per i referti incapsulati (PDF, PDF firmato)

3	80	CE	R		Observation Identifier	idServizio^Codice Servizio^INTEMA
4	20	ST	R		Observation Sub-ID	Id del Dipartimentale (sempre lo stesso anche in caso di rivali dazioni o addendum)
5	65536	*	C		Observation Value	Referto
11	1	ID	R	0085	Observation Result Status	F
13	20	ST	O	00581	User Defined Access Checks	FT-RT-FFT-FRT-TX-NR
14	26	TS	R		Date/Time of the Observation	Data validazione referto o data di firma digitale

✓ Il campo OBX-13 “User Defined Access Checks” contiene il formato del referto inserito nel campo 5:

FT = Pdf non Firmato; RT = RTF non Firmato; FFT= PDF Firmato; FRT= RTF Firmato; TX = Testo; NR=Testo del referto non presente

✓ Il campo 5 “Observation Value” contiene il referto.

APPENDICE B

ELETTROCARDIOGRAFI IN DOTAZIONE

N. Invent.	REPARTO	MARCA	MODELLO	RETE
1028	AMBULATORIO CARDIOLOGIA	HP	PAGE WRITER 2000	NO
3526	AMBULATORIO CARDIOLOGIA	HP	PAGE WRITER XLi	NO
997	AMBULATORIO CARDIOLOGIA	HP	PAGE WRITER XLi	NO
	AMBULATORIO CARDIOLOGIA (EMOD.)	ET MEDICAL DEVICES SPA	CARDIETTE DAEDALUS VIEW	NO
1552	AMBULATORIO CARDIOLOGIA (UTIC)	ET MEDICAL DEVICES SPA	CARDIETTE DAEDALUS VIEW	NO
1092	AMBULATORIO CARDIOLOGIA X.	XXXXXX	XXXXXXXX	SI
1112	AMBULATORIO CARDIOLOGIA R.	ET MEDICAL DEVICES SPA	CARDIETTE DAEDALUS VIEW	NO
3318	AMBULATORIO CARDIOLOGIA R.	GE	MAC 1200 ST	NO
3319	AMBULATORIO CARDIOLOGIA R.	GE	MAC 1200 ST	NO
1088	AMBULATORIO CARDIOLOGIA R.	REMCO ITALIA	CARDIOLINE DELTA 3 PLUS	NO
1091	AMBULATORIO CARDIOLOGIA R.	SIEMENS	MEGACART	NO
1747	CARDIOANESTESIA E RIANIMAZIONE	FUKUDA DENSHI CO LTD	FX 7402 CARDI-MAX	NO
1748	CARDIOANESTESIA E RIANIMAZIONE	FUKUDA DENSHI CO LTD	FX 7402 CARDI-MAX	NO
850	CARDIOLOGIA EMODINAMICA	HP	PAGE WRITER XLi	NO
3560	CARDIOLOGIA MEDICA	GE	MAC 1600	SI
3565	CARDIOLOGIA MEDICA	GE	MAC 1600	SI
996	CARDIOLOGIA MEDICA	HP	PAGE WRITER XLi	NO
2219	CARDIOLOGIA PEDIATRICA	ET MEDICAL DEVICES SPA	CARDIETTE DAEDALUS 346	NO
	CARDIOLOGIA PEDIATRICA	GE	MAC 1600	SI
2217	CARDIOLOGIA PEDIATRICA	REMCO ITALIA	CARDIOLINE DELTA 3 PLUS	NO
1049	CARDIOLOGIA RIABILITATIVA	ET MEDICAL DEVICES SPA	CARDIETTE DAEDALUS VIEW	NO
3566	CARDIOLOGIA RIABILITATIVA	GE	MAC 1600	SI
3567	CARDIOLOGIA RIABILITATIVA	GE	MAC 1600	SI
3568	CARDIOLOGIA RIABILITATIVA	GE	MAC 1600	SI
865	CHIRURGIA CARDIOVASCOLARE	HP	PAGE WRITER SLS	NO
1274	DIALISI	FUKUDA DENSHI CO LTD	FX 7402 CARDI-MAX	NO
2756	EMATOLOGIA	ESAOTE	P 8000	NO
2247	EMATOLOGIA	ET MEDICAL DEVICES SPA	FX 7402 CARDI-MAX	NO
2975	GERIATRIA	FUKUDA DENSHI CO LTD	FX 7402 CARDI-MAX	NO
750	GERIATRIA	REMCO ITALIA	CARDIOLINE DELTA 3 PLUS	NO
	MALATTIE INFETTIVA	GE	MAC 1600	SI
2899	MALATTIE INFETTIVE	ESAOTE	FX 7402 CARDI-MAX	NO
2857	MALATTIE INFETTIVE	GE	MAC 1200 ST	NO
104	MEDICINA DEL LAVORO	ET MEDICAL DEVICES SPA	CARDIETTE EXCEL 106	NO
121	MEDICINA DEL LAVORO	REMCO ITALIA	CARDIOLINE ETA 150	NO
1812	MEDICINA INTERNA	ESAOTE	P 80 POWER	NO
1814	MEDICINA INTERNA	HP	PAGE WRITER XLS	NO

311	MEDICINA LEGALE	REMCO ITALIA	CARDIOLINE DELTA 3 PLUS	NO
	MEDICINA URGENZA	GE	MAC 1200 ST	NO
	MEDICINA URGENZA	GE	MAC 1200 ST	NO
1578	NEUROLOGIA	EUROCAMINA SRL	CARDIORAPID K 131	NO
1581	NEUROLOGIA	HP	PAGE WRITER 100	NO
2439	ONCOLOGIA MEDICA	ET MEDICAL DEVICES SPA	CARDIETTE DAEDALUS VIEW	NO
	PEDIATRIA	GE	MAC 1600	SI
1934	PNEUMOLOGIA	ESAOTE	4210 ARCHIMED	SI
1931	PNEUMOLOGIA	REMCO ITALIA	CARDIOLINE DELTA 3 PLUS	NO
2288	PRONTO SOCCORSO	FUKUDA DENSHI CO LTD	FX 7402 CARDI-MAX	NO
2306	PRONTO SOCCORSO	FUKUDA DENSHI CO LTD	FX 7402 CARDI-MAX	NO
	PRONTO SOCCORSO	GE	FX 7402 CARDI-MAX	NO
2292	PRONTO SOCCORSO	PHILIPS	PAGE WRITER 000	XX
0000	XXXX	XXXXXX XXXXXX XX LTD	FX 7402 CARDI-MAX	NO
0000	XXXX	XXXXXX XXXXXX XX LTD	FX 7402 CARDI-MAX	NO
	UTIC	GE	FX 7402 CARDI-MAX	NO
	UTIC	GE	MAC 1200 ST	NO
	UTIC	GE	MAC 1200 ST	NO
	UTIC	GE	MAC 1200 ST	NO
	UTIC	GE	MAC 1600	SI
	UTIC	GE	MAC 1600	SI
	UTIC	GE	MAC 1600	SI
	UTIC	GE	MAC 1600	SI
	UTIC	GE	MAC 1600	SI

REGISTRATORI E SISTEMI DI LETTURA HOLTER IN DOTAZIONE

Q.tà	TIPOLOGIA	MARCA	MODELLO
19	REGISTRATORE HOLTER ECG	DMS	DMS 300-7
11	REGISTRATORE HOLTER PRESSORIO 90207-32	SPACELAB	SP90207
4	REGISTRATORE HOLTER ECG	MORTARA INSTRUMENTS	77165-001
Q.tà	TIPOLOGIA
4	HOLTER CARDIOSCAN II
3	SPACELAB MEDICAL
1	H SCRIBE MORTARA

SISTEMI PER PROVE DA SFORZO IN DOTAZIONE

UNITA' OPERATIVA	TAPPETO/CICLO	SOFTWARE
SERVIZI DI CARDIOLOGIA	RAM 770 M	NORAV PC ECG SRESS V.5.0.522
MEDICINA NUCLEARE	RUNNER	NORAV PC ECG SRESS V.5.0.523
CARDIOLOGIA RIABILITATIVA	LODE - ANGIO V2	LODE ERGOMETRY MANAGER
CARDIOLOGIA MEDICA	RAM 770 CE	NORAV PC ECG SRESS V. 4.5.5
CARDIOLOGIA MEDICA	LODE - ANGIO V2	LODE ERGOMETRY MANAGER
CARDIOLOGIA MEDICA	RAM 770 CE	NORAV PC ECG SRESS X. 0.0.00
XXXXXXXXXXX	X-XXXX - XX
CARDIOLOGIA PEDIATRICA		CARDIOSOFT V. 6.5