FR 2953961 A1 20110617 FR 1060577 A 20101215 AU' r~r~r r.~ w mr TTA T T TT1f1 RE EK~I'V(~ CROISEE POUR HYYLILA IÛNJ LILLJ (0001) Le présent dépôt s'appuie sur le dépôt de l'application de brevet provisionnel 61/286.609 effectué le 15 décembre 2009. Les contenus de l'application provisionnelle sont reportés ici en référence à leur exhaustivité. ORIGINE DE L'INVENTION Champ de la découverte (0002) La présente invention se rapporte aux dossiers santé électroniques et, en particulier, à l'enregistrement électronique des résultats de tests de laboratoires et à assurer l'interopérabilité quand les résultats des tests de laboratoires sont exprimés dans des formats différents. Description de l'état de l'art (0003) Une transmission fiable et sûre de données entre un laboratoire et un système d'information de laboratoire ("SIL") et ensuite du SIL vers le soignant (médecin, infirmier, etc.), au sein d'une même institution est communément pratiqué dans le champ de la santé. Pendant un temps, une telle transmission de données se limitait à un transfert sous forme "d'image" du document. Cependant, aujourd'hui, le transfert électronique des données est devenu la norme au sein de l'institution. Au sein d'une institution, le client (soignant) peut, dans ce cadre, exécuter ou utiliser un programme simple permettant un échange électronique de données, mais dans un périmètre strictement limité au système institutionnel en interne que constitue le SIL. En dehors de ce cercle limité, l'exportation de résultats de laboratoires est réalisée exclusivement sous format image PDF, en envoyant une copie physique par voie postale ou par fax. Les différents formats interdisent l'intégration des données dans un tableur permettant des comparaisons dans le temps. Afin d'obtenir un tableur unique ou un document contenant des résultats en provenance de différents laboratoires, une intervention manuelle pour l'entrée et la réconciliation des résultats est typiquement nécessaire. (0004) Au vu de ce qui précède, avec une fréquence croissante, un patient peut être porteur de copies physiques de résultats de laboratoires réalisés par différents professionnels entre des professionnels variés pour être revus par un professionnel de santé donné et, par conséquent, les différentes copies physiques ne peuvent pas être publiées sur une plateforme commune avec les résultats obtenus au sein d'un hôpital. Plus avant, lorsqu'un patient recherche des résultats de tests. réalisés par un prestataire extérieur, le format et la plateforme peuvent être différents du format et de la plateforme du laboratoire de l'institution ou de son SIL. (0005) Par exemple, un anesthésiste en charge d'une consultation pré-opératoire peut lire les résultats de laboratoire sur un document papier apporté par le patient ou envoyé directement par le laboratoire. Le résultat de laboratoire peut être transmis par fax ou en format électronique, telle qu'une image PDF, et habituellement sera imprimé dans le cabinet du médecin. Même si la transmission du résultat de laboratoire de l'institution est fournie par voie électronique au médecin, il y aura un degré d'incompatibilité avec le résultat des tests pratiqués en dehors de l'hôpital. Dans ce cas, il ne sera pas possible de présenter les résultats issus de ces différentes facilités sur un document unique utilisable par le soignant. (0006) De plus, en ce qui concerne les patients chroniques, la situation est même pire. Des transferts et prescriptions (différents tests de laboratoire), en aller-retour, interviennent dans la perspective d'un suivi médical partagé entre un centre tertiaire hautement spécialisé et un médecin de proximité (de famille, médecin généraliste) En conséquence, un volume important de transfert d'examens de laboratoires peut s'observer dans les deux directions, entre le centre tertiaire et le médecin de proximité, et vice versa. Les mêmes limitations décrites plus haut se retrouvent. En conséquence, il n'est typiquement pas possible de consolider les résultats en provenance de deux sources différentes automatiquement sur une feuille tableur unique. Un problème similaire se produit au cours d'un travail collaboratif, quand les différents acteurs ne peuvent pas réconcilier leurs propres résultats de laboratoire avec ceux des autres participants du groupe. (0007) La pratique clinique, comme illustré dans les exemples précédents dans le système de soins, a bénéficié d'une approche ontologique qui a conduit, dans la première moitié du XXème siècle, à une classification des maladies (classification évolutive "ICD",version actuelle # 10) et à une facilitation des recherches par l'utilisation de mots signifiants (SNOMED étant la plus répandue parmi de nombreuses applications verticales). Cependant ces solutions qui proposent un langage commun ont des limitations. En ce qui concerne les seules données cliniques, la taxonomie des symptômes de maladies aboutit à une exhaustivité décourageante pour l'utilisateur, en ce qu'existent des centaines de milliers de références dans SNOMED. (0008) En ce qui concerne la biologie, un standard a émergé avec Health Level 7 (HL7). HL7 est une organisation impliquée dans le développement de standards internationaux dans le domaine de la santé. Elle propose un cadre et les standards accompagnants pour l'échange, l'intégration, le partage et la récupération d'informations santé électroniques. Ces données standardisées sont conçues pour permettre aux professionnels de santé de partager l'information clinique efficacement. Ainsi, au sein de HL7, on trouvera par exemple des standards conceptuels (HL7 RIM), des standards documentaires (HL7 CDA), des standards applicatifs (HL7 CCOW) et des standards de messagerie (HL7 versions v2x and V3). Les versions actuellement utilisées de HL7 comprennent HL7 2.5 et HM7 3.0, la dernière intégrant un pont avec le Digital Imaging and COmmunication in Medicine format. La version européenne, dénommée HPrim, quoique largement utilisée, est en phase de régression d'autant qu'une conversion est facilement réalisée. (0009) Même avec l'avènement de HL7, les questions de compatibilité décrites ci-dessus, et les limitations à une seule institution proviennent, pour partie, d'une couche supplémentaire. En plus des standards juste décrits, surgit un problème de vocabulaire, y compris au sein du protocole HL7. Par exemple, au sein des résultats de laboratoire, « globule rouge » peut être défini par une dizaine d'homonymes, synonymes, acronymes, à savoir: globule(s) rouge(s), Erytrocyte(s), érythrocyte(s), (érythrocyte(s), Hématie(s), hématie(s), (Hematie(s), hematie(s), GR, Gr, G.R., parmi d'autres.... De plus des versions propriétaires et des formats non compatibles existants sont utilisés. RESUME DU CORPS DES REVENDICATIONS (0010) Une méthode permettant d'assurer l'interopérabilité des résultats de laboratoires d'un patient est proposée. La méthode comporte la réception, faisant appel à un premier processeur matériel, des résultats entrants sur un serveur central. Les résultats entrants comprennent une pluralité de formats différents et sont conservés sur le serveur central dans leur format originel. Les données des tests de laboratoires sont ensuite converties en un format commun pour obtenir des données de tests de laboratoires homogénéisées. Les données de tests de laboratoires homogénéisées sont ensuite corrélées en faisant appel à un second processeur matériel qui s'appuie sur un code d'identification santé pour rapprocher les données puis est enregistré, présenté sur un document unique en utilisant un troisième processeur matériel. DESCRIPTION SOMMAIRE DES FIGURES (0011) Les caractéristiques de la présente invention seront plus compréhensibles en se référant à la description présentée en conjonction avec les figures suivantes. (0012) La figure 1 est représentative des procédures en accords avec les caractéristiques de la présente invention (0013) La figure 2 est un organigramme des procédures en accord avec les caractéristiques de la présente invention (0014) La figure 3 est une représentation de données biologiques entrantes hétérogènes. (0015) La figure 4 est une table de corrélation illustrative en accord avec les caractéristiques de la présente invention (0016) Les figures 5A et 5B sont des sorties illustratives de tests de laboratoire réconciliés en accord avec les caractéristiques de la présente invention. (0017) Les figures 6A et 6B montrent des résultats graphiques illustratifs de données de test de laboratoires réconciliées en accord avec les caractéristiques de la présente invention. (0018) Le figure 7 montre une vue schématique du système informatique qui peut être utilisé en accord avec une ou plusieurs des caractéristiques de la présente invention. DESCRIPTION DETAILLEE (0019) Les caractéristiques de la présente invention sont expliquées ci-dessous, en référence aux figures associées. Dans les caractéristiques de l'invention, nombre de détails spécifiques sont avancés afin de permettre une meilleure compréhension de l'invention. Cependant, il sera apparent à un spécialiste du domaine de l'invention que celle-ci peut être mise en oeuvre sans ces détails spécifiques. Dans d'autres 4 circonstances, des caractéristiques évidentes ne seront pas décrites de façon à ne pas obscurcir l'invention. (0020) Il doit être entendu que la présente invention fournit de nombreuses variantes ou exemples pour la mise en oeuvre de caractéristiques différentes sur des variations diverses. Des exemples spécifiques par leurs compositions et leurs arrangements sont décrits ci-après pour simplifier la compréhension du présent brevet. Ce ne sont, bien entendu que des exemples qui ne sont pas limitatifs. De plus, le présent brevet peut répéter des lettres ou chiffres de référence dans divers exemples. Cette répétition a pour but de simplifier et de clarifier et n'est pas indicative par elle-même d'une quelconque relation entre les différentes caractéristiques et configurations discutées. De plus, l'ordonnancement de la première disposition sur ou par rapport à la seconde dans la description qui suit peut inclure aussi des caractéristiques dans lesquelles des éléments additionnels peuvent être formés s'interposant entre le première et la seconde de ces dispositions de sorte que celles-ci ne se trouvent plus en contact direct. (0021) En vue de qui précède, un système pour l'interopérabilité des résultats de test de laboratoires est proposé. L'interopérabilité peut être développée pour produire une feuille de tableur unique ou pour tout autre document de référence consolidé. L'interopérabilité, au niveau de l'individu ou du patient, permet de connecter et d'agréger en mode structuré des résultats de tests de laboratoires colligés à partir de sources différentes, à travers des formats différents and de les réconcilier dans un format et/ou un document uniques. (0022) Les éléments rapportés ici sont dirigés vers une agrégation automatique (ou semi-automatique) de résultats le tests de laboratoires réalisés à partir de matériel humain, en particulier de sang, par des laboratoires cliniques et/ou d'autres professionnels de santé. Dans ce contexte, professionnel de santé s'entend pouvoir inclure médecins, infirmiers, techniciens, cabinets, hôpitaux, laboratoires et tout autre individu/institution qui propose des soins à des patients. (0023) De même, les éléments rapportés ici permettent la réconciliation de formats disparates et de variations sémantiques pour produire un résultat unique et cohérent. De la sorte, les caractéristiques de l'invention sont dirigées pour collecter et corréler des données structurées, évitant ainsi l'empilement passif de documents indépendants - simples regroupements d'images, tels que des PDF. Les caractéristiques de l'invention conduisent à une interopérabilité "ex post", à travers un processus de réconciliation de documents et/ou de résultats produits dans différents laboratoires. Les éléments rapportés ici conduisent aussi à un processus de réconciliation pour des documents hétérogènes en termes de taxonomie, d'unités, de valeurs normales, de volumes d'échantillons et/ou de paramètres divers autorisant ainsi une intégration automatique de données de laboratoires. (0024) D'une façon générale, les caractéristiques de l'invention permettent à un serveur sécurisé d'héberger et de traiter des données de laboratoires. Un professionnel de santé peut se connecter de façon sécurisée au serveur et charger des résultats de laboratoires. Les résultats peuvent être déposés dans n'importe quel format - il n'y a aucune exigence sur la nature d'un format particulier. Le serveur peut ensuite travailler ces résultats et les convertir en un format unique créant un format unifié cohérent de données de test de laboratoires. Ce processus peut être répété avec de nombreux laboratoires différents, chacun utilisant un format différent lorsqu'il soumet ou envoie ses données au serveur. Le serveur pourra convertir toutes ces données, issues de différents laboratoires, en un format unifié. Une fois que la donnée est traduite en format unique, le serveur peut la corréler, sur la base d'un code d'identification santé la donnée en format unifié en une donnée nominative corrélée. Les données corrélées peuvent alors être entrées dans ou utilisées pour créer un document unique, tel qu'un tableur ou tout autre document de référence. (0025) De façon avantageuse, le processus décrit plus haut peut être utilisé au profit d'un même patient, tout au long de sa vie. Cependant, afin de mettre en oeuvre un système sécurisé fondé sur un seul et même individu, un identifiant unique peut être nécessaire pour chaque patient individuel. (0026) En conséquence, la première étape pour construire un dossier santé électronique (DSE) est de créer un système d'identification fiable ("ID") que tous les participants au processus de distribution des soins puisse utiliser soit pour entrer des données sur le DES ou pour lire les contenus du dossier associant ainsi le dossier à in patient particulier. Un moyen d'identification qui peut être utilisé est une ID habituelle (fondée sur nom patronymique, prénom, date de naissance, numéro de sécurité sociale, etc.). De façon alternative, lorsque le patient appartient à un plan de santé, une ID peut être fournie en interne avec une procédure spéciale de «bris de glace» Si nécessaire lorsque le patient est vu en dehors de ce réseau. Par exemple, Kaiser Permanente, un plan de santé regroupant assureur et soignants, a développé son propre système en donnant des identifiants aux patients et/ou aux clients. Plusieurs agences gouvernementales, par exemple dans les pays nordiques, au Canada , et en France, ont développé des politiques nationales spécifiques et/ou des règles d'identification personnelle, des procédures et/ou des schémas pour attribuer des identifiants à des individus, citoyens, patients et/ou clients. (0027) Par exemple, en France la CNIL, Commission Nationale de l'Informatique et des Libertés, en charge de la protection des individus dans le monde des technologies de l'information, s'est opposée à l'utilisation du "NIR" (numéro de Sécurité Sociale) et l'Agence des Systèmes d'Information Partagée en santé a établi une procédure utilisant le numéro de sécurité sociale, la date de naissance et une transformation numérique du prénom, combinés à travers un algorithme spécifique pour produire un "INS-C" (Identifiant National Santé - Calculé) résultant en un nombre à 22 chiffres. (0028) Le but des ces dispositions susmentionnées, ou de tout autre schéma d'identification unique, pour partie, est de protéger l'individu vis à vis de voyeurs intrusifs sur le profil médical et/ou le dossier. Toutefois, une limitation majeure de ce schéma d'identification proposé est qu'il n'est plus valable en dehors du territoire, de l'institution, de l'entreprise, de l'autorité, etc., qui assigne ce numéro d'identification unique. (0029) En conséquence, une approche alternative peut consister à combiner cette approche classique décrite plus haut avec une URL personnelle pour chaque dossier médical d'un individu. De plus, ce procédé pourrait être utilisé pour attribuer une URL à chaque ressource dans le système de soins - professionnels de santé, institutions, etc. Attribuer une adresse URL permanente à l'individu pourrait de prolonger en ajoutant un système de numérotation interne dans le nom de domaine et il serait possible dès lors de communiquer largement l'adresse URL à tous les professionnels de santé sans ouvrir de brèche de sécurité à travers une police rigoureuse d'accès et de relevé des passages. (0030) L'approche URL peut permettre un modèle de distribution facile et simple pour les différents professionnels de santé impliqués dans la création du DES d'un patient. Le format est simple d'utilisation et peut permettre de stocker des sous-dossiers parmi les intervenants de ce DSE. De plus, l'identifiant unique fondé sur l'URL peut offrir toute sécurité pour le DSE et être en compliance avec HIPAA et/ou autres règles, régulations, et/ou lois gouvernant le portage de dossiers patients électroniques et de dossiers santé électroniques en particulier. (0031) Un identifiant unique permet une approche normative pour le DSE. Si un patient a un identifiant unique, n'importe quel dossier, quel qu'en soit le format, peut être transféré au serveur central et converti et/ou corrélé en un document de référence unique, incluant toutes les informations pertinentes du patient, autorisant ainsi l'interopérabilité entre différentes sources de données de tests de laboratoires. En fournissant 1111LC1up idu111LC de dossiers pour un patient, assignes Ct un identifiant (1Lj unique, un dossier longitudinal du patient peut être créé. (0032) Nous référant maintenant à la figure 1, un diagramme schématique d'un système en accord avec une ou plusieurs des caractéristiques de l'invention est représenté. Les laboratoires externes (laboratoire 150, laboratoire 151 et laboratoire 151) peuvent être configurés pour envoyer les tests de laboratoire collectés dans leur propre laboratoire au serveur central 100. Les laboratoires 150, 151 et 152 peuvent être des laboratoires de tests sanguins ou d'autres tests médicaux, y compris hospitaliers, configurés pour collecter des échantillons et des données à partir de patients. (0033) Les laboratoires externes 150, 151 et 152 peuvent envoyer les données des tests biologiques par différentes méthodes. Par exemple, laboratoire 150 peut envoyer les données collectées au laboratoire 150 par Apicrypt. Laboratoire 151 peut envoyer les données collectées au laboratoire 151 par transfert FTP sécurisé. Laboratoire 152 peut envoyer les données collectées par e-mail sécurisé ou OpenPGP. De plus, ceux qui sont experts dans le domaine apprécieront que d'autres moyens d'envoi sécurisés ou non pourront être utilisés pour l'envoi de données électroniques d'un laboratoire au serveur central 100. (0034) Le serveur central 100 peut comprendre un ou plusieurs processeurs et une ou plusieurs unités de stockage. De plus, alors qu'il est représenté par une entité serveur/stockage unique le serveur central 100 peut comprendre de multiples serveurs, le traitement et le stockage décrits ici peuvent se dérouler sur des outils matériels séparés et distincts, des redondances peuvent être installées, des images miroirs créées, et/ou d'autres méthodes de traitement et de stockage peuvent être utilisées sans se départir de la logique de la présente invention. Qui plus est, indépendamment du fait que seuls trois laboratoires sont représentés, les experts dans le domaine apprécieront qu'un nombre quelconque de laboratoires peuvent envoyer leurs données au serveur central 100. Enfin, le serveur central 100 peut être un système informatique comme présenté et décrit sur la figure 7. (0035) Le serveur central 100 peut inclure un vérificateur 102, un enregistreur 104, une unité de stockage 106, un ou plusieurs analyseurs 110 (112, 114 et 116) et un traducteur 108. De plus, les experts du domaine apprécieront que bien que le serveur 100 soit présenté avec les caractéristiques décrites, le serveur central 100 peut inclure une ou plusieurs des éléments matériels ou logiciels décrits ici et/ou peut inclure d'autres éléments connus dans l'état de l'art. De plus, le serveur central 100 peut comprendre plus qu'une unité physique et peut être reparti dans plusieurs unités sans que ceci soit en contradiction avec la logique de la présente invention. (0036) Le vérificateur 102 peut être configuré pour arranger les résultats de laboratoire entrants. Le vérificateur 102 peut être un processeur matériel ou un programme informatique. Le vérificateur 102 peut être configuré pour retirer l'information au sein des données entrantes associées à la fonction transport. En conséquence, le vérificateur 102 peut être configuré pour distiller les données de laboratoire entrantes pour ne laisser que les résultats de tests de laboratoire pertinents. (0037) L'enregistreur 104 peut être un programme d'écriture et/ou un processeur matériel qui peut écrire des données à une unité de stockage et/ou à d'autres éléments et/ou à des processeurs matériels appartenant au serveur central 100. L'enregistreur 104 peut être configuré pour écrire des données vers l'unité de stockage 106 qui peut être toute unité de stockage connue dans l'état de l'art. (0038) Le serveur central 100 peut inclure un ou plusieurs analyseurs 110. Un analyseur général 112 peut être configuré pour analyser toute information entrante et/ou distribuer les données entrantes aux autres parsers. Par exemple, les données qui sont en format HL7 peuvent être envoyées à l'analyseur 114. L'analyseur 114 peut être configuré pour analyser les données en format HL7 et peut être configuré pour attribuer un dictionnaire aux données en format HL7, de sorte que les données puissent être traduites, comme décrit ci-après. L'analyseur 116 peut être configuré pour analyser des données en format HPrim. Bien que seulement trois types de «parsers » 110 (112,114 et 116) soient montrés, les experts du domaine apprécieront que plus ou moins d'analyseurs puissent être inclus dans le serveur central 100. En particulier, des analyseurs dédiés aux différentes versions de HL7 et de HPrim et/ou dédiés à d'autres formats/normes connus peuvent être fournis pour analyser plus efficacement les données des tests de laboratoires sans s'extraire de la logique de la présente invention. (0039) Les analyseurs 110 peuvent attribuer un dictionnaire à chaque format, tel que HL7 et HPrim . Le dictionnaire peut fournir une table de correspondance entre le format HL7, ou le format HPrim pour un format générique tel que Logical Observation Identifier Names and Codes ("LOINC''). Plus avant, les analyseurs 110 peuvent être configurés pour hacher le format original et produire des données hachées auxquelles pourra être assigné un dictionnaire. (004x) Le traducteur 108 peut être configuré pour traduire les données du format original (HL7, HPrim) à un format générique (par exemple, LOINC) en utilisant les dictionnaires assignés. Par exemple, le traducteur peut être configuré, en utilisant un dictionnaire attribué, de données hachées en LOINC. Le traducteur 108 peut être configuré pour corréler les données des différents laboratoires et générer des données corrélées 120, de la sorte à incorporer chacun des ensembles de données en un document unique. Les données corrélées 120 peuvent constituer un dossier santé complet pour un patient particulier ou peuvent constituer un ensemble de données unique relevées sur une période de temps à partir de laboratoires particuliers, ou peut représenter tout autre ensemble de données. (0041) Maintenant, en référence à la figure 2, un processus de génération de données corrélées pour un patient sera décrit. Initialement, au niveau 210, les laboratoires peuvent envoyer des données de tests de laboratoire vers un serveur central pour être traitées. Le serveur central peut recevoir les données dans une localisation distante par rapport à la source d'émission des laboratoires. Pour permettre un transport sécurisé des données médicales, par exemple, Apicrypt (qui est un système de messagerie sécurisée utilisant une messagerie électronique, fondée sur un registre de partenaires parmi les professionnels de santé, détenteurs d'une clé privée) peut être utilisé. De façon alternative, d'autres méthodes de transferts de messageries électroniques sécurisées peuvent être utilisées. (0042) Par exemple, un laboratoire peut se connecter de façon sécurisée à un serveur. Lorsqu'il appelle et se connecte au serveur, le laboratoire peut utiliser un réseau privé virtuel, ou toute autre forme de connexion sécurisée. Le laboratoire, une fois connecté, peut ensuite transférer les données des tests de laboratoire au serveur par un système de messagerie sécurisée, tel qu'Apicrypt, mentionné plus haut. Bien qu'Apicrypt soit mentionné ici, les experts du domaine apprécieront que d'autres outils de cryptage puissent être utilisés sans sortir de la logique de l'invention. De plus, bien qu'un réseau privé virtuel soit mentionné ici comme moyen de se connecter au serveur, les experts apprécieront que d'autres méthodes de connexion sécurisée peuvent être utilisées sans sortir de la logique de l'invention. Par exemple, des systèmes de messagerie sécurisée, e-mail sécurisé, FTP, FTPS, web services sécurisés, et/ou tout autre méthode sécurisée et/ou cryptée ou processus connus dans l'art peuvent être utilisés sans sortir de la logique de l'invention. Le processus, décrit ici, ne repose pas sur un seul format et/ou méthode de transport et, par conséquent, n'importe quels et tous formats de transport de données peuvent être utilisés. (vv43) Puis, au niveau 220, les données entrantes du laboratoire peuvent être vérifiées. Parce que les différents laboratoires peuvent envoyer les données des tests de laboratoire par différents moyens et méthodes, la fonction du vérificateur est de retirer l'information liée au protocole de transport des données pour ne conserver que les données pertinentes des tests de laboratoire. Aucune donnée externe, telle que l'adresse et/ou les données du protocole, ne peut être part des données des tests de laboratoire après que l'action du vérificateur ait été complète. (0044) Puis, au niveau 230, les données des tests de laboratoire, après avoir été vérifiées peuvent être stockées. Les données des tests de laboratoires, au niveau 230, peuvent être du matériel brut et non traité, hormis l'ablation des données liées au transport et au protocole. En conséquence, une copie de la donnée originelle, avant tout traitement, peut être stockée. (0045) Puis, au niveau 240, les données des tests de laboratoire peuvent être analysées. Pendant cette analyse, à l'étape 240, les données des tests de laboratoires peuvent se voir attribuer un dictionnaire associé à un référentiel particulier de données de tests de laboratoire. Un dictionnaire peut fournir un ensemble de données d'équivalents qui peuvent inclure un libellé-plus-unités permettant une traduction vers un code générique ou propriétaire. (0046) De plus, en accord avec les caractéristiques de l'invention, les données des tests de laboratoire peuvent être hachées au moment où elles sont analysées Par exemple, une fonction de hachage et/ou un algorithme peuvent être utilisées. La fonction de hachage peut extraire l'information concernant le patient et/ou le laboratoire d'origine, le code des résultats des tests de laboratoire et/ou d'autres informations désirées ou souhaitées. De plus, les experts du domaine apprécieront que d'autre informations et/ou combinaisons d'informations peuvent être utilisées ou extraites pendant cette fonction de hachage, sans sortir de la logique de l'invention. En conséquence, au niveau 240, les données des tests de laboratoire peuvent être analysées, hachées et se voir attribuer un dictionnaire qui peut permettre la traduction de données du format originel à leur réception vers un format générique. (0047) La fonction d'analyse peut permettre la réconciliation et la conversion de formats hétérogènes de données de tests de laboratoire pour les corréler et les agréger dans un format unique utilisable indépendamment de la méthode de livraison ou du format des données de tests de laboratoire. Le principe de base est de ne rien imposer aux laboratoires quand la donnée de test de laboratoire est transférée au serveur central ; il n'y a aucune exigence de format spécifique, pas d'exigence d'un protocole de transfert particulier (autre que ceux imposés par les règles, régulations et/ou dispositions législatives). En conséquence, les techniques de l'invention permettent à tous les laboratoires de 11 conserver leur logiciel existant et/ou leurs protocoles et n'imposent aucun changement sur leurs systèmes internes. (0048) Puis, au niveau 250, les données analysées qui peuvent se voir attribuer un dictionnaire peuvent être traduites en un format générique. Le format générique peut être ensuite traduit en un langage universel, tel qu'un code d'identification santé ou, plus spécifiquement, « Logical Observation Identifiers Names and Codes (LOINC) utilisant le dictionnaire attenant. En conséquence, une table de correspondance peut être créée entre les données hachées et le LOINC. En conséquence, les dictionnaires peuvent fournir une traduction pour une fonction hachée d'un format standard, tel que HL7 ou HPrim en LOINC. Les données traduites peuvent être rapprochées pour former des données structurées. (0049) Par exemple, des données peuvent être fournies en format HL7. Pour HL7, chaque ligne annonçant un résultat codé démarre avec « OBX », les éléments étant séparés par des pipes "1", et des subdivisions désignées par "^" ou ". En contraste, les données fournies dans le format HPrim annoncent un résultat codé avec "RES," et seules les pipes "1" sont utilisées comme séparateurs. De plus, il existe plusieurs versions de HL7 et HPrim et, de surcroît, tous les laboratoires ne se conforment pas à ces deux formats, de sorte que d'autres formats peuvent être adressés au serveur central. Comme démontré dans la figure 3, le laboratoire A peut fournir des données de tests de laboratoire en format de données 1, HL7 et le laboratoire B peut fournir des données de tests de laboratoire en format de données 2, HPrim. (0050) Dans le but de permettre aux processus de compatibilité et d'interopérabilité de se réaliser, les données entrantes de tests de laboratoire doivent être converties en un format utilisable et cohérent. En conséquence, les données des tests de laboratoires peuvent être transformées de façon générique en Java Script Object Notation. Pour convertir en Java Script Object Notation, à partir de langages multiples, un test ou code unique peut être fourni qui servira à convertir les données des tests de laboratoires. A cet effet, le serveur central peut comporter une liste de référence qui fournit une table de conversion pour chacun des langages entrants pour les convertir en Java Script Object Notation. (0051) Finalement, au niveau 260, les données corrélées peuvent être utilisées pour générer un document unique. Une fois que les données sont converties en LOINC, elles peuvent être écrites en un système de données unifié, cohérent et unique. Ce document unique peut être un fichier, un tableur, un texte ou tout autre format électronique qui peut inclure toutes les informations concernant un patient, collectées à partir de sources variées. (0052) En se référant maintenant à la figure 3, un exemple de différents formats entrants est présenté. Le laboratoire A peut fournir des données avec un cryptage faisant appel à une clé qui peut être en format données 300. Ce format de données 300 peu être de type HL7. Le laboratoire B peut fournir des données avec un cryptage faisant appel à une clé qui peut être en format données 302. Ce format de données 302 peu être de type HPrim. En conséquence, la figure 3 montre différents laboratoires proposant des données de tests de laboratoire en différents formats. (0053) Maintenant, en se référant maintenant à la figure 4, un exemple de tables de correspondances est présenté. Les données des tests de laboratoire peuvent être hachées à partir d'un format original, tel que HL7 ou HPrim, et converties en un ensemble de données hachées 400. L'ensemble de données hachées peut être fourni avec une correspondance ou une traduction en données LOINC format 402. Par conséquent, en accord avec une ou plusieurs caractéristiques de l'invention, une table de correspondance ou un dictionnaire peuvent être fournis pour convertir n'importe quel format en un format générique. (0054) Une fois que le processus décrit ici est achevé, un pont peut être établi pour les parties externes telles qu'un professionnel de santé, pour accéder au format unifié de données de tests de laboratoire et/ou à des fichiers textes. Le pont peut utiliser une table d'association reliée au numéro d'identification unique d'un patient donné, comme discuté plus haut, pour partager les données entre les professionnels de santé qui peuvent avoir besoin d'accéder aux données des tests de laboratoire. Afin d'obtenir ces données, l'institution peut être équipée avec un dérivé de l'application analyseur. Le dérivé de l'application analyseur comporte, du côté de l'institution, une fonction analyseur simple, au lieu des multiples analyseurs pour chacun des formats généralement usités et d'un analyseur général. La fonction analyseur simple de l'application analyseur dérivée transformera le format unifié des données des tests de laboratoire envoyés par le pont en données utilisables par le requérant pour utilisation et/ou observation. (0055) Faisant suite aux opérations d'analyses et de corrélations, une fonction opératoire peut permettre l'affichage et l'utilisation des données en un tableur orienté individu ou orienté patient. Les résultats sont présentés sous divers caractères graphiques (id est différents caractères, italiques, soulignés, etc.). De plus, les unités ou résultats peuvent apparaître comme des métadonnées quand on sélectionne un paramètre et seront aussi disponibles sur les graphiques. De façon générale, les résultats sont exprimés de façon structurée sous forme de colonnes adjacentes dans la fonction opératoire. (0056) Par exemple, en référence aux figures 5A, 5B, 6A et 6B, un spécimen de l'ensemble de données tel que produit par la fonction opératoire est présenté. Les figures 5A et 5B montrent les données des tables 500 et 501, respectivement, avec des données en provenance de deux laboratoires ou plus. Les deux figures 5A et 5B présentent les mêmes entrées de données dans les tables 500 et 501, mais en comportant l'indication que plus d'un laboratoire a fourni les données, l'ensemble des données issues d'un laboratoire étant soulignées, l'autre ne l'étant pas. Comme cela est montré dans les tables, les colonnes avec les entrées de données soulignées sont produites par le laboratoire HCC de Colmar (Figure 5A montrant la surimpression 504 de ce laboratoire sur la table 500) et les entrées qui ne sont pas soulignées sont fournies par le laboratoire HUS de Strasbourg (Figure 5B montrant la surimpression 505 de ce laboratoire sur la table 501). Quand on revoit une information, un professionnel de santé peut voir de quel laboratoire le résultat a été reçu et aussi observer les entrées de données (ou les valeurs) sur une période de temps. (0057) De plus, comme présenté sur les figures 5A et 5B, la première colonne 510 peut fournir le test de laboratoire spécifique correspondant à la rubrique d'entrée tels que cholestérol, triglycérides, glucose, numération globules rouges, plaquettes, etc. L'entrée suivante 512 dans la table peut être présentée entre parenthèses "[ ]", et peut représenter les valeurs les plus récentes disponibles pour un patient donné. Egalement, sont représentées une série de colonnes 514 affichant les résultats du patient sur une période de temps, à partir de chacun des laboratoires. (0058) En se référant maintenant aux figures 6A et 6B, une représentation graphique des données est présentée. A nouveau, les figures 6A et 6B montrent la même image graphique dans les tables 601 et 602, respectivement, mais les indicateurs en surimpressions 604 et 605, respectivement, indiquent quels points de données ont été reçus, en provenance de quel laboratoire. Les graphiques 600 et 601 peuvent présenter le résultat d'un test particulier au cours du temps, fournissant ainsi une visualisation de la tendance. De plus, la représentation graphique peut montrer facilement ce que les laboratoires considèrent comme valeurs normales et/ou anormales pour un test donné. Le rectangle 610 représente les valeurs normales pour les triglycérides reçus de HCC Colmar et la boite 612 représente les valeurs normales pour les triglycérides reçus des HUS. En conséquence, un professionnel de santé peut constater qu'un test de laboratoire particulier sera « en dehors de la norme » pour un laboratoire et dans la norme pour un autre. Ceci permet au professionnel de santé de voir les tendances et d'éliminer les disparités entre laboratoires, aboutissant à un diagnostic et/ou à un traitement plus efficace et plus précis, pour un patient donné. (UUrn) Les caractéristiques de l'invention peuvent être implantées sur virtuellement tout type d'ordinateur, indépendamment de la plateforme utilisée. Par exemple, comme illustré dans la figure 7, un ordinateur 700 comprend un ou plusieurs processeur(s) 702 (tel qu'une unité centrale (UC), des circuits intégrés, etc.), de la mémoire associée 704 (p.e., mémoires RAM, cache, flash, etc.,), un disque de stockage 706 (p.e., disque dur, disque optique tel qu'un compact disque ou un disque video digital, DVD, une mémoire flash, etc.), et de nombreux autres éléments et fonctionnalités, (non mentionnés), faisant partie d'un ordinateur actuel typiques. Le système d'ordinateur 700 peut aussi comporter des périphériques d'entrée tels qu'un clavier 708, une souris 710, ou un microphone (non représenté). De plus, le système d'ordinateur 700 peut comprendre des périphériques de sortie, tels qu'un moniteur 712 (p.e., de type affichage à cristaux liquides (LCD), affichage plasma ou un tube à rayons cathodiques, (CRT). Le système d'ordinateur 400 peut être connecté à un réseau 714 (par exemple, un réseau local (LAN), un réseau large (WAN), à l'Internet ou à tout autre type de réseau à travers une interface de connexion réseau (non représentée). Les experts du domaine apprécieront que d'autres types d'ordinateurs existent et que les moyens d'entrée et de sortie présentés ci-avant puissent prendre d'autres formes. D'une façon générale, le système d'ordinateur 700 comporte au moins la configuration minimale, processeur, entrées, sorties, nécessaire à la mise en oeuvre de l'invention. (0060) De plus, pour une ou plusieurs des caractéristiques de l'invention, un ou plusieurs éléments du système d'ordinateur 700 décrit ci-avant peut (peuvent) être localisés à distance et connectés aux autres éléments à travers le réseau. Plus encore, des caractéristiques de l'invention peuvent être installées sur un système distribué comportant une pluralité de noeuds, où chaque composante de l'invention (par exemple., vérificateur 102, analyseurs110, traducteur 108, enregistreur 104, unité de stockage 106, etc.) peut être localisée sur un noeud différent à l'intérieur du système distribué. Dans une caractéristique de l'invention, le noeud correspond à un système d'ordinateur. De façon alternative, le noeud peut correspondre à un processeur associé à une mémoire physique. Le noeud peut également correspondre à un processeur ou à un microcomposant de processeur avec une mémoire et/ou des ressources partagées. De même, des instructions logicielles sous forme d'un programme code informatique en lecture permettant de réaliser les caractéristiques de l'invention peuvent être stockées, de façon temporaire ou permanente, sur un moyen de stockage informatique tangible en lecture, tel qu'un disque compact (CD) une disquette, une bande magnétique, des cartes perforées, de la mémoire ou toute autre forme de dispositif de mémoire informatique tangible. (0061) De façon avantageuse, les caractéristiques de la présente invention fournissent un service, un procédé ou une méthode permettant l'interopérabilité entre données de tests de différents laboratoires, sans nécessiter aucun changement à effectuer au niveau des laboratoires. Les laboratoires peuvent soumettre les données des tests de laboratoire au serveur central sous n'importe quel format et par tout moyen de transmission et un professionnel de santé sera capable de réconcilier les résultats en provenance d'une multitude de laboratoires. (0062) De plus les caractéristiques présentées ici peuvent permettre pour un patient en général d'attribuer une identité afin de connecter et de référencer les résultats de laboratoire dans le temps. De plus, l'identification du patient est gage de confidentialité et de protection du DSE du patient. (0063) Qui plus est, les caractéristiques de l'invention permettent une intervention humaine pour corriger les erreurs dans les données envoyées par le laboratoire. Par exemple, les laboratoires peuvent présenter et/ou envoyer des données qui ne soient pas en phase avec les règles des formats standard, ou avec le code approprié, ou encore les données pourraient être erronées, etc. Les exemples qui suivent peuvent être identifiées et enregistrées par le système, autorisant une analyse cohérente un dossier santé fiable. -Non. respect de la norme Ex I PRIM médecin : le texte formaté contient un a TILT u avec rur résultat à l'intérieur mais pas de segment « RES » qui pourrait être analy sé De façon avantageuse, les caractéristiques de l'invention permettent une interopérabilité entre des données de tests de laboratoires issues de laboratoires différents et génère des données unifiées et corrélées. Qui plus est, les erreurs dans les données fournies par les laboratoires différents peuvent être réconciliées, même si des erreurs sont présentes dans les données. (0065) En conséquence, les caractéristiques de l'invention fournissent une interopérabilité utilitariste sélectivement orientée vers les besoins de l'utilisateur final, en l'occurrence le patient, sous la forme du serveur central. Une telle approche est totalement en accord avec le concept de construction d'un dossier santé individuel longitudinal, un dossier personnel ( type DMP, dossier médical personnel) ou un dossier professionnel (DCC, dossier de suivi de soins) qui peuvent être utilisés avec efficience par les professionnels de santé. (0066) Les caractéristiques de l'invention permettent la réconciliation de données pour un patient précis, envoyés par le laboratoire "X" (tout laboratoire ou toute combinaison de laboratoires) au serveur central, il4y-R, en attribuant et en utilisant les dictionnaires pour créer un ensemble unique de données unifiées et corrélées qui pourraient permettre au dossier santé individuel longitudinal électronique de se constituer. En tant que tel, laboratoire "X" peut être lié à laboratoire "Y" à travers l'entrepôt il4y-R qui inesjUP[C1410101g/11O.O10.1INIFIlII clt=O.1Olg/110-OI0.11NIFIIII