Conception et architecture d'un entrepôt de données cliniques

Un entrepôt de données cliniques est un référentiel intégré, orienté requête, qui consolide les données provenant des sources transactionnelles d'un système de santé afin qu'elles puissent être analysées sans perturber les systèmes de soins opérationnels. Sa conception et son architecture déterminent la manière dont les données sources sont extraites, modélisées et exposées pour la recherche, la mesure de la qualité et le reporting opérationnel.

Definition

La conception d'un entrepôt de données cliniques est l'architecture et l'ingénierie de référentiels intégrés qui consolident les données de santé provenant de multiples sources opérationnelles dans une structure optimisée pour l'interrogation, l'analyse et la réutilisation, plutôt que pour les soins transactionnels.

Scope

Ce sujet aborde les modèles architecturaux sous-jacents aux entrepôts de données cliniques : la séparation des systèmes analytiques et transactionnels, les pipelines d'extraction-transformation-chargement (ETL), la modélisation dimensionnelle versus normalisée, et l'utilisation de modèles de données communs pour rendre les requêtes portables. Il traite la conception d'entrepôts comme un sujet d'informatique et d'ingénierie des données, et non comme des instructions opérationnelles pour une plateforme spécifique.

Key concepts

• Séparation des charges de travail analytiques et transactionnelles (OLAP vs OLTP)
• Pipelines d'extraction-transformation-chargement (ETL)
• Modélisation dimensionnelle (schémas en étoile et en flocon)
• Conception d'entrepôt d'entreprise normalisé (troisième forme normale)
• Modèles de données communs
• Data marts
• Métadonnées et lignage des données
• Dimensions à évolution lente

Mechanisms

Les systèmes opérationnels, tels que les dossiers de santé électroniques, sont optimisés pour des transactions individuelles rapides, ce qui les rend peu adaptés aux requêtes analytiques de grande envergure. Un entrepôt de données cliniques y remédie en extrayant périodiquement les données de ces sources, en les transformant et en les nettoyant, puis en les chargeant dans un référentiel distinct structuré pour l'analyse. Deux traditions de conception influentes informent la couche de modélisation : l'approche d'entrepôt d'entreprise normalisé associée à Inmon, et l'approche de schéma en étoile dimensionnel associée à Kimball, qui organise les données en tables de faits et de dimensions pour une agrégation efficace. Dans les contextes de recherche, des plateformes telles qu'i2b2 organisent les données des patients autour d'un schéma en étoile et d'une ontologie contrôlée afin que les chercheurs puissent interroger des cohortes. Le mappage de l'entrepôt à un modèle de données commun permet d'exécuter la même requête dans différentes institutions.

Clinical relevance

L'architecture d'un entrepôt de données cliniques détermine les analyses réalisables et la fiabilité avec laquelle les cohortes peuvent être identifiées, ce qui, à son tour, affecte la mesure de la qualité et la recherche qui éclaire les soins. Comprendre la conception de l'entrepôt aide les utilisateurs à interpréter l'origine des données analytiques et les transformations qu'elles ont subies. Ceci est une description de référence de l'infrastructure et ne fournit pas de conseils cliniques individuels.

History

L'entreposage de données est apparu dans les systèmes d'information généraux à la fin du XXe siècle, le modèle d'entreprise normalisé d'Inmon et le modèle dimensionnel de Kimball encadrant le débat majeur sur la conception. Les soins de santé ont adopté ces modèles à mesure que les dossiers électroniques accumulaient des données réutilisables ; des plateformes orientées recherche telles qu'i2b2 en 2010 ont démontré des architectures d'entrepôts adaptées à la découverte de cohortes cliniques, et les modèles de données communs ont ensuite standardisé l'interrogation interinstitutionnelle.

Debates

Entrepôt d'entreprise normalisé versus modélisation dimensionnelle

Les concepteurs divergent sur la question de savoir s'il faut construire un entrepôt d'entreprise normalisé et intégré (la tradition d'Inmon) à partir duquel les data marts sont dérivés, ou construire directement des data marts dimensionnels en schéma en étoile (la tradition de Kimball) ; ce choix met en balance l'intégration et la flexibilité par rapport à la simplicité et la rapidité des requêtes.

Key figures

• William H. Inmon
• Ralph Kimball
• Shawn N. Murphy
• Isaac Kohane

Seminal works

• inmon-2005
• kimball-ross-2013
• murphy-2010

Frequently asked questions

Pourquoi ne pas exécuter les analyses directement sur la base de données du dossier de santé électronique ?

Les systèmes transactionnels sont optimisés pour de nombreuses petites lectures et écritures qui soutiennent les soins en temps réel, de sorte que les requêtes analytiques de grande envergure peuvent les ralentir et risquer d'affecter les opérations cliniques. Un entrepôt de données sépare l'analyse de la prestation des soins et structure les données pour une interrogation efficace.

Qu'est-ce qu'un modèle de données commun et pourquoi est-il important pour la conception d'un entrepôt ?

Un modèle de données commun est un schéma et un vocabulaire partagés que plusieurs institutions adoptent pour leurs entrepôts. Le mappage à ce modèle permet d'exécuter la même requête analytique sur différents sites sans réécriture, ce qui soutient la recherche multi-institutionnelle et la reproductibilité.