Ensemble へのインタフェース変換

以下のダイアグラムは、一般的な病院経営に必要な情報テクノロジの一部を示しています。このダイアグラムは、病院の IT 担当者が直面する複雑な課題を示しています。このダイアグラムでは、さまざまなエンドユーザ・アプリケーションが、ラボ情報システムや病院情報システム (HIS) と HL7 メッセージを交換しています。インタフェース・エンジンは、これらのシステム間で HL7 メッセージをルーティングします。病院のすべてのアプリケーションが表示されているわけではありません。重要なのは、インタフェース・エンジンに出入りする HL7 メッセージです。

この章では、各医療アプリケーションに対し、受信側と送信側の両方のインタフェースを定義することが必要になります。図では、各メッセージ・タイプのソースに円、各宛先に矢印を示して、これを説明しています。受信側および送信側インタフェースのさまざまな組み合わせが示されています。この章内では、インタフェースとは医療アプリケーションに関連する受信または送信をいいます。受信インタフェースは、インタフェース・エンジンを介して HIS またはラボ・システムからのメッセージを受信します。送信インタフェースは、インタフェース・エンジンを介して HIS またはラボ・システムにメッセージを送信します。病院の IT 構成内のその他のインタフェースは、ダイアグラムに表示されていても、この章では扱いません。

ダイアグラムにおいて、実線の矢印はリアルタイムの情報交換を表し、点線の矢印はバッチ転送を表します。矢印の色でデータのさまざまなカテゴリを表示しています。緑は承認、黄色は薬剤、金色は患者、オレンジはスケジュール、ピンクはマスタ・ファイル通知、紫はトランザクション、水色は要求、青は研究室、灰色は医師、黒はベンダを示します。

generated description: hospital interfaces

Ensemble をこのような構成にする場合、多くは、既存のインタフェース・エンジンを Ensemble と置き換えることが目的です。このためには、以下のようにする必要があります。

前の章で説明したように、Ensemble プロダクションをルーティング・エンジンとして使用します。
以前のインタフェース・エンジンではなく Ensemble ルーティング・エンジンを使用するよう、既存の各インタフェースを変換します。
すべてのインタフェースが変換されたら、以前のインタフェース・エンジンを構成から削除します。

この章の変換アプローチでは、既存のインタフェース・エンジンをそのままにし、Ensemble を使用するようにインタフェースを 1 つずつ変換します。新しいインタフェースが Ensemble を使用して適切に機能することをテストし、確認する間、変換されていないインタフェースは、そのまま以前のエンジンを使用します。変換されたインタフェースが正しく機能したらすぐに、変換されていない次のインタフェースに取り掛かります。このような逐次変更を基にしたポリシーにより、変換の際、可能な限り中断されず、エラーのないサービスが保証されます。

関連するインタフェースのグループを同時に変換するアプローチを取ることもできます。つまり、血液バンク・アプリケーションとの間でメッセージを交換するすべてのインタフェースを変換した後に、胎児監視アプリケーションのインタフェース変換に進むことが可能です。それでもやはり、この作業は一度に 1 インタフェースの変換になります。

この章では、1 つの既存の HL7 インタフェースを Ensemble を使用するように変換する方法を説明します。一般的な手順は以下のとおりです。この章の各節では、これらの手順を 1 つずつ詳細に説明します。

この章の手順は、通常 Ensemble プロダクションを説明する順序 (“HL7 ビジネス・サービスが受信メッセージを受け取る...”) と逆の順序になります。しかし、インタフェース変換の経験より、要素をトップダウンで開発し、ビジネス・サービスより始めてカスタム・スキーマへと作業を進めると、多くの場合、前の手順に戻り、上位項目を構成したさまざまな形式で下位項目の名前を入力または修正する必要があることは明らかです。

この章の手順では、ボトムアップのアプローチを取り、上位項目を構成するときに下位項目の名前がわかるように、下位項目を最初に作成することで後戻りを最小限に抑えます。ボトムアップの順序はこの章で示すように、手順 1 および 2、手順 3、4、5、6、7、8、手順 9 および 10 となります。

単純なエラーを削減する確立された命名規則がある場合は特に、トップダウンの順序でこの手順が成功する場合があります。トップダウンの順序は、手順 1 および 2、手順 8、7、6、5、4、3、手順 9 および 10 となります。

プロダクションのバックアップ

以下の手順は、HL7 を使用する Ensemble プロダクションの汎用的なバックアップ手順の概要を説明しています。正確な手順は、Ensemble クラス、カスタム・クラス、ルーティング・ルール、およびカスタムの HL7 カテゴリ定義のパッケージ方法および命名規則により異なります。

Note:

XML バックアップ・ファイルについて： UNIX® システムを使用する場合、バックアップ XML ファイルをバイナリ・モードで FTP 転送しないでください。通常の FTP では、このファイルを DOS から UNIX® に正しく変換しますが、バイナリ FTP では正しく変換しない場合があります。

スタジオからのバックアップ

スタジオからフルバックアップを行うには、以下のように実行します。

スタジオを起動して、バックアップするネームスペースに変更します。
スタジオからクラスの該当パッケージをエクスポートします。これにより、すべてのビジネス・サービス、ビジネス・プロセス、ビジネス・オペレーション、データ変換、およびユーティリティ・クラスがエクスポートされます。パッケージをバックアップするには、以下のように実行します。
- [ワークスペース] ウィンドウでパッケージ名を選択します。
- 右クリックし、コンテキスト・メニューから [エクスポート] を選択します。
- [XML 形式でエクスポート] チェックボックスにチェックを付け、適切なファイル名を選択して、[OK] をクリックします。
スタジオからのエクスポートには、必要に応じて、パッケージを選択するのではなく、以下のようにして個々のクラスを選択することができます。
- [ツール] および [エクスポート] の順に選択し、[追加] をクリックします。
- [ファイルのタイプ] で All Files を選択し、[ファイル名] で *.cls を入力して、[開く] をクリックします。
- リストから該当のクラスを選択し、[開く] をクリックすると、クラスが [エクスポート] リストに追加されます。
- [XML 形式でエクスポート] チェックボックスにチェックを付け、適切なファイル名を選択して、[OK] をクリックします。
該当のビジネス・ルール ([ファイル名] は *.rul) をエクスポートします。
該当のカスタム・スキーマ ([ファイル名] は *.hl7) をエクスポートします。
この結果として生成される XML ファイルを Ensemble 対応のネームスペースにインポートすることができます。

ObjectScript からのバックアップ

スタジオで上記の手順を何度も繰り返さなければならないのが煩わしいこともあります。都合のいいときに、これらの手順を ObjectScript メソッドにコード化してください。正確なコードは、Ensemble クラス、カスタム・クラス (データ変換を含む)、ビジネス・ルール、およびカスタムのカテゴリ定義のパッケージ方法および命名規則により異なります。概念的には、ObjectScript でのこの手順は、エクスポートされるすべての項目の単一のマスタ・リストを作成し、このリストのすべてを適切な日付の付いた単一の XML ファイルにエクスポートします。詳細は、以下のとおりです。

ObjectScript $ORDER または $O 関数と共に $system.OBJ.GetPackageList メソッドを使用して、対象となる各パッケージのすべてのクラス (*.cls) のリストを作成します。各パッケージのコードは、以下の Mutro というカスタム・パッケージの例のようになります。
```
  do $system.OBJ.GetPackageList(.tList,"Mutro","ars")
  set class="" for  {
    set class=$o(tList(class)) quit:class=""
    set tFullList(class_".cls")=""
  }
```
$ORDER や $EXTRACT などの ObjectScript 関数の詳細は、"Caché ObjectScript リファレンス" の “ObjectScript 関数” の章を参照してください。
^EnsHL7.Schema グローバルおよび ObjectScript 関数 $ORDER および $EXTRACT を使用して、Ensemble 対応のネームスペース内のすべてのカスタム・スキーマ (*.hl7) のリストを作成します。以下の例では、すべての名前は接頭語 Mutro_ で始まるというカスタム・スキーマの命名規則を使用しているため、リストは簡単に作成されます。
```
  set cat="" for  {
  set cat=$o(^EnsHL7.Schema(cat)) quit:cat=""
  if $e(cat,1,6)="Mutro_" set tFullList(cat_".hl7")=""
  }
```

出力ディレクトリを設定して、タイム・スタンプを含めた XML ファイル名を作成し、ファイルをエクスポートします。これは以下のようになります。

 ; Normalize the directory name and figure the file name
 if pDir'="" set pDir=$tr(pDir,"\","/")
 if $e(pDir,$l(pDir))'="/" set pDir=pDir_"/"
 for count=1:1  {
   set filename=pDir_"backup_"_$zdate($h,8)_"_"_count_".xml"
   quit:##class(%File).Exists(filename)=0
   }
 ;
 ; Export all the items on the list
 Set tSC=$system.OBJ.Export(.tFullList,pDir_"backup_"_$zdate($h,8)_".xml")
 Do:('tSC) $system.Status.DisplayError(tSC)
 ;
 Set tSC=$system.OBJ.Export(.tFullList,filename)
 Do:('tSC) $system.Status.DisplayError(tSC)
 ;
 write !,"Backup to file "_filename_" done.",!

上の例では、パラメータ pDir がメソッドに渡されることを予定していますが、pDir は、バックアップ・メソッドにより簡単に特定のディレクトリに設定することができます。この例では、ObjectScript 関数の $TRANSLATE、$EXTRACT、$ZDATE、および $HOROLOG と、%File.Exists() メソッドおよび $system.OBJ.Export() メソッドが使用されています。

インタフェースの説明

企業で使用されている各医療アプリケーションは、独自の HL7 アプリケーション仕様ドキュメントを持っています。仕様ドキュメントでは、アプリケーションが送信 (または受信) できる HL7 イベントのタイプ、およびこれらのイベントに対してアプリケーションが送信 (または受信) するメッセージ・セグメントおよび各セグメント部分について説明しています。例えば、MSH セグメントの場合、HL7 アプリケーションの仕様ドキュメントには、セグメントがどのようなものであるか、何がハードコーディングされるか、文字列にはどの形式が使用されるかなどについて、正確に示されています。情報は非常に詳細です。各医療アプリケーションのこのようなドキュメントは、そのアプリケーション管理者に問い合わせて確認してください。

ソースおよびターゲット・アプリケーションにはそれぞれ HL7 アプリケーションの仕様ドキュメントがあります。ただし、変換するインタフェースなど、これらのアプリケーション間の単一のインタフェースは、仕様ドキュメントにリストされている機能の小さなサブセットを使用します。インタフェースを説明する最も有効なソースは、事実上、置換対象のインタフェース定義です。

既存のインタフェース定義 (eGate のコラボレーション・ルールなど) を開きます。この定義を表示し、テキスト・ファイルを開いて、ここにインタフェースの動作について簡単な説明を入力します。既存の定義 (LOOP、CASE など) のコーディング規則の詳細を複製しないでください。以下のように簡単に表します。

ソースからの受信が予定されるメッセージ・セグメント。
ターゲットに送信する前の、インタフェースによるこれらの変更方法。

Ensemble に変換するインタフェースの説明に備え、置き換えるテクノロジと Ensemble との用語を比較すると役に立つ場合があります。例として、以下のテーブルに SeeBeyond と Ensemble の用語の類似性をリストします。

SeeBeyond	Ensemble
コラボレーション・ルール	インタフェース定義
COPY または DUPLICATE	DTL データ変換の <assign> 文
DISPLAY	DTL データ変換の <trace> 文
LOOP	DTL の <foreach> または省略表記 ()
IF	DTL データ変換の <if> 文
CASE	ルーティング・ルール
FUNCTION	ビジネス・サービスまたはビジネス・オペレーションのコード、および <code>
CHANGE-PATTERN	$CHAR や $PIECE などの関数を使用するテキスト置換

受信インタフェース

さまざまな HL7 メッセージの送信元のソース・アプリケーションがあるとします。しかし、関係するのは付随の指示のみ、しかも、特定タイプの患者の特定タイプの指示のみで、メッセージはシステムのテストではなく、実際的メッセージの場合です。このソースからの対象メッセージを説明する場合、以下のように入力します。

Send only:
  Message Type "ORM_O01 "
  PV1:18 Patient Type = "ER" or "ECM" or "ERQ"
  ORC:1 Order Control = "NW" or "CA" or "OC"
  PID:5 Last Name not "TEST"

送信インタフェース

これらのメッセージ・セグメントが、送信前にインタフェースによってどのように変更されるのかは、ターゲット・アプリケーションが何を受信する必要があるかにより異なります。インタフェースの知識と上記の情報のソースに基づいて、以下のように入力できます。

Copy source MSH to target.
Set target MSH:11 Processing ID = "P".
Copy source MSH:10 Control ID to target MSH:13 Sequence Number.

Copy source PID to target.
Set target PID:1 Set ID = "1".
Copy source PID:2 Patient External ID
  to the 2nd repetition of target PID:3 Patient Internal ID and
  set its Identifier Type = "PI".
Null out target PID:2.

Copy source ORC to target.
If source ORC:1 Order Control = "CA" or "OC",
  then set target ORC:5 Order Status to "CA".
If source ORC:2.1 Placer Order Number is empty, then
  copy source ORC:3.1 Filler Order Number
  to target ORC:2.1 Placer Order Number and
  set target ORC:2.2 Placer Application = "ULTRA".
Set target ORC:3.2 Filler Application = "ULTRA".

Copy source OBR to target.
If source OBR:2.1 Placer Order Number is empty, then
  copy source OBR:3.1 Filler Order Number
  to target OBR:2.1 Placer Order Number and
  set target OBR:2.2 Placer Application = "ULTRA".
Set target OBR:3.2 Filler Application = "ULTRA".
Set target OBR:4.3 Coding Scheme (SIM Department) = "LAB".

スキーマ・カテゴリの選択

この手順では、インタフェースの受信側と送信側で使用する HL7 スキーマを決定する必要があります。まずおおよその選択を行い、管理ポータルでそのスキーマに対するメッセージをテストすることによりこれを調整します。

各医療アプリケーションには、メッセージの送信時に使用したり、メッセージの受信時に予定される HL7 スキーマのバージョンを指定する、HL7 アプリケーションの仕様ドキュメントがあります。アプリケーションにより送信されたメッセージ・データに対してこのバージョンを確認することができます。送信メッセージの MSH セグメントには、(理論的に) アプリケーションが使用している HL7 バージョンを通知する HL7 バージョン番号が記述されます。

どの情報のソースも厳密に言って正確ではない場合もあります。医療アプリケーションはそれぞれ別の時間帯に HL7 バージョンを更新できるため、あるアプリケーションでは新しい HL7 バージョンを使用し、別のアプリケーションでは同じバージョンを使用しないということになります。アプリケーションは、MSH セグメントのコンテンツの変更や変更のドキュメント化を行わずに、HL7 バージョンをアップグレードしたり、Z セグメントを追加または変更することができます。

受信スキーマ・カテゴリの選択

インタフェースの受信側 (HL7 ビジネス・サービスを介して Ensemble にメッセージが入る) のスキーマ・カテゴリを以下のように選択します。

ソース・アプリケーションからのいくつかのサンプル・メッセージをテキスト・ファイルに捕捉します。これらのメッセージがアーカイブされたファイル・コピーがあれば、これを使用できます。
管理ポータルで、[HL7スキーマ構造] ページを使用して、目的のメッセージ・セグメントの構造に適合すると思われる HL7 標準スキーマを探します。
[メッセージ・ビューワ] ページを使用して、選択したスキーマに照らしてテキスト・ファイル・メッセージをテストします。メッセージ構造に最も適合する標準スキーマが見つかるまで、さまざまなスキーマを試します。

Tip:

送信側と受信側のそれぞれのインタフェースで期待される特定の HL7 区切り文字については気にしないでください。HL7 ビジネス・オペレーションがこれらを適切に処理します。
ソース・アプリケーションからのメッセージには、スキーマにはない追加セグメントが含まれる場合があります。このとき、[メッセージビューワ] オプションを使用してメッセージを解析すると、次のように、メッセージが受け入れられる場合と、不正メッセージ・エラーが生成される場合があります。
- メッセージに追加 Z セグメントが含まれ、スキーマがこれらの Z セグメントを定義する場合、メッセージは受け入れられます。
- メッセージに追加 Z セグメントが含まれているにもかかわらず、スキーマが Z セグメントを定義していない場合、メッセージは受け入れられます。
- メッセージに追加 Z セグメントが含まれ、スキーマが Z セグメントを定義しているものの、メッセージ内の Z セグメントがスキーマにある Z セグメントと一致しない場合、これは不正メッセージとなります。
- メッセージに追加の非 Z セグメントが含まれる場合、Z セグメントに関係なく、これは不正メッセージとなります。
背景は、"Ensemble 仮想ドキュメント" の “メッセージ検証の制御” を参照してください。HL7 の詳細は、"Ensemble HL7 バージョン 2 開発ガイド" の [検証] 設定のリファレンスを参照してください。
メッセージで不正メッセージ・エラー状態の 1 つがトリガされた場合は、別の標準スキーマの選択を試みます。
そのスキーマが機能していない場合は、非標準メッセージ構造に対応したカスタム HL7 カテゴリ定義を作成します。"Ensemble 仮想ドキュメント" の “カスタム・スキーマ・カテゴリの作成” を参照してください。

送信スキーマ・カテゴリの選択

同様の手順を繰り返し、送信インタフェースのスキーマを選択します。

ルーティング・ルール・セットの定義

ルーティング・ルール・セットを作成します。詳細は、"Ensemble HL7 バージョン 2 開発ガイド" の “HL7 のルーティング・ルール・セットの定義” を参照してください。

データ変換の作成

DTL データ変換を作成します。詳細は、"Ensemble HL7 バージョン 2 開発ガイド" の “HL7 の DTL データ変換の定義” を参照してください。

ビジネス・オペレーションの追加

HL7 インタフェースのビジネス・オペレーションは、ターゲット・アプリケーションへの送信メッセージ転送を制御します。HL7 ビジネス・オペレーションの追加方法は、"Ensemble HL7 バージョン 2 開発ガイド" の “プロダクションの構成” を参照してください。

テスト用に、同じ構成名を持つ以下の 2 つの HL7 ビジネス・オペレーションのあるプロダクションを構成すると便利です。

1 つは、プロダクションが正常に動作しているときにインタフェース上での HL7 メッセージの FTP または TCP 転送を制御する FTP または TCP のビジネス・オペレーションです。
もう 1 つは、インタフェースのテストまたはトラブルシューティングの際に HL7 メッセージをファイルに送信する File ビジネス・オペレーションです。

Ensemble の規則 (項目は同じ構成名を持つ) で、これらの構成項目のうち、一度に有効にできるのは 1 つのみです。“テスト” 環境 (File オペレーション) にするのか、“ライブ” 環境 (TCP または FTP オペレーション) にするのかに応じて、どちらか一方を有効にします。

“ライブ” ビジネス・オペレーションおよび “テスト” ビジネス・オペレーションを作成する手順は以下のとおりです。

ターゲット・アプリケーションを調査し、HL7 メッセージに含まれることが想定される区切り文字を確認します。
“ライブ” (FTP または TCP) HL7 ビジネス・オペレーションを作成します。
同様の手順を使用して、“テスト” (File) HL7 ビジネス・オペレーションを作成します。
“テスト” (File) オペレーションに “ライブ” オペレーションと同じ構成の名前を付与します。
[有効にする] フィールドを使用して、“ライブ” (FTP または TCP) または “テスト” (File) バージョンのビジネス・オペレーションを有効化および無効化します。一度にアクティブにできる同じ名前のビジネス・サービスは 1 つのみです。

詳細は、"Ensemble プロダクションの構成" の “複数バージョンのビジネス・ホストの操作” を参照してください。

ルーティング・プロセスの作成または編集

Ensemble ルーティング・エンジンを使用するため新しいインタフェースを有効にするには、以下のプロダクションにルーティング・プロセスを追加する必要があります。

ソースからのデータの解釈方法を指示する (ルーティング・ルールを指定する) プロダクション。
解釈されたデータの送信先を指示する (ビジネス・オペレーションを指定する) プロダクション。

新しい HL7 ルーティング・プロセスを作成できます。詳細は、"Ensemble HL7 バージョン 2 開発ガイド" の “プロダクションの構成” を参照してください。

ビジネス・サービスの追加

HL7 インタフェースのビジネス・サービスは、ソース・アプリケーションからの受信メッセージを受け取ります。HL7 ビジネス・サービスの追加方法は、"Ensemble HL7 バージョン 2 開発ガイド" の “プロダクションの構成” を参照してください。

テスト用に、同じ構成名を持つ以下の 2 つの HL7 ビジネス・サービスのあるプロダクションを構成すると便利です。

1 つは、プロダクションが正常に動作しているときに FTP または TCP を介してソース・アプリケーションからの HL7 メッセージを受け取る FTP または TCP のビジネス・サービスです。
もう 1 つは、インタフェースのテストまたはトラブルシューティングの際にファイルからの HL7 メッセージを受け取る File ビジネス・サービスです。

Ensemble の規則 (項目は同じ構成名を持つ) で、これらの構成項目のうち、一度に有効にできるのは 1 つのみです。“テスト” 環境 (File サービス) にするのか、“ライブ” 環境 (TCP または FTP サービス) にするのかに応じて、どちらか一方を有効にします。

“ライブ” ビジネス・サービスおよび “テスト” ビジネス・サービスを作成する手順は以下のとおりです。

“ライブ” (FTP または TCP) HL7 ビジネス・サービスを作成します。
同様の手順を使用して、“テスト” (File) HL7 ビジネス・サービスを作成します。
“テスト” (File) サービスに “ライブ” サービスと同じ構成の名前を付与します。
[有効にする] フィールドを使用して、“ライブ” (FTP または TCP) または “テスト” (File) バージョンのビジネス・サービスを有効化および無効化します。一度にアクティブにできる同じ名前のビジネス・サービスは 1 つのみです。

詳細は、"Ensemble プロダクションの構成" の “複数バージョンのビジネス・ホストの操作” を参照してください。

インタフェースのテスト

一般には、医療施設で “稼動” しているプロダクションの完全コピーである、別の “テスト” プロダクションを管理する必要があります。新しい Ensemble インタフェースは “テスト” プロダクション内で開発します。これが完了すると、新しいインタフェースのコピーを “ライブ” プロダクションに移行することができます。

新しいインタフェースをテストするには、以下の手順を実行します。

ソース・アプリケーションからのいくつかのサンプル・メッセージをファイルに捕捉します。
“テスト” プロダクションで、File ビジネス・サービスと File ビジネス・オペレーションを有効にし、ファイルとしてメッセージを送信します。
結果として作成された出力ファイルの HL7 メッセージ・データを調べ、ターゲット・アプリケーションの要件を満たしているかどうかを確認します。
必要であれば、インタフェース要素を調整し、再テストします。
“テスト” プロダクション内で、ビジネス・サービスとビジネス・オペレーションの “テスト” (File) バージョンで無効を選択し、“ライブ” (FTP または TCP) バージョンを再度有効にします。

インタフェースの導入

テスト・プロダクションで Ensemble インタフェースのテストを完了したら、新しい Ensemble インタフェース要素を稼動中のプロダクションに追加します。これを行うには、以下を実行します。

この手順の最初のステップで説明したとおり、ライブ・プロダクション全体をバックアップします。
前の手順で作成したテスト・プロダクションの新しい要素をエクスポートします。
- インタフェースの新しいクラス (ビジネス・プロセス、データ変換、ビジネス・オペレーション、ビジネス・サービス、およびすべてのユーティリティ・クラス) をエクスポートします。
- ビジネス・ルール *.rul をエクスポートします。
- カスタム・スキーマ *.hl7 をエクスポートします。

新しいインタフェースによりプロダクション・クラスの XDATA セクションに追加された新しい XML <Item> 要素をコピーします。以下に例を示します。

構成項目	<Item> 要素の開始サンプル
ビジネス・サービス (テスト)	<Item name="App1toApp2_In"
ビジネス・サービス (ライブ)	<Item name="App1toApp2_In"
ビジネス・プロセス (新規の場合)	<Item name="App1toApp2"
ビジネス・オペレーション (テスト)	<Item name="App1toApp2_Out"
ビジネス・オペレーション (ライブ)	<Item name="App1toApp2_Out"

新しいインタフェース要素を、以下のようにしてライブ・プロダクションに転送します。
- ライブ・プロダクションを停止またはシャットダウンします。
- 新しいクラス、ルール、およびスキーマをインポートし、コンパイルします。
- クラスとしてビジネス・プロセスをインポートするのではなく、“ライブ” システム上のビジネス・プロセスで ACTIONS 文字列を編集することを選択している場合は、ここで行います。編集したクラスをコンパイルします。
- 新しい <Item> 要素をプロダクション・クラスの XDATA セクションに貼り付けます。プロダクション・クラスをコンパイルします。
- ライブ・プロダクションを再開または再起動します。
オプションで、新しいプロダクション要素のアラートを構成します。
- HL7 ビジネス・サービスおよびビジネス・オペレーションには、[エラー時に警告] という構成設定があります。[エラー時に警告] を真に設定している場合、その項目でエラー状態が発生するとすぐ、アラートが自動的にトリガされます。アラートがトリガされた時点で、Ensemble イベント・ログにメッセージが書き込まれます。また、電子メールや携帯電話でアラートをユーザに通知することもできます。 [エラー時に警告] 設定を偽に設定している場合、オプションは無効になります。
- [警告猶予期間] (ビジネス・サービスの場合) と [警告再試行猶予期間] (ビジネス・オペレーションの場合) は、有効になっているアラートの頻度を適切に制限します。
Note:

この手順では、インタフェースを “ライブ” プロダクションに 1 つずつ追加する方法を説明します。アラートは、一度設定されていれば、この手順で説明するように容易に構成できます。“テスト” または “ライブ”・プロダクション用のアラートをセットアップするには、"Ensemble HL7 バージョン 2 開発ガイド" の “携帯電話および電子メールのアラート” を参照してください。
新しいインタフェースが新しいメッセージをすべて処理していることを確認します。
以前のインタフェース・テクノロジを無効化またはクリーンアップします。
- 以前保留されていたすべての要求が満たされ、すべてのキューが空となっていることを確認します。
- 古いインタフェースを無効にします。eGate 要素については、“start automatically” オプションを無効にします。