Considérations sur l’utilisation pour transformation des données DICOM dans les solutions de données de santé
Note
Ce contenu est en cours de mise à jour.
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
Pour la version actuelle de la fonctionnalité transformation des données DICOM, il existe une limite de taille logique de 3 Go pour les fichiers ZIP et jusqu’à 600 Mo 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 3 Go) pour garantir une exécution réussie. Pour les fichiers DCM natifs de plus de 600 Mo, assurez-vous d’augmenter les nœuds Spark (exécuteurs) selon vos besoins.
Extraction de balises DICOM
Nous accordons la priorité à la promotion des 30 balises présentes dans la table delta dicomimagingmetastore de la lakehouse bronze pour les deux raisons suivantes :
- Ces 30 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. Toutefois, les notebooks transformation des données DICOM ne reconnaissent ni ne traitent automatiquement les autres colonnes des balises DICOM que vous ajoutez à la table delta dicomimagingmetastore dans la lakehouse bronze. 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 dicomimagingmetastore dans la lakehouse bronze. Pour chaque fichier DCM ingéré avec succès, nous créons une nouvelle entrée d’enregistrement dans la table delta dicomimagingmetastore. 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 dicomimagingmetastore 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 dicomimagingmetastore pour le même fichier. Cependant, les noms de fichiers sont différents en raison de l’horodatage du préfixe Unix. En fonction de la date d’ingestion, le fichier peut être placé dans un autre dossier 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 et est 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 via 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 la lakehouse bronze 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 dicomimagingmetastore dans la lakehouse bronze. |
| Ingérer les données dans la table delta ImagingStudy de la lakehouse bronze | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
Fichiers FHIR NDJSON dans la lakehouse bronze 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 sont appliqués lorsque vous ingérez de nouveaux enregistrements de la table delta dicomimagingmetastore dans la lakehouse bronze vers la table delta ImagingStudy dans la lakehouse bronze. La fonctionnalité transformation des données DICOM regroupe tous les enregistrements au niveau de l’instance dans la table delta dicomimagingmetastore 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 basées sur {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.
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. Toutefois, si vous ingérez ultérieurement d’autres fichiers DCM (d’un lot différent) appartenant à la même étude DICOM précédemment ingérée dans la lakehouse argent, l’ingestion génère une opération Insert. Le processus n’effectue pas d’opération Update.
Cette opération Insert se produit car le notebook crée un nouveau {FHIRResource}.id pour ImagingStudy à chaque exécution par lots. 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. À la place, vous pouvez utiliser d’autres ID tels que [studyinstanceuid (0020,000D)] et [patientid (0010,0020)] pour fusionner les enregistrements.
Approche de suivi OMOP
Le notebook healthcare#_msft_silver_omop utilise l’API OMOP pour surveiller les modifications apportées à la table delta de la lakehouse argent. 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 or sont remplies à l’aide des données de vocabulaire incluses dans le déploiement des exemples de données cliniques. Le jeu de données de vocabulaire dans ce dossier est géré à l’aide du Streaming structuré dans Spark.
Vous pouvez localiser les exemples de données de vocabulaire dans le chemin suivant :
healthcare#.HealthDataManager\DMHSampleData\healthcare-sampledata\msft_dmh_omop_vocab_data
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 OMOP utilisée par le notebook healthcare#_msft_silver_omop crée de nouveaux ID pour chaque entrée dans les tables delta de la lakehouse or. 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.
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. Cela signifie que vous pouvez créer de nouvelles études, séries et instances d’imagerie, ou même mettre à jour celles existantes. Cependant, l’intégration ne prend pas en charge les événements Supprimer encore. 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.