Volet de transmission d'un document CDA-R2 en HL7v2 - Local Development build (v2.1.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Accueil

Official URL: https://interop.esante.gouv.fr/ig/hl7v2/trans-cda-r2/ImplementationGuide/ans.hl7v2.fr.trans-cda-r2				Version: 2.1.1
Draft as of 2024-11-01				Computable Name: CISIS_CDA_HL7_V2

Brief description of this Implementation Guide
[Add a brief description of this IG in English]

Avant-propos

Ce document fait partie de la couche Service du Cadre d’Interopérabilité des Systèmes d’Information de santé (CI_SIS).

Ce présent volet décrit la possibilité pour un logiciel métier d’une organisation de déléguer à un acteur tiers, la plateforme d’intermédiation (PFI), la capacité d’interagir avec le DMP et/ou avec la MSSanté. Dans le cas d’un envoi par MSSanté, ce volet est à considérer par le lecteur en association avec un autre volet du CI_SIS, le volet « Transmission au LPS d’un document CDA provenant d’un courriel MSSanté » de façon à avoir une vision de bout en bout des échanges (du créateur de la demande de traitement sur un document vers le consommateur final de cette demande).

Les deux volets en question intègrent à la fois une partie fonctionnelle et une partie technique.

La partie fonctionnelle décrit, à titre d’exemple et de façon non exhaustive, un ensemble de cas d’usage. Sur la base de ces cas d’usage, sont ensuite définis des acteurs du système d’information (au sens d’IHE) et des transactions qui interviennent entre ces acteurs pour répondre à ces cas d’usage. Les processus collaboratifs sont ensuite décrits et les flux entre les acteurs sont également identifiés.

La partie technique décrit les standards retenus pour implémenter les flux identifiés par l’étude fonctionnelle et décrit dans le détail les règles d’implémentation de ces standards.

Pour une meilleure compréhension du lecteur, les cas d’usage décrits dans la partie fonctionnelle de chacun des volets couvrent la totalité des échanges entre les acteurs définis dans les deux volets. Dans le contexte de ce présent document, seuls les échanges entre le logiciel métier et la PFI font partie du périmètre du volet.

Dans le cas d’usage où la demande provenant du CREATEUR est relayée par le GESTIONNAIRE de l’établissement vers une BAL personnelle ou organisationnelle d’un autre établissement, l’envoi de l’accusé de lecture MSSanté (Message Disposition Notification- MDN décrit dans la RFC 8098) est déclenché par le traitement du courriel déposé dans la BAL de l’utilisateur destinataire (lecture, suppression, traitement, etc.). Le courriel MDN est alors réceptionné par la PFI de l’établissement expéditeur qui construit le message métier HL7 ZAM^Z03^ZAM_Z01 et le transmet au logiciel métier de l’utilisateur expéditeur.

Une liste de cas d’usage, non exhaustive, est présentée à titre d’exemple dans le Volume 1 - Etude fonctionnelle, pour susciter les retours des industriels et des utilisateurs lors des prochains projectathons.

Rappel des conventions utilisées par IHE et HL7 :

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

Introduction

Ce document est une spécification d’une transaction de demande de transmission/remplacement/suppression de document(s) clinique(s) en intra-organisation entre un système créateur de documents et une PFI (plateforme d’intermédiation), dans l’objectif de partager et/ou d’échanger ces documents avec les acteurs externes à l’établissement pour :

• Publication de document(s) clinique(s) du patient au DMP (Dossier Médical Partagé),

• Envoi de document(s) clinique(s) du patient à différents destinataires externes à l’établissement au moyen de la MSSanté (Messagerie Sécurisée de Santé),

Cette spécification doit permettre d’harmoniser les modes de communication des documents cliniques concernant un patient, quelle que soit leur origine (CR de laboratoire, CR de radiologie, CR d’anatomie pathologique, CR de cardiologie, Lettre de liaison, etc..).

La PFI réceptionne les documents cliniques des patients pris en charge au sein de l’établissement provenant du système créateur de documents et les distribue en direction du DMP et/ou de la MSSanté en fonction de la demande exprimée par le créateur du document. La PFI retourne également au système créateur du document, le cas échéant, les accusés de réception du DMP et de la MSSanté de cette diffusion ainsi que l’accusé de lecture du courriel MSSanté.

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é ». Ces documents 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.

Dépendances documentaires

Cette spécification n’est pas autonome. Notamment, dans le cas d’un envoi d’une demande de traitement sur le(s) document(s), le lecteur pourra également consulter le volet « Transmission au LPS d’un document CDA provenant d’un courriel MSSanté » pour avoir une vision complète et transversale des échanges représentée de façon synthétique sur la figure suivante et décrits de façon détaillée dans la volume 2 du présent document :

Dépendances avec la documentation SEGUR

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.

Les contraintes décrites dans ce présent volet sont moins fortes que certaines exigences du programme SEGUR vague 2. En conséquence, un système référencé SEGUR vague 2 devra mettre en œuvre les spécifications techniques décrites dans ce présent volet, mais également répondre aux exigences des couloirs de la vague 2 du SEGUR concernés par ce volet.

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 Partage de documents de santé,

• Le volet Echange de documents de santé,

Les développeurs de PFI devront également respecter le Référentiel socle « MSSanté #2- Clients de Messageries Sécurisées de Santé » publié par l’ANS et le référentiel « Service DMP intégré aux LPS- Version 2.10.0 » publié par le GIE SESAM-VITALE.

L’ensemble de ces spécifications sont hors périmètre de ce présent volet du CI-SIS.

Ce dont ne traite pas ce volet du CI_SIS

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.

Lectorat cible

Les lecteurs cibles sont principalement des chefs de projets ainsi que toute personne concernée par les travaux du Ségur du Numérique et qui spécifie des projets avec des interfaces interopérables.