HL7 EDI コネクタ

Premium

HL7 EDI コネクタを使用すると、リストとマップを使用して、HL7 ER7 メッセージを DataWeave 互換の表現との間で変換できます。

前提条件

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

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

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

このコネクタの新機能

HL7 EDI コネクタ 4.0.0 で使用するデータ構造は、Mule 3.x で使用する 3.x バージョンのデータ構造とは異なります。

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

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

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

Design Center での接続方法

HL7 EDI コネクタ 4.0 は Design Center では使用できません。

Anypoint Studio 7 でこのコネクタをインストールする方法

  1. Anypoint Studio で、Studio タスクバーの Exchange アイコンをクリックします。

  2. Anypoint Exchange で [Login (ログイン)] をクリックします。

  3. コネクタを検索して [Install (インストール)] をクリックします。

  4. 画面の指示に従ってコネクタをインストールします。

Studio の更新がある場合、右下隅にメッセージが表示されます。メッセージをクリックすると、更新をインストールできます。

HL7 EDI コネクタ 4.0.0 を使用するようにデフォルトの Anypoint 設定を変更する必要があります。

Anypoint Studio 7.1.0 以降で HL7 EDI コネクタ 4.0.0 を使用するには、標準を上回るメモリ設定が必要です。Studio のメモリ設定を変更するには、Anypoint Studio インストールディレクトリにある Anypoint.ini ファイルを編集し、-Xms および -Xmx で始まる 2 つの行を変更します。

-Xms4096m
-Xmx4096m

これにより、Anypoint Studio メモリが 4GB に設定されます。これは、このコネクタのほとんどの用途に対応する十分な容量です。

スキーマの作成方法

スキーマを作成し、実装に従ってメッセージを記述します。

EDI スキーマ言語について

HL7 EDI では、ESL (EDI スキーマ言語) と呼ばれる YAML 形式を使用して EDI スキーマを表します。 基本 ESL は、構造 (HL7 用語のメッセージ構造)、グループ、セグメント、複合、および要素の観点で ER7 メッセージの構造を定義します。HL7 バージョン v2.1、v2.2、v2.3.1、v2.3、v2.4、v2.5、v2.5.1、v2.6、2.7、2.7.1、2.8、および 2.8.1 の ESL が次の 2 種類の形式で含まれます。 2.

  • 標準 HL7。HL7 バージョンごとにリストされている必須または省略可能な状況、データ型、項目の長さ、および反復数を使用します。

  • 可変 HL7。すべてのセグメントおよび値項目が省略可能です。低レベルのすべてのデータ型は単純な文字列として処理され、項目の長さと反復数は適用されません。

コネクタで提供されるメッセージ構造のスキーマ定義の詳細は、HL7 スキーマリストを参照してください。

HL7 スキーマ定義をデータに合わせてカスタマイズするには、スキーマ定義を直接コピーして編集するか、コンソールツールを使用して 1 つ以上のサンプルドキュメントに基づいて簡単なスキーマを生成することができます。また、他の EDI 形式と同様に HL7 のオーバーレイスキーマを使用することもできますが、HL7 定義の複雑さのためこのオプションはお勧めできません。

独自のスキーマを最初から定義することもできます。 詳細は、「EDI スキーマ言語リファレンス」を参照してください。

YAML では、リストとキー-値ペアのセットの組み合わせが使用されます。必須項目が存在する場合、値の順序は重要ではありません。数字で構成される可能性があっても文字列として解釈するように意図される値は、引用符 (単一引用符または二重引用符) で囲みます (そうしないと、YAML パーサーは値を数値として処理するため)。インデントを使用して、リストのネストを示します。

読みやすくすることを目的として、ここで示している ESL 構造では、同じ定義の一部であるリストの前に、すべての簡単なキー-値ペアを定義しています。

スキーマ定義のコピーおよび編集

HL7 スキーマ定義は hl7-schemas-4.0.0.jar 内で配布されます。これは、HL7 EDI コネクタ更新サイト内に組み込まれているか、標準の MuleSoft Enterprise Maven リポジトリ (グループ ID の com.mulesoft.connectors の下) にもあります。この JAR からメッセージ構造スキーマをコピーして、特定のニーズに合わせて編集できます。セグメントレベルでの変更のみが必要な場合は、メッセージ構造スキーマをコピーするだけで済みます。セグメント定義の変更が必要な場合は、同じバージョンの basedefs.esl スキーマもコピーする必要があります。このファイルにセグメント、複合、および要素の定義が含まれるためです。

「EDI スキーマ言語リファレンス」では、HL7 EDI コネクタを含め、すべての EDI コネクタで使用される ESL スキーマ構造の概要が説明されています。 スキーマ定義の構造については、このドキュメントを参照してください。

標準の v2.5.1 ADT_A05 メッセージ構造の HL7 メッセージ構造スキーマの例を次に示します。

form: HL7
version: '2.5.1'
imports: [ '/hl7/v2_5_1/basedefs.esl' ]
id: 'ADT_A05'
name: 'ADT_A05'
data:
- { idRef: 'MSH', position: '01', usage: M }
- { idRef: 'SFT', position: '02', usage: O, count: '>1' }
- { idRef: 'EVN', position: '03', usage: M }
- { idRef: 'PID', position: '04', usage: M }
- { idRef: 'PD1', position: '05', usage: O }
- { idRef: 'ROL', position: '06', usage: O, count: '>1' }
- { idRef: 'NK1', position: '07', usage: O, count: '>1' }
- { idRef: 'PV1', position: '08', usage: M }
- { idRef: 'PV2', position: '09', usage: O }
- { idRef: 'ROL', position: '10', usage: O, count: '>1' }
- { idRef: 'DB1', position: '11', usage: O, count: '>1' }
- { idRef: 'OBX', position: '12', usage: O, count: '>1' }
- { idRef: 'AL1', position: '13', usage: O, count: '>1' }
- { idRef: 'DG1', position: '14', usage: O, count: '>1' }
- { idRef: 'DRG', position: '15', usage: O }
- groupId: 'PROCEDURE'
  count: '>1'
  usage: O
  items:
  - { idRef: 'PR1', position: '17', usage: M }
  - { idRef: 'ROL', position: '18', usage: O, count: '>1' }
- { idRef: 'GT1', position: '20', usage: O, count: '>1' }
- groupId: 'INSURANCE'
  count: '>1'
  usage: O
  items:
  - { idRef: 'IN1', position: '22', usage: M }
  - { idRef: 'IN2', position: '23', usage: O }
  - { idRef: 'IN3', position: '24', usage: O, count: '>1' }
  - { idRef: 'ROL', position: '25', usage: O, count: '>1' }
- { idRef: 'ACC', position: '27', usage: O }
- { idRef: 'UB1', position: '28', usage: O }
- { idRef: 'UB2', position: '29', usage: O }

これは、セグメントグループ PROCEDURE および INSURANCE を含む ADT_A05 メッセージ構造を構成するセグメントのリストを示しています。上の例は標準定義 (可変バージョンではない) のため、必須のセグメント (用途: M) および省略可能なセグメント (用途: O) が含まれます。HL7 で使用する使用方法コードの完全なセットを次に示します。

  • C: 条件付き (省略可能に相当します)

  • M: 必須

  • O: 省略可能

  • U: 未使用 (読み取り時に警告なしで受け入れられますが、読み取りから渡されるデータには存在しません。書き込み時には無視されます)

セグメントまたはグループの出現可能な数は count の値によって提供されます。デフォルトでは、この値は 1 に設定されます。

メッセージ構造からセグメントを削除する場合や、セグメント要件を必須から省略可能 (またはその逆) に変更する場合は、スキーマのコピーに変更を加えて、その変更バージョンをアプリケーションで容易に使用できます。

元のメッセージ構造定義に含まれないセグメントを追加することもできます。このためには、まず、位置の値をスキーマ内の既存のすべてのセグメント定義行およびグループ定義行から削除することをお勧めします。これを行わない場合、追加したセグメント以降のすべてを採番し直す必要があります。 明示的な位置番号を削除した場合、セグメントとグループに位置番号が順次割り当てられます。また、ほとんどの用途で、HL7 EDI コネクタ 3.1.0 アプリケーションはこの番号を参照しません。

標準 HL7 セグメントをメッセージ構造に追加する場合は、適切な場所で idRef 行を使用してセグメントを参照するだけです。HL7 が、インポートとして参照された basedefs.esl ファイルから定義を取得します。

次の部分的な例は、ADT_A05 メッセージ構造に追加された CON セグメントを示しています。

form: HL7
version: '2.5.1'
imports: [ '/hl7/v2_5_1/basedefs.esl' ]
id: 'ADT_A05'
name: 'ADT_A05'
data:
- { idRef: 'MSH', usage: M }
- { idRef: 'SFT', usage: O, count: '>1' }
- { idRef: 'EVN', usage: M }
- { idRef: 'PID', usage: M }
- { idRef: 'PD1', usage: O }
- { idRef: 'CON', usage: O, count: '>1' }
- { idRef: 'NTE', usage: O }
- { idRef: 'ROL', usage: O, count: '>1' }
- { idRef: 'NK1', usage: O, count: '>1' }
- { idRef: 'PV1', usage: M }
- { idRef: 'PV2', usage: O }
- { idRef: 'CON', usage: O, count: '>1' }
- { idRef: 'ROL', usage: O, count: '>1' }
...

メッセージ構造で標準以外のセグメントを定義する場合、セグメント定義をスキーマに追加します。この場合、セグメント内のすべてのコンポーネントをリストする必要があるため、単にセグメント構造を変更するよりも複雑です。これを最も簡単に開始する方法は、似た標準 HL7 セグメントを見つけて、その標準セグメントで使用されている定義を basedefs.esl ファイルからコピーすることです。次に、メッセージ構造定義の後にセグメントキーを追加し、その後に 1 つ以上のセグメント定義を追加します。

メッセージ構造およびセグメント定義を組み合わせたスキーマの例については、以下のセクションを参照してください。

サンプルメッセージを使用したスキーマの簡素化

HL7 標準定義は非常に複雑です。多くの場合、セグメントには 20 個以上のコンポーネントと多くのコンポーネント複合が含まれ、さらにそれら自体が多くのサブコンポーネントに分割されています。メッセージの DataSense ビューにはこのすべてのサブコンポーネントを含める必要があるため、これにより HL7 のマッピングが困難になる可能性があります。

実際には、HL7 のほとんどのユーザは HL7 標準定義全体のごくわずかな部分のみを入力しています。この方法を利用するには、HL7 EDI コネクタが提供するコンソールベースの Java ツールを使用し、メッセージで通常使用されないコンポーネントを除外して、スキーマ定義を簡素化することができます。

このスキーマ簡素化ツールは hl7-simplify-4.0.0.jar として配布されます。これは、標準の MuleSoft Enterprise Maven リポジトリ (グループ ID の com.mulesoft.connectors の下) にあります。 これは、入力としてメッセージ構造スキーマと 1 つ以上のサンプルメッセージ (別々のファイル) を取得し、1 つ以上のサンプルメッセージに含まれるセグメントとコンポーネントのみに縮小される出力スキーマを生成します。

このツールを使用するには、JAR をダウンロードし、コマンドラインコンソールを開いて次のように入力します。

java -jar hl7-simplify-4.0.0.jar {input-schema} {output-schema} {sample1} {sample2} ...

各パラメータの説明:

  • input-schema は、メッセージを読み取るために使用するメッセージ構造スキーマであり、 これには、提供するスキーマを参照するファイルまたはクラスパスを使用できます (/hl7/v2_5_1/ADT_A05.esl パスなど)。

  • output-schema は、簡素化されたスキーマ出力のファイルパスです。

  • sample1…​n は、サンプルメッセージへのファイルパスです。

注意: キャリッジリターン (CR) の行末を含むサンプルメッセージファイルが保存されていることを確認してください。これは必須の HL7 セグメント区切り文字です。通常、テキストエディタでは、オペレーティングシステムのデフォルトの行末が使用されますが、これが適切でない場合があります。

このツールを使用して生成された簡素化されたスキーマの部分的な例を次に示します。

form: HL7
version: '2.5.1'
structures:
- id: 'SIU_S12'
  name: 'SIU_S12'
  data:
  - { idRef: 'MSH', position: '01', usage: O }
  - { idRef: 'SCH', position: '02', usage: O }
  - groupId: 'PATIENT'
    count: '>1'
    usage: O
    items:
    - { idRef: 'PID', position: '06', usage: O }
    - { idRef: 'PV1', position: '08', usage: O }
  - groupId: 'RESOURCES'
    count: '>1'
    usage: O
    items:
    - { idRef: 'RGS', position: '14', usage: O }
    - groupId: 'SERVICE'
      count: '>1'
      usage: O
      items:
      - { idRef: 'AIS', position: '16', usage: O }
    - groupId: 'GENERAL_RESOURCE'
      count: '>1'
      usage: O
      items:
      - { idRef: 'AIG', position: '20', usage: O }
    - groupId: 'LOCATION_RESOURCE'
      count: '>1'
      usage: O
      items:
      - { idRef: 'AIL', position: '24', usage: O }
    - groupId: 'PERSONNEL_RESOURCE'
      count: '>1'
      usage: O
      items:
      - { idRef: 'AIP', position: '28', usage: O }
segments:
- id: 'AIG'
  name: 'Appointment Information - General Resource'
  varTag: 'AIG'
  values:
  - { idRef: 'SI', name: 'Set ID - AIG', usage: O }
  - { idRef: 'varies', name: 'Segment Action Code', usage: U, count: '>1' }
  - { idRef: 'CE_2', name: 'Resource ID', usage: O }
  - { idRef: 'varies', name: 'Resource Type', usage: U, count: '>1' }
  - { idRef: 'varies', name: 'Resource Group', usage: U, count: '>1' }
  - { idRef: 'varies', name: 'Resource Quantity', usage: U, count: '>1' }
  - { idRef: 'varies', name: 'Resource Quantity Units', usage: U, count: '>1' }
  - { idRef: 'TS', name: 'Start Date/Time', usage: O }
- id: 'AIL'
  name: 'Appointment Information - Location Resource'
  varTag: 'AIL'
  values:
  - { idRef: 'SI', name: 'Set ID - AIL', usage: O }
  - { idRef: 'varies', name: 'Segment Action Code', usage: U, count: '>1' }
  - { idRef: 'PL', name: 'Location Resource ID', usage: O, count: '>1' }
  - { idRef: 'CE', name: 'Location Type-AIL', usage: O }
  - { idRef: 'varies', name: 'Location Group', usage: U, count: '>1' }
  - { idRef: 'TS', name: 'Start Date/Time', usage: O }
- id: 'AIP'
  name: 'Appointment Information - Personnel Resource'
  varTag: 'AIP'
  values:
  - { idRef: 'SI', name: 'Set ID - AIP', usage: O }
  - { idRef: 'varies', name: 'Segment Action Code', usage: U, count: '>1' }
  - { idRef: 'XCN_2', name: 'Personnel Resource ID', usage: O, count: '>1' }
  - { idRef: 'CE_1', name: 'Resource Type', usage: O }
  - { idRef: 'varies', name: 'Resource Group', usage: U, count: '>1' }
  - { idRef: 'TS', name: 'Start Date/Time', usage: O }
...
composites:
- id: 'CE'
  name: 'Coded Element'
  values:
  - { idRef: 'ST', name: 'Identifier', usage: O }
  - { idRef: 'ST', name: 'Text', usage: O }
- id: 'CE_1'
  name: 'Coded Element'
  values:
  - { idRef: 'ST', name: 'Identifier', usage: O }
- id: 'CE_2'
  name: 'Coded Element'
  values:
  - { idRef: 'ST', name: 'Identifier', usage: O }
  - { idRef: 'ST', name: 'Text', usage: O }
  - { idRef: 'ID', name: 'Name of Coding System', usage: O }
...

セグメントの未使用のコンポーネントをセグメント定義から単に削除することはできません (ただし、そのコンポーネントがセグメントの末尾にある場合を除く)。そのため、簡素化ツールでは、そのコンポーネントを varies データ型で置換し、Usage: U (未使用) としてマークします。この場合、varies は元のコンポーネントと同じ回数反復されますが、DataWeave に表示されるデータの DataSense ビューには表示されません。

スキーマ簡素化ツールは、メッセージに含まれるデータを確認するときに、コンテキスト内の複合の各出現箇所を処理します。同じ複合でも使用方法が異なると、サンプルに異なる値が含まれる可能性があります。この場合、複合は異なる識別子で複数回定義されます。 上の例の CE 複合がこれを示しています。

簡素化されたスキーマでは、元のスキーマのセグメント位置が保持されます。 セグメントキー (コネクタ設定オプションの 1 つ) で位置プレフィックスを使用しない限り、この位置の値は HL7 EDI コネクタでは使用されないため、簡素化されたスキーマから必要に応じてこの位置の値を削除できます。

HL7 スキーマの場所の特定

コネクタを使用するには、プロジェクト内のスキーマの場所を認識しておく必要があります。標準の HL7 スキーマを使用し、何もカスタマイズしていない場合、標準スキーマの場所は /hl7/{version}/{message structure}.esl のパターンに従い、可変スキーマの場所は /hl7lax/{version}/{message structure}.esl のパターンに従います。 たとえば、2.5.1 バージョンと ADT_A01 メッセージ構造を使用している場合、スキーマの場所は標準バージョンでは /hl7/v2_5_1/ADT_A01.esl (必須値、データ型、長さ/反復数を含む)、可変バージョンでは /hl7lax/v2_5_1/ADT_A01.esl です。

1 つ以上のカスタムスキーマを使用している場合、それらを src/main/mule 内のディレクトリの下に配置し、${app.home} を使用して場所を参照する必要があります。 たとえば、ADT_A01 スキーマを「src/main/mule/mypartner/ADT_A01.esl」の下に配置した場合、スキーマの場所は ${app.home}/mypartner/ADT_A01.esl になります。

Mule Runtime は自動的に src/main/mule を参照し、${app.home} 値を含む場所があるかどうかを確認します。

イベントおよびメッセージからメッセージ構造へのマップについて

(提供されているスキーマのように別々のスキーマ定義内か、1 つのファイル内かに関係なく) 複数のメッセージ構造スキーマを使用してコネクタを設定する場合、HL7 のイベントおよびメッセージ種別からメッセージ構造へのマッピングの定義が必要になる場合があります。

HL7 は、MSG 種別の複合構造である MSH-09 のコンポーネント値でメッセージ種別を定義します。HL7 EDI コネクタは、このコンポーネント値を使用して、以下のルールに従って、受信メッセージの処理に使用する構造スキーマを見つけます。

  • MSG-01 メッセージコードの値が「ACK」の場合、定義済みの ACK スキーマを常に使用します。

  • それ以外の場合、MSG-03 メッセージ構造の値 (ADT_A01 などの値) が存在するときは、その ID のスキーマ構造を使用します。

  • それ以外の場合、イベントおよびメッセージからメッセージ構造への設定済みのマップを使用して、指定されたトリガイベント (MSG-02) およびメッセージコード (MSG-01) の値からメッセージ構造を特定します。

イベントおよびメッセージからメッセージ構造へのマップは、省略可能な設定パラメータです。 これは、サポートされる各メッセージコードから実際のメッセージ構造へのマップに対する各イベント種別からのマップで構成される YAML ファイルである必要があります。

例を次に示します。

A01: { XYZ: ADT_A01, ACK: ACK }
A02: { XYZ: ADT_A02, ACK: ACK }
A03: { XYZ: ADT_A03, ACK: ACK }
A04: { XYZ: ADT_A01, ACK: ACK }
A05: { XYZ: ADT_A05, ACK: ACK }
A06: { XYZ: ADT_A06, ACK: ACK }
A07: { XYZ: ADT_A06, ACK: ACK }
A08: { XYZ: ADT_A01, ACK: ACK }

HL7 のバージョンごとに、イベント種別およびメッセージコードからメッセージ構造への異なるマッピングセットを定義します。デフォルトのマッピングは、標準 HL7 スキーマ定義と同じ JAR 内の event-message.yaml という名前のファイルで提供されます。 このマッピング定義では、実際のメッセージ構造スキーマと同じ種別のパスを使用します。

Anypoint Studio 7 で Mule プロジェクトを作成する方法

コネクタをインストールし、(必要に応じて) スキーマをカスタマイズしたら、コネクタの使用を開始できます。実装規定ごとに個別の設定を作成します。

  1. キャンバスの下部にある [Global Elements (グローバル要素)] タブをクリックし、[Create (作成)] をクリックします。

  2. [Choose Global Type (グローバル種別の選択)] ウィザードで、検索条件を使用して [HL7 EDI: Configuration (HL7 EDI: 設定)] を探して選択し、[OK] をクリックします。

  3. [OK] をクリックして、グローバルコネクタ設定を保存します。

  4. Studio の [Message Flow (メッセージフロー)] タブに戻ります。

一般オプションについて

一般オプションでは、HL7 メッセージの読み取りと書き込みに適用する設定を定義できます。

  • HL7 文字エンコード。メッセージの書き込みで常に使用されます。また、異なる文字コードが MSH-18 (文字セット) により指定されていない限り、メッセージを読み取るときに使用されます。

  • Disable numeric prefixes for data keys (データキーの数値プレフィックスを無効化) - このオプションはデフォルトで true になっています。true では、セグメントデータの数値プレフィックスが無効になります。このオプションを無効にする唯一の理由は、HL7 EDI コネクタ 3.0.0 用に定義されたマッピングとの互換性を維持することです。

  • スキーマのリストを手動で作成または編集します。

ビジュアルエディタでの HL7 ID の設定

独自のメッセージヘッダー (MSH) アプリケーションと施設 ID、および取引パートナーを HL7 EDI コネクタ設定で指定できます。

HL7 メッセージを書き込むときに、設定した値を使用して名前空間 ID、ユニバーサル ID、およびユニバーサル ID 種別を提供します。設定した値は受信メッセージ内で検証されます。受信メッセージを制限しない場合、これを空白のままにして、書き込み操作時に送信メッセージの値を設定するか、実際の送信メッセージの値を設定します。書き込み操作時に設定された値は、コネクタ設定を上書きし、メッセージに直接設定された値は、コネクタ設定と書き込み操作時に設定されたすべての値を上書きします。

Studio ではこの値は [Global Element Properties (グローバル要素のプロパティ)] で設定されます。

  • セルフ ID パラメータは、取引パートナーリレーションの自分側を識別します。

    セルフ ID の設定:

    Mule Application Namespace ID (MSH-03/HD-01 when sending, MSH-05/HD-01 when receiving)
    Mule Application Universal ID (MSH-03/HD-02 when sending, MSH-05/HD-02 when receiving)
    Mule Application Universal ID Type (MSH-03/HD-03 when sending, MSH-05/HD-03 when receiving)
  • パートナー ID パラメータは、取引パートナーを識別します。

    パートナー ID の設定:

    Partner Application Namespace ID (MSH-03/HD-01 when receiving, MSH-05/HD-01 when sending)
    Partner Application Universal ID (MSH-03/HD-02 when receiving, MSH-05/HD-02 when sending)
    Partner Application Universal ID Type (MSH-03/HD-03 when receiving, MSH-05/HD-03 when sending)

パーサーオプションの設定方法

必要に応じて、以下のオプションを設定できます。

  • HL7 メッセージバージョンを検証する。

  • イベントおよびメッセージからメッセージ構造へのマッピングパス (受信したメッセージに MSH-09 および MSG-03 メッセージ構造値が常に含まれていない限り、複数のメッセージ構造を使用する場合、必須)。

  • 必須の処理 ID (本番の P など、受信メッセージで必要とされる特定の処理 ID を指定)。

  • 汎用の拡張セグメント名のパターン (項目値のマップとして拡張セグメントを処理できる)。

  • 必須値がない場合に失敗する。

  • 値の長さが許容範囲を超える場合に失敗する。

  • 無効な文字が値に含まれる場合に失敗する。

  • 値の反復が多すぎる場合に失敗する。

  • 不明なセグメントがメッセージに含まれる場合に失敗する。

  • メッセージ内のセグメントの順序が不適切な場合に失敗する。

  • 未使用のセグメントがメッセージに含まれる場合に失敗する。

  • セグメントの反復が多すぎる場合に失敗する。

例: HL7 Studio

以下の XML から次のフローを読み込むことができます。

Studio でのサンプルフロー
<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:hl7="http://www.mulesoft.org/schema/mule/hl7"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns="http://www.mulesoft.org/schema/mule/core"
  xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
  http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http
http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/hl7
http://www.mulesoft.org/schema/mule/hl7/current/mule-hl7.xsd
http://www.mulesoft.org/schema/mule/ee/core
http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
	<http:listener-config name="HTTP_Listener_config"
  doc:name="HTTP Listener config" >
		<http:listener-connection host="localhost" port="8081" />
	</http:listener-config>
	<hl7:config name="HL7_Extension_Config" doc:name="HL7 Extension Config" identKeys="true">
		<hl7:schemas >
			<hl7:schema value="/hl7/v2_5_1/ADT_A05.esl" />
			<hl7:schema value="/hl7/v2_5_1/ADT_A01.esl" />
		</hl7:schemas>
	</hl7:config>
	<flow name="hl7testFlow" >
		<http:listener doc:name="Listener" config-ref="HTTP_Listener_config" path="/hl7"/>
		<hl7:read doc:name="Read" config-ref="HL7_Extension_Config"/>
		<ee:transform doc:name="Transform Message" >
			<ee:message >
				<ee:set-payload ><![CDATA[%dw 2.0
output application/java
---
{
	Delimiters: payload.Delimiters,
	Id: payload.Id
}]]></ee:set-payload>
			</ee:message>
		</ee:transform>
		<hl7:write doc:name="Write" config-ref="HL7_Extension_Config"/>
	</flow>
</mule>

XML での HL7 ID の設定

独自のメッセージヘッダー (MSH) アプリケーションと施設 ID、および取引パートナーを HL7 EDI コネクタ設定で指定できます。

HL7 メッセージを書き込むときに、設定した値を使用して名前空間 ID、ユニバーサル ID、およびユニバーサル ID 種別を提供します。設定した値は受信メッセージ内で検証されます。受信メッセージを制限しない場合、これを空白のままにして、書き込み操作時に送信メッセージの値を設定するか、実際の送信メッセージの値を設定します。書き込み操作時に設定された値は、コネクタ設定を上書きし、メッセージに直接設定された値は、コネクタ設定と書き込み操作時に設定されたすべての値を上書きします。

  • セルフ ID パラメータは、取引パートナーリレーションの自分側を識別します。

    セルフ ID パラメータ:

    appNamespaceIdSelf="<value>"
    appUniversalIdSelf="<value>"
    appUniversalIdTypeSelf="<value>"
  • パートナー ID パラメータは、取引パートナーを識別します。

    パートナー ID パラメータ:

    appNamespaceIdPartner="<value>"
    appUniversalIdPartner="<value>"
    appUniversalIdTypePartner="<value>"

パーサーオプションの設定方法

必要に応じて、以下のオプションを設定できます。

XML 値 Visual Studio オプション

eventMessageMap="/hl7/v2_5_1/event-message.yaml"

イベントおよびメッセージからメッセージ構造へのマッピングパス (受信したメッセージに MSH-09 および MSG-03 メッセージ構造値が常に含まれていない限り、複数のメッセージ構造を使用する場合、必須)。

genericExtensionPattern="Z.."

汎用の拡張セグメント名の Java 正規パターン (項目値のマップとして拡張セグメントを処理できる)。

invalidCharacterInValueFail="true"

無効な文字が値に含まれる場合に失敗する。

missingRequiredValueFail="true"

必須値がない場合に失敗する。

processingId="PRODUCTION"

必須の処理 ID (本番の「P」など、受信メッセージで必要とされる特定の処理 ID を指定)。

segmentOutOfOrderFail="true"

メッセージ内のセグメントの順序が不適切な場合に失敗する。

unknownSegmentFail="true"

不明なセグメントがメッセージに含まれる場合に失敗する。

unusedSegmentPresentFail="true"

未使用のセグメントがメッセージに含まれる場合に失敗する。

validateHL7Version="true"

HL7 メッセージバージョンを検証する。

valueLengthErrorFail="true"

値の長さが許容範囲を超える場合に失敗する。

wrongSegmentsRepeatsFail="true"

セグメントの反復が多すぎる場合に失敗する。

wrongValuesRepeatsFail="true"

値の反復が多すぎる場合に失敗する。

スキーマの場所を設定する方法

Anypoint Studio XML ビューでスキーマの場所を設定できます。

Anypoint Studio で [Configuration XML (設定 XML)] をクリックして XML ビューに切り替えて、各ドキュメント種別の <http://edischema[edi:schema]> 要素を追加することで、含めたいすべてのスキーマのリストが含まれるように HL7 EDI 設定を変更します。

<hl7-edi:config name="HL7_EDI__Configuration" identKeys="true" doc:name="HL7 EDI: Configuration">
  <hl7-edi:schemas>
    <hl7-edi:schema>hl7/v2_6/ADT_A01.esl</hl7-edi:schema>
  </hl7-edi:schemas>
</hl7-edi:config>

HL7 EDI のグローバル要素を作成したら、メッセージ構造、操作、肯定応答を設定します。

HL7 メッセージ構造について

HL7 コネクタでは、正規の ER7 メッセージ構造との間で HL7 ドキュメントの読み書きを行います。この構造は、DataWeave またはコードを使用して操作できる Java マップおよびリストの階層として表されます。各トランザクションには、スキーマで定義された独自の構造があります。

HL7 メッセージには、次のキーが含まれます。

キー名 説明

ACK (参照のみ)

入力データに応答して生成された ACK メッセージ。MSA-01 肯定応答コード値は、パーサー設定に基づきます。肯定応答を送信するには、肯定応答の送信に関する以下のセクションを参照してください。

Data (参照/更新)

実際のデータにリンクするメッセージ構造 ID 値に一致するキーを持つメッセージデータのラッパー。これにより、異なるメッセージをメタデータに含めて DataWeave マッピングで処理できます。

Delimiters (参照/更新)

メッセージで使用する区切り文字。文字列内の文字は位置に基づいて次の順序で解釈されます。(コンポーネントの区切り文字)、(反復の区切り文字)、(エスケープ文字)、(サブコンポーネントの区切り文字)。

Errors (参照のみ)

入力メッセージに関連付けられたエラーのリスト。HL7 メッセージの読み取りと検証に関する以下のセクションの HL7Error 構造の説明を参照してください。

Id

メッセージ構造 ID。

MSH (参照のみ)

受信した MSH セグメントデータへのリンク。

Name (参照のみ)

メッセージ構造名。

個々のメッセージには、メッセージのセグメントに一致するキーを持つ独自のマップがあります。たとえば、ACK メッセージでメッセージ構造 ID の ACK を使用すると、送信または受信された ACK メッセージのデータは、データマップに ACK 値として含まれます。ACK メッセージ自体はマップです。メッセージのセグメントとグループは、位置キーを持つマップ (単一インスタンスの場合) またはマップのリスト (反復するインスタンスの場合) として表されます。

スキーマ定義に含まれないデータに対して汎用処理を使用する 2 つの特別なケースがあります。1 つ目は、varies 型の HL7 値の場合です。この値はコンポーネントとサブコンポーネントの任意の構造で構成され、反復される場合があるため、パーサーは varies 型ごとにマップリスト表現を使用します。値が解析されるときに各マップのキーが生成され、標準の HL7 値の名前が、各ネストレベルで使用される 2 桁の数字と一致します。 したがって、たとえば、OBX-05 の [Observation Value (観測値)] 項目の簡単なテキスト値はマップ内でキー OBX-05 のみを使用します。2 つのコンポーネントが含まれる場合、それらはキー OBX-05-01 および OBX-05-02 を使用します。

パーサーオプションで設定されたパターンに一致するタグを持つ拡張セグメントは、「varies」値に似た構造を使用しますが、セグメント全体の 1 つのマップ内に限られます。拡張セグメントの解析および書き込みコードでは反復値はサポートされません。

拡張セグメントデータを含むマップは、キー ExtensionSegs を持つリスト内の基本メッセージマップに追加されます。実際の拡張セグメントデータに加えて、拡張セグメントのマップには 2 つの他のキーが含まれます。

Key (キー) 説明

Ident

拡張セグメント ID (タグ)。

Position

メッセージ構造内のセグメントの位置 (2 桁文字列)。これは、スキーマで定義されている、直前に定義されたセグメントの位置と同じです。ADT_A01 メッセージ構造内で EVN セグメントの後に ZVN 拡張セグメントが使用されている場合、ZVN の位置は 03 になります。

ネストされたグループ内で拡張セグメントが使用されている場合、そのセグメントを含むリストは、そのグループを表すマップに含まれます。拡張セグメントは、パーサーが作成したリスト内の位置で並び替えられます。また、書き込み時にも位置で並び替えられる必要があります。

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub