Volet Téléradiologie - version de développement local (intégration continue v0.1.0) construite par les outils de publication FHIR (HL7® FHIR® Standard). Voir le répertoire des versions publiées

Volume 2 : Détail des transactions

Introduction

La présente spécification technique définit les modalités d’échange des informations de téléradiologie au moyen du standard HL7 version 2.5.1. Elle a pour objectif de préciser les profils de messages, segments, champs, cardinalités et règles d’usage nécessaires à l’interopérabilité entre les systèmes d’information impliqués dans les processus de téléradiologie, particulèrement les RIS et les plateformes de téléradiologie.

Cette spécification s’applique exclusivement aux flux identifiés dans le Volume 1 - Etude fonctionnelle. Le choix du standard est également le fruit d’une étude dédiée à retrouver en annexe.

Les échanges sont basés sur des messages HL7 v2 conformes à la version 2.5.1. Lorsque cela est applicable, la spécification s’appuie sur les profils du domaine IHE Radiology, et notamment le profil IHE Scheduled Workflow (SWF.b), afin d’assurer la cohérence des échanges avec les workflows d’imagerie existants. Les principes définis par le profil IHE PAM-FR sont également pris en compte pour la gestion de l’identité patient, en particulier en ce qui concerne l’identité nationale de santé (INS). Enfin, les types de données HL7 v2 sont contraints, lorsque cela est applicable, par la spécification Contraintes sur les types de données HL7 v2.5 applicables aux profils d’intégration du cadre technique IT Infrastructure, publiée par Interop’santé.

Il est pertinent de préciser que les flux décrits dans la présente spécification portent principalement sur des données nécessaires à l’orchestration du workflow.
La transmission de la demande d’examen d’imagerie formalisée sous forme de document clinique, ainsi que celle d’éventuels documents cliniques complémentaires, n’est pas assurée par ces flux transactionnels et fait l’objet de flux documentaires distincts s’appuyant sur le Volet de transmission d’un document CDA-R2 en HL7v2.

Evènements déclenchants

La présente partie décrit, pour chaque flux métier inclus dans le périmètre du volet Téléradiologie, le message HL7 v2 et l’événement HL7 v2 associé utilisés pour supporter l’échange.

(1) : Le flux d'annulation est un flux optionnel dans le cadre du volet Téléradiologie. Son implémentation n’est pas obligatoire et peut être omise sans remettre en cause la conformité globale des échanges.

Interactions entre les acteurs

La présente partie décrit les interactions entre les acteurs du volet Téléradiologie, au travers de diagrammes de séquence illustrant les échanges de messages HL7 v2 identifiés précédemment.

Les interactions sont présentées flux par flux. Chaque diagramme s’appuie sur le profil de messages HL7 v2 retenu. Le diagramme de séquence complet est fourni en annexe.

Flux 1 et 2 - Transmission/Annulation d’une demande d’examen d’imagerie

Ce diagramme décrit les échanges techniques entre le RIS de la structure d’imagerie et le SI de téléradiologie pour la transmission et la gestion d’une demande d’examen d’imagerie.

Figure 1 – Diagramme de séquence des flux 1 et 2

La demande d’examen est transmise du RIS vers le SI de téléradiologie au moyen d’un message HL7 v2 ORM^O01^ORM_O01.

Les options techniques suivantes sont représentées :

• lorsque la demande d’examen est disponible sous forme de document structuré, le RIS doit transmettre ce document au SI de téléradiologie en s’appuyant sur les transactions définies au sein du volet de transmission de documents CDA-R2 en HL7 v2 ;
• lorsque plusieurs documents complémentaires sont associés à la demande, ceux-ci peuvent être transmis individuellement au SI de téléradiologie au travers de mécanismes également définis au sein du volet de transmission de documents CDA-R2 en HL7 v2.

Enfin, le diagramme illustre la possibilité d’annulation de la demande d’examen par le RIS, notifiée au SI de téléradiologie au moyen d’un message HL7 v2 ORM^O01^ORM_O01, en cohérence avec les règles de gestion HL7 v2 et le profil IHE SWF.

Flux 3 Réponse à la demande d’examen d’imagerie

Ce diagramme décrit les échanges techniques consécutifs à la consultation et à l’évaluation d’une demande d’examen par le professionnel de santé effecteur au sein du SI de téléradiologie.

Figure 2 – Diagramme de séquence du flux 3

Après réception de la demande d’examen d’imagerie, le professionnel de santé effecteur procède à son évaluation (acceptation ou refus).
Le résultat de cette évaluation est notifié à la structure d’imagerie par l’émission d’un message HL7 v2 ORU^R01^ORU_R01 depuis le SI de téléradiologie.

Les cas suivants sont couverts :

• Acceptation de la demande :
  le message ORU^R01 contient un ou plusieurs protocoles d’imagerie, véhiculés dans les segments OBX ;
  le champ ORC-1 (Order Control) est valorisé à OK.

• Refus de la demande :
  le message ORU^R01 est transmis sans protocole d’imagerie ;
  le champ ORC-1 (Order Control) est valorisé à OC.

Flux 4 Transmission d’un complément d’information post-examen

Ce diagramme décrit les échanges techniques intervenant après l’acceptation de la demande d’examen et la transmission du protocole d’imagerie.

Figure 3 – Diagramme de séquence du flux 4

À l’issue de cette acceptation, l’examen d’imagerie est réalisé au sein de la structure d’imagerie.
Une fois l’examen effectué, le RIS transmet au SI de téléradiologie un ensemble de compléments d’information post-examen, destinés à permettre la rédaction du compte rendu par le professionnel de santé effecteur.

Ces informations sont transmises via un message OMI^O23^OMI_023 conforme au profil IHE SWF.

Après rédaction du compte rendu d’examen d’imagerie, celui-ci est transmis par le SI de téléradiologie vers le RIS, afin de permettre sa publication dans le DMP du patient.

Profils de message

La présente partie décrit les profils de messages HL7 v2 retenus pour supporter les flux d’échange du volet Téléradiologie.
Pour chaque flux identifié, le type de message HL7 v2 associé est précisé, ainsi que la structure générale des segments utilisés afin de couvrir les concepts métiers attendus.

Les profils de message définissent :

• le type de message HL7 v2 et l’événement associé ;
• l’ordre des segments ;
• les segments requis, optionnels ou répétables ;
• le rôle fonctionnel de chaque segment dans le cadre du flux considéré.

Des exemples représentatifs de chacun des profils de message conformes au volet Téléradiologie sont fournis en annexe.

Description des messages HL7 v2

L’implémentation doit valoriser l’intégralité des segments et champs obligatoires applicables aux messages HL7v2 afin de répondre au standard d’interopérabilité afférent.

Ci-dessous sont représentées les structures de messages HL7 v2, présentées selon deux vues complémentaires :

• une vue technique, sous forme de tableaux, décrivant de manière exhaustive la structure des profils de messages (segments, cardinalités et ordonnancement) ;
• une vue fonctionnelle, plus synthétique, matérialisée par des diagrammes, centrée sur les segments utilisés dans le cadre du volet Téléradiologie.

Flux 1 - Message ORM^O01^ORM_O01 en HL7 v2.5.1

Le flux 1 repose sur l’échange d’un message ORM^O01 conforme à la norme HL7 v2.5.1, utilisé pour la transmission d’une demande d’examen d’imagerie dans le cadre du volet Téléradiologie.

La structure du message est conforme au profil IHE RAD – Scheduled Workflow (SWF). Une surcouche de contraintes spécifiques au domaine de la Téléradiologie vient compléter ce cadre afin de couvrir des besoins fonctionnels non pris en charge nativement par IHE SWF.

Description technique

Le message est composé des segments principaux suivants :

• MSH : en-tête du message et informations de routage ;
• PID / PV1 : identification du patient et du contexte de prise en charge ;
• ORC / OBR : informations liées à la demande d’examen, conformément à IHE SWF ;
• Groupes OBSERVATION (OBX) : supporte les informations complémentaires spécifiques au volet Téléradiologie, non contraintes par IHE SWF.

Le tableau ci-dessous décrit la structure HL7 v2 du message, l’ordre des segments ainsi que leur caractère requis, optionnel ou répétable conformément au volet Téléradiologie.

Description fonctionnelle

Le message ORM^O01 du flux 1 permet au système demandeur (RIS) de transmettre au système effecteur (SI Téléradiologie) l’ensemble des informations associées à la prise en charge du patient ainsi que les éléments relatifs à une demande d’examen d’imagerie le concernant.

Outre les éléments standards concernant la demande et la prescription portés par les segments ORC et OBR, ce flux s’appuie sur des groupes OBSERVATION (OBX) afin de véhiculer des informations fonctionnelles complémentaires indispensables à la bonne réalisation de l’examen, telles que :

• la localisation anatomique et, le cas échéant, une précision topographique
• les antécédents médicaux du patient
• des données morphologiques pertinentes pour la planification de l’examen d’imagerie (taille, poids, statut de grossesse)

Ces OBSERVATION sont structurées et identifiées conformément aux règles définies dans la partie Contraintes applicables aux profils de message, notamment via l’utilisation de codes locaux dans OBX-3.

Le diagramme ci-dessous présente la description fonctionnelle du message de transmission de la demande.
Les éléments reliés par des flèches traduisent des dépendances fonctionnelles : un élément cible ne peut être présent que si l’élément source associé est également présent.

Figure 4 : Structure fonctionnelle du message ORM^O01^ORM_O01 du flux 1

Flux 2 - Message ORM^O01^ORM_O01 en HL7 v2.5.1

Le flux 2 repose sur l’échange d’un message ORM^O01 conforme à la norme HL7 v2.5.1, utilisé pour l’ annulation d’une demande d’examen d’imagerie dans le cadre du volet Téléradiologie.

Ce flux est structurellement très proche du flux 1 et s’appuie lui aussi sur le profil IHE RAD – Scheduled Workflow (SWF), notamment pour les segments ORC et OBR, qui conservent les mêmes principes de structuration et de valorisation que pour la demande initiale.

La principale différence structurelle en comparaison avec le flux 1 concerne l’utilisation du groupe OBSERVATION (OBX) qui est optionnel dans le cadre de ce flux.

Description technique

Le message est composé des segments principaux suivants :

• MSH : en-tête du message et informations de routage
• PID / PV1 : identification du patient et du contexte de prise en charge
• ORC / OBR : informations de demande, avec une action positionnée à l’annulation

Le tableau ci-dessous décrit la structure HL7 v2 du message, l’ordre des segments ainsi que leur caractère requis, optionnel ou répétable conformément au volet Téléradiologie.

Description fonctionnelle

Le message ORM^O01 du flux 2 permet au système demandeur de notifier au système effecteur l’annulation d’une demande d’examen d’imagerie précédemment transmise.

Les segments ORC et OBR assurent l’identification de la demande concernée et portent les informations nécessaires à sa mise à jour dans les systèmes récepteurs, conformément aux règles définies par le profil IHE SWF.

Le diagramme ci-dessous présente la description fonctionnelle du message d’annulation :

Figure 5 : Structure fonctionnelle du message ORM^O01^ORM_O01 du flux 2

Flux 3 - Message ORU^R01^ORU_R01 en HL7 v2.5.1

Le flux 3 repose sur l’échange d’un message ORU^R01 conforme à la norme HL7 v2.5.1.
Il est utilisé pour la réponse à une demande d’examen d’imagerie, en particulier pour notifier la décision du médecin effecteur (approbation/refus de la demande).

Contrairement aux flux 1 et 2, ce flux ne s’appuie sur aucun profil IHE existant.
En effet, les cas d’usage couverts par ce flux, notamment la transmission d’une décision médicale en réponse à une demande d’examen d’imagerie, ne disposent pas d’un équivalent direct dans les profils IHE RAD.
Le message ORU^R01 est donc défini sur la base du standard HL7 v2.5.1, complété par une surcouche de contraintes spécifiques au volet Téléradiologie.

Description technique

Le message est structuré autour des segments suivants :

• MSH : en-tête du message et informations de routage
• PID : identification du patient
• ORC / OBR : décision du médecin effecteur sur la demande d’examen (validation ou refus), avec la possibilité de préciser un motif de refus le cas échéant
• Groupes OBSERVATION (OBX) : transmission des informations spécifiques au volet Téléradiologie, notamment le protocole d’imagerie, exprimé soit en clair, soit sous forme de contenu encapsulé.

Le tableau ci-dessous décrit la structure HL7 v2 du message, l’ordre des segments, ainsi que leur caractère requis, optionnel ou répétable conformément au volet Téléradiologie.

Description fonctionnelle

Le message ORU^R01 du flux 3 permet au système effecteur de transmettre au système demandeur la réponse à la demande d’examen d’imagerie.

Le segment ORC porte la décision du médecin effecteur, exprimée de manière :

• validation de la demande d’examen ;
• ou refus de la demande, accompagné le cas échéant d’un motif de refus optionnel.

Le segment OBR rappelle l’identification de la demande d’examen d’imagerie.

Le groupe OBSERVATION (OBX) est conditionné à la valeur du champ ORC-1. Il est optionnel en cas de refus de la demande et obligatoire en cas d’acceptation, afin de permettre la transmission d’un ou plusieurs protocoles d’imagerie selon l’une des modalités suivantes :

• protocole exprimé en clair dans le message
• protocole encapsulé sous forme de contenu binaire

Ces OBSERVATION sont structurées et identifiées conformément aux règles définies dans la partie Contraintes applicables aux profils de message, notamment via l’utilisation de codes locaux dans OBX-3.

Le diagramme ci-dessous illustre la description fonctionnelle du flux 3 :

Figure 3 : Structure fonctionnelle du message ORU^R01^ORU_R01 du flux 3

Flux 4 - Message OMI^O23^OMI_023 en HL7 v2.5.1

Le flux 4 repose sur l’échange d’un message OMI^O23 conforme à la norme HL7 v2.5.1.
Il est utilisé pour la transmission d’informations complémentaires post-acte à la suite de la réalisation d’un examen d’imagerie dans le cadre du volet Téléradiologie.

Le message OMI^O23 permet de transmettre des informations qui ne sont pas nécessairement disponibles au moment de la construction de la demande d’examen, mais qui sont connues après la réalisation effective de l’examen.

Bien que le message OMI^O23 soit décrit dans le profil IHE RAD – Scheduled Workflow (SWF), le cas d’usage couvert par IHE ne répond pas entièrement aux besoins spécifiques du volet Téléradiologie.
En conséquence, le message OMI^O23 est défini sur la base du standard HL7 v2.5.1 et enrichi par une surcouche de contraintes propres au volet Téléradiologie.

Description technique

Le message est structuré autour des segments suivants :

• MSH : en-tête du message et informations de routage
• PID / PV1 : identification du patient et du contexte de prise en charge
• ORC : informations de demande initiale
• OBR : informations relatives à l’examen réalisé
• TQ1 : informations temporelles, notamment la date de réalisation de l’examen et la durée de rétention des images
• IPC : informations relatives à l’examen d’imagerie
• Groupes OBSERVATION (OBX) : transmission des compléments d’information post-acte spécifiques au volet Téléradiologie

Le tableau ci-dessous décrit la structure HL7 v2 du message, l’ordre des segments ainsi que leur caractère requis, optionnel ou répétable conformément au volet Téléradiologie.

Description fonctionnelle

Le message OMI^O23 du flux 4 permet au système demandeur (RIS) de transmettre au système effecteur (SI de Téléradiologie) des compléments d’information post-acte relatifs à un examen d’imagerie déjà réalisé.

Les segments ORC et OBR assurent le rattachement de ces informations à la demande d’examen initiale.

Dans le cadre du flux 4, chaque occurrence du groupe ORDER représente un examen d’imagerie.

Un examen est identifié par son StudyInstanceUID et est associé :

• à un Accession Number
• à une URL de visionneuse permettant d’accéder aux images correspondantes
• à la demande d’examen initiale, identifiée par l’Order Placer Number.

Ainsi, un groupe ORDER correspond à un examen d’imagerie rattaché à une demande d’examen.

Dans le cas où un même flux doit véhiculer des informations associées à plusieurs examens, le système émetteur répète le groupe ORDER autant de fois que nécessaire, chaque occurrence portant les identifiants propres à l’examen correspondant (StudyInstanceUID, Accession Number, URL de visionneuse), tout en conservant l’Order Placer Number permettant de rattacher ces examens à la demande initiale.

Cette structuration permet de conserver l’association explicite entre la demande d’examen, chaque examen réalisé et l’URL permettant d’accéder aux images correspondantes.

Les groupes OBSERVATION (OBX) jouent un rôle central dans ce flux.
Ils permettent notamment de véhiculer :

• des éléments constitutifs de l’URL de la visionneuse DRIMbox donnant accès aux images ;
• le code de l’acte d’imagerie réalisée
• la modalité d’imagerie utilisée lors de l’examen
• les informations relatives aux produits administrés dans le cadre de la procédure (type, numéro de lot, quantité) ;
• les informations sur l’appareil d’imagerie utilisé ;
• la localisation anatomique ciblée par l’examen et les éventuelles précisions topographiques associées.

L’utilisation de ces groupes OBSERVATION est encadrée par des règles de structuration, de codification et de liaison entre segments, définies dans la partie relatives aux contraintes spécifiques du volet.

Le diagramme ci-dessous présente la description fonctionnelle du message OMI^O23^OMI_O23.
Les éléments reliés par des flèches traduisent des dépendances fonctionnelles : un élément cible ne peut être présent que si l’élément source associé est également présent.

Figure 4 : Structure fonctionnelle du message OMI^O23^OMI_023 du flux 4

Acquittements

Pour l’ensemble des flux décrits ci-dessus, les messages HL7 font l’objet d’un acquittement technique HL7 v2 (ACK). Les mécanismes d’acquittement s’appuient sur les fonctionnalités natives du standard HL7 v2.5.1. Les règles applicables à la structure et au contenu des messages d’acquittement sont décrites ultérieurement dans une partie dédiée.

Profil du message ACK

Le profil du message ACK conformément au standard HL7 v2.5.1 est le suivant :

Contraintes applicables aux profils de message

Cette section précise les contraintes d’implémentation applicables aux profils de message identifiés précédemment.
Elle est structurée selon deux niveaux complémentaires.

Contraintes communes à l’ensemble des messages

Un premier sous-ensemble de contraintes s’applique de manière transversale à l’ensemble des messages HL7 v2 échangés, quel que soit le flux concerné.
Ces contraintes portent notamment sur les segments suivants :

• MSH (Message Header) : identification du message, des acteurs émetteur et récepteur, gestion des versions, horodatage, identifiants de message ;
• PID (Patient Identification) : identité du patient, traits d’identification et conformité aux exigences nationales, notamment en lien avec l’INS ;
• PV1 (Patient Visit) : contexte de prise en charge et éléments nécessaires à la qualification du séjour ou de l’acte.

Ces contraintes communes garantissent une cohérence globale des échanges, une identification fiable des acteurs et du patient, ainsi qu’une homogénéité de mise en œuvre entre les flux.

Eléments de l’entête

Les éléments de contrôle du message HL7 sont portés par le segment d’entête MSH. Le tableau ci-dessous liste les champs à renseigner pour le segment MSH :

Exemple d’en-tête MSH d’un message ORM :

MSH|^~\&|RIS|CHU_X|SI-TLR|PLAT-TLR|202310030830||ORM^O01^ORM_O01|12345|P|2.5.1|||||FRA|8859/15|||1.0^CISIS_TLR_HL7_V2

Les données concernant le patient et sa venue

Le message HL7 est centré sur un seul patient. Les informations concernant le patient sont décrites par le segment requis PID. Le segment PV1, requis, représente la venue courante du patient.

Ces deux segments doivent être renseignés conformément à la spécification « PAM – National extension France » version 2.11 publiée en 2024. Le segment PID doit suivre les contraintes décrites dans l’annexe CI-SIS « Prise en charge de l’identifiant National de Santé (INS) dans les standards d’interopérabilité et les volets du CI-SIS ».

Pour le segment PV1, ce volet ajoute les contraintes suivantes :

(2) : Dans le cadre du volet Téléradiologie, le champ PV1-19 Visit Number est utilisé pour véhiculer l’identifiant du rendez-vous issu des flux SIU.

Contraintes spécifiques au volet Téléradiologie

Un second niveau de contraintes est défini spécifiquement pour chaque flux, en fonction du type de message et du rôle fonctionnel attendu.
Ces contraintes portent notamment sur les segments métiers suivants, selon les flux :

• ORC / OBR (Order) : gestion de la demande, de son cycle de vie et de ses états ;
• OBX (Observation Result) : transmission d’informations cliniques structurées ou de références documentaires ;
• IPC (Imaging Procedure Control) : partage du contexte de réalisation des études et procédures d’imagerie.

Pour chaque flux, les contraintes précisent :

• les segments obligatoires et optionnels ;
• les champs requis, conditionnels ou interdits ;
• les règles de cardinalité, de codage et de valeurs attendues ;
• les éventuelles références aux profils IHE ou spécifications nationales applicables.

Flux 1 - Transmission de la demande d’examen d’imagerie

Ce flux repose sur l’utilisation d’un messages ORM^O01, conformes au standard HL7 v2.5.1.

Les segments sont renseignés conformément au profil IHE Scheduled Workflow (SWF), lorsqu’il est applicable, et font l’objet d’une surcouche de contraintes spécifiques à la téléradiologie afin de répondre aux besoins métier du contexte de téléradiologie.

Les groupes OBSERVATION (segments OBX), non contraints et optionnels dans le cadre du profil IHE SWF, sont explicitement contraints par le volet téléradiologie. Ces contraintes permettent notamment de structurer et de normaliser la transmission d’informations complémentaires nécessaires à la compréhension de la demande d’examen d’imagerie.

Les parties suivantes détaillent les contraintes appliquées aux segments du message ORM^O01 dans le cadre de ce flux.

Segment ORC (Common Order)

Le segment ORC est renseigné conformément au profil IHE Scheduled Workflow (SWF) et fait l’objet d’une surcouche de contraintes spécifiques à la téléradiologie.

Le tableau ci-après décrit l’ensemble des champs requis du segment ORC, ainsi que certains champs requis si connus, dont l’usage est jugé pertinent au regard du workflow de téléradiologie.

(3) : Le champ ORC-12, de type XCN (Extended Composite ID Number and Name for Persons), ne permet pas de véhiculer explicitement le code profession du professionnel de santé. Or, cette information est requise dans le cadre de la rédaction du compte rendu d’imagerie. En conséquence, il est considéré que le code profession du professionnel de santé est déduit par la plateforme de téléradiologie au moyen d’une interrogation de l’annuaire de référence, à partir de l’identifiant national du professionnel de santé (PS_IdNat) transmis dans ORC-12. Cette approche garantit la cohérence avec les référentiels nationaux tout en respectant les contraintes du type de données HL7 v2 utilisé. Par ailleurs, les informations relatives au professionnel de santé demandeur étant véhiculées dans le cadre du flux 1, il est considéré que la plateforme de téléradiologie enregistre ces informations lors de la réception de ce flux afin de les réutiliser lors de la rédaction du compte rendu d’imagerie, suite à la réception du flux 4.

(4) : Conformément au profil IHE RAD – Scheduled Workflow (SWF), le champ ORC-17 – Entering Organization est renseigné dans les flux concernés. Dans le cadre du volet Téléradiologie, ce champ est utilisé pour qualifier le type d’organisation à l’origine du message (par exemple : structure d’imagerie, plateforme de téléradiologie), sur la base d’une table de valeurs locale documentée. L’identification de l’organisation est portée dans le champ ORC-21 – Ordering Facility Name, de type XON, permettant de véhiculer un identifiant structuré et pérenne, conformément aux principes retenus dans le CI-SIS. Ce découplage permet de respecter les exigences IHE tout en garantissant une identification robuste.

Segment OBR (Observation Request)

Le segment OBR est renseigné conformément au profil IHE Scheduled Workflow (SWF) et fait l’objet d’une surcouche de contraintes spécifiques à la téléradiologie.

Dans le cadre du volet Téléradiologie, le champ OBR-4 – Universal Service Identifier est utilisé afin de véhiculer un code local identifiant la procédure métier portée par le message. Les valeurs autorisées dans OBR-4 sont définies dans une table de codes locaux, commune à l’ensemble des flux du volet Téléradiologie.

Segment NTE - Finalité de l’examen

Le segment NTE peut être utilisé en complément du segment OBR afin de véhiculer un ou des commentaires libres relatifs à la finalité de l’examen.

La structure et l’utilisation du segment NTE sont conformes au standard HL7 v2.5.1. Des contraintes spécifiques s’applique toutefois lorsque ce segment est utilisé pour porter des informations relatives à la finalité de l’examen telles que définies dans le présent volet.

Groupe OBSERVATION - Modalité d’imagerie

Ce groupe obligatoire est composé d’un segment OBX permettant d’indiquer la modalité d’imagerie souhaitée pour l’examen demandé.

Le segment NTE peut être utilisé en complément du segment OBX afin de véhiculer un ou des commentaires libres relatifs à la modalité d’imagerie demandée.

Segment OBX - Modalité d’imagerie

Segment NTE - Commentaire sur la modalité

La structure et l’utilisation du segment NTE sont conformes au standard HL7 v2.5.1. Des contraintes spécifiques s’applique toutefois lorsque ce segment est utilisé pour porter des informations relatives à la modalité d’imagerie, telles que définies dans le présent volet.

Groupes OBSERVATION - Localisation anatomique

Ces groupes OBSERVATION sont utilisés afin de véhiculer les informations relatives à la localisation anatomique concernée par la demande d’examen d’imagerie. Ces informations permettent de préciser la zone anatomique à explorer et, le cas échéant, d’apporter un niveau de détail complémentaire facilitant l’interprétation et la réalisation de l’examen.

La localisation anatomique est portée par un premier segment OBX obligatoire, pouvant être complété par un second segment OBX optionnel destiné à préciser la topographie de manière plus fine. Les segments OBX portant sur la localisation anatomique sont identifiés par un code local “REGION_ANATOMIQUE” dans OBX-3, documenté en annexe. Ces segments sont différenciés à l’aide du champ OBX-4 – Observation Sub-ID.

Groupe OBSERVATION - Localisation anatomique principale

Ce groupe est composé d’un segment OBX obligatoire permettant d’indiquer la localisation anatomique principale de l’examen demandé.

Groupe OBSERVATION - Précision topographique

Ce groupe est composé d’un segment OBX optionnel permettant de compléter la localisation anatomique principale par une précision topographique.

Groupe OBSERVATION - Antécédents

Ce groupe OBSERVATION optionnel et répétable permet de véhiculer les antécédents médicaux du patient jugés pertinents pour la réalisation de l’examen d’imagerie.

Les antécédents sont transmis sous forme de texte libre dans le champ OBX-5. Le champ OBX-8, optionnel, est utilisé comme indicateur de pertinence, permettant de qualifier le niveau d’impact des antécédents transmis vis-à-vis de l’examen d’imagerie demandé.

Groupe OBSERVATION - Taille corporelle

Ce groupe OBSERVATION optionnel est utilisé afin de véhiculer la taille corporelle du patient, lorsque celle-ci est nécessaire à la réalisation de l’examen d’imagerie. La taille du patient est véhiculée par l’intermédiaire d’un segment OBX.

Groupe OBSERVATION - Poids corporel

Ce groupe OBSERVATION optionnel est utilisé afin de véhiculer le poids corporel du patient, lorsque cette donnée est nécessaire pour la réalisation de l’examen d’imagerie. Le poids du patient est véhiculé par l’intermédiaire d’un segment OBX.

Groupe OBSERVATION - Statut grossesse

Ce groupe OBSERVATION optionnel est utilisé afin de véhiculer le statut de grossesse de la personne prise en charge, lorsque cette information est pertinente pour la réalisation de l’examen d’imagerie.

Flux 2 - Annulation de la demande d’examen d’imagerie

Ce flux repose sur l’utilisation d’un message ORM^O01, conforme au standard HL7 v2.5.1.

Les segments sont renseignés conformément au profil IHE Scheduled Workflow (SWF), lorsqu’il est applicable, et font l’objet d’une surcouche de contraintes spécifiques à la téléradiologie afin de répondre aux besoins métier du contexte de téléradiologie.

Les parties suivantes détaillent les contraintes appliquées aux segments du message ORM^O01 dans le cadre de ce flux.

Segment ORC (Common Order)

Le segment ORC est utilisé pour véhiculer l’annulation d’une demande d’examen d’imagerie, conformément au profil IHE Scheduled Workflow (SWF) .

La structure du segment ORC est identique à celle du flux 1, à l’exception du champ ORC-1 – Order Control, dont la valeur est fixée à CA (Cancel Order).
Un motif d’annulation peut être véhiculé lorsque cette information est disponible, son renseignement est optionnel.

Le tableau ci-après décrit l’ensemble des champs requis du segment ORC, ainsi que certains champs requis si connus ou optionnels, dont l’usage est jugé pertinent au regard du workflow de téléradiologie.

Segment OBR (Observation Request)

Le segment OBR est utilisé pour véhiculer des informations relatives à la demande d’examen d’imagerie.
Il est renseigné conformément au profil IHE Scheduled Workflow (SWF) et fait l’objet d’une surcouche de contraintes spécifiques à la téléradiologie.

Dans le cadre du volet Téléradiologie, le champ OBR-4 – Universal Service Identifier est utilisé afin de véhiculer un code local identifiant la procédure métier portée par le message. Les valeurs autorisées dans OBR-4 sont définies dans une table de codes locaux, commune à l’ensemble des flux du volet Téléradiologie.

Flux 3 - Réponse à la demande d’examen d’imagerie

Ce flux repose sur l’utilisation de messages ORU^R01, conformes au standard HL7 v2.5.1.

Les segments ci-dessous sont définis sur la base du standard HL7 v2.5.1, complété par une surcouche de contraintes spécifiques à la téléradiologie, décrite dans les sections suivantes.

Segment ORC (Common Order)

Le segment ORC est utilisé pour véhiculer la décision du médecin effecteur vis-à-vis de la demande d’examen d’imagerie.

Le champ ORC-1 – Order Control permet d’indiquer la décision prise sur la demande, à savoir sa validation ou son refus. En cas de refus, un motif de refus peut être transmis lorsque cette information est disponible ; son renseignement est optionnel.

Le tableau ci-après décrit l’ensemble des champs requis du segment ORC, ainsi que certains champs requis si connus ou optionnels, dont l’usage est jugé pertinent au regard du workflow de téléradiologie.

Segment OBR (Observation Request)

Le segment OBR est renseigné conformément au profil IHE Scheduled Workflow (SWF) et fait l’objet d’une surcouche de contraintes spécifiques à la téléradiologie.

Dans le cadre du volet Téléradiologie, le champ OBR-4 – Universal Service Identifier est utilisé afin de véhiculer un code local identifiant la procédure métier portée par le message. Les valeurs autorisées dans OBR-4 sont définies dans une table de codes locaux, commune à l’ensemble des flux du volet Téléradiologie.

Groupe OBSERVATION - Protocole d’imagerie

Le groupe OBSERVATION est requis dans le cadre d’une demande d’examen d’imagerie acceptée (ORC-1 = OK) afin de véhiculer le protocole d’imagerie associé à l’examen. Ce groupe est répétable afin de permettre, le cas échéant, la transmission de plusieurs protocoles d’imagerie distincts.
Le protocole d’imagerie est porté par un segment OBX unique au sein du groupe OBSERVATION. Deux alternatives d’encodage sont proposées, en fonction du niveau de structuration et du contenu du protocole à transmettre :

• Protocole en clair : transmission du protocole sous forme de texte lisible directement dans le message HL7, à l’aide du type de données FT (Formatted Text).
• Protocole encapsulé : transmission du protocole sous forme de document encapsulé (par exemple PDF, XML ou texte structuré), encodé en base64 et véhiculé à l’aide du type de données ED (Encapsulated Data).

Ces deux alternatives sont exclusives : un seul segment OBX est utilisé pour porter le protocole d’imagerie, avec le type de données adapté au mode de transmission retenu. Le choix de l’alternative relève des capacités des systèmes émetteurs et récepteurs et doit être cohérent avec les besoins métier du flux. Le segment OBX portant sur le protocole est identifié par un code local “PROTOCOLE_IMAGERIE” dans OBX-3, documenté en annexe.

Protocole d’imagerie en clair

Cette alternative permet de transmettre le protocole d’imagerie en clair, sous forme de texte formaté directement exploitable par un utilisateur.
Le contenu peut inclure des retours à la ligne et une structuration légère facilitant la lecture humaine.

Protocole d’imagerie encapsulé

Cette alternative permet de transmettre le protocole d’imagerie sous forme encapsulée, en utilisant le type de données ED.
Le protocole est encodé en base64 et peut correspondre à un document structuré (PDF, XML, ou autre format convenu entre les acteurs).

Flux 4 - Transmission d’un complément d’information post-acte

Ce flux repose sur l’utilisation d’un messages OMI^O23, conformes au standard HL7 v2.5.1.

Les segments présentés dans cette partie font l’objet d’une surcouche de contraintes spécifiques à la téléradiologie afin de répondre aux besoins métier du contexte de téléradiologie.

Les sections suivantes décrivent les contraintes appliquées aux segments du message OMI^O23 dans le cadre de ce flux.

Segment ORC (Common Order)

Le segment ORC est renseigné conformément au standard HL7v2.5.1 et fait l’objet d’une surcouche de contraintes spécifiques à la téléradiologie.

Segment TQ1 (Timing/Quantity)

Le segment TQ1 – Timing/Quantity est utilisé pour véhiculer les informations temporelles relatives à l’examen d’imagerie réalisé.
Il est renseigné conformément au standard HL7v2.5.1 et fait l’objet d’une surcouche de contraintes spécifiques à la téléradiologie.

Segment OBR (Observation Request)

Le segment OBR – Observation Request est renseigné conformément au standard HL7v2.5.1 et fait l’objet d’une surcouche de contraintes spécifiques à la téléradiologie.

Dans le cadre du volet Téléradiologie, le champ OBR-4 – Universal Service Identifier est utilisé afin de véhiculer un code local identifiant la procédure métier portée par le message. Les valeurs autorisées dans OBR-4 sont définies dans une table de codes locaux, commune à l’ensemble des flux du volet Téléradiologie.

Segment IPC (Imaging Procedure Control)

Le segment IPC – Imaging Procedure Control est utilisé dans le cadre du flux 4 pour véhiculer les informations spécifiques à la procédure d’imagerie réalisée.
Il est renseigné conformément à HL7v2.5.1 et fait l’objet d’une surcouche de contraintes spécifiques à la téléradiologie.

(5) : Bien que le type de donnée du champ IPC-3 soit EI (Entity Identifier) et que la spécification d'Interop'santé concernant les types de données utilisables en France prévoit le renseignement des couples EI.1 + EI.2 ou EI.1 + EI.3 + EI.4, cette contrainte ne s’applique pas dans le cas du Study Instance UID. En effet, le Study Instance UID est un identifiant globalement unique et n’est pas associé à une autorité d’affectation distincte. À ce titre, seul le composant EI.1 (Entity Identifier) est requis pour véhiculer cet identifiant. Cette approche est conforme aux principes décrits dans le volet Partage de documents de santé section 3.4.56.5.

Groupe OBSERVATION - URL de viewer DRIMbox

Ce groupe OBSERVATION est utilisé afin de véhiculer l’URL d’accès à la vieweuse DRIMbox, permettant la consultation à distance des images issues de l’examen d’imagerie. Il est important de noter que la valeur associée correspond à une adresse partielle à compléter afin de permettre l’accès à la visionneuse DICOM implémentée par une solution DRIMBox associée au système RIS. En effet, il est nécessaire de compléter cette donnée avec l’identifiant du compte-rendu d’imagerie afin d’obtenir un lien d’accès fonctionnel. Une fois l’URL assemblée, celle-ci doit être mentionnée au sein du compte-rendu d’imagerie. Ce concept permet l’intégration au maillage DRIM-M du compte-rendu d’imagerie rédigé suite à la réalisation de l’acte d’imagerie.

L’URL de la vieweuse est portée par un segment OBX unique au sein du groupe OBSERVATION. Elle est transmise sous forme de texte encodé en base 64 afin d’éviter toute contrainte liée à la présence de caractères spéciaux. La valeur portée dans OBX-5 correspond à l’encodage en base 64 d’une URL partielle, incluant les éléments suivants : FQDN du point d’accès, service cible, paramètres StudyInstanceUID et AccessionNumber. Pour plus de précisions concernant le formalisme à appliquer dans le cadre de la construction de cette URL, se référer à la section 4.2.2 de la spécification projet DRIMBox visionneuse.
Le segment OBX portant sur l’adresse d’accès à la visionneuse est identifié par un code local “URL_PARTIELLE_VIEWER” dans OBX-3, documenté en annexe.

Groupe OBSERVATION - Acte d’imagerie

Ce groupe obligatoire est composé d’un segment OBX permettant d’indiquer le code de l’acte d’imagerie réalisée.

Groupes OBSERVATION - Localisation anatomique

Les groupes OBSERVATION – Localisation anatomique sont optionnel dans le cadre du flux 4.
Leur présence permet de transmettre les informations relatives à la localisation anatomique concernée par l’examen réalisé, ainsi que, le cas échéant, une précision topographique associée. La structure, le contenu et les contraintes applicables à ces groupes OBSERVATION sont strictement identiques à ceux définis pour le flux 1 à l’exception du champ OBX-11 prenant la valeur “F” dans le cadre de ce flux. Pour le détail des segments OBX, se référer à la section dédiée du flux 1 : Groupes OBSERVATION – Localisation anatomique

Groupe OBSERVATION - Modalité d’imagerie

Le groupe OBSERVATION - Modalité d’imagerie est optionnel dans le cadre du flux 4. Sa présence permet de transmettre la modalité d’imagerie utilisée lors de l’examen. La structure, le contenu et les contraintes applicables à ce groupe OBSERVATION sont strictement identiques à ceux définis pour le flux 1 à l’exception du champ OBX-11 prenant la valeur “F” dans le cadre de ce flux.
Pour le détail du segment OBX, se référer à la section dédiée du flux 1 : Groupes OBSERVATION – Modalité d’imagerie

Groupes OBSERVATION - Produit administré

Les groupes OBSERVATION – Produit administré sont optionnels et permettent de transmettre les informations relatives aux produits administrés lors d’un examen d’imagerie.

Chaque ensemble d’informations associées à un produit donné est portée dans un groupe OBSERVATION et un segment OBX distincts.
Les groupes sont répétables pour permettre la transmission d’informations associées à plusieurs produits administrés au cours du même examen.
Pour assurer la cohérence des informations :

• le type de produit et le numéro de lot sont indissociables,
• la quantité administrée est facultative mais recommandée lorsque le produit est renseigné.

Les segments OBX portant sur le produit administré sont identifiés par un code local “PRODUIT_ADMINISTRE” dans OBX-3, documenté en annexe. Ces segments sont différenciés à l’aide du champ OBX-4 – Observation Sub-ID.

Groupe OBSERVATION – Type de produit

Ce groupe OBSERVATION permet de transmettre le type de produit administré. La valeur est codée à partir du Jeu de Valeurs ATC niveau 2, limité aux classes :

• V09 – Produits de diagnostic
• V10 – Produits thérapeutiques

Un segment OBX unique au sein de ce groupe porte la valeur codée dans OBX-5.
Ce groupe est obligatoirement associé au groupe Numéro de lot.

Groupe OBSERVATION – Numéro de lot

Ce groupe OBSERVATION permet de transmettre le numéro de lot du produit administré, garantissant la traçabilité et l’identification précise du produit.
Le segment OBX unique au sein de ce groupe porte le numéro de lot dans OBX-5.
Ce groupe doit être présent si le groupe Type de produit est renseigné.

Groupe OBSERVATION – Quantité de produit administré

Ce groupe OBSERVATION permet de transmettre la quantité réellement administrée du produit. Le segment OBX unique au sein de ce groupe porte la valeur dans OBX-5 et l’unité de mesure dans OBX-6 (par exemple millilitres ou milligrammes).
La quantité est optionnelle mais fortement recommandée lorsque le produit est renseigné.

Groups OBSERVATION - Appareil d’imagerie utilisé

Les groupes OBSERVATION – Appareil d’imagerie utilisé sont optionnels. Lorsqu’ils sont présents, ils permettent de transmettre les informations relatives à l’appareil d’imagerie ayant été utilisé pour la réalisation de l’examen, en particulier dans le cas des techniques irradiantes. Les informations relatives à l’appareil sont portées dans deux groupes OBSERVATION distincts :

• un groupe dédié à l’identifiant unique de l’appareil d’imagerie,
• un groupe dédié au modèle de l’appareil d’imagerie.

Ces groupes peuvent être utilisés conjointement ou indépendamment, selon le niveau d’information disponible, l’identifiant de l’appareil constituant l’information principale de référence. Les segments OBX portant sur l’appareil d’imagerie sont identifiés par un code local “APPAREIL_IMAGERIE” dans OBX-3, documenté en annexe. Ces segments sont différenciés à l’aide du champ OBX-4 – Observation Sub-ID.

Groupe OBSERVATION – Identifiant de l’appareil d’imagerie

Ce groupe OBSERVATION permet de transmettre l’identifiant unique de l’appareil d’imagerie utilisé lors de l’examen. L’identifiant correspond au Support IUD, tel que communiqué via un dispositif d’identification automatique (AIDC) ou, le cas échéant, via son marquage en clair. Le groupe contient un segment OBX unique portant la valeur de l’identifiant dans OBX-5.

Groupe OBSERVATION – Modèle de l’appareil d’imagerie

Ce groupe OBSERVATION permet de transmettre le modèle de l’appareil d’imagerie utilisé. La valeur est exprimée sous forme de texte libre et correspond à la dénomination du modèle fournie par le constructeur. Le groupe contient un segment OBX unique portant le modèle de l’appareil dans OBX-5.
Ce groupe est optionnel et vient compléter l’identifiant de l’appareil lorsqu’une information plus détaillée sur l’équipement est requise.

Description des contraintes à appliquer sur l’acquittement

Segment MSH (Header)

Le segment MSH reprend une partie des informations du message initial :

Le tableau ci-après décrit l’ensemble des champs requis du segment MSH :

Segment MSA (Message Acknowledgment)

Segment ERR (Error)

Ce segment est utilisé au niveau des messages d’acquittement dans le cas où le champ MSA-1 prend la valeur AE (Application error) ou AR (Application reject).

Le tableau ci-dessous liste les champs à renseigner pour le segment ERR :

Exemples

Entête MSH d’un message ORM^O01 dans le cadre du flux 1 :

MSH|^~\&|StructureApp|StructureFacility|TLRapp|TLRfacility|20260106134418||ORM^O01^ORM_O01|12345|P|2.5.1|||||FRA|UNICODE UTF-8|||1.0^CISIS_TLR_HL7_V2

Un acquittement positif retourné par le SI de téléradiologie :

MSH|^~\&|TLRapp|TLRfacility|StructureApp|StructureFacility|20260106134419||ACK^R01^ACK|12346|P|2.5.1|||||FRA|8859/15
MSA|AA|12345

Un acquittement négatif retourné par le SI de téléradiologie : version d’HL7 inconnue

MSH|^~\&|TLRapp|TLRfacility|StructureApp|StructureFacility|20260106134419||ACK^R01^ACK|12347|P|2.5.1|||||FRA|8859/15
MSA|AE|12345
ERR||MSH^1^12|203^ Unsupported version^messageErrorCondition|E