Cos’è il protocollo HL7 L’HL7 è originariamente sviluppato negli Stati Uniti dove nel 1987 viene pubblicata la versione1.0. L’HL7 organization si occupa di sviluppare e pubblicare le specifiche del protocollo HL7 a livello “applicazione” per la comunicazione tra diversi processi e sistemi in ambiente sanitario. Ad oggi (dalla versione 2.5, l’HL7 è uno standard approvato dall’ANSI) l’HL7 è lo standard per la comunicazione di messaggi più diffuso al mondo nell’IT in ambito sanitario ed è stato adottato dall’intera comunità internazionale soprattutto per gli elettromedicali, tanto è che vi sono circa 30 sezioni nazionali con 40 gruppi di lavoro che ne contribuiscono allo sviluppo. Sicurezza livello 7 nel modello OSI È chiamato livello 7 perché si pone a questo livello nel modello OSI (Open Systems Interconnection), dove il più basso è il livello di comunicazione fisica e il più alto è livello di applicazione che riguarda i cosiddetti programmi applicativi. A differenza di altri standard come il DICOM, l’HL7, ponendosi al livello più alto o livello applicativo, si concentra solo su dati e informazioni che devono essere scambiate con i messaggi. A cosa serve 1. Supportare lo scambio di dati definendo un formato ed un protocollo per le applicazioni informatiche tra sistemi eterogenei. L’implementazione è indipendente dal linguaggio di programmazione e dal sistema operativo e deve supportare tutti i metodi di comunicazione compatibili con il livello 7 del modello OSI 2. Raggiungere il più alto grado di standardizzazione possibile nell’uso e nel formato dei dati permettendo allo stesso modo la personalizzazione per adattarsi a necessità specifiche o a variazioni locali 3. Supportare nuove necessità, introducendo estensioni alla versione attuale o nuove release mantenendo la compatibilità con le versioni precedenti 4. Negoziare e trovare un accordo tra le applicazioni al fine di gestire le differenze che esistono nei vari processi amministrativi tra strutture sanitarie diverse, quando non è stato previsto un modello di elaborazione standard 5. Permettere a implementazioni locali l’uso di messaggi o parti di messaggio personalizzati, evitando conflitti con le versioni future dello standard 6. Integrare lo standard con nuove transazioni o nuovi dati; è importante che questi aggiornamenti possano essere implementati nella applicazione che li richiede, senza per questo dover aggiornare tutti gli altri applicativi
