作者

MOD

文章 Kelly Huang · 5 小时前 6m read

OMOP Odyssey - FHIR® 到 OMOP ETL 之旅

专业级 FHIR® 到 OMOP 的转换

让我们把 "专业（__professional）"一词的使用归零，并将其放在一定的背景下。它是由行业专家编写的，他们将其包装成一项收费服务，并提供支持和一些围绕 灵活选项的保护措施，以促进其行为。我认为，无论是开放式还是自家开发的解决方案（尽管可能做的是同一件事），考虑其规模或提供关键任务价值的另一面都是一个重要的区别。OHDSI 社区拥有一整套围绕 OMOP 数据库 ETL 主题的能力，例如，WhiteRabbit可以分析 OMOP 数据库，Rabbit in a Hat可以帮助设计 ETL。我想做空这只股票，因为我打赌社区工具会应用到 InterSystems 的转换堆栈中，以完善产品。

在这里，我试图让一个社区对数据转换产生兴趣，这个社区可能生活在数据转换中，但可以肯定的是，这是一个快速入门的开始，可以让您进入 OHDSI 社区的大门，获得财富和 "大规模解决方案武器"，对您的（或他人的）医疗保健数据进行有意义的大规模分析。

Bulk FHIR

该管道的摄取标准是Bulk FHIR 导出，看看 InterSystems 是如何实现Bulk FHIR 协调器的，导出的有效载荷是一个 zip 文件，其中包含带有 FHIR 资源的ndjson文件，每行一个。

您可以用 json 格式的单个导出资源文件作为示例，在程序中使用......

生成简单的 BulkFHIR.zip 文件

cd hospitals/
jq -c . hospital*.json > hospitals.ndjson
zip -r hospitals.zip hospitals.ndjson

......或者我们可以简化它，使用 Synthea 和 @Dmitry Zasypkin 在 github 上提供的解决方案生成合成有效载荷，该解决方案会处理👣 🔫，以纠正 synthea 和某些 FHIR 服务器之间的参照不匹配。

因此，让我们按照指示，生成一个由 10 名患者组成的小群体，以便登陆我们的 OMOP 数据库，并突出显示该服务。

git clone https://github.com/dmitry-zasypkin/synthea-ndjson
cd synthea-ndjson
docker build . -t synthea
docker run --rm -v ./output:/synthea/output -it synthea -p 10
chmod +x patch-synthea-ndjsons.sh
sudo chmod -R 777 output # may need this
./patch-synthea-ndjsons.sh output/fhir
zip -j fhir1.zip output/fhir/*.*

如果一切顺利，你应该会在当前工作目录下看到一个名为 `fhir1.zip` 的批量 FHIR 导出压缩包。

需要注意的是，批量导出 fhir 实际上是 `synthea.properties` 中的一个受支持的导出选项...

exporter.fhir.bulk_data=true

好了，让我们发送它。还记得我们之前设置的`arn:aws:s3::omop-fhir`桶吗？让我们上传有效载荷，开始加载我们的 OMOP 数据库。

检查我们的工作：

检查转换

回到 InterSystems OMOP 云门户，导航到侧边面板中的 "Metrics"（指标），让我们检查一下转换结果，希望我们有一些。

转换只用了不到一分钟就完成了，如果你高亮运行，就会看到数据导入的统计和报告单，看起来有两种不同的情况发生，一些是错误，一些是警告。

检查 OMOP 表，可以确认登陆的 "人员 "数量为 15，有 13 个资源出错，无法在 ETL 中登陆。要查看发生了什么，请导航到 InterSystems 门户中 OMOP 服务的 "错误 "导航项。绝对不是检查 OMOP 数据库的有趣方法，但让我们使用 SQL 浏览器快速浏览一下，确认数据库中有 15 个病人（又称 OMOP 人员）。

高亮显示顶部窗格中的运行将显示下面的两个表，一个是数据错误表，另一个是警告表。关于错误和警告的详尽解释，InterSystems OMOP 文档比我做得更好。

看起来缺少了一个对转换至关重要的概念 ID（通过 OMOP 数据模型），你可以在CDM 文档中快速检查程序的表引用的必填字段。

此外，我们在尝试发布转换时，似乎曾两次尝试发布一个位置，幸好没有成功。

至于警告，Synthea 似乎用字符串填充了一个数量字段，但资源还是持久化了，如这里的 `{#}` 所示。

如果您想了解引擎盖下的映射，可以在InterSystems 文档中找到它（它很容易看懂，理解起来也很简单，至少那个链接是这样：）。

转换选项

在 "配置 "选项卡中（也包括前面的 "供应 "选项卡），有几个与控制转换有关的选项值得一看。前两个选项与源数据映射选项有关，使用 FHIRPath 表达式可以控制映射。我发现fhirpath.js 演示对在 FHIR 资源 json 上挖掘 FHIRPaths 很有教育意义，也很有用。

人员 ID 选项

这些选项很重要，但在使用合成数据时很难看到它们的价值。FHIR 资源 ID 是一个永不改变的 ID，可识别资源本身，因此对临床意义而言毫无意义，但对 FHIR 服务器的运行却很重要。如果您熟悉 HealthShare 患者索引和域冲突的概念，那么源系统对识别患者是否唯一同样重要。这些选项允许您控制 OMOP 数据库中的重复最小化和使用有意义的标识符。