Partilhar via

Arquitetura e gestão de dados em soluções de dados de cuidados de saúde no Microsoft Fabric

  • Artigo

A estrutura das soluções de dados de cuidados de saúde usa uma arquitetura especializada de medalhas para simplificar a organização e o processamento de dados. Este design garante a melhoria contínua da qualidade e estrutura dos dados, permitindo-lhe gerir os dados de cuidados de saúde de forma mais eficaz. Este artigo explora as principais funcionalidades e os benefícios desta arquitetura, fornecendo uma descrição geral abrangente da forma como os dados são geridos nessa estrutura.

Design de lakehouse de medalhas

Conforme explicado na arquitetura da solução, as soluções de dados de cuidados de saúde usam a arquitetura de lakehouse de medalhas para organizar e processar os dados em várias camadas. À medida que os dados se movem através de cada camada, a sua estrutura e qualidade são melhoradas continuamente. Basicamente, o design de lakehouse de medalhas em soluções de dados de cuidados de saúde consiste nos seguintes lakehouses principais:

  • Lakehouse de bronze: Também denominado zona não processada, o lakehouse de bronze é a primeira camada que organiza os dados de origem no seu formato de ficheiro original. Ingere ficheiros de origem no OneLake e/ou cria atalhos a partir de origens de armazenamento nativas. Também armazena dados estruturados e semiestruturados a partir da origem em tabelas delta, também conhecidas como tabelas de teste. Estas tabelas são comprimidas e indexadas por colunas para suportar transformações e processamento de dados eficientes. Os dados nesta camada normalmente são apenas de acréscimo e imutáveis.

    Os ficheiros no lakehouse de bronze (sejam persistentes ou atalhos) servem como origem da verdade. Estabelecem a base para a linhagem de dados em todo o património de dados em soluções de dados de cuidados de saúde. As tabelas de teste na camada de bronze geralmente consistem em algumas colunas e são concebidas para manter cada modalidade e formato de dados numa única tabela (por exemplo, tabelas ClinicalFhir e ImagingDicom). Não deve expandir, personalizar ou criar dependências nestas tabelas de teste no lakehouse de bronze pelos seguintes motivos:

    • Implementação interna: As tabelas de teste são implementadas a nível interno especificamente para as soluções de dados de cuidados de saúde no Microsoft Fabric. O seu esquema foi criado especificamente para as soluções de dados de cuidados de saúde e não segue nenhum padrão de dados do setor ou da comunidade.
    • Armazenamento transitório: Após os dados serem processados e transformados a partir das tabelas de teste do lakehouse de bronze para as tabelas delta simplificadas e normalizadas no lakehouse de prata, os dados da tabela de teste de bronze são considerados prontos para serem removidos. Este modelo garante eficiência de custo e armazenamento, e reduz a redundância de dados entre os ficheiros de origem e as tabelas de teste no lakehouse de bronze.

  • Lakehouse de prata: Também denominada zona melhorada, o lakehouse de prata melhora os dados do lakehouse de bronze. Inclui verificações de validação e técnicas de melhoramento para melhorar a precisão dos dados para análise a jusante. Ao contrário da camada de bronze, os dados do lakehouse de prata usam regras baseadas em ID deterministas e carimbos de data/hora de modificação para gerir as inserções e atualizações de registos.

  • Lakehouse de ouro: Também denominada zona organizada, o lakehouse de ouro melhora ainda mais os dados do lakehouse de prata para satisfazer os requisitos comerciais e analíticos específicos. Esta camada serve como principal origem para conjuntos de dados agregados de alta qualidade, prontos para uma análise abrangente e extração de informações. Enquanto as soluções de dados de cuidados de saúde implementam um lakehouse de bronze e um de prata por implementação, pode ter vários lakehouses de ouro para satisfazer várias unidades de negócios e pessoas.

  • Lakehouse de administração: O lakehouse de administração contém ficheiros para a governação e rastreabilidade de dados nas camadas de lakehouse, incluindo erros globais de configuração e validação armazenados na tabela BusinessEvent. Para saber mais, consulte Lakehouse de administração.

Estrutura unificada de pastas

Os clientes de cuidados de saúde e ciências da vida lidam com grandes quantidades de dados de vários sistemas de origem, em várias modalidades de dados e formatos de ficheiro, incluindo os seguintes formatos de ficheiro:

  • Modalidade clínica: ficheiros NDJSON FHIR, conjuntos FHIR e HL7.
  • Modalidade de imagem: DICOM, NIFTI e NDPI.
  • Modalidade genómica: BAM, BCL, FASTQ e VCF.
  • Reclamações: CCLF e CSV.

Em que:

  • FHIR: Fast Healthcare Interoperability Resources
  • HL7: Health Level Seven International
  • DICOM: Digital Imaging and Communications in Medicine
  • NIFTI: Neuroimaging Informatics Technology Initiative
  • NDPI: Nano-dimensional Pathology Imaging
  • BAM: Binary Alignment Map
  • BCL: Base Call
  • FASTQ: Um formato baseado em texto para armazenar uma sequência biológica e as pontuações de qualidade correspondentes
  • VCF: Variant Call Format
  • CCLF: Claim and Claim Line Feed
  • CSV: Valores separados por vírgulas

O OneLake no Microsoft Fabric oferece um data lake lógico para a sua organização. As soluções de dados de cuidados de saúde no Microsoft Fabric fornecem uma estrutura de pastas unificada que ajuda a organizar os dados em várias modalidades e formatos. Esta estrutura simplifica a ingestão e o processamento de dados, mantendo a linhagem de dados nos níveis do ficheiros de origem e do sistema de origem no lakehouse de bronze.

As seis pastas de nível superior incluem:

  • Externo
  • Com Falha
  • Ingerir
  • Processar
  • ReferenceData
  • SampleData

Uma captura de ecrã a apresentar as pastas do OneLake para soluções de dados de cuidados de saúde.

As subpastas estão organizadas da seguinte forma:

  • Files\Ingest\[DataModality]\[DataFormat]\[Namespace]
  • Files\External\[DataModality]\[DataFormat]\[Namespace]\[BYOSShortcutname]\
  • Files\SampleData\[DataModality]\[DataFormat]\[Namespace]\
  • Files\ReferenceData\[DataModality]\[DataFormat]\[Namespace]\
  • Files\Failed\[DataModality]\[DataFormat]\[Namespace]\YYYY\MM\DD
  • Files\Process\[DataModality]\[DataFormat]\[Namespace]\YYYY\MM\DD

Descrições das pastas

  • Namespace (obrigatório): Identifica o sistema de origem dos ficheiros recebidos, crucial para garantir a exclusividade do ID por sistema de origem.

  • Ingerir pasta: Funciona como uma pasta suspensa ou de fila. Esta pasta permite-lhe largar os ficheiros para serem ingeridos na modalidade apropriada e subpastas do formato. Após o início da ingestão, os ficheiros são transferidos para a respetiva pasta Processo ou para a pasta Falha em caso de falhas.

  • Pasta do processo: O destino final de todos os ficheiros processados com sucesso dentro de cada combinação de modalidade e formato. Esta pasta segue o padrão YYYY/MM/DD com base na data de processamento. A criação de partições de pastas segue as Práticas recomendadas para utilizar o Azure Data Lake Storage para uma melhor organização, pesquisas filtradas, automatização e potencial processamento paralelo.

  • Pasta externa: Serve como pasta principal para as pastas de atalho Bring Your Own Storage (BYOS). A implementação predefinida fornece uma estrutura de pastas sugestiva para modalidades de reclamações, clínica, genómica e imagem. As modalidades de imagem e clínica têm formatos predefinidos e namespaces configurados para suportar serviços DICOM e FHIR em Serviços de Dados de Saúde do Azure. Este formato aplica-se apenas se pretender criar um atalho de dados para o OneLake. As soluções de dados de cuidados de saúde no Microsoft Fabric têm acesso só de leitura aos ficheiros nestas pastas de atalho.

  • Pasta Falha: Se ocorrer uma falha ao mover ou processar ficheiros nas pastas Ingerir ou Processar, os ficheiros afetados serão movidos para a pasta Falha correspondente à sua combinação de modalidade e formato. Um erro é registado na tabela BusinessEvent no lakehouse de administração. Esta pasta usa o padrão YYYY/MM/DD com base na data de processamento/falha. Os ficheiros nesta pasta não são eliminados e permanecem aqui até que os corrija e volte a ingerir usando o mesmo padrão de ingestão inicial.

  • Pasta de dados de amostra: Inclui conjuntos de dados sintéticos, referenciais e/ou públicos. A implementação predefinida fornece dados de amostra para várias combinações de modalidades e formatos para facilitar a execução imediata de blocos de notas e pipelines após a implementação. Esta pasta não cria subpastas YYYY/MM/DD.

  • Pasta de dados de referência: Contém conjuntos de dados referenciais e principais de origens públicas ou específicas do utilizador. Esta pasta não cria subpastas YYYY/MM/DD. A implementação predefinida fornece uma estrutura de pastas sugerida para vocabulários OMOP (Observational Medical Outcomes Partnership).

Padrões de ingestão de dados

Com base na estrutura unificada de pastas descrita anteriormente, as soluções de dados de cuidados de saúde no Microsoft Fabric suportam dois padrões de ingestão distintos. Em ambos os casos, as soluções usam transmissão em fluxo estruturada no Spark para processar os ficheiros recebidos nas respetivas pastas.

Padrão de ingestão

Este padrão é uma abordagem simples em que os ficheiros a serem ingeridos são deixados na pasta Ingerir sob a modalidade, formato e namespace apropriados. Os pipelines de ingestão monitorizam esta pasta em busca de ficheiros deixados recentemente e movem-nos para a pasta Processar correspondente para processamento. Se a ingestão de dados de ficheiros na tabela de teste do lakehouse de bronze for bem-sucedida, o ficheiro será comprimido e guardado com um prefixo de carimbo de data/hora na pasta Processar, de acordo com o padrão YYYY/MM/DD baseado em quando ocorre o processamento. Este prefixo garante nomes de ficheiros exclusivos. Pode configurar ou desativar a compressão conforme necessário.

Se o processamento de ficheiros falhar, os ficheiros com falhas serão movidos da pasta Ingerir para a pasta Falhas para cada combinação de modalidade e formato, e um erro será registado na tabela BusinessEvent no lakehouse de administração.

Este padrão de ingestão é ideal para ingestões incrementais diárias ou ao mover dados fisicamente para o Azure Data Lake Storage ou OneLake.

Padrão Bring Your Own Storage (BYOS)

Às vezes, pode ter dados e ficheiros já presentes no Azure ou noutros serviços de armazenamento na nuvem, com implementações a jusante existentes e dependências desses ficheiros. Nos cuidados de saúde e nas ciências da vida, os volumes de dados podem atingir vários terabytes ou mesmo petabytes, especialmente para imagiologia médica e genómica. Por estas razões, o padrão de ingestão direta pode não ser viável.

Recomendamos o uso do padrão BYOS para ingestão de dados históricos quando tiver volumes de dados substanciais já disponíveis no Azure ou outro armazenamento na nuvem e local que suporte o protocolo S3. Este padrão usa atalhos do OneLake no Fabric e a pasta Externo no lakehouse de bronze para permitir o processamento local dos ficheiros de origem. Elimina a necessidade de mover ou copiar ficheiros e evita incorrer em cobranças de saída e duplicação de dados.

Apesar das eficiências oferecidas pelo padrão de ingestão BYOS, deve observar as seguintes considerações:

  • As atualizações de ficheiros no local (atualizações de conteúdo dentro do ficheiro) não são monitorizadas. Espera-se que crie um novo ficheiro (com um nome diferente) para quaisquer atualizações, pois o pipeline de ingestão monitoriza apenas os ficheiros novos. Esta limitação está associada à transmissão estruturada no Spark.
  • As compressões de dados não são aplicadas.
  • O padrão BYOS não cria nenhuma estrutura de pastas otimizada com base no YYYY/MM/DD padrão.
  • Se o processamento de ficheiros falhar, os ficheiros com falhas não serão movidos para a pasta Falhas. No entanto, um erro é registado na tabela BusinessEvent no lakehouse de administração.
  • Presume-se que os dados de origem sejam apenas de leitura.
  • Não há controlo sobre a linhagem ou disponibilidade dos dados de origem após a ingestão.

Compressão de dados

As soluções de dados de cuidados de saúde no Microsoft Fabric suportam a compressão desde a conceção em todo o design do lakehouse de medalhas. Os dados ingeridos nas tabelas delta no lakehouse de medalhas são armazenados num formato de colunas comprimido usando ficheiros parquet. No padrão de ingestão, quando os ficheiros são movidos da pasta Ingerir para a pasta Processar, são comprimidos por predefinição após o processamento bem-sucedido. Pode configurar ou desativar a compressão conforme necessário. Para as capacidades de imagiologia e reclamações, os pipelines de ingestão também podem processar ficheiros sem formato num formato comprimido ZIP.

Modelo de dados de cuidados de saúde

Conforme descrito no design de lakehouse de medalhas, as tabelas de teste do lakehouse de bronze implementam internamente tabelas criadas especificamente para soluções de dados de cuidados de saúde e não seguem nenhum padrão de dados do setor ou da comunidade.

O modelo de dados de cuidados de saúde no lakehouse de prata é baseado no padrão FHIR R4. Fornece uma linguagem de dados comum para os analistas de dados, cientistas de dados e programadores para colaborarem e criarem soluções orientadas por dados que melhorem os resultados dos pacientes e o desempenho dos negócios. Suporta dados em diferentes domínios de cuidados de saúde, tais como clínico, administrativo, financeiro e social. O modelo de dados de cuidados de saúde captura os dados definidos pelo padrão FHIR e organiza os recursos FHIR usando tabelas e colunas dentro do lakehouse.

Ao simplificar os dados FHIR em tabelas parquet delta, pode usar ferramentas familiares, como T-SQL e Spark SQL para exploração e análise de dados. Para dados não clínicos fora do âmbito do FHIR, utilizamos esquemas dos modelos de bases de dados do Azure Synapse. Esta implementação permite a integração de informações não clínicas, como dados de cativação do paciente, no perfil do paciente.

O modelo de dados de cuidados de saúde no lakehouse de prata foi concebido para representar uma vista empresarial de ponto a ponto dos dados de cuidados de saúde em unidades de negócios e domínios de pesquisa.

Diagrama de modelo de dados de cuidados de saúde.

Linhagem e rastreabilidade dos dados

Para garantir a linhagem e a rastreabilidade no nível de registo e ficheiro, as tabelas do modelo de dados de cuidados de saúde incluem as seguintes colunas:

Coluna Descrição
msftCreatedDatetime Carimbo de data/hora quando o registo foi criado pela primeira vez no lakehouse de prata.
msftModifiedDatetime Carimbo de data/hora da última modificação do registo.
msftFilePath Caminho completo para o ficheiro de origem no lakehouse de bronze, incluindo atalhos.
msftSourceSystem O sistema de origem do registo, correspondente ao Namespace especificado na estrutura unificada de pastas.

Se um campo for normalizado, simplificado ou modificado, o valor original será preservado numa coluna {columnName}Orig. Por exemplo, na tabela do lakehouse de prata Paciente, pode encontrar as seguintes colunas:

Coluna Descrição
meta_lastUpdatedOrig Preserva o valor original no seu formato não processado (cadeia de carateres ou data) e armazena-o como datetime.
idOrig e identifierOrig Os ID e identificadores harmonizados no lakehouse de prata.
birthdateOrig e deceasedDateTimeOrig Preserva os valores de data originais com uma formatação de carimbo de data/hora diferente.

Se uma coluna for simplificada (por exemplo, meta_lastUpdated) ou convertida para uma cadeia de carateres (por exemplo, meta_string), indicamo-la usando um sufixo que começa com um sublinhado (_).

Processamento de atualizações

Quando novos dados são ingeridos do lakehouse de bronze para de prata, uma operação de atualização compara os registos de entrada com as tabelas de destino no lakehouse de prata para cada recurso e tipo de tabela. Para tabelas FHIR no lakehouse de prata, esta comparação verifica ambos os valores {FHIRResource}.id e {FHIRResource}.meta_lastUpdated nas colunas id e lastUpdated na tabela de teste do lakehouse de bronze ClinicalFhir.

  • Se uma correspondência for identificada e o registo de entrada for novo, o registo de prata será atualizado.
  • Se o registo de entrada for antigo, o registo de prata será ignorado.
  • Se nenhuma correspondência for encontrada, o novo registo é inserido no lakehouse de prata.

Lakehouse de administração

O lakehouse de administração gere a configuração no lakehouse, a configuração global, os relatórios de estado e a monitorização de soluções de dados de cuidados de saúde no Microsoft Fabric.

Configuração global

A pasta do lakehouse de administração configurações do sistema centraliza os parâmetros de configuração global. Os três ficheiros de configuração contêm valores pré-configurados para a implementação predefinida de todas as capacidades de soluções de dados de cuidados de saúde. Não é necessário reconfigurar nenhum desses valores para executar os dados de exemplo ou os pipelines de dados para qualquer capacidade.

Uma captura de ecrã a mostrar os ficheiros de configuração global no lakehouse de administração.

O ficheiro deploymentParametersConfiguration.json contém parâmetros globais em activitiesGlobalParameters e parâmetros específicos da atividade para blocos de notas e pipelines em activities. As respetivas orientações de capacidades abrangem detalhes de configuração específicos para cada capacidade. Os parâmetros do ficheiro validation_config.json são explicados em Validação de dados.

A tabela seguinte lista todos os parâmetros de configuração global.

Secção Parâmetros de configuração
activitiesGlobalParameters •administration_lakehouse_id: Identificador do lakehouse de administração.
•bronze_lakehouse_id: Identificador do lakehouse de bronze.
•silver_lakehouse_id: Identificador do lakehouse de prata.
•keyvault_name: Valor do Azure Key Vault quando implementado com a oferta Azure Marketplace.
•enable_hds_logs: Permite o registo; valor predefinido como true.
•movement_config_path: Caminho para o ficheiro file_orchestration_config.
•bronze_imaging_delta_table_path: Caminho do Fabric para a tabela de modalidades de imagiologia (se implementada).
•bronze_imaging_table_schema_path: Caminho do Fabric para o esquema de modalidades de imagiologia (se implementado).
•omop_lakehouse_id: Identificador do lakehouse de ouro (se implementado).
Atividades para healthcare#_msft_fhir_ndjson_bronze_ingestion •source_path_pattern: Caminho do OneLake para a pasta Processar.
•move_failed_files_enabled: Sinalizador para determinar se um ficheiro com falhas deve ser movido da pasta Ingerir para a pasta Falhas.
•compression_enabled: Sinalizador para determinar se os ficheiros NDJSON não processados serão comprimidos após o processamento.
•target_table_name: Nome da tabela de ingestão clínica no lakehouse de bronze.
•target_tables_path: Caminho do OneLake para todas as tabelas delta no lakehouse de bronze.
•max_files_per_trigger: Número de ficheiros processados com cada execução.
•max_structured_streaming_queries: Número de consultas de processamento que podem ser executadas em paralelo.
•checkpoint_path: Caminho do OneLake para a pasta de pontos de verificação.
•schema_dir_path: Caminho do OneLake para a pasta de esquemas de bronze.
•validation_config_key: Configuração de validação de nível principal. Para mais informações, consulte Validação de dados.
•file_extension: A extensão do ficheiro não processado ingerido.
Atividades para healthcare#_msft_bronze_silver_flatten •source_table_name: Nome da tabela de ingestão clínica no lakehouse de bronze.
•config_path: Caminho do OneLake para o ficheiro de configuração simplificado.
•source_tables_path: Caminho do OneLake para as tabelas delta de origem no lakehouse de bronze.
•target_tables_path: Caminho do OneLake para as tabelas delta de destino no lakehouse de prata.
•checkpoint_path: Caminho do OneLake para a pasta de pontos de verificação.
•schema_dir_path: Caminho do OneLake para a pasta de esquemas de bronze.
•max_files_per_trigger: Número de ficheiros processados em cada execução.
•max_bytes_per_trigger: Número de bytes processados em cada execução.
•max_structured_streaming_queries: Número de consultas de processamento que podem ser executadas em paralelo.
Atividades para healthcare#_msft_imaging_dicom_extract_bronze_ingestion •byos_enabled: Sinalizador que determina se a ingestão do conjunto de dados de imagiologia DICOM no lakehouse de bronze tem origem num local de armazenamento externo através de atalhos do OneLake. Neste caso, os ficheiros não são movidos para a pasta Processar, pois seriam de outra forma.
•external_source_path: Caminho do OneLake para a pasta de atalho Externo no lakehouse de bronze.
•process_source_path: Caminho do OneLake para a pasta Processar no lakehouse de bronze.
•checkpoint_path: Caminho do OneLake para a pasta de pontos de verificação.
•move_failed_files: Sinalizador que determina se um ficheiro com falhas é movido da pasta Ingerir para Falhas.
•compression_enabled: Sinalizador que determina se os ficheiros NDJSON não processados são comprimidos após o processamento.
•max_files_per_trigger: Número de ficheiros processados em cada execução.
•num_retries: Número de novas tentativas para cada processamento de ficheiros antes de um erro.
Atividades para healthcare#_msft_imaging_dicom_fhir_conversion •fhir_ndjson_files_root_path: Caminho do OneLake para a pasta Processar.
•avro_schema_path: Caminho do OneLake para a pasta de esquemas de prata.
•dicom_to_fhir_config_path: Caminho do OneLake para o mapeamento de configuração de metatags DICOM para o recurso FHIR ImagingStudy.
•checkpoint_path: Caminho do OneLake para a pasta de pontos de verificação.
•max_records_per_ndjson: Número de registos processados num único ficheiro NDJSON em cada execução.
•subject_id_type_code: Código de valor para o número médico do paciente nos metadados DICOM. O valor predefinido está definido como MR, que corresponde a Medical Record Number no FHIR.
•subject_id_type_code_system: O sistema de códigos para o número médico do paciente nos metadados DICOM.
•subject_id_system: O ID do objeto do sistema de códigos para o número médico do paciente nos metadados DICOM.
Atividades para healthcare#_msft_omop_silver_gold_transformation •vocab_path: Caminho do OneLake para a pasta de dados de referência no lakehouse de bronze onde os conjuntos de dados de vocabulário OMOP são armazenados.
•vocab_checkpoint_path: Caminho do OneLake para a pasta de pontos de verificação.
•omop_config_path: Caminho do OneLake para a configuração de mapeamento do lakehouse de prata para o lakehouse de ouro OMOP.

Tabela BusinessEvents

A tabela delta BusinessEvents captura todos os erros de validação, avisos e outras notificações ou exceções que podem ocorrer durante os processos de ingestão e transformação. Use esta tabela para monitorizar o progresso da execução da ingestão nos níveis funcional e do utilizador, em vez de apenas no nível de registo do sistema. Por exemplo, identifica os ficheiros não processados que introduziram erros de validação ou avisos durante a ingestão. Para os registos ao nível do sistema e para monitorizar as atividades Apache Spark em todos os lakehouses, pode usar o hub de Monitorização do Fabric, com a opção de integrar o Log Analytics do Azure.

A tabela seguinte lista as colunas na tabela BusinessEvent:

Coluna Descrição
id GUID (identificador exclusivo) para cada linha da tabela.
activityName Nome da atividade/bloco de notas que gerou a falha e/ou o erro de validação ou aviso.
targetTableName Tabela de destino para a atividade de dados que gerou o evento.
targetFilePath Caminho para o ficheiro de destino para a atividade de dados que gerou o evento.
sourceTableName Tabela de origem para a atividade de dados que gerou o evento.
sourceLakehouseName Lakehouse de origem para a atividade de dados que gerou o evento.
targetLakehouseName Lakehouse de destino para a atividade de dados que gerou o evento.
sourceFilePath Caminho para o ficheiro de origem para a atividade de dados que gerou o evento.
runId ID de execução para a atividade de dados que gerou o evento.
severity Nível de gravidade do evento, que pode ter um dos dois valores seguimntes: Error ou Warning. Error significa que deve resolver este evento antes de continuar com a atividade de dados. Warning serve como uma notificação passiva, que geralmente não exige nenhuma ação imediata.
eventType Distingue entre eventos gerados pelo motor de validação e eventos genéricos gerados por utilizadores ou exceções não processadas/do sistema que os utilizadores desejam apresentar na tabela BusinessEvent.
recordIdentifier Identificador do registo de origem. Esta coluna difere da coluna id, pois representa um identificador exclusivo e novo para cada evento na tabela BusinessEvents.
recordIdentifierSource Sistema de origem para o identificador do registo de origem. Por exemplo, se o sistema de origem for o EMR, o nome ou URL do EMR servirá como origem.
active Sinalizador que indica se o evento (erro ou aviso) foi resolvido.
message Mensagem descritiva para o erro ou aviso do evento.
exception Mensagem de exceção não processada/do sistema.
customDimensions Aplicável quando os dados de origem da validação ou exceção não são uma coluna discreta numa tabela. Por exemplo, quando os dados de origem são um atributo dentro de um objeto JSON guardado como uma cadeia de carateres numa única coluna, o objeto JSON completo é fornecido como a dimensão personalizada.
eventDateTime Carimbo de data/hora no qual o evento ou a exceção é gerado.

Validação de dados

O motor de validação de dados dentro das soluções de dados de cuidados de saúde no Microsoft Fabric garante que os dados não processados satisfazem aos critérios predefinidos antes da ingestão no lakehouse de bronze. Pode configurar as regras de validação nos níveis de tabela e coluna no lakehouse de bronze. Atualmente, estas regras são implementadas exclusivamente durante o processo de ingestão, desde os ficheiros não processados até às tabelas delta no lakehouse de bronze.

Quando um ficheiro não processado é processado, as regras de validação aplicam-se ao nível da ingestão. Há dois níveis de severidade para validação: Error e Warning. Se uma regra de validação estiver definida para Error, o pipeline será interrompido quando a regra for violada e o ficheiro defeituoso será movido para a pasta Falhas. Se a gravidade estiver definida como Warning, o pipeline continuará o processamento e o ficheiro será movido para a pasta Processar. Em ambos os casos, as entradas que refletem os erros ou avisos são criadas na tabela BusinessEvents no lakehouse de administração.

A tabela BusinessEvents captura registos e eventos no nível da empresa em todos os lakehouses para qualquer atividade, bloco de notas ou pipeline de dados em soluções de dados de cuidados de saúde. No entanto, a configuração atual só impõe regras de validação durante a ingestão, o que pode fazer com que algumas colunas na tabela BusinessEvents permaneçam não preenchidas para erros de validação e avisos.

Pode configurar as regras de validação de dados no ficheiro validation_config.json no lakehouse de administração. Por predefinição, as colunas meta.lastUpdated e id na tabela ClinicalFhir do lakehouse de bronze são definidas como obrigatórias. Estas colunas são essenciais para determinar como as atualizações e inserções são geridas no lakehouse de prata, conforme explicado em Processamento de atualizações.

A tabela seguinte lista os parâmetros de configuração para a validação de dados:

Tipo de configuração Parâmetros
Nível do lakehouse bronze: O âmbito das validações e dos nós identificadores de registos. Neste caso, o valor é definido para o lakehouse de bronze.
Validações •validationType: O tipo de validação exists verifica se um valor para o atributo configurado é fornecido no ficheiro não processado (dados de origem).
•attributeName: Nome do atributo a ser validado.
•validationMessage: Mensagem que descreve o erro de validação ou aviso.
•severity: Indica o nível do problema, que pode ser Error ou Warning.
•tableName: Nome da tabela a ser validada. Um asterisco (*) indica que esta regra se aplica a todas as tabelas no âmbito desse lakehouse.
recordIdentifier •attributeName: Identificador do registo do ficheiro de origem/não processado colocado na coluna recordIdentifier na tabela BusinessEvent.
•jsonPath: Valor opcional que representa o caminho JSON de uma coluna ou atributo para o valor a ser colocado na coluna recordIdentifier na tabela BusinessEvent. Este valor aplica-se quando os dados de origem para a validação não são uma coluna discreta numa tabela. Por exemplo, se os dados de origem forem um atributo dentro de um objeto JSON armazenado como uma cadeia de carateres numa única coluna, o caminho JSON direcionará para o atributo específico que serve como identificador do registo.