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