Volet Transmission au LPS de documents CDA provenant d'un courriel MSSanté
1.1.2 - trial-implementation
Volet Transmission au LPS de documents CDA provenant d'un courriel MSSanté
1.1.2 - trial-implementation
This page is part of the [CI-SIS]Volet transmission au LPS d'un document CDA provenant d'un courriel MSSanté (v1.1.2: Publications) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
Cette section décrit les détails techniques nécessaires à la mise en œuvre de la transaction permettant la transmission d’une demande de traitement (transmission initiale/remplacement/suppression) d’un document clinique au format CDA-R2 (Clinical Document Architecture Release 2) entre une Plateforme d’Intermédiation (PFI) et le logiciel métier du professionnel de santé, après détection d’un courriel reçu sur une Boîte Aux Lettres (BAL) MSSanté de l’établissement.
Le périmètre des spécifications s’applique à toute demande de transmission initiale/remplacement/suppression d’un document CDA-R2, provenant d’un courriel MSSanté réceptionné dans une BAL applicative et traité par la PFI de l’établissement hospitalier, accompagnée des informations du courriel et des métadonnées MSSanté associées au document. Ces informations sont encodées dans un flux HL7v2.6 MDM.
Les spécifications couvrent également l’accusé de réception du message HL7 MDM.
L’accusé de réception du message HL7 MDM rend compte de la bonne ou mauvaise intégration du message et des informations portées par le message au niveau de l’acteur CONSOMMATEUR.
|
Acteur |
GESTIONNAIRE |
|---|---|
|
Rôle |
- Le GESTIONNAIRE extrait les informations de l'archive IHE_XDM (pièce jointe du mail), analyse ces informations et construit le message HL7 MDM correspondant pour l'envoyer au CONSOMMATEUR. - Le GESTIONNAIRE réceptionne l'accusé de réception et d'intégration du message HL7 MDM, gère cet accusé et construit un accusé de lecture MSSanté (MDN-Message Disposition Notification) en fonction du statut retourné par l'acquittement du message HL7 MDM. |
|
Acteur |
CONSOMMATEUR |
|
Rôle |
- Le CONSOMMATEUR reçoit la demande du GESTIONNAIRE (transmission initiale/remplacement/suppression d'un document) sous la forme d'un message HL7 MDM, intègre si possible dans sa base de données les informations portées par le message HL7 MDM et renvoie vers le GESTIONNAIRE l'accusé de réception du message HL7 MDM. |
HL7 v2.6 : Chapitre 9, message MDM (Medical Document Management) (1),
Extension française du profil IHE PAM : PAM.fr, version 2.11
Les types de données utilisés (2) doivent se conformer 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
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.
(1) : Les messages décrits au niveau de cette transaction implémentent 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 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.
Après réception d’un courriel détecté dans une BAL applicative MSSanté, la PFI ouvre l’archive IHE_XDM contenant des documents médicaux et les transmets individuellement au LPS consommateur en utilisant un message HL7v2.6 de type MDM.
Ensuite, le LPS accuse réception de cette demande de traitement sur le document avec un message HL7v2.6 de type ACK.
|
Flux métiers |
Type de message HL7v2.6 |
|---|---|
|
TransmissionDocuments |
Transmission initiale d'un document : L'évènement utilisé sera le T02 « Original document notification » -> -> OBX-11 = F (Final results; Can only be changed with a corrected result.) [HL7 Tables 0085] |
|
Suppression d'un document : L'évènement utilisé sera le T04 « Document status change notification and content » -> -> OBX-11 = D (Deletes the OBX record) [HL7 Tables 0085] |
|
|
Remplacement d'un document : L'évènement utilisé sera le T10 « Document replacement notification and content » -> -> OBX-11 = C (Record coming over is a correction and thus replaces a final result) [HL7 Tables 0085] |
|
|
ReponseTransmissionDocuments |
ACK : Acquittement du message HL7 MDM |
La gestion de l’accusé de lecture MSSanté (MDN-Message Disposition Notification) va dépendre de l’organisation choisie par l’établissement pour traiter les courriels réceptionnés.
Ce flux d’accusé de lecture MSSanté (courriel MDN) rend compte de la lecture du courriel par le destinataire lorsque ce courriel est traité de façon manuelle. Dans le cas d’un traitement automatique du courriel par la PFI de l’établissement destinataire, ce flux d’accusé de lecture rend compte de la réalisation de la demande de traitement sur le document contenu dans le courriel par le logiciel métier associé à la BAL destinatrice du courriel.
Dans le cas où le courriel entrant, réceptionné par une BAL organisationnelle, est transféré vers la BAL applicative associée pour traitement automatique de la demande, le courriel MDN généré par le GESTIONNAIRE (PFI) et envoyé à la BAL organisationnelle demandeuse est indispensable pour avertir l’utilisateur du succès ou de l’échec de la demande de traitement par le CONSOMMATEUR.
La structure du MDN (Message Disposition Notification) est précisée ici.
Le profil du message MDM est le suivant :
|
Segment |
Meaning |
Usage |
Card. |
§ HL7 |
|---|---|---|---|---|
|
MSH |
Message Header |
R |
[1..1] |
2 |
|
[{SFT}] |
Software Segment |
O |
[0..*] |
2 |
|
[UAC] |
User Authentication Credentials |
O |
[0..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 service 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, informations sur le courriel, métadonnées sur le document) |
R |
[1..*] |
|
|
OBX |
Observation/Result |
R |
[1..1] |
9 |
|
[{PRT}] |
Participation : Expéditeur, destinataire(s) MSS et adresse mail sur laquelle le destinataire peut répondre. Segment PRT pré-adopté de la version 2.9 |
R |
[1..*] |
7 (v2.9) |
|
[{NTE}] |
Notes and comments |
O |
[0..*] |
2 |
|
} |
---OBXNTE end |
|
|
|
Le message HL7 MDM ne peut transmettre qu’un seul document médical.
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 les informations de l’expéditeur (requis), le destinataire MSSanté (requis si connu) et, le cas échéant, l’adresse mail de réponse (contraintes décrites au paragraphe dédié).
Le deuxième groupe véhicule, dans un segment OBX, les informations du courriel MSSanté dont a été extrait le document.
Les groupes OBXNTE suivants (requis et répétables) véhiculent les métadonnées spécifiques à l’envoi par la MSSanté.
Dans le message MDM, le document est accompagné de quelques métadonnées renseignées 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.
|
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 MDM^T02^MDM_T02 MDM^T10^MDM_T02 MDM^T04^MDM_T02 |
MSG |
R
|
|
MSH-10 |
Identifiant du message |
ST |
R |
|
MSH-11 |
Processing Id P : en production T : message de test D : environnement de debug |
PT |
R |
|
MSH-12 |
Version du standard 2.6 |
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 (1.1) MSH-21.2 : Namespace Id CISIS_CDA_HL7_LPS |
EI |
R |
Entête MSH d’un message MDM émis par le GESTIONNAIRE :
MSH|^~\&|PFI|CHU_X|DPI|CHU_X|202310030830||MDM^T02^MDM^T02^MDM_T02|12345|P|2.6|||||FRA|8859/15|||1.1^ CISIS_CDA_HL7_LPS
Le message HL7 MDM est centré sur un seul patient. Les informations concernant le patient sont décrites par le segment requis PID. Le segment PV1, requis dans le standard, 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 ».
|
Champ |
Contenu |
Type donnée |
Caractère optionnel/obligatoire |
|---|---|---|---|
|
PID-3 |
Identifiants du patient |
CX |
R |
|
PID-5 |
Nom du patient |
XPN |
R |
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 : N (Not applicable) |
IS |
R |
|
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 |
|
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 (lien vers la TRE) en fonction de l'appartenance du code à l'un des trois systèmes de codage |
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 exemple : 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é
Le message HL7 MDM contient un premier groupe OBXNTE composé :
d’un segment OBX contenant un document encodé en Base64 dont le type MIME est précisé en OBX-5.2, il peut s’agir d’un document CDA-R2 Niv1 ou d’un CDA-R2 Niv3,
d’un segment PRT requis, pré-adopté de HL7v2.9, véhiculant les informations sur l’expéditeur du courriel MSSanté,
d’un segment PRT requis si connu et répétable, pré-adopté de HL7v2.9, véhiculant les informations sur le(s) destinataire(s) du courriel MSSanté,
d’un segment PRT optionnel et répétable, pré-adopté de HL7v2.9, l’(es) adresse(s) mail sur la(les)quelle(s) le(s) destinataire(s) peut ou peuvent 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). Seuls les segments et les champs indiqués dans les tableaux suivants sont à renseigner dans le message MDM :
|
Composition du groupe OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|---|---|---|
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
Contient un document au format CDA-R2 |
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment 1 |
|
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) |
|
> OBX-3.2 : |
Libellé du Document |
|
|
>OBX-3.3 |
Système de codage dont est issu le code |
LN ou TRE_A05 (lien vers la TRE) 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 |
text |
|
> OBX-5.3 |
Data Subtype |
Le champ prend la valeur XML. |
|
> OBX-5.4 |
Encoding |
Base64 |
|
> OBX-5.5 |
Data |
Intégrer le document CDA |
|
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 (Requis) |
Participation Information Expéditeur |
Ce segment contient les informations de l'expéditeur à l'origine de la demande de traitement sur le document. |
|
PRT-2 |
Action Code |
UC (Unchanged) |
|
PRT-4 |
Participation |
|
|
> PRT-4.1 |
Code |
SB |
|
> PRT-4.2 |
Libellé du code |
Send by |
|
> PRT-4.3 |
Name Of Coding System |
participation |
|
PRT-5 (Requis si connu) |
Participation Person |
Ce champ est requis si connu si l'expéditeur est un professionnel de santé (Note 1). |
|
> PRT-5.1 (Requis si connu) |
ID number |
Identifiant du professionnel de santé expéditeur |
|
> PRT-5.2 (Requis si connu) |
Family Name |
Nom d'exercice de l'expéditeur |
|
> PRT-5.3 (Requis si connu) |
Given Name |
Prénom d'exercice de l'expéditeur |
|
> PRT-5.9 (Requis si connu) |
Assigning Authority |
Autorité d'affectation de l'identifiant de l'expéditeur |
|
> PRT-5.13 (Conditionnel) |
Identifier Type Code |
Le type d'identifiant (issu de la Table 0203 - Interop'Santé présent dan le document "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") est requis lorsque le PRT-5.1 est renseigné |
|
PRT-8 (Requis si connu) |
Participation Organization |
Ce champ est requis si connu si l'expéditeur est une organisation (Note 1). |
|
> PRT-8.1 (Requis si connu) |
OrganizationName |
Nom de l'organisation |
|
> PRT-8.6 (Requis si connu) |
Assigning Authority |
Autorité d'affectation de l'identifiant de l'organisation expéditrice du document |
|
> PRT-8.7 (Requis si connu) |
Identifier Type Code |
Type d'identifiant (issu de la Table 0203 - Interop'Santé présent dan le document "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") |
|
> PRT-8.10 (Requis si connu) |
Organization number |
Identifiant de l'organisation expéditrice du document |
|
PRT-10 (Conditionnel) |
Participation Device |
Ce champ est requis si l'expéditeur est une application. |
|
> PRT-10.1 |
Entity Identifier |
Identifiant de l'application |
|
PRT-15 (Requis) |
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 l'expéditeur |
|
Segment PRT (Requis si connu) |
Participation Information Destinataire |
Contient les informations du destinataire initial du courriel MSSanté. Cf (Note 1), (Note 2). |
|
PRT-2 |
Action Code |
UC (Unchanged) |
|
PRT-4 |
Participation |
|
|
> PRT-4.1 |
Code |
RCT |
|
> PRT-4.2 |
Libellé du code |
Result Copies To |
|
> PRT-4.3 |
Name Of Coding System |
participation |
|
PRT-5 (Requis si connu) |
Participation Person |
Ce champ est requis si connu si le destinataire initial du courriel est un PS |
|
> PRT-5.1 (Requis si connu) |
ID number |
Identifiant du destinataire |
|
> PRT-5.2 (Requis si connu) |
Family Name |
Nom d'exercice du destinataire |
|
> PRT-5.3 (Requis si connu) |
Given Name |
Prénom d'exercice du destinataire |
|
> PRT-5.9 (Requis si connu) |
Assigning Authority |
Autorité d'affectation de l'identifiant du destinataire |
|
> PRT-5.13 (Conditionnel) |
Identifier Type Code |
Le type d'identifiant (issu de la Table 0203 - Interop'Santé présent dan le document "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") est requis lorsque le PRT-5.1 est renseigné |
|
PRT-8 (Requis si connu) |
Participation Organization |
Ce champ permet de faciliter le traitement du document dans la bonne organisation au niveau du système CONSOMMATEUR (service, UF, pôle…). Cf (Note 3). |
|
> PRT-8.1 (Requis si connu) |
OrganizationName |
Nom du destinataire |
|
> PRT-8.6 (Requis si connu) |
Assigning Authority |
Autorité d'affectation de l'identifiant du destinataire |
|
> PRT-8.7 (Requis si connu) |
Identifier Type Code |
Type d'identifiant (issu de la Table 0203 - Interop'Santé présent dan le document "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") |
|
> PRT-8.10 (Requis si connu) |
Organization number |
Identifiant du destinataire |
|
PRT-15 (Requis) |
Participant Telecommunication Address |
|
|
> PRT-15.3 |
Telecommunication Equipment Type |
X.400 (X.400 email address) |
|
> PRT-15.4 |
Communication Address |
Intégrer l'adresse MSSanté du destinataire |
|
Segment PRT (segment optionnel) |
Participation Information adresse de réponse |
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 |
|
|
> PRT-4.1 |
Code |
REPLY |
|
> PRT-4.2 |
Libellé du code |
Reply To |
|
> PRT-4.3 |
Name Of Coding System |
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 |
Note 1 : le renseignement des informations concernant l’identification de l’expéditeur/destinataire est conditionné à la capacité du GESTIONNAIRE à interroger l’annuaire de l’établissement.
Note 2 : en cas de transfert du courriel original au niveau de l’établissement destinataire, il n’est pas certain que l’acteur GESTIONNAIRE puisse récupérer l’information concernant le destinataire initial du courriel. Cette information peut être utilisée pour notifier au niveau du système CONSOMMATEUR, le PS ou le service clinique concerné par le courriel (organisation) du résultat du traitement réalisé sur le document par le système CONSOMMATEUR.
Note 3 : dans la configuration où le GESTIONNAIRE est en capacité de maintenir une table de correspondance entre une BAL et une organisation correspondante (service clinique, UF, pôle…), le champ PRT-8 permet de préciser l’organisation de l’établissement concerné par la demande de traitement sur le document au niveau du CONSOMMATEUR. Dans le cas où le GESTIONNAIRE n’est pas en capacité de maintenir cette table de correspondance, le système CONSOMMATEUR peut prévoir un paramétrage pour associer une organisation de l’établissement (service clinique, UF, pôle…) à une BAL afin de réaliser le traitement sur le document dans la bonne organisation.
|
Composition du groupe OBXNTE : Usage = Required / Cardinalité = [1..1] |
||
|---|---|---|
|
Elément requis : |
Description : |
Valeur : |
|
Segment OBX |
Observation/Result |
Contient les informations du courriel MSSanté dont a été extrait le document |
|
OBX-1 |
Set Id - Obx |
Numéro de séquence du segment 2 |
|
OBX-2 |
Value Type |
ED (Encapsulated Data) |
|
OBX-3 |
Observation Identifier |
|
|
> OBX-3.1 : |
Identifier |
Identifiant unique du courriel correspondant à l'élément Message-ID de l'entête du courriel MSSanté |
|
> OBX-3.2 : |
Text |
Objet du courriel |
|
OBX-4 |
Observation Sub-id |
|
|
OBX-5 |
Observation Value |
Contenu du courriel codé en base 64
|
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
Cette section présente uniquement les métadonnées de restriction indispensables aux échanges avec la MSSanté. Ces groupes sont conformes à ceux définis dans le volet « Transmission de documents CDA en HL7v2 » version 2.1
Les métadonnées peuvent ê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 requises et doivent apparaître dans le message MDM dans l’ordre présenté ci-dessous.
Pour l’ensemble des OBX listés dans cette section, le champ OBX-3 prend ses valeurs dans la table « MetaDMP/MSS ». Le champ OBX-11 étant requis par le standard HL7v2, la valeur de ce champ est arbitrairement fixée à « F ».
Document Masqué aux professionnels de Santé
Cet OBX permet au Consommateur de vérifier que le document n’est pas 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 3 |
|
OBX-2 |
Value Type |
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 : · N (No) à MASQUE_PS non Actif · Y (Yes) à MASQUE_PS Actif |
|
> OBX-5.3 |
Name Of Coding System |
expandedYes-NoIndicator |
|
OBX-11 |
Observation Result Status |
Valeur fixée à « F » |
Document Non visible par le patient
Cet OBX permet d’informer le Consommateur que le document est masqué ou non 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 4 |
|
OBX-2 |
Value Type |
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 » |
Document Non visible par les représentants légaux du patient
Cet OBX permet d’informer le Consommateur que le document est masqué ou non 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 5 |
|
OBX-2 |
Value Type |
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 » |
Modification Confidentiality Code
Cet OBX permet d’informer le Consommateur que la transaction porte une modification du CONFIDENTIALITY CODE indiquant une mise à jour de la métadonnée de mise en visibilité du document au patients et/ou aux 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 6 |
|
OBX-2 |
Value Type |
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 » |
Un exemple est disponible ici.
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 |
O |
[0..1] |
2 |
|
MSA |
Message Acknowledgement |
R |
[1..1] |
2 |
|
[{ERR}] |
Error |
C |
[0..*] |
2 |
Après réception du message MDM, le LPS (DPI ou RIS dans le contexte SEGUR vague 2) va acquitter le message. Ci-dessous la structure du message ACK :
Ces segments doivent être conformes au standard HL7v2.6.
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 |
Facility 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 |
Facility destinatrice 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 champ MSH.9 « Message type » prend la valeur : ACK^T02^ACK ou ACK^T04^ACK ou ACK^T10^ACK selon l’évènement du message initial.
|
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 P : en production T : message de test D : environnement de debug |
PT |
R |
|
MSH-12 |
Version du standard 2.6 pour MDM |
VID |
R |
|
MSH-17 |
FRA |
ID |
R |
|
MSH-18 |
Jeux de caractères, valeurs possibles : UNICODE UTF-8 ou 8859/15 |
ID |
R |
Le segment MSA contient à minima les champs suivants :
|
Champ requis |
Contenu |
|---|---|
|
MSA.1 - Acknowledgment Code |
Code d'acquittement du message : · 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 HL7 dans le cas où le champ MSA-1 prend la valeur AE (Application error).
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(Note 1) (Note 2) |
|
ERR-4 |
Sévérité de l'erreur dont les valeurs sont à prendre dans la table HL7 0516 (nom symbolique : errorSeverity) |
ID |
R |
|
ERR-5 |
Code erreur du traitement applicatif du message HL7 dont les valeurs sont à prendre dans la table user-defined 0533 (nom symbolique : applicationErrorCode) |
CWE |
C(Note 1) (Note 2) |
(Note 1) : les valeurs possibles pour les champs ERR-3 et ERR-5 sont listées dans les tables messageErrorCondition et applicationErrorCondition précisées ici.
Note (2) : dans le cas où le rejet du message HL7 MDM est dû à un problème applicatif au niveau du CONSOMMATEUR, le champ ERR-3 sera renseigné avec la valeur « 207 » (Application error) et le champ ERR-5 sera renseigné avec une valeur comprise dans la table applicationErrorCode. Dans le cas où le message MDM est rejeté par le système CONSOMMATEUR pour une raison technique, le champ ERR-3 sera renseigné avec une valeur comprise dans la table messageErrorCondition et le champ ERR-5 ne sera pas renseigné.
Entête MSH d’un message MDM émis par le GESTIONNAIRE vers le CONSOMMATEUR :
MSH|^~\&|PFI|CHU_X|DPI|CHU_X|202310030830||MDM^T02^MDM_T02|12345|P|2.6|||||FRA|8859/15|||1.1^ CISIS_CDA_HL7_LPS
Un acquittement positif retourné par le CONSOMMATEUR :
MSH|^~\&|DPI|CHU_X|PFI|CHU_X|202310030831||ACK^T02^ACK|12346|P|2.6|||AL|AL|FRA|8859/15
MSA|AA|12345
Un acquittement négatif retourné par le CONSOMMATEUR : version d’HL7 inconnue
MSH|^~\&|DPI|CHU_X|PFI|CHU_X|202310030831||ACK^T02^ACK|12347|P|2.6|||AL|AL|FRA|8859/15
MSA|AE|12345
ERR||MSH^1^12|203^Unsupported version id^messageErrorCondition|E
Un acquittement négatif retourné par le CONSOMMATEUR : patient inconnu du DPI (erreur applicative)
MSH|^~\&|DPI|CHU_X|PFI|CHU_X|202310030831||ACK^T02^ACK|12347|P|2.6|||AL|AL|FRA|8859/15
MSA|AE|12345
ERR||PID^1^3|207^Application error^messageErrorCondition| E|902^Identifiant de patient inconnu^applicationErrorCode