JP2007507046A - 臨床システムインタフェースを含む医療デバイス管理システム - 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