Partager via

Utiliser les jeux de données de santé – Transformation (version préliminaire) dans les solutions de données de santé

  • Article

[Cet article fait partie de la documentation en version préliminaire et peut faire l’objet de modifications.]

Cette section fournit des conseils sur la façon d’ingérer, de transformer et d’unifier les ensembles de données SDOH (déterminants sociaux de la santé) à l’aide des jeux de données SDOH – Transformations (préversion) dans les solutions de données de santé.

Une fois que vous avez terminé les étapes de la section Préparer les jeux de données publics dans Jeux de données SDOH – Transformations (version préliminaire), les jeux de données SDOH sont prêts pour l’ingestion. Considérez aussi les exigences suivantes :

  1. Assurez-vous qu’aucun fichier n’est ouvert localement pour éviter le chargement de copies temporaires de fichiers.
  2. L’étiquette de confidentialité des fichiers doit être définie sur Général ou Public.

Pour commencer le processus ingestion :

  1. Dans votre environnement de solutions de données de santé, ouvrir pipeline de données healthcare#_msft_sdoh_ingestion.

  2. Cliquer sur le bouton Exécuter.

Une fois l’exécution réussie, vos jeux de données SDOH sont prêtes à être utilisées dans les charges de travail d’analyse.

Comprendre le mécanisme d’ingestion

L’exécution de bout en bout de cette fonctionnalité implique les étapes consécutives de haut niveau suivantes :

  1. Ingérez les jeux de données SDOH de OneLake dans le dossier Ingérer .
  2. Déplacez les jeux de données SDOH du dossier Ingestion vers Processus.
  3. Convertissez les jeux de données SDOH en tables delta dédiées dans la maison du lac en bronze.
  4. Ingérez et convertissez les tables delta bronze en tables en un modèle de données inspiré de l’industrie (IDM) dans la maison du lac d’argent.

Ingérer des jeux de données SDOH à partir de OneLake

L’exécution commence une fois que vous avez téléchargé les jeux de données SDOH dans le dossier Ingérer. Le pipeline d’exécution déplace les fichiers vers le dossier Processus organisé dans la maison du lac de bronze à l’étape suivante. En cas d’échec, le pipeline déplace les fichiers vers le dossier Échec .

Pour en savoir plus sur ces dossiers et le mouvement des fichiers entre eux, voir Description des dossiers.

Déplacer les jeux de données SDOH

Le bloc-notes raw_process_movement déplace les fichiers vers le dossier Processus organisé dans la maison du lac en bronze. La structure du sous-dossier est la suivante : Files\Process\SDOH\<file format>\<publisher name>\<dataset-specific folders.

Les fichiers traités sont stockés dans leurs sous-dossiers respectifs, avec l’horodatage d’ingestion ajouté au début du nom du fichier.

Convertir des jeux de données SDOH en tables delta

Une fois les fichiers déplacés vers le dossier Processus , le bloc-notes healthcare#_msft_bronze_ingestion remplit les tables de métadonnées, de mise en page et de données dans la maison du lac de bronze au format de table delta. Les informations de disposition sont renseignées dans la table SD_Layout, les informations de métadonnées sont renseignées dans SD_Metadata table et les données sont renseignées dans les tables de données individuelles générées au moment de l’exécution. Les tables de données sont précédées SD_ du nom de la feuille ou du fichier et contiennent le nom de la feuille ou du fichier. Toutes les feuilles de données de chaque jeu de données conservent leur structure de table. Vous pouvez comparer la fiche technique d’origine avec le tableau delta bronze correspondant pour comprendre la variation.

Convertir les tables delta en modèle de données Silver

Après une ingestion réussie du bronze, le notebook healthcare#_msft_bronze_silver_ingestion permet de définir un modèle de données personnalisé dans la maison du lac d’argent. Ce Bloc-notes :

  • Normalise les données dans la maison de bronze tout en préservant le contexte des tables correspondantes, ce qui vous permet d’identifier ou d’interroger les données dans le contexte source.
  • Crée des tables dédiées dans la Silver Lakehouse pour chacun des contextes source.

Voici les principales tables silver lakehouse :

  • SocialDeterminant : contient les points de données réels pour chaque déterminant social et les détails de l’emplacement tels qu’ils sont entrés dans la feuille de configuration de l’emplacement .
  • SocialDeterminantCategory : contient la catégorie de points de données pour chaque déterminant social.
  • SocialDeterminantSubCategory : contient la sous-catégorie de points de données pour chaque déterminant social.
  • UnitOfMeasure (table IDM) : contient les détails de l’unité de mesure.
  • SocialDeterminantDataSetMetadata : contient des informations sur le jeu de données, telles que le nom du jeu de données, l’éditeur et la date de publication.

Vous pouvez comparer les tables de lac delta bronze avec leurs représentations de lakehouse argentées correspondantes pour comprendre la transformation du modèle de données personnalisé. La structure et l’organisation des tables de modèle de données personnalisées diffèrent de celles des tables FHIR classiques.

Exemple : Analyser l’impact de l’environnement alimentaire et des conditions socio-économiques sur le diabète

Prenons l’exemple d’un scénario où nous essayons de comprendre l’impact de l’environnement alimentaire et des conditions socio-économiques d’un comté sur le nombre de patients diabétiques dans ce comté.

L’environnement alimentaire et le revenu médian des ménages représentent des informations sur le SDOH provenant des ensembles de données publics SDOH récemment ingérés, en particulier l’Atlas de l’environnement alimentaire de l’USDA et les données SDOH de l’AHRQ. Vous pouvez utiliser des champs tels que le nombre de restaurants de restauration rapide, le nombre d’épiceries et le revenu médian des ménages du modèle de données SDOH (table SocialDeterminer) dans la maison du lac d’argent.

SELECT
  SocialDeterminantName,
  SocialDeterminantValue,
  SocialDeterminantDescription,
  parsedJson.CountyName AS CountyName,
  parsedJson.CountyFIPS AS CountyFIPS,
  parsedJson.StateName AS StateName
FROM
  healthcare1_msft_silver.SocialDeterminant sd
LATERAL VIEW json_tuple(sd.LocationJson, 'STATENAME', 'COUNTYNAME', 'COUNTYFIPS') parsedJson AS StateName, CountyName, CountyFIPS) sd
ON sd.CountyFIPS = fip_zip_mapping.STCOUNTYFP
WHERE
  sd.SocialDeterminantName IN ('GROC16', 'FFR16', 'ACS_MEDIAN_HH_INC')
AND sd.SocialDeterminantValue IS NOT NULL

D’autre part, le nombre de patients diabétiques fait référence aux informations cliniques issues du pipeline clinique des solutions de données de santé, qui doivent également être déployées et installées. Vous pouvez ingérer des données cliniques dans ce pipeline ou utiliser les données d’échantillons cliniques fournies. Utilisez des champs tels que l’adresse du patient et l’état du patient pour récupérer les mesures requises.

WITH ExpandedPatients AS (
  SELECT
    p.id_orig,
    address_item.postalCode AS postalCode,
    address_item.state AS state
  FROM
    healthcare1_msft_silver.patient p
    LATERAL VIEW explode(p.address) exploded_address AS address_item
)
SELECT
  fzm.STCOUNTYFP,
  SUM(CASE WHEN c.code.text LIKE '%Asthma%' THEN 1 ELSE 0 END) AS Total_Asthma_Patients,
  SUM(CASE WHEN c.code.text LIKE '%Diabetes%' THEN 1 ELSE 0 END) AS Total_Diabetes_Patients,
  SUM(CASE WHEN c.code.text LIKE '%Hypertension%' THEN 1 ELSE 0 END) AS Total_Hypertension_Patients
FROM
  ExpandedPatients ep
JOIN healthcare1_msft_silver.condition c ON ep.id_orig = c.subject.id_orig
JOIN healthcare1_msft_silver.fips_zip_mapping fzm ON ep.postalCode = fzm.ZIP
GROUP BY
  fzm.STCOUNTYFP

De manière inhérente, il n’y a pas de relation directe entre ces deux ensembles de données. L’élément de liaison est le détail de leur emplacement :

  • Les données sur l’environnement alimentaire sont disponibles au niveau du comté, accessibles en développant la colonne Locationjson dans la table SocialDeterminant et en utilisant le CountyFIPS champ.
  • Les données cliniques contiennent les adresses des patients au format FHIR, à partir desquelles vous pouvez récupérer des informations sur le comté. Si seul le code postal du patient est disponible, vous pouvez le récupérer et créer une table de mappage des codes postaux aux codes FIPS à lier au jeu de données SDOH. Cette table de correspondance est facilement disponible dans les référentiels de données publics.

Une fois les données de localisation préparées, vous pouvez lier les deux ensembles de données pour créer une requête Gold Lakehouse qui affiche tous les points de données nécessaires. Voici un exemple de requête SQL :

FROM
   social_determinants sd
JOIN
   patient_conditions pc
ON
   sd.CountyFIPS = pc.STCOUNTYFP

Vous pouvez maintenant analyser et visualiser le jeu de données final pour déterminer la relation entre le nombre de patients atteints de diabète et la présence de fast-foods. Ainsi, la couche argentée permet une normalisation robuste des données, ce qui vous permet de construire des requêtes et d’obtenir des informations complètes au sein et entre différents ensembles de données.