X12 EDI Connector 2.17 HIPAA - Mule 4

X12 EDI Connector 用 Anypoint Connector 2.9 - HIPAA では、X12 EDI Connector 標準およびバージョン 005010 ドキュメント種別に基づいた医療保険の携行性と責任に関する法律 (HIPAA) 標準をサポートしています。ここでは、HIPAA トランザクションセット用の X12 EDI Connector の使用方法と、標準 X12 との違いについて説明します。 X12 標準についての詳細は、「X12 EDI Connector の概要」と「EDI スキーマ言語リファレンス」を参照してください。

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

X12 HIPAA EDI のメッセージの読み取り、メッセージの検証、メッセージの書き込み
DataSense および DataWeave とのインテグレーション
ベース X12 HIPAA スキーマをカスタマイズする機能

X12 EDI Connector と組み合わせた HIPAA の使用は、標準の X12 の使用とほぼ同じです。主な違いは次のとおりです。

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

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

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

HIPAA の使用の設定

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

使用する 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 EDI Connector では、EDI スキーマ言語 (ESL) と呼ばれる 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 }yaml
コンテンツを展開する

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 }yaml

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

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

セグメントのバリエーションの指定

次に、同じ 005010X222A2 837 トランザクションセットのスキーマの例の 3 つ目の部分を示します。この例では、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 }yaml

これらの 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] }yaml

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

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

N402 と N407 のいずれか 1 つのみが存在できる ({ 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 からの推奨される検証の種別

整合性テストには、2 つの検証の種別を使用できます。

種別 1: EDI 構文整合性テスト

有効なセグメント、セグメント順、要素属性に関する EDI ファイルのテスト、数値データ要素の数値のテスト、X12 または NCPDP 構文の検証、X12 および NCPDP ルールへの準拠。これにより、EDI 送信の基本的な構文の整合性が検証されます。

種別 2: HIPAA 構文要件テスト

反復数の制限、使用済みおよび未使用の修飾子、コード、要素、セグメントなどの、HIPAA 実装ガイド固有の構文要件のテスト。このタイプのテストには、必要な HIPAA またはセグメント内の状況型データ要素のテスト、WEDI SNIP 実装ガイドで詳細に記されている非医療コードセット、および X12 コードリストまたはテーブルを使用した WEDI SNIP 実装ガイドに記されている値およびコードのテストも含まれます。

コネクタはセグメント内の状況型データ要素の一連のアクションを判断できないため、セグメント内の状況型データ要素は X12 EDI Connector には含まれず、コネクタ外の検証ロジックで設定する必要があります。