Dataarkitektur och -hantering i vårddatalösningar i Microsoft Fabric

Ramverket för vårddatalösningar använder en specialiserad medaljongarkitektur för att effektivisera dataorganisation och bearbetning. Den här designen säkerställer kontinuerlig förbättring av datakvalitet och struktur, vilket gör att du kan hantera vårddata mer effektivt. Den här artikeln utforskar de viktigaste funktionerna och fördelarna med den här arkitekturen och ger en omfattande översikt över hur data hanteras inom det här ramverket.

Medaljongdesign av sjöhus

Som förklaras i lösningsarkitekturen använder vårddatalösningar medaljongarkitekturen för sjöhus för att organisera och bearbeta data i flera lager. När data rör sig genom varje lager förbättras dess struktur och kvalitet kontinuerligt. I grunden består medaljongarkitekturen för sjöhus inom vårddatalösningar av följande centrala sjöhus:

• Bronssjöhus: Bronssjöhus, även kallat rå är det första lagret som organiserar källdata i sitt ursprungliga filformat. Den matar in källfiler i OneLake och/eller skapar genvägar från interna lagringskällor. Den lagrar också strukturerade och halvstrukturerade data från källan i deltatabeller, även kallade mellanlagringstabeller. Dessa tabeller är komprimerade och kolumnindexerade för att stödja effektiva omvandlingar och databearbetning. Data i det här lagret är vanligtvis endast tillägg och oföränderliga.

  Filer i bronssjöhuset (oavsett om de är beständiga eller genvägar) fungerar som källan till sanningen. De lägger grunden för dataursprung i hela dataegendomen i vårddatalösningar. Mellanlagringstabeller i bronslagret består vanligtvis av några kolumner och är utformade för att innehålla varje datamodalitet och format i en enda tabell (till exempel tabellerna ClinicalFhir och ImagingDicom). Du bör inte utöka, anpassa eller skapa beroenden för dessa mellanlagringstabeller i bronssjöhuset av följande skäl:

  • Intern implementering: Mellanlagringstabellerna implementeras internt specifikt för vårddatalösningar i Microsoft Fabric. Deras schema är specialbyggt för vårddatalösningar och följer inte någon bransch- eller communitydatastandard.
  • Övergående lager: När data har bearbetats och omvandlas från mellanlagringstabellerna för bronssjöhus till de tillplattade och normaliserade deltatabellerna i silversjöhuset, anses tabelldata i bronsmellanlagring vara redo att rensas. Den här modellen säkerställer kostnads- och lagringseffektivitet och minskar dataredundansen mellan källfiler och mellanlagringstabeller i bronssjöhuset.

• Silversjöhus: Kallas även den berikade zonen, silversjöhus förfinar data från bronssjöhuset. Det innehåller valideringskontroller och berikningstekniker för att förbättra datanoggrannheten för nedströmsanalys. Till skillnad från bronslagret använder data i silversjöhuset regler baserade på deterministiska ID:n och tidsstämplar för ändringar för att hantera postinfogningar och uppdateringar.

• Guldsjöhus: Guldsjöhus, kallas även den modererade zonen, förfinar ytterligare data från silversjöhuset för att uppfylla specifika affärs- och analyskrav. Det här lagret fungerar som den primära källan för högkvalitativa, aggregerade datauppsättningar som är redo för omfattande analys och extrahering av insikter. Även om vårddatalösningar distribuerar ett bronssjöhus och ett silversjöhus per distribution, kan du ha flera guldsjöhus för att betjäna olika affärsenheter och personer.

• Admin sjöhus: Admin sjöhus innehåller filer för datastyrning och spårbarhet över lakehouse-lagren, inklusive globala konfigurations- och valideringsfel som lagras i tabellen BusinessEvent. Mer information finns i Admin sjöhus.

Enhetlig mappstruktur

Kunder inom hälso- och sjukvård och biovetenskap hanterar stora mängder data från olika källsystem, över flera datamodaliteter och filformat, inklusive följande filformat:

• Klinisk modalitet: FHIR NDJSON-filer, FHIR-paket och HL7.
• Bildmodalitet: DICOM, NIFTI och NDPI.
• Genomikmodalitet: BAM, BCL, FASTQ och VCF.
• Anspråk: CCLF och CSV.

Där:

• FHIR: elektronisk standard för utbyte av vårdinformation
• HL7: Health Level Seven International
• DICOM: Digital bildbehandling och kommunikation inom medicin
• NIFTI: Neuroimaging Informatics Technology Initiative
• NDPI: Nano-dimensional Pathology Imaging
• BAM: Binary Alignment Map
• BCL: Base Call
• FASTQ: Ett textbaserat format som används för att lagra biologiska sekvenser tillsammans med tillhörande kvalitetsvärden
• VCF: Variant Call Format
• CCLF: Anspråk och anspråksradsflöde
• CSV: Kommaavgränsade värden

OneLake i Microsoft Fabric erbjuder en logisk datasjö för din organisation. Vårddatalösningar i Microsoft Fabric tillhandahåller en enhetlig mappstruktur som hjälper till att organisera data i olika modaliteter och format. Den här strukturen effektiviserar datainmatning och bearbetning samtidigt som data härkomst bevaras på källfils- och källsystemnivå i bronssjöhuset.

De sex mapparna på den översta nivån är:

• Externt
• Misslyckad
• Mata in
• Bearbeta
• ReferenceData
• Exempeldata

Undermapparna är organiserade enligt följande:

• 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

Mappbeskrivningar

• Namnområde (obligatoriskt): Identifierar källsystemet för mottagna filer, vilket är avgörande för att säkerställa att ID:t är unikt per källsystem.

• Inmatningsmapp: Fungerar som en mapp för släpp- eller köhantering. Med den här mappen kan du släppa de filer som ska importeras i lämpliga undermappar för modalitet och format. När inmatningen har påbörjats överförs filerna till respektive mapp för Process eller Misslyckades för fel.

• Processmapp: Slutdestinationen för alla bearbetade filer inom varje modalitets- och formatkombination. Den här mappen följer YYYY/MM/DD mönstret baserat på bearbetningsdatumet. Mapppartitioneringen följer Metodtips för att använda Azure Data Lake Storage förbättrad organisation, filtrerade sökningar, automatisering och potentiell parallell bearbetning.

• Extern mapp: Fungerar som överordnad mapp för BYOS-genvägsmapparna (Bring Your Own Storage). Standarddistributionen ger en suggestiv mappstruktur för anspråk, kliniska, genomiska och avbildningsmodaliteter. Bild- och kliniska modaliteter har standardformat och namnrymder som konfigurerats för att stödja DICOM- och FHIR-tjänster i Azure Health Data Services. Det här formatet gäller endast om du tänker genvägsdata till OneLake. Vårddatalösningar i Microsoft Fabric har skrivskyddad åtkomst till filer i dessa genvägsmappar.

• Misslyckad mapp: Om ett fel inträffar när du flyttar eller bearbetar filer i mapparna Inmatning eller Process flyttas de berörda filerna till mappen Misslyckades som motsvarar deras modalitet och formatkombination. Ett fel loggas i tabellen BusinessEvent i admin sjöhus. Den här mappen använder YYYY/MM/DD mönstret baserat på bearbetnings-/feldatumet. Filer i den här mappen rensas inte och fortsätter att finnas kvar här tills du åtgärdar och matar in dem igen med samma inledande inmatningsmönster.

• Exempeldatamapp: Innehåller syntetiska, refererande och/eller offentliga datauppsättningar. Standarddistributionen innehåller exempeldata för flera kombinationer av modaliteter och format för att underlätta omedelbar körning av notebook-filer och pipelines efter distributionen. Den här mappen skapar inte YYYY/MM/DD undermappar.

• Referensdatamapp: Innehåller refererande och överordnade datauppsättningar från offentliga eller användarspecifika källor. Den här mappen skapar inte YYYY/MM/DD undermappar. Standarddistributionen innehåller en föreslagen mappstruktur för OMOP (Observational Medical Outcomes Partnership) vokabulärer.

Mönster för datainmatning

Baserat på den enhetliga mappstrukturen som beskrevs tidigare stöder vårddatalösningar i Microsoft Fabric i två olika inmatningsmönster. I båda fallen använder lösningarna strukturerad direktuppspelning i Spark för att bearbeta inkommande filer i respektive mappar.

Inmatningsmönster

Det här mönstret är en enkel metod där filer som ska matas in släpps i mappen Mata in under lämplig modalitet, format och namnområde. Inmatningspipelines övervakar den här mappen för nyligen släppta filer och flyttar dem till motsvarande mapp för Process för bearbetning. Om inmatningen av fildata i mellanlagringstabellen för bronssjöhuset lyckas, komprimeras filen och sparas med ett tidsstämpelsprefix i mappen Process följt av mönstret YYYY/MM/DD baserat på när bearbetningen sker. Det här prefixet säkerställer unika filnamn. Du kan konfigurera eller inaktivera komprimeringen efter behov.

Om filbearbetningen misslyckas flyttas de misslyckade filerna från mappen Inmatning till mappen Misslyckades för varje kombination av modalitet och format och ett fel loggas i tabellen BusinessEvent i admin sjöhus.

Det här inmatningsmönstret är idealiskt för dagliga inkrementella inmatningar eller när du fysiskt flyttar data till Azure Data Lake Storage eller OneLake.

Mönstret ta med din egen lagring (BYOS)

Ibland kan data och filer redan finnas i Azure eller andra molnlagringstjänster, med befintliga underordnade implementeringar och beroenden för dessa filer. Inom hälso- och sjukvård och biovetenskap kan datavolymer nå flera terabyte eller till och med petabyte, särskilt för medicinsk bildbehandling och genomik. Av dessa skäl kanske mönstret för direkt inmatning inte är möjligt.

Vi rekommenderar att du använder BYOS-mönstret för historisk datainmatning när du redan har betydande datavolymer tillgängliga i Azure eller annan molnlagring och lokal lagring som stöder S3-protokollet. Det här mönstret använder OneLake-genvägar i Fabric och den externa mappen i bronssjöhuset för att möjliggöra bearbetning av källfiler på plats. Det eliminerar behovet av att flytta eller kopiera filer och undviker därmed utgående avgifter och dataduplicering.

Trots den effektivitet som erbjuds av BYOS-inmatningsmönstret bör du tänka på följande:

• Filuppdateringar på plats (innehållsuppdateringar i filen) övervakas inte. Du förväntas skapa en ny fil (med ett annat namn) för alla uppdateringar, eftersom inmatningspipelinen endast övervakar nya filer. Den här begränsningen är associerad med strukturerad direktuppspelning i Spark.
• Datakomprimeringar tillämpas inte.
• BYOS-mönstret skapar ingen optimerad mappstruktur baserat på YYYY/MM/DD mönstret.
• Om filbearbetningen misslyckas flyttas inte de misslyckade filerna till mappen Misslyckades. Ett fel loggas emellertid i tabellen BusinessEvent i admin sjöhus.
• Källdata antas vara skrivskyddade.
• Det finns ingen kontroll över ursprunget eller tillgängligheten för källdata efter inmatningen.

Datakomprimering

Lösningar för vårddatalösningar har Microsoft Fabric stöd för komprimering genom design i hela medaljongarkitekturen för sjöhus. Data som matas in i deltatabellerna i medaljong för sjöhus lagras i ett komprimerat, kolumnformat med hjälp av parquet-filer. I inmatningsmönster, när filerna flyttas från mappen Mata in till mappen Process komprimeras de som standard efter att bearbetningen har lyckats. Du kan konfigurera eller inaktivera komprimeringen efter behov. För avbildnings- och anspråksfunktionerna kan inmatningspipelines även bearbeta rådatafiler i ett ZIP-komprimerat format.

Vårddatamodell

Som beskrivs i medaljongdesignen i sjöhus implementerar mellanlagringstabeller för bronssjöhus specialbyggda tabeller internt för vårddatalösningar och följer inte någon bransch- eller communitydatastandard.

Vårddatamodellen i silversjöhus baseras på FHIR R4-standard. Det tillhandahåller ett gemensamt dataspråk för dataanalytiker, dataforskare och utvecklare för att samarbeta och skapa datadrivna lösningar som förbättrar patientresultat och affärsresultat. Den stöder data inom olika hälso- och sjukvårdsdomäner, t.ex. kliniska, administrativa, ekonomiska och sociala. Vårddatamodellen samlar in data som definieras av FHIR-standarden och organiserar FHIR-resurserna med hjälp av tabeller och kolumner i sjöhuset.

Genom att platta ut FHIR-data till delta parquet-tabeller kan du använda välbekanta verktyg som T-SQL och Spark SQL för datautforskning och analys. För icke-kliniska data utanför FHIR-ramverket använder vi scheman från Azure Synapse databasmallarna. Den här implementeringen gör det möjligt att integrera icke-klinisk information, till exempel patientengagemangsdata, i patientprofilen.

Vårddatamodellen i silversjöhuset är utformad för att representera en komplett företagsvy över hälso- och sjukvårdsdata över affärsenheter och forskningsdomäner.

Dataursprung och spårbarhet

För att säkerställa ursprung och spårbarhet på post- och filnivå innehåller tabellerna för vårddatamodellen följande kolumner:

Kolumn	Beskrivning
msftCreatedDatetime	Tidsstämpel när posten först skapades i silversjöhus.
msftModifiedDatetime	Tidsstämpeln för postens senaste ändring.
msftFilePath	Fullständig sökväg till källfilen i bronssjöhuset, inklusive genvägar.
msftSourceSystem	Postens källsystem, som motsvarar det Namespace som anges i den enhetliga mappstrukturen.

Om ett fält normaliseras, plattas ut eller ändras bevaras det ursprungliga värdet i en {columnName}Orig kolumn. I tabellen Patient i silversjöhus hittar du till exempel följande kolumner:

Kolumn	Beskrivning
meta_lastUpdatedOrig	Bevarar det ursprungliga värdet i dess råa format (sträng eller datum) och lagrar det som en datetime.
idOrig och identifierOrig	ID och identifierare harmonierade i silversjöhuset.
birthdateOrig och deceasedDateTimeOrig	Bevarar de ursprungliga datumvärdena med en annan tidsstämpelformatering.

Om en kolumn plattas ut (till exempel meta_lastUpdated) eller konverteras till en sträng (till exempel meta_string) betecknar vi den med ett suffix som börjar med ett understreck (_).

Uppdateringshantering

När nya data matas in från brons- till silversjöhus jämför en uppdateringsåtgärd de inkommande posterna med måltabellerna i silversjöhus för varje resurs och tabelltyp. För FHIR-tabell i silversjöhus kontrollerar denna jämförelse både {FHIRResource}.id och {FHIRResource}.meta_lastUpdated värden mot kolumnerna id och lastUpdated i mellanlagringstabellen ClinicalFhir för bronssjöhus.

• Om en matchning identifieras och den inkommande posten är ny uppdateras silverposten.
• Om den inkommande posten är gammal ignoreras silverposten.
• Om ingen matchning hittas sätts den nya posten in i silversjöhuset.

Admin sjöhus

Admin sjöhuset hanterar konfigurationer mellan sjöhus, globala inställningar, statusrapportering och spårning för vårddatalösningar i Microsoft Fabric.

Global konfiguration

Admin sjöhusmappen systemkonfigurationer centraliserar de globala konfigurationsparametrarna. De tre konfigurationsfilerna innehåller förkonfigurerade värden för standarddistribution av alla funktioner för vårddatalösningar. Du behöver inte konfigurera om något av dessa värden för att köra exempeldata eller datapipelines för någon funktion.

Filen deploymentParametersConfiguration.json innehåller globala parametrar under activitiesGlobalParameters och aktivitetsspecifika parametrar för notebook-filer och pipelines under activities. Respektive funktionsvägledning innehåller specifik konfigurationsinformation för varje funktion. Filparametrarna validation_config.json förklaras i Datavalidering.

I följande tabell visas alla globala konfigurationsparametrar.

Avsnitt	Konfigurationsparametrar
activitiesGlobalParameters	•administration_lakehouse_id: Identifierare för admin sjöhus. •bronze_lakehouse_id: Identifierare för bronssjöhus. •silver_lakehouse_id: Identifierare för silversjöhus. •keyvault_name: Azure Key Vault-värde när det distribueras med Azure Marketplace-erbjudandet. •enable_hds_logs: Aktiverar loggning; standardvärdet inställt på true. •movement_config_path: Sökväg till filen file_orchestration_config. •bronze_imaging_delta_table_path: Fabric-sökväg för tabellen avbildningsmodalitet (om den är distribuerad). •bronze_imaging_table_schema_path: Fabric-sökväg för tabellen avbildningsschema (om den är distribuerad). •omop_lakehouse_id: Identifierare för guldsjöhus (om distribuerad).
Aktiviteter för healthcare#_msft_fhir_ndjson_bronze_ingestion	•source_path_pattern: OneLake-sökvägen till mappen Process. •move_failed_files_enabled: Flagga för att avgöra om en misslyckad fil ska flyttas från mappen Mata in till mappen Misslyckad. •compression_enabled: Flagga för att avgöra om de råa NDJSON-filerna kommer att komprimeras efter bearbetning. •target_table_name: Namn på det kliniska inmatningstabellen i bronssjöhuset. •target_tables_path: OneLake-sökvägen för alla delta-tabeller i bronssjöhuset. •max_files_per_trigger: Antal filer som bearbetas med varje körning. •max_structured_streaming_queries: Antal bearbetningsfrågor som kan köras parallellt. •checkpoint_path: OneLake-sökväg för kontrollpunktsmappen. •schema_dir_path: OneLake-sökväg för bronsschemamappen. •validation_config_key: Valideringskonfiguration på överordnad nivå. Mer information finns i Datavalidering. •file_extension: Tillägget av den inhämtade råfilen.
Aktiviteter för healthcare#_msft_bronze_silver_flatten	•source_table_name: Namn på det kliniska inmatningstabellen i bronssjöhuset. •config_path: OneLake sökväg till den tillplattade konfigurationsfilen. •source_tables_path: OneLake-sökvägen till källan för delta-tabeller i bronssjöhuset. •target_tables_path: OneLake-sökvägen till målet för delta-tabeller i silversjöhuset. •checkpoint_path: OneLake-sökväg för kontrollpunktsmappen. •schema_dir_path: OneLake-sökväg för bronsschemamappen. •max_files_per_trigger: Antal filer som bearbetas i varje körning. •max_bytes_per_trigger: Antal byte som bearbetas i varje körning. •max_structured_streaming_queries: Antal bearbetningsfrågor som kan köras parallellt.
Aktiviteter för healthcare#_msft_imaging_dicom_extract_bronze_ingestion	•byos_enabled: Flagga som avgör om inmatningen av DICOM-avbildningsdatauppsättningen i bronssjöhuset kommer från en extern lagringsplats via OneLake-genvägar. I det här fallet flyttas inte filerna till mappen Process som de annars skulle göra. •external_source_path: OneLake-sökväg för genvägsmapp Extern i bronssjöhuset. •process_source_path: OneLake-sökväg fö mapp Process i bronssjöhuset. •checkpoint_path: OneLake-sökväg för kontrollpunktsmappen. •move_failed_files: Flagga som avgör om en misslyckad fil flyttas från Mata in till mappen Misslyckad. •compression_enabled: Flagga som avgör om de råa NDJSON-filerna komprimeras efter bearbetning. •max_files_per_trigger: Antal filer som bearbetas i varje körning. •num_retries: Antal försök för varje filbearbetning före ett fel.
Aktiviteter för healthcare#_msft_imaging_dicom_fhir_conversion	•fhir_ndjson_files_root_path: OneLake-sökvägen till mappen Process. •avro_schema_path: OneLake-sökväg för silverschemamappen. •dicom_to_fhir_config_path: OneLake-sökväg för mappning av konfiguration från DICOM-metataggar till FHIR-resursen ImagingStudy. •checkpoint_path: OneLake-sökväg för kontrollpunktsmappen. •max_records_per_ndjson: Antal poster som bearbetats i en enda NDJSON-fil i varje körning. •subject_id_type_code: Värdekod för patientens medicinska nummer i DICOM-metadata. Standardvärdet anges till MR, vilket motsvarar Medical Record Number i FHIR. •subject_id_type_code_system: Kodsystemet för patientens medicinska nummer i DICOM-metadata. •subject_id_system: Objekt-ID för kodsystemet för patientens medicinska nummer i DICOM-metadata.
Aktiviteter för healthcare#_msft_omop_silver_gold_transformation	•vocab_path: OneLake-sökväg till referensdatamappen i bronssjöhuset där datauppsättningarna för OMOP-vokabulär lagras. •vocab_checkpoint_path: OneLake-sökväg för kontrollpunktsmappen. •omop_config_path: OneLake-sökväg för kartläggningskonfiguration från silversjöhuset till OMOP guldsjöhuset.

Tabellen BusinessEvents

Deltatabellen BusinessEvents samlar in alla valideringsfel, varningar och andra meddelanden eller undantag som kan inträffa under inmatnings- och omvandlingsprocesser. Använd den här tabellen för att övervaka körningsförloppet för inmatning på både användar- och funktionsnivå, i stället för enbart på systemloggnivå. Den identifierar till exempel vilka råfiler som introducerade valideringsfel eller varningar under inmatningen. För loggar på systemnivå och för att övervaka Apache Spark-aktiviteter i alla lakehouses kan du använda Fabric övervakningshubb, med alternativet att integrera Azure Log Analytics.

I följande tabell visas kolumnerna i tabellen BusinessEvent:

Kolumn	Beskrivning
id	Unik identifierare (GUID) för varje rad i tabellen.
activityName	Namnet på aktiviteten/notebook-filen som genererade felet och/eller valideringsfelet eller varningen.
targetTableName	Måltabell för dataaktiviteten som genererade händelsen.
targetFilePath	Sökväg för målfilen för dataaktiviteten som genererade händelsen.
sourceTableName	Källtabell för dataaktiviteten som genererade händelsen.
sourceLakehouseName	Källsjöhus för dataaktiviteten som genererade händelsen.
targetLakehouseName	Målsjöhus för dataaktiviteten som genererade händelsen.
sourceFilePath	Sökväg för källfilen för dataaktiviteten som genererade händelsen.
runId	Kör ID för dataaktiviteten som genererade händelsen.
severity	Allvarlighetsgrad för händelsen, som kan ha något av följande två värden: Error eller Warning. Error innebär att du måste lösa den här händelsen innan du fortsätter med dataaktiviteten. Warning fungerar som en passiv avisering, som i allmänhet inte kräver någon omedelbar åtgärd.
eventType	Skiljer mellan händelser som genereras av valideringsmotorn och allmänna händelser som genereras av användare eller ohanterade/systemundantag som användarna vill visa för BusinessEvent-tabellen.
recordIdentifier	Identifierare för källposten. Den här kolumnen skiljer sig från id-kolumnen eftersom den representerar en ny och unik identifierare för varje händelse i tabellen BusinessEvents.
recordIdentifierSource	Källsystem för identifieraren för källposten. Om källsystemet till exempel är EMR fungerar EMR-namnet eller URL:en som källa.
active	Flagga som anger om händelsen (fel eller varning) har lösts.
message	Beskrivande meddelande för händelsefelet eller varningen.
exception	Meddelande om ohanterad/systemundantag.
customDimensions	Gäller när källdata för verifieringen eller undantaget inte är en diskret kolumn i en tabell. Om källdata till exempel är ett attribut i ett JSON-objekt som sparats som en sträng i en enda kolumn anges det fullständiga JSON-objektet som den anpassade dimensionen.
eventDateTime	Tidsstämpel där händelsen eller undantaget genereras.

Datavalidering

Datavalideringsmotorn i vårddatalösningar i Microsoft Fabric säkerställer att rådata uppfyller fördefinierade kriterier innan de matas in i bronssjöhuset. Du kan konfigurera valideringsreglerna på tabell- och kolumnnivå i bronssjöhuset. För närvarande implementeras dessa regler exklusivt under inmatningsprocessen, från råfiler till deltatabeller i bronssjöhuset.

När en råfil bearbetas gäller valideringsreglerna på inmatningsnivå. Det finns två allvarlighetsgrader för validering: Error och Warning. Om en valideringsregel är inställd på Error stoppas pipelinen när regeln överträds och den felaktiga filen flyttas till mappen Misslyckade. Om allvarlighetsgraden är inställd på Warning fortsätter pipelinen bearbetningen och filen flyttas till mappen Process. I båda fallen skapas poster som återspeglar felen eller varningarna i tabellen BusinessEvents i admin sjöhus.

Tabellen BusinessEvents samlar in loggar och händelser på affärsnivå i alla sjöhus för alla aktiviteter, notebook-filer eller datapipelines inom vårddatalösningar. Den aktuella konfigurationen tillämpar emellertid endast valideringsregler under inmatningen, vilket kan leda till att vissa kolumner i tabellen BusinessEvents förblir tomma för valideringsfel och varningar.

Du kan konfigurera dataverifieringsreglerna i filen validation_config.json i admin sjöhus. Som standard anges kolumnerna meta.lastUpdated och id tabellen ClinicalFhir i bronssjöhuset efter behov. Dessa kolumner är avgörande för att avgöra hur uppdateringar och inlägg hanteras i silversjöhus, som förklaras i Uppdateringshantering.

Följande tabell listar konfigurationsparametrarna för datavalidering:

Konfigurationstyp	Parametrar
Sjöhusnivå	bronze: Omfattningen av noderna för valideringar och postidentifierare. I det här fallet anges värdet till bronssjöhuset.
Valideringar	•validationType: Valideringstypen exists kontrollerar om ett värde för det konfigurerade attributet anges i råfilen (källdata). •attributeName: Namn på attributet som valideras. •validationMessage: Meddelande som beskriver valideringsfelet eller varningen. •severity: Anger nivån på problemet, som kan vara antingen Error eller Warning. •tableName: Namn på tabellen som valideras. En asterisk (*) anger att den här regeln gäller för alla tabeller inom ramen för det sjöhuset.
recordIdentifier	•attributeName: Postidentifierare för käll-/råfilen som placeras i kolumnen recordIdentifier i tabellen BusinessEvent. •jsonPath: Valfritt värde som representerar JSON-sökvägen för en kolumn eller ett attribut för värdet som ska placeras i kolumnen recordIdentifier i tabellen BusinessEvent. Det här värdet gäller när källdata för verifieringen inte är en diskret kolumn i en tabell. Om källdata till exempel är ett attribut i ett JSON-objekt som lagras som en sträng i en enda kolumn, dirigerar JSON-sökvägen till det specifika attribut som fungerar som postidentifierare.

Relaterad information

• Översikt över vårddatalösningar i Microsoft Fabric
• Översikt över vårddatalösningar i Microsoft Fabric-lösningsarkitektur