H L 7

Littéralement HL7 désigne Santé Niveau 7, le chiffre 7 correspond à la couche application de la norme OSI pour les réseaux.
Donc HL7 est un standard qui définit un format pour les échanges informatisés de données cliniques, financières et administratives entre systèmes d’information hospitaliers.

Tous les systèmes informatiques orientés vers la santé tendent à intégrer cette norme, ceci permettra à plusieurs systèmes hétérogènes l’échange de données cliniques sans tenir compte des plateformes et des applications.

Structure de message HL7 : Les messages HL7 sont composés d’une suite de segments, chaque segment est composé d’un ensemble d e champs qui sont eux-mêmes composés de composants et de sous composants. La suite et l’ordre des segments dans le message sont définit par le type de message à envoyer (admission, transfert, congé etc.…). Version HL7 : Il existe plusieurs versions de HL7 :

  • La version 1.0 (1987) était un prototype qui a été peu implanté..
  • La version 2.3 autorise des variations dans l’implémentation des messages aboutissant à des difficultés de communication si les partenaires ne s’entendent pas sur la variation qu’ils retiennent.
  • La Version 2.4 (2000) est devenue une norme accréditée ANSI le 6 octobre 2000. La Version 2.4 a introduit les profils d’interrogation de la conformité dans le chapitre 5 et a ajouté des messages pour l’automatisation en laboratoire, la gestion des applications et la gestion du personnel. De même, un nouvel événement a été ajouté, propre aux exigences OPPS et APC. Cet événement, Transmission de paiement ambulatoire, contient deux nouveaux segments, le segment groupement/remboursement de la visite et le segment groupement des remboursements (GP1, GP2…).
  • La Version 2.5 (2002) est la dernière mise à jour de la série 2.X. Elle contient de nouveaux messages et des mises à jour de la norme précédente, HL7 Version 2.4. À l’heure actuelle, la Version 2.5 contient plus de messages et couvre un champ d’application plus étendu que la Version 3. De plus, elle offre une compatibilité descendante avec les autres versions 2.X, qui sont mises en œuvre à grande échelle dans le monde. Elle a été généralement acceptée en partie à cause de sa flexibilité inhérente pour définir un contenu facultatif des messages sous forme de segment Z. Par contre, son interopérabilité et sa capacité à certifier la conformité ont diminué..
  • La version 3 (lancée en 1997) en cours d’élaboration, conserve le format XML pour la représentation des messages, mais sous une forme beaucoup plus structurée. En effet, la définition de ce format découle d’une réflexion autour d’un modèle objet représenté en (Unified Modeling Language). Cette nouvelle version introduit d’autres concepts tels que le CDA (Clinical Document Architecture), le CCOW (Clinical Context Object WorkGroup). HL7 V3
La version 2.x
  • Problèmes posés de la version 2.x de HL7 :
    • Les messages v2 autorisent les champs de données optionnels, de sorte que la même norme v2 peut être interprétée de différentes manières.
    • La version 2 ne permet pas d'exploiter les outils et les processus contemporains, comme le langage de balisage extensible (XML) et la modélisation orientée objet.
    • La version 2 utilise des outils simples, comme MS Word, de sorte qu'il est difficile de valider et d'élargir ses fonctions.
    • L'objectif et le fondement même de la conception des messages sont en grande partie perdus avec la version 2 de HL7.
  • Présentation succincte de HL7 version 2.3
    • Les séparateurs
      • Séparateur valeur Usage
      • Segment <cr> hex 0D Termine le segment. Cette valeur ne peut pas être modifié.
      • Champs | Sépare deux champs adjacents.
      • Composant ^ Sépare deux composants d'un même champ
      • Sous Composant & Sépare deux sous composants d'un même composant
      • Répétition ~ Sépare plusieurs occurrences du même champ.
      • Échappement \ Caractère d’échappement
    • Règles syntaxiques de HL7 :
      • 1. Les segments doivent se suivre dans l’ordre définit par le type de message ex : ADT/A30). Chaque message est construit de la façon suivante :
        • * Les trois premiers caractères représentent l’identifiant du segment MSH
        • * Chaque champ du segment est inséré de la manière suivante :
          • Un séparateur de champs |
          • Si la valeur du champ n’existe pas aucun caractère n’est requis
          • Si la valeur existe mais nulle alors insérer ""
          • Sinon ajouter les caractères de la valeur du champ dans le segment sans dépasser le maximum, respecter le masque si le champ est formaté
          • Si le champ est un champ composé alors :
            • Si plus d'un composant alors les séparer par le séparateur ^
            • Les composant nuls sont représentés par ""
            • Les composants absents ne sont pas représentés du tout
            • Les composants absents à la fin du champs ne sont pas séparés par ^ exemple: |ABC^DEF^^| est écrit: |ABC^DEF|.
          • Si un composant est aussi composé de plusieurs sous composants alors:
            • Si plus d'un sous composant alors les séparer par le séparateur &
            • Les sous composants nuls sont représentés par ""
            • Les composants absents ne sont pas représentés du tout
            • Les composants absents à la fin du champs ne sont pas séparés par ^ exemple: |ABC^DEF&&^^| est écrit: |ABC^DEF|.
          • Si le champ permet la répétition alors on utilise ~ pour séparer les différentes occurrences
        • La fin de chaque segment est signalé par la présence d'un retour chariot (ASCII 13), si tout le segment est absent alors, la présence de son nom est inutile.
      • 2. Répéter l'étape 1 pour tous les segments
      • 3. Dans le cas de la réception d'un message HL7 il faut tenir compte des règles suivantes:
        • Ignorer les segments, champs, composants, sous composants et répétitions qui sont présents mais non prévus dans le type de message
        • Considérer les segments prévus mais absents comme étant des segments avec des champs absents
        • Considérer les champs et composants prévus mais non inclus dans le segment comme absent.
    • Quelques segments :
      • MSH : Entête, premier segment dans chaque message.
      • PID : Identification du patient
      • EVN : Événement
      • PV1 : Visite du patient
      • PV2 : Complément d’information du PV1
      • OBX : Observation
      • AL1 : Allergie
      • MRG : Fusion
      • ORC : Examen demandé (information globale)
      • OBR : Examen demandé (information détaillée)
      • MSA : Accusé de réception
    • Quelque type de messages :
      • ACK : Message d’accusé de réception général
      • ADR : Réponse ADT
      • ADT : Message ADT
      • OMS : Message de demande de fourniture en stock
      • ORU : Transmission non sollicitée d’un message d’examen
    • Exemple de message HL7 de type ORU : MSH|^~\&|DIGIMED|BPTRU|CIT|PROFIL|200701221630||ORU^R01|IM00001254|T|2.3|||||CA|ASCII|FR PID|1|MP0245|PP2548||JEAN^JACQUES|LAMERE^DEJEAN|196405060925|F|||rue souvenir, 1052^^^^^CA|||FR|M|||660815 063 69||||LAVAL|||CA||||| OBR|1|R2578|R264|ECO^ECOGRAPHIE|||200702221530|200702231250|||||||||||||||||A|||||||||||||||||| OBX|1|ST|^Hémodialyse|||||||||||| fin du message