Partage via

Transformation des métadonnées DICOM mappage dans les solutions de données de santé

  • Article

Cet article explique comment l’environnement de solutions de données de santé extrait et transforme les métadonnées DICOM à différents niveaux de la lakehouse. Vous pouvez également en apprendre davantage sur le processus de transformation des métadonnées de bout en bout et comprendre le mappage de transformation à chaque niveau.

La transformation des métadonnées via le pipeline d’ingestion comprend les trois phases consécutives suivantes :

  1. Extraction et transformation des métadonnées DICOM dans la table delta bronze
  2. Transformation des métadonnées de la table delta bronze à la table delta argent
  3. Transformation des métadonnées de la table delta argent à la table delta or

Les sections suivantes détaillent le mappage de transformation pour chaque phase.

Mappage de transformation pour les métadonnées DICOM dans la table delta bronze

Il existe plus de 5 000 balises DICOM définies par la norme DICOM, y compris des balises privées spécifiques au fournisseur. Cette section identifie quelles balises nous récupérons et explique le processus d’extraction dans la lakehouse bronze.

Le processus d’extraction de balises et de création de table delta ImagingDicom inclut les actions suivantes :

  1. Extraction des fichiers DICOM : extrayez une collection de toutes les balises des fichiers DICOM (DCM) dans la structure de dossiers optimisée de la lakehouse bronze.

  2. Exclusion de la balise de données de pixel : excluez la balise de données de pixel DICOM (7FE0,0010) et les attributs du module de données de pixel d’image de la collection. La balise de données de pixel DICOM inclut des détails au niveau de l’image ou du pixel.

  3. Mappage JSON : mappez toutes les balises DICOM extraites dans une structure JSON de paires de clé-valeur dans le schéma suivant :

    METADATA_JSON_DICT_SCHEMA = MapType
   (
      StringType(),
      StructType([
                   StructField("vr", StringType(), True),
                   StructField("Value", ArrayType(StringType(), True), True)
                 ])
   )

    Ces paires JSON clé-valeur sont écrites dans la colonne métadonnées de la table delta bronze lakehouse ImagingDicom .

    Note

    La colonne metadata_string stocke également les métadonnées sous forme de chaîne, car les points de terminaison Fabric SQL 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.

  4. Extraction et mappage vers bronze lakehouse : extrayez ensuite les 29 balises DICOM suivantes et écrivez-les dans les colonnes de destination respectives de la table delta ImagingDicom  :

    Balise DICOM source Colonne de destination Requise
    (0020,000D) [studyInstanceUid] Oui
    (0010,0010) [patientName] No
    (0010,0040) [patientSex] No
    (0010,0020) [patientId] Oui
    (0010,0030) [patientBirthDate] No
    (0008,0050) [accessionNumber] Oui
    (0008,0090) [referringPhysicianName] Oui
    (0008,0020) [studyDate] Oui
    (0008,1030) [studyDescription] Oui
    (0020,000E) [seriesInstanceUid] Oui
    (0008,0060) [modality] Oui
    (0008,0061) [modalitiesInStudy] Oui
    (0040,0244) [performedProcedureStepStartDate] No
    (0008,1090) [manufacturerModelName] No
    (0008,0018) [sopInstanceUid] Oui
    (0008,0030) [studyTime] Oui
    (0008,0201) [timezoneOffsetFromUtc] Oui
    (0020,1206) [numberOfStudyRelatedSeries] Oui
    (0020,1208) [numberOfStudyRelatedInstances] Oui
    (0020,0011) [seriesNumber] Oui
    (0008,103E) [seriesDescription] Oui
    (0020,1209) [numberOfSeriesRelatedInstances] Oui
    (0018,0015) [bodyPartExamined] Oui
    (0020,0060) [laterality] Oui
    (0008,0021) [seriesDate] Oui
    (0008,0031) [seriesTime] Oui
    (0008,0016) [sopClassUid] Oui
    (0020,0013) [instanceNumber] Oui
    (0042,0010) [documentTitle] Oui

    Note

    • Pour plus d’informations sur les raisons pour lesquelles nous promouvoir ces 29 balises DICOM particulières, voir Extraction de balises DICOM.

    • Pour en savoir plus sur le modèle d’ingestion (ajout), accédez à Ajouter un modèle dans la lakehouse bronze.

    • La colonne modalitiesInStudy_string stocke également la balise modalitiesInStudy sous forme de chaîne, car les points de terminaison Fabric SQL 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.

  5. Stockage du chemin d’accès au fichier DCM : le chemin d’accès complet au fichier DCM est écrit dans la colonne filePath de la table delta ImagingDicom .

  6. Enregistrement de l’heure de modification : l’horodatage le plus récent auquel le fichier DCM a été modifié à sa source est écrit dans la colonne sourceModifiedAt de la table delta ImagingDicom .

  7. Stockage de l’espace de noms : la valeur de l’espace de noms est écrite dans la colonne sourceSystem de la table delta ImagingDicom . Cette valeur dérive du nom du dossier dans la structure de dossier unifiée.

    • Pour une ingestion régulière, la valeur de l’espace de noms est le nom du dossier après Files\Process\Imaging\DICOM.
    • Pour l’ingestion Bring Your Own Storage (BYOS), la valeur de l’espace de noms est le nom du dossier après Files\External\Imaging\DICOM.

  8. Journalisation du temps d’exécution : la date et l’heure d’exécution du bloc-notes sont écrites dans la colonne createdDatetime de la table delta ImagingDicom .

Mappage de transformation de la table delta bronze à la table delta argent

Les tableaux suivants expliquent le couche complet pour la transformation des métadonnées DICOM de la table delta bronze lakehouse ImagingDicom aux tables delta ImagingMetastore et ImagingStudy dans la table argent lakehouse. La table delta ImagingMetastore stocke les balises DICOM pour chaque fichier DCM sous forme de paires clé-valeur JSON dans les colonnes de métadonnées. La copie de toutes les métadonnées du bronze vers l’argent couche préserve l’intégrité des données à travers les couches. La table delta ImagingStudy inclut les 29 balises DICOM sélectionnées pour mappage avec les champs standard FHIR. Il contient également davantage de champs pour prendre en charge le suivi et la lignée des données.

Colonne source dans ImagingDicom Colonne de destination dans ImagingMetastore Détails du mappage
N/A msftModifiedDatetime Inclus via la logique de fusion delta commune appliquée à toutes les tables dans l’argent #glsr_cfhibaz.
studyInstanceUid studyInstanceUid Direct mappage avec une relation individuelle. Chaque valeur de la colonne source correspond directement à une seule valeur correspondante dans la destination.
seriesInstanceUid seriesInstanceUid Direct mappage avec une relation individuelle.
sopInstanceUid sopInstanceUid Direct mappage avec une relation individuelle.
sourceSystem msftSourceSystem Direct mappage avec une relation individuelle.
metadata metadata Direct mappage avec une relation individuelle.
metadata_string metadata_string Direct mappage avec une relation individuelle.
filePath filePath Direct mappage avec une relation individuelle.
sourceModifiedAt sourceModifiedAt Direct mappage avec une relation individuelle.
N/A id Un GUID généré à l’aide du module UUID Python.
N/A msftCreatedDatetime Inclus via la logique de fusion delta commune appliquée à toutes les tables dans l’argent #glsr_cfhibaz.
Colonne source dans ImagingDicom Colonne de destination dans ImagingStudy Détails du mappage
N/A msftModifiedDatetime Inclus via la logique de fusion delta commune appliquée à toutes les tables dans l’argent #glsr_cfhibaz.
N/A id Un GUID généré à l’aide du module UUID Python.
N/A resourceType "ImagingStudy"
sourceSystem msftSourceSystem Pas un mappage direct. La capacité de transformation des données DICOM utilise la colonne sourceSystem dans le bronze lakehouse pour créer le dossier Namespace lors de l’écriture des fichiers NDJSON générés dans le dossier Process . Pour en savoir plus sur le dossier Espace de noms , consultez Structure de dossier unifiée : descriptions de dossiers. À ce stade, le service d’ingestion de bronze clinique utilise le nom du dossier Namespace pour renseigner la colonne msftSourceSystem dans le lakehouse argent.

Par exemple, si la valeur est définie comme dans la table bronze ImagingDicom, le service d’ingestion d’imagerie Bronze écrit les fichiers NDJSON nouvellement créés dans la structure de dossiers suivante :. sourceSystem MyPACSsystem Process\Clinical\FHIR-NDJSON\MyPACSsystem\YYYY\MM\DD\ImagingStudy-<timestamp>.ndjson Lorsque l’ingestion de bronze clinique récupère ces fichiers, elle remplit automatiquement la msftSourceSystem colonne avec MyPACSsystem de la structure du dossier et propage la même valeur à l’argent couche.
N/A msftFilePath Chemin d’accès au fichier ImagingStudy NDJSON généré dans le dossier Process\Clinical\FHIR-NDJSON\DICOM-HDS .
filePath extension "extension": [{"url": "lit('file_path')", "valueUrl": "col('FilePath')"}]

La valeur pour FilePath inclut le chemin du fichier ABFS dans OneLake pour tous les fichiers DCM au niveau de l’instance qui font partie de ce ImagingStudy.
N/A méta "meta": {"lastUpdated":"current_timestamp()"}
studyInstanceUid
accessionNumber		 identifier ImagingStudy.identifier.where(system = 'urn:dicom:uid') =>StudyInstanceUID

ImagingStudy.identifier.where(type.coding.system = 'http://terminology.hl7.org/CodeSystem/v2-0203' et type.coding.code = 'ACSN')) =>"AccessionNumber"
N/A status "available"
modalitiesInStudy modality modality = List{code = col('ModalitiesInStudy')}
patientId subject ""subject"": {""identifier"": {""type"": {""coding"": [{""system"": ""lit('http://terminology.hl7.org/CodeSystem/v2-0203')"",""code"": ""lit('MR')""}]},""value"": ""col('PatientID')""},""type": ""lit('Patient')""},"
patientName
patientBirthDate
patientSex		 subject "subject": {"extension": [{"url": "lit('name')", "valueString": "col('PatientName')"}, {"url": "lit('birthDate')", "valueDateTime": "col('PatientBirthDate')"}, {"url": "lit('gender')", "valueCode": "col('PatientSex')"}]}
studyDate
studyTime
timezoneOffsetFromUtc		 started concat_ws(' ', col('StudyDate'), col('StudyTime'), col('TimezoneOffsetFromUTC'))
numberOfStudyRelatedSeries numberOfSeries col('NumberOfStudyRelatedSeries')
numberOfStudyRelatedInstances numberOfInstances col('NumberOfStudyRelatedInstances')
studyDescription description col('StudyDescription')
seriesInstanceUid
seriesDate
seriesTime
timezoneOffsetFromUtc
modality
laterality
bodyPartExamined
numberOfSeriesRelatedInstances
seriesDescription
seriesNumber
sopInstanceUid
sopClassUid
instanceNumber
documentTitle		 series {"series": [{"uid": "col('SeriesInstanceUID')", "started": {"tag": "SeriesDate,SeriesTime,TimezoneOffsetFromUTC", "calc": "concat_ws(' ', col('SeriesDate'), col('SeriesTime'), col('TimezoneOffsetFromUTC')).cast(TimestampType())"}, "modality": {"code": "col('Modality')", "system": "lit('https://dicom.nema.org/resources/ontology/DCM')"}, "laterality": {"display": "col('Laterality')"}, "bodySite": {"display": "col('BodyPartExamined')"}, "numberOfInstances": "col('NumberOfSeriesRelatedInstances')", "description": "col('SeriesDescription')", "number": "col('SeriesNumber')", "instance": [{"uid": "col('SOPInstanceUID')", "sopClass": {"code": "col('SOPClassUID')"}, "number": "col('InstanceNumber')", "title": "col('DocumentTitle')", "extension": [{"url": "lit('file_path')", "valueUrl": "col('FilePath')"}]}]}]}
N/A meta.lastupdated Currenttimestamp()
N/A msftCreatedDatetime Inclus via la logique de fusion delta commune appliquée à toutes les tables dans l’argent #glsr_cfhibaz.

Note

  • Les colonnes avec le suffixe Orig sont créées dans l’argent lakehouse pour stocker les valeurs originales des champs provenant du bronze couche. Cette pratique standard inclut les colonnes suivantes dans la table ImagingStudy  : meta_lastUpdatedOrig, identifierOrig, idOrig et startedOrig.

  • Les colonnes avec le suffixe _string stockent des versions stringifiées de champs contenant des données JSON complexes, permettant ainsi d’effectuer des requêtes via les analyses SQL point de terminaison. Cette pratique s’applique à toutes les tables du silver lakehouse et inclut les colonnes suivantes dans le tableau ImagingStudy  : meta_string, text_string, contained_string, identifier_string, modality_string, subject_string, encounter_string, basedOn_string, referrer_string, interpreter_string, endpoint_string, procedureReference_string, procedureCode_string, location_string, reasonCode_string, reasonReference_string, note_string, series_string, et identifierOrig_string.

  • Certains champs de la table ImagingStudy sont générés en aligner avec le schéma FHIR ImagingStudy . Cependant, comme le bronze couche n’extrait pas les données des fichiers DCM qui correspondent exactement à ces champs, les colonnes associées dans la table argent restent vides. Par conséquent, les colonnes suivantes dans la table ImagingStudy contiennent des valeurs nulles : implicitRules, language, text, contained, encounter, basedOn, referrer, interpreter, endpoint, procedureReference, procedureCode, location, reasonCode, reasonReference et note.

Mappage de transformation de la table delta argent à la table delta or

Le tableau suivant explique le couche complet pour la transformation des données DICOM dans la table delta argent lakehouse ImagingStudy en table delta Observational Medical Outcomes Partnership (OMOP) Image_Occurrence dans la table delta or lakehouse.

Colonne source dans ImagingStudy Colonne de destination dans OMOP Image_Occurrence Type de données Détails du mappage
series.started image_occurrence_date date Date d’occurrence de la procédure d’imagerie (série).
series.modality (combinaison de series.modality.code et series.modality.system) modality_concept_id chaine concat_ws('<->', exp_series.modality.code, exp_series.modality.system)
N/A SourceTable chaine 'ImagingStudy_FHIR'
id msftSourceRecordId chaine ID généré par le système de l’enregistrement source.
identifier['studyInstanceUid'] image_study_uid chaine Étude DICOM UID.
subject person_id Entier ID de la personne associée à la procédure enregistrée.
Un tableau de valeurs de dictionnaire, où la clé est instance.uid et la valeur est instance.extension[0].valueUrl local_path chaine to_json(transform(exp_series.instance, x -> map('instanceid', x.uid, 'local_path', from_json(x.extension, 'array<struct<valueUrl:string,url:string>>')[0].valueUrl)))
N/A SourceModifiedOn DateHeure Date de modification de l’enregistrement.
resourceType msftSourceTableName chaine 'Imaging Study'
msftModifiedDatetime msftModifiedDatetime DateHeure Direct mappage avec une relation individuelle.
series.uid image_occurrence_id chaine Clé unique fournie à un enregistrement d’étude d’imagerie.
series.modality.code modality_source_value chaine Modalité de la série.

Note

Certains champs de la table Gold génèrent aligner avec le schéma OMOP Image_Occurrence . Cependant, comme le bronze #glsr_cfhibaz n’extrait pas de données correspondant précisément à ces champs, les colonnes associées dans la table or restent vides. Par conséquent, les colonnes suivantes dans la table Image_Occurrence contiennent des valeurs nulles : visit_occurrence_id, procedure_occurrence_id et anatomic_site_concept_id.