特許 7423679 電子患者ケアのためのシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-01-19

(45)【発行日】2024-01-29

(54)【発明の名称】電子患者ケアのためのシステム

(51)【国際特許分類】

   G16H 40/00 20180101AFI20240122BHJP

【ＦＩ】

G16H40/00

【請求項の数】 23

(21)【出願番号】P 2022063771

(22)【出願日】2022-04-07

(62)【分割の表示】P 2019186451の分割

【原出願日】2013-12-20

(65)【公開番号】P2022091978

(43)【公開日】2022-06-21

【審査請求日】2022-04-18

(31)【優先権主張番号】13/723,239

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】13/724,568

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】PCT/US2012/071490

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】13/723,251

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】PCT/US2012/071142

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】13/723,235

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】13/723,244

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】13/723,253

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】13/723,238

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】13/723,242

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】13/725,790

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】PCT/US2012/071131

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】13/836,497

(32)【優先日】2013-03-15

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】PCT/US2012/071112

(32)【優先日】2012-12-21

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】594010009

【氏名又は名称】デカ・プロダクツ・リミテッド・パートナーシップ

(74)【代理人】

【識別番号】110003579

【氏名又は名称】弁理士法人山崎国際特許事務所

(74)【代理人】

【識別番号】100173978

【弁理士】

【氏名又は名称】朴 志恩

(74)【代理人】

【識別番号】100118647

【弁理士】

【氏名又は名称】赤松 利昭

(74)【代理人】

【識別番号】100123892

【弁理士】

【氏名又は名称】内藤 忠雄

(74)【代理人】

【識別番号】100169993

【弁理士】

【氏名又は名称】今井 千裕

(72)【発明者】

【氏名】ケイメン、ディーン

(72)【発明者】

【氏名】バイアシー、ジョン・ジェイ

【審査官】今井 悠太

(56)【参考文献】

【文献】特表２００６－５２００３７（ＪＰ，Ａ）

【文献】特開２００１－２９１０４４（ＪＰ，Ａ）

【文献】特開２００８－２６２５４１（ＪＰ，Ａ）

【文献】特表２０１２－５１１９６５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ１６Ｈ １０／００－８０／００

(57)【特許請求の範囲】

【請求項1】

電子患者ケアのためのシステムであって、
ネットワーク、
アプリケーション用の出版購読型（ｐｕｂｌｉｓｈ－ｓｕｂｓｃｒｉｂｅ）サービスを提供する様に構成されているファシリティゲートウェイ、
前記ファシリティゲートウェイにより実行されるように構成されるデバイスゲートウェイアプリケーションを備え、デバイスゲートウェイは、ウェブサービスを提供することによりネットワークを介して通信する様に構成されている、
ネットワークと動作可能に通信することができる医療デバイスを備え、前記医療デバイスは、ウェブサービスを用いて前記デバイスゲートウェイと通信する様に構成されている、及び
前記ファシリティゲートウェイ上で実行可能なデバイスマネージャを備え、前記デバイスマネージャは、前記医療デバイスを含む医療デバイスのリストを保持することを含む様に構成され、前記医療デバイスのリストは、前記医療デバイスのリストに対応する通し番号のリストを含む、
電子患者ケアのためのシステム。

【請求項2】

請求項１のシステムであって、さらに、出版購読型サービスを提供するように構成された出版購読型エンジンを含む、
前記システム。

【請求項3】

請求項１のシステムであって、前記ネットワークは、ＴＣＰ／ＩＰベースのネットワークである、
前記システム。

【請求項4】

請求項１のシステムであって、前記デバイスゲートウェイアプリケーションは、ウェブサービスのウェブサーバーであり、前記医療デバイスはウェブサービスのクライアントである、
前記システム。

【請求項5】

請求項１のシステムであって、前記デバイスゲートウェイアプリケーションは、出版購読型サービスを用いてトピックを記録する様に構成されている、
前記システム。

【請求項6】

請求項５のシステムは、さらに前記ファシリティゲートウェイにより実行されるように構成された統合ＡＰＩを備え、前記統合ＡＰＩはトピックに登録申込みして、そのトピックに登録申込みをすることにより受領したイベントを、少なくとも１つの外部サーバーに通信するように構成される、
前記システム。

【請求項7】

請求項６のシステムであって、前記トピックは、報告可能な生物医学（ｂｉｏｍｅｄ）イベントトピック及び報告可能な臨床イベントトピックの少なくとも一つである、
前記システム。

【請求項8】

請求項５のシステムであって、前記トピックは、報告可能な生物医学イベントトピックであり、前記デバイスゲートウェイは、ウェブサービスを介して受領した医療デバイスイベントを、出版購読型エンジンを介してトピックの登録申込者（ｓｕｂｓｃｒｉｂｅｒ）が受領可能な、報告可能な生物医学イベントに再フォーマットする、
前記システム。

【請求項9】

請求項８のシステムであって、前記医療デバイスは、ウェブサービスを用いて、ネットワークを介して前記医療デバイスイベントを通信する、
前記システム。

【請求項10】

請求項５のシステムであって、前記トピックは、報告可能な臨床イベントトピックであり、前記デバイスゲートウェイは、ウェブサービスを介して受領した医療デバイスイベントを、出版購読型エンジンを介して、トピックの登録申込者により受領可能な、報告可能な臨床イベントに再フォーマットする、
前記システム。

【請求項11】

請求項１０のシステムであって、前記医療デバイスはウェブサービスを用いてネットワークを介して医療デバイスイベントを通信する、
前記システム。

【請求項12】

請求項５のシステムであって、前記トピックは少なくとも一つのクラスのポンプ・イベントに対応する、前記システム。

【請求項13】

請求項１２のシステムであって、少なくとも一つのクラスのポンプ・イベントは、警報、警告または通知に関する輸液イベント（ｉｎｆｕｓｉｏｎ ｅｖｅｎｔ）、輸液に関する輸液イベント、プログラミングに関する輸液イベント、通信に関するデバイスイベント（ｄｅｖｉｃｅ ｅｖｅｎｔ）、アクセス要求に関するデバイスイベント、設定の更新に関するデバイスイベント、ロギング（ｌｏｇｇｉｎｇ）に関するデバイスイベント、及び／又は電力消費に関するデバイスイベントの少なくとも一つを含む、
前記システム。

【請求項14】

請求項１のシステムであって、さらに、前記ファシリティゲートウェイにより実行するために構成される継続的な品質改善指向リスナーを含み、
前記継続的な品質改善指向リスナーは、報告可能な生物医学イベントのトピック及び報告可能な臨床イベントのトピックに登録申込みをし、
前記継続的な品質改善指向は、報告可能な生物医学イベントトピックへ登録申込みをすることにより受領される報告可能な生物医学イベントを外部データベースに通信する様に構成され、及び
前記継続的な品質改善指向は、報告可能な臨床イベントトピックへ登録申込みをすることにより受領される報告可能な臨床イベントを外部データベースに通信する様に構成される、
前記システム。

【請求項15】

請求項１４のシステムであって、前記外部データベースは、報告可能な生物医学イベント及び報告可能な臨床イベントの少なくとも一つを記録する、
前記システム。

【請求項16】

請求項１のシステムであって、さらに、そこからステータス情報を受領するためにネットワークを介して前記医療デバイスと動作可能に通信する監視クライアントを含む、
前記システム。

【請求項17】

電子患者ケアのためのシステムであって、
ネットワーク、
出版購読型（ｐｕｂｌｉｓｈ－ｓｕｂｓｃｒｉｂｅ）サービスを提供する様に構成されているファシリティゲートウェイ、
前記ファシリティゲートウェイにより実行されるように構成されたデバイスゲートウェイを備え、そして前記デバイスゲートウェイは、ウェブサービスを提供することによりネットワークを介して通信する様に構成されており、前記デバイスゲートウェイは医療デバイスイベントトピックを発行し、
前記ファシリティゲートウェイ上で実行する様に構成されており、医療デバイスイベントトピックに登録申込みするように構成されたデバイスアプリケーションを備え、前記デバイスアプリケーションは、ＣＱＩメッセージトピックを発行し、前記デバイスアプリケーションは、医療デバイスイベントトピックに登録申込みすることによりイベントを受信し、そしてＣＱＩメッセージトピックを通して、イベントをＣＱＩメッセージとして発行するように構成され、
前記ファシリティゲートウェイ上で実行可能なデバイスマネージャを備え、前記デバイスマネージャは、医療デバイスを含む医療デバイスのリストを保持することを含む様に構成され、前記医療デバイスのリストは、前記医療デバイスのリストに対応する通し番号のリストを含む、及び
ネットワークと動作可能に通信する医療デバイスを備え、前記医療デバイスは、ウェブサービスを用いて前記デバイスゲートウェイと通信し、ウェブサービスのウェブメソッドを用いてイベントを生成する様に構成されている、
電子患者ケアのためのシステム。

【請求項18】

請求項１７のシステムであって、前記デバイスゲートウェイは、ＣＱＩメッセージを受領するためにＣＱＩメッセージトピックに登録申込みをする、
前記システム。

【請求項19】

請求項１８のシステムであって、さらに前記ファシリティゲートウェイにより実行するように構成されるＣＱＩリスナーを含み、前記ＣＱＩリスナーは、ＣＱＩメッセージを受領するためにＣＱＩメッセージのトピックに登録申込みする、
前記システム。

【請求項20】

請求項１９のシステムであって、前記ＣＱＩリスナーは前記ＣＱＩメッセージを外部データベースに通信する、
前記システム。

【請求項21】

請求項１７のシステムであって、前記ＣＱＩメッセージは、報告可能な生物医学イベントおよび報告可能な臨床イベントの一つである、
前記システム。

【請求項22】

さらに、前記医療デバイスと動作可能に通信するように構成された監視クライアントを含む、
請求項１７のシステム。

【請求項23】

請求項２２のシステムであって、前記監視クライアントは、ＣＱＩメッセージトピックに登録申込みすることにより前記医療デバイスと通信する、
前記システム。

【発明の詳細な説明】

【発明の背景】

【0001】

関連出願の相互参照
本出願は、２０１３年３月１５日に出願された発明の名称を電子患者ケアのためのシステムおよび装置と題する出願、米国非仮特許出願番号１３／８３６，４９７の継続出願である（代理人整理番号Ｋ２２）。
２０１３年３月１５日に出願された発明の名称を電子患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、以下の出願の優先権の利益及びその出願の利益を主張する。
２０１２年８月３日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国仮特許出願、出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）及び
２０１２年５月２４日に出願された、発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する米国仮特許出願、出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）であり、両出願は参照によりその全体が本明細書に組み入れられる。
２０１３年３月１５日に出願された発明の名称を電子的な患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、以下の出願の優先権の利益を主張し、及び以下の出願の一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）、これらの全ての出願は参照により本明細書に組み入れられる；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。
２０１３年３月１５日に出願され、発明の名称を電子的な患者ケアのためのシステムおよび装置と題する米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称をクランピングのためのシステム、方法及び装置と題する出願、米国特許出願第１３／７２３，２３８であって、米国特許出願第１３／７２３，２３８は、２０１３年７月１８日に公開され、その公開番号ＵＳ２０１３－０１８２３８１－Ａ１の出願（代理人整理番号Ｊ４７）の優先権の利益を主張すると共にその一部継続出願であり、米国特許出願第１３／７２３，２３８は以下の出願の優先権及びその出願の利益を主張する：

【0002】

２０１１年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年８月３日に出願された発明の名称を流体フローを監視、規制又は制御するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）；及び
２０１２年５月２４日に出願された発明の名称を電子患者ケアシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）であり、これらの出願は、参照によりその全てが本明細書に組み込まれる。
米国特許出願第１３／７２３，２３８は、２０１３年７月１８日に公開され、その公開番号ＵＳ２０１３－０１８２３８１－Ａ１（代理人整理番号Ｊ４７）は、以下の出願の優先権の利益を主張するとともにその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。
２０１３年３月１５日に出願され、発明の名称を電子患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を経口薬の調合のためのシステム、方法及び装置と題する出願、米国特許出願第１３／７２３，２３５であって、２０１３年８月１日に公開され、その公開番号ＵＳ－２０１３－０１７９６９３－Ａ１である出願（代理人整理番号Ｊ７４）の優先権の利益を主張すると共にその一部継続出願であり、米国特許出願第１３／７２３，２３５は以下の出願の優先権及びその出願の利益を主張する：
２０１１年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年８月３日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国仮特許出願、出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）及び
２０１２年３月２４日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する米国仮特許出願、出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）、であり、これらの出願は参照によりその全体が本明細書に組み入れられる。
２０１２年１２月２１日に出願された経口薬の調合のためのシステム、方法及び装置と題する出願、米国特許出願第１３／７２３，２３５であって、２０１３年８月１日に公開され、その公開番号ＵＳ－２０１３－０１７９６９３－Ａ１である出願（代理人整理番号Ｊ７４）は、以下の出願の優先権の利益を主張すると共にその出願の一部継続出願である：２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。

【0003】

２０１３年３月１５日に出願され、発明の名称を電子患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、ＰＣＴ出願第ＰＣＴ／ＵＳ１２／７１１３１であって、ＰＣＴ／ＵＳ１２／７１１３１は、２０１３年７月２７日に公開され、その公開番号ＷＯ２０１３／０９６７１８（代理人整理番号Ｊ７４ＷＯ）である出願の一部継続出願であり、ＰＣＴ出願第ＰＣＴ／ＵＳ１２／７１１３１は以下の出願の優先権の利益及びその出願の利益を主張する：
２０１１年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年５月２４日に出願された発明の名称を電子的な患者ケアのためのシステムおよび装置と題する米国仮特許出願、出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）、及び
２０１２年８月３日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国仮特許出願、出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）であり、両出願は参照によりその全体が本明細書に組み入れられる。
２０１２年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、ＰＣＴ出願ＰＣＴ／ＵＳ１２／７１１３１であって、２０１３年６月２７日に公開され、その公開番号ＷＯ２０１３／０９６７１８（代理人整理番号Ｊ７４ＷＯ）である出願は、以下の出願の優先権の利益を主張するものであるとともにその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）、これらの全ての出願は参照により本明細書に組み入れられる；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。
２０１３年３月１５日に出願された発明の名称を電子患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を、液体供給を推定するためのシステム、方法、および装置と題する出願、米国特許出願番号１３／７２４，５６８であって、２０１３年７月１８日に公開され、その公開番号ＵＳ２０１３－０１８４６７６－Ａ１である出願（代理人整理番号Ｊ７５）の優先権の利益を主張すると共にその一部継続出願であり、米国特許出願番号１３／７２４，５６８は以下の出願の優先権の利益及びその出願の利益を主張する。
２０１１年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年８月３日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国仮特許出願、出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）及び
２０１２年３月２４日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する米国仮特許出願、出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）であり両出願は参照によりその全体が本明細書に組み入れられる。
２０１２年１２月２１日に出願された発明の名称を、液体供給を推定するためのシステム、方法、および装置と題する出願、米国特許出願番号１３／７２４，５６８であって、２０１３年７月１８日に公開され、その公開番号ＵＳ２０１３－０１８４６７６－Ａ１である出願（代理人整理番号Ｊ７５）は以下の出願の優先権の利益を主張すると共にその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。

【0004】

２０１３年３月１５日に出願され、発明の名称を電子的な患者ケアのためのシステムおよび装置と題する米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を流体を注入するためのシステム、方法、および装置と題する出願、米国特許出願番号１３／７２５，７９０であって、２０１３年７月１１日に公開され、その公開番号ＵＳ２０１３－０１７７４５５－Ａ１（代理人整理番号Ｊ７６）である出願の優先権の利益を主張すると共にその一部継続出願であり、米国特許出願番号１３／７２５，７９０は以下の出願の優先権の利益及びその出願の利益を主張する：
２０１１年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を、液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年８月３日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国仮特許出願、出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）及び
２０１２年３月２４日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する米国仮特許出願、出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）であり、両出願は参照によりその全体が本明細書に組み入れられる。
２０１２年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国特許出願番号１３／７２５，７９０であって、２０１３年７月１１日に公開され、その公開番号ＵＳ２０１３－０１７７４５５－Ａ１である出願（代理人整理番号Ｊ７６）は、以下の出願の優先権の利益を主張すると共にその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。

【0005】

２０１３年３月１５日に出願され、電子患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）はまた、２０１２年１２月２１日に出願された発明の名称を流体を注入するためのシステム、方法、および装置と題する出願、ＰＣＴ出願、出願番号ＰＣＴ／ＵＳ１２／７１４９０であって、２０１３年６月２７日に公開され、その公開番号ＷＯ２０１３／０９６９０９である出願（代理人整理番号Ｊ７６ＷＯ）の一部継続出願であり、ＰＣＴ出願、出願番号ＰＣＴ／ＵＳ１２／７１４９０は以下の出願の優先権の利益及びその出願の利益を主張する。
２０１１年１２月２１日に出願された発明の名称を流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年８月３日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国仮特許出願、出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）及び
２０１２年３月２４日に出願された発明の名称を電子患者ケアのためのシステム、方法および装置と題する米国仮特許出願、出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。
２０１２年１２月２１日に出願された発明の名称を流体を注入するためのシステム、方法、および装置と題する出願、ＰＣＴ出願番号ＰＣＴ／ＵＳ１２／７１４９０であって、２０１３年６月２７日に公開され、その公開番号ＷＯ２０１３／０９６９０９である出願（代理人整理番号Ｊ７６）は以下の出願の優先権の利益を主張すると共にその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）、これらの全ての出願は参照により本明細書に組み入れられる；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。
２０１３年３月１５日に出願された電子患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願番号１３／７２３，２３９であって、２０１３年１１月７日に公開され、その公開番号ＵＳ２０１３－０２９７３３０－Ａ１である出願（代理人整理番号Ｊ７７）の優先権の利益を主張すると共にその一部継続出願であり、米国特許出願番号１３／７２３，２３９は以下の出願の優先権の利益及びその出願の利益を主張する：
２０１１年１２月２１日に出願された発明の名称を流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年５月２４日に出願された発明の名称を電子患者ケアシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）；及び
２０１２年８月３日に出願された発明の名称を流体フローを監視、規制又は制御するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）であり、これの出願は、参照によりその全体が本明細書に組み込まれる。
２０１２年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願番号１３／７２３，２３９であって、２０１３年１１月７日に公開され、その公開番号ＵＳ２０１３－０２９７３３０－Ａ１である出願（代理人整理番号Ｊ７７）は、以下の出願の優先権の利益を主張すると共にその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）、これらの全ての出願は参照により本明細書に組み入れられる；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。

【0006】

２０１３年３月１５日に出願され、発明の名称を電子患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を電子患者ケアのためのシステム、方法および装置と題する出願、米国特許出願番号１３／７２３，２４２であって、２０１３年１１月２８日に公開され、その公開番号ＵＳ２０１３－０３１７７５３－Ａ１である出願（代理人整理番号Ｊ７８）の優先権の利益を主張すると共にその一部継続出願であり、米国特許出願番号１３／７２３，２４２は以下の出願の優先権の利益及びその出願の利益を主張する：
２０１２年３月２４日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する米国仮特許出願、出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。
２０１３年３月１５日に出願された発明の名称を電子患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する出願、米国特許出願番号１３／７２３，２４４であり、２０１３年７月２５日に公開され、その公開番号ＵＳ２０１３－０１８８０４０－Ａ１である出願（代理人整理番号Ｊ７９）の優先権の利益を主張すると共にその一部継続出願であり、米国特許出願番号１３／７２３，２４４は、以下の出願の優先権の利益及びその出願の利益を主張する：
２０１１年１２月２１日に出願された発明の名称を流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を、経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年３月２４日に出願された発明の名称を電子患者ケアのためのシステムおよび装置と題する米国仮特許出願、出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）；及び
２０１２年８月３日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国仮特許出願、出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）であり、両出願は参照によりその全体が本明細書に組み入れられる。
２０１２年１２月２１日に出願された流体フローの監視、規制又は制御するシステム、方法及び装置と題する出願、米国特許出願番号１３／７２３，２４４であり、２０１３年７月２５日に公開され、その公開番号ＵＳ２０１３－０１８８０４０－Ａ１である出願（代理人整理番号Ｊ７９）は以下の出願の優先権の利益を主張すると共にその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）、これらの全ての出願は参照により本明細書に組み入れられる；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。
２０１３年３月１５日に出願され、発明の名称を電子的な患者ケアのためのシステムおよび装置と題する米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を流体フローを監視、規制又は制御するためのシステム、方法、および装置と題する出願、ＰＣＴ特許出願番号ＰＣＴ／ＵＩＳ１２／７１１４２であって、ＰＣＴ特許出願番号ＰＣＴ／ＵＩＳ１２／７１１４２は、２０１３年７月２７日に公開され、その公開番号ＷＯ２０１３／０９６７２２である出願（代理人整理番号Ｊ７９ＷＯ）の優先権の利益を主張すると共にその一部継続出願でありであり、ＰＣＴ特許出願番号ＰＣＴ／ＵＩＳ１２／７１１４２は以下の出願の優先権の利益及びその出願の利益を主張する：
２０１１年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年３月２４日に出願された発明の名称を電子的な患者ケアのためのシステムおよび装置と題する米国仮特許出願、出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）、及び
２０１２年８月３日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国仮特許出願、出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）であり、両出願は参照によりその全体が本明細書に組み入れられる。
２０１２年１２月２１日に出願された発明の名称を流体フローを監視、規制又は制御するためのシステム、方法、および装置と題する出願、ＰＣＴ特許出願番号ＰＣＴ／ＵＩＳ１２／７１１４２であって、２０１３年６月２７日に公開され、その公開番号ＷＯ２０１３／０９６７２２である出願（代理人整理番号Ｊ７９ＷＯ）は、以下の出願の優先権の利益を主張すると共にその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）、これらの全ての出願は参照により本明細書に組み入れられる；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。

【0007】

２０１３年３月１５日に出願され、発明の名称を電子的な患者ケアのためのシステムおよび装置と題する米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国特許出願番号１３／７２３，２５１であって、２０１３年８月８日に公開され、その公開番号ＵＳ２０１３－０２０４１８８－Ａ１である出願（代理人整理番号Ｊ８１）の優先権の利益を主張すると共にその一部継続出願であり、米国特許出願番号１３／７２３，２５１は以下の出願の優先権の利益及びその出願の利益を主張する：
２０１１年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年５月２４日に出願された発明の名称を電子患者ケアシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）；及び
２０１２年８月３日に出願された発明の名称を流体フローを監視、規制又は制御するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）であり、両出願は参照によりその全体が本明細書に組み入れられる。
２０１２年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国特許出願番号１３／７２３，２５１であって、２０１３年８月８日に公開され、その公開番号ＵＳ２０１３－０２０４１８８－Ａ１である出願（代理人整理番号Ｊ８１）の優先権の利益を主張すると共にその一部継続出願である：２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。

【0008】

２０１３年３月１５日に出願され、発明の名称を電子的な患者ケアのためのシステムおよび装置と題する米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題するＰＣＴ特許出願、出願番号ＰＣＴ／ＵＳ１２／７１１１２
であって、２０１３年６月２７日に公開され、その公開番号ＷＯ ２０１３／０９６７１３である出願（代理人整理番号Ｊ８１ＷＯ）の一部継続出願であり、出願番号ＰＣＴ／ＵＳ１２／７１１１２は以下の出願の優先権の利益及びその出願の利益を主張する：
２０１１年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年５月２４日に出願された発明の名称を電子患者ケアシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）；２０１２年８月３日に出願された発明の名称を、流体フローを監視、規制又は制御するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）であり、これの出願は、参照によりその全体が本明細書に組み込まれる。
２０１２年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、ＰＣＴ／ＵＳ１２／７１１１２であって、２０１３年６月２７日に公開され、その公開番号ＷＯ ２０１３／０９６７１３である出願（代理人整理番号Ｊ８１ＷＯ）は、以下の出願の優先権の利益を主張すると共にその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）；及び

【0009】

２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。
２０１３年３月１５日に出願され、発明の名称を電子患者ケアのためのシステムおよび装置と題する米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、２０１２年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国特許出願番号１３／７２３，２５３であって、その公開番号ＵＳ２０１３－０１９１５１３－Ａ１である出願（代理人整理番号Ｊ８５）の優先権の利益を主張すると共にその一部継続出願であり、以下の出願の優先権の利益を主張するものであり、米国特許出願番号１３／７２３，２５３は以下の出願の優先権の利益及びその出願の利益を主張する：
２０１１年１２月２１日に出願された発明の名称を、流体を注入するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６４９（代理人整理番号Ｊ０２）；
２０１１年１２月２１日に出願された発明の名称を液体供給を推定するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６５８（代理人整理番号Ｊ０４）；
２０１１年１２月２１日に出願された発明の名称を経口薬を調合するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／５７８，６７４（代理人整理番号Ｊ０５）；
２０１２年５月２４日に出願された発明の名称を電子患者ケアシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６５１，３２２（代理人整理番号Ｊ４６）
４）；及び
２０１２年８月３日に出願された発明の名称を流体フローを監視、規制又は制御するためのシステム、方法、および装置と題する出願、米国仮特許出願番号６１／６７９，１１７（代理人整理番号Ｊ３０）であり、これの出願は、参照によりその全てが本明細書に組み込まれる。
２０１２年１２月２１日に出願された発明の名称を電子患者ケアのためのシステム、方法および装置と題する出願、米国特許出願番号１３／７２３，２５３であって、その公開番号ＵＳ２０１３－０１９１５１３－Ａ１である出願（代理人整理番号Ｊ８５）は、以下の出願の優先権の利益を主張すると共にその一部継続出願である：
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題する出願、米国特許出願１３／３３３，５７４であって、２０１２年７月１９日に公開された米国公開番号ＵＳ－２０１２－０１８５，２６７－Ａ１（代理人整理番号Ｉ９７）であり、この出願は２０１１年１月２１日に出願された発明の名称を電子患者監視システムと題する出願、米国特許出願１３／０１１，５４３の一部継続出願であり、米国特許出願１３／０１１，５４３は２０１１年１２月２２日に、公開番号ＵＳ－２０１１－０３１３７８９－Ａ１で公開され（代理人整理番号Ｉ５２）、この出願は２０１０年１月２２日に出願された、発明の名称を医療施設のための電子発注仲介システムと題する米国仮特許出願第６１／２９７，５４４の優先権を主張する（代理人整理番号Ｈ５３）；及び
２０１１年１２月２１日に出願された発明の名称を電子的な患者ケアのためのシステム、方法および装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１１／６６５８８であって、２０１３年９月１２日に公開され、その公開番号はＷＯ２０１３／０９５４５９である出願（代理人整理番号Ｉ９７ＷＯ）であり、これらの出願は参照によりその全体が本明細書に組み入れられる。

【0010】

２０１３年３月１５日に出願された発明の名称を電子患者ケアのためのシステムおよび装置と題する米国特許出願１３／８３６，４９７（代理人整理番号Ｋ２２）は、また以下の米国特許出願の一以上と関連し、これらの出願は参照によりその全体が本明細書に組み入れられる：
２０１３年３月１５日に出願され、発明の名称を流体を注入するための装置と題する米国特許出願１３／８３６，４９７（代理人整理番号Ｋ１４）；
２０１３年３月１５日に出願され、発明の名称を流体を注入するための装置と題するＰＣＴ出願ＰＣＴ／ ＵＳ１３／３２４４５（代理人整理番号Ｋ１４ＷＯ）；
２０１３年３月１５日に出願され、発明の名称を注射ポンプ及び関連する方法と題する米国特許出願１３／８３３，４３２であり、公開番号ＵＳ－２０１１－０２８１９６５－Ａ１で公開された出願（代理人整理番号Ｋ２１）；
２０１３年３月１５日に出願された発明の名称をクランピングのためのシステム、方法及び装置と題する米国特許出願１３／８３３，７１２であり、２０１３年１０月１７日に公開番号ＵＳ－２０１１－０２７２７７３－Ａ１で公開された出願（代理人整理番号Ｋ２３）；
２０１３年３月１５日に出願された発明の名称を流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国特許出願１３／８３４，０３０であり、２０１３年１１月２１日に公開番号ＵＳ－２０１３－０３１０９９０－Ａ１で公開された出願（代理人整理番号Ｋ２８）；
２０１３年７月３１日に出願された発明の名称をマイクロウエーブエアー検出のためのシステム、方法及び装置と題する米国仮特許出願１３／８６０，３９８（代理人整理番号Ｊ３１）；
２０１２年１２月２１日に出願された発明の名称をデータ通信のためのシステム、方法及び装置と題する米国仮特許出願６１／７４０，４７４（代理人整理番号Ｊ８０）；
２０１３年１１月６日に出願された発明の名称を、流体フローの監視、規制又は制御するシステム、方法及び装置と題する米国仮特許出願６１／９００，４３１（代理人整理番号Ｋ５２）；
２０１３年１０月２３日に出願された発明の名称を注射ポンプ及び関連する方法と題する米国仮特許出願６１／８９４，４３１（代理人整理番号Ｋ８８）；
２０１３年５月２３日に出願された発明の名称を電子患者ケアのためのシステムおよび装置と題する出願、米国特許出願１３／９００，６５５（代理人整理番号Ｋ６６）；
２０１３年５月２３日に出願された発明の名称を電子患者ケアのためのシステムおよび装置と題するＰＣＴ出願、出願番号ＰＣＴ／ ＵＳ１３／４２３５０（代理人整理番号Ｋ６６ＷＯ）；
２０１３年７月８日に出願された発明の名称をクランピングのためのシステム、方法及び装置と題する米国仮特許出願６１／８４３，５７４（代理人整理番号Ｋ７５）；
２０１３年８月２０日に出願された発明の名称を電子患者監視システムと題する米国特許出願１３／９７１，２５８（代理人整理番号Ｋ８４）；
２０１３年１１月１４日に出願された発明の名称を注射ポンプ及び関連する方法と題する米国仮特許出願６１／９０４，１２３（代理人整理番号Ｌ３３）；

【技術分野】

【0011】

本開示は患者のケアに関する。より詳細には、本開示は電子患者ケアのためのシステムおよび装置に関する。
関連する文献の記載

【0012】

病院で患者のケアを提供する場合、一般的に、所与の患者の治療のために必要な多数の専門家や介護者（例えば、医師、看護師、薬剤師、技師、看護のための専門家等）と多く医療デバイス／システムとの間の相互協働作業を必要とする。電子カルテ（「ＥＭＲ」）と、コンピュータ化されたプロバイダオーダーエントリ（ｃｏｍｐｕｔｅｒｉｚｅｄ ｐｒｏｖｉｄｅｒ ｏｒｄｅｒ ｅｎｔｒｙ）（「ＣＰＯＥ」）を組み込んだケアプロセスを容易にすることを目的とシステムがあるにもかかわらず、投薬の様な治療薬剤を発注し、治療をすることを含む、患者に対する総合的なケアを提供するプロセスは、多くの無視できない問題が関連している。

【0013】

電子カルテ（「ＥＭＲ」）と、コンピュータ化されたプロバイダーオーダーエントリ（「ＣＰＯＥ」）を組み込んだシステムがあるにもかかわらず、治療薬剤を発注し、治療をするプロセスには、まだ決定的な情報が誤って伝わったり、完全な情報にすぐにアクセスできない状況で治療の決定を下す、及び不必要に重複する及び非効率的な手続きのために治療の指示の実行が遅れる等の可能性がまだ存在する。

【0014】

米国で投薬の過誤により毎年３００人以上の死亡がおきている可能性があり、そして１００万人以上が損傷を受けていると思われる。経営が苦しい病院では投薬ミスの発生率が増加するおそれがある。最も危険な投薬の過誤に関連する薬剤として、インスリン、麻薬、ヘパリンおよび化学療法薬が含まれる。
過誤の原因には、誤まった薬剤の投与、誤まった濃度の薬の処方、投与する頻度、または誤った投与経路（薬剤は、経口、静脈内、筋肉内、皮下、直腸、皮膚に局所的に、目や耳を介して、髄腔内、腹腔内、あるいは膀胱内においても投与することができる）によるものを含む。適切な発注と適切なラベリングをされたものであっても、判読不能な手書き、注文の伝達誤り、および類似した名前を持つ薬の誤った発音のため、薬剤はまだ不適切な投与をされることがあり得る。電子カルテ（ＥＭＲ）と薬剤についてのバーコードシステムの使用が増大するにつれて、投薬ミスの発生が低減していることが示されている。
ＥＭＲシステムは、例えば、コンピュータ化されたプロバイダオーダエントリ（ＣＰＯＥ）を容易にし、そして、診断、アレルギー、体重、年齢などの様な患者の特性と一致していない薬剤についての発注にフラグを立てることができる。しかし、これらのシステムは、広く採用されておらず、そのため、薬剤の発注、調剤及び投与の大幅な遅延や非効率をもたらすこととなり得る。

【0015】

薬剤注入装置が、重大な害をもたらすすべての投薬過誤の三分の一にまで関与していると推定されている。間違った薬剤が注入され、誤ったパラメータ（例えば、薬剤濃度や注入速度）が入力され又は既存の注入パラメータが不適切に変更されることなどがある。輸液ポンプに関連した死亡のうち、ほぼ半数はユーザーエラーが原因であり、これらのほとんどは輸液注入装置のプログラムエラーが原因である可能性がある。

【0016】

効果的な監視システムは、処置から生じる可能性のある多くの有害イベントのうちのいずれをも最小限に抑えるために、薬剤の発注と投与プロセスの全ての相において監視及び介入するものであるべきである。薬剤処理プロセスは、概念的に３つの相に分けることができる：処方相、薬剤調合相、および投与相である。過誤は、処方が書き込みまたは入力された場合、薬剤を使用するために取出され又は溶液中で混合された場合、又は患者に投与される場合に生じうる。監視システムは、薬剤が発注され、調製または投与される際の効率を大きく損なうことが無いようにするのが特に望ましく、及び分析のために関連情報を収集し、組織化し及び提示することにより、これらの活動を実行するために必要な時間を、実際に低減させることが望ましい。

【発明の概要】

【0017】

本開示の一の実施の形態では、電子患者ケアのためのシステムには、ネットワーク、ファシリティゲートウェイ、デバイスゲートウェイアプリケーションおよび医療デバイスを含む。ファシリティゲートウェイは、アプリケーション用の出版購読型（ｐｕｂｌｉｓｈ－ｓｕｂｓｃｒｉｂｅ）サービスを提供する様に構成されている。デバイスゲートウェイアプリケーションはファシリティゲートウェイにより実行されるように構成される。デバイスゲートウェイは、ウェブサービスを提供することによりネットワークを介して通信する様に構成されている。医療デバイスはネットワークと動作可能に通信することができる。
医療デバイスは、ウェブサービスを用いてデバイスゲートウェイと通信する様に構成されている。

【0018】

システムは、さらに、出版購読型サービスを提供するように構成された出版購読型エンジンを含む。ネットワークは、ＴＣＰ／ＩＰベースのネットワークであってもよい。デバイスゲートウェイアプリケーションは、ウェブサービスのウェブサーバーであっても良く、医療デバイスはウェブサービスのクライアントである。デバイスゲートウェイアプリケーションは、出版購読型サービスを用いてトピックを記録する様に構成されている。システムは、ファシリティゲートウェイにより実行される様に構成されている統合ＡＰＩを含む。統合ＡＰＩは、トピックに登録申込みして、そのトピックに登録申込みをすることにより受領したイベントを、少なくとも１つの外部サーバーに通信するように構成されている。

【0019】

前記トピックは、１以上の報告可能な生物医学（ｂｉｏｍｅｄ）イベントトピック、及び／又は報告可能な臨床イベントトピックであっても良い。
前記トピックは、報告可能な生物医学イベントトピックであってもよく、デバイスゲートウェイは、ウェブサービスを介して受領した医療デバイスイベントを、出版購読型エンジンを介して登録申込者（ｓｕｂｓｃｒｉｂｅｒ）が受領可能な、報告可能な生物医学イベントに再フォ‐マットしても良い。前記医療デバイスは、ウェブサービスを使用して、ネットワークを介して医療デバイスイベントを通信することができる。前記トピックは、報告可能な臨床イベントトピックであってもよく、デバイスゲートウェイは、ウェブサービスを介して受領した医療デバイスを出版購読型エンジンを介して、トピックの登録申込者により受領可能な、報告可能な臨床イベントに再フォーマットしてもよい。医療デバイスはウェブサービスを用いてネットワークを介して医療デバイスイベントを通信しても良い。

【0020】

前記トピックはポンプ・イベントの少なくとも一つのクラスに対応しても良い。例えば、警報、警告または通知に関する輸液イベント（ｉｎｆｕｓｉｏｎ ｅｖｅｎｔ）、輸液（以下、輸液注入、注入とも言う）に関する輸液イベント、プログラミングに関する輸液イベント、通信に関するデバイスイベント（ｄｅｖｉｃｅ ｅｖｅｎｔ）、アクセス要求に関するデバイスイベント、設定の更新に関するデバイスイベント、ロギング（ｌｏｇｇｉｎｇ）に関するデバイスイベント、及び／又は電力消費に関するデバイスイベントの少なくとも一つである。

【0021】

前記システムは、さらに、ファシリティゲートウェイにより実行するために構成されている継続的な品質改善指向リスナーを含んでも良い。継続的な品質改善指向リスナーは、報告可能な生物医学イベントのトピック及び報告可能な臨床イベントのトピックに登録申込みをしても良い。継続的な品質改善指向は、報告可能な生物医学イベントトピックへの登録申込みをすることにより受領された報告可能な生物医学イベントを外部データベースに通信する様に構成されても良い。継続的な品質改善指向は、報告可能な臨床イベントトピックへの登録申込みをすることにより受領された報告可能な臨床イベントを外部データベースに通信する様に構成されても良い。

【0022】

外部データベースは、報告可能な生物医学イベント及び報告可能な臨床イベントの少なくとも一つを記録することができる。

【0023】

前記システムは、ファシリティゲートウェイ上で実行可能なデバイスマネージャを含むことができる。デバイスマネージャは、前記医療デバイスを含む医療デバイスのリストを保持することを含む様に構成しても良い。医療デバイスのリストは、医療デバイスのリストに対応する通し番号のリストを含んでも良い。

【0024】

システムは、そこからステータス情報を受信するためにネットワークを介して医療デバイスと動作可能に通信をしている監視クライアントを含むことができる。

【0025】

本開示の他の実施形態において、医療デバイスは、ネットワーク、プロセッサ、トランシーバ、およびデバイスゲートウェイ通信マネージャを含む。トランシーバは、プロセッサと動作可能に通信が可能であり、ネットワークを介して通信するように構成されている。
デバイスゲートウェイ通信マネージャは、プロセッサ上で実行可能であり、トランシーバを介して動作可能に通信することができるように構成されている。デバイスゲートウェイ通信マネージャは、ネットワーク上のウェブメソッドを使用してデバイスイベントを伝達するように構成することができる。デバイスは、ネットワークを介して監視デバイスにデータを送信するように構成することができる。

【0026】

ネットワークは、ＷｉＦｉネットワークであってもよく、トランシーバは、ＷｉＦｉトランシーバであってもよい。いくつかの実施形態では、前記デバイスのみがウェブメソッドを使用して通信を開始するように構成されている。

【0027】

本開示のさらに別の実施形態では、電子患者ケアのためのシステムは、ネットワーク、ファシリティゲートウェイ、デバイスゲートウェイアプリケーション、デバイスアプリケーション、および医療デバイスを含む。ファシリティゲートウェイは出版購読型サービスを提供するように構成することができる。
デバイスゲートウェイアプリケーションは、ファシリティゲートウェイにより実行されるように構成されてもよい。デバイスゲートウェイは、ウェブサービスを提供することにより、ネットワークを介して通信するように構成されてもよい。デバイス・ゲートウェイは、医療デバイスイベントトピックを発行（ｐｕｂｌｉｓｈ）することができる。デバイスアプリケーションは、ファシリティゲートウェイ上で実行する様に構成されており、医療デバイスイベントトピックを登録申込みするように構成されている。デバイスアプリケーションは、ＣＱＩメッセージトピックを発行することができる。デバイスアプリケーションは、医療デバイスイベントトピックに登録申込みすることによりイベントを受信し、ＣＱＩメッセージトピックを通して、イベントをＣＱＩメッセージとして発行するように構成することができる。医療デバイスは、ネットワークと動作可能に通信する。医療デバイスは、ウェブサービスを使用してデバイスゲートウェイと通信し、そしてウェブサービスのウェブメソッドを使用してイベントを生成するように構成されている。

【0028】

デバイス・ゲートウェイは、ＣＱＩメッセージを受信するために、ＣＱＩメッセージトピックに登録申込みをすることができる。システムは、さらに、ファシリティゲートウェイにより実行するように構成されるＣＱＩリスナーを含むことができる。ＣＱＩリスナーは、ＣＱＩメッセージを受信するために、ＣＱＩメッセージのトピックに登録申込みすることができる。ＣＱＩリスナーはＣＱＩメッセージを外部データベースに通信することができる。 ＣＱＩメッセージは、報告可能な生物医学イベントおよび／または報告可能な臨床イベントであってもよい。

【0029】

システムは医療デバイスと動作可能に通信するように構成された監視クライアントを含んでも良い。監視クライアントは、ＣＱＩメッセージトピックに登録申込みすることにより医療デバイスと通信することができる。

【0030】

他の実施形態では、電子患者ケアのためのシステムは、サーバーとポンプを含む（例えば、輸液ポンプやシリンジポンプ）。サーバーは、薬剤代謝の情報を含み患者に関連した情報を含む。ポンプは、薬剤代謝情報を用いて患者に関連する各情報に基づいて、患者への薬剤の流れを調整するように構成される。ポンプは、サーバーからの患者関連情報を受信する。

【0031】

いくつかの実施形態では、電子患者ケアのためのシステムは、サーバーとポンプを含む。
サーバーには、薬剤代謝の情報を含む、患者に関連した情報が含まれる。
ポンプは、薬剤代謝情報を用いて患者に関連する各情報に基づいて、患者への薬剤の流れを調整するように構成される。ポンプはサーバーから患者に関連した情報を受信する。

【図面の簡単な説明】

【0032】

これらおよび他の態様は、図面を参照して、本開示の種々の実施形態についての以下の詳細な説明からより明らかになるであろう。

【0033】

【図1】本開示の実施形態による、電子患者ケアのためのシステムのブロック図を示す。

【0034】

【図2】本開示の実施形態による、図１のシステムのいくつかの態様のブロック図を示す。

【0035】

【図3】本開示の実施形態による通信のためのいくつかの設備の集合を示す図である。

【0036】

【図4】本開示の実施形態による、電子患者ケアのためのシステムを示す図である。

【0037】

【図5】本開示の実施形態による、用量投与のライブラリファイルを生成するために使用される薬剤の安全性の方法を示す。

【0038】

【図6】本開示の一実施形態による、薬剤を注入する方法を示す。

【0039】

【図7】本開示の一実施形態による、ソフトウェア、ファームウェア、および／または設定ファイルを有する医療デバイスを更新する方法を示す。

【0040】

【図8】本開示の一実施形態による、医療デバイスとデバイスアプリケーションとの間の通信のいくつかの側面を説明するブロック図である。

【0041】

【図9】本開示の一実施形態による、注入デバイスのプログラム方法を示す状態図である。

【0042】

【図10】本開示の一実施形態による、図１のファシリティゲートウェイ及び図２及び図４のアプリケーションおよびデバイスゲートウェイにより使用される出版購読型モデルを示す。

【0043】

【図11】本開示の一実施形態による、ケイパビリティレジストリモデル（ｃａｐａｂｉｌｉｔｙ－ｒｅｇｉｓｔｒｙ ｍｏｄｅｌ）を示す。

【0044】

【図12】本開示の一実施形態による、医療デバイスとデバイスゲートウェイとの間の通信を説明するためのシステムブロック図である。

【0045】

【図13】本開示の一実施形態による、図１、２または４の医療デバイスとデバイスゲートウェイとの間の通信を容易にするためのウェブ法で使用するためのデータ構造の開示を示している。

【0046】

【図14】本開示の一実施形態による、医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0047】

【図15】本開示の一実施形態による、ステータスと通信チェックを実行するための医療デバイスとデバイス・ゲートウェイとの間の通信方法を示すフローチャートである。

【0048】

【図16】本開示の一実施形態による、それぞれのクロックを同期させるための、医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0049】

【図17】本開示の一実施形態による、患者への輸液注入トランザクションを実行するための医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0050】

【図18】本開示の一実施形態による、患者指示トランザクションを実行するための医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0051】

【図19】本開示の一実施形態による、患者のスカラーデータトランザクションを実行するための医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0052】

【図20】本開示の一実施形態による、デバイス情報トランザクションシーケンスを実行するための医療デバイスとデバイスゲートウェイとの間の通信方法を示すフローチャートである。

【0053】

【図21】本開示の一実施形態による警告通知トランザクションを実行するための医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0054】

【図22】本開示の一実施形態による、ソフトウェア・パッケージチェックトランザクションを実行するための医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0055】

【図23】本開示の一実施形態による、用量投与ライブラリ設定ファイルチェックトランザクションを実行するための医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0056】

【図24】本開示の一実施形態による、サービスログのポストトランザクションを実行するための医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0057】

【図25】本開示の一実施形態による、エンジニアリングログポストトランザクションを実行するための医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【0058】

【図26】本開示の一実施形態による、注入ログポストトランザクションを実行するための医療デバイスとデバイスゲートウェイ間の通信方法を示すフローチャートである。

【発明の詳細な説明】

【0059】

図１は、本開示の実施形態による、電子患者ケアのためのシステム１のブロック図を示す。システム１は、ファシリティＩＴアプリケーション／サービス１１、ファシリティ１０、およびクラウドサービス２を備える。

【0060】

ファシリティ１０は、病院、診療所、医療施設、外来診療センター、緊急ケアセンター、またはそれらの組み合わせ、またはそれらのグループ化したものとすることができる。ファシリティ１０は、ファシリティゲートウェイ２１を含むことができるので、様々な医療デバイス２６は、ファシリティＩＴアプリケーション／サービス１１および／またはクラウドサービス２と通信することができる。ファシリティ１０は、ファシリティ１０の介護を受ける患者を受け持つ看護師９が操作し使用する様々な医療デバイス２６を含む。医療デバイス２６は、輸液ポンプ、蠕動ポンプ、シリンジポンプ、生理学的パラメータの監視装置、その他の患者ケアのためのデバイス、またはそれらの組み合わせであっても良い。

【0061】

ファシリティゲートウェイ２１は、ホストコンピュータにあってもよく、クラウドにあってもよく、ファシリティ１０のためにサービスプロバイダにより保守されてもよく、サービスプロバイダおよび／またはファシリティのＩＴ要員１８の組み合わせによって保守又はサービスされてもよく、および／または仮想または現実環境において実施することができる。いくつかの実施形態では、ファシリティゲートウェイ２１は、患者の自宅のデバイスにおいて実施されてもよい。ファシリティゲートウェイ２１は、病院、看護グループ、統合配信ネットワーク（「ＩＤＮ」）、統合サービスグループや診療所、診療所のグループ、中央診療所、または他の医療ケア施設やインフラストラクチャで使用してもよい。

【0062】

生物医学用ＰＣツール２０は、デバイス２６のソフトウェアをアップデートする生物医学系技術者１９によって使用することができる。生物医学用ＰＣツール２０は、生物医学系ユーザー１９が、彼等の医療デバイス２６の状態を監視し、ログファイルを観察し、保守活動を追跡し、ソフトウェア／ファームウェアのインストールを管理するためのブラウザベースのツールであってもよい。
生物医学系技術者１９は、医療デバイス２６が良好な動作状態にあることを確実にするために、それらの機器にインストール、アップグレード、及びサービスを提供する病院の従業員（または契約サービス）であってもよい。
生物医学用ＰＣツール２０は、生物医学系技術者１９がこれらのサービスを実施することができるように、ＵＳＢ接続又はシリアルケーブル接続のような物理的データ接続により医療デバイス２６とのインターフェース接続をしても良い。生物医学系技術者１９はまた、デバイスマネージャ２４を使用してデバイス２６をワイヤレスで更新することができる。

【0063】

デバイス２６は、ファシリティＩＴアプリケーション／サービス１１（通信リンク３４３を介して）および／またはクラウドサービス２（通信リンク３４４を介して）とファシリティゲートウェイ２１を介して通信する。通信リンク３４３と３４４は、ＷｉＦｉ，イーサネット、ＴＣＰ／ＩＰ、ＷｉＭａｘ、光ファイバーケーブル、または任意の他の既知の通信技術を使いても良い。

【0064】

デバイス２６は、デバイスゲートウェイ２２と通信を確立する（例えば、登録を介して、）ことにより、ファシリティゲートウェイ２１と通信する。ファシリティゲートウェイ２１は、コンピュータ、仮想マシン、ハードウェアデバイス、ソフトウェアデバイス、ホストされているデバイス、実行中のソフトウェア等、それらの組み合わせであってもよい。
デバイスゲートウェイ２２はファシリティゲートウェイ２１により実行可能なソフトウェアであっても良い。デバイス２６は、ウェブサービスを用いてデバイスゲートウェイ２２と通信しても良い。
いくつかの特定の実施形態では、唯一の医療デバイス２６がデバイス・ゲートウェイ２２（及びしたがって、ファシリティゲートウェイ２１）との通信を開始する。デバイスゲートウェイ２２は、出版購読型（ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ）、及びポイントツーポイントルーティングメカニズム（ｐｏｉｎｔ－ｔｏ－ｐｏｉｎｔ ｒｏｕｔｉｎｇ ｍｅｃｈａｎｉｓｍ）の両方をサポートするメッセージルーティングエンジン（ｍｅｓｓａｇｅ ｒｏｕｔｉｎｇ ｅｎｇｉｎｅ）を含むことができる。デバイスゲートウェイ２２はまた名前の解決及びレジストリ能力（ｒｅｇｉｓｔｒｙ ｃａｐａｂｉｌｉｔｉｅｓ）機能を提供する。オブジェクト関係マッピング（Ｏｂｊｅｃｔ－Ｒｅｌａｔｉｏｎａｌ Ｍａｐｐｉｎｇ）は、小規模オブジェクトの永続化のためにデバイス・ゲートウェイ２２によって使用することができる（例えば、オブジェクト関係マッピング（ＯＲＭ）エンジンを使用して）。追加的または代替的に、デバイス・マネージャ２４は、名前解決および／またはレジストリ能力（ｒｅｇｉｓｔｒｙ ｃａｐａｂｉｌｉｔｉｅｓ）を提供することができる。

【0065】

本開示のいくつかの実施形態では、デバイス２６の一つのデバイスは、監視クライアント、例えば、タブレットコンピュータ、タブレットデバイス、ＰＤＡ、スマートフォン、ラップトップコンピュータ、またはタッチスクリーンベースのコンピュータである。デバイス２６の監視クライアントはデバイスアプリケーション２３内に監視クライアントアプリケーションを有していてもよく、デバイスアプリケーション２３は、介護者にデバイス２６の他のデバイスと通信することを可能にする。監視クライアントは、デバイス２６の一つの医療デバイスからステータス情報を受信し、デバイス２６の一つの医療デバイスからＣＱＩ－メッセージを受信し、デバイス２６の一つの医療デバイスからＲＢＥｓ又はＲＣＥを受信し、デバイス２６の一つの医療デバイスをプログラムし、又はそうでなければ、デバイス２６の一つの医療デバイスと通信するために使用することができる。

【0066】

デバイス２６とファシリティゲートウェイ２１との間の通信リンク３４３は、ＷｉＦｉ，イーサネット（登録商標）、ＴＣＰ／ＩＰ、ＷｉＭａｘの、光ファイバーケーブル、または任意の他の既知の通信技術を使いても良い。本開示のいくつかの実施形態では、デバイス２６は、携帯電話接続（例えば、通信リンク３４３は携帯電話接続を含む）を介してファシリティゲートウェイ２１と通信する。
例えば、一以上のデバイス２６は、患者の自宅、診療所内、現場施設（例えば、テント施設）、緊急の場所、他の場所、またはそれらの組み合わせの場所のいずれかにあっても良い。

【0067】

デバイスゲートウェイ２２は、以下のものを提供する：（１）コンポーネントレジストリおよびライセンス管理（例えば、デバイスマネージャ２４を使用）。 （２）インストール可能なコンポーネントの新しいバージョンを受信し、維持および追跡するためのインストール・リポジトリー、例えば、デバイスファームウェア／ソフトウェア、薬剤投与ライブラリ、エンタープライズ アプリケーションソフトウェア、およびインフラストラクチャソフトウェア（例えば、オペレーティング システムのリリース、アプリケーションサーバー、データベース管理システム（「ＤＢＭＳ」）；および／または（３）メッセージのルーティング能力、例えば、メッセージ配布を、ファシリティゲートウェイ２１内の両アプリケーション間および外部サブシステム（例えば、クラウドサービス２）との間の両方におけるものである。

【0068】

医療デバイス２６が、デバイスゲートウェイ２２へのアクティブなネットワーク接続を維持する配置環境は、接続された環境と呼ばれ、上で述べた様に
ワイヤレスネットワーク（ＩＥＥＥ８０２．１１ｂ／ｇ／ｎ）を使用して達成することができる。また前述したように、他の実施形態においては、ネットワーク接続は、携帯電話のような他の技術によって達成することができる。

【0069】

エンタープライズ・アプリケーション・コンポーネントと外部サブシステムがまだ接続されているという事実にもかかわらず、デバイスが無線接続を維持しない環境は標準的な環境と呼ばれる。この特定の実施形態では、デバイスゲートウェイ２２は、依然として、エンタープライズアプリケーションコンポーネントと外部サブシステムのすべての３つの役割を実行する。その一方、デバイス２６を巻き込むメッセージ交換は、外部メディア・デバイス（例えば、メモリスティック）にメッセージを保存するために生物医学技術者１９（例えば、生物医学用ＰＣツール２６を用いて）を使用することができる。

【0070】

デバイスアプリケーション２３のようなイベントの登録申込者は、イベントストリームを洗練して、デバイスゲートウェイ２２へ、より高いレベルのイベントを再発行して戻すことができる。報告可能な生物医学系イベント（Ｒｅｐｏｒｔａｂｌｅ ｂｉｏｍｅｄ ｅｖｅｎｔｓ）（「ＲＢＥ」）は、以下に説明する様に、このようなアプリケーションにより再発行されるイベントに属する。ＲＢＥは、クラウドサービス２にＣＱＩメッセージとして報告されることがある。いくつかの実施形態では、ファシリティゲートウェイ２１上で動作するアプリケーションは、ＲＢＥに登録申込みし、そしてファシリティゲートウェイ２１内のローカルデータベースにそれらを保存する生物医学系（ＢＩＯＭＥＤ）サーバーである。

【0071】

生物医学系技術者１９は、デバイスマネージャ２４にアクセスするために彼らのブラウザを使用して、そしてデバイス２６の一つのデバイスにデバイスステータスレポートを要求してもよい。デバイスマネージャ２４のＵＩは生物医学用サーバーにデータベースにアクセスして、生物医学系技術者１９のためにブラウザディスプレイのためのＨＴＭＬ／ＪＳページを生成する様に命令する。

【0072】

いくつかの実施形態では、医療デバイス２６の一つの新しいデバイスが、デバイス・ゲートウェイ２２によって使用することが許可される前に、生物医学系技術者１９はそのシリアル番号を使用して新しいデバイスを登録する必要がある。これは、非対称鍵（公開鍵／秘密鍵のペア）の暗号化を使用して確認することができ、製造工程の一部として実行されてもよい。医療デバイスの一つのデバイスがデバイスゲートウェイ２２に登録されると、生物医学系技術者１９は、無線プロトコルと暗号化の設定を行う。医療デバイス２６の内の一つの医療デバイスがデバイスゲートウェイ２２に登録されると、それは、モデル、オプション、およびハードウェア、ファームウェア、およびデバイスゲートウェイ２２および／またはデバイスマネージャ２４内に保存するためのデバイス制御ソフトウェアのバージョンを含む、その初期設定を報告する。同様に、デバイスが、デバイスゲートウェイ２２の許可されたデバイスのリストから削除された場合には、生物医学系技術者１９は、その登録を解除することができる。

【0073】

各々の医療デバイス２６は起動時にセルフテストを実行し、結果を格納するデバイスゲートウェイ２２のイベントを発行することができる。さらに、医療デバイス２６は、通常再起動の間の長い時間間隔をおいて実行されることがあるので、医療デバイス２６は、自動的にスケジュールを決めて、患者の安全および／または治療の妨げにならない時間に、一定の自己診断テストを実行することができる。

【0074】

ファシリティゲートウェイ２１は出版購読型データ接続を使用してデータを通信することができるデバイスアプリ２３を含む（後述する）。デバイスアプリ２３の各デバイスアプリはデバイス２６中の特定のタイプおよび／またはモデルのデバイスのためのものでも良い。これらのアプリケーションは、生のイベントを受信し、フィルタリングし、及び分析して、より高いレベルの解釈を再送信することによって、医療デバイスにソフトウェア情報を提供する。（医療デバイス２６の）各タイプの医療デバイスは（デバイスアプリケーション中の）対応するデバイスアプリケーションを持っている。

【0075】

ファシリティゲートウェイ２１はまたデバイス２６を制御、管理、または監視するためのデバイスマネージャ２４を含む。例えば、デバイスマネージャ２４は、デバイス２６の一つのデバイスの設定ファイルを更新および／またはデバイスにダウンロードするために使用することができる。前述のように、生物医学系技術者１９は、デバイス２６のソフトウェア、ファームウェア、または設定ファイルの更新を制御することができる。デバイスマネージャ２４は、患者ケアの配信をサポートするために使用される、ハードウェア、ソフトウェア、およびネットワークリソースの状態を監視するためにＩＴ管理者および／または技術者１８用のためにブラウザベースのツールを提供することができる。すなわち、ファシリティゲートウェイ２１は、ファシリティＩＴ職員／請負業者１８によって管理されてもよい。

【0076】

新しい用量投与ライブラリ（「ＤＡＬ」）バージョンがリリースされた場合は、
安全なメッセージングリンクは、生物医学系技術者１９にそれが利用可能であることを通知するために、ＤＡＬマネージャ５からデバイスゲートウェイ２２にＤＡＬファイルを送信することができる。この通知は、デバイスのタイプ、ＤＡＬの場所、ドキュメンテーション、リリースノ－トＵＲＬ、チェックサム、およびインストールの依存関係を明示する。本開示のいくつかの実施形態では、デバイス・マネージャ２４は、新たなＤＡＬファイルへのアクセスを有し、デバイスゲートウェイ２２からＤＡＬファイルを受信し、ＤＡＬマネージャ５から直接ＤＡＬファイルを受信し、および／またはＤＡＬファイルを使用して医療デバイス２２の更新を制御する。

【0077】

特定の実施形態では、生物医学系技術者１９は、アップグレードに関する情報にアクセスするためにリリースノートＵＲＬを使用し（例えば、デバイスマネージャ２４のウェブページおよび／または生物医学用ＰＣツール２０を介して）、インストーラＵＲＬ及びチェックサムを使用して、ＤＡＬファイルをダウンロードして、検証し、そしてデバイスゲートウェイ２２の保存場所に保存する。次に、生物医学系技術者１９は、新しいＤＡＬファイルが彼らのために利用可能であることが通知された（例えば、デバイスゲートウェイ２２を介して）一以上の医療デバイス２２を選択して新しいＤＡＬファイルをコピーする。
（更新されるように選択された医療デバイス２６の）医療デバイスの次の再起動では、医療デバイスの選択されたグループは、新しいＤＡＬのバージョン（エラー時にそれをバックアップ）をインストールし、結果をデバイスゲートウェイ２２および／またはデバイスマネージャ２４に通知する。ＤＡＬファイルを更新するために、本明細書に記載された手順のいずれも、ファームウェア、ソフトウェア、ＯＳ、または医療デバイス２６中の一つの医療デバイスの他の設定ファイルを更新するために使用することができる。

【0078】

ファシリティゲートウェイ２１はまた、デバイス２６、デバイスアプリ２３、および／またはデバイスマネージャ２４が、ファシリティＩＴアプリ１１の様々なデータベースと通信することを可能にする統合ＡＰＩ２５を含むことができ、そのデータベースには、例えば、患者情報システム１６、電子カルテ１７、コンピュータ化された医師オーダーエントリ１４、検査情報システム１５、リアルタイム位置情報サービス１２、および／またはその他のデータベースやサービス１３がある。統合ＡＰＩ２５は、ファシリティゲートウェイ２１内のコンポーネントがファシリティＩＴアプリケーション／サービス１１と相互に作用することを可能にする。ファシリティゲートウェイ２１は、無線リンク、有線接続リンク、ＴＣＰ／ ＩＰリンク、インターネットリンク、ソフトウェア通信リンク、ハードウェア通信リンク、または他の通信手法または技術、を含む通信リンク３４１を介してファシリティＩＴアプリ１１と通信することができる。

【0079】

電子カルテは、特定の患者の薬剤代謝データを含んでも良い。このデータは、臨床検査、遺伝子検査によるものであっても良く、または患者ケアデバイスからのフィードバックを使用して自動テストを形成することができる。
これらのテストの結果は、薬物が以下に迅速にまたはゆっくりと代謝されるか、に基づいて、患者に与えられる特定の薬物の量を調整するために医療用ポンプ２６によって使用されてもよい。

【0080】

ファシリティＩＴアプリ／サービス１１は病院の管理機能（例えば、入院、退院、移送、コ－ド化、課金、回収など）をサポートする。統合ＡＰＩ２５は、ファシリティＩＴアプリ１１のアプリケーション１２～１６と、アプリケーション２３－２４、デバイスゲートウェイ２２、および／またはデバイス２６における違いを分離する。例えば、デバイス２６の一つのデバイスはデバイスゲートウェイ２２からプログラミング情報を要求することができる（またはプログラミング情報は、デバイス１６の一つのデバイスに押し出されても良い）。
患者ＩＤ、ポンプＩＤ、薬剤、及び流量は一以上のファシリティＩＴアプリ１１に存在しても良く；統合ＡＰＩ２５は、ファシリティＩＴアプリ１１の必要又は要求に関係なく、この情報をデバイス２６に通信するための共通のフォーマットを提供する。この情報は、データを取得し、標準化された形式でデバイス２６にデータを提供するために、ファシリティＩＴアプリケーション１１の種々のアプリケーションについて照会する統合ＡＰＩ２５によって収集されてもよい。統合ＡＰＩ２５は、異なるフォーマット、データ標準、通信規格、暗号化標準等を有する様々なファシリティＩＴアプリ１２～１７により使用することが可能であるが、アプリケーション２２～２４および／またはデバイス２６との標準的なインターフェースを提供する。

【0081】

統合ＡＰＩ２５は、一以上のデバイス２６の自動プログラミングを容易にする。処方箋はファシリティＩＴアプリケーション１４のいずれか一つのサーバーから送信することができる。統合ＡＰＩ２５は、処方箋を受けてそれを再フォーマットしてデバイスゲートウェイ２２に送信する。ファシリティゲートウェイ２１は、永続的キャッシュに処方イベントを書き込む臨床サーバーを含むことができる。臨床サーバーは、自動プログラミングのワークフローを開始することができる。このワークフローは、対象患者に対応する医療デバイス２６中の一つの医療デバイスを識別し、処方箋を書き込むために、医療デバイス２６中の各デバイスにコマンドメッセージを送信することができる。
医療デバイス２６中のそれぞれの医療デバイスは処方箋の受信を確認し、ディスプレイ上に通知を表示する。臨床医は、薬剤バッグを探して、医療デバイス２６中のそれぞれの医療デバイスにバーコードリーダーを使用して、その薬剤と患者を確認することができる。
医療デバイス２６中のそれぞれの医療デバイスは、その後、薬剤が処方と一致しているかを確認することができ、そして臨床医は輸液注入を開始する。医療デバイス２６中のそれぞれの医療デバイスは、デバイスゲートウェイを介して臨床サーバーにメッセージを送信することにより、自動プログラミングワークフローを完了する。

【0082】

介護者は、医療デバイス２６中の一つの医療デバイスのプログラミングを確認するためにＵＩを使用する。臨床医は薬剤を見つけ出して、医療デバイス２６中の各医療デバイスのユーザー・インターフェースを使用して、医療デバイス２６中の各医療デバイスの自動プログラミングパラメータを確認するかおよび／または医療デバイス２６中のその医療デバイスを手動でプログラムする。

【0083】

ＰＩＳ１６は、処方薬の注文を受け、内容を確認し、追跡し、注文を満たす薬剤師８により使用される部門別システムである。ＥＭＲ１７システムは、医療機関において患者の病歴を追跡する（出会い、検査、診断、手続きなど）。 ＣＰＯＥ１４は、ラボテスト、処方薬、医療用画像および他の臨床手順を注文するために医師や看護師９によって使用されるシステムである。ＬＩＳ１５は、臨床サンプル（例えば、組織、血液、尿など）を受領し及びその処理をする実験技術者によって使用される部門別システムである。ＲＴＬＳ１２は医療デバイス２６の位置と状態を追跡調査する。その他の１３は患者のケアのために使用される任意の他のデータベースであっても良い。

【0084】

クラウドサービス２には、クラウドがホストである注入安全管理マネージャ３を含む。ＩＳＭ３は、継続品質改善（「ＣＱＩ」）マネージャ４とＤＡＬマネージャ５を含む。リスクオフィサー６、看護師マネージャ７、および薬剤師８の全ての人は、ＤＡＬマネージャ５を介してＤＡＬファイルの開発を容易にするために、ＣＱＩマネージャ４によって取得されたＣＱＩメッセージを確認することができる。ＤＡＬファイルは、その後、一以上のデバイス２６にダウンロードすることができる。ＤＡＬマネージャ５は薬剤エラーリダクションシステム（「ＤＥＲＳ」）エディタ（例えば、後述の図４のＤＥＲＳエディタ１１２）を含んでもよく、又はそれに関連している。

【0085】

図２は、本開示の実施形態による、図１のシステムのいくつかの態様のブロック図を示している。すなわち、図２は、図１のいくつかの態様の詳細を示している。

【0086】

デバイス・ゲートウェイ４０、デバイスマネージャ４１及び統合ＡＰＩ６５はすべて図１のファシリティゲートウェイ２１の部分である。
大容量アプリ４４、シリンジポンプアプリ５４、およびその他のアプリ４２はすべて、図１のデバイスアプリ２３の一部であるアプリケーションである。
その関連データベース４５を含むデバイスマネージャ４１は、図１のデバイスマネージャ２４であっても良い。

【0087】

大容量ポンプ（「ＬＶＰ」）アプリ４４は、ＬＶＰ３６のためのアプリケーションである。シリンジアプリ４３は、シリンジポンプ３８用のアプリケーションであり及び他のアプリケーション４２は、他のデバイス３９のためのアプリケーションである。他のアプリケーション４２及び他のデバイス３９は、任意の医療デバイスに対応してもよい。

【0088】

デバイス・ゲートウェイ４０は、出版購読型データ接続５８－６４を提供する。アプリケーション４２、４３、４４はまた、出版購読型データ接続４９－５７を提供する。出版購読型メッセージング・パターンは、デバイスゲートウェイ４０および／またはアプリケーション４１、４２、４３、４４、６５、７２の間の通信を提供する。しかし、追加の実施形態においては、他のメッセージング・パターンは、通信のために利用することができる。

【0089】

ＣＱＩリスナー７２は、ＣＱＩマネージャ２９にＣＱＩメッセージを報告するために、アプリケーション４２、４３、４４からの各種のデータ供給に登録申込みすることができ、ＣＱＩマネージャ２９はデータベース３０にそれらを保存することができる。ＣＱＩリスナー７２は、発行された接続４９－５７および／または５８－６４の生の結果を報告することができ、および／またはそれらをフォーマットすることができる。

【0090】

いくつかの実施形態では、アプリケーションは４２、４３、４４は、デバイス３６～３９のそれぞれのデバイスからの生のイベント（デバイスゲートウェイ４０に登録されたトピックに登録申込みすることにより受信される）をＣＱＩ－メッセージに再フォーマットする。アプリケーション４２、４３、４４は、ＣＱＩリスナー７２によって登録申込みされたＣＱＩ－トピックを登録してもよい。アプリケーション４２、４３、４４は、ＣＱＩリスナー７２にＣＱＩメッセージを受信させるようにするこれらのＣＱＩ－トピックにＣＱＩ－のメッセージを発行（ｐｕｂｌｉｓｈ）する。ＣＱＩ－リスナー７２は、クラウドサービス２８にＣＱＩメッセージを送信する。

【0091】

ある特定の実施形態では、単一のＧＵＩインターフェース３３はデータベース３０内のＣＱＩメッセージを見るために使用してもよく、一方、デバイス３６、３７、３８、及び３９による使用のためにＤＡＬファイル３５を作成する。
ソフトウェアアップデート３４は、また、医療デバイス３６、３７、３８、及び３９を更新するために、デバイス・ゲートウェイ４０に送信されても良い。

【0092】

図３は、本開示の実施形態に従った、通信のためのいくつかの施設（ファシリティ）７６－８０の集合体を示した図形７３を示す。いくつかの施設７６－８０は、それぞれ、注入安全管理マネージャ７４のようなクラウドサービスとの通信のためのファシリティゲートウェイ２１（図２参照）を含むことができる。
いくつかの実施形態では、いくつかの施設７６－８０は、施設７６－８０のグループ内にない他の施設がアクセスできない一般的な注入安全管理マネージャ７４を共有する施設のグループの一部である。

【0093】

図４は、本開示の一実施形態による電子患者ケアのためのシステム８１を示す図表である。システム８１は施設、例えば、病院ネットワーク８２、およびクラウドサービス８３を含む。

【0094】

病院ネットワーク８２は、病院情報ネットワーク８４、ＥＭＲ８５、ＣＰＯＥ８６、ＰＩＳ８７、ＬＩＳ８８、統合エンジン８９、統合能力コンポーネント９０、臨床状態マネージャ９１、データベース９２、９５及び９８、生物医学系アプリケーション９４、ＣＱＩリスナー９３、ポンプアプリケーション９６、シリンジアプリケーション９７、デバイスゲートウェイ９９、ファイアウォール１００、及び医療デバイス１０１を含む。いくつかの実施形態では、システム８４－８８は、病院ネットワーク８２の外部にあってもよい。
生物医学系技術者のチーム１０２は、生物医学系アプリケーション９４を使用する場合に利用することが可能である。

【0095】

クラウドサービス８３は、データベース１０４、１０５、１０６および１１３、ファイアウォール１０３、ＣＱＩ受信機１０８、ＣＱＩサーバー１０９、ＣＱＩ ＵＩ １１０、およびＤＥＲＳエディタ１１２を含む。薬局や臨床医１１１は、ＤＥＲＳエディタ１１および／またはＣＱＩ ＵＩ １１０にインターフェース接続することができる。安全スタッフ１０７は、ＣＱＩ ＵＩ １１０にインターフェース接続することができる。ＤＥＲＳエディタ１１２および／またはＣＱＩ ＵＩ１１０はブラウザベースのインターフェースであってもよい。

【0096】

ＨＩＳ８４は病院の管理機能（例えば、入院、退院、移送、コ－ド化、課金、回収）をサポートする。ＥＭＲ８５は、医療機関での患者の病歴を追跡する（出会い、検査、診断、手続きなど）。ＣＰＯＥ８６は、ラボテスト、処方薬、医療用画像および他の臨床手順を注文する医師によって使用されるシステムである。ＰＩＳ９７は、処方薬の受領、確認、追跡及び発注を完了させるために薬剤師によって使用される部門別システムである。ＬＩＳ８８は、臨床サンプル（例えば、組織、血液、尿など）の受領及びその注文処理をする実験技術者によって使用される部門別システムである。病院の統合エンジン８９は、情報システム８４－８８が互いにおよび外部システムと相互に作動することを可能にするメッセージ翻訳機能を提供する。これらのエンジンのほとんどは、ＨＬ７の異なる方言間をマッピングする。統合エンジンは、病院の統合エンジン８９を通して、ＨＩＳ、ＥＭＲとＰＩＳと相互作動するためにデバイスゲートウェイ９９に配置することができる。デバイスゲートウェイ９９は、メッセージルーティングエンジン提供し、出版購読型（ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ）およびポイントツーポイントルーティングメカニズム（ｐｏｉｎｔ－ｔｏ－ｐｏｉｎｔ ｒｏｕｔｉｎｇ ｍｅｃｈａｎｉｓｍ）の両方をサポートする。
デバイスゲートウェイ９９はまた、名前解決（ｎａｍｅ ｒｅｓｏｌｕｔｉｏｎ）と能力レジストリ機能を提供する。

【0097】

様々なデバイス１０１は、静脈内（ＩＶ）または皮下経路を介して患者に、液体状で薬剤、栄養と水分補給を提供する注入デバイスなどの様に患者を治療するために使用される。
ポンプアプリケーション９６とシリンジアプリケーション９７は、生イベントを受信し、フィルタリングしそして分析して、より高いレベルの解釈を再送信することによって、医療デバイス１０１にソフトウェアインテリジェンス（ｓｏｆｔｗａｒｅ ｉｎｔｅｌｌｉｇｅｎｃｅ）を提供するアプリケーションである。デバイス１０１の各タイプの医療デバイスは、対応するデバイスアプリケーション、例えば、アプリケーション９６－９７のいずれかを有することができる。

【0098】

デバイス１０１の各注入デバイスは、特定の患者に特定の注入液（液状での水分補給、栄養、血液または薬剤）を制御された形で配送するために用いても良い。装填（ｌｏａｄｉｎｇ）またはボーラス投与又は用量滴定の形態での投与用の調剤は親注入内の別個の注入段階であると考えることができる。同じ治療の一部として同じ患者に対する注入輸液の総体は、ＣＱＩサーバー１０９によって記録され得る「注入物語」（Ｉｎｆｕｓｉｏｎ Ｓｔｏｒｙ）と考えられる。

【0099】

注入は、セットアップ相、プログラミング相、および配送相に編成することができる。セットアップ相では、臨床医が注入液、患者とポンプを検証し、チューブを注入液からのポンプに、及びポンプから患者に接続し、それらはＣＱＩサーバー１０９によって記録することができる。プログラミング相の間、臨床医は、投与パラメーターをポンプに入力し、ポンプはインストールされたＤＡＬバージョン（これは、またＣＱＩサーバー１０９によって記録されてもよい）を用いてそれを確認する。配送相の間、ポンプはプログラムされた速度で指定されたボリュームの注入液を配送する。

【0100】

医療デバイス１０１の各々は、警報（ａｌａｒｍ）状態（すなわち、ポンプが注入していない状況）、また、安全にとって危機的である又はそうでない場合である、警告及び勧告が好ましい状態を検出することができる。医療デバイス１０１の各々は、デバイスゲートウェイ９９への安全なネットワーク接続を確立しようと試みることができる。医療デバイス１０１の各々は、それぞれの注入のためのプログラミング、配送状態と例外イベントを収集し、それらをＣＱＩ受信機１０８にＣＱＩメッセージとして報告することができるように、デバイス・ゲートウェイ９９に提供することができる。医療デバイス１０１のそれぞれは、これらのイベントをデバイスゲートウェイ９９に通信することができ、デバイスゲートウェイ９９は、このデータをＣＱＩ受信機１０８（直接的または間接的に）に送る。いくつかの実施形態では、もし医療デバイス１０１のある医療デバイスが、デバイスゲートウェイ９９と動作可能な接続を確立または維持できない場合は、その医療デバイスはこれらのイベントを内部バッファに保存し、それらを生物医学系技術者１０２が生物医学系アプリケーション９４を使用して又は使用せずに携帯型メディア（例えば、メモリスティック）にコピーすることを可能にすることができる。いくつかの実施形態では、これらのイベントは、医療デバイスに接続されたＵＳＢケーブルを有するパーソナルコンピュータで走行可能な生物医学系アプリケーションを介してダウンロードすることができる。

【0101】

生物医学系アプリ９４は、生物医学系ユーザー１０２が自分達の医療デバイス１０１の健全性を監視し、ログファイルを確認し、及びメンテナンス活動の状態を追跡し、ソフトウェア／ファームウェアのインストールを管理するために、生物医学系ユーザー１０２にブラウザベースのツールを提供する。
ログファイル、メンテナンスログ、およびソフトウェア／ファームウェアのインストールおよび追跡データの更新はデータベース９５に保存することができる。

【0102】

デバイスゲートウェイ９９は、特定の患者に関連するデバイス１０１の全てに結合する付随的機器であってもよい。他の実施形態では、デバイスゲートウェイ９９は、ファシリティゲートウェイ上で実行可能なソフトウェアアプリケーションである。さらに、他の実施形態では、デバイス・ゲートウェイ９９は、ベッドサイド機器（例えば、コンパクト・コンピュータ）上で実行可能なソフトウェアである。デバイス・ゲートウェイ９９は、メッセージルータ、サービス・レジストリ、および／またはポンプ許可レジストリであってもよい。デバイスアプリケーション９６～９７はメッセージタイプを登録し、ゲートウェイデバイス９９にメッセージを発行する（ｐｕｂｌｉｓｈ）ことができる。医療デバイス１０１（例えば、ＰＣＡに連結する呼吸モニター）のある医療デバイス（図２の「その他」３７を参照）に連結するセンサーを含み、医療デバイス１０１の任意の医療デバイスはゲートウェイデバイス９９を介してデータを発行（ｐｕｂｌｉｓｈ）するために使用することができる。デバイスアプリケーション９６－９７は「情報の精製装置」として働くことができる。各デバイスアプリケーション９６－９７は、ゲートウェイデバイス９９を経由して医療デバイス１０１の特定のタイプのベッドサイド装置のメッセージに登録申込みする。
各デバイスアプリケーション９６－９７は、ゲートウェイデバイス９９を介して一以上の医療デバイス１０１から受領したイベントストリームから、ＣＱＩ、臨床、および生物医学系情報を合成することができる。いくつかの実施形態では、それぞれのデバイス・アプリケーション９６－９７はこれらのより高レベルのイベントをデバイスゲートウェイ９９またはＣＱＩリスナー９３などの他の登録申込者に再発行（ｒｅ－ｐｕｂｌｉｓｈ）する。

【0103】

いくつかの実施形態では、ＣＱＩメッセージのいくつかは、自動ドキュメント化、自動プログラミング及び課金機能のために使用することができる。
いくつかのさらなる実施形態では、ＣＱＩメッセージは、医療デバイス１０１からＥＭＲ８５への自動ドキュメント化および／またはｅＭＡＲシステム（例えば、ＨＩＳ ８４の一部）からの医療デバイス１０１の自動プログラミングに使用され得る。ＣＱＩメッセージは、薬剤安全性イベントおよび潜在情報を含むことができる。

【0104】

ＣＱＩリスナー９３は、薬剤の安全性の継続的な品質改善に関連するイベントに登録申込みをし、ホスト管理された環境への信頼性の高い配送を確かにする。
ＣＱＩリスナー９３は、（ファイアウォール１０３を介して）ＣＱＩ受信機１０８へ定期的に伝送するためにデータベース９８にイベントを保存させることができる。

【0105】

ＣＱＩ受信機１０８、ＣＱＩサーバー１０９、およびＣＱＩ ＵＩ １０１は、ホスト環境８３（すなわち、クラウドサービス）において提供することができる。マスタースレーブ（ｍａｓｔｅｒ－ｓｌａｖｅ）データベース複製（データベース１０５はマスターとしておよびデータベース１０６はスレーブとして）は、ユーザーの問合せおよびＣＱＩデータ更新間の競合を低減するために、ホスト環境８３において使用しても良い。ＣＱＩサーバー１０９は、最上位の問合せ及び提示要求に対する応答時間を短縮するために、ＣＱＩイベントをデータベース１０５に記憶させる前に、サマリー（報告可能な）フォームで後処理する（ｐｏｓｔ－ｐｒｏｃｅｓｓ）ことができる。ＣＱＩ ＵＩ １１０は、一連の標準レポート（コンプライアンス、制限違反、滴定の安全性、ステージ毎のイベント、優先順位によるイベント）を提供することができる。ＣＱＩサーバー１０９は、ＤＥＲＳエディタ４４５およびＣＱＩ ＵＩ １１０によって使用されるために、問合せＡＰＩをより詳細なサマリー及び、特定のＣＱＩメッセージの詳細に掘り下げる様にサポートすることができる。

【0106】

ＣＱＩサーバー１０９は、ＣＱＩ ＵＩ １１０を使用するユーザーに分析および照会サービスを提供する。ＣＱＩサーバー１０９は、ＣＱＩ ＵＩ １１０のユーザーに、ＣＱＩメッセージのサマリーの全て及び更新サマリー表（設定可能な間隔で）を提供しても良い。これらのサマリー表の目的は、トップレベルのＣＱＩ問合せへの応答時間を短縮することである。
これらのサマリーは、以下の統計的測定方法をカバーすることができる：（１）ＤＥＲＳ制限対ワイルドカードを使用した注入の様な、使用されたプログラムモード；（２）ソフトおよびハード限界の違反；（３）滴定増加／減少の設定と用量限度違反の様な、滴定安全情報；（４）優先度レベルによる報告すべき臨床イベント（例えば、以下に説明する図８のＲＣＥ１４９）；および／または（５）注入段階による報告すべき臨床イベント（例えば、以下に説明する図８のＲＣＥ１４９）。これらのサマリーの各々は、次のデータ観察についてその小計を算出することができる：（１）組織名、（２）機関名（例えば、ファシリティ名）、（３）ケア（ｃａｒｅ）領域、（４）一日の時間および／または（５）週。

【0107】

ウェブサービス問合せＡＰＩは、ＣＱＩ ＵＩ １１０および／またはＤＥＲＳエディタ１１２が以下のものを選択することを可能にするために使用されても良い：（１）上に記載された、指定されたセレクタによってフィルタリングされた各データ観察のサマリー合計、（２）注入によるＲＣＥの詳細； および／または（３）実際のプログラミング、患者による制限及び注入の統計（すなわち注入物語）。いくつかの特定の実施形態において、ＤＥＲＳエディタ１１２および／またはホストサービス８３の任意のシステムは、Ｊ２ＥＥ準拠のアプリケーションサーバーに基づいていてもよい。データベース１０４、１０５、１０６、及び１１３はデータベース管理サーバーを使用してもよい。

【0108】

Ｊ２ＥＥおよびデータベース管理サーバーがインストールされ、設定が完了したら、以下の共有データベーステーブルがＤＥＲＳデータベース１１３の初期化を実行するためにインポートされることがある：
（1） 参照テーブル、例えば、測定単位、投与方法等；（２）管理ユーザーのためのアクセス制御テーブル、役割、権限および許可；（３）ＤＥＲＳ薬剤リスト（４）ＮＤＮＱＩケアグループリスト； （５）機関の属性、および／または（６）ＤＥＲＳエディタ１１２に必要なデータベーステーブル。
ＤＥＲＳエディタ１１２は、組織を追加または編集する、領域を追加または編集する、および／またはアクセス制御を追加または編集するために使用することができる（それぞれは属性を持つ又は持たない）。

【0109】

一実施形態では、ＤＥＲＳエディタ１１２および／またはＤＥＲＳデータベースは、複数のファシリティ８２のための単一のアプリケーションサーバー及びデータベース環境で実行することができる。さらに他の実施形態では、各機関８２は、独自の仮想環境でホストし／またはされてもよい（例えば、クラウドサービス２）。

【0110】

いくつかの特定の実施形態では、ＣＱＩ ＵＩ １１０および／またはＤＥＲＳエディタ１１２は、ウエッブラウザを実行しているユーザーに、ＣＱＩレポート及びインタラクティブなドリルダウン動作を生成するためにＨＴＴＰ／Ｊａｖａｓｃｒｉｐｔ（登録商標）のインターフェースをサポートすることができる。

【0111】

ＣＱＩメッセージは、データベース１０５にそれを記憶させるＣＱＩ受信機１０８により受領される。もし、ＣＱＩ受信機１０８が、所定の速度で入ってくるＣＱＩメッセージの全てを処理することが出来ない、および／またはＣＱＩ受信機１０８のバッファがいっぱいである場合は、ＣＱＩメッセージは一時的にデータベース１０４に保存され、ＣＱＩ受信機がアンロードされるときに、データベース１０５内に保存するためにデータベース１０４はＣＱＩ受信機１０８によってアクセスされる。データベース１０５は、データベース１０６によって複製されてもよい。データベース１０６は、ＣＱＩユーザーインターフェース１１０および／またはＤＥＲＳエディタ１１２のいずれかを使用してＣＱＩサーバー１０９を介してユーザーがアクセス可能である。

【0112】

ＣＱＩデータベース１０５、１０６の記録はＤＥＲＳエディタ１１２に依存する。記録は、次を含む：（１）参照テーブル、例えば、測定単位、投与方法等；（２）管理ユーザーのためのアクセス制御テーブル、役割、権限および許可；（３）ＤＥＲＳ薬剤リスト（４）ＮＤＮＱＩケアグループリスト； （５）機関の属性。

【0113】

これらの参照はＤＥＲＳエディタデータベースの１１３バージョンに依存しているので、一貫性のあることが好ましい。ある一つの選択肢は、データベース１１３、１０５、１０６間でテーブルを共有することである。この選択は便利であるが二つのデータベース１１３および１０５、１０６の間で展開のための結合を増加させる。代替的に、結合は、ＤＥＲＳエディタ１１２に変更が起きるときに常にそれらを更新する手順によって、ＣＱＩデータベース１０５、１０６内のこれらのテーブルの読み取り専用コピーを維持することにより減少させることができる。

【0114】

ＣＱＩデータベース１０５、１０６のためのアクセス制御は、ＤＥＲＳデータベース１１３とはその構造で類似しているが、内容において異なっていることもある。一部のユーザーはＣＱＩサーバー１０９のために定義することができるが、ＤＥＲＳエディタ１１２では定義されない。両方に現れるそれらのユーザーにおいても、権限が異なる場合がある（例えば、いくつかのＣＱＩデータは読み取り専用である）。

【0115】

特定のデータベーステーブル（例えば、報告すべき臨床イベントと統計のサマリー）は、ＣＱＩデータベース１０５、１０６により必要とされ、ＣＱＩデータベース１０５、１０６が作成されるときにセットアップされる。

【0116】

ＣＱＩ ＵＩ １１０および／またはＤＥＲＳエディタ１１２は、ＣＱＩサーバー１０９からデータ（及び、したがってデータベース１０６からのデータ）及びＤＥＲＳエディタ１１２からのデータ（したがって、データベース１１３と共に）を各々使用して、ＤＡＬファイル１１４を生成する。

【0117】

臨床状態マネージャ９１は、デバイスゲートウェイ９９と統合エンジン８９間の仲介者であり、いくつかの行為者及びコンポーネントを含む非同期ワークフローを組織化する。

【0118】

薬剤師と選ばれた臨床医１１１は、ＤＥＲＳエディタ１１２を使用してある機関のための投与限度を定義し、ＤＡＬファイル１１４（ＸＭＬ形式であってもよい）を作成する。投与限度は制御された放出手順により、明確に定義され、注意深く制御され、十分に文書化されたプロセスにより定義することができる。投与限度は、ＤＡＬマネージャ５のＤＥＲＳエディタ１１２を用いて特定することができる。ファシリティ８２は、後の機関の間の比較を容易にするに、薬剤、ケア領域、投与方法等の共通の参照モデルを使用することができる。ＤＥＲＳエディタ１１２は、ホスト環境８３で実行することができるので、ユーザーはウエッブブラウザを使用してそれにアクセスする。いくつかの実施形態では、ＤＥＲＳエディタ１１２を実行するためには、クライアント側ソフトウェアは、十分なブラウザ以外は必要とされない。ＤＥＲＳエディタ１１２は、ケア領域、薬剤、臨床使用および薬剤濃度によって編成される投与限度とデフォルト値を提供することができる。ＤＥＲＳエディタ１１２は、次のＤＡＬのバージョンの改善のためにＣＱＩ探求についての検索および分析を統合するために、 ＣＱＩサーバー１０９への問合せインターフェースをサポートすることができる。

【0119】

図５は、本開示の実施形態によるＤＡＬファイルを生成するために使用される薬剤安全方法１１５を示す。方法１１５は、図１のシステム１、図２のシステム２７、図４のシステム８１または任意の他の電子患者ケアシステムで使用することができる。

【0120】

製薬および臨床ケア領域からの参加者（例えば、図１の６、７、８、９、１８、及び１９または図４の１０２、１０７、１１１から選択されたユーザー）は、薬剤の種類、臨床ケア領域、投与方法を考慮することができる薬剤注入のための安全規則（例えば、量ベース、速度ベースまたは重量ベース、投与戦略（装填（ｌｏａｄｉｎｇ）、ボーラス、ランプ（ｒａｍｐ））などを含む、ＤＡＬファイル３５を生成し、定義する（図２参照）ことを支援するために選択されても良い。

【0121】

方法１１５は行為１１６と１１７を含む。行為１１６は行為１１８－１２５をサブ行為として含み、行為１１７は行為１２６－１２７をサブ行為として含む。
行為１１６はＤＡＬファイルを生成し、行為１１７はＤＡＬファイル３５を更新するためにＤＡＬファイルの使用を監視する（図２参照）。

【0122】

行為１２２は、例えば、分野のエントリのない初期ＤＡＬファイル又はテンプレートＤＡＬファイルのようなＤＡＬファイルをセットアップする。
行為１２３は、選択されたユーザーの１人からのエントリに従って、ＤＡＬファイルへの変更を受領する（例えば、図４のＧＵＩインタフェース１１２を介して）。行為１１２は、例えば、図４のＧＵＩインターフェース１１２を介して医療デバイスシミュレータを作動させることによりＤＡＬファイルを検討する。
行為１１２の間の検討の後に、パイロットＤＡＬファイルは行為１２０において（電子的に）リリースされる。行為１１８は、パイロットＤＡＬファイルを承認する。しかしパイロット（案内）が完了した後、ＤＡＬに調整がなされてもよい。行為１１８は、参照ファイル（例えば、バージョン番号、作成日等により参照される）の使用を承認するために、ウエッブブラウザ上で「承認」ボタンをクリックすることにより実行することができる。

【0123】

行為１１９において、ＤＡＬファイルがリリースされ、行為１２７において医療デバイスに送信される。行為１２５において、ＣＱＩサーバーはＤＡＬファイルから参照データ（例えば、薬剤、ケア領域、投与方法等）をインポートする。ＤＡＬのリリース時には、投与記録を含むファイルは、病院及びＣＱＩ環境の両方にリリースされる。生物医学系技術者は、行為１１９でのリリースの後に各々の注入デバイスにＤＡＬをインストールする。
行為１２６において、医療デバイスはＣＱＩイベントをＣＱＩ受信機１０８に送信する。

【0124】

注入の間、医療デバイスはＣＱＩイベント（すなわち、ＣＱＩメッセージ）を生成する。
ＣＱＩメッセージは、何時通常の注入が生じ、何時注入がＤＥＲＳチェックをバイパスするか、何時ソフト制限を超え、そしてオーバーライドされるか、および／または何時ソフトまたはハード制限を超えて、とりわけ、用量が再プログラムされるかの情報を含むことができる。

【0125】

ＣＱＩイベントは行為１２６において、ＣＱＩサーバーに送信され、ＣＱＩサーバーはそれを収集し保存する。安全担当者はこれらのイベントをまとめたレポートを実行し、行為１２４において、手続き改善の機会を特定するための掘り下げる機能を提供する。同様に、薬剤師、臨床医は、行為１２４において、ＤＡＬの次のリリースでの投与記録の改善の機会を特定するためにＣＱＩデータベースに照会することができる。すなわち、行為１２４において、ＣＱＩメッセージが分析や検討がされる。ＤＡＬファイルへの変更は、ＤＡＬのファイルの新しいバージョンを作成するため行為１２３で行うことができる。

【0126】

図６は、本開示の実施形態による薬剤を注入する方法１２８を示す。方法１２８は行為１２９、１３１，１３３、１３４、及び１３５を含む。方法１２８は、図１のシステム１、図２のシステム２７、図４のシステム８１又は任意の他の電子患者ケアシステムで使用することができる。

【0127】

行為１２９において、医師は、電子処方箋を書き込む。注文が、ＣＰＯＥ１３０に入力され、それは電子的に薬局に送信される。行為１３１において、薬剤師は発注をレビューし、薬剤相互作用および薬剤供給の評価を行い、処方箋を埋めるか又は処方を変更する、のいずれか（例えば、医師と協議の上）を実施する。また、行為１３１において、処方箋が完成され、注文がＰＩＳ１３２に提出される。行為１３３で処方箋が実行される。これは、以下の方法により（これらを含むが、これらに限定されるものではない）なされる：
既に所望の濃度の薬剤による事前に調製された合成物を用いて；
薬剤師が薬局において所望の投与量および濃度に配合；及び／又は臨床医（例えば、看護師）が、患者のベッドサイドで所望の投与量および濃度を配合する。

【0128】

次に、投与量が行為１３４で患者に投与される。入院患者の設定（病院や養護施設）では典型的には臨床医が用量投与を行う。外来または自宅の設定では、投与は、臨床医、患者の家族または患者自身が行っても良い。薬剤の安全性手順では、「正しい患者」、「正しい薬剤」、「正しい用量」、「正しい時期」と「正しいルート」のテストが満たされていることを確認する様に努める。これは、ベッドサイドポイントオブケアシステムにより、患者と薬剤をバーコード化することにより、及び／又は自動プログラミングを使用することを含む、種々の方法で達成することができる。ドキュメント化された記録は行為１３５で記録保管システムに提出される。患者のカルテを更新するために行為１３５においてドキュメントはＥＭＲシステムに提供される。

【0129】

図７は、医療デバイスのソフトウェア、ファームウェア、および／または本発明の実施形態による設定ファイルを更新する方法１３７を示す。方法１３７は、行為１３８―１４３を含む。方法１３７は、図１のシステム１、図２のシステム２７、図４のシステム８１又は任意の他の電子患者ケアシステムで使用することができる。

【0130】

行為１３８において、生物医学系技術者１９（図１参照）は、医療デバイスにソフトウェア、ファームウェア、または設定ファイルをインストールし（例えば、初めての場合）および／または行為１４０で、生物医学系技術者１９は医療デバイス上のソフトウェア、ファームウェア、または設定ファイルを更新する。行為１３９において、医療デバイスは構成または再構成される。
行為１３８、１３９および／または１４０は、無線によりまたは生物医学用ツール２０（図１参照）及び医療デバイスとの間の物理的接続を介して実行されてもよい。

【0131】

生物医学系技術者１９は行為１３８および／または行為１４０を実行することができる。
行為１４１で医療デバイス（例えば、ＣＱＩのメッセージなどを介して）が監視される。
いくつかの実施形態では、生物医学系技術者１９は注入デバイスからＣＱＩイベント・ファイルを、ポータブルメモリスティックへコピーすることができ、続いてＣＱＩへアップロードすることができる。行為１４１は以下のことを実行するのに使用しても良い：
デバイスが、何時予防保守をする必要があるかについての予定時期を認定する；
医療デバイスが、ソフトウェア、ファームウェア、設定ファイルやその他のアップデートとアップグレードをダウンロードする必要があるかどうかを認定する；
デバイスのログファイルをアップロードする；及び／又は他の診断および保守タスクを実行する。

【0132】

行為１４１は、医療デバイス（例えば、無線で）を監視する。行為１４２は医療デバイスに問題が見出されたかを決定する。問題は、例えば、医療デバイスが所定のパラメータの範囲内で動作していない、医療デバイスが内部エラーを検出している、および／または医療デバイスは、ソフトウェア、ファームウェア、または設定ファイルが古くなっているか等である。
行為１４３において、医療デバイスは、医療デバイスで識別された問題に対応して修復される。

【0133】

図８は、本開示の実施形態による、医療デバイス１４５（例えば、注入ポンプ）と、デバイスアプリケーション１５１（例えば、ポンプアプリケーション）との間の通信のいくつかの側面を説明するブロック図１４４を示す。ポンプ１４５は、図８を参照して本明細書に記載されているが、イベント１４６を生成するために、ポンプ１４５の代わりに、またはそれと共に、任意の他の医療デバイスを使用することが意図されている。

【0134】

ブロック図１１４には、イベント１４６（例えば、ポンプイベント）をデバイス・ゲートウェイ１４７に通信する医療デバイス１４５（例えば、注入ポンプ）が示されている。ポンプイベント１４６は、ＣＱＩメッセージであってもよく、ＣＱＩメッセージのための基礎であってもよく、またはそれは、医療１４５から生データのような他のデータであってもよい。ポンプイベント１４６は、操作パラメータ、配送パラメータ、および／または他の操作イベントであってもよい。いくつかの特定の実施形態では、ポンプイベント１４６は、ウェブサービス（「ＷＳ」）アドレス指定を用いたシンプル オブジェクトアクセスプロトコル（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）（「ＳＯＡＰ」）を使用してもよい。いくつかの実施形態では、イベント１４６は、フルＨＴＴＰ（又は、複数のＨＴＴＰ）プロトコルを使用しているレプリゼンテイショナル ステートートランス ファー（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）（「ＲＥＳＴ」）を使用して通信される。

【0135】

イベント１４６は、次のように表１に示すようなイベントであっても良い。

【表1】

【0136】

表１に項目１、２、３、４、５、６、７、８、および９としてリストされたものは、ポンプイベント類（ｐｕｍｐ ｅｖｅｎｔ ｃｌａｓｓｅｓ）である。医療デバイス１４５がデバイス・ゲートウェイ１４７に接続されていない場合には、これらのイベントは医療デバイス１４５のローカル・メモリ・バッファに記憶される。接続された場合（及び、再接続された場合には）、これらのイベントは安全なプロトコル、例えば、ＳＳＬ、ＳＳＨ、対称鍵暗号化、および／または非対称鍵暗号化を用いて、デバイスゲートウェイ１４７に発行される。前述したように、デバイス・ゲートウェイ１４７は、ポンプイベントを興味を持つ登録申込者に配信する様に構成された出版購読型エンジンとして機能することができる（または、それを含んでも良い）。

【0137】

再び図１を参照すると、ポンプイベントは、デバイス２６のデバイスイベントに関連するＣＱＩマネージャ４に送信されても良い。これらのイベントは、多くのファシリティ１０にわたる全医療デバイス２６の一群を監視するために使用することができる。例えば、デバイス ハードウェア ステータス アレイ（Ｄｅｖｉｃｅ Ｈａｒｄｗａｒｅ Ｓｔａｔｕｓ Ａｒｒａｙ ）９．７１はＣＱＩメッセージに変換されてもよく、そしてＣＱＩマネージャー４に伝達される。ユーザーは、保守イベントをスケジュールに記入するためにＣＱＩマネージャー４にログインし、データに基づいて新たな部品を注文し、予測又は予防保守を提供し、および／または予防的な理由または予測による理由で新しい部品を注文する。ユーザーは、何を注文するか、何時注文するか、および／または各種ファシリティ１０内の幾つかのデバイス２６の保守について何時フラッグを立てるかを決定するために決定論的発見的教授法（ｈｅｕｒｉｓｔｉｃｓ）を使用してもよい。ＣＱＩマネージャー４は、医療デバイス２６群の部品のサプライチェーン管理のために使用することができ、医療デバイス２６の群の全てのデバイスのステータスに関するリアルタイム情報を提供することができる。例えば、デバイス ハードウェア ステータス アレイは、内部バッテリーの健全性を示している満充電時の電流の様なバッテリー情報を含むことができる。
いくつかのファシリティの中で全てのデバイス２６又はデバイス２６のサブセットについては、バッテリーの状態が所定の閾値を下回った場合、ＣＱＩマネージャ４は、自動的に新しい電池を発注することができる。
追加的にまたは代替的に、ＣＱＩマネージャ４は、デバイス２６の内の、これらの識別されたデバイスにおいて自動的に電池を交換するスケジュールを組むことができる。

【0138】

再び図８を参照すると、デバイスアプリケーション１５１（例えば、ポンプを操作するために構成されたポンプアプリケーション）は、デバイス・ゲートウェイ１４７上で実行することができる（いくつかの実施形態では、これらは異なるハードウェアおよび／またはソフトウェアであってもよい）。
デバイスアプリケーション１５１は、医療デバイス１４５によって発行されたイベントに登録申込みをする。

【0139】

ポンプアプリケーション１５１は、生のイベントの流れを処理し、より高いレベルの臨床イベントの流れに整える。例えば、ホストクラウドサービスのサーバーに報告され、そこに保存される（例えば、図２のデータベース３０）様な、報告されるべき臨床イベント１４９である。

【0140】

本開示のいくつかの実施形態では、デバイスアプリケーション１５１は、メッセージ駆動型Ｂｅａｎ（「ＭＤＢ」）としてＪ２ＥＥアプリケーション・サーバーに配置される。ＭＤＢはジャバメッセーサービス（Ｊａｖａ（登録商標） Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）（ＪＭＳ）トピック、例えば、ポンプトピック（ＰｕｍｐＴｏｐｉｃ）１５０に登録申込みするステートレスコンポーネント（ｓｔａｔｅｌｅｓｓ ｃｏｍｐｏｎｅｎｔ）である、メッセージが利用可能になったとき、デバイスゲートウェイ１４７のアプリケーション・サーバーは、ワーカースレッド上でデバイスアプリケーション１５１を活性化することができる。

【0141】

デバイスアプリケーション１５１は、ステートフルコンポーネント（ｓｔａｔｅｌｆｕｌ ｃｏｍｐｏｎｅｎｔ）であり、各機関に配置される各ポンプ１４５に１つのポンプハンドラ（ｐｕｍｐ ｈａｎｄｌｅｒ）１５３の例（ｉｎｓｔａｎｃｅ）を含む。ポンプディスパッチャ（ｐｕｍｐ ｄｉｓｐａｔｃｈｅｒ）１５２は、ポンプ１４５のシリアル番号をユニークキー（ｕｎｉｑｕｅ ｋｅｙ）として使用して、ポンプ・ハンドラ１５３のルックアップテーブルを保持する。

【0142】

ポンプＭＤＢは、アプリケーション・サーバーのネーミングサービスを使用してポンプアプリケーション１５１にアクセスする。それはメッセージヘッダから、ポンプ１４５のシリアル番号を取得し、ポンプハンドラ１５３中の適切なポンプ・ハンドラを見つけ出すためにポンプディスパッチャ１５２を使用する。
ポンプハンドラ１５３のそれぞれのポンプハンドラが使用中である（他のメッセージを処理中、他のスレッドに係属など）場合、ポンプＭＤＢは、ポンプディスパッチャ１５２へのメッセージの待ち順に入れる（メッセージが順番に処理されていることを確認するため）。ポンプハンドラ１５３群のそれぞれのポンプハンドラがアイドル状態の場合、ポンプＭＤＢがポンプ・ハンドラ１５３群のそれぞれのポンプハンドラにイベントを処理する様に要求する。ポンプ・ハンドラ１５３群の各ポンプハンドラは、ポンプＦＳＭ１５６、プログラムＦＳＭ１５７及び配送ＦＳＭ１５８を含み、ポンプ・イベント（上記表１参照）の関連するサブセットを処理する一組の有限状態機械（「ＦＳＭ」）を保持する。

【0143】

ポンプＦＳＭ１５６は、何れの注入にも属していないイベントを処理するトップレベル状態機械（ｓｔａｔｅ ｍａｃｈｉｎｅ）である。プログラムＦＳＭ１５７は、注入プログラミングコンテキストが開始されたときに起動される子供状態機械であり、注入プログラミングイベントの処理に責任があるものである。配送ＦＳＭ１５８は、注入配送が開始されたときに起動される子供状態機械であって、注入中の操作イベントの処理に責任があるものである。
別のプログラミングＦＳＭ１５７と配送ＦＳＭ１５８は、一次注入の進行中に、二次注入（装填、ボーラス、または滴定を含み）をプログラムすることができるため、使用することができる。医療デバイス１４５の運転モデル、例えば、ポンプＦＳＭ１５６は、報告可能な臨床イベント（ＲＣＥ）を構築したり、報告可能な生物医学イベント（ＲＢＥｓ）を構築するために使用することができる。例えば、ポンプＦＳＭ １５６は、ポンプ１４５が一つの注入を完了し、中断した別の注入に戻った場合にポンプ１４５を追跡し；他の注入が実行されているときに、ある注入のプログラミングを追跡し；および／または一度に発生する可能性がある、複数の優先度の高い運転アラームを追跡してもよい。すなわち、ポンプ１５６ ＦＳＭは、入れ子状態モデル（ｎｅｓｔｅｄ ｓｔａｔｅ ｍｏｄｅｌ）を含んでいてもよい。

【0144】

ポンプ・ハンドラー１５３群の各ポンプハンドラは、また、プログラミングおよび配送コンテキスト情報を保持するためにいくつかのコンテキストオブジェクトを維持することができる。これらのコンテキストオブジェクトは、完成すると（トラッキングポンプ利用のための）生物医学イベントとして生成され、ポンプアプリケーション１５１が再起動する必要があるときに回復用に保持される。コンテキストオブジェクトは、注入状態、注入モード及び注入セグメントを含んでもよい。注入状態は、一次および二次注入のためのプログラミング／配送状態データを含む。注入モードは、特定の用量／速度（例えば、装填、ボーラス、および／または滴定）のプログラミング／配送状態データを含む。注入セグメントは注入モード内のある運用期間の配送状態（例えば、ポンプ可動、停止、警報状態など）を含む。ポンプイベント１４６を処理すると、各ＦＳＭ１５６、１５７、または１５８のそれぞれは、新しい状態に移り、コンテキストオブジェクトを作成、更新又は削除することができ、報告可能な生物医学イベント１４８または報告可能な臨床イベント１４９の様な報告可能なイベント（ＣＱＩメッセージ）を出力する。本開示の具体的な実施形態では、報告可能な臨床イベントのリストが以下の表２に示されている。

【表2】

【0145】

図４及び図８を参照すると、図４のＣＱＩリスナー９３は、各ファシリティ８２内を動き、デバイス・ゲートウェイ（図４の９９又は図８の１４７）に接続することができ、そしてＣＱＩ ＲＣＥ１４９またはＣＱＩ ＲＢＥｓ１４８に登録申込みすることができる。
図４のＣＱＩリスナー９３はホスト環境８３におけるＣＱＩ受信機１０８への安全なプライベート接続を確立することができる（図４参照）。この接続は、物理的な（連続的に接続されている）または論理的（メッセージを送信している間の一時的な接続）であってもよい。

【0146】

デバイスゲートウェイ１４７は、ＲＣＥｓ１４９またはＲＢＥｓ１４８をＣＱＩリスナー９３にルーティングすることができる。ＣＱＩリスナー９３はメッセージの耐久性を確保することができる（すなわち、ネットワークの混雑や断線によって送信中にメッセージが失われることがない）。その結果、ＣＱＩリスナー９３は：（１）（バッファリングのために）ローカルの待ち状態列（ｐｅｒｓｉｓｔｅｎｔ ｑｕｅｕｅ）に送信すべき各メッセージを保存する；（２）ＲＣＥｓ１４９および／またはＲＢＥｓ１４８の各々を列の先頭からＣＱＩ受信機１０８へ送信する；および／または（３）ＣＱＩ受信機１０８からの確認応答を受信した後メッセージを削除する、ことができる。

【0147】

ＣＱＩ受信機１０８はホスト環境８３内で作動する。ＣＱＩ受信機１０８は聴取し、１以上のＣＱＩリスナー９３からの安全なネットワーク接続の要求を受ける。ＣＱＩ受信機１０８は、接続された各ＣＱＩリスナー９３からのＲＣＥ１４９を受信する。ＣＱＩ受信機１０８は、メッセージの耐久性を確認することがあり、したがって、それを受領すると各ＲＣＥ１４９をデータベースに１０５に書き込む。ＣＱＩ受信機１０８は、（１）受信した各メッセージ（ＣＱＩメッセージ）を（バッファリングのために）ローカルの待ち状態列に保存する；（２）列の先頭から各ＣＱＩメッセージをＣＱＩイベント・データベース内のテーブルに追加する；（３）メッセージの受信を、メッセージを送信したＣＱＩリスナー９３へ確認する；及び（４）ローカル列からのＣＱＩメッセージを削除する（それはＣＱＩイベントデータベース１０５に安全に存在するため）。

【0148】

前述したように、ＣＱＩイベントデータベース１０５は、マスタースレーブ複写を使用して実行される。つまり、データベース１０５はマスターであり、データベース１０６はスレーブである。いくつかの具体的な実施形態では、このアプローチでは、同一の図式を持つＣＱＩイベント・データベースのコピーが２つ存在する。挿入、更新、および削除トランザクションがマスター・データベース１０５に適用されるので、データベース１０５内のデータベース管理システム（ＤＢＭＳ）は、ジャーナルに変更を書き込み、スレーブデータベース１０６に未送信の変更を送信することができる。

【0149】

各ＣＱＩメッセージ（例えば、ＲＣＥ）は、特定の機関に属するものであってよい。この機関の基準は医療デバイスを操作し、そのデバイスに配置されている薬剤管理ライブラリ（Ｄｒｕｇ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｌｉｂｒａｒｙ）（ＤＡＬ）をリリースした機関のものと一致する必要がある（例えば、図４の医療デバイス１０１の一つの医療デバイスまたは図８の医療デバイス１４５。その結果、ＣＱＩデータベース１０５、１０６ は、ＤＥＲＳデータベース１１３と一致している機関のリストを必要とするであろう。

【0150】

図９は、本開示の実施形態による注入デバイス（例えば、図１のデバイス１６のそれ）をプログラムする方法１６１を示す状態図である。方法１６１は、機器のＵＩとインターフェース接続が可能なユーザーから始まる。

【0151】

注入プログラミングは「開始」とラベルに記載の状態として示した状態で開始される。状態１６２は基本モードのプログラミングを使用する場合（例えば、ＤＥＲＳコンプライアンス例外デバイスが使用される場合など）である。
ＤＥＲＳコンプライアンス例外デバイスを使用してプログラミングした後、この方法は、用量プログラミングが完了した状態１６５に移行する。

【0152】

状態１６６はＤＥＲＳベースの保護が使用され、用量パラメータがデバイスにプログラムされた場合であり、制限違反が検出されない場合、状態１６５に移行する。もしソフト制限違反又はハード制限違反が検出された場合、方法１６１は状態１６７に移行する。もし、それがソフト制限である場合、臨床医は（１）ソフトウェアの制限を無視し、その結果方法は状態１６５へ続く；注入の意図を変えることなく注入属性をプログラムする、そして、新しい違反がない場合は状態１６５に続くか、新しい違反が発見された場合は、状態１６５に進むかの何れかであり；または（３）注入意図（薬剤、臨床ケア領域、臨床使用および／または濃度）を変更し、それにより方法１６１は状態１６６で再出発する。

【0153】

ハードの制限が検出された場合は、方法は、状態１６６から状態１６７に移行し、その場合には、状態は状態１６６へ戻る再移行が必要となり、臨床医がＤＥＲＳ違反を無視することはできない。

【0154】

注入方法１６１は、多くの状態においてキャンセルされる場合がある。基本モードプログラミング状態１６２において、プログラミングが完了する前に、臨床医は注入を中止することができる。ＤＥＲＳプログラミング状態１６６において、プログラミングが完了する前に、臨床医は注入を中止することができる。
状態１６７で、ＤＥＲＳソフト制限またはハード制限違反が検出された場合、臨床医は注入４を取り消すことができる。

【0155】

状態１６５の間、医療デバイスは「注入開始」ボタンを提示するが、介護者はこのボタンを押すことにより、注入が始まる状態１６３に医療デバイスを移行させることができる。
状態１６３において一時停止ボタンは、ユーザーインターフェース上に存在し、このボタンを押すとデバイスを一時停止させることができ、それによってデバイスを状態１６４へ移行させる。状態１６４において継続ボタンは、ユーザーインターフェース上に存在し、押すとそれによってデバイスを状態１６３へ戻し、治療を継続させる。致命的なエラー（所定のエラーのセット）が状態１６３および／または１６４で検出された場合、方法１６１は終了状態へ移る。

【0156】

注入が完了すると、ポンプは、デバイスゲートウェイを介して臨床サーバーに注入完了メッセージを送信する。臨床サーバーは完了イベントを処方記録にリンクする。臨床サーバーは、患者の電子カルテ（ＥＭＲ）１７更新し、および／または薬剤の成功注入を記録するために、病院の課金システムを更新するように、ＩＨＥ自動ドキュメントメッセージをフォーマットし、そして例えば、電子医療管理記録（「ｅＭａｒ」）に記録するために、それとＩＴアプリ１１（図１参照）の一つに送信する。

【0157】

図１０は、本開示の実施形態による、図１のファシリティゲートウェイ２１により、図２または図４のアプリケーション４１、４２、４３、４４及びデバイスゲートウェイ４０により使用される出版購読型モデル１６８を示す。

【0158】

このモデルは、発行者１７１が、一以上のトピック１７０を出版購読型エンジン１６９に登録することを可能とする出版購読型エンジン１６９を使用する。
トピック１７０が登録されると、一以上の登録申込者１７２は、トピック１７０を登録申込みすることができる。いくつかの特定の実施形態では、登録申込者１７２は、保証された登録申込み（ｇｕａｒａｎｔｅｅｄ ｓｕｂｓｃｒｉｐｔｉｏｎ）を使用してトピック１７０に加入することができる。発行者１７１群のある発行者がトピック１７０に関連したイベントを投稿すると、トピック１７０に登録申込みしている全ての登録申込者１７２は、出版購読型エンジン１６９からのデータを受信する。

【0159】

発行者１７１群のある一の発行者は、一以上のトピック１７０に登録することができ、各トピックはユニークなトピックであってもよい。１以上の登録申込者１７２は、そこからイベントを受領するため一以上のトピックに登録申込みすることができる。発行者１７１がトピック１７０中のユニークなトピック（例えば、「第１のトピック」）にイベントを投稿すると、トピック１７０の第１のトピックのすべての登録申込者はそのイベントを受信する、トピック１７０の第１のトピックへ登録申込者していない非加入者は、そのイベントを受信せず；トピック１７０の他のトピック（例えば、第２の光学系）に登録申込しているが最初のトピックに登録申込していない登録申込者１７２は、第１のトピックにのみ対応する送信されたイベントを受信しない。

【0160】

いくつかの実施形態では、トピック１７０は、発行者１７１と登録申込者１７２が匿名であることを可能にするある間接的なレベルを提供することができる。
出版購読型エンジン１６９は通信を一方向および非同期であることを可能にすることができる（例えば、「点火及びその後は処置不要」（“ｆｉｒｅ ａｎｄ ｆｏｒｇｅｔ”））。出版購読型エンジン１６９は、両方の側に、耐久性のあるメッセージ配信を提供することができる。トピック１７０中の耐久性のあるトピックは、出版購読型エンジン１６９が旨く作動しない場合にもメッセージが失われないことを保証することができる。登録申込者１７２によって使用される耐久性のある登録申込は、それが実行されていないときに、登録申込者１７２がメッセージを見逃すことがないことを確実にすることができる。

【0161】

出版購読型エンジン１６９は、デバイスゲートウェイ２２の一部であってもよいし、ファシリティゲートウェイ２１内のその他の任意のソフトウェアの一部であってもよく、又は図１のスタンドアローンアプリケーションであってもよい。出版購読型エンジン１６９は、アプリケーション４１～４４内でデバイスゲートウェイ４０の一部であってもよいし、又は図２のスタンドアローンのアプリケーションであってもよい。出版購読型エンジン１６９は、図４のデバイス・ゲートウェイ９９の一部であってもよく、アプリケーション９４、９６、９７の一部であってもよく、又は図４のスタンドアローンアプリケーションであってもよい。

【0162】

図１１は、本開示の実施形態による能力－レジストリモデル（ｃａｐａｂｉｌｉｔｙ－ｒｅｇｉｓｔｒｙ ｍｏｄｅｌ ）１７３を示す。プロバイダ１７６は、その能力１７５を能力レジストリ１７４に登録する。能力１７４は、インターフェースや属性を含む二つの側面を持つことができる。
インターフェースは、要求／応答のペアと（両方向への）通知のリストである。
属性は、配送の品質の制限（例えば、応答時間、エラー率と回復ポリシー、コストなど）を特定するサービスレベル合意パラメータである。

【0163】

イニシエータ１７７は、その能力を見つけ出し、そしてその能力に結合するために、能力 レジストリ１７４と通信することができる。
その後、イニシエータ１７７は、プロバイダ１７６から情報を要求し、応答を受け取ることができる。能力 レジストリ１７４は、デバイスゲートウェイ２２の一部であってもよいし、ファシリティゲートウェイ２１内の任意の他のソフトウェアの一部であってもよいし、又は図１のスタンドアローンアプリケーションであってもよい。能力 レジストリ１７４は、アプリケーション４１～４４内で、デバイスゲートウェイ４０の一部であってもよいし、または図２のスタンドアローンのアプリケーションであってもよい。能力レジストリ１７４は、図４のデバイスゲートウェイ９９の一部であってもよく、アプリケーション９４、９６、９７の一部であってもよく、又は図４のスタンドアローンアプリケーションであってもよい。いくつかの特定の実施形態では、能力 レジストリ１７４は、出版購読型エンジン１６９を補足しまたは代替することができる。

【0164】

図１２は、本開示の実施形態による医療デバイス１７９とデバイスゲートウェイ１８５との間の通信を説明するためにシステム１７８のブロック図を示す。
医療デバイス１７９は、デバイスゲートウェイ１８５と通信するためにデバイス・ゲートウェイ通信マネージャ（「ＤＧＣＭ」）３４２を利用してもよい。
通信は、医療デバイス１７９がクライアントであり、デバイスゲートウェイ１８５はＨＴＴＰＳ通信トランスポートを使用するウェブサーバーである、ウェブサービスに基づくことができる。

【0165】

通信は、医療デバイス１７９が、デバイスゲートウェイ１８５（例えば、医療デバイス ゲートウェイ）にホストされているウェブメソッドを呼び出すトランザクション（ｔｒａｎｓａｃｔｉｏｎ）形態をとる。医療デバイスは、イーサネット接続１８６を介してデバイスゲートウェイ１８５に結合されたネットワーク１８４に接続されたＷｉＦｉルータ１８３を使用して、デバイスゲートウェイ１８５と通信するＷｉＦｉ接続１８２を使用してもよい．特定の一実施形態では、ＴＣＰ／ＩＰは、ネットワーク１８４上にトランスポートプロトコルを提供する。ＳＯＡＰは、ＨＴＴＰに準拠したメッセージング形式を提供し、及びＳＳＬは安全な通信（ＨＴＴＰＳ）のために必要な暗号化／認証を提供する。医療デバイス１７９のソフトウェアの中で、通信マネージャは、ウェブサービス通信のクライアント側を管理する。

【0166】

通信マネージャは、ＨＴＴＰＳ上でＳＯＡＰメッセージングおよびＳＳＬを使用して、デバイスゲートウェイ１８５上でホストされるウェブメソッドの一つを呼び出すことによって、デバイスゲートウェイ１８５と通信する。これは、インターフェースを実行するために使用されるソフトウェア言語のためのＳＯＡＰバインディング１８７を使用することができる。さらに、ＳＯＡＰバインディング１８７は、ＨＴＴＰＳ上で安全な通信を提供するためにＳＳＬ能力を有してもよい。ウェブサービスオペレーション（ウェブメソッド１９５）とデバイスゲートウェイ１８５のウェブサーバーに必要な枠組み（ｓｃｈｅｍａ）を定義するウェブ－サ－ビス記述言語（“ＷＳＤＬ”）が作成される。ＷＳＤＬファイルが、ウェブメソッド１９５および使用されるデータ型のために作成されてもよい。ＷＳＤＬおよびＳＯＡＰプロバイダのユーティリティツールを使用して、ＳＯＡＰクライアント・ソース・コード・ファイルが生成され、通信マネージャソフトウェアに追加される。通信マネージャが正常にデバイスゲートウェイ１８５とのトランザクションを開始するためには、以下の事項が使用／セットアップされても良い：
（1） 医療デバイス１８５にインストールされているＯｐｅｎＳＳＬ１７９
（ソフトウェア１８１）；（２）デバイス・ゲートウェイ１８５のホスト名とＩＰポートが、データ構造１９２に保存；（３）医療デバイス１７９上にデバイスゲートウェイ１８５の公開証明データ構造１９３が存在する； 及び （４）医療デバイス１７０の秘密鍵と公開証明１９４が医療デバイス１７９上に存在する。

【0167】

デバイスゲートウェイ１８５は、ウェブサーバーとして構成され、デバイスゲートウェイ１８５から情報を取得し又はデバイスゲートウェイ１８５へ情報を送るために、リモートデバイス（例えば、医療デバイス１７９）がアクセスするウェブメソッド１９５をホストする。安全な通信のためにはＨＴＴＰＳが使用されるため、デバイスゲートウェイは、ＳＯＡＰ及びＳＳＬインターフェース１８７を使用することができる。ウェブサービス操作（例えば、ウェブメソッド１９５）とウェブサーバーに必要なデータ型を定義するＷＳＤＬファイルを作成することができる。ＷＳＤＬファイルは、ウェブメソッド１９５および必要なデータ型のために作成されている。ＷＳＤＬおよびＳＯＡＰプロバイダのユーティリティツールを使用して、ＳＯＡＰサーバーのソースコードファイルが生成され、ゲートウェイ機能１８８を提供を容易にするためデバイスゲートウェイ１８５ソフトウェアに追加される。デバイスゲートウェイ１８５が医療デバイス１７９からのトランザクションを処理するためには、以下の事項が使用／セットアップされても良い：
（１） デバイスゲートウェイ１８５上にインストールされたＯｐｅｎＳＳＬ
１８７（または同等のソフトウェア）であり、デバイスゲートウェイ１８５は通信ポート１８９およびネットワーク接続１９１を提供することができる；
（２）医療デバイス１７９の公開証明は、データ構造１９０内のデバイスゲートウェイ１８５上に存在することができる、及び／又は（３）デバイスゲートウェイ１８５の秘密鍵と公開証明はデータ構造１９０内のデバイスゲートウェイ１８５上に存在する。

【0168】

ウェブサービスの実施は、通信を確立し情報を交換するために医療デバイス１７９とデバイス・ゲートウェイ１７９との間の通信インターフェースを定義する。
この通信は、ウェブメソッド１９５にホストされたデバイスゲートウェイ１８５を呼び出すことによって開始されるトランザクションの形である。
４つのウェブメソッドが、医療デバイス１７９（ＤＧＣＭ３４２を使用）とデバイスゲートウェイ１８５との間で情報を渡すために使用される。
ウェブメソッドは、デバイス・ゲートウェイ１８５上でホストされ、デバイス・ゲートウェイ１８５との情報交換トランザクションを開始するためにＤＧＣＭ３４２によって呼び出される。それぞれのウェブメソッドは、表３に確認されるように、特定のタイプの移動情報（ｉｎｆｏｒｍａｔｉｏｎ ｍｏｖｉｎｇ）のために使用することができる。ある特定の実施形態では、これらのトランザクション及び関連するウェブメソッドのリストを以下の表３に示す。

【表3】

【0169】

通信ステータスチェックトランザクション（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｔｕｓ Ｃｈｅｃｋ ｔｒａｎｓａｃｔｉｏｎ）は、医療デバイス１７９をデバイスゲートウェイ１８５に登録し、デバイスゲートウェイ１８５との通信を維持し、及びデバイス・ゲートウェイ１８５が、医療デバイス１７９のために保持している利用可能な情報に関するステータスを取得するために使用される。患者注入プログラムチェック（Ｐａｔｉｅｎｔ Ｉｎｆｕｓｉｏｎ Ｐｒｏｇｒａｍ Ｃｈｅｃｋ）は、患者指示チェック（Ｐａｔｉｅｎｔ Ｉｎｓｔｒｕｃｔｉｏｎｓ Ｃｈｅｃｋ）、患者のスカラー・データチェック（Ｐａｔｉｅｎｔ Ｓｃａｌａｒ Ｄａｔａ Ｃｈｅｃｋ）、デバイス情報チェッ（Ｄｅｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈｅｃｋ）、警告通知チェック（Ａｌｅｒｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｃｈｅｃｋ）、Ｄｅｂｉａｎソフトウェアパッケージチェック（Ｄｅｂｉａｎ Ｓｏｆｔｗａｒｅ Ｐａｃｋａｇｅ Ｃｈｅｃｋ）、及びＤＡＬ構成ファイルチェック（ＤＡＬ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｆｉｌｅ Ｃｈｅｃｋ）トランザクションは、デバイスゲートウェイ１８５からの従前の通信ステータスチェック応答の範囲で認定された、利用可能なデバイスゲートウェイ１８５情報を取得するために使用される。
サービスログファイルポスト及びエンジニアリングログポストトランザクション（Ｓｅｒｖｉｃｅ Ｌｏｇ Ｆｉｌｅ Ｐｏｓｔ ａｎｄ Ｅｎｇｉｎｅｅｒｉｎｇ Ｌｏｇ Ｆｉｌｅ Ｐｏｓｔ ｔｒａｎｓａｃｔｉｏｎｓ）は、デバイスゲートウェイ１８５からの、従前の通信ステータスチェック応答の範囲で認定された、ログファイルをデバイスゲートウェイ１８５に送信するために使用される。医療デバイス１７９内で利用可能な注入ログイベントが、デバイスゲートウェイ１８５に送信されていないときは、いつでもデバイスゲートウェイ１８５への注入ログ情報ポストトランザクション（Ｉｎｆｕｓｉｏｎ Ｌｏｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｏｓｔ ｔｒａｎｓａｃｔｉｏｎ）は開始される。ファイルは、医療デバイス１７９とデバイスゲートウェイとの間で、ＳＯＡＰメッセージへのＤＩＭＥ添付として転送することができる。時刻情報チェックトランザクション（Ｔｉｍｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈｅｃｋ ｔｒａｎｓａｃｔｉｏｎ）は時刻同期のためにデバイスゲートウェイ１８５の時間を取得するために使用される。

【0170】

ウェブメソッド１８４は、デバイス・ゲートウェイ１８５から情報を取得し、デバイスゲートウェイ１８５に情報を渡すために使用される。
ウェブメソッド１８４は、それらのＣ－スタイル プロトタイプと共に表４に示す。

【表4】

【0171】

いくつかの実施形態では、各渡されたパラメータは、データ構造またはｉｎｔ（すなわち、Ｃ言語における整数データタイプ）であってもよい。他の実施形態では、任意のデータ型を渡すことができる。データ構造宣言は図１３に示される。すべてのデータ構造メンバーのポインター（ｇＳＯＡＰの実施により必要とされるデータ構造であるｄｅｖｉｃｅ＿Ｉｍａｇｅ＿Ｔ１９９以外）はゼロで終わる文字列である。
ウェブメソッド内のパラメータリストは、デバイス・ゲートウェイ１８５に情報を渡すための１以上のパラメータ（図１２参照）及びデバイスゲートウェイ１８５から情報を受信するための一つのパラメータを含む。情報を渡すためのパラメータは、値により、参照により、ポインターであっても良い。情報を受信するためのパラメータは、常にパラメータリストの最後にあり、参照されるデータ・タイプ（＆ｄａｔａＴｙｐｅ）である。ウェブメソッドが返すための情報を持っていない場合でも、受信パラメータは依然として必要とされる。例えば、ｄｅｖｉｃｅ＿ｉｎｆｕｓｉｏｎＳｅｎｄＴｒａｎｓａｃｔｉｏｎ（．．．， ｉｎｔ＆ｒｅｓｕｌｔ）とｄｅｖｉｃｅ＿ｆｉｌｅＳｅｎｄＴｒａｎｓａｃｔｉｏｎ（．．．，ｉｎｔ＆ｒｅｓｕｌｔ）がこの要件を満たすために“＆ｒｅｓｕｌｔ”を使用する。

【0172】

各ウェブメソッドは、イニシエータにトランザクション完了の状態を識別させる、戻り値を持っている。戻り値の例示的なセットを、次のように表５に提供する。

【表5】

【0173】

図１３を再び参照すると、ｄｅｖｉｃｅ＿Ｈｅａｄｅｒ＿Ｔ１９７のメンバーポインターが示されており、以下の表６に記載されている。

【表6】

【0174】

ｄｅｖｉｃｅ＿ＩｎｔｅｒｎａｌＳｔａｔｕｓ＿Ｔ１９８のメンバーポインターが示されており、以下の表７に記載されている。

【表7】

【0175】

図１２－１３を参照すると、ｄｅｖｉｃｅ＿ＣｌｉｅｎｔＲｅｑｕｅｓｔ＿Ｔ２００は、医療デバイス１７９の通信マネージャがデバイスゲートウェイ１８５から要求する情報の種類を識別する。特定の一実施形態では、ｄｅｖｉｃｅ＿ＣｌｉｅｎｔＲｅｑｕｅｓｔ＿Ｔ２００を使用する要求が示され、以下の表８に記載されている。

【表8】

【0176】

ｄｅｖｉｃｅ＿ＧａｔｅｗａｙＲｅｓｐｏｎｓｅ＿Ｔ２０１は、受信した要求に対するデバイスゲートウェイの１８５応答を提供する。
状態（例えば、ｃｈａｒ＊ｓｔａｔｅ＿ｐｔｒ）の典型的な実施形態及びそれらの説明を、以下の表９に示す。

【表9】

【0177】

Ｃｈａｒ＊ｐａｙｌｏａｄ＿ｐｔｒは、デバイス１７９の通信マネージャを介して、医療デバイス１７９によって要求される情報を提供する。

【0178】

ｄｅｖｉｃｅ＿ＦｉｌｅＤａｔａ＿Ｔ２０３は、デバイスゲートウェイ１８５に送られるファイルの種類を識別する。ファイルタイプの典型的な実施形態及びその説明は以下の表１０に示す。

【表10】

【0179】

ｄｅｖｉｃｅ＿ＦｉｌｅＲｅｓｐｏｎｓｅ＿Ｔ２０４は、受信した要求に対するデバイスゲートウェイ１８４の応答を提供する。その状態の典型的な実施形態及びその説明は以下の表１１に示す。

【表11】

【0180】

ｃｈａｒ＊ｆｉｌｅｎａｍｅ＿ｐｔｒはデバイスゲートウェイ通信マネージャ３４２に転送されたファイルを特定する。ｄｅｖｉｃｅ＿ＩｎｆｕｓｉｏｎＤａｔａ＿Ｔ２０２のｃｈａｒ ＊ｐａｙｌｏａｄ＿ｐｔｒは、注入ログ情報をデバイスゲートウェイ１８５にＸＭＬとして提供する。ペイロードがＸＭＬ要素として編成され、ルート要素と子要素がある。

【0181】

図１４は、本開示の実施形態による医療デバイスとデバイスゲートウェイとの間の通信方法２０５を示すフローチャートである。すなわち、方法２０５は、医療デバイス（ＤＧＭを使用して）とデバイスゲートウェイとの間の汎用トランザクションシーケンスである。
方法２０５は、それぞれのトランザクションを実行するために、図１５－２６に示す方法により使用することができる。

【0182】

一般的に、トランザクションは、デバイスゲートウェイにホストされるウェブメソッドを呼び出す医療デバイスのＤＧＣＭ３４２から構成される。この行為は、デバイスゲートウェイとＨＴＴＰＳ接続を確立する。
接続確立中に、安全／信頼関係を確立するために医療デバイスとゲートウェイデバイスとの間で非対称暗号化を使用して認証が行われる。一度、認証が行われるとＳＳＬセッションが確立され、２つのエンドポイントは、共通鍵を作成し、データを渡すための対称暗号化を使用する。トランザクションは処理され、情報が返され、そしてＨＴＴＰＳ接続を終了する。成功したトランザクションの実現までに、最大３つのトランザクションの再試行が実施される。図１４は、ある特定の実施形態、すなわち、このトランザクションの方法２０５、を示す。

【0183】

方法２０５は行為２０６から２３２を含む。行為２０６で方法に入る。行為２０７は、デバイスのゲートウェイ認証を開始し、証明を要求する。ソケット接続（ｓｏｃｋｅｔ ｃｏｎｎｅｃｔｉｏｎ）が行為２２３で確立される。
行為２２４で、デバイスゲートウェイは要求を受信し、医療デバイスへ公開証明を送信する。行為２０８において、医療デバイスは、ローカルコピーと比較することによって、公開証明を有効にする。行為２０９において、医療デバイスは、デバイスゲートウェイが、データ（例えば、デバイスゲートウェイのシリアル番号やＩＤ番号などの所定のデータ）を暗号化することにより、その身元を証明することを要求する。データは、その後、医療デバイスからデバイスゲートウェイへ送信される。

【0184】

その後、デバイスゲートウェイは行為２２５中において、その秘密鍵を使用してメッセージ（例えば、デバイスゲートウェイのシリアル番号やＩＤ）を暗号化し、暗号化されたメッセージを医療デバイスに送信する。
行為２１０において、メッセージはデバイスゲートウェイの公開証明を使用して復号化される。

【0185】

行為２２６は、公開証明を要求することによって、医療デバイス認証を開始するが、公開証明は医療デバイスによって受信され、医療デバイスは行為２１１において公開証明をデバイスゲートウェイに送信する。行為２２７において、デバイスゲートウェイは、ローカルコピーと比較することによって、公開証明を有効にする。行為２２８において、デバイスゲートウェイは、医療デバイスがいくつかのデータ（例えば、医療デバイスのシリアル番号やＩＤ番号などの所定のデータ）を暗号化することにより、その身元を証明することを要求する。

【0186】

行為２１２において、医療デバイスはデータ（例えば、所定のデータ）を暗号化する。暗号化されたデータは、行為２２９でデータを復号化するデバイスゲートウェイに送信される。行為２３０で、デバイスゲートウェイは、医療デバイスが認証されたか否かを決定し、行為２１３で医療デバイスは、デバイスゲートウェイが認証されたか否かを決定する。
両者が認証された場合は、行為２１４はセッションキーを確立する。行為２３０でデバイスゲートウェイが医療デバイスを認証できない場合は、トランザクションは行為２３１で終了される。もし医療デバイスがデバイスゲートウェイを認証できない場合は、医療デバイスは最大３回まで認証を試み（２１９を参照）、そしてトランザクションは３回の試行後に、行為２２０において失敗したとみなされる。

【0187】

行為２１４でＳＳＬセッションが確立された後、行為２１５で、医療デバイスはトランザクション（例えば、ウェブメソッド）をフォーマットし、デバイスゲートウェイにトランザクションを送信するために、ＳＳＬ対称暗号鍵を使用する。行為２３２は、ウェブメソッドを受信し、ウェブメソッドを処理し、応答をフォーマットした後、ウェブメソッドを復号化する。行為２３２は、医療デバイスに送信される応答（例えば、戻り値）を暗号化する。医療デバイスは応答を復号化し、行為２１６で戻り値を調べる。
行為２１７において、医療デバイスは、戻り値は成功したトランザクションに対応するかを決定し、行為２１８でトランザクションが成功したことを宣言する。トランザクションが成功しなかった場合は、行為２１７は行為２１９によって他の試みを開始する。

【0188】

図１５は、本開示の実施形態による、ステータス及び通信チェックを実行するために、医療デバイスとデバイス・ゲートウェイとの間の通信方法２３３を示すフローチャートである。通信ステータスチェックトランザクションは、デバイス・ゲートウェイとの通信を確立し（切断から接続へ移る）、デバイス・ゲートウェイとの通信を維持する（接続を維持する、切断へ移る）、及びデバイスゲートウェイが医療デバイスのために保持している利用可能な情報についてのステータス情報を取得するために、定期的に、ＤＧＣＭ３４２によって開始される。

【0189】

方法２３３には、行為２３４－２３８と２４０－２４１が含まれる。行為２３４は、６０秒ごとにステータスチェックを開始する。行為２３４は、ステータスチェック要求（例えば、ＤＧＣＭ３４２がそれを受信）を受信する。行為２３６は、要求を送信し、行為２４１においてＨＴＴＰＳ接続を確立する。表２３９は、デバイスゲートウェイにアクセス可能な医療デバイスのアクセスリストを示す。

【0190】

行為２４０において、デバイスゲートウェイは、その医療デバイスがアクセスリスト２３９にあるか否かを決定し、医療デバイスのために利用可能である情報を含む応答を策定する。応答は行為２３７でそれをチェックする医療デバイスに送信される。

【0191】

医療デバイスがデバイスアクセスリスト２４８のメンバーでない場合は、デバイス・ゲートウェイは応答状態を「拒否」（ＲＥＪＥＣＴＥＤ）に設定する。
情報が医療デバイスにとり使用できない場合は、デバイスゲートウェイは、入手可能な情報を「なし」（ＮＯＮＥ）に設定し、それ以外の場合は
ＸＭＬベースの応答ペイロード内の適切な要素を、以下のように表１２の値に設定する。

【表12】

【0192】

図１６は、本開示の実施形態に従って、それぞれのクロックを同期させるための医療デバイスとデバイスゲートウェイとの間の通信の方法２４２を示すフローチャートである。方法２４２は、デバイスゲートウェイの現在の日付と時刻を取得するために、医療デバイスのＤＧＣＭによって定期的に時刻同期トランザクションを実行する。医療デバイスのリアルタイムクロックをデバイスゲートウェイのリアルタイムクロックと一致させるように、その情報は医療デバイスのリアルタイムクロックを更新するために使用される。

【0193】

行為２４３は、定期的に（例えば、９０分ごと）、「時間」要求を行う。その要求は、行為２５０でＨＴＴＰＳ接続を確立することにより、デバイスゲートウェイにそれを通信する行為２４５でウェブメソッドとしてフォーマットされる。
行為２４９で、応答はフォーマットされ、それはデバイスゲートウェイの時間を示すペイロードを含む。もし医療デバイスが、デバイスゲートウェイのアクセス・リスト２４８のメンバでない場合は、状態は「拒否」（ＲＥＪＥＣＴＥＤ）に設定されそうでなければ「利用可能」（ＡＶＡＩＬＡＢＬＥ）に設定される。
もし状態が「利用可能」に設定される場合は、デバイスゲートウェイは応答ペイロードを１９７０年１月１日からの経過秒数としてフォーマットする。
デバイスゲートウェイは、送信後に行為２４７で閉鎖されるＨＴＴＰＳ接続を介して応答を伝達する。行為２４６は、デバイスゲートウェイにより応答を検証する。

【0194】

図１７は、本開示の実施形態による患者注入トランザクションを実行するための医療デバイスとデバイスゲートウェイとの間の通信の方法２５１を示すフローチャートである。方法２１５として実行される患者注入プログラムチェックトランザクションは、デバイスゲートウェイから利用可能な患者注入プログラムを取得するために開始される。患者注入プログラムは、一以上の注入パラメータであってもよく、例えば、流量、配送投与量、注入される薬剤などである。
「注入利用可能」が前の通信ステータスチェックトランザクションから受信されると常にトランザクションが開始され、方法２５１を開始させるトリガ（契機）となる。

【0195】

行為２５２は、トリガを受信する。行為２５３は、行為２５４でウェブメソッドにフォーマットされる「プログラム」要求を開始する。ウェブメソッドは、行為２５９で確立されるＨＴＴＰＳ接続を介してデバイスのゲートウェイに送信される。行為２５８はウェブメソッドを処理しそして応答をフォーマットする。医療デバイスがアクセスリスト２５７の一部でない場合、デバイスゲートウェイは、応答状態を「拒否」（ＲＥＪＥＣＴＥＤ）に設定する。
患者注入プログラムが医療デバイスで利用できない場合、状態は「なし」（ＮＯＮＥ）に設定され、そうでなければ、それは「利用可能」（ＡＶＡＩＬＡＢＬＥ）に設定される。
注入プログラムはペイロードの一部であってもよく、またはテキストベースの注入プログラムを参照してもよい。応答は、行為２５５においてトランザクション応答をチェックする医療デバイスに送信される。応答が送信された後、行為２５６はＨＴＴＰＳ接続を終了する。

【0196】

図１８は、本開示の実施形態に従って、患者指示トランザクションを実行するために、医療デバイスとデバイスゲートウェイとの間の通信の方法２６０を示すフローチャートである。この患者指示チェックトランザクション（Ｐａｔｉｅｎｔ Ｉｎｓｔｒｕｃｔｉｏｎｓ Ｃｈｅｃｋ ｔｒａｎｓａｃｔｉｏｎ）は、デバイスゲートウェイから、入手可能な患者への指示を取得するために開始される。「利用可能な指示」（ＩＮＳＴＲＵＣＴＩＯＮＳ ＡＶＡＩＬＡＢＬＥ）が前の通信ステータスチェックトランザクションから受信されたときには常に、トランザクション（方法２６０として示されている）が開始される（例えば、図１５を参照）。

【0197】

行為２６１では、方法２６０が開始される。行為２６２では、患者指示質問要求（ｐａｔｉｅｎｔ ｉｎｓｔｒｕｃｔｉｏｎ ｑｕｅｒｙ ｒｅｑｕｅｓｔ）が開始され、行為２６３で、ウェブメソッドがフォーマットされ、行為２６８で確立されるＨＴＴＰＳ接続を使用して、デバイスゲートウェイに送信される。
行為２６７で、デバイスゲートウェイは、医療デバイスに送信される応答をフォーマットする。もし医療デバイスがデバイスゲートウェイのアクセスリスト２６６のメンバーでない場合は、状態は「拒否」（ＲＥＪＥＣＴＥＤ）に設定される。もし医療デバイスがデバイスゲートウェイのアクセスリスト２６６の一部であり、患者指示は使用できない場合は、状態は「なし」（ＮＯＮＥ）に設定される。し医療デバイスがデバイスゲートウェイのアクセスリスト２６６の一部であり、そして患者指示が利用できる場合は、状態は「利用可能」（ＡＶＡＩＬＡＢＬＥ）に設定され、デバイスゲートウェイはレスポンスペイロードを参照にフォーマットし、又はテキストベースの患者指示を含む。応答が送られた後、ＨＴＴＰＳ接続は行為２６５で閉じられ、行為２６４で応答が検査される。

【0198】

図１９は、本開示の実施形態に従って、患者スカラーデータトランザクションを実行するために、医療デバイスとデバイスゲートウェイとの間の通信の方法２６９を示すフローチャートである。
患者スカラー・データチェックトランザクション（方法２６９によって実施される）は、デバイスゲートウェイから利用可能な患者スカラデータを取得するために、医療デバイスによって開始される。トランザクションは、利用可能なデータが、以前の通信状態チェックトランザクションから受信されたときには常に開始される。

【0199】

行為２７０において、方法２６９が開始される。行為２７１で、要求が開始され、それは行為２７２においてウェブメソッドとしてフォーマットされる。
ウェブメソッドは、行為２７７で確立されたＨＴＴＰＳ接続を介して医療デバイスからデバイスゲートウェイへ通信される。デバイスゲートウェイは行為２７６への応答をフォーマットする。もし医療デバイスがデバイスゲートウェイのデバイスアクセスリスト２７５のメンバーでない場合、状態は「拒絶」に設定される。もし医療デバイスがデバイスゲートウェイのデバイスアクセスリスト２７５のメンバーである場合であって、患者に関連するスカラデータが利用できない場合、状態は、「なし」（ＮＯＮＥ）に設定される。もし医療デバイスがデバイスゲートウェイのデバイスアクセスリスト２７５のメンバーである場合であって、患者に関連するスカラデータが利用できる場合、状態は、利用可能（ＡＶＡＩＬＡＢＬＥ）に設定され、応答ペイロードはテキストベースのスカラデータを含むか又は参照する。患者スカラデータは、患者の年齢、体重、アレルギー、性別、身長などの患者に関連する任意のデータであってもよい。応答は送信され、行為２７４でＨＴＴＰＳ接続を終了する。行為２７３で、医療デバイスは応答をチェック（例えば、プロセスおよび使用）する。

【0200】

図２０は、本開示の一実施形態に係るデバイス情報トランザクションシーケンスを実行するための、医療デバイスとデバイスゲートウェイとの間の通信の方法２７８を示すフローチャートである。デバイス情報チェックトランザクション（行為２７８として実施）は、デバイスゲートウェイから利用可能なデバイス情報を取得するために開始される。「利用可能なデバイス」（ＤＥＶＩＣＥ ＡＶＡＩＬＡＢＬＥ）が、以前の通信ステータスチェックトランザクションから受信されたときは常にトランザクションが開始される。

【0201】

行為２７９では、方法２７８が開始される。行為２８０では、デバイス情報質問要求が開始され、行為２８１で、ウェブメソッドがフォーマットされる。 ウェブメソッドは、行為２８６で確立されたＨＴＴＰＳ接続を介してデバイスゲートウェイに通信される。行為２８５で、応答がフォーマットされる。もし医療デバイスが、デバイスゲートウェイのデバイスアクセスリスト２７５のメンバーでない場合は、状態は「拒否」（ＲＥＪＥＣＴＥＤ）に設定される。
医療デバイスが、デバイスゲートウェイのデバイスアクセスリスト２７５のメンバーであり、デバイス情報が利用できない場合、状態は「なし」（ＮＯＮＥ）に設定される。医療デバイスが、デバイスゲートウェイデバイスアクセスリスト２７５のメンバーであり、デバイス情報が利用できる場合は、状態は「使用可能」（ＡＶＡＩＬＡＢＬＥ）に設定され、そしてレスポンス・ペイロードは、テキストベースデバイス情報を含む又はそれを参照する。いくつかの実施形態では、テキストベースのデバイス情報は、デバイスゲートウェイまたは医療デバイスに関連する任意の情報であってもよい。応答は、医療デバイスに伝達され、ＨＴＴＰＳ接続は行為２８３で終了される。行為２８２において医療デバイスは応答をチェックする。

【0202】

図２１は、本開示の一実施形態による警告通知トランザクションを実行するための、医療デバイスとデバイスゲートウェイとの間の通信の方法２８７を示すフローチャートである。警告通知チェックトランザクション（方法２８７によって実施される）は、デバイスゲートウェイから利用可能な警告通知を取得するために開始される。以前の通信ステータスチェックトランザクションから「利用可能な通知」（ＮＯＴＩＦＩＣＡＴＩＯＮ ＡＶＡＩＬＡＢＬＥ）が受信されたときには常にトランザクションが開始される。

【0203】

行為２８８で、方法２８７が開始される。行為２８９で、警告通知質問要求が開始され、行為２９５で、ウェブメソッドがフォーマットされる。ウェブメソッドは、行為２９５で確立されたＨＴＴＰＳ接続を介してデバイスゲートウェイに伝達される。行為２９４で応答がフォーマットされる。もし医療デバイスがデバイスゲートウェイのアクセスリスト２７５のメンバーでない場合は、状態は「拒否」（ＲＥＪＥＣＴＥＤ）に設定される。もし医療デバイスがデバイスゲートウェイのアクセスリスト２７５のメンバーである場合で、警告通知が利用できない場合は、状態は「なし」（ＮＯＮＥ）に設定される。もし医療デバイスがデバイスゲートウェイのアクセスリスト２７５のメンバーであり、そして警告通知が利用できる場合は、状態は「利用可能」（ＡＶＡＩＬＡＢＬＥ）に設定され、レスポンス・ペイロードはテキストベースの警告通知を含む又はそれを参照する。いくつかの実施形態では、テキストベースの警告通知は、デバイスゲートウェイまたは医療デバイスの警告に関連する任意の情報であってもよい。
応答は、医療デバイスに伝達されそしてＨＴＴＰＳ接続は行為２９５で終了される。行為２９１では、医療デバイスは応答を検査する。

【0204】

図２２は、本開示の実施形態に従ったソフトウェアパッケージチェック（例えば、Ｄｅｂｉａｎソフトウェアパッケージ）トランザクション（方法２９６として実施される）を実行する、医療デバイス及びデバイス・ゲートウェイの間の通信の方法２９６を示すフローチャートである。ソフトウェアパッケージチェックトランザクションは、デバイス・ゲートウェイから利用可能なソフトウェアパッケージを取得するために開始される。利用可能なソフトウェアが、以前の通信状態チェックトランザクションから受信されたときには常にトランザクションが開始される。

【0205】

行為２９７では、方法２６９が開始される。行為２９８では、行為２９９でウェブメソッドとしてフォーマットされる要求が開始される。
ウェブメソッドは、行為３０４で確立されるＨＴＴＰＳ接続を介して医療デバイスからデバイスゲートウェイへ通信される。デバイスゲートウェイは行為３０３への応答をフォーマットする。もし医療デバイスがデバイスゲートウェイのアクセスリスト２７５のメンバーでない場合は、状態は「拒否」（ＲＥＪＥＣＴＥＤ）に設定される。もし医療デバイスがデバイスゲートウェイのアクセスリスト２７５のメンバーであり、ソフトウェアパッケージが利用できない場合は、状態は「なし」（ＮＯＮＥ）に設定される。もし医療デバイスがデバイスゲートウェイのアクセスリスト２７５のメンバーであり、そしてソフトウェアパッケージが利用できる場合は、状態は「利用可能」（ＡＶＡＩＬＡＢＬＥ）に設定され、レスポンス ペイロードはソフトウェアパッケージファイルを含む（又はそれを参照する）（例えば、ＤＩＭＥを使用）。応答は伝達され、行為３０１においてＨＴＴＰＳ接続が終了される。行為３００では、医療デバイスは応答をチェックする（例えば、プロセスおよび使用）。

【0206】

図２３は、本開示の実施形態によるＤＡＬ設定ファイルチェックトランザクションを実行するための，医療デバイスとデバイスゲートウェイとの間の通信の方法３０５を示すフローチャートである。ＤＡＬ設定ファイルチェックトランザクション（行為３０５として実施）は、デバイスゲートウェイから利用可能なＤＡＬファイルを取得するために開始される。 利用可能なＤＡＬ（ＡＶＡＩＬＡＢＬＥ ＤＡＬ）が、前の通信ステータスチェックトランザクションから受信されたときには常にトランザクションが開始される。

【0207】

行為３０６は方法３０５を開始する。要求は行為３０６で開始され、要求は行為３０８でウェブメソッドとしてフォーマットされる。
医療デバイスは、行為３１３でＨＴＴＰＳ接続を確立することにより、ウェブメソッドをデバイスゲートウェイに伝達する。行為３１２では、応答がフォーマットされる。もし医療デバイスがデバイスゲートウェイのデバイスアクセスリスト２７５のメンバーでない場合は、状態は「拒否」（ＲＥＪＥＣＴＥＤ）に設定される。そうでなければ「利用可能」（ＡＶＡＩＬＡＢＬＥ）に設定される。
もし状態が「利用可能」（ＡＶＡＩＬＡＢＬＥ）に設定されると、デバイスゲートウェイはレスポンス ペイロードをフォーマットしＤＡＬ設定ファイル（これはＤＩＭＥを使用して添付されても良い）を含むようにする。応答は医療デバイスに通信され、行為３１０でＨＴＴＰＳ接続を終了される。行為３０９は、デバイスゲートウェイによる応答を検査する。その後新しいＤＡＬファイルを医療デバイス上にインストールすることができる。

【0208】

図２４は、本開示の実施形態によるサービスログポストトランザクションを実行するための医療デバイスとデバイスゲートウェイとの間の通信の方法３１４を示すフローチャートである。サービスログポストトランザクション（行為３１４として実行）は、デバイスゲートウェイにサービスログを送信するために開始される。サービスログ要求（ＳＥＲＶＩＣＥＬＯＧ ＲＥＱＵＥＳＴ）が前の通信ステータスチェックトランザクションから受信されたときには常にトランザクションが開始される。

【0209】

行為３１５は、トリガー（ｔｒｉｇｇｅｒ）を受信して、方法３１４を開始する．行為３１６は行為３１７でウェブメソッドにフォーマットされるポストサービスログ（ｐｏｓｔ ｓｅｒｖｉｃｅ ｌｏｇ）を開始する。ウェブメソッドは、行為３２２で確立されたＨＴＴＰＳ接続を介してデバイスゲートウェイに送信される。行為３２１はウェブ方法を処理して応答をフォーマットする。デバイスゲートウェイは、ログファイルに情報を書き込むか、またはサービスログポストをＣＱＩメッセージとして通信し、それを（上記のように）をクラウドサービスに送る。応答は、行為３１７でトランザクション応答を検査する医療デバイスに伝達される（例えば、それが成功したサービスログポストだったかどうかを決定するために、戻り値を調べることによって）。行為３１９は、応答が送信された後にＨＴＴＰＳ接続を閉鎖する。

【0210】

図２５は、本開示の実施形態によるエンジニアリングログポストトランザクションを実行するための医療デバイスとデバイスゲートウェイとの間の通信の方法２３２を示すフローチャートである。エンジニアリングログポストトランザクションが、デバイスゲートウェイにエンジニアリングログを送信するために開始される。エンジニアリングログ（ＥＮＧＩＮＥＥＲＩＮＧＬＯＧ）要求が前の通信ステータスチェックトランザクションから受信されたとき常にトランザクションが開始される。

【0211】

行為３２４はトリガーを受信し、方法３２３開始する。行為３２５は、行為３２６でウェブメソッドにフォーマットされるポストエンジニアリングログを開始する。ウェブメソッドは、行為３３１で確立されたＨＴＴＰＳ接続を介してデバイスゲートウェイに送信される。行為３３０はウェブ方法を処理して応答をフォーマットする。もし、医療デバイスがアクセスリスト２３９によって示されるような許可された医療デバイスである場合、デバイスゲートウェイは、ログファイルに情報を書き込み又はサービスログポストをＣＱＩメッセージとして通信し、そして（上記のように）それをクラウドサービスに送ってもよい。応答は行為３２７でトランザクション応答を検査する医療デバイスに伝達される。（例えば、それが成功したエンジニアリングログポストであったかどうかを決定するために、戻り値を調べることによって）。行為３２８は、応答が送信された後にＨＴＴＰＳ接続を終了する。

【0212】

図２６は、本開示の実施形態による注入ログポストトランザクションを実施するための医療デバイスとデバイスゲートウェイとの間の通信の方法３３２を示すフローチャートである。注入ログポストトランザクション（行為３３２として実行）は、デバイスゲートウェイにＸＭＬにフォーマットされた注入イベント情報を送信するために開始される。デバイスマネージャに事前に送信されていない注入イベント情報が利用可能である場合は、常にトランザクションが開始される。トランザクションが成功した場合は、ＤＧＣＭ３４２は記録を配送されたとしてマークする。

【0213】

行為３３３は、トリガーを受信して方法３３２開始する。行為３３４は行為３３５でウェブメソッドにフォーマットされる注入ログポストを開始する。ウェブメソッドは、行為３４０で確立されるＨＴＴＰＳ接続を介してデバイスゲートウェイに送信される。行為３３９はウェブ方法を処理して応答をフォーマットする。デバイス・ゲートウェイは、ログファイルに情報を書き込み、又は注入ログポストをＣＱＩメッセージとして通信し、そして（上記のように）それをクラウドサービスに送ってもよい。応答は、行為３３６でトランザクション応答を検査する医療デバイスに伝達される（例えば、それが成功した注入ログ・ポストであったかどうかを決定するために、戻り値を調べることによって）。行為３３７は、応答が送信された後にＨＴＴＰＳ接続を終了する。

【0214】

様々な代替および修正が、本開示から逸脱することなく当業者によって考案され得る。したがって、本開示は、そのような全ての代替、修正および変形を包含することを意図する。さらに、本開示のいくつかの実施形態は、図面に示され、および／または本明細書で説明されているが、これらに限定されるものではないし、それが意図されているように、本開示は、当該分野で許容される範囲において広いものであり、明細書も同様に解される。
従って、上記の説明は、限定的に解釈されるべきではなく、単に特定の実施形態の例示である。また、当業者は、他の改変も、添付の特許請求の範囲および思想内にあると想定するであろう。上記の記載および／または添付の特許請求の範囲に記載されたものと本質的でない特徴において異なる他の要素、ステップ、方法および技術もまた、本開示の範囲内であると了解する。

【0215】

図面に示す実施形態は、本開示の特定の例を実証するためにのみ提示されている。また、記載された図面は例示に過ぎず、非限定的なものである。
図面において、例示の目的のために、いくつかの要素のサイズは誇張されてもよく、特定のスケールで描かれていない。さらに図面に示す要素で同一の番号を持っているものは同一の要素であってもよいか、文脈に応じて、同様の要素であってもよい。

【0216】

「含む」という用語は、本明細書および特許請求の範囲において使用される場合、それは他の要素又は工程を排除するものではない。
単数名詞を参照するときに、不定冠詞または定冠詞が使用される場合、例えば、“ａ”、“ａｎ”または“ｔｈｅ”、他に特に明記されない限り、その名詞の複数形を含む。したがって、用語「含む」は、その後に列挙された項目に限定して解釈されるべきではない。
それは他の要素又は工程を排除するものではなく、「商品ＡとＢを含む装置」の表現の範囲は、構成要素ＡとＢのみからなる装置に限定されるべきではない。本発明に関して、この表現は、装置の唯一の関連する構成要素がＡとＢであることを意味する。

【0217】

さらに、用語「第１」「第２」、「第３」などが、明細書または特許請求の範囲の何れで使用されるかを問わず、同様の要素を区別するために用いられているものであり、これらは、必ずしも連続でありまたは時間の順を記述するために設けられているものではない。
これは、そのように使用される用語は（明確にそうでないと開示されている場合を除き）、適切な状況下で交換可能であること、及び本明細書に記載の開示の実施形態は、他の順序および／または本明細書に記載または例示されていると異なる配置で操作が可能であるということが理解される。
本発明の第１の態様は、
電子患者ケアのためのシステムであって、
ネットワーク、
アプリケーション用の出版購読型（ｐｕｂｌｉｓｈ－ｓｕｂｓｃｒｉｂｅ）サービスを提供する様に構成されているファシリティゲートウェイ、
ファシリティゲートウェイにより実行されるように構成されるデバイスゲートウェイアプリケーションを備え、前記デバイスゲートウェイは、ウエブサービスを提供することによりネットワークを介して通信する様に構成されている、及び
ネットワークと動作可能に通信することができる医療デバイスを備え、前記医療デバイスは、ウェブサービスを用いてデバイスゲートウェイと通信する様に構成されている、電子患者ケアのためのシステムである。
本発明の第２の態様は、
第１の態様のシステムであって、さらに、出版購読型サービスを提供するように構成された
出版購読型エンジンを含む、前記システムである。
本発明の第３の態様は、
第１の態様のシステムであって、前記ネットワークは、ＴＣＰ／ ＩＰベースのネットワークである、前記システムである。
本発明の第４の態様は、
第１の態様のシステムであって、デバイスゲートウェイアプリケーションは、ウェブサービスのウェブサーバーであり、医療デバイスはウェブサービスのクライアントである、前記システムである。
本発明の第５の態様は、
第１の態様のシステムであって、デバイスゲートウェイアプリケーションは、出版購読型サービスを用いてトピックを記録する様に構成されている、前記システムである。
本発明の第６の態様は、
第５の態様のシステムであって、さらにファシリティゲートウェイにより実行されるように構成された統合ＡＰＩを備え、前記統合ＡＰＩはトピックに登録申込みして、そのトピックに登録申込みをすることにより受領したイベントを、少なくとも１つの外部サーバーに通信するように構成される、前記システムである。
本発明の第７の態様は、
第６の態様のシステムであって、前記トピックは、報告可能な生物医学（ｂｉｏｍｅｄ）イベントトピック及び報告可能な臨床イベントトピックの少なくとも一つである、前記システムである。
本発明の第８の態様は、
第５の態様のシステムであって、前記トピックは、報告可能な生物医学イベントトピックであり、前記デバイスゲートウェイは、ウェブサービスを介して受領した医療デバイスイベントを、出版購読型エンジンを介してトピックの登録申込者（ｓｕｂｓｃｒｉｂｅｒ）が受領可能な、報告可能な生物医学イベントに再フォーマットする、前記システムである。
本発明の第９の態様は、
第８の態様のシステムであって、前記医療デバイスは、ウェブサービスを用いて、ネットワークを介して医療デバイスイベントを通信する、前記システムである。
本発明の第１０の態様は、
第５の態様のシステムであって、前記トピックは、報告可能な臨床イベントトピックであり、前記デバイスゲートウェイは、ウェブサービスを介して受領した医療デバイスイベントを、出版購読型エンジンを介して、トピックの登録申込者により受領可能な、報告可能な臨床イベントに再フォーマットする、前記システムである。
本発明の第１１の態様は、
第１０の態様のシステムであって、前記医療デバイスはウェブサービスを用いてネットワークを介して医療デバイスイベントを通信する、前記システムである。
本発明の第１２の態様は、
第５の態様のシステムであって、前記トピックは少なくとも一つのクラスのポンプ・イベントに対応する、前記システムである。
本発明の第１３の態様は、
第１２の態様のシステムであって、少なくとも一つのクラスのポンプ・イベントは、警報、警告または通知に関する輸液イベント（ｉｎｆｕｓｉｏｎ ｅｖｅｎｔ）、輸液に関する輸液イベント、プログラミングに関する輸液イベント、通信に関するデバイスイベント（ｄｅｖｉｃｅ ｅｖｅｎｔ）、アクセス要求に関するデバイスイベント、設定の更新に関するデバイスイベント、ロギング（ｌｏｇｇｉｎｇ）に関するデバイスイベント、及び／又は電力消費に関するデバイスイベントの少なくとも一つを含む、前記システムである。
本発明の第１４の態様は、
第１の態様のシステムであって、さらに、ファシリティゲートウェイにより実行するために構成される継続的な品質改善指向リスナーを含み、
前記継続的な品質改善指向リスナーは、報告可能な生物医学イベントのトピック及び報告可能な臨床イベントのトピックに登録申込みをし、
前記継続的な品質改善指向は、報告可能な生物医学イベントトピックへ登録申込みをすることにより受領される報告可能な生物医学イベントを外部データベースに通信する様に構成され、及び
前記継続的な品質改善指向は、報告可能な臨床イベントトピックへ登録申込みをすることにより受領される報告可能な臨床イベントを外部データベースに通信する様に構成される、
前記システムである。
本発明の第１５の態様は、
第１４の態様のシステムであって、前記外部データベースは、報告可能な生物医学イベント及び報告可能な臨床イベントの少なくとも一つを記録する、前記システムである。
本発明の第１６の態様は、
第１の態様のシステムであって、さらに前記ファシリティゲートウェイ上で実行可能なデバイスマネージャを含み、前記デバイスマネージャは、前記医療デバイスを含む医療デバイスのリストを保持することを含む様に構成される、前記システムである。
本発明の第１７の態様は、
第１６の態様のシステムであって、前記医療デバイスのリストは、医療デバイスのリストに対応する通し番号のリストを含む、前記システムである。
本発明の第１８の態様は、
第１の態様のシステムであって、さらに、そこからステータス情報を受領するためにネットワークを介して医療デバイスと動作可能に通信する監視クライアントを含む、前記システムである。
本発明の第１９の態様は、
医療デバイスであって、
ネットワーク、
プロセッサ、
プロセッサと動作可能に通信が可能であり、ネットワークを介して通信するように構成されているトランシーバ、および
プロセッサ上で実行可能であり、トランシーバを介して動作可能に通信することができるように構成されているデバイスゲートウェイ通信マネージャを備え、前記デバイスゲートウェイ通信マネージャは、ネットワーク上のウェブメソッドを使用してデバイスイベントを伝達するように構成されている、前記医療デバイスである。
本発明の第２０の態様は、
前記ネットワークはＷｉＦｉネットワークである、第１９の態様のデバイスである。
本発明の第２１の態様は、
前記トランシーバはＷｉＦｉトランシーバである、第１９の態様のデバイスである。
本発明の第２２の態様は、
前記デバイスのみがウェブメソッドを使用して通信を開始するように構成されている、第１９の態様のデバイスである。
本発明の第２３の態様は、
前記デバイスは、ネットワークを介して監視デバイスにデータを送信するように構成されている、第１９の態様のデバイスである。
本発明の第２４の態様は、
電子患者ケアのためのシステムであって、
ネットワーク、
出版購読型（ｐｕｂｌｉｓｈ－ｓｕｂｓｃｒｉｂｅ）サービスを提供する様に構成されているファシリティゲートウェイ、
ファシリティゲートウェイにより実行されるように構成されたデバイスゲートウェイアプリケーションを備え、そして前記デバイスゲートウェイは、ウェブサービスを提供することによりネットワークを介して通信する様に構成されており、前記デバイスゲートウェイは医療デバイスイベントトピックを発行し、
ファシリティゲートウェイ上で実行する様に構成されており、医療デバイスイベントトピックに登録申込みするように構成されたデバイスアプリケーションを備え、前記デバイスアプリケーションは、ＣＱＩメッセージトピックを発行し、前記デバイスアプリケーションは、医療デバイスイベントトピックに登録申込みすることによりイベントを受信し、そしてＣＱＩメッセージトピックを通して、イベントをＣＱＩメッセージとして発行するように構成され、及び
ネットワークと動作可能に通信する医療デバイスを備え、前記医療デバイスは、ウェブサービスを用いてデバイスゲートウェイと通信し、ウェブサービスのウェブメソッドを用いてイベントを生成する様に構成されている、電子患者ケアのためのシステムである。
本発明の第２５の態様は、
第２４の態様のシステムであって、前記デバイス・ゲートウェイは、ＣＱＩメッセージを受領するためにＣＱＩメッセージトピックに登録申込みをする、前記システムである。
本発明の第２６の態様は、
第２５の態様のシステムであって、さらに前記ファシリティゲートウェイにより実行するように構成されるＣＱＩリスナーを含み、前記 ＣＱＩリスナーは、ＣＱＩメッセージを受領するためにＣＱＩメッセージのトピックに登録申込みする、前記システムである。
本発明の第２７の態様は、
第２６の態様のシステムであって、前記ＣＱＩリスナーは前記ＣＱＩメッセージを外部データベースに通信する、前記システムである。
本発明の第２８の態様は、
第２４の態様のシステムであって、前記ＣＱＩメッセージは、報告可能な生物医学イベントおよび報告可能な臨床イベントの一つである、前記システムである。
本発明の第２９の態様は、
さらに、医療デバイスと動作可能に通信するように構成された監視クライアントを含む、第２４の態様のシステムである。
本発明の第３０の態様は、
第２９の態様のシステムであって、前記監視クライアントは、ＣＱＩメッセージトピックに登録申込みすることにより前記医療デバイスと通信する、前記システムである。
本発明の第３１の態様は、
電子患者ケアのためのシステムであって、
薬剤代謝の情報を含む患者に関連した情報を含むサーバ、及び
薬剤代謝情報を用いて、患者に関連する各情報に基づいて、患者への薬剤の流れを調整するように構成されたポンプを備え、前記ポンプは、前記サーバから患者関連情報を受領する、前記システムである。
本発明の第３２の態様は、
電子患者ケアのためのシステムに関し、記述され、参照され、例示で示され、または本明細書、特許請求の範囲、図面に示された全ての新規な特徴である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】