Capitolo 4. IHE-PCD: linee guida sull'utilizzo degli standard per l'interoperabilità nei
4.2 Il dominio IHE-PCD
4.2.5 Test di approvazione
Una volta che sono stati identificati tutti i Profili IHE, attori e transazioni coinvolti nell'installazione, una lista di Test di Approvazione delle caratteristiche di interoperabilità può essere scritta per ognuno dei sistemi implicati. È preferibile eseguire i Test di Approvazione solo dopo che tutti i sistemi fisici sono stati installati e correttamente collegati alla rete. Il piano dei test dovrebbe includere i seguenti componenti:
• Quali sistemi sono richiesti per eseguire la verifica? • Quali test dovrebbero essere eseguiti?
• Quali dati sono richiesti per eseguire la verifica?
• Come sarà verificato il funzionamento del test e quali strumenti devono essere acquistati per supportare il test di verifica?
• Quali sono gli obiettivi di ogni test?
• È stato predisposto il tempo sufficiente per sviluppare queste specifiche?
Test System Suite (serie di test sul sistema): questo test richiede di includere tutti i sistemi che sono interconnessi. In alcuni casi, sarà necessario configurare un ambiente di test per assicurare che l'ambiente reale non sia occluso dall'esecuzione del test. In altri casi, l'ambiente reale può essere utilizzato ma il tempismo e i dati utilizzati per verificare il sistema dovranno essere pensati con attenzione.
Sviluppo dei test: le strategie dei test dipenderanno da quali sistemi si stanno integrando. Parimenti, la conferma dei risultati dipenderà dalle possibilità dei sistemi che vengono impiegati e dal workflow dell'istituzione stessa. Osservate che se i sistemi non-IHE sono coinvolti nell'impresa, una valutazione aggiuntiva è necessaria per determinare quello che i risultati attesi dovrebbero essere, dal momento che essi possono allontanarsi da quello che avverrebbe in un ambiente IHE completo.
Test Data: I Test Data specifici dipenderanno dai casi d'uso che vengono verificati e da quali dati sono rilevanti per operazioni del sistema. I dati dovrebbero essere rappresentativi di casi reali e includere insiemi completi di informazioni demografiche del paziente e degli ordini e delle informazioni procedurali. In alcuni casi, può essere necessario avere risultati simulati rappresentativi, usando gli emulatori dei dispositivi che emettono gli stessi valori ripetutamente. Un insieme di dispositivi biomedici da numerosi produttori con campi di dati specifici può essere richiesto per verificare completamente le caratteristiche di interoperabilità.
Test Tools: La verifica di risultati può richiedere l'utilizzo di strumenti e più sistemi. Ad esempio, strumenti HL7, l'utilizzo del dispositivo biomedico per visualizzare i risultati, o alternativamente l'utilizzo di un EMR per verificare che le informazioni all'interno dell'EMR contengano gli stessi dati visualizzato sul dispositivo biomedico. Le seguenti sono classi di strumenti che possono essere utilizzati per verificare i risultati:
• Analizzatori HL7 (Parsers): analizzano i campi dei messaggi HL7 e presentano i componenti in un modo più comprensibile.
• NIST (National Institute of Standards and Technology) Test Tools:
➢ ICSGenerator - testa le implementazioni contro il set di standard ISO/IEEE 11073
➢ ValidatePDU - convalida la sintassi e la struttura base dei messaggi
➢ HL7 v2 IHE-PCD Pre-Connectathon Test Tools - Supporta la verifica del messaggio statico HL7 V2 del fornitore IHE-PCD Pre-Connectathon secondo lo Standard HL7, il TF IHE-PCD e i documenti di supplemento, Harmonized Rosetta Terminology Mappings (hRTM) e casi di test.
• Messaging Workbench: verifica la conformità dei messaggi HL7
• MESA (Medical Enterprise Simulators and Analyzer) Tools: Come una parte del processo di verifica IHE, HIMSS e RSNA hanno incaricato lo sviluppo di un insieme di strumenti software dal Laboratorio di Radiologia Elettronico all'Istituto Mallinckrodt di Radiologia, Università Washington di St. Louis. Essi forniscono partner di comunicazione, data test e test plan per consentire ai fornitori di eseguire test di base dato che implementano i TF IHE. Questi test sono limitati in un ambito ma possono essere utili nello sviluppo di piani di test.
4.3 I profili PCD
I profili di integrazione del dominio PCD pubblicati all'interno della versione del TF final-text (in rete ancora come bozza) sono [51]:
• DEC → Device Enterprise Communication: è un profilo di transazioni che descrive i
meccanismi per comunicare i dati dei PCD ai sistemi informativi sanitari. I tipici dati dei PCD includono: dati fisiologici periodici (velocità cardiaca, pressione sanguigna invasiva, velocità di respirazione, ecc.), dati fisiologici aperiodici (pressione sanguigna non invasiva, peso del paziente, output cardiaco, ecc.), e test di laboratorio CLIA waived (o l'equivalente internazionale waiver). I dati possono anche includere informazioni contestuali come l'ID del paziente, identificazione del medico e l'informazione sulla configurazione del dispositivo biomedico del paziente.
• PIV → Point-of-care Infusion Verification: è un profilo di transazioni che supporta la
comunicazione di un ordine di consegna/infusione di medicazione validato dalle cinque regole (Paziente Giusto, Farmaco Giusto, Dose Giusta, Modalità Giusta, Tempo Giusto) da un sistema BCMA (Bedside Computer-assisted Medication Administration) a una pompa di infusione o un sistema di gestione della pompa, così da “chiudere il cerchio”.
• IDCO → Implantable Device Cardiac Observations: è un profilo di transazioni che
specifica un meccanismo per la traduzione, la trasmissione e l'elaborazione di elementi di dati discreti e allegati rapporti associati con le interrogazioni dei dispositivi cardiaci impiantabili (osservazioni).
• RTM → Rosetta Terminology Mapping: è un profilo di contenuti che stabilisce
un'insieme di strumenti (fogli di calcolo Excel e file XML) che mappa le semantiche proprietarie comunicare dai dispositivi biomedici oggi a una rappresentazione standard utilizzando le semantiche ISO/IEEE 11073 e unità di misura UCUM.
Profili addizionali che sono stati o sono in corso di sviluppo ma non hanno ancora i requisiti per essere pubblicati nel final-text del TF sono i seguenti:
✔ SPD → Subscribe to PCD Data: è un profilo di transazioni che supporta la limitazione
dell'informazione trasmessa dall'attore DEC DOR all'attore DEC DOC. È un'opzione del profilo DEC.
✔ DPI → Device Point-of-care Integration: è un profilo di transazioni che si focalizza
sulla connettività dei dispositivi nel punto di cura centrale al paziente, che include interfacce “first link” tra dispositivi o un sistema di dispositivi manager/supervisor. Quest'attività include lo sviluppo iniziale di un white paper, seguito da un numero di profili proposti come: discovery and association (DPI-DnA), che fornisce un supporto per i dispositivi per trovare e associarsi ad altri dispositivi, sistemi di gestione o applicazioni; data reporting (DPI-DR), che fornisce un supporto per la comunicazione base dell'informazione sulla configurazione e sullo status del dispositivo a altri dispositivi, sistemi di gestione o applicazioni; symmetric (bi-directional) communication (DPI-SYM), che fornisce un supporto per la comunicazione bi-direzionale o simmetrica dove un dispositivo non solo riporta la sua configurazione e il suo status interni ma necessita anche di scoprire e acquisire informazioni da altri sistemi e applicazioni; external control.
la comunicazione remota di condizioni di allarme dei dispositivi biomedici nel point-of-care assicurando il giusto allarme con la giusta priorità alle persone giuste con il contenuto giusto (per esempio i dati probatori).
✔ WCM → Waveform Communication Management: è un profilo di contenuti che
estenderà i profili IHE PCD esistenti per fornire un metodo per il passaggio vicino al real-time di dati di forme d'onda usando messaggi di osservazione HL7 v2.
In aggiunta, rapporti tecnici e allegati ai documenti esistenti sono stati sviluppati e includono:
➢ SA → Semantic Architecture White Paper: fornirà una panoramica dei soggetti a volte
sconcertanti della nomenclatura, della terminologia e dei modelli di informazione che sono usati per consentire l'interoperabilità semantica vera delle informazioni dei dispositivi di cura dei pazienti. Configurerà inoltre le fondamenta della nuova terminologia sviluppata che è richiesta per riempire i vuoti che sono stati identificati, specialmente durante lo sviluppo del profilo RTM.
➢ MEM → Medical Equipment Management: è un White Paper che investiga sulla
questione di come un IT sanitario possa supportare le attività di ingegneri clinici e biomedici, migliorando l'efficienza del workflow e la qualità. Gli argomenti chiave includono l'identificazione univoca del dispositivo, l'allineamento con la postazione real-time, la configurazione software e hardware e la gestione delle correzioni, la gestione della batteria, e altro. PCD anticipa che ciò sarà sviluppato in un profilo di transazioni. ➢ PCD User Handbook: uno strumento per aiutare gli implementatori a capire gli
argomenti specifici del dominio PCD.
➢ Profile Conformance Testing: IHE e NIST stanno collaborando per testare le
implementazioni dei produttori definite attraverso i profili IHE-PCD. Questo ciclo annuale include la verifica dei messaggi IHE-PCD V2, sia sintatticamente che semanticamente. La terminologia è vincolata a quella di Rosetta dallo standard ISO/IEEE 11073.
Molti casi d'uso all'interno del dominio PCD possono essere compiuti sfruttando gli attori e le transazioni del profilo DEC. Questo profilo è infatti alla base di tutti gli altri che si differenziano più per il contenuto del messaggio e che per la struttura o il funzionamento del messaggio stesso. Ad esempio, il contenuto della comunicazione di una pompa di infusione a un EMR sarà molto diverso da quello di un monitor fisiologico. La varietà dei profili PCD è comunque utile per allargare il campo dell'interoperabilità a più settori specifici del dominio dei dispositivi biomedici, in modo che un utente possa essere più specifico nel richiedere l'implementazione di un particolare servizio al produttore.
I profili che interessano più da vicino questo lavoro e che verranno impiegati ampiamente per la strutturazione di un servizio di telemonitoraggio sono: DEC e DEC-SPD, ACM, RTM e IDCO. Questi verranno quindi descritti più approfonditamente nei prossimi paragrafi.