HL7 mesajlarıyla çalışırken hangi sorunlar ortaya çıkar?

Sağlık işletmeleri için bir ürünü test ediyorum ve HL7 mesajları ile çalışıyoruz. İnsanların HL7 ile ilgili sorunlar hakkında başka bir soru üzerinde inlediğini gördüm, ancak ayrıntılardan bahsetmedim. Birisi bana özellikle hangi konuları veya sorun sınıflarını aramamız gerektiğine dair bazı fikirler verebilir mi?

Ayrıştırma için bazı iyi kullanılmış kütüphaneler kullanıyoruz. Bunlarla ilgili bilgiler veya yaptığımız iş yararlı olursa lütfen yorumlarda bana bildirin, eğer yapabilirsem soruyu ekleyeceğim.

testing parsing hl7

— Ethel Evans
kaynak

Yanıtlar:

HL7 v2.x ile uğraştığınızı varsayıyorum

HL7 gönüllü olarak son derece esnektir. Bunun büyük avantajları var ama aynı zamanda zorlukları da beraberinde getiriyor. Akılda tutulması gereken temel bir kural, her bir uygulamanın farklı olacağıdır. Aynı ürünü 2 farklı ortama (örneğin 2 hastane) dağıtırsanız, veri alışverişi kuralı muhtemelen farklı olacaktır. Etkileşim kuracağı HL7 arabirimi sayısını ölçeklendirmek istiyorsanız, ürününüz bu gizli gereksinimleri karşılamaya hazır olmalıdır.

HL7 ile ilgilenen çoğu sağlık sisteminde, bu ortak sorunların kısmi listesiyle karşı karşıyayız:

Her sistem, her veri parçasının anlamını yorumlayabilir. Ayrıca bağlam ve iş akışları semantiği etkileyebilir. Bazı klinik iş akışlarına uygun olacak hastayı tanımlamak için hesap numarasını (PID.18) veya ziyaret numarasını (PV1.19) kullanan bazı sistemler gördüm. Bu tür anlambilimsel boşluk muhtemelen sistemin bu veriyi nasıl ele aldığı üzerinde bazı etkileri olacaktır.
Zorunlu ve Opsiyonel: Birkaç farklı bağlamda birkaç hedefe ulaşmak için bir veri parçası değiş tokuş edilebildiğinden, segmentlerin ve alanların çoğu resmi belgelerde (ve bazı ayrıştırıcılarda) isteğe bağlı olarak belgelenir. Bununla birlikte, belirli iş akışlarını karşılamak için sağlık ürünleri muhtemelen veri kısıtlama kuralları ekler ve bazılarını rahatlatır. Çoğu zaman, bunları tanımlamak için bir vaka analizinin yapılması gerekir.
Tablolar: HL7, bazı alanlar için önerilen değerlerin bir listesini sağlar. Örneğin, cinsiyet için önerilen değer listesi 6 uzun ... Açıkçası, çoğu sistem 6'nın tümünü uygulamıyor, ancak desteklemediğiniz bir tane alırsanız harita stratejiniz nedir?
Segmentler ve alanlar özelleştirilebilir: Alan uzunluğu, veri türleri ve diğer tanım özellikleri özelleştirilebilir. Önemli bilgileri kaybetmeden, bildiğiniz bazı veri yapılarıyla eşleştirmeniz gerekir.

jlmorin

www.caristix.com

— jlmorin
kaynak

Karşılaştığım birkaç sorun:

Bazı kuruluşlar HL7'nin farklı sürümlerini kullanabilir, bu nedenle uyumluluk sorunlarınız olacaktır ("çapraz yürüme"). Kuruluşlar arası veri aktarımlarına dahil olursanız kesinlikle bu sorunla karşılaşırsınız.
Semantik bir standart yoktur (v2.x için, sanırım v3 bunu ele almaya başlamış olabilir), bu nedenle belirli bir alanda hangi verilerin olması gerektiğini biliyor olsanız bile, bu baytların tam anlamını veya temsilini bilmiyor olabilirsiniz.
HL7 standart olmayan bir standarttır. Z-segmentsYaygın olarak kullanılan ve tamamen tescilli olan satıcıya özel destekler .
HL7 v2.x (hala vahşi ortamda kullanılmakta olan birçok x değeri) XML'e özgü olmayan bir biçimdir, bu nedenle onunla çalışmak için bir HL7 ayrıştırıcısına ihtiyacınız olacaktır. (Bu, zaten başkaları için de dahil olmak üzere bir HL7 ayrıştırma kitaplığınız olduğunu biliyorsunuz)

— G__
kaynak

Bunların en kötüsü anlambilim eksikliğidir. Standardı yazan insanlar bile "iyi X veya Y gönderebilirsiniz, ancak Z de geçerlidir" derken bir sorununuz olduğunu bilirsiniz. Tasarruf eden, ayrıştırıcı insanlar dışında hiç kimsenin tüm HL7 seçenekleriyle uğraşmak zorunda olmamasıdır - herkes aslında müşterileri tarafından alınan küçük alt kümeyle ilgilenir. Bu, yeni bir alıcı yazmanın "standart uygulama" alıştırmasından ziyade (şu an yaşadığım) bir keşif süreci olduğu anlamına gelir. Oh, ve istenen efekti elde etmek için hangi seçeneği göndermeniz gerektiğini tahmin etmek.

@ +1 ile yanıt için ve ben OP (ben) dışındaki kişiler için bilgi eklemek için +1 verebilir. @moz - sadece küçük bir alt kümeye ihtiyaç duymak için iyi bir nokta. Bu bizim durumumuz. Ayrıca, müşteri verileriyle karşılaştırmanın önemli olacağına dair şüphemi de onaylıyorsunuz.

— Ethel Evans

@ethel ve @moz, bu tam olarak HL7 ile uğraşmayı zorlaştıran bir tür düşünme, lütfen programlarınızı mümkün olduğunca esnek hale getirmek için zaman ayırın, HL7, YAGNI'nın hiçbir şekilde uygulanabilir olmadığı bir yer.

— Peter Turner

Tamam, bu mantıklı. Değer sağlamak için kullanabileceğimiz HL7 mesajlarının türlerini genişletmeyi planladığımız için uygulamamızın YAGNI sorunlarına neden olacağını düşünmüyorum. Gelecekte neye ihtiyacımız olacağını bilmediğimizi biliyoruz.

— Ethel Evans

Bu yüzden en azından alıcı taraf için açık kaynak kütüphanelerini (HAPI / NHAPI) kullanma hayranıyım. Yüksek bir seviyeye sahip olmak çok daha iyi "geçerli bir HL7 mesajı aldık ama işlemek için kod yazmadık" dan "ayrıştırıcımız başarısız oldu çünkü bu mesajı beklemiyorduk". Ne yazık ki herkes küçük "sadece X gönderiyoruz ve Y alıyoruz" diye başlıyor, bu yüzden bir şeyleri birlikte kesmek çok daha basit, yeni bir gereksinim her seferinde her seferinde biriken kruvazerin ağırlığı altında çökünceye kadar genişletiyor.

İlk konu, herkesin HL7'nin ne olduğunu bildiğinden emin olmaktır.

Bu [tıbbi | fatura | sigorta] kodlayıcılarını değiştirmenin ve [eczane | banka | sigorta şirketi] paradan tasarruf etmenin bir yoludur.

Yazılım geliştirmedeki tüm normal sorunların üstündeki kırışıklık budur.

Kapsam Sünme
Eksik özellikler
"Değiştirilemez" özel mülk özellikleri

Böylece, bir HL7 arayüzünden yazılımınızı kullanan tesise kadar ellerinden geleni yapmak isteyen [Eczane | Banka | Sigorta Şirketi] ile temasa geçersiniz. Sözleşmeniz tesis ile, sözleşmeleri eczane ile, [Eczane | Banka | Sigorta Şirketi] yazılımınızın nasıl çalıştığına dair hiçbir fikre sahip değil, tesisin HL7'nin ne olduğu hakkında hiçbir fikri yok ve eczaneden işaretliyorsunuz çünkü onlar size sürekli yazılımınızın hatalı olduğunu söyler.

HL7 ile ilgili sorun çoğunlukla ucuz yapılır olduğuna inanıyorum. HL7 3.0 asla para kazanmayacağından asla gerçekleşmeyebilir.

"HL7 için ödeme" yapacaksanız, HL [1-6] için de ödeme yaptığınızı unutmayın. Bir SOAP arayüzü HL7 değil. Bir HL7 ileti ayrıştırıcısı HL7 değil, ne de bir mesaj oluşturucu.

— Peter Turner
kaynak

HL7 sadece eczanelerden çok daha fazlasıdır. Çoğu zaman HL7, EMR gibi farklı sistemleri bir faturalandırma sistemine bağlamak için kullanılır.

— Bill

Ürünümüz dolaylı olarak bile eczanelere yönelik değildir ve yanıt çok az destekle çok taraflıdır.

— Ethel Evans

@Ethel Bazı normal ifadeler ekleyeceğim, ancak sorunuzda daha spesifik olmalısınız. % 100 evde yetiştirilen HL7 uygulamamızla eczanelerden daha fazlasını yapıyoruz, ancak geliştirmenin arkasındaki ana taşıyıcı her zaman "büyük ilaçtır", eğer diğerleri yaygın olarak kullanılan bir spesifikasyondan faydalanabilirse, öyle olsun.

— Peter Turner

@Peter: Bunun neden yararlı olmadığını düşündüğüm konusunda daha spesifik olmaya çalışacağım. İlk olarak, vurgulanan teklifiniz son derece taraflı ve desteksiz görünüyor. İkincisi, numaralı listenizdeki öğeler belirsizdir veya diğer cevapların daha açık bir şekilde söylediklerinin ötesine geçmez. Üçüncüsü, örnek senaryonuz son derece spesifiktir ve ben (ve görünüşe göre diğerleri) ile uğraştığınız senaryoya benzemez ve bu da onu bilgilendirmez. Dördüncüsü, HL7'nin ucuza yapıldığına dair ifadeniz taraflı ve desteksiz görünüyor. Beşinci olarak, "HL7" yapmıyorum, HL7 mesajları ile çalışıyorum, bu yüzden son paragrafın noktası kayboluyor.

— Ethel Evans

@Ethel, iddialarımı nasıl desteklemeliyim, HL7'yi kavrayarak hiç fayda görmüyorum, son yıllardaki birkaç tedarikçiyle çalışma deneyimimden bildiğim şey, birileriyle çalışmak istediğini söylediğinde yazılım ve onlara bir "Test mesajı" göndermek, böylece neye benzemesi gerektiğini ele alabilmeleri için, mesajın etrafında bir çeşit ORM oluşturacaklar ve sadece bunun için çalışacaklar. Bu iyi değil. Cevabım diğerlerinden farklı görünüyorsa, kesinlikle gerçeği söylemediğim için değil. HL7 esas olarak parayla ilgilidir.

— Peter Turner