Soutenance mémoire
Il faut remonter jusqu’en 1600 avant J.-C. pour trouver les premiers rapports médicaux rédigés sur un papyrus égyptien (Al-Awqati, 2006). Il s’agit des premières études de cas à visée pédagogique. A partir du 17ième siècle, le processus s’amplifie toujours dans un objectif d’enseignement mais aussi afin de réaliser des corrélations anatomiques et diagnostiques (Gillum, 2013). Il faut attendre le début du 19ième siècle à Paris et Berlin pour voir l’apparition du premier dossier patient sous forme de feuilles volantes (Hess, 2010). En France, l’émergence dans les années 1920 d’une classe moyenne qui refuse de se faire soigner dans des hôpitaux réservés aux pauvres et indigents, mais qui n’a pas suffisamment de revenus pour aller dans des cliniques privées, va initier dans les années 50 une « humanisation » de l’hôpital et remettre le patient au centre du soin (Nardin, 2010) et donc profondément modifier la manière de recueillir les données. A partir des années 70, le dossier patient se structure et s’archive sous forme de dossier infirmier, de comptes rendus médicaux, de lettres de sortie. A la fin des années 90, les comptes rendus s’informatisent et se structurent davantage. L’informatisation s’accélère notamment pour évaluer les coûts et les remboursements des soins (PMSI, DRG) (Ordonnance no 96-346 du 24 avril 1996 portant réforme de l’hospitalisation publique et privée, n.d.). A partir des années 2000, le dossier patient informatisé (DPI) commence à faire son apparition dans les hôpitaux pour se généraliser en 2010.
Avec l’informatisation du dossier patient, la réutilisation de ces données pour la recherche, pour le management hospitalier et pour l’enseignement devient de plus en plus immédiate, au point que nous structurons les DPIs non plus pour améliorer la prise en charge du patient, mais pour faciliter cette réutilisation. Cette dérive du DPI rend son remplissage laborieux et finalement peu efficace. En effet, les médecins préfèrent utiliser les champs en texte libre plutôt que de cocher des cases. Le texte libre leur permet de mieux préciser leur pensée, d’y inscrire des doutes et des absences de signe, des hypothèses diagnostics (Hanauer et al., 2015; Raghavan et al., 2014; Shivade et al., 2014). Dans le contexte des maladies rares, le texte libre reste le moyen idéal de conserver la richesse phénotypique du patient tout en conservant la relation malade / médecin autour d’une médecine narrative (Charon, 2012). Par ailleurs, certains patients restent sans diagnostic au début de leur prise en charge, le médecin doit donc pouvoir décrire les signes cliniques du patient sans a priori sur son approche sémiologique afin de documenter l’état clinique du patient le plus précisément possible.
Comment réutiliser le dossier de soin ?
Le système d’information hospitalier reste encore très hétérogène et cloisonné d’un logiciel de soin à l’autre. Les hôpitaux mettent en place depuis une dizaine d’années le DPI afin d’uniformiser leur parc logiciel et ainsi réduire le nombre de sources de données de production. Malgré cela, certaines spécialités médicales ont leur propre logiciel, la réanimation, l’anesthésie, l’imagerie, la génétique, l’imagerie anténatale (qui nécessite un identifiant particulier pour les fœtus), le PMSI, les urgences etc. Ces spécialités sont de plus en plus intégrées dans le DPI pour rationnaliser les coûts de maintenance, souvent au détriment des fonctionnalités nécessaires à prendre en compte leurs spécificités. Certaines spécialités résistent à cette intégration afin de garder une souplesse dans les outils qu’ils utilisent. Afin de pallier cette dispersion des données qui peut rendre compliquée la prise en charge des patients, les DPIs peuvent fonctionner comme « data repository ». Cela permet de stocker dans le DPI les données produites dans d’autres logiciels. La DGOS publie annuellement un état des lieux de l’informatisation des établissements de soin (DGOS, 2017). Cet atlas ne prend en compte que les logiciels dits institutionnels et témoigne déjà de la grande hétérogénéité du parc logiciel hospitalier.
Au delà de la diversité des logiciels qui coexistent dans un hôpital, les données médicales sont aussi contenues dans des logiciels obsolètes inutilisés dont les données n’ont pas été reprises dans un logiciel de remplacement. Suivant l’année de mise en place du DPI, le nombre de données ainsi « perdues » est difficilement évaluable sans faire le travail de les récupérer, mais on peut le supposer élevé. Dans le contexte des maladies rares, toutes les données sont importantes en raison, par définition, de la rareté des patients atteints. Il s’agit de pouvoir réutiliser aussi bien les données des logiciels institutionnels que des archives, des logiciels utilisés par une seule équipe, des bases de données réalisées dans le cadre d’un suivi de cohorte, des bases de données « maison » non maintenues etc.
Les données dans ces logiciels sont stockées dans des formats très hétérogènes :
– données codées par un thésaurus local ou national, (résultat biologique, PMSI)
– données structurées non codées (par exemple « diabete : oui », « taille : 180cm »)
– données textuelles semi structurées (texte divisé en section « motif », « conclusion», « résultat » etc.)
– données textuelles non structurées (comptes rendus au format Word, PDF, ASCII, HTML) Au sein d’un même logiciel, tous ces formats peuvent coexister.
Réutiliser ces données nécessite de pouvoir y accéder rapidement sans compromettre le logiciel de production. L’entrepôt de données biomédical permet de répondre à cette problématique en colligeant toutes les données en une seule base de données par la copie régulière du contenu des bases de production de soins. Il existe autant d’entrepôts de données qu’il y a de cas d’usage de celui-ci. Il s’agit donc de proposer un entrepôt de données qui réponde à notre vision de la réutilisation des données de soins. Nous avons déjà évoqué précédemment la nécessité de privilégier la relation médecin patient au cœur du système d’information hospitalier. Pour cela, l’entrepôt de données doit intégrer et gérer les données textuelles. Cela implique des outils adaptés et cela va impacter la structure et les fonctionnalités de l’entrepôt de données. Nous avons considéré trois cas d’usage de cet entrepôt de données :
– La recherche de patients
– La fouille de données
– L’aide au diagnostic
Sélection d’entrepôts de données
Nous avons réalisé un état de l’art par l’analyse de 16 entrepôts de données publiés. Nous les avons sélectionnés par une recherche sur PubMed. Les critères de sélection sont:
– il doit contenir des données cliniques de patients. Nous avons exclu les entrepôts de données documentaires
– il doit proposer une solution originale. Nous avons exclu les entrepôts de données qui réutilisaient un modèle existant (par exemple i2b2).
– la publication de référence doit donner suffisamment d’information sur les aspects techniques de l’entrepôt de données. Les entrepôts de données retenus sont :
– CATCH/IT (Berndt et al., 1998) développé par le College of Public Health University of South Florida
– Data-Warehouse-Concept for Clinical and Biological Information (Brammen et al., 2005) développé par le CHU de Giessen en Allemagne
– I2B2 (Murphy et al., 2006) développé par Harvard medical school / MIT
– EMERSE (Hanauer, 2006) développé par le Michigan medical school
– Radbank (Rubin and Desser, 2008) développé par le Stanford Medical Informatics
– STRIDE (Lowe et al., 2009) développé par l’université de Stanford
– Enterprise Data Trust at Mayo Clinic (Chute et al., 2010) développé par la Mayo Clinic
– NC CATCH (Studnicki et al., 2010) développé par l’université de Caroline du Nord
– DW4TR (Hu et al., 2011) développé par Windber Research Institute (USA)
– ERS Kyoto (Yamamoto et al., 2012) développé par Department of Clinical Trial Design and Management, Translational Research Centre, Kyoto University Hospital, Kyoto, Japan
– VANDERBILT DWH (Danciu et al., 2014) développé par Vanderbilt Institute for Clinical and Translational Research
– Archetype-based DWH (Marco-Ruiz et al., 2015) développé par Norwegian Centre for Integrated Care and Telemedicine, University Hospital of North Norway, Norway
– METEOR (Puppala et al., 2015) par le Houston Methodist Hospital Research Institute
– Starmaker (Krasowski et al., 2015) développé par University of Iowa Hospitals and Clinics
– Consore (Heudel et al., 2016) par Sword (France)
– SMEYEDAT (Kortüm et al., 2017) par University Eye Hospital, LudwigMaximilians University Munich, Munich, Germany.
|
Table des matières
1. Introduction
2. Etat de l’art
2.1. Sélection d’entrepôts de données
2.2. Les modèles de données
2.2.1. Les types de modèle
2.2.2. Le modèle des entrepôts de données biomédicaux
2.3. Les types de données intégrés
2.4. Les fonctionnalités des entrepôts de données
2.5. Les méthodes de traitement automatique du langage dans l’intégration des données textuelles
2.6. Les objectifs
3. Méthodes
3.1. Un modèle d’entrepôt de données orienté document
3.1.1. Pourquoi créer un nouveau modèle ?
3.1.2. Le modèle de données
3.2. La recherche d’information
3.2.1. Les critères de recherche
3.2.2. Prise en compte de la négation et des antécédents familiaux
3.2.3. Enrichissement terminologique
3.3. Phénotypage haut débit
3.4. Similarité entre patients
5. Résultats
5.1. L’entrepôt de données de l’hôpital Necker Enfants Malades
5.2. Dr Warehouse – le logiciel
6. Discussion
7. Conclusion
Bibliographie
Annexe 1 : Schéma simplifié du modèle de données de Dr Warehouse
Annexe 2
Télécharger le rapport complet
