拆分 HIPAA 子文档

正如 ST/SE 标头所限定的，用于 HIPAA 的 EDI 交换通常在单个事务集内具有多个子文档。 EDI 接收管道支持从这样的事务集创建单独的 HIPAA 子文档。 这不同于将单个事务集作为单个消息进行处理的非 HIPAA EDI 交换。

子文档拆分架构

BizTalk Server支持通过本机架构拆分以下 HIPAA 文档类型：

• HIPAA 版本 4010 文档：834 注册、835 索赔付款和 837 声明的三种变体

• HIPAA 版本 5010 文档：276/277 声明状态 - 请求和响应、834 注册和 837 声明的三个变体

  BizTalk Server为这三种文档类型中的每一种提供两个版本的架构。 对于每一种文档类型，通过文件名中的“Mulitple”标签对支持拆分的架构进行标识。 其他架构不支持子文档拆分。

  在某些情况下，拆分和非拆分架构可能都是必需的。 通过为架构的一种变体使用自定义目标命名空间可以对此提供支持。

如何启用子文档拆分

可以通过 HIPAA 架构中的三个批注项启用 HIPAA 子文档的拆分。 前两个是 appinfo 注释中架构的条目，必须将其设置为 yes：

subdocument_break = "yes" Split_Without_Sibling_Data = "Yes"  

第三个批注项位于 HIPAA 架构内的相应记录级别。 此属性还必须设置为 yes。

subdocument_creation_break = "yes"  

仅当 HIPAA 架构中的子文档创建中断批注设置为“yes”，并且入站批处理选项参与方属性设置为“将交换拆分为事务集”时，HIPAA 交换才会拆分为子文档。 如果入站批处理选项参与方属性设置为保留该交换，EDI 拆装器将不会把交换拆分为子文档。 在此情况下，EDI 拆装器将忽略该批注。 如果发生此情况，事件查看器中不会产生任何警告。

注意

子文档创建中断批注不能进行嵌套。 如果架构包括一个已对其应用了子文档批注的循环，该循环不能包含应用了子文档批注的另一个循环。

如何处理子文档

由 EDI 接收管道中的 EDI 拆装器对子文档进行拆分。 在接收管道验证了传入的交换并生成相应确认之后，它将每个单独的子文档路由至 MessageBox。 每个子文档在结构和语法上都是有效的；但是，可以预期的是，业务级别摘要、事务集总计和事务集控制编号是不同步的。 发送管道将覆盖每个子文档的 SE01 中现有段计数的值（来自原始事务集），将其改写为子文档中所包含的段的计数。 接收管道还将重置每个子文档中的事务集控制编号，以免子文档具有重复的控制编号。 这样可确保发送端的处理工作不会失败。

如果事务集在子文档拆分期间未能通过 EDI 或扩展验证，则单个未通过的事务集将被挂起。

订阅子文档的发送端口将从 MessageBox 获取每个子文档，序列化 XML 子文档，对它们进行批处理（如果启用），验证它们，然后发送它们。 发送管道会更新段数据元素 (SE01) 的计数。

如何拆分子文档

子文档创建中断批注通常应用于包含 HIPAA 架构内的一个或多个元素的循环。 架构中位于中断循环之前和之后的其他元素复制到每个子文档中。

下表显示了子文档拆分的一个例子。 在本例中，子文档创建中断批注对于 CC 元素循环设置为“yes”。 因此，事务集中的 CC 元素被分割为多个单独的子文档，同时每个单独的子文档中都包括了事务集中的 AA、BB 和 DD 元素。

架构（最小/最大出现次数）	原始实例	子文档 #1	子文档 #2	子文档 #3
ST (1,0)	ST	ST	ST	ST
AA (1,1)	AA	AA	AA	AA
BB loop (1,n) BB1 (1,n) CC loop (1,n) - subdocument_break = "yes" CC1 (1,n) CC2 (0,n) BB2 (0,n)	BB1*1 CC1*1 CC2*1 BB2*1 BB1*2 CC1*2 CC2*2 BB1*3 CC1*3 CC2*3	BB1*1 CC1*1 CC2*1 BB2*1	BB1*2 CC1*2 CC2*2	BB1*3 CC1*3 CC2*3
DD (0,n)	DD	DD	DD	DD
SE	SE	SE	SE	SE