Implémentation et administration d'un système d'information distribué pour le suivi des dossiers médicaux dans un hôpital

SECTION I : MODELISATION FONCTIONNELLE

1. ANALYSE FONCTIONNELLE

1.1. DEFINITION DES BESOINS DU SYSTEME D'INFORMATION

a) Spécification des besoins des utilisateurs

Ce système doit permettre la gestion d'un dossier médical informatisé, de pouvoir permettre la consultation des dossiers médicaux de manière instantané, d'ajouter des nouveaux éléments dans les dossiers (Consultation médicale, hospitalisation, vaccination ou intervention chirurgicale), de créer un dossier médical s'il est inexistant.

· Pour le secrétaire : Se connecter au système, consulter un dossier médical et pouvoir ajouter une activité bien que pour cela il lui faut une autorisation spéciale du médecin ;

· Ambulancier : Se connecter au système, Consulter un dossier médical ;

· Patient : Se connecter au système, Consulter un dossier ;

· Médecin : Ajouter une activité, créer un dossier et consulter un dossier.

b) Identification des cas d'utilisation

· Créer un dossier : doit se faire par le Médecin en se connectant au préalable ;

· Ajouter une activité : doit se faire par le Médecin et parfois le secrétaire. Et cette activité peut être une hospitalisation, une consultation ou une intervention chirurgicale ;

· Consulter un dossier : peut se faire avec n'importe quel utilisateur.

1.2. MODELISATION METIER

· Présentation des acteurs

Les acteurs d'un système sont les entités externes à ce système qui interagissent (saisie de données, réception d'information,) avec lui. Les acteurs sont donc à l'extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner l'interface que le système va devoir offrir à son environnement. Oublier des acteurs ou en identifier de faux conduit donc nécessairement à se tromper sur l'interface et donc la définition du système à produire.

Nous pouvons donc citer nos acteurs qui sont entre autre le médecin, le patient, le secrétaire ainsi que l'ambulancier.

1.3. DIAGRAMME DE CAS D'UTILISATION

Un diagramme de cas d'utilisation capture le comportement d'un système, d'un sous-système, d'une classe ou d'un composant tel qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d'utilisation, ayant un sens pour les acteurs^8(*).

v Eléments des diagrammes de cas d'utilisation

· Acteur : Est l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système

Figure 2 : Représentation d'un acteur

· Cas d'utilisation : Un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de l'extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service.

Un cas d'utilisation se représente par une ellipse contenant le nom du cas (un verbe à l'infinitif), et optionnellement, au-dessus du nom, un stéréotype.

Figure 3 : Représentation d'un cas d'utilisation

v Représentation d'un diagramme de cas d'utilisation

Figure 4 : Représentation d'un diagramme de cas d'utilisation

v Relations entre acteurs et cas d'utilisation

Une relation d'association est un lien de communication entre un acteur et un cas d'utilisation.

· Représentation d'une relation d'association

Un trait continu

Figure 5 : Représentation d'une relation d'association

· Relation d'inclusion

La relation d'inclusion spécifie qu'un cas d'utilisation est nécessairement une partie d'un autre cas d'utilisation

Représentation d'une relation d'inclusion

Une flèche discontinue stéréotypée <<inclusion>>

Figure 6.1Représentation d'une relation d'inclusion

Rôle de la relation d'inclusion

- Décomposer un cas complexe en sous-cas plus simples

- Factoriser une partie d'un cas d'utilisation commune à d'autres cas d'utilisation

· Relation d'extension

La relation d'extension spécifie qu'un cas d'utilisation est éventuellement une partie d'un autre cas d'utilisation.

Représentation d'une relation d'extension

Une flèche discontinue stéréotypée <<extension>>

Figure 6.2 Représentation d'une relation d'extension

v Principe

La relation de généralisation/spécialisation est la transposition aux cas d'utilisation de la notion d'héritage dans le paradigme objet.

· Représentation d'une relation de généralisation/spécialisation

Une flèche dont la pointe (un triangle fermé) est dirigée vers l'élément le plus général.

Figure 6.3 : Représentation d'une relation de généralisation/spécialisation

· Associations

Une relation d'association est chemin de communication entre un acteur et un cas d'utilisation et est représenté un trait continu.

Figure 7 Exemple de relation entre acteur et cas d'utilisation en ligne

v Association :

· Relation entre acteurs et cas d'utilisation

· Représente la possibilité pour l'acteur de déclencher le cas

v Multiplicité

Lorsqu'un acteur peut interagir plusieurs fois avec un cas d'utilisation, il est possible d'ajouter une multiplicité sur l'association du côté du cas d'utilisation. Le symbole * signifie plusieurs, exactement n s'écrit tout simplement n, n..m signifie entre n et m, etc. Préciser une multiplicité sur une relation n'implique pas nécessairement que les cas sont utilisés en même temps. La notion de multiplicité n'est pas propre au diagramme de cas d'utilisation.

La Multiplicité est le nombre de fois où l'acteur peut déclencher le cas :

· * : une infinité de fois (pas représenté en général)

· [n..m] : entre n et m fois

· n : exactement n fois

Acteurs principaux et secondaires

Un acteur est qualifié de principal pour un cas d'utilisation lorsque ce cas rend service à cet acteur. Les autres acteurs sont alors qualifiés de secondaires. Un cas d'utilisation a au plus un acteur principal. Un acteur principal obtient un résultat observable du système tandis qu'un acteur secondaire est sollicité pour des informations complémentaires. En général, l'acteur principal initie le cas d'utilisation par ses sollicitations. Le stéréotype « primary » vient orner l'association reliant un cas d'utilisation à son acteur principal, le stéréotype « secondary » est utilisé pour les acteurs secondaires.

Figure 8 : Acteur primaire et secondaire

v Acteurs primaires et secondaires :

· Acteur primaire « primary » : acteur déclenchant le cas

· Acteur secondaire « secondary » : acteur sollicité par le cas

v Cas d'utilisation interne

Quand un cas n'est pas directement relié à un acteur, il est qualifié de cas d'utilisation interne.

v Relations entre cas d'utilisation

· Inclusion : X « include » Y ?X implique Y

Figure 9.1 : Exemple relation d'inclusion

· Extension : X « extend » Y ?X peut être provoqué par Y

X est optionnel pour Y

Figure 9.2 : Exemple relation d'extension

· Généralisation : X est un cas particulier de Y

Entre les acteurs

Figure 9.3 : Exemple généralisation

v Présentation du diagramme de cas d'utilisation

Schéma 5 : Diagramme de cas d'utilisation

1.4. DESCRIPTION TEXTUELLE DES CAS D'UTILISATIONS

· Cas d'utilisation créer un dossier

Sommaire d'identification

Titre : Créer un dossier

But : Permettre au médecin de créer un dossier pour le compte du patient

Résumé : Prélever les informations de l'identification du patient ainsi, sa biométrie ainsi que ses antécédents

Acteur : Médecin

Description de l'enchainement

Précondition : validation de l'authentification dans le système

Post condition : Un nouveau Dossier sera enregistré

Scénario nominal

1. Le médecin saisie son login et son mot de passe

2. Le système vérifie le login et le mot de passe

3. Le système affiche un menu du médecin

4. Le médecin choisi Créer un nouveau dossier

5. Le système affiche un formulaire d'enregistrement

6. Le médecin saisi les informations du patient

7. Le système effectue un contrôle sur les champs obligatoires

8. Le système enregistre les informations

9. Le système affiche un message de confirmation

Scénario alternatif :Erreur d'authentification

Le scénario reprend au point 1 : Nature des champs saisie incorrects

Scénario alternatif :Détection des champs obligatoire vides

Le scénario reprend au point 5 : Champs obligatoires non remplis

Tableau 4.1 : Description textuelle cas d'utilisation créer dossier

· Cas d'utilisation Consulter un dossier

Sommaire d'identification

Titre : Consulter un dossier

But : Permettre aux utilisateurs de pouvoir consulter les informations ultérieures du dossier du patient

Résumé : Afficher les consultations, hospitalisation et toute activité concernant le dossier du patient

Acteurs : Médecin, ambulancier, patient, secrétaire

Description de l'enchainement

Précondition : validation de l'authentification dans le système

Post condition : Une fenêtre d'affichage des données du dossier apparaitra

Scénario nominal

1. L'utilisateur saisie son login et son mot de passe

2. Le système vérifie le login et le mot de passe

3. Le système affiche un menu du médecin

4. L'utilisateur choisi Consulter un nouveau dossier

5. Le système demande le numéro du dossier ou du patient

6. L'utilisateur saisi les informations du patient

7. Le système vérifie les informations saisies

8. Le système affiche les données du dossier

Scénario alternatif :Erreur d'authentification

Le scénario reprend au point 1 : Nature des champs saisie incorrects

Scénario alternatif :Dossier ou patient introuvable

Le scénario reprend au point 5 : Champs obligatoires non remplis

Tableau 4.2 : Description textuelle cas d'utilisation consulter un dossier

· Cas d'utilisation ajouter une consultation

Sommaire d'identification

Titre : Ajouter une consultation

But : Permettre au médecin d'ajouter des nouveaux éléments des consultations médicales dans le dossier du patient

Résumé : Ajouter une consultation dans le dossier médical du patient tout en ajoutant une image, une » ordonnance, un examen et la maladie trouvé si cela est nécessaire

Acteurs : Médecin

Description de l'enchainement

Précondition : validation de l'authentification dans le système

Post condition : Une consultation sera ajoutée

Scénario nominal

1. Le médecin saisie son login et son mot de passe

2. Le système vérifie le login et le mot de passe

3. Le système affiche un menu du médecin

4. Le médecin choisi Ajouter une consultation

5. Le système affiche un formulaire d'enregistrement

6. Le médecin saisi les informations de la consultation

7. Le système effectue un contrôle sur les champs obligatoires

8. Le système enregistre les informations

9. Le système affiche un message de confirmation

Scénario alternatif :Erreur d'authentification

Le scénario reprend au point 1 : Nature des champs saisie incorrects

Scénario alternatif :Détection des champs obligatoire vides

Le scénario reprend au point 5 : Champs obligatoires non remplis

Tableau 4.3 : Description textuelle cas d'utilisation Ajouter une consultation

· Ajouter une hospitalisation

Sommaire d'identification

Titre : Ajouter une hospitalisation

But : Permettre au médecin d'ajouter des nouveaux éléments des hospitalisations dans le dossier du patient

Résumé : Ajouter des une hospitalisation dans le dossier médical du patient en ajoutant des images si possibles

Acteurs : Médecin

Description de l'enchainement

Précondition : validation de l'authentification dans le système

Post condition : Une hospitalisation sera ajoutée

Scénario nominal

1. Le médecin saisie son login et son mot de passe

2. Le système vérifie le login et le mot de passe

3. Le système affiche un menu du médecin

4. Le médecin choisi Ajouter une hospitalisation

5. Le système affiche un formulaire d'enregistrement

6. Le médecin saisi les informations de l'hospitalisation

7. Le système effectue un contrôle sur les champs obligatoires

8. Le système enregistre les informations

9. Le système affiche un message de confirmation

Scénario alternatif :Erreur d'authentification

Le scénario reprend au point 1 : Nature des champs saisie incorrects

Scénario alternatif :Détection des champs obligatoire vides

Le scénario reprend au point 5 : Champs obligatoires non remplis

Tableau 4.4 : Description textuelle cas d'utilisation Ajouter consultation

· Cas d'utilisation Ajouter une intervention chirurgicale

Sommaire d'identification

Titre : Ajouter une intervention chirurgicale

But : Permettre au médecin d'ajouter des nouveaux éléments des interventions chirurgicales dans le dossier du patient

Résumé : Ajouter des une intervention chirurgicale dans le dossier médical du patient en ajoutant des images si possibles

Acteurs : Médecin

Description de l'enchainement

Précondition : validation de l'authentification dans le système

Post condition : Une intervention chirurgicale sera ajoutée

Scénario nominal

1. Le médecin saisie son login et son mot de passe

2. Le système vérifie le login et le mot de passe

3. Le système affiche un menu du médecin

4. Le médecin choisi Ajouter une intervention chirurgicale

5. Le système affiche un formulaire d'enregistrement

6. Le médecin saisi les informations de la consultation

7. Le système effectue un contrôle sur les champs obligatoires

8. Le système enregistre les informations

9. Le système affiche un message de confirmation

Scénario alternatif :Erreur d'authentification

Le scénario reprend au point 1 : Nature des champs saisie incorrects

Scénario alternatif :Détection des champs obligatoire vides

Le scénario reprend au point 5 : Champs obligatoires non remplis

Tableau 4.5 : Description textuelle cas d'utilisation Ajouter une intervention chirurgicale

1.5. IDENTIFICATION DES CLASSES CANDIDATES

Les classes candidates sont déduites de la description textuelle des cas d'utilisation. On parle aussi de classes participantes, dans le sens où elles participent à la description statistique du domaine.

Dans notre cas nous avons identifié les classes candidates suivantes :

- Patient

- Antécédent

- Biométrie

- Activité

- Photo

- Consultation

- Médecin

- Intervention

- Consultation

- Examen

- Maladie

- Vaccination

- Ordonnance

- Hospitalisation

2. ANALYSE DES RESSOURCES UTILISEES

a) Ressources humaines

Généralement la seule personne qui s'occupe du dossier du patient est le médecin traitant lui-même.

b) Ressources matérielles

N°	DESIGNATION	MARQUE/ TYPE	QUANTITE	FREQUENCE	ANNEE D'ACHAT	ETAT
01	Chaise	En bois	4	Journalier	2018	Bon
02	Table	En bois	1	Journalier	2018	Bon
03	Lit de consultation	Métallique	1	Journalier	2015	Bon
04	Armoire	En bois	1	Journalier	2013	Bon
05	Glucomètre		1	Journalier	2013	Bon
06	Tension mètre		1	Journalier	2020	Bon
07	Ventilateur	Philips	1	Journalier	2018	Bon
08	Corbeil en plastique	At.com.Plast	1	Journalier	2020	Bon
09	Balance		1	Journalier	2019	Bon

Tableau 5 : Ressourcesmatérielles

c) Ressources financières

L'hôpital Général de la référence de KINKANDA est sous tutelle de l'état congolais, en occurrence sous la gestion du ministère de santé public son premier partenaire auquel il tire ses ressources financières. Les activités médicales de l'hôpital génèrent des entrées conséquentes. En dehors de ça il y a aussi les ressources financières extérieures comme les O.N.G et les personnes physique et morale de bonne volonté.

3. ETUDE DES DOCUMENTS CIRCULANT DANS LE DOMAINE

Fiche de consultation

Nom Rubrique	Nature	Taille
Date consultation Motif Observation Poids Taille Pouls A_T T_A Nom du patient	AN AN AN N N N N N AN	10 50 300 5 10 8 8 8 50

Tableau 6.1 : Description du document fiche de consultation

Formulaire d'enregistrement

Nom Rubrique	Nature	Taille
Numéro patient Numéro dossier Nom Post nom Prénom Sexe Nationalité Niveau intellectuel Niveau socio-économique Adresse Email Médecin correspondant Antécédents	N N AN AN AN AN AN AN AN AN AN AN AN	10 10 50 50 50 9 30 15 30 100 50 50 300

Tableau 6.2 : Description du document formulaire d'enregistrement

Bon d'analyse labo

Nom rubrique	Nature	Taille
Nom malade Age Sexe Tension artérielle Fréquence cardiaque Fréquence respiratoire Poids Taille Body masse corporelle Signes vitaux	AN N AN AN AN AN N N AN AN	20 3 1 10 10 10 3 3 10 50

Tableau 6.3 : Description du document bon d'analyse

Ordonnance médicale

Nom rubrique	Nature	Taille
Nom Age Sexe Nom du médecin Catégorie patient Prescription médicament Date prescription	AN N AN AN AN AN DATE	20 10 1 25 5 10 10

Tableau 6.4 : Description du document ordonnance médicale

* ⁸ https://laurent-audibert.developpez.com/CoursUML/?page=diagramme-cas-utilisation, consulté le 14/06/2020 à 22h41'.