Considérations sur l’utilisation pour transformation des données DICOM dans les solutions de données de santé
Cet article décrit les principales considérations à prendre en compte avant d’utiliser la fonctionnalité transformation des données DICOM. Comprendre ces facteurs garantit une intégration et un fonctionnement fluides dans votre environnement de solutions de données de santé. Cette ressource vous aide également à gérer efficacement certains défis et limitations potentiels liés à cette fonctionnalité.
Taille du fichier d’ingestion
Actuellement, il existe une limite de taille logique de 8 Go pour les fichiers ZIP et jusqu’à 4 Go pour les fichiers DCM natifs. Si vos fichiers dépassent ces limites, des temps d’exécution plus longs ou un échec de l’ingestion risquent de se produire. Nous vous recommandons de diviser les fichiers ZIP en segments plus petits (moins de 4 Go) pour garantir une exécution réussie. Pour les fichiers DCM natifs supérieurs à 4 Go, assurez-vous d’augmenter la taille des nœuds Spark (exécuteurs) selon vos besoins.
Extraction de balises DICOM
Nous accordons la priorité à la promotion des 29 balises présentes dans la table delta bronze lakehouse ImagingDicom pour les deux raisons suivantes :
- Ces 29 balises sont cruciales pour la recherche générale et l’exploration des données DICOM, telles que la modalité et la latéralité.
- Ces balises sont nécessaires pour générer et remplir les tables delta argent (FHIR) et or (OMOP) dans les étapes d’exécution ultérieures.
Vous pouvez étendre et promouvoir d’autres balises DICOM qui vous intéressent. Cependant, les blocs-notes de transformation de données DICOM ne reconnaissent ni ne traitent automatiquement les autres colonnes de balises DICOM que vous ajoutez à la table delta ImagingDicom dans le bronze lakehouse. Vous devez traiter les colonnes supplémentaires de manière indépendante.
Ajouter un modèle dans la lakehouse bronze
Tous les fichiers DCM (ou ZIP) nouvellement ingérés sont ajoutés à la table delta ImagingDicom dans le bronze lakehouse. Pour chaque fichier DCM ingéré avec succès, nous créons une nouvelle entrée d’enregistrement dans la table delta ImagingDicom . Il n’existe aucune logique métier pour les opérations de fusion ou de mise à jour au niveau de la lakehouse bronze.
La table delta ImagingDicom reflète chaque fichier DCM ingéré au niveau de l’instance DICOM et doit être considérée comme telle. Si le même fichier DCM est à nouveau ingéré dans le dossier Ingest , nous ajoutons une autre entrée à la table delta ImagingDicom pour le même fichier. Cependant, les noms de fichiers sont différents en raison de l’horodatage du préfixe Unix. Selon la date d’ingestion, le fichier peut être placé dans un dossier différent. YYYY\MM\DD
Extensions de version et d’imagerie OMOP
La mise en œuvre actuelle de la lakehouse or est basée sur la Version 5.4 de l’Observational Medical Outcomes Partnership (OMOP) Common Data Model. OMOP n’a pas encore d’extension normative pour prendre en charge les données d’imagerie. Par conséquent, la capacité implémente l’extension proposée dans Développement de la standardisation des données d’imagerie médicale pour la recherche observationnelle basée sur l’imagerie : Extension d’OMOP Common Data Model. Cette extension est la proposition la plus récente dans le domaine de la recherche en imagerie publiée le 5 février 2024. La version actuelle de la fonctionnalité transformation des données DICOM est limitée à la table Image_Occurrence dans la lakehouse or.
Streaming structuré dans Spark
Le streaming structuré est un moteur de traitement de flux évolutif et tolérant aux pannes, basé sur le moteur SQL Spark. Vous pouvez exprimer votre calcul en streaming de la même manière que vous exprimeriez un calcul par lots sur des données statiques. Le système garantit une tolérance aux pannes de bout en bout grâce à des points de contrôle et des journaux d’écriture anticipée. Pour en savoir plus sur le streaming structuré, voir Guide de programmation du streaming structuré (v3.5.1).
Nous utilisons ForeachBatch pour traiter les données incrémentielles. Cette méthode applique des opérations arbitraires et écrit la logique sur la sortie d’une requête de streaming. La requête est exécutée sur les données de sortie de chaque micro-lot d’une requête de streaming. Dans la fonctionnalité transformation des données DICOM, le streaming structuré est utilisé dans les étapes d’exécution suivantes :
Étape d’exécution | Emplacement du dossier des points de contrôle | Objets suivis |
---|---|---|
Extraire les métadonnées DICOM dans la lakehouse bronze | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
Fichiers DCM dans le bronze lakehouse sous Files\Process\Imaging\DICOM\YYYY\MM\DD . |
Convertir les métadonnées DICOM au format FHIR | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Table Delta ImagingDicom dans le bronze lakehouse. |
Ingérer les données dans la table delta ImagingStudy de la lakehouse bronze | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
Fichiers FHIR NDJSON dans le bronze lakehouse sous Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy . |
Ingérer les données dans la table delta ImagingStudy de la lakehouse argent | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Table delta ImagingStudy dans la lakehouse bronze. |
Astuce
Vous pouvez utiliser l’Explorateur de fichiers OneLake pour afficher le contenu des fichiers et dossiers répertoriés dans le tableau. Pour plus d’informations, consultez Utiliser l’explorateur de fichiers OneLake.
Modèle de groupe dans la lakehouse bronze
Les modèles de groupe s’appliquent lorsque vous ingérez de nouveaux enregistrements de la table delta ImagingDicom dans le bronze lakehouse vers la table delta ImagingStudy dans le bronze lakehouse. La capacité de transformation des données DICOM regroupe tous les enregistrements au niveau de l’instance dans la table delta ImagingDicom par niveau d’étude. Elle crée un enregistrement par étude DICOM en tant que ImagingStudy, puis insère l’enregistrement dans la table delta ImagingStudy de la lakehouse bronze.
Modèle d’upsert dans la lakehouse argent
L’opération upsert compare les tables delta FHIR entre les lakehouses bronze et argent en fonction de {FHIRResource}.id
:
- Si une correspondance est identifiée, l’enregistrement argent est mis à jour avec le nouvel enregistrement bronze.
- Si aucune correspondance n’est identifiée, l’enregistrement bronze est inséré comme nouvel enregistrement dans la lakehouse argent.
Nous utilisons ce modèle pour créer des ressources dans la table argentée lakehouse ImagingStudy .
Limitations d’ImagingStudy
L’opération upsert fonctionne comme prévu lorsque vous ingérez des fichiers DCM de la même étude DICOM dans la même exécution par lots. Cependant, si vous ingérez ultérieurement davantage de fichiers DCM (à partir d’un lot différent) appartenant à la même étude DICOM précédemment ingérée dans le fichier silver lakehouse, l’ingestion entraîne une opération d’ Insertion . Le processus n’effectue pas d’opération de mise à jour .
Cette opération Insertion se produit parce que le bloc-notes crée un nouveau {FHIRResource}.id
pour ImagingStudy à chaque exécution par lot. Ce nouvel ID ne correspond pas aux ID du lot précédent. Par conséquent, vous voyez deux enregistrements ImagingStudy dans la table Silver avec des valeurs ImagingStudy.id
différentes. Ces ID sont liés à leurs exécutions par lots respectives mais appartiennent à la même étude DICOM.
Pour contourner le problème, terminez les exécutions par lots et fusionnez les deux enregistrements ImagingStudy dans la lakehouse argent en fonction d’une combinaison d’ID uniques. Cependant, n’utilisez pas ImagingStudy.id
pour la fusion. Au lieu de cela, vous pouvez utiliser d’autres identifiants tels que [studyInstanceUid (0020,000D)]
et [patientId (0010,0020)]
pour fusionner les enregistrements.
Approche de suivi OMOP
Le bloc-notes healthcare#_msft_omop_silver_gold_transformation utilise l’API OMOP pour surveiller les modifications dans la table delta argent lakehouse. Il identifie les enregistrements nouvellement modifiés ou ajoutés qui nécessitent une opération upsert dans les tables delta de la lakehouse or. Ce processus est appelé filigranage.
L’API OMOP compare les valeurs de date et d’heure entre {Silver.FHIRDeltatable.modified_date}
et {Gold.OMOPDeltatable.SourceModifiedOn}
pour déterminer les enregistrements incrémentiels qui ont été modifiés ou ajoutés depuis la dernière exécution du notebook. Toutefois, cette approche de suivi OMOP ne s’applique pas à toutes les tables delta dans la lakehouse or. Les tables suivantes ne sont pas ingérées à partir de la table delta dans la lakehouse argent :
- concept
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- vocabulary
Ces tables delta d’or sont remplies à l’aide des données de vocabulaire incluses dans le OMOP déploiement de données d’exemple. Le jeu de données de vocabulaire dans ce dossier est géré à l’aide du Streaming structuré dans Spark.
Modèle d’upsert dans la lakehouse or
Le modèle upsert dans la lakehouse ou est différent de celui de la lakehouse argent. L’API utilisée par le bloc-notes OMOP healthcare#_msft_omop_silver_gold_transformation crée de nouveaux identifiants pour chaque entrée dans les tables delta de l’or lakehouse. L’API crée ces ID lorsqu’elle ingère ou convertit de nouveaux enregistrements de la lakehouse argent à la lakehouse or. L’API OMOP maintient également les mappages internes entre les ID nouvellement créés et leurs ID internes correspondants dans la table delta de la lakehouse argent.
L’API fonctionne comme suit :
Lors de la conversion d’un enregistrement d’une table delta argent vers une table delta or pour la première fois, elle génère un nouvel ID dans la Gold lakehouse OMOP et la mappe à ce nouvel ID dans la lakehouse argent. Elle inséré ensuite l'enregistrement dans la table delta or avec l’ID nouvellement généré.
Si le même enregistrement dans la lakehouse argent subit des modifications et est à nouveau ingéré dans la lakehouse or, l’API OMOP reconnaît l’enregistrement existant dans la lakehouse or (à l’aide des informations de mappage). Il met ensuite à jour les enregistrements dans la maison du lac d’or avec le même ID qu’il a généré auparavant.
Les mappages entre les ID nouvellement générés (ADRM_ID) dans la lakehouse or et les ID d’origine (INTERNAL_ID) pour chaque table delta OMOP sont stockés dans les fichiers parquet OneLake. Vous pouvez localiser les fichiers parquet dans le chemin de fichier suivant :
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
Vous pouvez également interroger les fichiers parquet dans un notebook Spark pour afficher le mappage.
Conception ImagingMetastore en argent lakehouse
Un seul fichier DICOM peut contenir jusqu’à 5 000 balises distinctes, ce qui rend inefficace et gourmand en ressources le mappage et la création de champs pour toutes ces balises dans le fichier argenté lakehouse. Cependant, conserver l’accès à l’ensemble complet des balises est essentiel pour éviter la perte de données et maintenir la flexibilité, en particulier si vous avez besoin de balises au-delà des 29 extraites et représentées dans le modèle de données. Pour résoudre ce problème, la table delta argentée lakehouse ImagingMetastore stocke toutes les balises DICOM dans la metadata_string
colonne. Ces balises sont représentées sous forme de paires clé-valeur dans un format JSON stringifié, permettant une interrogation efficace via les analyses SQL point de terminaison. Cette approche s’aligne sur les pratiques standard de gestion des données JSON complexes dans tous les champs du fichier silver lakehouse.
De la table ImagingDicom dans le bronze lakehouse à la table ImagingMetastore dans le argent lakehouse, la transformation n’effectue aucun regroupement. Les ressources sont représentées au niveau de l’instance dans les deux tables. Cependant, le {FHIRResource}.id
est inclus dans la table ImagingMetastore . Cette valeur vous permet d’interroger tous les artefacts au niveau de l’instance associés à une étude spécifique en référençant son ID unique.
Intégration avec le service DICOM
L’intégration actuelle entre la fonctionnalité transformation des données DICOM et le service DICOM des services de données de santé Azure prend uniquement en charge les événements Créer et Mettre à jour. Vous pouvez créer de nouvelles études d’imagerie, séries et instances, ou même mettre à jour celles existantes. Cependant, l’intégration ne prend pas encore en charge les événements Supprimer. Si vous supprimez une étude, une série ou une instance dans le service DICOM, la fonctionnalité transformation des données DICOM ne reflète pas cette modification. Les données d’imagerie restent inchangées et ne sont pas supprimées.
Avertissements sur les tableaux
Des avertissements s’affichent pour toutes les tables de chaque lakehouse où une ou plusieurs colonnes utilisent des types de données orientés objet complexes pour représenter les données. Dans les tables ImagingDicom et ImagingMetastore , la colonne metadata_string
utilise une structure JSON pour mapper les balises DICOM sous forme de paires clé-valeur. Cette conception prend en compte la limitation des points de terminaison Fabric SQL, qui ne prennent pas en charge les types de données complexes tels que les structures, les tableaux et les cartes. Vous pouvez interroger ces colonnes sous forme de chaînes à l’aide de SQL point de terminaison (T-SQL) ou travailler avec leurs types natifs (structures, tableaux, cartes) à l’aide de Spark.