2

After moving away from Biztalk since BT2006, we're looking at bringing it back into the organization. One of the frustrations I had early on was when dealing wht HL7 and orchestrations, we needed to have a seperate orchestration for each ADT message type, even though the schema for each type is essentially the same, and each orchestration did exactly the same thing. Moving forward into the world of BizTalk 2010, has anything improved here? Is there a pattern I can utilize to use a single orchestration for all ADT types?

4

2 に答える 2

3

ご覧のとおり、ここには 2 つの可能性があります。

  1. メッセージを匿名として扱います。これは、メッセージが「型指定されていない」ことを意味します (System.Xml.XmlDocument 型として宣言します)。その後、オーケストレーションはメッセージを調べて、そのタイプを判断できます。
  2. 本文が可能なすべてのメッセージ タイプであるエンベロープ メッセージを作成します (xsd 選択グループ セレクターを使用)。次に、オーケストレーションがエンベロープ メッセージ タイプを処理します。このアプローチでは、エンベロープ ヘッダーに値を設定することで、エンベロープの本文に含まれる型を宣言できます。

私は2番目のものを好むでしょう。確かに手間はかかりますが (すべての受信メッセージをエンベロープでラップする必要があります)、エンベロープ ヘッダーを見るだけでメッセージが何であるかを理解できます。これは、必要に応じてメッセージ タイプ別にルーティングできることを意味します。

于 2012-04-09T09:12:03.203 に答える
3

BizTalk での HL7 メッセージングは​​、2006 年のリリースからほぼ変更されていません。BizTalk はメッセージの種類(ADT、BAR、MDM など)だけでなく、メッセージとイベントの種類(ADT^A01、ADT^A03、ADT^A08 など)ごとにスキーマを定義するため、マッピングとオーケストレーションはすぐに混乱します。

この制限を回避するために私が過去に行ったことは次のとおりです。

  1. 型付けされていないメッセージがオーケストレーションに届くようにします。つまり、MessageType = System.Xml.XmlDocument に設定されています。一般に、いくつかの要素を解析または更新することにのみ関心があることがわかったので、必要なデータを取得するために、いくつかの一般的な linq ステートメントを含むヘルパー ライブラリを作成するだけです。このようにして、PID-3 (患者 ID 番号) に到達する linq ステートメントを作成でき、PID が同じままであるため、どのメッセージまたはイベント タイプでも一貫して使用できます。同様に、同じ手法を使用してメッセージも更新します。更新しようとしているフィールドに大きな構造上の違いがある場合、または大量のデータを読み取り/更新しようとしている場合、この手法はうまく機能しません。
  2. マスター/正規の HL7 メッセージ タイプ スキーマを作成します。これにはもう少し手間がかかりますが、処理しようとしているメッセージ タイプの数によっては、これが実際に効果を発揮し、医療機関が HL7 インターフェースをどのように考えているかにより一貫性を持たせることができます。これを行うには、メッセージ タイプの新しいスキーマを定義し、このメッセージの可能なすべてのセグメントを含める必要があります。したがって、複数の ADT タイプを定義する代わりに、A01、A03、A04 などのすべての可能なバリエーションを 1 つのマスター スキーマにまとめます。これにより、必要なマッピングおよび解析ロジックの量を大幅に削減できます。残念ながら、これは HL7 アクセラレータの既定の動作ではなく、実現するにはカスタム パイプラインとオーケストレーション ロジックが必要になるためです。基本的、

ほとんどがパススルー インターフェイスの場合は、テクニック #1 をお勧めします。それ以外の場合、基本的に任意のメッセージ イベントを正規の方法で生成または消費する必要がある場合は、手法 2 が長期的には効果を発揮します。

于 2012-04-10T16:08:03.493 に答える