JP2013514576A - ユニバーサル医療デバイスドライバアダプタ - Google Patents

Abstract

典型的な医療装置のためにカスタムソフトウェアを書き込む必要なく、医療デバイスドライバの生成を可能にし、それにより、個々のドライバについての開発時間を短縮し、ドライバディベロッパのトレーニング時間及び技能に設定される要求を低減することが可能であるユニバーサル医療デバイスドライバを提供する。ＸＭＬデバイスドライバファイルにおいて、種々のフォーマットパラメータ、例えば、ボーレート、パリティ、バッファサイズ、タイムスタンプ、トークン、メッセージリンク等が規定される。認識される医療装置が特定されるとき、対応するＸＭＬファイルが検索され、インタフェースは、モニタとの双方向通信のために記述されたパラメータを用いる。

Description

本発明は、病院情報システム（ＨＩＳ）における特定のユーティリティを見出す。しかしながら、記載している技術はまた、他の種類の医療システム、他のデバイスドライバシステム及び／又は他の装置通信フレームワークにおける応用を見出すことも可能であることを理解することができる。

Ｐｈｉｌｉｐｓ社のＩｎｔｅｌｌｉＢｒｉｄｇｅ（登録商標）プラットフォームは、Ｐｈｉｌｉｐｓ社製製品のための医療装置インタフェーシングソリューションをもたらすために組み合わされる種々の構成要素を有する。ＥＣ１０、ＥＣ４０及びＥＣ８０通信プラットフォームは、医療装置に物理接続し、ドライバの使用を介して通信して、データを得、そのデータを規格１１０７３のフォーマットに変換し、そのデータを中央サーバに配信するＬｉｎｕｘ（登録商標）ベースのプラットフォームである。ＥＣ１０は、Ｐｈｉｌｉｐｓブランドのモニタのみにデータを供給する一方、ＥＣ４０／８０は、ＳＣ５０通信アーキテクチャを介して病院情報システム（ＨＩＳ）にデータを供給する。

ＥＣ１０は、既存のソリューションの後継であり、レガシーソリューションを有する既存の装置に存在することが可能である。所与のデバイスドライバが未だに、ＥＣ１０のために開発されていない場合には、レガシーソリューションを使用することが可能である。ＥＣ１０とは異なり、ＥＣ４０／８０はレガシーソリューションとは共存できず、故に、ＥＣ４０／８０のためのドライバが存在しない場合には、ドライバが開発される必要がある。

医療デバイスドライバの巨大なライブラリを開発するための現代化した方法を提供することを容易化するシステム及び方法に対する当該技術分野においては満たされていない要求が存在している。

一特徴に従って、拡張可能なフレームワークにおいてデバイスドライバのための再使用可能なコードの供給を容易化するシステムは、シングルポートパススルー接続を介してマルチポート医療データ取得装置（ＭＤＡＤ）に結合されている医療装置を検出するＭＤＡＤと、その医療装置のためにプラグアンドプレイ拡張可能マークアップ言語（ＸＭＬ）を生成するデバイスドライバマネージャ（ＤＤＭ）ツールとを有する。そのシステムは更に、医療装置又は類似する装置がそのシステムに結合されているときはいつでも、用いるためのＸＭＬデバイスドライバファイルを記憶するコンピュータ読み出し可能媒体を有する。ＸＭＬデバイスドライバファイルは、医療装置のためのデバイスドライバを記述している複数のフォーマットパラメータを有する。

他の特徴に従って、再使用可能な拡張可能マークアップ言語（ＸＭＬ）デバイスドライバファイルを生成する方法は、デバイスドライバのリストからデバイスドライバを選択するステップと、デバイスドライバマネージャ（ＤＤＭ）ツールを用いて選択されたデバイスドライバのためにＸＭＬドライバファイルを設定するステップと、それが完全に設定されたときに、ＸＭＬデバイスドライバを生成するステップと、を有する。その方法は、互換性のある医療装置の検出時に呼び出しのためにコンピュータ読み出し可能媒体にＸＭＬデバイスドライバファイルを記憶するステップを更に有する。ＸＭＬデバイスドライバファイルは、医療装置のためのデバイスドライバを記述している複数のフォーマットパラメータを有する。

他の特徴に従って、拡張可能マークアップ言語（ＸＭＬ）デバイスドライバマネージャ（ＤＭＭ）ツールは、複数の選択可能なボタン及びテキストフィールドを有するユーザインタフェースを有し、それらのボタン及びテキストフィールドにより、ユーザは情報を入力し、医療装置のためのＸＭＬデバイスドライバファイルを設定することができる。その情報は、１つ又はそれ以上のドライバ特性、１つ又はそれ以上のメッセージ特性、１つ又はそれ以上のドライバパラメータ及び１つ又はそれ以上のストリッピング要素を有する。
一有利点は、デバイスドライバの製品化までの時間が短縮されることである。

他の有利点は、ドライバ当たりの開発コストを低減することができることである。

他の有利点は、ドライバ開発者のための訓練時間及び技能に設定される要求を低減することができることである。

他の有利点は、ドライバ当たりのコードのラインを最小化することである。

他の有利点は、ドライバ維持コストを最小化することができることである。

他の有利点は、標準化イニシアティブを容易化することができることである。

本発明の更なる有利点については、当業者は、以下の詳細説明を読んで、理解することにより、認識することができる。

図は、種々の特徴を単に例示する目的のためのものであり、限定するとして解釈されるべきものではない。

プラグアンドプレイ医療装置環境でデバイスドライバのための用いられるコードの量の最小化を容易にするユニバーサル医療デバイスドライバアダプタ（ＵＭＤＡＡ）システム又はフレームワークを示す図である。 ＥＣ−１０コードベース、関連ドライバ及びデバイスドライバフレームワークを用いる医療データ取得装置（ＭＤＡＤ）を示す図である。 専用プロトコルを用いて通信するフレームワークに必要な情報をドライバ開発者が入力するデバイスドライバマネージャ（ＤＤＭ）ツールを示す図である。 本明細書に記載している種々の特徴に従った、ＤＤＭツールのスクリーンショットを示す図である。 本明細書に記載している１つ又はそれ以上の特徴に従った、デバイスドライバ構成インタフェース（ＤＤＣＩ）の“特徴”ページを示す図である。 本明細書に記載している１つ又はそれ以上の特徴に従った、ＤＤＣＩの“メッセージ”ページを示す図である。 本明細書に記載している種々の特徴に従った、メッセージを特定するように用いられるトークンの作成及び編集を容易にするトークン特定エディタ（ＴＳＥ）を示す図である。 本明細書に記載している１つ又はそれ以上の特徴に従った１６進フォーマットでの要求メッセージ又は応答メッセージをユーザが編集することを可能にする“メッセージビューア”を示す図である。 “チェックサム”ページ又はインタフェースを示す図である。（チェックサムは、メッセージにおけるバイト数に適用される算術演算である。） タイムスタンプ又はインタフェースを示す図である。 ＤＤＣＩの“パラメータ”ページを示す図である。 データフォーマットページ又はインタフェースのスクリーンショットを示す図である。 トークン特定インタフェースのスクリーンショットである。 “測定の単位”インタフェースのスクリーンショットである。 チャネル特定インタフェースのスクリーンショットである。 タイムスタンプインタフェースのスクリーンショットを示す図である。 ＤＤＣＩの“ストリッピングページ”インタフェースのスクリーンショットである。 “インポートＸＭＬファイル”オプションがドロップダウンメニューの形で選択されたデバイスドライバマネージャのスクリーンショットである。

図１は、プラグアンドプレイ医療装置環境でデバイスドライバのために用いられるコードの量の最小化を容易にするユニバーサル医療デバイスドライバアダプタ（ＵＭＤＡＡ）システム又はフレームワーク１０を示している。そのシステム１０は、種々の専用（特定のベンダーの）プロトコルを用いて、人工呼吸器、麻酔装置及び注入ポンプ等の医療装置から医療装置メトリック又はパラメータを検索することができるオブジェクト指向の設定可能フレームワークを有し、それらのメトリックを正規化されたデータ表現に変換する医療データ情報ベース（例えば、データベース）（ＭＤＩＢ）を有する。外部のアプリケーションは、メトリックを１１０７３（医療データ情報言語、即ち“ＭＤＩＬ”）及びＨＬ７プロトコルを含むプロトコルに変換する目的で、インタフェースを介して正規化されたデータにアクセスすることができるが、それらに限定されるものではない。

ＵＭＤＤＡ１０は、医療装置毎に適切な拡張可能マークアップ言語（ＸＭＬ）設定ファイルを選択することによりドライブが生成されるようになっている医療装置の型／モデルに従って、フレームワーク構成要素を動的に構成する装置スーパーバイザ構成要素１４を有する。例えば、装置スーパーバイザ構成要素１４は、プラグアンドプレイイベントを“聞き”、特定の装置と通信するように適切なＸＭＬファイルを動的に選択するように設定されることが可能である。特定の装置モデルと共に用いるためのポートマネージャ１６、通信マネージャ１８、パーサ２０及びデータプロバイダ２２を設定することは、装置スーパーバイザモデルのジョブである。ポートマネージャ、通信マネージャ、パーサ及びデータプロバイダは、オープンシステム相互運用性（ＯＳＩ）のレイヤをカプセル化し、フル医療デバイスドライバ機能を提供する目的で相互運用する。

ポートマネージャ１６は、通信スタックの物理レイヤ及びデータリンクレイヤを管理する。例えば、このレイヤは、ボーレート、ストップビット及びパリティ等のシリアルポート設定を構成するように用いられる。通信マネージャ１８は、トランスポートレイヤ及びセッションレイヤを制御する。その通信マネージャは、非同期及び同期通信、メッセージセグメント化及びデータ要求を管理する。パーサ２０は、プレゼンテーションレイヤを管理し、装置から受信された生データを正規化されたパラメータＩＤ／値の対に変換する。“固定バッファ”パーサ、及び異なる種類の“タグ付きデータパーサ”等のパーサレイヤにおいて実施される複数のパターンが存在する。このレイヤはまた、新しいデータフォーマットがサポートされる必要がある場合に、拡張可能である。

データプロバイダ２２は、外部のアプリケーションに対して利用可能であるサーバのセットに基づいて、正規化された医療装置データを管理し、その医療装置データにアクセスし、ある場合には、その医療装置データを変換する。データプロバイダの外部インタフェースは、医療装置から得られたメトリックにアクセスする。各々のメトリックは、一意の識別子によりタグ付けされ、ソース装置、例えば、測定ユニットにより与えられるメタデータも有する。

ＭＤＩＢ１２は、ドライバ毎（又は、装置タイプ毎）に発行されるマニフェストデータを取得する複数のモノリシックドライバ実装２４及びデコレータ２６（例えば、ＭＤＩＬＩＺＥＲ）を更に有し、データプロバイダ２２のデータをマニフェストデータと組み合わせ、それをマニフェストデータで飾り付けることにより、ＭＤＩＢのサブツリーを構築する。

更に、そのシステムは、本明細書に記載している種々の方法及び動作を実行するためのコンピュータ実行可能命令を実行するプロセッサと、その命令を記憶するメモリとを有する。メモリ２８は、制御プログラムが記憶されるコンピュータ読み出し可能媒体であって、例えば、ディスク、ハードドライブ等であることが可能である。コンピュータ読み出し可能媒体の一般的な形式には、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、何れかの他の磁気記憶媒体、ＣＤ−ＲＯＭ、ＤＶＤ、何れかの他の光ディスク、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、それらの変形、他のメモリチップ又はカートリッジ、それからプロセッサが読み出して、実行できる何れかの他の有形媒体がある。このコンテキストにおいては、システム１０は、１つ又はそれ以上の汎用コンピュータ、プログラムドマイクロプロセッサ又はマイクロコントローラ、周辺集積回路素子、ＡＳＩＣ又は他の集積回路、ディジタル信号プロセッサ、配線で接続されたエレクトロニクス、ディスクリート素子回路等の論理回路、ＰＬＤ、ＰＬＡ、ＦＰＧＡ、グラフィカルカードＣＰＵ（ＧＰＵ）又はＰＡＬ等のプログラマブル論理装置等において実施されることが、若しくはそれらの１つ又はそれ以上として実施されることが可能である。

図２は、ＥＣ−１０コードベース、関連ドライバ及びデバイスドライバフレームワークを使用する医療データ取得装置（ＭＤＡＤ）５０を示している。ＭＤＡＤが、図１のＵＭＤＤＡの任意の又はすべての構成要素に結合されることが可能であること、若しくはそれらの構成要素を有することが可能であることが理解できる。ＭＤＡＤは、患者モニタ５２に、及びそれぞれの識別モジュール５６を介する複数の医療装置５４に、結合される。一実施形態においては、識別モジュールはＥＣ−５タイプのモジュールである一方、ＭＤＡＤはＥＣ４０／８０タイプの装置である。患者モニタ５２は、装置ポート６０を有するＥＣ−１０ ＢＢＮ５８に結合され、ＥＣ−４０／８０ ＭＤＡＤに患者モニタを接続するパススルー接続としての役割を果たす。ＭＤＡＤは、ＥＣ１０プロトコル及びＥＣ４０／８０プロトコルを用いて実行可能であるコンピュータ実行可能命令を有する共通コードモジュール６１を有する。共通コードモジュールは、ベッドサイドホストインタフェース６２、ウェブサーバ６４、並びに、ベーシックＩドライバ、ベーシックＭドライバ及び強化されたドライバを有するドライバフレームワーク６６（図１のシステムと類似する又はそれと同じであることが可能である）を有する。ＭＤＡＤは、プラグアンドプレイ構成要素（例えば、１つ又はそれ以上のＥＣ−５構成要素）６８、ＭＤＩＢ１２（図１）、１つ又はそれ以上のＭＤＩＬスキャナリポート７０、システムログ７２及びＬＩＮＵＸ（登録商標）／基板支持パッケージ７４を更に有する。更に、ＭＤＡＤは、ＩＣＩＰホストインタフェース７６と、複数の装置ポート７８（例えば、ＥＣ８０のためには最大８つ）とを有する。

一実施形態においては、ＭＤＡＤは、健康レベル７（ＨＬ７）通信プロトコルをサポートする病院情報システムに存在する。ＥＣ１０通信プロトコルは、ＭＤＩＬフォーマットでモニタ５２における表示のためにデータを供給する一方、ＥＣ４０／８０通信プロトコルは、ＨＬ７フォーマットでレンダリングするためにＨＩＳに同じデータを送る。従って、各々の医療装置のためにモノリシック実行ファイルをロードする代わりに、ＭＤＡＤは、各々の装置と通信するために各々の装置と互換性のあるＸＭＬデバイスドライバファイル（例えば、図１のメモリ２８等のコンピュータ読み出し可能媒体に記憶されている）を見つけ、それからデータを受け取り、ＭＤＩＢ１２にそのデータを記憶する。

他の実施形態に従って、プラグアンドプレイドライバ６８は、装置５４から医療データを得、受け取ったデータをＭＤＩＬフォーマットに変換し、それをＭＤＩＢに記憶する、ＭＤＡＤ又は“ハブ”で実行する。ＩＣＩＰホスト７６は、ＭＤＩＬデータをＨＬ７フォーマットに変換し、ＨＬ７データをＨＩＳに出力する。

図３は、ドライバディベロッパが専用プロトコルを用いて通信するようにフレームワークのために必要な情報を入力する、図１のＵＭＤＤＡシステム及び図２のＭＤＡＤ５０と関連して用いるためのデバイスドライバマネージャ（ＤＤＭ）ツール９０（本明細書ではドライバディベロッパツールとも呼ばれる）を示している。ＤＤＭツールは、医療装置の通信能力ばかりでなく、その装置が供給することができるデータのモデルを実行するＸＭＬファイル９２を生成する。プログラミング技術は、ＸＭＬファイルを生成するためには必要ない。ＸＭＬファイル９２は、フレームワーク６６（図２）を構成するために用いられ、故に、そのフレームワークは、医療装置によりサポートされるプロトコルに“適応する”。

複数の医療デバイスドライバを分析した後、繰り返しパターンがドライバソフトウェアにおいて観察され得る。ドライバ設計時間及び努力をかなり低減し、コード再使用を最大化する種々の設計パターンが見つけ出され得る。オブジェクトモデルが、デザインパターンに基づいて生成される。異なるメッセージパーサパターンが、例えば、医療装置に対するデータ要求から装置パラメータを抽出するように、見つけ出される。例としては、“固定長バッファパーサ”及び“可変長タグ付きバッファパーサ”がある。

ＤＤＭツール９０は、集中化リレーショナルデータベース９４にドライバ構成（例えば、ＸＭＬファイル）を記憶する。ユーザは、アクティブなデバイスドライバ（ＡＤＤ）リスト９６から装置を選択し、“Ｇｅｎｅｒａｔｅ ＸＭＬ”ボタン９８をクリックする。システムは、ＸＭＬファイル９２並びにｍｅｄｉｃａｌ．ｘｍｌファイル及び他の既存のｘｍｌファイルを有するデバイスドライバを生成する。ＤＤＭツールは、それが生成された装置に及びデバイスポートモジュール７８にそのドライバを配備する。

図４は、本明細書に記載している種々の特徴に従った、ＤＤＭツール９０のスクリーンショットを示している。ＤＤＭツールは、デバイスドライバを捕捉し、図３の関連データベース９４等の構造化クエリ言語（ＳＱＬ）データベースにＸＭＬファイルとしてドライバ開発中にそれらのデバイスドライバを記憶する。一旦、ＸＭＬデバイスドライバファイル９２が十分に開発されると、それらのファイルは、後の呼び出し及び使用のために、図１のメモリ等のコンピュータ読み出し可能媒体に記憶される。ＤＤＭツールは、ユーザが“ビュードライバ”機能、“編集ドライバ”機能、“新しいドライバ”機能、“削除ドライバ”機能及び“終了”機能を選択することを可能にする、クリック可能“ファイル”タグ１２０を有する。ドライバを削除する機能は、データベースからドライバを削除し、ユーザは、削除コマンドの実行の前に１つ又はそれ以上の警告が与えられる。終了機能はプログラムを終了する。

ＤＤＭツールは更に、ＵＭＤＤＡ ＸＭＬファイルスキーマに適合する第三者デバイスドライバをユーザがインポートすることを可能にする“Ｇｅｎｅｒａｔｅ ＸＭＬ”機能、“Ｂｕｌｋ Ｇｅｎｅｒａｔｅ ＸＭＬ”機能及び“Ｉｍｐｏｒｔ ＸＭＬ”機能をユーザが呼び出すことを可能にするクリック可能“Ｐｕｂｌｉｓｈ”タグ１２０を有する。また、選択されたときに、リストボックス１２６においてデバイスドライバを決定する“Ｄｉｓｐｌａｙ Ｍｏｄｅ”タグ１２４が示される。リストボックス１２６は、“すべてのデバイスドライバ”（例えば、アクティブ及びインアクティブデバイスドライバ）、“アクティブデバイスドライバ”、“インアクティブデバイスドライバ”等の選択された表示モードに従って、デバイスドライバを表示する。

“Ｖｉｅｗ”ボタン１２８は、デバイスドライバにおける特性のすべてをユーザが見ることを可能にする。Ｖｉｅｗボタンの選択は、“Ｆｉｌｅ”タブ１２０の下で“ビュードライバ”を選択するのと同じ機能を実行する。そのドライバへの変更は、“Ｖｉｅｗ”機能を用いてなされるときには、保存されない。“Ｅｄｉｔ”ボタン１３０は、リストボックスにおいて選択されたデバイスドライバの特性をユーザが編集することを可能にする。そのドライバへの変更は、ユーザが“ＯＫ”ボタン（図示せず）によりエディタを抜け出るときに、データベースに記憶される。Ｅｄｉｔボタンの選択は、ファイルタグの下で“ドライバ編集”機能の選択と同じ機能を実行する。“Ｎｅｗ”ボタン１３２は、新しいデバイスドライバを生成する処理をユーザが開始することを可能にする。デバイスドライバは、ユーザが“ＯＫ”ボタン（図示せず）により特性エディタを抜け出るときに、データベースに記憶される。Ｎｅｗボタンの選択は、ファイルタブの下で“新しいドライバ”機能を選択するのと同じ機能を実行する。

“Ｇｅｎｅｒａｔｅ ＸＭＬ”ボタン１３４は、リストボックスにおいて選択された装置のためのＸＭＬファイルをユーザが作成することを可能にする。一実施形態においては、ＸＭＬファイルは、リストボックスにおいてデバイスドライバの後に名付けられ、Ｃ：＼ＩｎｔｅｌｌｉＢｒｉｄｇｅ＼ＤｅｖｉｃｅＤｒｉｖｅｒｓに記憶される。インアクティブデバイスドライバが選択される場合、メッセージボックスが表示され、ファイルは作成されない。ＸＭＬ作成ボタンは、表示モードが“インアクティブデバイスドライバ”である場合には、アクティブでない。

“Ｂｕｌｋ Ｇｅｎｅｒａｔｅ ＸＭＬ”ボタン１３６は、リストボックスにおけるすべてのデバイスドライバを介してルーピングする機能を実行する。一実施形態においては、ＸＭＬファイルは、Ｃ：＼ＩｎｔｅｌｌｉＢｒｉｄｇｅ＼ＤｅｖｉｃｅＤｒｉｖｅｒｓに記憶される。この機能は既存のファイルを上書きする。デバイスドライバがアクティブな場合、その機能はスキップされる。ＸＭＬバルク作成ボタンは、表示モードが“インアクティブデバイスドライバ”である場合には、アクティブである。

図５は、本明細書で記載している１つ又はそれ以上の特徴に従ったデバイスドライバ構成インタフェース（ＤＤＣＩ）１５０の“Ｐｒｏｐｅｒｔｉｅｓ”ページを示している。“Ｄｒｉｖｅｒ Ｎａｍｅ”テキストボックス１５２は、ユーザがデバイスドライバの名前を編集することを可能にする。一実施形態においては、その名前は、ＥＣ５プロトコルにより用いられる名前と適合し、ＸＭＬドライバファイル（例えば、Ｂｒａｕｎ ＦＭ．ｘｍｌ）を作成するときにも用いられる。“Ｂａｕｄ Ｒａｔｅ”コンボボックス１５４は、ドライバが通信のために用いるボーレートをユーザが設定することを可能にする。このボーレートは、ドライバが生成された装置のボーレートに適合する。一実施形態においては、ボーレートは、約３００乃至１１５２００ｂｐｓの範囲内にある。

“Ｄａｔａ Ｂｉｔｓ”コンボボックス１５６は、装置により送信されるようになっているデータビットの数をユーザが設定することを可能にする。一実施形態においては、データビット範囲は、最も一般的な値である５乃至８である。“Ｐａｒｉｔｙ”コンボボックス１５８は、通信中に用いられるようになっているパリティチェックをユーザが設定することを可能にする。一実施形態においては、値は無、偶数又は奇数であり、選択される値は装置特定（ｄｅｖｉｃｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ）に適合する。

“Ｓｔｏｐ Ｂｉｔｓ”コンボボックス１６０は、通信のために用いられるストップビット数をユーザが設定することを可能にする。一実施形態においては、値は、０、１、１．５、２であることが可能であり、選択される値は装置特定に適合する。“Ｂｕｆｆｅｒ Ｓｉｚｅ”テキストボックス１６２は、入来メッセージを保持するのに利用可能であるバイト数を表す数を有する。一実施形態においては、この値は、最大予測メッセージより少なくとも２０％大きい。“Ｔｉｍｅ Ｏｕｔ”テキストボックス１６４は、入来メッセージを識別する／処理するために割り当てられたミリ秒数を表す値を有する。“Ｄａｔａ Ｓｔｙｌｅ”コンボボックス１６６は、生データメッセージを送るときに、装置によってユーザがフォーマットを選択することを可能にする。一実施形態においては、値は、小さいエンディアン、大きいエンディアン、ニブルリバース及びユーザが規定するものである。“Ｕｓｅｒ−ｄｅｆｉｎｅｄ”はプレースホルダであり、サポートされていないデータスタイルを表す。

“Ａｃｔｉｖｅ Ｄｒｉｖｅｒ”チェックボックス１６８は、ユーザがドライバを有効にする又は無効にすることを可能にする。ドライバが無効にされる場合、ドライバのためのＸＭＬファイルは生成されない。“ＯＫ”ボタン１７０は、ユーザがエディタを抜け出して、変更を保存することを可能にする。抜け出す時点で、変更がＳＱＬデータベースに保存される。ユーザが“Ｖｉｅｗ”変更を介して入力した場合、変更は保存されない。“Ｃａｎｃｅｌ”ボタン１７２は、ユーザがエディタを抜け出し、すべての変更を破棄することを可能にする。

図６は、本明細書に記載している１つ又はそれ以上の特徴に従った、ＤＤＣＩ１５０の“Ｍｅｓｓａｇｅｓ”ページを示している。メッセージリストボックス１９０は、装置により処理されるメッセージを表示する。選択されたメッセージの特徴が下方に表示されている。“Ｎｅｗ Ｍｅｓｓａｇｅ”ボタン１９４は、ユーザがデバイスドライバに新しいメッセージを追加することを可能にする。“Ｄｅｌｅｔｅ Ｍｅｓｓａｇｅ”ボタン１９４は、ユーザがあるメッセージ及びそのメッセージの関連する部分のすべてを削除することを可能にする。“Ｍｅｓｓａｇｅ Ｎａｍｅ”テキストボックス１９６は、メッセージを記述するように用いられる内部名である。

“Ｍｅｓｓａｇｅ Ｔｙｐｅ”コンボボックス１９８は、処理されるようになっているメッセージのタイプをユーザが設定することを可能にする。メッセージタイプ規定及び予測使用は、装置との通信を確立するために用いられる“Ｉｎｉｔ”（初期化）メッセージを有する。“Ｄａｔａ Ｍｅｓｓａｇｅ Ｗｉｔｈ Ｎｏ Ｒｅｓｐｏｎｓｅ”メッセージは、応答メッセージを必要としない受け取られるデータメッセージである。“Ｄａｔａ Ｍｅｓｓａｇｅ Ｗｉｔｈ Ｒｅｓｐｏｎｓｅ”メッセージは、応答メッセージを必要とする受け取られるデータメッセージである。“Ｋｅｅｐ Ａｌｉｖｅ”又は“Ｈｅａｒｔｂｅａｔ”メッセージは、通信をアライブ状態に保つように、装置に送られるメッセージである。“ＡＣＫ”（確認）メッセージは、装置からの要求に基づいて装置に送られるメッセージである。“Ｑｕｉｔ”メッセージは、データを送る場合に、ストップさせるように装置に送られるメッセージである。“Ｏｎｅ Ｔｉｍｅ Ｄａｔａ Ｒｅｑｕｅｓｔ”メッセージは、装置が連続的にデータを送るようにする、装置に送られる要求である。他のタイプのメッセージには、“Ｓｕｂ−ｍｅｓｓａｇｅ Ｗｉｔｈ ｎｏ Ｒｅｓｐｏｎｓｅ”メッセージ、“Ｓｕｂ−ｍｅｓｓａｇｅ Ｗｉｔｈ Ｒｅｓｐｏｎｓｅ”メッセージ、アラームメッセージ等がある。

“Ｍｅｓｓａｇｅ Ｆｏｒｍａｔ”コンボボックス２００は、メッセージ長の決定で用いられる方法をユーザが設定することを可能にする。固定長はメッセージの長さが一定であることを示し、その長さはメッセージ長テキストボックスに入力される。可変長メッセージは、その長さが変化し、開始トークン及び終了トークンが、メッセージ長を決定するために必要であることを示す。“Ｌｅｎｇｔｈ Ｉｎ Ｍｅｓｓａｇｅ”は、メッセージの長さが変化可能であり、メッセージにおける正確なバイト数がそのメッセージに含まれることを示す。このメッセージは、開始トークン及び終了トークンを有し、その長さがメッセージにおいて求められる場所を示すメッセージパラメータを有することが可能である。

“Ｄｅｌａｙ”テキストボックス２０２は、要求メッセージを再送する前に、経過する必要があるミリ秒数を表す値が与えられる。“Ｍａｘ Ｒｅｑｕｅｓｔ Ｔｒｉｅｓ”テキストボックス２０４は、遅延に拘わらず装置に強制される場合に、要求の前に実行される要求試みの数を表す値を有する。“Ｍｅｓｓａｇｅ Ｌｅｎｇｔｈ”テキストボックス２０６は、メッセージ探索処理が開始する前に読み込まれるバイト数を表す値を示す。メッセージ長テキストボックスは、代表的なメッセージ長の約１０％である値に設定されることが可能である。

“Ｔｏｋｅｎｓ”ボックス２０８は、データメッセージを特定するのに用いられるトークンを表示する。ユーザは、“Ｎｅｗ Ｔｏｋｅｎ”ボタンを用いてトークンを生成する、“Ｅｄｉｔ Ｔｏｋｅｎ”ボタン２１２を用いてトークンを編集する、又は“Ｄｅｌｅｔｅ Ｔｏｋｅｎ”ボタン２１４を用いてトークンを削除する能力が与えられる。一実施形態においては、トークンは、例えば、＜ＳＯＨ＞．．．．．＜ＥＯＴ＞（０ｘ０１．．．．．０ｘ０４）等の１６進値として表示される。

“Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ”ボタン２１６は、ユーザが関連要求を見て、編集することを可能にする。“Ｒｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅ”ボタン２１８は、ユーザが関連応答を見て、編集することを可能にする。“ＮＡＫ Ｒｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅ”ボタン２２０は、ユーザがＮＡＫ関連応答を見て、編集することを可能にする。“Ｃｈｅｃｋ Ｓｕｍ”ボタン２２２は、ユーザが、メッセージに関連するチェックサムを見て、編集することを可能にする。チェックサムは、メッセージが正しく受信されたかどうかを判定するように用いられる。“Ｔｉｍｅ Ｓｔａｍｐ”ボタン２２４は、ユーザが、メッセージに関連するタイムスタンプを見て、編集することを可能にする。

図７は、本明細書に記載されている種々の特徴に従って、メッセージを特定するのに用いられるトークンの生成及び編集を容易化するトークン特定エディタ（ＴＳＥ）２４０を示している。ＴＳＥは、ユーザがトークンタイプを設定することを可能にする“Ｔｏｋｅｎ Ｔｙｐｅ”コンボフィールド２４２を示している。一実施形態においては、トークンタイプは、“Ｆｉｒｓｔ Ｔｏｋｅｎ”、“Ｍｅｓｓａｇｅ Ｔｏｋｅｎ”及び“Ｅｎｄ Ｔｏｋｅｎ”を有する。“Ｆｉｒｓｔ Ｔｏｋｅｎ”は、メッセージにおいて見つけられる最初のトークンであり、メッセージにおける本当に最初のバイトであることが可能である。メッセージには１つのみの最初のトークンが存在する。“Ｍｅｓｓａｇｅ Ｔｏｋｅｎ”は、メッセージにおいて見つけられる任意のトークンである。“Ｅｎｄ Ｔｏｋｅｎ”は、メッセージの終了を特定するのに用いられ、メッセージの終了で見つけ出され得る。“Ｅｎｄ Ｔｏｋｅｎ”は可変長メッセージのために用いられる。

“Ｔｏｋｅｎ Ｏｆｆｓｅｔ”テキストフィールド２４４は、メッセージにおけるトークンの位置を示すように用いられる。オフセット値は、メッセージの開始から数えられる。終了のトークン又は最初のトークンは、オフセット値０を有する。“Ｔｏｋｅｎ Ｓｔｒｉｎｇ”テキストボックス２４６は、ユーザが１６進フォーマットでトークンを入力し、編集することを可能にする。トークンは、常に同じ位置のメッセージにある文字（ｃｈａｒａｃｔｅｒｓ）である
図８は、本明細書に記載している１つ又はそれ以上の特徴に従って、１６進フォーマットで要求又は応答メッセージをユーザが編集することを可能にする“Ｍｅｓｓａｇｅ Ｖｉｅｗｅｒ”インタフェース２６０を示している。ユーザは、メッセージに対する変更を終了して、保存するように、“ＯＫ”ボタン１７２を選択することが可能であり、又は、変更を保存することなく、終了するように、“Ｃａｎｃｅｌ”ボタン１７２を選択することが可能である。

図９は、“ＣｈｅｃｋＳｕｍ”ページ又はインタフェース２７０を示している。チェックサムは、メッセージにおいてバイト数に適用される算術演算である。その開始及び終了は、チェックサムの演算に含まれる。算術演算は、“ＣｈｅｃｋＳｕｍ Ｔｙｐｅ”により決定される。メッセージがチェックサムを有さない場合には、チェックサムは生成される必要がないことに留意されたい。“ＣｈｅｃｋＳｕｍ Ｔｙｐｅ”コンボボックス２７２は、チェックサム値を演算するために用いられる方法をユーザが選択することを可能にする。チェックサム値“Ｎｏｎｅ”はチェックサムがないことを示す。“ＢｙｔｅＳｕｍ”は、メッセージにおけるバイトの合計を示す。“Ｔｗｏｓ Ｃｏｍｐｌｅｍｅｎｔ”は、２つについての補間技術を用いて、文字（ｃｈａｒａｃｔｅｒｓ）の合計を示す。“ＣＲＣ”は巡回冗長検査を表す。“Ｍｏｄｕｌｏ ２５６”は、モジュロ２５６加算を用いる文字の合計を示す。“Ｕｓｅｒ Ｄｅｆｉｎｅｄ”は、プレースホルダとしての役割を果たし、サポートされていないチェックサムタイプが存在することを示す。

“ＣｈｅｃｋＳｕｍ Ｌｏｃａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ”コンボボックス２７４は、データメッセージにおいて検査合計値を見つけることで用いられる開始点をユーザが選択することを可能にする。このフィールドにおける“Ｆｒｏｍ Ｂｅｇｉｎｎｉｎｇ Ｏｆ Ｍｅｓｓａｇｅ”は、オフセットバイトがメッセージのチェックサム値における最初のバイトから数えられることを示す。このフィールドにおける“Ｂｅｆｏｒｅ Ｅｎｄ Ｏｆ Ｍｅｓｓａｇｅ”は、オフセットバイトがメッセージにおける最後のバイトから逆に数えられることを示す。

“ＣｈｅｃｋＳｕｍ Ｏｆｆｓｅｔ”テキストボックス２７６は、メッセージのチェックサム値において最初のバイトを位置付けるように、メッセージの開始から数えられる又はメッセージの最後から逆に数えられるバイト数を示す値を有する。“ＣｈｅｃｋＳｕｍ Ｌｅｎｇｔｈ”ボックス２７８は、チェックサム値におけるバイト数を表す値を有する。この値は、長さが１バイト又は２バイトであることが可能である。

“Ｓｔａｒｔ Ｐｏｉｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ”コンボボックス２８０は、チェックサムの演算で用いられる開始バイトを表す値を有する。このフィールドにおける“Ｆｒｏｍ Ｂｅｇｉｎｎｉｎｇ Ｏｆ Ｍｅｓｓａｇｅ”は、オフセットバイトがメッセージにおける最初のバイトから数えられることを示す。このフィールドにおける“Ｂｅｆｏｒｅ Ｅｎｄ Ｏｆ Ｍｅｓｓａｇｅ”は、オフセットバイトがメッセージにおける最後のバイトから逆に数えられることを示す。

“Ｓｔａｒｔ Ｐｏｉｎｔ Ｏｆｆｓｅｔ”テキストボックス２８２は、メッセージにおいて開始バイトを位置付けるように、メッセージの開始から数えられる又はメッセージの終了から逆に数えられるバイト数を示す値を有する。

“Ｅｎｄ Ｐｏｉｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ”コンボボックス２８４は、チェックサムの演算で用いられる最終バイトを注目させるように用いられる。このフィールドにおける“Ｆｒｏｍ Ｂｅｇｉｎｎｉｎｇ Ｏｆ Ｍｅｓｓａｇｅ”は、オフセットバイトがメッセージにおける最初のバイトから数えられることを示す。このフィールドにおける“Ｂｅｆｏｒｅ Ｅｎｄ Ｏｆ Ｍｅｓｓａｇｅ”は、オフセットバイトがメッセージにおける最後のバイトから逆に数えられることを示す。

“Ｅｎｄ Ｐｏｉｎｔ Ｏｆｆｓｅｔ”テキストボックスは、メッセージにおいて終了バイトを位置付けるように、メッセージの開始から数えられる又はメッセージの終了から逆に数えられるバイト数を表す値を示す。“Ｎｅｗ／Ｄｅｌｅｔｅ”ボタン２８６は、ユーザがメッセージに関連するチェックサムを生成する又は削除することを可能にする。“ＯＫ”ボタン１７０は、ユーザが変化を終了して、保存することを可能にする。“Ｃａｎｃｅｌ”ボタン１７２は、ユーザが任意の変化を保存することなく終了することを可能にする。

図１０は、“Ｔｉｍｅ Ｓｔａｍｐ”ページ又はインタフェース３００を示す。“Ｔｉｍｅ Ｓｔａｍｐ Ｔｙｐｅ”コンボボックス３０２は、ユーザが実行しているタイムスタンプのタイプをユーザが選択することを可能にする。このボックスにおける“Ｍｅｓｓａｇｅ Ｔｉｍｅ Ｓｔａｍｐ”は、メッセージが古いかどうかを判定するように用いられる。このボックスにおける“Ｐａｒａｍｅｔｅｒ Ｔｉｍｅ Ｓｔａｍｐ”は、メッセージにおける生理値が古いかどうかを判定するように用いられる。“Ｔｉｍｅ Ｓｔａｍｐ Ｔｏｋｅｎ”フィールド３０４は、メッセージにおけるタイムスタンプの位置を特定するのに用いられる。Ｔｉｍｅ Ｓｔａｍｐ Ｔｏｋｅｎは、何れかのタイプのタイムスタンプについてオプションである。“Ｔｏｋｅｎ Ｔｙｐｅ”コンボボックス３０６は、ユーザがトークンタイプを設定することを可能にする。“Ｔｏｋｅｎ Ｏｆｆｓｅｔ”テキストボックス３０８は、トークンがメッセージにおいてどこに位置しているかを示すように用いられる。オフセット値は、メッセージの始めから数えられる。“Ｔｏｋｅｎ Ｓｔｒｉｎｇ”テキストボックス３１０は、ユーザが１６進フォーマットでトークンを入力して、編集することを可能にする。

“Ｔｉｍｅ Ｓｔａｍｐ Ｄａｔａ Ｆｏｒｍａｔ”フィールド３１２は、メッセージにおけるタイムスタンプを解釈するように用いられる。“Ｄａｔａ Ｌｏｃａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ”コンボボックス３１４は、メッセージにおいてタイムスタンプを見つけ出すのに用いられる方法をユーザが選択することを可能にする。このボックスにおける“Ｂｅｇｉｎｎｉｎｇ Ｏｆ Ｍｅｓｓａｇｅ”は、オフセットがメッセージにおける最初のバイトから数えられることを示し、タイムスタンプトークンを必要としない。このボックスにおける“Ａｆｔｅｒ Ｐａｒａｍｅｔｅｒ Ｉｄｅｎｔｉｆｉｅｒ”は、オフセット計数がタイムスタンプトークンにおける最初のバイトの位置からのものであることを示す。このボックスにおける“Ｂｅｆｏｒｅ Ｐａｒａｍｅｔｅｒ Ｉｄｅｎｔｉｆｉｅｒ”は、オフセット計数がタイムスタンプトークンにおける最初のバイトの位置から逆のものであることを示す。

“Ｄａｔａ Ｓｔｙｌｅ”コンボボックス３１６は、タイムスタンプ値を解釈するための処理を決定する。殆どの場合、２値を用いることが可能である。データスタイル機能は、タイムスタンプ値が変化したかどうかを判定するようにメモリ比較を実行する。“Ｄａｔａ Ｌｅｎｇｔｈ”ボックス３１８は、データを作るメッセージにおけるバイト数を示す。

図１１は、ＤＤＣＩ１５０の“Ｐａｒａｍｅｔｅｒｓ”ページを示す。“Ｃｕｒｒｅｎｔ Ｍｅｓｓａｇｅ”コンボボックス３３２は、どのパラメータが調査されるかについてのメッセージをユーザが選択することを可能にする。メッセージを選択することにより、メッセージに関連するパラメータを表示する“Ｃｕｒｒｅｎｔ Ｍｅｓｓａｇｅ Ｐａｒａｍｅｔｅｒｓ”リストボックス３３４がポピュレート（ｐｏｐｕｌａｔｅ）される。パラメータを選択することにより、パラメータ特性がポピュレートされる。“Ｎｅｗ Ｐａｒａｍｅｔｅｒ”ボタン３３６は、現在のメッセージに関連する新しいパラメータをユーザが生成することを可能にする。“Ｄｅｌｅｔｅ Ｐａｒａｍｅｔｅｒ”ボタン３３８は、ユーザが現在のメッセージからあるパラメータ及びそのパラメータの関連するアイテムすべてを削除することを可能にする。

“Ｐａｒａｍｅｔｅｒ Ｎａｍｅ”テキストボックス３４０は、ユーザがパラメータの内部名（ｉｎｔｅｒｎａｌ ｎａｍｅ）を編集することを可能にする。“Ｐａｒａｍｅｔｅｒ Ｔｙｐｅ”コンボボックス３４２は、ユーザがパラメータ対応付け方法を選択することを可能にする。この選択は、パラメータＩＤコンボボックス３４４において何がロードされるかを決定する。パラメータタイプ“Ｐｈｙｓｉｏ”は、パラメータが生理データ（例えば、心拍数、呼吸数、血中酸素飽和度等）を示す。他のパラメータタイプは“Ａｌｅｒｍ”パラメータである。“Ｍｅｓｓａｇｅ Ｌｅｎｇｔｈ”は、メッセージの長さを決定するように用いられるパラメータであり、長さ情報がメッセージに含まれる可変長メッセージに関して用いられることが可能である。

“Ｐａｒａｍｅｔｅｒ Ｄａｔａ Ｆｏｒｍａｔ”ボタン３４６は、ユーザがデータフォーマットを設定することを可能にするダイアログを示す。“Ｐａｒａｍｅｔｅｒ Ｔｏｋｅｎ Ｉｄｅｎｔｉｆｉｅｒ”ボタン３４８は、メッセージにおけるパラメータを識別するように用いられるトークンをユーザが設定することを可能にするダイアログを表示する。“Ａｄｊｕｓｔ Ｏｐｅｒａｔｉｏｎ”コンボボックス３５０は、生データ値に適用される算術演算をユーザが選択することを可能にする。“Ａｄｊｕｓｔ Ｖａｌｕｅ”テキストボックス３５２は、“Ａｄｊｕｓｔ”演算により用いられる値を示す。

“Ｕｎｉｔｓ Ｏｆ Ｍｅａｓｕｒｅ”ボックス３５４は、パラメータに関連する有効な単位のリストをユーザが作成することを可能にする。メッセージにおけるパラメータが、固定された測定の単位を有する場合、そのリストには１つの入力のみが存在する。“Ｃｈａｎｎｅｌｓ”ボックス３５６は、データがメッセージにおいて関連するサブ装置を識別するように用いられるチャネル識別子をユーザが生成する、編集する又は削除することを可能にする。“Ｔｉｍｅ Ｓｔａｍｐ”ボックス３５８は、ユーザがパラメータに関連するタイムスタンプを生成する、編集する又は削除することを可能にする。複数のタイムスタンプが、複数のチャネルが存在する場合に、用いられることが可能である。タイムスタンプは、任意の周期的データ要素（ＮＩＢＰ）に適用されることが可能である。連続的に測定されるデータ要素はタイムスタンプを必要としない。

図１２は、データフォーマットページ又はインタフェース３７０のスクリーンショットを示す。“Ｄａｔａ Ｌｏｃａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ”コンボボックス３７２は、メッセージにおいてタイムスタンプを見つけ出すのに用いられる方法をユーザが選択することを可能にする。オプションには、“Ｂｅｇｉｎｎｉｎｇ Ｏｆ Ｍｅｓｓａｇｅ”、“Ａｆｔｅｒ Ｐａｒａｍｅｔｅｒ Ｉｄｅｎｔｉｆｉｅｒ”及び“Ｂｅｆｏｒｅ Ｐａｒａｍｅｔｅｒ Ｉｄｅｎｔｉｆｉｅｒ”がある。“Ｄａｔａ Ｓｔｙｌｅ”コンボボックス３７４は、メッセージにおけるデータ値を解釈する処理を決定する。“Ａｓｃ Ｉｎｔ”は、その値がスタンダードＡＳＣＩＩフォーマットでの整数であること（例えば、１２３４＝０ｘ３１ ０ｘ３２ ０ｘ３３ ０ｘ３４）を示す。“Ａｓｃ Ｆｌｏａｔ”は、その値がスタンダードＡＳＣＩＩフォーマットでの浮動小数であること（１２３４．５＝０ｘ３１ ０ｘ３２ ０ｘ３３ ０ｘ３４ ０ｘ２Ｅ ０ｘ３５）を示す。“Ｂｉｎａｒｙ”は、その値がデータメッセージにおける２値フォーマットにあること（例えば、１２３４＝０ｘ０４ ０ｘＤ２）を示す。“Ｓｔｒｉｎｇ”は、データメッセージにおけるその値がテキストであって、ＡＳＣＩＩフォーマットにある（例えば、Ｆｏｒｍａｔ＝０ｘ４６ ０ｘ６Ｆ ０ｘ７２ ０ｘ６Ｄ ０ｘ６１ ０ｘ７４）ことを示す。“Ｕｓｅｒ ｄｅｆｉｎｅｄ”はプレースホルダであって、サポートされていないデータスタイルが存在することを示す。“Ｄａｔａ Ｌｅｎｇｔｈ”テキストボックス３７６は、データを作るメッセージにおけるバイト数を示す。“Ｄａｔａ Ｏｆｆｓｅｔ”テキストボックス３７８は、そのデータの位置に到達するように、数えられるバイト数を示す。

図１３は、トークン特定インタフェース３９０のスクリーンショットである。“Ｔｏｋｅｎ Ｔｙｐｅ”コンボボックス３９２は、ユーザがトークンタイプを設定することを可能にする。例えば、“Ｐａｒａｍｅｔｅｒ Ｔｏｋｅｎ”は、トークンについてのメッセージの探索を強制して、トークンがパラメータに対して一意であり、オフセットは０であることを示す。“Ｐａｒｓｅ Ｔｏｋｅｎ”は、メッセージを表現するように用いられるトークンを示す。オフセットは、データ値の前に存在するトークンの数である。

“Ｔｏｋｅｎ Ｏｆｆｓｅｔ”テキストボックス３９４は、トークンがメッセージにおいてどこに位置しているかを示すように用いられる。オフセット値は、メッセージの始めから数えられる。値０は、メッセージの探索を強制する。“Ｔｏｋｅｎ Ｓｔｒｉｎｇ”テキストボックス３９６は、ユーザが１６進フォーマットでトークンを入力して、編集することを可能にする。トークンは、メッセージに含まれる一意の文字列である。

図１４は、“Ｕｎｉｔ ｏｆ Ｍｅａｓｕｒｅ”インタフェースのスクリーンショットである。“Ｕｎｉｔ ｏｆ Ｍｅａｓｕｒｅ”コンボボックス４１２は、測定の単位をユーザが選択することを可能にする。“Ｉｓ Ｄｅｆａｕｌｔ Ｕｎｉｔ Ｏｆ Ｍｅａｓｕｒｅ”ボックス４１４は、選択された測定の単位が単に表示されたパラメータについての測定の単位であることをユーザが示すことを可能にする。“Ｔｏｋｅｎ Ｔｙｐｅ”コンボボックス４１６は、ユーザがトークンタイプを設定することを可能にする。“Ｔｏｋｅｎ Ｏｆｆｓｅｔ”ボックス４１８は、トークンがメッセージにおいてどこに位置しているかを示すように用いられる。メッセージがパラメータ識別子を伴わない固定長を有する場合、そのオフセットは、メッセージの始めからのバイト数である。固定長のメッセージにおいてパラメータ識別子が存在する場合、設定されたオフセットは、パラメータ識別子からのバイト数である。メッセージが可変長を有する場合、そのオフセットは、トークンについてのパラメータ識別子を超えて調べる必要がある最大バイト数である。

“Ｔｏｋｅｎ Ｓｔｒｉｎｇ”テキストボックス４２０は、１６進フォーマットでユーザがトークンを入力して、編集することを可能にする。“Ｎｅｗ／Ｄｅｌｅｔｅ”ボタン４２２は、ユーザが測定の単位を特定するためのトークンを生成する又は削除することを可能にする。

図１５は、チャネル特定インタフェース４３０のスクリーンショットである。“Ｃｈａｎｎｅｌ Ｓｐｅｃ Ｓｔｒｉｎｇ”テキストボックス４３２は、パラメータが属すパラメータチャネル又はサブ装置を特定するのに用いられる列を有する。“Ｄａｔａ Ｌｏｃａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ”コンボボックス４３４は、メッセージにおいてタイムスタンプを見つけるのに用いられる方法をユーザが選択することを可能にする。データ位置オプションには、“Ｂｅｇｉｎｎｉｎｇ Ｏｆ Ｍｅｓｓａｇｅ”（メッセージの始め）、“Ａｆｔｅｒ Ｐａｒａｍｅｔｅｒ Ｉｄｅｎｔｉｆｉｅｒ”（パラメータ識別子後）及び“Ｂｅｆｏｒｅ Ｐａｒａｍｅｔｅｒ Ｉｄｅｎｔｉｆｉｅｒ”（パラメータ識別子前）がある。“Ｄａｔａ Ｓｔｙｌｅ”テキストボックス４３６は、その値を解釈するための処理を決定する。殆どの場合、２値が用いられる。
“Ｎｅｗ／Ｄｅｌｅｔｅ”ボタン４３８は、ユーザがチャネル特定に関連するデータフォーマットを生成する又は削除することを可能にする。

図１６は、タイムスタンプインタフェース４５０のスクリーンショットを示す。“Ｔｉｍｅ Ｓｔａｍｐ Ｔｙｐｅ”コンボボックス４５２は、ユーザが実行されるタイムスタンプのタイプを選択することを可能にする。“Ｐａｒａｍｅｔｅｒ Ｔｉｍｅ Ｓｔａｍｐ”は、メッセージにおける生理値が古いかどうかを判定するように用いられる。“Ｃｈａｎｎｅｌ”コンボボックス４５４は、タイムスタンプが関連するチャネルをユーザが選択することを可能にする。“Ｔｉｍｅ Ｓｔａｍｐ Ｔｏｋｅｎ”フィールド４５６は、メッセージにおけるタイムスタンプの位置を特定するのに用いられる。タイムスタンプトークンは、何れかのタイプのタイムスタンプのオプションである。“Ｔｏｋｅｎ Ｔｙｐｅ”コンボボックス４５８は、ユーザがトークンタイプを設定することを可能にする。“Ｔｏｋｅｎ Ｏｆｆｓｅｔ”テキストボックス４６０は、メッセージ内のトークンの位置を示すように用いられる値を有する。そのオフセット値は、パラメータ識別子の始めから数えられる。“Ｔｏｋｅｎ Ｓｔｒｉｎｇ”テキストボックス４６２は、ユーザが１６進フォーマットでトークンを入力して、編集することを可能にする。

図１７は、ＤＤＣＩ１５０の“Ｓｔｒｉｐｐｉｎｇ”ページのスクリーンショットである。“Ｓｔｒｉｐｐｉｎｇ Ｅｌｅｍｅｎｔ”ボックス４７０は、メッセージを送る時点でそのメッセージにおいて交換されるバイトをリストアップする。“Ｎｅｗ”ボタン４７２は、ユーザが新しいストリッピング特定アイテムを生成することを可能にする。“Ｄｅｌｅｔｅ”ボタン４７４は、ユーザが新しいストリッピング特定アイテムを削除することを可能にする。“Ｄｅｓｃｒｉｐｔｏｒ”テキストボックス４７６は、バイト及びバイトの使用を記述するように用いられる内部テキストを示す。“Ｏｌｄ Ｂｙｔｅｓ”テキストボックス４７８は、メッセージを送る時点で正常なバイトのためのメッセージに対して交換されるバイトを示している。“Ｎｅｗ Ｂｙｔｅｓ”テキストボックス４８０は、生データメッセージにおける古いバイトを置き換えるように用いられるバイトを示す。それらは、メッセージが解析される前に置き換えられる必要がある。そのバイトは１６進フォーマットで表される。

図１８は、“Ｉｍｐｏｒｔ ＸＭＬ Ｆｉｌｅ”オプションがドロップダウンメニューから選択されたデバイスドライバマネージャ９０のスクリーンショットである。“Ｉｍｐｏｒｔ ＸＭＬ Ｆｉｌｅ”機能は、第三者により生成されていて、デバイスドライバのマスターデータベースにデバイスドライバを追加するデバイスドライバをユーザがインポートすることを可能にする。ユーザには、ユーザがインポートしたいドライバをユーザが選択することが可能である、開いているファイルダイアログ４９２が提示される。ドライバをインポートするとき、ユーザは、編集ツールにおいてドライバを再調査する又はデータベースにそのドライバを直接インポートするオプションが与えられる。インポートする前にドライバを再調査する場合、ドライバは、ユーザが再調査するためのエディタにロードされる。ユーザがキャンセルを介してエディタを終了する場合、ドライバは、データベースに保存されない。

例えば、本明細書に記載しているＤＤＭツールは、記載しているシステムに最終的に結合される医療装置のメーカに提供されることが可能である。そのメーカは、その場合に“Ｉｍｐｏｒｔ ＸＭＬ Ｆｉｌｅ”オプションを選択することにより、ＳＱＬデータベース９４（図３）にインポートされることが可能である装置のためのＸＭＬファイルを作成することが可能である。このように、メーカは、その装置に関連する専用情報を開示する必要がない。

本発明について、上では、複数の実施形態を参照して詳述している。上の詳述を読んで、理解することにより、当業者には修正及び変形が発想され得る。本発明はそのような修正及び変形のすべてを包含し、それらの修正及び変形は同時提出の特許請求の範囲又はそれらと同等なものの範囲内にあるように意図されている。

Claims (20)

1. 拡張可能なフレームワークにおいてデバイスドライバのための再使用可能なコードの供給を容易にするシステムであって：
   単独のポートのパススルー接続を介して複数のポートの医療データ取得装置（ＭＤＡＤ）に結合された医療装置を検出する複数のポートのＭＤＡＤ；
   前記医療装置のためのプラグアンドプレイ拡張可能マークアップ言語（ＸＭＬ）デバイスドライバファイルを生成するデバイスドライバマネージャ（ＤＤＲ）ツール；及び
   前記医療装置又は類似する装置が当該システムに結合されるときにはいつでも、用いるための前記ＸＭＬデバイスドライバファイルを記憶するコンピュータ読み出し可能媒体； を有するシステムであり、
   前記ＸＭＬデバイスドライバファイルは、前記医療装置のためのデバイスドライバを記述する複数のフォーマットパラメータを有する；
   システム。
2. 前記単独のポートのパススルー接続を介して前記ＭＤＡＤに結合された患者モニタ；
   を更に有する、請求項１に記載のシステム。
3. 前記単独のポートのパススルー接続及び前記複数のポートのＭＤＡＤにより使用可能なコードを有する共有コードモジュール；
   を更に有する、請求項２に記載のシステム。
4. 前記フォーマットパラメータは、ドライバ名、ボーレート、パリティ、バッファサイズ、タイムスタンプ情報、トークン情報、データスタイル、ストップビット情報及びメッセージ情報の少なくとも１つを有する、請求項１乃至３の何れか一項に記載のシステム。
5. 識別モジュールはＥＣ−５タイプ識別モジュールである、請求項１乃至４の何れか一項に記載のシステム。
6. 前記ＭＤＡＤはＥＣ−４０タイプＭＤＡＤ又はＥＣ−８０タイプＭＤＡＤの一である、請求項１乃至５の何れか一項に記載のシステム。
7. 前記単独のポートのパススルー接続はＥＣ−１０タイプパススルー接続である、請求項２乃至５の何れか一項に記載のシステム。
8. 前記ＭＤＡＤは前記医療装置と互換性のあるＸＭＬファイルを前記コンピュータ読み出し可能媒体から検索し、前記医療装置と通信してデータを受け取るようにドライバフレームワークに前記ＸＭＬファイルをロードし、医療データ情報ベース（ＭＤＩＢ）に前記受け取られたデータを記憶する、請求項１乃至７の何れか一項に記載のシステム。
9. 受け取られたデータをＭＤＩＬフォーマットから健康レベル７（ＨＬ７）フォーマットに変換し、前記ＨＬ７フォーマット化されたデータを病院情報システム（ＨＩＳ）に出力するＩＣＩＰホスト；
   を更に有する、請求項８に記載のシステム。
10. 再使用可能な拡張可能マークアップ言語（ＸＭＬ）デバイスドライバファイルを生成する方法であって：
    デバイスドライバのリストからデバイスドライバを選択するステップ；
    デバイスドライバマネージャ（ＤＤＭ）ツールを用いて、前記選択されたデバイスドライバのためのＸＭＬデバイスドライバファイルを設定するステップ；
    前記ＸＭＬデバイスドライバファイルが完全に設定されたときに、前記ＸＭＬデバイスドライバファイルを生成するステップ；及び
    互換性のある医療装置の検出時に呼び出しのためにコンピュータ読み出し可能媒体に前記ＸＭＬデバイスドライバファイルを記憶するステップ；
    を有する方法であり、
    前記ＸＭＬデバイスドライバファイルは、前記医療装置のためのデバイスドライバを記述する複数のフォーマットパラメータを有する；
    方法。
11. 新しく接続された医療装置のためのプラグインイベントを検出するステップ；
    前記医療装置の医療デバイスドライバ情報を受け取るステップ；
    前記コンピュータ読み出し可能媒体から互換性のあるＸＭＬデバイスドライバファイルを検索するステップ；及び
    前記新しく接続された医療装置と双方向通信するように、前記検索されたＸＭＬデバイスドライバを実行するステップ；
    を更に有する、請求項１０に記載の方法。
12. 前記ＸＭＬデバイスドライバファイルを設定するステップは、１つ又はそれ以上のドライバ特性、１つ又はそれ以上のメッセージ特性、１つ又はそれ以上のドライバパラメータ及び１つ又はそれ以上のストリッピング要素を設定する、請求項１０又は１１に記載の方法。
13. 前記１つ又はそれ以上のドライバ特性は、ドライバ名、ボーレート、データビット数、パリティ値、ストップビット値、バッファサイズ、タイムアウト値及びデータスタイル識別子の少なくとも１つを有する、請求項１２に記載の方法。
14. 前記１つ又はそれ以上のメッセージ特性は、メッセージ名、メッセージタイプ、メッセージフォーマット、遅延値、最大要求数、メッセージ長、トークン情報、タイムスタンプ情報及びチェックサム情報の少なくとも１つを有する、請求項１２又は１３に記載の方法。
15. 前記１つ又はそれ以上のドライバパラメータは、現在のメッセージ同一性、現在のメッセージパラメータ及びパラメータ特性情報を有する、請求項１２乃至１４の何れか一項に記載の方法。
16. 前記パラメータ特性情報は、パラメータ名、パラメータタイプ、パラメータ同一性、パラメータ調整演算情報、パラメータ調整値、測定情報の単位、パラメータ通信チャネル情報及びパラメータタイムスタンプ情報の少なくとも１つを有する、請求項１５に記載の方法。
17. 前記１つ又はそれ以上のストリッピング要素は、ディスクリプタ情報、古いバイト数及び新しいバイト数の少なくとも１つを有する、請求項１２乃至１６の何れか一項に記載の方法。
18. 第３者メーカにより生成され、前記第３者メーカにより製造された１つ又はそれ以上の医療装置と互換性のあるＸＭＬデバイスドライバファイルをインポートするステップ；及び
    前記第３者メーカにより製造された医療装置の検出時に呼び出しのために前記コンピュータ読み出し可能媒体に前記インポートされたＸＭＬデバイスドライバファイルを記憶させるステップ；
    を更に有する、請求項１０乃至１７の何れか一項に記載の方法。
19. ユーザが情報を入力し、医療装置のためにＸＭＬデバイスドライバファイルを設定する複数の選択可能ボタン及びテキストフィールドを有するユーザインタフェースであって、前記情報は、１つ又はそれ以上のドライバ特性、１つ又はそれ以上のメッセージ特性、１つ又はそれ以上のドライバパラメータ及び１つ又はそれ以上のストリッピング要素を有する、ユーザインタフェース；
    を有する拡張可能マークアップ言語（ＸＭＬ）デバイスドライバマネージャ（ＤＭＭ）ツール。
20. 複数のＸＭＬデバイスドライバファイルを記憶するコンピュータ読み出し可能媒体；
    を更に有し、
    当該ツールは、プラグアンドプレイイベントの検出時に互換性のある医療装置のためにＸＭＬデバイスドライバファイルを検索し、前記互換性のある医療装置は、当該ツールが接続された病院情報システムに接続されるようになる；
    請求項１９に記載のツール。

Images