A. Simonet Ana SIMONET 22 décembre 2004 6 ème Workshop SYNTHESE TECHNOLOGIQUE SIMS@REINSIMS@REIN & GENNERE Les Avancées en GENNERE Vers des Systèmes dInformation

A. Simonet

Ana SIMONET

22 décembre 2004

6ème Workshop

SYNTHESE TECHNOLOGIQUE

SIMS@REIN & GENNERE

Les Avancées en GENNEREVers des Systèmes d’Information Intelligents

A. Simonet2

PLAN

1. GENNERE1. Le présent2. Le futur

2. Bases de production Vs entrepôts3. Conclusion

A. Simonet3

Synthèse Technologique

GENNERE

GENNERE

A. Simonet4


• GENNERE

• Équipe :

• pluridisciplinaire

• localisations géographiques diverses

• cultures différentes

• langues différentes

• Peut-on aller vers des systèmes génériques ?

• Deux domaines distincts : la Néphrologie et la Rhumatologie

GENNERE

A. Simonet5


• Conception par ontologie du noyau

PATIENT SUIVI TRAITEMENT

CENTRE MEDECIN

1,1

1,*

0,*

1,1

1,*

0,*

1,*

1,1

NEPHRO RHUMATO

GENNERE

A. Simonet6


• SUIVI en RHUMATO

COMMORBIDI SUIVI

GESTES-CHIRUR

0,*

0,*

0,*

0, *

GROSSESSE

INFECTIONS

GENNERE

A. Simonet7


• PATIENT

PATIENT_COMM

PATIENT

PATIENT_SPEC

identité

comorbidités

PAT_SPEC_PATH PAT_SPEC-PAYS

PAT_NEPHRO

PAT_RHUMATO

GENNERE

A. Simonet8


Données communes

Données spécifiques

1. Dépendant de la pathologie

2. Dépendant du pays

GENNERE

A. Simonet9


• Ontologie pour les meta-données

• Quelles tables

• Quels attributs

• Quels types et quels domaines de valeurs (multi-langue)

partage des connaissances pour une base

inter-base

• Les libellés et leurs codages dans plusieurs langues

Gérés comme des objets

Travail lourd pour garantir la cohérence des informations

Automatisation totale ou partielle de cette tâche

GENNERE

A. Simonet10


• Usage de l’ontologie des meta-données

• en phase d’utilisation - interface multilingue :

chinois, anglais et français

• en phase de conception d’interface :

« reprogrammation de l’interface »

• en phase de raffinement des tables, des noms d’attributs, ….

• du codage : norme UTF8

• Usage des ontologies/thésaurus spécifiques

GENNERE

A. Simonet11


• Schéma logique : normalisé (de manière générique) ajout / supp de valeurs tâche simple

•VUES• Indépendance logique de données• Garant de la sécurité de l’accès la vue délimite les droits d’accès

et de mise à jour des utilisateurs

• IHM• Blocs réutilisables sur plusieurs fonctionnalités• Utilisation des Templates• Séparation maximale entre code php et HTML• Dissociation de la présentation et du contenu

Autres aspects génériques

GENNERE

A. Simonet12


• Fonction administration

• Gestion Explicite des événements

• Et encore de la déclarativité

• Génération de la base de connaissances

• Génération de prototypes d’IHM

• Vers une première API

GENNERE

A. Simonet13


DW

GENNERESuivis Cliniques

Base d’Identité

GENNERE

A. Simonet14

Synthèse Technologique Base de production Vs Data Warehouse

Base de production Vs Data Warehouse

A. Simonet15

Synthèse Technologique Base de production Vs Data Warehouse

Schéma de synthèse Schéma de synthèse

A. Simonet16

Synthèse TechnologiqueBase de production Vs Data Warehouse

Principaux objectifs :• éliminer les redondances• garantir la cohérence• favoriser le partage • garantir la sécurité en cas de panne Processus de normalisation :==> éclatement de l’information ==> nécessite la reconstruction de l ’information initiale

Dédiées à la gestion des processus opérationnels de l’entreprise OLTP

OLTP == On Line Transactional Processing

Bases de Données Classiques

Bases de Production : inadaptées à l’aide à la décision

A. Simonet17


Un Entrepôt de Données est une collection de données :

• orientées sujet : données structurées par thèmes ou sujets

• intégrées : données répliquées et intégrées à l’ED

• historisées : enregistrement périodique des données

• non volatiles : donnée à t = donnée à t+1

Données dédiées aux décideurs

Conséquences :

• besoin de requêtes interactives

• structuration adaptée aux processus d’aide à la décision.

Entrepôt de Données

A. Simonet18


Principales différences :

Base de Données Opérationnelle


Mise à jour quotidienne Intégration périodique

Données modifiables Données non modifiables / accessibles en consultation

Durée de vie moyenne des données environ 60 à 90 jours

Période d’historisation des données en général > 10 ans

Capacité de stockage de l’ordre du Mo ou Go

Capacité de stockage de l’ordre du To

Traitement des données par systèmes transactionnels (OLTP)

Traitements analytiques en ligne (OLAP)

Données orientées application Données orientées sujet

A. Simonet19


Et encore :

Base de Données Opérationnelle


Fonctionnement : par transactions Fonctionnement : par requêtes

Quelques dizaines de tuples Des millions ( et ++) de tuples

Plusieurs centaines (voire milliers) de transactions par jour

Quelques dizaines de requêtes par semaine

accès concurrents Concurrence : hors sujet

Temps de réponse attendus : très courts

Temps de réponse : quelques heures voire quelques jours

Accès au travers de menus (frontaux )

Accès non programmés a priori

A. Simonet20


• Bases de données en production1) bases pour la gestion de stocks (supermarché, agence de voyages, etc.)

2) bases pour le suivi (suivi de patient, suivi de clients (banque, assurance, etc.)

Gestion des Stocks Gestion des Suivis

Mise à jour quotidienne Mise à jour quotidienne

Données modifiables Données modifiables

Durée de vie moyenne des données : environ 60 à 90 jours

Durée de vie des données : 3 à 4 ans

Traitement des données par systèmes transactionnels OLTP


Données orientées application Données orientées application

Événements non explicites Organisées autour des événements

A. Simonet21


Mes Archives

A. Simonet22

1. Lymphome2 11.1. Résumé 11.2. Étude de l'existant 12. Nouvelle base 12.1. Principaux objectifs 13. Les ensembles 33.1. Le patient 33.2. L'événement 43.3. Données cliniques 63.4. Le traitement 73.5. Données histologiques 83.6. Données cytologiques 93.7. Données immunologiques 103.8. Données cytogénétiques 124. Les transactions 364.1. Le menu principal 365. La mise à jour 375.1. Écran PATIENT 385.2. Écran EVENEMENT 39


Base pour le cancer (mise en place 1994)

A. Simonet23


PATIENT

EVENEMENT

1,* 1,1

TRAITE- MENT

1, 1

CLINIQUE

1,1

0,1

1,1 1,1

0,1

HYST_ CYTO

IMMUNO

1,1

0,1 CARYO

1,1

0,1

ETAT_ SURVIE

1,1

1,1

A. Simonet24


Événement :

1) nouveau patient,

2) visite patient

3) hospitalisation

4) changement de traitement

5) prélèvement

6) décès

7) …

A. Simonet25


ETAT_EVENEMENT

NOM ENSEMBLE NOM ATTRIBUT COMMENTAIRE

CODE_EVENEMENT

SAISIE_CARYO code indiquant la validité des données sur une composante d'un événement par exemple :0 : rien n'est saisi (valeur par défaut);1 : (en caryo) il n'existe pas d'informations ;2 :les informations saisies sont à compléter ;3 : informations complètes et valides ;

SAISIE_CLINIQUE

SAISIE_HYSTO

SAISIE_CYTO

A. Simonet26


• Bases de Données de Suivi Vs Entrepôts de Données:

Entrepôt de Données Gestion des Suivis

Mise à jour périodique Mise à jour quotidienne

Données non modifiables Données modifiables

Durée de vie des données : 2 à 3 ans

Durée de vie des données : quelques années

Traitement des données par systèmes des systèmes OLAP


Données orientées sujet Données orientées application

Structuré autour des axes d’étude privilégiés

Structurées autour des événements

Schéma peu évolutif Schéma évolutif

A. Simonet27


• Bases de Données de Suivi Vs Entrepôts de Données

• Base des Suivis : dossier (patient / client /… ) constitué dynamiquement

Base de Suivis : schéma plus évolutif et données hétérogènes

de préférence normalisé

• Entrepôt de Données : étude des états d’un système

état défini par l’agrégation des

objets des bases sources composants

Entrepôt de Données : optimisation des requêtes pré-définies

indexes et/ou vues

granularité minimale

A. Simonet28


SIMS@REIN

Rappel historique

A. Simonet29


NIVEAUNATIONAL

NIVEAUREGIONAL

NIVEAULOCAL

BL1 BL2 BL3

BR1 BR2

BN

Dialyse Nephro Transplant

Usage ? BD classique Data Warehouse

Bases ? Virtuelles Persistantes?

Alimentation ? Snapshot Périodique Evénementielle

QUESTIONSDécembre 99

A. Simonet30


NIVEAUNATIONAL

NIVEAUREGIONAL

NIVEAULOCAL

BL1 BL2 BL3

BR1 BR2

BN

Dialyse Nephro Transplant

2000

A. Simonet31


XMLEDI

DATAWAREHOUSE NATIONAL

Base de données nationales + vues persistantes

Intégrateur

Intégrateur local moniteur

Client

AUTRES bases de données

Intégrateur local* moniteur

Client

SANS base de données

Client

SUSIEREIN

SERVEUR D'IDENTIFIANT

UNIQUE NATIONAL

CRISTAL EfG

Mai 2000

A. Simonet32


Fin 2000 un MCD est adopté par le groupe SIMS-REIN Base de Production : base tampon destinée à stocker temporairement

les données des centres sans SI propre Données destinées à être intégrées au Data Warehouse Elles passent par divers états : brouillon, validé, bloqué

Mise en place à Necker à partir de 2001 Année 2001 : feed-back intense sur le logiciel réalisé par Mohamed Un entrepôt a été conçu et réalisé (Grenoble) Alimentation en EJB et SQL sur une base de production test (Paris) …

Le système aujourd’hui : base de production ou data warehouse ?

A. Simonet33


A. Simonet34

6ème Workshop : Synthèse Technologique

A. Simonet35


Conception Classique (E-R) :

•Étape 1 : Extraction des connaissances

interviews, documents (supports divers ) à produire, …

point de vue des diverses catégories d’utilisateurs

•Étape 2 : Synthèse des connaissances

résolution des problèmes de homonymes, de synonymes, …

1ères prises de décision : ce qui va être calc / rep

point de vue globale

A. Simonet36


Conception Classique (E-R ou E-A) :•Étape 3 : normalisation du schéma global

éclatement de l’information

1 concept :: plusieurs tables

MCD : Modèle Conceptuel de Données

•Étape 4 : validation du modèle MCD

les utilisateurs valident la proposition des analystes

validation de surface

•Étape 5 : production des points de vue par catégorie

d’utilisateurs

sous-schéma / catégorie d’utilisateurs

mise en place des règles de confidentialité définies

A. Simonet37


Conception Objet Classique (UML) :

• Point 1 : attributs multivalués (« un patient a plusieurs

prénoms »)

• Point 2 : attributs complexes (« un patient est suivi par des

médecins »)

• Point 3 : notion de hiérarchie de concepts :: notion is-a

ENFANT

Is-a

PATIENT

ENFANT hérite des attributs de PATIENTENFANT peut avoir des attributs et / ou méthodes propres

A. Simonet38



Ce qui est moins connu par des amateurs

• point 1 : a un OID

• point 2 : les objets sont définis par :

<état, comportement>

• point 3 : l’état est défini par les valeurs des attributs

• point 4 : comportement est défini par des méthodes (procédures)

les méthodes héritées peuvent être redéfiniesles méthodes héritées peuvent être surchargéesun ENFANT n’est plus un PATIENT

A. Simonet39

PATIENT

ENFANT


PATIENT

ENFANT

surcharge et redéfinition

A. Simonet40



Ce qui est inconnu des amateurs

• point 1 : le MCD mélange des classes de programmation, des

classes d’objets et des classes d’IHM

• point 2 : la traduction vers un modèle relationnel pose

problème

• point 3 : la traduction vers un modèle relationnel-objet introduit

un autre paradigme de programmation

La jointure est « remplacée » par une programmation

navigationelle

• mise à jour du MCD : plus chère que dans le relationnel

A. Simonet41


Bases de production en médecine

A. Simonet42


A. Simonet43


A. Simonet44


A. Simonet45


A. Simonet46


A. Simonet47


A. Simonet48


Documents

A. Simonet Ana SIMONET 22 décembre 2004 6 ème Workshop SYNTHESE TECHNOLOGIQUE SIMS@REINSIMS@REIN & GENNERE Les Avancées en GENNERE Vers des Systèmes dInformation