6

我工作的公司在 HL7 中启动了一项新计划，我们在其中交易 v2X 和 v3（特别是 CDA）消息。我现在能够接受、验证和确认我们从贸易​​伙伴收到的消息，并开始为所述消息的后端存储创建数据模型。经过大量的考虑和研究，我不知道在 MS SQL Server 2008 R2 中解决这个问题的最佳方法是什么。

目前，我的想法是直接从我的集成引擎 (BizTalk) 将数据加载到数据仓库中，并使用一个支持的、标准化的操作数据库。我已经根据 v2.7 规范为 v2X 消息设置了数据库，因为 HL7 v2 的所有版本都是向后兼容的（我可以将任何以前的版本存储在同一个数据库中）。我的初始设计为每个段都有一个表，该表将与我在运行时生成和存储的 guid 绑定到标题表。这种方法的最大问题是每个表中的列数，这是我没有经验的。例如 PV1 段有 569 列以容纳所有可能的数据。除此之外，我需要将所有列设置为 varchar，并使它们足够大以容纳我们供应商提供的任何可能的定制方案。我打算使用 varchar(1024) 来实现这一点。很多这些列（可能大部分）都是 NULL，所以我会使用 SPARSE 列。这对我来说是糟糕的设计，但是完全规范化这些表需要在 BizTalk 和 SQL Server 中进行大量工作，我不确定这样做会得到什么。因为我有最后期限，所以我试图变得务实。

如果完全标准化，我基本上必须创建具有大量参数的存储过程，或者将这些消息拆分到第 n 级，以将单独加载到较小的子表中，并确保它们都与原始 guid 相关联。我还想维护 ACID 处理，这可能会变得棘手并在 BizTalk 中导致大量开销。我想第三种选择是使用 nHapi 从我可以与 Entity Framework 绑定的消息中创建对象，但 nHapi 似乎是一个死项目，我目前还没有使用 Entity Framework 的经验。

我基本上不知所措，需要一些有 HL7 数据建模经验的行业专业人士的帮助。完全规范化表格是否值得付出额外的努力？如果我使用这些具有数百列的非规范化段表（其中每行的大部分将为 NULL），SQL 端的性能会很糟糕吗？我不是 DBA，所以我试图了解每种方法的缺陷。我也看过 RIMBAA，但作为 HL7 新手，HL7 RIM 对我来说似乎是一门外语，将 v2 消息翻译到 RIM 可能需要比我完成这个项目更长的时间。我希望我想多了，有一个更简单的解决方案正盯着我看。希望这个问题不会太开放。

4

5 回答 5

4

HL7 不是“严格”的标准输入，预期输出会因您正在与之交谈的系统而异。在这种情况下，添加 Mirth、Rhaposdy 或 BizTalk 等代理是一个非常好的主意。

无论您采用什么解决方案，都可以确保您能够应对“非标准”输入和输出，因为您很快就会发现情况有所不同。在 HL7 版本 2X 和 3 上，请注意，很少有医院拥有版本 3，大多数仍在运行 2X。

我一直在使用试图遵循 HL7 结构的数据库，它可以工作，但是需要时间和精力。鉴于您有一个紧迫的截止日期，可能会打破您需要搜索的数据位并具有字段（例如，PID 段 3 是患者 ID 将很有用），其余的可以进入您的 varchar。此外，如果您没有在列上建立索引，则可以使用 varchar(max)。

至于数据库中的 Guid，这可以正常工作，但请注意不要使用 Guid 聚集任何索引，因为这会使您的数据碎片化。在这里做你的研究，如果有疑问，请改用身份列。

我也会推荐实体框架，优秀的ORM，值得学习。

所以我的总体建议。现在就选择混合动力车，打破你需要的东西。预计它会随着时间的推移而发展，根据需要将 HL7 的各个部分分解为自己的区域。一定要编写一个通用的 HL7 解析器（不是太难，我已经做过几次了）并保持它的灵活性。但最重要的是希望 HL7 在结构上有所不同，不要将规范视为 100% 真实，您会得到变化。

于 2014-03-04T14:53:59.043 回答
3

我只能根据个人经验对 CDA（以及一些非常有限的 HL7v2）方面进行评论。

我们从外部供应商（以及内部系统——见下文）接收和发送封装在 HL7v3 包装器中的 CDA 文档。包装器包含诸如发送/接收系统/日期和其他高级数据之类的元数据。非常有限的消息元数据被剥离并存储在消息数据存储库中。包装器内部是实际的 CDA，然后将其作为 XML 数据类型存储在 SQL 数据库中。

使用此模型，我们可以在元数据级别进行搜索，还可以使用 Xpath 查询根据 CDA 缩小范围。它使数据库变得更加简单......我什至无法想象基于 CDA 模式创建列。

至于让客户遵循 CDA 模式，作为项目的一部分，我们创建了一个实施指南，如果客户希望他们的消息被接受，他们必须遵循该指南。

使用实施指南 + schematron + BizTalk 和 XSD 验证，我们只接受遵循 CDA 架构的消息。然后，我们使用 schematron 验证检查一些数据字段，如果其中任何一个失败，则拒绝。这通过使用特定错误消息和/或无效字段的 HL7v3 消息转发给发件人。这是消息将存储在数据库中的点。

这一切都在 BizTalk/SQL Server 中完成。并且由于 CDA 模式是由 HL7 组预先定义的，因此您可以使该系统的消费者遵循该模式。这与我在 HL7v2 中看到的不同，似乎人们只是根据需要弯曲架构。

对于 HL7v2 方面，我 99% 确定“我们”（如“我的公司”）以相同的方式存储消息。除了因为 HL7v2 模式是如此开放，我们不验证，只是接受/存储所有消息。已经编写了一个 HL7v2 解析器来使用我们所知道的模式的变体来解析 HL7v2。

在我的项目中，我们从 HCIS --> Mirth --> BizTalk 发送 HL7v2，然后遵循实施指南 + CDA 架构以及 XSLT 转换以将 HL7v2 映射到 CDA 然后将其提交到其他 BizTalk CDA 提交服务就好像它是外部供应商一样。

现在阅读量很大，所以请提出问题，因为我想谈谈它。

于 2014-03-18T16:26:49.570 回答
3

在大多数情况下，尝试创建规范化的关系数据模型来持久化 HL7 V2 或 V3 数据是浪费时间。我建议将整个消息或文档存储为单个 XML 列值。然后使用 SQLXML 和/或 XQuery 进行查询。现在所有现代关系数据库都支持这一点。

于 2014-04-07T03:41:48.457 回答
2

在 HL7 上建模可能会很痛苦。

我会做以下事情；

  • 将 HL7 中描述的标准用于暂存表，这样即使您有 varchar(1024) 并且它们为空，也不会伤害您
  • 根据您已实施或将要实施的标准，创建要从临时表填充的实际表。

这意味着您有 500 多列来自消息，但只有 10 或 50 列有意义，您只需对 50 列进行建模。是的，这有一个不平衡，明天您想要更有意义，然后它将从 50 增加到 75 ，历史消息将没有信息；这很好，但你需要考虑到设计。

于 2014-03-14T10:59:47.237 回答
1

在任何情况下，我都不会尝试使用 HL7 v3 RIM 对任何东西进行建模。原因是这个模式非常通用，将大部分元数据推迟到消息本身。您熟悉 EAV 表吗？RIM就是这样。

另一方面，HL7 v2 应该是 DB 模式的一个相当简单的基础。您可以围绕段类型创建表，并围绕字段名称创建列。

我认为把所有东西都拉进去的问题会扼杀项目，你不应该这样做。通常，HL7 v2 消息只包含整个消息的一小部分，因此构建整个消息完全是浪费，而且会非常混乱。

此外，您建模的 v2 版本会显着影响您的模式，随着更高版本，越来越多的字段成为重复字段，并且您的连接关系会发生变化。

我建议您从 v2.4 开始，这很容易，但比实际使用的大多数接口还要复杂。专注于几个细分市场和几个领域。首先是 MSH 和 PID。

添加一个 EAV 表以捕获您的表中可能还没有的内容。然后，您可以查看随着时间的推移进入该表的内容，并使用它来决定下一步要构建什么。您的 EAV 可能如下所示 MSG_ID、SEGMENT、SET_ID、FIELD_NAME、FIELD VALUE。只需存储字段值的未解析的 HL7 内容。

于 2014-04-01T00:01:28.293 回答