Microsoft Fabric 中的医疗保健数据解决方案中的数据体系结构和管理
医疗保健数据解决方案框架使用专门的奖牌体系结构来简化数据组织和处理。 此设计可确保数据质量和结构的持续改进，使您能够更有效地管理医疗保健数据。 本文探索了此体系结构的关键功能和优势，全面概述了如何在此框架中管理数据。
奖牌湖屋设计
如解决方案体系结构中所述，医疗保健数据解决方案使用奖牌湖屋体系结构跨多个层组织和处理数据。 随着数据在每一层中移动，其结构和质量会不断改进。 医疗保健数据解决方案中的奖牌湖屋设计的核心由以下关键湖屋组成：
铜牌湖屋：也称为原始 区域，是以原始文件格式组织源数据的第一层。 它将源文件引入到 OneLake 中和/或从本机存储源创建快捷方式。 它还将来自源的结构化和半结构化数据存储在增量表（也称为暂存 表）中。 这些表经过压缩和列索引，以支持高效的转换和数据处理。 此层中的数据通常是仅追加且不可变的。
铜牌湖屋中的文件（无论是保留的文件还是快捷方式）充当事实来源。 它们为医疗保健数据解决方案中整个数据资产的数据世系奠定了基础。 铜牌层中的暂存表通常由几列组成，旨在将每种数据模态和格式保存在单个表中（例如，ClinicalFhir 和 ImagingDicom 表）。 出于以下原因，不应扩展、自定义或生成对铜牌湖屋中的这些暂存表的依赖项：
- 内部实现：暂存表特定于 Microsoft Fabric 中的医疗保健数据解决方案在内部实现。 其架构专为医疗保健数据解决方案而生成，不遵循任何行业或社区数据标准。
- 暂时性存储：在处理数据并将其从铜牌湖屋暂存表转换为银牌湖屋中的平展和规范化增量表后，铜牌暂存表数据将被视为可以清除。 此模型可确保成本和存储效率，并减少铜牌湖屋中源文件和暂存表之间的数据冗余。
银牌湖屋：也称为扩充 区域，银牌湖屋优化来自铜牌湖屋的数据。 它包括验证检查和扩充技术，以提高下游分析的数据准确性。 与铜牌层不同，银牌湖屋数据基于确定性 ID 和修改时间戳使用规则来管理记录插入和更新。
金牌湖屋：也称为特选 区域，金牌湖屋进一步优化来自银牌湖屋的数据以满足特定的业务和分析要求。 此层是高质量聚合数据集的主要来源，可进行全面分析和见解提取。 虽然医疗保健数据解决方案在每次部署时部署一个铜牌湖屋和一个银牌湖屋，但您可以拥有多个金牌湖屋来为各个业务部门和角色提供服务。
管理员湖屋：管理员湖屋包含用于跨湖屋层的数据治理和可追溯性的文件，包括存储在 BusinessEvent 表中的全局配置和验证错误。 若要了解详细信息，请参阅管理员湖屋。
统一文件夹结构
医疗保健和生命科学客户处理来自各种源系统、多种数据模态和文件格式（包括以下文件格式）的大量数据：
- 临床模态：FHIR NDJSON 文件、FHIR 捆绑包和 HL7。
- 成像模态：DICOM、NIFTI 和 NDPI。
- 基因组学模态：BAM、BCL、FASTQ 和 VCF。
- 索赔：CCLF 和 CSV。
其中：
- FHIR：快速医疗保健互操作性资源
- HL7：国际保健七级
- DICOM：医学数字成像和通信
- NIFTI：神经影像信息学技术倡议
- NDPI：纳米维病理成像
- BAM：二进制比对图
- BCL：基本调用
- FASTQ：一种基于文本的格式，用于存储生物序列及其相应的质量分数
- VCF：变体调用格式
- CCLF：索赔和索赔行馈送
- CSV：逗号分隔的值
Microsoft Fabric 中的 OneLake 为您的组织提供一个逻辑数据湖。 Microsoft Fabric 中的医疗保健数据解决方案提供统一的文件夹结构，有助于跨各种模态和格式组织数据。 此结构简化了数据引入和处理，同时在铜牌湖屋中在源文件和源系统级别维护数据世系。
六个顶级文件夹包括：
- External
- Failed
- Ingest
- Process
- ReferenceData
- SampleData
子文件夹按如下方式组织：
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\DDFiles\Process\[DataModality]\[DataFormat]\[Namespace]\YYYY\MM\DD
文件夹描述
命名空间（必需）：标识接收文件的源系统，这对于确保每个源系统的 ID 唯一性至关重要。
引入文件夹：用作放置文件夹或队列文件夹。 此文件夹允许您将要引入的文件放置在适当的模态和格式子文件夹中。 开始引入后，文件将转移到相应的 Process 文件夹，如果失败，将转移到 Failed 文件夹。
处理文件夹：每个模态和格式组合中所有成功处理的文件的最终目标。 此文件夹基于处理日期遵循
YYYY/MM/DD模式。 文件夹分区遵循使用 Azure Data Lake Storage 的最佳做法以实现改进组织、筛选搜索结果、自动化和潜在并行处理。外部文件夹：充当自带存储 (BYOS) 快捷方式文件夹的父文件夹。 默认部署为索赔、临床、基因组学和成像模态提供建议性文件夹结构。 成像和临床模态配置了默认格式和命名空间，以支持 Azure Health Data Services 中的 DICOM 和 FHIR 服务。 仅当您打算将数据快速引入 OneLake 中时，此格式才适用。 Microsoft Fabric 中的医疗保健数据解决方案对这些快捷方式文件夹中的文件具有只读访问权限。
失败文件夹：如果在 Ingest 或 Process 文件夹中移动或处理文件时出现故障，则受影响的文件将移至与其模态和格式组合相对应的 Failed 文件夹。 在管理员湖屋的 BusinessEvent 表中记录错误。 此文件夹基于处理/失败日期使用
YYYY/MM/DD模式。 此文件夹中的文件不会清除，而是会继续保留在此处，直到您使用相同的初始引入模式修复和重新引入它们。示例数据文件夹：包括综合数据集、参考数据集和/或公共数据集。 默认部署为多种模态和格式组合提供示例数据，以便于在部署后立即执行笔记本和管道。 此文件夹不会创建任何
YYYY/MM/DD子文件夹。参考数据文件夹：包含来自公共或用户特定来源的参考数据集和父数据集。 此文件夹不会创建任何
YYYY/MM/DD子文件夹。 默认部署为 OMOP（观察性医疗结果伙伴关系）词汇提供建议的文件夹结构。
数据引入模式
基于前面概述的统一文件夹结构，Microsoft Fabric 中的医疗保健数据解决方案支持两种不同的引入模式。 在这两种情况下，解决方案都使用 Spark 中的结构化流式处理来处理相应文件夹中的传入文件。
引入模式
此模式是一种简单的方法，其中要引入的文件将放置在适当的模态、格式和命名空间下的 Ingest 文件夹中。 引入管道监视此文件夹中新放置的文件，并将其移动到相应的 Process 文件夹以进行处理。 如果成功将文件数据引入到铜牌湖屋暂存表中，该文件将进行压缩，并基于处理时间遵循 YYYY/MM/DD 模式使用时间戳前缀保存在 Process 文件夹中。 此前缀可确保文件名的唯一性。 您可以根据需要配置或禁用压缩。
如果文件处理失败，则对于每个模态和格式组合，失败的文件将从 Ingest 文件夹移动到 Failed 文件夹，并且错误将记录到管理员湖屋的 BusinessEvent 表中。
此引入模式非常适合每日增量引入或将数据物理移动到 Azure Data Lake Storage OneLake 时的情况。
自带存储 (BYOS) 模式
有时，Azure 或其他云存储服务中可能已经存在数据和文件，这些文件具有现有的下游实现和依赖项。 在医疗保健和生命科学中，数据量可以达到数 TB 甚至数 PB，尤其是医学成像和基因组学。 出于这些原因，直接引入模式可能不可行。
当您在 Azure 或其他支持 S3 协议的云和本地存储中已有大量可用数据时，我们建议使用 BYOS 模式进行历史数据引入。 此模式使用 Fabric 中的 OneLake 快捷方式和铜牌湖屋中的 External 文件夹来就地处理源文件。 它消除了移动或复制文件的需要，并避免了产生出口费用和数据重复。
尽管 BYOS 引入模式提供了效率，但您应注意以下注意事项：
- 不监视就地文件更新（文件中的内容更新）。 应为任何更新创建新文件（具有不同的名称），因为引入管道仅监视新文件。 此限制与 Spark 中的结构化流式处理相关联。
- 不应用数据压缩。
- BYOS 模式不会基于
YYYY/MM/DD模式创建任何优化的文件夹结构。 - 如果文件处理失败，失败的文件不会移动到 Failed 文件夹中。 但是，在管理员湖屋的 BusinessEvent 表中记录错误。
- 假定源数据是只读的。
- 引入后无法控制源数据的世系或可用性。
数据压缩
Microsoft Fabric 中的医疗保健数据解决方案支持在整个奖牌湖屋设计中按设计压缩。 在整个奖牌湖屋中引入到增量表中的数据使用 Parquet 文件以压缩的列格式存储。 在引入模式中，当文件从 Ingest 文件夹移动到 Process 文件夹时，默认情况下这些文件会在成功处理后进行压缩。 您可以根据需要配置或禁用压缩。 对于成像和索赔功能，引入管道还可以处理 ZIP 压缩格式的原始文件。
医疗保健数据模型
如奖牌湖屋设计中所述，铜牌湖屋暂存表在内部实现用于医疗保健数据解决方案的专用表，并且不遵循任何行业或社区数据标准。
银牌湖屋中的医疗保健数据模型基于 FHIR R4 标准。 它为数据分析师、数据科学家和开发人员提供了一种通用数据语言，用于协作和生成数据驱动型解决方案，以改善患者治疗效果和业务绩效。 它支持不同医疗保健领域的数据，例如临床、行政、财务和社交。 医疗保健数据模型捕获 FHIR 标准定义的数据，并在湖屋中使用表和列来组织 FHIR 资源。
通过将 FHIR 数据平展到 delta parquet 表中，可以使用 T-SQL 和 Spark SQL 等熟悉的工具进行数据探索和分析。 对于 FHIR 范围之外的非临床数据，我们使用 Azure Synapse 数据库模板中的架构。 此实施允许将非临床信息（例如患者参与数据）集成到患者个人资料中。
银牌湖屋中的医疗保健数据模型旨在表示跨业务部门和研究领域的医疗保健数据的端到端企业视图。
数据世系和可追溯性
为了确保记录和文件级别的世系和可追溯性，医疗保健数据模型表包括以下列：
| Column | 描述 |
|---|---|
msftCreatedDatetime |
首次在银牌湖屋中创建记录时的时间戳。 |
msftModifiedDatetime |
上次修改记录的时间戳。 |
msftFilePath |
铜牌湖屋中源文件的完整路径，包括快捷方式。 |
msftSourceSystem |
记录的源系统，与在统一文件夹结构中指定的 Namespace 相对应。 |
如果对字段进行规范化、展平或修改，则原始值将保留在 {columnName}Orig 列中。 例如，在银牌湖屋 Patient 表中，您可以找到以下列：
| Column | 描述 |
|---|---|
meta_lastUpdatedOrig |
以原始格式（字符串或日期）保留原始值，并将其存储为日期/时间。 |
idOrig 和 identifierOrig |
ID 和标识符在银牌湖屋中协调一致。 |
birthdateOrig 和 deceasedDateTimeOrig |
使用不同的时间戳格式保留原始日期值。 |
如果列展平（例如，meta_lastUpdated）或转换为字符串（例如，meta_string），我们将使用以下划线 (_) 开头的后缀表示它。
更新处理
当新数据从铜牌湖屋引入到银牌湖屋时，更新操作会针对每种资源和表类型将传入记录与银牌湖屋中的目标表进行比较。 对于银牌湖屋中的 FHIR 表，此比较会针对 ClinicalFhir 铜牌湖屋暂存表中的 id 和 lastUpdated 列检查 {FHIRResource}.id 和 {FHIRResource}.meta_lastUpdated 值。
- 如果识别到匹配并且传入记录为新记录，将更新银牌记录。
- 如果传入记录为旧记录，将忽略银牌记录。
- 如果未找到匹配，新记录将插入到银牌湖屋中。
管理员湖屋
管理员湖屋管理 Microsoft Fabric 中医疗保健数据解决方案的跨湖屋配置、全局配置、状态报告和跟踪。
全局配置
管理员湖屋 system-configurations 文件夹将全局配置参数集中在一起。 三个配置文件包含所有医疗保健数据解决方案功能的默认部署的预配置值。 您无需重新配置其中任何值，即可为任何功能运行示例数据或数据管道。
deploymentParametersConfiguration.json 文件在 activitiesGlobalParameters 下包含全局参数，在 activities 下包含笔记本和管道的活动特定参数。 相应的功能指南涵盖了每个功能的特定配置详细信息。 数据验证中解释了 validation_config.json 文件参数。
下表列出了所有全局配置参数。
| 客户细分 | 配置参数 |
|---|---|
activitiesGlobalParameters |
•administration_lakehouse_id：管理员湖屋标识符。• bronze_lakehouse_id：铜牌湖屋标识符。• silver_lakehouse_id：银牌湖屋标识符。• keyvault_name：使用 Azure 市场产品/服务部署时的 Azure Key Vault 值。• enable_hds_logs：启用日志记录；默认值设置为 true。• movement_config_path：file_orchestration_config 文件的路径。• bronze_imaging_delta_table_path：成像模态表的 Fabric 路径（如果已部署）。• bronze_imaging_table_schema_path：成像模态架构的 Fabric 路径（如果已部署）。• omop_lakehouse_id：金牌湖屋标识符（如果已部署）。 |
| healthcare#_msft_fhir_ndjson_bronze_ingestion 的活动 | •source_path_pattern：Process 文件夹的 OneLake 路径。• move_failed_files_enabled：用于确定失败文件是否应从 Ingest 文件夹移动到 Failed 文件夹的标志。• compression_enabled：用于确定原始 NDJSON 文件在处理后是否压缩的标志。• target_table_name：铜牌湖屋中临床引入表的名称。• target_tables_path：铜牌湖屋中所有增量表的 OneLake 路径。• max_files_per_trigger：每次运行时处理的文件数。• max_structured_streaming_queries：可以并行运行的处理查询数。• checkpoint_path：检查点文件夹的 OneLake 路径。• schema_dir_path：铜牌架构文件夹的 OneLake 路径。• validation_config_key：父级验证配置。 有关详细信息，请参阅数据验证。• file_extension：引入的原始文件的扩展名。 |
| healthcare#_msft_bronze_silver_flatten 的活动 | •source_table_name：铜牌湖屋中临床引入表的名称。• config_path：已展平的配置文件的 OneLake 路径。• source_tables_path：铜牌湖屋中源增量表的 OneLake 路径。• target_tables_path：银牌湖屋中目标增量表的 OneLake 路径。• checkpoint_path：检查点文件夹的 OneLake 路径。• schema_dir_path：铜牌架构文件夹的 OneLake 路径。• max_files_per_trigger：每次运行时处理的文件数。• max_bytes_per_trigger：每次运行时处理的字节数。• max_structured_streaming_queries：可以并行运行的处理查询数。 |
| healthcare#_msft_imaging_dicom_extract_bronze_ingestion 的活动 | •byos_enabled：用于确定铜牌湖屋中 DICOM 成像数据集的引入是否通过 OneLake 快捷方式源自外部存储位置。 在这种情况下，文件不会像其他情况那样移动到 Process 文件夹。• external_source_path：铜牌湖屋中快捷方式 External 文件夹的 OneLake 路径。• process_source_path：铜牌湖屋中 Process 文件夹的 OneLake 路径。• checkpoint_path：检查点文件夹的 OneLake 路径。• move_failed_files：用于确定失败文件是否从 Ingest 移动到 Failed 文件夹的标志。• compression_enabled：用于确定原始 NDJSON 文件在处理后是否压缩的标志。• max_files_per_trigger：每次运行时处理的文件数。• num_retries：出错前每个文件处理的重试次数。 |
| healthcare#_msft_imaging_dicom_fhir_conversion 的活动 | •fhir_ndjson_files_root_path：Process 文件夹的 OneLake 路径。• avro_schema_path：银牌架构文件夹的 OneLake 路径。• dicom_to_fhir_config_path：用于将配置从 DICOM 元标记映射到 FHIR ImagingStudy 资源的 OneLake 路径。• checkpoint_path：检查点文件夹的 OneLake 路径。• max_records_per_ndjson：每次运行时单个 NDJSON 文件中处理的记录数。• subject_id_type_code：DICOM 元数据中患者医疗编号的值代码。 默认值设置为 MR，与 FHIR 中的 Medical Record Number 相对应。• subject_id_type_code_system：DICOM 元数据中患者医疗编号的代码系统。• subject_id_system：DICOM 元数据中患者医疗编号的代码系统的对象 ID。 |
| healthcare#_msft_omop_silver_gold_transformation 的活动 | •vocab_path：铜牌湖屋中存储 OMOP 词汇数据集的参考数据文件夹的 OneLake 路径。• vocab_checkpoint_path：检查点文件夹的 OneLake 路径。• omop_config_path：用于将配置从银牌湖屋映射到金牌 OMOP 湖屋的 OneLake 路径。 |
BusinessEvents 表
BusinessEvents 增量表捕获在引入和转换流程中可能发生的所有验证错误、警告和其他通知或异常。 使用此表可以在用户和功能级别（而不仅仅是在系统日志级别）监视引入执行进度。 例如，它可以识别哪些原始文件在引入期间引入了验证错误或警告。 对于系统级别日志，若要监视所有湖屋中的 Apache Spark 活动，您可以使用 Fabric 监视中心，其中包含用于集成 Azure Log Analytics 的选项。
下表列出了 BusinessEvent 表中的列：
| Column | 描述 |
|---|---|
id |
表中每行的唯一标识符 (GUID)。 |
activityName |
生成失败和/或验证错误或警告的活动/笔记本的名称。 |
targetTableName |
生成事件的数据活动的目标表。 |
targetFilePath |
生成事件的数据活动的目标文件路径。 |
sourceTableName |
生成事件的数据活动的源表。 |
sourceLakehouseName |
生成事件的数据活动的源湖屋。 |
targetLakehouseName |
生成事件的数据活动的目标湖屋。 |
sourceFilePath |
生成事件的数据活动的源文件路径。 |
runId |
生成事件的数据活动的运行 ID。 |
severity |
事件的严重性级别，可能具有以下两个值之一：Error 或 Warning。 Error 表示必须先解决此事件，然后才能继续数据活动。 Warning 用作被动通知，通常不需要立即采取行动。 |
eventType |
区分由验证引擎生成的事件和由用户生成的一般事件，或者用户希望显示到 BusinessEvent 表的未处理/系统异常。 |
recordIdentifier |
源记录的标识符。 此列与 id 列不同，因为它表示 BusinessEvents 表中每个事件的全新唯一标识符。 |
recordIdentifierSource |
源记录的标识符的源系统。 例如，如果源系统是 EMR，则 EMR 名称或 URL 将用作源。 |
active |
指示事件（错误或警告）是否已解决的标志。 |
message |
事件错误或警告的描述性消息。 |
exception |
未处理/系统异常消息。 |
customDimensions |
当验证或异常的源数据不是表中的离散列时适用。 例如，当源数据是 JSON 对象中作为字符串保存在单个列中的属性时，完整的 JSON 对象将作为自定义维度提供。 |
eventDateTime |
生成事件或异常的时间戳。 |
数据验证
Microsoft Fabric 中医疗保健数据解决方案中的数据验证引擎可确保原始数据在引入到铜牌湖屋之前满足预定义的标准。 您可以在铜牌湖屋中的表和列级别配置验证规则。 目前，这些规则仅在引入流程中实施，从原始文件到铜牌湖屋中的增量表。
处理原始文件时，验证规则在引入级别应用。 验证有两个严重性级别：Error 和 Warning。 如果验证规则设置为 Error，则在违反规则时管道将停止，并且错误文件将移动到 Failed 文件夹。 如果严重性设置为 Warning，则管道将继续处理，并且文件将移动到 Process 文件夹。 在这两种情况下，都会在管理员湖屋中的 BusinessEvents 表中创建反映错误或警告的条目。
BusinessEvents 表捕获医疗保健数据解决方案中任何活动、笔记本或数据管道的所有湖屋中的业务级别日志和事件。 但是，当前配置仅在引入期间强制执行验证规则，这可能会导致 BusinessEvents 表中的某些列仍未填充验证错误和警告。
您可以在管理员湖屋中的 validation_config.json 文件中配置数据验证规则。 默认情况下，铜牌湖屋的 ClinicalFhir 表中的 meta.lastUpdated 和 id 列设置为必填。 这些列对于确定如何在银牌湖屋中管理更新和插入至关重要，如更新处理中所述。
下表列出了数据验证的配置参数：
| 配置类型 | 参数设置 |
|---|---|
| 湖屋级别 | bronze：验证和记录标识符节点的范围。 在本例中，该值设置为铜牌湖屋。 |
| 验证 | •validationType：exists 验证类型检查原始文件（源数据）中是否提供了配置属性的值。• attributeName：要验证的属性的名称。• validationMessage：描述验证错误或警告的消息。• severity：指示问题的级别，可以是 Error 或 Warning。• tableName：要验证的表的名称。 星号 (*) 表示此规则适用于该湖屋范围内的所有表。 |
recordIdentifier |
•attributeName：放置在 BusinessEvent 表的 recordIdentifier 列中的源/原始文件的记录标识符。• jsonPath：表示要放置在 BusinessEvent 表的 recordIdentifier 列中的值的列或属性的 JSON 路径。 此值在验证的源数据不是表中的离散列时适用。 例如，如果源数据是 JSON 对象中作为字符串存储在单个列中的属性，则 JSON 路径将定向到用作记录标识符的特定属性。 |