Scenario 1: comprare un dispositivo biomedico

Quando si compra e si implementa un nuovo dispositivo in un ospedale o in una clinica, a seconda delle applicazioni dei sistemi aziendali (CIS, EMR, EHR) e delle capacità (HL7) presenti in loco, implementare un dispositivo con i requisiti di integrazione di IHE può fornire molti vantaggi.

Specificando i requisiti di integrazione per il sistema che si sta acquistando, è poi semplice scegliere quali Profili di Integrazione IHE e quali Attori IHE si vuole che siano supportati. Alcuni profili inoltre, includono alcune opzioni che forniscono funzionalità aggiuntive che si possono decidere di selezionare.

I Profili di Integrazione attinenti all'acquisto di un dispositivo per la cura del paziente sono DEC e ACM che verranno descritti con maggior dettaglio nel prossimo paragrafo.

Identificare chiaramente gli obiettivi organizzativi è importante per la definizione dei requisiti utili per l'acquisto dell'apparecchiatura. Ogni Profilo di Integrazione IHE è progettato per incontrare un insieme specifico di obiettivi organizzativi. Di seguito è presentata una lista di finalità che un'istituzione potrebbe raggiungere nell'acquisto di nuovo un dispositivo o di un sistema (per esempio un nuovo CIS) e dei contributi che ogni Profilo di Integrazione porta per sostenere questi obiettivi.

1) Ridurre gli errori e migliorare la cura del paziente DEC:

• Evita o riduce gli errori di immissione manuale dei dati nel dispositivo recuperando l'informazione demografica del paziente da sistemi principali ADT per mezzo di un'interfaccia HL7 e vincolando l'informazione al dispositivo.

• Evita o riduce gli errori di immissione manuale dei dati al CIS trasmettendo l'informazione elettronicamente dal dispositivo.

• Evita dati demografici vecchi aggiornandoli in corrispondenza del dispositivo. • Riduce i ritardi nella cura del paziente trasmettendo i dati del dispositivo

elettronicamente, riducendo il numero di passaggi manuali e permettendo che i dati vengano esaminati attraverso l'impresa.

• Mitiga il rischio di perdita dei dati. ACM:

✔ Permette la centralizzazione di allarmi e notifiche.

✔ Migliora il tempo di consegna della notifica di allarme al medico. ✔ Migliora il tempo di risposta all'allarme.

✔ Riduce la confusione dovuta agli allarmi.

✔ Riduce i livelli di emissione del rumore in ambiente sanitario. ✔ Permette l'analisi e la gestione degli eventi passati di allarme. ✔ Migliora la sicurezza inviando allarmi al personale appropriato 2) Incrementare la produttività:

DEC:

• Risparmia il tempo di immissione manuale dei dati abilitando la comunicazione con sistemi principali ADT che forniscono elettronicamente l'informazione al dispositivo.

• Migliora l'efficienza e l'omogeneità della raccolta di dati inviandoli direttamente e regolarmente al CIS.

• Riduce i ritardi nel processo di resoconto/segnalazione. Il dispositivo invia i dati completi o i dati in avanzamento (in corso) al CIS, permettendo una diagnosi iniziale e finale più veloce.

• Riduce il tempo amministrativo del personale registrando elettronicamente i dati invece di inserirli manualmente.

• Evita la perdita di dati attraverso la loro trasmissione elettronica al CIS. ACM:

✔ Migliora la qualità dell'allarme e il tempo di risposta.

✔ Permette di gestire le varie priorità di allarme efficientemente ed efficacemente. 3) Ridurre i costi:

DEC:

• Riduce i passi supplementari nel workflow utilizzando una comunicazione automatica fra il dispositivo e il CIS.

• Migliora la precisione del fatturato.

• Promuove la validazione automatizzata con la cartella elettronica più completa. 4) Ridurre i costi/tempi di avvio del sistema:

Tutti i profili:

• Eliminano la necessità di creare specifiche interfacce personalizzate per il dispositivo biomedico, salvando il tempo e la spesa dell'ospedale.

una specifica dettagliata per un'interfaccia potente, sostenuto e testata da molti venditori.

• Riducono il tempo e i costi di verifica fra sistemi. Molte combinazioni di sistemi sono già state direttamente testate durante i Connectathon.

• Riducono il tempo e i costi di mantenimento di interfacce personalizzate introducendo una singola interfaccia IHE al posto di più interfacce personalizzate. Condurre la richiesta del supporto IHE nel RFP (Request for Proposal- richiesta di proposta, appoggio) è semplice perché si dichiara quali Profili di Integrazione IHE e opzioni si vuole che il sistema supporti e quali Attori IHE il sistema dovrebbe avere in ogni profilo. Le seguenti sono dichiarazioni campioni per specificare i profili e gli attori per un dispositivo di acquisizione completamente rappresentato:

1) "Il dispositivo supporterà il profilo di integrazione DEC nel ruolo dell'attore Device Observation Reporter (DOR)".

2) "Il dispositivo supporterà il profilo di integrazione DEC nel ruolo dell'attore Device Observation Filter (DOF)".

3) "Il dispositivo supporterà il profilo di integrazione ACM nel ruolo dell'attore Alarm Reporter (AR)".

L'utente invia il RFP al produttore che risponde comunicando i propri dispositivi e /o sistemi che soddisfano le richieste dell'utente.

Mentre si può scegliere di passare direttamente all'invio del RFP a un esteso gruppo di venditori potenziali, si possono trovare i venditori che hanno prodotti con le capacità di integrazione IHE facendo riferimento a sorgenti pubbliche come gli Integration Statements o i risultati del Connectathon. In effetti, il produttore può rispondere al RFP direttamente inviando l'Integration Statement.

In alcuni casi i profili di integrazione non costano nulla ma fanno parte integrante delle capacità del prodotto. Il altri casi, i produttori possono includere i profili con un costo aggiuntivo ma gli operatori sanitari dovrebbero insistere che ogni costo aggiuntivo per i profili IHE sia minore del costo dei servizi di integrazione che non utilizzano i profili di integrazione. Si impiegano meno risorse, tempo e soldi per progettare e implementare i profili di integrazione rispetto a interfacce personalizzate per entrambi i produttori e gli operatori sanitari.

Per quanto riguarda la verifica dell'impatto economico che ha l'implementazione dei profili di integrazione, bisogna considerare che essi permettono di gestire efficacemente l'insieme dei sistemi informativi integrati necessari per sostenere un sistema sanitario più efficace. L'alternativa -costruire interfacce specifiche per ogni luogo- è più costosa e richiede il mantenimento di queste interfacce personalizzate per tutta la durata di vita del sistema coinvolto. L'integrazione attraverso IHE è meno costosa all'inizio e rende gli acquisti futuri più facili da pianificare e da eseguire, come pure più produttivi nella fornitura di funzionalità pregiate.

Il processo di configurazione e di implementazione

Come primo passo bisogna considerare i cambiamenti nel workflow: i profili PCD sono progettati per trasmettere dati, ordini o allarmi per facilitare un workflow clinico efficiente. Per esempio, essi eliminano la necessità di immettere informazioni sul paziente nel dispositivo e di trascriverle nella cartella elettronica, perché la comunicazione tra dispositivo e EHR è automatica. Essi permettono anche che i dati del dispositivo siano immediatamente disponibili

per la visualizzazione.

Per conseguire il vantaggio pieno di questi cambiamenti ci sono numerosi compiti che devono essere eseguiti nel modo corretto: una valutazione dello stato corrente, una valutazione poi dello stato futuro e un'analisi delle differenze tra i due stati aiuteranno a identificare i cambiamenti significativi richiesti.

Il passo successivo consiste nel confermare che il dispositivo è operativo secondo il Profilo IHE realizzato. Per esempio, considerando il profilo DEC, si devono valutare le seguenti situazioni: la prima è che, per i dispositivi, è importante che le informazioni demografiche del paziente (trasmesse attraverso messaggi ADT) siano disponibili in corrispondenza del dispositivo attraverso un CIS; in secondo luogo, si deve verificare che le informazioni critiche siano disponibili sul dispositivo e che le informazioni spedite dal dispositivo al CIS siano corrette. Infine, si deve confermare che le informazioni corrette siano mantenute controllando le informazioni associate ai comandi.

Il seguente è un esempio della lista ad alto livello di prove che dovrebbero essere eseguite su un nuovo dispositivo con il profilo DEC:

– Conferma dello scenario

1. Verificare che le informazioni demografiche sul paziente, incluse quelle di collocazione, sul dispositivo siano corrispondenti a quelle sul CIS.

2. Confrontare i parametri fisiologici visualizzati sul dispositivo con i dati mostrati nel CIS e verificare la corrispondenza.

3. Verificare che i dati vengano inviati come sono stati programmati.

4. Verificare che i dati non siano persi quando si verifica un'interruzione nella comunicazione.

Per ognuna di queste aree, è necessario sviluppare una serie di test dettagliati con la serie di dati appropriata. Ad esempio, quando un dispositivo invia dati fisiologici al CIS, devono essere considerate le seguenti tipologie di voci:

a. Quale tipo di dati può raccogliere il dispositivo? b. Quali tipi di dati può inviare il dispositivo? c. Quali tipi di dati può ricevere il CIS?

d. Quanti dati possono essere memorizzati nel caso di una perdita di connettività Sviluppare le prove che esigono le aree sopra identificate (per esempio, controllare tutti i parametri per raggiungere la precisione).

– Verificare le informazioni che un dispositivo può mostrare e inviare

1. Sviluppare test per esaminare tutti i dati e verificare che ognuno dei campi DEC sia restituito e sia mostrato sul dispositivo (nome paziente, identificativo (ID) paziente, ecc). Sviluppare prove per esaminare tutte le informazioni risultanti, che sono state generate dal dispositivo, trasformate nei messaggi risultanti HL7 che sono trasmessi al CIS. Ad esempio controllare che i parametri fisiologici come SPO2, frequenza del battito cardiaco, pressione del sangue che sono visualizzati nel CIS (dopo essere stati inviati dal dispositivo attraverso messaggi HL7) corrispondano a quelli sul dispositivo (con attenzione speciale all'unità di misura e alla nomenclatura).

Ci sono anche alti metodi per confermare i dati e le transazioni descritti nel paragrafo 4.2.5. Si devono poi considerare le possibili problematiche di installazione. Anche con IHE, l'installazione non è completamente “plug-and-play” e quindi i sistemi non sono auto-configuranti. Informazioni richieste come l'indirizzo IP di interfaccia HL7 e le interfacce per la connessione delle unità esterne (uscite) devono essere coordinate tra il dispositivo biomedico e il CIS. Ci dovrebbero essere una pre-coordinazione dei parametri da scambiare e della frequenza delle transazioni. La nomenclatura e le unità di misura dovranno anche essere coordinate e verificate tra il CIS e i dispositivi biomedici. Inoltre, questo passo dovrebbe essere coordinato con leadership clinica e con punti di contatto per assicurare che i moduli di flusso contengano informazioni richieste e desiderate per l'uso in diversi ambienti clinici di impresa (per esempio: i parametri specifici richiesti per l'ispezione durante il giro nei reparti di terapia intensiva (ICU – Intensive Care Unit), reparti medici/chirurgici, ecc).

Infine, è necessario identificare e risolvere eventuali problemi con sistemi proprietari, cioè problemi che si riscontrano quando si ha a che fare con sistemi che non supportano i profili IHE ma che conservano una propria conformazione che rende difficile l'integrazione nel momento in cui la si vuole sviluppare. I profili di Integrazione sono costruiti supponendo che tutti i sistemi principali li supportino. Se alcuni sistemi, invece, non supportano i profili selezionati ma supportano gli standard su cui il profilo è costruito (ad esempio HL7), qualche vantaggio è ancora possibile. IHE incoraggia gli implementatori ad assicurare che i prodotti conformi con il TF IHE soddisfino anche i requisiti completi degli standard essendo alla base di IHE: ciò consente ai prodotti di interagire, sebbene a un livello inferiore di integrazione, con prodotti che sono stati implementati in conformità con quegli standard ma non in conformità completa con il TF IHE. Se infine si hanno sistemi insufficienti, si deve considerare come lavorare intorno alle insufficienze nel breve termine e quando prevedere la sostituzione o il potenziamento di quei sistemi con Profili di Integrazione IHE nel futuro.

L'interoperabilità tra il CIS e un dispositivo biomedico consente il flusso elettronico dei parametri fisiologici e operativi del dispositivo dal letto del paziente alla cartella clinica. La stessa interoperabilità può ancora essere disponibile quando si collega un dispositivo configurato in accordo con le specifiche IHE ad un CIS che non supporta i profili IHE ma ha le sue caratteristiche proprie (vale anche il contrario: un dispositivo biomedico non conforme alle specifiche IHE collegato a un CIS conforme a IHE). L'organizzazione dovrebbe richiedere una specificazione riguardo all'interfaccia HL7 corrente del CIS per determinare come integrare il dispositivo IHE con un non-IHE CIS . Di seguito si riportano le brevi direttive da seguire per verificare l'interoperabilità tra il dispositivo IHE e il non-IHE CIS nel caso in cui si utilizzi per il dispositivo il profilo DEC.

Nel profilo DEC, il dispositivo invia messaggi HL7 in un formato specifico con dei vincoli oltre alle normali norme HL7. I seguenti standard sono utilizzati dalle transazioni IHE PCD DEC:

• HL7 versione 2.6

• ISO/IEEE 11073-10201 Domain Information Model • ISO/IEEE 11073-10101 Nomenclature

Se anche il CIS supporta questi standard, il passo successivo è confermare che gli attributi critici forniti nei messaggi dal dispositivo sono interpretati nel CIS.