Considérations sur l’utilisation pour l’ingestion des données DICOM dans les solutions de données de santé (version préliminaire)
[Cet article fait partie de la documentation en version préliminaire et peut faire l’objet de modifications.]
Cet article décrit les principales considérations à prendre en compte avant d’utiliser la fonctionnalité d’ingestion 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é (version préliminaire). 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 préliminaire de la fonctionnalité d’ingestion 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 d’ingestion 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 préliminaire de la fonctionnalité d’ingestion 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é, accédez à 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é d’ingestion 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 des 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 des 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é d’ingestion 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 or diffère 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, l’API génère un nouvel ID dans la lakehouse or OMOP et établit un mappage entre ce nouvel ID et l’ID d’origine dans la lakehouse argent. L’enregistrement est ensuite inséré 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). Les enregistrements sont ensuite mis à jour dans la lakehouse or sous le même ID précédemment généré par l’API OMOP.
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é d’ingestion 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 encore en charge les événements Supprimer. Si vous supprimez une étude, une série ou une instance dans le service DICOM, la fonctionnalité d’ingestion des données DICOM ne reflète pas cette modification. Les données d’imagerie restent inchangées et ne sont pas supprimées.
Utiliser l’explorateur de fichiers OneLake
L’application Explorateur de fichiers OneLake intègre de manière transparente OneLake à l’explorateur de fichiers Windows. Vous pouvez utiliser l’explorateur de fichiers OneLake pour afficher n’importe quel dossier ou fichier déployé dans votre espace de travail Fabric. Vous pouvez également voir les exemples de données, les fichiers et dossiers OneLake et les fichiers du point de contrôle.
Utiliser l’Explorateur de stockage Azure
Vous pouvez également utiliser l’Explorateur de stockage Azure pour :
- Accéder aux fichiers OneLake dans vos lakehouses Fabric
- Vous connecter au chemin de votre fichier d’URL OneLake