検証
HL7 メッセージ・ルータの [検証] 設定は、ルータによる受信メッセージの検証方法を制御します。受信メッセージが指定された検証に失敗した場合、イベント・ログにその失敗がレポートされ、HL7 ルーティング・プロセスはそのメッセージを不正メッセージ・ハンドラのみに渡します ([不正なメッセージ・ハンドラ] 設定を参照してください)。メッセージが指定検証に失敗したが、不正メッセージ・ハンドラがない場合、エラーがログに記録されますが、メッセージはどのターゲットにも送信されません。メッセージが検証に合格した場合、HL7 ルーティング・プロセスはルーティング・ルールで指定されたターゲットにそのメッセージを送信します。
ルーティング・ルールとデータ変換を使用して、メッセージごとにターゲット・システムで受理可能かどうかを確認することができ、その結果として検証の使用を避けることができる、というのが理想的です。 これにより、すべてのメッセージが適切なターゲットで処理されます。検証を有効にした場合、ルーティング・ルールの前に検証テストが適用されます。検証に失敗したメッセージは、ルーティング・ルールに従ってターゲットに送信されず、不正なメッセージ・ハンドラのみに送信されます。ただし、HL7 メッセージ検証がメッセージのフィルタリング方法として適している環境も存在します。例えば、以下の状況では、HL7 検証を使用することが正しい選択です。
-
インタフェースを開発またはデバッグしており、システムで処理が必要なメッセージに類似する形式を判定する必要がある場合。
-
ターゲット・アプリケーションで、仕様と相違があるメッセージを処理できず、ルーティング・ルールおよび変換でその相違を解決できない場合。
-
規制やその他のビジネスの要件があり、メッセージがその仕様に従っている場合。
HL7 検証はルーティング・プロセスにオーバーヘッドを付加します。このオーバーヘッドが大きな影響を与えるために、プロダクションで処理可能なメッセージの最大量が減少する可能性があります。
Validation プロパティでは、以下を制御するフラグを指定できます。
-
メッセージが有効なドキュメント・タイプを持つかどうか
-
メッセージ構造が検証されるかどうか
-
スキーマに指定されていない末尾の Z セグメントが検証されるかどうか
-
どのフィールドに検証を適用する必要があるか
-
最初のエラーをレポートした後に検証を停止するか、または引き続きメッセージの残りのセグメントおよびフィールドの検証を行うか
Validation プロパティ値に空の文字列を指定した場合、メッセージ・ルータは検証を省略し、すべてのメッセージをルーティングします。管理ポータルで新しい HL7 ルーティング・プロセスを作成すると、[検証] 設定が空の文字列に初期化されます。
以前のリリースとの下位互換性を維持するため、[検証] を 1 に設定することは dm-z に設定することと同様に扱われ、[検証] を 0 に設定することは空の文字列に設定することと同様に扱われます。
メッセージ検証シーケンスは以下のとおりです。
-
メッセージ・オブジェクトに DocType プロパティ値があることを検証します。
-
セグメントの順序を検証します。
-
セグメント内のフィールドを検証します。
このシーケンスのいずれかの時点でメッセージが検証に失敗し、-x フラグが指定されていない場合、HL7 ルーティング・プロセスはメッセージの残りのセグメントを検証しません。
Note:
指定された [検証] フラグによっては、検証に合格したメッセージでも、厳密にはスキーマ定義に適合しない場合があります。
DocType プロパティの検証
ビジネス・サービスは、HL7 メッセージの MSH:9 フィールドで指定されたサービスとドキュメント名に対して定義された [メッセージ・スキーマ・カテゴリ] に基づいて、DocType プロパティ値を設定します。Validation プロパティ値に d が含まれている場合、メッセージ・ルータは DocType プロパティに値があるかどうかをテストします。値がない場合、そのメッセージは不正メッセージになります。
以下のいずれかの状況では、ビジネス・サービスは DocType プロパティに値を割り当てません。
セグメントの順序の検証
この節では、ルーティング・エンジンによるセグメントの検証方法について説明します。
Validation プロパティの値が dm、dmz、または dm-z である場合、ルーティング・プロセスの検証では、以下のテストによって、メッセージを検証するか、またはメッセージが不正であると宣言します。
-
ビジネス・サービスがメッセージに割り当てた DocType 値で指定されるメッセージ構造にメッセージのセグメントが準拠している場合、m 検証に適合します。例えば、メッセージの DocType 値が 2.3.1 で、メッセージ内の MSH:9 の値が ORU^R01 の場合、メッセージは 2.3.1 カテゴリの ORU_R01 メッセージ構造に対して検証されます。2.3.1 ORU_R01 と比較した際、メッセージ・データに必要なセグメントがない場合、または未定義の追加セグメントがある場合、それは不正メッセージとなります。HL7 では、末尾の Z セグメントとして、標準メッセージに独自のローカルなバリエーションを追加できます。メッセージの末尾の Z セグメントは、以下のルールに従って検証されます。
-
スキーマで、末尾の Z セグメントが指定されているか、“Zxx” ワイルドカード・セグメントが指定されている場合、末尾の Z セグメントは検証に合格します。
-
-z フラグが指定されている場合、メッセージの末尾の Z セグメントは検証に合格します。
-
-z フラグが指定されておらず、スキーマに末尾の Z セグメントが定義されていない場合、末尾の Z セグメントは検証に失敗します。
-
スキーマで末尾の Z セグメントが要求され、メッセージに含まれていない場合、そのメッセージは検証に失敗します。
-
DocType がカスタム・スキーマを参照する場合、メッセージがカスタム定義に対して照合されることを除き、テスト 1 と同じルールが適用されます。各カスタム・スキーマには、ベース・カテゴリ (例えば base="2.3.1") が定義されます。カスタム・スキーマで明示的に定義されていないメッセージが到着すると、ベース・カテゴリが使用されます。
MSH:9 フィールドに非標準値が含まれる可能性がある場合は、カスタム・スキーマを定義して、この非標準値を持つメッセージが検証に失敗することを回避する必要があります。例えば、MSH:9 が ORU^R01 ではなく ORU^Z22 と同じである場合、構造 ORU_R01 に対してメッセージ名 ORU^Z22 を照合する必要があることを指定するには、カスタム・スキーマが必要となります。
カスタム・スキーマ・カテゴリの作成に関する情報は、"プロダクション内での仮想ドキュメントの使用法" の “カスタム・スキーマ・カテゴリの作成” を参照してください。
フィールドの検証
f フラグは、すべてのフィールド検証を有効にします。f を指定すると、メッセージ・ルータは以下のフィールド検証を実行します。
-
メッセージのフィールドとコンポーネントの順序がスキーマに適合しているかどうかをテストします。
-
必須のフィールド、コンポーネント、およびサブコンポーネントが存在することをテストします。
-
メッセージのフィールド・サイズがスキーマに適合しているかどうかをテストします。
-
フィールドのデータ値がスキーマで定義されたデータ型に適合するかどうかをテストします。
-
フィールドのデータ値がコード・テーブルに適合するかどうかをテストします。ただし、コード・テーブルに ... の値が含まれているか、コード・テーブルが空の場合は任意の値が許可されます。
検証フラグの指定
それぞれのフラグの前には、- (ハイフン記号) を付けてフラグの意味を無効化することができます。例えば、x フラグは、最初のエラーが検出された後にルーティング・プロセスが検証を停止する必要があることを指定し、-x フラグは、メッセージ全体を検証してすべてのエラーが検出されるまでルーティング・プロセスが検証を続行する必要があることを指定します。いくつかの検証フラグは、一連のフラグを指定するのと同等となります。例えば、s フラグは、jpw フラグを指定するのと同等です。無効化フラグを指定することで、連続するフラグの 1 つを解除できます。例えば、s-p は jw と等価です。フラグを無効化するには、フラグ文字の直前にハイフンを入力する必要があります。例えば、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 セグメントを、スキーマに指定されていない場合でも許可します。 |
(空の文字列) |
検証を省略し、すべてのメッセージをルーティングします。 |