ARCHIMED - Une base de données historicisée au quotidien

 

In : « Mémoire électronique, Archivage et travail des historiens du futur », Bulletin de l’association Histoire et Informatique (vol. 13/14, 2002/2003, pp. 89-102)

[http://www.ahc-ch.ch/index.php?id=40&L=1]

 

Jean-Daniel Zeller

Archiviste principal

Hôpitaux universitaires de Genève

 

Résumé

 

Les Hôpitaux universitaires de Genève, forment depuis 1995 un réseau d’établissements hospitaliers, comptant près de 7'900 collaborateurs travaillant sur 5 sites géographiques, comptant 2187 lits, et offrant annuellement 45'000 hospitalisations et 730'000 consultations ambulatoires (chiffres 2001). L’hôpital cantonal de Genève a été un des pionnier de l’informatique médicale en Suisse, voire en Europe. Dès 1976, le centre d’informatique hospitalière concevait le système DIOGENE, qui allait connaître de nombreux développements. Actuellement, la base de données patients rassemble les données d’environs un million de patients, avec un accroissement annuel de l’ordre de 40'000 patients.

 

Dès le départ, le système DIOGENE a été conçu comme un système orienté patient et non pas comme un système de gestion administratif. Cependant, une telle base de données ne pouvait pas ne pas être exploitée du point de vue statistiques, tant pour des interrogations de type médical qu’administratif. Durant les premières années d’utilisation, ce type d’interrogation s’effectuait en mode batch, durant les heures creuses de l’exploitation. Cependant, ce type d’exploitation s’est progressivement heurté à plusieurs obstacles, et l’on envisagea la possibilité de créer une base « d’archivage » qui permettrait le lancement de requêtes statistiques sophistiquées, paramétrables, et sur une base anonyme sans mobiliser les ressources de la base de données opérationnelle.

 

Ce projet vit le jour en 1993 par la réalisation de la base de données intégrée ARCHIMED,. Le concept clé de cette application réside dans la transcription des données liées aux patients en une série de « faits élémentaires », qui peuvent être manipulés ultérieurement de manière extrêmement performante. Pratiquement, les données préalablement sélectionnées des différents systèmes informatiques opérationnels, sont déversées quotidiennement dans une application qui les transforme en faits élémentaires puis les déversent dans la base de données ARCHIMED sur une base annualisée.

 

Après dix ans d’activité (1993-2003) les chiffres sont les suivants :

70 millions d’enregistrements (faits élémentaires)

Accroissement d’environs 1,5 Gigabytes par an (5MB * 365 j. = 1,8 GB)

(soit 200 tables annuelles)

 

Le concept qui a présidé à la naissance d’ARCHIMED a été d’ordre médical et opérationnel. Cependant, la nécessité d’harmoniser les données provenant de plusieurs systèmes initiaux, a forcé ses concepteurs à une réflexion ontologique qui a amené à une structuration qui rencontre les préoccupations d’une conservation des données à long terme. ARCHIMED représente donc un prototype de ce que pourrait être une base de donnée « historique », conçue dès le départ pour maîtriser un grand nombre de données à long terme.

 

Summary

 

The university Hospitals of Geneva, formed since 1995 with a network of hospitable establishments, with 7'900 collaborators working on 5 geographic sites, with 2185 beds, and offering annually 175'000 hospitalizations (HC: 52'000) and 620'000 ambulatory consultations (2001).

 

The cantonal hospital of Geneva was one of the pioneers of medical data processing in Switzerland, even in Europe. From 1976, a team of  IT specialists-doctors, designed the DIOGENE system, which went through numerous developments.

 

At present, the data base of patients DIOGENE gathers data for a little more than a million of patients, with an annual increase of the order of 45'000 new patients.

From the beginning, the DIOGENE system was designed as a patient oriented system and not as an administrative system of management.

 

Such a data base could be exploited from the statistical point of view, for example for queries of a medical type or administrative data. During the first years of use, this type of query was made in batch mode, during the ‘slack’ periods.

 

However, this type of exploitation gradually met with several obstacles and we envisaged the possibility of creating an “archival” data base with the possibility of directly interrogating an anonymised data base, by using browsers, without using the operational data bases resources.

This project lives by the implementation of the data base integrated ARCHIMED system in 1993. The key concept of this application lies in the transcription of the data linked to the patients in a series of "elementary facts", which can later be manipulated in an extremely powerful way.

 

Practically, the pre-selected data from the various operational computer systems, are filtered daily by a series of interfaces, which transforms them into elementary facts then places them in the ARCHIMED data base on an annualised base.

After ten years of activity (1993-2003) the annual evolutions are the following :

Increase in the neighborhood of 1,5 Gigabytes a year (5MB / j * 365 j. = 1,8 GB)

70 million entries (elementary facts)

(i.c. the addition of 200 tables annually)

The concept which presided over the birth of ARCHIMED was of a medical and operational order. However, the necessity of harmonizing the data resulting from several different operational systems, forced its designers to an ontological reflection leading to a structuralization meeting the concerns of a conservation of the long-term data.

 

ARCHIMED represent therefore a prototype “historical” data base, designed at the beginning for the management of large amounts of data for long term preservation.

 

 


 

1.     Contexte institutionnel

 

Les Hôpitaux universitaires de Genève, forment depuis 1995 un réseau d’établissements hospitaliers, comptant près de 7'900 collaborateurs travaillant sur 5 sites géographiques, comptant 2185 lits, et offrant annuellement environs 175'000 hospitalisations (HC : 52'000) et 620'000 consultations ambulatoires (chiffres 2001). Il est issu du regroupement des établissements suivants :

 

Etablissement

Créé en*

Type de soins

Lits

Hôpital cantonal (HC)

1856

Soins aigus (i.c. pédiatrie et maternité)

1176

Hôpital psychiatrique

1900

Psychiatrie

343

Hôpital de Loëx

1900

Soins de longue durée

268

Hôpital gériatrique

1970

Gériatrie

293

Centre de soins continus

1980

Soins palliatifs

105

* sur leur site actuel

2185

 

Cette répartition, issue de l’héritage historique, tend à être remplacée par une organisation plus répartie, en fonction des spécialités médicales, regroupées actuellement en 11 départements médicaux, correspondants également aux activités académiques que se doit d’assumer un hôpital universitaire.

 

 

2.     Contexte informatique

 

L’hôpital cantonal de Genève a été un des pionnier de l’informatique médicale en Suisse, voire en Europe. Dès 1976, l’équipe d’informaticiens-médecins emmenée par le professeur Jean-Raoul Scherrer, concevait le système DIOGENE, qui allait connaître de nombreux développements, dont les principales étapes (applications patients uniquement) sont résumées ci-dessous :

 

Année

Application

Remarques

1978

Démarrage de l’application hospitalière DIOGENE.

Au départ, uniquement pour les patients hospitaliers

1982

Intégration des policliniques dans le système DIOGENE.

Bases de données en parallèle. L’intégration sera achevée seulement en 1993.

1988-1998

Déploiement progressif des applications UNI-LAB.

Gestion des examens de laboratoire

1994

Mise en application d’UNI-IMAGE.

Gestion des examens d’imagerie médicale

1993-1996

Mise en application d’UNI-DOC.

Production de documents à partir des données DIOGENE

1995

Migration de DIOGENE sur des machines et applications standards. Les stations de travail sont remplacé par des PC.

Restructuration des bases de données. Changement d’OS et de DBMS.

1998

Création du concept DOMED (médical), DOSSI (soins infirmier) puis DPI (Dossier du Patient Intégré).

Navigateur médical permettant l’accès aux données/documents des patients issus de diverses applications

2003

Début de l’analyse de la fusion des applications de gestion administratives des patients (DIOGENE+PHILOS)

Intégration des systèmes de l’hôpital cantonal avec ceux des autres sites hospitaliers

2005

Fusion des bases de donnd IMPACT (site HC) et PHILOS (autres sites)

Dans une nouvelle application nommée DPA (Dossier Patient Administratif)

 

Actuellement, la base de données patients de DIOGENE rassemble des données pour un peu plus d’un million de patients, avec un accroissement annuel de l’ordre de 45'000 nouveaux patients.

 

 

3                   Problématique …

 

Dès le départ, le système DIOGENE a été conçu comme un système orienté patient et non pas comme un système de gestion administratif. Cela est particulièrement bien illustré par la représentation constamment affirmée de la « roue » DIOGENE (voir figure 1). Cela apparaît également dans la structure fonctionnelle des application dont le point d’entrée est également le patient (voir schéma des tables de données de DIOGENE, figure 2).

 

 

Figure 1 : Structure globale des applications informatiques des HUG

 

 

 

 

Figure 2 : Schéma des relations des données dans le système DIOGENE

Les flèches simples indiquent une relation fonctionnelle, les flèche barrées indiquent une application.

 

 

Cependant, une telle base de données ne pouvait pas ne pas être exploitée du point de vue statistique, tant pour des interrogations de type médical (charge des services, épidémiologie) qu’administratif (statistiques annuelles, coût par patient, etc.).

 

Durant les premières années d’utilisation de DIOGENE, ce type d’interrogation s’effectuait en mode batch, durant les heures creuses de l’exploitation, entre 22 heures et 4 heures du matin. Cependant, ce type d’exploitation s’est progressivement heurté à plusieurs obstacles :

 

a)      L’accroissement continuel de la base et les besoins de sécurité élevés nécessitaient de plus en plus d’opérations de maintenance devant s’effectuer pendant ces mêmes heures creuses.

b)      L’accroissement de la base rendait également les analyses statistiques de plus en plus intéressantes pour les gestionnaires, qui prirent l’habitude d’en solliciter de plus en plus.

c)      L’organisation hiérarchique de la base ne facilitait pas le lancement de requêtes statistiques, dont les critères n’étaient pas directement liés au patients mais plutôt à des groupes d’événements, qui pouvaient se situer à des niveaux hiérarchiques très divers dans la base, et nécessiter la constitution de fichiers temporaires très volumineux, perturbant d’autant le fonctionnement opérationnel courant de la base de données.

 

Pour toutes ces raisons, le responsable de ces éditions statistiques, envisagea dès les années 90, la possibilité de créer une base normalisée unique, qui permettrait :

 

d)      Le lancement de requêtes statistiques sophistiquées et paramétrables sans mobiliser les ressources de la base de données opérationnelle.

e)      La possibilité d’interroger une base de données anonymisée, directement par les utilisateurs finaux au moyen de navigateurs (en limitant la réalisation à la demande de requêtes SQL par les informaticiens).

f)        La possibilité d’intégrer des données relatives aux patients issues de systèmes d’information divers. Cette option allait s’avérer cruciale quelques années plus tard lorsqu’il s’agira de préparer la fusion des HUG, dont les établissements possédaient des systèmes informatiques divers et non intégrés.

 

Ce projet vit le jour par la réalisation de la base de données intégrée ARCHIMED, en 1993. Le concept clé de cette application réside dans la transcription des données liées aux patients en une série de « faits élémentaires », qui peuvent être manipulés ultérieurement de manière extrêmement performante. Avec l’ouverture du service intranet à l’Hôpital cantonal, cette version « dynamique » des atlas statistiques remplacera définitivement en 1995 la version papier produite entre 1983 et 1993.

 

 

4                   Le concept d’ARCHIMED[1]

 

Si le concept se rapproche des notions actuellement bien connues des « entrepôts de données » (Data Warehouses) il s’en distingue dans la mesure ou les systèmes de data warehousing s’occupent plus d’offrir une présentation comparable des données sélectionnées issues de différents système opérationnels, en vue de leur consultation par les gestionnaires, tandis qu’ARCHIMED effectue de surcroît un travail d’harmonisation et d’homogénéisation des données au niveau syntaxique, sémantique et ontologique (voir plus bas chap. 4.1) pour constituer une base de données intégrée. Cette base de données constitue le noyau d’un système complété par une série d’outils d’aide à la décision.

 

Pratiquement, les données préalablement sélectionnées des différents systèmes informatiques opérationnels, sont filtrées quotidiennement par une série d’interfaces (8 à ce jour), qui les transforment en faits élémentaires puis les déversent dans la base de données ARCHIMED sur une base annuellisée (voir schéma en annexe). L’annuellisation a été imposée au départ par des contraintes techniques de place mémoire et de gestion des applications. Avec les moyens actuels elle ne serait plus nécessaire, et les tables annuelles pourraient être regroupées en une seule grande table. (note de l’archiviste : cependant cette organisation, si elle implique certaines contraintes lorsque l’on effectue des requêtes sur des données pluri-annuelles, représente un mode de stockage intéressant sur le long terme car il permet une maîtrise prévisible des volumes de données et une rupture temporelle claire et explicite si l’on devait mettre certaines données off-line. Voir plus loin Chap 6).


 

4.1.           Le modèle ontologique d’ARCHIMED

 

Le modèle ontologique conçu pour construire l’application repose sur structure de domaines se superposant en couche d’abstraction successive, tel qu’illustré sur le schéma ci-dessous 

 

DOMAINES

 

Soit :

Faits considérés

 

 

 

 

Domaine de Réalité

 

Toutes les activités

de l’Hôpital cantonal

 

 

 

 

…structurées par

les découpages opérationnels

(services, processus, etc.)

 

Tous les faits dans

le champs d’activités

 

 

 

 

Domaine Particulier

 

Activités hospitalières spécifiques (mouvements patients, laboratoires, etc.)

 

 

 

 

…décrites dans les analyses des

applications informatiques

spécifiques

 

Les faits correspondant

à un champs d’activité spécifique

 

 

 

 

Domaine de Base

 

Activités enregistrées dans les bases de données opérationnelles hétérogènes

 

N

interfaces

 

 

…sélectionnées, extraites

et normalisées

 

Les faits considérés

comme relevants

 

 

 

 

Domaine Normalisé

 

Activités enregistrées dans la base de donnés ARCHIMED

structurées en faits élémentaires

Les faits non-modifiables

->« bons à archiver »…

 

 

Ce schéma montre que s’il s’agit bien, sur le plan technique, d’extraire des données des bases de données opérationnelles, la cohérence de ces données doit être assurée en amont. D’une part en fonction des définitions adoptées lors de la constitution des applications opérationnelles et d’autre part en fonction des « découpages » des unités opérationnelles définies indépendamment des applications informatiques mais dont celles-ci doivent tenir compte. Il existe par ailleurs d’autres découpages, liés à la gestion budgétaire ou à la localisation physique par exemple.

 

A partir de ce modèle, on a défini des liens de base qui ont été déduits en examinant les relations ou les similarités entre les faits contenus dans les différents domaines de base (par ex : patient, service médical, centre budgétaire, etc.)

 


A ces liens de base sont attachés des propriétés, caractérisées par un type, une valeur, un temps. La connexion entre un lien de base et une propriétés forme un fait élémentaire. On a alors l’équation suivante :

Lien de base + propriété = fait élémentaire

 

A ce niveau, il faut noter que chaque faits élémentaire est estampillé d’un temps. Celui-ci peut être un temps ponctuel, quand le fait n’a lieu qu’un fois (date d’examen par ex.), ou une durée avec ses deux limites de début et de fin (durée de séjour par ex.), celle-ci est alors représentée par un processus avec un fait de début et un fait de fin (ce qui formalise la notion de trajectoire hospitalière, mais permet, plus génériquement, de définir n’importe quelle chronologie de manière stricte).

 

Il faut également remarquer que les faits ne sont sélectionnés que lorsqu’ils ne sont plus modifiables. Cela correspond partiellement à la notion de clôture de dossier en archivistique classique, avec un nuance de taille : c’est le « fait » qui est clos et cette clôture s’effectue indépendamment d’une notion de dossier, bien que celle-ci existe par ailleurs dans certains domaines de base. Ceci est rendu possible sans perte d’information et de contexte parce que chacun des faits élémentaires est d’une part daté pour lui-même et d’autre part « liés » à un domaine de base.

 

 

4.2.           Pratique quotidienne

 

Dans la pratique, une fois les domaines de base définis, des routines d’extraction sont appliquées aux différentes bases opérationnelles hétérogènes, en général sur un rythme quotidien pendant les heures creuses nocturnes. Ces tables, issues pour la plupart de base INGRESS sont extraites en fichiers ASCII et envoyées par protocole FTP vers l’application ARCHIMED. Elles sont alors distribuées dans des « paniers », en fonction de leur domaine de provenance. Ces paniers sont traités pour transformer les données en faits élémentaires normalisés, qui sont déversés dans les tables de la base de données ARCHIMED. Par ailleurs, un traitement parallèle sur les faits élémentaires permet de produire des « données réduites » qui sont en fait des indicateurs dérivés. (voir schéma de la constitution de la base de données ARCHIMED en annexe).

 

 

4.3.           L’accès aux données ARCHIMED

 

Dans un premier temps, les gestionnaires d’ARCHIMED ont développé des requêtes d’interrogation similaires à celles préalablement utilisées pour produire les statistiques à partir des applications opérationnelles. Celles-ci étaient éditées sous la forme d’atlas statistiques annuels en mensuels, ainsi que d’autres atlas particuliers, en fonction des demandes. Ces éditions ont été remplacées par un navigateur, disponible sur l’Intranet des HUG, qui permet aux collaborateurs de consulter ces données communes de manière rétrospective (ce qui était difficile avec les atlas publiés sur papier) et avec une actualisation quotidienne (ce qui était impossible avec des éditions annuelles et mensuelles). Ces statistiques d’activités sont affichables à différentes échelles temporelles (années, mois, jour en général) et à différents niveaux d’agrégation (des HUG en entier jusqu’à l’unité de soins). Les tableaux sont exportables vers un tableur excel pour un traitement localisé.

 

La véritable valeur de la base de données intégrée d’ARCHIMED n’apparaît cependant qu’avec les différents outils d’aide à la décision développés ultérieurement par l’Unité d’information médico-économique (UIME) qui permettent diverses interrogations sophistiquées. La plupart se présentent sous forme de navigateur, nécessitant un droit d’accès.

 


Les outils disponibles sont, par exemple :

-                le calcul d’indicateurs (DRG :diagnosis related groups, ré-admissions)

-                les archives des faits des patients (recherche de cas similaires, recherche des faits d’un patients, données de laboratoires)

-                les statistiques médicales (code diagnostic, interventions, statistique selon normes OFS, etc.)

-                les services Archimed (analyse des mouvements d’urgence, calcul des scores de gravité, suivi des patients sur plusieurs années, etc.)[2]

 

 

5                   Etat actuel de la base ARCHIMED

 

A fin 1998 la base de données ARCHIMED était constitué de:

 

-   5 MB de données (faits) incorporés quotidiennement dans la Base de Données Intégrée (BDI).

-   Distribuées dans 750 tables, incluant 50 millions d’enregistrement, pour un total de 8 GB.

          Ces données couvrent les activités hospitalières depuis 1990, la plupart des activités de laboratoire depuis 1993 et les activités ambulatoires depuis 1996.

 

Après dix ans d’activité (1993-2003) les évolutions annuelles sont les suivantes :

 

     -   Accroissement d’environs 1,5 Gigabytes par an (5MB/j * 365 j. = 1,8 GB)

     -   70 million d’enregistrements (faits élémentaires)

          (soit l’ajout de 200 tables annuelles)

 

 

6.     Une base de données historique(s) ?

 

Comme expliqué plus haut, le concept qui a présidé à la naissance d’ARCHIMED a été d’ordre médical et opérationnel. Cependant, la nécessité d’harmoniser les données provenant de plusieurs systèmes opérationnels différents, a forcé ses concepteurs à une réflexion ontologique qui a mené à une structuration qui rencontre les préoccupations d’une conservation des données à long terme.

 

Actuellement, ARCHIMED représente non seulement un outils d’aide à la décision, raison par laquelle il a été conçu, mais également une source de données historique sans égale, car les données consolidées dans cette base unique ne pourraient être rassemblées autrement, chaque système opérationnel (et il y en a environs une centaine au sein des HUG) ayant sa propre structure et ses propres dictionnaires.

 

Cependant, ARCHIMED n’est pas une base de données historique « idéale » pour les raisons suivantes :

 

a)    Un outil avant d’être un système

ARCHIMED a été initialement conçu comme un outil technique, dont l’objectif était de simplifier l’accès à des données provenant de bases de données hétérogènes. Bien que très vite ses concepteurs aient appréhendés ses possibilités d’outil d’aide à la décision, ce n’est qu’après la migration des systèmes informatiques en 1995 et la mise en place d’un plan d’investissement de grande envergure en 1998 qu’ARCHIMED apparaît pour la première fois comme une application identifiée au sein de la division informatique et de l’institution.

 

b)    Un manque de vision institutionnelle

Conséquence du point précédent, la hiérarchie, tant informatique qu’administrative, n’a réalisé l’intérêt de ce système d’information que lorsqu’il a été rendu visible sur l’intranet institutionnel. N’ayant pas participé directement à sa conception, les décideurs ont mis longtemps à reconnaître sa valeur.

 

c)    Une normalisation à posteriori

Bien que certains dictionnaires de données soient communs à toutes les applications opérationnelles, comme les découpages, certaines harmonisations ne sont effectuées que lors du transfert des données dans ARCHIMED. Il manque à l’institution une instance qui définirait certains référentiels communs de manière univoque et uniforme, permettant une normalisation en amont.

 

d)    Une absence de politique de conservation à long terme

Le système ARCHIMED représente surtout aux yeux de ses concepteurs et de ses utilisateurs un outil d’aide à la décision basé sur des périodes longues (10 ans) mais qui sont relativement courtes en terme d’archivistique. Jusqu’à présent, la place mémoire n’ayant pas fait défaut, la question de la conservation ne s’est pas posée, l’intérêt étant d’offrir en ligne le plus de données possible. Ce contexte est également valable pour les données des bases opérationnelles. La nature même de l’activité hospitalière portant sur la totalité de la vie des patients, cette tendance restera une constante. De plus en plus de données se trouvant nativement dans les systèmes informatiques des HUG, nous entamons seulement maintenant, secteur par secteur, des discussions sur la conservation (ou la non-conservation) à long terme de ces données.

 

Nonobstant ces réserves, ARCHIMED représente un intérêt historique considérable, pour les raisons suivantes :

 

a)        Une validation préalable des données

L’analyse ontologique et sémantique des données déversées dans ARCHIMED implique que les données ainsi conservées ont été considérées comme pertinente à la base. Ceci évitera un travail d’évaluation supplémentaire lors d’un futur archivage historique. On devra cependant veiller à ce que ces critères de validation soient explicitement documentés.

 

b)        Une structure simple et documentée

La gestion des données en faits élémentaires et en tables annuelles rendent leur manipulation très indépendante des logiciels de gestion de base de données. Chaque type de relation étant documenté dans des dictionnaires il ne serait par exemple pas difficile de conserver ces tables sous forme XML. Dans la perspective d’une conservation à très long terme, on doit cependant se poser la question de la conservation des navigateurs (qui donnent une image de l’usage actuel de ces données) et la possibilité de construire à long terme d’autres navigateurs, répondant à des questions d’ordre historique plutôt que médico-économique. Les HUG ne se sont pas encore prononcés à cet égard.

 

c)        Une structure indépendante du temps

Comme chaque fait élémentaire est daté et qu’il n’est transféré dans la base de donnée intégrée qu’une fois qu’il n’est plus susceptible de changement, on évite un problème récurent dans les entrepôts de données courants, qui est celui de la mise à jour de données. De ce fait, la base est parfaitement cohérente dans le temps. La structuration en tables annuelles permet potentiellement une mise off-line par tranche chronologique sans aucune manipulation supplémentaire (les trajectoires de soins qui « passent » d’une année sur l’autre sont signalées dans les tables par un drapeau, ce qui permet leur identification et la concaténation des données entre les tables annuelles).

 

 

Conclusion

 

Dans un article de 2001, Edward Atkinson défend la proposition selon laquelle les Data Warehouses (et ARCHIMED peut y être assimilé) sont des records, et sont à ce titre digne d’être conservés[3]. Dans son article la justification de sa position n’est pas très étayée. L’exemple de la base de données ARCHIMED peut fournir au moins un argument de taille. Si les entrepôts de données sont strictement documentés chronologiquement au niveau du fait élémentaire, ils représentent une source historique de première qualité.

 

En conclusion on peut affirmer que les entrepôts de données sont des records (historiques) si :

 

Ø      ils sont strictement documentés (ontologies)

Ø      ils sont strictement délimités (faits élémentaires)

Ø      ils sont strictement datés (attributs temporels)

Ø      ils permettent la construction de nouveaux critères de navigation

 

 

 

 

 

 

 

 

 

Auteur:

Jean-Daniel Zeller

Archiviste principal

Hôpitaux universitaires de Genève

Rue Micheli-du-Crest 24

CH-1211 Genève 14

 

Tel: +41 (0)22 372.60.31

Fax: +41 (0)22 372.60.30

Mail: jean-daniel.zeller(at)hcuge.ch

 


 



[1] On trouvera une description historique de ces travaux dans : ARCHIMED : A Network of Intergrated Information systems, G. Thurler, F. Borst, C. Bréant, D. Campi, J. Jenc, B. Lehner-Godinho, P. Maricot, J.R. Scherrer, in : Methods on Information in Medecine, Schattauer Verlag, 2000, vol. 39, no 1, pp. 36-43.

[2] On trouvera des descriptions plus détaillées de ces outils dans les articles suivants: Retrieval of Similar Cases using the ARCHIMED Navigator; Lehner B, Thurler G., Bréant C :, Tahintzi P. Borst F. ; MIE, 2003, et Toward a Systemic Approch to Disease ; Thurler G. , Bréant C., Lehner B., Bunge M., Samii K., Hochstrasser D., Nendaz M., Gaspoz J.M., Tahintzi P., Borst F. ; ComPlexUs, Karger 2003.

[3] Dans: Data warehousing-a boat records managers should not miss, Records Management Journal, vol. 11, no. 1, avril 2001, pp 35-43.