FR2931570A1 - Procedes de conversion de documents medicaux, dispositifs et programmes d'ordinateur correspondants - Google Patents
Procedes de conversion de documents medicaux, dispositifs et programmes d'ordinateur correspondants Download PDFInfo
- Publication number
- FR2931570A1 FR2931570A1 FR0853408A FR0853408A FR2931570A1 FR 2931570 A1 FR2931570 A1 FR 2931570A1 FR 0853408 A FR0853408 A FR 0853408A FR 0853408 A FR0853408 A FR 0853408A FR 2931570 A1 FR2931570 A1 FR 2931570A1
- Authority
- FR
- France
- Prior art keywords
- document
- format
- destination
- source
- metadata
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/258—Data format conversion from or to a database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H30/00—ICT specially adapted for the handling or processing of medical images
- G16H30/20—ICT specially adapted for the handling or processing of medical images for handling medical images, e.g. DICOM, HL7 or PACS
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Health & Medical Sciences (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Public Health (AREA)
- Strategic Management (AREA)
- Human Resources & Organizations (AREA)
- Epidemiology (AREA)
- Primary Health Care (AREA)
- Medical Informatics (AREA)
- Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- General Physics & Mathematics (AREA)
- Entrepreneurship & Innovation (AREA)
- Data Mining & Analysis (AREA)
- Marketing (AREA)
- General Business, Economics & Management (AREA)
- Tourism & Hospitality (AREA)
- Quality & Reliability (AREA)
- Operations Research (AREA)
- Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
- Radiology & Medical Imaging (AREA)
- Economics (AREA)
- General Engineering & Computer Science (AREA)
- Medical Treatment And Welfare Office Work (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Document Processing Apparatus (AREA)
Abstract
L'invention concerne un 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. Selon l'invention, 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 d'imagerie médicale, et 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.
Description
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 : <Classification ...> <Slot name="authorPerson"> <ValueList><rim:Value>0993000462^DURAND^Romuald^B^^Dr. </Value></ValueList></Slot> <Slot name=" authorinstitution"> <ValueList><Value>Groupe Pitié Salpétrière^^^^^^^^^1750100125 </Value></ValueList></Slot> <Slot name="authorRole"> <ValueList><Value>Médecin </Value></ValueList></Slot> <Slot name="authorSpecialty"> <ValueList><Value>Radiologie </Value></ValueList></Slot> </Classification> 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
Claims (16)
- 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.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0853408A FR2931570B1 (fr) | 2008-05-26 | 2008-05-26 | Procedes de conversion de documents medicaux, dispositifs et programmes d'ordinateur correspondants |
| US12/994,704 US20110138269A1 (en) | 2008-05-26 | 2009-05-18 | Methods for converting medical documents and corresponding devices and computer software |
| EP09753807A EP2279475A1 (fr) | 2008-05-26 | 2009-05-18 | Procedes de conversion de documents medicaux, dispositifs et programmes d'ordinateur correspondants |
| PCT/EP2009/056031 WO2009144152A1 (fr) | 2008-05-26 | 2009-05-18 | Procedes de conversion de documents medicaux, dispositifs et programmes d'ordinateur correspondants |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0853408A FR2931570B1 (fr) | 2008-05-26 | 2008-05-26 | Procedes de conversion de documents medicaux, dispositifs et programmes d'ordinateur correspondants |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2931570A1 true FR2931570A1 (fr) | 2009-11-27 |
| FR2931570B1 FR2931570B1 (fr) | 2010-07-30 |
Family
ID=40020160
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0853408A Expired - Fee Related FR2931570B1 (fr) | 2008-05-26 | 2008-05-26 | Procedes de conversion de documents medicaux, dispositifs et programmes d'ordinateur correspondants |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20110138269A1 (fr) |
| EP (1) | EP2279475A1 (fr) |
| FR (1) | FR2931570B1 (fr) |
| WO (1) | WO2009144152A1 (fr) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11206245B2 (en) * | 2009-10-14 | 2021-12-21 | Trice Imaging, Inc. | Systems and devices for encrypting, converting and interacting with medical images |
| CN102713913B (zh) | 2009-10-14 | 2016-08-31 | 特莱斯伊美津股份有限公司 | 用于转换医学图像并将医学图像输送到移动设备和远程通信系统的系统和方法 |
| US11948678B2 (en) * | 2009-10-14 | 2024-04-02 | Trice Imaging, Inc. | Systems and devices for encrypting, converting and interacting with medical images |
| US11462314B2 (en) | 2009-10-14 | 2022-10-04 | Trice Imaging, Inc. | Systems and devices for encrypting, converting and interacting with medical images |
| US9712498B2 (en) * | 2009-10-14 | 2017-07-18 | Trice Imaging, Inc. | Systems and devices for encrypting, converting and interacting with medical images |
| US8498881B2 (en) | 2009-10-20 | 2013-07-30 | Universal Research Solutions, Llc | Generation and data management of a medical study using instruments in an integrated media and medical system |
| US9678956B2 (en) * | 2012-02-17 | 2017-06-13 | Kno2 Llc | Data capturing and structuring method and system |
| US9607038B2 (en) * | 2013-03-15 | 2017-03-28 | International Business Machines Corporation | Determining linkage metadata of content of a target document to source documents |
| US20140317109A1 (en) * | 2013-04-23 | 2014-10-23 | Lexmark International Technology Sa | Metadata Templates for Electronic Healthcare Documents |
| US11243974B2 (en) * | 2016-12-29 | 2022-02-08 | Hyland Switzerland Sarl | System and methods for dynamically converting non-DICOM content to DICOM content |
| US20180342314A1 (en) * | 2017-02-15 | 2018-11-29 | Marshfield Clinic Health System, Inc. | System and method for medical imaging workflow management without radiology information systems |
| CN109726182A (zh) * | 2018-12-28 | 2019-05-07 | 新博卓畅技术（北京）有限公司 | 一种基于非结构化数据库和ipf的共享文档的系统 |
| US11250018B2 (en) * | 2019-06-25 | 2022-02-15 | Periscope Data Inc. | Method for automated query language expansion and indexing |
| US20230162837A1 (en) * | 2021-11-24 | 2023-05-25 | Efferent LLC | Method and apparatus for clinical data integration |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002077863A2 (fr) * | 2001-03-27 | 2002-10-03 | Koninklijke Philips Electronics N.V. | Dicom vers generateur xml |
| WO2004102412A1 (fr) * | 2003-05-19 | 2004-11-25 | Intellirad Solutions Pty Ltd | Distribution de donnees dicom |
| US20070118540A1 (en) * | 2005-11-23 | 2007-05-24 | Oracle International Corporation | integrating medical data and images in a database management system |
| US20070143342A1 (en) * | 2005-12-21 | 2007-06-21 | Vannostrand S L | Destination based extraction of XML clinical data |
| US20070286466A1 (en) * | 2006-05-25 | 2007-12-13 | Heffernan Patrick B | DICOM adapter service for CAD system |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6275869B1 (en) * | 1994-11-22 | 2001-08-14 | Eastman Kodak Company | System for network communication of image information between imaging devices according to multiple protocols |
| US6618060B1 (en) * | 2000-04-24 | 2003-09-09 | Ge Medical Systems Global Technology Company, Llc | Method and apparatus for formatting digital images in accordance with user-selected communications standard |
| DE60109621T2 (de) * | 2000-07-25 | 2006-01-19 | ACUO Technologies, LLC, Oakdale | Routen und Speichern innerhalb eines Computer-Netzwerks |
| US7426567B2 (en) * | 2000-09-02 | 2008-09-16 | Emageon Inc. | Methods and apparatus for streaming DICOM images through data element sources and sinks |
| US6725231B2 (en) * | 2001-03-27 | 2004-04-20 | Koninklijke Philips Electronics N.V. | DICOM XML DTD/schema generator |
| US20030005464A1 (en) * | 2001-05-01 | 2003-01-02 | Amicas, Inc. | System and method for repository storage of private data on a network for direct client access |
| US6950985B2 (en) * | 2001-12-27 | 2005-09-27 | Koninklijke Philips Electronics, N.V. | Specifying DICOM semantic constraints in XML |
| US7523505B2 (en) * | 2002-08-16 | 2009-04-21 | Hx Technologies, Inc. | Methods and systems for managing distributed digital medical data |
| CA2528492A1 (fr) * | 2003-06-04 | 2005-01-06 | The Trustees Of The University Of Pennsylvania | Schema de base de donnees ndma, traduction de dicom en schemas relationnels, et traduction de demandes xml en sql |
| US20060064328A1 (en) * | 2004-08-30 | 2006-03-23 | Debarshi Datta | System and method for utilizing a DICOM structured report for workflow optimization |
| US8489410B2 (en) * | 2005-02-22 | 2013-07-16 | Medimaging Tools, Llc | System and method for modifying and routing DICOM examination files |
| US20070041647A1 (en) * | 2005-07-22 | 2007-02-22 | Charles Florin | Method for increasing the flexibility of DICOM tags management in application-specific integration |
| EP2036003B1 (fr) * | 2006-06-30 | 2017-05-03 | Leica Biosystems Imaging, Inc. | Procédé de stockage et de récuperation de grandes images par dicom |
| US8156440B2 (en) * | 2007-11-08 | 2012-04-10 | Siemens Aktiengesellschaft | User interface for a DICOM transfer configuration |
| US20090125541A1 (en) * | 2007-11-08 | 2009-05-14 | Franz Amon | Obtaining and providing content for a dicom transfer configuration |
| US20100010983A1 (en) * | 2008-07-11 | 2010-01-14 | Apteryx, Inc. | Automated dicom pre-fetch application |
-
2008
- 2008-05-26 FR FR0853408A patent/FR2931570B1/fr not_active Expired - Fee Related
-
2009
- 2009-05-18 WO PCT/EP2009/056031 patent/WO2009144152A1/fr active Application Filing
- 2009-05-18 US US12/994,704 patent/US20110138269A1/en not_active Abandoned
- 2009-05-18 EP EP09753807A patent/EP2279475A1/fr not_active Withdrawn
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002077863A2 (fr) * | 2001-03-27 | 2002-10-03 | Koninklijke Philips Electronics N.V. | Dicom vers generateur xml |
| WO2004102412A1 (fr) * | 2003-05-19 | 2004-11-25 | Intellirad Solutions Pty Ltd | Distribution de donnees dicom |
| US20070118540A1 (en) * | 2005-11-23 | 2007-05-24 | Oracle International Corporation | integrating medical data and images in a database management system |
| US20070143342A1 (en) * | 2005-12-21 | 2007-06-21 | Vannostrand S L | Destination based extraction of XML clinical data |
| US20070286466A1 (en) * | 2006-05-25 | 2007-12-13 | Heffernan Patrick B | DICOM adapter service for CAD system |
Also Published As
| Publication number | Publication date |
|---|---|
| EP2279475A1 (fr) | 2011-02-02 |
| US20110138269A1 (en) | 2011-06-09 |
| WO2009144152A1 (fr) | 2009-12-03 |
| FR2931570B1 (fr) | 2010-07-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2931570A1 (fr) | Procedes de conversion de documents medicaux, dispositifs et programmes d'ordinateur correspondants | |
| US11948029B2 (en) | Access control for encrypted data in machine-readable identifiers | |
| Dolin et al. | The HL7 clinical document architecture | |
| Clunie et al. | Technical challenges of enterprise imaging: HIMSS-SIIM collaborative white paper | |
| FR2953961A1 (fr) | Outils et procedures d'interoperabilite pour agreger et consolider les resultats de tests de laboratoire | |
| Peng et al. | A literature review of current technologies on health data integration for patient-centered health management | |
| US20220028506A1 (en) | Data capturing and exchange method and system | |
| CA2864590A1 (fr) | Procede et systeme de structuration et de capture de donnees | |
| Zawali et al. | Realising a push button modality for video-based forensics | |
| CN112635026A (zh) | 基于云的患者数据交换 | |
| Sun et al. | Meaningful secret image sharing scheme with high visual quality based on natural steganography | |
| US20150213218A1 (en) | Medical information management apparatus | |
| US10692592B2 (en) | Synchronization of healthcare data across disparate data centers | |
| Takaoğlu et al. | A novel and robust hybrid blockchain and steganography scheme | |
| Shahid et al. | A two-stage de-identification process for privacy-preserving medical image analysis | |
| Natsheh et al. | Automatic selective encryption of DICOM images | |
| Sui et al. | Reversible data hiding in encrypted images based on hybrid prediction and huffman coding | |
| Trigo et al. | Building standardized and secure mobile health services based on social media | |
| Dixon et al. | Facilitating HIE in Denmark: the story of MedCom, a Danish health information organization | |
| US20180330806A1 (en) | System and method for virtual enablement of health care services | |
| Pervan et al. | MIDOM—A DICOM-Based Medical Image Communication System | |
| Wu et al. | Block-based steganography method using optimal selection to reach high efficiency and capacity for palette images | |
| Parikh et al. | PACS: next generation | |
| Shaikh et al. | A system design for a telemedicine health care system | |
| Evsutin et al. | Algorithm of information embedding into digital images based on the Chinese remainder theorem for data security |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 9 |
|
| ST | Notification of lapse |
Effective date: 20180131 |