ルーティング・プロダクションの設計モデル

構成項目

Ensemble プロダクションは構成項目より構成されます。構成項目には以下の 3 タイプがあります。

• ビジネス・サービスは、受信メッセージを受け付けます。

• ビジネス・オペレーションは、送信メッセージを送信します。

• ビジネス・プロセスは、その中間のすべての処理を指示します。ビジネス・プロセスにはいくつかの特殊なタイプがあります。

  ルーティング・プロセスは、ルーティング・プロダクションの以下の主要なコンポーネントを呼び出すことにより、メッセージのルーティングおよび変換を行います。

  • ルーティング・ルールは、メッセージのコンテンツに基づいてメッセージを宛先に送ります。

  • スキーマ・カテゴリは、メッセージのコンテンツの検証およびアクセスの手段を提供します。

  • データ変換は、変更を適用し、宛先に向けてメッセージを準備します。

  シーケンス・マネージャは、関連するメッセージが適切なシーケンスとタイミングでターゲットに到達するようにします。

以下の図は、ルーティング・プロセスのダイアグラムを拡大したもので、このプロセスがルーティング・ルールを使用してインタフェースでの情報のフローを指示する方法を示しています。以下の図には、上のダイアグラムの点線の円で示された部分のみのルーティング・ルールおよびデータ変換の詳細が示されています。

ルーティング・プロセスには、ルーティング・ルール・セットが関連付けられています。ルール・セットの定義方法、およびソース・アプリケーションから着信するメッセージのタイプにより、ルール・セットは実行するルールを特定します。複数のルールを順に実行することもできますが、説明を簡易化するため、以下の図にはルール・セットが 1 つのルールのみを選択する場合を示します。図のように、ルールはここからメッセージを削除することも、Ensemble 内の宛先に送信することもできます。この宛先がビジネス・オペレーションの場合、メッセージは Ensemble からターゲット・アプリケーションに送信されます。

アプリケーションの仕様

観念的に言えば、医療アプリケーションは、アプリケーションが送信 (または受信) できる HL7 イベントのタイプ、およびこれらのイベントについてアプリケーションが送信 (または要求) するメッセージ・セグメントおよび各セグメントの部分を説明する、HL7 アプリケーション仕様ドキュメントまたは実装ガイドを提供します。

この種の公式ドキュメントは、非常に詳しく、非常に有用です。仕様ドキュメントが利用可能な場合、医療アプリケーションの管理者は、これをユーザに示したり、可能性のある多くのイベントのうち、どれが実際に企業内で使用されているのかを説明することができます。これは通常、イベントの全リストの小さなサブセットとなります。

アプリケーション仕様ドキュメントがなくても、通常は非公式ドキュメントがあります。アプリケーション管理者に、使用可能なドキュメントを参照させてもらうよう依頼してください。

ドキュメントの代替として、または既存のドキュメントが正しいことを検証するため、メッセージ自体を調査して、アプリケーションが送信または受信要求する HL7 イベントのタイプを決定することができます。アプリケーション管理者に、ファイルに保存されたメッセージ・データのサンプリングの提供を依頼してください。

HL7 メッセージ・ファイルを入手したら、ドキュメント・ビューアを使用してさまざまなスキーマ定義によりこれらを表示および解析することができます。このようにして、アプリケーションが標準の HL7 スキーマを使用しているかどうかを迅速に判断できます。使用していない場合は、メッセージ・ビューアを使用してアプリケーションのカスタム HL7 スキーマを調整およびテストすることができます。

これらのタスクをサポートする背景情報については、このドキュメントの後続の章および以下のドキュメントを参照してください。

• "Ensemble 仮想ドキュメント" の “カスタム・スキーマ・カテゴリの作成”

• "Ensemble 仮想ドキュメント" の “メッセージ検証の制御”

• "Ensemble HL7 バージョン 2 開発ガイド" の “利用可能なツール”

• “Ensemble へのインタフェース変換” の章の “スキーマ・カテゴリの選択”

プロダクション・スプレッドシート

情報システムを編成するスプレッドシートをアプリケーションごとに管理するのは有用なことです。スプレッドシートは紙面上で作成することも、任意のソフトウェア・ツールを使用して作成することもできます。

一般的なガイドラインとして、送受信データを提供する各アプリケーションの行を作成します。それぞれの行では、以下の列が有用です。

• [フィード] — インタフェース・エンジンまたはサーバでは、いくつかのアプリケーションからのメッセージをルーティング・プロダクションに送ることがよくあります。このような場合、エンジンまたはサーバの名前をここに記します。

• [アプリケーション] — 特定のアプリケーション、システム内でのロール、およびこのアプリケーションの問題についての連絡先を簡単に指定します。Ensemble を使用していないがシステムの動作については大まかに理解している組織のメンバが理解できる説明であることが理想的です。

• [名前] — このアプリケーションに対する 3 ～ 6 文字の一意の名前。

• [タイプ] — アプリケーションが外部の通信に使用するプロトコル。

• [接続] — IP アドレスやポート番号など、接続の詳細。

• [送信] — このアプリケーションが情報システムに提供する HL7 バージョン 2 メッセージ構造。

  情報システムに入った後の受信メッセージの構造を考慮してください。宛先のシステムまたはその他の要因によって異なるルーティングまたは変換を行う必要があるでしょうか。その必要がある場合、必要な数だけこれをリストし、相違点に関する注釈を付けます。このようにして、スプレッドシートは、それぞれの場合で必要なルーティング・ルール、データ変換、およびカスタム・スキーマを作成する際のチェックリストとして機能します。

• [受信] — このアプリケーションが情報システムから利用する HL7 バージョン 2 メッセージ構造。

• [ACK] — 確認応答の詳細。ACK および NACK メッセージを必要としますか。これらのメッセージを送信および受信するための個別のインタフェースがありますか。Ensemble で ACK および NACK を生成する必要がありますか。もしくは受信アプリケーションで生成しますか。

プロジェクトの開始時、最初のスプレッドシートに情報システム内のすべてのアプリケーションについて記述する必要はありません。新規インタフェースを導入するごとにスプレッドシートに追加することができます。

インタフェース設計

このトピックでは、インタフェース設計をモジュール式にして、開発の各段階において Ensemble プロダクションを容易に理解、拡張、および管理するための効果的な方法を説明します。

• Ensemble に HL7 メッセージを送信するアプリケーションごとに 1 つのビジネス・サービスを提供する。これは、プロダクション・スプレッドシートの [送信] 列に 1 つ以上のエントリがあるアプリケーションです。

  1 つのビジネス・サービスは、同じアプリケーションのすべてのメッセージ構造を受信できます。通常、これが適切な設計です。この目的でビジネス・サービスを設定する場合、一般的にはビジネス・サービスをそのアプリケーション・システムに常時接続します。

  同じアプリケーションに対してさらにビジネス・サービスの接続が必要となる構成がある場合もあります。例えば、ソース・アプリケーションが既に異なる 2 つの TCP/IP ポートにメッセージを送信するよう設定されている場合、1 つのポートからのすべてのメッセージを受信するよう 1 つのビジネス・サービスを設定し、別のポート用にもう 1 つのビジネス・サービスを設定します。1 通信ソースあたり 1 ビジネス・サービスであるため、これは一般的にアプリケーションごとに 1 ビジネス・サービスというモデルと一貫しています。

  一方、同じ医療アプリケーションを使用する何百人ものユーザがデータを企業に送信している場合、これらすべてのメッセージを 1 つのビジネス・サービスにより (アプリケーションの単一のインスタンスに常時接続されているかどうかによらず) Ensemble にルーティングすると便利なこともあります。

• ビジネス・サービスごとに 1 つのルーティング・プロセスを提供する。ルーティング・プロセスでは、メッセージ自体のコンテンツまたは Ensemble に保存された情報に基づいて、メッセージをルーティングすることができます。ルーティングが別のメッセージのコンテンツに依存する場合、またはルーティングの決定に外部アプリケーションの呼び出しを必要とする場合は、ルーティング・プロセスは別のクラスを呼び出す BPL ビジネス・プロセスである必要があります。ただし、ほとんどの場合は、組み込みのルーティング・ルール・エンジンに基づくルーティング・プロセスで十分です。

  関連するメッセージが適切なシーケンスでターゲットに到達することが不可欠である場合は、シーケンス・マネージャの使用を検討します。詳細は、"Ensemble HL7 バージョン 2 開発ガイド" の “プロダクションの構成” を参照してください。

• Ensemble から HL7 メッセージを受信するアプリケーションごとに 1 つのビジネス・オペレーションを提供する。これは、プロダクション・スプレッドシートの [受信] 列に 1 つ以上のエントリがあるアプリケーションです。

  1 つのビジネス・オペレーションは、同一アプリケーションに対してすべて異なるメッセージ構造を送信できます。通常、これが適切な設計です。この目的でビジネス・オペレーションを設定する場合、一般的にはビジネス・オペレーションをそのアプリケーション・システムに常時接続します。ただし、ビジネス・サービスの場合、このモデルにバリエーションがある場合があります。

基本概念は、一貫したモジュール式設計です。つまり、一度に 1 つのインタフェースを開発し、インタフェースごとに 1 つのルーティング・プロセスを使用します。これは、単一の大規模なルーティング・プロセスがすべてのインタフェースのルーティング・エンジンとして機能するモデルとは対照的です。ルーティング・プロセスが 1 つより多い方が優れている理由はいくつかあります。

• 1 つのインタフェースで必要なケースのみに対応すればよいため、それぞれのルーティング・ルール・セットの管理が単純かつ容易である。自己完結した、簡単な一連の問題を解決する作業を共有および再利用する方が容易です。

• インタフェースの個別の開発、置換、および管理が容易になる。企業が特定のアプリケーションを削除またはアップグレードする必要がある場合、かかわりが必要になるのは、このアプリケーションを処理するルーティング・プロセスのみです。インタフェースがダウンした場合、そのインタフェースを無効化、診断、修正、および再テストするだけで、これを再起動することができます。

  これは、大規模なルーティング・プロセスで 1 つのインタフェースを追加、削除、または修正する必要が生じるたびにすべてのルールを再テストし、検証する必要性に比べ、非常に簡潔です。このような考慮事項は、一部のインタフェースを動作させる一方で、その他はまだ開発中である場合に特に重要となります。既に稼動中のルーティング・プロセスに追加するたびに、何百もの既存のルールを再テストし、検証する必要が生じる可能性があるのです。下の図は、複数のインタフェースを持つルーティング・プロダクションを示しています。

プロダクションの各構成項目には、果たすべき特定のロールがあります。各項目にそのロールを遂行させます。

• ビジネス・サービスおよびビジネス・オペレーションは簡単にする。一般に、ビジネス・サービスまたはビジネス・オペレーションに対して独自のコードを記述する必要はありません。Ensemble が提供する組み込みクラスを選択してください。この選択により、自動的に正しいアダプタが指定されます。管理ポータルの設定を使用してこれらのクラスを構成します。

• 複雑なアクティビティはすべてルーティング・プロセスの制御下に配置する。インタフェースが単純な場合、そのルーティング・プロセスを複雑にする必要はありません。しかし、複雑なアクティビティが存在する場合、それはビジネス・サービスやビジネス・オペレーションではなく、ルーティング・プロセスに所属させます。タスクを実行するため、ルーティング・プロセスは別のルーティング・プロセスに連鎖するか、ビジネス・ルール、ルーティング・ルール、データ変換、ビジネス・プロセス、またはカスタム・コードを呼び出すことができます。

命名規則

このトピックでは、命名規則の重要性について説明し、その例を示します。

一般に、Ensemble プロダクションは、一度に 1 インタフェースずつ、付加的に開発します。項目は “その都度” 命名し、命名規則をプロジェクトの進行に伴って増やしていくという考えもありますが、命名規則にはこのような付加的アプローチを取らないことをお勧めします。

HIS システム全体には数百ものインタフェースが関与する可能性があることに注意してください。これらのインタフェースがすべて含まれた場合のルーティング・プロダクションの管理タスクを予想してください。各コンポーネントの名前は、その目的を明確に示す必要があります。このようにすることで、開発者とシステム管理者は、機能に基づいてコンポーネントの名前を容易に予測することができます。

命名規則は一式すべてプロジェクトの開始時に確立し、その後はこれらに従うことをお勧めします。これによって、名前を修正するだけのためにプロダクション構成に戻る必要性が軽減されます。

機能別に明確にコンポーネントを特定できる規則であれば問題ありません。Ensemble ユーザが使用し、成功を収めている命名規則一式を以下に示します。

• 構成項目名に関する規則は、"Ensemble プロダクションの構成" の “構成名” を参照してください。

• 名前を作成するために組み合わせる個々のセグメントをリストします。具体的な内容は次のとおりです。

  • キーワード ：

    • From (受信用)

    • To (送信用)

    • Router (ルーティング用)

    • Rules (ルール・セット用)

    • ベース・スキーマ・カテゴリの番号 — 2.1、2.2、2.3、2.3.1、2.4、2.5、2.5.1、2.6、2.7、または 2.7.1 — (スキーマ用)

  • アプリケーションごとの短い名前

  • メッセージ構造の一般的なクラスを特定するキーワード (ADT、ORM など)

  • 完全なメッセージ構造名 (ADT_A01、ADT_A04、ORM_O01 など)

• 名前の各セグメントは簡潔にする (3 ～ 6 文字)

• 名前は大文字と小文字を区別する

プロダクションの要素ごとに、定義したセグメントから名前を組み立てます。

• ビジネス・サービス ： FromSourceAppName

• ビジネス・オペレーション ： ToTargetAppName

• ルーティング・プロセス ： SourceAppNameRouter

• ルーティング・ルール・セット ： SourceAppNameRules

• データ変換 ：

  SourceAppNameSourceMessageTypeToTargetAppNameTargetMessageType

• カスタム・スキーマ・カテゴリ ： SourceAppNameBaseSchemaNumber

さらに複雑な設計の場合は以下のようになります。

• ビジネス・サービス ： FromSourceAppNameMessageTypes

• ビジネス・オペレーション ： ToTargetAppNameMessageTypes

• ルーティング・プロセス ： SourceAppNameMessageTypesRouter

• ルーティング・ルール・セット ： SourceAppNameMessageTypesRules

以下のトピックでは、これらの命名規則について説明し、例を示します。

ビジネス・サービス

規則

例

FromERChart、FromFineOR、FromDeskAdm

バリエーション

1 つのアプリケーションが複数のビジネス・サービスを介してメッセージを Ensemble に送信するようインタフェースを編成する場合は、各ビジネス・サービスを通過する MessageTypes を分類するキーワードも含めます。一般的な MessageTypes キーワードでは、ADT、ORM、ORU など、HL7 バージョン 2 のメッセージ構造の最初の 3 文字を使用します。この場合、ビジネス・サービス名の規則は、FromSourceAppNameMessageTypes となります。

例

FromERChartADT、FromERChartORM、FromERChartOther

ルーティング・プロセス

規則

例

ERChartRouter、FineORRouter、DeskAdmRouter

1 つのアプリケーションが複数のビジネス・サービスを介してメッセージを Ensemble に送信するようインタフェースを編成する場合は、各ビジネス・サービスを通過してルーティング・プロセスに渡される MessageTypes を分類するキーワードも含めます。この場合、ルーティング・プロセス名の形式は以下のとおりです。

バリエーション

例

ERChartADTRouter、ERChartORMRouter、ERChartOtherRouter

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

規則

例

ToImagit、ToFineOR、ToPindex

バリエーション

1 つのアプリケーションが複数のビジネス・オペレーションを介して Ensemble からメッセージを受信するようインタフェースを編成する場合は、各ビジネス・オペレーションを通過する MessageTypes を分類するキーワードも含めます。一般的な MessageTypes キーワードでは、ADT、ORM、ORU など、HL7 バージョン 2 のメッセージ構造の最初の 3 文字を使用します。この場合、ビジネス・オペレーション名の規則は以下のとおりです。

例

ToMainLabADT、ToMainLabORM、ToMainLabOther

データ変換

規則

SourceMessageType と TargetMessageType は同じ名前になる場合がありますが、異なるスキーマ・カテゴリの同じメッセージ構造を表しています。

例

ERChartADTA03ToMainLabADTA03、ERChartADTA02ToMainLabADTA01

カスタム・スキーマ・カテゴリ

規則

ApplicationName は、送信アプリケーションまたは受信アプリケーションを表すことができます。

例

ERChart2.2、Imagit2.3.1、OurFavorite2.5