Mise au point : HPRIM2 et AlmaPro

[Stéphane Fraize]

Pour répondre à des questions récurrentes, voici une explication concernant certains problèmes d'intégration de résultats HPRIM2 dans AlmaPro.
Ça concerne essentiellement les formules leucocytaires mais aussi des résultats donnés en mmol et mg par exemple.

J'ai essayé de traiter ce problème il y a presque 8 ans et Alban et mon principal labo se sont renvoyé la balle indéfiniment.

Personnellement, j'ai fini par laisser tomber et je rentre le détail de mes NFS à la main...

Voici l'explication.

Ici un exemple de fichier HPRIM2 transmis par le labo :

RES|Polynucleaires neutrophiles : |NF(10)|N|54.3|%|||N|F||||
RES| Soit:|NF(11)|N|2.83|G/L|1.50|7.00|N|F||||
RES|Polynucleaires Eosinophiles : |NF(12)|N|3.1|%|||N|F||||
RES| Soit:|NF(13)|N|0.16|G/L|0.10|0.40|N|F||||
RES|Polynucleaires basophiles : |NF(14)|N|0.4|%|||N|F||||
RES| Soit:|NF(15)|N|0.02|G/L|0.00|0.10|N|F||||

Explication d'Alban :
Ce labo ne respecte pas la norme HPRIM2 qui prévoit qu'un même résultat en plusieurs unités (ici /mm3 ou % ; mais on a le même cas avec mg / mmol) figure sur UNE SEULE ligne.
En effet les petits traits verticaux qu'on voit ( |||||| ) déterminent des cases et certaines cases sont prévues, en norme HPRIM2, pour tenir compte de ces unités différentes.
Bref, tout devrait être sur une seule ligne et les "Soit:" qu'on voit occupent en fait une case de dénomination d'analyse. AlmaPro n'a aucun moyen de distinguer les différentes lignes "Soit" et de savoir ce qui se rapporte à des neutrophiles, des éosinophiles,...

Explication du labo :
Votre logiciel est mal fichu, il devrait raisonner sur la case suivante (NF(11)| ; NF(13)| ; NF(15)|) car il s'agit d'un code unique, propre à chaque labo, pour une donnée précise alors que la case précédente est généralement utilisée pour une dénomination en texte libre qui peut être redondante (et qui varie parfois dans le temps contrairement au "code unique").

Voilà.
Alban a parfaitement raison sur le fond. Ce sont les labos qui ne respectent pas l'intégralité de la norme HPRIM2.
Inversement, je ne vois pas bien ce qui empêche AlmaPro de raisonner sur la troisième case (le "code unique") pour tenir compte de cet état de fait.
La balle au centre.

Encore une fois, rien de neuf, ça fait 8 ans que ça n'a pas bougé.

Stéphane

[olivier]

Bonjour,

Je crois avoir une solution.
Comme je l'expliquais dans un autre message :
- je configure APICRYPT pour exporter décrypter les fichiers HPRIM dans le répertoire Almapro qui va bien : donc je n'utilise pas la fonctionnalité de décryptage de Almapro
- je lance un script Python pour modifier le HPRIM comme je veux
- Dans Almapro : Decrypter les nouveaux messages

Mon labo fait le même genre de connerie :
| P neutrophiles |...
|| ...

Mon script reconnais les cases vides et ça donne :
| P neutrophiles |...
| P neutrophiles2 |...
Avec le choix des unités.

Vu votre exemple je pense qu'on pourrait généraliser le processus en utilisant la 3e case : chez vous c'est NF(10) et NF(11), dans mon labo c'est F2 et F3... au final si on compare les caractères alphabétiques sans tenir compte des numériques ça devrait aller. A ce moment là on remplacerait dans la première case "Soit ..." par "P neutrophiles 2" qu'Almapro pourra identifier.

Dès que j'ai 5 minutes j'arrange ça et je poste ici le script et un petit tuto.

Avantage de la méthode : on peut virtuellement tout modifier.
Inconvénient : comme tous les labos ne respectent pas HPRIM de la même manière, c'est pas forcément évident de trouver un truc applicable pour tous.

Cordialement

[olivier]

Voici le script python très simple que j'utilise, modifié pour utiliser le code labo :

Rapidement :

A - Une fois pour toutes
1- installer Python3 disponible gratuitement sur le net
2- décompresser le fichier ZIP dans c:\ALMAPRO\HPRIM
3- Dans APIMAIL : OUTILS > OPTIONS > EXPORTER AUTOMATIQUEMENT : entrer le chemin c:\ALMAPRO\HPRIM

B - A chaque réception de courrier :
!! L'idée est de recevoir les courriers cryptés par Apimail, et non directement par Almapro !!
1- Dans APIMAIL cliquer sur "Vérifier les courriers" (première icone)
2- Ouvrir l'explorateur Windows sur le répertoire c:\ALMAPRO\HPRIM, double clic sur le fichier PyHPRIM1.py
3- Dans Almapro, dans un dossier patient, cliquer sur "HPRIM > Décoder les fichiers HPRIM"

C'est tout si tout va bien.
Almapro demandra deux associations pour certains paramètres : par exemple il y aura "P neutrophiles" et "P neutrophiles*" (noter l'astérisque) et sauf erreur de ma part on peut associer chacun avec une unité différente dans Almapro.

[olivier]

Pour Stéphane Fraize : en fait n'utilise pas mon script en l'état, je n'avais pas vu que ton labo ne donne pas de code spécifique à chaque ligne donc ça va merder et tout nommer selon le premier paramètre qui porte ce code labo.
En cas de problème le script créé un répertoire "bak" avec les fichiers apicrypts originaux.

Le seul moyen est de repérer le mot "Soit" en première case ; je regarde ça dès que j'ai le temps. Sachant que chaque labo fait à sa sauce...
Il sont pénibles ces labo de ne pas savoir lire 3 pages de spécifications avant de pondre leurs logiciels...

[TChatenet]

Bonjour ,

Oui , la modification des examens transmis par les labos est acrobatique et risquée et ne devrait en réalité pas avoir lieu d'être .
La difficulté est d'identifier à coup sûr un examen de labo pour le substituer par ce que l'on veut .
Et vu que la norme n'est pas toujours comprise de la même manière par les divers éditeurs du marché il y a des moments où c'est périlleux .
C'est d'ailleurs pour cela que rares sont les éditeurs de logiciels médicaux proposant cette fonction de substitution car le risque de dénaturer les examens est trop grand . Tout le monde attend l'évolution de la norme qui devrait unifier les codes . Je ne sais plus bien quand ce chantier a commencé mais il doit y avoir plus de dix ans et j'ignore où il en est ....

Je conçois mal un système permettant d'intégrer en toute sécurité les deux valeurs d'un même examen , car c'est de cela qu'il s'agit quand il est attendu de pouvoir intégrer la formule blanche en pourcentage et en valeur absolue quand le labo les propose sur la même ligne . Déjà il me semble que la base de biologie de Almapro devrait pour commencer proposer deux libellés différents histoire de ne pas alterner pourcentage et valeur absolue dans le tableau récapitulatif sous le même libellé . Ensuite il faudrait que le module de décodage invente un code qui serait unique pour représenter la deuxième valeur de chaque ligne d'examen afin de le proposer à la reconnaissance . Comme je ne vois pas comment ce traitement pourrait être automatiquement réservé à la seule NFS cela voudrait dire que l'on doublerait le nombre d'items à reconnaitre et donc les chances d'erreur qui sont déjà très élevées dans le module actuel qui ne permet pas de visualiser l'examen ou la ligne à reconnaitre au moment de la reconnaissance .

Je me suis très tôt intéressé à l'uniformisation des résultats Hprim et cette fonction m'a pourtant toujours gêné car nous dénaturons une production qui n'est pas la nôtre sans retour en arrière possible .

J'ai récemment entendu parler d'un mode opératoire qui m'a immédiatement séduit :
Les résultats HPRIM sont intégrés et conservés dans la base sans la moindre modification ou correction donc le résultat original n'est pas perdu ET le visualiseur du logiciel métier pratique une substitution à la volée donc les résultats affichés sont uniformisés ainsi qu'attendu . L'intérêt est double car la consultation des résultats originaux est toujours possible et la correction d'une erreur d'identification est immédiatement rétroactive .

Que du bonheur !
Qu'en pensez vous ?

[olivier]

Bonjour ,

Oui , la modification des examens transmis par les labos est acrobatique et risquée et ne devrait en réalité pas avoir lieu d'être .

Mon scipt est sûr pour mon utilisation car je connais la façon dont mes 2 labos structurent (mal) leurs données. Le problème est de le généraliser, il faudrait étudier des fichiers HPRIM venant de nombreux labo différents pour trouver le point commun.

Je vais pour l'instant faire la modification suivante pour détecter si deux lignes correspondent à deux unités du même paramètre :

Code : Tout sélectionner

si la cellule 0 (première case) est vide ou, privée des caractères non alphabétiques (.,; etc.) est égale à "soit"
ET
si la cellule code labo (2 ou 3 je ne sais plus) privée de ses caractères numériques est identique à la ligne précédente (chez moi par exemple "PN" ; dans l'exemple du premier message "NFS()") 
>>>> c'est que cette ligne reprend le paramètre précédent avec une autre unité.

De plus les fichiers HPRIM originaux sont sauvegardés automatiquement dans un répertoire séparé.
Enfin à titre personnel, vu les nombreux problèmes d'unités (en plus je n'arrive pas à mettre à jour la base de biologie) je coche systématiquement la croix "conserver également sous forme de courrier" dans Almapro.

Code : Tout sélectionner

Je conçois mal un système permettant d'intégrer en toute sécurité les deux valeurs d'un même examen

C'est un point à approfondir mais pour l'instant je n'ai pas de problème avec. Chaque valeur Almapro est rattaché à deux valeurs HPRIM par exemple % et G/l. Je n'ai pas regardé ce que ça donne pour les graphiques, possible que ça coince.
Auquel cas il faut perfectionner le script pour réécrire complètement le HPRIM (donc rassembler sur une seule ligne deux lignes correspondant à deux unités pour le même paramètre).
La page http://bluegyn.com/spip/spip.php?article387 donne précisément la structuration des valeurs normales, différentes unités, etc.

C'est d'ailleurs pour cela que rares sont les éditeurs de logiciels médicaux proposant cette fonction de substitution

Les labos n'auront la pression que quand la majorité des logiciels métiers structureront enfin les données bio correctement. L'un des problèmes est je pense la non standardisation des examens biologiques. Il faudrait que l'OMS crée un thésaurus des examens biologiques.

Les résultats HPRIM sont intégrés et conservés dans la base sans la moindre modification ou correction donc le résultat original n'est pas perdu ET le visualiseur du logiciel métier pratique une substitution à la volée donc les résultats affichés sont uniformisés ainsi qu'attendu .

Ce serait bien mais si un labo donné modifie sa présentation des résultats (unité, ...) et que la modification est rétro active sur les anciens résultats ça fera désordre.

Mon script se veut pragmatique : la norme HPRIM est incomplète, les labos l'implémentent n'importe comment car ils partent du principe qu'aucun logiciel métier ne structure les données bio (almapro est le seul non ?). J'ai fais un truc qui marche bien pour mon utilisation personnelle.

Le problème serait de faire un script généralisable. L'utilisateur final doit absolument vérifier que les modifications sont adéquates avant une utilisation quotidienne.
Ce serait plus facile en créant un vrai petit logiciel autonome avec interface graphique qui guiderait l'utilisateur pour configurer la moulinette, mais je n'ai pas le temps d'apprendre à créer une interface en Python.

[TChatenet]

Bonjour ,

Mon scipt est sûr pour mon utilisation car je connais la façon dont mes 2 labos structurent (mal) leurs données. Le problème est de le généraliser, il faudrait étudier des fichiers HPRIM venant de nombreux labo différents pour trouver le point commun.

Tu peux bien sûr réaliser un script personnel adapté à ta situation sans aucune difficulté .
Quand il s'agit de réaliser quelque chose de diffusable qui sera confronté à toutes les aberrations de la vraie vie c'est parfois surprenant .
Déjà l'identifiant unique de l'examen :
Tu ne peux pas te contenter d'une clé associant le nom du labo au code labo de l'examen car le nom du labo n'est pas toujours présent dans l'entête , et tu ne peux pas te contenter du seul code labo car rien ne te dit que le même code ne sera pas utilisé par deux labos différents pour des examens différents
Une meilleure approche est l'association du code labo et du libellé médecin de l'examen . Cela laisse peu de chances à ce que le code soit utilisé pour un examen différent ailleurs à condition toutefois que le champ libellé médecin soit renseigné ce qui n'est pas toujours le cas .
Et de toutes façons ça ne te prémunit pas d'un changement de paramétrage du labo qui modifierait ses unités ou leur ordre
Donc on peut affiner en créant une clé faite de l'association libellémédecin + code labo + unité 1 + unité 2.
C'est en tous cas le choix qui avait été le mien dans le script que j'avais commis à l'usage des utilisateurs de Axisanté.

si la cellule 0 (première case) est vide ou, privée des caractères non alphabétiques (.,; etc.) est égale à "soit"
ET
si la cellule code labo (2 ou 3 je ne sais plus) privée de ses caractères numériques est identique à la ligne précédente (chez moi par exemple "PN" ; dans l'exemple du premier message "NFS()")
>>>> c'est que cette ligne reprend le paramètre précédent avec une autre unité.

Là tu résoud un problème particulier de la formule blanche telle que l'a paramétrée UN labo , tu n'es pas sorti de l'auberge ...

Les labos n'auront la pression que quand la majorité des logiciels métiers structureront enfin les données bio correctement. L'un des problèmes est je pense la non standardisation des examens biologiques. Il faudrait que l'OMS crée un thésaurus des examens biologiques.

C'est le fameux chantier dont je te parle ... . Ce n'est à mon avis pas le rôle de l'OMS mais celui du ministère de la santé . On aurait pu espérer que le délire DMP fasse avancer les choses ..

Les résultats HPRIM sont intégrés et conservés dans la base sans la moindre modification ou correction donc le résultat original n'est pas perdu ET le visualiseur du logiciel métier pratique une substitution à la volée donc les résultats affichés sont uniformisés ainsi qu'attendu .

Ce serait bien mais si un labo donné modifie sa présentation des résultats (unité, ...) et que la modification est rétro active sur les anciens résultats ça fera désordre.

Tu n'as pas bien compris : si un labo modifie quelque chose on aura un nouvel examen à reconnaitre et cela ne changera rien à ceux déja associés

Le problème serait de faire un script généralisable. L'utilisateur final doit absolument vérifier que les modifications sont adéquates avant une utilisation quotidienne.
Ce serait plus facile en créant un vrai petit logiciel autonome avec interface graphique qui guiderait l'utilisateur pour configurer la moulinette, mais je n'ai pas le temps d'apprendre à créer une interface en Python.

Et tu trouveras peu d'utilisateurs non férus de l'informatique prêts à installer un interpréteur Python sur leur machine Windows ..

Bonne journée

[TChatenet]

Il y a des jours où on démarre dans la mauvaise direction .

Persuadé que la demande initiale était de pouvoir intégrer les deux unités d'une seule ligne j'ai passé la première et embrayé .
En relisant ce post je me rends compte que ce n'est pas l'exemple fourni
Effectivement , même si le libellé médecin est fantaisiste ( soit : ) l'examen est parfaitement identifiable car il possède un code propre .
Je ne vois pas pourquoi il ne serait pas reconnu par le module et si c'est le cas ce module mériterait d'être amélioré sur ce point là aussi .
J'aurai un peu de temps cette après midi pour observer le comportement de Almapro sur ces lignes .

[TChatenet]

Effectivement , ça craint .
Manifestement ce module ne tient pas compte du code labo mais uniquement du libellé praticien car la demande d'association n'est faite pour ' soit: ' qu'une seule fois
Tel quel ce module est donc à même de faire n'importe quoi . J'ai par exemple un labo qui envoie comme libellé praticien ' hématies ' autant pour les hématies de la NFS que pour les résultats urinaires .
Cela faisait un petit temps que les résultats présents sur les tableaux me posaient question au point que je ne regarde plus que les résultats au format texte et j'avais remis l'exploration du problème à plus tard , maintenant j'ai l'explication .
Tel quel ce module est la parfaite illustration de ce qu'il ne faut pas faire et des dangers de la substitution .
Si on ajoute qu'il confond le champ correspondant avec le champ labo ce qui m'oblige à recommencer toutes les associations à chaque changement d'infirmier et que ces associations se font à l'aveugle car il est impossible de visualiser l'examen en cours de reconnaissance il n'existe qu'une solution :
Le retravailler pour les développeurs et éviter de l'utiliser en attendant sa refonte pour les utilisateurs du logiciel .
Je vous rappelle que vous ( chaque usager ) assumez l'entière responsabilité de cette altération du compte rendu signé par le laboratoire et l'entière responsabilité des aberrations du module de substitution .
On ne peut pas traiter ce sujet à la légère .
Alban n'a peut être pas complètement tort quand il dit que la norme HPRIM n'est pas parfaitement respectée par le labo montré en exemple mais de toutes façons limiter les identifiants des examens aux seuls libellé medecin associé au nom du correspondant c'est au mieux un coupable manque de rigueur .

Pour en revenir au problème de l'intégration de la formule blanche autant en valeur absolue qu'en pourcentage : ce n'est pas possible tant qu'il n'existe qu'une seule variable dans Almapro . On parvient à faire admettre à cette variable successivement le pourcentage et la valeur absolue et c'est affichable à l'ouverture de l'examen mais le tableau n'affiche qu'une valeur par variable et par jour donc ce sera soit la valeur absolue soit le pourcentage selon l'ordre dans lequel ils ont été intégrés , donc selon l'ordre des lignes dans le résultat du labo .

un exemple du jour provenant d'un labo local pour illustrer combien il est insuffisant de se contenter du libellé medecin pour identifier les examens . Ce libellé n'est pas et n'a jamais été un identifiant

Code : Tout sélectionner

RES|HEMATIES x1 000 000|GR|N|5.25|/mm3|3.8|5.4|N|F|5250000|/mm3|3800000|5400000|
RES|H‚moglobine|HB|N|14.2|g/100mL|12.5|15.5|N|F|||||
RES|H‚matocrite|HT|N|40.0|%|37|47|N|F|||||
RES|V.G.M.|VGM|N|76|µ3|82|99|L|F|||||
RES|T.C.M.H.|TCMH|N|27.0|picog|27|0|N|F|||||
RES|C.C.M.H.|CCMH|N|36|%|32|36|N|F|||||
RES|LEUCOCYTES x1 000|GB|N|5.45|/mm3|4|10.001|N|F|5450|/mm3|4000|10001|
RES|P. neutrophiles|PN|N|50.0|%|||N|F|||||
RES|P. neutrophiles|PN3|N|2725|/mm3|1800|7501|N|F|||||
RES|P. éosinophiles|PE|N|0.5|%|||N|F|||||
RES|P. éosinophiles|PE3|N|27|/mm3|100|401|L|F|||||
RES|P. basophiles|PB|N|0.5|%|||N|F|||||
RES|P. basophiles|PB3|N|27|/mm3|0|201|N|F|||||
RES|Lymphocytes|LY|N|39.0|%|||N|F|||||
RES|Lymphocytes|LY3|N|2126|/mm3|1000|4501|N|F|||||
RES|Monocytes|MO|N|10.0|%|||N|F|||||
RES|Monocytes|MO3|N|545|/mm3|20|1001|N|F|||||
RES|100% de la formule|NF100|N|100||||N|F|||||
RES|PLAQUETTES x1 000|PLA|N|250|/mm3|150|401|N|F|250000|/mm3|150000|401000|
RES|V.P.M.|VPM|N|9.0|µ3|0|10.1|N|F|||||

Bonne fin de journée

[olivier]

Effectivement tu mets le doigt sur un problème qui m'avait échappé... La structuration des examens biologiques par Almapro est donc impossible pour le moment dans de bonnes conditions.

[TChatenet]

Explication illustrée du problème .
Telle quelle la discrimination des examens est beaucoup trop imparfaite pour être acceptable

[Stéphane Fraize]

Effectivement tu mets le doigt sur un problème qui m'avait échappé... La structuration des examens biologiques par Almapro est donc impossible pour le moment dans de bonnes conditions.

Ça me paraît un poil exagéré.
Pour ma part, ça ne me gêne que pour les formules leucocytaires et quelques autres "détails" (urines de 24 heures...).

Dans l'ensemble, ça marche assez bien tout de même.

Après avoir échangé avec Alban, celui-ci m'a répondu que la 3ème colonne était parfois remplie de manière toute aussi fantaisiste, empêchant de se fonder dessus.
Il m'a donné cet exemple à l'appui :

image[1].png (178.4 Kio) Consulté 18808 fois

Sauf que j'ai un doute et je me demande si cette capture d'écran correspond bien à un fichier HPRIM2 récent.

Vous êtes quelques-uns à avoir mis des captures d'écran. A chaque fois, la 3ème colonne comprend un code bien spécifique. Ce serait chouette que les uns et les autres vérifient auprès des différents labos pour voir ce dont il en retourne.

[TChatenet]

Bonjour ,

Le cas de figure que tu illustres est certainement moins fréquent que l'inverse car le code labo est le code interne utilisé dans leur gestion informatique .
De toutes façons cet exemple illustre bien la nécessité de multiplier les critères de reconnaissance, aucun d'eux pris séparément n'offrant une sécurité suffisante .
Ce n'est tout de même pas la mer à boire de concaténer le code labo au libellé medecin à l'unité 1 et à l'unité 2 et de se servir de la chaine obtenue comme clé de reconnaissance .
L'intérêt d'inclure les unités dans la clé de reconnaissance réside dans la détection des modifications de présentation du résultat par le labo ce qu'ils font de temps en temps ( changement d'ordre des unités ou d'ordre de grandeur du résultat ).

la gêne à l'usage est certaine et ne concerne pas que la num
viewtopic.php?f=14&t=185