Transactions HL7 et encodage base64
Le protocole HL7 est utilisé de façon extensive pour échanger des données cliniques. Il est basé sur l’utilisation de caractères ASCII lisibles. On peut donc lire facilement les messages (ou transactions). Chaque message comporte des segments. Les segments sont identifiés au début par 3 caractères ASCII, comme MSH qui est l’entête et PID qui est l’identifiant du patient Les éléments des segments sont délimités par des caractères comme le pipe « | » qui sépare les champs, l’accent circonflexe « ^ » qui sépare les composantes d’un champ, l’esperluette « & » qui sépare les sous-composantes, le tilde « ~ » qui marque la répétition d’un champ.
Dans un message HL7, il est possible d’insérer des fichiers, de nature binaire, comme des images ou en texte lisible, comme des rapports codés en RTF par exemple.
L’important à retenir ici est la nature du protocole HL7, qui est du texte lisible.
Problèmes
Le problème qui se présente lorsque l’on a un protocole (comme HL7) qui utilise du texte, des caractères ASCII, c’est l’insertion d’un caractère qui sert de caractère de contrôle au protocole, dans le message. Par exemple, si on veut insérer dans un message, un texte qui contient un « & » comme « XR poumon PA&LAT » ou un nom comme « Gilbert & fils », il faut convertir le « & » , car le « & » est un caractère de contrôle utilisé par HL7.
Cette difficulté est amplifiée quand on veut insérer un document complet comme un RTF par exemple. Le format RTF est constitué de caractères ASCII lisibles et de caractères de contrôle ASCII comme «CR» (carriage return) et «LF» (linefeed).
Le «CR» est utilisé par le RTF et il délimite aussi la fin d’un segment en HL7. Le tilde (~) est utilisé dans les rapports pour exprimer une approximation (environ) et il s’agit aussi d’un caractère de contrôle de HL7.
On voit bien que de graves erreurs peuvent se glisser si on n’y prête pas attention. L’analyseur (parseur) est un automatisme qui ne réfléchit pas.
Solutions
Il existe deux solutions à ce problème. La première est de remplacer les caractères de contrôle supporté par HL7 par des séquences d’échappement (Escape Sequences) dans le texte que l’on veut insérer dans le message. Par exemple, si on veut insérer « XR poumon PA&LAT », la séquence sera « XR poumon PA\T\LAT ».
Quand on a un fichier RTF à insérer, il faudra le convertir en BASE64, ce qui éliminera tous les caractères spéciaux de la séquence ASCII du fichier RTF. La conversion en BASE64 permet aussi d’insérer des fichiers binaires comme des images ou des fichiers de son comme des waves, MP3, et autres. La conversion BASE64 nous assure de l’intégrité des fichiers à transférer.
Voici un exemple d’un message qui contiendrait un rapport RTF encodé BASE64 :
OBX|1|ED||Rapport RTF|RTF^TEXT^^Base64^[textencodé]||||||P|||||1112002
Mises en garde
Si le parseur rencontre des caractères qu’il reconnait comme des caractères de contrôle dans le contenu des messages, il rejettera le message et cela pourra être très difficile à diagnostiquer.
Le protocole HL7 est un outil d’échange de données et de résultats très important entre deux logiciels ou deux systèmes qui doivent partager des données sur la santé des patients. Il va sans dire que les processus d’échange ne doivent en rien altérer les données contenues dans les rapports. Les parties impliquées dans les échanges doivent donc remplir leurs obligations et s’assurer que les rapports qu’ils envoient soient encodés comme il se doit. Actuellement, Imagem est obligée de parser les rapports RTF pour en extraire les caractères en conflit avec HL7. Comme il s’agit d’une altération qui peut conduire à des transmissions de rapports erronés, Imagem se dégage de la responsabilité de cette manière de faire. Imagem encourage donc les responsables à demander au fournisseur qu’il corrige cette lacune que nous estimons grave. Cette mauvaise pratique ne serait pas tolérée chez Imagem qui considérerait ce cas comme une faute à corriger.