X12 EDI Connector HIPAA

サポートカテゴリ: Premium

ベース X12 標準に加えて、X12 Module は X12 バージョン 005010 に基づいた HIPAA (医療保険の携行性と責任に関する法律) 標準もサポートしています。

X12 Module HIPAA のサポートには以下が含まれています。

X12 HIPAA EDI message-reading (メッセージの読み取り)、message-validation (メッセージの検証)、message-writing (メッセージの書き込み)
DataSense および DataWeave とのインテグレーション
005010X212、005010X214B3、005010X217、005010X218、005010X220A1、005010X221A1、005010X222A1、005010X222A2、005010X223A2、005010X223A3、005010X224A2、005010X224A3、005010X279A1 用の HIPAA メッセージパック
ベース X12 HIPAA スキーマをカスタマイズする機能

HIPAA の X12 Module での使用は、標準の X12 の使用とほぼ同じです。主な違いは次のとおりです。

スキーマの形式。
実行される検証の範囲とタイプ。
データ構造の表現。

提供されている HIPAA スキーマでは、ベース X12 スキーマとは異なる構造を使用します。HIPAA に使用される構造は、目的に応じて、多くの場合はコードセットおよび項目使用の異なる要件によって、トランザクションセットで同じセグメントが異なる場所で使用されることを反映しています。異なる使用を区別しやすいように、HIPAA スキーマではセグメントキーとして完全名を使用します。これは、セグメントキーで通常数値プレフィックスとセグメントタグを使用する、基本の X12 標準で使用される方法とは異なっています。

HIPAA スキーマには、要素について定義されたコードセットの詳細も含まれています。トランザクションセットを解析するときと書き込むときに、データはこれらのコードセットに対して検証されます。

このページでは、HIPAA トランザクションセットのための X12 Module の使用と、標準 X12 との使用の違いについて詳しく説明します。

前提条件

このドキュメントは、読者が X12、HIPAA、Mule、Anypoint Connector、Anypoint Studio、Mule フロー、Mule グローバル要素に精通していることを前提としています。

互換性情報については、リリースノートを参照してください。リリースノートへのリンクは、このドキュメントの「関連情報」セクションに含まれます。

X12 EDI Connector を本番環境で使用するには、Anypoint B2B 用の MuleSoft ライセンスを購入しておく必要があります。

このコネクタの新機能

HIPAA データ用の X12 EDI Connector 2.x によって使用されるデータ構造は、Mule 3.x で使用される 1.x バージョンのデータ構造とは異なります。

コネクタの 1.x バージョンでは、複合コンポーネントは使用時に効果的にインライン化されるため、複合コンポーネント内でネストされた個々の要素には、包含するセグメントに基づいてキーが与えられ、それらの要素は、セグメントを表すマップから直接参照されます。

コネクタの 2.x バージョンでは、各複合コンポーネントは代わりに子のマップによって表され、複合内の値には複合識別子に基づくキーが含まれます。

この構造の変更により、包含するセグメントまたはセグメント内の位置に関係なく、複合コンポーネント内のデータで一貫したマッピングを使用できます。

HIPAA の使用の設定方法

HIPAA トランザクションセット用に X12 Module コネクタを使用するには、以下を実行する必要があります。

使用する 1 つ以上の HIPAA スキーマを選択する。
目的の SNIP 検証の種別に応じて、Form (フォーム) および Validation (検証) 設定パラメーター (formValidation) を「HIPAA_SNIP1」または「HIPAA_SNIP2」に設定する。

HIPAA スキーマの場所を判断する方法

このコネクタを使用するには、プロジェクトのスキーマの場所を把握しておく必要があります。特に設定せずに HIPAA スキーマを使用し、何もカスタマイズしていない場合、スキーマの場所は /hipaa/{version}/{transaction-set}.esl のパターンに従います。たとえば、005010X222A2 バージョンおよび 837 トランザクションセットを使用している場合、スキーマの場所は /hipaa/005010X222A2/837.esl になります。

1 つ以上のカスタムスキーマを使用している場合、これらを src/main/resources に配置し、このディレクトリに対して相対的な場所を参照する必要があります。たとえば、HIPAA 837 スキーマを src/main/app/mypartner/837.esl に配置した場合、スキーマの場所は /mypartner/837.esl になります。

HIPAA スキーマ定義について

X12 Module では ESL (EDI スキーマ言語) と呼ばれる YAML 形式を使用して標準 X12 スキーマと HIPAA スキーマの両方を表現します。HIPAA 標準は X12 に基づいていますが、以下を含めて、いくつかの点で対応する X12 ベース標準を変更しています。

HL (階層レベル) ループの複数の特化された定義。X12 で定義された基本ループ構造が複数のバリエーションに拡張されており、多くの場合はネストされています。
定義のさまざまなポイントで再利用可能なモジュラーループ定義。
特定の要素のコード値による反復されたセグメントの異なる使用の区別。
セグメントおよびセグメントコンポーネントの使用要件の変更。

HIPAA のこれらの機能を表現するために、ESL スキーマ定義は標準 X12 スキーマと大きく異なっています。以下は、005010X222A2 837 トランザクションセットのスキーマから引用した例の一部です。

form: HIPAA
version: '005010X222A2'
structures:
- id: '837'
  name: 'Health Care Claim'
  class: 'HC'
  areas:
  - code: '1'
    items:
    - { idRef: 'ST_TransactionSetHeader', position: '0050', usage: M }
    - { idRef: 'BHT_BeginningOfHierarchicalTransaction', position: '0100', usage: M }
    - groupId: '1000A_Loop'
      usage: O
      items:
      - { idRef: 'NM1_SubmitterName', position: '0200', usage: M }
      - { idRef: 'PER_SubmitterEDIContactInformation', position: '0450', usage: M, count: 2 }
    - groupId: '1000B_Loop'
      usage: O
      items:
      - { idRef: 'NM1_ReceiverName', position: '0500', usage: M }
  - code: '2'
    items:
    - groupId: '2000A_Loop'
      count: '>1'
      usage: M
      items:
      - { idRef: 'HL_BillingProviderHierarchicalLevel', position: '0010', usage: I }
      - { idRef: 'PRV_BillingProviderSpecialtyInformation', position: '0030', usage: O }
      - { idRef: 'CUR_ForeignCurrencyInformation', position: '0100', usage: O }
      - groupId: '2010AA_Loop'
        usage: O
        items:
        - { idRef: 'NM1_BillingProviderName', position: '0150', usage: M }
        - { idRef: 'N3_BillingProviderAddress', position: '0250', usage: M }
        - { idRef: 'N4_BillingProviderCityStateZIPCode', position: '0300', usage: M }
        - { idRef: 'REF_BillingProviderTaxIdentification', position: '0350', usage: M }
        - { idRef: 'REF_BillingProviderUPINLicenseInformation', position: '0360', usage: O, count: 2 }
        - { idRef: 'PER_BillingProviderContactInformation', position: '0400', usage: O, count: 2 }
      - { area: '3', usage: O }
      - { area: '4', count: '>1', usage: O }
  - code: '3'
    items:
    - groupId: '2010AB_Loop'
      usage: O
      items:
      - { idRef: 'NM1_PayToAddressName', position: '0150', usage: O }
      - { idRef: 'N3_PayToAddressADDRESS', position: '0250', usage: M }
      - { idRef: 'N4_PayToAddressCityStateZIPCode', position: '0300', usage: M }
    - groupId: '2010AC_Loop'
      usage: O
      items:
      - { idRef: 'NM1_PayToPlanName', position: '0450', usage: O }
      - { idRef: 'N3_PayToPlanAddress', position: '0550', usage: M }
      - { idRef: 'N4_PayToPlanCityStateZIPCode', position: '0600', usage: M }
      - { idRef: 'REF_PayToPlanSecondaryIdentification', position: '0650', usage: O }
      - { idRef: 'REF_PayToPlanTaxIdentificationNumber', position: '0655', usage: M }

areas キーについて

上記の部分的なスキーマで、areas キーには各領域定義の値の配列が入ります。領域は通常の X12 トランザクションセットのヘッダー、詳細、概要の各セクションへの分解に似ていますが、それよりもはるかに細かくなっています。 X12 で定義されるトランザクションではこれら 3 つの部分に固定されているのに対して、HIPAA トランザクションセットでは 20 以上の領域を定義できます。

各領域は定義の再利用可能なコンポーネントであり、コード文字値によって識別されます。この値は慣例により 1 桁の数字または 1 つの英字が使用されます。

領域はコンポーネントリストの領域項目を含めて定義に含めるために参照されます。X12 スキーマ定義では、グループまたは領域のコンポーネントのリストにセグメント、グループ、wrapped と呼ばれるグループバリエーション (X12 の用語で LS/LE ループに使用) のみが含まれる場合があります。HIPAA スキーマ定義では、コンポーネントのリストに領域参照も含まれる可能性があります。領域を参照する効果は、領域のすべてのコンポーネントが参照の時点での定義に挿入された場合と同じです。

もう一度上記の部分的なスキーマを見てみると、領域コード「2」のコンポーネントリストの最後が領域「3」および「4」を参照しており、領域「4」が必要に応じて反復されています。

HIPAA メッセージのデータ構造では、見出し、詳細、概要の各セクションに分かれた X12 の区分を保持します。見出しは常に並び替え順が最も低いコードの領域であり、詳細はその次 (すべての参照される領域を含む)、概要は並び替え順が最も高いコードです。

コードセットについて

次に、上で使用したのと同じ 005010X222A2 837 トランザクションセットの別の部分を示します。この部分は、BHT_BeginningOfHierarchicalTransaction セグメント定義を示しています。

- id: 'BHT_BeginningOfHierarchicalTransaction'
  name: 'Beginning of Hierarchical Transaction'
  varTag: 'BHT'
  values:
  - { id: '1005', name: 'Hierarchical Structure Code', usage: M, codeSet: { '0019': 'Information Source, Subscriber, Dependent' }, type: ID, length: 4 }
  - { id: '353', name: 'Transaction Set Purpose Code', usage: M, codeSet: { '00': 'Original', '18': 'Reissue' }, type: ID, length: 2 }
  - { id: '127', name: 'Originator Application Transaction Identifier', usage: M, type: AN, minLength: 1, maxLength: 50 }
  - { id: '373', name: 'Transaction Set Creation Date', usage: M, type: DT, length: 8 }
  - { id: '337', name: 'Transaction Set Creation Time', usage: M, type: TM, minLength: 4, maxLength: 8 }
  - { id: '640', name: 'Claim or Encounter Identifier', usage: M, codeSet: { 'RP': 'Reporting', 'CH': 'Chargeable', '31': 'Subrogation Demand' }, type: ID, length: 2 }

このセグメントの最初の要素、2 番目の要素、最後の要素は、キーと値のペアの配列の形式で codeSet 値を定義しています。各ペアのキーは、HIPAA 標準によって許可された項目の特定の値であるのに対して、キーの値は標準からのその値のテキストの説明です。

X12 EDI Connector は HIPAA ドキュメントのこれらのコードセットを適用し、解析または書き込みのいずれかを行うときに、トランザクションセットが項目の未定義の値 (つまり、codeSet にキーとしてリストされていない値) を使用するとエラーを知らせます。BHT 定義の最初の要素など、1 つの値しか使用できない場合もあれば、多数の値を使用できる場合もあります。

セグメントのバリエーションについて

次に、同じ 005010X222A2 837 トランザクションセットのさらに別の部分を示します。この部分は、2 つの異なる DTP セグメント定義を示しています。

- id: 'DTP_DateAccident'
  name: 'Date - Accident'
  varTag: 'DTP'
  values:
  - { id: '374', name: 'Date Time Qualifier', usage: M, varValue: true, codeSet: { '439': 'Accident' }, type: ID, length: 3 }
  - { id: '1250', name: 'Date Time Period Format Qualifier', usage: M, codeSet: { 'D8': 'Date Expressed in Format CCYYMMDD' }, type: ID, minLength: 2, maxLength: 3 }
  - { id: '1251', name: 'Accident Date', usage: M, type: AN, minLength: 1, maxLength: 35 }
- id: 'DTP_DateAcuteManifestation'
  name: 'Date - Acute Manifestation'
  varTag: 'DTP'
  values:
  - { id: '374', name: 'Date Time Qualifier', usage: M, varValue: true, codeSet: { '453': 'Acute Manifestation of a Chronic Condition' }, type: ID, length: 3 }
  - { id: '1250', name: 'Date Time Period Format Qualifier', usage: M, codeSet: { 'D8': 'Date Expressed in Format CCYYMMDD' }, type: ID, minLength: 2, maxLength: 3 }
  - { id: '1251', name: 'Acute Manifestation Date', usage: M, type: AN, minLength: 1, maxLength: 35 }

これらの 2 つの定義は、2300 請求情報ループの一環として、DTP セグメントの異なるインスタンスに適用されます。トランザクションセット構造では、DTP セグメントのこうした使用は基本的に同じ場所で起こり、ベース X12 標準で反復する DTP セグメントが 2 回起こる可能性があるのに一致します。ただし、セグメントのこの 2 つの使用によって異なる情報が提供されるため、HIPAA 標準ではこれらに異なる名前が付き、DTP03 項目の解釈方法が異なります。

この場合、セグメントの最初の項目である [Date Time Qualifier (日時修飾子)] 項目のデータ値は、セグメントのどちらのバリエーションが実際に使用されているかを識別します。この項目のコードセットはこれらのそれぞれの使用で異なる値になるため、項目に表示される値によって、解析されたドキュメントの DTP セグメントが DTP_DateAccident であるか DTP_DateAcuteManifestation (または、同じ部分の DTP セグメントの異なる使用のいずれか) であるかがわかります。スキーマ定義の varValue: true フラグは、この最初の項目がこのようにバリエーションを区別するために使用されていることを示します。

この項目の値は事実上セグメントの各使用で固定ですが、それでもデータを書き込むときに正しく設定する必要があります。この項目に異なる値を指定するか、値を指定しないと、書き込んだときにエラーが発生します。

構文ルールについて

次に、構文ルールの表現方法について説明するために、005010X222A2 837 トランザクションセットスキーマから最後の例を挙げます。

- id: 'N4_PayerCityStateZIPCode'
  name: 'Payer City, State, ZIP Code'
  varTag: 'N4'
  values:
  - { id: '19', name: 'Payer City Name', usage: M, type: AN, minLength: 2, maxLength: 30 }
  - { id: '156', name: 'Payer State or Province Code', usage: O, type: ID, length: 2 }
  - { id: '116', name: 'Payer Postal Zone or ZIP Code', usage: O, type: ID, minLength: 3, maxLength: 15 }
  - { id: '26', name: 'Country Code', usage: O, type: ID, minLength: 2, maxLength: 3 }
  - { id: '309', name: 'Location Qualifier', usage: U, type: ID, minLength: 1, maxLength: 2 }
  - { id: '310', name: 'Location Identifier', usage: U, type: AN, minLength: 1, maxLength: 30 }
  - { id: '1715', name: 'Country Subdivision Code', usage: O, type: ID, minLength: 1, maxLength: 3 }
  rules:
  - { type: E, items: [2, 7] }
  - { type: C, items: [6, 5] }
  - { type: C, items: [7, 4] }

構文ルールは、X12 および HIPAA で、セグメントまたは複合内の値間のリレーションを定義するために使用されます。ルールは、値のリストと同じレベルでスキーマに含まれます。ルールのタイプのコードは X12 および HIPAA 仕様によって使用されているのと同じであり、項目のリストでルールによって制御される値の数が示されます。

上記の例の場合、3 つのルールから次のことがわかります。

N402 または N407 のいずれかのみが存在する可能性がある ({ type: E, items: [2, 7] })
N406 が存在する場合、N405 が必須である ({ type: C, items: [6, 5] })
N407 が存在する場合、N404 が必須である ({ type: C, items: [7, 4] })

スキーマの変更方法

標準 X12 スキーマと HIPAA スキーマの違いにより、ベース定義を変更するためのオーバーレイスキーマの使用は HIPAA ではサポートされていません。代わりに、変更の方法として、指定された HIPAA スキーマを x12-schemas-2.0.0.jar 内から抽出する方法をお勧めします。このファイルは、標準の MuleSoft Enterprise Maven リポジトリ (グループ ID の com.mulesoft.connectors の下) にあります。メッセージ構造スキーマをこの JAR (標準 X12 スキーマと HIPAA スキーマの両方が含まれる) からコピーし、抽出したスキーマを変更して直接使用できます。そのままではセグメント、複合、要素定義のベースセットを使用する X12 スキーマと異なり、HIPAA スキーマは自己完結型です。これにより、複数のファイルを操作することなく、簡単にスキーマを変更できます。

WEDI からの推奨されるテストのタイプについて

タイプ 1: EDI 構文整合性テスト – 有効なセグメント、セグメント順、要素属性に関する EDI ファイルのテスト、数値データ要素の数値のテスト、X12 または NCPDP 構文の検証、X12 および NCPDP ルールへの準拠。これにより、EDI 送信の基本的な構文の整合性が検証されます。
タイプ 2: HIPAA 構文要件テスト – 反復数の制限、使用済みおよび未使用の修飾子、コード、要素、セグメントなどの、HIPAA 実装ガイド固有の構文要件のテスト。このタイプのテストには、必要な HIPAA またはセグメント内の状況型データ要素のテスト、WEDI SNIP 実装ガイドで詳細に記されている非医療コードセット、および X12 コードリストまたはテーブルを使用した WEDI SNIP 実装ガイドに記されている値およびコードのテストも含まれます。
- コネクタはセグメント内の状況型データ要素の一連のアクションを判断できないため、セグメント内の状況型データ要素は X12 EDI Connector ではサポートされません。ユーザーはコネクタ外で検証ロジックを設定する必要があります。