IBM® Integration Bus Healthcare Pack は、IBM Integration Bus 上に構築され、医療環境のアプリケーションに対するサポートを提供します。
IBM Integration Bus Healthcare Pack では、以下の機能を提供します。
以下の図には、IBM Integration Bus Healthcare Pack 構成の基本的なアーキテクチャーが示されています。 医療デバイス、臨床アプリケーション、デバイス・ゲートウェイ、請求システム、医療情報交換などの多様な医療システムに IBM Integration Bus Healthcare Pack をどのように接続できるかが示されています。
HL7の詳細については、Health Level Seven Internationalを参照してください。
DFDL (Data Format Definition Language) は、汎用性があり、共有可能で、規定的ではない、汎用テキストおよびバイナリー形式の記述です。 これは、メッセージ・モデルを定義するために IBM Integration Bus (バージョン 8 以降) で使用されます。 メッセージ・モデルでの DFDL の使用について詳しくは、メッセージ・モデル (IBM Integration Bus 製品資料内) を参照してください。
IBM Integration Bus Healthcare Pack は、DFDL メッセージ・モデルの 3 つのバージョン (HL7 バージョン 2.7 用、HL7 バージョン 2.6 用、および HL7 バージョン 2.5.1 以前用) を提供します。 各 DFDL メッセージ・モデル には、汎用 HL7 メッセージの定義が含まれます。 この汎用 HL7 メッセージは、送信元の臨床アプリケーションからメッセージを読み取り、メッセージを宛先の臨床アプリケーションに書き込むために、パターン内の DFDL パーサーとともに使用されます。 この HL7 メッセージは、HL7 バージョン 2.7、2.6、または 2.5.1 以前で定義された有効なセグメントを処理できます。
HL7v25P メッセージ・セット には、汎用 HL7 メッセージの定義が含まれます。 この汎用 HL7 メッセージは、送信元の臨床アプリケーションからメッセージを読み取り、またメッセージを宛先の臨床アプリケーションに書き込むために、パターン内の MRM パーサーとともに使用されます。 この HL7 メッセージは、HL7 バージョン 2.5.1 以前で定義された有効なセグメントを処理できます。
可能であれば HL7v25P メッセージ・セットの代わりに DFDL メッセージ・モデルを使用することが推奨されていますが、HL7v25P メッセージ・セットを使用した方がよい場合もあります。 例えば、データを HL7v2 の非 XML 標準から XML 表現に変換するために HL7v25P メッセージ・セットを使用する場合には、メッセージ・ツリーのエレメント名を変更する必要はありません。
臨床アプリケーションは、HL7 メッセージの Z セグメントを使用することにより、非標準の情報を伝達することもできます。 パターンでこのタイプのメッセージを使用すると、追加の非標準の Z セグメントを HL7 メッセージに追加して、サイト固有の Z セグメントをサポートすることができます。
HL7 メッセージがパターン・インスタンスに読み込まれると、選択したメッセージ・モデルを使用して、最初のカスタマイズ・ポイントの後で生成される正規形式 (XML フォーマット) を出力することもできます。 パターンによって出力される正規形式は HL7 XML ではありませんが、これを使用してデータをプラットフォームから独立した表記で保持することができます。 このデータは、標準化された日時、数値のフォーマット、または課されるその他のデータ標準化要件の形式になることがあります。
メッセージ・モデルは、特定のタイプの HL7 メッセージとイベント・コードを処理することもできます。 特定の HL7 チャプターのメッセージを処理するメッセージ・フロー・アプリケーションを実装する場合は、メッセージ・モデルのチャプター定義からの適切なメッセージ・タイプを使用して、メッセージの読み取りおよび書き込みを実行しなければなりません。 HL7 は、そのすべてのメッセージをチャプターと呼ばれるグループに分割します。 これは HL7 標準のチャプターに対応します。 メッセージ・モデルからの特定の HL7 メッセージを処理している場合、メッセージの出力は HL7 フォーマットで行うことも HL7 XML フォーマットで行うことも可能です。 これらのフォーマットを使用することにより、送信元と宛先のメッセージの間で行うメッセージの変換におけるグラフィカル・マッピングの使用を簡略化することもできます。
HL7の詳細については、Health Level Seven Internationalを参照してください。
IBM Integration Bus Healthcare Pack には、入力ノードである MedicalDeviceInput ノードがあります。 このノードによって、接続した医療デバイスからの情報をメッセージ・フローに渡すことができます。 このノードを使用して、医療デバイスのデータを他のシステム (例えば、データウェアハウス) やナースのモニター端末に送信するメッセージ・フローを開発できます。
各デバイスは別個の通信ポート (シリアルまたは LAN) に接続し、これらの通信ポートを listen するように MedicalDeviceInput ノード内のデバイス・ドライバーを構成します。 このノード構成は、接続されたデバイス、および各デバイスからの必要な測定を識別します。
この図には、ベット 1、ベット 2、ベット N のそれぞれに備えられた臨床装置からデバイス・ドライバーへのデータのフローが示されています。 例えば、心拍数モニターからドライバー 1 へ、そして点滴ポンプから実行グループを介してドライバー 2 に進みます。 その後、フローは、状況およびデータ情報を残りのフローに送信する MedicalDeviceInput ノードに進みます。
メッセージ・フローからのデータ・フローは、デバイス構成を更新するときに中断することはできません (例えば、必要な測定を変更するときや、デバイスの追加、切断、移動の際に物理接続を変更するときなど)。 そのため、医療データを受け取るメッセージ・フローを停止したり再デプロイしたりしなくても、ノードによって構成の変更を実装できるように、構成データは構成可能サービスとして保持されます。
MedicalDeviceInput ノードは、構成可能サービス用のエディターを始動する「プロパティー」タブを使用して構成します。 「医療デバイス構成可能サービス」エディターで、管理者はサポートされるデバイスのリストからデバイス・タイプを最初に選択します。それから、通信タイプ (シリアルまたは LAN) を選択して、適切な通信の詳細を指定します。
同じタイプの複数のデバイスが同じタイプの測定を同じ間隔で (例えば、心拍数、血液温度、呼吸数を 5 分ごとに) 提供する必要がある場合は少なくありません。 この要件は、病室のすべてのベットに配置する複数のデバイスに当てはまるかもしれません。 そのため、「医療デバイス構成可能サービス」エディターは、複数の測定を指定し、任意の数のデバイスに適用できる測定セット の構成をサポートします。
測定セットを構成する際、管理者はデバイス・タイプを選択すると、そのデバイス・タイプによってサポートされる測定のリストが表示されます。 管理者は必要な測定を選択することができます。 また、管理者は各測定に対して、処理のためにメッセージ・フローに渡す測定の間隔を指定します。
多くのデバイスと測定を構成する必要がある場合、構成データが広範囲に及ぶことがあります。 そのため、明確にするために、管理者は、各デバイスのロケーション、患者 ID 情報、注記、および各デバイスと測定セットのタグに関する説明を提供することができます。
MedicalDeviceInput ノードから流れるデータは、メッセージ・フローによって処理することができます。 その際、IBM Integration Bus で使用可能なノードのいずれかを使用します。 測定データは、論理メッセージ・ツリーとしてメッセージ・フローに渡されます。 メッセージ・ツリーでは DataObject ドメインが使用され、直列化フォーマットとして XML が存在します (メッセージがメッセージ・キューに書き込まれると、メッセージは XML に直列化されます)。 このデータは、ターゲット・エンドポイント (例えば、データベース、IBM WebSphere®Â MQ キュー、サービスの呼び出しなど) に書き込まれる前に、標準 IBM Integration Bus 機能を使用することにより、フィルタリング、変換、集約、およびルーティングすることができます。
MedicalDeviceInput ノードの使用について詳しくは、メッセージ・フローでの医療デバイスからのデータの使用および MedicalDeviceInput ノードを参照してください。
DICOM (Digital Imaging and Communications in Medicine) は、医療イメージ情報の処理、保管、印刷、および伝送のための標準です。 情報には、DICOM イメージと DICOM 構造化レポート (SR) を含めることができます。
医療システム全体で DICOM イメージの検索、処理、およびルーティングを可能にするため、IBM Integration Bus Healthcare Pack を使用して DICOM PACS (画像アーカイブ通信システム) およびその他の DICOM モダリティーをメッセージ・フローに接続することができます。
IBM Integration Bus Healthcare Pack によって提供される DICOM 機能は、いくつかの主要シナリオをサポートします。Healthcare: HL7 から HL7 DFDL パターンは、メッセージの HL7 v2 規格を使用する医療アプリケーション間の仲立ちをします。 例えば、患者管理システム (PAS) が、患者情報を必要とする 1 つ以上の臨床アプリケーションに配布される単一メッセージを送出することがあります。
このパターンは、単一の HL7 タイプ (例えば ADT) とコード (例えば A01) のメッセージの処理に制約されません。 有効なメッセージ・タイプとコードを持つメッセージなら何でも受信して処理できます。 これらのアプリケーションは、MLLP over TCP/IP を使用して、メッセージを送受信できる必要があります。
このパターンには、3 つの異なるメッセージ・フローが含まれ (複数の宛先を選択する場合、追加のメッセージ・フローを使用します)、さらにカスタマイズ可能なサブフローが含まれます。
パターンの詳細については、IBM Integration Bus Healthcare Pack で提供されるパターンを使用した医療メッセージ・フロー・アプリケーションの開発を参照してください。
IBM Integration Bus Healthcare Pack には、臨床アプリケーション間のメッセージのフローおよび医療デバイスの状況をモニターするための 「Healthcare 運用モニター」ビューが IBM Integration Explorer 内にあります。 発生する接続性に関する問題を検出し修正するために、この情報を使用できます。
パターン・インスタンスとして生成されるメッセージ・フローは、IBM Integration Explorer の運用モニターが各メッセージ・フローの TCP/IP 接続と、これらの TCP/IP 接続のそれぞれに関連付けられたアプリケーションを識別できるようにするプロパティーで定義されます。 そのため、モニター・パネルは、管理者が是正措置を実行できるようにアプリケーションが切断されたことを示す警告アイコンを表示することができます。
TCP/IP モニター・パネルは、IBM Integration Bus Healthcare Pack のパターンの 1 つによって生成されたのではないメッセージ・フローの一部である TCP/IP 接続の状態を表示することもできます。 例えば、DFDL メッセージ・モデルまたは HL7v25P メッセージ・セットを使用して開発されたフローなどです。 フローがパターンによって使用されるプロパティーと同じプロパティーを使用して定義されない限り、これらのフローにはパターン・インスタンスによって構成される追加情報がありません。
運用モニターのための 「Healthcare 運用モニター」ビューは、パターン・インスタンスのメッセージ・フローによって使用されるキューの状況も表示します。 特定のパターン・インスタンスに関するすべてのキューは、パターン・インスタンスに固有のキューの接頭部が名前に付けられます。 キューの接頭部を使用することにより、管理者は 1 つのパターン・インスタンスに関するすべてのキューを表示して、キュー項目数をモニターし、しきい値に達したとき (これはキューに対して表示される警告アイコンによって示されます) を識別できます。 すべてのキューを表示する機能は、さらなる問題、特にキューの順序付けにおけるメッセージの蓄積の判別も可能にします。 これは、シーケンス内でメッセージが欠落し、その欠落したメッセージが到着するまで後続のメッセージの送達が保留にされていることを示します。 この処置により、是正措置を取ってメッセージが送信元から宛先に流れるようにすることができます。
DFDL メッセージ・モデルまたは HL7v25P メッセージ・セットを使用して開発された Healthcare メッセージ・フロー・アプリケーションで、TCP/IP 接続と同じようにしてキューをモニターできます。 モニターが必要な場合、モニターするキューは、すべて同じ接頭部を名前に付けて、モニターのディスプレイで臨床アプリケーションの情報をグループ化できるようにする必要があります。
MedicalDeviceInput ノードに接続された医療デバイスの状況をモニターできます。
運用モニターについて詳しくは、運用モニターを参照してください。
ATNA (監査証跡およびノード認証) 統合プロファイルは、セキュリティーのいくつかの側面を扱います。 これには、リポジトリー内の監査イベント・メッセージを安全にルーティングして保管するための標準およびプロセスが含まれます。 ATNAAudit ノードを使用することにより、メッセージ・フローを介してルーティングされる医療データから ATNA 監査イベント・メッセージを生成し、指定した ATNA 監査リポジトリーにそれらの監査イベント・メッセージを送信できます。
メッセージ・フローにおけるデータの監査については、メッセージ・フローからのデータの監査を参照してください。
IBM Integration Bus Healthcare Pack は、4 つのデータ分析プロファイルを提供します。 各プロファイルは、特定のタイプの医療データに使用されます。
医療データの分析について詳しくは、メッセージ・フロー内の医療データの分析を参照してください。