IBM Integration Bus Healthcare Pack の概要

IBM® Integration Bus Healthcare Pack は、IBM Integration Bus 上に構築され、医療環境のアプリケーションに対するサポートを提供します。

IBM Integration Bus Healthcare Pack では、以下の機能を提供します。

以下の図には、IBM Integration Bus Healthcare Pack 構成の基本的なアーキテクチャーが示されています。 医療デバイス、臨床アプリケーション、デバイス・ゲートウェイ、請求システム、医療情報交換などの多様な医療システムに IBM Integration Bus Healthcare Pack をどのように接続できるかが示されています。

医療デバイス、臨床アプリケーション、デバイス・ゲートウェイ、請求システム、イメージ・アーカイブ、監査リポジトリー、医療情報交換などの多様な医療システムに IBM Integration Bus Healthcare Pack をどのように接続できるかを示した図です。

HL7の詳細については、Health Level Seven International を参照してください。

メッセージ・モデル

IBM Integration Bus Healthcare Pack バージョン 4.0 には、HL7 メッセージを処理するための以下の 2 つのメッセージ・モデルが含まれています。
  • DFDL メッセージ・モデル
  • HL7v25P メッセージ・セット
DFDL メッセージ・モデル

DFDL (Data Format Definition Language) は、汎用のテキスト形式とバイナリー形式に対応した、汎用性の高い、共有可能で、規定的ではない記述言語です。IBM Integration Bus では、この言語を使用してメッセージ・モデルを定義します。 メッセージ・モデルでの DFDL の使用について詳しくは、メッセージ・モデル (IBM Integration Bus 製品資料内) を参照してください。

注: IBM WebSphere® Message Broker Connectivity Pack for Healthcare バージョン 7.0 で使用できる HL7v25P メッセージ・セットは、現在もサポートされています。 ただし、DFDL メッセージ・モデルには以下のメリットがあるため、可能であれば新規および更新するアプリケーションにはこのモデルを使用することをお勧めします。
  • DFDL はオープン・スタンダード形式であるのに対し、MRM および HL7v25P メッセージ・セット は、IBM Integration Bus 独自の形式です。
  • HL7 スキーマの拡張機能の開発およびテスト用ツールは、MRMHL7v25P メッセージ・セット で提供されるものと比較して、DFDL エディターの方が簡単です。
  • DFDL メッセージ・モデルHL7 のバージョン 2.7、2.6、および 2.5.1 以前をサポートするのに対し、MRMHL7v25P メッセージ・セットHL7 バージョン 2.5.1 以前しかサポートしません。

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 以前で定義された有効なセグメントを処理できます。

注: DFDL メッセージ・モデルは、Healthcare: HL7 から HL7 DFDL パターンのパターン・リソースからダウンロードできます。 詳しくは、HL7 アプリケーションとの統合を参照してください。
注: IBM WebSphere Message Broker Connectivity Pack for Healthcare バージョン 7.0 でも使用できる HL7 パターン (「Healthcare: HL7 から HL7」パターン、「「Healthcare: 医療デバイスから EMR」パターン) では、HL7v25P メッセージ・セット を使用します。 ただし、IBM WebSphere Message Broker Connectivity Pack for Healthcare バージョン 8.0 の「Healthcare: HL7 から HL7 DFDL」パターンでは、DFDL メッセージ・モデルの使用が導入されました。 IBM Integration Bus Healthcare Pack バージョン 3.0 (「Healthcare: HL7 変換」および「Healthcare: ホーム・ヘルス」パターン) で追加されたパターンでは、DFDL メッセージ・モデル が使用されます。
HL7v25P メッセージ・セット

HL7v25P メッセージ・セット には、汎用 HL7 メッセージの定義が含まれます。 この汎用 HL7 メッセージは、送信元の臨床アプリケーションからメッセージを読み取り、またメッセージを宛先の臨床アプリケーションに書き込むために、パターン内の MRM パーサーとともに使用されます。 この HL7 メッセージは、HL7 バージョン 2.5.1 以前で定義された有効なセグメントを処理できます。

可能であれば HL7v25P メッセージ・セットの代わりに DFDL メッセージ・モデルを使用することが推奨されていますが、HL7v25P メッセージ・セットを使用した方がよい場合もあります。 例えば、データを HL7v2 の非 XML 標準から XML 表現に変換するために HL7v25P メッセージ・セットを使用する場合には、メッセージ・ツリーのエレメント名を変更する必要はありません。

注: HL7v25P メッセージ・セットは、Healthcare: HL7 から HL7 パターンのパターン・リソースからダウンロードできます。 詳しくは、HL7 アプリケーションとの統合を参照してください。

臨床アプリケーションは、HL7 メッセージの Z セグメントを使用することにより、非標準の情報を伝達することもできます。 パターンでこのタイプのメッセージを使用すると、追加の非標準の Z セグメントHL7 メッセージに追加して、サイト固有の Z セグメントをサポートすることができます。

HL7 メッセージがパターン・インスタンスに読み込まれると、選択したメッセージ・モデルを使用して、最初のカスタマイズ・ポイントの後で生成される正規形式 (XML フォーマット) を出力することもできます。 パターンによって出力される正規形式は HL7 XML ではありませんが、これを使用してデータをプラットフォームから独立した表記で保持することができます。 このデータは、標準化された日時、数値のフォーマット、または課されるその他のデータ標準化要件の形式になることがあります。

メッセージ・モデルは、特定のタイプの HL7 メッセージとイベント・コードを処理することもできます。 特定の HL7 チャプターのメッセージを処理するメッセージ・フロー・アプリケーションを実装する場合は、メッセージ・モデルのチャプター定義からの適切なメッセージ・タイプを使用して、メッセージの読み取りおよび書き込みを実行しなければなりません。 HL7 は、そのすべてのメッセージをチャプターと呼ばれるグループに分割します。これは HL7 標準のチャプターに対応します。メッセージ・モデルからの特定の HL7 メッセージを処理している場合、メッセージの出力は HL7 フォーマットで行うことも HL7 XML フォーマットで行うことも可能です。 これらのフォーマットを使用することにより、送信元と宛先のメッセージの間で行うメッセージの変換におけるグラフィカル・マッピングの使用を簡略化することもできます。

HL7の詳細については、Health Level Seven Internationalを参照してください。

HL7 ノード

DFDL メッセージ・モデル を使用すると、HL7 メッセージを送受信するためにメッセージ・フローで使用できる以下の HL7 ノードが提供されます。
  • HL7DFDLInput。 これは、メッセージ・フローで処理する HL7 メッセージを受信し、メッセージが重複していないかどうか判別するために、メッセージ・フローで使用できます。
  • HL7DFDLOutput。 これは、HL7 メッセージを MLLP で宛先に渡し、有効な肯定応答を受け取るかどうかを検査するために使用できます。
これらのHL7 ノードについて詳しくは、HL7DFDLInput ノードおよびHL7DFDLOutput ノードを参照してください。
HL7v25P メッセージ・セット を使用すると、HL7 メッセージを送受信するためにメッセージ・フローで使用できる以下の HL7 ノードが提供されます。
  • GenericHL7Input。 これは、メッセージ・フローで処理する HL7 メッセージを受信し、メッセージが重複していないかどうか判別するために、メッセージ・フローで使用できます。
  • GenericHL7Output。 これは、HL7 メッセージを MLLP で宛先に渡し、有効な肯定応答を受け取るかどうかを検査するために使用できます。
これらのHL7 ノードについて詳しくは、GenericHL7Input ノードおよびGenericHL7Output ノードを参照してください。

医療デバイスの統合

IBM Integration Bus Healthcare Pack には、入力ノードである MedicalDeviceInput ノードがあります。 このノードによって、接続した医療デバイスからの情報をメッセージ・フローに渡すことができます。 このノードを使用して、医療デバイスのデータを他のシステム (例えば、データウェアハウス) やナースのモニター端末に送信するメッセージ・フローを開発できます。

各デバイスは別個の通信ポート (シリアルまたは LAN) に接続し、これらの通信ポートを listen するように MedicalDeviceInput ノード内のデバイス・ドライバーを構成します。 このノード構成は、接続されたデバイス、および各デバイスからの必要な測定を識別します。

この図には、臨床装置からデバイス・ドライバーへのデータのフローが示されています。
その後、このフローは MedicalDeviceInput ノードに進み、そのノードは状況およびデータ情報を残りのフローに送信します。

この図には、ベット 1、ベット 2、ベット N のそれぞれに備えられた臨床装置からデバイス・ドライバーへのデータのフローが示されています。 例えば、心拍数モニターからドライバー 1 へ、そして点滴ポンプから 統合サーバー を介してドライバー 2 に進みます。 その後、フローは、状況およびデータ情報を残りのフローに送信する MedicalDeviceInput ノードに進みます。

MedicalDeviceInput ノードの構成

メッセージ・フローからのデータ・フローは、デバイス構成を更新するときに中断することはできません (例えば、必要な測定を変更するときや、デバイスの追加、切断、移動の際に物理接続を変更するときなど)。 そのため、医療データを受け取るメッセージ・フローを停止したり再デプロイしたりしなくても、ノードによって構成の変更を実装できるように、構成データは構成可能サービスとして保持されます。

MedicalDeviceInput ノードは、構成可能サービス用のエディターを始動する「プロパティー」タブを使用して構成します。 「医療デバイス構成可能サービス」エディターで、管理者はサポートされるデバイスのリストからデバイス・タイプを最初に選択します。それから、通信タイプ (シリアルまたは LAN) を選択して、適切な通信の詳細を指定します。

測定セット

同じタイプの複数のデバイスが同じタイプの測定を同じ間隔で (例えば、心拍数、血液温度、呼吸数を 5 分ごとに) 提供する必要がある場合は少なくありません。 この要件は、病室のすべてのベットに配置する複数のデバイスに当てはまるかもしれません。 そのため、「医療デバイス構成可能サービス」エディターは、複数の測定を指定し、任意の数のデバイスに適用できる測定セット の構成をサポートします。

管理者が測定セットを構成している時にデバイス・タイプを選択すると、そのデバイス・タイプによってサポートされている測定のリストが表示されます。管理者は必要な測定を選択することができます。 また、管理者は各測定に対して、処理のためにメッセージ・フローに渡す測定の間隔を指定します。

多くのデバイスと測定を構成する必要がある場合、構成データが広範囲に及ぶことがあります。 そのため、明確にするために、管理者は、各デバイスのロケーション、患者 ID 情報、注記、および各デバイスと測定セットのタグに関する説明を提供することができます。

メッセージ・フローでの MedicalDeviceInput ノードの使用

MedicalDeviceInput ノードから流れるデータは、メッセージ・フローによって処理することができます。 その際、IBM Integration Bus で使用可能なノードのいずれかを使用します。 測定データは、論理メッセージ・ツリーとしてメッセージ・フローに渡されます。 メッセージ・ツリーでは DataObject ドメインが使用され、直列化フォーマットとして XML が存在します (メッセージがメッセージ・キューに書き込まれると、メッセージは XML に直列化されます)。 このデータは、ターゲット・エンドポイント (例えば、データベース、 IBM WebSphere MQ キュー、またはサービス呼び出しなど) に書き込まれる前に、標準の IBM Integration Bus の機能を使用して、フィルタリング、変換、集約、およびルーティングすることができます。

MedicalDeviceInput ノードの使用について詳しくは、メッセージ・フローでの医療デバイスからのデータの使用および MedicalDeviceInput ノードを参照してください。

DICOM イメージの統合

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 機能は、いくつかの主要シナリオをサポートします。
患者入院のための研究の収集
患者が病院に入院する場合、1 つ以上の場所にある DICOM PACS を照会して、その患者に関するすべての研究を検索および取得できます。 その患者を扱う医療スタッフは、関係のある医療イメージをすぐに使用できるようになります。 このシナリオの詳細については、患者入院のための研究の収集を参照してください。
セカンド・オピニオンまたは専門医の紹介
放射線技術が限られた場所で、DICOM イメージを医療システム内の他の病院の専門医に送付することができます (診断目的または研究目的)。 このシナリオの詳細については、セカンド・オピニオンまたは専門医の紹介を参照してください。
臨床ポータル
Web アプリケーションを使用して患者の DICOM 研究の詳細を表示できます。 このシナリオでは、イメージ・データではなく研究の属性のみが示されています (例えば、モダリティーや研究の日時)。 このシナリオの詳細については、臨床ポータルを参照してください。このシナリオは、IBM Integration Bus Healthcare PackHealthcare: Web サービスから DICOM パターンでも実装されています。
IBM Integration Bus Healthcare Pack には、3 つのノードが含まれます。
  • DICOMInput ノード。 DICOM イメージを DICOM Service Class User (SCU) ノード (例えば、DICOM モダリティー) から受信するために使用できます。 このノードを使用すると、メッセージ・フローで使用するために DICOM イメージからデータを抽出できます。 このノードは、DICOM C-STORE 要求をサポートします。
  • DICOMOutput ノード。 DICOM イメージを DICOM 画像アーカイブ通信システム (PACS) などの DICOM Service Class Provider (SCP) ノードに送信するために使用できます。 このノードを使用すると、メッセージ・フローからのメタデータを DICOM イメージと結合したり、その結果を外部の宛先に送信したりできます。 このノードは、DICOM C-STORE 要求をサポートします。
  • DICOMFindMove ノード。 特定の基準に一致する DICOM イメージを外部ソースに照会したり、オプションで DICOM イメージを別の場所に移動したりするために使用できます。 このノードは、DICOM C-FIND および C-MOVE 要求をサポートします。
注: IBM Integration Bus Healthcare Pack によって提供される DICOM 機能は、DICOM C-GET 要求をサポートしません。
メッセージ・フローでの DICOM ノードの使用について詳しくは、メッセージ・フローでの DICOM イメージのデータの使用を参照してください。

Healthcare パターン

IBM Integration Bus Healthcare Pack には、以下のパターンが組み込まれています。
Healthcare: HIPAA から XML パターン
Healthcare: HIPAA から XML パターンは、HIPAA ファイルを XML ファイルに変換するために使用できるメッセージ・フローを作成します。

 

Healthcare: ホーム・ヘルス パターン
Healthcare: ホーム・ヘルス」パターンを使用すれば、ホーム・ヘルス・デバイス (体重計など) に記録されたデータを要求元の臨床アプリケーションに転送する処理を簡略化できます。患者に関する読み取りデータがホーム・ヘルス・デバイスからアプリケーション・ホスティング・デバイス (AHD) に送信されます。その AHD から WAN 経由で要求元のアプリケーションにデータが送信されます。
「Healthcare: ホーム・ヘルス」パターン

 

Healthcare: HL7 から HL7 パターン
Healthcare: HL7 変換 パターンは、HL7 メッセージをアセンブルするために使用できるグラフィカル・データ・マップを生成します。
Healthcare: HL7 変換パターン

 

Healthcare: HL7 から HL7 DFDL パターン
注: このパターンの別のバージョン (「Healthcare: HL7 から HL7」パターン) も用意されています。 ただし、「Healthcare: HL7 から HL7 DFDL」パターンは MRMHL7v25P メッセージ・セット の代わりに DFDL メッセージ・モデルを使用するため、可能であれば新規および更新するアプリケーションにはこのパターンを使用することをお勧めします。 DFDL メッセージ・モデルには、以下のメリットがあります。
  • DFDL はオープン・スタンダード形式であるのに対し、MRM および HL7v25P メッセージ・セット は、IBM Integration Bus 独自の形式です。
  • HL7 スキーマの拡張機能の開発およびテスト用ツールは、MRMHL7v25P メッセージ・セット で提供されるものと比較して、DFDL エディターの方が簡単です。
  • DFDL メッセージ・モデルHL7 のバージョン 2.7、2.6、および 2.5.1 以前をサポートするのに対し、MRMHL7v25P メッセージ・セットHL7 バージョン 2.5.1 以前しかサポートしません。

Healthcare: HL7 から HL7 DFDL パターンは、メッセージの HL7 v2 規格を使用する医療アプリケーション間の仲立ちをします。 例えば、患者管理システム (PAS) が、患者情報を必要とする 1 つ以上の臨床アプリケーションに配布される単一メッセージを送出することがあります。

このパターンは、単一の HL7 タイプ (例えば ADT) とコード (例えば A01) のメッセージの処理に制約されません。 有効なメッセージ・タイプとコードを持つメッセージなら何でも受信して処理できます。 これらのアプリケーションは、MLLP over TCP/IP を使用して、メッセージを送受信できる必要があります。

このパターンには、3 つの異なるメッセージ・フローが含まれ (複数の宛先を選択する場合、追加のメッセージ・フローを使用します)、さらにカスタマイズ可能なサブフローが含まれます。

この図には、Healthcare: HL7 から HL7 DFDL パターンのメッセージ・フローが示されています。
送信元アプリケーションは MLLP over TCP/IP を使用して、受信側フローにメッセージを送信します。
受信側フローは WebSphere MQ を使用して、変換およびルーティング・フローにメッセージを送信します。
変換およびルーティング・フローは WebSphere MQ を使用して、1 つ以上の送信側フローにメッセージを送信します。
送信側フローは、MLLP over TCP/IP を使用して宛先アプリケーションにメッセージを送信します。

 

Healthcare: 医療デバイスから EMR パターン
Healthcare: 医療デバイスから EMR パターンは、HL7 v2 観察結果メッセージ (ORU R01) を受信できる電子医療記録 (EMR) アプリケーションと医療デバイスを統合します。 このアプリケーションは、MLLP over TCP/IP を使用して、HL7 ORU R01 メッセージを受信できる必要があります。 このパターンには、カスタマイズ可能なサブフローが含まれます。
この図には、Healthcare: 医療デバイスから EMR パターンのメッセージ・フローが示されています。
医療デバイスは、医療デバイス・フローにメッセージを送信します。
医療デバイス・フローは WebSphere MQ を使用して、変換およびルーティング・フローにメッセージを送信します。
変換およびルーティング・フローはデータベースから患者情報を読み取ります。
このデータベースは、Web サービス・フローによって臨床ダッシュボードからの情報で更新されます。
変換およびルーティング・フローは WebSphere MQ を使用して、送信側フローにメッセージを送信します。
送信側フローは MLLP over TCP/IP を使用して、宛先アプリケーションにメッセージを送信します。

 

Healthcare: Web サービスから DICOM パターン
Healthcare: Web サービスから DICOM パターンは、Web サービスを使用して書かれたアプリケーションを、C-FIND および C-MOVE 操作をサポートする DICOM アプリケーションと統合します。 このパターンを使用すると、IBM Integration Bus によって実装される Web サービスを使用することによって、患者、研究、系列およびイメージを DICOM PACS から照会できます。
この図には、Healthcare: Web サービスから DICOM パターンのメッセージ・フローが示されています。
要求側アプリケーションは、SOAP 要求メッセージで検索基準を XML 本体として送信します。
このパターン・インスタンスによって生成されるメイン・メッセージ・フローは、その本体を抽出し、それを DICOMFindMove ノードに渡します。
DICOMFindMove ノードによって伝搬される XML の結果は、SOAP 応答で要求側アプリケーションに送り返されます。

 

Healthcare: Patient Identifier Cross-reference Manager パターン
Healthcare: Patient Identifier Cross-reference Manager」パターンを使用すると、IBM InfoSphere Master Data Management によって、Integrating the Healthcare Enterprise (IHE) 患者 ID 相互参照 (Patient Identifier Cross Referencing: PIX) プロファイルで使用する患者 ID 相互参照マネジャー (Patient Identifier Cross-reference Manager) を作成できます。その後、臨床アプリケーションをパターンに接続して、PIX プロファイルで定義されたとおりに「Patient Identity Source」アクターおよび「Patient Identifier Cross-reference Consumer」アクターとなるようにすることができます。

 

Healthcare: 患者基本情報照会サプライヤー パターン
Healthcare: 患者基本情報照会サプライヤー」パターンを使用すると、IBM InfoSphere Master Data Management によって Integrating the Healthcare Enterprise (IHE) 患者基本情報照会 (Patient Demographics Query: PDQ) プロファイルで使用する患者基本情報サプライヤー (Patient Demographics Supplier) を作成できます。その後、臨床アプリケーションをこのパターンに接続して、PDQ プロファイルで定義されているように「患者基本情報コンシューマー (Patient Demographics Consumer)」アクターとなるようにすることができます。

 

Healthcare: 企業間ドキュメント共有コンシューマー」パターン
Healthcare: 企業間ドキュメント共有コンシューマー」パターンは、XDS レジストリーに格納されているドキュメントの UUID (Unique Universal Identifiers) を検索し、その UUID を使用して XDS リポジトリーからそれらのドキュメントを取り出すときに用います。詳しくは、「Healthcare: 企業間ドキュメント共有コンシューマー」パターンを参照してください。

 

Healthcare: FHIR 変換 パターン
Healthcare: FHIR 変換」パターンは、HL7 FHIR リソースを XML 形式から JSON 形式に変換する場合に使用します。詳しくは、「Healthcare: FHIR 変換」パターンを参照してください。

 

パターンの詳細については、IBM Integration Bus Healthcare Pack で提供されるパターンを使用した医療統合ソリューションの開発を参照してください。

ATNA 監査イベント

ATNA (監査証跡およびノード認証) 統合プロファイルは、セキュリティーのいくつかの側面を扱います。 これには、リポジトリー内の監査イベント・メッセージを安全にルーティングして保管するための標準およびプロセスが含まれます。 ATNAAudit ノードを使用することにより、メッセージ・フローを介してルーティングされる医療データから ATNA 監査イベント・メッセージを生成し、指定した ATNA 監査リポジトリーにそれらの監査イベント・メッセージを送信できます。

メッセージ・フローにおけるデータの監査については、メッセージ・フローからのデータの監査を参照してください。

医療データ分析

IBM Integration Bus の「データ分析」パースペクティブを、IBM Integration Bus Healthcare Pack によって提供されるデータ分析プロファイルとともに使用して、メッセージ・フローの医療データを分析したりフィルターに掛けたりできます。 医療データは、下流のアプリケーションが簡単に処理できない複雑なドキュメントやメッセージに送り込まれることがよくあります。 データ分析プロジェクトを使用することによって、医療データを分析し、主要エレメントを抽出し、簡略化されたメッセージ構造を作成して、その構造を、ビジネス・インテリジェンス・ツールによって使用されるデータベース表に直接マップすることができます。

IBM Integration Bus Healthcare Pack は、4 つのデータ分析プロファイルを提供します。 各プロファイルは、特定のタイプの医療データに使用されます。

医療データの分析について詳しくは、メッセージ・フロー内の医療データの分析を参照してください。

Copyright IBM Corporation 2011, 2015Copyright IBM Corporation 2011, 2015.

        
        最終更新
        
        最終更新 : 2015-06-23 08:45:59


概念トピック概念トピック | バージョン 4.0.0.0 | ha00010