Des dossiers médicaux - PHP - Programmation
Marsh Posté le 07-12-2015 à 13:13:02
Faire une table par patient n'a absolument aucun sens dans une BD de type relationnelle Une table d'un SGBD digne de ce nom peut accueillir des millions d'enregistrements sans pb. Pour les perfs, ça implique de bien dimensionner le ou les serveurs et de tuner le SGBD comme il faut (taille des caches, des indexes... ça vaut surtout pour Mysql je pense) et, bien entendu, de modéliser sa BD, de positionner les indexes correctement et d'écrire ses requêtes SQL de manière à tirer parti des indexes.
Après, pour les très gros volumes de données (big data), les BD de type NoSQL sont adaptées.
Cependant, y'a un aspect que tu semble laisser de côté (tu n'en a pas parlé en tout cas), c'est la sécurité et l'accès aux données. Des dossiers médicaux, c'est très sensible comme info. Ca doit donc être chiffré, à mon sens. De plus, en fonction des profils d'utilisateurs, il ne faut pas qu'il puissent accéder à des données dont ils n'auraient pas besoin.
Ta proposition de faire une table par patient me laisse à penser (peut-être à tord) que tu es assez novice dans ce type de logiciel. Si c'est le cas, ça me paraît inconcevable qu'on te laisse développer une appli aussi sensible
Marsh Posté le 07-12-2015 à 14:59:35
Une table par patient, intéressant comme approche
Et tu comptes mettre une nouvelle colonne par info à introduire, et une seule ligne par table ?
Tu n'as jamais du toucher à un SGBDR ?
Je ne me vois même pas proposer un modèle alternatif, là on ne peut que t'inviter à lire un cours fondamental sur la modélisation de BdD relationnelles.
Et j'approuve rufo sur toute la ligne, sauf que je n'aurai même pas évoqué NoSQL (hors de portée et sans objet dans ton cas à mon avis).
Marsh Posté le 07-12-2015 à 19:20:11
Gaffe à la législation, c'est très sensible les données médicales
Marsh Posté le 08-12-2015 à 09:12:40
ReplyMarsh Posté le 08-12-2015 à 13:27:35
Héy les gars pas de panique, c'est une petite application que j'éssaye de developper pour un ami infirmier chef de poste dans un petit dispensaire de village ou durant l'hivernage il recoit beaucoup de malades atteints de pathologies locales courantes (palu, méningite ets ...) mais qu'il veut suivre sur plusieurs années facilement sans manipuler beaucoup de paparasse et puis ce ne sera pas un truc qui sera en ligne avec hebergement et machins.... juste un truc en local sur un seul ordinateur qu'il sera le seul à manipuler parcequ'etant le seul instruit pour utiliser un ordi quand l'hôpital a parfois les moyens d'avoir de l'electricité bien sure .
Vous savez rabaissez un peu le niveau pour nous autres du sud on est à des années lumières par rapport à votre envoronnement technique et vos niveau des performance
En tout cas Merci de vos conseils certains me paraissent pertinants et parlants je vais les experimenter et voire
Marsh Posté le 08-12-2015 à 14:18:55
Présenté comme ça l'intention est admirable et effectivement on peut faire fi de toutes les normes qui régissent la confidentialité des données si on part du principe que c'est ta solution ou pas de solution du tout.
Donc on en revient à la question initiale, en SGBDR, et une fois que tu auras lu un petit cours, applique quelques principes de base de modélisation :
- Identifier les fonctionnalités voulues parce que là tu es super vague
- Identifier les entités (patients, dossier, élément médical...) et leurs relations
- Identifier les actions possibles dans l'appli (saisir une note, stocker un fichier contenant un élément médical, exporter, consulter)...
Mais plutôt que partir de 0 il n'y aurait pas des projets opensource (même non orientés vers les problématiques médicales) qui ferait déjà ce que tu veux ?
En outre puisque tu veux du PHP tu es conscient qu'il faut une connexion internet ou un serveur web local ? Si le but est de tout avoir sur un unique ordinateur sans hébergement ça crée une difficulté inutile.
Marsh Posté le 08-12-2015 à 15:09:08
+1 pour l'intention Néanmoins, je me dis que ce n'est pas parce que ce sont des gens pauvres du Sud qu'ils n'ont pas droit à un minimum de confidentialité. Chiffrer certaines données de la base, ça peut se faire relativement facilement aujourd'hui avec des libs
Perso, je trouve que l'idée d'une appli web est bonne, même pour une appli en local. En effet, si un jour il faut passer à une appli en réseau, l'architecture ne va pas changer fondamentalement, au contraire d'une appli mono-poste (qu'il faudra reprendre complètement).
Par contre, partir de 0 me paraît délicat. Quelques liens intéressants à mon avis sur le sujet :
http://medintux.org/
https://fr.wikipedia.org/wiki/Mediboard
http://codes-sources.commentcamarc [...] s-medicaux
Si tu voulais malgré tout faire le dev en partant de 0, qq conseils :
- cours sur la modélisation de BD (voir MERISE et la forme 3NF de Codd)
- Mysql ou Postgres feront l'affaire. Vu les conditions que tu décris, je doute qu'il faille à ton appli stocker des Go d'imageries médicales Ce qui sera stocké sera essentiellement du texte, donc ça prend pas tellement de place.
- le design pattern MVC te sera utile. Tu peux, d'ailleurs, regarder qq frameworks. Il faut bien comprendre la séparation entre la partie métier, l'affichage et le stockage des données.
- côté html/css, bien comprendre la séparation fond/forme. Fond = HTML (structuration des infos d'une page), forme = css (mise en page). Le site d'alsacreation est très bien pour apprendre ça
- penses à faire une appli avec des fichiers de langues pour permettre sa traduction aisée.
Bon courage en tout cas.
Marsh Posté le 09-12-2015 à 14:17:27
Je viens de tomber sur cet article aujourd'hui : http://korben.info/zerodb-base-donnee-chiffree.html
Un SGBD chiffré nativement
Marsh Posté le 09-12-2015 à 14:20:03
Il y a un connecteur PHP pour ce machin ?
Déjà qu'une bdd en clair avec un provider stable c'est pas forcément facile à utiliser pour un débutant, là c'est quand même se créer des difficultés même si sur le fond je suis d'accord sur le besoin de confidentialité
Marsh Posté le 09-12-2015 à 14:24:46
Ben il indiquait que c'est une appli en local. Donc pas besoin de trouver un hébergeur.
Marsh Posté le 09-12-2015 à 14:26:48
Quel rapport ? Local ou pas ton langage doit bien pouvoir consommer ton SGBDR.
Marsh Posté le 09-12-2015 à 14:36:30
Quand tu as parlé de provider, j'ai cru que tu parlais d'un hébergeur (pour son appli web). Pour l'instant, y'a pas de connecteur php apparemment. Y'en a que pour Python. Mais y'a une API JSON, donc suffit de mettre côté serveur un script Python qui va traiter les queries reçues en JSON.
Edit : après, c'est clair que c'est un produit très jeune et pas forcément accessible pour un débutant en dév. C'est donc pas ce que je recommanderais de base. On tout à fait faire une appli avec un minimum de sécu pour les données avec du PHP, Mysql et qq lib de chiffrement.
Marsh Posté le 09-12-2015 à 14:37:45
Ah ok. Oui j'ai changé de terme entre les deux phrases mais le sujet était toujours le même.
Marsh Posté le 07-12-2015 à 11:59:10
Bonjour je souhaite développer avec PHP, et HTMLune application qui gère des centaines de dossiers médicaux .je souhaiterais que chaque dossier concernant un patient soit confiné dans une table ou l'ensemble des soins reçus par l'individu au cours de plusieurs années seront enregistrés . Alors reste à savoir est ce que la création d'un millier de table est supportable par une application , aussi est ce que ce nombre de tables risque d’altérer la performance de l'application (la rapidité d’exécution ) si oui , existe t''elle une solution alternative à la création de ces tables .
merci