|
+ Acteur : + |
+
+ Description : + |
+
|
+ GESTIONNAIRE + |
+
+ Le GESTIONNAIRE réceptionne et transmet au système CONSOMMATEUR les demandes de transmission initiale/remplacement/suppression de document(s) provenant d’un courriel. + |
+
|
+ CONSOMMATEUR + |
+
+ Le CONSOMMATEUR réceptionne et gère les demandes de transmission initiale/remplacement/suppression de document(s) issues d’un courriel, provenant du système GESTIONNAIRE et renvoie l’accusé de traitement de la demande vers le GESTIONNAIRE. + |
+
|
+ Acteur : + |
+
+ Systèmes concernés : + |
+
|
+ GESTIONNAIRE + |
+
+ - Les Plateformes d’Intermédiation (PFI) qui assurent la transmission de document(s) cliniques provenant d’un courriel MSSanté vers un CONSOMMATEUR (le LPS destinataire). + |
+
|
+ CONSOMMATEUR + |
+
+ - Tout logiciel métier (LPS) du SIH qui récupère et gère la demande de traitement du document transmis par le GESTIONNAIRE. +- Dans le contexte du SEGUR vague 2, les applications consommatrices de ces documents sont limitées au dossier patient informatisé (DPI) et au système de gestion de radiologie (RIS). + |
+
+ + +Le tableau ci-dessous représente l’ensemble des acteurs directement impliqués dans ce volet ainsi que les transactions entre ces acteurs. + +Pour être en conformité avec ce volet, chaque acteur doit supporter les transactions obligatoires (R-Required) et peut supporter les transactions optionnelles (O-Optional). + +
|
+ Acteur + |
+
+ Transaction + |
+
+ Caractère requis/optionnel + |
+
|
+ GESTIONNAIRE + |
+
+ Flux6 HL7-MDM en émission : Demande de transmission/remplacement/suppression d’un document CDA + |
+
+ R + |
+
|
+ CONSOMMATEUR + |
+
+ Flux6 HL7-MDM en réception : Demande de transmission/remplacement/suppression d’un document CDA + |
+
+ R + |
+
|
+ Acteur de ce volet + |
+
+ Groupé avec un autre acteur + |
+
+ Référence + |
+
|
+ GESTIONNAIRE + |
+
+ Système cible (Portable Media Importer) XDM + |
++ + | +
|
+ CONSOMMATEUR + |
+
+ Content Consumer (TF PCC[1]) + |
+
+ TF Patient Care Coordination – Appendix A: Actors definition + |
+
+
[1] PCC : Patient Care Coordination – Appendix A : Actors definition
+ +L'acteur GESTIONNAIRE est groupé avec : + +- L'acteur Système cible du [volet d'Echange de documents de santé](https://esante.gouv.fr/sites/default/files/media_entity/documents/ci-sis_service_volet-echange-documents-sante_v1.8.pdf), pour permettre à la PFI de réceptionner l'archive IHE_XDM inclue dans le courriel reçu de l'extérieur, + +L'acteur CONSOMMATEUR est groupé avec : + +- L'acteur Content Consumer définit dans le [Technical Framework PCC d'IHE](https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol1.pdf), permettant au CONSOMMATEUR de visualiser et d'importer tout ou parties du document CDA. diff --git a/input/pagecontent/autres_ressources.md b/input/pagecontent/autres_ressources.md index ba4b6695..971d184c 100644 --- a/input/pagecontent/autres_ressources.md +++ b/input/pagecontent/autres_ressources.md @@ -1,3 +1,2 @@ * [Téléchargements et usage](./downloads.html) -* [Spécifications FHIR]({{site.data.fhir.path}}index.html) * [Site de l'ANS](https://esante.gouv.fr/) diff --git a/input/pagecontent/cas-usage.md b/input/pagecontent/cas-usage.md new file mode 100644 index 00000000..6af99577 --- /dev/null +++ b/input/pagecontent/cas-usage.md @@ -0,0 +1,126 @@ +Cette section décrit, **à titre d’exemple et de façon non exhaustive**, un ensemble de cas d’usage. Pour une meilleure compréhension du lecteur, ces cas d’usage couvrent les échanges entre la PFI et le logiciel métier consommateur, mais également les échanges en amont de la PFI de l’établissement destinataire (et donc au-delà du périmètre du présent volet). + +### Réception et traitement par la PFI de l’établissement hospitalier d’un document clinique provenant d’un médecin traitant + +**Cas d’usage :** le médecin traitant du patient, le Dr Adam Hoda, envoi un compte rendu au médecin hospitalier qui prend en charge son patient. + +Le patient est connu de l’établissement hospitalier et est pris en charge par le Dr Dupont qui exerce à l’hôpital-A (jean.dupont@hopital-A.mssante.fr). Le Dr Adam Hoda valide le compte rendu et renseigne au travers de l’IHM de son logiciel métier les métadonnées de masquage aux PS et de visibilité au patient et à ses représentants légaux attachées au compte rendu. Il précise également qu’il souhaite envoyer ce compte rendu au Dr Dupont, et sélectionne à partir de son annuaire l’adresse mail de contact de ce médecin. Avant de valider sa demande, le Dr Hoda peut préciser s’il souhaite recevoir un accusé de réception MSSanté et un accusé de lecture (prise en compte de sa demande par le destinataire). + +La demande du Dr Adam est détectée et interprétée par la PFI de l’établissement hospitalier. La PFI analyse le contenu du courriel et transmet au destinataire la demande de traitement à réaliser sur le document contenu dans ce courriel. +Si demandé initialement, l’accusé de réception du courriel est renvoyé vers la BAL du Dr Adam Hoda suite à la réception du mail sur le serveur de messagerie de l’établissement hospitalier. + + +### Réception d’un compte rendu de biologie par un établissement hospitalier + +**Cas d’usage :** un établissement hospitalier (le CH Martin) réceptionne, via MSSanté, un compte rendu de laboratoire concernant un patient pris en charge dans l’établissement, provenant d’un laboratoire d’analyses externe au CH Martin. Le laboratoire d’analyse ainsi que le CH Martin sont dotés d’une PFI. Ce cas d’usage nécessite un accord de partenariat entre les deux structures permettant de rendre possible l’échange MSSanté au travers des BAL applicatives. + +#### Description du cas nominal + +Le médecin biologiste du laboratoire d’analyses valide le compte rendu de biologie via son système de gestion de laboratoire (SGL) et précise les métadonnées de masquage du document aux PS et de visibilité au patient et à ses représentants légaux. Ces métadonnées peuvent également, selon les organisations mises en place, être paramétrées en fonction du type d’analyse réalisé. Le SGL est également paramétré pour prendre en compte les souhaits du médecin biologiste concernant la réception des accusés métier de réception DMP, de réception MSSanté par le serveur de messagerie de l’établissement CH Martin, et l’accusé métier de lecture/traitement du courriel MSSanté et du(des) document(s) CDA contenu(s) dans la pièce jointe IHE_XDM.zip. + +A la validation du compte rendu de biologie par le médecin biologiste, le SGL envoie la demande d’intégration du CR de biologie dans l’application destinatrice. + +La PFI du laboratoire de biologie réceptionne la demande, construit le courriel ainsi que la pièce jointe IHE_XDM.zip et l’envoi à une BAL applicative de l’établissement CH Martin dédiée ou non à la réception des CR de biologie de laboratoire partenaire. La PFI du CH Martin détecte l’arrivée du courriel, analyse son contenu et construit la demande d’intégration du CR de biologie dans le logiciel métier du destinataire (DPI). + +Le DPI intègre le document à partir des informations disponibles dans la demande d’intégration et dans l’entête du document CDA, et renvoie un accusé de réception de la demande à la PFI. + +Dans le contexte SEGUR vague 2, la PFI doit pouvoir générer un courriel MDN (Message Disposition Notification) à destination de la BAL du SGL contenant le statut de l’intégration. + +La structure du MDN est décrite [ici](struct-msg-mdn.html). + + +++ ++ Point d'attention : dans le contexte du SEGUR vague 2, la PFI doit pouvoir générer un courriel MDN (Message Disposition Notification) à destination de la BAL du SGL contenant le statut de l'intégration. +
+
+ +La Figure 2 illustre les échanges de bout en bout relatifs à une demande de transmission du compte rendu du SGL d’un laboratoire extérieur vers le DPI d’un établissement partenaire. + +Le diagramme serait identique dans le cas d’une demande de remplacement ou de suppression du compte rendu. + +#### Description du cas en erreur + +Le CR de biologie n’est pas intégré dans le logiciel métier du destinataire pour une raison technique (par exemple, non-conformité de la transaction de demande d’intégration du document) ou pour une raison fonctionnelle (par exemple, le patient n’est pas connu du logiciel destinataire). + +Dans le contexte du SEGUR, la PFI doit pouvoir envoyer un accusé métier de lecture MSSanté négatif vers la BAL de l’expéditeur dans le cas où le médecin biologiste a exprimé le souhait de recevoir cet accusé de lecture MSSanté. + +Sur la figure suivante, seule la partie basse de la figure précédente est représentée. Les séquences relatives à l’accusé de réception MSSanté sont identiques. + + +
+ +La Figure 3 illustre la gestion des erreurs par l’établissement destinataire dans le cas d’une demande de transmission du compte rendu du SGL vers le DPI. + +Le diagramme serait identique dans le cas d’une demande de remplacement ou de suppression du compte rendu. + +### Transmission d’un document clinique d’un patient d’un établissement hospitalier vers un autre établissement hospitalier + +**Cas d’usage :** Le Dr Jean Dupont exerce dans le service X de l’établissement-A. Il souhaite transférer un de ses patients dans le service Y de l’établissement B. Il demande à la secrétaire médicale du service X d’envoyer le compte rendu d’hospitalisation de son patient à l’équipe de soins du service Y de l’établissement-B. + +La secrétaire médicale du service X de l’établissement-A envoie un courriel à la BAL du service Y de l’établissement-B. Les deux établissements sont dotés d’une PFI. + +#### Description du cas nominal + +Dans ce cas d’usage, le compte rendu d’hospitalisation est envoyé par MSSanté sur la BAL organisationnelle du service Y. La secrétaire de l’établissement-B consulte sa BAL organisationnelle. Si la secrétaire souhaite intégrer automatiquement les documents de la pièce jointe IHE_XDM.zip dans le DPI, elle transfère manuellement les courriels vers la BAL applicative du service Y. Ces courriels sont ensuite détectés par la BAL applicative de la PFI de l’établissement-B qui les traitent, construit pour chaque courriel la demande d’intégration/remplacement/suppression du document et envoie cette demande au DPI du service Y. le document est intégré/remplacé/supprimé dans le DPI du service Y. + +La secrétaire médicale du service X de l’établissement-A sélectionne le compte rendu et sélectionne, à partir de l’annuaire de l’établissement, la BAL organisationnelle correspondant au service Y de l’établissement-B. elle précise également si elle souhaite recevoir en retour un accusé de réception MSSanté (réception par le serveur de messagerie de l’établissement-B) ainsi qu’un accusé de lecture MSSanté (selon les organisations, ce choix peut être réalisé par paramétrage). + +Cette demande d’envoi est traitée par la PFI de l’établissement-A qui réceptionne, analyse les éléments portés par la transaction émise à partir du DPI du service X et construit l’archive IHE_XDM conformément au volet Echange de documents de santé du CI_SIS en pièce jointe du courriel à destination du service Y de l’établissement-B. + +Le courriel envoyé par la BAL attachée à la PFI de l’hôpital-A est réceptionné par la BAL organisationnelle du service Y. Dans le cas d’usage décrit ci-dessous, la secrétaire du service Y de l’établissement-B prend connaissance des courriels non lus dans la BAL organisationnelle du service et transfert ces courriels vers la BAL applicative du service Y dans le cas où elle désire importer automatiquement les documents dans le DPI. Si un accusé de lecture a été demandé par l’expéditeur, celui-ci est alors renvoyé vers la BAL organisationnelle du service X de l’établissement- A. Des règles peuvent également être mises en place dans le serveur de messagerie de l’établissement-B pour transférer automatiquement les courriels avec une pièce jointe IHE_XDM.zip ou un objet qui commence par XDM/1.0/DDM vers la BAL applicative du service Y. + +Suite au transfert, la PFI de l’établissement-B détecte chaque courriel arrivé sur la BAL applicative du service Y. La PFI de l’hôpital-B extrait les informations du courriel ainsi que la demande d’intégration associée au document clinique et transmet ces éléments vers le DPI associé au service Y pour traitement de la demande d’intégration du document clinique dans le dossier du patient. La configuration d’une BAL applicative par service de l’établissement B permet au DPI de classer plus finement le document. + +Le DPI intègre le document à partir des informations qu’il reçoit et renvoie un accusé de réception à la PFI. + +Dans le contexte du SEGUR vague 2, la PFI doit pouvoir générer un courriel MDN (Message Disposition Notification) à destination de la BAL organisationnelle du service Y contenant le statut de l’intégration du document. En cas d’erreur, la secrétaire pourra envisager une intégration manuelle (voir le paragraphe suivant). + +La structure du MDN est précisée [ici](struct-msg-mdn.html). + +
++ + ++ Point d'attention : ce cas d’usage décrit un mécanisme de traitement d’un courriel réceptionné sur une BAL organisationnelle. Ce mécanisme pourrait être identique pour un courriel réceptionné sur une BAL personnelle, sous réserve de s’assurer et de respecter les exigences réglementaires relatives au transfert d’un courriel personnel dans un contexte professionnel. +
+
+ Ce cas d’usage nécessite de définir une BAL organisationnelle ainsi qu’une BAL applicative associée pour chaque service clinique de l’établissement B. La PFI ou le DPI peuvent prévoir un paramétrage pour associer un service clinique de l’établissement à une BAL afin de classer les documents dans le bon service. +
+
+ + +La Figure 4 illustre les échanges de bout en bout relatifs à une demande de transmission du compte rendu du SGL vers le DPI. +Le diagramme serait identique dans le cas d’une demande de remplacement ou de suppression du compte rendu. + +#### Description du cas d'usage en erreur + +La cinématique des échanges est la même que précédemment mais le compte rendu d’hospitalisation n’est pas intégré dans le DPI du service Y en raison de l’inexistence du patient dans le DPI. + +La figure ci-dessous représente uniquement la partie basse de la figure précédente, à partir de la lecture par la PFI de la BAL applicative de l’établissement-B. + + +
+ + + +La Figure 5 illustre la gestion des erreurs par l’établissement destinataire dans le cas d’une demande de transmission d’un compte rendu vers le DPI d’un autre établissement. + +Le diagramme serait identique dans le cas d’une demande de remplacement ou de suppression du compte rendu. diff --git a/input/pagecontent/change-log.md b/input/pagecontent/change-log.md new file mode 100644 index 00000000..b71dbb05 --- /dev/null +++ b/input/pagecontent/change-log.md @@ -0,0 +1,668 @@ +
|
+
+ Version |
+
+ Rédigé par |
+
+ Vérifié par |
+
+ Validé par |
+ |||
|
+
+ 1.0 |
+
+ Kereval |
+
+ Le 13/02/2023 |
+
+ ANS |
+
+ Le 19/02/2023 |
+
+ ANS |
+
+ Le 26/04/2023 |
+
|
+
+ Motif et nature de la modification : Première version |
+ ||||||
|
+
+ 1.1 |
+
+ ANS |
+
+ Le 24/10/2023 |
+
+ ANS |
+
+ |
+
+ ANS |
+
+ |
+
|
+
+ ·
+ Ajout
+ de la partie Avant-propos et des questions ouvertes ·
+ Le
+ volet est scindé en 2 parties : Etude fonctionnelle et Etude technique ·
+ Section
+ 1 : suppression de toutes références au choix technique (HL7) ·
+ Ajout
+ de l’étude fonctionnelle o
+ Section
+ 2 : Cas d’usage o
+ Section
+ 3 : Organisation métier o
+ Section
+ 4 : Acteurs et Transactions o
+ Section
+ 5 : cas d’usage o
+ Section
+ 6 : Définition des processus collaboratifs o
+ Section
+ 7 : Identification des flux. ·
+ Etude
+ technique o
+ Section
+ 7 : Périmètre. §
+ Précision
+ concernant l’accusé de lecture proposé à titre expérimental à retours des
+ éditeurs attendus. o
+ Section
+ 8 : ajout du rôle des acteurs o
+ Section
+ 9 : Standards §
+ Référence
+ la version 1.7.4 des « 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 » qui intègre l’agrandissement du champ EI-1 du type de données
+ EI (passage de EI-1 à 199). §
+ Ajout
+ de la contrainte sur les types de données CE et CWE pré adoptée de la
+ version 2.7 d’HL7 : nécessité de citer le code et le codeSystem
+ dont est issu ce code. o
+ Section
+ 11 : Interactions entre les acteurs, précisions apportées sur le schéma o
+ Section
+ 12.1.1 : ajout du profil de message MDM o
+ Section
+ 12.1.2 : description fonctionnelle. §
+ Préciser
+ la cardinalités sur les métadonnées [1..*] §
+ 1°
+ OBXNTE : supprimer la référence au CDAr2 Niv1 (MDM contient un CDA Niv1
+ ou Niv3) o
+ Section
+ 12.2.1 : ajout des contraintes sur les éléments de contrôle MSH, MSA,
+ ERR o
+ Section
+ 12.2.2 : éléments concernant le patient PID, PV1 o
+ Section
+ 12.2.3 : Ajout de la description OCR o
+ Section
+ 12.2.4 : Ajout de la description du segment OBR o
+ Section
+ 12.2.5 : Ajout de la description du segment TXA o
+ Section
+ 12.2.6 : Eléments concernant la demande de traitement sur le document §
+ 12.2.6.1 :
+ Le1° groupe de segment OBXNTE, les segments et les champs sont à renseigner
+ dans l’ordre indiqué. Ajout OBX-3.3 (contrainte CWE). Reprise des champs
+ concernant l’expéditeur et le destinataire. §
+ 12.2.6.3 :
+ groupe de segment portant les métadonnées. ·
+ Les
+ métadonnées doivent obligatoirement être renseignées et doivent apparaître
+ dans l’ordre indiqué. ·
+ Ajout
+ des lignes OBX-3.3 pour prendre en compte la contrainte sur le type de donnée
+ CWE (code+codeSystem dont est issu le code) §
+ Section
+ 12.2.7.3 : description ERR et exemples o
+ Section
+ 12.3.1 : description de l’évènement déclenchant de l’accusé de lecture
+ dans le contexte de ce volet. Proposition de considérer cet accusé de lecture
+ à titre expérimental à retours des éditeurs attendus. |
+ ||||||
|
+ 1.1 |
+
+ ANS |
+
+ Le 15/01/2024 |
+
+ ANS |
+
+ 19/01/2024 |
+
+ DNS |
+
+ 21/02/2024 |
+ |
|
+ Motif et nature de la modification : Prise en compte + des retours de concertation publique (27/11/2023 au 08/12/2023) et prise en + compte des modifications demandées par la DNS après clôture de la période de + concertation publique. +· + Rédaction des questions ouvertes +· + Section 1.1 : référence au volet + Transmission d’un document CDA provenant d’un courriel MSS de façon à mettre + en exergue le lien entre le présent volet et le volet référencé +· + Volume 1 – Etude fonctionnelle +o + Section 2 : complétude des cas d’usage DNS + et modifications en fonction des remarques de la DNS +o Section 4.1 :
+ liste des acteurs concernés. L’envoi par le CONSOMMATEUR et la réception par
+ le GESTIONNAIRE de l’accusé métier de lecture est supprimé (ZAM_Z03). Le
+ GESTIONNAIRE envoie simplement l’accusé du message HL7 MDM. Cet accusé HL7
+ rend compte du bon déroulement ou pas de la demande de traitement du document
+ au niveau du CONSOMMATEUR. o Section
+ 4.2 : Diagramme des acteurs/transactions. Suppression de l’accusé de
+ lecture MSS (ZAM_Z03) entre l’acteur CONSOMMATEUR et l’acteur GESTIONNAIRE o Section
+ 4.3 : regroupement de l’acteur CONSOMMATEUR avec l’acteur IHE Content
+ Consumer o Section
+ 5 : Processus collaboratifs. Amélioration de la rédaction des processus
+ et suppression de la notion d’accusé métier de lecture MSS (ZAM_Z03). ·
+ Volume 2 – Etude technique o Section
+ 7 : Périmètre de la transaction, suppression de l’accusé métier de
+ lecture MSS (ZAM_Z03). L’accusé de lecture (message MDN) est généré par le
+ GESTIONNAIRE sur réception de l’ack HL7 du message
+ MDM o Section
+ 9 : Choix des standards § Référencement de la
+ version 2.11 de la version française PAM.FR §
+ Référencement de la version 1.8 des types de données HL7 en France
+ (passage de la longueur du champ ED-1 de 16 caractères à 128 caractères o Section
+ 11 : modification de la figure 13. La PFI génère le message MDN
+ (MSSanté) à partir de l’ack du message HL7 MDM. Le
+ client de messagerie de la PFI envoi cet accusé de lecture (message MDN
+ MSSanté) à l’expéditeur. o Section 12.2.6.1 : OBXNTE
+ portant le document. Ajout d’une note au niveau du PRT destinataire o Section
+ 12.2.6.2 : Informations du courriel MSS. Le contenu du courriel est codé
+ en base 64 o Section
+ 12.2.6.3.5 : suppression de l’OBX permettant de préciser qu’un accusé
+ métier de lecture MSS est attendu par le GESTIONNAIRE o Section
+ 12.3 : suppression de la description du message ZAM^Z03^ZAM_Z01 · Annexe
+ 2 : ajout des codes erreurs 902, 903 et 904 demandés par la DNS dans la
+ table des codes erreurs de traitement du message MDM ·
+ Annexe
+ 3 : modification des exemples pour prendre en compte les corrections/modifications
+ de la version ·
+ Annexe 4 : structure du message MDN-Message
+ Disposition Notification (MSSanté) |
+ |||||||
|
+ 1.1 |
+
+ ANS |
+
+ Le 21/03/2024 |
+
+ ANS |
+
+ |
+
+ ANS |
+
+ |
+ |
|
+ Motif et nature de la modification : Prise en compte + des retours de concertation publique (04/03/2024 au 18/03/2024. +· + Ajout du paragraphe 1.2 Ce dont ne traite pas + ce volet +· + Volume 1 – Etude fonctionnelle +o Section
+ 2.1 : correction de l’@ MSS du médecin o Paragraphe
+ 2.3.1 : cas d’usage, transmission d’une BAL orga vers une BAL
+ orga : précisions apportées sur le point d’attention juste avant la
+ figure 4. o Section
+ 3.2 : les processus, précision apportée sur les métadonnées MSS sont
+ limitées au masquage des documents aux PS et à la mise en visibilité au
+ patient/rep légaux. ·
+ Volume 2 – Etude technique o Section
+ 7 : Modification de la rédaction du périmètre de la transaction :
+ « 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 » o Section
+ 12.1.1 : § Profil
+ du message HL7 MDM : passage du segment PRT à obligatoire et répétable [1..*] § Précision
+ dans le texte sous le profil o Section 12.2.5 :
+ précisions apportées sur le peuplement des champs TXA-12 et TXA-13 o Section
+ 12.2.6.1 : OBX portant le document § Précision
+ (Note 2) : il sera possible au GESTIONNAIRE ou au CONSOMMATEUR de
+ notifier le PS ou le service d’une demande de traitement sur un document à
+ condition que le GESTIONNAIRE ou le CONSOMMATEUR ait la capacité à maintenir
+ une correspondance entre les BAL perso/orga/app et les PS/services
+ correspondants. o Section 12.2.6.3.1 :
+ OBX masquage aux PS § Dans le
+ contexte de la réception d’un courriel par la PFI, la métadonnée MASQUE_PS
+ devrait prendre la valeur « N » (exigence formulée dans le volet « Transmission
+ de document(s) CDA en HL7v2 ». Dans le cas contraire, la PFI ne doit pas
+ envoyer le message HL7 MDM vers le DPI. o Section
+ 12.2.7.3.3 : message ACK du message MDM § Ajout du
+ champ ERR-5 qui permet de préciser l’erreur de traitement de la demande sur
+ le document au niveau du CONSOMMATEUR § Précisions
+ des noms symboliques pour les tables HL70357 et HL70516 § Précisions
+ apportées sur le renseignement des champs ERR-3 et ERR-5 · Annexe
+ 3 : la table initiale est scindée en deux tables : messageErrorCondition et applicationErrorCondition |
+ |||||||
| + | + | + | + | + | + | + | + |
+ + +Le périmètre de l'étude englobe les processus en bleu sur le diagramme de paquetage. \ No newline at end of file diff --git a/input/pagecontent/def-proc-collab.md b/input/pagecontent/def-proc-collab.md new file mode 100644 index 00000000..9faad668 --- /dev/null +++ b/input/pagecontent/def-proc-collab.md @@ -0,0 +1,178 @@ +### Processus collaboratif « Demande de transmission initiale de document(s) » + +
+ + +
|
+ Service Attendu + |
+
+ Le GESTIONNAIRE transmet au CONSOMMATEUR la demande d’intégration de(s) document(s) de santé d'un patient reçue sur la BAL MSSanté destinatrice. + |
+
|
+ Pré-Conditions + |
+
+ - Le patient est connu du CONSOMMATEUR. +- Le GESTIONNAIRE détecte qu'un courriel a été reçu sur la BAL avec en pièce jointe une archive XDM. +- Le GESTIONNAIRE dézippe l’archive XDM. Il vérifie qu’elle contient des documents de santé d’un patient au format CDA ainsi qu’un fichier de métadonnées. + |
+
|
+ Post-Conditions + |
+
+ Le GESTIONNAIRE trace les transmissions de document(s) + |
+
|
+ Contraintes fonctionnelles + |
+
+ La BAL du GESTIONNAIRE doit être en capacité de détecter les courriels entrants avec demande de traitement sur le(s) document(s) + |
+
|
+ Scénario Nominal + |
+
+ - Suite à la réception d’un courriel sur la BAL destinatrice, le GESTIONNAIRE transmet le document de santé de la pièce jointe au CONSOMMATEUR. +- Le CONSOMMATEUR traite la demande d’intégration du document. +- Le CONSOMMATEUR retourne au GESTIONNAIRE un accusé de réception de la demande d'intégration du document. + |
+
+ +Le processus « Demande de remplacement de document(s) » permet également de gérer la mise à jour des métadonnées associées au(x) document(s). + +Ainsi, dans le cas d’une demande de mise à jour des métadonnées de masquage/démasquage aux PS et de visibilité du document au patient, une nouvelle version de document est générée par l’initiateur du courriel. Cette nouvelle version vient remplacer la précédente au niveau du CONSOMMATEUR (application métier destinatrice). + +
|
+ Service Attendu + |
+
+ Le GESTIONNAIRE transmet au CONSOMMATEUR la demande de remplacement de(s) document(s) de santé d'un patient reçue sur la BAL MSSanté destinatrice. + |
+
|
+ Pré-Conditions + |
+
+ - Le patient est connu du CONSOMMATEUR. +- Le document doit être validé et identifié comme remplaçant un document précédemment envoyé par MSSanté. +- Le CONSOMMATEUR dispose de la dernière version du document original dans sa base de données. +- Le GESTIONNAIRE détecte qu'un courriel a été reçu sur la BAL avec en pièce jointe une archive IHE_XDM. +- Le GESTIONNAIRE dézippe l’archive XDM. Il vérifie qu’elle contient des documents de santé d’un patient au format CDA ainsi qu’un fichier de métadonnées et prend connaissance du traitement à effectuer sur le(s) document(s) + |
+
|
+ Post-Conditions + |
+
+ Le GESTIONNAIRE trace les transmissions de document(s) + |
+
|
+ Contraintes fonctionnelles + |
+
+ La BAL du GESTIONNAIRE doit être en capacité de détecter les courriels entrants avec demande de traitement sur le(s) document(s) + |
+
|
+ Scénario Nominal + |
+
+ - Suite à la réception du courriel sur la BAL destinatrice, le GESTIONNAIRE transmet la demande de remplacement de documents de santé de la pièce jointe au CONSOMMATEUR +- Le CONSOMMATEUR traite la demande de remplacement du document. +- Le CONSOMMATEUR retourne au GESTIONNAIRE un accusé de réception de la demande de remplacement du document. ++ |
+
+ + +
|
+ Service Attendu + |
+
+ Le GESTIONNAIRE transmet au CONSOMMATEUR la demande de suppression de(s) document(s) de santé d'un patient reçue sur la BAL MSSanté destinatrice. + |
+
|
+ Pré-Conditions + |
+
+ - Le patient est connu du consommateur. +- Le document doit être validé et doit correspondre à la dernière version du document envoyé au CONSOMMATEUR. +- Le CONSOMMATEUR dispose de la dernière version du document original dans sa base de données. +- Le GESTIONNAIRE détecte qu'un courriel a été reçu sur la BAL avec en pièce jointe une archive IHE_XDM. +- Le GESTIONNAIRE dézippe l’archive XDM. Il vérifie qu’elle contient des documents de santé d’un patient au format CDA ainsi qu’un fichier de métadonnées et prend connaissance du traitement à effectuer sur le document + |
+
|
+ Post-Conditions + |
+
+ Le GESTIONNAIRE trace les transmissions de document(s) + |
+
|
+ Contraintes fonctionnelles + |
+
+ La BAL du GESTIONNAIRE doit être en capacité de détecter les courriels entrants avec demande de traitement sur le(s) document(s) + |
+
|
+ Scénario Nominal + |
+
+ - Suite à la réception d’un courriel sur la BAL destinatrice, le GESTIONNAIRE transmet la demande de suppression du document de santé de la pièce jointe au CONSOMMATEUR +- Le CONSOMMATEUR traite la demande de suppression du document. +- Le CONSOMMATEUR retourne au GESTIONNAIRE un accusé de réception de suppression du document. + |
+
|
+ Code |
+
+
+ Libellé |
+
+
+ Description |
+
+
|
+ 0 |
+
+
+ Message accepted |
+
+
+ Message accepté |
+
+
|
+ 100 |
+
+
+ Segment sequence error |
+
+
+ Les segments ne sont pas
+ dans le bon ordre ou il manque un ou plusieurs segments requis |
+
+
|
+ 101 |
+
+
+ Required field missing |
+
+
+ Un champ requis dans un segment est manquant |
+
+
|
+ 102 |
+
+
+ Data type error |
+
+
+ Erreur sur un type de
+ donnée |
+
+
|
+ 103 |
+
+
+ Table value
+ not found |
+
+
+ Table non trouvée |
+
+
|
+ 198 |
+
+
+ Non-conformant cardinality |
+
+
+ Erreur de cardinalité sur
+ un champ du message |
+
+
|
+ 199 |
+
+
+ Other HL7 Error |
+
+
+ Autre type d’erreur concernant la syntaxe du message HL7 |
+
+
|
+ 200 |
+
+
+ Unsupported
+ message type |
+
+
+ Type de message non
+ supporté |
+
+
|
+ 201 |
+
+
+ Unsupported event code |
+
+
+ Code évènement
+ non supporté |
+
+
|
+ 202 |
+
+
+ Unsupported
+ processing |
+
+
+ Code process non supporté |
+
+
|
+ 203 |
+
+
+ Unsupported version |
+
+
+ Version HL7 non supportée |
+
+
|
+ 207 |
+
+
+ Application error |
+
+
+ Erreur de niveau
+ applicatif dont le contenu est détaillé dans le champ ERR-5 |
+
+
|
+ Code |
+
+
+ Libellé |
+
+
+ Description |
+
+
|
+ 900 |
+
+
+ Version du document
+ incorrecte lors d’une demande de remplacement/suppression |
+
+
+ Lors d’une demande de
+ remplacement ou suppression d’un document, la version de document transmise
+ dans le message HL7 ne correspond pas à la version la plus récente du
+ document existant au niveau de l’application réceptrice (consommateur) |
+
+
|
+ 901 |
+
+
+ Auteur non autorisé à remplacer ou supprimer un document |
+
+
+ Lors d’une demande de remplacement ou suppression d’un document, l’acteur
+ qui demande le traitement sur le document doit être l’auteur du document ou
+ un acteur qui appartient à la même organisation que l’auteur du document
+ original. Dans le cas contraire, le message est rejeté. |
+
+
|
+ 902 |
+
+
+ Identifiant patient inconnu |
+
+
+ Le patient pour lequel le
+ traitement sur le document est demandé est inconnu de l’application
+ réceptrice (consommateur) |
+
+
|
+ 903 |
+
+
+ INS non présent dans le document |
+
+
+ Le document CDA contenu dans le message contient une liste d’identifiants
+ de patient mais pas l’INS. Dans ce cas, la demande de traitement sur le
+ document (intégration/remplacement/suppression) ne peut pas être réalisée de
+ façon automatique par le système consommateur. |
+
+
|
+ 904 |
+
+
+ L’INS transmis ne
+ correspond pas exactement à celui stocké dans la base du consommateur |
+
+
+ L’INS du patient est
+ présent dans le document CDA contenu dans le message HL7 mais les traits ou
+ le matricule ne correspondent pas exactement à ceux stockés dans le système
+ consommateur. Dans ce cas, la demande de traitement sur le document
+ (intégration/remplacement/suppression) ne peut pas être réalisée de façon
+ automatique par le système consommateur. |
+
+
|
+ Flux métiers + |
+
+ Type de message HL7v2.6 + |
+
|
+ TransmissionDocuments + |
+
+ Transmission initiale d’un document : L’évènement utilisé sera le T02 « Original document notification » +-> MDM^T02^MDM_T02 +-> 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 » +-> MDM^T04^MDM_T02 +-> 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 » +-> MDM^T10^MDM_T02 +-> 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 + |
+
|
+ Sigle / Acronyme + |
+
+ Signification + |
+
|
+ ACK : + |
+
+ General acknowledge message + |
+
|
+ BAL : + |
+
+ Boîte aux lettres + |
+
|
+ CDA-R2 : + |
+
+ Clinical Document Architecture Release 2 + |
+
|
+ DPI : + |
+
+ Dossier Patient Informatisé + |
+
|
+ INS : + |
+
+ Identité Nationale de Santé + |
+
|
+ LPS : + |
+
+ Logiciel Professionnel de Santé + |
+
|
+ MDM : + |
+
+ Médical Document Management + |
+
|
+ MLLP : + |
+
+ Minimal Lower Layer Protocol + |
+
|
+ MSSanté : + |
+
+ Messagerie Sécurisée de Santé + |
+
|
+ NOS : + |
+
+ Nomenclature des Objets de Santé + |
+
|
+ PFI : + |
+
+ Plateforme Intermédiation + |
+
+ \ No newline at end of file diff --git a/input/pagecontent/index.md b/input/pagecontent/index.md index c2b85425..836c7dff 100644 --- a/input/pagecontent/index.md +++ b/input/pagecontent/index.md @@ -8,41 +8,196 @@
- Attention ! Cet Implementation Guide n'est pas en version courante. La version courante sera accessible via l'URL canonique suite à la première release : http://interop.esante.gouv.fr/ig/fhir/[code - ig] + Attention ! Cet Implementation Guide n'est pas en version courante. La version officielle est ici : https://esante.gouv.fr/volet-de-transmission-dun-document-cda-r2-en-hl7v2
+++ Cette version, au statut Trial Implementation, intègre le traitement des commentaires reçus par l’ANS pendant la phase de commentaires publics qui s’est déroulée du 27/11/2023 au 08/12/2023 ainsi que des corrections ou des améliorations apportées à la suite du projectathon organisé par l’ANS en septembre 2023. Cette version du volet intègre également le résultat de l’étude conduite en janvier 2024 par la DNS avec des industriels et leurs représentants sur les cas d’usage de la MSSanté présentés dans la section Volume 1 – Etude fonctionnelle. +
+
|
+ Code d’usage + |
+
+ Signification + |
+
|
+ R + |
+
+ Requis : l’élément de donnée doit obligatoirement être renseigné par l’émetteur et intégré par le récepteur + |
+
|
+ RE + |
+
+ Requis si connu : le système doit démontrer sa capacité à renseigner l’élément en émission et/ou à l’exploiter en réception. +Sur le terrain il peut exister des situations où l’élément est non renseigné. + |
+
|
+ O + |
+
+ Optionnel + |
+
|
+ X + |
+
+ Non supporté + |
+
|
+ C + |
+
+ Conditionnel : La condition de remplissage de l’élément de donnée est spécifiée dans le tableau de description du profil de message ou dans une note en dessous du tableau. + |
+
|
+ Code d’usage + |
+
+ Signification + |
+
|
+ [ ] + |
+
+ Champ optionnel + |
+
|
+ { } + |
+
+ Champ répétable + |
+
|
+ [{ }] + |
+
+ Champ optionnel et répétable + |
+
+QUESTIONS OUVERTES :
+LPS_MSS_Q1 : demande de fusionner les deux spécifications : Transmission d’un document CDA en HL7v2 et Transmission au LPS d’un document CDA provenant d’un courriel. La fusion des deux spécifications est sans doute possible. Cependant, utiliser la même transaction entre les acteurs CREATEUR/GESTIONNAIRE et GESTIONNAIRE/CONSOMMATEUR nécessite d’effectuer une étude plus approfondie de façon à déterminer comment harmoniser ces transactions. La mise en place d'une transaction unique indépendamment du contexte créerait de l'ambiguïté avec notamment des informations non pertinentes véhiculées entre le GESTIONNAIRE et le CONSOMMATEUR (alimentation DMP, échange MSSanté…).
+
+LPS_MSS_Q2 : demande d’un éditeur de permettre également d’utiliser le message ORU (HL7v2.5) de la même façon que le message MDM pour transférer la demande portée par le courriel reçu par le GESTIONNAIRE vers l’acteur CONSOMMATEUR. Un sondage a été proposé aux éditeurs sur ce sujet. Ce sondage n’a pas permis de dégager un consensus clair sur ce point (50% de non et 50% de oui et d’autre part l’éditeur à l’origine de la demande n’a pas confirmé ce besoin au niveau du sondage.
+
+LPS_MSS_Q3 : faut-il gérer la cohérence entre les métadonnées DMPMSS du document stocké dans le DMP et les métadonnées de ce même document géré dans les logiciels métier ? et si oui, comment gérer cette cohérence.
+Par exemple, dans le cas où le PS a alimenté le DMP du patient avec un document clinique et que le patient a exprimé le souhait de ne pas donner accès à ce document aux PS, alors est-il permis d’échanger ce même document au travers de la MSSanté ?
+Le cas d’usage qui nous a été soumis est le suivant :
+
-
+
- Le médecin de l’établissement alimente le DMP en positionnant le masquage aux PS à vrai à l’instant T (CR opératoire du patient) ; +
- Le médecin souhaite solliciter l’avis d’un collègue ; +
- La secrétaire médicale ou le médecin envoie par MSSanté ce même document à un collègue pour avis à T+1 jour. +
+ -Toujours laisser l'onglet "Ressources de conformité" pour s'assurer d'une cohérence globales entre tous les IGs -### Auteurs et contributeurs +##### Dépendances avec la documentation SEGUR -| Role | Nom | Organisation | Contact | -| --- | --- | --- | --- | -| **Primary Editor** | Prenom Nom | Agence du Numérique en Santé | prenom.nom@address.email | +Ce document doit être utilisé dans le cadre du référencement SEGUR vague 2. Il s’applique, entre autres, à la vague 2 du Ségur Numérique mais pas uniquement. Il peut également être utilisé hors SEGUR. + +##### Positionnement dans le cadre d'interopérabilité + +Cette spécification n’est pas autonome. Les développeurs doivent également connaître et maîtriser d’autres volets du CI_SIS publiés par l’ANS : + +- [Le volet Echange de documents de santé](https://esante.gouv.fr/sites/default/files/media_entity/documents/ci-sis_service_volet-echange-documents-sante_v1.8.pdf), + +Ainsi que le [Référentiel Socle MSSanté #2, Clients messagerie de sécurité de santé version 1.0.1](https://esante.gouv.fr/espace_documentation/mssante-clients-de-messageries-securisees-de-sante/referentiel-socle-mssante-2/actual), publié par l’ANS. -### Dépendances +#### Ce dont ne traite pas ce volet du CI_SIS -{% include dependency-table.xhtml %} +Les contraintes de sécurité concernant les flux échangés ne sont pas traitées dans ce document. En effet, les aspects relatifs à la sécurité sont du ressort du système d’information les implémentant. +Ce volet du CI_SIS n’a pas vocation à décrire le cadre juridique applicable. Il appartient à chaque acteur concerné par ce volet de veiller à ce que les fonctionnalités fournies et/ou mises en œuvre respectent ce cadre légal, notamment en termes de confidentialité et de sécurité des données par application des règles de la [PGSSI_S](https://esante.gouv.fr/produits-services/pgssi-s). + +#### Lectorat cible + +Ce document s'adresse aux développeurs des interfaces interopérables des systèmes implémentant le volet « Transmission au LPS d’un document CDA provenant d'un courriel MSSanté » ou à toute autre personne intervenant dans le processus de mise en place de ces interfaces. + + \ No newline at end of file diff --git a/input/pagecontent/interactions-acteurs.md b/input/pagecontent/interactions-acteurs.md new file mode 100644 index 00000000..6c968dd2 --- /dev/null +++ b/input/pagecontent/interactions-acteurs.md @@ -0,0 +1,12 @@ +
+ +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](struct-msg-mdn.html). diff --git a/input/pagecontent/lien-entete-cda-meta-xds.md b/input/pagecontent/lien-entete-cda-meta-xds.md new file mode 100644 index 00000000..36bb3b49 --- /dev/null +++ b/input/pagecontent/lien-entete-cda-meta-xds.md @@ -0,0 +1,6 @@ +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](https://esante.gouv.fr/sites/default/files/media_entity/documents/CI-SIS_ANX_LIENS-CDA-METADONNEES-XDS_V1.6.pdf)** \ No newline at end of file diff --git a/input/pagecontent/meta-dmp-mss.md b/input/pagecontent/meta-dmp-mss.md new file mode 100644 index 00000000..700d53cc --- /dev/null +++ b/input/pagecontent/meta-dmp-mss.md @@ -0,0 +1,647 @@ +La table « MetaDMP/MSS » utilisé dans le champ OBX-3 contient l’ensemble des métadonnées de restriction permettant les échanges avec le DMP et la MSSanté. + +
|
+ Code |
+
+
+ Libellé |
+
+
+ CodeSystem |
+
+
|
+ MASQUE_PS |
+
+
+ Masqué aux professionnels
+ de Santé |
+
+
+ MetaDMPMSS |
+
+
|
+ INVISIBLE_PATIENT |
+
+
+ Document Non Visible par le patient |
+
+
+ MetaDMPMSS |
+
+
|
+ INVISIBLE_REP_LEGAUX |
+
+
+ Non
+ visible par les représentants Légaux du patient |
+
+
+ MetaDMPMSS |
+
+
|
+ CONNEXION_SECRETE |
+
+
+ Connexion Secrete |
+
+
+ MetaDMPMSS |
+
+
|
+ MODIF_CONF_CODE |
+
+
+ Modification
+ Confidentiality Code |
+
+
+ MetaDMPMSS |
+
+
|
+ DESTDMP |
+
+
+ Destinataire DMP |
+
+
+ MetaDMPMSS |
+
+
|
+ DESTMSSANTEPS |
+
+
+ Destinataire
+ (Professionnel de Santé, organisation ou BAL applicative) |
+
+
+ MetaDMPMSS |
+
+
|
+ DESTMSSANTEPAT |
+
+
+ Destinataire Patient |
+
+
+ MetaDMPMSS |
+
+
|
+ ACK_RECEPTION |
+
+
+ Accusé
+ de réception |
+
+
+ MetaDMPMSS |
+
+
|
+ ACK_LECTURE_MSS |
+
+
+ Accusé de lecture |
+
+
+ MetaDMPMSS |
+
+
|
+ CORPSMAIL_PS |
+
+
+ Corps
+ du mail pour un PS |
+
+
+ MetaDMPMSS |
+
+
|
+ CORPSMAIL_PATIENT |
+
+
+ Corps du mail pour le patient |
+
+
+ MetaDMPMSS |
+
+
|
+ 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 + |
+
+ + |
+
+ + |
+
+ + |
+
+ +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é](profils-messages.html#le-groupe-de-segments-obxnte-portant-le-document-cda)). + +- 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). + +### Contraintes appliquées aux messages MDM 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 MDM + +##### Le segment MSH – Header 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 |
+
+
+ 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 (1.1) MSH-21.2 :
+ Namespace Id CISIS_CDA_HL7_LPS |
+
+
+ EI |
+
+
+ R |
+
+
|
+ Champ |
+
+
+ Contenu |
+
+
+ Type donnée |
+
+
+ Caractère
+ optionnel/obligatoire |
+
+
|
+ PID-3 |
+
+
+ Identifiants du patient |
+
+
+ CX |
+
+
+ R |
+
+
|
+ PID-5 |
+
+
+ Nom du patient + |
+
+
+ XPN |
+
+
+ R |
+
+
|
+ 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 en fonction de
+ l’appartenance du code à l’un des trois systèmes de codage |
+
+
|
+ 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 |
+
+
|
+ 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 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 |
+
+
+ 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 (Table 0203 – Interop’Santé) 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 (Table 0203 – Interop’Santé) |
+
+
|
+ > 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 |
+
+
+ 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 (Table 0203 – Interop’Santé) 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 (Table 0203 – Interop’Santé) |
+
+
|
+ > 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 |
+
+
+ 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 |
+
+
|
+ Composition du groupe
+ OBXNTE : Usage = Required /
+ Cardinalité = |
+
+ ||
|
+ 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 » |
+
+
|
+ 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 » |
+
|
+ 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 » |
+
|
+ 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 » |
+
|
+ 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 » |
+
|
+ 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 + |
+
+ +Ces segments doivent être conformes au standard HL7v2.6. + +#### Description des contraintes à appliquer sur le message ACK +##### Segment MSH +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 |
+
|
+ 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 : ·
+ 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.
+ |
+
|
+ 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) |
+
|
+ 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. + |
+
++ ++ (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. +
+
+\ No newline at end of file diff --git a/input/pagecontent/struct-msg-mdn.md b/input/pagecontent/struct-msg-mdn.md new file mode 100644 index 00000000..7d5d4782 --- /dev/null +++ b/input/pagecontent/struct-msg-mdn.md @@ -0,0 +1,136 @@ +La RFC 8098 définit le type de contenu +« message/disposition-notification » propre au MDN (Message +Disposition Notification). Ce MDN est utilisé pour notifier +l'émetteur d'un courriel de tout traitement qui survient après la +livraison de ce courriel au niveau du récepteur. Conformément à la RFC +8098, ce MDN doit : + +- Être lisible par un humain et par une machine, + +- Fournir suffisamment d'informations pour permettre à l'émetteur du + message d'associer sans ambiguïté le MDN au message + initialement envoyé et à l'adresse du récepteur initial au nom + duquel le MDN a été produit, + +- Être structuré conformément à la RFC 2822 et la RFC 8098, + +L'envoi du MDN à l'expéditeur du courriel initial est +conditionné par la présence d'un entête Disposition-Notification-To au +niveau du courriel expédié. D'autres informations peuvent également être +fournies en utilisant les entêtes Original-Recipient et +Disposition-Notification-Options. + +La RFC 8098 précise qu'un MDN ne devrait pas être renvoyé +automatiquement par le récepteur du courriel dans le cas où l'entête +Disposition-Notification-To diffère de l'adresse précisée dans l'entête +returm-Path du courriel envoyé, ceci afin d'éviter une transmission de +messages en boucle. Dans ce cas l'envoi du MDN nécessite une +confirmation de l'utilisateur. + +Dans le cas d'un MDN en erreur, l'objet du MDN doit être précisé +de la façon suivante : `[KO Intégration système ! ] XDM/1.0/DDM++ (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. +
+