医疗保健数据解决方案中的 DICOM 数据转换的使用注意事项
本文概述了在使用 DICOM 数据转换功能之前要查看的关键注意事项。 了解这些因素可确保在您的医疗保健数据解决方案环境中顺利集成和运行。 此资源还可帮助您有效地应对该功能的一些潜在挑战和限制。
引入文件大小
目前，ZIP 文件的逻辑大小限制为 8 GB，本机 DCM 文件的逻辑大小限制为 4 GB。 如果您的文件超过这些限制，可能会遇到更长的执行时间或引入失败的情况。 我们建议将 ZIP 文件拆分为更小的部分（小于 4 GB），以确保成功执行。 对于大于 4 GB 的本机 DCM 文件，请确保根据需要扩展 Spark 节点（执行程序）。
DICOM 标记提取
我们优先推广 铜牌湖屋 ImagingDicom delta 表中 的 29 个标签，原因如下：
- 这 29 个标记对于 DICOM 数据的常规查询和探索至关重要，例如模态和横向性。
- 这些标记对于在后续执行步骤中生成和填充银牌 (FHIR) 和金牌 (OMOP) 增量表是必需的。
您可以扩展和推广您感兴趣的其他 DICOM 标记。 但是，DICOM 数据转换笔记本不会自动识别或处理您添加到 铜牌湖屋中的 ImagingDicom delta 表中的任何其他 DICOM 标记列。 您需要单独处理额外列。
铜牌湖屋中的追加模式
所有新摄取的 DCM（或 ZIP）文件都附加到 铜牌湖屋的 ImagingDicom delta 表中。 对于每个成功摄取的 DCM 文件，我们在 ImagingDicom delta 表中创建一个新的记录条目 。 没有用于铜牌湖屋级别的合并或更新操作的业务逻辑。
ImagingDicom delta 表反映了 DICOM 实例级别的每个提取的 DCM 文件，应被视为如此。 如果将同一 DCM 文件再次提取到 Ingest 文件夹中，我们将向同一文件的 ImagingDicom delta 表添加另一个条目 。 但是，由于 Unix 前缀时间戳，文件名不同。 根据摄取日期，文件可能会放置在不同的 YYYY\MM\DD 文件夹中。
OMOP 版本和映像扩展
金牌湖屋的当前实施基于观察性医疗结果伙伴关系 (OMOP) Common Data Model 版本 5.4。 OMOP 尚无规范的扩展来支持成像数据。 因此，该功能实施基于成像的观察性研究的医学成像数据标准化开发：OMOP Common Data Model 扩展中建议的扩展。 此次扩展是 2024 年 2 月 5 日发布的成像研究领域的最新提案。 当前版本的 DICOM 数据转换功能仅限于金牌湖屋中的 Image_Occurrence 表。
Spark 中的结构化流式处理
结构化流式处理是基于 Spark SQL 引擎生成的可缩放且容错的流处理引擎。 您可以使用表达静态数据批处理计算的相同方式来表达您的流式处理计算。 该系统通过检查点和预写日志确保端到端的容错保证。 若要了解有关结构化流式处理的详细信息，请参阅结构化流式处理编程指南 (v3.5.1)。
我们使用 ForeachBatch 来处理增量数据。 此方法应用任意操作，并将逻辑写入流式处理查询的输出中。 对流式处理查询的每个微批处理的输出数据执行查询。 在 DICOM 数据转换功能中，结构化流式处理用于以下执行步骤：
| 执行步骤 | 检查点文件夹位置 | 跟踪的对象 |
|---|---|---|
| 将 DICOM 元数据提取到铜牌湖屋中 | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
铜牌湖屋下的 Files\Process\Imaging\DICOM\YYYY\MM\DD DCM 文件。 |
| 将 DICOM 元数据转换为 FHIR 格式 | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Delta 表 ImagingDicom 在铜牌湖屋。 |
| 将数据引入到铜牌湖屋 ImagingStudy 增量表中 | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
铜牌湖屋下的 Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy FHIR NDJSON 文件。 |
| 将数据引入到银牌湖屋 ImagingStudy 增量表中 | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
铜牌湖屋中的增量表 ImagingStudy。 |
小费
您可以使用 OneLake 文件资源管理器查看表中列出的文件和文件夹的内容。 有关详细信息，请参阅使用 OneLake 文件资源管理器。
铜牌湖屋中的分组模式
当您将新记录从 铜牌湖屋的 ImagingDicom delta 表提取到 铜牌湖屋的 ImagingStudy delta 表时，将应用组模式。 DICOM 数据转换功能按研究级别对 ImagingDicom delta 表中的所有 实例级记录进行分组。 它为每个 DICOM 研究创建一个记录作为 ImagingStudy，然后将该记录插入到铜牌湖屋中的 ImagingStudy 增量表中。
银牌湖屋中的更新插入模式
upsert 操作根据以下 {FHIRResource}.id因素比较青铜色和银色湖仓一体之间的 FHIR 增量表：
- 如果识别到匹配，将使用新的铜牌记录更新银牌记录。
- 如果没有识别到匹配，则铜牌记录将作为新记录插入到银牌湖屋中。
我们使用此模式在银色湖屋 ImagingStudy 表中创建资源。
ImagingStudy 限制
当您在同一批处理执行中从同一 DICOM 研究中引入 DCM 文件，upsert 操作将按预期工作。 但是，如果您稍后摄取更多 DCM 文件（来自不同批次），这些文件属于之前摄取到银牌湖屋中的同一 DICOM 研究，则摄取会导致插入 操作。 该进程不执行 Update 操作。
发生此 Insert 操作是因为笔记本在每次批处理执行中为 ImagingStudy {FHIRResource}.id 创建一个新 操作。 此新 ID 与上一批处理中的 ID 不匹配。 因此，您会在银牌表中看到两条 ImagingStudy 记录，具有不同的 ImagingStudy.id 值。 这些 ID 与其各自的批处理执行相关，但属于同一 DICOM 研究。
解决方法是完成批处理执行，并基于唯一 ID 的组合将两个 ImagingStudy 记录合并到银牌湖屋中。 但是，不要使用 ImagingStudy.id 进行合并。 相反，您可以使用其他 ID（如 [studyInstanceUid (0020,000D)] and [patientId (0010,0020)] ）来合并记录。
OMOP 跟踪方法
healthcare#_msft_omop_silver_gold_transformation 笔记本使用 OMOP API 来监控 silver 湖屋 delta 表中的变化。 它标识新修改或添加的记录，这些记录需要更新插入到金牌湖屋增量表中。 此流程称为水印。
OMOP API 比较 {Silver.FHIRDeltatable.modified_date} 和 {Gold.OMOPDeltatable.SourceModifiedOn} 之间的日期和时间值，以确定自上次执行笔记本以来修改或添加的增量记录。 但是，此 OMOP 跟踪方法并不适用于金牌湖屋中的所有增量表。 以下表不会从银牌湖屋中的增量表中引入：
- concept
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- vocabulary
这些黄金 delta 表使用示例数据部署 OMOP 中包含的词汇数据进行填充。 此文件夹中的词汇数据集使用 Spark 中的结构化流式处理进行管理。
金牌湖屋中的更新插入模式
金牌湖屋中的更新插入模式与银牌湖屋中的模式不同。 OMOP healthcare#_msft_omop_silver_gold_transformation 笔记本使用的 API 为黄金湖屋的增量表中的每个条目创建新 ID。 API 在引入新记录或将其从银牌湖屋转换到金牌湖屋时创建这些 ID。 OMOP API 还维护新创建的 ID 与其在银牌湖屋增量表中对应的内部 ID 之间的内部映射。
API 的工作原理如下：
如果首次将记录从银牌增量表转换到黄金增量表，它会在 OMOP 金牌湖屋中生成一个新 ID，并将其映射到银牌湖屋中的原始新 ID。 然后，它将记录插入到具有新生成的 ID 的金牌增量表中。
如果银牌湖屋中的同一记录经过一些修改并再次引入到金牌湖屋中，则 OMOP API 将识别金牌湖屋中的现有记录（使用映射信息）。 然后，它使用之前生成的相同 ID 更新金牌湖屋中的记录。
金牌湖屋中新生成的 ID (ADRM_ID) 与每个 OMOP 增量表的原始 ID (INTERNAL_ID) 之间的映射存储在 OneLake Parquet 文件中。 您可以在以下文件路径中找到 parquet 文件：
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
您还可以在 Spark 笔记本中查询 parquet 文件以查看映射。
银色的 ImagingMetastore 设计湖屋
单个 DICOM 文件最多可包含 5,000 个不同的标签，这使得在银色湖屋中为所有这些标签映射和创建字段效率低下且耗费大量资源。 但是，保留对完整标签集的访问权限对于防止数据丢失和保持灵活性至关重要，尤其是当您需要的数据模型中提取和表示的 29 个标签之外的标签时。 为了解决这个问题，银色湖屋 ImagingMetastore delta 表将所有 DICOM 标记 metadata_string 存储在列中。 这些标签以字符串化的 JSON 格式表示为键值对，从而支持通过 SQL 分析终结点进行高效查询。 这种方法与管理白银湖屋中所有字段中的复杂 JSON 数据的标准做法一致。
从铜牌湖屋中的 ImagingDicom 表到 银牌湖屋中的 ImagingMetastore 表，转换不执行任何分组。 资源在两个表中都表示在实例级别。 但是，它 {FHIRResource}.id 包含在 ImagingMetastore 表中。 此值允许您通过引用特定研究的唯一 ID 来查询与特定研究关联的所有实例级对象。
与 DICOM 服务的集成
DICOM 数据转换功能与 Azure Health Data Services DICOM 服务之间的当前集成仅支持创建和更新事件。 您可以创建新的成像研究、系列和实例，甚至可以更新现有研究、系列和实例。 但是，集成尚 不支持 Delete 事件。 如果删除 DICOM 服务中的研究、系列或实例，DICOM 数据转换功能不会反映此更改。 成像数据保持不变，不会删除。
表警告
每个湖屋中的所有表都会显示警告，其中一个或多个列使用复杂的面向对象的数据类型来表示数据。 在 ImagingDicom 和 ImagingMetastore 表中，该 metadata_string 列使用 JSON 结构将 DICOM 标记映射为键值对。 此设计适应了 Fabric SQL 终端节点的限制，这些终端节点不支持复杂的数据类型，例如结构、数组和映射。 您可以使用 SQL 终结点（T-SQL）以字符串形式查询这些列，也可以使用 Spark 处理其本机类型（结构、数组、映射）。
