Quels problèmes ont tendance à survenir lorsque vous travaillez avec des messages HL7?

Je teste un produit pour les entreprises de soins de santé et nous travaillons avec des messages HL7. J'ai vu des gens gémir sur une autre question sur les problèmes avec HL7 mais sans mentionner de détails. Quelqu'un peut-il me donner des idées sur les problèmes ou les catégories de problèmes que nous devrions rechercher spécifiquement?

Nous utilisons des bibliothèques bien utilisées pour l'analyse. Si des détails à ce sujet ou sur ce que nous faisons seraient utiles, faites-le moi savoir dans les commentaires et j'ajouterai à la question si je le peux.

testing parsing hl7

— Ethel Evans
source

Réponses:

Je suppose que vous avez affaire à HL7 v2.x

HL7 est volontairement extrêmement flexible. Cela présente de grands avantages mais présente également des défis. Une règle de base à garder à l'esprit est que chaque implémentation sera différente. Si vous déployez le même produit dans 2 environnements différents (2 hôpitaux par exemple), la règle d'échange de données sera probablement différente. Votre produit doit être prêt à répondre à ces exigences masquées si vous souhaitez pouvoir adapter le nombre d'interfaces HL7 avec lesquelles il va interagir.

Dans la plupart des systèmes de santé traitant le HL7, nous sommes confrontés à cette liste partielle de défis communs:

Chaque système pourrait interpréter la signification de chaque élément de données. Le contexte et les workflows peuvent également influencer la sémantique. J'ai vu certains systèmes utiliser le numéro de compte (PID.18) ou le numéro de visite (PV1.19) pour identifier le patient qui devait se conformer à certains workflows cliniques. Ce type de fossé sémantique aura probablement des répercussions sur la façon dont le système reçoit ces données.
Obligatoire vs facultatif: Puisqu'un élément de données peut être échangé pour atteindre plusieurs objectifs dans plusieurs contextes différents, la plupart des segments et des champs sont documentés comme facultatifs dans la documentation officielle (et certains analyseurs). Cependant, pour satisfaire des flux de travail spécifiques, les produits de santé ajouteraient probablement des règles de contraintes de données et en assoupliraient d'autres. La plupart du temps, une analyse au cas par cas doit être effectuée pour les identifier.
Tableaux: HL7 fournit une liste de valeurs suggérées pour certains champs. Par exemple, la liste de valeurs suggérée pour le genre est longue de 6 ... Évidemment, la plupart des systèmes n'implémentent pas tous les 6 mais quelle est votre stratégie de mappage si vous en recevez une que vous ne supportez pas en amont?
Les segments et les champs peuvent être personnalisés: la longueur des champs, les types de données et d'autres attributs de définition peuvent être personnalisés. Vous devez le mapper à une structure de données que vous connaissez sans perdre d'informations importantes.

jlmorin

www.caristix.com

— jlmorin
source

Quelques problèmes que j'ai rencontrés:

Certaines organisations peuvent utiliser différentes versions de HL7, vous aurez donc des problèmes de compatibilité ("cross-walking"). Vous rencontrerez certainement cela si vous vous impliquez dans des transferts de données inter-organisationnels.
Il n'y a pas de norme sémantique (pour v2.x, je pense que v3 a peut-être commencé à résoudre ce problème), donc même si vous savez quelles données devraient être dans un champ particulier, vous ne connaissez peut-être pas la signification exacte ou la représentation de ces octets.
HL7 est une norme non standard. Il prend en charge les fournisseurs spécifiques Z-segmentsqui sont largement utilisés et totalement propriétaires.
HL7 v2.x (de nombreuses valeurs de x toujours utilisées dans la nature) est un format propriétaire non XML, vous aurez donc besoin d'un analyseur HL7 pour travailler avec. (Ceci, vous le savez, car vous avez déjà une bibliothèque d'analyse HL7 qui ne fait que l'inclure pour les autres)

— G__
source

Le pire d'entre eux est le manque de sémantique. Quand même les personnes qui écrivent la norme disent "vous pourriez bien envoyer X ou Y, mais Z est également valide", vous savez que vous avez un problème. Ce qui sauve, c'est que personne, à l'exception des analyseurs, n'a à gérer toute la gamme d'options HL7 - tout le monde s'occupe du petit sous-ensemble qui est réellement reçu par leurs clients. Cela signifie que l'écriture d'un nouvel accepteur est un processus de découverte (que je traverse en ce moment) plutôt qu'un exercice de "mise en œuvre de la norme". Oh, et devinez quelle option vous devez envoyer pour avoir l'effet souhaité.

@ +1 pour la réponse, et avec je pourrais donner +1 pour inclure des informations pour les personnes autres que l'OP (moi). @moz - bon point sur le simple besoin d'un petit sous-ensemble. Telle est précisément notre situation. Vous confirmez également mon soupçon que la comparaison avec les données des clients sera la clé.

— Ethel Evans

@ethel et @moz, c'est exactement le genre de réflexion qui rend le traitement de HL7 si difficile, veuillez prendre le temps de rendre vos programmes aussi flexibles que possible, HL7 est un endroit où YAGNI n'est en aucun cas applicable.

— Peter Turner

D'accord, cela a du sens. Je ne pense pas que notre application causera des problèmes avec YAGNI, car nous prévoyons d'étendre les types de messages HL7 que nous pouvons utiliser pour fournir de la valeur. Nous savons que nous ne savons pas de quoi nous aurons besoin à l'avenir.

— Ethel Evans

C'est pourquoi je suis un fan de l'utilisation des bibliothèques open source (HAPI / NHAPI) au moins pour le côté récepteur. Beaucoup mieux d'avoir un niveau élevé "nous avons reçu un message HL7 valide mais n'avons pas écrit de code pour le traiter" que "notre analyseur a échoué parce que nous ne nous attendions pas à ce message". Malheureusement, tout le monde commence petit "nous envoyons simplement X et recevons Y", il est donc beaucoup plus simple de pirater quelque chose ensemble pour ensuite l'étendre à chaque fois qu'une nouvelle exigence arrive jusqu'à ce qu'elle s'effondre finalement sous le poids de la cruauté accumulée.

Le premier problème est de s'assurer que tout le monde sait ce qu'est HL7.

C'est un moyen de remplacer les codeurs [médicaux | facturation | assurance] et d'économiser de l'argent [pour une pharmacie | une banque | une compagnie d'assurance].

C'est la ride en plus de tous les problèmes normaux du développement logiciel.

Fluage portée
Spécifications incomplètes
Spécifications propriétaires non valides qui "ne peuvent pas être modifiées"

Donc, vous contactez votre [Pharmacie | Banque | Compagnie d'Assurances] qui veut dépenser tout l'argent qu'ils peuvent d'une interface HL7 à l'établissement qui utilise votre logiciel. Votre contrat est avec l'établissement, leur contrat est avec la pharmacie, la [Pharmacie | Banque | Compagnie d'assurance] n'a aucune idée du fonctionnement de votre logiciel, l'établissement n'a aucune idée de ce qu'est HL7 et vous êtes coché à la pharmacie parce qu'ils vous dire constamment que votre logiciel est bogué.

Je crois que le problème avec HL7 est qu'il se fait principalement à bas prix. HL7 3.0 peut ne jamais se matérialiser car il ne sera jamais monétisé.

Si vous allez "payer pour HL7", n'oubliez pas que vous payez également pour HL [1-6]. Une interface SOAP n'est pas HL7. Un analyseur de messages HL7 n'est pas HL7, ni un générateur de messages.

— Peter Turner
source

HL7 est bien plus que juste pour les pharmacies. Le plus souvent, HL7 est utilisé pour connecter des systèmes disparates tels qu'un EMR à un système de facturation.

— Bill

Notre produit n'est pas destiné aux pharmacies, même indirectement, et la réponse est très biaisée avec peu de soutien à la réponse.

— Ethel Evans

@Ethel Je vais ajouter quelques expressions rationnelles, mais vous devriez être plus précis dans votre question. Nous faisons plus que des pharmacies avec notre implémentation HL7 100% locale, mais le moteur principal du développement est toujours "big pharma", si d'autres peuvent profiter d'une spécification largement utilisée, alors qu'il en soit ainsi.

— Peter Turner du

@Peter: Je vais essayer d'être plus précis sur les raisons pour lesquelles je pense que cela n'est pas utile. Tout d'abord, votre citation en surbrillance semble très biaisée et non prise en charge. Deuxièmement, les éléments de votre liste numérotée sont soit vagues, soit ne s'ajoutent pas à ce que les autres réponses ont dit plus clairement. Troisièmement, votre exemple de scénario est très spécifique et ne ressemble en rien au scénario que je (et apparemment d'autres) traitons, ce qui le rend non informatif. Quatrièmement, votre déclaration selon laquelle le HL7 est effectué à bas prix semble biaisée et non prise en charge. Cinquièmement, je ne fais pas "HL7", je travaille avec des messages HL7, donc le point du dernier paragraphe est perdu.

— Ethel Evans

@Ethel, comment diable suis-je censé soutenir mes revendications, je ne profite pas du tout de la prise en compte de HL7, ce que je sais de mes dernières années de travail avec plusieurs fournisseurs, c'est que lorsque quelqu'un dit qu'il veut travailler avec mon logiciel et pour leur envoyer un "message de test" afin qu'ils puissent avoir une idée de ce à quoi il devrait ressembler, ils créeront une sorte d'ORM autour du message et cela fonctionnera juste pour cela. Ce n'est pas bien. Si ma réponse semble différente des autres, ce n'est certainement pas parce que je ne vous dis pas la vérité. HL7 concerne principalement l'argent.

— Peter Turner