受信確認の既知の問題
このセクションには、受信確認 (ACK) エラーを回避するのに役立つ有用な情報が含まれています。
HL7 V2.1 受信確認メッセージが MSA6 フィールドを含む場合でも受け入れられます
MICROSOFT BizTalk Accelerator for HL7 (BTAHL7) は、MSA6 フィールドが含まれている場合でも HL7 V2.1 受信確認メッセージを受け入れます。
コミット確認エラーに対して MSA-01 値が生成されない
BTAHL7 では、コミット受信確認エラー (CE) の MSA-01 受信確認コードは生成されません。
双方向 MLLP アダプターが ACK の問題を検出しない可能性がある
BTAHL7 が双方向 MLLP アダプターで ACK を受信すると、アダプターは ACK に対して軽量の検証を実行してその有効性を判断します。 有効であることが判明した場合、MSA1 フィールドが抽出され、その値に応じて、アダプターは ACK が応答していた元のメッセージを再試行、中断、または削除します。 ただし、アダプターによって実行される検証は完全な検証ではないため、アダプターが ACK の問題を検出しない可能性があります。 たとえば、アダプターは ACK が有効であると判断し、元のメッセージを削除できます。一方、パイプラインは ACK が整形式ではないことを判断し、ACK メッセージを中断します。
複数のエラーを含む V2.XML ACL は検証に失敗します
受信 V2.XML メッセージに複数のエラーが含まれている場合、BTAHL7 パーサーは、エラー フィールドに複数のエラーがある V2.XML ACK を生成する可能性があります。 このような V2.XML ACK は検証に失敗します。HL7 標準では、パーサーが V2.XML ACK エラー フィールドでエラーを 1 つだけ報告できることを指定しているためです。
MLLP パフォーマンス カウンターで ACL がカウントされない
BTAHL7 パフォーマンスの 1 つの尺度は、MLLP パフォーマンス カウンターで示されているように、MLLP アダプターによって処理されるメッセージの数です。 この数は、受信または送信されたメッセージの数を測定します。 ただし、この数では、受信または送信された ACL の数は測定されません。
双方向 MLLP アダプターによって生成された NAK
双方向 MLLP アダプターがメッセージを中断すると、BTAHL7 は NAK (否定受信確認) を生成し、MessageBox データベースに配置します。 これは予期しない動作である可能性があります。 メッセージ ボックス データベースから NAK を削除するか、別のメッセージにマップすることができます。
バッチ メッセージへの ACK のデータ型
バッチ メッセージに応答して生成された ACK メッセージでは、バッチ メッセージ内の MSH10 フィールドのデータ型に基づくのではなく、MSH10 フィールド (メッセージ コントロール ID) が GUID になります。
生成された受信確認 DOC の種類
BTAHL7 は、DOC 型 http://microsoft.com/HealthCare/HL7/2X#ACK_24_GLO_DEF または http://microsoft.com/HealthCare/HL7/2X#ACK_25_GLO_DEFを使用して受信確認を生成します。 宛先パーティが別の名前空間を使用している場合は、送信ポートに本文マップを適用する必要があります。そうしないと、シリアル化エラーが発生する可能性があります。