Service Attendu

Le CREATEUR émet le(s) document(s) validé(s) vers le GESTIONNAIRE qui publie ce(s) document(s) sur le DMP et/ou réalise un envoi par MSSanté.

Pré-Conditions

Les métadonnées de contexte DMP/MSSanté doivent être renseignées (soit par paramétrage de l’application soit par l’utilisateur) et l’utilisateur doit valider ce(s) document(s) au niveau de l’application métier dans laquelle il a été généré via un statut de validation géré en interne. Chaque document CDA doit être valide et disponible.

L’INS du patient est obligatoirement qualifiée dans le cas où la publication sur le DMP est demandée.

Une dérogation valable jusqu’à fin 2023, puis renouvelable jusqu’à sa révocation qui sera indiquée dans les futures versions du référentiel socle MSSanté#2, permet d’échanger un courriel par MSSanté en l’absence d’un INS qualifié.

Post-Conditions

Le document est partagé sur le DMP et/ou reçu par le(s) destinataire(s) via MSSanté.

Contraintes fonctionnelles

Dans le cas où le CREATEUR de documents transmet les 2 formats de documents séparément (CDA Niv1 et CDA Niv3), ces 2 documents sont transmis simultanément dans la même transaction. (Note1)

Scénario Nominal

Le CREATEUR transmet une demande de transmission initiale de document(s) au GESTIONNAIRE en précisant si ce(s) document(s) doit(vent) être transmis au DMP et/ou à un ou plusieurs destinataire(s) via la MSSanté.

Le CREATEUR permet également à l’utilisateur de préciser les métadonnées DMP/MSSanté : masquage au(x) PS, visibilité au patient, visibilité au(x) représentant(s) légaux. Il permet également à l’utilisateur de préciser s’il souhaite recevoir un accusé de réception DMP/MSSanté et/ou un accusé de lecture MSSanté.

Le GESTIONNAIRE réceptionne cette demande et utilise les informations portées par la transaction ainsi que les informations contenues dans le(s) document(s) CDA pour réaliser la transaction d’alimentation du DMP et/ou l’envoi vers le(s) destinataire(s) (Patient et/ou PS) via la MSSanté (i.e. ; produire les métadonnées XDS).

En fonction de la demande, le GESTIONNAIRE transmet au CREATEUR l’accusé de réception DMP, l’accusé de réception MSSanté et/ou l’accusé de lecture MSSanté.

Dans le cas de la DrimBox, seule l’alimentation du DMP avec le document de référence d’objets d’examen d’imagerie (KOS) est réalisée. La DRIMBox-Source n’est pas concernée par la MSSanté.

Service Attendu

Le CREATEUR émet une demande de remplacement de document(s) vers le GESTIONNAIRE. Celui-ci réalisera ensuite le relais vers le DMP pour réaliser un Replace et vers MSSanté pour réaliser un nouvel envoi contenant le(s) document(s) remplaçant le(s) document(s) initialement envoyés.

Pré-Conditions

Le document CDA doit être disponible, validé et identifié comme remplaçant un document précédemment envoyé par MSSanté et/ou publié sur le DMP.

L’INS du patient doit être obligatoirement qualifié dans le cas où le remplacement du document est demandé au niveau du DMP.

Une dérogation valable jusqu’à fin 2023, puis renouvelable jusqu’à sa révocation qui sera indiquée dans les futures versions du référentiel socle MSSanté#2, permet d’échanger un courriel par MSSanté en l’absence d’un INS qualifié.

Post-Conditions

La nouvelle version de document est publiée sur le DMP et envoyée par MSSanté (Patient et/ou PS). L’ancienne version de document est mise au statut « Deprecated » au niveau du CONSOMMATEUR MSSanté et/ou sur le DMP.

Contraintes fonctionnelles

Dans le cas où le CREATEUR de document(s) transmet les 2 formats de documents séparément (CDA Niv1 et CDA Niv3), le remplacement (ou de la mise à jour des métadonnées) d’un des formats doit s’accompagner du remplacement (ou de la mise à jour des métadonnées) du format lié. La transaction doit contenir les 2 nouvelles versions de documents. Cf Note 1

Scénario Nominal

Le CREATEUR transmet une demande de remplacement de document(s) au GESTIONNAIRE. Il peut s’agir de mettre jour le document, de masquer/démasquer le document aux PS, de rendre visible le document au patient ou de rendre visible le document aux représentants légaux.

Le GESTIONNAIRE réceptionne cette demande de remplacement et utilise les informations portées par la transaction ainsi que les informations contenues dans le(s) document(s) CDA pour réaliser la transaction d’alimentation du DMP et/ou l’envoi vers le(s) destinataire(s) (Patient et/ou PS) via la MSS (i.e. ; produire les métadonnées XDS).

Le code RPLC dans clinicalDocument/relatedDocument@typeCode dans le CDA-R2 [cf: volet CI-SIS : CONTENU_VOLET-STRUCTURATION-MINIMALE_V1.15] permet de constituer l’association RPLC dans la soumission XDS sur le DMP pour le remplacement [cf: SESAM-VITALE : Service DMP intégré aux LPS - Version 2.10.0].

En fonction de la demande, le GESTIONNAIRE transmet au CREATEUR l’accusé de réception DMP, l’accusé de réception MSSanté et/ou l’accusé de lecture MSSanté.

Service Attendu

Le CREATEUR émet une demande de suppression de document(s) vers le GESTIONNAIRE. Celui-ci réalisera ensuite le relais vers le DMP pour réaliser un Delete et vers MSSanté pour réaliser un nouvel envoi contenant le(s) document(s) à supprimer.

Pré-Conditions

Le document a été envoyé préalablement pour soumission au DMP et/ou pour envoi par MSSanté.

L’INS du patient doit obligatoirement être qualifié dans le cas où la suppression du document du DMP est demandée.

Une dérogation valable jusqu’à fin 2023, puis renouvelable jusqu’à sa révocation qui sera indiquée dans les futures versions du référentiel socle MSSanté#2, permet d’échanger un courriel par MSSanté en l’absence d’un INS qualifié.

Post-Conditions

Le document est supprimé du DMP (availabilityStatus = Deleted) [cf: volet CI-SIS : CONTENU_VOLET-STRUCTURATION-MINIMALE_V1.15]

TD3.3 (Supprimer un document) [cf: volet CI-SIS : CONTENU_VOLET-STRUCTURATION-MINIMALE_V1.15]

Le document est également supprimé au niveau de chacun des destinataire(s) de l’envoi par MSS.

Contraintes fonctionnelles

Dans le cas où le CREATEUR de documents transmet les 2 formats de documents séparément (CDA Niv1 et CDA Niv3), la suppression d’un des formats doit s’accompagner de la suppression du format lié. La transaction doit contenir les 2 formats de document à supprimer. Hors périmètre SEGUR.

Scénario Nominal

Une erreur détectée nécessite la suppression du document sans qu’il soit remplacé par une autre version (ex. erreur d’association entre le CR et le patient).

Le CREATEUR transmet une demande de suppression de document(s) au GESTIONNAIRE.

Le GESTIONNAIRE réceptionne cette demande de suppression et utilise les informations portées par la transaction ainsi que les informations contenues dans le(s) document(s) CDA pour réaliser la transaction de suppression du document sur le DMP et/ou l’envoi vers le(s) destinataire(s) (Patient et/ou PS) via la MSS (i.e. ; produire les métadonnées XDS).

Un message est envoyé par le GESTIONNAIRE vers le(s) destinataire(s) MSSanté indiquant dans le corps du mail que le document doit être supprimé.

cf : volet Volet Echange des Documents de Santé 1.8.

En fonction de la demande, le GESTIONNAIRE transmet au CREATEUR l’accusé de réception DMP, l’accusé de réception MSSanté et/ou l’accusé de lecture MSSanté.