Volet de transmission d'un document CDA-R2 en HL7v2 - Local Development build (v2.1.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Volume 2 : Détail des transactions

Introduction

Cette section décrit les détails techniques nécessaires pour la mise en œuvre de la transaction

• Flux 1 : Demande de transmission/remplacement/suppression de document(s) CDA (Flux HL7-ORU)
• Flux 2 : Demande de transmission/remplacement/suppression d’un document CDA (Flux HL7-MDM)
• Des flux d’accusés métier identifiés dans le tableau des Acteurs/Transactions.

Périmetre de la transaction

Cette transaction véhicule en intra hospitalier les demandes de transmission initiale, de remplacement ou de suppression de(s) document(s) du patient au niveau d’un système cible (le DMP et/ou le(s) destinataire(s) MSSanté indiqués dans la transaction).

La spécification de cette transaction s’applique à toute demande de transmission initiale/de remplacement/de suppression de document(s) clinique(s) d’un patient, au moyen d’un message HL7, entre un acteur CREATEUR de documents vers un acteur GESTIONNAIRE de documents. Le message transmis contient une demande de traitement sur le(s) document(s) au format CDA-R2 encodé(s) dans un flux HL7v2 ORU ou MDM avec description uniquement des segments nécessaires au GESTIONNAIRE de documents pour alimenter le DMP et/ou envoyer le(s) document(s) via MSSanté au(x) destinataire(s) désigné(s) dans le message HL7 par le CREATEUR de document(s).

Les autres données nécessaires aux transactions XDS ou à la création de l’archive IHE-XDM ne rentrent pas dans le périmètre de cette spécification, elles sont récupérées de l’en-tête CDA (ANS – CI-SIS : ANNEXE – LIEN ENTRE L’EN-TETE CDA ET LES METADONNEES XDS).

La spécification technique de cette transaction couvre également l’envoi de l’accusé du message HL7, l’envoi de l’accusé de réception du DMP et MSSanté ainsi que l’accusé de lecture du courriel MSSanté du GESTIONNAIRE vers le CREATEUR.

Rôle des acteurs pour cette transaction

Choix des standards

• HL7 v2.5 Chapitre 7, message ORU (Unsolicited transmission of an observation message), HL7 v2.6 Chapitre 9, message MDM (Medical Document Management) (1)

• Le présent document spécifie également une nouvelle structure de message HL7, le message ZAM spécifique à ce volet, basé sur HL7v2.6 et utilisé pour implémenter les accusés métier (accusé de réception DMP, accusé de réception MSSanté et accusé de lecture MSSanté),

• Extension française du profil IHE PAM : PAM.fr, version 2.11 (1),

• Les types de données utilisés (2) doivent se conformer aux spécifications « INTEROP’SANTE : ITI - Contraintes sur les types de données HL7 v2.5 applicables aux profils d’intégration du cadre technique IT Infrastructure dans le périmètre d’IHE France - Release 1.8 – Final Text – 31 janvier 2024 »

• Le choix du protocole de transport est libre. L’utilisation du protocole MLLP est à privilégier pour gérer au mieux les accusés de réception techniques (ACK).

• Dans le cadre de cette spécification, les documents médicaux véhiculés correspondent à des documents au format CDA-R2 conformes au volet du CI-SIS « Structuration minimale des documents de santé ».

• Les documents transmis par le message HL7 doivent être validés par le professionnel de santé dans l’application métier qui les a générés via un statut de validation géré en interne.

• Dans le cas d’une publication de(s) document(s) sur le DMP, l’INS du patient doit être qualifié en suivant les spécifications de l’annexe INS CI-SIS et les règles du corpus documentaire INS.

(1) : Les messages décrits au niveau de cette transaction implémentent la version 2.5 (message ORU) ou la version 2.6 (message MDM) du standard HL7 mais pré adoptent le segment PRT de la version 2.9, permettant de spécifier l'expéditeur et le(s) destinataire(s) d'un courriel. Le message ORU permet de transmettre, si nécessaire, deux formats de document (CDAr2 Niv1 et CDAr2 Niv3). Le message MDM permet de transmettre un seul document.

(2) : Pour l'ensemble des champs de type CE en HL7v2.5 et CWE en HL7v2.6, la contrainte imposée en version 2.7 sur le type de donnée CE/CWE est pré adoptée. En conséquence, ces spécifications imposent de préciser le système de codage (CE/CWE.3) lorsque le code (CE/CWE.1) est renseigné. Les bonnes pratiques consistent à renseigner systématiquement les 3 composantes : le code, le libellé du code et le libellé de la nomenclature.

Evènements déclenchants

Les cas d’usages liés à une demande de transmission initiale/remplacement/suppression de document(s) clinique(s) d’un patient sont gérés différemment entre l’ORU et le MDM :

Interactions entre les Acteurs

Les échanges sont représentés de bout en bout pour permettre au lecteur d’avoir une vision de l’ensemble des échanges, y compris du côté du destinataire. Cependant, le périmètre du présent volet est limité aux transactions représentées en bleu sur les figures suivantes.

Implémentation du message ORU et de ses acquittements métier HL7

Les interactions de la transaction de transmission/remplacement/suppression de document(s) utilisent le message HL7 ORU^R01^ORU_R01 en version 2.5 ainsi que ses acquittements métiers HL7 ZAM^Z01^ZAM_Z01 (accusé métier de réception DMP), ZAM^Z02^ZAM_Z01 (accusé métier de réception MSSanté) et ZAM_Z03^ZAM_Z01 (accusé métier de lecture MSSanté).

L’action à réaliser sur le document porté par la transaction est indiquée par la valeur renseignée au niveau du champ OBX-11 du segment OBX portant le document (cf section dédiée), qui prend la valeur F (pour demande d’intégration du document), C (pour demande de remplacement de document) et D (pour demande de suppression de document), et sur la valeur du champ ORC-1 (cf section dédiée).

Pour des questions de lisibilité, la figure 13 représente sur le même schéma la possibilité pour l’acteur CREATEUR d’envoyer une demande d’intégration, de remplacement ou de suppression de document(s) au moyen d’un message HL7 ORU.

Implémentation du message MDM et de ses acquittements métier HL7

Les interactions de la transaction de transmission/remplacement/suppression de document(s) utilisent respectivement les messages HL7 MDM^T02^MDM_T02, MDM^T10^MDM_T02 et MDM^T04^MDM_T02 en version 2.6 ainsi que ses acquittements métiers HL7 ZAM^Z01^ZAM_Z01 (accusé métier de réception DMP), ZAM^Z02^ZAM_Z01 (accusé métier de réception MSSanté) et ZAM_Z03^ZAM_Z01 (accusé métier de lecture MSSanté).

L’action à réaliser sur le document porté par la transaction est indiquée par la nature de l’événement (T02, T10 et T04).

Demande de transmission initiale d’un document

Demande de remplacement d’un document

Demande de suppression d’un document

Profils de messages

Description des messages ORU et MDM

La description des messages ORU et MDM est basée sur le contenu du document et les métadonnées complémentaires à véhiculer dans le cadre du partage et de l’échange.

Les données utiles pour publication sur le DMP et pour l’envoi par MSSanté de(s) document(s) sont stockées à la fois dans le segment PID du message HL7, dans le document CDA-R2 conforme au volet du CI_SIS Structuration minimale des documents de santé et dans des segments OBX du message HL7 spécifiant les métadonnées complémentaires.

Le développeur doit valoriser tous les segments et champs obligatoires des messages HL7v2 afin de répondre au standard d’interopérabilité des messages.

Ci-dessous sont représentées les structures de messages HL7v2 proposées pour la transmission de document(s) CDA-R2 en HL7v2.

Message ORU^R01^ORU_R01 en HL7v2.5

Profil du message ORU_R01

Le profil du message ORU_R01 est le suivant :

Note (1) : le segment PRT est utilisé uniquement avec l’OBX qui porte la demande de traitement sur le document. Dans ce cas il est requis et conditionnel (sa valeur dépend de la demande exprimée : envoi de la demande de traitement sur le DMP et/ou envoi vers un ou des destinataire(s) via MSSanté).

Le message ORU peut transmettre une ou deux instances de documents CDA-R2. Le CREATEUR peut ainsi transmettre un document au format CDA-R2 niveau 1 et un deuxième document de contenu clinique identique au format CDA-R2 niveau 3. Chaque document possède son propre identifiant (fonctionnalité non applicable au SEGUR vague 2).

Dans le cadre de ce volet, spécifique à un échange entre un système (CREATEUR) et une PFI (GESTIONNAIRE), l’occurrence ORDER_OBSERVATION est utilisée pour transmettre une demande de traitement sur le(s) document(s) : transmission initiale/remplacement/suppression de document(s). Seuls les segments ORC, OBR et le groupe de segments OBSERVATION de l’occurrence ORDER_OBSERVATION sont à renseigner.

Les contraintes apportées par ce volet sur les données des différents segments du message ORU sont décrites à la section dédiée.

Description fonctionnelle du message ORU

Les groupes en rouge sur le schéma représentent les éléments spécifiques à ce volet :

• Un premier groupe de segments OBSERVATION contenant le document médical au format CDA-R2 codé en base64 suivi de segments PRT, pré-adoptés depuis la version 2.9 du standard, permettant ainsi de renseigner le cas échéant les informations de l’expéditeur, le(s) destinataire(s) MSSanté et l’adresse mail de réponse.

• Un deuxième groupe OBSERVATION contenant le cas échéant le même document médical spécifié dans un autre format, codé en base64. Le contenu clinique des documents est identique, seul le format est différent. Cette possibilité n’est pas utilisée dans le contexte du SEGUR vague2 (la version PDF du compte-rendu est insérée dans une section dédiée du document CDA Niv3).

Les groupes de segments OBSERVATION suivants (répétables) véhiculent les métadonnées spécifiques à la publication sur le DMP et/ou à l’envoi par la MSSanté. Ces métadonnées sont communes aux deux formats du document. Ces métadonnées sont décrites dans la section dédiée.

Message MDM en HL7v2.6

Profil du message MDM

Le profil du message MDM est le suivant :

Note (1) : le segment PRT est utilisé conjointement avec l’OBX qui porte la demande de traitement sur le document. Dans ce cas il est requis et conditionnel (sa valeur dépend de la demande exprimée : envoi de la demande de traitement sur le DMP et/ou envoi vers un ou des destinataire(s) via MSSanté).

Le message MDM ne peut transmettre qu’un seul document médical au format CDAr2.

Les contraintes apportées par ce volet sur les données du message MDM sont décrites à la section dédiée.

Description fonctionnelle du message MDM

Les groupes de segments en rouge sur le schéma représentent les éléments spécifiques à ce volet :

• Un groupe OBXNTE, requis, contenant le document médical au format CDA-R2 codé en base64 suivi de segments PRT, pré-adoptés depuis la version 2.9 du standard, permettant ainsi de renseigner si nécessaire les informations de l’expéditeur, le(s) destinataire(s) MSSanté et l’adresse mail de réponse.

• Les groupes OBXNTE suivants (répétables) véhiculent les métadonnées spécifiques à la publication sur le DMP et à l’envoi par la MSSanté.

Dans le message MDM, le document est accompagné de quelques métadonnées à renseigner au niveau du segment TXA. Il s’agit à minima du type de document (TXA-2), de la présentation du contenu du document (TXA-3), de l’identifiant unique du document (TXA-12), de l’identifiant unique du document remplacé (TXA-13) lorsque l’évènement est à T10 et du statut indiquant la complétude du document (TXA-17).

Contraintes appliquées aux messages MDM et ORU dans le contexte de ce volet

Dans la suite de cette section, les valeurs indiquées en bleu dans les tableaux indiquent les valeurs fixes à insérer dans le champ du message.

Eléments de contrôle du message ORU ou MDM

Le segment MSH – Header du message

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 :

Exemples

Entête MSH d’un message MDM ou ORU émis par le CREATEUR :

MSH|^~\&|SIL|CHU_X|PFI|CHU_X|202310030830||ORU^R01^ORU_R01|12345|P|2.5|||||FRA|8859/15|||2.1^ CISIS_CDA_HL7_V2

Les données concernant le patient et la venue du patient

Le message HL7 (ORU ou MDM) 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. Si l’INS est véhiculé, 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 PID, ce volet ajoute une contrainte particulière sur le PID-18 par rapport à PAM.FR. Il doit être renseigné si connu afin de pouvoir calculer des indicateurs, dans le contexte de l’alimentation du DMP.

Le PID-3 doit être identique aux identifiants de patient portés par le document CDA (recordTarget/patientRole/id).

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

Note 1 : A noter que ces champs sont à renseigner, s’ils sont connus, par l’acteur CREATEUR afin de pouvoir calculer des indicateurs.

Note 2 : Le champ PV1-19 est requis lorsque le PV1-2 prend la valeur E, I, O ou R. Si PV1-2 prend la valeur N alors PV1-19 est requis si connu.

Les métadonnées du document [Uniquement pour le message MDM]

Le message MDM requiert l’utilisation du segment TXA qui porte les métadonnées associées au document contenu dans le message. Les contraintes apportées par ce volet sur le segment TXA sont les suivantes :

(Note 1) : conformément au volet de Structuration minimale des documents de santé, l’identifiant du document au sein du document CDA s’exprime soit par un OID complet identifiant complètement l’instance du document (sans extension), soit par une racine d’OID commune à toutes les instances de documents de l’émetteur associée à une extension propre à l’instance du document.

La règle de peuplement des sous champs des champs TXA-12 et TXA-13 est la suivante :

• si ClinicalDocument/id@extension est renseigné :

  • TXA-12.1 < = ClinicalDocument/id@extension

  • TXA-12.2 < = Non renseigné

  • TXA-12.3 < = ClinicalDocument/id@root

  • TXA-12.4 < = ISO

• si ClinicalDocument/id@extension n’est pas renseigné :

  • TXA-12.1 < = ClinicalDocument/id@root

  • TXA-12.2 < = Non renseigné

  • TXA-12.3 < = Non renseigné

  • TXA-12.4 < = Non renseigné

Point d'attention La version actuelle du DMP ne supporte pas le format OID^Extension.

Le segment ORC

La valeur du champ ORC-1 doit être cohérente avec la valeur du champ OBX-11 et dans le cas du message MDM avec l’évènement déclenchant (T02, T04 ou T10). En cas d’incohérence entre ces champs, le message HL7 sera rejeté par la PFI.

Le segment OBR

Les données concernant la demande de traitement sur le(s) document(s)

Les messages ORU/MDM utilisés contiennent un premier groupe, respectivement OBSERVATION/OBXNTE composé :

• D’un segment OBX contenant un document au format CDA-R2 dont le type MIME est précisé en OBX-5.2.

• D’un segment PRT conditionnel, pré-adopté de la version 2.9 du standard, permettant de renseigner les informations concernant l’expéditeur de la demande de traitement sur le document (publication/remplacement/suppression) et la structure à laquelle l’expéditeur est attaché. Ce segment est requis dans le cas d’une publication du document sur le DMP. Il permet à la PFI de générer le jeton VIHF lors de l’alimentation du DMP ainsi que la métadonnée représentant l’auteur et la structure de l’auteur du lot de soumission.

• D’un segment PRT conditionnel, pré-adopté de la version 2.9 du standard, permettant de renseigner les informations du ou des destinataires MSSanté. Ce segment est requis dans le cas d’un échange de document(s) via le canal MSSanté.

• D’un segment PRT optionnel, pré-adopté de la version 2.9 du standard, permettant de renseigner l’adresse mail sur laquelle le destinataire peut répondre.

Les champs des segments PRT doivent être renseignés conformément aux spécifications « Contraintes sur les types de données HL7 v2.5 applicables aux profils d’intégration du cadre technique IT Infrastructure dans le périmètre d’IHE France » release 1.8.

Les tableaux suivants listent l’ensemble des segments et des champs à renseigner obligatoirement, dans l’ordre indiqué, à l’exception du dernier segment PRT permettant de préciser l’adresse mail de réponse (qui est optionnel).

De façon à éviter les incohérences entre les données spécifiées dans le(s) document(s) et le message ORU/MDM et de façon privilégiée, seuls les segments et les champs indiqués dans les tableaux suivants sont à renseigner dans le message ORU/MDM. Néanmoins, dans le cas où un champ ou un segment autre que ceux indiqués dans le tableau serait renseigné, l’expéditeur du message prend la responsabilité de la cohérence des données entre le message et le(s) document(s) et le récepteur n’a pas l’obligation de gérer le contenu de ces champs ou segments.

​[2] SC.DMP/CONF.12 : « Le système DOIT transmettre à la PFI les informations d'identification nécessaires à la constitution du jeton VIHF : FINESS géographique de l'établissement et l'identifiant du professionnel ou du dispositif à l'origine de la demande d'alimentation du DMP ».

Exemple pour un Compte-Rendu d’imagerie médicale :

Compte-rendu d’imagerie médicale à transmettre à 4 destinataires (le patient, le médecin HODA Adam, le service radiologie de l’hôpital A, une application). Une adresse mail de réponse est indiquée.

OBX|1|ED|18748-4^CR d’imagerie médicale^LN||^Text^XML^Base64^RG9jdW1lbnQgbcOpZGljYWwgYX
UgZm9ybWF0IENEQQ||||||F|
PRT||UC||SB^Send By^participation|801234567866^Dupont^Jean^^^^^^ASIP-SANTE- PS&1.2.250.1.71.4.2.1&ISO^D^^^RPPS |||Organisation-X^^^^^ASIP-SANTE-ST&1.2.250.1.71.4.2.2&ISO^FINEG^^^300017985                  
PRT||UC||RCT^results Copies To^participation|||||||||||^^X.400^146026322000196@patient.mssante.fr
PRT||UC||RCT^results Copies To^participation|101234567897^Hoda^Adam^^^^^^ASIP-SANTE- PS&1.2.250.1.71.4.2.1&ISO^D^^^RPPS|||||||||||^^X.400^adam.hoda@test-ci-sis.mssante.fr PRT||UC||RCT^results Copies To^participation||||Radiologie^^^^^120456789^UF^^^3435|||||||^^X.400^radiologie@hopitalA.mssante.fr
PRT||UC||RCT^results Copies To^participation||||||12|||||^^X.400^appliExemple@hopitalB.mssante.fr
PRT||UC||REPLY^Reply to^participation|||||||||||^^X.400^adam.hoda@test-ci-sis.mssante.fr

Expéditeur MSSanté : Le segment PRT est également utilisé pour renseigner les informations sur l’expéditeur du courriel en fixant le champ PRT-4 « Participation » à SB « Send by ».

La version précédente du présent volet valorisait les adresses email MSSanté des professionnels de santé directement dans le document CDA au niveau de l’élément informationRecipient/intendedRecipient/telecom@Value (Type : url).

Les retours d’expérience du SEGUR ont mis en évidence qu’il ne s’agissait pas d’une bonne pratique. En effet, le contenu de l’élément informationRecipient ne rend pas forcément compte de la réalité des échanges. Rien ne permet par la suite, de certifier que le document a réellement été envoyé à ce(s) destinataire(s). D’autre part, certains médecins n’acceptent pas la dématérialisation des échanges. Cette information doit être prise en compte par les Créateurs de documents lors de l’envoi du message HL7v2.

Pour ces raisons, il a été décidé de dissocier l’information « médicale » portée par l’élément informationRecipient au sein du document CDA de l’information « technique ». La constitution « technique » de cette liste consiste à sélectionner au niveau du Créateur de documents, à partir de l’annuaire des professionnels de santé, la liste des destinataires MSSanté souhaitée au moment de la génération du message HL7v2.

La liste des destinataires MSSanté et l’expéditeur sont ainsi insérés dans le message HL7v2 au travers du segment PRT tel que décrit ci-dessus.

Pour information, la norme CDA r2 précise les points suivants, concernant l’élément informationRecipient :

• (1) informationRecipient contient les destinataires d’une copie du document désignés [au moment de la création du document]{.underline},

• (2) informationRecipient ne permet pas de spécifier les destinataires auxquels le document est transmis ultérieurement à sa création,

• (3) informationRecipient permet de spécifier le destinataire principal (prescripteur de l’examen) et les destinataires secondaires.

En conséquence, l’envoi ultérieur du document CDA à un destinataire non prévu au moment de la création du document ne doit pas donner lieu à la mise à jour de l’élément informationRecipient et donc à une nouvelle version du document.

Concernant le point (3), le « Volet Structuration minimale des documents de santé » a été modifié de façon à lever la contrainte existante sur l’élément « participant ». Il est prévu de modifier la prochaine version du « Volet CR-BIO – Compte-rendu d’examens de biologie médicale » dans le même sens.

Les métadonnées DMP/MSSanté

Cette section présente les métadonnées de restriction indispensables aux échanges avec le DMP et/ou la MSSanté. Ces métadonnées doivent être valorisées avec Y ou N suivant qu’elles sont activées ou non au moment de la validation du document.

Ces métadonnées sont spécifiées au niveau des groupes de segments OBSERVATION/OBXNTE des messages HL7, respectivement ORU/MDM.

Ces métadonnées sont requises sauf les deux dernières (Corps du mail proposé au PS ou au patient) qui sont proposées de façon optionnelle afin de véhiculer des informations complémentaires à intégrer dans le courriel MSSanté. Le caractère obligatoire de chaque métadonnée est indiqué en entête des tableaux.

Les métadonnées doivent apparaître dans le message HL7 dans l’ordre indiqué ci-dessous.

Pour l’ensemble des OBX listés dans cette section, le champ OBX-3 prend ses valeurs dans la table « MétaDMP/MSS » disponible sur cette page.

Le champ OBX-11 étant requis par le standard HL7v2, la valeur de ce champ est arbitrairement fixée à « F ».

L’ensemble de ces métadonnées est identique pour les 2 formats de documents pouvant être contenus dans le message ORU.

Document Masqué aux professionnels de Santé 

Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document est masqué aux professionnels de santé.

Document Non visible par le patient 

Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document est masqué au patient.

Point d'attention un document clinique masqué au patient ne doit pas être envoyé au patient par MSSanté.

Document Non visible par les représentants légaux du patient  

Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document est masqué aux représentants légaux du patient.

Point d'attention : un document clinique masqué aux représentants légaux du patient ne doit pas être envoyé aux représentants légaux du patient par MSSanté.

Connexion Secrète

Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document doit être utilisé pour une transaction DMP « connexion secrète » (cf SESAM-VITALE : Service DMP intégré aux LPS - Version 2.10.0 – 07/07/2023)

Modification Confidentiality Code

Cet OBX permet d’informer l’acteur GESTIONNAIRE que la transaction porte une modification du CONFIDENTIALITY CODE indiquant une mise à jour des métadonnées de masquage/démasquage aux PS et/ou de visibilité du document au patient ou à ses représentants légaux.

Alimentation DMP

Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document doit être utilisé pour une transaction DMP.

Echange MSSanté Professionnel de Santé/Organisation/BAL applicative

Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document doit être envoyé vers un PS, une organisation ou une Boîte aux lettres (BAL) applicative.

Point d’attention : Les adresses mails MSSanté sont valorisées dans les segments PRT (Participation Information) du message HL7v2, dont l'élément PRT-4 (Participation) prend la valeur « RCT (Results Copies To) ». L'adresse mail MSSanté est à récupérer dans l'élément PRT-15 (Participant Telecommunication Address).

Echange MSSanté Patient

Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document doit être échangé vers le mail MSSanté du Patient.

Si l’utilisateur ne souhaite pas que le patient puisse répondre à son message, un segment NTE avec la valeur « FIN » doit être ajouté.

Point d'attention : L'adresse mail MSSanté du patient est valorisée dans un segment PRT (Participation Information) du message HL7v2, dont l'élément PRT-4 (Participation) prend la valeur « RCT (Results Copies To) ». L'adresse mail MSSanté est à récupérer dans l'élément PRT-15 (Participant Telecommunication Address).

Transmission de l’accusé de réception DMP/MSSanté

Cet OBX permet d’informer le GESTIONNAIRE que l’utilisateur souhaite recevoir un accusé de réception provenant du DMP et un accusé de réception provenant du serveur de messagerie de chaque destinataire MSSanté.

Transmission de l’accusé de lecture

Cet OBX permet d’informer le GESTIONNAIRE que l’utilisateur souhaite recevoir un accusé de lecture pour chaque destinataire MSSanté. En fonction de l’organisation choisie, cet accusé de lecture atteste soit de la lecture du courrier électronique présent dans la BAL pour chacun des destinataires MSSanté, soit du résultat du traitement automatique du courrier électronique par le GESTIONNAIRE destinataire.

Corps du mail à destination d’un professionnel de santé

Cet OBX permet à l’acteur CREATEUR de documents d’ajouter un texte à intégrer dans le corps du mail à destination des professionnels de santé via MSSanté. Cette métadonnée est optionnelle :

Point d'attention : Si ce segment OBX est renseigné, le GESTIONNAIRE doit récupérer le corps du mail proposé par le CREATEUR pour l'envoi par MSSanté aux professionnels de santé. A défaut, dans le cadre d'une suppression ou d'un remplacement de document, le GESTIONNAIRE renseigne un corps de mail par défaut.

Corps du mail à destination du patient

Cet OBX permet au CREATEUR de documents d’ajouter un texte à intégrer dans le corps du mail à destination du patient via MSSanté. Cette métadonnée est optionnelle :

Point d'attention : Si ce segment OBX est renseigné,le GESTIONNAIRE doit récupérer le corps du mail proposé par le CREATEUR pour l'envoi par MSSanté au patient. A défaut, dans le cadre d'une suppression ou d'un remplacement de document, le GESTIONNAIRE renseigne un corps de mail par défaut.

Quelques exemples sont disponibles ici.

Le message d’acquittement du message HL7v2 

Après réception du message ORU/MDM, le Gestionnaire va acquitter ce message HL7.

Profil du message ACK

Le profil du message ACK est le suivant :

Structure fonctionnelle du message ACK

La structure du message ACK est représentée ci-dessous :

Ces segments doivent être conformes au standard HL7v2.5 pour le message ORU et HL7v2.6 pour MDM.

Description des contraintes à appliquer sur l’acquittement

Segment MSH

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

Le segment MSH doit être conforme au standard HL7v2.5 ou HL7v2.6 selon le type du message (ORU ou MDM) :

Segment MSA

Segment ERR

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 :

Exemple

Entête MSH d’un message MDM ou ORU émis par le CREATEUR :

MSH|^~\&|SIL|CHU_X|PFI|CHU_X|202310030830||ORU^R01^ORU_R01|12345|P|2.5|||||FRA|8859/15|||2.1^ CISIS_CDA_HL7_V2

Un acquittement positif retourné par le GESTIONNAIRE :

MSH|^~\&|PFI|CHU_X|SIL|CHU_X|202310030831||ACK^R01^ACK|12346|P|2.5|||||FRA|8859/15
MSA|AA|12345

Un acquittement négatif retourné par le GESTIONNAIRE : version d’HL7 inconnue

MSH|^~\&|PFI|CHU_X|SIL|CHU_X|202310030831||ACK^R01^ACK|12347|P|2.5|||||FRA|8859/15
MSA|AE|12345
ERR||MSH^1^12|203^ Unsupported version^messageErrorCondition| E

Description des messages HL7 d’accusés métier

Evènements déclenchants des messages d’accusés métier HL7v2

Après réception du (des) document(s), le GESTIONNAIRE le(s) distribue(nt) au consommateur de documents (DMP/MSSanté). Lorsque le GESTIONNAIRE reçoit un retour du consommateur, il en informe le CREATEUR au moyen d’accusés métier HL7.

A noter qu’aucun accusé de réception métier n’est prévu dans la spécification lors de la réception par la DRIMbox Source du message HL7v2 ORU ou MDM avec le Compte-Rendu d’Imagerie. Par contre, un message d’acquittement technique (voir section dédiée) permettra à la DRIMbox de communiquer au GESTIONNAIRE qu’elle a bien pris la responsabilité des traitements associés au compte-rendu qui lui a été transmis (AA (Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept dans MSA-1)).

Pour couvrir ce besoin de retour d’accusés métiers, un nouveau type de message HL7 a été créé : HL7v2.6 ZAM – Accusé Métier.

Ce type de message est utilisé par trois évènements différents :

Structure des messages accusés métier HL7

L’accusé de réception du document par le DMP, l’accusé de réception du courriel MSSanté et l’accusé de lecture MSSanté seront transmis en utilisant la structure de message HL7v2.6 ZAM_Z01 :

Ces segments doivent être conformes au standard HL7v2.6. Les contraintes concernant les segments en rouge sur le schéma sont décrites dans la section suivante.

Description des contraintes à appliquer sur les accusés métiers

Pour l’ensemble des OBX listés dans cette section, le champ OBX-3 prend ses valeurs dans la table « AckMetierZAM » disponible ici.

Contraintes à appliquer au message ZAM^Z01^ZAM_Z01 - Accusé de réception DMP

Segment MSH

Le segment MSH doit être conforme au standard HL7v2.6. Dans le cadre de ces spécifications, le champ MSH-9 « Message Type » prend la valeur ZAM^Z01^ZAM_Z01.

Segment OBX portant le statut de d’accusé de réception

Le premier segment OBX renseigne le statut de l’accusé de réception :

Segment ERR

Si une erreur intervient lors du dépôt du document sur le DMP, ce segment contient sa description.

Contraintes à appliquer au message ZAM^Z02^ZAM_Z01 – Accusé de réception MSSanté

Segment MSH

Le segment MSH doit être conforme au standard HL7v2.6. Dans le cadre de ces spécifications, le champ MSH-9 « Message Type » prend la valeur ZAM^Z02^ZAM_Z01.

Segment OBX portant le statut de d’accusé de réception

Le premier segment OBX renseigne le statut de l’accusé de réception MSSanté :

Segment OBX portant les informations du destinataire MSSanté

Le deuxième segment OBX renseigne les informations du destinataire du courriel MSSanté :

Segment ERR

Si une erreur intervient lors de la distribution du ou des document(s) par MSSanté dans le serveur de messagerie du destinataire MSSanté, ce segment contient sa description.

Contraintes à appliquer au message ZAM^Z03^ZAM_Z01 – Accusé de lecture MSSanté

Segment MSH

Le segment MSH doit être conforme au standard HL7v2.6. Dans le cadre de ces spécifications, le champ MSH-9 « Message Type » prend la valeur ZAM^Z03^ZAM_Z01.

Segment OBX portant le statut de d’accusé de lecture MSSanté

Le premier segment OBX renseigne le statut de l’accusé de lecture :

Segment OBX portant les informations du lecteur

Le deuxième segment OBX renseigne les informations du lecteur du courriel MSSanté :

Segment ERR

Si une erreur intervient lors du traitement de la demande réceptionnée par le destinataire, ce segment contient sa description.

Seules les erreurs de niveau applicatif du traitement automatique sur le document au niveau du destinataire final sont remontées au travers du courriel MDN et réceptionnées par le GESTIONNAIRE (la PFI expéditrice). Les erreurs de type technique (erreurs de syntaxe du message HL7) sont généralement traitées localement, côté du destinataire, par une des intervenants techniques. Dans ces conditions, le segment ERR-3 prend la valeur 207 et le segment ERR-5 contient l’erreur applicative remontée au travers du courriel MDN. Le message HL7 ZAM^Z03^ZAM_Z01 est généré ple GESTIONNAIRE à partir des informations contenues dans le courriel MDN (cf structure du MDN – Message Disposition Notification) décrit en Annexe 4 du volet « Transmission au LPS d’un document CDA provenant d’un courriel MSSanté ».

Message d’acquittement technique des accusés métiers

Le message d’acquittement est identique à celui spécifié dans la partie dédiée, à l’exception du champ MSH-9 qui prend la valeur ACK^Z01^ACK ou ACK^Z02^ACK ou ACK^Z03^ACK selon l’évènement du message initial.

Règles de gestion MSSANTE

Ci-dessous la matrice de gestion pour les échanges MSSanté suivant les OBX valorisés. Le tableau présente une liste exhaustive des combinaisons possibles des OBX pour l’échange MSSANTE. Les cas non représentés génèrent un message d’erreur.

Lien entre l’EN-TETE CDA et les métadonnées XDS

Une annexe disponible sur le CI-SIS indique la correspondance entre les données d’en-tête d’un document CDA définies dans le volet structuration minimale des documents de Santé et les métadonnées XDS définies dans le volet partage de documents de Santé.

• Annexe – Lien Entre l’en-tête CDA et les métadonnées XDS