La transaction KMEHR résultat de laboratoire est la spécification de transaction belge pour l'échange de résultats issus de plusieurs disciplines de laboratoire.[1] La version 1.1 autorise du texte libre ou des documents et recommande des éléments structurés.[1] La version 2.0 emballe un rapport de laboratoire FHIR conforme au Lab-IG belge ainsi qu'un pdf dans une enveloppe KMEHR minimale destinée au système hub-métahub.[2][2][2] Pour les hôpitaux, ce choix détermine quelle sortie le système d'information de laboratoire doit produire pour la publication des résultats de laboratoire.[1][2]
", "last_verified": "2026-10-05", "verification_outdated": false, "sections": [ { "id": "qu-est-ce-que-c-est", "title": "Qu'est-ce que c'est ?", "kind": "tekst", "html": "« Laboratory result » est un type de transaction au sein de KMEHR permettant de transmettre des résultats issus du laboratoire, de l'anatomopathologie, de la génétique, de la bactériologie, de la biologie moléculaire et de la toxicologie ; la version 1.1 date du 2022-07-01 et a le statut Published[1]. Il existe en outre « Laboratory result 2.0 » (KMEHR avec FHIR intégré, v2.0, 2023-12-08, propriétaire Plate-forme eHealth), une transaction KMEHR minimale que le système hub-métahub actuel peut traiter et qui contient un rapport de laboratoire FHIR[2].
\nLa version 1.1 permet aux laboratoires d'échanger des résultats dans le format KMEHR courant.[1] La version 2.0 résout un problème de transition : le rapport de laboratoire FHIR peut circuler via l'infrastructure de hubs existante, accompagné d'un pdf simple pour les clients qui ne sont pas encore capables de traiter FHIR[2]. Les hubs souhaitent expressément une transition progressive d'un paysage sans clients capables de traiter FHIR vers un paysage avec uniquement des clients capables de traiter FHIR[2].
" }, { "id": "comment-est-il-structure", "title": "Comment est-il structuré ?", "kind": "tekst", "html": "Version 1.1. La transaction n'exige que le niveau de normalisation KMEHR 1 ; des niveaux supérieurs sont possibles[1]. Elle exige CD-TRANSACTION=labresult ; des codes locaux peuvent être ajoutés en complément[1]. Un résultat peut être transmis sous forme de texte libre ou de document incorporé, mais une structuration au moyen d'items avec des codes CD-LAB est fortement recommandée[1]. Pour l'organisation en paragraphes, la transaction recommande la table CD-HEADING-LAB[1]. Zéro, un ou plusieurs codes CD-LABORESULT-TYPE décrivent les sujets du rapport[1]. La date de la transaction est la date du rapport ; une date d'exécution différente se place au niveau de l'item[1]. La Plate-forme eHealth annonce, sur la page de cette transaction, une évolution vers une spécification en HL7 FHIR[1].
\nVersion 2.0. Le document FHIR incorporé doit suivre les règles du guide d'implémentation FHIR belge pour les résultats de laboratoire[2]. Outre le document FHIR, la transaction contient un pdf (base64) pour les clients qui ne peuvent pas traiter FHIR[2].
\nDemande de laboratoire. La transaction apparentée « Laboratory request » (version 1.0, 2002-10-15) annonçait pour 2018-2019 un successeur en HL7 V3 CDA R2 dans une enveloppe KMEHR ; un tel successeur n'a pas été retrouvé[3]. Le texte de définition de la page « Laboratory request » décrit la transaction Procedure Request et exclut précisément les demandes de laboratoire, ce qui ressemble à une erreur de copie[3]. Voir Demande électronique d'analyses de laboratoire.
" }, { "id": "ou-est-il-utilise", "title": "Où est-il utilisé ?", "kind": "tekst", "html": "Les deux versions servent l'échange des résultats de laboratoire cliniques.[1][2] Au sein de DIGIRELAB, la première phase passe par l'eHealthBox avec le guide d'implémentation Lab-IG comme charge utile ; la version 2.0 est l'emballage pour les hubs[2][2].
" }, { "id": "qu-est-ce-que-cela-signifie-pour-un-hopital", "title": "Qu'est-ce que cela signifie pour un hôpital ?", "kind": "tekst", "html": "