Implantable Device Cardiac Observation (IDCO)

Il profilo IDCO ([51],[52],[57]) specifica la traduzione, la trasmissione e l'elaborazione degli elementi di dati discreti e degli allegati di report associati a interrogazioni (osservazioni) o messaggi di dispositivi cardiaci. Descrive quindi un mezzo per trasferire l'informazione da un dispositivo cardiaco impiantabile interrogato a sistemi di gestione dell'informazione (Figura 4.25).

I cardiologi seguono pazienti con dispositivi cardiaci impiantabili da più fornitori. Questi dispositivi sono classificati come pacemaker (dispositivo elettronico fissato sotto la pelle che fornisce un battito cardiaco normale con incentivazione elettrica del muscolo di cuore, utilizzato in certe condizioni di cuore), defibrillatori cardioverter impiantabili (dispositivo elettronico fissato sotto la pelle utilizzato per opporsi alla fibrillazione del muscolo cardiaco e ripristinare il battito cardiaco normale applicando una scossa elettrica), dispositivi di resincronizzazione cardiaca (Implantable Cardiac Resynchronization Therapy (CRT): dispositivo elettronico fissato sotto la pelle utilizzato per ristabilire sincronia ventricolare in uno sforzo per migliorare efficienza sinistra ventricolare) e dispositivi di monitor cardiaci. Un altro dispositivo protagonista è il programmatore del dispositivo cardiaco (Cardiac Device Programmer) che è usato per interrogare, monitorare e ottenere altri parametri operativi non invasivi da un pacemaker, un defibrillatore o un dispositivo di resincronizzazione cardiaca impiantabili.

L'interrogazione di un dispositivo cardiaco è svolta come parte del follow-up del paziente o in clinica o da un'ubicazione remota. Le informazioni raccolte riguardanti il dispositivo sono: l'identificativo, le impostazioni della terapia, la diagnostica e la verifica del dispositivo. Queste interrogazioni (richieste o non richieste) sono eseguite da apparecchiature esclusive del fornitore. Per ottenere un miglioramento dell'efficienza del workflow nelle pratiche di Cardiologia e Elettrofisiologia dalla gestione delle informazioni sulle interrogazioni dei dispositivi impiantabili

di controllo del ritmo in un sistema centrale come un EHR o un sistema di gestione clinico dei dispositivi, l'IDCO definisce una traduzione e trasferimento basati su standard delle informazioni sommarie di interrogazione del dispositivo dal sistema di interrogazione al sistema di gestione di informazioni.

Con l'aumento di utilizzo di sistemi EHR, della connessione in rete di sistemi di follow-up in clinica e remoti per dispositivi cardiaci impiantabili e per la crescita continuata del mercato di dispositivo impiantabile cardiaco, l'importanza di questo profilo per i medici è diventata più evidente.

L'utilizzo del profilo migliora l'efficienza e la qualità del processi clinici collegati [60]: – singolo punto di accesso per le informazioni;

– standardizzazione dei processi di workflow;

– automazione di processi che attualmente sono manuali per la collezione l'analisi e l'aggregazione dei dati;

– miglioramento della qualità di cura consentendo follow-up più frequenti che allertano i medici riguardo problemi precocemente.

Figura 4.25 – Workflow IDCO

Descrizione degli attori

Attori del profilo IDCO:

• Implantable Device Cardiac Reporter (IDCR): riceve i dati dai dispositivi impiantabili e li mappa in transazioni che forniscono sintassi e semantica compatibili e standardizzate. • Implantable Device Cardiac Consumer (IDCC): riceve i dati dal IDCR

Descrizione delle transazioni

Transazioni del profilo IDCO:

• Communicate IDC Observation (PCD-09): le osservazioni, le misure o i report sono inviati utilizzando un messaggio di osservazione HL7, non richiesto, e con il corrispondente messaggio ACK di ritorno al IDCR.

Diagramma attori/transazione (Figura 4.27) e relativa tabella (Tabella 4.17):

Figura 4.26 – Diagramma attori/transazioni IDCO

Actors Transactions Optionality Section in Vol. 2

Device Observation Reporter Send Observation [PCD-09] R PCD TF-2: 4.12 Device Observation Consumer Send Observation [PCD-09] R PCD TF-2: 4.12

Tabella 4.17 – Attori e transazioni

Casi d'uso

1. Dispositivo cardiaco impiantabile in un follow-up clinico

Un paziente con un dispositivo cardiaco impiantabile sta eseguendo il follow-up dopo l'impianto. L'infermiere interroga il dispositivo utilizzando un programmatore del dispositivo cardiaco che estrae i dati del dispositivo da esso stesso. L'infermiere rivede e verifica i dati e inizia a trasferirli dal programmatore a un sistema di traduzione. Un sottoinsieme necessario di dati che rappresentano un sommario è convertito dal traduttore da un formato proprietario a un formato standard HL7. I dati sono poi trasmessi utilizzando messaggi HL7 a EHR o a sistemi di gestione clinica dei dispositivi. Questo sommario di dati è inviato in un messaggio di osservazione non richiesto.

Nell'area dell'elettrofisiologia, un "programmatore" è un termine comunemente utilizzato per descrivere un computer specializzato che è capace di comunicare con un dispositivo impiantato. I programmatori sono utilizzati per interrogare i dispositivi impiantati e il "programma", o per fare modifiche nelle impostazioni del dispositivo cardiaco.

In questo caso di utilizzo il sistema di traduzione è un sistema di computer di informazione clinica che può ricevere dati strutturati proprietari dal programmatore ed eseguire i protocolli di trasformazione e di comunicazione necessari per comunicare efficacemente con l'EMR.

Gli elettrocardiogrammi non sono attualmente indirizzabili con lo standard HL7 ma possono essere inviati con un PDF allegato al messaggio HL7.

Nel caso di utilizzo il sistema di traduzione si equipara a IDCR e l'EHR o il sistema di gestione clinica dei dispositivi si equipara a IDCC. Il messaggio del dispositivo cardiaco formattato HL7 è la transazione [PCD-09].

2. Dispositivo cardiaco impiantabile in un follow-up clinico con programmatore in rete che traduce l'informazione

Stessa situazione del caso precedente ma con le seguenti modifiche: il programmatore Implantable Device Cardiac Reporter IDCR Implantable Device Cardiac Consumer IDCC Dispositivo

comunica direttamente con un EHR o sistema di gestione clinica del dispositivo, agendo come un sistema di traduzione. Il programmatore assume il ruolo di IDCR.

3. Dispositivo cardiaco impiantabile in un follow-up remoto:

Le porzioni dei casi precedenti si applicano anche qui, ma il dispositivo è seguito a distanza. Il paziente presenterà un dispositivo di interrogazione localizzato fuori dalla clinica (per esempio nella sua casa) che catturerà lo stato del suo dispositivo impiantato e trasmetterà le informazioni a un sistema di traduzione. Il sistema di traduzione converte i dati in un messaggio HL7 e comunica i dati di riepilogo all'EHR della clinica. IDCR è raggruppato con il Secure Node, attore del Profilo ATNA, per assicurare comunicazioni per follow-up remoti se i dati sono inviati attraverso una rete non sicura.

4. Monitoraggio remoto di dispositivi cardiaci impiantati

Il sistema traduttore descritto nel caso di utilizzo precedente può essere implementato come un servizio di una terza parte, per esempio il produttore di dispositivo o un servizio di monitoraggio. Questo sistema può raccogliere dati forniti su una base periodica per captare per tempo le tendenze e i problemi, o fornire altre informazioni sull'evento. Questo sistema può anche fornire diversi tipi di servizi a valore aggiunto, come aggregazione e analisi di dati, andamenti, report statistici e la capacità di esaminare e verificare i dati prima di inviarli all'EMR. A seconda delle impostazioni selezionabili di utente nel sistema traduttore, le informazioni dettagliate che riguardano lo stato corrente del paziente e i rapporti possono essere inviati al sistema di destinatario. Il contesto IHE è uguale al caso precedente. L'aggregazione o la traduzione di dati aggiuntiva può essere inviata come un allegato PDF al messaggio HL7. È probabile che questi tipi di servizi a valore aggiunto siano forniti per una parte che invierà i risultati su Internet. Si consiglia che IDCR sia raggruppato con il Secure Node, attore del Profilo ATNA, per assicurare comunicazioni per follow-up remoti se i dati sono inviati attraverso una rete non sicura.

Flusso del processo IDCO (Figura 4.27)

Figura 4.27 – Flusso del processo IDCO

Note – il Dispositivo (Device), l'Interrogatore (Interrogator) e i passi da 1 al 4 e il 7 sono informativi e non sono attori o transazioni formali del profilo IDCO.

1. Send Interrogation (Inviare l'interrogazione) → il Dispositivo invia le informazioni in un modo proprietario (dipendente dal produttore del dispositivo) all'Interrogatore.

2. Send Interrogation (Inviare l'interrogazione) → l'Interrogatore invia le informazioni in un modo proprietario (dipendente dal produttore del dispositivo) a IDCR.

3. Validate and Review (Convalidare e esaminare) → IDCR convalida le informazioni. Questo può includere l'esame e l'approvazione delle informazioni da parte del medico. 4. Translate Information (Tradurre l'informazione) → IDCR traduce/mappa/trasforma le

informazioni nel formato corretto HL7.

5. Send Observation (Inviare l'osservazione) → IDCR invia le informazioni sul dispositivo a IDCC utilizzando la transazione [PCD-09].

6. Recive Observation (Ricevere l'osservazione) → IDCC riceve il messaggio di osservazione.

7. Process Observation (Elaborazione dell'osservazione) → IDCC più avanti elabora il messaggio di osservazione per inclusione all'interno di prodotti derivati, come rapporti clinici, database o risultati trans-coded/riformattati risultati.

Considerazioni sull'identificazione del paziente

Identificativo Pazienti: i sistemi del fornitore del dispositivo che forniscono le osservazioni e le cliniche che ricevono le osservazioni. A seconda dei regolamenti locali, ogni fornitore del dispositivo impiantabile cardiaco può essere obbligato a mantenere un registro che mappa un identificativo univoco del dispositivo con il paziente in cui è impiantato. Le informazioni sull'identificazione pazienti specifiche non sono di solito memorizzate nel dispositivo ma sono rese disponibili nel registro e o da altri mezzi. Di conseguenza a IDCR è richiesto solo di inviare questo identificativo (del dispositivo) che rappresenta il paziente in relazione al dispositivo per un dispositivo impiantato come parte della transazione PCD-09. L'identificativo è, dalla convenzionale normativa, una concatenazione di: un identificativo esteso univoco dell'industria produttrice, un numero univoco del modello prodotto, un numero seriale univoco del produttore. Questo profilo specifica un attore, IDCC, come il punto terminale per messaggi di osservazione, che avrà pre-coordinato un riferimento incrociato di identificativi dei pazienti attraverso i due Domini di Identificativo Pazienti. Questo sarà fatto memorizzando l'identificativo del dispositivo unico all'interno del record del paziente. Questo di solito sarà l'identità unica del paziente ma potrebbe essere l'ubicazione del paziente in situazioni di emergenza.

In alcuni casi IDCR avrà informazioni dettagliate sull'identificazione del paziente come il nome, indirizzo, ecc. In questi casi IDCR può inviare queste informazioni come parte della transazione PCD-09.

Considerazioni sulla sicurezza

Questo profilo non richiede l'utilizzo di ATNA, profilo del dominio ITI che autentica i sistemi usando certificati e invia eventi di verifica a un destinatario per aiutare l'implementazione delle politiche confidenziale(ATNA – Audit Trial and Node Authentication). ATNA stabilisce le caratteristiche di un nodo base sicuro (Basic Secure Node): (a) descrive l'ambiente di sicurezza (identificazione utente, autorizzazione, controllo all'accesso, ecc.) assunto per il nodo così i revisori della sicurezza possono decidere se questo corrisponde ai lori ambienti; (b) definisce i requisiti elementari di audit per il nodo; (c) definisce i requisiti elementari di sicurezza per le comunicazione del nodo usando TLS o funzionalità equivalenti; (d) stabilisce le caratteristiche della comunicazione di messaggi audit tra il Basic Secure Node e i nodi Audit Repository che collezionano le informazioni audit (di controllo); (e) definisce un attore Secure Application per la descrizione delle configurazioni del prodotto che non sono in grado di incontrare tutti i requisiti del Secure Node. Le considerazioni di sicurezza ATNA richiedono l'uso del Secure Node. Il Secure Application è definito per permettere alle configurazioni dei prodotti di indicare che il prodotto è pronto per essere facilmente integrato in un ambiente Secure Node perché esegue tutte le funzioni di sicurezza relative che sono direttamente collegate alla funzione applicativa. Ci sono numerosi modelli di implementazione per questo profilo che non richiedono la trasmissione di dati su reti pubbliche tra cui intra-institutional, VPN, ecc. Tuttavia, quando sono utilizzate le reti pubbliche, ATNA è un'opzione per il trasporto sicuro su quelle reti. Si consiglia che IDCR sia raggruppato con il Secure Node, attore del Profilo ATNA, per assicurare comunicazioni per follow-up remoti se i dati sono inviati attraverso una rete non sicura.

4.3.3.1 PCD-09 Communicate IDC Observation Ruoli (Figura 4.28):

Ruolo: emette l'osservazione come un messaggio ORU HL7 su completamento dell'osservazione. Questo messaggio contiene i dati discreti dell'osservazione e/o un PDF contenente i dati visualizzabili relativi all'osservazione.

➢ Attore: IDCC

Ruolo: riceve il messaggio ORU HL7 e fornisce qualche processing specifico per l'implementazione. Questo può includere: la creazione di report, l'integrazione dell'informazione in EHR, la creazione di dati derivati (trend, analisi, dati riformattati, statistiche di popolazione, ecc.). Se necessario, concilierà l'identificativo del paziente usando una funzione di mappatura specifica per l'implementazione.

Figura 4.28 – Diagramma degli attori coinvolti nella transazione Standard di riferimento:

• HL7 Messaging Standard v2.5

• ISO 19005-1. Document management – Electronic document file format for long-term preservation – Part 1: Use of PDF (PDF/A)

• UCUM: Unified Code for Units of Measure, Regenstrief Institute for Health Care, Indianapolis 2005. Version 1.6

• IEEE 11073_10103 MDC_IDC Nomenclature

Alcuni dati, come l'ECG, possono essere non indirizzati negli standard HL7 e quindi possono essere inviati come allegati PDF al messaggio HL7 utilizzando lo standard ISO 19005-1.

L'informazione contenuta nei messaggi HL7 è codificata utilizzando IEEE 11073_10103 MDC_IDC Nomenclature che deve essere disponibile a livello del IDCR.

Nei casi come quello qui presentato, in cui la comunicazione è remota, IHE raccomanda di raggruppare il IDCR con l'attore Secure Node del profilo ATNA per comunicazioni sicure dei dati se inviati su reti non sicure.

Diagramma di interazione (Figura 4.29):

Figura 4.29 – Diagramma di interazione Implantable Device – Cardiac – Consumer

IDCC

Implantable Device – Cardiac – Reporter IDCR

Communicate IDC Observation

Osservazione HL7 ORU: questo è uno standard di ordini non richiesti e il messaggio di osservazione contiene le osservazioni prese dal dispositivo impiantato. Le informazioni sono codificate utilizzando la nomenclatura IEEE 11073-10103 IDC. Nella nomenclatura IEEE 11073_10103 MDC_IDC ogni termine è discreto, descrive se stesso e corrisponde a un segmento OBX con cui si compongono i messaggi HL7.

Semantiche del messaggio

Il messaggio è un messaggio non richiesto v2.5 ORU dal IDCR al IDCC con un messaggio corrispondente ACK che torna al IDCR. I contenuti del messaggio (in segmenti OBX) sono un insieme richiesto di singole osservazioni o misure trans-coded in segmenti HL7 v2.5 OBX separati e un documento incapsulato facoltativo PDF.

La struttura del messaggio vincolata è data nel Tabella 4.18:

ORU Observation Results Message Usage ^{HL7 Spec} Chapter

MSH Message Header 2

[{ SFT }] Software Segment 2

PID Patient Identification Demographics for id matching 3

[ PV1 ] Patient Visit 3

{ ^{Order Observation Repeat Grouping} BEGIN

OBR Observations Request Clinical context 7

{[NTE]} Notes Section Notes related to OBR

{OBX} Observation results ^{Observations related to the pulse} _generator 7

{[NTE]} Notes Section Notes Related to OBX

} Order Observation Repeat Grouping END

[DSC] Continuation Pointer 2

Tabella 4.18 – Struttura messaggio

Azioni attese

IDCC manda il messaggio di risposta ACK al IDCR.