Condividi tramite

Architettura e gestione dei dati nelle soluzioni per dati sanitari in Microsoft Fabric

  • Articolo

Il framework delle soluzioni per dati sanitari utilizza un'architettura medallion specializzata per semplificare l'organizzazione e l'elaborazione dei dati. Questa progettazione garantisce un miglioramento continuo della qualità e della struttura dei dati, consentendoti di gestire i dati sanitari in modo più efficace. In questo articolo vengono esplorate le caratteristiche e i vantaggi principali di questa architettura, fornendo una panoramica completa di come i dati vengono gestiti nel framework.

Progettazione del lakehouse medallion

Come descritto nell'architettura della soluzione, le soluzioni per dati sanitari utilizzano l'architettura del lakehouse medallion per organizzare ed elaborare i dati su più livelli. Man mano che i dati si spostano in ogni livello, la relativa struttura e qualità vengono continuamente migliorate. La progettazione del lakehouse medallion nelle soluzioni per dati sanitari è costituita dai seguenti lakehouse principali:

  • Lakehouse Bronze: denominato anche zona non elaborata, il lakehouse Bronze è il primo livello che organizza i dati di origine nel relativo formato di file originale. Inserisce i file di origine in OneLake e/o crea collegamenti da fonti di archiviazione native. Archivia inoltre i dati strutturati e semistrutturati dall'origine in tabelle delta, note anche come tabelle di staging. Queste tabelle sono compresse e indicizzate a colonne per supportare trasformazioni ed elaborazione dei dati efficienti. I dati in questo livello sono in genere di sola aggiunta e non modificabili.

    I file nel lakehouse Bronze (sia persistenti che collegamenti) fungono da fonte di verità. Gettano le basi per la derivazione dei dati nell'intero patrimonio di dati nelle soluzioni per dati sanitarie. Le tabelle di staging nel livello Bronze sono generalmente costituite da poche colonne e sono progettate per contenere ogni modalità e formato di dati in un'unica tabella (ad esempio, tabelle ClinicalFhir e ImagingDicom). Non dovresti estendere, personalizzare o creare dipendenze da queste tabelle di staging nel lakehouse Bronze per i seguenti motivi:

    • Implementazione interna: le tabelle di staging sono implementate internamente in modo specifico per le soluzioni per dati sanitari in Microsoft Fabric. Il relativo schema è creato appositamente per soluzioni per dati sanitari e non segue alcun standard di dati di settore o community.
    • Archiviazione transitoria: dopo che i dati sono stati elaborati e trasformati dalle tabelle di staging del lakehouse Bronze alle tabelle delta flat e normalizzate nel lakehouse Silver, i dati della tabella di staging Bronze sono considerati pronti per l'eliminazione. Questo modello garantisce l'efficienza in termini di costi e archiviazione e riduce la ridondanza dei dati tra i file di origine e le tabelle di staging nel lakehouse Bronze.

  • Lakehouse Silver: denominato anche zona arricchita, il lakehouse Silver affina i dati del lakehouse Bronze. Include controlli di convalida e tecniche di arricchimento per migliorare l'accuratezza dei dati per l'analisi downstream. A differenza del livello Bronze, i dati del lakehouse Silver utilizzano regole basate su ID deterministici e timestamp di modifica per gestire gli inserimenti e gli aggiornamenti dei record.

  • Lakehouse Gold: denominato anche zona curata, il lakehouse Gold perfeziona ulteriormente i dati del lakehouse Silver per soddisfare specifici requisiti aziendali e analitici. Questo livello funge da origine primaria per set di dati aggregati di alta qualità, pronti per l'analisi completa e l'estrazione di informazioni dettagliate. Mentre le soluzioni per dati sanitari distribuiscono un lakehouse Bronze e uno Silver per ogni distribuzione, puoi disporre di più lakehouse Gold per servire varie Business Unit e utenti tipo.

  • Lakehouse di amministrazione: il lakehouse di amministrazione contiene i file per la governance e la tracciabilità dei dati nei livelli del lakehouse, inclusi gli errori di configurazione e convalida globali archiviati nella tabella BusinessEvent. Per ulteriori informazioni, vedi Lakehouse di amministrazione.

Struttura di cartelle unificata

I clienti del settore sanitario e delle scienze biologiche gestiscono grandi quantità di dati provenienti da vari sistemi di origine, in più modalità di dati e formati di file, inclusi i formati di file seguenti:

  • Modalità clinica: file NDJSON FHIR, aggregazione FHIR e HL7.
  • Modalità di imaging: DICOM, NIFTI e NDPI.
  • Modalità genomica: BAM, BCL, FASTQ e VCF.
  • Richieste di rimborso: CCLF e CSV.

Dove:

  • 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: un formato basato su testo per memorizzare una sequenza biologica e i relativi punteggi di qualità
  • VCF: Variant Call Format
  • CCLF: Claim and Claim Line Feed
  • CSV: valori delimitati da virgole

OneLake in Microsoft Fabric offre un data lake logico per la tua organizzazione. Le soluzioni per dati sanitari in Microsoft Fabric forniscono una struttura di cartelle unificata che aiuta a organizzare i dati in varie modalità e formati. Questa struttura semplifica l'inserimento e l'elaborazione dei dati mantenendo al contempo la derivazione dei dati a livello di file di origine e di sistema di origine nel lakehouse Bronze.

Le sei cartelle di primo livello includono:

  • Esterna
  • Non inviata
  • Ingerisci
  • Processo
  • ReferenceData
  • SampleData

Screenshot delle cartelle OneLake per soluzioni per dati sanitari.

Le sottocartelle sono organizzate come segue:

  • 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

Descrizioni delle cartelle

  • Namespace (obbligatoria): identifica il sistema di origine per i file ricevuti, fondamentale per garantire l'univocità degli ID per sistema di origine.

  • Cartella Ingest: funziona come una cartella di rilascio o di coda. Ti consente di rilasciare i file da inserire nelle sottocartelle di modalità e formato appropriate. Dopo l'inizio dell'inserimento, i file vengono trasferiti nella rispettiva cartella Process o nella cartella Failed per gli errori.

  • Cartella Process: la destinazione finale di tutti i file elaborati correttamente in ogni combinazione di modalità e formato. Questa cartella segue il modello YYYY/MM/DD in base alla data di elaborazione. Il partizionamento delle cartelle è conforme alle procedure consigliate per l'uso di Azure Data Lake Storage per un'organizzazione migliorata, ricerche filtrate, automazione e potenziale elaborazione parallela.

  • Cartella External: funge da cartella padre per le cartelle di collegamenti BYOS (Bring Your Own Storage). La distribuzione predefinita fornisce una struttura di cartelle suggerita per le modalità di richieste di rimborso cliniche, genomiche e di imaging. Le modalità di imaging e cliniche hanno formati e spazi dei nomi predefiniti configurati per supportare i servizi DICOM e FHIR in Servizi per i dati sanitari di Azure. Questo formato si applica solo se intendi collegare i dati in OneLake. Le soluzioni per dati sanitari in Microsoft Fabric hanno accesso in sola lettura ai file in queste cartelle di collegamenti.

  • Cartella Failed: se si verifica un errore durante lo spostamento o l'elaborazione dei file nelle cartelle Ingest o Process, i file interessati vengono spostati nella cartella Failed corrispondente alla relativa combinazione di modalità e formato. Viene registrato un errore nella tabella BusinessEvent nel lakehouse di amministrazione. Questa cartella usa il modello YYYY/MM/DD in base alla data di elaborazione/dell'errore. I file in questa cartella non vengono eliminati fino a quando non vengono corretti e reinseriti usando lo stesso modello di inserimento iniziale.

  • Cartella Sample data: include set di dati sintetici, referenziali e/o pubblici. La distribuzione predefinita fornisce dati di esempio per diverse combinazioni di modalità e formato per facilitare l'esecuzione immediata di notebook e pipeline dopo la distribuzione. Questa cartella non crea alcuna sottocartella YYYY/MM/DD.

  • Cartella dei dati di riferimento: contiene set di dati referenziali e padre provenienti da origini pubbliche o specifiche dell'utente. Questa cartella non crea alcuna sottocartella YYYY/MM/DD. La distribuzione predefinita fornisce una struttura di cartelle suggerita per i vocabolari OMOP (Observational Medical Outcomes Partnership).

Modelli di inserimento dei dati

In base alla struttura di cartelle unificata descritta in precedenza, le soluzioni per dati sanitari in Microsoft Fabric supportano due modelli di inserimento distinti. In entrambi i casi, le soluzioni usano lo streaming strutturato in Spark per elaborare i file in arrivo nelle rispettive cartelle.

Modello di inserimento

Questo modello è un approccio semplice in cui i file da inserire vengono rilasciati nella cartella Ingest secondo la modalità, il formato e lo spazio dei nomi appropriati. Le pipeline di inserimento monitorano questa cartella per i file appena rilasciati e li spostano nella cartella Process corrispondente per l'elaborazione. Se l'inserimento dei dati dei file nella tabella di staging del lakehouse Bronze riesce, il file viene compresso e salvato con un prefisso timestamp nella cartella Process seguendo il modello YYYY/MM/DD basato sul momento in cui si verifica l'elaborazione. Questo prefisso garantisce nomi di file univoci. Puoi configurare o disabilitare la compressione come necessario.

Se l'elaborazione dei file non riesce, i file con errore vengono spostati dalla cartella Ingest alla cartella Failed per ogni combinazione di modalità e formato e viene registrato un errore nella tabella BusinessEvent nel lakehouse di amministrazione.

Questo modello di inserimento è ideale per inserimenti incrementali giornalieri o quando si spostano fisicamente i dati in Azure Data Lake Storage o OneLake.

Modello BYOS (Bring Your Own Storage)

A volte potresti avere dati e file già presenti in Azure o in altri servizi di archiviazione cloud, con implementazioni downstream esistenti e dipendenze su tali file. Nel settore sanitario e delle scienze biologiche, i volumi di dati possono raggiungere diversi terabyte o addirittura petabyte, in particolare per imaging medico e genomica. Per questi motivi, il modello di inserimento diretto potrebbe non essere fattibile.

Consigliamo di utilizzare il modello BYOS per l'inserimento di dati storici quando si dispone di volumi di dati sostanziali già disponibili in Azure o altro cloud e l'archiviazione locale che supporta il protocollo S3. Questo modello usa collegamenti OneLake in Fabric e la cartella External nel lakehouse Bronze per consentire l'elaborazione sul posto di file di origine. Elimina la necessità di spostare o copiare i file ed evita di incorrere in addebiti in uscita e duplicazione di dati.

Nonostante le efficienze offerte dal modello di inserimento BYOS, è bene tenere presente le seguenti considerazioni:

  • Gli aggiornamenti di file sul posto (aggiornamenti del contenuto nel file) non vengono monitorati. Devi creare un nuovo file (con un nome diverso) per tutti gli aggiornamenti, poiché la pipeline di inserimento monitora solo i nuovi file. Questa limitazione è associata allo streaming strutturato in Spark.
  • Le compressioni di dati non vengono applicate.
  • Il modello BYOS non crea alcuna struttura di cartelle ottimizzata basata sul modello YYYY/MM/DD.
  • Se l'elaborazione dei file non riesce, i file con errore non vengono spostati nella cartella Failed. Tuttavia, un errore viene registrato nella tabella BusinessEvent nel lakehouse di amministrazione.
  • Si presuppone che i dati di origine siano di sola lettura.
  • Non vi è alcun controllo sulla derivazione o sulla disponibilità dei dati di origine dopo l'inserimento.

Compressione dei dati

Le soluzioni per dati sanitari in Microsoft Fabric supportano la compressione nella progettazione del lakehouse medallion. I dati inseriti nelle tabelle delta nel lakehouse medallion vengono archiviati in un formato a colonne compresso usando file parquet. Nel modello di inserimento, quando i file vengono spostati dalla cartella Ingest alla cartella Process, vengono compressi per impostazione predefinita dopo l'elaborazione riuscita. Puoi configurare o disabilitare la compressione come necessario. Per le funzionalità relative a imaging e richieste di rimborso, le pipeline di inserimento possono anche elaborare file non elaborati in un formato compresso ZIP.

Modello di dati per il settore sanitario

Come descritto nel progettazione del lakehouse medallion, le tabelle di staging del lakehouse Bronze implementano internamente tabelle appositamente progettate per soluzioni per dati sanitari e non seguono alcun standard di dati di settore o community.

Il modello di dati per il settore sanitario nel lakehouse Silver è basato sullo standard FHIR R4. Fornisce un linguaggio di dati comune per analisti di dati, data scientist e sviluppatori per collaborare e creare soluzioni basate su dati che migliorano i risultati dei pazienti e le prestazioni aziendali. Supporta i dati in diversi domini sanitari come domini clinici, amministrativi, finanziari e sociali. Il modello di dati per il settore sanitario acquisisce i dati definiti dallo standard FHIR e organizza le risorse FHIR usando tabelle e colonne nel lakehouse.

Rendendo flat i dati FHIR in tabelle parquet delta, puoi usare strumenti familiari come T-SQL e Spark SQL per l'esplorazione e l'analisi dei dati. Per i dati non clinici che non rientrano nell'ambito di FHIR, usiamo schemi dei modelli di database di Azure Synapse. Questa implementazione consente l'integrazione di informazioni non cliniche, come i dati sull'interazione con il paziente, nel profilo del paziente.

Il modello di dati per il settore sanitario nel lakehouse Silver è progettato per rappresentare una visione aziendale end-to-end dei dati sanitari tra Business Unit e i domini di ricerca.

Diagramma del modello di dati per il settore sanitario.

Derivazione e tracciabilità dei dati

Per garantire la derivazione e la tracciabilità a livello di record e file, le tabelle del modello di dati per il settore sanitario includono le colonne seguenti:

Column Descrzione
msftCreatedDatetime Timestamp di quando il record è stato creato per la prima volta nel lakehouse Silver.
msftModifiedDatetime Timestamp dell'ultima modifica al record.
msftFilePath Percorso completo del file di origine nel lakehouse Bronze, inclusi i collegamenti.
msftSourceSystem Il sistema di origine del record, corrispondente al Namespace specificato nella struttura di cartelle unificata.

Se un campo viene normalizzato, reso flat o modificato, il valore originale viene mantenuto in una colonna{columnName}Orig. Ad esempio, nella tabella Paziente del lakehouse Silver, sono disponibili le seguenti colonne:

Column Descrzione
meta_lastUpdatedOrig Mantiene il valore originale nel formato non elaborato (stringa o data) e lo archivia come datetime.
idOrig e identifierOrig ID e identificatori armonizzati nel lakehouse Silver.
birthdateOrig e deceasedDateTimeOrig Mantiene i valori di data originali con una formattazione di timestamp diversa.

Se una colonna viene resa flat (ad esempio, meta_lastUpdated) o viene convertita in una stringa (ad esempio, meta_string), la indichiamo usando un suffisso che inizia con un carattere di sottolineatura (_).

Gestione degli aggiornamenti

Quando vengono inseriti nuovi dati dal lakehouse Bronze nel lakehouse Silver, un'operazione di aggiornamento confronta i record in ingresso con le tabelle di destinazione nel lakehouse Silver di ogni risorsa e tipo di tabella. Per le tabelle FHIR nel lakehouse Silver, questo confronto controlla entrambi i valori {FHIRResource}.id e {FHIRResource}.meta_lastUpdated con le colonne id e lastUpdated nella tabella di staging ClinicalFhir del lakehouse Bronze.

  • Se viene identificata una corrispondenza e il record in entrata, il record Silver viene aggiornato.
  • Se il record in entrata non è nuovo, il record Silver viene ignorato.
  • Se non viene trovata alcuna corrispondenza, il nuovo record viene inserito nel lakehouse Silver.

Lakehouse di amministrazione

Il lakehouse di amministrazione gestisce la configurazione tra lakehouse, la configurazione globale, report sullo stato e il rilevamento di soluzioni per dati sanitari in Microsoft Fabric.

Configurazione globale

La cartella system-configurations del lakehouse di amministrazione centralizza i parametri di configurazione globali. I tre file di configurazione contengono valori preconfigurati per la distribuzione predefinita di tutte le funzionalità delle soluzioni per dati sanitari. Non è necessario riconfigurare nessuno di questi valori per eseguire i dati di esempio o le pipeline di dati per qualsiasi funzionalità.

Screenshot che mostra i file di configurazione globale nel lakehouse di amministrazione.

Il file deploymentParametersConfiguration.json contiene parametri globali in activitiesGlobalParameters e i parametri specifici dell'attività per notebook e pipeline in activities. Le rispettive linee guida coprono dettagli di configurazione specifici per ciascuna funzionalità. I parametri del file validation_config.json sono descritti in Convalida dei dati.

La tabella seguente elenca tutti i parametri di configurazione globale.

Sezione Parametri di configurazione
activitiesGlobalParameters •administration_lakehouse_id: identificatore del lakehouse di amministrazione.
•bronze_lakehouse_id: identificatore del lakehouse Bronze.
•silver_lakehouse_id: identificatore del lakehouse Silver.
•keyvault_name: valore di Azure Key Vault quando distribuito con l'offerta di Azure Marketplace.
•enable_hds_logs: abilita la registrazione; il valore predefinito è impostato su true.
•movement_config_path: percorso del file file_orchestration_config.
•bronze_imaging_delta_table_path: percorso Fabric della tabella della modalità di imaging (se distribuita).
•bronze_imaging_table_schema_path: percorso Fabric dello schema della modalità di imaging (se distribuito).
•omop_lakehouse_id: identificatore del lakehouse Gold (se distribuito).
Attività di healthcare#_msft_fhir_ndjson_bronze_ingestion •source_path_pattern: percorso OneLake alla cartella Process.
•:move_failed_files_enabled: flag per determinare se un file con errori deve essere spostato dalla cartella Ingest alla cartella Failed.
•compression_enabled: flag per determinare se i file NDJSON non elaborati verranno compressi dopo l'elaborazione.
•target_table_name: nome della tabella di inserimento clinica nel lakehouse Bronze.
•target_tables_path: percorso OneLake di tutte tabelle delta nel lakehouse Bronze.
•max_files_per_trigger: numero di file elaborati ad ogni esecuzione.
•max_structured_streaming_queries: numero di query di elaborazione che possono essere eseguite in parallelo.
•checkpoint_path: percorso OneLake della cartella del checkpoint.
•schema_dir_path: percorso OneLake della cartella dello schema Bronze.
•validation_config_key: configurazione della convalida a livello padre. Per ulteriori informazioni, vedi Convalida dei dati.
•file_extension: l'estensione del file non elaborato inserito.
Le attività di healthcare#_msft_bronze_silver_flatten •source_table_name: nome della tabella di inserimento clinica nel lakehouse Bronze.
•config_path: percorso OneLake del file di configurazione flat.
•source_tables_path: percorso OneLake delle tabelle delta di origine nel lakehouse Bronze.
•target_tables_path: percorso OneLake delle tabelle delta di destinazione nel lakehouse Silver.
•checkpoint_path: percorso OneLake della cartella del checkpoint.
•schema_dir_path: percorso OneLake della cartella dello schema Bronze.
•max_files_per_trigger: numero di file elaborati durante ogni esecuzione.
•max_bytes_per_trigger: numero di byte elaborati durante ogni esecuzione.
•max_structured_streaming_queries: numero di query di elaborazione che possono essere eseguite in parallelo.
Attività di healthcare#_msft_imaging_dicom_extract_bronze_ingestion •byos_enabled: flag che determina se l'inserimento del set di dati di imaging DICOM nel lakehouse Bronze proviene da una posizione di archiviazione esterna tramite i collegamenti OneLake. In questo caso, i file non vengono spostati nella cartella Process come avverrebbe altrimenti.
•external_source_path: percorso OneLake della cartella External del collegamento nel lakehouse Bronze.
•process_source_path: percorso OneLake della cartella Process nel lakehouse Bronze.
•checkpoint_path: percorso OneLake della cartella del checkpoint.
•:move_failed_files: flag che determina se un file con errori viene spostato dalla cartella Ingest alla cartella Failed.
•compression_enabled: flag che determina se i file NDJSON non elaborati vengono compressi dopo l'elaborazione.
•max_files_per_trigger: numero di file elaborati durante ogni esecuzione.
•num_retries: numero di tentativi per ogni elaborazione di file prima che si verifichi un errore.
Attività di healthcare#_msft_imaging_dicom_fhir_conversion •fhir_ndjson_files_root_path: percorso OneLake alla cartella Process.
•avro_schema_path: percorso OneLake della cartella dello schema Silver.
•dicom_to_fhir_config_path: percorso OneLake della configurazione di mapping dai metatag DICOM alla risorsa FHIR ImagingStudy.
•checkpoint_path: percorso OneLake della cartella del checkpoint.
•max_records_per_ndjson: numero di record elaborati in un singolo file NDJSON in ogni esecuzione.
•subject_id_type_code: codice valore del numero medico del paziente nei metadati DICOM. Il valore predefinito è impostato su MR, che corrisponde a Medical Record Number in FHIR.
•subject_id_type_code_system: il sistema di codici del numero medico del paziente nei metadati DICOM.
•subject_id_system: l'ID oggetto del sistema di codici del numero medico del paziente nei metadati DICOM.
Attività di healthcare#_msft_omop_silver_gold_transformation •vocab_path: percorso OneLake della cartella dei dati di riferimento nel lakehouse Bronze in cui sono memorizzati i set di dati del vocabolario OMOP.
•vocab_checkpoint_path: percorso OneLake della cartella del checkpoint.
•omop_config_path: percorso OneLake della configurazione di mapping dal lakehouse Silver al lakehouse OMOP Gold.

Tabella BusinessEvents

La tabella delta BusinessEvents acquisisce tutti gli errori di convalida, gli avvisi e altre notifiche o eccezioni che possono verificarsi durante i processi di inserimento e trasformazione. Usa questa tabella per monitorare l'avanzamento dell'esecuzione dell'inserimento sia a livello di utente che di funzionalità, anziché esclusivamente a livello di log di sistema. Ad esempio, identifica quali file non elaborati hanno introdotto errori di convalida o avvisi durante l'inserimento. Per i log a livello di sistema e per monitorare le attività Apache Spark in tutti i lakehouse, puoi usare l'hub di monitoraggio Fabric, con l'opzione di integrare Azure Log Analytics.

Nella tabella seguente sono elencate le colonne della tabella BusinessEvent:

Colonna Descrizione
id Identificatore univoco (GUID) di ogni riga nella tabella.
activityName Nome dell'attività/del notebook che ha generato l'errore e/o l'errore o l'avviso di convalida.
targetTableName Tabella di destinazione dell'attività dati che ha generato l'evento.
targetFilePath Percorso del file di destinazione dell'attività dati che ha generato l'evento.
sourceTableName Tabella di origine dell'attività dati che ha generato l'evento.
sourceLakehouseName Lakehouse di origine dell'attività dati che ha generato l'evento.
targetLakehouseName Lakehouse di destinazione dell'attività dati che ha generato l'evento.
sourceFilePath Percorso del file di origine dell'attività dati che ha generato l'evento.
runId ID esecuzione dell'attività dati che ha generato l'evento.
severity Livello di gravità dell'evento, che potrebbe avere uno dei due valori seguenti: Error o Warning. Error indica che devi risolvere questo evento prima di continuare con l'attività dati. Warning funge da notifica passiva e in genere non richiede alcuna azione immediata.
eventType Distingue tra gli eventi generati dal motore di convalida e gli eventi generici generati dagli utenti o dalle eccezioni di sistema/non gestite che gli utenti vogliono siano visualizzate nella tabella BusinessEvent.
recordIdentifier Identificatore del record di origine. Questa colonna differisce dalla colonna id in quanto rappresenta un identificatore nuovo e univoco di ogni evento nella tabella BusinessEvents.
recordIdentifierSource Sistema di origine dell'identificatore del record di origine. Ad esempio, se il sistema di origine è l'EMR, il nome o l'URL dell'EMR funge da origine.
active Flag che indica se l'evento (errore o avviso) è stato risolto.
message Messaggio descrittivo dell'errore o dell'avviso dell'evento.
exception Messaggio di eccezione non gestita/di sistema.
customDimensions Applicabile quando i dati di origine della convalida o dell'eccezione non sono colonne distinte in una tabella. Ad esempio, quando i dati di origine sono un attributo di un oggetto JSON salvato come stringa in una singola colonna, l'oggetto JSON completo viene fornito come dimensione personalizzata.
eventDateTime Timestamp della generazione dell'evento o dell'eccezione.

Convalida dei dati

Il motore di convalida dei dati nelle soluzioni per dati sanitari in Microsoft Fabric garantisce che i dati non elaborati soddisfino criteri predefiniti prima dell'inserimento nel lakehouse Bronze. Puoi configurare le regole di convalida a livello di tabella e di colonna nel lakehouse Bronze. Attualmente, queste regole vengono implementate esclusivamente durante il processo di inserimento, dai file non elaborati alle tabelle delta nel lakehouse Bronze.

Quando viene elaborato un file non elaborato, le regole di convalida si applicano a livello di inserimento. Esistono due livelli di gravità per la convalida: Error e Warning. Se una regola di convalida è impostata su Error, la pipeline si interrompe quando la regola viene violata e il file con errori viene spostato nella cartella Failed. Se la gravità è impostata su Warning, la pipeline continua l'elaborazione e il file viene spostato nella cartella Processo . In entrambi i casi, le voci che riflettono gli errori o gli avvisi vengono create nella tabella BusinessEvents nel lakehouse di amministrazione.

La tabella BusinessEvents acquisisce i log e gli eventi a livello aziendale in tutti i lakehouse per qualsiasi attività, notebook o pipeline di dati nelle soluzioni per dati sanitari. Tuttavia, la configurazione corrente applica le regole di convalida solo durante l'inserimento, il che potrebbe comportare che alcune colonne della tabella BusinessEvents rimangano non popolate per errori e avvisi di convalida.

Puoi configurare le regole di convalida dei dati nel file validation_config.json nel lakehouse di amministrazione. Per impostazione predefinita, le colonne meta.lastUpdated e id nella tabella ClinicalFhir del lakehouse Bronze sono impostate come necessario. Queste colonne sono fondamentali per determinare la modalità di gestione di aggiornamenti e inserimenti nel lakehouse Silver, come illustrato in Gestione degli aggiornamenti.

La tabella seguente elenca i parametri di configurazione per la convalida dei dati:

Tipo di configurazione Parametri
Livello del lakehouse bronze: l'ambito delle convalide e dei nodi identificatori dei record. In questo caso, il valore è impostato sul lakehouse Bronze.
Convalide •validationType: il tipo di convalida exists controlla se nel file non elaborato (dati di origine) viene fornito un valore per l'attributo configurato.
•attributeName: nome dell'attributo in fase di convalida.
•validationMessage: messaggio che descrive l'errore o l'avviso di convalida.
•severity: indica il livello del problema, che può essereError o Warning.
•tableName: nome della tabella in fase di convalida. Un asterisco (*) indica che questa regola si applica a tutte le tabelle che rientrano nell'ambito di quel lakehouse.
recordIdentifier •attributeName: identificatore del record del file di origine/non elaborato nella colonna recordIdentifier della tabella BusinessEvent.
•jsonPath: valore facoltativo che rappresenta il percorso JSON di una colonna o di un attributo per il valore da inserire nella colonna recordIdentifier nella tabella BusinessEvent. Questo valore si applica quando i dati di origine della convalida non sono colonne distinte in una tabella. Ad esempio, se i dati di origine sono un attributo in un oggetto JSON archiviato come stringa in una singola colonna, il percorso JSON indirizza all'attributo specifico che funge come identificatore del record.