Rit*_*572 6 sql sql-server hl7 hl7-v2 hl7-cda
我工作的公司在 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 从我可以与实体框架绑定的消息中创建对象，但 nHapi 似乎是一个死项目，而且我现在没有使用实体框架的经验。
我基本上很茫然，需要一些有 HL7 数据建模经验的行业专业人士的帮助。是否值得付出额外的努力来完全标准化表格？如果我使用这些具有数百列的非规范化段表（其中大部分每行为 NULL），SQL 端的性能是否会很糟糕？我不是 DBA，所以我试图了解每种方法的陷阱。我也研究过 RIMBAA，但对于作为 HL7 新手的我来说，HL7 RIM 似乎是一门外语，将 v2 消息翻译到 RIM 可能需要比我完成这个项目更长的时间。我希望我想得太多了，有一个更简单的解决方案摆在我面前。希望这个问题不要太开放。
小智 1
在任何情况下我都不会尝试使用 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 内容即可。