|
Type
|
Reference
|
Content
|
|
web
|
esante.gouv.fr
|
|
|
web
|
esante.gouv.fr
|
IG © 2020+ Agence du Numérique en Santé (ANS) - 2-10 Rue d'Oradour-sur-Glane, 75015 Paris
. Package ans.hl7v2.fr.trans-cda-r2#2.1.2 based on FHIR 4.0.1
. Generated 2025-03-04
Liens: Table des matières
|
QA
|
Historique des versions
| New Issue
|
|
web
|
github.com
|
IG © 2020+ Agence du Numérique en Santé (ANS) - 2-10 Rue d'Oradour-sur-Glane, 75015 Paris
. Package ans.hl7v2.fr.trans-cda-r2#2.1.2 based on FHIR 4.0.1
. Generated 2025-03-04
Liens: Table des matières
|
QA
|
Historique des versions
| New Issue
|
|
web
|
solidarites-sante.gouv.fr
|
|
|
web
|
esante.gouv.fr
|
|
|
web
|
github.com
|
Ajout de la possibilité d’utiliser un courriel standard à la place du MDN pour la gestion des erreurs ( 41
)
-
ajout d’une note pour décrire le cas d’usage
- ajout du lien vers l’annexe du volet Transmission au LPS de documents CDA provenant d’un courriel MSSanté
- suppression de l’annexe décrivant le MDN pour renvoyer vers l’annexe du volet Transmission au LPS de documents CDA provenant d’un courriel MSSanté
|
|
web
|
github.com
|
Correction PRT-8.7 : Ajout du code IDNST suite à l’évolution du volet InteropSanté profils des messages
( 47
)
|
|
web
|
github.com
|
Correction PRT-5.13 : Ajout du code IDNPS suite à l’évolution du volet InteropSanté profils des messages
( 43
)
|
|
web
|
github.com
|
Précisions apportées pour PRT-5.9 profils des messages
( 50
)
|
|
web
|
github.com
|
Ajout du code 906 ‘autres type d’erreur’ dans l’annexe Error codes
( 45
)
|
|
web
|
github.com
|
Modification du format du volet : passage du format PDF au format guide d’implémentation ( 3
)
|
|
web
|
github.com
|
Avant-propos : suppression d’une ligne vide du tableau des conventions HL7, IHE ( 3
)
|
|
web
|
github.com
|
remplacement adresse courriel adam.hoda@medecin.mssante.fr par adam.hoda@test-ci-sis.mssante.fr ( 10
)
|
|
web
|
github.com
|
remplacement de message MDN par MDN (qui signifie d’emblée Message Disposition Notification) ( 3
)
|
|
web
|
github.com
|
remplacement du terme « section » par « volume 2 » ( 3
)
|
|
web
|
github.com
|
cas d’usage, remplacement des termes « Guide d’implémentation du DMP » par « Guide d’intégration du DMP » ( 3
)
|
|
web
|
github.com
|
Choix des standards
: suppression de la phrase « Les échanges MSSanté doivent prendre en compte les restrictions positionnées sur le message. (Exemple : un document avec un masquage Médecin ne doit pas être envoyé sur le mail MSSanté du médecin). » qui n’a pas de rapport avec le choix des standards. ( 4
)
|
|
web
|
github.com
|
Profils des messages
: précision sur l’utilisation du code FIN dans NTE-4 dans l’OBX dans le contexte de l’“Echange MSSanté Patient” ( 21
)
|
|
web
|
github.com
|
Profils des messages
: suppression de la phrase et du point d’attention “un document clinique masqué aux PS ne doit pas être envoyé aux PS par MSSanté.” car les envois DMP et MSS aux PS correspondent à des cas d’usages différents qui justifient d’avoir leurs propres règles sans que les impératifs de l’un ne s’impose à l’autre. ( 5
)
|
|
web
|
github.com
|
Profils des messages
: Ajout du Point d’attention : Un document ayant un niveau renforcé de confidentialité (restreint ou très restreint) ne devrait pas être mis en partage. ( 15
)
|
|
web
|
github.com
|
correction typos/cohérence pour le type message en MSH-9.3 ( 13
):
|
|
web
|
github.com
|
correction exemples de messages d’acquittements de l’ORU ou du MDM
: Suppression dans les exemples du MSH-21.1 et MSH-21.2 car les Ack n’ont pas de contraintes particulières par rapport à la spécification international d’un Ack ( 3
)
|
|
web
|
github.com
|
Déplacement du paragraphe “Lien entre l’EN-TETE CDA et les métadonnées XDS” (page 52 dans la version précédente du volet) dans Volume 3 Annexes ( 37
)
|
|
web
|
github.com
|
Ajout mapping VIHF et Metadata XDS
( 8
)
|
|
web
|
github.com
|
Ajout mapping message MSS
( 28
)
|
|
web
|
github.com
|
Ajout du code erreur 905
( 33
)
|
|
web
|
esante.gouv.fr
|
Ici nous rappelons l’historique des précédentes versions.
Cet historique est également disponible dans la dernière version du volet au format pdf : ANNEXE 9 du doument CI_SIS-SERVICES_VOLET_TRANS_DOCS_CDA_EN_HL7V2_V2.1_Post_PAT_CONCERTATION_FINAL_0.pdf
|
|
web
|
esante.gouv.fr
|
ANS - MSSANTE : Référentiel socle MSSanté #2 version 1.0.1 et supérieure
|
|
web
|
esante.gouv.fr
|
PGSSI_S : Politique générale de sécurité des systèmes d’information de santé
|
|
web
|
esante.gouv.fr
|
ANS - CI-SIS : CONTENU_VOLET-STRUCTURATION-MINIMALE version 1.15 et supérieure
|
|
web
|
esante.gouv.fr
|
Annexe CI-SIS : Prise en charge de l’identifiant National de Santé (INS) dans les standards d’interopérabilité et les volets du CI-SIS. version 1.5 et supérieure
|
|
web
|
esante.gouv.fr
|
ANS - INS : Corpus Documentaire disponible sur le site de l’ANS
|
|
web
|
esante.gouv.fr
|
ANS - NOS : Nomenclature des Objets de Santé
|
|
web
|
industriels.sesam-vitale.fr
|
SESAM-VITALE : Service DMP intégré aux LPS - Version 2.9 et supérieure
|
|
web
|
esante.gouv.fr
|
ANS - CI-SIS : ANNEXE - LIEN ENTRE L’EN-TETE CDA ET LES METADONNEES XDS version 1.6 et supérieure
|
|
web
|
esante.gouv.fr
|
ANS - CI_SIS : Volet Partage de documents de santé version 1.15 et supérieure
|
|
web
|
esante.gouv.fr
|
ANS - CI_SIS : Volet Echange des Documents de Santé version 1.8 et supérieure
|
|
web
|
www.interopsante.org
|
INTEROP’SANTE : ITI - PAM - National extension France - Release 2.11 et supérieure
|
|
web
|
www.interopsante.org
|
INTEROP’SANTE : ITI - 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 - Release 1.8 et supérieure
|
|
web
|
github.com
|
Les exemples sont disponibles sur github ici
.
|
|
web
|
esante.gouv.fr
|
Les tables HL70357
(dont le nom symbolique est messageErrorCondition) et HL70533
(dont le nom symbolique est applicationErrorCode) sont décrites dans le volet « Transmission au LPS d’un document CDA provenant d’un courriel MSsanté
» du CI_SIS.
|
|
web
|
github.com
|
https://github.com/ansforge/hl7V2-exemples/tree/main/Vague%202/Trans_Doc-CDA-HL7V2/TRANSMISSION_DOCS_CDA_EN_HL7V2_V2.1/ORU
|
|
web
|
esante.gouv.fr
|
Exemple 3 :
Remplacement d’un document déjà partagé
DMP et échangé par une nouvelle version validée en CDA-R2 pour nouveau
partage et échange sans restriction, le message est partagé sur le DMP
pour « Replace ». Le code RPLC dans
clinicalDocument/relatedDocument@typeCode dans le CDA-R2 (voir Volet CONTENU_VOLET-STRUCTURATION-MINIMALE
) permet
de constituer l’association RPLC dans la soumission XDS pour le
remplacement (voir Volet Partage de documents de santé
)
|
|
web
|
esante.gouv.fr
|
Exemple 3 :
Remplacement d’un document déjà partagé
DMP et échangé par une nouvelle version validée en CDA-R2 pour nouveau
partage et échange sans restriction, le message est partagé sur le DMP
pour « Replace ». Le code RPLC dans
clinicalDocument/relatedDocument@typeCode dans le CDA-R2 (voir Volet CONTENU_VOLET-STRUCTURATION-MINIMALE
) permet
de constituer l’association RPLC dans la soumission XDS pour le
remplacement (voir Volet Partage de documents de santé
)
|
|
web
|
github.com
|
https://github.com/ansforge/hl7V2-exemples/tree/main/Vague%202/Trans_Doc-CDA-HL7V2/TRANSMISSION_DOCS_CDA_EN_HL7V2_V2.1/MDM
|
|
web
|
esante.gouv.fr
|
Exemple 3 :
Remplacement d’un document CR d’imagerie
médicale déjà partagé DMP et échangé par une nouvelle version validée en
CDA-R2 pour nouveau partage et échange sans restriction, le message est
partagé DMP pour « Replace ». Le code RPLC dans
clinicalDocument/relatedDocument@typeCode dans le CDA-R2 (voir Volet CONTENU_VOLET-STRUCTURATION-MINIMALE
) permet
de constituer l’association RPLC dans la soumission XDS pour le
remplacement (voir Volet Partage de documents de santé
)
|
|
web
|
esante.gouv.fr
|
Exemple 3 :
Remplacement d’un document CR d’imagerie
médicale déjà partagé DMP et échangé par une nouvelle version validée en
CDA-R2 pour nouveau partage et échange sans restriction, le message est
partagé DMP pour « Replace ». Le code RPLC dans
clinicalDocument/relatedDocument@typeCode dans le CDA-R2 (voir Volet CONTENU_VOLET-STRUCTURATION-MINIMALE
) permet
de constituer l’association RPLC dans la soumission XDS pour le
remplacement (voir Volet Partage de documents de santé
)
|
|
web
|
esante.gouv.fr
|
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).
|
|
web
|
wiki.ihe.net
|
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.
|
|
web
|
github.com
|
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.
|
|
web
|
esante.gouv.fr
|
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.
|
|
web
|
esante.gouv.fr
|
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 :
|
|
web
|
esante.gouv.fr
|
Le volet Partage de documents de santé
,
|
|
web
|
esante.gouv.fr
|
Le volet Echange de documents de santé
,
|
|
web
|
esante.gouv.fr
|
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.9 et supérieure »
publié par le GIE SESAM-VITALE.
|
|
web
|
industriels.sesam-vitale.fr
|
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.9 et supérieure »
publié par le GIE SESAM-VITALE.
|
|
web
|
esante.gouv.fr
|
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
.
|
|
web
|
esante.gouv.fr
|
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é
:
|
|
web
|
esante.gouv.fr
|
Annexe – Lien Entre l’en-tête CDA et les métadonnées XDS
|
|
web
|
ansforge.github.io
|
Fourni par le LPS
valeur de JDV_J61-HealthcareFacilityTypeCode-DMP
|
|
web
|
ansforge.github.io
|
1re occurrence obligatoire
Pour les professionnels de santé :
- Prendre la valeur de code la plus appropriée parmi les codes du jeu de valeurs JDV_J65_SubjectRole_DMP
avec un codeSystem provenant de :
- TRE TRE_G15-ProfessionSante
- TRE_G16_ProfessionFormation (Professions en formation (carte CPF))
Pour les autres :
- Prendre la valeur de code la plus appropriée parmi les codes du jeu de valeurs JDV_J65_SubjectRole_DMP
avec un codeSystem provenant de :
- TRE_A00_ProducteurDocNonPS
- TRE_R95_UsagerTitre
- TRE_R94_ProfessionSocial
- TRE_R291_AutreProfession
|
|
web
|
ansforge.github.io
|
2e occurrence uniquement et obligatoirement pour les médecins et pharmaciens
Pour les médecins :
- Prendre la valeur de code la plus appropriée parmi les codes du jeu de valeurs JDV_J65_SubjectRole_DMP
avec un codeSystem provenant de TRE_R01_EnsembleSavoirFaire_CISIS
Pour les pharmacines ;
- Prendre la valeur de code la plus appropriée parmi les codes du jeu de valeurs JDV_J65_SubjectRole_DMP
avec un codeSystem provenant de TRE_G05_SousSectionTableauCNOP
|
|
web
|
ansforge.github.io
|
Rôle - 2e occurrence obligatoire pour les professionnels caractérisés par leur rôle. Non requise pour les autres professionnels.
Prendre la valeur de code la plus appropriée parmi les codes du jeu de valeurs JDV_J65_SubjectRole_DMP
avec un codeSystem provenant de TRE_R85_RolePriseCharge
|
|
web
|
ansforge.github.io
|
Cette métadonnée contient le code correspondant au type d’activité associé à l’événement clinique ayant abouti à la constitution du lot de soumission.
Valeur de JDV_J59-ContentTypeCode-DMP
|
|
web
|
ansforge.github.io
|
CDA
: classCode est déduit du CDA (champ code) selon la table de correspondance ASS_X04-CorrespondanceType-Classe
|
|
web
|
ansforge.github.io
|
Cet attribut représente le code du format du document JDV_J60-FormatCode-DMP
|
|
web
|
ansforge.github.io
|
CDA
:
- CDA N1 => “urn:ihe:iti:xds-sd:pdf:2008”
- CDA N3 => Utilisation de l’association ASS-A11-CorresModeleCDA-XdsFormatCode-CISIS
|
|
web
|
esante.gouv.fr
|
Recherche sur Volet de transmission d'un document CDA-R2 en HL7v2 (Current Build)
Recherche Volet de transmission d'un document CDA-R2 en HL7v2 (Current Build)
|
|
web
|
solidarites-sante.gouv.fr
|
|
|
web
|
esante.gouv.fr
|
2-10 Rue d'Oradour-sur-Glane 75015 Paris
|
|
web
|
interop.esante.gouv.fr
|
Tests
Libre service
Espace de test
CGU
Manuel
Projectathon
Présentation
Consulter les Tests
Verification de conformité
Consulter les Tests
Programme Ségur
|
|
web
|
esante.gouv.fr
|
Tests
Libre service
Espace de test
CGU
Manuel
Projectathon
Présentation
Consulter les Tests
Verification de conformité
Consulter les Tests
Programme Ségur
|
|
web
|
industriels.esante.gouv.fr
|
Tests
Libre service
Espace de test
CGU
Manuel
Projectathon
Présentation
Consulter les Tests
Verification de conformité
Consulter les Tests
Programme Ségur
|
|
web
|
industriels.esante.gouv.fr
|
Tests
Libre service
Espace de test
CGU
Manuel
Projectathon
Présentation
Consulter les Tests
Verification de conformité
Consulter les Tests
Programme Ségur
|
|
web
|
interop.esante.gouv.fr
|
Tests
Libre service
Espace de test
CGU
Manuel
Projectathon
Présentation
Consulter les Tests
Verification de conformité
Consulter les Tests
Programme Ségur
|
|
web
|
interop.esante.gouv.fr
|
Tests
Libre service
Espace de test
CGU
Manuel
Projectathon
Présentation
Consulter les Tests
Verification de conformité
Consulter les Tests
Programme Ségur
|
|
web
|
industriels.esante.gouv.fr
|
Tests
Libre service
Espace de test
CGU
Manuel
Projectathon
Présentation
Consulter les Tests
Verification de conformité
Consulter les Tests
Programme Ségur
|
|
web
|
interop.esante.gouv.fr
|
Ces outils sont accessibles en ligne sur le site https://interop.esante.gouv.fr/
et notamment utilisés lors des Projectathons organisés par l’ANS pour les éditeurs.
|
|
web
|
industriels.sesam-vitale.fr
|
La demande du Dr Dupont est traitée par le composant PFI de l’hôpital-A
qui gère les échanges avec le DMP et/ou la MSSanté. La PFI de
l’hôpital-A réceptionne et analyse les éléments portés par la
transaction émise à partir du logiciel métier du Dr Dupont. La PFI
construit d’une part la requête d’alimentation du DMP conformément au
Guide d’intégration du DMP
ainsi que le courriel à destination de
la BAL personnelle du Dr Adam Hoda. La PFI construit également les
pièces jointes, c’est-à-dire l’archive IHE_XDM.zip conformément au volet
Echange de documents de santé du CI_SIS
et les fichiers PDF
correspondants aux comptes rendus envoyés dans l’archive IHE_XDM.
|
|
web
|
esante.gouv.fr
|
La demande du Dr Dupont est traitée par le composant PFI de l’hôpital-A
qui gère les échanges avec le DMP et/ou la MSSanté. La PFI de
l’hôpital-A réceptionne et analyse les éléments portés par la
transaction émise à partir du logiciel métier du Dr Dupont. La PFI
construit d’une part la requête d’alimentation du DMP conformément au
Guide d’intégration du DMP
ainsi que le courriel à destination de
la BAL personnelle du Dr Adam Hoda. La PFI construit également les
pièces jointes, c’est-à-dire l’archive IHE_XDM.zip conformément au volet
Echange de documents de santé du CI_SIS
et les fichiers PDF
correspondants aux comptes rendus envoyés dans l’archive IHE_XDM.
|
|
web
|
esante.gouv.fr
|
La structure du MDN est décrite dans l’exemple décrit en Annexe du volet « Transmission au LPS d’un document CDA provenant d’un courriel MSSanté
.
|
|
web
|
esante.gouv.fr
|
Dans le cas où un MDN (Message Disposition Notification) n'a pas été explicitement demandé par le destinataire (via l'entête `Disposition-Notification-To` dans le message d'origine), et que, pour pouvoir gérer toutes les erreurs, on souhaite utiliser une BAL dédiée, un courriel 'standard' peut être utlisé.
La structure du courriel est précisée en annexe du volet Transmission au LPS d'un document CDA provenant d'un courriel MSSanté
.
Ce cas d'usage est hors périmètre de ce volet.
|
|
web
|
esante.gouv.fr
|
La structure du MDN est décrite dans l’exemple accessible en annexe du volet « Transmission au LPS d’un document CDA provenant d’un courriel MSSanté
.
|
|
web
|
esante.gouv.fr
|
Dans le cas où un MDN (Message Disposition Notification) n'a pas été explicitement demandé par le destinataire (via l'entête `Disposition-Notification-To` dans le message d'origine), et que, pour pouvoir gérer toutes les erreurs, on souhaite utiliser une BAL dédiée, un courriel 'standard' peut être utlisé.
La structure du courriel est préciséé en annexe du volet Transmission au LPS d'un document CDA provenant d'un courriel MSSanté
.
Ce cas d'usage est hors périmètre de ce volet.
|
|
web
|
esante.gouv.fr
|
dans le contexte français, conformément au volet Partage de documents de santé du CI_SIS
, la mise à jour des métadonnées du document est limitée à la mise à jour des informations de masquage du document aux PS et de mise en visibilité du document au patient et à ses représentants légaux ainsi que le statut du document.
La PFI interagissant avec le DMP en mode d’authentification indirecte, il lui est impossible de mettre en œuvre la transaction TD3.3 (Gestion des attributs d’un document) du profil Alimentation du DMP, décrite dans le Guide d’intégration du DMP
(transaction équivalente à la
transaction Update Document Set [ ITI-57
] du profil IHE Update Metadata), car celle-ci nécessite une authentification directe (cf la matrice des droits fonctionnels du DMP).
Dans ce contexte, la mise à jour des métadonnées de masquage/démasquage aux PS et de visibilité du document au patient sera gérée comme un remplacement de document, ce qui implique la création d’une nouvelle version de document par le système créateur de documents. Cette nouvelle version vient remplacer la précédente au niveau du consommateur (DMP ou logiciel métier destinataire du courriel).
|
|
web
|
industriels.sesam-vitale.fr
|
dans le contexte français, conformément au volet Partage de documents de santé du CI_SIS
, la mise à jour des métadonnées du document est limitée à la mise à jour des informations de masquage du document aux PS et de mise en visibilité du document au patient et à ses représentants légaux ainsi que le statut du document.
La PFI interagissant avec le DMP en mode d’authentification indirecte, il lui est impossible de mettre en œuvre la transaction TD3.3 (Gestion des attributs d’un document) du profil Alimentation du DMP, décrite dans le Guide d’intégration du DMP
(transaction équivalente à la
transaction Update Document Set [ ITI-57
] du profil IHE Update Metadata), car celle-ci nécessite une authentification directe (cf la matrice des droits fonctionnels du DMP).
Dans ce contexte, la mise à jour des métadonnées de masquage/démasquage aux PS et de visibilité du document au patient sera gérée comme un remplacement de document, ce qui implique la création d’une nouvelle version de document par le système créateur de documents. Cette nouvelle version vient remplacer la précédente au niveau du consommateur (DMP ou logiciel métier destinataire du courriel).
|
|
web
|
profiles.ihe.net
|
dans le contexte français, conformément au volet Partage de documents de santé du CI_SIS
, la mise à jour des métadonnées du document est limitée à la mise à jour des informations de masquage du document aux PS et de mise en visibilité du document au patient et à ses représentants légaux ainsi que le statut du document.
La PFI interagissant avec le DMP en mode d’authentification indirecte, il lui est impossible de mettre en œuvre la transaction TD3.3 (Gestion des attributs d’un document) du profil Alimentation du DMP, décrite dans le Guide d’intégration du DMP
(transaction équivalente à la
transaction Update Document Set [ ITI-57
] du profil IHE Update Metadata), car celle-ci nécessite une authentification directe (cf la matrice des droits fonctionnels du DMP).
Dans ce contexte, la mise à jour des métadonnées de masquage/démasquage aux PS et de visibilité du document au patient sera gérée comme un remplacement de document, ce qui implique la création d’une nouvelle version de document par le système créateur de documents. Cette nouvelle version vient remplacer la précédente au niveau du consommateur (DMP ou logiciel métier destinataire du courriel).
|
|
web
|
www.ihe.net
|
Content Creator (TF PCC : Patient Care Coordination - Appendix A : Actors definition)
|
|
web
|
esante.gouv.fr
|
Volet Partage de documents de santé
dans un contexte général ou le Référentiel Service DMP intégré aux LPS dans le contexte du SEGUR.
|
|
web
|
esante.gouv.fr
|
Volet Echange de documents de santé
|
|
web
|
esante.gouv.fr
|
L’acteur Producteur (Document Source) du volet de Partage de document de santé
, pour permettre à la PFI d’implémenter la transaction ITI-41 Provide & Register Document Set dans un contexte général ou les transactions TDT2.1/TD2.2 (Alimentation du DMP) ou TD3.3c (Gestion des attributs d’un document) dans le contexte SEGUR (pour intégration/remplacement/suppression de document(s) dans le DMP en tenant compte des spécificités ajoutées par le référentiel Service DMP intégré aux LPS),
|
|
web
|
esante.gouv.fr
|
L’acteur Système initiateur du volet d’ Echange de documents de santé
, pour permettre à la PFI de construire l’archive IHE_XDM inclue dans le courriel émis vers le destinataire,
|
|
web
|
esante.gouv.fr
|
Le code RPLC dans clinicalDocument/relatedDocument@typeCode dans le CDA-R2 [cf: volet CI-SIS : CONTENU_VOLET-STRUCTURATION-MINIMALE]
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]
.
|
|
web
|
industriels.sesam-vitale.fr
|
Le code RPLC dans clinicalDocument/relatedDocument@typeCode dans le CDA-R2 [cf: volet CI-SIS : CONTENU_VOLET-STRUCTURATION-MINIMALE]
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]
.
|
|
web
|
esante.gouv.fr
|
Le document est supprimé du DMP (availabilityStatus = Deleted) [cf: volet CI-SIS : CONTENU_VOLET-STRUCTURATION-MINIMALE]
|
|
web
|
esante.gouv.fr
|
TD3.3 (Supprimer un document) [cf: volet CI-SIS : CONTENU_VOLET-STRUCTURATION-MINIMALE]
|
|
web
|
esante.gouv.fr
|
cf : Volet Echange de Documents de Santé
.
|
|
web
|
esante.gouv.fr
|
Les autres données nécessaires aux transactions XDS ou à la création de
l’archive IHE-XDM ne rentrent pas dans le périmètre de cette
spécification, elles sont récupérées de l’en-tête CDA ( ANS – CI-SIS : ANNEXE – LIEN ENTRE L’EN-TETE CDA ET LES METADONNEES XDS
).
|
|
web
|
www.interopsante.org
|
Extension française du profil IHE PAM : PAM.fr, version 2.11
(1),
|
|
web
|
www.interopsante.org
|
Les types de données utilisés (2) doivent se conformer aux
spécifications « INTEROP’SANTE : ITI - 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 - Release 1.8 – Final Text – 31 janvier 2024
»
|
|
web
|
esante.gouv.fr
|
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é
».
|
|
web
|
esante.gouv.fr
|
Dans le cas d’une publication de(s) document(s) sur le DMP, l’INS du
patient doit être qualifié en suivant les spécifications de l’annexe
INS CI-SIS
et les règles du corpus documentaire INS
.
|
|
web
|
esante.gouv.fr
|
Dans le cas d’une publication de(s) document(s) sur le DMP, l’INS du
patient doit être qualifié en suivant les spécifications de l’annexe
INS CI-SIS
et les règles du corpus documentaire INS
.
|
|
web
|
esante.gouv.fr
|
Les données utiles pour publication sur le DMP et pour l’envoi par
MSSanté de(s) document(s) sont stockées à la fois dans le segment PID du
message HL7, dans le document CDA-R2 conforme au volet du CI_SIS Structuration minimale des documents de santé
et dans des segments OBX du message HL7 spécifiant les métadonnées complémentaires.
|
|
web
|
www.interopsante.org
|
Ces deux segments doivent être renseignés conformément à la
spécification « PAM – National extension France » version 2.11
publiée
en 2024. Si l’INS est véhiculé, le segment PID doit suivre les
contraintes décrites dans l’annexe CI-SIS « Prise en charge de
l’identifiant National de Santé (INS) dans les standards
d’interopérabilité et les volets du CI-SIS
».
|
|
web
|
esante.gouv.fr
|
Ces deux segments doivent être renseignés conformément à la
spécification « PAM – National extension France » version 2.11
publiée
en 2024. Si l’INS est véhiculé, le segment PID doit suivre les
contraintes décrites dans l’annexe CI-SIS « Prise en charge de
l’identifiant National de Santé (INS) dans les standards
d’interopérabilité et les volets du CI-SIS
».
|
|
web
|
ansforge.github.io
|
le JDV_J07-XdsTypeCode-CISIS
de la Nomenclature des Objets de Santé (NOS).
|
|
web
|
esante.gouv.fr
|
conformément au volet de Structuration minimale des
documents de santé
, l’identifiant du document au sein du document CDA
s’exprime soit par un OID complet identifiant complètement l’instance du
document (sans extension), soit par une racine d’OID commune à toutes
les instances de documents de l’émetteur associée à une extension propre
à l’instance du document.
|
|
web
|
ansforge.github.io
|
Utiliser le JDV_J07-XdsTypeCode-CISIS
de la Nomenclature des Objets de Santé (NOS).
|
|
web
|
ansforge.github.io
|
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
).
|
|
web
|
ansforge.github.io
|
LN
ou TRE_A05
(lien vers la TRE)
en fonction de l'appartenance du code à l'un des systèmes de codage
|
|
web
|
www.interopsante.org
|
Les champs des segments PRT doivent être renseignés conformément aux
spécifications « 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 » release 1.8
.
|
|
web
|
ansforge.github.io
|
LN
ou TRE_A05
(lien vers la TRE)
en fonction de l'appartenance du code à l'un des systèmes de codage.
|
|
web
|
www.interopsante.org
|
Type d'identifiant du professionnel (valeur issue de la Table 0203 - Interop'Santé
présent dan le document "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")
|
|
web
|
www.interopsante.org
|
Type d'identifiant de l'organisation (valeur issue de la Table 0203 - Interop'Santé
présent dan le document "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") : FINEJ
(FINESS d'entité juridique) ou FINEG
(FINESS d'entité géographique) ou IDNST
.
|
|
web
|
www.interopsante.org
|
Type d'identifiant (valeur issue de la Table 0203 - Interop'Santé
présent dan le document "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") : RPPS
ou INS
ou IDNPS
|
|
web
|
www.interopsante.org
|
Cf 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
.
|
|
web
|
www.interopsante.org
|
Type d'identifiant (valeur issue de la Table 0203 - Interop'Santé
présent dan le document "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") : FINEJ
(FINESS d'entité juridique) ou FINEG
(FINESS d'entité géographique) ou IDNST
ou UF
(UF), SVR
(service).
|
|
web
|
esante.gouv.fr
|
Concernant le point (3), le « Volet Structuration minimale des documents
de santé
» a été modifié de façon à lever la contrainte existante sur
l’élément « participant ». Il est prévu de modifier la prochaine version
du « Volet CR-BIO – Compte-rendu d’examens de biologie médicale » dans
le même sens.
|
|
web
|
industriels.sesam-vitale.fr
|
Cet OBX permet d’informer l’acteur GESTIONNAIRE que le document doit
être utilisé pour une transaction DMP « connexion secrète » ( cf SESAM-VITALE : Service DMP intégré aux LPS - Version 2.10.0 – 07/07/2023
)
|
|
web
|
hl7-definition.caristix.com
|
MSH.3
- Sending Application
|
|
web
|
hl7-definition.caristix.com
|
MSH.5
- Receiving Application
|
|
web
|
hl7-definition.caristix.com
|
MSH.4
- Sending Facility
|
|
web
|
hl7-definition.caristix.com
|
MSH.6
- Receiving Facility
|
|
web
|
hl7-definition.caristix.com
|
MSH.11
- Processing Id
|
|
web
|
hl7-definition.caristix.com
|
MSA.1
- Acknowledgment Code
|
|
web
|
hl7-definition.caristix.com
|
MSA.2
- Message Control Id
|
|
web
|
industriels.sesam-vitale.fr
|
à Utiliser les codes et libellés de codes de l'annexe A7-1 « Liste des codes d'erreurs » de la spécification « Service DMP intégré aux LPS » v.2.10.0
|
|
web
|
esante.gouv.fr
|
Seules les erreurs de niveau applicatif du traitement automatique sur le document au niveau du destinataire final sont remontées au travers du courriel MDN et réceptionnées par le GESTIONNAIRE (la PFI expéditrice).
Les erreurs de type technique (erreurs de syntaxe du message HL7) sont généralement traitées localement, côté du destinataire, par une des intervenants techniques. Dans ces conditions, le segment ERR-3 prend la valeur 207 et le segment ERR-5 contient l’erreur applicative remontée au
travers du courriel MDN. Le message HL7 ZAM^Z03^ZAM_Z01
est généré ple GESTIONNAIRE à partir des informations contenues dans le courriel MDN
(cf structure du MDN – Message Disposition Notification) décrit en Annexe du volet « Transmission au LPS d’un document CDA provenant d’un courriel MSSanté
».
|
|
web
|
esante.gouv.fr
|
Dans le cas où un MDN (Message Disposition Notification) n'a pas été explicitement demandé par le destinataire (via l'entête `Disposition-Notification-To` dans le message d'origine), et que, pour pouvoir gérer toutes les erreurs, on souhaite utiliser une BAL dédiée, un courriel 'standard' peut être utlisé.
La structure du courriel est précisée en annexe du volet Transmission au LPS d'un document CDA provenant d'un courriel MSSanté
.
|
