Masalah apa yang cenderung muncul ketika bekerja dengan pesan HL7?

12

Saya menguji produk untuk bisnis perawatan kesehatan, dan kami bekerja dengan pesan HL7. Saya melihat orang-orang mengerang pada pertanyaan lain tentang masalah dengan HL7 tetapi tidak menyebutkan secara spesifik. Bisakah seseorang memberi saya ide tentang masalah atau kelas masalah apa yang harus kita cari secara spesifik?

Kami menggunakan beberapa pustaka yang digunakan dengan baik untuk parsing. Jika spesifik tentang ini atau apa yang kami lakukan akan sangat membantu, beri tahu saya di komentar dan saya akan menambahkan pertanyaan jika saya bisa.

testing parsing hl7 Ethel Evans
sumber

Jawaban:

13

Saya menganggap Anda sedang berhadapan dengan HL7 v2.x

HL7 sangat fleksibel secara sukarela. Itu memiliki keuntungan besar tetapi juga menghadirkan tantangan. Aturan dasar yang perlu diingat adalah bahwa setiap implementasi akan berbeda. Jika Anda menggunakan produk yang sama di 2 lingkungan yang berbeda (misalnya 2 rumah sakit), aturan pertukaran data mungkin akan berbeda. Produk Anda harus siap untuk memenuhi persyaratan tersembunyi tersebut jika Anda ingin dapat mengukur jumlah antarmuka HL7 yang akan berinteraksi dengannya.

Dalam sebagian besar sistem perawatan kesehatan yang menangani HL7, kami menghadapi sebagian daftar tantangan umum ini:

  • Setiap sistem dapat menginterpretasikan arti dari setiap data. Konteks dan alur kerja juga dapat mempengaruhi semantik. Saya melihat beberapa sistem menggunakan nomor akun (PID.18) atau nomor kunjungan (PV1.19) untuk mengidentifikasi pasien agar sesuai dengan beberapa alur kerja klinis. Jenis celah semantik itu mungkin akan berdampak pada bagaimana sistem menerima data ini.
  • Wajib vs Opsional: Karena sepotong data dapat ditukar untuk mencapai beberapa tujuan dalam beberapa konteks yang berbeda, sebagian besar segmen dan bidang didokumentasikan sebagai opsional dalam dokumentasi resmi (dan beberapa parser). Namun, untuk memenuhi alur kerja tertentu, produk kesehatan mungkin akan menambah aturan batasan data dan mengendurkan beberapa lainnya. Sebagian besar waktu, analisis kasus per kasus perlu terjadi untuk mengidentifikasi mereka.
  • Tabel: HL7 menyediakan beberapa daftar nilai yang disarankan untuk beberapa bidang. Misalnya, daftar nilai yang disarankan untuk jenis kelamin adalah 6 panjang ... Jelas, sebagian besar sistem tidak menerapkan semua 6 tetapi apa strategi pemetaan Anda jika Anda menerima satu yang tidak Anda dukung di muka?
  • Segmen dan bidang dapat disesuaikan: Panjang bidang, tipe data, dan atribut definisi lainnya dapat disesuaikan. Anda perlu memetakannya ke beberapa struktur data yang Anda tahu tanpa kehilangan informasi penting.

jlmorin

www.caristix.com

jlmorin
sumber
6

Beberapa masalah yang pernah saya jumpai:

  • Beberapa organisasi mungkin menggunakan versi HL7 yang berbeda, sehingga Anda akan memiliki masalah kompatibilitas ("lintas jalan"). Tentu saja Anda akan mengalami ini jika Anda terlibat dalam transfer data antar organisasi.
  • Tidak ada standar semantik (untuk v2.x, saya pikir v3 mungkin sudah mulai membahas ini), jadi bahkan jika Anda tahu data apa yang seharusnya ada di bidang tertentu, Anda mungkin tidak tahu arti atau representasi yang tepat dari byte tersebut.
  • HL7 adalah standar non-standar. Ini mendukung vendor khusus Z-segmentsyang banyak digunakan dan benar-benar eksklusif.
  • HL7 v2.x (banyak nilai x yang masih digunakan di alam liar) adalah format non-XML, jadi Anda memerlukan pengurai HL7 untuk bekerja dengannya. (Ini, Anda tahu bahwa Anda sudah memiliki parsing pustaka HL7 hanya termasuk untuk orang lain)
G__
sumber
2
Yang terburuk adalah kurangnya semantik. Ketika orang-orang yang menulis standar mengatakan "Anda bisa mengirim X, atau Y, tetapi Z juga valid", Anda tahu Anda punya masalah. Apa yang menyelamatkannya adalah bahwa tidak seorang pun kecuali orang-orang parser harus berurusan dengan seluruh jajaran opsi HL7 - semua orang berurusan dengan subset kecil yang sebenarnya diterima oleh pelanggan mereka. Ini berarti bahwa menulis accepter baru adalah proses penemuan (yang sedang saya alami sekarang) daripada latihan "menerapkan standar". Oh, dan menebak opsi mana yang perlu Anda kirim untuk mendapatkan efek yang diinginkan.
@ +1 untuk jawabannya, dan dengan saya dapat memberi +1 untuk menyertakan info untuk orang lain selain OP (saya). @Moz - poin bagus tentang hanya membutuhkan sebagian kecil. Itulah situasi kita. Anda juga mengonfirmasi kecurigaan saya bahwa membandingkan dengan data pelanggan akan menjadi kunci.
Ethel Evans
1
@ethel dan @moz, itulah jenis pemikiran yang membuat berurusan dengan HL7 sangat sulit, silakan luangkan waktu untuk membuat program Anda sefleksibel possbile, HL7 adalah satu tempat di mana YAGNI sama sekali tidak berlaku.
Peter Turner
Oke, ini masuk akal. Saya tidak berpikir aplikasi kita akan menyebabkan masalah YAGNI, karena kami berencana untuk memperluas jenis pesan HL7 yang dapat kita gunakan untuk memberikan nilai. Kami tahu bahwa kami tidak tahu apa yang akan kami butuhkan di masa depan.
Ethel Evans
1
Itu sebabnya saya penggemar menggunakan perpustakaan sumber terbuka (HAPI / NHAPI) setidaknya untuk sisi penerima. Jauh lebih baik untuk memiliki level tinggi "kami mendapat pesan HL7 yang valid tetapi belum menulis kode untuk memprosesnya" daripada "parser kami gagal karena kami tidak mengharapkan pesan itu". Sayangnya semua orang mulai dari kecil "kami hanya mengirim X dan menerima Y" jadi itu jauh lebih mudah untuk meretas sesuatu bersama untuk kemudian memperpanjangnya setiap kali persyaratan baru tiba sampai akhirnya runtuh di bawah berat akumulasi cruft.
2

Masalah pertama adalah memastikan semua orang tahu apa HL7 itu.

Ini adalah cara untuk mengganti coders [medis | penagihan | asuransi] dan menyimpan uang [farmasi | bank | perusahaan asuransi].

Itulah kerutan di atas semua masalah normal dalam pengembangan perangkat lunak.

  1. Cakupan Creep
  2. Spesifikasi tidak lengkap
  3. Spesifikasi hak milik tidak valid yang "Tidak dapat diubah"

Jadi, Anda menghubungi [Farmasi | Bank | Perusahaan Asuransi] Anda yang ingin mencabut semua uang yang mereka dapat dari antarmuka HL7 ke fasilitas yang menggunakan perangkat lunak Anda. Kontrak Anda dengan fasilitas, kontrak mereka dengan apotek, [Farmasi | Bank | Perusahaan Asuransi] tidak memiliki petunjuk bagaimana perangkat lunak Anda bekerja, fasilitas tidak memiliki petunjuk apa HL7 itu dan Anda teringat di apotek karena mereka terus-menerus memberi tahu Anda bahwa perangkat lunak Anda bermasalah.

Saya percaya masalah dengan HL7 adalah bahwa sebagian besar dilakukan dengan murah. HL7 3.0 mungkin tidak pernah terwujud karena tidak akan pernah menghasilkan uang.

Jika Anda akan "membayar untuk HL7" ingat bahwa Anda juga membayar untuk HL [1-6]. Antarmuka SOAP bukan HL7. Pengurai pesan HL7 bukan HL7, tidak juga generator pesan.

Peter Turner
sumber
1
HL7 jauh lebih dari sekedar untuk apotek. Paling sering HL7 digunakan untuk menghubungkan sistem yang berbeda seperti EMR ke sistem penagihan.
Bill
Produk kami tidak ditargetkan di apotek, bahkan secara tidak langsung, dan responsnya sangat bias dengan sedikit dukungan untuk jawabannya.
Ethel Evans
1
@ Ethel Saya akan menambahkan beberapa regex tetapi Anda harus lebih spesifik dalam pertanyaan Anda. Kami melakukan lebih dari apotek dengan penerapan HL7 100% buatan sendiri di rumah kami, tetapi penggerak utama di balik pengembangan selalu "pharma besar", jika orang lain dapat memanfaatkan spesifikasi yang banyak digunakan, maka jadilah itu.
Peter Turner
@ Peter: Saya akan mencoba untuk lebih spesifik dengan mengapa saya pikir ini tidak membantu. Pertama, kutipan Anda yang disorot tampaknya sangat bias dan tidak didukung. Kedua, item-item dalam daftar bernomor Anda tidak jelas atau tidak menambahkan apa yang dikatakan oleh jawaban lain dengan lebih jelas. Ketiga, skenario contoh Anda sangat spesifik dan tidak terlihat seperti skenario yang saya (dan tampaknya juga orang lain) hadapi, menjadikannya tidak informatif. Keempat, pernyataan Anda bahwa HL7 dilakukan dengan murah tampaknya bias dan tidak didukung. Kelima, saya tidak melakukan "HL7", saya bekerja dengan pesan HL7, sehingga poin paragraf terakhir hilang.
Ethel Evans
2
@Ethel, bagaimana saya bisa mendukung klaim saya, saya tidak mendapat manfaat sama sekali dengan mencengkeram HL7, apa yang saya tahu dari pengalaman tahun-tahun terakhir saya bekerja dengan beberapa vendor adalah ketika seseorang mengatakan mereka ingin bekerja dengan saya perangkat lunak dan untuk mengirimi mereka "Pesan uji" sehingga mereka dapat memahami seperti apa bentuknya, mereka akan membuat semacam ORM di sekitar pesan dan itu hanya akan berfungsi untuk itu. Ini tidak bagus. Jika jawaban saya tampaknya berbeda dari yang lain, itu pasti bukan karena saya tidak mengatakan yang sebenarnya kepada Anda. HL7 terutama tentang uang.
Peter Turner