Jakie problemy pojawiają się podczas pracy z komunikatami HL7?

Testuję produkt dla firm opieki zdrowotnej i pracujemy z komunikatami HL7. Widziałem ludzi jęczących na inne pytanie dotyczące problemów z HL7, ale nie wspominając o szczegółach. Czy ktoś może mi dać jakieś wyobrażenie o tym, jakich problemów lub klas problemów powinniśmy szczególnie szukać?

Do analizowania używamy dobrze używanych bibliotek. Jeśli szczegółowe informacje na temat tych lub tego, co robimy, byłyby pomocne, proszę dać mi znać w komentarzach, a jeśli to możliwe, dodam do pytania.

testing parsing hl7

— Ethel Evans
źródło

Odpowiedzi:

Zakładam, że masz do czynienia z HL7 v2.x

HL7 jest dobrowolnie niezwykle elastyczny. Ma to wielkie zalety, ale także wprowadza wyzwania. Podstawową zasadą, o której należy pamiętać, jest to, że każda implementacja będzie inna. Jeśli wdrożysz ten sam produkt w 2 różnych środowiskach (na przykład 2 szpitalach), reguła wymiany danych prawdopodobnie będzie inna. Twój produkt musi być gotowy do spełnienia tych ukrytych wymagań, jeśli chcesz mieć możliwość skalowania liczby interfejsów HL7, z którymi będzie on oddziaływać.

W większości systemów opieki zdrowotnej dotyczących HL7 mamy do czynienia z częściową listą wspólnych wyzwań:

Każdy system może interpretować znaczenie każdego elementu danych. Również kontekst i przepływy pracy mogą wpływać na semantyczny. Widziałem niektóre systemy wykorzystujące numer konta (PID.18) lub numer wizyty (PV1.19), aby zidentyfikować pacjenta, który jest zgodny z niektórymi klinicznymi przepływami pracy. Ten typ luki semantycznej prawdopodobnie będzie miał pewien wpływ na sposób, w jaki system odbiera te dane.
Wymagane a opcjonalne: Ponieważ część danych można wymieniać, aby osiągnąć kilka celów w kilku różnych kontekstach, większość segmentów i pól jest udokumentowana jako opcjonalna w oficjalnej dokumentacji (i niektórych parserach). Jednak aby spełnić określone przepływy pracy, produkty opieki zdrowotnej prawdopodobnie dodałyby reguły ograniczeń danych i złagodziłyby inne. W większości przypadków należy przeprowadzić analizę poszczególnych przypadków, aby je zidentyfikować.
Tabele: HL7 zawiera listę sugerowanych wartości dla niektórych pól. Na przykład sugerowana lista wartości dla płci wynosi 6 ... Oczywiście większość systemów nie implementuje wszystkich 6, ale jaka jest twoja strategia mapowania, jeśli otrzymasz taką, której nie wspierasz z góry?
Segmenty i pola można dostosować: długość pola, typy danych i inne atrybuty definicji można dostosować. Musisz odwzorować go na znaną strukturę danych bez utraty ważnych informacji.

jlmorin

www.caristix.com

— jlmorin
źródło

Kilka problemów, które napotkałem:

Niektóre organizacje mogą używać różnych wersji HL7, więc będziesz mieć problemy ze zgodnością („cross-walking”). Na pewno się na to natkniesz, jeśli zaangażujesz się w transfery danych między organizacjami.
Nie ma standardu semantycznego (dla v2.x, myślę, że v3 mogło zacząć to rozwiązywać), więc nawet jeśli wiesz, jakie dane powinny znajdować się w określonym polu, możesz nie znać dokładnego znaczenia lub reprezentacji tych bajtów.
HL7 jest niestandardowym standardem. Obsługuje specyficzne dla dostawców, Z-segmentsktóre są szeroko stosowane i całkowicie zastrzeżone.
HL7 v2.x (wiele wartości x nadal używanych na wolności) jest formatem innym niż XML, więc do pracy z nim potrzebujesz parsera HL7. (Wiesz, ponieważ masz już bibliotekę parsującą HL7, która zawiera ją tylko dla innych)

— SOL__
źródło

Najgorszy z nich to brak semantyki. Kiedy nawet ludzie piszący standard mówią „dobrze, że możesz wysłać X lub Y, ale Z jest również poprawny”, wiesz, że masz problem. Oszczędność polega na tym, że nikt oprócz parsera nie ma do czynienia z całą gamą opcji HL7 - wszyscy mają do czynienia z małym podzbiorem, który jest faktycznie odbierany przez klientów. Oznacza to, że napisanie nowego narzędzia jest procesem odkrywania (przez który właśnie przechodzę), a nie „implementacją standardowego” ćwiczenia. Aha, i zgadnij, którą opcję musisz wysłać, aby uzyskać pożądany efekt.

@ +1 za odpowiedź, a dzięki niemu mogę dać +1 za włączenie informacji dla osób innych niż OP (ja). @moz - dobrze, że potrzebuję tylko małego podzbioru. To jest dokładnie nasza sytuacja. Potwierdzasz również moje podejrzenie, że porównanie z danymi klientów będzie kluczowe.

— Ethel Evans

@ ethel i @moz, to jest właśnie taki sposób myślenia, który sprawia, że radzenie sobie z HL7 jest tak trudne, poświęć trochę czasu, aby uczynić swoje programy tak elastycznymi, jak to możliwe, HL7 to jedno miejsce, w którym YAGNI w żaden sposób nie ma zastosowania.

— Peter Turner

Ok, to ma sens. Nie sądzę, aby nasza aplikacja powodowała jakiekolwiek problemy z YAGNI, ponieważ planujemy z wyprzedzeniem rozszerzyć typy komunikatów HL7, których możemy użyć, aby zapewnić wartość. Wiemy, że nie wiemy, czego będziemy potrzebować w przyszłości.

— Ethel Evans,

Dlatego jestem fanem korzystania z bibliotek open source (HAPI / NHAPI) przynajmniej dla strony odbierającej. O wiele lepiej jest mieć wysoki poziom „otrzymaliśmy prawidłowy komunikat HL7, ale nie napisaliśmy kodu do jego przetworzenia” niż „nasz parser zawiódł, ponieważ nie spodziewaliśmy się tego komunikatu”. Niestety wszyscy zaczynają od drobnego „wysyłamy X i odbieramy Y”, więc o wiele łatwiej jest zhakować coś razem, niż wtedy rozszerzać go za każdym razem, gdy pojawia się nowe wymaganie, aż w końcu zawali się pod ciężarem nagromadzonego cruftu.

Pierwszą kwestią jest upewnienie się, że wszyscy wiedzą, czym jest HL7.

Jest to sposób na zastąpienie koderów [medycznych | rozliczeniowych | ubezpieczeniowych] i zaoszczędzenie pieniędzy [apteki | banku | firmy ubezpieczeniowej].

Jest to zmarszczka ponad wszystkimi normalnymi problemami związanymi z tworzeniem oprogramowania.

Zakres pełzania
Niekompletne specyfikacje
Nieprawidłowe zastrzeżone specyfikacje, których „nie można zmienić”

Kontaktujesz się więc z [apteką | bankiem | firmą ubezpieczeniową], która chce wydać wszystkie możliwe pieniądze z interfejsu HL7 do placówki korzystającej z twojego oprogramowania. Twoja umowa jest zawarta z placówką, ich umowa z apteką, [apteka | bank | firma ubezpieczeniowa] nie ma pojęcia, jak działa twoje oprogramowanie, placówka nie ma pojęcia, czym jest HL7, a ty jesteś zaznaczony w aptece, ponieważ oni stale informuję cię, że twoje oprogramowanie jest wadliwe.

Uważam, że problem z HL7 polega na tym, że najczęściej odbywa się to tanio. HL7 3.0 może nigdy się nie zmaterializować, ponieważ nigdy nie będzie zarabiać.

Jeśli zamierzasz „zapłacić za HL7”, pamiętaj, że płacisz również za HL [1-6]. Interfejs SOAP nie jest HL7. Analizator komunikatów HL7 nie jest HL7, nie jest też generatorem komunikatów.

— Peter Turner
źródło

HL7 to znacznie więcej niż tylko apteki. Najczęściej HL7 służy do łączenia różnych systemów, takich jak EMR, z systemem rozliczeniowym.

— Bill

Nasz produkt nie jest skierowany do aptek, nawet pośrednio, a reakcja jest bardzo stronnicza, przy niewielkim poparciu dla odpowiedzi.

— Ethel Evans

@Ethel Dodam kilka wyrażeń regularnych, ale powinieneś być bardziej szczegółowy w swoim pytaniu. Robimy więcej niż apteki dzięki naszemu w 100% domowemu wdrożeniu HL7, ale głównym motorem rozwoju jest zawsze „wielka farmacja”, jeśli inni mogą skorzystać z szeroko stosowanej specyfikacji, niech tak będzie.

— Peter Turner,

@Peter: Postaram się sprecyzować, dlaczego uważam, że to nie jest pomocne. Po pierwsze, wyróżniony przez Ciebie cytat wydaje się bardzo stronniczy i nie jest obsługiwany. Po drugie, pozycje na liście numerowanej są albo niejasne, albo nie dodają więcej niż to, co inne odpowiedzi powiedziały wyraźniej. Po trzecie, twój przykładowy scenariusz jest bardzo konkretny i nie przypomina scenariusza, z którym mam do czynienia (i najwyraźniej inni), co czyni go mało informacyjnym. Po czwarte, twoje stwierdzenie, że HL7 odbywa się tanio, wydaje się stronnicze i nie jest obsługiwane. Po piąte, nie robię „HL7”, pracuję z komunikatami HL7, więc punkt ostatniego akapitu został utracony.

— Ethel Evans,

@ Ehel, jak, u licha, mam poprzeć moje twierdzenia, w ogóle nie czerpię korzyści z zajmowania się HL7, to co wiem z moich ostatnich lat pracy z kilkoma dostawcami to to, że kiedy ktoś mówi, że chce współpracować z moim oprogramowania i aby wysłać im „wiadomość testową”, aby mogli dowiedzieć się, jak to powinno wyglądać, stworzą pewnego rodzaju ORM wokół wiadomości i to po prostu zadziała. To nie jest dobre. Jeśli moja odpowiedź wydaje się inna niż inne, to na pewno nie dlatego, że nie mówię prawdy. HL7 dotyczy głównie pieniędzy.

— Peter Turner