BizTalk EDI ソリューション

  • [アーティクル]

BizTalk Server 2010 により医療保健請求を処理する

Mark Beckner

BizTalk Server 2010 では、取引先との電子データ交換 (EDI) ドキュメントのやりとりを管理するためのプラットフォームのアーキテクチャが刷新されています。このプラットフォームの以前のエディションを使用したことがあれば、さまざまな取引先とのドキュメント交換の設定に頭を悩ませた経験があるかもしれません。最新リリースでは、取引先とのドキュメント交換に関連するドキュメント設定の編成と構成を完全に制御できます。

BizTalk Server 2010 では、マップ開発時の操作性も大幅に強化されています。

これらの新機能を説明するため、この記事では EDI ソリューションの構築に必要な手順を紹介します。BizTalk Server 2010 で開発するすべての EDI ソリューションは、次の基本パターンに従います。

  • 基本の EDI スキーマを追加および変更する
  • EDI ドキュメントと、内部および外部のメッセージング間のマップを作成する
  • EDI ドキュメントの処理に関係するワークフローを処理するためのオーケストレーションを実装する
  • パーティ、ビジネス プロファイル、契約、確認など、取引先の設定を構成する
  • ドキュメントの受信や配信を可能にするポートを構成する (FTP、AS2、または別のプロトコル)

説明のため、ここでは病院と請求処理部門とのドキュメント交換を見ていきます。両当事者間で交換されるドキュメントは、医療保険の携行性と責任に関する法律 (HIPAA) 準拠の 837 専門および公共機関向けファイルです。

スキーマを使用する

ほとんどの EDI ソリューションでは、2 種類の基本スキーマを使用します。1 つは、取引先との間で交換されるフラット ファイルを表す EDI スキーマで、もう 1 つは EDI ドキュメント内のデータ処理に必要なドキュメントの種類を表す内部スキーマです。

この例のソリューションでは、837 ドキュメントを外部パーティと交換しますが、内部処理には異なるドキュメント形式を使用します。内部スキーマは、医療保険請求処理業者向けの一般形式である ECSIF フラット ファイルを表します。837 スキーマは BizTalk に付属していて Visual Studio プロジェクトに追加できますが、内部スキーマ (ECSIF など) は手作業で作成する必要があります。

BizTalk Server 2010 には、現在使用されている EDI ドキュメントの大半を定義する、数千点の既存のスキーマが付属しています。スキーマを利用するには、$\Program Files\Microsoft BizTalk Server 2010\XSD_Schema\EDI ディレクトリにある MicrosoftEdiXSDTemplates.exe 実行可能ファイルを実行します。この記事の例では、HIPAA\00501 フォルダーにある 837 専門および公共機関 HIPAA 準拠のスキーマを使用します。XSD ファイルを Visual Studio プロジェクトに追加することで、他の BizTalk コンポーネント (中でも最も重要なのはマップ) からその XSD ファイルを参照および使用できるようになります。

図 1 は、Visual Studio 2010 に表示された 837 専門 5010 スキーマです。このスキーマのノード数に注目してください。837 は最も複雑な EDI ドキュメントの 1 つで、非常に扱いに注意が必要になる場合があります。このスキーマには、サブスクライバーと患者の情報を表す、ほぼ同じ内容のノードが数百個あります。

image: The 837 Professional 5010 Schema

図 1 837 専門 5010 スキーマ

図 2 は、ECSIF 形式を表す内部スキーマです。このスキーマは、フラット ファイル スキーマ ウィザードを使用して生成されました。フラット ファイル スキーマ ウィザードでは、有効なフラット ファイル インスタンスを参照して、XSD を作成できます。FileHeader ノード内の多数のフィールドが、このスキーマに昇格されています。フィールドを昇格すると、フィルターおよびマッピングの選択肢が広がります。

image: The Target ECSIF Schema Format

図 2 ターゲットの ECSIF スキーマ形式

スキーマが定義され、Visual Studio プロジェクトに追加されたら、マップの作成に着手できます。ここでは、837 ドキュメントのマップに有用ないくつかのシナリオについて説明します。

マップを開発する

BizTalk Server 2010 のマッピング インターフェイスは、大幅に改訂され、さまざまな新機能を導入しています。これらの機能には、ズーム、ノードの自動照合、検索機能などがあります。最も特筆すべき強化点の 1 つは、行または Functoid をクリックすると、すべての他のマッピングが背景にフェードインされる機能です。

EDI マップの開発者であればおわかりになりますが、一部のマップは非常に複雑で、複数のタブや数十の (または数百になる場合もある) Functoid があります。このため、送信元スキーマのどのデータを送信先スキーマのどのデータにマップするかや、このマッピングを行うにはどの Functoid が使用されるかを特定するにあたり、目で見て確認することが難しい場合があります。任意の行または Functoid をクリックすると、すべての関連するマッピングが強調表示されます。

マッピング ロジックの特定のセットが強調表示されている複雑なマップの例を図 3 に示します。これにより、BizTalk でのマップ開発において見過ごされがちな点が明らかになります。つまり、マップ インターフェイスは使用すべきときと、使用すべきでないときがあります。BizTalk で処理されるマッピングの中には、標準マッピングに最適ではないものもあり、別の手段を使用した方が適切な場合があります。別の手段としては、インライン スクリプトや、XSLT および Microsoft .NET Framework コンポーネントなどの外部コンポーネントがあります。

図 3 BizTalk Server 2010 マップの強調表示機能

BizTalk マップ開発は、通常、標準の Functoid とインライン XSLT および C# を組み合わせて行います。ときには、外部の XSLT スタイルシートを利用する方が適切な場合もあります (この場合は BizTalk マッパーをまったく使用しません)。EDI マップは複雑になり、必要なソリューションを作成するには工夫と計画が必要になる場合があります。

インライン C# の使い方を説明するため、送信される 837 専門または公共機関ファイルの一般的なマッピング機能である階層型 (HL) セグメントを見てみましょう。HL セグメントには、ファイルの各レコードに対応する増分値が必要です。HL セグメントでは、親子関係が表されます。これらの値を適切に設定できる、確立された Functoid の組み合わせは本当にありません。ただし、正しい値を設定できる簡単なインライン C# による方法はあります。この方法には、2 種類のスクリプト Functoid が必要です。1 つはグローバル変数を格納し、HL01 をマップする Functoid で、もう 1 つは HL02 (HL01の値に依存) をマップします。

HL01 Functoid のスクリプトは次のようになります。

int intHL01;
  public int getHL01() {
  intHL01++;
  return intHL01;
  }

次に HL02 スクリプトのコードを示します。

public int getHL02() {
  return intHL01 -1;
  }

図 4 はマップ内に配置された Functoid を示しています。

image: Mapping HL Segment on Outbound 837

図 4 送信 837 での HL セグメントのマッピング

他に EDI ドキュメントのマッピングで頻繁に起きるのは、インライン XSLT を使用する必要がある状況です。これは、BizTalk マッピングに取り入れられる最も重要な技術の 1 つです。ぜひ習得されることをお勧めします。インライン XSLT を使用すると、標準の Functoid の組み合わせでは利用できないさまざまなループやノード作成を実現できます。

マップでのインライン XSLT の使用例を図 5 に示します。このコードは、インライン XSLT 呼び出しテンプレート機能を使用して、送信元ドキュメントのパラメーター (Name) を渡し、送信先の 837 ドキュメントにノードを作成する方法を示しています。

image: Passing Parameters to an Inline XSLT Call Template Script

図 5 インライン XSLT 呼び出しテンプレートにパラメーターを渡すスクリプト

BizTalk マップの開発時には、常にマップが長期にわたって保守が容易になるよう考慮してください。マップが容易に更新できるかどうかや、他の人が将来操作できるかどうかを検討します。BizTalk マップの作業時は、忘れずに推奨コーディング プラクティスに従ってください。また、ロジックや複雑な機能を多く含むマップを作成する場合は、いくらかのアーキテクチャと計画も必要です。

オーケストレーション

EDI ソリューションでのオーケストレーションの使用は必須ではありません。ワークフローを含める必要なく、形式間のマッピングを行い、ドキュメントを配信するだけでよい場合も多くあります。

ただし、場合によっては、いくつかの処理を行わないと、ドキュメントが配信できる状態にならない場合もあります。これを説明するため、ここではマップにオーケストレーションを設定し、メッセージを SQL Server のテーブルにアーカイブします。オーケストレーションにフィルターを構成し、特定の種類のドキュメントのみがオーケストレーションによって処理されるようにします。

オーケストレーションは、(他にも多数のプロパティがありますが) EDI ドキュメントの ISA または ST セグメント内のほぼどのフィールドに対してでもサブスクライブするように設定できます。ドキュメントの特定のフィールドをサブスクライブするようにオーケストレーションを構成する場合は、オーケストレーションの初期状態の受信図形にフィルターを設定できます (図 6 参照)。

image: Setting a Filter on an Orchestration

図 6 オーケストレーションに対するフィルターの設定

フィルターが指定されると、オーケストレーションによって、EDI ドキュメントの必要な処理を実行できるようになります。ここでは、オーケストレーションによって 837 形式のデータが ECSIF 形式にマップされて、この情報が SQL Server のアーカイブ テーブルに書き込まれます。ドキュメントのマッピングは変換図形およびマップ ファイルの組み込みによって処理されますが、SQL Server への情報の書き込みにはさまざまな方法を利用できます。

SQL Server のことを考えると、多くの BizTalk 開発者は SQL への書き込みに利用できるアダプターの 1 つを使用する必要があると考えます。実際のところは、ほとんどの場合、SQL アダプターは基本的なデータベース呼び出しに使用するには複雑すぎます。概して、SQL Server と連携する場合に最も簡単でサポート可能な方法は、カスタムの .NET アセンブリ クラスを使用することです。オーケストレーションから呼び出されるクラスを開発するときは、必ずクラスをシリアライズ可能にして、どのようなトランザクションの状態からでも BizTalk がクラスを呼び出せるようにしてください。

namespace Demo.BizTalk.Helper {
    [Serializable]
    public class DataAccess
    { }
  }

EDI ソリューション用のオーケストレーションの開発は、その他の BizTalk 実装とまったく同じです。オーケストレーションを開発する場合に留意すべき最大のポイントは、オーケストレーションが複雑にならないようにすることです。BizTalk 開発および BizTalk プロジェクトの適切な編成には技術がいります。適切に計画および開発している場合は、更新および運用環境への展開を容易に実行できるソリューションを作成できます。

取引先の構成

BizTalk Server 2010 では、取引先との EDI ドキュメントの交換を管理するための新しいインターフェイスが導入されています。これは、パーティ、ビジネス プロファイル、および契約という、組織の基本的な 3 層で構成されています。

パーティは、取引先の最上位の組織を表します。このアイテムの構成は、この取引先と交換されるすべてのドキュメントに共通する事項に関連しています。たとえば、安全な通信のために必要になる証明書は、このレベルで構成します。

この記事の例では、関係者 (パーティ) は医療保険請求処理業者と病院の 2 つです。どちらも、それぞれ独自の BizTalk パーティとして設定されます。必要な構成は名前のみです (図 7 参照)。

image: Top-Level Party Configuration

図 7 最上位のパーティの構成

パーティには、1 つ以上のビジネス プロファイルが関連付けられます。ビジネス プロファイルは組織内の部門を表し、各部門には EDI ドキュメントの送受信に使用される固有のビジネス ID があります。ビジネス ID は、(送信されるドキュメントか受信されるドキュメントかに応じて) EDI ドキュメントの ISA06 または ISA08 セグメントに表示される値で、取引先を他のエンティティと区別し、一意に識別します。多くの組織では関連付けられるビジネス プロファイルは 1 つですが、複数のプロファイルが必要になる組織もあります。

この記事の例では、医療保険請求処理業者に 2 つのビジネス プロファイルがあります。1 つは専門用の医療保険請求処理を表し、もう 1 つは公共機関用の医療保険請求処理を表します。また、病院にも、国内の関連機関用と海外の関連機関用の 2 つのビジネス プロファイルがあります。図 8 は、これらのビジネス プロファイルが関連付けられているパーティを示しています。

image: Business Profiles Associated with Parties

図 8 パーティに関連付けられているビジネス プロファイル

ビジネス プロファイルはパーティ内の一意のビジネス ID を表すため、このレベルの構成はこの ID を使用して交換されるすべてのドキュメントに共通の情報に対応します。交換されるすべての種類のドキュメントに共通する、すべての送受信設定が構成されます。つまり、使用されるプロトコル (X12、EDIFACT、AS2)、検証設定、トランザクション セット (EDI ドキュメントではこのレベルで可能です)、受信確認、一部のエンベロープの設定は、すべてビジネス プロファイルにおいて構成されます。多くの場合、このレベルでは既定の情報を使用できます。ビジネス プロファイルの特定の契約の構成により、他の情報と併せてこの情報が定義されるためです。

ビジネス プロファイルには、1 つ以上の契約を構成できます。契約は、2 つのパーティ間での交換が予想されるドキュメントの種類を表します。契約では、エンベロープ、受信確認、および許可されるトランザクション セットについての詳細を定義します。たとえば、ある契約では特定のドキュメントの交換が許可され、997 受信確認が構成されていて、別の契約ではそれらの確認に先行する別の種類のドキュメントが許可されます。

この記事の例では、医療保険請求処理業者と病院がドキュメントを交換します。病院は医療保険請求を (X12 837 公共機関用バージョン 5010) を請求処理業者に送り、医療保険請求処理業者は受信確認 (X12 997) を病院に返送します。図 9 はエンベロープ ID の構成を示し、図 10 は病院から医療保険請求処理業者に送信されるドキュメントの契約のトランザクション セット構成を示しています。ここで、ウィンドウ上部のタブは、ドキュメントのフローを示しています。

image: Configuring ISA Envelope Settings on an Agreement

図 9 契約の ISA エンベロープ設定の構成

image: Configuring Transaction Sets on an Agreement

図 10 契約のトランザクション セットの構成

図 11 は、医療保険請求処理業者から病院に返送される受信確認の構成を示しています。

image: Configuring acknowledgments on an Agreement

図 11 契約の受信確認の構成

複数の取引先とドキュメントを交換する場合は、大半の構成がほぼ同じになると思います。唯一異なる点は、エンベロープの ISA セグメントに表示される ID です。

開発を容易にするため、契約構成画面から利用できるテンプレート機能を使用してください。この場合に利用が考えられるのは、[テンプレートとして保存] および [テンプレートから読み込む] という 2 つのボタンです。取引先の構成が完了し、正しいエンベロープ設定と受信確認を使用して EDI ドキュメントが両パーティ間で交換されるようになったら、契約設定をテンプレートとして保存し、将来契約を作成する際にひな型として使用できます。

ポート構成とドキュメント配信

BizTalk へのまたは BizTalk から外部取引先への実際のドキュメント配信は、ポートの構成によって処理されます。ポートには、配信メカニズムの種類 (FTP、ファイルなど) を定義し、取引先が予期するフラット ファイル EDI ドキュメントに BizTalk 内の XML ドキュメントを変換する BizTalk パイプラインが含まれます。パイプラインには、ドキュメントの EDI エンベロープを変換 (または作成) し、ドキュメントが解決されるパーティを特定するためのロジックが含まれます。

ポートによる EDI ドキュメントの処理を理解するため、受信確認の送信処理について説明します。前述のとおり、受信確認は BizTalk パーティの契約において構成されます。ドキュメントを受信すると、BizTalk は自動的に 997 受信確認を生成できます。このとき、BizTalk は 997 XML を作成してこれを BizTalk メッセージ ボックスに格納しますが、実はどこにもメッセージをルーティングしません。送信ポートを設定して、XML をフラット ファイルに変換し、エンベロープを追加して、これを適切な宛先に配信するように構成する必要があります。

受信確認を配信するように送信ポートを設定するには、次の基本的な 3 つの手順を実行します。

  1. 送信ポートおよび配信プロトコルの定義
  2. EdiSend パイプライン (または EDI パイプライン コンポーネントを使用したカスタム パイプライン) の組み込み
  3. 適切な受信確認を待ち受けするためのフィルターの構成

ドキュメントを特定の場所に配信するための送信ポートの構成は、簡単です。図 12 は、EdiSend パイプラインが構成された送信ポートを示しています。この送信ポートでは、完全な EDI エンベロープを使用してファイル ディレクトリにファイルが書き込まれ、適切な形式に変換されます。

image: Setting Pipeline and Delivery Information on a Port

図 12 ポートのパイプラインおよび配信情報の設定

送信ポートへのフィルターの設定も簡単です。(取引先から送られた 997 ではなく) 指定されている取引先に対してシステムによって生成された受信確認のみを受け付けるように指定するだけです。図 13 は、完全に構成されたフィルターのセットを示しています。

image: Filtering on a Send Port

図 13 送信ポートでのフィルター

まとめ

BizTalk Server 2010 の新しい EDI 機能は、取引先の管理を主眼としています。以前の BizTalk では実現できなかった階層型の関係や組織を、比較的簡単にモデル化できるようになりました。さらに、マップ インターフェイスも強化され、マッピング作成時の操作性も大幅に向上しています。さまざまな改良と機能強化により、BizTalk Server 2010 を使用した EDI ソリューションのモデル化および開発では素晴らしい成果を収めることができるでしょう。

Mark Beckner は、Inotek Consulting Group LLC の創設者です。BizTalk、SharePoint、Dynamics CRM、.NET 開発全般など、さまざまな Microsoft テクノロジに携わっています。連絡先は、mbeckner@inotekgroup.com (英語のみ) です。