Considerações de utilização para a transformação de dados DICOM em soluções de dados de cuidados de saúde
Este artigo descreve as principais considerações a rever antes de usar a capacidade de transformação de dados DICOM. A compreensão desses fatores garante uma integração e operação suaves no seu ambiente de soluções de dados de cuidados de saúde. Este recurso também o ajuda a navegar de forma eficaz em alguns potenciais desafios e limitações com a capacidade.
Tamanho do ficheiro de ingestão
Atualmente, há um limite de tamanho lógico de 8 GB para arquivos ZIP e até 4 GB para arquivos DCM nativos. Se os seus ficheiros excederem estes limites, poderá ter tempos de execução mais longos ou uma ingestão falhada. Recomendamos dividir os ficheiros ZIP em segmentos menores (menos de 4 GB) para garantir uma execução bem-sucedida. Para arquivos DCM nativos maiores que 4 GB, certifique-se de dimensionar os nós do Spark (executores) conforme necessário.
Extração de etiquetas DICOM
Priorizamos a promoção das 29 tags presentes na tabela delta bronze lakehouse ImagingDicom pelos dois motivos a seguir:
- Estas 29 etiquetas são cruciais para a consulta geral e exploração de dados DICOM, como modalidade e lateralidade.
- Essas etiquetas são necessárias para gerar e preencher as tabelas delta prata (FHIR) e ouro (OMOP) nas etapas de execução subsequentes.
Pode prolongar e promover outras etiquetas DICOM do seu interesse. No entanto, os blocos de anotações de transformação de dados DICOM não reconhecem ou processam automaticamente quaisquer outras colunas de tags DICOM que você adiciona à tabela delta ImagingDicom na lakehouse bronze. Precisa de processar as colunas adicionais de forma independente.
Anexar padrão no lakehouse de bronze
Todos os arquivos DCM (ou ZIP) recém-ingeridos são anexados à tabela delta ImagingDicom no lakehouse bronze. Para cada arquivo DCM ingerido com êxito, criamos uma nova entrada de registro na tabela delta ImagingDicom . Não há lógica de negócio para operações de fusão ou atualização a nível do lakehouse bronze.
A tabela delta ImagingDicom reflete todos os arquivos DCM ingeridos no nível de instância DICOM e deve ser considerada como tal. Se o mesmo arquivo DCM for ingerido novamente na pasta Ingest , adicionaremos outra entrada à tabela delta ImagingDicom para o mesmo arquivo. No entanto, os nomes dos ficheiros são diferentes devido ao carimbo de data/hora do prefixo Unix. Dependendo da data de ingestão, o arquivo pode ser colocado dentro de uma pasta diferente YYYY\MM\DD .
Extensões de versão e imagem OMOP
A implementação atual do lakehouse ouro é baseada no Observational Medical Outcomes Partnership (OMOP) Common Data Model versão 5.4. OMOP ainda não tem uma extensão normativa para suportar dados de imagem. Assim, a capacidade implementa a extensão proposta em Development of Medical Imaging Data Standardization for Imaging-Based Observational Research: OMOP Common Data Model Extension. Esta extensão é a proposta mais recente no campo da pesquisa em imagem publicada em 5 de fevereiro de 2024. A versão atual do recurso de transformação de dados DICOM está limitada à tabela Image_Occurrence no lakehouse ouro.
Transmissão em fluxo estruturada no Spark
A transmissão em fluxo estruturada é um mecanismo de processamento de fluxo dimensionável e tolerante a falhas construído no mecanismo Spark SQL. Pode expressar o seu cálculo de transmissão em fluxo da mesma forma que expressaria um cálculo em lote em dados estáticos. O sistema garante garantias de tolerância a falhas de ponta a ponta por meio de pontos de verificação e logs de Write-Ahead. Para saber mais sobre transmissão em fluxo estruturada, consulte Guia de programação de transmissão em fluxo estruturada (v3.5.1).
Usamos ForeachBatch para processar os dados incrementais. Este método aplica operações arbitrárias e grava a lógica na saída de uma consulta de transmissão em fluxo. A consulta é executada nos dados de saída de cada microlote de uma consulta de transmissão em fluxo. Na capacidade de transformação de dados DICOM, a transmissão em fluxo estruturada é usada nos seguintes passos de execução:
| Passo de execução | Localização da pasta de ponto de verificação | Objetos monitorizados |
|---|---|---|
| Extrair metadados DICOM para o lakehouse bronze | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
Arquivos DCM no bronze lakehouse abaixo Files\Process\Imaging\DICOM\YYYY\MM\DD. |
| Converter metadados DICOM para o formato FHIR | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Tabela Delta ImagingDicom no bronze lakehouse. |
| Ingerir dados na tabela delta ImagingStudy do lakehouse bronze | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
FHIR NDJSON arquiva no bronze lakehouse abaixo Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy. |
| Ingerir dados na tabela delta ImagingStudy do lakehouse prata | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
ImagingStudy da tabela delta no lakehouse bronze. |
Sugestão
Onde usar o explorador de ficheiros do OneLake para ver o conteúdo dos ficheiros e pastas listados na tabela. Para obter mais informações, consulte Usar o explorador de ficheiros do OneLake.
Agrupar padrão no lakehouse de bronze
Os padrões de grupo aplicam-se quando você ingere novos registros da tabela delta ImagingDicom no bronze lakehouse para a tabela delta ImagingStudy no bronze lakehouse. A capacidade de transformação de dados DICOM agrupa todos os registros de nível de instância na tabela delta ImagingDicom pelo nível do estudo. Cria um registo por estudo DICOM como um ImagingStudy e, em seguida, insere o registo na tabela delta ImagingStudy no lakehouse bronze.
Padrão Upsert no lakehouse prata
A operação upsert compara as tabelas do delta FHIR entre as casas de bronze e prata com base na {FHIRResource}.id:
- Se uma correspondência for identificada, o registo de prata é atualizado com o novo registo de bronze.
- Se não houver nenhuma correspondência identificada, o registo de bronze é inserido como um novo registo no lakehouse de prata.
Usamos esse padrão para criar recursos na tabela lakehouse ImagingStudy prateada.
Limitações de ImagingStudy
A operação upsert funciona como esperado quando ingere ficheiros DCM do mesmo estudo DICOM na mesma execução em lote. No entanto, se você ingerir mais arquivos DCM (de um lote diferente) que pertencem ao mesmo estudo DICOM ingerido anteriormente no lakehouse prata, a ingestão resultará em uma operação Inserir . O processo não executa uma operação de atualização .
Essa operação Inserir ocorre porque o bloco de anotações cria um novo {FHIRResource}.id para ImagingStudy em cada execução em lote. Este novo ID não corresponde aos IDs do lote anterior. Como resultado, vê dois registros ImagingStudy na tabela de prata com valores ImagingStudy.id diferentes. Esses IDs estão relacionados com as respetivas execuções em lote, mas pertencem ao mesmo estudo DICOM.
Como solução alternativa, conclua as execuções em lote e una os dois registos ImagingStudy no lakehouse prata com base numa combinação de IDs exclusivos. No entanto, não use ImagingStudy.id para a união. Em vez disso, você pode usar outras IDs, como [studyInstanceUid (0020,000D)] e [patientId (0010,0020)] para mesclar os registros.
Abordagem de rastreio OMOP
O computador portátil healthcare#_msft_omop_silver_gold_transformation usa a OMOP API para monitorar as alterações na tabela delta lakehouse prateada. Identifica registos recém-modificados ou adicionados que exigem atualização/inserção nas tabelas delta de lakehouse ouro. Este processo é conhecido como Marcas d'água.
A API OMOP compara os valores de data e hora entre {Silver.FHIRDeltatable.modified_date} e {Gold.OMOPDeltatable.SourceModifiedOn} para determinar os registos incrementais que foram modificados ou adicionados desde a última execução do bloco de notas. No entanto, essa abordagem de rastreio OMOPnão se aplica a todas as tabelas delta no lakehouse ouro. As tabelas a seguir não são ingeridas da tabela delta no lakehouse prata:
- conceito
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- vocabulário
Essas tabelas delta douradas são preenchidas usando os dados de vocabulário incluídos na implantação OMOP de dados deexemplo. O conjunto de dados de vocabulário nesta pasta é gerido usando transmissão em fluxo estruturado no Spark.
Padrão Upsert no lakehouse ouro
O padrão upsert no lakehouse ouro é diferente do lakehouse prata. A OMOP API usada pelo computador portátil healthcare#_msft_omop_silver_gold_transformation cria novos IDs para cada entrada nas tabelas delta do lakehouse dourado. A API cria esses IDs quando ingere ou converte novos registos do lakehouse prata para ouro. A API OMOPtambém mantém mapeamentos internos entre os IDs recém-criados e seus IDs internos correspondentes na tabela delta do lakehouse prata.
A IA funciona da seguinte forma:
Se converter um registo de uma tabela delta de prata para ouro pela primeira vez, gera um novo ID no lakehouse ouro do OMOP e o mapeia para o novo ID original no lakehouse de prata. Em seguida, insere o registo na tabela delta de ouro com o ID recém-gerado.
Se o mesmo registo no lakehouse prata sofre alguma modificação e é ingerido novamente no lakehouse de ouro, a API OMOP reconhece o registo existente no lakehouse de ouro (usando as informações de mapeamento). Em seguida, atualiza os registos no lakehouse de ouro com o mesmo ID que gerou antes.
Os mapeamentos entre os IDs (ADRM_ID) recém-gerados no lakehouse de ouro e os IDs originais (INTERNAL_ID) para cada tabela delta OMOP são armazenados em ficheiros parquet do OneLake. Pode localizar os ficheiros parquet no seguinte caminho de ficheiro:
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
Também pode consultar os ficheiros parquet num bloco de notas do Spark para visualizar o mapeamento.
Design ImagingMetastore na lakehouse prateada
Um único arquivo DICOM pode conter até 5.000 tags distintas, tornando ineficiente e intensivo em recursos mapear e criar campos para todas essas tags no lakehouse prateado. No entanto, manter o acesso ao conjunto completo de tags é essencial para evitar a perda de dados e manter a flexibilidade, especialmente se você precisar de tags além das 29 extraídas e representadas no modelo de dados. Para resolver esse problema, a tabela delta lakehouse ImagingMetastore prata armazena metadata_string todas as tags DICOM na coluna. Essas tags são representadas como pares chave-valor em um formato JSON stringified, permitindo consultas eficientes por meio do ponto final de análise SQL. Essa abordagem está alinhada com as práticas padrão para gerenciar dados JSON complexos em todos os campos no lakehouse prata.
Da tabela ImagingDicom na lakehouse bronze à tabela ImagingMetastore na lakehouse prata, a transformação não executa nenhum agrupamento. Os recursos são representados no nível da instância em ambas as tabelas. No entanto, o {FHIRResource}.id está incluído na tabela ImagingMetastore . Esse valor permite que você consulte todos os artefatos de nível de instância associados a um estudo específico, fazendo referência à sua ID exclusiva.
Integração com o serviço DICOM
A integração atual entre a capacidade de transformação de dados DICOM e o serviço ICOM dos Serviços de Dados de Saúde do Azure suporta apenas eventos Create e Update . Você pode criar novos estudos de imagem, séries e instâncias, ou até mesmo atualizar os existentes. No entanto, a integração ainda não suporta eventos Delete . Se eliminar um estudo, série ou instância no serviço DICOM, a capacidade de transformação de dados DICOM não refletirá essa alteração. Os dados de imagem permanecem inalterados e não são eliminados.
Advertências de tabela
Os avisos aparecem para todas as tabelas em cada lakehouse onde uma ou mais colunas usam tipos de dados orientados a objetos complexos para representar dados. Nas tabelas ImagingDicom e ImagingMetastore , a metadata_string coluna usa uma estrutura JSON para mapear marcas DICOM como pares chave-valor. Esse design acomoda a limitação dos pontos de extremidade Fabric SQL, que não suportam tipos de dados complexos, como structs, arrays e mapas. Você pode consultar essas colunas como cadeias de caracteres usando o SQL ponto final (T-SQL) ou trabalhar com seus tipos nativos (structs, arrays, maps) usando o Spark.
