GT 11 - Amula

Transcription

GT 11 - Amula

GT 11
Document DT11_2004_007
Restreinte au périmètre
Type de diffusion :
Restreinte à EdiSanté
x
Publique
Contenu :
Recommandation MMF - extension MXF
Format "d'enveloppe d'échange médical"
Origine :
Stéphane Croci, Bernard Hervault (ETIAM), Lisbeth Hajji (Cégétel.rss)
Emission :
15 février 2004
Action :
Pour diffusion publique
Etat :
Définitif (version 0.0 établie sur la base version alpha0 déployée et testée)
Commentaires :
DT11_2004_007.doc
Lancés à l'été 2000, les travaux du Groupe de travail GT11 "Echanges
d'éléments de dossier médicaux" de l'organisme de pré-normalisation Edisanté
ont pour objectif d'harmoniser les échanges médicaux par messagerie
sécurisée. Le sous-groupe "enveloppe" a pour but de définir un format de
"container" permettant de regrouper au sein d'un même envoi différents
documents concernant a priori un même patient. Ce document définit :
− le protocole et le format des messages supportant les échanges MMF
(Medical Message Format) "version 0.0" via une messagerie Internet
sécurisée.
− la structure d’une enveloppe MMF.
− Des exemples des différents messages MMF et de visualisation au travers de
clients de messagerie du classiques (annexes A, B, C)
− les extensions à inclure dans une enveloppe MMF sous forme de données
propriétaires pour décrire totalement une enveloppe MXF (annexe D).
Ce document permet un déploiement de solutions opérationnelles
interopérables. Il sert de base à la contribution du GT11 à l'élaboration d'un
standard international dans le domaine.
1
GT 11
SOMMAIRE
1.
1.1
1.2
1.3
INTRODUCTION..................................................................................................................................4
BUT DU DOCUMENT ..............................................................................................................................4
ETAT DU DOCUMENT ............................................................................................................................4
REFERENCES ........................................................................................................................................4
2.
CONTEXTE DES TRAVAUX MMF...................................................................................................5
3.
PROTOCOLE MMF VERSION 0.0 (COMPATIBLE AVEC LA VERSION ALPHA0)..............6
3.1
ARCHITECTURE DU RESEAU SUPPORT ...................................................................................................6
3.2
ENVELOPPE MMF VERSION 0.0 (COMPATIBLE ALPHA0) ......................................................................6
3.3
SECURITE MMF ...................................................................................................................................7
3.4
MESSAGES MMF VERSIONS 0.0 ET ALPHA0.........................................................................................7
3.5
PROTOCOLE D'ECHANGE MMF VERSIONS 0.0 (ET ALPHA0) .................................................................8
3.5.1 Echanges MMF sans demande de MDN .........................................................................................8
3.5.2 Echanges MMF avec demande de MDN.......................................................................................10
3.5.3 Echanges MMF avec demande de DSN (non supporté)................................................................10
4.
MESSAGES SPECIALISES POUR MMF........................................................................................12
4.1
MESSAGES CONCERNES ......................................................................................................................12
4.2
MESSAGE DE DONNEES MMF NON SEGMENTE (MMF-DATA).............................................................13
4.2.1 Début du message [rfc822] commun aux messages de données MMF.........................................13
4.2.2 Suite du message [rfc822] pour les messages de données MMF non sécurisées..........................15
4.2.3 Suite du message [rfc822] pour les messages de données MMF signés .......................................18
4.2.4 Suite du message [rfc822] pour les messages de données MMF chiffrés .....................................18
4.2.5 Suite du message [rfc822] pour les messages de données MMF signés et chiffrés ......................19
4.3
MESSAGE DE NOTIFICATION DE RECEPTION MMF (MMF-MDN) .......................................................20
5.
5.1
5.2
5.3
5.4
6.
MESSAGES NON SPECIALISES POUR MMF ..............................................................................25
MESSAGES CONCERNES ......................................................................................................................25
NOTIFICATION DE NON REMISE SUR INTRANET (DSN-ESMTP) ..........................................................25
NOTIFICATION DE REMISE SUR INTRANET (DSN-ESMTP) (NON SUPPORTE) ......................................25
NOTIFICATION DE NON REMISE SUR INTERNET (DSN-SMTP) (NON SUPPORTE) .................................25
STRUCTURE DU DOSSIER MMF ...................................................................................................26
6.1
INTRODUCTION ...................................................................................................................................26
6.2
STRUCTURE DU DOSSIER ....................................................................................................................26
6.2.1 Attributs dossier ............................................................................................................................26
6.2.2 Attributs patient / collection ..........................................................................................................27
6.2.3 Attributs document ........................................................................................................................27
7.
DESCRIPTION FORMATS DE DONNEES ....................................................................................27
7.1
DOSSIER MMF ...................................................................................................................................27
7.1.1 Contraintes....................................................................................................................................28
7.1.2 Rubrique dossier ...........................................................................................................................28
7.1.3 Rubrique Patient ...........................................................................................................................29
7.1.4 Rubrique Document ......................................................................................................................30
7.2
DOCUMENTS PLANCHES D’IMAGE .......................................................................................................31
8.
ANNEXE A : EXEMPLES DE MESSAGES MMF NON SECURISES .........................................32
8.1
MESSAGE DE DONNEES MMF NON SEGMENTE (MMF-DATA).............................................................32
8.1.1 Envoyé (SMTP) .............................................................................................................................32
8.1.2 Dans la BAL (POP3).....................................................................................................................33
8.1.3 Archivé dans Netscape 4.72 (Inbox)..............................................................................................35
DT11_2004_007.doc
2
GT 11
8.1.4 Visualisé dans Netscape 4.72 ........................................................................................................37
8.1.5 Sauvegarde du fichier attaché "folder.dsc" dans Netscape 4.72 ..................................................37
8.1.6 Sauvegarde du fichier attaché "folder.zip" dans Netscape 4.72 ...................................................38
8.1.7 Visualisé dans Outlook 2000.........................................................................................................39
8.1.8 Sauvegarde du fichier attaché "folder.dsc" dans Outlook 2000 ...................................................40
8.1.9 Sauvegarde du fichier attaché "folder.zip" dans Outlook 2000....................................................41
8.1.10
Netscape 4.61 sous Linux..........................................................................................................41
8.2
MESSAGE DE DONNEES MMF SEGMENTE (MMF-DATA-N) (NON-TRAITE) .........................................41
8.3
NOTIFICATION DE RECEPTION (MMF-MDN) ......................................................................................42
8.3.1 Dans la BAL (POP3).....................................................................................................................42
8.3.2 Archivé dans Netscape 4.72 (Inbox)..............................................................................................43
8.3.3 Visualisé dans Netscape 4.72 ........................................................................................................44
8.3.4 Visualisé dans Outlook 2000.........................................................................................................44
9.
ANNEXE B : EXEMPLES DE MESSAGES MMF SECURISES (NON REDIGE) ......................45
9.1
9.2
9.3
MESSAGE DE DONNEES MMF SIGNE (MMF-DATA-SIGNED) (NON REDIGE) ........................................45
MESSAGE DE DONNEES MMF CHIFFRE (MMF-DATA-CRYPTED) (NON REDIGE)..................................45
MESSAGE DE DONNEES MMF SIGNE ET CHIFFRE (MMF-DATA-SIGNEDANDCRYPTED) (NON REDIGE)45
10.
ANNEXE C : EXEMPLES DE NOTIFICATIONS ESMTP .......................................................46
10.1
10.2
NOTIFICATIONS DE REMISE SUR INTRANET RSS (DSN-ESMTP)........................................................46
NOTIFICATIONS DE NON-REMISE SUR INTRANET RSS (DSN-ESMTP)................................................47
11.
ANNEXE D : EXTENSIONS MXF................................................................................................48
11.1
INTRODUCTION ...................................................................................................................................48
11.2
CONVERSION MXF VERS MMF: GESTION DES CHAMPS PROPRIETAIRES MMF ..................................48
11.3
IDENTIFIANTS DOSSIERS ......................................................................................................................48
11.3.1
Section [DESCRIPTION] .........................................................................................................48
11.3.2
Section [COMMUNICATION] .................................................................................................48
11.3.3
Section [HEALTHCAREPARTY_N] .........................................................................................49
11.4
IDENTIFIANTS DOCUMENTS .................................................................................................................49
DT11_2004_007.doc
3
GT 11
1. Introduction
1.1 But du document
Ce document définit les recommandations MMF permettant l’échange de données
médicales multimédia "version 0.0" via une messagerie Internet sécurisée.
Sont décrits :
-
le protocole et le format des messages supportant les échanges MMF (Medical
Message Format) "version 0.0" via une messagerie Internet sécurisée.
la structure d’une enveloppe MMF.
des exemples des différents messages MMF et de visualisation au travers de clients de
messagerie du classiques (annexes A, B, C).
les extensions à inclure dans une enveloppe MMF sous forme de données propriétaires
pour décrire totalement une enveloppe MXF (annexe D).
1.2 Etat du document
Cette version du document est définitive et permet des implémentations d'échanges
médicaux. Elle sert de base aux travaux du groupe 11 de l’organisme de pré-normalisation
EdiSanté afin de contribuer à un standard d'échange reconnu internationalement.
1.3 Références
[EDISANTE]
< www.edisante.org >
[ebXML]
< http://www.ebxml.org>.
[POP3]
Post Office Protocol - Version 3 (RFC 1939, RFC 1957, RFC 2449, STD
0053)
[SMTP]
Simple Mail Transfer Protocol (RFC 821, BCP 30)
[ESMTP]
Enhanced Simple Message Transfer Protocol (RFC 1425)
[rfc822]
Format des messages SMTP (RFC 822)
[MIME]
Multipurpose Internet Message Extensions (RFC 2045 à RFC 2049)
[MDN]
Extensible Message Format for Message Disposition Notification (RFC
2298)
[DSN]
DSN (RFC 1894, RFC 2852)
[report]
Multipart/report (RFC 1892)
[SMIMEV3]
S/MIME version 3 (RFC 2630, RFC 2632 et RFC 2633)
[RSS]
< http://www.cegetel.rss.fr >
[ETIAM]
< http://www.etiam.com >
[GIP-CPS]
< www.gip-cps.fr >
DT11_2004_007.doc
4
GT 11
2. Contexte des travaux du GT11 et de la recommandation MMF
Lancés à l'été 2000, les travaux du Groupe de travail 11 (GT11) de l'organisme de prénormalisation Edisanté qui réunit éditeurs de logiciels médicaux, opérateurs et utilisateurs
ont pour objectif d'harmoniser les "Echanges d'éléments de dossier médicaux". Ils
prennent pour base la recommandation MMF (Medical Message Format) pour l'échange
de données médicales multimédia sur le Réseau Santé Social.
Ces travaux ont pris comme point de départ les concepts de la messagerie MXF (Medical
eXchange Folder) implémentée par ETIAM pour ses produits mediem. La version initiale
des recommandations MMF est dite version 0.0 (identique à la "version alpha0") et fait
l'objet du présent document.
Un certain nombre de réseaux ont déployés des systèmes interopérables entre eux et basés
sur des logiciels d'origine diverses, développés sur la base de ces recommandations.
En parallèle à ce déploiement, les travaux se poursuivent essentiellement au sein du GT11
pour définir une contribution aux standards internationaux sur la base de cette
recommandation MMF, notamment en tenant compte du standard [ebXML] en cours
d'élaboration, qui intègre la notion d'enveloppe pour les échanges dans de nombreux
domaines d'application.
DT11_2004_007.doc
5
GT 11
3. Protocole MMF version 0.0 (compatible avec la version alpha0)
3.1 Architecture du réseau support
Messages de données MMF
Notifications MMF-MDN
Serveur SMTP
Serveur
(E)SMTP
1
Application
MMF
2
Notifications DSN
3
Serveur
POP3
Notifications DSN
BAL dédiée ou usuelle
BAL
Figure 3-1: Architecture du réseau support.
Une application participant à des échanges MMF peut envoyer des messages de données
MMF et des messages de services MMF à un serveur de messagerie accessible via le
protocole [SMTP] ou [ESMTP].
Cette application dispose d'une BAL hébergée sur un serveur de messagerie accessible via
le protocole [POP3] pour recevoir des messages de données MMF et des messages de
services MMF ou non. Il est recommandé que cette BAL soit différente de celles utilisées
pour l'échange de courriers avec les clients de messagerie habituels (Netscape Messenger,
Microsoft Outlook, etc.). Elle peut être dédiée aux échanges MMF, ou partagée avec des
applications capable d'y prélever uniquement les messages qui leur sont destinés.
Les différents types de message sont décrits dans la suite du document.
3.2 Enveloppe MMF version 0.0 (compatible alpha0)
L'enveloppe MMF repose sur le concept d'une enveloppe numérique référençant et
organisant des documents médicaux multimédia.
Dans ses versions alpha0 et 0.0, le modèle de données induit par ce concept sépare les
informations de l'enveloppe MMF en deux parties :
La description de l'enveloppe : les données d'identification de l'enveloppe et
d'organisation des documents médicaux multimédia qu'elle contient.
Les données : les documents médicaux multimédia proprement dits.
Par suite, une enveloppe MMF version alpha0 est un objet [MIME] "multipart" qui est la
traduction informatique de ce modèle. Cet objet comprend lui-même deux parties
principales :
DT11_2004_007.doc
6
GT 11
Un objet [MIME] contenant la description de l'enveloppe.
Un objet [MIME] contenant les données.
L'objet [MIME] "multipart" qui implémente l'enveloppe MMF est décrit plus précisément
dans la suite du présent document. Un exemple de message MMF contenant une
enveloppe MMF version alpha0 est fourni en annexe.
3.3 Sécurité MMF
La sécurité des échanges MMF est obtenue par signature et chiffrement des objets
[MIME] implémentant les enveloppes MMF.
Le standard utilisé pour réaliser ces opérations est S/MIME version 3 avec une extension
possible pour la gestion de la CPS (Carte de Professionnel de Santé). L'application des
opérations de signature et de chiffrement [SMIMEV3] sur une enveloppe MMF produit un
objet [SMIMEV3] contenant l'enveloppe MMF protégée.
Le protocole est compatible avec le référentiel de messagerie du [GIP-CPS].
Documents médicaux
multimédia
Informations d'identification
et d'organisation
Formatage de
l’enveloppe
Objet [MIME] contenant
l'enveloppe MMF en clair
Signature et/ou
chiffrement
Objet [SMIME] contenant
l'enveloppe MMF protégée
Formatage
/
dé formatage
Message MMF conforme
[rfc822] contenant l'objet
[SMIME]
Emission (E)SMTP
/
Réception POP3
Figure 3-2 : Positionnement de la sécurité dans les traitements.
3.4 Messages MMF versions 0.0 et alpha0
L'échange d'enveloppes MMF versions 0.0 (et alpha0) met en œuvre plusieurs types de
messages pouvant être acheminés par une messagerie Internet :
DT11_2004_007.doc
7
GT 11
Les messages de données MMF transportant les enveloppes MMF protégées ou
non. Un message de données MMF contient une seule enveloppe MMF.
Les messages de service transportant les notifications de remise (DSN ou
"Delivery Status Notification").
Une DSN positive (message délivré) n'est générée par un serveur de messagerie
(ESMTP) que si l'application émettrice l'a explicitement demandée.
Une DSN négative (message non délivré) est générée par un serveur de messagerie
même si l'application émettrice n'a rien demandé. Le formatage d'une DSN varie
selon le type de serveur (SMTP ou ESMTP).
Les messages de service transportant les notifications de réception (MDN ou
"Message Disposition Notification").
Une MDN positive ou négative est générée par l'application destinataire si
l'application émettrice l'a demandée.
Ces messages sont conformes aux standards Internet pour la messagerie définis dans les
RFC citées en référence, en particulier [rfc822], [MIME], [DSN], et [MDN]. Ils sont
décrits plus précisément dans la suite du présent document.
Note : Dans la présente version, les recommandations MMF ne prévoient pas de demande
de DSN. Seules les DSN négatives générées automatiquement par les serveurs ESMTP
doivent être prises en compte par les applications MMF.
Note : Dans la présente version, les recommandations MMF ne prévoient pas de
segmentation des messages.
3.5 Protocole d'échange MMF versions 0.0 (et alpha0)
3.5.1 Echanges MMF sans demande de MDN
3.5.1.1 Sans anomalie de transport
Dans ce type d'échange, l'application émettrice ne demande pas de notification de
réception à l'application destinataire.
Serveur
SMTP
Serveur
POP3
Serveur
SMTP
1
2
3
BAL
Application
émettrice
4
Application
destinataire
Serveur
POP3
Serveur
SMTP
BAL
Figure 3-3: Echange sans MDN et sans erreur.
DT11_2004_007.doc
8
GT 11
L'application émettrice envoie un message MMF, qui ne contient pas de demande de
MDN, à son serveur [ESMTP ou SMTP] sans lui demander une DSN. L'acheminement du
message se passe bien jusqu'à sa remise au serveur POP3 gérant la BAL du destinataire.
L'application émettrice ne reçoit aucune notification et elle peut légitimement considérer
que le message MMF a bien été délivré dans la BAL destinataire.
3.5.1.2 Avec anomalie de transport
Serveur
SMTP
Serveur
SMTP
3
1
Serveur
POP3
2
Pb
BAL
Application
émettrice
Application
destinataire
Serveur
POP3
5
4
Serveur
SMTP
BAL
Figure 3-4: Echange sans MDN et avec erreur.
L'application émettrice envoie un message MMF, qui ne contient pas de demande de
MDN, à son serveur [ESMTP ou SMTP] sans lui demander une DSN. L'acheminement du
message se passe mal. Le serveur [ESMTP] ou [SMTP] ayant détecté le problème renvoie
une notification de non remise ([DSN] négative).
L'application émettrice reçoit dans sa BAL une DSN négative qui lui indique que le
message MMF n'a pas pu être délivré dans la BAL destinataire.
Le formatage de ce message dépend du type de serveur ayant détecté le problème ([SMTP]
ou [ESMTP]). Le format d'une notification renvoyée par un serveur [ESMTP] est
conforme à [DSN]. Le format d'une notification renvoyée par un ancien serveur [SMTP]
est moins bien défini [SMTP].
Note : Un exemple de DSN négative générée par un serveur ESMTP du RSS de Cegetel
est fourni en annexe.
DT11_2004_007.doc
9
GT 11
3.5.2 Echanges MMF avec demande de MDN
Serveur
SMTP
Serveur
POP3
2
Serveur
SMTP
1
3
BAL
Application
émettrice
Serveur
POP3
9
5
4
Application
destinataire
6
8
7
Serveur
SMTP
BAL
Figure 3-5: Echange avec MDN et sans erreur.
L'application émettrice envoie un message MMF, qui contient une demande de MDN, à
son serveur [ESMTP ou SMTP] sans lui demander une DSN. L'acheminement du message
se passe bien jusqu'à sa remise au serveur POP3 gérant la BAL du destinataire.
L'application destinataire récupère le message MMF depuis sa BAL et note que ce
message contient une demande de MDN. Par la suite, elle peut déchiffrer l'enveloppe
MMF qu'il contient et en vérifier la signature, puis exploiter les informations qu'elle
contient pour les afficher, les traiter ou les remettre à une autre application. Elle génère la
notification de réception en indiquant le niveau de traitement atteint (displayed,
dispatched, processed,...) et le problème rencontré le cas échéant (ex: processed/error), et
elle l'envoie vers l'application émettrice du message MMF initial.
L'application émettrice reçoit la notification qui lui indique si l'application destinataire a
pu récupérer le message MMF, le déchiffrer, voire le traiter.
3.5.3 Echanges MMF avec demande de DSN (non supporté)
Serveur
ESMTP
5
Serveur
ESMTP
1
Serveur
POP3
4
2
3
BAL
Application
émettrice
7
Application
destinataire
Serveur
POP3
6
Serveur
SMTP
BAL
Figure 3-6: Echange avec DSN et sans erreur
L'application émettrice envoie un message MMF à son serveur [ESMTP] en lui
demandant une DSN. L'acheminement du message se passe bien jusqu'à sa remise au
serveur POP3 gérant la BAL du destinataire. Le dernier serveur [ESMTP] ayant acheminé
DT11_2004_007.doc
10
GT 11
le message renvoie une notification de remise ([DSN] positive) vers l'application
émettrice.
L'application émettrice reçoit la notification qui lui indique que le message MMF a bien
été déposé dans la BAL destinataire.
Note : Ce scénario est présenté pour information. Il n'est pas prévu dans la présente
version des recommandations qui s'appuie sur les MDN pour gérer ce problème.
DT11_2004_007.doc
11
GT 11
4. Messages spécialisés pour MMF
4.1 Messages concernés
Les messages mis en œuvre dans les échanges MMF sont conformes aux RFC citées en
références. Parmi eux, certains messages doivent respecter des règles supplémentaires
décrites dans le présent document et justifiées par les besoins propres à MMF. Ces
messages dits "spécialisés pour MMF" sont les suivants :
Les messages de données MMF non segmentés (MMF-data).
Les messages de notification de réception MMF (MMF-MDN).
Ces messages [rfc822] ont une entête (header) conforme aux RFC [rfc822], [MIME] et
[MDN] mais la liste des champs et la valeur de certains d'entre eux habituellement libres
dans ces RFC est imposée dans le contexte MMF.
Le format de ces messages est décrit dans la suite de ce document. Les messages de
données MMF sont décrits sous leur forme non protégée et sous leur forme protégée.
Note : Le format définitif des messages sous leur forme protégée est conditionné par des
expérimentations qui resteront à réaliser : doivent être prises en compte à la fois la
meilleure conformité possible aux RFC et la recherche d’interopérabilité entre les
différentes solutions de sécurité disponibles.
Note : En cas d'ambiguïté sur la sémantique ou la valeur d'un champ, se reporter à la
RFC citée pour ce champ.
DT11_2004_007.doc
12
GT 11
4.2 Message de données MMF non segmenté (MMF-data)
4.2.1 Début du message [rfc822] commun aux messages de données MMF
RFC
R/O
822
R
Message-ID:
2298
O
Disposition-NotificationTo:
822
R
Date:
822
R
From:
822
O
Reply-To:
822
R
Subject:
822
O
To:
DT11_2004_007.doc
FIELD-NAME
FIELD-BODY (VALUE)
COMMENTS AND SAMPLE VALUES
BEGINNING OF HEADER RFC822
Identification unique du message. Créé à partir du nom
<domain-uniq-id @domain>
de domaine de l'expéditeur et d'un identificateur unique
dans ce domaine.
Ex: <[email protected]>
Demande de notification de réception MDN et adresse où
phrase <mailbox> | mailbox
l'envoyer. Limité à une seule adresse dans MMF.
Ex: Alice Merveille <[email protected]>
Ex: [email protected]
Date et heure, en indiquant le décalage par rapport à
day, date month year hour:min:sec
l'heure GMT (+1 heure pour la France).
GMTdelta
Ex: Thu, 14 Dec 2000 10:08:01 +0100
Adresse de l’expéditeur du message.
Adresse de réponse au message. Si ce champ n'est pas
renseigné, la réponse sera renvoyée à l'adresse spécifiée
par "From".
Ex: Alice Merveille <[email protected]>,
[email protected]
Ex:[email protected], [email protected]
Sujet du message commençant par le préfixe
MMF/0.0/MSG: phrase
"MMF/0.0/MSG: Identifie un message MMF version 0.0
(ou alpha0) qui est un message de données. Il est suivi
d'un texte libre.
Ex: MMF/0.0/MSG: Demande d'avis.
Ex: MMF/0.0/MSG: Compte-rendu du cabinet FunRadio.
phrase <mailbox> | mailbox [, phrase Adresse des destinataires du message.
13
GT 11
Note : Une adresse au moins doit être fournie, soit dans
le champ "To:", soit dans le champ "CC:".
phrase <mailbox> | mailbox [, phrase Adresse des destinataires en copie.
Note : Une adresse au moins doit être fournie, soit dans
<mailbox> | mailbox ]
le champ "To:", soit dans le champ "CC:".
Priorité ou importance du message : 1=highest, 2=high,
1|2|3|4|5
3=normal, 4=low, 5=lowest.
Ex: 2 (high)
Note : Les parenthèses indiquent un commentaire.
Note : Le champ apparenté "Importance" n'est pas géré
(cf. annexes).
application-name
Nom de l'application ayant composé le message.
Ex: mediem
application-version
Version de l'application ayant composé le message.
Ex: 1.0
Protocole
MMF version 0.0 (ou alpha0).
0.0
Le "body" du message est une entité MIME version 1.0.
1.0
<mailbox> | mailbox ]
822
O
CC:
822
O
X-Priority:
822
R
X-Mailer:
822
O
X-Mailer-Version:
822
2045
R
R
X-MMF-Version:
MIME-Version :
Colonne "R/O": R =Requis, O=Optionnel. Ces contraintes sont celles de MMF. Un champ optionnel dans les RFC peut donc être requis
dans MMF.
Colonne "Field-body": Les valeurs en italiques doivent être substituées par une valeur applicative en respectant les règles d'encodage si
besoin. Les caractères soulignés sont obligatoires et ne doivent pas être substitués, le caractère "|" indique un choix, les caractères "[" et "]"
encadrent une phrase facultative.
DT11_2004_007.doc
14
GT 11
4.2.2 Suite du message [rfc822] pour les messages de données MMF non sécurisées
RFC
R/O
2045
R
Content-Type :
multipart/mixed;
boundary="boundary"
2046
822
R
R
Content-Description:
MMF/0.0
CRLF
2046
FIELD-NAME
FIELD-BODY (VALUE)
END OF HEADER RFC822
L'entité MIME contient plusieurs entités MIME séparées
par un délimiteur "boundary". La valeur de "boundary"
est une combinaison quelconque d'au plus 70 caractères
US-ASCII.
Ex: multipart/mixed; boundary="=====mmf721A2a3060D"
Enveloppe MMF version 0.0 (ou alpha0).
Ligne vide obligatoire séparant la partie "header" de la
partie "body".
TOP LEVEL MIME BODY
PREAMBLE FOR "NOT MIME ENABLE" RECIPIENTS
phrase
Préambule codé en "US-ASCII" destiné aux applications
ne supportant pas MIME.
Ex:
R
Ceci est un message MMF (Medical Message
Format) prevu pour etre traite par un
logiciel de messagerie specialise.
Si vous pouvez lire ce texte, votre logiciel de
messagerie n'est probablement
pas capable de manipuler des messages formates
selon MIME, et vous ne pourrez
vraisemblablement pas exploiter ce message.
2046
2046
O
R
2046
2046
R
R
DT11_2004_007.doc
Ligne vide pour une meilleure lisibilité.
Délimiteur précédé de 2 caractères "-".
Ex: --=====mmf-721A2a3060D
PREAMBLE FOR "NOT MMF ENABLE" RECIPIENTS
text/plain; charset=iso-8859-1
En théorie, le type d'encodage devrait plutôt être
8bit
"quoted-printable" pour traverser sans dommage les
anciens serveurs fonctionnant en mode "7 bits". Le choix
"8bit" est justifié par les essais effectués : Netscape et
Outlook utilisent cet encodage, et un serveur du réseau
convertit automatiquement le "quoted-printable" en
CRLF
--boundary
Content-Type:
Content-TransferEncoding:
15
GT 11
2046
R
CRLF
2046
R
phrase
"8bit".
partie "body".
Préambule destiné aux applications supportant MIME
mais pas MMF.
Ex:
Ceci est un message MMF (Medical Message
Format) prévu pour être traité par un
logiciel de messagerie spécialisé.
Si vous pouvez lire ce texte, votre logiciel de
messagerie ne peut probablement
pas vous présenter le message MMF lui-même que
sous forme de fichiers attachés.
Vous pouvez sauver ces fichiers sur votre
disque avant de les exploiter manuellement.
2046
2046
O
R
2046
R
Content-Type:
2046
R
2046
2046
R
R
CRLF
--boundary
O
R
2046
R
Content-Type:
2046
R
2046
R
DT11_2004_007.doc
MMF ENVELOPE DESCRIPTOR
MIME body part contenant la partie "description" de
application/x-mmf-dsc;
l'enveloppe MMF.
name="folder.dsc"
Encodage en base 64.
base64
MMF/0.0
CRLF
Base64-encoded-mmf-envelopedescriptor
CRLF
--boundary
2046
2046
Ex: --=====mmf-721A2a3060D
partie "body".
Ex: --=====mmf-721A2a3060D
MMF ENVELOPE DOCUMENTS
MIME body part contenant la partie "documents" de
application/x-mmf-doc;
l'enveloppe MMF sous forme d'un fichier compressé au
name="folder.zip";
format ZIP.
encoding="zip"
Encodage en base 64.
base64
MMF/0.0
16
GT 11
2046
2046
2046
partie "body".
R
CRLF
O
R
Base64-encoded-mmf-envelope-zipeddocuments
CRLF
Délimiteur de fin précédé de 2 caractères "-" et suivi de 2
--boundary -caractères "-".
Ex: --=====mmf-721A2a3060D--
Note : Dans un message [rfc822], la partie "header" s'achève juste avant la première ligne vide rencontrée, et la partie "body" commence
juste après celle-ci. A contrario, l'entité MIME de plus haut niveau commence avec la ligne contenant le paramètre "Content-Type" qui
appartient au "header" rfc822 et se poursuit avec le "body" rfc822. De façon générale, l'enveloppe MMF correspond à l'entité MIME de plus
haut niveau.
DT11_2004_007.doc
17
GT 11
4.2.3 Suite du message [rfc822] pour les messages de données MMF signés
RFC
R/O
2633
R
Content-Type :
2633
R
2633
R
Content-Disposition:
822
R
2633
R
822
R
FIELD-NAME
FIELD-BODY (VALUE)
application/x-pkcs7-mime;
name="smime.p7m"; smimetype=signed-data
base64
Attachment;
filename="smime.p7m"
CRLF
MIME BODY
Capsule CMS
Dans la RFC, le premier paramètre vaut "pkcs7-mime" et
non "x-pkcs7-mime".
partie "body".
Capsule CMS (cf. [SMIMEV3]) contenant les données signées
et la signature (mode encapsulé).
Fin du message.
CRLF
4.2.4 Suite du message [rfc822] pour les messages de données MMF chiffrés
RFC
R/O
FIELD-NAME
FIELD-BODY (VALUE)
2633
R
Content-Type :
2633
R
2633
R
822
R
Attachment;
CRLF
2633
R
Capsule CMS
Capsule CMS (cf. [SMIMEV3]) contenant les données
chiffrées.
822
R
CRLF
Fin du message.
name="smime.p7m"; smimetype=envelopped-data
base64
non "x-pkcs7-mime".
partie "body".
MIME BODY
DT11_2004_007.doc
18
GT 11
4.2.5 Suite du message [rfc822] pour les messages de données MMF signés et chiffrés
RFC
R/O
FIELD-NAME
R
Content-Type :
2633
R
2633
R
822
R
FIELD-BODY (VALUE)
name="smime.p7m"; smimetype=envelopped-data
base64
Attachment;
CRLF
non "x-pkcs7-mime".
La signature est appliquée avant le chiffrement.
partie "body".
MIME BODY
2633
R
Capsule CMS
Capsule CMS (cf. [SMIMEV3]) contenant le résultat du
chiffrement de la capsule CMS contenant les données signées et
la signature (mode encapsulé).
822
R
CRLF
Fin du message.
DT11_2004_007.doc
19
GT 11
4.3 Message de notification de réception MMF (MMF-MDN)
Note : L'application qui traite un message contenant une demande de MDN ne doit renvoyer au plus qu'une seule notification MDN.
RFC
R/O
822
R
822
R
822
R
822
R
822
R
822
R
822
O
822
2045
R
R
DT11_2004_007.doc
FIELD-NAME
FIELD-BODY (VALUE)
HEADER RFC822
Identification unique du message MDN. Créé à partir du
nom de domaine de l'expéditeur et d'un identificateur
unique dans ce domaine.
Date et heure, en indiquant le décalage par rapport à
day, date month year hour:min:sec
Date:
l'heure GMT (+1 heure pour la France).
GMTdelta
Ex: Thu, 14 Dec 2000 10:08:01 +0100
Adresse de l’expéditeur du message MDN.
From:
Sujet du message commençant par le préfixe
Subject:
MMF/0.0/MDN: phrase
"MMF/0.0/MDN: Identifie un message MMF version 0.0
(ou alpha0) qui est un MDN. Suivi d'un texte libre.
Ex: MMF/0.0/MDN: Demande d'avis.
Ex: MMF/0.0/MDN: Compte-rendu du cabinet
FunRadio.
Adresse du destinataire du message MDN. Limité à une
To:
seule adresse dans MMF. L'adresse à utiliser est la valeur
du paramètre "Disposition-Notification-To:" du
message initial.
application-name
Nom de l'application ayant composé le message MDN.
X-Mailer:
Ex: mediem-box
application-version
Version de l'application ayant composé le message
X-Mailer-Version:
MDN.
Ex: 1.0
Protocole MMF version alpha0.
X-MMF-Version:
0.0
Le "body" du message est une entité MIME version 1.0.
MIME-Version :
1.0
END OF HEADER RFC822 / BEGINNING OF TOP LEVEL MIME BODY
Message-ID:
<domain-uniq-id @domain>
20
GT 11
2298
R
822
R
2046
R
Content-Type :
L'entité MIME contient plusieurs entités MIME séparées
par un délimiteur "boundary". La valeur de "boundary"
est une combinaison quelconque d'au plus 70 caractères
US-ASCII.
Ex: multipart/report; boundary="=====mmf721A2a3060D"
CRLF
partie "body".
PREAMBLE FOR "NOT MIME ENABLE" RECIPIENTS
phrase
Préambule codé en "US-ASCII" destiné aux applications
ne supportant pas MIME.
Ex:
multipart/report; reporttype=disposition-notification;
boundary="boundary"
Ceci est un message "multi-part" au format
MIME.
2046
2046
CRLF
--boundary
O
R
MDN HUMAN READABLE EXPLANATION
2298
R
Content-Type:
2298
R
text/plain; charset=iso-8859-1
8bit
2046
R
CRLF
2046
R
phrase
Ex: --=====mmf-721A2a3060D
En théorie, le type d'encodage devrait plutôt être
"quoted-printable" pour traverser sans dommage les
anciens serveurs fonctionnant en mode "7 bits". Le choix
"8bit" est justifié par les essais effectués : Netscape et
Outlook utilisent cet encodage, et un serveur du réseau
convertit automatiquement le "quoted-printable" en
"8bit".
partie "body".
Préambule destiné aux applications supportant MIME
mais pas MMF.
Ex:
Ceci est un accusé de réception pour le message
MMF (Medical Message Format) que vous avez
envoyé à [email protected] le 13/12/00 15:39. Il
indique que ce message a été affiché, mais il
ne garantit pas que ce message a été lu ou
compris.
Ex:
DT11_2004_007.doc
21
GT 11
Idem, mais indique que le message n'a pu être
affiché.
2046
2046
CRLF
--boundary
O
R
MDN DISPOSITION NOTIFICATION
2298
R
Content-Type:
2298
R
2046
R
message/disposition-notification
7bit
CRLF
2298
R
Reporting-UA:
dns-name; application-name
[application-version]
2298
O
Original-Recipient:
rfc822; mdn-recipient-mailbox
2298
R
Final-Recipient:
rfc822; mdn-sender-mailbox
2298
R
Original-Message-ID:
Original-message-id
2298
R
Disposition:
action-mode/sending-mode;
disposition-type[/dispositionmodifier[, disposition-modifier]]
2298
O
Failure:
phrase
DT11_2004_007.doc
Ex: --=====mmf-721A2a3060D
partie "body".
Identification de la machine et de l'application qui ont
traité le message pour lequel est généré ce MDN.
Ex: host24; myappli0.1
Adresse destinataire du message initial.
Note : Ce champ doit être ajouté si le champ "OriginalRecipient" est présent dans le message initial.
Ex: Original-Recipient: rfc822;
mailto:[email protected]
Adresse de l'expéditeur du message MDN.
Ex: Final-Recipient: rfc822; [email protected]
"Message-ID" du message pour lequel est généré ce
MDN.
Ex: Original-Message-ID: <[email protected]>
action-mode = "manual-action" | "automatic-action"
sending-mode = "MDN-sent-manually" | "MDN-sent
automatically"
disposition-type = "displayed" | "dispatched" |
"processed" | "deleted" | "denied" | "failed"
disposition-modifier = "error" | "warning" | "superseded"
| "expired" | "mailbox-terminated"
Ex: manual-action/MDN-sent-manually;
displayed/warning
Note: Lire RFC2298 page 13 et suivantes.
Texte explicatif si le paramètre "disposition-type vaut
"failed".
22
GT 11
2298
O
2298
O
2046
2046
O
R
1892
2298
R
2046
R
2298
Ex: Failure: Not enough memory available.
phrase
Texte explicatif si le paramètre "dispositionError:
modifier"vaut "error".
Ex: Error: Bad MMF message.
phrase
Texte explicatif si le paramètre "dispositionWarning:
modifier"vaut "warning".
Ex: Warning: Bad MMF message version.
CRLF
--boundary
Ex: --=====mmf-721A2a3060D
MDN ORIGINAL PORTION OF MESSAGE (FACULTATIF, MAIS CONSEILLE)
MIME body part contenant la partie "header" du message
Content-Type:
text/rfc822-headers
MMF pour lequel ce MDN est généré.
Content-Transfer7bit
Encoding:
CRLF
partie "body".
Rfc822-header
Entête rfc822 du message initial.
Ex:
>From ecordonn Fri Dec 15 10:20:19 2000
Received: from etiam.com
(1cust163.tnt1.dial.ren1.fr.uu.net
[212.155.1.163])
by CarlCox.iway.fr (8.9.3/8.8.7) with
SMTP id KAA13889386;
Fri, 15 Dec 2000 10:18:42 +0100 (MET)
Message-ID:
<[email protected]>
Disposition-Notification-To: Bernard Hervault
<[email protected]>
Date: Tue, 14 Dec 2000 17:50:42 +0100
From: Bernard Hervault
<[email protected]>
Reply-To: Alice Merveille <[email protected]>
Subject: MMF: Exemple de message MMF version
0.0 (ou alpha0).
To: Bernard Hervault
<[email protected]>, [email protected]
CC: Alice Merveille <[email protected]>
X-Priority: 1
X-Mailer: mediem-box
DT11_2004_007.doc
23
GT 11
X-Mailer-Version: 0.0
X-MMF-Version: 0.0
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=====mmf-9QIWKGMMYJ0CCJD0"
Content-Description: MMF/0.0
X-UIDL: b014e852357696d99903dc37082cec53
2046
2046
O
R
DT11_2004_007.doc
CRLF
--boundary --
Délimiteur de fin précédé de 2 caractères "-" et suivi de 2
caractères "-".
Ex: --=====mmf-721A2a3060D--
24
GT 11
5. Messages non spécialisés pour MMF
5.1 Messages concernés
Comme décrit dans le chapitre précédent, les applications MMF utilisent des messages
"spécialisés pour MMF" générés par les applications MMF. Mais elles doivent aussi
savoir traiter des messages générés par les serveurs de messagerie du réseau, voire par des
applications qui ignorent tout du protocole MMF.
Les messages reçus d'applications "non MMF" sont inévitables et doivent être traités par
les applications MMF, probablement en fonction d'une décision de l'utilisateur.
Les messages reçus des serveurs de messagerie sont des notifications de type DSN
(Delivery Status Notification). Le format d'un message de type DSN dépend du serveur de
messagerie qui l'a généré : serveur ESMTP ou serveur SMTP (certains cas sur Internet).
Note : Seul le cas ESMTP est traité dans le protocole MMF version 0.0 (ou alpha0).
5.2 Notification de non remise sur Intranet (DSN-ESMTP)
Un exemple de notification de non-remise (DSN négative) générée par un serveur de
messagerie de l'Intranet RSS de Cegetel.rss est fourni en annexe.
5.3 Notification de remise sur Intranet (DSN-ESMTP) (non supporté)
Le protocole MMF version 0.0 (ou alpha0) ne gère pas les demandes de DSN. Une
application MMF ne peut pas demander explicitement une notification de remise (DSN)
au réseau, et celui-ci ne peut donc pas lui renvoyer une notification de remise positive.
Note : Pour information, un exemple de notification de remise (DSN positive) générée par
un serveur de messagerie de l'Intranet RSS de Cegetel.rss est fourni en annexe.
5.4 Notification de non remise sur Internet (DSN-SMTP) (non supporté)
Les notifications de non remise sont au format RFC1894 décrite plus haut. Les éventuelles
notifications de non remise à un autre format ne sont pas prises en comptes comme telles,
et elles sont traitées comme un message "non MMF".
DT11_2004_007.doc
25
GT 11
6. Structure du dossier MMF
6.1 Introduction
Le dossier MMF est un dossier médical multimédia, qui permet de transporter dans une
"enveloppe virtuelle" des documents de toute nature (textes, images, sons, données)
concernant un patient ou un thème (collection de données ne concernant pas un seul
patient).
L’ "enveloppe virtuelle" correspond à une description des informations liées au dossier et
à chaque document du dossier.
Pour permettre l’utilisation de ce dossier d'échange médical, un format d’échange basé sur
le standard MIME est défini.
6.2 Structure du dossier
Un dossier d'échange médical MMF est représenté par un répertoire du système de
fichiers. Ce répertoire contient les différents fichiers (ou hiérarchie de fichiers)
correspondant aux documents présents dans le dossier d’échange, ainsi qu’un fichier de
description donnant la structure du dossier.
La structure du dossier est décomposée en 3 rubriques principales :
Dossier : informations d’identification, de typage et de présentation du dossier
Patient/collection : identification du patient ou de la collection
Documents : informations d’identification, de typage et de présentation de chaque
document contenu dans le dossier.
6.2.1 Attributs dossier
Il s’agit des attributs permettant l’exploitation du dossier :
Version MMF
Type : Patient/Collection
Date et heure de création
Identifiant créateur : id unique (e.g. IDNAT), nom
Identification dossier : unique (généré à la création),
Description : champ libre
DT11_2004_007.doc
26
GT 11
Données propriétaires : données applicatives textuelles libres regroupées par
propriétaire
6.2.2 Attributs patient / collection
Informations permettant d’identifier le patient y compris dans un référentiel particulier :
Nom (Patient / Collection)
Prénom
Sexe
Date de naissance
Médecin référent
Adresse
Identifiant patient dans un référentiel donné
6.2.3 Attributs document
Informations permettant l’exploitation des documents du dossier :
Référence du document : relative au dossier, URL absolue
Format (MIME Type, encodage)
Date et heure de création
Identifiant document : unique (généré à la création)
Données propriétaires : données applicatives textuelles libres regroupées par
propriétaire
7. Description formats de données
7.1 Dossier MMF
Le dossier MMF est implémenté sous la forme d’un répertoire du système de fichiers
contenant :
un fichier de description folder.dsc, au format ".ini" de MS Windows, structuré en 3
rubriques principales : dossier, patient/collection, document
les fichiers (ou hiérarchies de fichiers) correspondant à chacun des documents du
dossier
DT11_2004_007.doc
27
GT 11
Exemple d’implémentation de dossier MMF
7.1.1 Contraintes
Pour préserver le maximum de compatibilité, notamment au niveau de l’encodage MIME
du dossier, les contraintes suivantes doivent être respectées :
Les noms des fichiers contenus dans le dossier doivent être au format US-ASCII
(ASCII 7 bits) et ne pas dépasser 31 caractères (contrainte MacOS) exceptés les
documents de type hiérarchie de fichiers (arborescence html, …).
Les données de type date présentes dans le fichier folder.dsc sont au format
YYYYMMJJ, les donnée de type heure sont au format HHMMSS et exprimées en
Temps Universel.
7.1.2 Rubrique dossier
Section [DESCRIPTION]
Champ
Type
Format
FolderType
Chaîne de
caractères
Chaîne de
caractères
Enum
CreationDate
Date
R
CreationTime
Heure
R
Heure valide
CreatorUID
Chaîne de
caractères
Chaîne de
caractères
Chaîne de
caractères
Chaîne de
caractères
Chaîne de
caractères
Entier
R
Identifiant
unique
Version
CreatorName
FolderUID
ModifID
Description
NumberOfDocu
ments
DT11_2004_007.doc
Requis /
Optionnel
R
Valeurs
autorisées
MMF
R
0.0
R
Description
Format de description
Numéro de version du format de
description
PATIENT
Type de dossier (patient ou
COLLECTION collection)
Date valide
Date de création du dossier
Heure de création du dossier
O
Identifiant unique du créateur du
dossier
Nom du créateur du dossier
R
Identifiant unique de dossier
R
Identifiant secondaire de dossier
O
Description du dossier
R
Nombre de documents
28
GT 11
Sections [X-ownerID] (données privées)
On trouve autant de sections que de "propriétaire" déclaré. Le nombre et la valeur des tags
est libre. Le nom de la section est la concaténation de "X-" avec une chaîne de caractères*
fournie par l’utilisateur de l’API (correspondant au OwnerID)
Champ
Type
OwnerID
Chaîne de
caractères
Chaîne de
caractères
Chaîne de
caractères
Chaîne de
caractères
Tag1
…
TagN
Requis /
Optionnel
R
Valeurs
autorisées
Description
Identifiant propriétaire des
données
O
O
O
*Rappel : la valeur ownerID ne doit pas comprendre le caractère ‘|’
7.1.3 Rubrique Patient
Section [PATIENT]
Champ
Type
Name
Sex
Chaîne de
caractères
Chaîne de
caractères
Enum
BirthDate
Date
FirstName
Requis /
Optionnel
R
Valeurs
autorisées
Nom du patient
R
GeneralPhysician Chaîne de
caractères
Address
Chaîne de
caractères
NumberOfID
Entier
Description
Prénom du patient
R
M, F, O
R
Date valide
Sexe du patient
Date de naissance du patient
O
Médecin référent du patient
O
Adresse du patient
R
Nombre d’identifications patient
Remarque : Dans le cas d’un dossier de type COLLECTION, seul le champ Name est
obligatoire.
Sections [PATIENTID_N]
On trouve autant de sections PATIENTID que d’ "Identifications Patient" déclarées.
L’indice N commence à 0.
DT11_2004_007.doc
29
GT 11
Champ
Type
HCP_UID
Chaîne de
caractères
Chaîne de
caractères
HCP_OtherID
PatientUID
PatientOtherID
Requis /
Optionnel
R
Valeurs
autorisées
Identifiant unique du référentiel
(N° FINESS/ADELI/…)
Identifiant secondaire du
référentiel (service, unité de soins,
…)
Identifiant unique du patient dans
le référentiel
Identifiant secondaire du patient
dans le référentiel (N°
séjour/examen/…)
O
Chaîne de
caractères
Chaîne de
caractères
Description
R
O
7.1.4 Rubrique Document
Section [DOCUMENT_N]
On trouve autant de sections DOCUMENT que de documents déclarées dans le dossier.
L’indice N commence à 0.
Champ
Type
FileName
Chaîne de
caractères
OriginalFileName Chaîne de
caractères
Requis /
Optionnel
R
O
MimeType
Chaîne de
caractères
R
UID
Chaîne de
caractères
Chaîne de
caractères
R
Semantics
Description
Encoding
X-OwnerID|Tag
Chaîne de
caractères
Chaîne de
caractères
Chaîne de
caractères
DT11_2004_007.doc
O
Valeurs
Description
autorisées
Nom de fichier Nom du fichier correspondant au
document ou au descripteur du
valide, relatif
document (série d’images).ou au
par rapport au
document principal (hiérarchie de
répertoire du
documents)
dossier.
Nom original du fichier
Nom de fichier
correspondant au document
valide, relatif
par rapport au
répertoire du
dossier.
MIME Type Type MIME du document
valide +
series/dcmseries
Généré par
l’API
note
report
series
autres
Identifiant unique de document
Sémantique du document
O
Description du document
O
Encoding des documents textuels
O
Données privées
30
GT 11
N.B. : Dans le cas d’un document de type hiérarchie de fichiers, le champ FileName sera
constitué d’un nom de sous-répertoire concaténé avec le caractère séparateur ‘/’ puis avec
le nom du fichier "document principal". Par exemple index.html/index.html
Les champs données privées sont construits en concaténant les éléments suivants:
La chaîne de caractères "X-" qui identifie les champs propriétaires,
l'identifiant du propriétaire de la donnée (OwnerID, qui ne doit pas inclure le
caractère ‘|’),
le caractère de séparation "|",
l'identifiant de la donnée privée (Tag)
7.2 Documents planches d’image
Les documents "Planches d’images DICOM" sont implémentés sous la forme de fichiers
de description portant l’extension ".dsc", au format ".ini" de MS Windows.
Section [DESCRIPTION]
Champ
Type
Format
Chaîne de
caractères
Chaîne de
caractères
Entier
Version
NumberOfImage
s
Requis /
Optionnel
R
Valeurs
autorisées
MMF
R
0.0
R
Description
Format de description
Version MMF
Nombre d’images dans la planche
Sections [IMAGE_N]
On trouve autant de sections IMAGE que d’images déclarées dans la planche. L’indice N
commence à 0.
Champ
Type
FileName
Chaîne de
caractères
Entier
WindowLevel
WindowWidth
Entier
positif
OriginalFileNam Chaîne de
e
caractères
DT11_2004_007.doc
Requis /
Optionnel
R
R
R
O
Valeurs
autorisées
Description
Nom du fichier DICOM
Niveau de la fenêtre de
visualisation
Largeur de la fenêtre de
visualisation
Nom de fichier Nom original du fichier
valide, relatif correspondant à l'image
par rapport au
répertoire du
dossier.
31
GT 11
8. Annexe A : Exemples de messages MMF non sécurisés
8.1 Message de données MMF non segmenté (MMF-data)
Note : Le contenu du message est fourni en entier pour permettre la répétition du test via
une opération de copier/coller.
8.1.1 Envoyé (SMTP)
MAIL FROM: [email protected]
250 [email protected]... Sender ok
RCPT TO: [email protected]
250 [email protected]... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Message-ID: <[email protected]>
Disposition-Notification-To: Bernard Hervault <[email protected]>
Date: Tue, 14 Dec 2000 17:50:42 +0100
From: Bernard Hervault <[email protected]>
Subject: MMF/0.0/MSG: Exemple de message MMF version 0.0 (ou alpha0).
To: Bernard Hervault <[email protected]>, [email protected]
X-Priority: 1
X-MMF-Version: 0.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=====mmf-9QIWKGMMYJ0CCJD0"
Ceci est un message MMF (Medical Message Format) prevu pour etre traite par un
Si vous pouvez lire ce texte, votre logiciel de messagerie n'est probablement
pas capable de manipuler des messages formates selon MIME, et vous ne pourrez
vraisemblablement pas exploiter message.
--=====mmf-9QIWKGMMYJ0CCJD0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Ceci est un message MMF (Medical Message Format) prévu pour être traité par un
Si vous pouvez lire ce texte, votre logiciel de messagerie ne peut probablement
vous présenter le message MMF lui-même que sous forme de fichiers attachés.
Vous pouvez sauver ces fichiers sur votre disque avant de les exploiter
manuellement.
Content-Type: application/x-mmf-dsc; name="folder.dsc"
Content-Transfer-Encoding: base64
W0RFU0NSSVBUSU9OXQ0KVmVyc2lvbj0wLjANCkRlc2NyaXB0aW9uPQ0KRm9sZGVyVHlwZT1QQVRJ
RU5UDQpDcmVhdGlvbkRhdGU9MjAwMDEyMTINCkNyZWF0aW9uVGltZT0xMTIwMzcNCkZvbGRlclVJ
RD0xMjM0LjAwMTIxMi4xMTIwMzcxOTAwNA0KTnVtYmVyT2ZEb2N1bWVudHM9MQ0KW1BBVElFTlRd
DQpOYW1lPUR1cG9uZA0KRmlyc3ROYW1lPUxvdWlzDQpHZW5lcmFsUGh5c2ljaWFuPQ0KU2V4PU0N
CkJpcnRoRGF0ZT0xOTUwMDEwMQ0KQWRkcmVzcz0NCk51bWJlck9mSUQ9MA0KW0RPQ1VNRU5UXzBd
DQpGaWxlTmFtZT1tbWYuMDAxMjEyLjExMjAzNzE5MDE0LnR4dA0KTWltZVR5cGU9dGV4dC9wbGFp
bg0KRGVzY3JpcHRpb249DQpTZW1hbnRpY3M9bm90ZQ0KVUlEPTEyMzQuMDAxMjEyLjExMjAzNzE5
DT11_2004_007.doc
32
GT 11
MDExDQpFbmNvZGluZz1JU084ODU5XzENCg==
Content-Type: application/x-mmf-doc; name="folder.zip"; encoding="zip"
UEsDBBQAAAAIAJNijCmiHn7C0ggAAKQTAAAaAAAAbW1mLjAwMTIxMi4xMTIwMzcxOTAxNC50eHSd
WM1uG0cSPmeAeYcG90DJkMa0aNmWTstQdMKFRHFFJr4ECFozTaqzM9OT7h5aeQ0/4SKXaHLOA+xX
3T3kkLIdYGHAgKar6+erqq+q+c037MWLF2x2u5ws2OKHO3Y9Yde3303H08k1u5lcTSc3JBBH9O9V
wn6c3C2mt7M4GgtrBdsIbaQqWVazXK1lKkXOeoXIpCh6TBjL6nInlKqiyp9wy/DSxFH6IFcrLQpR
WpYJwzJVlo0wCVtwljWlKmTJLd0jPUEpe5WcCXYlCtVLvE9n8Gl0Pb2aLifsCr6P2PV0PJmNJ3F0
zdmG5zKTtoEBlnOWy1SUqWBZv7Yyl2an36i6kEYwXj8yK3RB/ggvb0QckX9tgIZNltPRDTtKVyTA
1/rnVWIf7XHwaJiw6WyxHF1fj5aAirzyQMbRtDSW57nQLBc7wEJo/2UV11ZqAnN8BR+ll3ZOBt2v
E0SI4G4ms2VX8TiXv9ZQa2qn+l7VFoH1rpqCay10L8Tfu6c/Hdr29/RBmN4JiyPT5CIlI6V3DBmp
We8mZLGqpdnmNIH4QiKrEDKGrwlKAZUwa/p8tZJQymSZwRuOtMInUkifpdBxVJhNqm2S5Tkr+wR7
xQ3jaQpd8h6ClVZpk8ELlEqBOqmlvYyjU6ZFqipoYB0FlW4MlQ4yZ9hH2FQfzU/mN2MdlAhW81Si
+pA8hydVYRy9YOPLnw6kK+VQM6wC1mKlXPY/eBl2cf7y4t3uXmnDreHZ1+/NlpSv8wRZWnypHOgc
PTXS+k9LWTdCbwjKq+n4FscLJS3jdIjIXRq0yEJGO/6dAIKOIGBs9cSR08QWViHri/GcHe3lGt8r
UoQThJOhK7fpjyOfzYYJNG4e8unKqy/Tv4CrFiEDdICCyKShdANmy+Djr3XDoKUH3b2gmrNO+XEq
v20UMHLPfcv1m1Tz0jfTeYL2noFp1G+u1upghXobfeyCXaOOKB4uneq22KATmDZW1/Qdcrqp4Jqi
v1ASe81F13yBB6vDPaviwHXXOf9Xz7mgfRN189Cbc82LJ6txGPrt28NLvtpUvdFgCKiNo5Uo/8QV
3Naq0rLZstyzJj+0l/dVuc6BD11dw7Sju9pnvuM/ZS11PL+1lnwx7kVdwYtC6CRJdndZsPRl77f3
2B2YAGKpNC+vFBgBSSSWXxzQU+bPdgzlq6vP9T3K3HiGD9Ur/CGGjQsjGD3xIKd/E0g7Yt6gRcdj
zEfMlv5oejXZ9TA0Xz9nclmmee1nH5fICao7l2v85bjKEQWNoJIKUaW1m4C8dgfcsu+XN9eE14Ya
y2G0kabGIDNN62oclc2aW2VAiyJhfhZ7UyDVDqF2m5dvRNqJE7Y18YavGXimAUnQv1Jl1mnGE/ag
tHEVpe5/EdYwFE31QOgZhxGUvaWp9/727sax3IItJ+PvZ9N//zBZkMBb4rml5tK28x5T9tGKffjo
63MZuFemDQ3HFl9XTAUvZVXTLI0jImHaLqwwp1qUGVAmIFKR1xJDSHpYjFGpbGg49ElvaULrB8aA
nkTbla+YMCKSEBto6EZlEpKBMNAsKnvKHTt4y8wZjqM5OZfqRvjZ0D00J20Efv1wvLTTs60F0Ca+
ivznlSaPQu8jS+0mtUJS/uCkwEgLom2p29XXHtGBfYzokb+dzwerBepni0El6lB0hYu38bYBcZ9n
vKIBQyvSvcDMKQNht7sURk7ikz08hMvVWKrKlVzX2n3DbNrRS4jrhMmcrTg86Ay67qbkfKkIS+1q
G33t4aVWKw4smgOLwTesUGMEUru+yhqFPQ5rl2A33Gr1yG6EFUofU2F2V76yoZ6iGWO8Fys3b9Ao
O2qCvT3FRrlc5nKDQdm21rPN7hkptKmg0GDONOis3DiukBvRckJQAcVohFpgqfQ04lijs90mzBek
8B47iLHy1eBHS8vbo0jrsDZU7TCgdY9QSHDa+2pxyfJvass3OA1r39N9R4opehKVS9EHqOAiQp+P
3duA+Yz4ozhqQ3UeblRYKu9zlYalYD4OucW6NauLRrebfbepjmSJOFccSCw/jKaz46+9YdZPtDR8
Oriy7UPw7xfMgCFrzyl5YTzlIi6TcioRLO8onzCEXEZxUXJYrcWe+RXslHLL2OE64xVIEG3v9t52
p4qjZ1tVS15sAvr3a1VA64RtlPTJhibH4j6RLZjUzzCThz7qBWAxAsfdXmrXfy2pEgFSiRl/JE4L
LvPQO7L08wzSaBl6Ulm3KjrC9Kp803xOFaCh8AJb7hW+x4bakNMmwzO8E6XB3CD+CUyDl8ZOKRLi
RNurgI8E+xiTT8ZNg9YsAMuJs0PjYp6W1g05SKXCHfnOaloWyPdIwq2RW7txtG7KRtPgtiLg+PYQ
x+V4/nI698rC2k/g0QaPtydU9hu8S119CoedBhFVvur6soApgz7hoX2tSpVbD/ze7wNYScKOPC1Q
HngSBegIBbyy2dGDwnQseSGOaRQY+viMboBvhteY29R5RrQEQTh+BIrAq16wS/bq4ix59WaQDJKz
82Nnwm047WMEvjvFR1ezxQmbTfGfsGly3OZnj6upG3ZjmRw0Wx7qkA3eZB/aWnc0V+W1SwOeJlgj
qfR2FY+dM2hE7vfWMhjbcd+zJ9POD/SVSavhWfKQV1+kxc+R4uGD4ziUw7uEfdvpvE+dzkMduJ3r
E0Bsu9P1f1iN9oQdq7uNBxELCa4kkTjagKNW5Lv5RAKPVIluVrbbd5eAKLPgQ/SCr7OKdLX78+ce
b1uaCZPccc3nl2oa1LhtoBMKbVisEf74drYcjd1b2f2qEkdLkT6UqqI6HgEwSIvTHxGS+EVwoHI2
OGHa0+UchPovfGRzkf6Hfl4Yng8GA3Y3mc2wrJ+y95rmDjQ2eYL6PBoOj9ngjF1csFev2XDI3uFd
/54/fvZoEEcfxD2OHqytLl++/PjxYyKs5EWCsQxfHdPhmFjun52DODo9PSX6ccTV/gLm3sPwGZia
xnGv/w0J0DXVX3ZH/JdsNJ+zf1y8Ox2+GQzOXp8O4Mj/AFBLAQIAABQAAAAIAJNijCmiHn7C0ggA
AKQTAAAaAAAAAAAAAAAAAAAAAAAAAABtbWYuMDAxMjEyLjExMjAzNzE5MDE0LnR4dFBLBQYAAAAA
AQABAEgAAAAKCQAAAAA=
--=====mmf-9QIWKGMMYJ0CCJD0-.
250 KAA13889386 Message accepted for delivery
8.1.2 Dans la BAL (POP3)
RETR 2
+OK 5896 octets
Received: from etiam.com (1cust163.tnt1.dial.ren1.fr.uu.net [212.155.1.163])
by CarlCox.iway.fr (8.9.3/8.8.7) with SMTP id KAA13889386;
Fri, 15 Dec 2000 10:18:42 +0100 (MET)
Date: Tue, 14 Dec 2000 17:50:42 +0100
X-Priority: 1
DT11_2004_007.doc
33
GT 11
X-MMF-Version: 0.0
MIME-Version: 1.0
X-UIDL: b014e852357696d99903dc37082cec53
manuellement.
DT11_2004_007.doc
34
GT 11
8.1.3 Archivé dans Netscape 4.72 (Inbox)
Fri, 15 Dec 2000 10:18:42 +0100 (MET)
Date: Tue, 14 Dec 2000 17:50:42 +0100
X-Priority: 1
X-MMF-Version: 0.0
MIME-Version: 1.0
X-Mozilla-Status: c001
X-Mozilla-Status2: 00800000
X-UIDL: b014e852357696d99903dc37082cec53
manuellement.
DT11_2004_007.doc
35
GT 11
--=====mmf-9QIWKGMMYJ0CCJD0--
DT11_2004_007.doc
36
GT 11
8.1.4 Visualisé dans Netscape 4.72
Figure 8-1: Visualisation d'un message MMF par Netscape 4.72 sur Windows95
8.1.5 Sauvegarde du fichier attaché "folder.dsc" dans Netscape 4.72
DT11_2004_007.doc
37
GT 11
8.1.6 Sauvegarde du fichier attaché "folder.zip" dans Netscape 4.72
DT11_2004_007.doc
38
GT 11
8.1.7 Visualisé dans Outlook 2000
Figure 8-2: Visualisation d'un message MMF par Outlook 2000 sur Windows98.
DT11_2004_007.doc
39
GT 11
8.1.8 Sauvegarde du fichier attaché "folder.dsc" dans Outlook 2000
DT11_2004_007.doc
40
GT 11
8.1.9 Sauvegarde du fichier attaché "folder.zip" dans Outlook 2000
8.1.10 Netscape 4.61 sous Linux
La visualisation du message MMF et sa manipulation avec Netscape 4.61 est similaire à
celles obtenues avec Nescapte 4.72 sous Windows, y compris l'envoi d'une MDN en
réponse à une demande de MDN.
8.2 Message de données MMF segmenté (MMF-data-N) (non-traité)
Les message de données MMF segmentés ne sont actuellement pas supportés.
DT11_2004_007.doc
41
GT 11
8.3 Notification de réception (MMF-MDN)
8.3.1 Dans la BAL (POP3)
RETR 1
+OK 2548 octets
>From ecordonn Tue Dec 19 10:55:48 2000
Tue, 19 Dec 2000 10:54:54 +0100 (MET)
Date: Tue, 19 Dec 2000 17:50:42 +0100
From: Alice Merveille <[email protected]>
Subject: MMF/0.0/MDN: Exemple de message MMF version 0.0 (ou alpha0).
To: Bernard Hervault <[email protected]>
X-MMF-Version: 0.0
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
X-UIDL: 882df44db65f73962bd9cb5454b54c5d
Ceci est un message "multi-part" au format MIME.
Ceci est un accusé de réception pour le message MMF (Medical Message
Format) que vous avez envoyé à [email protected] le 13/12/00 15:39. Il
signifie que ce message a été affiché, mais il ne garantit pas qu'il
a été lu ou compris.
Content-Type: message/disposition-notification; name="MMF_MDN_Part2.txt"
Reporting-UA: pc24; mediem-box 0.0
Final-Recipient: rfc822; [email protected]
Original-Message-ID: <[email protected]>
Disposition: manual-action/MDN-sent-manually; displayed/warning
Warning: Bad MMF enveloppe version.
Content-Type: text/rfc822-headers; name="MMF_MDN_Part3.txt"
Fri, 15 Dec 2000 10:18:42 +0100 (MET)
Date: Tue, 14 Dec 2000 17:50:42 +0100
X-Priority: 1
X-MMF-Version: 0.0
MIME-Version: 1.0
X-UIDL: b014e852357696d99903dc37082cec53
DT11_2004_007.doc
42
GT 11
8.3.2 Archivé dans Netscape 4.72 (Inbox)
>From ecordonn Tue Dec 19 10:55:48 2000
Tue, 19 Dec 2000 10:54:54 +0100 (MET)
Date: Tue, 19 Dec 2000 17:50:42 +0100
From: Alice Merveille <[email protected]>
Subject: MMF/0.0/MDN: Exemple de message MMF version 0.0 (ou alpha0).
To: Bernard Hervault <[email protected]>
X-MMF-Version: 0.0
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: 882df44db65f73962bd9cb5454b54c5d
Ceci est un message "multi-part" au format MIME.
Ceci est un accusé de réception pour le message MMF (Medical Message
Format) que vous avez envoyé à [email protected] le 13/12/00 15:39. Il
signifie que ce message a été affiché, mais il ne garantit pas qu'il
a été lu ou compris.
Content-Type: message/disposition-notification; name="MMF_MDN_Part2.txt"
Reporting-UA: pc24; mediem-box 0.0
Original-Message-ID: <[email protected]>
Disposition: manual-action/MDN-sent-manually; displayed/warning
Warning: Bad MMF enveloppe version.
Content-Type: text/rfc822-headers; name="MMF_MDN_Part3.txt"
Fri, 15 Dec 2000 10:18:42 +0100 (MET)
Date: Tue, 14 Dec 2000 17:50:42 +0100
X-Priority: 1
X-MMF-Version: 0.0
MIME-Version: 1.0
X-UIDL: b014e852357696d99903dc37082cec53
--=====mmf-9QIWKGMMYJ0CCJD0--
DT11_2004_007.doc
43
GT 11
8.3.3 Visualisé dans Netscape 4.72
Figure 8-3: Visualisation d'une MDN MMF par Netscape 4.72 sur Windows95.
8.3.4 Visualisé dans Outlook 2000
Figure 8-4: Visualisation d'une MDN MMF par Outlook 2000 sur Windows98.
DT11_2004_007.doc
44
GT 11
9. Annexe B : Exemples de messages MMF sécurisés (non rédigé)
9.1 Message de données MMF signé (MMF-data-signed) (non rédigé)
9.2 Message de données MMF chiffré (MMF-data-crypted) (non rédigé)
9.3 Message de données MMF signé et chiffré (MMF-data-signedAndCrypted)
(non rédigé)
DT11_2004_007.doc
45
GT 11
10. Annexe C : Exemples de notifications ESMTP
10.1 Notifications de remise sur Intranet RSS (DSN-ESMTP)
Return-Path: <>
Received: by cluster.rss.fr (5.1.054) id 3A155A2100000CEB for [email protected]; Wed,
29 Nov 2000 18:21:43 +0100
From: Mail Delivery Service <[email protected]>
Subject: Delivery Status Notification
To: [email protected]
Date: Wed, 29 Nov 2000 18:21:42 +0100
MIME-Version: 1.0
Content-Type: Multipart/Report; report-type=delivery-status;
boundary="=========3A155A2100000CE9/cluster.rss.fr"
This multi-part MIME message contains a Delivery Status Notification.
If you can see this text, your mail client may not be able to understand MIME
formatted messages or DSNs (see RFC 2045 through 2049 for general MIME
information and RFC 1891 through 1894 for DSN specific information).
--=========3A155A2100000CE9/cluster.rss.fr
Content-Type: text/plain; charset=us-ascii
- These recipients of your message have been processed by the mail server:
[email protected]; Action: Delivered
Content-Type: Message/Delivery-Status
Original-Envelope-ID: NS40112696JT
Reporting-MTA: dns; cluster.rss.fr
Received-from-MTA: dns; cluster.rss.fr (Local)
Arrival-Date: Wed, 29 Nov 2000 18:21:41 +0100
Original-Recipient: rfc822;[email protected]
Action: Delivered
Status: 2.1.5 (destination mailbox address valid)
Content-Type: Text/RFC822-headers
Return-Path: <[email protected]>
X-Internal-ID: 3A155A2100000CE9
Received: from rss.fr (172.16.13.144) by cluster.rss.fr (5.1.054)
id 3A155A2100000CE9 for [email protected]; Wed, 29 Nov 2000 18:21:40 +0100
Date: Wed, 29 Nov 2000 18:14:34 +0100
From: alex <[email protected]>
X-Mailer: Mozilla 4.75 [fr] (WinNT; U)
X-Accept-Language: fr
MIME-Version: 1.0
Subject: test ok
--=========3A155A2100000CE9/cluster.rss.fr--
DT11_2004_007.doc
46
GT 11
10.2 Notifications de non-remise sur Intranet RSS (DSN-ESMTP)
Return-Path: <>
Received: by cluster.rss.fr (5.1.054) id 3A155A2100000CEE for [email protected]; Wed,
29 Nov 2000 18:23:29 +0100
From: Mail Delivery Service <[email protected]>
Subject: Delivery Status Notification
Date: Wed, 29 Nov 2000 18:23:27 +0100
MIME-Version: 1.0
Content-Type: Multipart/Report; report-type=delivery-status;
boundary="=========3A155A210000030E/cluster.rss.fr"
This multi-part MIME message contains a Delivery Status Notification.
If you can see this text, your mail client may not be able to understand MIME
formatted messages or DSNs (see RFC 2045 through 2049 for general MIME
information and RFC 1891 through 1894 for DSN specific information).
--=========3A155A210000030E/cluster.rss.fr
- These recipients of your message have been processed by the mail server:
[email protected]; Action: Failed; Status: 4.4.7 (delivery time expired)
Content-Type: Message/Delivery-Status
Reporting-MTA: dns; cluster.rss.fr
Arrival-Date: Tue, 28 Nov 2000 14:09:43 +0100
Action: Failed
Status: 4.4.7 (delivery time expired)
Content-Type: Message/RFC822
Return-Path: <[email protected]>
X-Internal-ID: 3A155A210000030E
Received: from rss.fr (172.16.13.144) by cluster.rss.fr (5.1.054)
id 3A155A210000030E for [email protected]; Tue, 28 Nov 2000 14:09:41
+0100
Date: Tue, 28 Nov 2000 14:02:34 +0100
From: alex <[email protected]>
X-Mailer: Mozilla 4.75 [fr] (WinNT; U)
X-Accept-Language: fr
MIME-Version: 1.0
Subject: testrdtd
gsfsgdsg
--=========3A155A210000030E/cluster.rss.fr--
DT11_2004_007.doc
47
GT 11
11. Annexe D : Extensions MXF
11.1 Introduction
Le format de message médical MMF est fonctionnellement un sous-ensemble du format
MXF. Le format MMF ne transmet donc pas de manière systématique la totalité des
informations contenues dans les dossiers MXF. Pour pallier ce manque il est possible
d'utiliser la notion de champs propriétaires prévue au niveau MMF. Le format des champs
est analogue aux champs du même type dans MMF.
11.2 Conversion MXF vers MMF: Gestion des champs propriétaires MMF
Les identifiants des données propriétaires concernant le dossier ou ces documents sont
décrits ci-dessous.
11.3 Identifiants dossiers
11.3.1 Section [DESCRIPTION]
Les paramètres Tag (identifiant donnée privée) :
"Format", la valeur associée doit être "MXF"
"Version", la version MXF transportée
"CreatorId", identifiant créateur de l'enveloppe
"CreatorName", nom créateur
"CreatorGroupId", identifiant du groupe du créateur
"CreatorGroupName", nom de ce groupe
"ManufacturerId", identifiant de l'éditeur du logiciel ayant créé l'enveloppe
"SofwareId", identifiant de ce logiciel.
"AccesMode", droits d'accès sur l'enveloppe
11.3.2 Section [COMMUNICATION]
Les tags à transmettre sont :
"EmissionToAddresses", adresses des destinataires
"EmissionReplyToAddress", adresse de la réponse
"EmissionFromAddress" , adresse de l’émetteur
"EmissionCCAddresses", adresses des destinataires en copie
tous les autres éléments sont récupérés dans l’entête RFC 822 (Rq : Pas de section
communication dans le format MMF de base).
DT11_2004_007.doc
48
GT 11
11.3.3 Section [HEALTHCAREPARTY_N]
La section équivalente de MMF est [PATIENTID_N]. Comme les structures sont
strictement identiques rien ne doit être passé par données privées.
11.4 Identifiants documents
Les paramètres Tag (identifiant donnée privée) à ajouter au dossier MMF sont :
"CreationDate", date de création
"CreationTime", heure de création
"CreatorId", identifiant du créateur du document
"CreatorName", nom de ce créateur
"CreatorGroupId", identifiant de son groupe
"CreatorGroupName", nom de son groupe
"SubDocuments", le notion de sous-documents étant absente dans MMF, mettre
l’UID du sous-document à la place du nom du fichier qui est amené à évolué lors
de la conversion. Puis lors de la conversion MMF vers MXF récupérer le nom du
fichier sous-document.
"PosX", abscisse de l'icône du document (1 à 1000)
"PosY", ordonnées (idem)
"ModifId", identifiant unique de la dernière modification du document
"AccesMode", droits d'accès
"MacFileType", type Mac
"MacFileCreator", créateur Mac
"Icon", icône
"Format", à ajouter si le document est une série, valeur à associer « MXF »
"Version", à ajouter si le document est une série, valeur à associer version "mxf"
du descripteur de série.
"X-OwnerID|Tag", ajouter les données privées au niveau document.
_______________________________________
DT11_2004_007.doc
49

GT 11 - Amula

Transcription

Documents pareils

Istanbul, le 30/06/2010 Forum Européen de la MMF, atelier Services

Enseigner dehors Les sorties nature hebdomadaires

AMA33 - Assistance à maîtrise d`ouvrage agile

Télécharger les résumés d`avril en PDF

ET-ISC-O

3- Veille technologique