Considerações de uso para o recurso Transformação de dados DICOM nas soluções de dados de serviços de saúde
Este artigo descreve as principais considerações a serem revisadas antes de usar o recurso Transformação de dados DICOM. A compreensão desses fatores garante uma integração e operação tranquilas em seu ambiente de soluções de dados de serviços de saúde. Esse recurso também ajuda você a navegar com eficiência por alguns possíveis desafios e limitações do recurso.
Tamanho do arquivo de ingestão
Atualmente, There tem um limite de tamanho lógico de 8 GB para arquivos ZIP e até 4 GB para arquivos DCM nativos. Se os seus arquivos excederem esses limites, você poderá ter tempos de execução mais longos ou falha na ingestão. Recomendamos dividir os arquivos ZIP em segmentos menores (menos de 4 GB) para garantir uma execução com êxito. Para arquivos DCM nativos maiores que 4 GB, certifique-se de dimensionar os nós Spark (executores) conforme necessário.
Extração de marcas DICOM
Priorizamos a promoção das 29 tags presentes na tabela delta ImagingDicom de bronze lakehouse pelos dois motivos a seguir:
- Essas 29 marcas são cruciais para consulta geral e exploração de dados DICOM, como modalidade e lateralidade.
- Essas marcas são necessárias para gerar e preencher as tabelas delta prata (FHIR) e ouro (OMOP) nas etapas de execução subsequentes.
Você pode estender e promover outras marcas DICOM de seu interesse. No entanto, os notebooks de transformação de dados DICOM não reconhecem ou processam automaticamente nenhuma outra coluna de tags DICOM que você adiciona à tabela ImagingDicom delta no bronze lakehouse. É necessário processar as colunas extras de forma independente
Padrão de acréscimo no lakehouse bronze
Todos os arquivos DCM (ou ZIP) recém-ingeridos são anexados à tabela delta ImagingDicom no bronze lakehouse. Para cada arquivo DCM ingerido com sucesso, criamos uma nova entrada de registro na tabela delta ImagingDicom . Não há lógica de negócios para operações de mesclagem ou atualização no nível do lakehouse bronze.
A tabela delta ImagingDicom reflete cada arquivo DCM ingerido no nível da 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 arquivos são diferentes devido ao carimbo de data/hora do prefixo Unix. Dependendo da data de ingestão, o arquivo pode ser colocado em uma pasta diferente. YYYY\MM\DD
Extensões de versão e imagens OMOP
A implementação atual do lakehouse ouro é baseada no OMOP (Observational Medical Outcomes Partnership) Common Data Model versão 5.4. OMOP ainda não tem uma extensão normativa para oferecer suporte aos dados de imagem. Portanto, o recurso implementa a extensão proposta em "Desenvolvimento de padronização de dados de imagem para pesquisa observacional baseada em imagem: Extensão do OMOP Common Data Model". 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 Transformação de dados DICOM é limitada à tabela Image_Occurrence no lakehouse ouro.
Streaming estruturado no Spark
O streaming estruturado é um mecanismo de processamento de fluxos escalonável e tolerante a falhas criado no mecanismo Spark SQL. Você pode expressar sua computação de fluxos da mesma forma que expressaria uma computação em lote em dados estáticos. O sistema garante tolerância a falhas de ponta a ponta por meio de pontos de verificação e logs Write-Ahead. Para saber mais sobre streaming estruturado, consulte Guia de programação de streaming estruturado (v3.5.1).
Usamos ForeachBatch para processar os dados incrementais. Esse método aplica operações arbitrárias e grava a lógica na saída de uma consulta de streaming. A consulta é executada nos dados de saída de cada microlote de uma consulta de streaming. No recurso Transformação de dados DICOM, o streaming estruturado é usado nas seguintes etapas de execução:
| Etapa de execução | Local da pasta do ponto de verificação | Objetos rastreados |
|---|---|---|
| Extrair metadados DICOM para o lakehouse bronze | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
Arquivos DCM no bronze lakehouse em Files\Process\Imaging\DICOM\YYYY\MM\DD. |
| Converter metadados DICOM no formato FHIR | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Tabela Delta ImagingDicom em bronze lakehouse. |
| Ingerir dados na tabela delta ImagingStudy do lakehouse bronze | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
Arquivos FHIR NDJSON no bronze lakehouse em Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy. |
| Ingerir dados na tabela delta ImagingStudy do lakehouse prata | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Tabela delta ImagingStudy no lakehouse bronze. |
Dica
Você pode usar o explorador de arquivos do OneLake para exibir o conteúdo dos arquivos e pastas listados na tabela. Para obter mais informações, consulte Usar o explorador de arquivos do OneLake.
Padrão de grupo no lakehouse bronze
Os padrões de grupo são aplicados quando você ingere novos registros da tabela delta ImagingDicom no bronze lakehouse para a tabela delta ImagingStudy no bronze lakehouse. O recurso de transformação de dados DICOM agrupa todos os registros em nível de instância na tabela delta do ImagingDicom pelo nível de estudo. Ele cria um registro por estudo DICOM como um ImagingStudy e, em seguida, insere o registro na tabela delta ImagingStudy no lakehouse bronze.
Padrão de upsert no lakehouse prata
A operação upsert compara as tabelas delta FHIR entre os lakehouses bronze e silver com base em {FHIRResource}.id:
- Se uma correspondência for identificada e o registro do prata será atualizado com o novo registro do bronze.
- Se não houver nenhuma correspondência, o registro do bronze será inserido como um novo registro no lakehouse prata.
Usamos esse padrão para criar recursos na tabela lakehouse ImagingStudy prata.
Limitações de ImagingStudy
A operação upsert funciona conforme o esperado quando você ingere arquivos DCM do mesmo estudo DICOM na mesma execução em lote. No entanto, se posteriormente você ingerir mais arquivos DCM (de um lote diferente) que pertencem ao mesmo estudo DICOM ingerido anteriormente no silver lakehouse, a ingestão resultará em uma operação Inserir . O processo não executa uma operação de Atualização .
Esta operação Inserir ocorre porque o notebook cria um novo {FHIRResource}.id para ImagingStudy em cada execução em lote. Essa nova ID não corresponde às IDs do lote anterior. Como resultado, você verá dois registros de ImagingStudy na tabela prata com valores ImagingStudy.id diferentes. Essas IDs estão relacionados às suas respectivas execuções em lote, mas pertencem ao mesmo estudo DICOM.
Como solução alternativa, conclua as execuções em lote e mescle os dois registros de ImagingStudy no lakehouse prata com base em uma combinação de IDs exclusivas. No entanto, não use ImagingStudy.id para a mesclagem. Em vez disso, você pode usar outros IDs, como [studyInstanceUid (0020,000D)] e [patientId (0010,0020)] para mesclar os registros.
Abordagem de rastreamento OMOP
O notebook healthcare#_msft_omop_silver_gold_transformation usa a OMOP API para monitorar alterações na tabela delta lakehouse de prata. Ele identifica registros recém-modificados ou adicionados que exigem upsert nas tabelas delta do lakehouse ouro. Esse processo é conhecido como Watermarking.
A API OMOP compara os valores de data e hora entre {Silver.FHIRDeltatable.modified_date} e {Gold.OMOPDeltatable.SourceModifiedOn} para determinar os registros incrementais que foram modificados ou adicionados desde a última execução do notebook. No entanto, essa abordagem de rastreamento OMOP nã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:
- concept
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- vocabulary
Essas tabelas delta de ouro são preenchidas usando os dados de vocabulário incluídos na OMOP implantação de dados de amostra. O conjunto de dados de vocabulário nessa pasta é gerenciado usando Streaming estruturado no Spark.
Padrão de upsert no lakehouse ouro
O padrão de upsert no lakehouse ouro é diferente do lakehouse prata. A OMOP API usada pelo healthcare#_msft_omop_silver_gold_transformation notebook cria novos IDs para cada entrada nas tabelas delta do ouro lakehouse. A API cria essas IDs quando ingere ou converte novos registros do lakehouse prata em ouro. A API OMOP também mantém mapeamentos internos entre as IDs recém-criadas e suas IDs internas correspondentes na tabela delta do lakehouse prata.
A API funciona da seguinte forma:
Se converter um registro de uma tabela delta prata em ouro pela primeira vez, ela gerará uma nova ID no lakehouse ouro OMOP e a mapeará para a nova ID original no lakehouse prata. Em seguida, ela insere o registro na tabela delta ouro com a ID recém-gerada.
Se o mesmo registro no lakehouse prata sofrer alguma modificação e for ingerido novamente no lakehouse ouro, a API reconhecerá o registro OMOP existente no lakehouse ouro (usando as informações de mapeamento). Em seguida, atualizará os registros no lakehouse ouro com a mesma ID que gerou antes.
Os mapeamentos entre as IDs recém-geradas (ADRM_ID) no lakehouse ouro e as IDs originais (INTERNAL_ID) para cada tabela delta OMOP são armazenadas em arquivos parquet do OneLake. Você pode localizar os arquivos parquet no seguinte caminho:
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
Você também pode consultar os arquivos parquet em um notebook do Spark para exibir o mapeamento.
Design do ImagingMetastore em prata lakehouse
Um único arquivo DICOM pode conter até 5.000 tags distintas, o que torna ineficiente e trabalhoso mapear e criar campos para todas essas tags no arquivo silver lakehouse. No entanto, manter o acesso ao conjunto completo de tags é essencial para evitar 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 todas as tags DICOM na metadata_string coluna. Essas tags são representadas como pares de chave-valor em um formato JSON em string, permitindo consultas eficientes por meio do endpoint analítico SQL. Essa abordagem está alinhada às práticas padrão para gerenciar dados JSON complexos em todos os campos do silver lakehouse.
Da tabela ImagingDicom no bronze lakehouse para a tabela ImagingMetastore no prata lakehouse, a transformação não realiza nenhum agrupamento. Os recursos são representados no nível da instância em ambas as tabelas. Entretanto, o {FHIRResource}.id está incluído na tabela ImagingMetastore . Este valor permite que você consulte todos os artefatos de nível de instância associados a um estudo específico referenciando seu ID exclusivo.
Integração com o serviço DICOM
A integração atual entre o recurso Transformação de dados DICOM e o serviço DICOM dos Serviços de Dados de Saúde do Azure oferece suporte somente a eventos Criar e Atualizar. Você pode criar novos estudos de imagem, séries e instâncias, ou até mesmo atualizar os existentes. Entretanto, a integração ainda não suporta eventos de exclusão. Se você excluir um estudo, série ou instância no serviço DICOM, o recurso Transformação de dados DICOM não refletirá essa alteração. Os dados de imagem permanecem inalterados e não são excluídos.
Avisos de tabela
Avisos aparecem para todas as tabelas em cada lakehouse onde uma ou mais colunas usam tipos de dados complexos orientados a objetos para representar dados. Nas tabelas ImagingDicom e ImagingMetastore , a metadata_string coluna usa uma estrutura JSON para mapear tags DICOM como pares chave-valor. Este design acomoda a limitação dos endpoints do Fabric SQL, que não oferecem suporte a tipos de dados complexos, como structs, arrays e mapas. Você pode consultar essas colunas como strings usando o endpoint SQL (T-SQL) ou trabalhar com seus tipos nativos (structs, arrays, maps) usando o Spark.
