Volet de transmission d'un document CDA-R2 en HL7v2
2.1.1 - ci-build
Volet de transmission d'un document CDA-R2 en HL7v2
2.1.1 - ci-build
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
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.
Le profil du message ORU_R01 est le suivant :
|
Segment |
Meaning |
Usage |
Card. |
§ HL7 |
|
MSH |
Message Header |
R |
[1..1] |
2 |
|
|
--- PATIENT_RESULT begin |
R |
[1..1] |
|
|
|
--- PATIENT begin |
R |
[1..1] |
|
|
PID |
Patient Identification |
R |
[1..1] |
3 |
|
|
--- PATIENT_VISIT begin |
RE |
[0..1] |
|
|
PV1 |
Patient Visit |
R |
[1..1] |
3 |
|
|
--- PATIENT_VISIT end |
|
|
|
|
|
--- PATIENT end |
|
|
|
|
{ |
--- ORDER_OBSERVATION begin |
R |
[1..*] |
|
|
ORC |
Common Order : demande de traitement sur un document |
R |
[1..1] |
4 |
|
OBR |
Observation Request |
R |
[1..1] |
4 |
|
[{NTE}] |
Comments on the order |
O |
[0..*] |
2 |
|
[{ |
--- TIMING begin |
O |
[0..*] |
|
|
TQ1 |
Timing Quantity |
R |
[1..1] |
4 |
|
}] |
--- TIMING end |
|
|
|
|
{ |
--- OBSERVATION begin |
R |
[1..*] |
|
|
OBX |
Document et expression des métadonnées de document relatives au masquage du document aux PS et de visibilité au patient. |
R |
[1..1] |
7 |
|
[{PRT}] (note 1) |
Participation : Expéditeur du document, destinataire(s) MSSanté, adresse mail sur laquelle le destinataire peut répondre. Segment PRT pré-adopté de la version 2.9 |
R/C |
[1..*] |
7 (v2.9) |
|
[{NTE}] |
Comment of the result |
O |
[0..*] |
2 |
|
} |
--- OBSERVATION end |
|
|
|
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.
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.
Le profil du message MDM est le suivant :
|
Segment |
Meaning |
Usage |
Card. |
§ HL7 |
|
MSH |
Message Header |
R |
[1..1] |
2 |
|
EVN |
Event type |
R |
[1..1] |
2 |
|
PID |
Patient Identification |
R |
[1..1] |
3 |
|
PV1 |
Patient Visit |
R |
[1..1] |
3 |
|
|
--- COMMON_ORDER begin |
R |
[1..1] |
|
|
ORC |
Common Order = demande de traitement sur le document |
R |
[1..1] |
4 |
|
[{ |
--- TIMING begin |
O |
[0..*] |
|
|
TQ1 |
Timing/Quantity |
R |
[1..1] |
4 |
|
[{TQ2}] |
Timing/Quantity RelationShip |
O |
[0..*] |
4 |
|
}] |
--- TIMING end |
|
|
|
|
OBR |
Observation Request segment |
R |
[1..1] |
4 |
|
[{NTE}] |
Notes and comments |
O |
[0..*] |
2 |
|
|
--- COMMON_ORDER end |
|
|
|
|
TXA |
Transcription document header |
R |
[1..1] |
9 |
|
{ |
OBXNTE : Document ou expression des métadonnées de document relatives au masquage du document aux PS et de visibilité au patient. |
R |
[1..*] |
|
|
OBX |
Observation/Result. |
R |
[1..1] |
9 |
|
[{PRT}] (Note 1) |
Participation : Expéditeur, destinataire(s) MSSanté, adresse mail sur laquelle le destinataire peut répondre. Segment PRT pré-adopté de la version 2.9 |
R/C |
[1.*] |
7 (v2.9) |
|
[{NTE}] |
Notes and comments |
O |
[0..*] |
2 |
|
} |
---OBXNTE end |
|
|
|
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.
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).
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.
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 :
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire
|
|
MSH-1 |
| séparateur de champ |
ST |
R |
|
MSH-2 |
^~\& : séparateur de composant, répétition, caractère d’échappement, séparateur de sous-composants |
ST |
R |
|
MSH-3 |
Application émettrice |
HD |
R |
|
MSH-4 |
Organisation émettrice |
HD |
R |
|
MSH-5 |
Application réceptrice |
HD |
R |
|
MSH-6 |
Organisation réceptrice |
HD |
R |
|
MSH-7 |
Date/time du message |
TS |
R |
|
MSH-9 |
Type du message |
MSG |
R
|
|
MSH-10 |
Identifiant du message |
ST |
R |
|
MSH-11 |
Processing Id |
PT |
R |
|
MSH-12 |
Version du standard |
VID |
R |
|
MSH-17 |
FRA |
ID |
R |
|
MSH-18 |
Jeux de caractères, valeurs possibles : UNICODE UTF-8 ou 8859/15 |
ID |
R |
|
MSH-21 |
Identifiant du profil de message MSH-21.1 : Entity Identifier (2.1) MSH-21.2 : Namespace Id CISIS_CDA_HL7_V2 |
EI |
R |
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
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.
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire |
|
PID-3 |
Identifiants du patient |
CX |
R |
|
PID-5 |
Nom du patient |
XPN |
R |
|
PID-18 (Note 1) |
N° de dossier administratif |
CX |
RE |
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 :
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire |
|
PV1-2 |
Classe du patient |
IS |
R |
|
PV1-19 (Note 1) et (Note 2) |
Identifiant de la venue |
CX |
C (Note 2) |
|
PV1-44 (Note 1) |
Date d’entrée du patient |
TS |
RE |
|
PV1-45(Note 1) |
Date de sortie du patient |
TS |
RE |
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.
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 :
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire |
|
TXA-1 |
Set-ID TXA. Valeur = 1 |
SI |
R |
|
TXA-2 |
Type de document dont les valeurs sont à prendre dans le JDV_J07-XdsTypeCode-CISIS de la Nomenclature des Objets de Santé (NOS). Par ex : 11502-2 |
IS |
R |
|
TXA-3 |
Document Content Presentation TEXT |
ID |
R |
|
TXA-12 (Note 1) |
Unique document number Si ClinicalDocument/id@extension est renseigné : ex : 58132^^1.2.250.2345.3245.13^ISO Si ClinicalDocument/id@extension n’est pas renseigné : ex : 1.2.250.2345.3245.13.58132 |
EI |
R |
|
TXA-13 (Note 1) |
Parent document number Si ClinicalDocument/id@extension est renseigné : ex : 58131^^1.2.250.2345.3245.13^ISO Si ClinicalDocument/id@extension n’est pas renseigné : ex : 1.2.250.2345.3245.13.58131 |
EI |
C Requis dans le cas d’une demande de remplacement |
|
TXA-17 |
Document completion status dont la valeur est à prendre dans la table HL7 0271 AU |
ID |
R |
(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.
|
Composition du segment ORC : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment ORC |
Common Order |
|
|
ORC-1 |
Order control |
NW (New order/service dans le cas d’une demande d’intégration de document(s) RO (Replace order) dans le cas d’une demande de remplacement CA (Canceled) dans le cas d’une demande de suppression |
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.
|
Composition du segment OBR : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBR |
Observation Request |
|
|
OBR-4 |
Universal Service Identifier |
|
|
>OBR-4.1 |
Code du document |
Utiliser le JDV_J07-XdsTypeCode-CISIS de la Nomenclature des Objets de Santé (NOS). A noter qu’en cas d’envoi au DMP, le Gestionnaire doit contrôler que le type de document appartient au jeu de valeur défini par le DMP (JDV_J66-TypeCode-DMP). |
|
>OBR-4.2 |
Libellé du document |
|
|
>OBR-4.3 |
Système de codage dont est issu le code |
LN ou TRE_A05 en fonction de l’appartenance du code à l’un des systèmes de codage |
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.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX (Requis) |
Observation/Result |
Contient un document au format CDA-R2 |
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
ED (Encapsuled Data) |
|
OBX-3 = OBR-4 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code du Document |
Utiliser le JDV_J07-XdsTypeCode-CISIS de la Nomenclature des Objets de Santé (NOS). A noter qu’en cas d’envoi au DMP, le Gestionnaire doit contrôler que le type de document appartient au jeu de valeur défini par le DMP (JDV_J66-TypeCode-DMP). |
|
> OBX-3.2 : |
Libellé du Document |
|
|
>OBX-3.3 |
Système de codage dont est issu le code |
LN ou TRE_A05 en fonction de l’appartenance du code à l’un de ces systèmes de codage. |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Source Application |
|
|
> OBX-5.2 |
Type |
Pour le message ORU : TEXT (Machine readable text document) Pour le message MDM : text (Text data) |
|
> OBX-5.3 |
Data Subtype |
XML |
|
> OBX-5.4 |
Encoding |
Base64 |
|
> OBX-5.5 |
Data |
Intégrer le document CDA-R2 |
|
OBX-11 |
Observation Result Status |
Statut du document pris dans la table HL7 0085 (Observation Result Status Codes Interpretation) : · F : Document validé · D : Document à supprimer · C : Remplacement du Document |
|
Segment PRT (Conditionnel) |
Participation Information |
Ce segment est requis, en particulier dans le cas d’une publication du document sur le DMP, pour permettre à la PFI de générer le VIHF ainsi que l’auteur du lot de soumission. [2] Ce segment contient les informations de l’expéditeur à l’origine de la demande de traitement sur le document et de la structure à laquelle il est rattaché. |
|
PRT-2 |
Action Code |
UC (Unchanged) |
|
PRT-4 |
Participation |
SB^Send by^participation |
|
PRT-5 (conditionnel) |
Participation Person |
Ce champ est requis si l’expéditeur est un professionnel de santé |
|
> PRT-5.1 |
Person Identifier |
Identifiant du professionnel de santé qui fait la demande de traitement sur le(s) document(s) |
|
> PRT-5.2 |
Family Name |
Nom d’exercice du PS expéditeur |
|
> PRT-5.3 |
Given Name |
Prénom d’exercice du PS expéditeur |
|
> PRT-5.9 |
Assigning Authority |
Autorité d’affectation de l’identifiant du PS (OID de gestion de personnes) : 1.2.250.1.71.4.2.1 |
|
> PRT-5.13 |
Identifier Type Code |
Type d’identifiant du professionnel de santé (valeur issue de la Table 0203 – Interop’Santé) : RPPS |
|
PRT-8 |
Participation Organization |
Décrit l’organisation rattachée au professionnel de santé ou au système à l'origine de la demande de traitement sur le(s) document(s) |
|
> PRT-8.1 |
OrganizationName |
Nom de l’organisation |
|
> PRT-8.6 |
Assigning Authority |
Autorité d’affectation de l’identifiant de l’organisation dont dépend le PS ou le système à l’origine de la demande de traitement sur le(s) document(s). 1.2.250.1.71.4.2.2 (OID de gestion des structures pour un PS dans un établissement de santé). |
|
> PRT-8.7 |
Identifier Type Code |
Type d’identifiant de l’organisation (valeur issue de la Table 0203 – Interop’Santé) : FINEJ (FINESS d’entité juridique) ou FINEG (FINESS d’entité géographique). |
|
> PRT-8.10 |
Organization number |
Identifiant de l’organisation à l’origine de la demande de traitement sur le(s) document(s) |
|
PRT-10 (conditionnel) |
Participation Device |
Ce champ est requis si l’auteur est un dispositif. |
|
> PRT-10.1 |
Entity Identifier |
Identifiant du dispositif expéditeur du document |
|
Segment PRT (conditionnel) |
Participation Information destinataire(s) |
Ce segment est répétable et requis si le document est échangé via MSSanté. Il contient l’adresse MSSanté d’un destinataire. Ce segment est répétable. |
|
PRT-2 |
Action Code |
UC (Unchanged) |
|
PRT-4 |
Participation |
RCT^Result Copies To^participation |
|
PRT-5 (conditionnel) |
Participation Person |
Ce champ est requis si le destinataire est un professionnel de santé ou un patient. |
|
> PRT-5.1 |
Person Identifier |
Identifiant du professionnel de santé destinataire/patient |
|
> PRT-5.2 |
Family Name |
Nom d’exercice du PS destinataire/nom patient |
|
> PRT-5.3 |
Given Name |
Prénom d’exercice du PS destinataire/prénom patient |
|
> PRT-5.9 |
Assigning Authority |
Autorité d’affectation de l’identifiant du PS (OID de gestion de personnes) : 1.2.250.1.71.4.2.1 ou du patient 1.2.250.1.213.1.4.8 (INS-NIR) ou 1.2.250.1.213.1.4.9 (INS-NIA). |
|
> PRT-5.13 |
Identifier Type Code |
Type d’identifiant (valeur issue de la Table 0203 – Interop’Santé) : RPPS ou INS |
|
PRT-8 (conditionnel) |
Participation Organization |
Ce champ est requis si le destinataire est une organisation (établissement, service, UF…). |
|
> PRT-8.1 |
OrganizationName |
Nom de l’organisation |
|
> PRT-8.6 |
Assigning Authority |
Autorité d’affectation de l’identifiant de l’organisation destinataire du document. 1.2.250.1.71.4.2.2 (OID de gestion des structures pour préciser une entité juridique ou une entité géographique), N° FINESS ou N° FINEG pour identifier une organisation intra-établissement (service, UF, pôle…). Cf 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.[12] |
|
> PRT-8.7 |
Identifier Type Code |
Type d’identifiant (valeur issue de la Table 0203 – Interop’Santé) : FINEJ (FINESS d’entité juridique) ou FINEG (FINESS d’entité géographique) ou UF (UF), SVR (service)... |
|
> PRT-8.10 |
Organization number |
Identifiant de l’organisation destinataire du document |
|
PRT-10 (conditionnel) |
Participation Device |
Ce champ est requis si le destinataire est une application. |
|
> PRT-10.1 |
Entity Identifier |
Identifiant de l’application destinataire du document |
|
PRT-15 |
Participant Telecommunication Address |
|
|
> PRT-15.3 |
Telecommunication Equipment Type |
X.400 (X.400 email address) |
|
> PRT-15.4 |
Communication Address |
Intégrer l’adresse mail MSSanté |
|
|
|
|
|
Segment PRT (segment optionnel) |
Participation Information |
Ce segment optionnel permet d’indiquer l’adresse mail sur laquelle le destinataire peut répondre. |
|
PRT-2 |
Action Code |
UC (Unchanged) |
|
PRT-4 |
Participation |
REPLY^Reply To^participation |
|
PRT-15 |
Participant Telecommunication Address |
|
|
> PRT-15.3 |
Telecommunication Equipment Type |
X.400 (X.400 email address) |
|
> PRT-15.4 |
Communication Address |
Intégrer l’adresse mail de réponse |
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@medecin.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@medecin.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.
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.
Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document est masqué aux professionnels de santé.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
MASQUE_PS |
|
> OBX-3.2 : |
Libellé : |
Masqué aux professionnels de Santé |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code |
Table HL7 : 0136 : · Y (Yes) àMASQUE_PS actif · N (No) à MASQUE_PS non Actif |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document est masqué au patient.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
INVISIBLE_PATIENT |
|
> OBX-3.2 : |
Libellé : |
Document Non Visible par le patient |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Table HL7 : 0136 : · Y (YES) à INVISIBLE_PATIENT actif · N (No) à INVISIBLE_PATIENT non actif |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
Point d'attention un document clinique masqué au patient ne doit pas être envoyé au patient par MSSanté.
Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document est masqué aux représentants légaux du patient.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
INVISIBLE_REP_LEGAUX |
|
> OBX-3.2 : |
Libellé : |
Non visible par les représentants Légaux du patient |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Table HL7 : 0136 : · Y (YES) à INVISIBLE_ REP_LEGAUX actif · N (No) à INVISIBLE_ REP_LEGAUX non actif |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
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é.
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)
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
CONNEXION_SECRETE |
|
> OBX-3.2 : |
Libellé : |
Connexion Secrete |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Table HL7 : 0136 : - Y (Yes) à CONNEXION_SECRETE actif - N (No) à CONNEXION_SECRETE non Actif |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
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.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
MODIF_CONF_CODE |
|
> OBX-3.2 : |
Libellé : |
Modification Confidentiality Code |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Table HL7 : 0136 : - Y (Yes) à MODIF_CONF_CODE actif - N (No) à MODIF_CONF_CODE non Actif |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document doit être utilisé pour une transaction DMP.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
DESTDMP |
|
> OBX-3.2 : |
Libellé : |
Destinataire DMP |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Table HL7 : 0136 : - Y (Yes) à DESTDMP actif - N (No) à DESTDMP non Actif |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
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.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
DESTMSSANTEPS |
|
> OBX-3.2 : |
Libellé : |
Destinataire (Professionnel de Santé, organisation ou BAL applicative) |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Table HL7 : 0136 : - Y (Yes) à DESTMSSANTEPS actif - N (No) à DESTMSSANTEPS non Actif |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
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).
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é.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
DESTMSSANTEPAT |
|
> OBX-3.2 : |
Libellé : |
Destinataire Patient |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Table HL7 : 0136 : - Y (Yes) : DESTMSSANTEPAT actif - N (No) : DESTMSSANTEPAT non Actif |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
|
Segment NTE (conditionnel) |
Notes And Comments |
Ce segment doit être renseigné avec la valeur « FIN » si l’utilisateur ne souhaite pas que le patient puisse répondre au courriel. |
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).
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é.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Optional / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
ACK_RECEPTION |
|
> OBX-3.2 : |
Libellé : |
Accusé de réception |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Table HL7 : 0136 : - Y (Yes) à ack de réception DMP/MSSanté souhaité - N (No) à accusé de réception DMP/MSSanté non souhaité |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
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.
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Optional / Cardinalité = [1..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
Pour le message ORU : CE (Coded Entry) Pour le message MDM : CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
ACK_LECTURE_MSS |
|
> OBX-3.2 : |
Libellé : |
Accusé de lecture |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Table HL7 : 0136 : - Y (Yes) à accusé de lecture MSSanté souhaité - N (No) à accusé de lecture MSSanté non souhaité |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
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 :
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Optional / Cardinalité = [0..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
ED (Encapsulated Data) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
CORPSMAIL_PS |
|
> OBX-3.2 : |
Libellé : |
Corps du mail pour un PS |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
Indiquer le texte à intégrer dans le corps du mail |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
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.
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 :
|
Composition du groupe OBSERVATION/OBXNTE : Usage = Optional / Cardinalité = [0..1] |
||
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
|
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment |
|
OBX-2 |
Value Type |
ED (Encapsulated Data) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Code : |
CORPSMAIL_PATIENT |
|
> OBX-3.2 : |
Libellé : |
Corps du mail pour le patient |
|
> OBX-3.3 : |
Name of Coding system |
MetaDMPMSS |
|
OBX-5 |
Observation Value |
Indiquer le texte à intégrer dans le corps du mail |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
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.
Après réception du message ORU/MDM, le Gestionnaire va acquitter ce message HL7.
Le profil du message ACK est le suivant :
|
Segment |
Meaning |
Usage |
Card. |
HL7 § |
|
MSH |
Message header |
R |
[1..1] |
2 |
|
[{SFT}] |
Software segment |
O |
[0..*] |
2 |
|
[UAC] |
User Authentication credential– Utilisé uniquement dans la version 2.6 |
O |
[0..1] |
2 |
|
MSA |
Message Acknowledgement |
R |
[1..1] |
2 |
|
[{ERR}] |
Error |
C |
[0..*] |
2 |
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.
Le segment MSH reprend une partie des informations du message initial :
|
Message initial |
Message d’acquittement |
||
|
Champ |
Description |
Champ |
Description |
|
MSH.3 - Sending Application |
Application source du message à acquitter |
MSH.5 - Receiving Application |
Application destinatrice de l’acquittement |
|
MSH.4 - Sending Facility |
Etablissement source du message à acquitter |
MSH.6 - Receiving Facility |
Etablissement destinataire de l’acquittement |
|
MSH.5 - Receiving Application |
Application destinatrice du message à acquitter |
MSH.3 - Sending Application |
Application source de l’acquittement |
|
MSH.6 - Receiving Facility |
Etablissement destinataire du message à acquitter |
MSH.4 - Sending Facility |
Etablissement source de l’acquittement |
|
MSH.11 - Processing Id |
Identifiant de traitement |
MSH.11 - Processing Id |
Identifiant de traitement |
Le segment MSH doit être conforme au standard HL7v2.5 ou HL7v2.6 selon le type du message (ORU ou MDM) :
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire
|
|
MSH-1 |
| séparateur de champ |
ST |
R |
|
MSH-2 |
^~\& : séparateur de composant, répétition, caractère d’échappement, séparateur de sous-composants |
ST |
R |
|
MSH-3 |
Application émettrice |
HD |
R |
|
MSH-4 |
Organisation émettrice |
HD |
R |
|
MSH-5 |
Application réceptrice |
HD |
R |
|
MSH-6 |
Organisation réceptrice |
HD |
R |
|
MSH-7 |
Date/time du message |
TS |
R |
|
MSH-9 |
Type du message, selon l’évènement du message
initial : ACK^T02^ACK ACK^T04^ACK ACK^T10^ACK.
|
MSG |
R
|
|
MSH-10 |
Identifiant du message |
ST |
R |
|
MSH-11 |
Processing Id |
PT |
R |
|
MSH-12 |
Version du standard |
VID |
R |
|
MSH-17 |
FRA |
ID |
R |
|
MSH-18 |
Jeux de caractères, valeurs possibles : UNICODE UTF-8 ou 8859/15
|
ID |
R |
|
Champ requis |
Contenu |
|
MSA.1 - Acknowledgment Code |
Code d’acquittement du message autorisé : · AA (Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept) : le message a été compris et intégré par l’application destinatrice qui prend la responsabilité du message et libère ainsi l’application productrice de toute obligation de le renvoyer. · AE (Original mode: Application Error - Enhanced mode: Application acknowledgment: Error) : le message contient des erreurs de syntaxe. · AR (Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject) : le message est rejeté pour une raison circonstancielle. Il peut être réémis plus tard. |
|
MSA.2 - Message Control Id |
Rappel l’identifiant du message acquitté correspondant au champ MSH.10 du message initial. |
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 :
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire |
|
ERR-2 |
Localisation de l’erreur dans le cas d’une erreur de syntaxe du message initial. |
ERL |
O |
|
ERR-3 |
Code erreur HL7 dont les valeurs sont à prendre dans la table HL7 0357 (nom symbolique messageErrorCondition) |
CWE |
R |
|
ERR-4 |
Sévérité de l’erreur dont les valeurs sont à prendre dans la table HL7 0516 (nom symbolique errorSeverity) |
ID |
R |
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
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 :
|
Flux métier |
Evènement déclenchant au niveau du GESTIONNAIRE |
Message métier HL7 |
|
AccuseMetierReceptionDMP : Accusé de réception de(s) document(s) par le DMP. |
Réception du retour du DMP (Provide And Register Document Set-b Response) |
- ZAM : L’évènement utilisé sera le Z01 « Accusé de réception DMP » à ZAM^Z01^ZAM_Z01 |
|
AccuseMetierReceptionMSS : Accusé de réception de la demande par le serveur de messagerie du destinataire MSSanté |
Réception du message DSN (RFC 3461 à 3464 et 6522) |
- ZAM : L’évènement utilisé sera le Z02 « Accusé de réception MSSanté » à ZAM^Z02^ZAM_Z01 |
|
AccuseMetierLectureMSS : Accusé de lecture du courriel (traitement automatique du courriel ou lecture du courriel par un utilisateur dans sa boîte aux lettres) |
Réception du courriel MDN (RFC 8098) |
- ZAM : L’évènement utilisé sera le Z03 « Accusé de lecture MSSanté » à ZAM^Z03^ZAM_Z01 |
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.
Pour l’ensemble des OBX listés dans cette section, le champ OBX-3 prend ses valeurs dans la table « AckMetierZAM » disponible ici.
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.
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire |
|
MSH-1 |
| séparateur de champ |
ST |
R |
|
MSH-2 |
^~\& : séparateur de composant, répétition, caractère d’échappement, séparateur de sous-composants |
ST |
R |
|
MSH-3 |
Application émettrice |
HD |
R |
|
MSH-4 |
Organisation émettrice |
HD |
R |
|
MSH-5 |
Application réceptrice |
HD |
R |
|
MSH-6 |
Organisation réceptrice |
HD |
R |
|
MSH-7 |
Date/time du message |
TS |
R |
|
MSH-9 |
Type du message : ZAM^Z01^ZAM_Z01 |
MSG |
R |
|
MSH-10 |
Identifiant du message |
ST |
R |
|
MSH-11 |
Processing Id |
PT |
R |
|
MSH-12.1 |
Version du standard |
VID |
R |
|
MSH-17 |
FRA |
ID |
R |
|
MSH-18 |
Jeux de caractères, valeurs possibles : UNICODE UTF-8 ou 8859/15 |
ID |
R |
|
MSH-21.1 |
Version du présent volet du CI_SIS : 2.1 |
ST |
R |
|
MSH-21.2 |
Identifiant du profil de message : CISIS_CDA_HL7_V2 |
IS |
R |
Le premier segment OBX renseigne le statut de l’accusé de réception :
|
Composition du segment OBX : Usage = Required / Cardinalité = [1..1] |
||
|
Champ requis : |
Description : |
Valeur : |
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment 1 |
|
OBX-2 |
Value Type |
CWE (Coded with Exceptions) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Identifier |
ACK_RECEPTION_DMP |
|
> OBX-3.2 : |
Text |
Accusé de réception DMP |
|
> OBX-3.3 |
Name of Coding system |
AckMetierZAM |
|
OBX-4 |
Observation Sub-ID |
Indiquer l’identifiant du message (ORU/MDM) ayant transmis le document |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Statut de l’accusé de réception - Table HL7 : 0136 : - Y (Yes) à Succès - N (No) à Erreur |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
Si une erreur intervient lors du dépôt du document sur le DMP, ce segment contient sa description.
|
Composition du segment ERR : Usage = Conditional / Cardinalité = [0..1] (Requis si le champ 5 du premier OBX prend la valeur N) |
||
|
Champ requis : |
Description : |
Valeur : |
|
ERR - 3 |
Hl7 Error Code |
207^Application error^messageErrorCondition |
|
ERR - 4 |
Severity |
Error, Fatal Error, Information, Warning |
|
ERR - 5 |
Application Error Code (CWE) |
Code erreur de DMP à Utiliser les codes et libellés de codes de l’annexe A7-1 « Liste des codes d’erreurs » de la spécification « <a href=https://industriels.sesam-vitale.fr>Service DMP intégré aux LPS » v.2.10.0</a></sup> Code^libellé du code^DMP_ERROR_CODE |
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.
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire |
|
MSH-1 |
| séparateur de champ |
ST |
R |
|
MSH-2 |
^~\& : séparateur de composant, répétition, caractère d’échappement, séparateur de sous-composants |
ST |
R |
|
MSH-3 |
Application émettrice |
HD |
R |
|
MSH-4 |
Organisation émettrice |
HD |
R |
|
MSH-5 |
Application réceptrice |
HD |
R |
|
MSH-6 |
Organisation réceptrice |
HD |
R |
|
MSH-7 |
Date/time du message |
TS |
R |
|
MSH-9 |
Type du message : ZAM^Z02^ZAM_Z01 |
MSG |
R |
|
MSH-10 |
Identifiant du message |
ST |
R |
|
MSH-11 |
Processing Id |
PT |
R |
|
MSH-12.1 |
Version du standard |
VID |
R |
|
MSH-17 |
FRA |
ID |
R |
|
MSH-18 |
Jeux de caractères, valeurs possibles : UNICODE UTF-8 ou 8859/15 |
ID |
R |
|
MSH-21.1 |
Version du présent volet du CI_SIS : 2.1 |
ST |
R |
|
MSH-21.2 |
Identifiant du profil de message : CISIS_CDA_HL7_V2 |
IS |
R |
Le premier segment OBX renseigne le statut de l’accusé de réception MSSanté :
|
Composition du segment OBX : Usage = Required / Cardinalité = [1..1] |
||
|
Champ requis : |
Description : |
Valeur : |
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment 1 |
|
OBX-2 |
Value Type |
CWE |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Identifier |
ACK_RECEPTION_MSS |
|
> OBX-3.2 : |
Text |
Accusé de réception MSSanté |
|
> OBX-3.3 |
Name of Coding system |
AckMetierZAM |
|
OBX-4 |
Observation Sub-ID |
Indiquer l’identifiant du message (ORU/MDM) ayant transmis le document |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Statut de l’accusé de réception - Table HL7 : 0136 : - Y (Yes) à Succès - N (No) à Erreur |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
Le deuxième segment OBX renseigne les informations du destinataire du courriel MSSanté :
|
Composition du segment OBX : Usage = Required / Cardinalité = [1..1] |
||
|
Champ requis : |
Description : |
Valeur : |
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment 2 |
|
OBX-2 |
Value Type |
XTN |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Identifier |
DESTINATAIRE_MSS |
|
> OBX-3.2 : |
Text |
Destinataire MSSanté |
|
> OBX-3.3 |
Name of Coding system |
AckMétierZAM |
|
OBX-4 (optionnel) |
Observation Sub-ID |
Indiquer l’identifiant du destinataire |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.3 |
Telecommunication Equipment Type |
X.400 (X.400 email address) |
|
> OBX-5.4 |
Communication Address |
Intégrer l’adresse MSSanté du destinataire |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
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.
|
Composition du segment ERR : Usage = Conditional / Cardinalité = [0..1] (Requis si le champ 5 du premier OBX prend la valeur N) |
||
|
Champ requis : |
Description : |
Valeur : |
|
ERR - 3 |
Hl7 Error Code |
207^Application error^messageErrorCondition |
|
ERR - 4 |
Severity |
Error, Fatal Error, Information, Warning |
|
ERR - 5 |
Application Error Code |
Code erreur de MSSanté. Cf Table « SMTPERRORCODE » Code SMTP^libellé du code^SMTPERRORCODE |
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.
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire |
|
MSH-1 |
| séparateur de champ |
ST |
R |
|
MSH-2 |
^~\& : séparateur de composant, répétition, caractère d’échappement, séparateur de sous-composants |
ST |
R |
|
MSH-3 |
Application émettrice |
HD |
R |
|
MSH-4 |
Organisation émettrice |
HD |
R |
|
MSH-5 |
Application réceptrice |
HD |
R |
|
MSH-6 |
Organisation réceptrice |
HD |
R |
|
MSH-7 |
Date/time du message |
TS |
R |
|
MSH-9 |
Type du message : ZAM^Z03^ZAM_Z01 |
MSG |
R |
|
MSH-10 |
Identifiant du message |
ST |
R |
|
MSH-11 |
Processing Id |
PT |
R |
|
MSH-12.1 |
Version du standard |
VID |
R |
|
MSH-17 |
FRA |
ID |
R |
|
MSH-18 |
Jeux de caractères, valeurs possibles : UNICODE UTF-8 ou 8859/15 |
ID |
R |
|
MSH-21.1 |
Version du présent volet du CI_SIS : 2.1 |
ST |
R |
|
MSH-21.2 |
Identifiant du profil de message : CISIS_CDA_HL7_V2 |
IS |
R |
Le premier segment OBX renseigne le statut de l’accusé de lecture :
|
Composition du segment OBX : Usage = Required / Cardinalité = [1..1] |
||
|
Champ requis : |
Description : |
Valeur : |
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment 1 |
|
OBX-2 |
Value Type |
CWE |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Identifier |
ACK_LECTURE_MSS |
|
> OBX-3.2 : |
Text |
Accusé de lecture |
|
> OBX-3.3 |
Name of Coding system |
AckMetierZAM |
|
OBX-4 |
Observation Sub-ID |
Indiquer l’identifiant du message (ORU/MDM) ayant transmis le document |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.1 |
Code : |
Statut de l’accusé de lecture - Table HL7 : 0136 : - Y (Yes) à Succès - N (No) à Erreur |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
Le deuxième segment OBX renseigne les informations du lecteur du courriel MSSanté :
|
Composition du segment OBX : Usage = Required / Cardinalité = [1..1] |
||
|
Champ requis : |
Description : |
Valeur : |
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment 2 |
|
OBX-2 |
Value Type |
XTN |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Identifier |
LECTEUR_MSS |
|
> OBX-3.2 : |
Text |
Lecteur du courriel MSSanté |
|
> OBX-3.3 |
Name of Coding system |
AckMetierZAM |
|
OBX-4 (optionnel) |
Observation Sub-ID |
Indiquer l’identifiant du professionnel de santé |
|
OBX-5 |
Observation Value |
|
|
> OBX-5.3 |
Telecommunication Equipment Type |
X.400 (X.400 email address) |
|
> OBX-5.4 |
Communication Address |
Intégrer l’adresse de la BAL qui a lu le courriel. |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
Si une erreur intervient lors du traitement de la demande réceptionnée par le destinataire, ce segment contient sa description.
|
Composition du segment ERR : Usage = Conditional / Cardinalité = [0..1] (Requis si le champ 5 du premier OBX prend la valeur N) |
||
|
Champ requis : |
Description : |
Valeur : |
|
ERR - 3 |
Hl7 Error Code |
207^Application error^messageErrorCondition |
|
ERR - 4 |
Severity |
Error, Fatal Error, Information, Warning |
|
ERR - 5 |
Application Error Code (CWE) |
Sélection d’un code erreur dans la table HL70533 (nom symbolique : applicationErrorCode) à Utiliser les codes et libellés de Codes erreurs de l’accusé métier de lecture/traitement de la demande. Code^libellé du code^ applicationErrorCondition |
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é ».
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.