Quali problemi tendono a sorgere quando si lavora con i messaggi HL7?

Sto testando un prodotto per le aziende sanitarie e stiamo lavorando con i messaggi HL7. Ho visto persone lamentarsi per un'altra domanda sui problemi con HL7 ma senza menzionare i dettagli. Qualcuno può darmi alcune idee su quali problemi o classi di problemi dovremmo specificamente cercare?

Stiamo usando alcune librerie ben utilizzate per l'analisi. Se i dettagli su questi o quello che stiamo facendo sarebbero utili, per favore fatemi sapere nei commenti e aggiungerò alla domanda se posso.

testing parsing hl7

— Ethel Evans
fonte

Risposte:

Suppongo che tu abbia a che fare con HL7 v2.x

HL7 è volontariamente estremamente flessibile. Ciò ha grandi vantaggi ma introduce anche sfide. Una regola di base da tenere a mente è che ogni singola implementazione sarà diversa. Se si distribuisce lo stesso prodotto in 2 ambienti diversi (ad esempio 2 ospedali), la regola di scambio di dati sarà probabilmente diversa. Il tuo prodotto deve essere pronto a soddisfare quei requisiti nascosti se vuoi essere in grado di ridimensionare il numero di interfaccia HL7 con cui interagirà.

Nella maggior parte dei sistemi sanitari che si occupano di HL7, stiamo affrontando questo elenco parziale di sfide comuni:

Ogni sistema potrebbe interpretare il significato di ciascun dato. Anche il contesto e i flussi di lavoro possono influenzare il semantico. Ho visto alcuni sistemi utilizzando il numero di conto (PID.18) o il numero di visita (PV1.19) per identificare il paziente in modo che fosse conforme ad alcuni flussi di lavoro clinici. Questo tipo di gap semantico avrà probabilmente degli impatti sul modo in cui il sistema riceve questi dati.
Richiesto o facoltativo: poiché è possibile scambiare una parte di dati per raggiungere diversi obiettivi in diversi contesti, la maggior parte dei segmenti e dei campi sono documentati come opzionali nella documentazione ufficiale (e in alcuni parser). Tuttavia, per soddisfare specifici flussi di lavoro, i prodotti sanitari probabilmente aggiungerebbero regole sui vincoli di dati e ne rilascerebbero altri. Il più delle volte, è necessario eseguire un'analisi caso per caso per identificarli.
Tabelle: HL7 fornisce un elenco di valori suggeriti per alcuni campi. Ad esempio, l'elenco di valori suggeriti per il genere è lungo 6 ... Ovviamente, la maggior parte dei sistemi non implementa tutti e 6 ma qual è la tua strategia di mappatura se ne ricevi una che non supporti in anticipo?
Segmenti e campi possono essere personalizzati: lunghezza del campo, tipi di dati e altri attributi di definizione possono essere personalizzati. Devi mapparlo su alcune strutture di dati che conosci senza perdere informazioni importanti.

jlmorin

www.caristix.com

— jlmorin
fonte

Alcuni problemi che ho riscontrato:

Alcune organizzazioni potrebbero utilizzare versioni diverse di HL7, quindi avrai problemi di compatibilità ("cross-walking"). Sicuramente ti imbatterai in questo se vieni coinvolto in eventuali trasferimenti di dati tra organizzazioni.
Non esiste uno standard semantico (per v2.x, penso che v3 potrebbe aver iniziato a risolvere questo problema), quindi anche se sai quali dati dovrebbero essere in un determinato campo, potresti non conoscere il significato esatto o la rappresentazione di quei byte.
HL7 è uno standard non standard. Supporta specifici del fornitore Z-segmentsche sono ampiamente utilizzati e totalmente proprietari.
HL7 v2.x (molti valori di x sono ancora in uso in natura) è un formato proprietario non XML, quindi avrai bisogno di un parser HL7 per lavorare con esso. (Questo, sai che hai già una libreria di analisi HL7 che la include solo per gli altri)

— G__
fonte

La cosa peggiore è la mancanza di semantica. Quando anche le persone che scrivono lo standard dicono "bene potresti inviare X, o Y, ma anche Z è valido" sai che hai un problema. Ciò che salva è che nessuno, tranne il parser, ha a che fare con l'intera gamma di opzioni HL7 - tutti si occupano del piccolo sottoinsieme che viene effettivamente ricevuto dai loro clienti. Significa che scrivere un nuovo acceptre è un processo di scoperta (che sto attraversando proprio ora) piuttosto che un esercizio di "implementazione dello standard". Oh, e indovina a quale opzione devi inviare per avere l'effetto desiderato.

@ +1 per la risposta, e con me potrei dare +1 per includere informazioni per persone diverse dall'OP (me). @moz - buon punto solo per aver bisogno di un piccolo sottoinsieme. Questa è precisamente la nostra situazione. Stai anche confermando il mio sospetto che il confronto con i dati dei clienti sarà fondamentale.

— Ethel Evans,

@ethel e @moz, questo è esattamente il tipo di pensiero che rende così difficile gestire HL7, per favore prenditi il tempo di rendere i tuoi programmi il più flessibile possibile, HL7 è un posto dove YAGNI non è in alcun modo applicabile.

— Peter Turner,

Ok, questo ha senso. Non credo che la nostra applicazione causerà problemi YAGNI, poiché stiamo pianificando in anticipo di espandere i tipi di messaggi HL7 che possiamo usare per fornire valore. Sappiamo che non sappiamo di cosa avremo bisogno in futuro.

— Ethel Evans,

Ecco perché sono un fan dell'utilizzo delle librerie open source (HAPI / NHAPI) almeno per il lato ricevente. Molto meglio avere un livello elevato "abbiamo ricevuto un messaggio HL7 valido ma non abbiamo scritto codice per elaborarlo" piuttosto che "il nostro parser non è riuscito perché non ci aspettavamo quel messaggio". Sfortunatamente tutti iniziano in piccolo "inviamo semplicemente X e riceviamo Y", quindi è molto più semplice hackerare qualcosa insieme solo per poi estenderlo ogni volta che arriva un nuovo requisito fino a quando non collassa sotto il peso dell'accumulo accumulato.

Il primo problema è assicurarsi che tutti sappiano cos'è HL7.

È un modo per sostituire i programmatori [medici | fatturazione | assicurazioni] e risparmiare denaro [farmacia | banca | compagnia assicurativa].

Questa è la ruga in cima a tutti i normali problemi di sviluppo del software.

Scree Creep
Specifiche incomplete
Specifiche proprietarie non valide che "Non può essere modificato"

Quindi, contatta la tua [Farmacia | Banca | Compagnia assicurativa] che vuole spremere tutto il denaro che può da un'interfaccia HL7 alla struttura che utilizza il tuo software. Il tuo contratto è con la struttura, il loro contratto è con la farmacia, la [Farmacia | Banca | Compagnia assicurativa] non ha idea di come funzioni il tuo software, la struttura non ha idea di cosa sia HL7 e tu sei spuntato in farmacia perché loro informarti costantemente che il tuo software è difettoso.

Credo che il problema con HL7 sia che viene fatto principalmente a basso costo. HL7 3.0 potrebbe non materializzarsi mai perché non monetizzerà mai.

Se hai intenzione di "pagare per HL7", ricorda che stai pagando anche per HL [1-6]. Un'interfaccia SOAP non è HL7. Un parser di messaggi HL7 non è HL7, né è un generatore di messaggi.

— Peter Turner
fonte

HL7 è molto più di una semplice farmacia. Molto spesso HL7 viene utilizzato per collegare sistemi diversi come un EMR a un sistema di fatturazione.

— Bill

Il nostro prodotto non è destinato alle farmacie, neppure indirettamente, e la risposta è molto parziale con scarso supporto per la risposta.

— Ethel Evans,

@Ethel Aggiungerò alcune regex ma dovresti essere più specifico nella tua domanda. Facciamo più delle farmacie con la nostra implementazione HL7 al 100% coltivata in casa, ma il motore principale dietro lo sviluppo è sempre "grande farmaceutica", se altri possono trarre vantaggio da una specifica ampiamente utilizzata, allora così sia.

— Peter Turner,

@Peter: proverò ad essere più specifico sul perché penso che questo non sia utile. Innanzitutto, la citazione evidenziata sembra fortemente distorta e non supportata. In secondo luogo, gli elementi nel tuo elenco numerato sono vaghi o non si aggiungono a ciò che altre risposte hanno detto più chiaramente. In terzo luogo, il tuo scenario di esempio è altamente specifico e non assomiglia affatto allo scenario che io (e apparentemente altri) sto affrontando, rendendolo non informativo. In quarto luogo, la tua affermazione che HL7 è fatto a buon mercato sembra distorta e non supportata. In quinto luogo, non sto facendo "HL7", sto lavorando con i messaggi HL7, quindi il punto dell'ultimo paragrafo è perso.

— Ethel Evans,

@Ethel, come diavolo dovrei sostenere le mie affermazioni, non traggo alcun beneficio dal lamentarmi di HL7, quello che so dalla mia esperienza degli ultimi anni di lavoro con diversi fornitori è che quando qualcuno dice che vogliono lavorare con il mio software e per inviare loro un "messaggio di prova" in modo che possano avere un'idea di come dovrebbe essere, realizzeranno una sorta di ORM attorno al messaggio e funzionerà solo per quello. Questo non è buono. Se la mia risposta sembra diversa dalle altre, non è certo perché non ti sto dicendo la verità. HL7 riguarda principalmente i soldi.

— Peter Turner,