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 WebSphere Message Broker Connectivity Pack for Healthcare をどのように接続できるかが示されています。

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

メッセージ・モデル

IBM Integration Bus Healthcare Pack バージョン 3 には、HL7 メッセージを処理するための以下の 2 つのメッセージ・モデルが含まれます。
  • DFDL メッセージ・モデル (IBM Integration Bus バージョン 8 で導入され、IBM Integration Bus Healthcare Pack バージョン 8 でサポートされるようになっています)
  • HL7v25P メッセージ・セット (IBM Integration Bus Healthcare Pack バージョン 7 でも使用できます)
DFDL メッセージ・モデル

DFDL (Data Format Definition Language) は、汎用性があり、共有可能で、規定的ではない、汎用テキストおよびバイナリー形式の記述です。 これは、メッセージ・モデルを定義するために IBM Integration Bus (バージョン 8 以降) で使用されます。 メッセージ・モデルでの DFDL の使用について詳しくは、メッセージ・モデル (IBM Integration Bus 製品資料内) を参照してください。

注: IBM Integration Bus Healthcare Pack バージョン 7 で使用可能な 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 Integration Bus Healthcare Pack バージョン 7 でも使用できる HL7 パターン (Healthcare: HL7 から HL7 パターン、Healthcare: HL7 からレポート パターン、および Healthcare: 医療デバイスから EMR パターン) は、HL7v25P メッセージ・セットを現在も使用します。 ただし、DFDL メッセージ・モデルが使用する新しいパターン (Healthcare: HL7 から HL7 DFDL) は、IBM Integration Bus Healthcare Pack バージョン 8 で使用できます。
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: HL7 から HL7 パターン
Healthcare: HL7 変換 パターンは、HL7 メッセージをアセンブルするために使用できるグラフィカル・データ・マップを生成します。
Healthcare: HL7 変換パターン
Healthcare: HL7 から HL7 DFDL パターン
注: IBM Integration Bus Healthcare Pack バージョン 8 には、使用可能なこのパターンの別バージョンが存在します (Healthcare: HL7 から HL7)。 ただし、Healthcare: HL7 から HL7 DFDLMRMHL7v25P メッセージ・セットの代わりに 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: HL7 からレポート パターン
Healthcare: HL7 からレポート パターンは、HL7 v2 メッセージを送信できるアプリケーションを、レポート生成と統合します。 送信元アプリケーションは、MLLP over TCP/IP を使用して、HL7 メッセージを送受信できる必要があります。 このパターンには、カスタマイズ可能なサブフローが含まれます。
この図には、Healthcare:
HL7 からレポート パターンのメッセージ・フローが示されています。
送信元アプリケーションは MLLP over TCP/IP を使用して、受信側フローにメッセージを送信します。 受信側フローは WebSphere
MQ を使用して、レポートを生成するプロセッサー・フローにメッセージを送信します。

 

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 応答で要求側アプリケーションに送り返されます。

パターンの詳細については、IBM Integration Bus Healthcare Pack で提供されるパターンを使用した医療メッセージ・フロー・アプリケーションの開発を参照してください。

運用モニター

IBM Integration Bus Healthcare Pack には、臨床アプリケーション間のメッセージのフローおよび医療デバイスの状況をモニターするための 「Healthcare 運用モニター」ビューIBM Integration Explorer 内にあります。 発生する接続性に関する問題を検出し修正するために、この情報を使用できます。

パターン・インスタンスとして生成されるメッセージ・フローは、IBM Integration Explorer の運用モニターが各メッセージ・フローの TCP/IP 接続と、これらの TCP/IP 接続のそれぞれに関連付けられたアプリケーションを識別できるようにするプロパティーで定義されます。 そのため、モニター・パネルは、管理者が是正措置を実行できるようにアプリケーションが切断されたことを示す警告アイコンを表示することができます。

この図は、送信元アプリケーションから「Healthcare: HL7 から HL7」パターンへ、およびそのパターンから宛先アプリケーションへの両方のモニターされる接続を示しています。

TCP/IP モニター・パネルは、IBM Integration Bus Healthcare Pack のパターンの 1 つによって生成されたのではないメッセージ・フローの一部である TCP/IP 接続の状態を表示することもできます。 例えば、DFDL メッセージ・モデルまたは HL7v25P メッセージ・セットを使用して開発されたフローなどです。 フローがパターンによって使用されるプロパティーと同じプロパティーを使用して定義されない限り、これらのフローにはパターン・インスタンスによって構成される追加情報がありません。

運用モニターのための 「Healthcare 運用モニター」ビューは、パターン・インスタンスのメッセージ・フローによって使用されるキューの状況も表示します。 特定のパターン・インスタンスに関するすべてのキューは、パターン・インスタンスに固有のキューの接頭部が名前に付けられます。 キューの接頭部を使用することにより、管理者は 1 つのパターン・インスタンスに関するすべてのキューを表示して、キュー項目数をモニターし、しきい値に達したとき (これはキューに対して表示される警告アイコンによって示されます) を識別できます。 すべてのキューを表示する機能は、さらなる問題、特にキューの順序付けにおけるメッセージの蓄積の判別も可能にします。 これは、シーケンス内でメッセージが欠落し、その欠落したメッセージが到着するまで後続のメッセージの送達が保留にされていることを示します。 この処置により、是正措置を取ってメッセージが送信元から宛先に流れるようにすることができます。

DFDL メッセージ・モデルまたは HL7v25P メッセージ・セットを使用して開発された Healthcare メッセージ・フロー・アプリケーションで、TCP/IP 接続と同じようにしてキューをモニターできます。 モニターが必要な場合、モニターするキューは、すべて同じ接頭部を名前に付けて、モニターのディスプレイで臨床アプリケーションの情報をグループ化できるようにする必要があります。

MedicalDeviceInput ノードに接続された医療デバイスの状況をモニターできます。

運用モニターについて詳しくは、運用モニターを参照してください。

ATNA 監査イベント

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

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

医療データ分析

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

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

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

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 2011, 2014Copyright IBM Corporation 2011, 2014.

        
        最終更新
        
        最終更新 : 2014-03-20 23:29:11


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