Consideraciones de uso de la transformación de datos DICOM en soluciones de datos de atención sanitaria
En este artículo se describen las consideraciones clave que se deben revisar antes de usar la funcionalidad de transformación de datos DICOM. Comprender estos factores garantiza una integración y un funcionamiento sin problemas en su entorno de soluciones de datos de atención sanitaria. Este recurso también le ayuda a sortear de manera eficaz algunos posibles desafíos y limitaciones con la capacidad.
Tamaño de archivo de ingesta
Actualmente, hay un límite de tamaño lógico de 8 GB para archivos ZIP y hasta 4 GB para archivos DCM nativos. Si sus archivos superan estos límites, es posible que experimente tiempos de ejecución más largos o una ingesta con error. Se recomienda dividir los archivos ZIP en segmentos más pequeños (menos de 4 GB) para garantizar una ejecución correcta. Para archivos DCM nativos de más de 4 GB, asegúrese de ampliar los nodos Spark (ejecutores) según sea necesario.
Extracción de etiquetas DICOM
Priorizamos la promoción de las 29 etiquetas presentes en la tabla delta de bronce almacén de lago de datos ImagingDicom por las dos razones siguientes:
- Estas 29 etiquetas son cruciales para las consultas generales y la exploración de datos DICOM, como la modalidad y la lateralidad.
- Estas etiquetas son necesarias para generar y rellenar las tablas delta plata (FHIR) y oro (OMOP) en los pasos de ejecución posteriores.
Puede ampliar y promover otras etiquetas DICOM de su interés. Sin embargo, los cuadernos de transformación de datos DICOM no reconocen ni procesan automáticamente ninguna otra columna de etiquetas DICOM que agregue a la tabla delta ImagingDicom en el bronce almacén de lago de datos. Debe procesar las columnas adicionales de manera independiente.
Anexar patrón en el almacén de lago bronce
Todos los archivos DCM (o ZIP) recién ingeridos se agregan a la tabla delta ImagingDicom en el bronce almacén de lago de datos. Por cada archivo DCM ingerido exitosamente, creamos una nueva entrada de registro en la tabla delta ImagingDicom . No hay lógica de negocios para las operaciones de combinación o actualización en el nivel del almacén de lago bronce.
La tabla delta ImagingDicom refleja cada archivo DCM ingerido en el nivel de instancia DICOM y debe considerarse como tal. Si el mismo archivo DCM se ingiere nuevamente en la carpeta Ingest , agregamos otra entrada a la tabla delta ImagingDicom para el mismo archivo. Sin embargo, los nombres de archivo son diferentes debido a la marca de tiempo del prefijo Unix. Dependiendo de la fecha de ingestión, el archivo podría ubicarse dentro de una carpeta diferente. YYYY\MM\DD
Extensiones de versión e imágenes OMOP
La implementación actual del almacén de lago oro se basa en Common Data Model versión 5.4 de Observational Medical Outcomes Partnership (OMOP). OMOP aún no tiene una extensión normativa para admitir datos de imágenes. Por lo tanto, la capacidad implementa la extensión propuesta en Desarrollo de la estandarización de datos de imágenes médicas para la investigación observacional basada en imágenes: extensión del Common Data Model OMOP. Esta extensión es la propuesta más reciente en el campo de la investigación en imágenes publicada el 5 de febrero de 2024. La versión actual de la capacidad de transformación de datos DICOM se limita a la tabla Image_Occurrence en el almacén de lago oro.
Streaming estructurado en Spark
El streaming estructurado es un motor de procesamiento de flujos escalable y tolerante a errores basado en el motor SQL de Spark. Puede expresar el cálculo de streaming de la misma manera que expresaría un cálculo por lotes en datos estáticos. El sistema garantiza tolerancia a fallos de extremo a extremo a través de puntos de control y registros de escritura anticipada. Para obtener más información sobre el streaming estructurado, consulte Guía de programación de streaming estructurado (v3.5.1).
Usamos ForeachBatch para procesar los datos incrementales. Este método aplica operaciones arbitrarias y escribe la lógica en la salida de una consulta de streaming. La consulta se ejecuta en los datos de salida de cada microlote de una consulta de streaming. En la funcionalidad de transformación de datos DICOM, el streaming estructurado se usa en los siguientes pasos de ejecución:
| Paso de ejecución | Ubicación de carpeta de punto de control | Objetos de seguimiento |
|---|---|---|
| Extraer metadatos DICOM en el almacén de lago de bronce | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
Archivos DCM en bronce almacén de lago de datos bajo Files\Process\Imaging\DICOM\YYYY\MM\DD. |
| Convertir metadatos DICOM al formato FHIR | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Tabla delta ImagingDicom en bronce almacén de lago de datos. |
| Ingerir datos en la tabla delta de ImagingStudy del almacén de lago bronce | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
Archivos FHIR NDJSON en el bronce almacén de lago de datos en Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy. |
| Ingerir datos en la tabla delta de ImagingStudy del almacén de lago plata | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Tabla delta ImagingStudy en el almacén de lago bronce. |
Propina
Puede usar el explorador de archivos de OneLake para ver el contenido de los archivos y carpetas enumerados en la tabla. Para obtener más información, consulte Usar el explorador de archivos de OneLake.
Agrupar patrón en el almacén de lago bronce
Los patrones de grupo se aplican cuando se ingieren nuevos registros de la tabla delta ImagingDicom en el bronce almacén de lago de datos a la tabla delta ImagingStudy en el bronce almacén de lago de datos. La capacidad de transformación de datos DICOM agrupa todos los registros de nivel de instancia en la tabla delta ImagingDicom por nivel de estudio. Crea un registro por estudio DICOM como ImagingStudy y, a continuación, inserta el registro en la tabla delta ImagingStudy en el almacén de lago bronce.
Patrón Upsert en el almacén de lago plata
La operación upsert compara las tablas delta de FHIR entre los lagos de bronce y plata en función de {FHIRResource}.id:
- Si se identifica una coincidencia, el registro plata se actualiza con el nuevo registro bronce.
- Si no se identifica ninguna coincidencia, el registro bronce se inserta como un nuevo registro en el almacén de lago plata.
Usamos este patrón para crear recursos en la tabla de plata almacén de lago de datos ImagingStudy .
Limitaciones de ImagingStudy
La operación upsert funciona según lo previsto cuando ingiere archivos DCM del mismo estudio DICOM en la misma ejecución por lotes. Sin embargo, si posteriormente ingiere más archivos DCM (de un lote diferente) que pertenecen al mismo estudio DICOM ingerido previamente en el almacén de lago de datos plateado, la ingestión da como resultado una operación de Insertar . El proceso no realiza una operación de Actualización .
Esta operación de Insertar se produce porque el cuaderno crea un nuevo {FHIRResource}.id para ImagingStudy en cada ejecución por lotes. Este nuevo id. no coincide con los id. del lote anterior. Como resultado, verá dos registros ImagingStudy en la tabla plata con valores ImagingStudy.id diferentes. Estos id. están relacionados con sus respectivas ejecuciones por lotes, pero pertenecen al mismo estudio DICOM.
Como solución alternativa, complete las ejecuciones por lotes y combine los dos registros ImagingStudy en el almacén de lago en función de una combinación de id. únicos. Sin embargo, no use ImagingStudy.id para la combinación. En su lugar, puede utilizar otros identificadores como [studyInstanceUid (0020,000D)] y [patientId (0010,0020)] para fusionar los registros.
Enfoque de seguimiento OMOP
El cuaderno healthcare#_msft_omop_silver_gold_transformation usa la OMOP API para monitorear los cambios en la tabla delta de plata almacén de lago de datos. Identifica los registros recién modificados o agregados que requieren upsert en las tablas delta del almacén de lago oro. Este proceso se conoce como marcas de agua.
La API de OMOP compara los valores de fecha y hora entre {Silver.FHIRDeltatable.modified_date} y {Gold.OMOPDeltatable.SourceModifiedOn} para determinar los registros incrementales que se modificaron o agregaron desde la última ejecución del cuaderno. Sin embargo, este enfoque de seguimiento OMOP no se aplica a todas las tablas delta del almacén de lago oro. Las siguientes tablas no se ingieren desde la tabla delta del almacén de lago plata:
- concepto
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- vocabulario
Estas tablas delta de oro se completan utilizando los datos de vocabulario incluidos en la OMOP implementación de datos de muestra. El conjunto de datos de vocabulario de esta carpeta se administra mediante Streaming estructurado en Spark.
Patrón Upsert en el almacén de lago oro
El patrón upsert en el almacén de lago oro es diferente al del almacén de lago plata. La OMOP API utilizada por el cuaderno healthcare#_msft_omop_silver_gold_transformation crea nuevos ID para cada entrada en las tablas delta del oro almacén de lago de datos. La API crea estos id. cuando ingiere o convierte nuevos registros del almacén de lago plata a oro. La API de OMOP también mantiene asignaciones internas entre los id. recién creados y sus id. internos correspondientes en la tabla delta del almacén de lago plata.
La API funciona de este modo:
Si convierte un registro de una tabla delta plata a oro por primera vez, genera un nuevo id. en el almacén de lago oro OMOP y lo asigna al nuevo id. original en el almacén de lago plata. A continuación, inserta el registro en la tabla delta oro con el id. recién generado.
Si el mismo registro del almacén de lago plata sufre alguna modificación y se ingiere de nuevo en el almacén de lago oro, la API de OMOP reconoce el registro existente en el almacén de lago oro (utilizando la información de asignación). A continuación, actualiza los registros del almacén de lago oro con el mismo id. que generó antes.
Las asignaciones entre los id. recién generados (ADRM_ID) en el almacén de lago oro y los id. originales (INTERNAL_ID) para cada tabla delta OMOP se almacenan en archivos de Parquet de OneLake. Puede localizar los archivos Parquet en la siguiente ruta de archivos:
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
También puede consultar los archivos Parquet en un cuaderno de Spark para ver la asignación.
Diseño de ImagingMetastore en plata almacén de lago de datos
Un solo archivo DICOM puede contener hasta 5000 etiquetas distintas, lo que hace que sea ineficiente y requiera muchos recursos asignar y crear campos para todas estas etiquetas en el archivo silver almacén de lago de datos. Sin embargo, conservar el acceso al conjunto completo de etiquetas es esencial para evitar la pérdida de datos y mantener la flexibilidad, especialmente si necesita etiquetas más allá de las 29 extraídas y representadas en el modelo de datos. Para solucionar este problema, la tabla delta plateada almacén de lago de datos ImagingMetastore almacena todas las etiquetas DICOM en la columna metadata_string . Estas etiquetas se representan como pares clave-valor en un formato JSON en cadena, lo que permite realizar consultas eficientes a través del análisis SQL punto de conexión. Este enfoque se alinea con las prácticas estándar para gestionar datos JSON complejos en todos los campos de la plata almacén de lago de datos.
Desde la tabla ImagingDicom en el bronce almacén de lago de datos a la tabla ImagingMetastore en el plata almacén de lago de datos, la transformación no realiza ninguna agrupación. Los recursos están representados a nivel de instancia en ambas tablas. Sin embargo, el {FHIRResource}.id está incluido en la tabla ImagingMetastore . Este valor le permite consultar todos los artefactos a nivel de instancia asociados con un estudio específico haciendo referencia a su ID único.
Integración con el servicio DICOM
La integración actual entre la capacidad de transformación de datos DICOM y el servicio DICOM de Azure Health Data Services solo admite eventos Crear y Actualizar. Puede crear nuevos estudios de imágenes, series e instancias, o incluso actualizar los existentes. Sin embargo, la integración aún no admite eventos de Eliminación . Si elimina un estudio, una serie o una instancia en el servicio DICOM, la capacidad de transformación de datos DICOM no refleja este cambio. Los datos de imágenes permanecen sin cambios y no se eliminan.
Advertencias sobre la tabla
Aparecen advertencias para todas las tablas en cada almacén de lago de datos donde una o más columnas utilizan tipos de datos orientados a objetos complejos para representar datos. En las tablas ImagingDicom y ImagingMetastore , la columna metadata_string utiliza una estructura JSON para mapear etiquetas DICOM como pares clave-valor. Este diseño se adapta a la limitación de los puntos finales de Fabric SQL, que no admiten tipos de datos complejos como estructuras, matrices y mapas. Puede consultar estas columnas como cadenas usando SQL punto de conexión (T-SQL) o trabajar con sus tipos nativos (estructuras, matrices, mapas) usando Spark.
