sql - HL7 v2X 和 v3 数据建模

Question

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

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

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

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

Answer 1

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

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

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

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

我也会推荐 Entity Framework ，优秀的ORM，值得学习。

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