ヘルスケアEDI ドキュメントの変換と統合（X12 837ドキュメントをCSV に変換）

• EDI 統合の概要
  • EDI 変換
  • 宛先フォーマットの変換
  • XML マッピング
• サンプル837 フロー
  • X12 コネクタ
    • サンプルX12 ファイル
  • CSV コネクタ
    • サンプルCSV ファイル
  • XML Map コネクタ
    • Foreach ループ（要求）
    • 値のマッピング
    • 先読み（NM1Loops）
    • 条件付きスクリプト（IsChargeable）
    • データの仮定（ClaimDiagnosisCode）
• 結論

Arc のマッピングツールを使用すると、X12 837 などのヘルスケア固有のドキュメントを含む、EDI データのあらゆるマナーを処理できます。パッケージ化されたArc のフローテンプレートのひとつは、入力837 ドキュメントを、バックエンド処理用のフラットCSV ファイルにマッピングします。この記事では、この特定のフローとEDI マッピングフローの両方を一般的に理解するのに役立つ概念について説明します。

この記事を読みながら試すには、こちらから837-to-CSV フローをダウンロードしてください。

この記事ではまず、Arc におけるEDI 統合の概要を説明し、次に837 フローに固有の詳細について説明します。

Arc でのEDI 統合には、主に以下の3つのステップがあります。

• EDI をXML に変換
• デスティネーションフォーマット（例：CSV）をXML に変換
• これら2つのXML 構造の間をマッピング

このアプローチを理解する上で重要な点は、Arc がデータ変換の一般的な媒体としてXML を使用することです。開始データと終了データの両方がXML としてモデル化されるため、実際の変換ステップは2つのXML 構造の間で行われます。

このセクションでは、各ステップに関連する概念を紹介します。これらの概念は、次のセクションで実装されます。

Arc はデータを変換および統合するための共通の媒体としてXML を使用するため、EDI フローの最初のステップはEDI データをXML に変換することです。Arc には、特定のファイルフォーマットをXML に変換したり、XML を別のフォーマットに変換するための専用コネクタが数多く用意されています。

XML 変換ステップの最中で、Arc はEDI インターチェンジヘッダーも検証して、ドキュメントが予想される相手との間で送受信されたことを確認します。各EDI コネクタ（X12 コネクタ、EDIFACT コネクタなど）の設定は、ドキュメントのヘッダーを検証するために使用されます。

EDI コネクタは任意のドキュメントタイプを変換できるため、837、834、270 などの変換に必要なコネクタは1つだけです。

EDI データをXML に変換することに加えて、デスティネーションデータフォーマットのXML テンプレートを生成することも必要です。たとえば、EDI データを最終的にCSV ファイルに変換する必要がある場合は、CSV ファイルのXML テンプレートを生成する必要があります。

Arc のファイルフォーマットコネクタでは、コネクタのテストファイルをアップロード機能を使用してXML テンプレートを自動的に生成できます。たとえば、サンプルCSV ファイルをテストファイルとしてCSV コネクタにアップロードすると、XML テンプレートが生成されます。

Arc ではXML テンプレートを手動で生成することもできるため、XML に変換されたファイルはすべてデスティネーションテンプレートとして直接アップロードできます。

Arc は、データベースの入出力もXML としてモデル化するため、EDI データをデータベースに統合する場合、宛先の形式をXML テンプレートに変換する必要はありません。デスティネーションテンプレートはすでにXML としてモデル化されています。

EDI データとデスティネーションフォーマットの両方がXML としてモデル化されたら、あとは1つのXML 構造を別のXML 構造にマップするだけです。このマッピング関係が確立されると、データは以下のパターンに従って流れます。

• 入力データはXML に変換されます。
• 入力XML は、出力ドキュメントのXML フォーマットにマッピングされます。
• 出力XML は出力フォーマットに変換されます。

XML Map コネクタは、2つのXML 構造間のマッピング関係を確立するために使用されます。このコネクタには、マッピングの際にデータを操作および変換するための多くの強力なツールも含まれています。

XML マッピングは、データへの理解と典型的な作業が最も要求されるステップです。この記事の次のセクションでは、独自のEDI 統合を実装する際に理解しておくことが最も重要な、フローテンプレートで確立されたマッピング関係に主に焦点を当てます。

一般的なEDI マッピングの原則について説明しました。次に、サンプル837 のマッピングフローに移ります。続行する前にこのフローをインストールすることを強くお勧めします。

フローテンプレートは、X12 コネクタ、XML Map コネクタ、およびCSV コネクタで構成されています。これらのコネクタは、上記のArc でのEDI 統合の概要のサブセクションに（順番に）対応しています。

X12 コネクタは、入力837 ドキュメントをXML に変換します。XML はArc のデータマッピングのための一般的な形式であるため、これはEDI データをさらに処理するために必要なステージングステップです。

製品フローでは、X12 コネクタも、これらの837 ドキュメントを送信するパーティのEDI 識別子を使用して構成されます。X12 コネクタは、XML 変換ステップ中に、これらの設定に従って入力ドキュメントを検証します。これらのパーティ識別子は個々のユースケースに固有であるため、フローで提供されているサンプルX12 コネクタには含まれていません。

X12 コネクタが使用状況インジケータフィールドでT - Test Data を処理するように設定されている場合、コネクタは検証をバイパスし、EDI ファイルをXML に変換します。これにより、事前設定なしでフローをテストできます。

このフローテンプレートには、テストクレームデータを含むサンプルX12 837 ドキュメントが含まれています。プロバイダーによってこれらの837 ドキュメントの生成方法が微妙に異なる場合があるため、このサンプルファイルは、すべての製品ユースケースに完全に一致するとは限りません。

最も重要な点は、サンプルX12 ファイルがEDI ドキュメントの構造と、この構造をCSV のようなまったく異なるフォーマットにマッピングする方法を示していることです。サンプルの837 と実際の837 ドキュメントとの違いは、マッピングの値をわずかに変えるだけで、この記事で説明した概念を変えずに扱うことができます。

CSV コネクタはXML をCSV に変換するため、EDI からCSV へのフローの最終ステップとなります。CSV コネクタでは、サンプルCSV ファイルを使用してXML マッピングのデスティネーション構造を確立することもできます。

このケースを理解するには、まずCSV コネクタがデータをCSV からXML とXML からCSV の双方向に変換することを理解することが重要です。 コネクタはCSV ファイルを処理する際に、標準構造のXML ファイルに変換します。XML ファイルをCSV に戻すには、CSV ファイルを生成するためにXML がこれと同じ標準構造を持っている必要があります（データ自体は異なります）。

EDI データをCSV コネクタが受け入れるXML 構造にマッピングするには、最初にサンプルの目的のCSV ファイルをXML に変換する必要があります。生成されたXML がマッピングのターゲットとなり、その構造に一致する任意のXML ファイルがCSV コネクタによって目的のCSV ファイルに変換されます。

このフローテンプレートには、837 データの格納に必要と考えられるフィールドを含むサンプルCSV ファイルが含まれています。デスティネーションCSV に関連する特定のフィールドは、特定のユースケースの詳細に依存するため、サンプルのCSV ファイルは837 データの包括的な表現を提供することを目的としていますが、この正確なCSV フォーマットがすべての顧客の正確な要件に一致することは期待できません。

最も重要なのは、サンプルのCSV ファイルが、EDI データをCSV のようなフラットなフォーマットにマッピングするプロセスを示していることです。この記事で説明した一般的なマッピングの概念を乱すことなく、CSV ファイル内の特定のフィールドを追加、削除、または再配置できます。

XML Map コネクタは、このフローテンプレートに関連する作業の大部分を実行します。一般に、XML Map コネクタとのマッピング関係を確立するプロセスは以下のとおりです。

• ソースファイルのXML テンプレートを設定します（フローの例でこれは、X12 コネクタによってXML に変換された837 ドキュメントです）。
• デスティネーションファイルのXML テンプレートを設定します（フローの例でこれは、CSV コネクタによってXML に変換されたサンプルCSV ファイルです）。
• 要素をソース構造からビジュアルデザイナ内のデスティネーション構造の要素にドラッグします。

このセクションでは、サンプルのXML Map コネクタで確立されたマッピング関係を理解するために重要な概念について説明します。これらと同じ概念を使用して独自のカスタムマッピング関係を生成できますが、適切な値をマッピングするには、使用しているデータを常に理解しておく必要があります。

マッピングの最初の側面は、デスティネーションの（CSV ファイルの行を表す）ClaimItem と各CLMLoop1 内のLXLoop 1 との間で確立されるForeach ループ関係です。これは、Foreach 修飾子プレフィックスが付いた緑色のxpath を介してClaimItem 要素の横に表示されます。

CLMLoop1 は要求を表し、その中の各LXLoop1 は要求の詳細項目を表します。したがって、Foreach 関係は次のようになります。

各要求の各ラインアイテムは、デスティネーションCSV ファイルの新しい行になります。

そのため、CSV の行には特定の要求ラインアイテムのデータが含まれます。

EDI データをCSV のようなフラットフォーマットにマッピングするには、まず、各CSV 行が何を表すかを決め、その結果どのセグメントがCSV 行要素とForeach 関係を持つかを決定します。

Foreach ループの関係は、ソースの親ノードをデスティネーションの親ノードにドラッグすることで確立されます。親ノードは、子を持ち、値を持たないノードです。これらは、展開（子を表示）または縮小（子を非表示に）できるため、XML Map コネクタのビジュアルデザイナで簡単に認識できます。

Foreach リレーションシップが確立され、各要求ラインアイテムの新しいCSV 行が生成されたら、各行のフィールドにソースEDI ドキュメントのデータを入力する必要があります。これらの値から値へのマッピングは、（Foreach 修飾子プレフィックスなしで）角括弧内の緑色のxpath を介して表示されます。緑色のxpath は、値の取得元となるソースドキュメント内のパスを示します。

注意：値マッピングの緑色のxpath は、内部にあるForeach xpath を基準にしています。このマッピング例では、Foreach xpathが1 つしかないため、すべての値のxpath はソースのLXLoop1 要素を基準にしています。

たとえば、各要求ラインアイテムのサービス量は、要求ラインアイテムを表すLXLoop1 セグメント内にあるSV1/SV102 要素内に格納されます。すべての値xpath はすでにLXLoop1 のxpath に対する相対値であるため、Service Amount の値は[SV1/SV102] から取得されます。

一部の値xpath には、「dot-dot」構文が含まれています：.. これは、xpath が現在のForeach ループのxpath を「終了」し、ソースドキュメント内の以前のレベルにアクセスすることを意味します。たとえば、LXLoop1 ノードはCLMLoop1 ノード内に直接あるため、.. 構文は、LXLoop1 を前のCLMLoop1 セグメントに 「残す」 ことを意味します。この構文は、ソースXML 構造経由で外側（つまり、子から親）に移動するように連結することができます。

値から値へのマッピングは、ソースの葉ノードをデスティネーションの葉ノードにドラッグすることで確立されます。葉ノードは、値を持ち、子を持たないノードです（拡張または縮小することはできませんが、実際のデータが含まれています）。

フルカスタムマッピングでは、ソース葉ノードをデスティネーションにドラッグするプロセスが何度も繰り返され、各値がソースからデスティネーションにマッピングされます。当然これには、ソースのどの値がデスティネーションの目的のフィールドに対応するかを理解する必要があります。

一部の値マッピングでは、正しい値がソースからマッピングされるようにするために、追加の構文が必要です。この追加構文は「先読み」と呼ばれ、エクスプレッションエディタ内でデスティネーションノードに指定されます。

このマッピングの各先読みの例には、ソースのNM1Loop からの値が含まれます。それぞれのNM1Loop は、サービスプロバイダーや加入者、プラクティショナなど、交換のパーティを表します。各NM1Loop には異なるパーティのデータが含まれているため、データをマッピングするときにNM1Loop セグメントを識別することが重要です。ただし、一部のNM1Loop セグメントはNM1/NM101 値に基づいてのみ識別できるため、ループを「調査」してNM101 値を確認するには、先読みが必要です。

例として、2 番目のHLLoop1 内の2つのNM1Loop2 ノードにあるEDI ソースデータを見てみましょう。わかりやすくするために、これらのNM1Loop2 ノードへのxpath を以下に示します。

/Interchange/FunctionalGroup/TransactionSet/TX-00501-837/HLLoop1[2]/NM1Loop2

これらのNM1Loop2 セグメントの1つには支払者のデータが含まれ、もう1つには加入者のデータが含まれます。どちらがどちらであるかを判断するには、NM1/NM101 値を確認する必要があります。

• 「IL」は加入者を意味します。
• 「PR」は支払者を意味します。

この値を決定してはじめて、このNM1Loop2 に、特定のデスティネーションノードにマッピングするデータが含まれているかどうかがわかります。

XML Map コネクタでこの先読みがどのように表示されるかを確認するには、デスティネーション（CSV）でSubscriberLastName ノードを検索します。このノードの値マッピング（xpath）はNM1Loop2/NM1/NM103 から値を取得しますが、先読み条件を指定する追加の構文が角括弧内にあります。

[NM1/NM101='IL']

この先読み条件は、NM1Loop2 セグメントを識別します。NM1/NM101 が「IL」（「加入者」のコード）に等しいNM1Loop2 からの値だけをマッピングします。このようにすることで、支払人の姓ではなく、加入者の姓がマッピングされることを確認します。

先読みはエクスプレッションエディタで指定します。エクスプレッションエディタを開くには、目的のノードの横にあるタブレットと鉛筆のアイコンをクリックします。SubscriberLastName ノードのエクスプレッションエディタを開くことで、先読み条件がエスケープされた角括弧を使用して通常のxpath 表記の途中で追加されていることを確認できます。独自の先読み条件を追加する場合は、以下の2つの手順を使用します。

• まず、通常のドラッグアンドドロップアプローチを使用して適切な値をマッピングします。
• エクスプレッションエディタを開き、繰り返されるセグメントを識別するために、エスケープされた角括弧に先読み条件を追加します。

サンプルマッピングには、カスタムスクリプトロジックにマッピングされた2つのノード（IsReissue とIsChargeable）が含まれています。スクリプトを表示するには、デスティネーションパネルでこれらのノードを検索し、その横にある</\> ボタンをクリックします。このセクションでは、マッピング中にカスタムロジックを実装する方法を説明するために、IsChargeable ノードのスクリプトについて簡単に説明します。

IsChargeable のスクリプトを以下に示します。

<arc:set attr="isChargeable" value="" />

<arc:if exp="[xpath(../../../BHT/BHT06) | equals('CH')]">
  <arc:set attr="isChargeable" value="YES" />
  <arc:else>
    <arc:set attr="isChargeable" value="NO" />
  </arc:else>
</arc:if>

<arc:set attr="result.text">[isChargeable]</arc:set>

まず、このマッピングスクリプトは、アプリケーションに含まれている専用のスクリプト言語であるArcScript で記述されていることに注意してください。ArcScript に慣れるための入門書は、こちらのナレッジベースにあります。

このスクリプトは、入力EDI ドキュメント（具体的にはBHT/BHT06 要素）から値を読み取り、この値が「CH.’」と等しいかどうかを確認しています。「CH」はチャージ可能なトランザクションのコードであるため、isChargeable 変数は、そのコードが存在する場合は 「YES」 に設定され、存在しない場合は 「NO」 に設定されます。スクリプトの最後の行は、isChargeable 変数の値を返し、出力ドキュメントにマッピングされます。

IsReissue 出力ノードのロジックは非常に似ていますが、BHT セグメントの別の要素を確認しています。

これらは、マッピング中にスクリプトロジックを利用してデータを変更する簡単な例ですが、ArcScript の完全な柔軟性をXML Map コネクタ内で利用することで、さまざまなユースケースに対応できます。

マッピング関係によっては、処理されるデータについて前提条件を設定する必要があります。このフローテンプレートには、要求診断情報を含む2つの出力要素のセットがあります。

• ClaimDiagnosisCodeQualifier1
• ClaimDiagnosisCode1
• ClaimDiagnosisCodeQualifier2
• ClaimDiagnosisCode2

これらの要素は、繰り返しHI セグメントへの「ハードコードされた」参照でマッピングされます。たとえば、ClaimDiagnosisCode1 要素は以下のようにマッピングされます。

[../HI[1]/HI01/HI0102]

HI セグメントの横にある「 [1] 」構文は、値がこのxpath の最初の出現から無条件にマッピングされる必要があることを示します。使用するセグメントを決定するために角括弧内で条件を指定した、前述の「先読み」セクションとの違いに注意してください。

ClaimDiagnosisCode2 要素は、微妙に異なるxpath にマッピングされます。

[../HI[2]/HI01/HI0102]

これは、値がこのxpath の2 回目の出現、つまりHI セグメントの2 回目の繰り返しから無条件に取得されることを意味します。このような繰り返しが存在しない場合、出力ノードは空のままになります。

このマッピングアプローチでは、最大で2つのClaimDiagnosisCode 値が関連していると想定しています。別のアプローチでは、この前提条件が必要なくなるかもしれません。たとえば、診断情報を含むCSV ファイルに2行目のタイプを導入すると、マッピングで任意の数のコードを処理できます。しかし、上記の前提条件を作成することで、出力データ構造とマッピング全体の単純さが維持されます。

このフローの例を実際の運用ケースで動作させるために、この前提条件を修正するか、対処する必要がある場合があります。このサンプルは、ライブデータのケースの大部分を処理することを想定していますが、マッピングされるデータについて、真実でなければならない前提を理解することは常に重要です。

この記事の目的は、サンプルの837 からCSV へのフローが特定のマッピングニーズにどのように関連しているかを知るためのコンテキストを提供することです。EDI マッピングフローの原則を理解したら、作業の大部分はXML Map コネクタ内の特定のマッピング関係を理解することになります。

このサンプルには、EDI マッピングに見られる基本的なマッピング手法の多くが含まれています。

• 繰り返しを処理するForeach ループ
• 値から値へのマッピング
• 先読み条件式
• カスタムスクリプトロジック

XML Map コネクタで使用可能なツールの詳細については、専用のドキュメントページを参照することをお勧めします。