Soutenance mémoire
Présentation de quelques concepts
Définition d’un SIH
Selon Wikipédia, un Système d’Information Hospitalier (SIH) est un système permettant un traitement intégré de l’information, garantissant sa cohérence et son intégration. L’information, une fois capturée, doit être disponible en tous lieux, en tous temps, dans des délais acceptables (dossiers médicaux, images,…), sous une forme paramétrable et ne doit pas faire l’objet de ressaisies. Elle doit être exprimée dans une « granulosité » suffisamment fine pour être utile et autoriser des agrégations ainsi que des associations.
Un SIH est composé de deux domaines différents:
./ Les systèmes de gestion (qui concernent la gestion des ressources humaines, les affaires financières et économiques, la logistique, les achats, mais également toutes les activités dites d’intendance, à savoir la gestion des repas, la gestion de la lingerie, etc.)
./ Les systèmes relatifs à la prise en charge du patient (prise en charge administrative, médicale et paramédicale) qui concernent le cœur de métier de l’hôpital: la production de soins. Ces systèmes comprennent toutes les informations nécessaires à l’accomplissement des activités du processus de production des soins au patient, de son accueil à sa sortie, ainsi qu’à la bonne circulation des flux physiques qui servent directement cette production.
Définition des causes de décès
Selon l’OMS, la définition des causes de décès qui doit être rapportée sur le certificat médical est la suivante: « toutes maladies, états morbides ou traumatismes qui ont abouti ou contribué au décès, et les circonstances de l’accident ou de la violence qui ont entraîné ces traumatismes». Cette définition conduit à l’inscription sur le certificat médical de l’ensemble des renseignements médicaux relatifs au décès et à éviter au certificateur de ne retenir que certaines affections observées et d’en écarter d’autres. Elle n’inclut pas les symptômes et les mécanismes de décès tel que les défaillances cardiaques ou respiratoires.
Le codage des causes médicales de décès
Les causes médicales de décès mentionnées sur le volet médical du certificat sont analysées et codées selon les règles de la Classification Internationale des Maladies (CIM). La codification des décès comporte deux tâches distinctes et successives: Attribuer un code à chaque maladie, traumatisme ou cause externe de décès mentionné sur le certificat et sélectionner et coder la cause initiale de décès. La qualité de la codification détermine largement la qualité et la comparabilité internationale des données produites. La Classification Internationale des Maladies définit les codes, les règles et les directives permettant de mener ces tâches à bien. Elle existe depuis plus d’un siècle. Elle est révisée périodiquement, la version actuelle étant la dixième révision (CIMIO). Cette classification est utilisée tant pour l’étude de la morbidité que de la mortalité.
Présentation des SIH les plus courants
Définition
Mediboard est un Framework d’entreprise, un système web libre de gestion d’établissement. Il se définit plus précisément comme un SIH (Système d’Information Hospitalier), ou un PGI (Progiciel de Gestion Intégré) adapté aux établissements de santé de toute taille, du simple cabinet de praticien au centre médical multi-sites.
Fonctionnalités
Mediboard est un système d’information hospitalier dédié à la gestion du dossier patient, la planification de l’activité de l’établissement de santé et la gestion de IIactivité clinique et libérale des praticiens.
Il fournit les modules suivants:
Dossier patient administratif et médical
.Gestion de l’identité des patients;
.Moteur de recherche avancé incluant les résultats proches phonétiquement;
.Gestion des séjours;
.Accueil clinique: admissions et sorties des patients;
.Création de dossier par « carte vitale» ;
.Gestion des doublons de dossier;
.Génération de documents basés sur des modèles: feuilles d’admission, consentements, fiches d’information, ordonnance;
.Gestion électronique de documents, tout format;
.Gestion des antécédents, allergies;
.Systèmes d’alerte entre les professionnels de santé et le personnel d’établissement;
Activités de l’établissement de santé
.Planning des admissions/sorties du patient à l’accueil;
.Gestion bloc opératoire;
.Planification de l’hospitalisation;
.Dossier de soin et circuit du médicament;
.Gestion des repas;
.Système de gestion de la qualité / accréditation;
.Vérification du codage des actes et pré-groupage pour exportation;
.Tableau de bord de l’activité;
Activités des praticiens/ libérales
.Prise de rendez-vous de consultation;
.Gestion de consultation médicales, chirurgicales;
.Gestion des consultations pré-anesthésiques;
.Intégration de la télétransmission de F5E;
.Production automatisée de courriers, prescription des ordonnances basées sur des
modèles;
.Tableaux de bord hebdomadaires et quotidiens;
.Gestion comptable de l’activité libérale;
.Gestion comptable du cabinet médical;
Activités cliniques
.Fiche d’administration électronique basée sur des protocoles;
.Planification des plages d’opération;
.Planning du bloc opératoire;
.Codage direct des actes CCAM (Classification commune des actes médicaux) en
salle, pendant IIintervention ;
.Production automatisé de compte-rendu d’intervention, basé sur modèles;
.Gestion des dossiers d’anesthésie ;
CONCEPTION ET REALISATION DU FUTUR SYSTEME
Architecture du futur système
D’après l’étude que nous avons effectuée sur l’état de l’art des technologies à utiliser, nous rangeons notre application dans le groupe des architectures à base de composants. Ainsi nous projetons d’adopter une architecture Client-Serveur pour l’architecture du système et une architecture MVC pour l’application en tant que telle.
Architecture du système: Client-serveur 3-tiers
L’architecture 3-tires (de l’anglais tiers signifiant étage ou niveau) est un modèle logique d’architecture applicative qui vise à séparer très nettement trois couches logicielles au sein d’une même application ou système, à modéliser et présenter cette application comme un empilement de trois couches, étages, niveaux ou strates dont le rôle est clairement défini:
➩ La présentation des données (couche présentation): correspondant à l’affichage, la restitution sur le poste de travail, le dialogue avec l’utilisateur;
➩ Le traitement métier des données (couche métier): correspondant à la mise en œuvre de l’ensemble des règles de gestion et de la logique applicative ;
➩ L’accès aux données persistantes (couche accès aux données) : correspondant aux données qui sont destinées à être conservées sur la durée, voire de manière définitive.
Dans cette approche, les couches communiquent entre elles à travers un «modèle d’échange», et chacune d’entre elles propose un ensemble de services rendus. Les services d’une couche sont mis à disposition de la couche supérieure. On s’interdit par conséquent qu’une couche invoque les services d’une couche plus basse que la couche immédiatement inférieure ou plus haute que la couche immédiatement supérieure (chaque couche ne communique qu’avec ses voisins immédiats). Le rôle de chacune des couches et leur interface de communication étant bien définis, les fonctionnalités de chacune d’entre elles peuvent évoluer sans induire de changement dans les autres couches.
Nous adaptons l’architecture client-serveur 3-tiers pour plusieurs raisons:
• Toutes les dOlmées sont centralisées sur un serveur, ce qui simplifie les contrôles de sécurité, l’administration, la mise à jour des données et des logiciels.
• La complexité du traitement et la puissance de calculs sont à la charge du ou des serveurs, les utilisateurs utilisent simplement un client léger sur un ordinateur terminal qui peut être simplifié au maximum.
• Le modèle nous garantit aussi un réseau évolutif car il est possible de supprimer ou rajouter des clients sans perturber le fonctionnement du réseau et sans modification majeure.
• Amélioration de la sécurité des données avec une suppression du lien directe entre le .client et les données;
• Rupture du lien de propriété exclusive entre application et données;
|
Table des matières
INTRODUCTION GENERALE
CHAPITRE 1: ETUDE PREALABLE
1.1 Phase de lancement
1.1.1. Présentation de l’ESI
1.1.2. Présentation du CHUSS
1.2 Présentation du problème et résultats attendus
1.2.1. Problématique
1.2.2. Résultats attendus
1.3 Approche de résolution
1.3.1. Langage de modélisation et méthode d’analyse
1.3.2. Acteurs du projet
1.4 Gestion du projet
CHAPITRE 2: ETAT DE L’ART SUR LES SYSTEMES D’INFORMATION HOSPITALIERS
2.1 Présentation de quelques concepts
2.2 Présentation des SIH les plus courants
2.3 Etude comparée et choix d’un SIH pour le CHUSS
CHAPITRE 3: PRESENTATION DU SIH MEDIBOAD
3.1. Présentation générale de Mediboard
3.2. Architecture de Mediboard
3.2.1. Architecture web de Mediboard
3.2.2. Architecture technique de Mediboard
CHAPITRE 4: CONCEPTION ET REALISATION DU FUTUR SYSTEME
4.1 Architecture du futur système
4.2 Choix technologiques pour le développement
4.3 Conception détaillée
4.3.1. Diagramme des cas d’utilisation
4.3.2. Description des cas d1utilisation
4.3.3. Diagramme de classe de base du système
4.3.4. Diagramme d’activité du circuit du patient au CHUSS
4.3.5. Diagramme d’activité de la certification et du codage des causes de décès
4.3.6. Diagramme des séquences du circuit du patient au CHUSS
4.3.7. Diagramme des séquences de la certification et du codage des causes de décès
4.3.8. Diagramme de déploiement de KENEYA-SIRA mise en place
4.4 Réalisation
4.4.1. Présentation de quelques maquettes
4.4.2. Politique de sécurité et phase de transition
4.4.3. Bilan et perspectives
CONCLUSION GENERALE
Télécharger le rapport complet
