Quali problemi si presentano quando si lavora con i messaggi HL7?

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

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

Nella maggior parte dei sistemi sanitari che si occupano di HL7, ci troviamo di fronte a questo elenco parziale di sfide comuni:

• Ogni sistema potrebbe interpretare il significato di ogni pezzo di dati. 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 qualche impatto sul modo in cui il sistema riceve questi dati.
• Obbligatorio vs Opzionale: poiché un dato può essere scambiato per raggiungere diversi obiettivi in diversi contesti, la maggior parte dei segmenti e dei campi sono documentati come facoltativi nella documentazione ufficiale (e alcuni parser). Tuttavia, per soddisfare specifici flussi di lavoro, i prodotti sanitari probabilmente aggiungerebbero regole di vincoli sui dati e rilasseranno altri. Nella maggior parte dei casi, è necessario eseguire un'analisi caso per caso per identificarli.
• Tabelle: HL7 fornisce alcuni elenchi di valori suggeriti per alcuni campi. Ad esempio, l'elenco dei valori suggeriti per il sesso è lungo 6 ... Ovviamente, la maggior parte dei sistemi non implementa tutti i 6 ma qual è la tua strategia di mappatura se ne ricevi uno non supportato in anticipo?
• I segmenti e i campi possono essere personalizzati: lunghezza del campo, tipi di dati e altri attributi di definizione possono essere personalizzati. Devi mapparlo ad una struttura dati che conosci senza perdere informazioni importanti.

jlmorin

www.caristix.com

Alcuni problemi che ho incontrato:

• Alcune organizzazioni potrebbero utilizzare diverse versioni di HL7, quindi avrai problemi di compatibilità ("cross-walking"). Certamente ti imbatterai in questo se sarai coinvolto in trasferimenti di dati inter-organizzativi.
• Non esiste uno standard semantico (per v2.x, penso che v3 possa aver iniziato a risolverlo), quindi anche se sai quali dati dovrebbero essere in un campo particolare, potresti non sapere il significato esatto o la rappresentazione di quelli byte.
• HL7 è uno standard non standard. Supporta Z-segments specifico del fornitore che è ampiamente utilizzato e totalmente proprietario.
• HL7 v2.x (molti valori di x ancora in uso in the wild) è un formato proprietario non XML, quindi avrai bisogno di un parser HL7 per lavorarci. (Questo, sai come hai già una libreria di analisi HL7 includendola solo per gli altri)

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

It is a way to replace [medical|billing|insurance] coders and save a [pharmacy|bank|insurance company] money.

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

1. Scope Creep
2. Specifiche incomplete
3. Specifiche proprietarie non valide che "Can not be changed"

Quindi, contatti la [Società di assicurazioni | Banca | Compagnia di assicurazioni] che vuole eliminare tutti i soldi che possono 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 di Assicurazioni] non ha idea di come funziona il tuo software, la struttura non ha idea di cosa sia HL7 e tu sei spuntato in farmacia perché costantemente ti dico che il tuo software è bacato.

Credo che il problema con HL7 sia che per lo più è fatto a buon mercato. 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.