Vous êtes sur la page 1sur 11

SESSION 2006

UE 205 – INFORMATIQUE
40 rue des Jeûneurs
75002 PARIS

Durée de l’épreuve : 2 heures

Le sujet comporte : 11 pages dont 2 annexes (3 et 4) à rendre avec la copie.

Ó L’usage de la calculatrice est interdit et surtout inutile.

Ó Aucun document n’est autorisé.

Ó Le sujet est composé de quatre dossiers :

Dossier n° 1 : 5 points
Dossier n° 2 : 5 points
Dossier n° 3 : 5 points
Dossier n° 4 : 5 points

Contexte commun aux 4 dossiers

Dans le cadre du plan « Hôpital 2007 », le CHU d’une grande métropole régionale souhaite moderniser son
système d'information pour permettre le partage d'un plus grand nombre d'informations entre les différentes
unités administratives, logistiques et médicales et accroître ainsi sa réactivité et son efficacité dans
l'accompagnement de ses patients.

Les 4 dossiers traitent les points suivants :

Dossier 1 : Dictionnaire des données et dépendances fonctionnelles

Dossier 2 : Modèle Conceptuel des Données

Dossier 3 : Modèle relationnel / Algèbre relationnel / SQL

Dossier 4 : Problématiques techniques

Les questions s’enchaînent logiquement mais il n’est pas indispensable d’avoir trouvé la bonne solution à la
question N pour pouvoir bien répondre à la question N+1.

1
Dossier 1 : Dictionnaire des données et dépendances fonctionnelles

C’est autour du patient que va se constituer le nouveau système d’information, mais le respect du secret
médical impose de séparer les données administratives des données cliniques. Nous ne nous intéressons
qu’aux données administratives.

En tant que contrôleur de gestion attaché au Département de l'Offre de Soins et de la Clientèle (DOSC), vous
êtes nommé coordinateur du projet et recevez les premiers travaux réalisés sous forme d’un dictionnaire des
données. 1

Voir l’extrait du dictionnaire des données en Annexe 1.

Ce dictionnaire des données a permis aux informaticiens de construire une matrice des dépendances
fonctionnelles (D.F.) présentée en annexe 2.

Travail à faire :

1) Il est fait mention dans le dictionnaire de l’AFNOR, Association Française de Normalisation, qui définit
les normes dans de nombreux domaines et est la correspondante de l’I.S.O. (Organisation internationale
de normalisation) qui dépend de l’Organisation des Nations Unies.

Quel est l’intérêt de respecter les normes AFNOR pour la définition des adresses ?

2) Compte-tenu des données dont vous disposez, complétez le graphe des D.F. de l’annexe 3 (à joindre à la
copie).

Dossier 2 : Modèle Conceptuel des données

Dictionnaire des données et matrice des DF des annexes 1 et 2 permettent aussi de construire le modèle
conceptuel des données de l’annexe 3.

Travail à faire :

1) Compléter ce MCD avec les cardinalités en appliquant la règle de gestion selon laquelle, du point de vue
administratif, un séjour est prescrit par un médecin et un seul.

2) Le MCD considéré jusqu’ici n’est que la petite partie d’un MCD beaucoup plus complexe. Parmi les
évènements liés au séjour du patient, il y a le problème de la réservation d’une chambre pendant la durée
du séjour, ainsi que celui de la réservation d’une salle d’opération et/ou d’équipements lourds comme
radiographie, scanner, etc... à un instant précis du séjour.

Intéressons nous à ce dernier point. Sachant que le système gère l’entité « EQUIP_EXAMEN », identifiée
par la clef EquipExamen_Id, complétez le MCD avec cette entité et l’association qui la relie à l’entité
« SEJOUR_ADMINISTRATIF ». Précisez les cardinalités et complétez éventuellement l’association
avec les données qu’elle est susceptible de porter. Pour définir ces données, songez que vous devez
consolider les données d’ordre administratif mais proscrire toute donnée d’ordre clinique pour respecter la
règle du secret médical.

1
Ce dictionnaire est, pour les besoins de l’examen, considérablement simplifié par rapport à ce que serait le dictionnaire
réel d’une telle application.
2
Dossier 3 : Modèle relationnel / Algèbre relationnel / SQL

La base de données est construite avec des tables relationnelles qui matérialisent les diverses entités. Nous
fournissons ci-dessous quelques éléments du schéma relationnel de la Base :

PATIENTS_ADM (PatientAdm_Id, #Civilite_Id, PatientAdm_Nom, PatientAdm_Prenom,


PatientAdm_NoSS, PatientAdm_DateNaissance, PatientAdm_VilleNaissance, PatientAdm_PaysNaissance,
PatientAdm_AdresseFrPL, PatientAdm_AdresseFrVoie, PatientAdm_AdresseFrLieuDit,
PatientAdm_AdresseFrCP, PatientAdm_AdresseFrBD)
SEJOURS_ADM (SejourAdm_Id, #PatientAdm_Id, SejourAdm_DateDebut, SejourAdm_DateFin,
#MedecinId, #Motif_Id)
PRESTATIONS_ADM (PrestationAdm_Id, #SejourAdm_Id, #NaturePrestation_Id, PrestationAdm_Date,
PrestationAdm_Commentaire)
NATURES_PRESTATIONS (NaturePrestation_Id, NaturePrestation_Code,
NaturePrestation_Designation, NaturePrestation_NbUO)
MEDECINS (MedecinId, Medecin_Nom, Medecin_Prenom, Medecin_NoConseil)
CIVILITES (Civilite_Id, Civilite_IntCourt, Civilite_IntLong)
MOTIFS (MotifId, MotifIntitule)

Travail à faire :

1) Quelles sont les deux clefs étrangères manquantes dans la table PRESTATIONS_ADM ?

2) Compte tenu de la définition des tables fournies ci-dessus, rédiger les requêtes (SQL ou algébre
relationnelle) fournissant les éléments suivants :

1. Liste des patients (Civilité réduite, nom, prénom, Date et ville de naissance, classés par date (ordre
décroissant) et par ville (ordre alphabétique croissant).
2. Liste des séjours effectués par les patients. Pour chaque patient, on indiquera le nom et le prénom.
Pour chaque séjour, on indiquera la date de début de séjour et la date de fin. Les critères de tri
(croissant) seront Nom patient (primaire) et date de début de séjour (secondaire).
3. Montant en U.O. de la facture des prestations du Patient No 1 pour l’ensemble de ses séjours.

Dossier 4 : Problématiques techniques

Le CHU avait mis en place des systèmes de gestion indépendants, conçus pour une fonction spécifique. Il est
très difficile de faire dialoguer ces systèmes entre eux alors que l’exigence de communication est
indispensable pour construire un véritable système d’information. Le CHU recherche aujourd’hui le pilotage
intégré de ses fonctions et de ses processus de base :

• Comptabilité/Finances (comptabilité générale, analytique et budgétaire) ;


• Immobilisations ;
• Achats (médicaments, suivi des lots, matériel médical) ;
• Stocks (pharmacies centrales et secondaires, gestion de l'économat) ;
• Maintenance (Infrastructure et équipements médicaux) ;
• Gestion des processus (Workflow Information Manager) ;
• Pilotage des activités ;
• Gestion des recettes ;
• Contrôle budgétaire ;
• Enregistrement et traitement des besoins des services, transformés en demandes d'achats ou en livraisons
internes ;
• Reporting budgétaire ;
• Aide à la prise de décision.

3
Travail à faire :

1) Quelle solution peut-il envisager pour ses choix de logiciels ?

Le futur réseau interne doit irriguer le CHU et doit constituer le vecteur d’information et de publication.

Ce réseau sera aussi le portail d’entrée vers de nombreuses applications fonctionnant en mode Web, telles
que les demandes au Centre d’Editique ou le catalogue des actes de biologie. Bientôt, le PMSI (Plan de
Médicalisation du Système d’Information) et la consultation des dossiers médicaux seront accessibles via
ce réseau qui deviendra le point d’entrée de nombreuses applications du Système d’Information
Hospitalier (SIH).

2) Quel nom sera donné à ce type de réseau compte-tenu de ces spécifications ? A quel type de réseau ce
nom fait-il référence et quel point commun a-t-il avec lui ?

50 % des images de radiologie sont aujourd’hui obtenues sous forme numérique (IRM, scanner,
échographies et médecine nucléaire). La tendance est donc d’intégrer l’image au système d’information
hospitalier. Or l’image est gourmande en ressources :

• une image de radiographie de thorax occupe entre 4 et 8 mégaoctets,


• un examen de tomodensitométrie 10 mégaoctets,
• une imagerie par résonance magnétique 2 mégaoctets.

Un autre problème est aussi celui du grand nombre d'images générées par examen : un seul examen de
tomodensitométrie peut générer entre 20 et 50 images.

3) Quelles technologies doit envisager l’hôpital pour que son réseau réponde à ces exigences de haut débit ?

Le concept de Réseau de Santé va permettre les échanges (télémédecine) entre l’hôpital et les médecins
de la ville. Le dossier patient sera géré dans le S.I. de l’hôpital, des données seront extraites de ce dossier
et envoyées au médecin traitant.

4) Quelles précautions devront prendre les informaticiens pour assurer les transferts d’information dans le
respect des exigences du secret médical ?

4
ANNEXE N° 1

Dictionnaire des données

Compl.
No Identifiant propriété Description Format format/Taille Commentaire

Le "Patient_Administratif" regroupe les données administratives relatives à un patient.


Il doit être rattaché à un médecin (médecin traitant).
Identifiant administratif Code interne d'identifiant du Patient
1 PatientAdm_Id Patient Entier long Numéro auto Administratif
2 PatientAdm_Civilite_Id Code civilité Patient Numérique Entier long Civilités (M., Mme, Mlle, ..) en table
3 PatientAdm_Nom Nom patronymique Texte 50
4 PatientAdm_Prenom Prénom Texte 50
5 PatientAdm_NoSS No sécurité sociale Texte 18
6 PatientAdm_DateNaissance Date de naissance Date JJ/MM/AAAA
7 PatientAdm_VilleNaissance Ville de naissance Texte 50
8 PatientAdm_PaysNaissance Pays de naissance Texte 50
Point de livraison Adresse en France codifiée selon
9 PatientAdm_AdresseFrPL adresse Texte norme AFNOR
10 PatientAdm_AdresseFrVoie Voie adresse Texte idem
11 PatientAdm_AdresseFrLieuDit Lieu dit adresse Texte idem
12 PatientAdm_AdresseFrCP Code Postal Adresse Texte idem
Bureau distributeur
13 PatientAdm_AdresseFrBD adresse Texte idem

Le "Séjour_Administratif" regroupe les données décrivant le séjour d'un patient du point de vue administratif.
Il doit être rattaché à un patient administratif (qui effectue le séjour).
Il doit aussi être motivé (urgence ou prescription) et rattaché au médecin qui prescrit le séjour.
Code interne d'identifiant du séjour
14 SejourAdm_Id Identifiant d'un séjour Entier long Numéro auto administratif
Un séjour est initié par
JJ/MM/AAAA l'administration à l'entrée du
15 SejourAdm_DateDebut Début du séjour Date HH:MM PatientAdm
JJ/MM/AAAA
16 SejourAdm_DateFin Fin du séjour Date HH:MM

Durant ce séjour, le patient a consommé diverses prestations générales (Chambre, TV, repas, lingerie).
La prestation doit être rattachée à un séjour administratif. Elle doit aussi être rattachée à une nature de
prestation.
Identifiant de la Code interne d'identifiant de la
17 PrestationAdm_Id prestation Entier long Numéro auto prestation
JJ/MM/AAAA
18 PrestationAdm_Jour Date prestation Date HH:MM
Commentaire éventuel
19 PrestationAdm_Commentaire sur prestation Texte 50

Ces prestations sont codifiées, identifiées et tarifées sous forme d'Unités d'œuvre.
Identifiant de la nature Code interne de l'identifiant de la
20 NaturePrestation_Id de la prestation Entier long Numéro auto nature de la prestation
21 NaturePrestation_Code Code mnémonique Texte 10
Désignation de la
22 NaturePrestation_Designation prestation Texte 50
Nb d'unités d'oeuvre
23 NaturePrestation_NbUO pour la facturation Numérique Entier

5
Les civilités sont codifiées dans une table.
Code interne de l'identifiant de la
24 Civilite_Id Identifiant de la civilité Entier long Numéro auto civilité
25 Civilite_IntCourt Intitulé court Texte 5
26 Civilite_IntLong Intitulé long Texte 25

Une table identifie l'ensemble des médecins prescripteurs potentiels.


Code interne de l'identifiant du
27 Medecin_Id Identifiant Entier long Numéro auto médecin
Nom patronymique du
28 Medecin_Nom médecin Texte 50
29 Medecin_Prenom Prénom du médecin Texte 50
No d'inscription du
médecin au conseil de
30 Medecin_NoConseil l'ordre Texte 25

Une table identifie les motifs d'hospitalisation.


31 Motif_Id Identifiant Entier long Numéro auto Code interne de l'identifiant du motif
Intitulé du motif
32 Motif_Intitule d'hospitalisation Texte 50

6
ANNEXE N° 2

Matrice des Dépendances Fonctionnelles

No Identifiant propriété
1 14 17 20 24 27 31
1 PatientAdm_Id X 1
2 PatientAdm_Civilite_Id 1
3 PatientAdm_Nom 1
4 PatientAdm_Prenom 1
5 PatientAdm_NoSS 1
6 PatientAdm_DateNaissance 1
7 PatientAdm_VilleNaissance 1
8 PatientAdm_PaysNaissance 1
9 PatientAdm_AdresseFrPL 1
10 PatientAdm_AdresseFrVoie 1
11 PatientAdm_AdresseFrLieuDit 1
12 PatientAdm_AdresseFrCP 1
13 PatientAdm_AdresseFrBD 1
14 SejourAdm_Id X 1
15 SejourAdm_DateDebut 1
16 SejourAdm_DateFin 1
17 PrestationAdm_Id X
18 PrestationAdm_Jour 1
19 PrestationAdm_Commentaire 1
20 NaturePrestation_Id 1 X
21 NaturePrestation_Code 1
22 NaturePrestation_Designation 1
23 NaturePrestation_NbUO 1
24 Civilite_Id X
25 Civilite_IntCourt 1
26 Civilite_IntLong 1
27 Medecin_Id 1 1 X
28 Medecin_Nom 1
29 Medecin_Prenom 1
30 Medecin_NoConseil 1
31 Motif_Id 1 X
32 Motif_Intitule 1

7
NOM PATRONYME :
Prénoms :
N° UE :
Matière :
______________________________________________________________________________________________

ANNEXE N° 3

Graphe des Dépendances Fonctionnelles

(A conserver)

8
NOM PATRONYME :
Prénoms :
N° UE :
Matière :
______________________________________________________________________________________________

ANNEXE N° 3

Graphe des Dépendances Fonctionnelles

(A compléter et à rendre avec la copie)

9
NOM PATRONYME :
Prénoms :
N° UE :
Matière :
______________________________________________________________________________________________

ANNEXE N° 4

Modèle Conceptuel des Données

(A compléter et à rendre avec la copie)

ier 4 : Problématiques techniques

10
NOM PATRONYME :
Prénoms :
N° UE :
Matière :
______________________________________________________________________________________________

ANNEXE N° 4

Modèle Conceptuel des Données

(A conserver)

ier 4 : Problématiques techniques

11

Vous aimerez peut-être aussi