FR 2931570 A1 20091127 FR 0853408 A 20080526 Procédés de conversion de documents médicaux, dispositifs et programmes d'ordinateur correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui de la gestion, du partage et des 5 échanges de documents médicaux de tous types. Plus précisément, l'invention concerne le stockage et la transmission de documents médicaux de types texte, images médicales, ... 2. Art antérieur On connaît à l'heure actuelle différentes techniques d'imagerie numérique, 10 et différents systèmes de stockage et d'échange d'images numériques. Par exemple, le standard � DICOM � (pour � Digital Imaging and COmmunications in Medicine � en anglais), reconnu comme norme internationale par l'ISO (pour � International Standards Organisation), permet d'échanger de telles images sous forme numérique, en maintenant en permanence en lien les 15 images elles-mêmes (sous forme de pixels) et les informations médicales associées (nom du patient, organe représenté sur l'image, ...). Les images numériques ainsi générées peuvent par exemple être échangées et stockées au sein de systèmes d'archivage et de communication d'images de type � PACS � (pour � Picture Archiving and Communication System � en 20 anglais), capables de gérer des très gros volumes de données. Il existe également différents formats de documents médicaux, et différents systèmes de stockage et d'échange de ces documents médicaux. Par exemple, des systèmes d'information médicaux gèrent des informations médicales sous la forme de � dossier patient � de type � EHR � (pour 25 � Electronic Health record � en anglais). En complément à des messages véhiculant les informations structurées telles que l'identification des patients et de leur mouvement au sein de l'hôpital, souvent au format � HL7 � (pour � Health Level Seven � en anglais), l'initiative � IHE � (pour � Integrating the Healthcare Enterprise � en anglais) a défini un 30 format de partage et d'échange de documents entre � dossiers patient� au sein du profil d'intégration � XDS � (pour � Cross-Enterprise Document Sharing � en anglais). Le profil � XDS � définit un jeu normalisé de méta données associées aux documents, une méta donnée étant une sorte � d'étiquette � permettant aux � dossiers patient � de gérer correctement les documents qui le composent, et qui peuvent être eux-mêmes dans différents formats, non structurés (texte, � PDF � (pour � Printable Document Format � en anglais), éditables � RTF � (pour � Rich Text Format � en anglais) ou structurés (� XML � (pour � eXtensible Markup Language � en anglais) dont � HL7 CDA � (pour � Clinical Document Architecture � en anglais). Le profil � IHE-XDS � est considéré comme un standard reconnu pour tous les échanges de documents médicaux textuels, c'est-à-dire qui ne sont pas des images. Un inconvénient de ces différentes techniques de l'art antérieur réside dans 15 le fait qu'aucun système ne gère des documents médicaux dans plusieurs types de formats différents. Ainsi, des applications devant présenter aux utilisateurs à la fois les documents médicaux et les images associées (ou vice-versa) doivent interagir avec le système de gestion des documents médicaux et avec le système de gestion 20 des images, subissant les éventuels problèmes de synchronisation entre les deux systèmes. Le transfert d'images et de documents associés entre deux entités suppose donc dans ce cas deux communications différentes, non synchronisées entre elles et plus complexes à mettre en oeuvre. 25 Il existe également des systèmes d'informations médicaux qui gèrent des documents et des images, à condition que les documents aient été produits dans le contexte du système d'imagerie, des documents médicaux externes ne pouvant donc pas être gérés. Le transfert d'images et de documents entre deux entités ne concernera 30 dans ce cas que les documents d'imagerie. Enfin, il existe des systèmes d'information médicaux gérant les documents et les images dans un format adapté au document, c'est à dire ne gérant pas les images dans un format adapté à l'image médicale. 3. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention, selon au moins un mode de réalisation, est de fournir une technique permettant d'optimiser le stockage et la transmission de documents médicaux de types différents (texte, images, etc). Un autre objectif de l'invention, selon au moins un mode de réalisation, est de permettre de gérer des documents médicaux au sein de systèmes d'imagerie, et des documents d'imagerie au sein de systèmes d'information gérant des documents médicaux. L'invention a également pour objectif de fournir une telle technique 15 présentant de meilleures performances en termes d'échanges de documents médicaux et d'images associées. Un autre objectif de l'invention, selon au moins un mode de réalisation, est de fournir une telle technique qui soit simple et peu coûteuse à implémenter. Encore un objectif de l'invention est de fournir une telle technique 20 compatible avec des formats de documents médicaux et de documents d'imagerie existants. 4. Exposé de l'invention L'invention propose une solution nouvelle qui ne présente pas l'ensemble de ces inconvénients de l'art antérieur, sous la forme d'un procédé de conversion 25 d'un document source décrit dans un format source et d'au moins une méta donnée associée décrite dans ledit format source ou dans un format permettant la génération de méta données dans ledit format source, vers au moins un document de destination décrit dans un format de destination. Selon l'invention, ledit format source est conforme à un premier protocole 30 d'échange et/ou de partage de documents médicaux et ledit format de destination est conforme à un second protocole d'échange et/ou de partage de documents d'imagerie médicale et un tel procédé comprend les étapes suivantes : - insertion dudit document source dans une première partie dudit document de destination ; - transposition de ladite au moins une méta donnée en une donnée transposée ; - insertion de ladite donnée transposée dans une deuxième partie dudit document de destination, distincte de ladite première partie. Ainsi, l'invention repose sur une approche nouvelle et inventive de la 10 gestion et de l'échange de documents médicaux et de documents d'imagerie médicale, dans un même format, sans perte d'informations. On entend par document médical un document, non image, définissant des informations relatives à un patient, aux examens qu'il a subis, à son suivi médical, une éventuelle hospitalisation, etc. La ou les méta données associées à un 15 document médical sont des données permettant notamment de gérer le document associé au sein d'un � dossier patient� (regroupant une pluralité de documents et informations relatives à un même patient). On entend par documents d'imagerie médicale des images sous forme numérique, correspondant à des examens subis par un patient, comme par 20 exemple une radiologie, un scanner, un examen par Imagerie par Résonance Magnétique, etc. Ainsi l'invention permet, selon ce mode de réalisation particulier, de convertir un document médical et ses méta données associées, décrits dans un format adapté à l'échange et au partage de documents médicaux, vers un 25 document décrit dans un format adapté à l'imagerie médicale. Le principe de l'invention repose sur une conversion distincte du document source et des méta données associées, vers deux parties également distinctes d'un document de destination. Par exemple, le document médical est inséré dans une partie du document 30 de destination, pré-identifiée comme une partie � binaire � du document de destination, et la ou les méta données associées au document médical sont quant à elles transposées en données destinées à être insérées dans une deuxième partie du document de destination, pré-identifiée par exemple comme un � en-tête � du document de destination. Ainsi, le principe de l'invention repose sur une transposition de méta données associées à un document médical en des données d'en-tête d'un document d'imagerie (en effectuant un traitement adapté à chaque méta donnée, consistant à identifier une fonctionnalité de la méta donnée) et non sur une encapsulation au format de destination d'informations de type � propriétaire �. En particulier, ladite étape de transposition comprend les sous-étapes suivantes : - décodage de ladite au moins une méta donnée ; - identification, parmi une pluralité de champs compris dans ladite deuxième partie dudit document de destination, d'un champ assurant une fonctionnalité équivalente à celle de ladite au moins une méta donnée ; - conversion de ladite au moins une méta donnée en ladite donnée transposée à insérer dans ledit champ identifié. Ainsi, selon ce mode de réalisation, la transposition de la méta donnée associée au document source consiste à la décoder, de manière à identifier un champ correspondant fonctionnellement dans le document de destination. Par exemple, si l'on considère que la partie � en-tête � du document de destination comprend une pluralité de champs assurant diverses fonctionnalités, le procédé de conversion selon ce mode de réalisation permet d'identifier parmi cette pluralité de champs celui assurant, dans le format de destination, une fonctionnalité équivalente à la fonctionnalité assurée par la méta donnée dans le format source. Plusieurs critères sont pris en compte pour l'identification d'un champ de fonctionnalité équivalente à celle de la méta donnée, et notamment des informations relatives au patient auquel est associé le document médical, aux examens qu'il a subis, aux personnes ayant effectué ces examens, aux établissements dans lesquels ont été faits ces examens, aux dates et heures de ces examens, etc. Selon une caractéristique particulière de l'invention, ladite étape d'identification comprend les sous-étapes suivantes : - détermination d'un niveau d'information de ladite méta donnée ; - sélection dudit champ en fonction dudit niveau déterminé. Ainsi, selon ce mode de réalisation, un des critères utilisé pour identifier un champ assurant une fonctionnalité équivalente à celle de la méta donnée correspond à un niveau d'information de la méta donnée. En effet, les méta données décrivent notamment le document médical auquel elles sont associées, et les éventuels liens entre ce document et d'autres documents médicaux relatifs au même patient par exemple. Par exemple, ledit niveau d'information appartient au groupe comprenant : - niveau relatif à un patient auquel est lié ledit document source ; - niveau relatif à un jeu de documents auquel appartient ledit document source, noté lot de soumission ; - niveau relatif au document source. Ainsi, selon ce mode de réalisation, le niveau d'information d'une méta donnée peut être un niveau indiquant que la méta donnée est relative directement au document source auquel elle est associée, ou bien un niveau indiquant que la méta donnée est relative au lot de soumission du document source auquel elle est associée (c'est-à-dire le jeu de documents dont fait partie le document source) ou encore un niveau indiquant que la méta donnée est relative au patient auquel est associé le document source ou relatif à un examen subi par le patient. Selon un aspect particulier de l'invention, chacun desdits champs est d'un type appartenant au groupe comprenant : - champ obligatoire ; - champ optionnel ; - champ conditionnel, et ledit procédé comprend une étape d'attribution d'une valeur par défaut à au moins un champ obligatoire dudit format de destination lorsque aucune méta donnée assurant une fonctionnalité équivalente n'est associée audit document source. Ainsi, selon ce mode de réalisation de l'invention, le procédé permet d'attribuer une valeur par défaut à un champ obligatoire, tel que défini ci-dessous, quand aucune méta donnée assurant une fonctionnalité équivalente à ce champ n'est associée au document source. De cette manière, un champ obligatoire n'est pas vide, même s'il ne 10 correspond pas à une méta donnée associée au document source. Les champs compris dans la deuxième partie du document de destination peuvent donc être de différents types, en fonction de leur importance. Par exemple, certains champs sont obligatoires, c'est-à-dire toujours présents dans un document d'imagerie médicale. 15 Certains champs sont optionnels, c'est-à-dire qu'ils sont présents ou pas dans un document d'imagerie médicale, selon le niveau d'information que l'on veut atteindre pour le document en question. Enfin, certains champs sont conditionnels, c'est-à-dire qu'ils deviennent obligatoires sous certaines conditions, par exemple si un autre champ est présent, 20 alors un champ peut devenir obligatoire. Avantageusement, ladite étape de conversion comprend : - une étape de sélection, parmi une pluralité de valeurs pour une méta donnée, d'une valeur présentant une pertinence supérieure à un seuil prédéterminé ; 25 - une étape d'attribution de ladite valeur sélectionnée audit au moins un champ identifié dudit format de destination, lorsque ledit champ ne peut prendre qu'une seule valeur. Ainsi, l'invention permet, selon ce mode de réalisation, de choisir la valeur la plus pertinente d'une méta donnée, lorsque celle-ci comprend plusieurs valeurs 30 et que le champ identifié pour la conversion ne peut prendre qu'une seule valeur. En particulier, ladite étape de transposition prend en considération au moins une information appartenant au groupe comprenant : - une information liée à un patient ; - une information liée à un lot de soumission ; - une information liée audit document source. Ainsi, selon ce mode de réalisation, les critères utilisés pour la conversion de la méta donnée en un champ de fonctionnalité équivalente peuvent être relatifs : - au patient auquel est associé le document source : par exemple ses coordonnées, ... ; - à une série de documents concernant le patient : par exemple la date et l'heure de création de la série de documents, ... ; - au document source lui-même : la date et l'heure de création du document, l'auteur du document, le destinataire du document, le type de codage du document, .... Ces critères listés à titre indicatif et non exhaustif permettent notamment d'identifier la fonctionnalité de la méta donnée et donc permettent la recherche d'un champ de fonctionnalité équivalente. Selon un mode de réalisation préférentiel de l'invention, ledit format source est � IHE-XDS � et ledit format de destination est � DICOM �. Ainsi, le procédé selon un mode de réalisation de l'invention est notamment adapté à une conversion d'un document de type � IHE-XDS � vers un document de type � DICOM �. L'invention concerne également un procédé de conversion d'un document source décrit dans un format source vers au moins un document de destination décrit dans un format de destination et au moins une méta donnée associée, décrite dans ledit format de destination ou dans un format permettant la génération de méta données dans ledit format de destination. Selon l'invention, ledit format source est conforme à un premier protocole 30 d'échange et/ou de partage de documents d'imagerie médicale et ledit format de destination est conforme à un deuxième protocole d'échange et/ou de partage de documents médicaux non images, et ledit procédé comprend les étapes suivantes : - insertion d'une première partie dudit document source dans ledit document de destination ; - transposition d'une deuxième partie dudit document source en au moins une méta donnée associée audit document de destination. Ainsi l'invention permet, selon ce mode de réalisation particulier, de convertir un document décrit dans un format adapté à l'imagerie médicale vers un document médical et une ou plusieurs méta données associées, décrits dans un format adapté à l'échange et au partage de documents médicaux. Le principe de l'invention repose sur une conversion distincte d'une première partie du document source vers un document de destination, et une deuxième partie du document source vers une ou plusieurs méta données associées au document de destination. Par exemple, une première partie du document source, pré-identifiée comme une partie � binaire �, est insérée dans un document de destination, et une deuxième partie du document source, pré-identifiée par exemple comme un � en-tête �, est transposée en une ou plusieurs méta données associées au document de destination. En particulier, ladite étape de transposition comprend les sous-étapes suivantes : - décodage d'au moins un champ de ladite deuxième partie dudit document source ; - identification d'une méta donnée associée audit document de destination assurant une fonctionnalité équivalente à celle de dudit champ ; - conversion dudit champ vers ladite au moins une méta donnée identifiée. Ainsi, selon ce mode de réalisation, la transposition d'une deuxième partie 30 du document source en une ou plusieurs méta données associées au document de destination consiste à décoder les champs compris dans cette deuxième partie de manière à identifier des méta données associées au document de destination correspondant fonctionnellement aux champs décodés. Par exemple, si l'on considère que la partie � en-tête � du document de destination comprend une pluralité de champs assurant diverses fonctionnalités, le procédé de conversion selon ce mode de réalisation permet d'identifier parmi les méta données possibles à associer au document de destination, les méta données assurant, dans le format de destination, des fonctionnalités équivalentes aux fonctionnalités assurées par les champs dans le format source. Plusieurs critères sont pris en compte pour l'identification d'une méta donnée fonctionnalité équivalente à celle d'un champ compris dans la deuxième partie du document source, et notamment des informations relatives au patient auquel est associé le document médical, aux examens qu'il a subis, aux personnes ayant effectué ces examens, aux établissements dans lesquels ont été faits ces examens, aux dates et heures de ces examens, etc. Selon un aspect particulier, ladite étape d'identification comprend les sous-étapes suivantes : - détermination d'un niveau d'information dudit champ identifié ; - sélection de ladite méta donnée en fonction dudit niveau déterminé. Ainsi, selon ce mode de réalisation, un des critères utilisé pour identifier une méta donnée assurant une fonctionnalité équivalente à celle du champ identifié correspond à un niveau d'information du champ. En effet, les champs compris dans la deuxième partie du document source décrivent notamment le document d'imagerie dont ils font partie, et les éventuels liens entre ce document et d'autres documents d'imagerie relatifs au même patient par exemple. En particulier, ledit niveau d'information appartient au groupe comprenant : - niveau relatif à un patient auquel est lié ledit document source ; - niveau relatif à un examen subi par un patient ; niveau relatif à une série de documents à laquelle appartient ledit document source ; - niveau relatif audit document source. Ainsi, selon ce mode de réalisation, le niveau d'information d'un champ peut être un niveau indiquant que le champ est relatif directement au document source, ou bien un niveau indiquant que le champ est relatif à la série de documents dont fait partie le document source, ou encore un niveau indiquant que le champ est relatif au patient auquel est associé le document source ou relatif à un examen subi par le patient. Avantageusement, le procédé comprend une étape d'attribution d'une valeur par défaut à une méta donnée lorsque aucun champ assurant une fonctionnalité équivalente n'est identifié dans ledit document source. Ainsi, selon ce mode de réalisation de l'invention, le procédé permet d'attribuer une valeur par défaut à une méta donnée associée au document de destination quand aucun champ assurant une fonctionnalité équivalente à cette méta donnée n'est identifié dans le document source. De cette manière, une méta donnée dont la présence est requise associée à un document de destination n'est pas vide, même si elle ne correspond pas à un champ du document source. Selon une caractéristique particulière de l'invention, ladite étape de transposition prend en considération au moins une information appartenant au groupe comprenant : une information liée à un patient ; une information liée à un examen ; une information liée à une série de documents ; une information liée audit document source. Ainsi, selon ce mode de réalisation, les critères utilisés pour la conversion d'un champ en une méta donnée de fonctionnalité équivalente peuvent être relatifs : au patient auquel est associé le document source : par exemple ses coordonnées, ... ; - à un examen subi par le patient : par exemple la date et l'heure de l'examen, l'établissement dans lequel il a été effectué, la personne ayant effectué l'examen, ... ; - à une série de documents concernant le patient : par exemple la date et l'heure de création de la série de documents, ... ; - au document source lui-même : la date et l'heure de création du document, l'auteur du document, le destinataire du document, le type de codage du document, .... Ces critères listés à titre indicatif et non exhaustif permettent notamment d'identifier la fonctionnalité du champ et donc permettent la recherche d'une méta donnée de fonctionnalité équivalente. Selon un mode de réalisation préférentiel, ledit format source est � DICOM � et ledit format de destination est � IHE-XDS �. L'invention concerne également un dispositif de conversion d'un document source décrit dans un format source et d'au moins une méta donnée associée décrite dans ledit format source ou dans un format permettant la génération de méta données dans ledit format source, vers au moins un document de destination décrit dans un format de destination. Selon l'invention, ledit format source est conforme à un premier protocole d'échange et/ou de partage de documents médicaux et ledit format de destination est conforme à un second protocole d'échange et/ou de partage de documents d'imagerie médicale, et un tel dispositif comprend : - des moyens d'insertion dudit document source dans une première partie dudit document de destination ; - des moyens de transposition de ladite au moins une méta donnée en une donnée transposée ; - des moyens d'insertion de ladite donnée transposée dans une deuxième partie dudit document de destination, distincte de ladite première partie. 30 Un tel dispositif est notamment apte à mettre en oeuvre les étapes du procédé de conversion décrit précédemment. L'invention concerne encore un dispositif de conversion d'un document source décrit dans un format source vers au moins un document de destination décrit dans un format de destination et au moins une méta donnée associée, décrite dans ledit format de destination ou dans un format permettant la génération de méta données dans ledit format de destination. Selon l'invention, ledit format source est conforme à un premier protocole d'échange et/ou de partage de documents d'imagerie médicale et ledit format de destination est conforme à un deuxième protocole d'échange et/ou de partage de documents médicaux, et un tel dispositif comprend : - des moyens d'insertion d'une première partie dudit document source dans une première partie dudit document de destination ; - des moyens de transposition d'une deuxième partie dudit document 15 source en au moins une méta donnée associée audit document de destination. Un tel dispositif est notamment apte à mettre en oeuvre les étapes du procédé de conversion décrit précédemment. L'invention concerne également un produit programme d'ordinateur 20 téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé de conversion d'un document médical et des méta données associées vers un document d'imagerie tel que décrit précédemment, lorsque ledit programme est 25 exécuté sur un ordinateur. L'invention concerne enfin un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé de 30 conversion d'un document d'imagerie vers un document médical et des méta données associées tel que décrit précédemment, lorsque ledit programme est exécuté sur un ordinateur. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 illustre un exemple de documents convertibles l'un vers l'autre selon un mode de réalisation de l'invention ; - la figure 2 illustre les principales étapes du procédé de conversion d'un document médical vers un document d'imagerie selon un mode de réalisation de l'invention ; - la figure 3 illustre les principales étapes du procédé de conversion d'un document d'imagerie vers un document médical selon un mode de réalisation de l'invention ; - la figure 4 présente un exemple de système dans lequel sont mis en oeuvre les procédés de conversion selon un mode de réalisation de l'invention. 6. Description d'un mode de réalisation de l'invention 6.1 Principe général Le principe général de l'invention repose sur l'analyse des formats du document source et du document de destination de façon à mettre en oeuvre une conversion distincte pour les différentes parties du document source vers différentes parties du document de destination. On considère un premier format de document adapté à l'échange et au 25 partage de documents médicaux non images et un deuxième format adapté à l'échange et au partage de documents d'imagerie médicale. On présente maintenant, en relation avec la figure 1, un exemple de document médical et des méta données associées et un exemple de document d'imagerie médicale, pour la mise en oeuvre des procédés de conversion selon 30 l'invention. On considère un document médical B, associé à des méta données A, et un document d'imagerie médicale composé d'une première partie D, correspondant à une partie binaire représentative d'une image et d'une deuxième partie C, correspondant à un en-tête. On décrit par la suite, en relation avec les figures 1 et 2, les deux procédés de conversion de l'invention, permettant de passer d'un document médical B associé aux méta données A, à un document d'imagerie composé des parties C et D, et vice versa. En particulier, on décrit des modes de réalisation particuliers au format de 10 documents médicaux � IHE-XDS � et au format d'imagerie � DICOM �. 6.2 Conversion d'un document médical et des méta données associées vers un document d'imagerie La figure 2 illustre les principales étapes du procédé de conversion d'un document médical, et des méta données associées, vers un document d'imagerie, 15 selon un mode de réalisation particulier de l'invention. On considère donc un document médical B, par exemple un document associé à un patient hospitalisé, correspondant à son dossier médical comprenant des informations sur sa pathologie, les examens et/ou les interventions qu'il a subis, ses coordonnées, sa date d'amission à l'hôpital, etc. 20 Des méta données A sont associées à ce document, permettant notamment de le gérer au sein d'un dossier concernant le patient, et permettant le stockage, le partage et/ou le transfert de ce document vers un destinataire (par exemple un autre hôpital, ou un médecin traitant...). On souhaite pouvoir gérer ce document médical, ainsi que les méta 25 données associées, dans un système de gestion, de partage et d'échange de documents d'imagerie médicale, au même titre qu'un document d'imagerie, sans perte d'information par rapport au document médical et aux méta données. Pour ce faire, on met en oeuvre les étapes de la figure 2, pour le document B et chacune des méta données A 30 La première étape 20 consiste à insérer le contenu du document médical B dans une première partie d'un document d'imagerie, pré-identifiée. Dans l'exemple illustré en figure 1, cette étape 20 consiste à incorporer le contenu du fichier correspondant au document B au sein de la partie binaire D du document d'imagerie. Lors d'une deuxième étape 21, on transpose une méta donnée associé au document médical en une donnée transposée, compatible avec le format de destination. Cette étape 21 correspond, pour l'exemple illustré en figure 1, à transposer les méta données A en données compatibles avec le format des en-têtes C des 10 documents d'imagerie. Cette étape de transposition est décrite plus en détail dans les paragraphes suivants, en relation avec des exemples de réalisation. Cette donnée transposée est ensuite insérée, lors d'une étape 22, dans une deuxième partie spécifique du document de destination, correspondant dans 15 l'exemple de la figure 1 à l'en-tête C. La partie binaire D et l'en-tête C ainsi générés forment un document d'imagerie correspondant au document médical B et aux méta données associées A d'origine. 6.3 Conversion d'un document d'imagerie vers un document 20 médical et des méta données associées On présente maintenant, en relation avec la figure 3, les principales étapes du procédé de conversion d'un document d'imagerie vers un document médical et des méta données associées, selon un mode de réalisation particulier de l'invention. 25 Il s'agit dans l'exemple illustré en figure 1 de convertir un document d'imagerie, composé d'une partie binaire D et d'un en-tête C, en un document médical B, associé à des méta données A. Pour ce faire, une première étape 30 consiste à insérer une première partie d'un document d'imagerie, la partie binaire D dans l'exemple, dans le document 30 médical B. Lors d'une deuxième étape 31, une deuxième partie du document d'imagerie, l'en-tête C dans l'exemple, est transposée en au moins une méta donnée associé au document médical. Cette transposition est décrite plus en détail dans les paragraphes suivants, en relation avec des exemples de réalisation. 6.4 Exemples de conversion d'un document d'imagerie vers un document médical et des méta données associées, et inversement On présente maintenant, en relation avec la figure 4, un exemple d'implémentation des procédés de conversion selon un mode de réalisation particulier de l'invention. On considère deux systèmes � routeurs d'images médicales � correspondant aux systèmes b et c, permettant d'échanger de manière sécurisée des images au format � DICOM � entre deux établissements de santé, par exemple a et d. Une des applications typiques est le transfert de garde de radiologie entre deux établissements le soir ou le week-end. L'invention, selon ce mode de réalisation particulier, permet d'associer aux images médicales des documents médicaux non images et leurs méta données associées, issus par exemple du dossier patient, géré par un système de l'établissement a. Ces documents médicaux non images, et leurs méta données associées, sont exportés dans un format m (par exemple � IHE-XDS �), adapté aux documents médicaux et supporté en standard par les dossiers patient. L'invention permet, selon ce mode de réalisation, de transférer ces documents médicaux avec les images entre les deux établissements (a et d) selon un format i (par exemple � DICOM �). L'invention permet également, selon ce mode de réalisation, de visualiser ces documents médicaux au sein du système d de gestion de radiologie, supportant une application d'élaboration de compte rendu d'interprétation de radiologies vers lequel les documents ont été exportés dans le format m. Les conversions du format m vers le format i, et inversement, sont réalisées à l'aide de tables de conversion, prenant en considération l'architecture des deux formats. En particulier, l'annexe 1, faisant partie intégrante de la présente description, correspond au tableau décrivant les conversions à mettre en oeuvre pour un mode de réalisation particulier de l'invention, permettant de convertir un document médical et les méta données associées, décrits dans le format � IHEXDS �, vers un document d'imagerie au format � DICOM �. Les méta données � XDS � sont décrites dans le Volume 2 du cadre technique IHE Infrastructure IT (IHE Technical Framework IT Infrastructure) IHE_ITI_TF_4.0_Vo12_FT_2007-08-22.pdf ou son évolution (www.ihe.net). Les champs d'en-tête du format � DICOM � sont décrits dans la partie 3 du standard � DICOM � (PS3.3) (dicom.nema.org). Par exemple, on considère un attribut � XDS � appelé � author � représentant un auteur du document, à convertir au format � DICOM �. Cet attribut � XDS � comprend un certains nombre de sous-attributs, tels que : � authorinstitution �, � authorPerson �, � authorRole � et � authorSpecialty �. Le champ de fonctionnalité équivalente à utiliser dans � DICOM � est la séquence � PersonIdentificationCodeSequence �, marquée par (0040,1101), comportant les sous-champs suivants : � CodeValue � (0008,0100), � CodeMeaning � (0008,0104) et � CodingSchemeDesignator � (0008,0106) (conformément à la partie 3 du document de standard � DICOM �). Par exemple, on considère l'attribut XDS � author � ayant les sous-25 attributs suivants : - � authorinstitution � : valeur = • Groupe Pitié Salpétrière^^^^^&1.2.250.1.71 &ISO^G-CPS^^^1750100125 � ; - � authorPerson � : valeur = � 0993000462ADURAND^Romuald^B^^Dr.^^^&1.2.250.1.71 &ISO^^^^G-CPS � ; 30 - � authorRole � : valeur = � Médecin � ; - � authorSpecialty � : valeur = � Radiologie �. Ces sous-attributs sont codés de la façon suivante : 0993000462^DURAND^Romuald^B^^Dr. Groupe Pitié Salpétrière^^^^^^^^^1750100125 Médecin Radiologie La correspondance � DICOM � pour cet attribut et ces sous-attributs selon un mode de réalisation de l'invention est la suivante : (0040,A078) { (0008,0080) : [Groupe Pitié Salpétrière] (0008,0082) {(0008,0100): [1750100125], (0008,0102):[NPI ], (0008,0104):[1750100125]} (0040,1101) {(0008,0100): [0993000462], (0008,0102): [UPIN],(0008,0104): [09930004621} {(0008,0100): [Médecin ], (0008,0102):[ROLE], (0008,0104): [Médecin ]} {(0008,0100): [Radiologie] ,(0008,0102): [S PECIALTY] , (000 8,0104) : [Radiologie] l (0040,A084) : [PSN ] (0040,Al23) : [DURAND^Romuald^B^^Dr] } ANNEXE 1 Principes généraux: 1) Dates Assurer la correspondance entre les dates en utilisant le champ DICOM TimeZoneOffsetFronUTC (0008,0201) 2) Codes Faire correspondre les valeurs, libellés et schémas de codage entre les structures XDS et DICOM valeur : CodeValue (0008,0100), libellé (DisplayName) : CodeMeaning (0008,0104) schéma de codage : CodingSchemeDesignator (0008,0102). A priori la version est vide. 3) Identifiants Les identifiants de personnes et d'organisation comprenant un identifiant d'une autorité d'assignation ou racine d'identifiant d'une part et un identifiant d'autre part font correspondre le premier à CodingSchemeDesignator (0008,0102) et le second à CodeValue (0008,0100). 4) Exceptions Par principe, le format DICOM de sortie est totalement conforme au standard. Quelques extensions ont toutefois été introduites mais de telle manière que les PACS maintiennent les objets dans leur intégrité, car d'une part aucun attribut propriétaire n'a été créé, et d'autre part aucun type d'attribut n'a été modifié. Les deux seuls types d'exceptions sont les suivants: - certains attributs non prévus pour certaines classes ont été utilisés. de manière schématique on peut considérer que l'entête des instances de type "document" est la fusion des entêtes du DICOM SR, du DICOM PDF et du DICOM CDA, seuls les attributs utiles ayant été rajoutés. - certaines séquences a priori avec une seule entrée on été étendues, en particulier pour permettre de gérer les identifiants, et un ou deux code(s) des entités (institution par exemple) XDS High DICOM Module DICOM Tag DICOM Comment Attribute level tag D_authorinsti 0040, SOP COMMON et SR InstitutionName tution (sub- A07C DOCUMENT GENERAL / (0008,0080) et attribute of AuthorObserverSequence eventuellement author) (0040,A078) et InstitutionalDepart CustodialOrganizationSequ mentName ence (0040,A07C) (0008,1040) D_authorPers 0040, SR DOCUMENT PersonName ObserverType on (sub- A078 GENERAL / (00040,Al23) et (00040,A084) est à mettre à attribute of AuthorObserverSequence Personldentificatio PSN. Initialiser author) (0040,A078) nSequence systématiquement la (0040,1101) première entrée. D_authorRole 0040, SR DOCUMENT CodeValue Le second (le troisième (sub-attribute A078 GENERAL / (0008,0100) et étant pour Specialty). Si of author) AuthorObserverSequence CodeMeaning spécialité non vide et rôle (0040,A078) / (0008,0104) vide, le mettre à PersonidentificationCodeS UNKNOWN. Seule la equence (0040,1101) première entrée du role est utilisée, les autres étant ignorées. D_authorSpe 0040, SR DOCUMENT CodeValue Le troisième (le premier cialty (sub- A078 GENERAL / (0008,0100) et étant pour l'identifiant de attribute of AuthorObserverSequence CodeMeaning l'institution de l'auteur, le author) (0040,A078) (0008,0104) secon pour Role) . Seule la première entrée de la spécialité est utilisée, les autres étant ignorées. D_availabilit yStatus D_classCode A priori à rendre identique au typeCode D_classCode A priori à rendre identique DisplayNam au typeCodeDisplayName e D_comments 0018, SOP COMMON ContributionDescri A003 ption (0018,A003) D_confidenti Non géré et donc ramené à alityCode la valeur � normal � en sortie. D_creationTi 0008, SOP COMMON et InstanceCreationDa me 0012 ENCAPSULATED te (0008,0012), DOCUMENT InstanceCreationTi me (0008,0013), TimeZoneOffsetFro mUTC (0008,0201) et DOC / ContentDate (0008,0023), ContentTime (0008,0033), AcquisitionDateTi me (0008,002A) D_creationTi 0008, SOP COMMON et InstanceCreationDa me 0013 ENCAPSULATED te (0008,0012), DOCUMENT InstanceCreationTi me (0008,0013), TimeZoneOffsetFro mUTC (0008,0201) et DOC / ContentDate (0008,0023), ContentTime (0008,0033), AcquisitionDateTi me (0008,002A) D_creationTi 0008, SOP COMMON et InstanceCreationDa me 0023 ENCAPSULATED te (0008,0012), DOCUMENT InstanceCreationTi me (0008,0013), TimeZoneOffsetFro mUTC (0008,0201) et DOC / ContentDate (0008,0023), ContentTime (0008,0033), AcquisitionDateTi me (0008,002A) D_creationTi 0008, SOP COMMON et InstanceCreationDa me 002A ENCAPSULATED te (0008,0012), DOCUMENT InstanceCreationTi me (0008,0013), TimeZoneOffsetFro mUTC (0008,0201) et DOC / ContentDate (0008,0023), ContentTime (0008,0033), AcquisitionDateTi me (0008,002A) D_creationTi 0008, SOP COMMON et InstanceCreationDa me 0033 ENCAPSULATED te (0008,0012), DOCUMENT InstanceCreationTi me (0008,0013), TimeZoneOffsetFro mUTC (0008,0201) et DOC / ContentDate (0008,0023), ContentTime (0008,0033), AcquisitionDateTi me (0008,002A) D_creationTi 0008, SOP COMMON et InstanceCreationDa me 0201 ENCAPSULATED te (0008,0012), DOCUMENT InstanceCreationTi me (0008,0013), TimeZoneOffsetFro mUTC (0008,0201) et DOC / ContentDate (0008,0023), ContentTime (0008,0033), AcquisitionDateTi me (0008,002A) D_entryUUl D D_eventCode DisplayName List D_eventCode List D_formatCo 0040, (si CDA) SOP SOPC1assUID La correspondance entre les de A390 COMMON/HL7Structured (0008,0016) = classes DICOM et les DocumentSequence 2.16.840.1.113883. formats dépend du domaine (0040,A390) 1.7.2 (CDAR2) ou d'activité XDS (affinity 1 (Rl) domain). D_hash D_healthcar 0040, SR GENERAL / CodeValue Le second de la séquence eFacilityTyp A07C CustodialOrganizationSequ (0008,0100), (le premier est utilisé pour eCode ence (0040,A07C) / CodingSchemeDesi l'id d'institution et le InstitutionCodeSequence gnator (0008,0102) troisième pour (008,0082) healthcareFacility) D_healthcar 0040, SR GENERAL / CodeMeaning Le second de la séquence eFacilityTyp A07C CustodialOrganizationSequ (0008,0100) (le premier est utilisé pour eCodeDispla ence (0040,A07C) / l'id d'institution et le yName InstitutionCodeSequence troisième pour (0008,0082) healthcareFacility) D_Ianguage 0008, SOP COMMON SpecificCharacterS En fonction du langage (FR Code 0005 et (0008,0005) 6 ISO_IR 100...) D_legalAuthe 0040, SR GENERAL / VerifyingObserver Si présent, mettre le nticator A073 VerifyingObserverSequenc Name (0040,A075) VerificationFlag e (0040,A073) et (0040,A493) à VERIFIED, VerifyingObserverI sinon à UNVERIFIED dentificationSequen ce (0040,A088) D_mimeTyp 0042, ENCAPSULATED MIMETypeOfEnca e 0012 DOCUMENT psulatedDocument (0042,0012) D_parentDoc Pourrait être géré si besoin umentld dans l'entête de type SR. D_parentDoc Cf. plus haut umentRelatio nship D_patientId 0010, PATIENT PatientlD 0020 (0010,0020) et IssuerOfPatientlD (0010,0021) D_patientId 0010, PATIENT PatientlD 0021 (0010,0020) et IssuerOfPatientlD (0010,0021) D_practiceSe 0040, SR GENERAL / CodeValue Le troisième de la séquence ttingCode A07C CustodialOrganizationSequ (0008,0100), (le premier est utilisé pour ence (0040,A07C) / CodingSchemeDesi l'id d'institution et le InstitutionCodeSequence gnator (0008,0102) second pour (008,0082) healthcareFacility) D_practiceSe 0040, SR GENERAL / CodeMeaning Le troisième de la séquence ttingCode A07C CustodialOrganizationSequ (0008,0100) (le premier est utilisé pour DisplayNam ence (0040,A07C) / l'id d'institution et le e InstitutionCodeSequence second pour (008,0082) healthcareFacility) D_serviceStar 0008, N'est pas à initialiser à tTime 0020 partir de cett-e valeur mais dans l'auyre sens, cette valeur pourrait être initialisée à partir des information de l'entête d'examen (GENERAL STUDY / StudyDate (0008,0020) et StudyTime (0008,0030)). D_serviceStar 0008, N'est pas à initialiser à tTime 0030 partir de cett-e valeur mais dans l'auyre sens, cette valeur pourrait être initialisée à partir des information de l'entête d'examen (GENERAL STUDY / StudyDate (0008,0020) et StudyTime (0008,0030)). D_serviceS to pTime D_size D_sourcePat 0010, PATIENT OtherPatientlD Au cas où il y a une ientld 0020 (0010,0020) réconciliation, le champ OtherPatientld permettra de récupérer le nom original. D_sourcePat 0010, PATIENT PatientsName Au cas où il y a une ientInfo 0010 (0010,0010), réconciliation, le champ PatientsBirthDate OtherPatientName (0010,0030), permettra de récupérer le PatientsBirthTime nom original. (0010,0032), PatientsSex (0010,0040), PatientsAddress (0010,1040) et OtherPatientNames (0010,1001) D_sourcePat 0010, PATIENT PatientsName Au cas où il y a une ientInfo 0030 (0010,0010), réconciliation, le champ PatientsBirthDate OtherPatientName (0010,0030), permettra de récupérer le PatientsBirthTime nom original. (0010,0032), PatientsSex (0010,0040), PatientsAddress (0010,1040) et OtherPatientNames (0010,1001) D_sourcePat 0010, PATIENT PatientsName Au cas où il y a une ientInfo 0032 (0010,0010), réconciliation, le champ PatientsBirthDate OtherPatientName (0010,0030), permettra de récupérer le PatientsBirthTime nom original. (0010,0032), PatientsSex (0010,0040), PatientsAddress (0010,1040) et OtherPatientNames (0010,1001) D_sourcePat 0010, PATIENT PatientsName Au cas où il y a une ientInfo 0040 (0010,0010), réconciliation, le champ PatientsBirthDate OtherPatientName (0010,0030), permettra de récupérer le PatientsBirthTime nom original. (0010,0032), PatientsSex (0010,0040), PatientsAddress (0010,1040) et OtherPatientNames (0010,1001) D_sourcePat 0010, PATIENT PatientsName Au cas où il y a une ientInfo 1000 (0010,0010), réconciliation, le champ PatientsBirthDate OtherPatientName (0010,0030), permettra de récupérer le PatientsBirthTime nom original. (0010,0032), PatientsSex (0010,0040), PatientsAddress (0010,1040) et OtherPatientNames (0010,1001) D_sourcePat 0010, PATIENT PatientsName Au cas où il y a une ientInfo 1001 (0010,0010), réconciliation, le champ PatientsBirthDate OtherPatientName (0010,0030), permettra de récupérer le PatientsBirthTime nom original. (0010,0032), PatientsSex (0010,0040), PatientsAddress (0010,1040) et OtherPatientNames (0010,1001) D_title 0042, ENCAPSULATED DocumentTitle 0010 DOCUMENT (0042,0010) D_typeCode 0040, ENCAPSULATED CodeValue Type de code = Loinc (LN) A043 DOCUMENT / (0008,0100) ou autre dans ConceptNameCodeSequen CodingSchemeDesignator ce (0040,A043) (0008,0102) voire version dans CodingSchemeVersion (0008,0103) D_typeCode 0040, ENCAPSULATED CodeMeaning Cf plus haut DisplayNam A043 DOCUMENT / (0008,0104) e ConceptNameCodeSequen ce (0040,A043) D_uniqueId 0040, SOP COMMON, SOPInstanceUID Traitement différent si UID A390 ENCAPSULATED (0008,0018), �pur� ou � étendu � : Si DOCUMENT et SOP ENC./InstanceNum uniqueld est � pur UID �, COMMONIHL7Structured ber (0020,0013) et l'utiliser en tant que SOP DocumentSequence HL7/HL7InstanceI Instance UID, sinon en (0040,A390) dentifier créer un. Mettre toujours (0040,E001) si uniqueld dans CDA InstanceNumber et éventuellement aussi dans la structure HL7 si le document est CDA. D_URI 0040, SOP RetrieveURl Rempli par le serveur sur la A390 COMMONIHL7Structured (0040,E010) base d'un WADO simplifié DocumentSequence par exemple s'il y un intérêt (0040,0390) à le faire (ce qui reste à démontrer). S_authorinstit 0008, GENERAL SERIES / InstitutionName ution (sub- 1052 PerformingPhysicianldentif (0008,0080), attribute of icationSequence InstitutionCodeSeq author) (0008,1052) uence (0008,0082) S_authorPers 0008, GENERAL SERIES PerformingPhysicia Exception, rajouter ce on (sub- 1050 nsName champ de l'entète générale attribute of (0008,1050) et de la série à l'entète série author) Personldentificatio document. Utiliser la nCodeSequence première entrée pour (0040,1101) l'identifiant de l'auteur. Seule la première entrée de l'auteur est utilisée. S_authorRole 0008, GENERAL SERIES / Personldentificatio La seconde entrée (mise à (sub-attribute 1052 PerformingPhysicianldentif nCodeSequence UNKNOWN) si le rôle est of author) icationSequence (0040,1101) / vide mais la spécialité ne (0008,1052) CodeValue l'est pas. Seule la première (0008,0100), entrée du rôle est utilisée, CodeMeaning les autres étant ignorées. (0008,0104) et CodingSchemeDesi gnator (0008,0102) S_authorSpec 0008, GENERAL SERIES / Personldentificatio La troisième entrée si non ialty (sub- 1052 PerformingPhysicianldentif nCodeSequence vide. Seule la première attribute of icationSequence (0040,1101) / entrée de la spécialité est author) (0008,1052) CodeValue utilisée, les autres étant (0008,0100), ignorées. CodeMeaning (0008,0104) et CodingSchemeDesi gnator (0008,0102) S_availability Status S_comments 0008, ENCAPSULATED PerformedProcedur Si pas vide Series 103E DOCUMENT SERTES eStepDescription description si comments pas (0040,0254), voire vide et title vide SeriesDescrition (0008,103E) S_comments 0040, ENCAPSULATED PerformedProcedur Si pas vide Series 0254 DOCUMENT SERTES eStepDescription description si comments pas (0040,0254), voire vide et title vide SeriesDescrition (0008,103E) S_contentTy 0040, ENCAPSULATED CodeValue Avec peCode 0260 DOCUMENT SERTES / (0008,0100) CodingSchemeDesignator PerformedProtocolCodeSe (0008,0102) quence (0040,0260) S_contentTy 0040, ENCAPSULATED CodeMeaning peCodeDispl 0260 DOCUMENT SERTES / (0008,0104) ayName PerformedProtocolCodeSe quence (0040,0260) S_entryUUID S_intendedRe 0008, GENERAL STUDY ReferringPhysician Seul le premier destinataire cipient 0090 MODULE sName (0008,0090) est stocké dans ce champ S_intendedRe 0008, GENERAL STUDY ReferringPhysicianI Seul le premier destinataire cipient 0096 MODULE dentificationSequen est stocké dans ce champ ce (0008,0096) S_patientId 0010, PATIENT PatientID 0020 (0010,0020) et IssuerOfPatientTD (0010,0021) S_patientId 0010, PATIENT PatientID 0021 (0010,0020) et IssuerOfPatientTD (0010,0021) S_sourceId 0008, SOP COMMON InstanceCreatorUT 0014 D (0008,0014) S_submissio 0040, ENCAPSULATED PerformedProcedur nTime 0244 DOCUMENT SERTES eStepStartDate (0040,0244), PerformedProcedur eStepStartTime (0040,0254) S_submissio 0040, ENCAPSULATED PerformedProcedur nTime 0245 DOCUMENT SERTES eStepStartDate (0040,0244), PerformedProcedur eStepStartTime (0040,0254) S_title 0008, ENCAPSULATED SeriesDescription Si pas vide PPS description 103E DOCUMENT SERTES (0008,103E) voire si comments vide PerformedProcedur eStepDescription (0040,0254) ENCAPSULATED DOCUMENT SERIES SerieslnstanceUlD (0020,000E) 0020, 000E S_uniqueId REVENDICATIONS1. Procédé de conversion d'un document source décrit dans un format source et d'au moins une méta donnée associée décrite dans ledit format source ou dans un format permettant la génération de méta données dans ledit format source, vers au moins un document de destination décrit dans un format de destination, dans un dispositif de conversion, en vue du stockage dans un système d'information et/ou de la transmission vers un système d'imagerie, caractérisé en ce que ledit format source est conforme à un premier protocole d'échange et/ou de partage de documents médicaux non images et ledit format de destination est conforme à un second protocole d'échange et/ou de partage de documents numériques d'imagerie médicale, et en ce que ledit procédé comprend les étapes suivantes : insertion dudit document source dans une première partie dudit document de destination ; transposition de ladite au moins une méta donnée en une donnée transposée ; insertion de ladite donnée transposée dans une deuxième partie dudit document de destination, distincte de ladite première partie. 2. Procédé de conversion selon la revendication 1, caractérisé en ce que ladite étape de transposition comprend les sous-étapes suivantes : - décodage de ladite au moins une méta donnée ; - identification, parmi une pluralité de champs compris dans ladite deuxième partie dudit document de destination, d'un champ assurant une fonctionnalité équivalente à celle de ladite au moins une méta donnée ; conversion de ladite au moins une méta donnée en ladite donnée transposée à insérer dans ledit champ identifié. 3. Procédé de conversion selon la revendication 2, caractérisé en ce que ladite étape d'identification comprend les sous-étapes suivantes : - détermination d'un niveau d'information de ladite méta donnée ;sélection dudit champ en fonction dudit niveau déterminé. 4. Procédé de conversion selon la revendication 3, caractérisé en ce que ledit niveau d'information appartient au groupe comprenant : niveau relatif à un patient auquel est lié ledit document source ; niveau relatif à un jeu de documents auquel appartient ledit document source, noté lot de soumission ; niveau relatif au document source. 5. Procédé de conversion selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite étape de transposition prend en considération au moins une information appartenant au groupe comprenant : une information liée à un patient ; une information liée à un lot de soumission ; une information liée audit document source. 6. Procédé de conversion selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit format source est � IHE-XDS � et ledit format de destination est � DICOM �. 7. Procédé de conversion d'un document source décrit dans un format source vers au moins un document de destination décrit dans un format de destination et au moins une méta donnée associée, décrite dans ledit format de destination ou dans un format permettant la génération de méta données dans ledit format de destination, dans un dispositif de conversion, en vue du stockage dans un système d'imagerie et/ou de la transmission vers un système d'information, caractérisé en ce que ledit format source est conforme à un premier protocole d'échange et/ou de partage de documents numériques d'imagerie médicale et ledit format de destination est conforme à un deuxième protocole d'échange et/ou de partage de documents médicaux non images, et en ce que ledit procédé comprend les étapes suivantes : insertion d'une première partie dudit document source dans ledit document de destination ; transposition d'une deuxième partie dudit document source en aumoins une méta donnée associée audit document de destination. 8. Procédé de conversion selon la revendication 7, caractérisé en ce que ladite étape de transposition comprend les sous-étapes suivantes : - décodage d'au moins un champ de ladite deuxième partie dudit document source ; identification d'une méta donnée associée audit document de destination assurant une fonctionnalité équivalente à celle de dudit champ ; conversion dudit champ vers ladite au moins une méta donnée identifiée. 9. Procédé de conversion selon la revendication 8, caractérisé en ce que ladite étape d'identification comprend les sous-étapes suivantes : - détermination d'un niveau d'information dudit champ identifié ; sélection de ladite méta donnée en fonction dudit niveau déterminé. 15 10. Procédé de conversion selon la revendication 9, caractérisé en ce que ledit niveau d'information appartient au groupe comprenant : niveau relatif à un patient auquel est lié ledit document source ; niveau relatif à un examen subi par un patient ; niveau relatif à une série de documents à laquelle appartient ledit 20 document source ; niveau relatif audit document source. 11. Procédé de conversion selon l'une quelconque des revendications 7 à 10, caractérisé en ce que ladite étape de transposition prend en considération au moins une information appartenant au groupe comprenant : 25 une information liée à un patient ; une information liée à un examen ; une information liée à une série de documents ; une information liée audit document source. 12. Procédé de conversion selon l'une quelconque des revendications 7 à 11, 30 caractérisé en ce que ledit format source est � DICOM � et ledit format de 10destination est � IHE-XDS �. 13. Dispositif de conversion d'un document source décrit dans un format source et d'au moins une méta donnée associée décrite dans ledit format source ou dans un format permettant la génération de méta données dans ledit format source, vers au moins un document de destination décrit dans un format de destination, en vue du stockage dans un système d'information et/ou de la transmission vers un système d'imagerie, caractérisé en ce que ledit format source est conforme à un premier protocole d'échange et/ou de partage de documents médicaux non images et ledit format de destination est conforme à un second protocole d'échange et/ou de partage de documents numériques d'imagerie médicale, et en ce que ledit dispositif comprend : des moyens d'insertion dudit document source dans une première partie dudit document de destination ; des moyens de transposition de ladite au moins une méta donnée en une donnée transposée ; des moyens d'insertion de ladite donnée transposée dans une deuxième partie dudit document de destination, distincte de ladite première partie. 14. Dispositif de conversion d'un document source décrit dans un format source vers au moins un document de destination décrit dans un format de destination et au moins une méta donnée associée, décrite dans ledit format de destination ou dans un format permettant la génération de méta données dans ledit format de destination, en vue du stockage dans un système d'imagerie et/ou de la transmission vers un système d'information, caractérisé en ce que ledit format source est conforme à un premier protocole d'échange et/ou de partage de documents numériques d'imagerie médicale et ledit format de destination est conforme à un deuxième protocole d'échange et/ou de partage de documents médicaux non images, et en ce que ledit dispositif comprend :des moyens d'insertion d'une première partie dudit document source dans une première partie dudit document de destination ; des moyens de transposition d'une deuxième partie dudit document source en au moins une méta donnée associée audit document de 5 destination. 15. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de conversion selon l'une 10 au moins des revendications 1 à 6, lorsque ledit programme est exécuté sur un ordinateur. 16. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de 15 code de programme pour la mise en oeuvre du procédé de conversion selon l'une au moins des revendications 7 à 12, lorsque ledit programme est exécuté sur un ordinateur.