Spécifications techniques du format GFOR-GCOR

Spécifications techniques du format GFOR-GCOR MediBridge 20080803 REV 2.3

1 GFOR Proposition de formatage 1.1 CONTACTS Pour toute information complémentaire sur ce document, contactez le support MediBridge : 02/600.40.40 support@medibridge.be 1.2 DEFINITIONS HL7 : Health Level 7, norme d origine américaine spécifiant un formatage pour l échange de données de tous types dans le domaine médical (informations sur le patient, données de facturation, résultats d analyses, sous-traitances, ). C est le format choisi par le consortium Medinet comme unique format à générer par les émetteurs. HL7 est une norme " générale ". Elle requiert de la part des " implémenteurs " de préciser les termes exacts des échanges en spécifiant différents éléments de la norme générale (notamment le dictionnaire utilisé pour codifier les résultats d analyse). GFOR : Generalized Format for Observation Results, nom que nous proposons d utiliser pour désigner les précisions que le consortium Medinet apportera à la norme générale HL7 (" instanciation de HL7 pour Medinet"). ACTH : Association Carolorégienne de Télétransmission Hospitalière, cette association a créé un dictionnaire codifiant les divers types d analyse ; c est le dictionnaire choisi par le consortium Medinet. GCOR : Generalized Codes for Observation Results, nom que nous proposons d utiliser pour désigner les dictionnaires créés par l ACTH ainsi que leurs évolutions futures dans le cadre Medinet et au delà (les efforts nécessaires doivent être fournis afin de garder une cohérence entre les évolutions suggérées par Medinet (Altem) et celles de l ACTH responsable évolution côté ACTH : Dr André VAndenberghe). Afin de préciser clairement les spécifications utilisées par le consortium Medinet, on pourra donc parler du format GFOR/GCOR, sachant que ce format est basé sur HL7 avec le dictionnaire ACTH. 1.3 DEFINITION D UN MESSAGE GFOR : Un message GFOR (message HL7) est structuré de la manière suivante : o Un message constitué de Segments constitués de Identificateur de segment Numéro d ordre du segment Champs Délimités par un caractère 124 : Séparés par des CR Remarque : toutes les références à la norme HL7 sont respectives à la version 2.3 de la norme. Rev 2.3 page 2

1.4 STRUCTURE PROPOSEE : La structure proposée est de type ORU/ACK Unsolicited transmission of an observation message (transmission d un message d observation spontané (sans gestion de demande préalable)). Selon le rapport HL7, le message de type ORU permet de transmettre via cinq types de segments, n importe quel rapport médical. Les segments du message ORU sont : MSH : Message Header PID : Patient Identification OBR : Observation report ID (Type de rapport médical) OBX : Observation/Result (Rapport médical) 1.5 LECTURE DES TABLES : SE Q = Nu mé ro d o rdr e du cha mp da ns le seg me nt Les tables ci-dessous sont les tables GFOR/HL7 proposées pour les messages de type ORU. La légende de chaque colonne est la suivante : LEN DT = Longueur maximale de la partie obligatoire du champ = Data type = Format du type de données. Chaque champ peut faire référence à un type de donnée qui permet ainsi de classifier l information relative au champ. Ce document est fourni avec une annexe reprenant les types de donnée acceptés. Une description complète de ces types se trouve à la section 2.8 de la norme HL7. Rev 2.3 page 3

GOPT ITEM = Importance du champ pour GFOR (certains champs considérés comme optionnels pour HL7 ont été désignés comme obligatoires pour GFOR ; tous les " R " de HL7 sont " R " en GFOR) : R=REQUIRED/OBLIGATOIRE O=OPTIONAL/OPTIONNEL = Identificateur unique du champ dans la liste des tous les champs HL7 (voir annexe A6 de la norme HL7) DESCRIPTION = Description du champ (description HL7 + précisions GFOR) Remarque : Dans un souci de simplification initiale, nous avons omis les possibilités de répétitions multiples des champs, comme HL7 le prévoit. Si une telle possibilité se révélait nécessaire, veuillez nous en avertir : nous la rajouterons dans la spécification du format. Dans les tables et les exemples, nu signifie " non utilisé à l heure actuelle ". 1.6 AUTRES PRECISIONS o Les champs optionnels peuvent être laissés vides à souhait ; dans l exemple ci-dessous, le 4 ème champ est optionnel et vide (entre " E2765 " et " DUPONT^PIERRE ") : PID 1 P276 E2765 DUPONT^PIERRE o Les séparateurs sont cependant requis. Dans le cas de champs TOUS vides ET en fin de segment, il est possible d omettre les séparateurs (nous déconseillons cependant cette simplification car elle rend le traitement moins uniforme). o Nous disposons d une version html (donc visible par un browser internet, sur PC, Mac ou Unix) de la norme HL7. Cette version a l avantage de contenir des hyperliens et vous permettra de mémoriser des signets (bookmarks) vers les sections les plus couramment utilisées. Contactez-nous si vous désirez recevoir ce fichier par email (fichier d 1Mo comprimé zip). 1.7 EXEMPLE DE MESSAGE: Remarques importantes concernant ces exemples : Afin de faciliter la lecture, les marques de fin de segment (carriage return) ont été explicitées par les symboles <CR> ; dans les fichiers " réels ", le simple retour à la ligne (code ascii 13) doit être inséré. Les sauts à la ligne (à l intérieur des segments) dans l exemple suivant sont insérés par le traitement de texte et ne doivent pas être pris en compte. Les types des segments ont été mis en gras afin de faciliter la lecture mais ne font pas partie du format GFOR. Une ligne blanche a été insérée entre chaque Rev 2.3 page 4

segment pour la lisibilité: elle ne doit pas non plus être insérée dans les fichiers réels. Les textes en italique sont des commentaires et ne doivent pas apparaître dans les fichiers réels. MSH ^~\& K654HGT Departement Radio YU7734DFF 199901221630 ORU^R01 P65388 T 2.3 BE ASCII FR<CR> PID 1 JK355 DR023PT6785 110/110 1 640506 069M62 TOUSSEUL^SEBASTIENNE^J^^MME^^M ASSONMOLLET^SEBASTIENNE^J^^MME^ ^L 196405060925 F rue jardon, 52^bte 5^Stembert^^4801^BE 087/291000^PRN^PH^tm@mexi.be^32^87^220785^^apres 18:30 087/291000^WPN^PH^thierry.melon@mexi.be^32^87^291000^^ FR M 6 60815 063 69 VERVIERS BE <CR> OBR 1 RL5645^LOGICIEL-XYZ DR654RP7667^SOFT43 BIO^Biologie^GCOR- SPECIALTY 199902221530 199902231250 A <CR> OBX 1 CE AA94^Antigène érithrocytaire s (petit s)^gcor- BIO 323 ml^milli litres^gcor-units 300-400 H S <CR> OBX 2 ST ^Hemogramme <CR> OBX 3 ST ^Hematocrite 14 % 42-54 L F <CR> OBX 4 FT DR John DUGENOU\.br\Scanner sur rendez-vous (087/ 29 10 00) samedi matin au CHU-OA par le Dr\.br\DUGENOU consultant au CHU\.br\ <CR> rem: <nu> = <non-utilise> rem: cet " exemple générique " reprend le " nom des champs " devant apparaître dans chaque segment. MSH <separateurs> <licence-medinet-emetteur> <antenne-ouservice> <licence- medinet-recepteur> <antenne-ou-service> <date-etheure-du- message> <nu> ORU^R01 <id-du-message-chez-lemetteur> <type-de- message> <version-hl7> <nu> <nu> <nu> <nu> <codepays> <character-set> <langue- du-message><cr> PID <numero-d-ordre-du-patient-dans-le-msg> <id-unique-du-patientchez-le- recepteur> <id-unique-du-patient-chez-l-emetteur> <numerode-mutuelle> <nom-l egal>^<prenom>^<initiale>^<divers>^<entete>^<titre>^<type-de-nom> <nom-de- jeunefille>^<prenom>^<initiale>^<divers>^<en-tete>^<titre>^<type-denom> <date- de-naissance> <sexe> <nu> <nu> <adressepatient> <nu> <tel-prive>^<type-de- telephone>^<type-dappareil>^<email-prive>^<code-pays>^<codezonal>^<numero>^<extension>^<texte> <tel-professionnel>^<type-detelephone>^<type-d-appareil>^<email-professionnel>^<code-pays>^<codezonal>^<numero>^<extension>^<texte> <langue-maternelle> <etatmarital> <nu> <nu> <numero-de-securite-sociale> <nu> <nu> <nu> <lieude- naissance> <nu> <nu> <nationalite> <nu> <nu> <nu><cr> OBR <numero-d-ordre-du-resultat-pour-le-patient> <id-rapport-chezdemandeur> <id-rapport-chez-prestataire> <code-du-type-derapport>^<libelle-du- type-de-rapport>^<systeme-de-codageutilise> <nu> <nu> <date-heure-debut- observation> <date-heure-finobservation> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> < Rev 2.3 page 5

nu> <nu> <nu> < nu> <nu16> <etat-du-resultat-de-lanalyse> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> < nu> <nu> <nu18><cr> 1/ format OBX général OBX <numero-d-ordre-du-segment-pour-le-resultat> <format-duresultat> <identifiant-de-l-analyse> <nu> <identifiant-de-la-valeurde-l- analyse> <unite> <intervalle-de-reference> <indicateur-denormalite> <nu> <nu> <etat-du-resultat-de-lanalyse> <nu> <nu> <nu> <nu> <nu> <nu6><cr> 2/ exemple d'obx structuré (CE) 3/ exemple d'obx NON structuré (ST) 3/ exemple d'obx NON Structuré contenant un texte formaté (FT) OBX <numero-d-ordre-du-segment-pour-le-resultat> CE <codeidentifiant-de-l- analyse>^<libelle-identifiant-de-l-analyse>^gcor- BIO <nu> <code-identifiant-de- la-valeur-de-l-analyse>^<libelleidentifiant-de-la-valeur-de-l-analyse>^gcor- BIO <unite> <intervallede-reference> <indicateur-de-normalite> <nu> <nu> <etat- du-resultatde-l-analyse> <nu> <nu> <nu> <nu> <nu> <nu><cr> OBX <numero-d-ordre-du-segment-pour-le-resultat> ST <texteidentifiant-de-l- analyse> <nu> <identifiant-de-la-valeur-de-lanalyse> <unite> <intervalle-de- reference> <indicateur-denormalite> <nu> <nu> <etat-du-resultat-de-lanalyse> <nu> <nu> <nu> <nu> <nu> <nu><cr> OBX <numero-d-ordre-du-segment-pour-le-resultat> FT <texteidentifiant-de-l- analyse> <nu> <texteformate> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu> <nu>< CR> 1.8 MSH : Message Header segment: Ce segment définit la raison, la source et la destination du message ; ainsi que quelques définitions de syntaxe. Voir la section 2.24.1 de la norme HL7. SEQ LEN DT GOP ITEM DES T # CRIP TION 1 1 ST R 00001 Field Separator A priori toujours ASCII 124: 2 4 ST R 00002 Encoding Characters (cf norme HL7 2.7) Signes de ponctuation, par défaut : ^ ~ \ &. ^ : Séparateur de composant de champs, ASCII 94 (ex :champ adresse= rue^numéro^cp^ville^pays ) Rev 2.3 page 6

~ : Séparateur de répétition, ASCII 126 (ex : un champ pouvant contenir n valeurs, ces valeurs seront séparées par ~ (nu)) \ : Séparateur qui précède des codes Escape Character, ASCII 92 & : Idem que le ^ mais à un niveau plus bas, c est à dire à l intérieur d un ^ (nu), ASCII 38 3 180 HD R 00003 Sending Application Identification de l émetteur structurée comme suit : <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID type (ID)> = <identifiant> ^ <libellé-émetteur> ^ exemple : CHUND02^CHU Notre Dame^ nb l identifiant correspond au champs oldsystemid du fichier mbambh.txt 4 180 HD O 00004 Sending Facility Antenne ou service Exemple: Departement Radio ou mieux: Departement Radio^RXD^GCOR-SPECIALTY (où RXD est le code du département radio selon le dictionnaire ACTH "GCOR-SPECIALTY" des départements/services/spécialités) 5 180 HD R 00005 Receiving Application Identification du récepteur structurée comme suit <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID type (ID)> = <identifiant> ^ <libellé-récepteur> ^ exemple: ADRT03^Dr ADAMS Pierre nb l identifiant correspond au champs oldsystemid du fichier mbambh.txt 6 180 HD O 00006 Receiving Facility Antenne ou service Exemple: - 7 26 TS O 00007 Date/Time Of Message Date & heure du message : YYYYMMDDHHMMSS Exemple: 199901221630 8 40 ST O 00008 Nu 9 7 CM R 00009 Message Type Rev 2.3 page 7

Identification du type de message Exemple: ORU^R01 (toujours cette valeur) 10 20 ST R 00010 Message Control ID Identifiant unique du message Exemple: P65388 11 3 PT R 00011 Processing ID Type de message D=Debugging ; P=Production ; T=Training Exemple: T 12 8 ID R 00012 Version ID Numéro de version HL7 Exemple: 2.3 (toujours cette valeur) 13 15 NM O 00013 Nu 14 180 ST O 00014 Nu 15 2 ID O 00015 Nu 16 2 ID O 00016 Nu 17 2 ID O 00017 Country Code Exemple: BE (toujours cette valeur) 18 6 ID O 00692 Character Set Exemple: ASCII pour les accentués DOSou 8859/1 pour les accentués Windows (toujours une de ces valeurs ) 19 60 CE O 00693 Principal Language Of Message Exemple: FR (toujours cette valeur) 1.9 PID : Patient Identification segment : Ce segment définit les caractéristiques du patient concerné par le message.nous vous demandons de ne générer qu un seul PID par MSG. Voir section 3.3.2 de la norme HL7. Rev 2.3 page 8

SEQ LEN DT BOP ITEM DES T # CRIP TION 1 4 SI O 00104 Set ID - Patient ID Occurrence du segment PID dans le message Exemple: 1 (toujours cette valeur pour l instant) 2 20 CX O 00105 Patient ID (External ID) Identificateur unique du patient chez le récepteur Exemple: JK355 3 20 CX R 00106 Patient ID (Internal ID) Identificateur unique du patient chez l émetteur Exemple: DR023PT6785 4 20 CX O 00107 Alternate Patient ID PID Autre identificateur, par exemple le N de mutuelle Exemple: 110/110 1 640506 069M62 5 48 XPN R 00108 Patient Name Nom du patient. Voir la structure data du type XPN (2.8.48) Exemple: CUSSONET^SIMON^P^JR^MR^PROF.^L Exemple: TOUSSEUL^SEBASTIENNE^J^^MME^^M Rem: L : Legal name, M: nom de femme mariée 6 48 XPN O 00109 Mother s Maiden Name Nom de jeune fille si le champ précédent contient le nom de femme mariée (le champ précédent se termine alors par M) Exemple: ASSONMOLLET^SEBASTIENNE^J^^MME^^L 7 26 TS O 00110 Date/Time of Birth Date (et heure) de naissance Exemple: 196405060925 8 1 IS O 00111 Sex (M=Male, F=Female, O=Other, U=Unknown) Exemple: F 9 48 XPN O 00112 Nu Rev 2.3 page 9

10 1 IS O 00113 Nu 11 106 XAD O 00114 Patient Address, format XAD cf 2.8.45 Exemple: rue Jardon, 52^bte 5^Verviers^^4800^BE 12 4 IS O 00115 Nu 13 40 XTN O 00116 Phone Number Home, format XTN cf 2.8.49 Exemple: 04/3380368^PRN^PH^tm@mexi.be^32^4^3380368^^apres 18:30 14 40 XTN O 00117 Phone Number Business Exemple: 02/6004040^WPN^PH^thierry.melon@mexi.be^32^87^226566^^ 15 60 CE O 00118 Primary Language Exemple: FR 16 1 IS O 00119 Marital Status Exemple: M A=séparé(e), D=divorcé(e), M=marié(e), S=célibataire, W=veuf(ve) 17 3 IS O 00120 Nu 18 20 CX O 00121 Nu 19 16 ST O 00122 SSN Number Patient Numéro de sécurité sociale (cf carte à puce SIC) Exemple: 640506 063 69 20 25 CM O 00123 Nu 21 20 CX O 00124 Nu 22 3 IS O 00125 Nu 23 60 ST O 00126 Birth Place Exemple: Rocourt Rev 2.3 page 10

24 2 ID O 00127 Nu 25 2 NM O 00128 Nu 26 4 IS O 00129 Citizenship Nationalité (cf ISO 3166) Exemple: BE 27 60 CE O 00130 Nu 28 80 CE O 00739 nu 29 26 TS O 00740 Nu 30 1 ID O 00741 Nu 1.10 OBR : Observation Report Id : Ce segment définit le type de rapport médical et ses spécificités. Nous vous demandons de ne générer qu un seul OBR par PID. Voir section 4.5.1 de la norme HL7. SEQ LEN DT BOP ITEM DES T # CRIP TION 1 4 SI R 00237 Set ID - OBR Occurrence du segment OBR dans le PID Exemple: 1 (toujours cette valeur pour l instant) 2 75 EI O 00216 Placer Order Number Identifiant du rapport chez le demandeur Exemple: RL5645^LOGICIEL-XYZ 3 75 EI R 00217 Filler Order Number Identifiant du rapport chez le prestataire Exemple: DR654RP7667^SOFT43 4 200 CE R 00238 Universal Service ID Type de rapport et type de formattage utilisé Rev 2.3 page 11

Exemple: BIO^Biologie^ GCOR-SPECIALTY 5 2 ID O 00239 Nu 6 26 TS O 00240 Requested Date/Time # Date de la demande Exemple: 199902191830 ou 19990219 (pour le 19 février 1999 à 18:30) 7 26 TS O 00241 Observation Date/Time # Date de l observation Exemple: 199902221530 8 26 TS O 00242 Nu 9 20 CQ O 00243 Nu 10 60 XCN O 00244 Nu 11 1 ID O 00245 Nu 12 60 CE O 00246 Nu 13 300 ST O 00247 Nu 14 26 TS O 00248 Nu 15 300 CM O 00249 Nu 16 80 XCN O 00226 Nu 17 40 XTN O 00250 Nu 18 60 ST O 00251 Nu 19 60 ST O 00252 Nu Rev 2.3 page 12

20 60 ST O 00253 Nu 21 60 ST O 00254 Nu 22 26 TS O 00255 Nu 23 40 CM O 00256 Nu 24 10 ID O 00257 Nu 25 1 ID O 00258 Result Status Etat des résultats publiés (cf 4.5.1.25) Exemple: S S=tous les résultats ne sont pas présents, P=résultats préliminaires à vérifier, F=résultats finaux et complets, 26 400 CM O 00259 Nu 27 200 TQ O 00221 Nu 28 150 XCN O 00260 Nu 29 150 CM O 00261 Nu 30 20 ID O 00262 Nu 31 300 CE O 00263 Nu 32 200 CM O 00264 Nu 33 200 CM O 00265 Nu 34 200 CM O 00266 Nu 35 200 CM O 00267 Nu 36 26 TS O 00268 Nu 37 4 NM O 01028 Nu Rev 2.3 page 13

38 60 CE O 01029 Nu 39 200 CE O 01030 Nu 40 60 CE O 01031 Nu 41 30 ID O 01032 Nu 42 1 ID O 01033 Nu 43 200 CE O 01034 Nu 1.11 OBX : Observation/Result : Ce segment définit le contenu du rapport médical. Voir section 7.3.2 de la norme HL7. SEQ LEN DT BOP ITEMDES T # CRIP TION 1 10 SI O 00569 Set ID OBX Occurrence du segment OBX dans l OBR Exemple: 1 ou 2 ou 3 2 2 ID R 00570 Value Type Type de donnée : Codée ou texte libre (une ligne par OBX) Exemple: CE ou ST ou ou FT ou ED ou PT (ne pas utiliser les autres) 3 590 CE R 00571 Observation Identifier Identifiant du type d analyse Exemple: <code-gcor-bio>^<libellé>^gcor-bio Exemple: AA94^Antigène érithrocytaire s (petit s)^ GCOR-BIO Exemple: ^Analyse non codifiée XYZ 4 20 ST O 00572 Nu 5 65536 * R 00573 Observation Value Identifiant de la valeur de l analyse (du résultat) Exemple: <code-gcor-bio>^<libellé>^gcor-bio quand les dicos GCOR-BIO coderont des valeurs alphanumériques Rev 2.3 page 14

Exemple: ^<libellé> s il ny a pas de code GCOR-BIO pour la valeur alphanumérique Exemple: 323 si le résultat est un nombre 6 60 CE O 00574 Units (cf 7.3.2.6) Unités Exemple: ml^millilitre^ GCOR-UNITS Exemple: g/l^grammes/litre^ GCOR-UNITS 7 10 ST O 00575 References Range Intervalle de référence (3 formats autorisés) Exemple: 3.5 4.5 Exemple: < 10 Exemple: > 15 8 5 ID O 00576 Abnormal Flags Indicateur d anormalité (cf table 0078) Exemple: L (=below low normal), H (=above high normal) 9 5 NM O 00577 Nu 10 2 ID O 00578 Nu 11 1 ID R 00579 Observ Result Status (cf table 0085) Etat du résultat de l analyse Exemple: P (=résultats préliminaires), S (=résultats partiels), F (=résultats finaux), 12 26 TS O 00580 Nu 13 20 ST O 00581 Nu 14 26 TS O 00582 Nu 15 60 CE O 00583 Nu 16 80 XCN O 00584 Nu Rev 2.3 page 15

17 60 CE O 00936 Nu 1.11.1 Protocoles multimédia Le but est de transmettre des protocoles au format HTML comprenant des images et/ou des liens vers le site de l émetteur du protocole. Pour ce faire, on utilise des données OBX de type ED (encapsulated data) pour transmettre le protocole HTML proprement dit ainsi que les images associées et des données de type RP (reference pointer) pour transmettre les liens. Un protocole est de type multimedia à partir du moment où il comporte en de ces deux type d OBX. Le champs Type de données ED permet de transmettre des éléments binaires, le corps est encodé en base 64 dans notre implémentation. La syntaxe étant la suivante : Components: < source application (HD) > ^ <main type of data (ID)> ^ <data subtype (ID))> ^ <encoding (ID)> ^ <data (ST)> Où les zones : o <source application (HD) > : définit le nom du fichier codé o <main type of data (ID)> : définit le type de fichier ( image, Application,..) ( défini Type of data (CM) de la norme HL7 ) o o o <data subtype (ID))> : définit le type de fichier ( cf HL7 table 0291 - Subtype of referenced data) <encoding (ID)> : définit le type d'encodage, le Base 64 est principalement utilisé. <data (ST)> : les données proprement dites. Exemple : OBX 1 ED img_prod_thumb20040105122857-.jpg^image^gif^base64^/9j/4aaqskzj OBX 2 ED Protocole.html^Application^HTML^Base64^PGh0bWw+ Le champs Type de données RP permet de transmettre un lien vers un site Internet. La syntaxe étant la suivante : Components: <pointer (ST) > ^ < application ID (HD)> ^ <type of data (ID)> ^ <subtype (ID)> Où les zones : o o <pointer(st) > : définit l adresse à invoquer <ApplicationID (ID)> : inutilisé Rev 2.3 page 16

o <main type of data (ID)> : définit le type de fichier ( image, Application,..) ( défini Type of data (CM) de la norme HL7 ) o <data subtype (ID))> : définit le type de fichier ( cf HL7 table 0291 - Subtype of referenced data) Exemple : OBX 49 RP http://127.0.0.1:81/cimfi/sys/login.php?log=1&lang=fr&dir ectaccess=1&login=pirenne&pass=uelsru5orq==&patientid=102&studyid=113 ^Application ^^Image^JPEG Ces segments OBX ED et RP sont ajoutés au protocole GFOR conventionnel. Typiquement, on aura donc : MSH ^~\& PID 1 OBR 1 OBX 1 FT Objet : Douleur de type OBX 2 ED 603816.jpg^Image^JPEG^Base64^/9j/4AAQS OBX 3 ED Protocole.html^Application^HTML^Base64^PCFkb2N0e Lors du traitement, la partie conventionnelle du protocole GFOR sert à la génération du protocole transcodé (vers HealthOne, Medigest, Medidoc, etc.) tandis qu une copie du protocole est envoyée telle qu elle. La version transcodée arrive dans le dossier habituel chez le récepteur tandis que la version complète arrive dans un dossier spécialement configuré à cet effet. (Par défaut c:\mexi\prenom.nom\edreceived). Le rendu du document HTML chez le récepteur est effectué par son logiciel pour autant qu il en soit capable, sinon par un utilitaire du type mexiwebviewer. Au cas où il n y aurait pas de segment ED contenant une version html du protocole, le système en génère un automatiquement sur base du contenu conventionnel du protocole. Ainsi, le protocole suivant : MSH ^~\& PID 1 OBR 1 OBX 2 FT Objet : Douleur de type OBX 3 ED 603816.jpg^Image^JPEG^Base64^/9j/4AAQS OBX 4 FT Autre image sur la quelle. OBX 5 ED 603817.jpg^Image^JPEG^Base64^/9j/4AAQS OBX 6 FT Cliquez sur l adresse suivante pour. OBX 7 RP http://127.0.0.1:81 Va être complété automatiquement par un ligne OBX de type ED contenant un protocole html où les images et les liens seront insérés à leur place dans le texte. Pour ce faire, le système utilise un modèle nommé ProtoTemplate.html qui se trouve dans le dossier data de mexi. Il peut être adapté à volonté, les marqueurs entre crochets étant remplacés par les données du protocole. Rev 2.3 page 17

1.12 ANNEXE 1 : TYPES DE DONNEES HL7: The data types in this section are listed in alphabetical order. Note: For data types which contain multiple components or subcomponents, the examples given in this section do not specify the optionality of the component or subcomponents. This must be specified in the field definitions that follow the formal segment attribute tables to a maximum length of 64K. Except for the TS data type and the maximum or minimum lengths for several other data types (CE, PN, TX, FT), the field length of HL7 attributes are specified in the segment attribute tables, and any specific length of the components or subcomponents of those attributes must be specified in the field definitions that follow the formal segment attribute tables. In general, HL7 does not specify the lengths of components and/or subcomponents. The data type examples in this Standard are given using the standard HL7 encoding rules, with the delimiter values from figure 2-1 of Section." Although only one set of encoding rules is defined as a standard in HL7 Version 2.3, other encoding rules are possible (but since they are non-standard, they may only be used by a site-specific agreement). In certain data type definitions, square brackets, "[" and "]", are used to specify optional parts of a data type (or of a data type component or subcomponent). 1.12.1 Figure 2-2. HL7 data types Data Type Category/ Data type Data Type Name Notes/Format Alphanumeric ST String Rev 2.3 page 18

TX Text data FT Formatted text Voir http://www.mexi.be/documents/hl7/ch200076.htm Numerical CQ Composite quantity with units <quantity (NM)> ^ <units (CE)> MO Money <quantity (NM)> ^ <denomination (ID)> NM Numeric SI Sequence ID SN Structured numeric <comparator> ^ <num1 (NM)> ^ <separator/suffix> ^ <num2 (NM)> Identifier ID Coded values for HL7 tables IS Coded value for user-defined tables HD Hierarchic designator <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Used only as part of EI and other data types. EI Entity identifier <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> RP Reference pointer <pointer (ST) > ^ < application ID (HD)> ^ <type of data (ID)> ^ <subtype (ID)> PL Person location <point of care (IS )> ^ <room (IS )> ^ <bed (IS)> ^ <facility (HD)> ^ < location status (IS )> ^ <person location type (IS)> ^ <building (IS )> ^ <floor (IS )> ^ <location description (ST)> PT Processing type <processing ID (ID)> ^ <processing mode (ID)> Date/Time DT Date YYYY[MM[DD]] TM Time HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ] TS Time stamp YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ] ^ <degree of precision> Code Values Rev 2.3 page 19

CE Coded element <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)> CF Coded element with formatted values <identifier (ID)> ^ <formatted text (FT)> ^ <name of coding system (ST)> ^ <alternate identifier (ID)> ^ <alternate formatted text (FT)> ^ <name of alternate coding system (ST)> CK Composite ID with check digit <ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> CN Composite ID number and name <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> CX Extended composite ID with check digit <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD) )> ^ <identifier type code (IS)> ^ < assigning facility (HD) XCN Extended composite ID number and name In Version 2.3, use instead of the CN data type. <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> Generic CM Composite No new CM s are allowed after HL7 Version 2.2. Hence there are no new CM s in Version 2.3. Demographics AD Address <street address (ST)> ^ < other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ <address type (ID)> ^ <other geographic designation (ST)> PN Person name <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> TN Telephone number [NN] [(999)]999-9999[X99999][B99999][C any text] XAD Extended address In Version 2.3, replaces the AD data type. <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)> XPN Extended person name In Version 2.3, replaces the PN data type. <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code (ID) > XON Extended composite name and ID number for organizations <organization name (ST)>^ <organization name type code (IS)> ^ <ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility ID (HD)> Rev 2.3 page 20

XTN Extended telecommunications number In Version 2.3, replaces the TN data type. [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^<telecommunication use code (ID)> ^ <telecommunication equipment type (ID)>^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)> Specialty/Chapter Specific Waveform CD Channel definition For waveform data only, see Chapter 7, Section 7.15.3. <channel identifier (*)> ^ <channel number (NM)> & <channel name (ST)>> ^ <electrode names (*) > ^ <channel sensitivity/units (*) > ^ <calibration parameters (*)> ^ <sampling frequency (NM)> ^ <minimum/maximum data values (*)> MA Multiplexed array For waveform data only, see Chapter 7, Section 7.15.2. <sample 1 from channel 1 (NM)> ^ <sample 1 from channel 2 (NM)> ^ <sample 1 from channel 3 (NM)>...~<sample 2 from channel 1 (NM)> ^ <sample 2 from channel 2 (NM)> ^ <sample 2 from channel 3 (NM)>...~ NA Numeric array For waveform data only, see Chapter 7, Section 7.15.1. <value1 (NM)> ^ <value2 (NM)> ^ <value3 (NM)> ^ <value4 (NM)> ^... ED Encapsulated data Supports ASCII MIME-encoding of binary data. <source application (HD) > ^ <main type of data (ID)> ^ <data subtype (ID)> ^ <encoding (ID)> ^ <data (ST)> Price data CP Composite price In Version 2.3, replaces the MO data type. <price (MO)> ^ <price type (ID)> ^ <from value (NM)> ^ <to value (NM)> ^ <range units (CE)> ^ <range type (ID)> ADT/Finance FC Financial class <financial class (ID)> ^ <effective date (TS)> Extended Queries QSC Query selection criteria <name of field (ST)> ^ <relational operator (ID)> ^ <value (ST)> ^ <relational conjunction (ID)> QIP Query input parameter list: <field name (ST) > ^ <value1 (ST) & value2 (ST) & value3 (ST)...> RCD Row column definition: <HL7 item number (ST)> ^ <HL7 data type (ST)> ^ <maximum column width (NM)> Rev 2.3 page 21

Master Files DLN Driver s license number <license number (ST)> ^ <issuing state, province, country (IS)> ^ <expiration date (DT) JCC Job code/class <job code (IS)> ^ <job class (IS)> VH Visiting hours <start day range (ID)> ^ <end day range (ID)> ^ <start hour range (TM)> ^ <end hour range (TM)> Medical Records/Information Management PPN Performing person time stamp: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(id)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID )> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ < date/time action performed (TS)> Time Series: DR Date/time range Scheduling Chapter Only: <range start date/time (TS)> ^ <range end date/time (TS)> RI Repeat interval Scheduling Chapter Only: <repeat pattern (IS)> ^ <explicit time interval (ST)> SCV Scheduling class value pair Scheduling Chapter Only: <parameter class (IS)> ^ <parameter value (IS)> TQ Timing/quantity For timing/quantity specifications for orders, see Chapter 4, Section 4.4. <quantity (CQ)> ^ <interval (*)> ^ <duration (*)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ID)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing (*)> * for subcomponents of these elements please refer to the definition in the text. Rev 2.3 page 22

1 GFOR PROPOSITION DE FORMATAGE... 2 1.1 DEFINITIONS... 2 1.2 DEFINITION D UN MESSAGE GFOR :... 2 1.3 STRUCTURE PROPOSEE :... 3 1.4 LECTURE DES TABLES :... 3 1.5 AUTRES PRECISIONS... 4 1.6 EXEMPLE DE MESSAGE:... 4 1.7 MSH : MESSAGE HEADER SEGMENT:... 6 1.8 PID : PATIENT IDENTIFICATION SEGMENT :... 8 1.9 OBR : OBSERVATION REPORT ID :... 11 1.10 OBX : OBSERVATION/RESULT :... 14 1.10.1 PROTOCOLES MULTIMEDIA... 16 1.11 ANNEXE 1 : TYPES DE DONNEES HL7:... 18 1.11.1 FIGURE 2-2. HL7 DATA TYPES... 18 Rev 2.3 page 23