Consideraciones de uso de la transformación de datos DICOM en soluciones de datos de atención sanitaria
Nota
Este contenido se está actualizando actualmente.
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
Para la versión actual de la funcionalidad de transformación de datos DICOM, hay un límite de tamaño lógico de 3 GB para archivos ZIP y de hasta 600 MB 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 3 GB) para garantizar una ejecución correcta. En el caso de los archivos DCM nativos de más de 600 MB, asegúrese de escalar verticalmente los nodos de Spark (ejecutores) según sea necesario.
Extracción de etiquetas DICOM
Priorizamos la promoción de las 30 etiquetas presentes en la tabla delta dicomimagingmetastore del almacén de lago bronce por las siguientes dos razones:
- Estas 30 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 se agregue a la tabla delta dicomimagingmetastore en el almacén de lago bronce. 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 anexan a la tabla delta dicomimagingmetastore en el almacén de lago bronce. Por cada archivo DCM ingerido correctamente, creamos una nueva entrada de registro en la tabla delta dicomimagingmetastore. 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 dicomimagingmetastore refleja todos los archivos DCM ingeridos en el nivel de instancia DICOM y debe considerarse como tal. Si el mismo archivo DCM se ingiere de nuevo en la carpeta Ingesta , agregamos otra entrada a la tabla delta dicomimagingmetastore para el mismo archivo. Sin embargo, los nombres de archivo son diferentes debido a la marca de tiempo del prefijo Unix. En función de la fecha de la ingesta, el archivo puede colocarse en una carpeta yyyy/mm/dd diferente.
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 de imágenes, y se publicó 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 garantías de tolerancia a fallos de un extremo a otro 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 el almacén de lago bronce bajo Files\Process\Imaging\DICOM\yyyy\mm\dd. |
| Convertir metadatos DICOM al formato FHIR | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Tabla delta dicomimagingmetastore en el almacén de lago bronce. |
| Ingerir datos en la tabla delta de ImagingStudy del almacén de lago bronce | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
Archivos NDJSON FHIR en el almacén de lago bronce bajo 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 ingiere nuevos registros de la tabla delta dicomimagingmetastore del almacén de lago bronce a la tabla delta ImagingStudy del almacén de lago bronce. La capacidad de transformación de datos DICOM agrupa todos los registros de nivel de instancia de la tabla delta dicomimagingmetastore por el 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 FHIR entre los almacenes de lago bronce y plata en función del {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.
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 más adelante ingiere más archivos DCM (de un lote diferente) que pertenecen al mismo estudio DICOM ingerido previamente en el almacén de lago plata, la ingesta da como resultado una operación Insert. El proceso no realiza una operación Update.
Esta operación Insert 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 usar otros id., como [studyinstanceuid (0020,000D)] y [patientid (0010,0020)] para combinar los registros.
Enfoque de seguimiento OMOP
El cuaderno healthcare#_msft_silver_omop usa la API de OMOP para supervisar los cambios en la tabla delta del almacén de lago plata. 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 oro se rellenan con los datos de vocabulario incluidos en la implementación de datos de ejemplo clínicos. El conjunto de datos de vocabulario de esta carpeta se administra mediante Streaming estructurado en Spark.
Puede localizar los datos de ejemplo de vocabulario en la siguiente ruta:
healthcare#.HealthDataManager\DMHSampleData\healthcare-sampledata\msft_dmh_omop_vocab_data
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 API de OMOP utilizada por el cuaderno healthcare#_msft_silver_omop crea nuevos id. para cada entrada en las tablas delta del almacén de lago oro. 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.
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. Esto significa que puede crear nuevos estudios, series e instancias de imágenes, o incluso actualizar los existentes. Sin embargo, la integración aún no admite eventos Eliminar. 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.