Skip to main content

This is documentation for Caché & Ensemble. See the InterSystems IRIS version of this content.Opens in a new tab

For information on migrating to InterSystems IRISOpens in a new tab, see Why Migrate to InterSystems IRIS?

HL7 ルーティング・プロセスの設定

HL7 ルーティング・プロセスの設定に関する参照情報を提供します。

概要

HL7 ルーティング・プロセスには次のような設定があります。

グループ 設定 参照先
基本設定 [ビジネス・ルール名] "Ensemble 仮想ドキュメント" の “ルーティング・プロセスに関する設定
[検証] このトピックの節
追加設定 [変換エラー時に作動][検証エラー時に作動][不正メッセージ警告][不正なメッセージ・ハンドラ][レスポンス From][応答タイムアウト][強制同期送信] "Ensemble 仮想ドキュメント" の “ルーティング・プロセスに関する設定
[ローカル・ファシリティ・アプリケーション][ACKタイプ][NACKコード][NACK ERR追加][応答ターゲット構成名] このトピックの節
開発とデバッグ ルールのロギング "Ensemble 仮想ドキュメント" の “ルーティング・プロセスに関する設定

残りの設定はすべてのビジネス・プロセスに共通のものです。"Ensemble プロダクションの構成" の “すべてのビジネス・プロセスに含まれる設定” を参照してください。

[ACK タイプ]

ACK または NACK 応答メッセージをローカルに作成する場合、ACK タイプ (つまり AA または CA) を決定します。A がデフォルトのコードです。詳細は、“HL7 確認応答 (ACK) モード” を参照してください。

[NACK ERR追加]

真の場合は、NACK メッセージを生成する際に、Ensemble のエラー・コードとエラー・テキストを含む ERR セグメントを付加します。偽の場合は、NACK メッセージに内部エラーの状態情報を埋め込みません。

[ローカル・ファシリティ・アプリケーション]

このルーティング・プロセスを介して HL7 メッセージを受け取る機能とアプリケーションを表す、コロンで区切られた LocalFacility:LocalApplication コード。ルーティング・プロセスが独自の ACK または NACK メッセージを作成する場合、[ローカル・ファシリティ・アプリケーション] はそのメッセージの SendingFacility:SendingApplication コードを指定します。構築しない場合、この設定は無視されます。

[NACKコード]

エラーをレポートするよう NACK 応答メッセージをローカルに作成する場合、NACK コード・タイプ (つまり AE または AR) を決定します。E がデフォルトのコードです。詳細は、“HL7 確認応答 (ACK) モード” を参照してください。

[応答ターゲット構成名]

プロダクション内の構成項目のカンマ区切りリスト。指定されている場合、このリストは呼び出し側のほかに応答を転送する宛先を示します。空の場合は、応答は呼び出し側のみに返されます。この設定は、[応答] フィールドに値がある場合のみ有効です。

[検証]

HL7 メッセージ・ルータの [検証] 設定は、ルータによる受信メッセージの検証方法を制御します。受信メッセージが指定された検証に失敗した場合、イベント・ログにその失敗がレポートされ、HL7 ルーティング・プロセスはそのメッセージを不正メッセージ・ハンドラのみに渡します ([不正なメッセージ・ハンドラ] 設定を参照してください)。メッセージが指定された検証に失敗したが、不正メッセージ・ハンドラがない場合、エラーがログに記録されますが、そのメッセージはどのターゲットにも送信されません。メッセージが検証に合格した場合、HL7 ルーティング・プロセスはルーティング・ルールで指定されたターゲットにそのメッセージを送信します。

理想的には、ルーティング・ルールとデータ変換を使用して、メッセージごとにターゲット・システムで受理可能かどうか確認することができ、その結果として検証の使用を避けることができます。 これにより、すべてのメッセージが適切なターゲットで処理されます。検証を有効にした場合、ルーティング・ルールの前に検証テストが適用されます。検証に失敗したメッセージは、ルーティング・ルールに従ってターゲットに送信されず、不正なメッセージ・ハンドラのみに送信されます。ただし、HL7 メッセージ検証がメッセージのフィルタに適した方法である環境も存在します。例えば、以下の状況では、HL7 検証を使用することが正しい選択です。

  • インタフェースを開発またはデバッグしており、システムで処理が必要なメッセージに類似する形式を判定する必要がある場合。

  • ターゲット・アプリケーションで、仕様と相違があるメッセージを処理できず、ルーティング・ルールおよび変換でその相違を解決できない場合。

  • 規制やその他のビジネスの要件があり、メッセージがその仕様に従っている場合。

HL7 検証はルーティング・プロセスにオーバーヘッドを付加します。このオーバーヘッドが大きな影響を持つ場合があり、プロダクションで処理可能なメッセージの最大負荷を減らす可能性があります。

Validation プロパティでは、以下を制御するフラグを指定できます。

  • メッセージが有効なドキュメント・タイプを持つかどうか

  • メッセージ構造が検証されるかどうか

  • スキーマに指定されていない末尾の Z セグメントが検証されるかどうか

  • どのフィールドに検証を適用する必要があるか

  • 最初のエラーをレポートした後に検証を停止するか、または引き続きメッセージの残りのセグメントおよびフィールドの検証を行うか

Validation プロパティ値に空の文字列を指定した場合、メッセージ・ルータは検証を省略し、すべてのメッセージをルーティングします。管理ポータルで新しい HL7 ルーティング・プロセスを作成すると、[検証] 設定が空の文字列に初期化されます。

以前のリリースとの下位互換性を維持するため、[検証]1 に設定することは dm-z に設定することと同様に扱われ、[検証]0 に設定することは空の文字列に設定することと同様に扱われます。

メッセージ検証シーケンスは以下のとおりです。

  1. メッセージ・オブジェクトに DocType プロパティ値があることを検証します。

  2. セグメントの順序を検証します。

  3. セグメント内のフィールドを検証します。

このシーケンスのいずれかの時点でメッセージが検証に失敗し、-x フラグが指定されていない場合、HL7 ルーティング・プロセスはメッセージの残りのセグメントを検証しません。

Note:

指定された [検証] フラグによっては、検証に合格したメッセージでも、厳密にはスキーマ定義に適合しない場合があります。

DocType プロパティの検証

ビジネス・サービスは、HL7 メッセージの MSH:9 フィールドに指定されたサービスとドキュメント名に対して定義された [メッセージ・スキーマ・カテゴリ] に基づいて、DocType プロパティ値を設定します。Validation プロパティ値に d が含まれている場合、メッセージ・ルータは DocType プロパティに値があるかどうかをテストします。値がない場合、そのメッセージは不正メッセージになります。

以下のいずれかの状況では、ビジネス・サービスは DocType プロパティに値を割り当てません。

  • ビジネス・サービスに対して [メッセージ・スキーマ・カテゴリ] が指定されていない。

  • HL7 メッセージのドキュメント名が、指定されたスキーマ (カスタム・スキーマの場合は指定されたスキーマまたはベース・スキーマ) で定義されていない。

セグメントの順序の検証

この節では、ルーティング・エンジンによるセグメントの検証方法について説明します。

Validation プロパティの値が dmdmz、または dm-z である場合、ルーティング・プロセスの検証では、以下のテストによって、メッセージを検証するか、またはメッセージが不正であると宣言します。

  1. メッセージのセグメントが、ビジネス・サービスがメッセージに割り当てた DocType 値によって指定されるメッセージ構造に準拠している場合、m 検証に適合します。例えば、メッセージの DocType 値が 2.3.1 で、メッセージ内の MSH:9 の値が ORU^R01 の場合、メッセージは 2.3.1 カテゴリの ORU_R01 メッセージ構造に対して検証されます。2.3.1 ORU_R01 と比較した際、メッセージ・データに必要なセグメントがない場合、または未定義の追加セグメントがある場合、それは不正メッセージとなります。HL7 では、末尾の Z セグメントとして、標準メッセージに独自のローカルなバリエーションを追加できます。メッセージの末尾の Z セグメントは、以下のルールに従って検証されます。

    1. スキーマで、末尾の Z セグメントが指定されているか、“Zxx” ワイルドカード・セグメントが指定されている場合、末尾の Z セグメントは検証に合格します。

    2. -z フラグが指定されている場合、メッセージの末尾の Z セグメントは検証に合格します。

    3. -z フラグが指定されておらず、スキーマに末尾の Z セグメントが定義されていない場合、末尾の Z セグメントは検証に失敗します。

    4. スキーマで末尾の Z セグメントが要求され、メッセージに含まれていない場合、そのメッセージは検証に失敗します。

  2. DocType がカスタム・スキーマを参照する場合、メッセージがカスタム定義に対して照合されることを除き、テスト 1 と同じルールが適用されます。各カスタム・スキーマには、ベース・カテゴリ (例えば base="2.3.1") が定義されます。カスタム・スキーマで明示的に定義されていないメッセージが到着すると、ベース・カテゴリが使用されます。

MSH:9 フィールドに非標準値が含まれる可能性がある場合は、カスタム・スキーマを定義して、この非標準値を持つメッセージが検証に失敗することを回避する必要があります。例えば、MSH:9 が ORU^R01 ではなく ORU^Z22 と同じである場合、構造 ORU_R01 に対してメッセージ名 ORU^Z22 を照合する必要があることを指定するには、カスタム・スキーマが必要となります。

カスタム・スキーマ・カテゴリの作成に関する情報は、"Ensemble 仮想ドキュメント" の “カスタム・スキーマ・カテゴリの作成” を参照してください。

フィールドの検証

f フラグは、すべてのフィールド検証を有効にします。f を指定すると、メッセージ・ルータは以下のフィールド検証を実行します。

  • メッセージのフィールドとコンポーネントの順序がスキーマに適合しているかテストします。

  • 必須のフィールド、コンポーネント、およびサブコンポーネントが存在することをテストします。

  • メッセージのフィールド・サイズがスキーマに適合しているかテストします。

  • フィールドのデータ値がスキーマで定義されたデータ型に適合するかテストします。

  • フィールドのデータ値がコード・テーブルに適合するかテストします。ただし、コード・テーブルに ... の値が含まれているか、コード・テーブルが空の場合は任意の値が許可されます。

検証フラグの指定

それぞれのフラグの前には、- (ハイフン記号) を付けてフラグの意味を無効化することができます。例えば、x フラグは、最初のエラーが検出された後にルーティング・プロセスが検証を停止する必要があることを指定し、-x フラグは、メッセージ全体を検証してすべてのエラーが検出されるまでルーティング・プロセスが検証を続行する必要があることを指定します。いくつかの検証フラグは、一連のフラグを指定するのと同等となります。例えば、s フラグは、jpw フラグを指定するのと同等です。無効化フラグを指定することで、連続するフラグの 1 つを解除できます。例えば、s-pjw と等価です。フラグを無効化するには、フラグ文字の直前にハイフンを入力する必要があります。例えば、z フラグと x フラグの両方を無効化する場合、-z-x を指定する必要があります。

以下の表は、HL7 検証フラグを示しており、それぞれが指定されたときに、ルーティング・プロセスがメッセージをどのように検証するかを説明しています。

フラグ ルーティング・プロセス
a フィールド配列の繰り返しの制限値を強制します。
b コード・テーブルの ... を解釈して、任意のフィールド値が検証に合格することを可能にします。
c すべてのコンポーネントおよびサブコンポーネントの検証を実行します。gijopw と等価です。
d DocType プロパティを定義するように要求します。他のフラグはすべて、指定された検証を実行するために DocType を定義する必要があります。
e すべての検証を実行します。abdgijlmnoprtuwy と等価です。
f セグメント内ですべてのフィールドの検証を実行します。abgijlnoprtuwy と等価です。
g セグメント内でデータ構造を強制します。
i コンポーネント・サイズの制限を強制します。
j 必須のサブコンポーネントが存在することを確認します。これらは、スキーマ内のオプション設定によって適用されます。
l フィールド・サイズの制限を強制します。
m スキーマ定義内のすべての必須セグメントがメッセージ内に含まれており、そのメッセージにスキーマで許可されていない間違ったセグメントが含まれていないことを確認します。
n セグメントに正しい数のフィールドが含まれていることを確認します。
o 必須のコンポーネントが存在することを確認します。これらは、スキーマ内のオプション設定によって適用されます。
p コンポーネント・レベルのデータ構造を強制します。
r 必須のフィールドが存在することを確認します。
s すべてのサブコンポーネント・レベルの検証を実行します。jpw と等価です。
t コード・テーブルを強制します。このフラグは b フラグおよび u フラグで変更できます。
u 許容可能な値がリストされていないコード・テーブルを無視します。これらの空のコード・テーブルに対して任意の値を許可します。
w サブコンポーネント・サイズの制限を強制します。
x 最初のエラーが検出されたら検証を停止します。これがデフォルトです。-x は、メッセージ全体を検証し、該当するステータスのすべてのエラーを返すことを指定します。
y 数値など、フィールドのデータ型を強制します。
z Z セグメントをスキーマ内で明示的に指定するか、またはスキーマ内でワイルドカード Zxx によって指定することを要求します。-z は、末尾の Z セグメントを、スキーマに指定されていない場合でも許可します。
(空の文字列) 検証を省略し、すべてのメッセージをルーティングします。
FeedbackOpens in a new tab