HIPAA 的 EDI 交换通常在一个事务集内包含多个子文档，由 ST/SE 标头界定。 EDI 接收管道支持从此类事务集创建单独的 HIPAA 子文档。 这不同于非 HIPAA EDI 交换，其中单个事务集作为单个消息进行处理。
子文档拆分架构
BizTalk Server 支持通过本机架构拆分以下 HIPAA 文档类型：
HIPAA 版本 4010 文档：834 注册、835 索赔付款和 837 声明的三个变体
HIPAA 版本 5010 文档：276/277 声明状态 - 请求和响应、834 注册和 837 声明的三个变体
BizTalk Server 为每个这三种文档类型提供两个版本的架构。 对于每个文档类型，支持拆分的架构由文件名中的“Multiple”标记标识。 其他架构不支持子文档拆分。
在某些情况下，可能需要拆分架构和非拆分架构。 将通过使用自定义目标命名空间来支持架构的一个变体，从而实现这一点。
子文档拆分的实现方式
HIPAA 子文档的拆分由 HIPAA 架构中的三个批注条目启用。 前两个是 appinfo 注释中架构的条目，必须设置为 “是”：
subdocument_break = "yes" Split_Without_Sibling_Data = "Yes"
第三个批注条目位于 HIPAA 架构中的相应记录级别。 此属性还必须设置为 “是”。
subdocument_creation_break = "yes"
仅当 HIPAA 架构中的子文档创建中断批注设置为“是”时，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） | 美国航空公司 | 美国航空公司 | 美国航空公司 | 美国航空公司 |
| BB 循环 （1，n） BB1 （1，n） CC 循环（1，n） - 子文档中断 = “是” 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 |
| 硒 | 硒 (if "SE" refers to Selenium). | SE | SE | 硒 |