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.

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

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)

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.

1. Fluage portée
2. Spécifications incomplètes
3. 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.