Volet de transmission d'un document CDA-R2 en HL7v2
2.1.1 - ci-build
Volet de transmission d'un document CDA-R2 en HL7v2
2.1.1 - ci-build
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
| 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-07-26 | Computable Name: CISIS_CDA_HL7_V2 | |||
Brief description of this Implementation Guide
[Add a brief description of this IG in English]
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.
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 |
QUESTIONS OUVERTES :
CDA_HL7_Q1 : demande de fusionner les deux spécifications : « Transmission de document(s) 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é…). Des retours des éditeurs sont attendus sur ce point. D’autre part, cette fusion des deux spécifications nécessiterait de modifier la rédaction des exigences SEGUR concernant la conformité des logiciels à ces spécifications.
CDA_HL7_Q2 : 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 :
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.
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 :
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.
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 :
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.
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.
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.