分割 HIPAA 子文件
HIPAA 的 EDI 交換通常會在單一交易集中,使用由 ST/SE 標頭繫結的多重子 (child/sub) 文件。 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 結構描述中的子文件建立分頁註解是設為 "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 |