Fermer

janvier 8, 2019

Intégration des données: Apprivoiser la bête des soins de santé – Partie 38 minutes de lecture

Participants à Data Lake - Rôles et responsabilités


Je l’ai déjà dit et je le répète… il est extrêmement difficile d’intégrer les données d’un ou de plusieurs systèmes de DME dans une base de données cohérente d’entrepôts analytiques. Surtout si vous le faites à partir de zéro.

Dans mes deux derniers blogs ( Intégration des données: maîtriser la bête des soins de santé et Intégration des données: maîtriser la bête des soins de santé – Partie 2), j'ai montré comment réduisez les délais et les coûts en extrayant les données de vos systèmes de DME et en les intégrant dans votre entrepôt prêtes pour des analyses et des rapports complexes via l'utilisation d '«accélérateurs» prédéfinis

Avant qu'une entreprise puisse créer un entrepôt de données, elle a besoin être une raison de le faire. En informatique, nous appelons parfois cela "les exigences de l’entreprise".

Voici comment cela fonctionne.

Quelqu'un dans un établissement de soins de santé s'adresse à la TI et dit: "Nous avons besoin d’une série de rapports pour rendre compte au gouvernement et mieux gérer nos procédures. De plus, nous aimerions analyser nos données sur les patients et nos données financières pour voir si nous pouvons fournir un meilleur service à nos patients à moindre coût. Nous en avons besoin tout de suite et nous ne voulons pas que cela coûte beaucoup d'argent. "

Vous travaillez avec eux pour dresser la liste des rapports qu'ils souhaitent et les résultats de type d'analyse recherchés.

Dans ce cas, votre personnel technique examine les systèmes de DME existants pour identifier les champs de données qui répondent aux exigences et déterminer la portée du projet. Pour commencer, vous avez besoin de Patient, Rencontre, Compte, Procédure, Diagnostic, Organisation, Emplacement, Revendications, Ordonnances de médication et de médication, Ordres de laboratoire, Résultats de recherche et autres éléments.

C'est quelque part dans le voisinage de 15 systèmes ou plus. , 353+ tables sources et 2933+ colonnes. Vous devrez concevoir une base de données, créer des centaines de programmes, tester et vérifier les données, etc. (un ensemble de chiffres totalement fictif et ridiculement dépourvu de sens, mais j’essaie d’illustrer qu’il s’agit d’un travail fastidieux). Vous réalisez soudainement que vous allez avoir besoin d’aide ou que cela prendra une éternité et coûtera des millions de dollars.

Pour rendre les choses plus compliquées, les systèmes opérationnels stockent et traitent des données dans un même état. Cela signifie qu'un système axé sur les rencontres enregistre les rencontres avec les patients associés, les diagnostics, les procédures et les ordres cliniques à l'appui, ainsi que les données de résultats cliniques, tous conçus de manière mélangée. Cela facilite le stockage et la mise à jour des données de transaction.

Mais un entrepôt ne peut pas être centré sur la transaction. La conception des données doit être hautement normalisée pour réduire les données redondantes. Etant donné que les données doivent également être réparties sur de longues périodes pour détecter les tendances et rechercher des modèles de traitement et de résultat, l'entrepôt doit stocker des milliards d'enregistrements pour obtenir des résultats d'analyse significatifs. Cela nécessite un schéma de stockage différent. Ceci est mieux servi avec une conception de schéma en étoile dimensionnelle (comme décrit dans la partie 2). Mais vous devrez réorganiser les données avant de pouvoir les charger dans une structure dimensionnelle.

Pour charger l’entrepôt, nous devons donc séparer les transactions source et les données par sujet (patient, organisation, etc.). Rencontre, etc.) Base de données Atomic.

La base de données Atomic est une 3ème forme normale hautement normalisée (pardon, il s'agit de la terminologie du modèle relationnel). Elle s'assure qu'elle est ré-liée ensemble pour s'assurer que vous l'avez correctement stockée.

Note : Il s'agit d'un facteur clé dans la conception de la passerelle d'admission, dernière pièce du portail Perficient Analytics pour les soins de santé.

Luck you! Vous lisez mon blog (les trois parties) et vous savez qui appeler! Mais vous êtes sceptique. Cela peut-il être vrai? Ainsi, vous rejoignez plusieurs organisations de soins de santé qui vous disent toutes la même chose… appelez Perficient!

Lorsque nous aurons l'appel, nous vous dirons ce que nous avons.

Dans cette illustration, vous pouvez voir

  1. La ​​passerelle d'analyse de données insuffisantes – pour les soins de santé, une ensemble de processus prédéfinis permettant de construire et de charger votre entrepôt en beaucoup moins de temps.
  2. Un modèle de données unifié conforme aux normes de l'industrie (celui avec lequel nous avons créé notre produit).
  3. Des processus presque clés en main pour déplacez les données de base à étape puis de base atomique à base de données dimensionnelle prête pour l'analyse et la génération de rapports.

Ce qui en fait un processus normalisé, est son alignement sur la base de données Atomic du modèle de données unifié. La stabilité de la structure Satellite et Data Vault Hub (décrite dans la partie 2) nous a permis de concevoir des tables de base de données Pre-Stage utilisant un format d'entrée standard (pour ceux d'entre vous qui ne peuvent pas vivre sans acronymes, nous les appellerons ainsi: SIF) qui a les mêmes colonnes que l’Atomic. Un type pour une combinaison concentrateur / satellite et un autre pour les relations, etc. Nous en avons quelques autres, mais vous obtenez l'image.

Nous utilisons le fichier SIF pour stocker les données source dans des limites orientées sujet, en maintenant des relations avec tous les concentrateurs associés. aligner tout avec le modèle atomique. Cela rend la programmation d'ingestion facile et réutilisable. Il fournit également un mécanisme de filtrage et de transformation des colonnes source en vue du traitement de l'entrepôt.

La partie «Passage d'admission» de Perficient Analytics Gateway – for Healthcare is;

  1. est utilisée pour extraire des données de vos sources dans l'admission ». SIF ”. Ceci est conçu pour accepter les données de tout système.
  2. Traite et stocke les enregistrements SIF dans la base de données Pre-Stage
  3. Il aide à filtrer les doublons, à nettoyer, valider, reformater, etc. les données entrantes pour le chargement final dans le fichier.
  4. Processus ETL pour déplacer les données de Pre-Stage à Atomic.
  5. Normalisez les formats de date, éliminez les données parasites, validez les codes et consolidez les entrées similaires de multiples systèmes.

Le flux de données de base est illustré ci-dessous. de source en SIF.

Pour que tout fonctionne bien, nous créons des documents de mappage avec les informations appropriées pour piloter un processus de génération de code mécanique qui crée la programmation ETL et ELT nécessaire pour charger correctement les tables SIF. Les autres programmes ETL prédéfinis font le reste.

Le format des données de toutes les colonnes des tableaux SIF est un caractère variable (avec quelques exceptions mineures) de longueur maximale, quelle que soit la longueur ou la valeur système pour un champ donné, il sera accepté. Les types de données de champ de magasin sont ensuite utilisés pour guider les programmes pour les types de données sortants à faire correspondre.

Comme le modèle d’entrepôt change rarement, la programmation permettant de déplacer les données de SIF (pré-étape) à Atomic fonctionne la plupart du temps avec peu ou pas de modification.

C’est un gain de temps considérable, comme indiqué ci-dessous.

Bien sûr, j’ai simplifié les choses pour les maintenir courtes.

Il va sans dire que l’équipe de BI de Perficient, ses connaissances du système source et l'expérience, les composants de la passerelle et du modèle de données ne sont pas bon marché. Cependant, par rapport à ce que vous faites vous-même à partir de rien, il est considérablement plus rapide, plus propre et moins cher que vous ne le pensez.

Appelez-nous!



Source link

0 Partages