工程

您不应该直接与数据库EHR集成的5个原因

发表于三月7,2019
布伦丹·基勒(Brendan Keeler)

在儿童医院内,大厅里热闹非凡。提供者正在四舍五入,孩子们正在努力成为孩子,甚至还有一个机器人在大厅里漫游,运送物资。当他们的电子健康记录系统突然冻结并变得无法访问时,所有这些都停止了。工作人员争先恐后地确保对最脆弱的患者进行检查和视觉监控。好像飓风袭击了医院。此过程持续了几个小时,直到可以恢复系统为止。

电子病历已成为医疗服务的支柱。在停机期间,有关诊断,药物,护理计划,甚至患者身体位置的重要信息都将丢失。除了对患者安全的影响之外,据估计,像这样的停机时间给医院造成的损失比 每小时100万美元 生产力损失。这种特殊的停机时间是由于医院EHR系统的生产实例中的数据库注入位置错误而引起的。第三方应用程序绕过了抽象层的安全性,并直接集成到生产数据库中。

这是错误的追求方式 电子病历整合。上面的故事是真的。在我描述了互操作性的不同愿景之后,儿童医院的一位IT主管告诉了我这一点。回到Redox,我对一些经验最丰富的集成工程师进行了投票。以下是您不应该直接与数据库进行EHR集成的5大原因。

他们一直在挣扎

直接到数据库集成非常脆弱。数据库架构经常更改且不会发布。这就像是试图蒙住一个目标。未经精心计划和解决的升级,更新或较小更改可能会导致灾难性的故障。由于定制和频繁维护的水平,即使趋于适当,直接到数据库的集成也容易遭受不可避免的人为错误。

即使在基本的只读方案中,架构重组也将意味着以下三种情况之一:

  1. 您的集成显然已中断。
  2. 您的集成没有显示数据,而是显示了实际数据。
  3. 您的集成显示过时的数据。

一切都不好。

EHR在发布软件的新版本时通常不会对已知的集成点(HL7,CDA,面向外部的Web服务等)进行重大更改,因为此处的任何更改都可能要求所有下游系统都必须对其集成进行更改。对于许多卫生系统而言,这是一项艰巨的工作,因为大型卫生系统通常都需要通过接口连接数百个下游系统。

直接到数据库的连接绕过了接口层,不再从其稳定性中受益。与基于接口的集成相比,EHR更新更有可能破坏直接数据库集成。绕过关键检查以尝试完成“快速”操作会大大增加失败的风险。

2.他们没有规模

为了使解决方案永不中断,必须始终在两侧进行相同的更改,这意味着它们需要高度的协调性(或者,正如我们的一位工程师所说,这需要“一定程度的魔术思维”),并且与之相比,其长期维护工作要多得多其他集成解决方案。此外,每种直接数据库解决方案都是自定义的,不会转化为下一个机会。与其他合作伙伴共享时,没有可重用性或边际收益。当您可以投资组织可以用于其他用例的基础架构时,为什么要投资这种一次性的孤立连接呢?

3.他们忽略了数据库的完整性和性能

数据库性能是系统的血液。如果速度变慢,其他所有东西都将崩溃。将API(包括HL7v2)放在它的前面可以为您提供更多保护数据库性能和完整性的方法。

精心设计的数据库将 快取指数 数据以提高性能。只要EHR完全负责数据库中的更改(一切都通过API),就可以正常工作。直接写入数据库会绕过缓存和索引的读/写操作,从而破坏系统。您的风险范围从重大错误到完全破坏数据库。

4.恶意活动的可能性增加

最小特权原则 在信息安全领域是一个众所周知的概念。基本概念是,每个模块仅应能够访问降低恶意活动可能性所需的信息。授予对数据库级操作的访问权限意味着连接方完全信任。您将为合作伙伴提供远远超出其需求的功能,而不是仅授予绝对必要的信息和资源的访问权限。

数据库管理员依赖的另一个安全实践是 纵深防御。因为数据库特别严重地依赖于在系统其他部分中实现的安全控制,所以通过直接与数据库医疗保健集成来规避这些安全控制,使系统容易受到未经检查的数据库操作的影响,无论这些操作来自恶意行为者还是善意的同事。作为患者数据的管理者,任何医疗机构都不应对此风险程度感到满意。

5.业务逻辑通常不在数据库层执行

在数据库层和应用程序层都强制执行业务逻辑。一般来说,开发人员会在应用程序层执行更多的强制措施。通过直接进入数据库,您可以执行使死者复活或将重要的实验室检查结果放在没人能看到的地方的操作。

您可能会想到,大多数EHR供​​应商通常不支持直接数据库集成。因此,对于不支持这种连接方式的大型EHR供应商,包括直接到数据库连接的任何集成策略都将需要备用的集成方法。如果您希望构建一个可扩展的解决方案,那么走一条龙直接进行数据库集成的方式来满足一位客户的需求就不是走的路。从FHIR和API到HL7,X12和常见的平面文件,那里有太多替代方案,可能会使您的应用程序冒险’在直接到数据库的连接上取得了成功。

***

想更多地了解氧化还原’电子病历集成的方法?观看下面的概述视频!