HL7 v2X和v3数据建模

Question

我工作的公司在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服务器上进行大量工作，而且我不确定这样做会得到什么。 我正努力务实，因为我有一个截止日期。

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

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

Answer 1

HL7不是“严格”的标准输入，预期输出会根据您所使用的系统而有所不同。 在这种情况下，在Mirth，Rhaposdy或BizTalk等经纪人中添加是一个非常好的主意。

您使用的解决方案确保您可以应对“非标准”输入和输出，因为您很快就会发现各种不同。 在HL7版本2X和3上，请注意很少有医院的版本3仍然运行2X。

我一直在使用一个试图遵循HL7结构的数据库，它可以工作，但这需要时间和精力。 鉴于你有一个紧张的死线可能会打破你需要搜索的数据位并有字段（例如，PID段3是患者ID将有用）其余的可以进入你的varchar。 此外，如果您没有对列进行索引，则可以使用varchar（max）。

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

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

所以我的总体建议。 现在就去混合动力车，打破你需要的东西。 期望它随着时间的推移而发展，根据需要将HL7的各个部分分解到他们自己的区域。 写一个通用的HL7解析器（我已经做过几次并不太困难）并保持灵活性。 但是大多数人都希望HL7在结构上有所不同，不要将规格视为100％的真相，你会得到变化。

Answer 2

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

Answer 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发送HL7v - > Mirth - > BizTalk，然后遵循实施指南+ CDA Schema以及XSLT转换将HL7v2映射到CDA然后将其提交给OTHER BizTalk CDA提交服务好像是外部供应商。

这是现在的大量阅读，所以请提问，因为我想谈谈它。

Answer 4

在HL7上建模可能很痛苦。

我会做以下事情;

• 使用HL7中描述的标准用于登台表，即使你有varchar（1024）并且它们为null也不会伤害你
• 根据您已强制执行或将强制执行的标准，创建要从登台表填充的实际表。

这意味着你有超过500列的消息，但只有10或50有意义，你需要只为你的50建模。是的，这有一个lopside，明天你想要更多的意义然后它会从50增加到75 ，历史信息不会有信息; 这很好，但你需要考虑到设计。

Answer 5

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

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

我认为拉入一切的问题会导致项目失败，你不应该这样做。 通常情况下，HL7 v2消息占据了整体的一小部分，因此构建整个内容将是一种完全的浪费，而且会非常混乱。

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

我建议你把赌注放在沙子里并从v2.4开始，这比实际使用的大多数界面都要简单但更复杂。 专注于几个细分和几个领域。 MSH和PID优先。

添加EAV表以捕获表中尚未存在的内容。 然后，您可以查看随着时间推移进入此表的内容，并使用它来决定下一步要构建的内容。 您的EAV可能看起来像MSG_ID，SEGMENT，SET_ID，FIELD_NAME，FIELD VALUE。 只需存储字段值的未解析的HL7内容。