JP7089048B2 - 患者用医療装置を管理するシステム及び方法 - Google Patents

Description

関連出願の相互参照
本出願は、「Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｐｌａｔｆｏｒｍ」という名称を有する、且つ、２０１５年４月２０日付けで出願された、米国仮特許出願第６２／１４９，９６０号に対する米国特許法第１１９条の下における利益を主張する、「Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｐｌａｔｆｏｒｍ」という名称を有する、且つ、２０１６年４月２０日付けで出願された、米国特許出願第１５／１３４，１３０号の一部継続である。本出願は、「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｍａｎａｇｉｎｇ Ｐａｔｉｅｎｔ Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅｓ」という名称を有する、且つ、２０１７年１２月１日付けで出願された、米国仮特許出願第６２／５０３，５４０号に対する米国特許法第１１９条の下における利益を更に主張する。これらの特許出願のそれぞれは、引用により、そのすべてが、本明細書において具体的に包含される。

本開示の態様は、１人又は複数の患者の患者用医療装置を管理することに関し、且つ、更に詳しくは、１つ又は複数の心臓埋め込み型電子装置（ｃａｒｄｉａｃ ｉｍｐｌａｎｔａｂｌｅ ｅｌｅｃｔｒｏｎｉｃ ｄｅｖｉｃｅｓ）を管理するシステム及び方法に更に関する。

一般に、様々な医学的状態を治療及び／又は監視するべく、埋め込み型医療装置が使用されている。例えば、心臓機能を調節及び監視するべく、しばしば、埋め込み型除細動器（ＩＣＤ：Ｉｍｐｌａｎｔａｂｌｅ Ｃａｒｄｉｏｖｅｒｔｅｒ Ｄｅｆｉｂｒｉｌｌａｔｏｒ）などの心臓埋め込み型電子装置（ＣＩＥＤ：Ｃａｒｄｉａｃ Ｉｍｐｌａｎｔａｂｌｅ Ｅｌｅｃｔｒｏｎｉｃ Ｄｅｖｉｃｅ）が利用されている。ＣＥＩＤは、限定を伴うことなしに、次のものを含みうる：低エネルギーの電気パルスを使用して低速の心拍を防止するペースメーカ（ＰＭ：ＰａｃｅＭａｋｅｒ）；異常な心臓不整脈を検出するべく、且つ、突然の心臓停止を防止するための救命ショックを供給するべく、使用される埋め込み型除細動器（ＩＣＤ）；心臓データを継続的に監視し、且つ、医師によって、且つ、患者の裁量において、処方されるデータをクリニックに送信する、埋め込み型ループレコーダ（ＩＬＲ：Ｉｍｐｌａｎｔａｂｌｅ Ｌｏｏｐ Ｒｅｃｏｒｄｅｒ）；及び、埋め込み型心臓モニタ（ＩＣＭ：Ｉｍｐｌａｎｔａｂｌｅ Ｃａｒｄｉａｃ Ｍｏｎｉｔｏｒ）。このようなＣＩＥＤは、分析、プログラミング、及び／又はこれらに類似したもののために、身体外の装置の動作に関係する情報を保存しており、且つ、定期的に送信することができる。更に具体的には、ＣＩＥＤは、医療提供者による事務所内における又は遠隔の監視のために、情報を保存し、且つ、送信している。

但し、医療提供者は、しばしば、異なる製造者によって製造された一連の装置を有する多数の患者の責任を担っている。製造者のそれぞれは、通常、その装置から伝達される情報、のみならず、この情報を要約した、医療提供者に提供される任意のデータ、用の固有のプロプライエタリなデータフォーマットを使用している。医療提供者が一連の固有のフォーマットにおいて情報を受け取る状態において、医療提供者が、様々な装置タイプ及び製造者に跨って、患者の看護を効率的に管理することは、難問である。これらの難問は、情報が、通常、送信が受け取られた順序において、検討及び分析のために医療提供者に提示されることにより、悪化する。その結果、医療提供者は、送信のいずれかが、相対的に緊急な検討を必要としうるかどうかを判定することができない。更には、送信と関連する情報の検討は、しばしば、面倒であり、この結果、特に、臨床的に適切ではない送信に関して、リソースが浪費されることになる。

本開示の様々な態様が、想定され、且つ、開発された背景には、その他のことに加えて、これらの観察結果に関する留意が存在している。

本明細書において記述及び特許請求されている実装形態は、患者用装置の管理用のシステム及び方法を提供することにより、上述の問題に対処している。一実装形態においては、インタロゲーション（ｉｎｔｅｒｒｏｇａｔｉｏｎ）データが、患者のインタロゲーションに対応する心臓埋め込み型電子装置から受け取られている。インタロゲーションデータは、心臓埋め込み型電子装置のデータと、患者の患者固有のデータと、を含む。インタロゲーションデータが、製造者とは独立したインタロゲーションデータとして正規化される。製造者とは独立したインタロゲーションデータが、許容されたユーザーと関連付けられる。製造者とは独立したインタロゲーションデータを使用することにより、処理状態が、インタロゲーションに対して割り当てられる。インタロゲーションが、処理状態に基づいて、所定のカテゴリに集計され、且つ、このカテゴリが、許容されたユーザーによる動作と関連付けられる。

又、本明細書には、その他の実装形態についても記述及び詳述されている。更には、複数の実装形態が開示されているが、当業者には、本明細書において開示されている技術の例示用の実装形態を図示及び記述している以下の詳細な説明から、本明細書において開示されている技術の更なるその他の実装形態について明らかとなろう。理解されるように、本明細書において開示されている技術は、いずれも、本明細書において開示されている技術の精神及び範囲からの逸脱を伴うことなしに、様々な態様における変更の能力を有する。従って、図面及び詳細な説明は、その特性が、限定ではなく、例示を目的としているものと見なされたい。

１つ又は複数の心臓埋め込み型電子装置を管理するべく、ネットワークと結合されたサーバー又はその他の演算装置上において稼働する医療装置マネージャを含む、例示用のネットワーク環境を示す。 例示用の医療装置データプラットフォームを含む医療装置データ通信システムのブロック図である。 例示用の医療装置データプラットフォームのブロック図である。 患者用医療装置を管理するための例示用の装置管理ユーザー固有インターフェイスを示す。 患者用医療装置を管理するための例示用の分析ウィジェットユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用の品質スコアウィジェットユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用の品質ベンチマークウィジェットユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用の患者サマリユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用のユーザー固有のドケットユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用のワークフロー概要ユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用の送信概要ユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用の患者パネルユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用のドケットタイムライン及び送信バーユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用のドケットジェネレータユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用のアクショントラッカユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用のリコール管理ユーザーインターフェイスを示す。 患者用医療装置を管理するための例示用の情報共有ユーザーインターフェイスを示す。 本明細書において記述されている様々なシステム及び方法を実装しうる例示用の演算システムである。

本開示の態様は、１つ又は複数の埋め込み型又はその他の方法によって装用可能な電子装置を管理するための医療装置管理プラットフォーム用の、システム、方法、コンピュータプログラムプロダクト、及びこれらに類似したものを伴っている。電子装置は、１つ又は複数の心臓埋め込み型な電子装置（ＣＩＥＤ）などの、医療装置を含みうる。プラットフォームは、一般に、患者の看護を管理するべく、これらの患者の、ＣＩＥＤなどの、１つ又は複数の医療装置から、動作送信を受け取ることができるが、これには、提供者が、患者用の看護戦略を閲覧し、文書化し、これについて報告し、且つ、これを生成することを可能にするための、このような装置からのデータ、レポート、及び情報の受け取りが含まれている。このような動作送信は、対応する装置、装置プログラミング機械、患者又は製造者からの、或いは、装置からの送信を受け取る第三者エンティティからの、報告を含む、多くの供給源を通じて、管理プラットフォームにおいて受け取ることができる。送信は、対応する装置の一般的な動作情報を提供しており、且つ、いくつかの例においては、装置動作に関するアラート又はイベントのみならず、装置製造者によって定義されているパッケージ化されたレポートをも含みうる。これらのアラート又はイベントは、装置の動作及び装置患者の健康に関係していることから、なんらかの形態の患者看護をトリガしうる。

又、患者プラットフォームは、医療要員又はプラットフォームのその他のユーザーが、装置送信の受け取りを管理しうる１つ又は複数のインターフェイスを提供することもできる。例えば、管理プラットフォームは、ユーザーが送信を検討しうる、送信に応答して１つ又は複数のワークフロー又は医療計画を確立しうる、装置状態について患者に警告しうる、且つ／又は、その他の医療要員との間において装置情報を共有しうる、ユーザー演算装置に対する１つ又は複数のインターフェイスを提供することができる。ＣＥＩＤのそれぞれの製造者は、対応するＣＥＩＤの監視を可能にするべく、固有の事務所内プログラマ及び固有のリモートデータアクセスポータルを有する。従って、クリニックは、例えば、それぞれの製造者ごとのプログラマ及びデータポータルを含む、無数のデータ供給源を使用して患者レポートを生成するべく、ＣＥＩＤデータへのアクセス及びその検討に直面している。

特定の一実装形態においては、送信管理インターフェイスは、クリニック技術者が、インターフェイスにアクセスし、且つ、受け取られた装置送信のリストを受け取ることを許容することができる。インターフェイスは、送信を完了まで処理するべく、受け取られた送信と関連する１つ又は複数のレポート（例えば、ドケット）又はワークフローの生成を更に提供することができる。このようなドケットは、装置情報に基づいて患者を治療するべく、送信に応答した患者用の医療計画を含みうる。又、受け取られた送信の統計及びその他の計測及び結果的に得られる看護プロトコルも、クリニックの運営及び効率を改善するべく、或いは、患者に対する看護を改善するべく、或いは、インターフェイスに対するアクセスを有する別のエンティティとの間においてデータを共有するべく、インターフェイスツールを通じて提供することができる。この結果、装置送信の管理が、装置管理プラットフォームインターフェイスのユーザーのために、簡単になり、且つ、改善される。

次に、図１を参照すれば、この図は、１つ又は複数の心臓埋め込み型電子装置１０４を管理するべく、ネットワーク１０６と結合されたサーバー１１２又はその他の演算装置上において稼働する医療装置マネージャ１０２を含む、例示用のネットワーク環境１００を示している。一実装形態においては、医療チームのメンバ、並びに／或いは、管理サービスを管理する又は完了させるべくアクセスが委譲されている第三者、などの、ユーザーは、ネットワーク１０６（例えば、インターネット）を介して１つ又は複数の医療装置にアクセスするべく、或いは、これを管理するべく、ユーザー装置１０８を使用して医療装置マネージャポータル１０２にアクセスし、且つ、これとやり取りしている。ユーザー装置１０８は、一般に、パーソナルコンピュータ、端末、ワークステーション、携帯型コンピュータ、モバイル装置、スマートフォン、タブレット、マルチメディアコンソールなどのような、ネットワーク１０６とやり取りする能力を有する任意の形態の演算装置である。ネットワーク１０６は、ネットワーク環境１００内において、医療装置マネージャ１０２及びその他のサービス、アプリケーション、又はモジュールを実装するべく、１つ又は複数の演算又はデータストレージ装置（例えば、１つ又は複数のデータベース１１０又は本明細書において記述されているその他の演算ユニット）により、使用されている。

一実装形態においては、ネットワーク環境１００は、医師の事務所内に存在すると共に患者の存在している際に利用される装置プログラミング機械を含む、ユーザーが医療装置マネージャ１０２及び／又はその他のネットワークコンポーネントにアクセスするべく訪問しうるウェブサイト又はアプリケーションをホスティングする少なくとも１つのサーバー１１２を含む。サーバー１１２は、単一のサーバー、それぞれのサーバーが物理サーバー又は仮想機械である状態の複数のサーバー、或いは、物理サーバーと仮想機械の両方の集合体、であってよい。別の実装形態においては、クラウドが、ネットワーク環境１００の１つ又は複数のコンポーネントをホスティングしている。ユーザー装置１０８、サーバー１１２、及びネットワーク１０６に接続されたその他のリソースは、統合された健康管理の供給のために使用される１つ又は複数のウェブサイト、アプリケーション、ウェブサービスインターフェイス、ストレージ装置、演算装置、又はこれらの類似したものにアクセスするべく、１つ又は複数のその他のサーバーにアクセスすることができる。又、サーバー１１２は、医療装置マネージャ１０２が、患者データ、チームメンバデータ、教育データ、及びその他のデータにアクセスするべく、これらについてサーチするべく、且つ、これらを変更するべく、使用するサーバーエンジンをホスティングすることもできる。一実装形態においては、医療装置マネージャ１０２は、１つ又は複数の埋め込み型医療装置１０４のデータ及び／又はその他の情報に対するアクセスを提供している。

専門家によるＣＥＩＤ監視は、通常、患者の一生にわたって発生する。このような監視には、償還及び看護ガイドラインが適用される。通常、ＣＥＩＤ看護は、ＰＭ又はＩＣＤを有する患者用の４回のリモートデータチェック／年、ＰＭ又はＩＣＤ患者用の少なくとも１回の事務所内チェック／年、並びに、ＩＣＭ又はＩＬＲ患者用の１１回のリモートデータチェック／年を伴っている。米国内の医療保険は、一般に、これらのガイドラインと一貫性を有する。但し、医療保険の償還が存在している一方で、これらは、しばしば、装置送信の取得、検討、及び文書化に関与した人件費をカバーしてはない。新しいＩＬＲ及びＩＣＭの迅速な採用及びデータボリュームの増大に伴って、これらのガイドラインの送信負担の推定値は、次の５年間において、８億回のＣＩＥＤ送信を超過しうるであろう。これらのガイドラインに準拠することにより、患者の結果が改善され、且つ、健康管理システムの費用が引き下げられ、これにより、ＰＭを有する患者の場合には、ほとんど２．５倍だけ、死亡率が低減され、且つ、ＩＣＤ患者の場合には、６５％超だけ、入院が低減される。但し、これらのガイドラインに伴う負担に起因して、これらのガイドラインに従って監視されるのは、患者の３０％未満になるものと推定される。

従って、医療装置１０４は、動作データを医療装置マネージャ１０２に提供するべく、ネットワーク１０６との通信状態にあってよい。例えば、且つ、上述のように、埋め込み型除細動器（ＩＣＤ）及びこれに類似したものなどの、心臓埋め込み型電子装置（ＣＩＥＤ）は、しばしば、分析、プログラミング、及び／又はこれらに類似したもののために、身体外の装置の動作に関係する情報を送信している。いくつかのケースにおいては、クリニックは、装置製造者の安全なウェブサイトから、且つ／又は、提供者の事務所内において物理的に配置された装置プログラミング機械から、医療装置１０４のデータを取得している。医療装置１０４によって生成されたデータは、通常、提供者によって検討される。通常の提供者は、すべての製造者並びに装置モデル及びタイプを埋め込むと共に、これらからの送信を監視している。提供者が単一の装置タイプを埋め込み及び監視することは、めったにない。データ送信及びデータ送信の検討モードの観点において、製造者のそれぞれは、固有の且つプロプライエタリなデータフォーマット、表示、アクセスプロトコル、レポート、及びプログラミング機械を使用している。医療提供者が、この広範囲の固有の且つ異なるフォーマットにおいてデータを受け取っている状態においては、医療提供者が患者の看護を効率的に管理することは、難問である。データアクセス及び管理の負担は、相対的に良好な患者の看護における主要な障害である。面倒なワークフローは、過剰な費用を生成し、優れた看護モードであるリモート看護の採用を妨げ、償還機会の喪失をもたらし、且つ、いくつかのクリニックが、リモート看護を諦め、且つ、その代わりに、事務所内看護の数を引き下げるように患者を促すことを強制し、この結果、低患者準拠状態に起因した更なる看護の低減と、入院の増大と関連する相対的に大きな健康管理システムの負担と、を更にもたらす。従って、更に詳細に後述するように、医療装置マネージャ１０２は、ユーザーが、様々な装置タイプ及び異なる製造者に跨って、１つ又は複数の医療装置１０４からのデータを管理し、分析し、且つ／又は、保存することを許容している。

図２を参照すれば、医療装置マネージャ１０２は、医療装置データ通信システム２００を含みうる。一実装形態においては、医療装置データ通信システム２００は、複数の埋め込み型医療装置製造者システム２０６及び複数のクリニックシステム２０２との通信状態にある医療装置プラットフォーム２０４を含む。医療装置プラットフォーム２０４は、例えば、インターネットなどの、ワイドエリアネットワーク（ＷＡＮ：Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介して製造者システム２０６及びクリニックシステム２０２と通信自在に結合することができる。いくつかの実装形態においては、製造者システム２０６のそれぞれは、固有の埋め込み型医療装置製造者と関連付けることができる。その他の例においては、製造者システム２０６のそれぞれは、埋め込み型医療装置製造者及び特定の医療クリニック又は事務所の固有のペア化と関連付けることができる。図２のシステム２００の例においては、製造者システム２０６は、装置データベース２１４から、複数の埋め込み型医療装置から予めアップロードされた診断及び関係するデータを取得する、例えば、ウェブサーバーなどの、製造者プラットフォーム２１２を含みうる。このようなデータは、上述のように、クリニック又は事務所を介して、或いは、リモートモニタを介して、様々な埋め込み型医療装置から予め取得されたものであってよい。

図２に描かれているように、医療装置プラットフォーム２０４は、製造者システム２０６のそれぞれからの埋め込み型医療装置の診断及び関係するデータにアクセスする統合マネージャ２１０を含みうる。一例においては、統合マネージャ２１０は、ＩＤＣＯ（Ｉｍｐｌａｎｔａｂｌｅ Ｄｅｖｉｃｅ Ｃａｒｄｉａｃ Ｏｂｓｒｅｖａｔｉｏｎ）メッセージの形態でありうる、診断データ及び関係する情報を取得するべく、特定のクリニックと関連する臨床情報システム（ＣＩＳ：Ｃｌｉｎｉｃａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ）識別子を製造者プラットフォーム２０６に提供することができる。いくつかの実装形態においては、統合マネージャ２１０と製造者プラットフォーム２１２の間のメッセージは、別の、改善された、或いは、増強された、データメッセージの形態であってもよい。例えば、ＩＤＣＯメッセージは、しばしば、ポータブルドキュメントフォーマット（ＰＤＦ：Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）において、サマリレポートとしてフォーマッティングされた情報を含む。その他の例においては、ＩＤＣＯ様のメッセージは、整数、浮動小数点、又は別のデータフォーマットにおいて埋め込み型装置によって検出される不整脈又はその他の心臓発作に関する数値的な且つ／又はグラフィカルなエレクトログラム（ＥＧＭ）データなどの、相対的に詳細な、或いは、「未加工」の、データを提供しうる。このような情報は、医療装置プラットフォーム２０４内の装置データの相対的に容易な且つ／又は相対的に詳細な処理を促進しうる。

次いで、統合マネージャ２１０は、患者指向の情報及び／又は提供者指向の情報を生成するべく、取得された情報を処理することができる。いくつかの例においては、様々な埋め込み型医療装置からの取得された情報は、特定のタイプのすべての製造者及び／又は装置に跨って統一又は一般化されたフォーマットに処理することができる。次いで、統合マネージャ２１０は、クリニックシステム２０２のみならず、図２には示されていない個々の患者通信システム、用の１つ又は複数のウェブポータルを提供しうるクラウド演算システム２０８に、処理済みの情報を転送することができる。その他の例においては、統合マネージャ２１０は、取得された装置データをクラウド演算システム２０８に転送してもよく、次いで、これが、データを処理するべく、情報プロセッサとして動作することができる。又、クラウド演算システム２０８は、ウェブポータルを介して、処理済みの情報に基づいて、分析結果及びその他の高度な情報を生成及び提供することもできる。ウェブポータル及び情報の分析の生成及び提供の例については、更に詳細に後述する。クラウド演算システム２０８は、いくつかの例においては、本明細書においてクラウド演算システム２０８に帰せられている様々な動作を実行するように構成された複数のコンピュータ装置又はシステムを含みうる。

図２に示されているように、ユーザー（例えば、１人又は複数の医師、看護師、技術者、分析者など）は、恐らくは、１つ又は複数の埋め込み型医療装置の分析結果及びその他の高度な情報を含む、処理済みの装置情報を取得するべく、クリニックシステム２０２を利用することができる。いくつかの例においては、クリニックシステム２０２は、ユーザーが、医療装置マネージャ１０２などの、提供者指向の情報を取得するべく、クラウド演算システム２０８によって提供されるウェブポータルにアクセスしうる、クリニックアクセスシステム２１８（例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォンなど）を含みうる。又、図２に示されているように、クリニックシステム２０２は、クリニックの患者の医療レコードを保存し、且つ、これに対するアクセスを促進するように、構成された電子医療レコードマネージャシステム２１６、並びに、クリニックシステム２０２の外部のその他の演算システムとの間においてクリニックの患者の健康及び医療情報を交換するように構成された健康情報交換（ＨＩＥ：Ｈｅａｌｔｈ Ｉｎｆｏｒｍａｔｉｏｎ Ｅｘｃｈａｎｇｅ）システム２２０、のうちの１つ又は複数を含みうる。一実装形態においては、ユーザーは、シングルサインオン（ＳＳＯ：Ｓｉｎｇｌｅ Ｓｉｇｎ－ＯＮ）手順を使用してクラウド演算システム２０８、医療レコードマネージャ２１６、及び／又はＨＩＥシステム２２０にサインオン又はログオンし、これにより、これらのシステムのそれぞれに個々にアクセスするべくユーザーによって通常必要とされる時間量を低減することできる。

いくつかの例においては、統合マネージャ２１０は、埋め込み型医療装置のうちの１つ又は複数との間の通信接続を介して、装置診断データ及びその他の装置情報を取得し、これにより、恐らくは、製造者システム２０６のうちの１つ又は複数に対するニーズを低減することができる。それらの例及びその他のものにおいては、統合マネージャ２１０及び／又はクラウド演算システム２０８は、装置の対応する製造者によって使用されるように、製造者システム２０６の１つ又は複数に、処理済みの且つ／又は未処理の装置情報のみならず、分析結果及びその他の高度な情報を転送又は「プッシング（ｐｕｓｈ）」することができる。

又、図２に描かれているように、クラウド演算システム２０８は、医療装置プラットフォーム２０４の外部のその他のシステムと通信してもよく、これからデータを取得してもよく、且つ／又は、これに対してデータを送信してもよい。例えば、クラウド演算システム２０８は、様々な埋め込み型医療装置の有効性及び／又は安全性、これらに対する患者応答、並びに、その使用に関するその他の情報、に関するデータを供給するべく、医療装置レジストリシステム２２２にアクセスすることができる。又、クラウド演算システム２０８は、そのデータをクラウド演算システム２０８と関連する様々な埋め込み型医療装置から受け取られた処理済みの情報と相関させるべく、装置レジストリデータにアクセスすることもできる。

又、クラウド演算システム２０８は、クラウド演算システム２０８と関連する埋め込み型医療装置のそれぞれを正確に追跡するように構成されたレジストリ情報及び装置データシステム２２６にアクセスすることもできる。例えば、クラウド演算システム２０８は、クラウド演算システム２０８内において処理された埋め込み型医療装置のうちの１つ又は複数と関連する情報を医療装置レジストリシステム２２２から受け取られたデータと正確に相関させる又は関連付けるべく、レジストリ情報及び装置データシステム２２６から得られたデータを利用することができる。

いくつかの例においては、クラウド演算システム２０８は、医療装置プラットフォーム２０４と関連付けられた装置を含む、一連の埋め込み型医療装置の製品リコールデータを取得するべく、リコール勧告レジストリデータベース２２４にアクセスすることができる。更には、クラウド演算システム２０８は、クリニックシステム２０２を介して、且つ／又は、ウェブポータルを介して、タイムリーな方式により、その対応する埋め込み型医療装置を伴う任意のリコールについて、ユーザーに通知することができる。このようなデータは、ウェブポータル、電子メール、テキスト、又はその他の通信手段を介して、ユーザーにプッシングすることができる。一例においては、医療装置プラットフォーム２０４は、リコール勧告レジストリデータベース２２４を含んでおり、且つ、例えば、正式な連邦政府機関、州、又は国家医事局、通信社、などのような、様々な供給源からのデータをリコール勧告レジストリデータベースに入力することができる。

図３は、図２の医療装置プラットフォーム２０４の一例のブロック図である。図３に描かれているように、医療装置プラットフォーム２０４は、アナライザモジュール３００、トラッカモジュール３０２、アグレゲータモジュール３０４、提供者ポータルモジュール３０６、スケジュールモジュール３０８、患者ポータル３１０、ドケットジェネレータモジュール３１２、ワークフローエンジン３１４、ビリングエンジン３１６、リコールマネージャ３１８、及び／又はレコードインテグレータ３２０のうちの１つ又は複数を含みうる。又、その他の例においては、本明細書において具体的に記述されてはいない、その他のモジュールも、医療装置プラットフォーム２０４に含まれうる。更には、これらのモジュールのそれぞれは、図２に描かれているように、統合マネージャ２１０及び／又はクラウド演算システム２０８に内蔵することもできる。

アナライザモジュール３００は、１つ又は複数のＣＩＥＤから受け取られた情報及びデータを分析するように構成されうると共に、分析された情報の傾向の自動化されたスナップショットを提供することができる。このような実装形態においては、このような情報は、特定のクリニックについて、或いは、複数のクリニックについて、分析することができる。上述のように、１つ又は複数のＣＩＥＤは、埋め込まれた装置の性能又は動作に関する保存された又は取得された情報又はデータを送信することができる。この情報は、医療装置プラットフォーム２０４に送信又はダウンロードされ、且つ、アナライザモジュール３００によって分析される。情報の分析は、ポータルを通じて分析及び／又は集計された情報の特定のスナップショットを提供しうる（これについては、更に詳細に後述する）。例えば、アナライザモジュール３００は、情報又はデータと関連する装置のタイプ、装置の製造者、又は特定の装置モデルに基づいて情報を提供することができる。同様に、トラッカモジュール３０２は、時間に伴って受け取られたデータにおける傾向を追跡するべく、医療装置プラットフォーム２０４に含まれていてもよい。アナライザモジュール３００、トラッカモジュール３０２、及びその他のモジュールの組合せを通じて、ＣＩＥＤ患者の増大の傾向、製造者によって受け取られ且つソートされたデータの百分率、受け取られたデータの全体的な送信、看護正規化の規格に対して適用された装置カウント、及びこれらに類似したもの、などの装置情報のスナップショットを提供することができる。１つ又は複数の医療装置から受け取られたデータに関する、且つ、アナライザモジュール３００によって分析された、更に多くの分析結果及び情報については、更に詳細に後述する。

又、アグレゲータモジュール３０４も、医療装置プラットフォーム２０４に含まれうる。一般に、アグレゲータモジュール３０４は、上述の製造者システム２０６のそれぞれから診断及びその他の装置に関係するデータを取得するように、且つ／又は、１つ又は複数のＣＩＥＤから情報を取得するように、構成することができる。一例においては、アグレゲータモジュール３０４は、それからデータを取得するべく必要とされる特定の製造者システム２０６の特定のセキュリティ手段、通信プロトコル、データフォーマット、及びその他の特性を使用してデータを取得するべく、製造者に固有のクーリエエンジンを利用することができる。更には、製造者に固有のクーリエエンジンのそれぞれは、クラウド演算システム２０８が、一貫性を有する方式により、患者指向の情報及び／又は提供者指向の情報をもたらすべく、装置データを処理しうるように、取得されたデータを製造者システム２０６のすべてから受け取られたデータに適用される統一されたフォーマットに変換することができる。少なくともいくつかの例においては、アグレゲータモジュール３０４を使用することにより、特に、そのそれぞれがその独自のデータフォーマット、通信プロトコル、及びこれらに類似したものを利用しうる、複数の製造者からの装置の診断データ及びその他の情報を埋め込み型医療装置から取得するためのクリニック内の情報技術（ＩＴ：Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）専門家に対するニーズを低減することができる。

提供者ポータル３０６は、そのクリニックの患者に対応する提供者指向の装置データ情報に対するクリニックスタッフによるアクセスを促進するクリニックシステム２０２に対してウェブインターフェイスを提示するように構成することができる。同様に、医療装置患者ポータル３１０は、特定のクリニックの患者に対する、或いは、一般には、埋め込み型医療装置の患者に対する、別個のウェブインターフェイスを提供するように構成することもできる。提供者ポータル３０６及び患者ポータル３１０は、適宜、提供者指向の又は患者指向の情報に対するアクセスを許容するべく、それぞれ、クリニックスタッフ及び患者のログオンを利用することができる。いくつかの例においては、提供者ポータル３０６に対するログオンは、上述のように、シングルサインオン（ＳＳＯ）機能を介して、クリニックシステム２０２の外部の、或いは、その内部に配置された、その他のシステム（例えば、医療レコードマネージャ２１６及び／又は図２のＨＩＥシステム２２０）に対するクリニックスタッフによるアクセスを促進しうる。これに加えて、提供者ポータル３０６及び／又は患者ポータル３１０は、装置に関係した情報に対する、例えば、埋め込まれたウェブリンクなどの、アクセスポイントを含みうる、患者の電子健康レコード（ＥＨＲ：Ｅｌｅｃｔｒｏｎｉｃ Ｈｅａｌｔｈ Ｒｅｃｏｒｄ）に対する患者又は提供者アクセスを促進するアプリケーションプログラミングインターフェイス（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供することもできる。

その他の例においては、医療装置プラットフォーム２０４は、提供者ポータル３０６及び患者ポータル３１０とは別個に、クリニック又は保険会社と関連する管理要員、クリニック又は保険会社と関連する役員、１つ又は複数の心臓装置製造者の従業員など、用のポータルなどの、その他の情報ポータルを提供してもよく、或いは、含んでいてもよい。このような例においては、医療装置プラットフォーム２０４の潜在的なユーザーのそれぞれの特定のクラス又はグループは、特定のアクセス範囲又はアクセス権限の組、セキュリティ要件の組（例えば、ユーザー名、パスワード、コンピュータシステムなどに対する要件）と関連付けることができる。この結果、ユーザーのそれぞれのグループは、提供者ポータル３０６及び／又は患者ポータル３１０に類似した、対応するユーザーポータルを利用することができる。それぞれの特定のポータルは、異なるユニフォームリソースロケータ（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を介してアクセス可能であってもよく、或いは、１つ又は複数のその他の方法によって弁別することもできる。

スケジュールモジュール３０８は、クリニックの患者との間の、事務所内又は自宅内装置チェック又はプログラミング訪問などの、アポイントをスケジューリングするべく、患者及び／又はクリニックスタッフがアクセス可能なウェブインターフェイス（例えば、上述のウェブポータル又は別個のウェブポータル）を提示するように構成することができる。いくつかの例においては、スケジューリングウェブポータルは、それぞれの特定のクリニックについてカスタマイズされており、これにより、恐らくは、クリニックによって提供されるサービスに関する更なる情報、クリニックスタッフのメンバの説明、などを提供することができる。

ドケットジェネレータモジュール３１２は、患者と関連する１つ又は複数のドケット又は受け取られたデータの集合体を生成するように、構成することができる。一般に、ドケットは、受け取られた患者ＣＩＥＤ送信の解釈及びレコードを要約する又はその他の方法で提供する、ある種のレポートである。ドケットのすべて又は一部分には、送信の際に受け取られた、且つ、分析及び承認のためにクリニックスタッフに提供された、情報を入力することができる。ドケットは、装置製造者情報、クリニックスタッフ承認、臨床データ、看護計画、装置用の監査証跡、患者情報、データ分析のサマリステートメント、などのような情報を含みうる。患者情報又は複数の医療装置から受け取られた情報に関する任意の情報は、ドケットジェネレータモジュール３１２を通じてドケット内に含むことができる。

ワークフローエンジン３１４は、定期的な装置チェック、結果的に得られる診断データ、及び１人又は複数の患者の埋め込み型医療装置に関係するその他の情報に関する情報を監視し、且つ、その情報に基づいて、例えば、装置チェックスケジュールに対する変更、埋め込み型医療装置から得られた特定のタイプの情報に対する変更、取得された情報の処理方式に対する変更、及びこれらに類似したものなどの、クリニックのワークフローに対する変更を推奨し、これにより、恐らくは、クリニックの動作を相対的に効率的なものにするように構成することができる。

ビリングエンジン３１６は、クリニックスタッフが、患者の埋め込み型医療装置との関係において実行される１つ又は複数の臨床動作の通知を入力しうる、且つ、その動作を表す現時点において適切なビリングコードが生成される、インターフェイスを（例えば、提供者指向のウェブポータルを介して）提示するように、構成することができる。更には、１つ又は複数のこのような動作の結果的に得られるビリングコードは、患者や医療保険会社などへの提示のために、ビリングコードサマリシート又はその他のフォーマットに更に挿入することができる。いくつかの例においては、ビリングエンジン３１６は、ＰＰＳ（Ｐｒｏｓｐｅｃｔｉｖｅ Ｐａｙｍｅｎｔ Ｓｙｓｔｅｍ）において利用可能なＣＭＳ（Ｃｅｎｔｅｒｓ ｆｏｒ Ｍｅｄｉｃａｔｅ ａｎｄ ｍｅｄｉｃａｉｄ Ｓｅｒｖｉｃｅｓ）からビリングコードの変化に関する情報を受領又は取得することができると共に、埋め込み型医療装置に関係する臨床動作に対応するビリングコードを更新するべく、これらの変更を利用することができる。

装置リコール管理モジュール３１８は、そのクリニックと関連する埋め込み型医療装置のリコールについて、タイムリーな通知と、更に詳細な情報と、をクリニックスタッフ又はその他のユーザーに提供する（例えば、「プッシング」する）ように、構成することができる。上述のように、医療装置リコール管理モジュール３１８は、例えば、正式な連邦政府機関、州、及び／又は国家医事局、通信社などのような、１つ又は複数のサイトから情報を収集しうると共に、リコール情報を生成してもよく、このような情報をリコール勧告レジストリデータベース２２４内において収集することができると共に、例えば、電子メール、テキスト、患者指向のウェブポータル、及び／又はそれぞれの影響を受けるクリニックに対応する提供者指向のウェブポータルを介して、リコール勧告レジストリデータベース内の情報に基づいて埋め込み型医療装置の発見されたリコールに関する通知を提供することができる。

レコード統合モジュール３２０は、例えば、処理済みの装置に関係するデータに対するアクセスを促進するウェブリンクを患者のＥＨＲに埋め込むことにより、処理済みの診断データ及び埋め込み型医療装置に関係するその他の情報により、ＥＨＲを更新するか又はこれを入力するように、構成することができる。このようなデータは、例えば、埋め込み型医療装置上において実行された診断の日付、診断結果の数値データ及び／又はグラフ、診断結果に基づいた推奨及び／又は実行された動作、装置によって検出されたデータに基づいた装置の動作に対する患者の健康又は生物学的応答、などを含みうる。

次に図４～図１７を参照すれば、１つ又は複数の埋め込み型医療装置から医療装置プラットフォーム２０４において受け取られる情報及びデータにアクセスする、これを分析する、観察する、或いは、その他の方法で管理するべく、ポータル又はユーザーインターフェイスの様々な例が提供されている。１つの特定の実装形態においては、ユーザーインターフェイスは、図１との関係において上述したものなどの、ユーザー装置１０８上において表示されている。ユーザー装置１０８上において表示される様々なユーザーインターフェイスは、ユーザー装置により、ネットワーク１０６を通じてアクセスすることができると共に、システム１００の１つ又は複数のサーバー１１２により、実行することができる。更には、１つ又は複数の患者の１つ又は複数の埋め込み型医療装置などの、１つ又は複数の医療装置１０４は、情報又はその他の動作データを医療装置マネージャ１０２に提供することができると共に、データベース１１０内において保存することができる。例えば、健康レベル７（ＨＬ７：Ｈｅａｌｔｈ Ｌｅｖｅｌ ７）プロトコルを利用することにより、医療装置マネージャ１０２は、装置及び／又は患者に固有のデータ、並びに、装置タイプ及びモデル用の装置フィールド、を含む、装置製造者リモート送信からの通信を受け取ることができる。医療装置マネージャ１０２は、このデータをユーザーインターフェイスを通じて提示されるデータに変換するか又はその他の方法で正規化することができる。別の例においては、患者は、インターフェイスを通じて直接的にデータ又は情報を医療装置マネージャ１０２に提供してもよく、或いは、マネージャへの入力のために、臨床スタッフに提供することもできる。次いで、この情報は、医療装置マネージャ１０２により、様々な方法で処理することができると共に、ユーザーインターフェイスを通じて、ユーザーにより、提示又は管理することができる。従って、（クリニックの看護師又は医師などの）ユーザーは、以前においては利用可能ではない方式により、患者ごとに、或いは、複数の患者に跨って、１つ又は複数の医療装置１０４からのデータを受信、アクセス、分析、及び／又は管理することができる。

本明細書において記述されるように、医療装置マネージャ１０２は、ＣＩＥＤ装置送信と、事務所内インタロゲーション及びリモートインタロゲーションの両方を含むインタロゲーションと、を管理している。一実装形態においては、事務所内インタロゲーションは、医療装置マネージャ１０２によって生成される事務所内アップロードインターフェイスを利用しており、これにより、ユーザーは、インポート用の１つ又は複数のファイルをドロップ又は選択することができる。これらのファイルには、ネットワーク上において、メモリ（例えば、フラッシュドライブ）を介して、且つ／又は、これに類似した方式により、アクセスすることができる。１つ又は複数のファイルが選択されたら、インターフェイスは、医療装置マネージャ１０２がインタロゲーションデータを処理するのに伴って、アップロードの進捗の視覚化を生成することができる。一実装形態においては、限定を伴うことなしに、データ抽出に対応する遭遇日付、患者名、患者誕生日、クリニック名、装置製造者、装置タイプ、及び装置連番を含む、遭遇情報を検証、追加、又は編集するべく使用されうる間隙インターフェイス（ｉｎｔｅｒｓｔｉｔｉａｌ ｉｎｔｅｒｆａｃｅ）が生成されている。データが失われている場合には、ユーザーは、そのデータを間隙インターフェイスを介して入力することができる。医療装置マネージャ１０２は、患者が新しい患者であるのか又は既存の患者であるのかを判定することができると共に、相応して進捗することができる。インタロゲーションデータの処理の進捗、進捗、編集、又は取消の選択肢、並びに、医療装置マネージャ１０２へのデータのアップロードの進捗、を含む、複数の視覚化が、インターフェイスを介して提供されている。ユーザーには、インタロゲーションから関連するＰＤＦをアップロードするかどうかを含む、選択肢を更に提供することができる。処理及びアップロードの際に、データファイルが解析され、且つ、別個のデータが、解析済みのデータファイルからインポートされる。インポートの際に、ユーザーは、ユーザーインターフェイスを介して、インポート済みのデータを追加、編集、及び検討することができる。ＰＤＦがインポートされた場合には、これは、インポート済みのデータと共に、提示されてもよく、或いは、さもなければ、インターフェイスを介してアクセス可能であってもよい。インポート済みのデータは、自動的に又は手動で、保存することができる。

換言すれば、一実装形態においては、それぞの装置製造者は、医師事務所内に配置された製造者に固有のプログラマ（ｐｇｍ）を有する。プログラマは、医療装置１０４の近傍において保持されたハンドヘルド型の磁気装置を介して患者用装置データのインタロゲーションを実行する（「プリング」又は「読取り」を実行する）事務所内デスクトップ装置である。プログラマデータは、ユニバーサルシリアルバス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ドライブなどの、安全なメモリへのエクスポートのために利用可能である。このデータは、しばしば、多くのファイル及び無関係の情報を含む。データは、ドラッグ及びドロップ又は手動的なインポートファイルの選択などの、様々なメカニズムを通じて、医療装置マネージャ１０２により、インポートされる。次いで、医療装置マネージャ１０２は、様々なマーカーについてデータを解析する。インポートされたら、装置及び患者に固有のデータ及び／又はその他の装置に固有のデータフィールドを自動的に識別するべく、遭遇（送信）が処理される。

更に具体的には、ファイルのアップロードの準備が完了したら、医療装置マネージャ１０２は、キー識別子についてデータファイルを解析する。ユーザー確認の後に、医療装置マネージャ１０２は、それぞれのベンダがプログラマから提供するパッケージ化されたＰＤＦレポートを含む、解析されたデータファイルからのデータにより、フィールドに自動的に入力する。一実装形態においては、本明細書において記述されているように、医療装置マネージャ１０２は、インタロゲーションからデータファイルを生成し、データファイルの初期アップロードを実行し、患者及び装置を識別し、データファイルを解析し、解析されたデータファイルをアップロードし、解析されたデータファイルから送信概要を生成し、且つ、ワークフローを生成している。

一実装形態においては、データファイルは、患者訪問の際の事務所内遭遇の後に、埋め込みの時点において、チェックの際に、且つ／又は、これらに類似したものにおいて、生成されている。データファイルは、医療装置マネージャ１０２により、製造者プログラマにより、且つ／又は、これらに類似したものにより、生成することができる。遭遇は、製造者プログラマを使用した、装置の読取り、異なるパラメータの性能の試験、装置上の設定の変更（再プログラミング）、及び／又はこれらに類似したもの、から構成されうる。別の実装形態においては、データファイルは、リモート送信から生成されている。関連するＰＤＦを含む、データファイルは、アップロードにおいて使用されるべくメモリに保存されてもよく、或いは、さもなければ、医療装置マネージャ１０２に送信することもできる。ユーザーは、ＰＤＦをアップロードするかどうかを選択することができる。いくつかの実装形態においては、医療装置マネージャ１０２は、アップロードを単一の識別されたデータファイルに制限している。

データファイルの初期アップロードの際には、データファイルが、識別され、且つ、検証される。それぞれの製造者は、ＰＤＦと共に、プログラマが生成するその独自のデータファイルタイプの組を有する。更には、それぞれの製造者は、複数のデータファイルサブタイプを有することもできる。ファイルタイプは、装置又はプログラマファームウェアバージョンによって判定されうるバリエーションを更に有しうるが、これは、結果的に、ファイルタイプの過多をもたらす。医療装置マネージャ１０２は、ファームウェアバージョンを識別し、且つ、識別されたファームウェアバージョンに基づいた位置において、データファイルの解析を開始する。

関連するデータが、ファイルの読取りが困難である、データが散乱している、並びに、しばしば、エンコードされている、ことに起因して、容易にアクセス可能ではないことから、医療装置マネージャ１０２は、複数の解析ステージにおいて、データを解析している。初期アップロードに後続して、医療装置マネージャ１０２は、複数の識別子に照らして、一連のチェックを実行している。一実装形態においては、識別子は、制限を伴うことなしに、連番、装置モデル、製造者、及びクリニックを含む。結果に基づいて、医療装置マネージャ１０２は、データファイルが、既存の患者に、新しい患者に、既存の患者だが新しい装置に、対応しているかどうか、或いは、患者が存在しているが別のクリニックに添付されているかどうか、を判定することにより、データファイルの初期解析を実行している。患者が既存である場合には、データファイルは、対応する現時点の患者レコードと関連付けられ、且つ、データファイルが新しい患者と関している場合には、新しい患者レコードが生成される。初期解析の際に、医療装置マネージャ１０２は、ファイルタイプ、ファイルフォーマット、及びデータファイル内のデータコンテンツを解析している。一実装形態においては、医療装置マネージャ１０２は、限定を伴うことなしに、名前、苗字、誕生日、製造者、装置、送信日付、及び連番を含む、キー識別子を見出すべく、データファイルを解析している。初期解析の結果に基づいて、医療装置マネージャ１０２は、患者が、新規であるのか、既存であるのか、或いは、その他の条件を充足しているのか、についてユーザーに通知し、これにより、適宜、間隙インターフェイスを使用することにより、ユーザーが動作を実行することを許容することができる。一実装形態においては、ユーザーは、レコード（例えば、ドケット）の生成によって進捗するべきか、或いは、入力されたドロップゾーンに戻るべく取り消すかどうか、を判定するべく、初期解析からの情報を検証することができる。レコードの生成によって進捗した後に、医療装置マネージャ１０２は、集約的なデータマッピングに基づいて別個のデータを分析及び抽出することにより、第２解析を実行する。第２解析に後続して、医療装置マネージャ１０２は、解析済みのデータを患者パネルに入力する。解析済みのデータに含まれているデータポイントは、６～２００個の範囲であってよい。

一実装形態においては、患者パネルは、送信概要インターフェイス内において関連するＰＤＦと共に視覚化された解析済みのデータを含む。ユーザーは、情報を編集してもよく、除去してもよく、或いは、事前に入力された患者パネルに追加することもできる。送信が新しい患者と関連している場合には、患者パネルは、限定を伴うことなしに、装置タイプ、製造者、及び連番を含むことができると共に、アップロードと関連する単一事務所内送信を示す新しい患者レコードが生成される。送信が既存の患者と関連している場合には、キー識別子の組がマッチングされる。患者レコードは、存在する場合に、事務所内送信が、事務所内インタロゲーションのスタックに追加されることを示している。リモート送信のスタックのみしか存在していない場合には、或いは、現時点の事務所内インタロゲーションスタックが存在していない場合には、医療装置マネージャ１０２は、新しいドケットインスタンスを生成する。従って、医療装置マネージャ１０２は、リモートインタロゲーションとは別個の事務所内インタロゲーション用のワークフローを生成及び追跡することができる。従って、医療装置マネージャ１０２は、事務所内ドケットが固有のＣＰＴ及びＩＣＤ－１０コードを含む状態において、事務所内ドケット及びリモートドケットを生成することができる。

一実装形態においては、医療装置マネージャ１０２は、技術者による患者事務所内インタロゲーション検討及びインプレッションの証跡並びに提供者の承認を文書化したレポート（例えば、ドケット）を生成している。レポートは、患者情報、プロプライエタリな履歴提示、検討者によって添付されている場合には送信されたＰＤＦファイル、及び／又はこれらに類似したものを組み合わせることにより、事務所内又はリモートインタロゲーションのために、医療装置マネージャ１０２により、生成されている。レポートは、医療装置マネージャ１０２により、クラウド内において生成され、且つ、保存又はパッケージ化することができると共に、ＰＤＦダウンロードとして提供することができる。

一実装形態においては、リモートインタロゲーションの場合に、医療装置マネージャ１０２は、装置及び患者に固有のデータ及び装置タイプ及びモデル用の装置フィールドを含むデータファイルを装置製造者リモート送信から受け取るべく、ＨＬ７通信プロトコル及びＩＤＣＯデータ規格を使用している。医療装置マネージャ１０２は、製造者によって確立された、公開及び定義された通信経路を使用することにより、製造者に対する安全な接続を構築する。患者用装置１０４から送信された装置送信は、まず、製造者によって受け取られ、且つ、次いで、製造者ＰＤＦレポートを含むデータファイルが、医療装置マネージャ１０２により、受け取られる。受け取りの際に、医療装置マネージャ１０２は、複数の処理ステージを通じて、データの完全性及び送信の受け取りを検証するべく、それぞれの新しい医療装置１０４を限定している。一実装形態においては、事務所内インタロゲーション又はリモートインタロゲーションの場合には、医療装置マネージャ１０２は、データマッピング及びＩＤＣＯデータ正規化を通じてＨＬ７データ抽出を実行し、且つ、装置設定計算及び正規化を生成している。

一実装形態においては、医療装置マネージャ１０２は、データマッピングの際に固有のデータフィールドをマッピングすることにより、識別されてはいないＨＬ７データを抽出している。すべてのケースにおいて、医療装置マネージャ１０２は、データを識別し、且つ、検証している。例えば、いくつかの製造者は、パラメータを送信データファイルの備考セクションに送信する一方で、その他のものは、この情報をどこか別の場所において保存している。医療装置マネージャ１０２は、適切なデータを識別し、関連するデータを抽出し、且つ、これをその他のデータと組み合わせ、且つ、これを患者パネル内において製造者とは独立したフォーマットにおいて提示するべく、データファイルを解析している。医療装置マネージャ１０２は、任意の関連するバックアップ計算又は情報と共に、製造者に固有の用語が損なわれることなしに提示される方式により、データファイルを解析することができる。

ＩＤＣＯデータ正規化の際に、医療装置マネージャ１０２は、イベントタイプを識別し、且つ、正規化する。更に詳しくは、すべての製造者は、異なる記述子を有する同一のイベントタイプを識別する。従って、医療装置マネージャ１０２は、変化する記述子を有する同一のデータを送信するすべての製造者方法を検討し、且つ、正規化している。例えば、イベントＮＳＶＴは、製造者に基づいて、ＮｏｎＳｕｓＶＴ、Ｎｏｎ－ＳＶＴ、ＮＳＶＴ、ＮｏｎＳｕｓｔ－ＶＴ、及び／又はこれらに類似したもの、として表されうる。更には、ＨＬ７は、曖昧であり、且つ、医療装置マネージャ１０２は、ショック量を集計し、且つ、それぞれの製造者からのＰＤＦにおいて使用される用語にＨＬ７における用語をマッピングする。更には、ゾーンの名前は、製造者の間において変化しており、且つ、ＰＤＦ内において、異なる方式により、使用されている。従って、医療装置マネージャ１０２は、ＨＬ７タイプの名前を取得し、且つ、これらを、すべての製造者に跨ってＰＤＦ内において使用されている用語にマッピングする。患者レポートにおいて、データは、表示内において、製造者に跨って正規化されている。一実装形態においては、共通の且つ正確な表示を臨床ユーザーに提示するべく、医療装置マネージャ１０２により、それぞれの製造者ごとに、２００個超の固有のデータフィールドが、異なる製造者及び装置に跨って正規化されている。

一実装形態においては、製造者は、装置データをＨＬ７を介してＩＤＣＯフォーマットにおいて纏めて送信している。製造者は、すべてのデータフィールドを送信するが、装置は、それらのフィールドのうちの１つのみによって管理されるようにプログラミングすることができる。ＩＤＣＯを介して送信されたＰＤＦレポートは、関連する「プログラミング」されたデータフィールドを正しく表示する。従って、医療装置マネージャ１０２は、それぞれの送信を検査し、且つ、装置設定計算においてプログラム設定に対応するデータを正確に表示するべく、プログラム設定を対応するデータフィールドに相関させる。ＩＤＣＯ規格は、データ検知フィールドに対するプログラム設定の関連付けを含んではいない。すべてのデータが、容易に利用可能であるわけではなく、且つ、医療装置マネージャ１０２により、メッセージングされる必要があるわけでもない。例えば、医療装置マネージャ１０２は、装置がプログラミングされる方式を理解するべく、インピーダンスを分析することができる。医療装置マネージャ１０２は、リング、チップ（ｔｉｐ）、コイル、カンなどを含む、適切な計測タイプを判定するべく、ＨＬ７データを検査する。これらのコンポーネントの間の計測が付与される。装置が、リング→チップとして、プログラミングされている場合には、医療装置マネージャ１０２は、インピーダンスがその医療装置１０４用の適切な計算であると判定する。

更には、医療装置マネージャ１０２は、ショック量をグループ化することができると共に、これらをＰＤＦ表示に従ってリスト化することができる。医療装置マネージャ１０２は、ＰＤＦにマッチングするように、データを組み立てる。治療タイプ（例えば、バースト、ショック）及びジュールを単位とする電荷量が編集される。又、ＨＬ７は、ＰＤＦ内において使用される値を常に有するわけではないことから、医療装置マネージャ１０２は、ＨＬ７値を製造者がＰＤＦ内において使用する相対的に有意な値にマッピングしている。例えば、なんらかのＲｘ－ＯｆｆがＰＤＦ内において表示され、これは、合格した値ではない。この値を表示するべく、医療装置マネージャ１０２は、その他の要因及びデータを分析する。医療装置マネージャ１０２は、ＨＬ７値を正規化する。例えば、製造者は、ＶＴ１及びＶＴ２用の異なる記述子を有している。医療装置マネージャ１０２は、ＶＴ１又はＶＴ２として値を識別するべく、これらを短縮し、且つ、これらをリマッピングし、或いは、その他のデータを観察する。ＩＤＣＯデータセットは、緩いものであり、且つ、乏しく定義されており、且つ、装置設定を反映するべく、医療装置マネージャ１０２により、正規化しなければならない。一例においては、医療装置マネージャ１０２は、別個のデータを取得し、これを１つに纏めている。いくつかのケースにおいては、医療装置マネージャ１０２は、ＰＤＦ内において識別された結論に到達するべく、その他のフィールド内の値を識別している。一実装形態においては、医療装置マネージャ１０２は、フィールドを解析し、且つ、フレーズを生成しており、これは、１つにグループ化するべきフィールドを知るべく、ゾーンがオフであるのか、モニタであるのか、或いは、アクティブであるか、を知るべく、使用される。Ｓ－ＩＣＤは、この情報がデータファイル内に含まれてはいないことから、医療装置マネージャ１０２が装置の知識から一方的に入力する固有のゾーンを有する。

いくつかの製造者は、患者及び／又は装置の寿命にわたって永遠に医療装置１０４用のすべての装置読取りを保存しており、これは、新しいイベントデータを送信する際の以前のイベントの報告を結果的にもたらしうる。装置設定の正規化の際に、医療装置マネージャ１０２は、以前には受け取られていない新しいイベントが強調表示されるように、このデータをフィルタリングしている。いくつかの製造者は、医療装置マネージャ１０２がそれぞれの医療装置１０４のデータ管理構造に基づいて選択的にフィルタリングするように、すべての送信の後に、これらのカウンタをリセットしている。イベントが、以前に報告されている場合には、医療装置マネージャ１０２は、イベントをレガシーイベントとして、バケッティング（ｂｕｃｋｅｔ）するか又はその他の方法でラベル付けし、これは、イベントが、送信がカバーしている（例えば、送信日付と以前の送信の送信日付の間の）時間フレーム外において発生したことを意味している。情報は、ＨＬ７／ＩＤＣＯデータセット内に存在していることから、医療装置マネージャ１０２は、イベントを依然として報告しうるが、医療装置マネージャ１０２は、これを現時点のイベントとして送信内に含めることはせず、その理由は、これが、既に臨床的に対策されているであろうからである。その他の項目は、症状の出現として到来するが、（例えば、定期的なＥＧＭ）ではなく、且つ、医療装置マネージャ１０２は、まったく症状の出現ではない製造者の間の２０個の症状の出現タイプにわたってスクラビングする。

データファイルの受け取り、解析、及びアップロードに後続して、医療装置マネージャ１０２は、例えば、図４～図１７を参照して本明細書において記述されている一連のインターフェイスを通じて、医療装置マネージャ１０２によって管理されているワークフローを開始する送信概要及びレポート（例えば、ドケット）を生成する。

図４は、患者用医療装置データを管理するための例示用の装置管理ユーザー固有インターフェイスを示している。一般に、図４のユーザーインターフェイス４００は、（その独自の装置データを分析するクリニックの看護師又は医師又は患者などの）ユーザーの役割に対するユーザー固有のポータルであるデータ及びデータ管理選択肢を提供している。従って、ユーザーインターフェイス４００内において表示されているデータ管理選択肢（その一例が図４に示されている）は、ユーザーがユーザーインターフェイスにアクセスする役割に応じて、変更されてもよく、或いは、異なっていてもよい。医療装置マネージャ１０２は、システムにアクセスする際にユーザーによってシステムに提供されるログイン情報に基づいて、ユーザーインターフェイス４００のスタイル及び／又はコンテンツを判定することができる。更に詳しく後述するその他のインターフェイスが、類似の識別情報に基づいて、特定のユーザーにとって利用可能であってもよく、或いは、そうでなくてもよい。

図４に示されている特定の例においては、医療装置情報及びデータ管理選択肢のいくつかの提示が提供されている。具体的には、ユーザーインターフェイス４００は、所定の期間にわたって受け取られた医療装置からの送信の数の通知を提供する送信サマリ部分を含みうる。例えば、送信サマリ４０２は、ユーザーによる最後のログイン以降に、現時点の２４時間の期間にわたって、医療装置マネージャ１０２の寿命にわたって、且つ、これらに類似したものにわたって、受け取られた送信の合計数のカウントを含みうる。更には、送信サマリ又はトラッカ４０２は、送信カウントを１つ又は複数のカテゴリにサブ分割することもできる。図示の例においては、送信サマリ部分４０２は、イベント４１２を伴って、且つ／又は、イベント４１４を伴うことなしに、アラート４１０と共に受け取られた送信の数を含みうる。上述のように、送信は、医療装置マネージャ１０２と通信状態にある１つ又は複数の医療装置から受け取ることができる。一例においては、埋め込み型装置を有する患者は、データを装置から医療装置マネージャ１０２に提供するべく、クリニックを訪問することができる。別の例においては、医療装置は、無線により、或いは、遠隔方式により、データを医療装置マネージャ１０２に提供することができる。データが受け取られる方法とは無関係に、ユーザーインターフェイス４００の送信サマリ４０２は、所定の期間にわたって医療装置から受け取られたデータのサマリ又は分析を提供している。

又、ユーザーインターフェイス４００は、患者サマリ部分４０４を含みうる。この場合にも、この部分４０４を通じて表示又は提供される情報は、ユーザーの役割に基づいたものであってよい。一例においては、患者サマリセクション４０４は、ユーザーが、クリニック従業員であるか、或いは、さもなければ、複数の患者情報にアクセスするための許可を有している場合には、その装置が、所定の期間にわたって性能データを医療装置マネージャ１０２に送信したすべての患者のリストを提供することができる。このようなリストは、患者ごとに受け取られたいくつかの送信を含むことができると共に、受け取られた送信のタイプと関連する色通知を含んでいてもよく、或いは、含んでいなくてもよい。別の例においては、患者サマリセクション４０４は、ユーザーがその患者である場合には、特定の患者の情報のみを提供することができる。一実装形態においては、患者サマリ情報４０４は、送信情報による代わりに、患者情報により、表示することができると共に、受け取られたいくつかの装置送信を表示することができる。或いは、この代わりに、情報は、患者当たりの送信の集合体が表示されえないように、送信タイプ又は送信の数ごとに、表示することもできる。後述するように、患者サマリ４０４内の患者情報のそれぞれのリストは、クリニック従業員によって完了されるべきその患者用のワークフローと結び付けられていてもよく、或いは、関連付けられていてもよい。

ユーザーインターフェイス４００の別の部分は、患者サマリ４０４内において表示されている（或いは、完了させるべきワークフローの任意のその他の集合体からの）イベントのうちの１つ又は複数の完了状態を要約したフローサマリ４０６を提供することができる。理解されるように、医療装置から受け取られた送信は、アラート又はイベントを有する送信などの、送信を分析するための又はこれらに対処するためのワークフローを開始することができる。フローサマリセクション４０６は、オープンワークフロー４１８から、ペンディングアクションワークフロー４２０、承認用ワークフロー４２２、及び／又は完了済みワークフロー４２４までの、ワークフローの状態のサマリを提供することができる。フローサマリ４０６は、任意の数のワークフローステージ４１８～４２４を含むことができると共に、それぞれのステージにおけるいくつかのワークフローをサマリ内において表示することができる。クリニックスタッフの場合には、フローサマリ４０６は、相対的に良好なワークフロー管理のために任意の期間にわたる潜在的なワークフロー活動の概要を提供することができる。

更には、ユーザーインターフェイス４００は、クリニック、患者、装置、品質スコア、負担スコア、ターゲット追跡などを中心として組織化された、受け取られたデータの洞察を付与するべく、受け取られた送信の分析を提供するウィジェット部分４０８を含むことができる。一般に、ウィジェット４０８は、分析情報４２６、品質スコア情報４２８、及びベンチマーク情報４３０を含みうるが、ウィジェット部分を通じて、更に少ない又は多くの数のウィジェットを提供することもできる。ユーザーインターフェイス４００の様々なウィジェット４０８の動作及び目的については、図５～図７を参照して更に詳細に後述する。

図５は、患者用医療装置を管理するための例示用の分析ウィジェットユーザーインターフェイス４２６を示す図である。一般に、分析インターフェイス４２６は、特定のクリニックと関連する送信の傾向の１つ又は複数の自動化されたスナップショットを提供することができる。例えば、装置内訳セクション５００は、患者又は送信ごとにソートされた送信情報内訳を観察するべく選択するための、ドロップダウンメニュー（或いは、その他の選択メカニズム）を提供することができる。カテゴリが選択されたら、限定を伴うことなしに、装置製造者ごとの内訳、装置タイプごとの内訳、及び／又は装置モデルごとの内訳を含む、受け取られた送信の装置固有の情報の通知を提供する１つ又は複数の装置内訳グラフ５０８を提示することができる。ユーザーインターフェイス内には、患者又は送信に基づいてソート可能である、更に多くの又は少ない数の内訳グラフ５０８を含むことができる。

又、ユーザーインターフェイス４２６は、インターフェイスのユーザーに提示される機会スコア５１０を含むこともできる。一実装形態においては、機会スコア５１０は、最大償還機会をドル又は臨床相対値単位（ＲＶＵ：Ｃｌｉｎｉｃａｌ Ｒｅｌａｔｉｖｅ Ｖａｌｕｅ Ｕｎｉｔ）を単位として示すべく、看護の正規化規格に適用される装置カウントを提供している。例えば、医療装置マネージャ１０２は、年毎の事務所内フォローアップ頻度及びリモートフォローアップ頻度を含む、それぞれの医療装置について許容された最大ビリングを判定することができる。これらは、償還レートによって乗算することができると共に、その特定の装置の患者の数によって乗算することもできる。この計算は、機会５１０の部分を通じてユーザーインターフェイス４２６内において提示することができる。

いくつかの実装形態においては、分析ウィジェットインターフェイス４２６は、送信サマリ部分５０２を含みうる。送信サマリ部分５０２は、受け取られた送信に適用するべき特定の期間又は時間の長さを選択するためのドロップダウンメニュー（又は、その他の選択メカニズム）を含むことができる。例えば、メニューは、以前の３０日間の送信、１５日間の送信、２４時間の送信、などの選択を提供することができる。時間フレームが選択されたら、送信部分５０２は、恐らくは、製造者又はベンダごとにソートされた、選択された時間フレームにわたって受け取られた送信の合計量の百分率の通知を図示又は提供することができる。又、選択された時間フレームにわたって受け取られた送信の数を示すその他のメカニズムを表示することもできる。又、送信サマリ部分５０２は、インターフェイス４２６にログインしたユーザーの全体的な活動のサマリを含むこともできる。例えば、選択された時間フレーム用の送信の合計数の通知５２４のみならず、表示されている送信に含まれるドケットの数５２６も、表示することができる。又、いくつかの実装形態においては、選択された時間フレーム内において受け取られた送信の合計数を表示することができる。

同様に、分析ウィジェットインターフェイス４２６は、送信ホットスポット部分５０４を含むこともできる。この部分５０４においては、装置タイプ当たりの受け取られた送信の数に基づいて、送信負担のリストを表示することができる。表示される情報は、一実装形態においては、製造者５２８、モデルタイプ５３０、又は送信分析５３２ごとに、ソート可能であってよい。一般に、送信ホットスポット部分５０４は、受け取られた医療装置送信内の患者／装置密度を反映するべく、高需要装置及び患者数を識別することができる。

又、分析ウィジェットインターフェイス４２６内には、リモート患者増加部分５０６を含むこともできる。一般に、リモート患者増加部分５０６は、装置送信が受け取られる患者の合計数及び患者数の月別変化に関するデータ及びグラフを提供している。従って、部分５０６は、インターフェイス内において表示されているデータに含まれるリモート患者５３４の合計数の通知のみならず、所定の期間にわたる患者数の変化を示すグラフ５３６をも含むことができる。一実装形態においては、グラフ５３６は、ユーザーインターフェイス内に含まれている患者数の月別の傾向を示しうる。

上述のように、図４に示されているユーザーインターフェイス４００は、品質スコア４２８のリンク又はその他のインジケータを更に含むことができる。図６は、患者用医療装置を管理するための例示用の品質スコアウィジェットユーザーインターフェイス４２８を示している。このインターフェイスは、ユーザーインターフェイス４００からの品質スコアウィジェットの選択の際に、ユーザー装置１０８上において表示することができる。一般に、品質スコアウィジェットインターフェイス４２８は、産業推奨値に照らして計測された、クリニックの業績の通知又は計算を提供している。例えば、特定の産業基準は、特定の装置が、２回の事務所内チェック（例えば、１８０日ごとに１回）を伴って、毎年４回にわたって（例えば、９１日ごとに）、遠隔方式でチェックすることを要することを示唆しうる。医療装置マネージャ１０２は、看護の新しい標準、或いは、既存の看護の標準に対する変更、に従って、自動的に又は手動的に較正することができる。従って、医療装置マネージャ１０２は、重みを特定のイベント（例えば、送信の見逃し、産業標準との比較における不十分な送信のスケジューリング、頻繁過ぎる送信、頻繁なビリング不能ドケット、過剰に長期にわたってアイドル状態に留まっている送信、送信管理の速度など）に対して適用することができると共に、且つ、その装置／患者の品質スコアを算出することができる。送信管理の速度は、ドケット生成、承認、及びビリングウィンドウの実現（例えば、看護ウィンドウの基準内におけるチェックの処理）を必要としうる。計算の後に、装置又は患者の個々のスコアを品質スコアウィジェットインターフェイス４２８内において表示することができる。例えば、インターフェイス４２８は、患者の名前６１２、判定された産業標準に照らして算出された品質スコア６１４、患者登録日付６１６、装置タイプのインジケータ６１８、最後の送信の日付及び時刻６２０、及びスケジューリングされている次の送信の日付及び時刻６２２を列挙したスコア表６０２を含みうる。一例においては、それぞれの患者の品質スコア６１４は、０～１０において、正規化することができる。

又、品質スコアウィジェットインターフェイス４２８は、送信効率部分６００内の患者スコア表６０２内に含まれるそれぞれの患者の品質スコアのサマリ又はその他の計算を提供することもできる。例えば、送信効率部分６００は、インターフェイスのユーザーと関連するクリニックの全体品質スコア６０４を含みうる。クリニックスコア６０４は、９．１～１０．０、６．１～９．０、３．１～６．０などの、リスト６０２内の品質スコアの数などの既定の範囲に含まれる患者品質スコアの数の通知又はグラフを提供することができる。更には、クリニック品質スコア６０４は、クリニックの患者の全体平均クリニックスコアを含みうる。更には、送信効率部分６００は、部分６０８内の定義されている閾値スコアを超過した、リスト６０２内の品質スコアの数又は百分率、並びに／或いは、部分６１０内のクリニックの状態の平均品質スコア未満の品質スコアの数又は百分率、の通知を含みうる。品質スコアウィジェットインターフェイス４２８内において提供されている情報は、患者サービスの改善が必要とされる時点を通知するべく、産業標準との比較におけるクリニックの全体性能の通知をクリニックスタッフに提供することができる。

又、上述したように、図４に示されているユーザーインターフェイス４００は、ベンチマークウィジェットインターフェイス４２０のリンク又はその他のインジケータを更に含みうる。図７は、患者用医療装置を管理するための例示用のベンチマークウィジェットユーザーインターフェイス４２０を示している。このインターフェイス４３０は、ユーザーインターフェイス４００からの品質スコアウィジェットの選択の際に、ユーザー装置１０８上において表示することができる。一般に、ベンチマークウィジェットインターフェイス４３０は、品質、目標設定、ベンチマーク、及び特定のクリニックに固有の目標に向かう業績を反映した分析を提供している。図７に示されている実装形態においては、ベンチマークウィジェットインターフェイス４３０は、所定の期間にわたる１つ又は複数のクリニックビリング可能メトリック７０６を含むクリニック機会部分７００を含む。例えば、医療装置マネージャ１０２は、ビリング可能である受け取られた送信を算出するか又はその他の方法で判定することができると共に、優先順位付け動作においてクリニックを支援するべく、このようなビリング可能な送信に関するメトリックを提供することができる。特定の一実装形態においては、クリニック機会部分７００は、ビリングされた送信の数、送信をビリングする機会の数、及び機会のうちの実際にビリングされたものの百分率を含む。これは、四半期ごとに、且つ、受け取られた送信の合計数について、提示することができる。

一実装形態においては、医療装置マネージャ１０２は、提供されるサービスの償還スケジュールの形態において、保険会社によって採用される看護の適用可能な標準に基づいて、ビリング機会を算出している。ビリング機会は、償還レートに、利用可能な償還の頻度（ビリングサイクル当たりのビリングされるべく許容されている治療の数）と、患者の数と、を乗算することにより、算出することができる。例えば、看護の標準が、＄９４のレートにおける４回のリモートインタロゲーションと、＄８８のレートにおける２回の事務所内インタロゲーションと、である、ＩＣＤ装置の場合には、年間機会は、４×＄９４＋２×＄８８＝＄５５２／ＩＣＤ患者である。ユーザーが看護頻度及び償還のレートについてターゲット範囲を設定することを許容するべく、構成ツールが使用されてもよく、これは、看護の標準と同一であってもよく、或いは、これとは異なっていてもよく、その理由は、クリニックは、様々な固有の状況に起因して看護の標準超の又は未満の患者の看護を選択することができると共に、異なる償還レートを有することができるからである。最後に、医療装置マネージャ１０２は、最後の送信ビリング日付以降の日数をカウントすることにより、ビリング可能なイベントの間の最小及び最大日数（例えば、３０又は９０）用の償還ガイドラインを反映する、ビリングウィンドウを識別することができる。ビリングウィンドウは、装置タイプに依存したものあってよい。例えば、ＩＣＤリモート看護償還は、現時点においては、９０日ごとに許容されている。医療装置マネージャ１０２は、そのビリングの間の９０日のインターバルに基づいて、送信がビリング可能であるかどうかを算出する。看護公開の標準は、装置及び治療タイプごとに、日付頻度及び許容可能インターバルを設定することができると共に、医療装置マネージャ１０２は、看護の標準に対する任意の変化に基づいて、ビリングウィンドウ及びビリング可能機会を更新することができる。

ベンチマークウィジェットインターフェイス４３０の別の部分は、判定された機会対実際のビリングのグラフ７０８と、予め設定された目標に向かう進捗を追跡するグラフ７１０と、を提供する遭遇部分７０２である。別の部分は、コミュニティ又は複数のクリニックサイト内のクリニック対その他のクリニックの機会の追跡を提供するグラフ７１２の集合体を示すビリング機会のトレンド７０４を提供している。従って、第１グラフ７１４は、ユーザーのクリニックのクリニック機会を提供してもよく、第２グラフ７１６は、類似のクリニックの機会を提供してもよく、且つ、グラフ７１８は、コミュニティ内の特定のクリニックの機会を提供することができる。この情報は、表示された機会情報に基づいてクリニックの動作を優先順位付けするべく、ユーザーによって利用することができる。

ベンチマークウィジェットインターフェイス４３０及び／又は別のインターフェイスは、コミュニティ分析を更に提供することができる。クラウドに基づいた製品として、医療装置マネージャ１０２は、コミュニティ分析を通知し、教育し、ユーザー及びコミュニティメンバの間において比較し、且つ、共有するべく、ユーザーのコミュニティ、患者の結果、及び看護力学を活用することができる。コミュニティ分析は、限定を伴うことなしに、コミュニティに跨る、且つ、特定の人口又は特定のクリニックに適用された、且つ／又は、これらに類似した、高品質スコアを有するクリニック相互の比較、様々なカテゴリにおけるトップ業績クリニックの識別、特定の患者タイプについて有効である任意の治療の識別、装置人口統計などを含みうる。一実装形態においては、コミュニティ分析は、償還されたドル金額、ビリングされた数、及びビリングされた百分率を伴う、所定の期間にわたるビリング機会を示すクリニックグラフを含みうる。その他の同様な状況のクリニックを要約した、類似のクリニックグラフを提示することができると共に、その他のクリニックに固有の、その他のクリニックグラフを比較のために含むこともできる。一実装形態においては、回帰分析アルゴリズムが、患者看護の未知の傾向、関連付け、及び機会を識別している。比較分析は、業績ベンチマーク、出力を識別するべく、且つ、個々の患者、クリニック、又は領域の比較を生成するべく、データベース計算を必要としている。ターゲット及び／又は実際の機会又は分析を適用することができると共に、コミュニティ傾向ライン、実績、及びトップ業績者に照らして視覚的に表すことができる。

又、上述のように、図４のユーザーインターフェイス４００内には、患者サマリ部分４０４も含まれている。記述されているように、患者サマリセクション４０４は、ユーザーが、クリニック従業員であるか、或いは、さもなければ、複数の患者情報にアクセスする許可を有している場合には、その装置が性能データを医療装置マネージャ１０２に所定の期間にわたって送信した患者のリストを提供することができる。患者サマリインターフェイス８００内の患者リストの数は、ドロップダウンセレクタ８０２又は任意のその他のタイプの選択可能なメカニズムを通じて選択可能であってよい。メニュー８０２を通じて、ユーザーは、合計数の患者サマリの任意のサブセット又はすべてを観察するべく選択することができる。又、利用可能な患者サマリの合計数は、ユーザーインターフェイス８００内において通知することもできる８０４。患者サマリ部分４０４は、送信の重大性のレベルを通知する視覚的識別子（例えば、色符号化）によって弁別されうる、処理の準備が完了したすべての送信の集計されたビューを提供している。それぞれは、フィルタが送信重大性のレベルに従って起動される状態において、ユーザーを患者リストまで導くべく、選択可能である。

一実装形態においては、患者サマリインターフェイス８００は、クリニックの患者のリストと、それぞれの患者の個々の送信データと、を含みうる。図８に示されているように、それぞれの患者リストは、医療装置マネージャ１０２において受け取られた特定の患者と関連する送信の合計数８０６、患者名８１０、特定の送信タイプ８１２、その送信と、或いは、最後に受け取られた送信と、関連付けられたイベント８１４、装置タイプ８１６、及び患者からの特定の送信又は最後に受け取られた送信が受け取られた時刻８１８を含みうる。更には、患者サマリインターフェイス４００内のそれぞれの患者リストは、送信機能の重大性を識別する色インジケータ８０８をも含みうる。例えば、赤色インジケータは、アラートを伴う送信を通知してもよく、黄色インジケータは、製造者から送信されたイベントを有する送信（ＨＬ７）を通知してもよく、緑色インジケータは、送信がカバーしている時間スパンにおいてイベントを伴っていない送信を通知してもよく、且つ、灰色は、（クリニックの医師又はチームリーダーによる承認などに応答して）送信が処理されたことを通知することができる。送信のスタック内においては、緑色が黄色未満であり、黄色が赤色未満である状態において、重大性が、スタックの全体色を決定している。従って、スタックには、スタック内のそれぞれの色が割り当てられている送信の数とは無関係において、最高の重大性のレベルに基づいて、色インジケータ８０８が割り当てられることになる。

全体活動、タイプごとの装置内訳、及びモデル別の装置内訳を含む状態において、既定された期間にわたる製造者の送信カウントを含む、過去の送信を表示することができる。全体活動は、ユーザーが処理した送信の数と、ユーザーが生成したドケットの数と、を含む、特定のユーザーの送信及びドケットカウントを含みうる。装置内訳タイプは、例えば、ＩＬＦ、ＩＣＤ、ＰＭ、ＣＲＴ－Ｐ、ＣＲＴ－Ｄ、及びその他のもの内へのものなどのように、ＨＬ７装置タイプの内訳によるものであってよい。データが、ＩＤＣＯフォーマットにおいて含まれ、且つ、手動入力のためにプロンプトされる状態において、患者及び送信の数を含むことができる。データ内のギャップを強調表示することができる。残りのものがその他のものにグループ化される状態において、モデルごとの装置内訳は、ＨＬ７モデルタイプによるものであってよい。データは、ＩＤＣＯフォーマット内において含むことができると共に、手動入力のためにプロンプトすることができる。データ内のギャップを強調表示することができる。

患者サマリインターフェイス８００内のそれぞれの患者又は送信リストは、クリニックスタッフ又は医療装置マネージャ１０２の任意のその他のユーザーにより、処理することができる。送信の処理は、医療装置マネージャ１０２及び／又はクリニックスタッフによる様々な活動を含みうる、それぞれの送信用のドケット又はワークフローを生成するステップを含むことができる。例えば、送信用のいくつかのワークフローは、送信が分析及び承認されたことを通知するべく、クリニックスタッフから署名又はその他のアクノリッジを受け付けることができる。その他の活動は、限定を伴うことなしに、受け取られた送信に基づいたフォローアップ試験のスケジューリング、患者のビリング、患者との間の治療選択肢の議論、クリニックスタッフに対する１つ又は複数のアラートの送信、特定の装置用の交換コンポーネントの発注、製造者に対する動作状態及び情報の報告、保存用の１つ又は複数の文書の生成、及びこれらに類似したものを含みうる。それぞれの送信ごとに生成されたワークフローは、送信が処理を要するものと見なされる前に実行を要する任意の数の活動又はプロセスを含みうる。このようなワークフロー又は処理を開始するべく、患者サマリインターフェイス８００内のそれぞれの患者送信リストは、それぞれのリストと関連するワークフロー又は処理開始ボタン８２０を含みうる。ユーザーの演算装置１０８への入力装置を通じた開始ボタン８２０の選択により、更に詳しく後述するワークフロープロセスを開始することができる。従って、患者サマリインターフェイス８００を通じて、クリニックスタッフは、受け取られた装置送信を処理することができる。

図９は、患者用医療装置を管理する例示用のユーザー固有のドケットインターフェイス９００を示している。一実装形態においては、ユーザー固有のドケットインターフェイス９００は、患者サマリインターフェイス８００内の上述の開始ボタン８２０を選択することに応答して、ユーザー演算装置１０８上において表示することができる。従って、ユーザー固有のドケットインターフェイス９００は、医療装置マネージャ１０２において受け取られた対応する装置送信に属する情報を提供している。一般に、ドケットインターフェイス９００は、要約された解釈、動作の計画、及び１つ又は複数の患者用装置送信のレコードを提供している。このようなドケットは、医療装置マネージャ１０２により、開始、作成、共有、及び／又は保存することができる。図９において示されてはいるが、ユーザー固有のドケット９００は、医療装置マネージャ１０２の管理者の所望に応じて、更に少ない又は多くの数の特徴、コンポーネント、又は部分を含みうることを理解されたい。

図９に示されている例示用のインターフェイス９００は、ドケットの処理用のドケット固有の情報を提供する部分を含む。例えば、インターフェイス９００は、ドケットの状態９０２（クリア済み、処理中、署名を待機中、始まった直後、など）、特定の患者用装置及び／又は特定のドケットと関連する送信９０４の数、並びに、ドケットタイムライン９０６、の通知を含んでいてもよく、これらについては、更に詳細に後述する。これに加えて、インターフェイス９００は、送信、ドケット日付９１０、及びドケットの装置からの送信の数のサマリ９１２に応答して、初期インタロゲーション９０８を実施する責任を担っているユーザーの通知を含みうる。又、（患者名又はその他の識別子などの）患者情報９１４及び送信が受け取られた装置の情報９１６も、含まれうる。

ユーザー固有のドケットインターフェイス９００の本体は、ドケットの目的を要約するサマリステートメント９１８（ドケットを通じて処理される送信の数及び／又はドケットが生成された日付を含む）、受け取られた送信に対する応答に関するガイダンスを提供するための１つ又は複数の決定又はインプレッション９２０、並びに、受け取られた患者用装置送信のうちの１つ又は複数ものに応答して患者を治療するための決定看護計画９２２の部分を含みうる。又、受け取られた送信用の看護計画９２２及び／又は決定インプレッション９２０を承認するべく、クリニックスタッフ又はインターフェイス９００のその他のユーザーの署名を収集するために、署名ブロック９３２も含まれうる。

これに加えて、装置情報及び履歴をインターフェイス９００の１つ又は複数の部分を通じて提供することもできる。図示の例においては、装置電源状態インジケータ９２４は、医療装置の電池寿命の百分率、推定される電池の寿命、及び充電時間の通知又は推定を提供することができる。監査証跡９２６の部分は、インターフェイス９００のユーザーによる参照のために保存されたインプレッションの履歴を提供することができる。更には、装置パラメータセクション９２８は、固有の装置情報を提供することができると共に、カウント９３０の部分は、装置の動作におけるイベント又はマイルストーンのカウントを提供することができる。この情報は、いずれも、受け取られた装置送信に応答してドケットを処理する際のユーザーインターフェイス９００のユーザーのコンテキストを提供することができる。

ユーザー固有のドケットインターフェイス９００のいくつかの実装形態においては、ユーザーが、．ｐｄｆフォーマットにおいてドケットを観察する又はその他の方法でこれにアクセスするべく選択することを許容する、ＰＤＦセレクタ９３４を提供することができる。一般に、ユーザー装置１０８内において表示されるドケットは、ハイパーテキストマークアップ言語（ＨＴＭＬ：ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）フォーマットを有する。但し、いくつかのユーザーは、ポータブルドキュメントフォーマット（ＰＤＦ）におけるドケットを観察することを選好しうる。インターフェイス９００のＰＤＦセレクタ９３４の選択を通じて、医療装置マネージャ１０２は、ドケットをユーザーによってアクセス可能なＰＤＦ文書に変換することができる。

医療装置マネージャ１０２は、受け取りから、生成、そして、提出から、承認までの、送信ライフサイクルの全体を通じて、装置送信のハンドリングを提供している。図１０は、患者用医療装置を管理する例示用のワークフロー概要ユーザーインターフェイス１０００を示している。インターフェイス１０００は、送信の処理が発生するのに伴って、レーンからレーンへ、送信検討及び報告を移動させる、処理のレーンを含む。例えば、医療装置マネージャ１０２において受け取られた任意の送信は、ワークフロー概要インターフェイス１０００内において含まれうる。「バックログ」レーン１００２は、受け取られたが処理されてはいない送信のリストを含む。後の時点において送信を処理するべく選択することにより、送信は、フォローアップコンポジション及び完了のための「コンポーズ１００４」処理レーンに移動される。ドケットが送信のために生成された際に、送信のリストは、１つ又は複数の必要とされる署名が、ドケットに適用され、且つ、保存される時点まで、「承認必要」レーン１００６内に移動される。クリア済みであり、且つ、完了した、送信ドケットは、「クリア済み」レーン１００８内において列挙されうる。更には、それぞれのクリア済みのドケットは、「クリア済み」処理レーン１００８からクリア済みのドケットを除去するべく、ドケット１０１２内の選択を通じて閉じることもできる。又、医療装置マネージャ１０２の管理者に基づいて、１つ又は複数の「カスタマイズ済み」処理レーン１０１０を含むことができると共に、カスタマイズすることができる。例えば、そのステージにおけるワークフローを調査するべく、「検討」レーンをレーン１００４及び１００６の間において追加することができる。同様に、レーンを除去することもできる。例えば、ドケットの保存が自動的にこれを承認している場合には、レーン１００６を除去することができる。従って、ワークフロー概要インターフェイス１０００を通じて、ユーザーは、相対的に良好なクリニック管理及びワークフローのために、医療装置マネージャ１０２を通じて１つ又は複数の送信の処理の進捗を追跡することができる。

送信の処理は、図１１において示されているインターフェイス１１００において開始しうる。具体的には、ユーザーは、送信の処理を開始するべく、図１０の特定のワークフローインターフェイス１０００を選択することができる。次いで、医療装置マネージャ１０２は、ユーザーが送信の処理を開始しうるように、ユーザーの演算装置１０８上において送信概要インターフェイス１１００を提供することができる。図示の実装形態においては、送信概要１１００は、（患者の名前及び／又はなんらかの更なる識別子などの）患者の詳細１１０２、患者送信用のドケットを生成するドケットジェネレータ１１０４のセレクタ（図１４との関係において更に詳しく後述する）、ドケットタイムラインバー１１０６、患者の送信の合計数１１０８、及び患者のドケットの処理を追跡する送信バー１１１０（図１３との関係において更に詳しく後述する）、患者の情報を提供する患者パネル（図１２との関係において更に詳しく後述する）、並びに、医療装置の１つ又は複数の製造者から受け取られた情報を提供する送信製造者レポート部分１１１４を含むことができる。又、更に多くの又は少ない数のコンポーネント又は部分を送信概要インターフェイス１１００内において提供することもできる。

特定の送信の処理を開始するべく、ユーザーは、送信バー１１１０から送信を選択することができる。具体的には、且つ、図１３を参照すれば、送信概要インターフェイス１１００は、特定の患者用のすべての又はいくつかの履歴ドケット又はレポートのみならず、そのドケットを構成する送信に対するアクセスをユーザーに提供するドケットタイムラインバー１１０６を含みうる。患者が送信概要インターフェイス１１００の患者詳細１１０２内において識別された際に、その患者の履歴ドケットがインターフェイスを通じてユーザーに提供される。一実装形態においては、ユーザーが、単一のビューにおいて、患者のすべての送信を効率的且つ迅速に管理しうるように、患者のもっとも最近のドケットがライムライン１１０６内において表示されている。ドケットタイムラインバー１１０６は、それぞれがその患者の対応するドケットの日付を有する一連のボックス１３００を含むことができると共に、ペンディング承認、オープン、又は承認済みなどのドケットの状態を通知することができる。ドケットタイムラインバー１１０６からのドケット日付の選択により、インターフェイス１１００の送信バー部分１１１０において、その日付と関連する患者ドケットの更に多くの情報が提供される。

図１３に示されているように、送信バー部分１１１０は、選択された患者について受け取られた１つ又は複数の送信を反映している。図１３に示されているドケットの場合には、１４個の送信が、この患者について含まれている。更には、それぞれの送信は、送信ボックス１３１０内において示されている。それぞれの送信ボックス１３１０は、限定を伴うことなしに、送信数、送信タイプ（恐らくは、特定のアイコンを通じて通知される）、及び受け取られた日付を含む、いくつかのタイプの送信情報を含みうる。又、送信状態（閲覧されていない、閲覧済み、コンポーズ、アーカイブ済み、アクティブである、など）などの、その他のインジケータが送信ボックス１３１０内に存在することもできる。送信ボックス１３１０は、アクティブな送信を表すべく着色された送信ボックスの一例であり、この場合に、ボックス１３０４は、閲覧済みなどの、別の情報を通知するべく着色された状態にある。更には、１つ又は複数の送信ボックス１３０６は、関係する送信が（なんらかの動作が、送信を文書化するべく実行されたことを反映する）コンポーズ状態を有することを通知している、灰色のシェーディング（又はその他のインジケータ）が施されてもよい。又、このようなボックス１３０６は、インプレッションカウンタ１３１２を含むこともできる（図１３には、数値を有する個々の送信ボックスのコーナーにおける円形バブルとして表されている）。インプレッションカウンタ１３１２は、患者ドケットに実施された、且つ、送信バー１１１０内の送信ボックスの特定の送信と関連する、インプレッションの数を通知している。最後に、送信バー１１１０は、臨床医がドケットには関係していないと判断したが、それにも拘らず、十分な送信追跡及び負担報告のためにドケットと共に保持された、送信を反映する、任意の数のアーカイブ済みの送信１３０８を含むこともできる。

又、送信概要インターフェイス１１００内には、患者パネル１１１２も含まれている。図１２は、患者パネルインターフェイス１１１２の一例を示している。上述のインターフェイスの説明と同様に、患者パネルインターフェイス１１１２は、ユーザー演算装置１０８の表示部分上において表示することができる。一般に、患者パネルインターフェイス１１１２は、患者の医療装置からの受け取られた送信に基づいて、患者の定義されたレポート期間にわたって、効果的な且つ迅速な診断、インプレッション、及び計画用の「一覧型」のコアデータポイントのユニバーサルツールを提供している。特定の部分及び情報は、患者パネル１１１２内において含まれているものとして後述されているが、更に多くの又は少ない数の情報部分をインターフェイス内において含むことができる。

インターフェイス１１１２の最上部の近傍には、送信１２００の部分が表示されている。送信部分１２００は、選択された患者及び患者と関連する医療装置からの送信に関する一般的な情報を含む。例えば、送信１２００は、現時点の送信の日付及びタイプ、過去の送信の日付及びタイプ、受け取られた送信に基づいた医療装置の推定された電池寿命、及びこれらに類似したものを含みうる。これに加えて、患者パネルインターフェイス１１１２は、クリニックにおける患者／装置のやり取りにおける以前の主要なイベントの迅速な再キャプチャのために、患者、送信、或いは、任意のその他のカテゴリ、に関係する過去の臨床インプレッションを表示する、過去のインプレッション部分１２０２を含むことができる。患者／送信用の予め承認された又は生成されたドケットを照合するべく、且つ、患者のすべての臨床インプレッション又はなんらかの臨床インプレッションを適用するべく、アルゴリズムを医療装置マネージャ１０２によって実行することができる。又、それぞれの表示された過去のインプレッションと関連する送信に対するリンクを過去のインプレッション部分１２０２内に含むこともできる。いくつかの実装形態においては、それぞれの個々のインプレッションが、過去のインプレッションの発生の日付ごとに配列されたドロップダウンメニューを通じて利用可能な状態において、類似の過去のインプレッションを単一インプレッション内において収集及び表示することができる。

製造者は、データ送信用の履歴構造を提供してはいない。その代わりに、送信は、それぞれの製造者が、過去の送信を異なる方式によって管理している状態において、リストとして提示され、且つ、時間に伴って除去される。医療装置マネージャ１０２は、それぞれの送信に日付を付与し、且つ、これを永久保存し、これにより、看護提供者が、過去の送信１２０２を保存し、且つ、ドケットレポートと相関させることを可能にしている。その後に、ドケットが承認され、過去の送信１２０２をそれぞれの履歴ドケット内において呼び出すことができる。主要イベントは、ユーザーがそのイベントをクリックすることが可能であり、且つ、結論を下し且つ看護プロトコル決定を下した、送信及び関連するドケットの関連する部分に直接進むことができるように、それぞれのドケットから、更に抽出され、且つ、患者パネルインターフェイス１１１２内において表示され、且つ、クリック可能である。

又、患者パネルインターフェイス１１１２内には、装置背景セクション１２０４も含まれている。装置背景セクション１２０４は、患者の医療装置からの受け取られた送信を処理する際にインターフェイス１１１２のユーザーを支援するべく、埋め込みの日付、装置タイプ、患者疾病タイプ、及び任意のその他の装置背景情報を含む、装置のコアデータを表示しうるが、その理由は、これが患者に関係しているからである。

又、（患者パネルインターフェイス１１１２の上部において送信セクション１２００内において通知される送信などの）特定の送信と関連するアラートを提供する、アラートサマリ部分１２０６を患者パネルインターフェイス１１１２内において表示することもできる。又、イベントサマリ部分１２０８は、特定の送信のために提供することもできる。一般に、アラート及びイベントは、重複する項目を除去するべく、且つ、受け取られた送信データを医療装置マネージャ１０２が処理しうるフォーマットにおいて提供するべく、スクラビング及び正規化されている。従って、イベントサマリ１２０８内のイベントは、イベントタイプ、発生の日付及び時刻、並びに、イベントの持続時間を含みうる。イベントサマリ１２０８内のイベントは、インターフェイス１１１２のユーザーによる選択を通じて、ドケットと自動的に関連付けることができる。イベントサマリ部分１２０８を通じてドケットと関連付けられたら、そのイベントを有する送信の．ＰＤＦレポートの関連するセクションが、ユーザーによる検討のための自動化された表示のために、リンクされる。又、．ＰＤＦ文書イベントも、装置マネージャ１０２のドケット内において自動的に含まれうる。イベントが、受け取られ、且つ、イベントサマリ１２０８内においてユーザーによって検討されるのに伴って、イベントは、アーカイブすることができると共に、過去のイベントとしてラベル付与することができる。

患者の医療装置の１つ又は複数のパラメータを装置パラメータセクション１２１０内において表示することができると共に、このようなパラメータのサマリを患者パネルインターフェイス１１１２のパラメータサマリセクション１２１２内において表示することができる。一般に、装置パラメータ１２１０及びパラメータサマリ１２１２は、送信概要インターフェイス１１００内において表示されている患者／送信の特定の医療装置に基づいている。例えば、埋め込まれた心臓装置は、リード検知電圧、リードインピーダンス読取り、及びリード閾値情報を含む、装置パラメータを含みうる。又、電池寿命及び交換までの推定時間を判定及び表示することもできる。パラメータ１２１０及びサマリ１２１２と関連する装置のタイプとは無関係に、データ及び／又はその他の情報を装置から送信することができると共に、医療装置マネージャ１０２において受け取ることができる。多くのケースにおいては、このような情報は、特定のフォーマット（例えば、ＨＬ７）において提供されてもよく、このフォーマットは、次いで、医療装置マネージャ１０２により、可読フォーマットに変換又は正規化される。この結果、様々なタイプのフォーマットにおいて装置の様々なタイプから受け取られたデータは、インターフェイス１１１２のユーザーによる理解の容易性を目的として、正規化することができると共に、装置パラメータ１２１０及びパラメータサマリ１２１２において表示することができる。装置情報と関連付けられているのは、医療装置マネージャ１０２において受け取られた装置イベントの１つ又は複数のカウントを表示する又はその他の方法で通知する、患者パネルインターフェイス１１１２のカウント部分１２１４である。

図１１の送信概要インターフェイス１１００を再度参照すれば、送信製造者レポート１１１４が、インターフェイス内において提供されている。一般に、送信製造者レポート１１１４は、装置の製造者のサーバーから供給される選択された送信ごとに、表示されている。具体的には、医療装置マネージャ１０２は、マネージャに情報又はデータを送信している医療装置の特定の製造者を判定することができる。これに応答して、マネージャ１０２は、装置上において対応する製造者のレポートを取得するべく、装置の製造者と関連する１つ又は複数のサーバーにアクセスすることができる。レポートは、装置の試験結果及び動作パラメータなどの、装置動作詳細を含みうる。レポートは、すべてを１つのインターフェイス１１００内において、装置からの送信を通じて受け取られたデータと共に、．ＰＤＦ文書として表示することができる。

表示されたレポートに加えて、送信製造者レポート１１１４のセクションは、対話型レポートリスト１１１６の部分と、「ドケットへの追加」１１１８セレクタと、を含みうる。レポートリスト１１１６は、ユーザーが、送信と関連するその他の．ＰＤＦレポートにアクセスしうる、メカニズムを提供している。例えば、単一の送信は、いくつかの製造者レポートと関連しうる。レポートのそれぞれは、レポートリスト１１１６を通じてアクセス可能であってよい。一実装形態においては、レポートリスト１１１６は、送信のための、且つ、インターフェイス１１００のユーザーによって選択可能である、利用可能なレポートのドロップダウンメニュー又はその他のリストであってよい。これに加えて、「ドケットへの追加」セレクタ１１１８は、ユーザーが、患者又は送信と関連するドケットを有する表示された．ＰＤＦレポートを含むべく、セレクタをクリックする又はその他の方法で選択することを許容している。

送信概要インターフェイス１１００内のドケットジェネレータ１１０４セレクタは、ユーザーがインターフェイス内において表示されている送信用のドケットを生成することを許容している。図１４は、患者用医療装置を管理するための例示用のドケットジェネレータユーザーインターフェイスを示している。ドケットジェネレータインターフェイス１４００は、送信概要インターフェイス１１００内のドケットジェネレータセレクタ１１０４の選択の際に、ユーザーの演算装置１０８上において表示することができる。上述のその他のインターフェイスと同様に、ドケットジェネレータインターフェイス１４００も、ドケットの送信が関連付けられているコンテキストを提供する送信１４０２インジケータを含みうる。これに加えて、ユーザーは、医療装置からの１つ又は複数の送信と関連するドケットの、インプレッション１４０４、計画１４０６、及び全体検討１４０８を生成するべく、且つ／又は、管理するべく、ドケットジェネレータインターフェイス１４００を利用することもできる。

ドケットジェネレータのインプレッション１４０４セクション内において、インターフェイス１４００のユーザーは、１つ又は複数のインプレッションをドケットと関連する受け取られた送信に追加することができる。一実装形態においては、インプレッション１４０４セクションは、インターフェイス１４００のユーザーによって選択可能である１つ又は複数のインプレッションテンプレート１４１０を含みうる。インプレッションテンプレートは、産業標準用語を反映するべく構築されてもよく、その理由は、これが、送信診断に関係しているからである。インプレッション１４０４ジェネレータの更なる部分は、１つ又は複数の対話型メニューを通じて選択可能であるインプレッションの詳細１４１２と、インプレッションの備考１４１６を含むためのセクションと、を含みうる。インプレッション１４０４インターフェイスを通じた任意の追加されたインプレッションは、保存ボタン１４１８の起動を通じて保存することができる。保存されたインプレッションは、医療装置マネージャ１０２を通じて、関連するインターフェイスに自動的にエクスポートすることができる。更には、情報は、ユーザーによって選択されたインプレッション１４０４に基づいて、ドケット内に自動的にインポートすることもできると共に、このようなインプレッションは、編集可能でありうる。

類似の方式により、計画セクション１４０６をドケットジェネレータインターフェイス１４００内において提供することができる。計画部分は、ユーザーが、計画と関連付けるための医療計画の詳細１４２２及び備考１４２４を含む、受け取られた装置送信に応答して、患者用の臨床コース１４２０を選択することを許容することができる。上述のように、臨床コース１４２０及び／又は計画詳細１４２２は、１つ又は複数のメニューから選択可能であってもよく、或いは、編集可能なテキストを受け付けることもできる。受け取られた送信のドケット内において医療計画を保存するべく、保存ボタン１４２６が計画セクション１４０６内において提供されている。

又、ドケット検討セクション１４０８をインターフェイス１４００内において含むこともできる。ドケット検討セクション１４０８は、特定のドケットの一般的な送信情報１４２８、ドケットの入力されたインプレッション１４３０、入力された医療計画１４３４、及び／又は、製造者レポート（恐らくは、．ＰＤＦフォーマットにおけるもの）がドケット内に含まれるべく選択されうるインタロゲーションレポートセクション１４３２、の概要を含みうる。このセクション１４０８において、ユーザーは、生成されたドケット内に含まれるべき情報を検討することができると共に、ドケットを承認することができる。ドケット検討セクション１４０８内において、或いは、その他の場所（ドケット保存ボタン１４３８）において、ユーザーは、医療装置マネージャ１０２システム内においてドケットを保存するように、選択することができる。いくつかの実装形態においては、ビリング可能な機会ウィンドウ又はこれに類似したものを待機している後から保存されるべきドケット、或いは、クリニックスタッフ承認のために保存されたドケットなどの、保存１４３６又はドケットの保存１４３８を通じて、複数の保存選択肢を提供することができる。これに加えて、インターフェイス１４００は、情報の喪失、予期されていない情報、１つ又は複数のフィールド内の文字限度の超過、並びに、これらに類似したものを含む、任意の理由から、ドケットが保存されえないことを通知する、１つ又は複数のアラート１４４０を含むこともできる。

医療装置マネージャ１０２のいくつかの実装形態においては、システム内の送信又は患者のクリアは、インターフェイスのユーザーからの２回のクリック又は入力に低減されており、これにより、９５％だけ、クリニックの効率を増大させることができる。例えば、且つ、図４を再度参照すれば、ユーザー固有のポータル４００は、患者サマリセクション４０４を含む。このポータルは、通常、ユーザーが医療装置マネージャ１０２にアクセスした際に遭遇することになる第１のインターフェイスである。（図８において更に詳細に示されている）患者ポータル４０４においては、医療装置マネージャ１０２において受け取られる送信を有する患者が表示されており、これには、それぞれの患者／送信用の開始ボタン８２０が含まれている。この開始ボタン８２０を選択することにより（１回のクリック）、インターフェイスは、図１１の送信概要インターフェイス１１００にリンクされる。更には、開始ボタン８２０の選択の際には、受け取られた送信から得られた情報から、既定のドケットを生成することもできる。具体的には、共通的に受け取られた送信のために、既定のインプレッション及び計画を既定のドケット内に自動的に入力することができる。例えば、送信と関連するアラート又はイベントを有していない送信は、患者看護（「ルーチンリモート送信」）及びインプレッション（「装置チェックなし：リモート」）における変化がない場合の既定の計画を受け取ることができる。この情報（インプレッション及び医療計画）は、ドケット内に自動的に入力することができると共に、承認のためにインターフェイス１１００のユーザーに提示することができる。承認された場合に、ユーザーは、送信のためにドケットを保存するべく、且つ、システムによる使用のためにドケットを保存するべく、ドケット保存ボタンを単にクリックすることができる（クリック２）。このようにして、ユーザーからインターフェイス内への２回のクリック又は入力を通じて、既定のドケットを特定の送信のために生成することができると共に承認することができる。イベントを伴うことなしに送信される症状の出現は、自動的に除去されてもよく、且つ、送信は、任意の症状の出現と共に残っている任意の送信が存在しているかどうかを判定するべく、分析される。症状の出現カウントがゼロである場合には、送信は、正常な装置機能（ＮＤＦ：Ｎｏｒｍａｌ Ｄｅｖｉｃｅ Ｆｕｎｃｔｉｏｎ）として取り扱われ、且つ、ドケットは、対応するＮＤＦインプレッション及び計画が自動的に入力され、且つ、緑色に着色される。ドケットは、ビリング可能な機会又はウィンドウを後から待機するべく、保存することができる。更には、複数の送信管理によって可能となるドケット内における包含のために、製造者レポートＰＤＦを選択することもできる。

一実装形態においては、ドケットは、インプレッション９２０が選択されたら、生成されている。インプレッションは、ドケット内の少なくとも１つの送信について選択されている。これは、ＮＤＦ用の自動生成されたインプレッション９２０を含む。イベントが存在している場合には、インプレッションは、その１つ又は複数のイベントに基づいている。これらのイベントは、ＩＤＣＯフォーマット内のＨＬ７を介して到来し、且つ、医療装置マネージャ１０２により、産業標準として正規化される。インプレッション９２０は、ドケット内に含まれているスマートフレーズを入力する。インプレッション９２０が選択されたら、ユーザーは、看護計画９２２を構築することができる。インプレッション９２０は、別個のデータポイントであり、且つ、ユーザーは、適切であると考えられるだけの数を選択することができる。インプレッション９２０を自動入力するべく、医療装置マネージャ１０２は、送信データポイントとアライメントされた可能なインプレッション応答のルックアップ編集可能データライブラリを生成し、且つ、利用している。多くのものが、通常の送信データポイント－インプレッションのペアに基づいた既定のルックアップである。送信が、イベントを有しておらず、且つ、緑色としてフラグ付与されている場合には、医療装置マネージャ１０２は、ＮＤＦインプレッション９２０を生成する。その送信について、インプレッション９２０が自動選択され、且つ、その結果、スマートフレーズが生成される。ＮＤＦは、受け取られた際に送信が現時点のイベントを有していない場合に、識別される。インプレッション９２０は、ドケットに自動的に装着され、これにより、ドケットからインプレッション９２０が除去される。ユーザーは、第２のクリックとしてドケットを生成することが可能であり、その理由は、インプレッション９２０が既に装着されているからである。看護計画９２２は、送信が、イベントを有しておらず、且つ、インプレッション９２０をＮＤＦとして自動生成している際に、ＮＤＦのために自動生成される。イベントが存在している場合には、医療装置マネージャ１０２は、ドロップダウンから、ルックアップテーブルからのフル関連データを反映するインプレッション９２０を生成するように、ユーザーに対して要求する。インプレッション９２０は、ドロップダウンから選択され、且つ、ルックアップテーブルと関連する数値を有する。この値は、データベース内のスマートフレーズインプレッションを表している。ドロップダウンインプレッション選択９２０は、装置タイプ及び／又は送信されたデータフィールドに基づいている。

図１５は、患者用医療装置を管理するための例示用のアクショントラッカユーザーインターフェイス１５００を示している。本明細書において記述されているその他のインターフェイスと同様に、アクショントラッカ１５００も、医療装置マネージャ１０２により、管理及び提供することができると共に、マネージャへのログインの際にユーザー演算装置１０８上において表示することができる。一般に、アクショントラッカ１５００は、送信、患者情報、及びドケットを含む、ＣＩＥＤとの関係において実行されるすべての動作の詳細な履歴ビューについての監査追跡特徴をユーザーに対して提供している。インターフェイス１５００の各部分については、後述するが、更に多くの又は少ない数の部分がインターフェイス内に含まれうることを理解されたい。

いくつかの実装形態においては、アクショントラッカインターフェイス１５００は、ナビゲーション部分１５０２を含む。ナビゲーション部分１５０２は、ユーザーが、本明細書において記述されているインターフェイスなどの、医療装置マネージャ１０２のその他のインターフェイスにアクセスすることを許容するリンク又はその他の選択可能な部分を含む。アクショントラッカ１５００用の患者情報１５０４は、インターフェイスの別の部分内において入力及び表示することができる。ユーザーは、患者情報部分１５０４内において識別される患者の動作追跡を要求及び閲覧するべく、アクション履歴セレクタ１５０６を利用することができる。選択されたら、医療装置マネージャ１０２によって実行及び追跡される動作１５１２のタイムラインが、インターフェイス１５００内において表示される。一般に、動作のタイムライン１５１２は、識別された装置又は患者のためにシステムによって実行されるすべての動作のサマリである。例えば、タイムライン１５１２は、ドケット生成、医療計画生成、受け取られた送信、承認されたドケットなど用のエントリを含みうる。タイムライン１５１２内のすべてのエントリは、ユーザーによる容易な理解のために、それぞれのエントリと関連する日付を含んでいてもよく、或いは、そうでなくてもよい。

更には、動作のタイムライン１５１２は、インターフェイス１５００のユーザーにより、編集可能又は構成可能であってよい。例えば、タイムライン１５１２内に含まれる動作のタイプ及び数を構成するべく、アクションフィルタ１５０８を選択するための１つ又は複数のドロップダウンメニューを提供することができる。それぞれ、タイムライン１５１２内に含まれるべく、或いは、これから除去されるべく、特定の動作１５１０を選択又は非選択することができる。アクションフィルタ１５０８及び／又は特定の動作１５１０の選択を通じて、ユーザーは、最も効率的であると共にユーザーにとって有用である方式により、タイムライン１５１２を構成することができる。

図１６は、患者用医療装置を管理するための例示用のリコール管理ユーザーインターフェイス１６００を示している。リコール管理インターフェイス１６００は、リコールされた／勧告を受けた装置及びその装置と関連する患者を自動的に識別している。例えば、リコールデータは、様々なパブルック及びプライベートな供給源から収集することができると共に、医療装置マネージャ１０２内にインポートすることができる。リコール又は勧告通知が製造者によって検証されたら、医療装置マネージャ１０２は、装置と関連するデータベース内の患者を判定することができると共に、リコール管理インターフェイス１６００内においてこのような患者の通知を提供することができる。患者がリコール管理インターフェイス１６００を通じて識別されたら、装置のリコール／勧告について患者及び／又はクリニックスタッフに通知するべく、通知又はその他のタイプのアラートを生成することができると共に、相応して医療計画を患者のために制定することができる。

一実装形態においては、リコール管理インターフェイス１６００は、リコールされた／勧告された医療装置を有するものとして識別された患者のリスト１６０２を含む。患者リスト１６０２内のそれぞれの患者エントリは、患者名１６１０、医療装置のタイプ１６１２、装置の製造者１６１４、装置のモデルタイプ１６１６、及びモデル番号１６１８を含みうる。この情報は、患者が、リコールされた装置と関連していることを検証するべく、ユーザーによって利用することができる。更には、患者リスト１６０２内のそれぞれのエントリは、識別された患者についてリコールに関する動作が実行されたら、ユーザーが選択しうる、「満足」ボタン１６２０を含むこともできる。換言すれば、通知、アラート、又は医療計画が、実装され、且つ、完了したら、インターフェイス１６００のユーザーは、患者用の「満足」ボタン１６２０を選択することができる。一実装形態においては、「満足」ボタン１６２０の選択により、患者リストから、対応する患者を除去することができる。

又、識別されたリコール／勧告に関する統計及び情報を提供する、リコールウィジェット１６０８を含むこともできる。リコールウィジェット１６０８は、クリニックのために、それぞれの受け取られたリコール／勧告の数及び／又はグラフと、満足した且つ満足していない患者の数と、を含みうる。これに加えて、患者リスト１６０２から選択された際に患者情報が入力される患者ポータルセクション１６０４を含むことができると共に、選択された患者用の対応するドケット１６０６を提示することもできる。従って、クリニックの患者のために、リコール管理インターフェイス１６００を通じて、１つ又は複数の装置リコール及び／又は勧告を処理することができる。又、限定を伴うことなしに、上述のユーザー固有のドケットインターフェイス９００を含む、その他のインターフェイス内に、リコール及びリコールの個々のプロセスの状態を含むこともできる。

又、医療装置マネージャ１０２は、ユーザーがその他のエンティティとの間において文書を共有することを許容することもできる。具体的には、このような第三者エンティティは、医師、心臓内科医、看護師、かかりつけ医などのような、患者情報を受け取る資格を有するＨＩＰＡＡであってもよい）。図１７に示されている共有インターフェイス１７００を通じて、医療装置マネージャ１０２のユーザーは、患者ワークフロー又はドケットなどの患者に関係する文書を共有／受領することができる。情報又は文書を共有するには、インターフェイス１７００のユーザーが、共有するための選択肢を選択するが、この結果、共有された文書を含む安全な電子メールが生成される。電子メールは、削除１７０６、返信１７０８、全員に返信１７１０、転送１７１２、及び印刷１７１４を含む、安全な電子メールを管理するための様々な選択肢を含んでいてもよく、これらのすべては、ユーザーによって選択されうる。又、受信者電子メールアドレス、送信者アドレス、主題ラインなどのような、通信詳細１７０４を含むこともできる。

安全な電子メールと、更に詳しくは、医療装置マネージャ１０２と、は、受信者が資格を有するＨＩＰＡＡであることを検証するべく、文書の意図された受取人と通信することができる。検証されたら、ユーザーは、共有されている特定の患者情報に対するアクセスを有することになる。従って、安全な電子メールは、共有された情報にアクセスするためのリンク１７１６と、受信者が意図された受信者であることを検証するべく、受信者が入力するためのＰＩＮ１７１８と、を含みうる。ＰＩＮの入力及びリンクの選択の際に、第三者エンティティは、共有されている文書に対するアクセスを有することができると共に、共有を確認する通知を送信することができる。

図１８を参照し、本明細書において記述されている様々なシステム及び方法を実装しうる１つ又は複数の演算ユニットを有する例示用の演算システム１８００の詳細な説明を提供する。演算システム１８００は、医療装置マネージャ１０２及び／又はユーザー演算装置１０８及びその他の演算及びネットワーク装置に適用可能でありうる。これらの装置の特定の実装形態は、そのすべてが本明細書において具体的に記述されているわけではないが当業者によって理解されることになる異なる可能な特定の演算アーキテクチャを有しうることを理解されたい。

コンピュータシステム１８００は、コンピュータプロセスを実行するべく、コンピュータプログラムプロダクトを実行する能力を有する演算システムであってよい。データ及びプログラムファイルが、コンピュータシステム１８００に入力されてもよく、コンピュータシステム１８００は、ファイルを読み取り、且つ、その内部のプログラムを実行する。図１８には、１つ又は複数のハードウェアプロセッサ１８０２、１つ又は複数のデータストレージ装置１８０４、１つ又は複数のメモリ装置１８０６、及び／又は１つ又は複数のポート１８０８～１８１０を含む、コンピュータシステム１８００の要素のいくつかが示されている。これに加えて、当業者によって認識されることになるその他の要素が、演算システム１８００内において含まれうるが、図１８には、明示的に描かれておらず、且つ、本明細書における更なる説明を省略する。コンピュータシステム１８００の様々な要素は、１つ又は複数の通信バス、ポイントツーポイント通信経路、又は図１８には明示的に描かれていないその他の通信手段を介して、互いに通信することができる。

プロセッサ１８０２は、例えば、中央処理ユニット（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ：Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、及び／又は１つ又は複数の内部キャッシュのレベルを含みうる。プロセッサ１８０２が、単一中央処理ユニット、或いは、命令を実行すると共に並行処理環境と一般に呼称される互いに並行して動作を実行する能力を有する複数の処理ユニット、を有するように、１つ又は複数のプロセッサ１８０２が存在しうる。

コンピュータシステム１８００は、従来のコンピュータ、分散型のコンピュータ、又は、クライド演算アーキテクチャを介して提供される１つ又は複数の外部コンピュータなどの、任意のその他のタイプのコンピュータであってもよい。本明細書において記述されている技術は、任意選択により、１つ又は複数のデータが保存される装置１８０４上において保存される、１つ又は複数のメモリ装置１８０６上において保存される、且つ／又は、ポート１８０８～１８１０の１つ又は複数を介して通信される、ソフトウェアにおいて実装され、これにより、図１８のコンピュータシステム１８００が、本明細書において記述されている動作を実装するための特殊目的機械に変換される。コンピュータシステム１８００の例は、パーソナルコンピュータ、端末、ワークステーション、携帯電話機、タブレット、ラップトップ、パーソナルコンピュータ、マルチメディアコンソール、ゲーミングコンソール、セットトップボックス、及びこれらに類似したものを含む。

１つ又は複数のデータストレージ装置１８０４は、演算システム１８００の様々なコンポーネントを管理するアプリケーションプログラム及びオペレーティングシステム（ＯＳ：Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の両方のものの命令を含みうる、コンピュータプロセスを実行するためのコンピュータ実行可能命令などの、演算システム１８００内において生成又は利用されるデータを保存する能力を有する、任意の不揮発性データストレージ装置を含むことができる。データストレージ装置１８０４は、限定を伴うことなしに、磁気ディスクドライブ、光ディスクドライブ、半導体ドライブ（ＳＳＤ：Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュドライブ、及びこれらに類似したものを含みうる。データストレージ装置１８０４は、着脱自在のデータストレージ媒体、非着脱自在のデータストレージ媒体、並びに／或いは、１つ又は複数のデータベース管理プロダクト、ウェブサーバープロダクト、アプリケーションサーバープロダクト、及び／又は、その他の更なるソフトウェアコンポーネントを含む、このようなコンピュータプログラムプロダクトと共に有線又は無線ネットワークアーキテクチャを介して提供される外部ストレージ装置を含むことができる。着脱自在のデータストレージ媒体の例は、コンパクトディスク読み出し専用メモリ（ＣＤ－ＲＯＭ：Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、デジタルバーサタイルディスク読み出し専用メモリ（ＤＶＤ－ＲＯＭ：Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁気－光ディスク、フラッシュドライブ、及びこれらに類似したものを含む。非着脱自在のストレージ媒体の例は、内部磁気ハードディスク、ＳＳＤ、及びこれらに類似したものを含む。１つ又は複数のメモリ装置１８０６は、揮発性メモリ（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ：Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、スタティックランダムアクセスメモリ（ＳＲＡＭ：Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）など）、並び／或いは、不揮発性メモリ（例えば、読み出し専用メモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリなど）を含みうる。

本明細書において記述されている技術に従ってシステム及び方法を実現するためのメカニズムを含むコンピュータプログラムプロダクトは、機械可読媒体と呼称されうるデータストレージ装置１８０４及び／又はメモリ装置１８０６内において存在することができる。機械可読媒体は、機械による実行のために本開示の動作のうちの任意の１つ又は複数を実行するべく命令を保存又はエンコーディングする能力を有する、或いは、このような命令によって利用される又はこれらと関連するデータ構造及び／又はモジュールを保存又はデンコーディングする能力を有する、任意の有体の一時的ではない媒体を含みうることを理解されたい。機械可読媒体は、１つ又は複数の実行可能命令又はデータ構造を保存する単一媒体又は複数媒体（例えば、中央集中化された又は分散化されたデータベース及び／又は関連するキャッシュ及びサーバー）を含みうる。

いくつかの実装形態においては、コンピュータシステム１８００は、入出力（Ｉ／Ｏ）ポート１８０８などの１つ又は複数のポートと、その他の演算、ネットワーク、又は車両装置と通信するための通信ポート１８１０と、を含む。ポート１８０８～１８１０は、組み合わせられてもよく、或いは、別個であってもよく、且つ、更に多くの又は少ない数のポートが、コンピュータシステム１８００内において含まれうることを理解されたい。

Ｉ／Ｏポート１８０８は、Ｉ／Ｏ装置又はその他の装置に接続されてもよく、これにより、情報が、演算システム１８００に入力され、且つ、これから出力される。このようなＩ／Ｏ装置は、限定を伴うことなしに、１つ又は複数の入力装置、出力装置、及び／又は環境トランスデューサ装置を含みうる。

一実装形態においては、入力装置は、人間の音声、物理的な運動、物理的な接触又は圧力、並びに／或いは、これらに類似したものなどの、人間によって生成された信号をＩ／Ｏポート１８０８を介して演算システム１８００への入力としての電気信号に変換している。同様に、出力装置は、Ｉ／Ｏポート１８０８を介して、演算システム１８００から受け取られた電気信号を音響、光、及び／又は接触などの人間によって出力として検知されうる信号に変換することができる。入力装置は、Ｉ／Ｏポート１８０８を介してプロセッサ１８０２に情報及び／又はコマンド選択を伝達するための英数の及びその他のキーを含む英数入力装置であってよい。入力装置は、限定を伴うことなしに、マウス、トラックボール、カーソル方向キー、ジョイスティック、及びホイールなどの、方向及び選択制御装置、カメラ、マイクロフォン、位置センサ、向きセンサ、重力センサ、慣性センサ、及び／又は加速度計などの、１つ又は複数のセンサ及び／又は接触感知表示画面（「タッチスクリーン」）を含む別のタイプのユーザー入力装置であってよい。出力装置は、限定を伴うことなしに、ディスプレイ、タッチスクリーン、スピーカ、触覚及び／又は皮膚感覚出力装置、並び／或いは、これらに類似したものを含みうる。いくつかの実装形態においては、入力装置及び出力装置は、例えば、タッチスクリーンのケースにおいては、同一の装置であってよい。

環境トランスデューサ装置は、Ｉ／Ｏポート１８０８を介した演算システム１８００への入力及び／又はこれからの出力のために、エネルギー又は信号の１つの形態を別のものに変換している。例えば、演算システム１８００内において生成された電気信号は、別のタイプの信号に変換されてもよく、且つ／又は、逆も又真である。一実装形態においては、環境トランスデューサ装置は、光、音響、温度、圧力、磁界、電界、化学プロパティ、物理運動、向き、加速度、重力、及び／又はこれらに類似したものなどの、演算装置１８００の近くの又はこれから離れた環境の特性又は側面を検知している。更には、環境トランスデューサ装置は、なんらかの物体の物理的運動（例えば、機械的なアクチュエータ）、物質の加熱又は冷却、化学物質の追加、及び／又はこれらに類似したものなどの、例示用の演算装置１８００の近くの又はこれから離れた環境に対してなんらかの効果を付与するべく、信号を生成することができる。

一実装形態においては、通信ポート１８１０は、コンピュータシステム１８００が、本明細書において記述されている方法及びシステムを実行する、のみならず、情報及びこれによって判定されたネットワーク構成の変化を送信する、際に有用であるネットワークデータを受け取りうる、ネットワークに接続されている。換言すれば、通信ポート１８１０は、１つ又は複数の有線又は無線通信ネットワーク又は接続を介して演算システム１８００とその他の装置の間において情報を送信及び／又は受信するように構成された１つ又は複数の通信インターフェイス装置にコンピュータシステム１８００を接続している。このようなネットワーク又は接続の例は、限定を伴うことなしに、ユニバーサルシリアルバス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離通信（ＮＦＣ：Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）などを含む。１つ又は複数のこのような通信インターフェイス装置は、ポイントツーポイント通信経路上において直接的に、ワイドエリアネットワーク（ＷＡＮ：Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）（例えば、インターネット）上において、ローカルエリアネットワーク（ＬＡＮ：Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）上において、セルラー（例えば、第３世代（３Ｇ）又は第４世代（４Ｇ））ネットワーク上において、或いは、別の通信手段上において、１つ又は複数のその他の機械と通信するように、通信ポート１８１０を介して利用することできる。更には、通信ポート１８１０は、電磁信号の送信及び／又は受信のためのアンテナ又はその他のリンクと通信することもできる。

但し、図１８において記述されているシステムは、本開示の態様を利用しうる又はこれらに従って構成されうるコンピュータシステムの１つの可能な例である。本明細書において開示されている技術を演算システム上において実装するためのコンピュータ実行可能命令を保存するその他の一時的ではない有体のコンピュータ可読ストレージ媒体が利用されうることを理解されたい。

本開示においては、開示されている方法は、装置によって判読可能な命令又はソフトウェアの組として実装することができる。更には、開示されている方法におけるステップの特定の順序又は階層は、例示用の方式の例であることを理解されたい。設計の好みに基づいて、方法におけるステップの特定の順序及び階層は、開示されている主題内に留まりつつ、再構成することができることを理解されたい。添付の方法の請求項は、例示用の順序において様々なステップの要素を提示しており、且つ、必ずしも、提示された特定の順序又は階層に限定されることを意味するものではない。

記述されている開示は、本開示によるプロセスを実行するべくコンピュータシステム（又は、その他の電子装置）をプログラミングするように使用されうる命令をその上部において保存された状態において有する一時的ではない機械可読媒体を含みうるコンピュータプログラムプロダクト又はソフトウェアとして提供することができる。機械可読媒体は、機械（例えば、コンピュータ）によって判読可能である形態（例えば、ソフトウェア、処理アプリケーション）において情報を保存する任意のメカニズムを含む。機械可読媒体は、限定を伴うことなしに、磁気ストレージ媒体、光ストレージ媒体、磁気－光ストレージ媒体、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、消去可能プログラム可能メモリ（例えば、ＥＰＲＯＭ及びＥＥＰＲＯＭ）、フラッシュメモリ、又は電子命令を保存するのに適したその他のタイプの媒体を含みうる。

以上、様々な実装形態を参照し、本開示について説明したが、これらの実装形態は、例示を目的としたものであり、且つ、本開示の範囲は、これらに限定されるものではないことを理解されたい。多くの変形、変更、追加、及び改善が可能である。更に一般的には、本開示による実装形態は、特定の実装形態の文脈において記述されている。機能は、本開示の様々な実装形態において、異なる方式により、複数のブロックとして分離されてもよく、或いは、組み合わせられてもよく、或いは、異なる用語によって記述されている場合もある。これらの及びその他の変形、変更、追加、及び改善は、添付の請求項において定義されている本開示の範囲に含まれうる。

Claims (20)

1. ネットワークを介して心臓埋め込み型電子装置と通信する少なくとも一つのプロセッサより実行される患者用装置の管理用の方法であって、前記方法は、
   患者のインタロゲーションに対応する、前記心臓埋め込み型電子装置からのインタロゲーションデータを受け取るステップであって、前記インタロゲーションデータは、前記心臓埋め込み型電子装置の装置データと、前記患者の患者固有のデータと、を含む、ステップと、
   前記インタロゲーションデータを、製造者とは独立したインタロゲーションデータに正規化するステップと、
   前記製造者とは独立したインタロゲーションデータを、許容されたユーザーと関連付けるステップと、
   前記製造者とは独立したインタロゲーションデータを使用することにより、前記インタロゲーションに対して処理状態を割り当てるステップと、
   前記処理状態に基づいて、前記インタロゲーションを所定のカテゴリに集計するステップであって、前記カテゴリは、前記許容されたユーザーによる動作と関連付けられている、ステップと、
   を有する方法。
2. 前記処理状態は、パッシブ、保存済み、アーカイブ済み、又はドケッティング済みである、請求項１に記載の方法。
3. 前記処理状態がパッシブである場合、前記カテゴリはバックログであり、前記処理状態が保存済みである場合、前記カテゴリはコンポーズであり、前記処理状態がアーカイブ済みである場合、前記カテゴリは隠蔽であり、前記処理状態がドケッティング済みである場合、前記カテゴリは承認要である、請求項２に記載の方法。
4. 前記許容されたユーザーは、クリニックと関連する専門家、又はアクセス権限が委譲された第三者のうちの少なくとも１つである、請求項１に記載の方法。
5. 前記インタロゲーションデータは、メモリから受け取られ、且つ、事務所内訪問の際に、製造者に固有のプログラマを使用することにより、前記心臓埋め込み型電子装置から受け取られる、請求項１に記載の方法。
6. 前記インタロゲーションのデータファイルが、製造者に固有のプログラマによって生成され、且つ、前記インタロゲーションデータを正規化するステップは、複数の解析ステージを使用することにより、前記データファイルを解析済みのデータファイルに解析するステップを含む、請求項５に記載の方法。
7. 前記インタロゲーションは、リモートインタロゲーションであり、且つ、前記インタロゲーションデータは、ＨＬ７（Ｈｅａｌｔｈ Ｌｅｖｅｌ ７）通信プロトコル及びＩＤＣＯ（Ｉｍｐｌａｎｔａｂｌｅ Ｄｅｖｉｃｅ Ｃａｒｄｉａｃ Ｏｂｓｅｒｖａｔｉｏｎ）データ規格を使用することにより、製造者システムからネットワーク上において受け取られている、請求項１に記載の方法。
8. 前記インタロゲーションデータを正規化するステップは、識別されていないＨＬ７データを１つ又は複数のインタロゲーションフィールドにマッピングし、且つ、ＩＤＣＯデータを正規化することによる、ＨＬ７データの抽出を含む、請求項７に記載の方法。
9. 前記インタロゲーションデータを正規化するステップは、装置設定の計算及び正規化を含む、請求項８に記載の方法。
10. 前記インタロゲーションには、イベントタイプとの間における前記インタロゲーションの関連付けに基づいて、重大性が割り当てられている、請求項１に記載の方法。
11. 前記重大性は、前記イベントタイプが非イベントである場合には、正常装置機能である、請求項１０に記載の方法。
12. 前記カテゴリは、前記許容されたユーザーによる２クリック承認に後続してクリアされ、前記重大性に応答して生成される前記２クリック承認用のプロンプトには、正常装置機能が割り当てられている、請求項１１に記載の方法。
13. 前記プロンプトは、正常装置機能に対応する、自動的に生成されたインプレッション及び自動的に生成された看護計画を含む、請求項１２に記載の方法。
14. 前記カテゴリに基づいて、クリニック用の１つ又は複数のビリング機会を生成するステップを更に有する、請求項１に記載の方法。
15. 前記１つ又は複数のビリング機会は、償還レート、利用可能な償還の頻度、及び患者の数に基づいて判定される、請求項１４に記載の方法。
16. 前記１つ又は複数のビリング機会は、前記インタロゲーション以降の日の数及びビリング可能イベントの間の日の最小及び最大数に基づいて、前記インタロゲーションに対応するビリングウィンドウを判定するステップを含む、請求項１４に記載の方法。
17. 前記心臓埋め込み型電子装置の監査証跡を生成するステップを更に有し、前記監査証跡は、過去のインタロゲーション、前記インタロゲーション、又は前記心臓埋め込み型電子装置との関係において実行された動作のうちの少なくとも１つを含む、請求項１に記載の方法。
18. 前記カテゴリに基づいてクリニックのコミュニティ分析を生成するステップを更に有し、前記コミュニティ分析は、第２のクリニック又は複数のクリニックのベンチマークのうちの少なくとも１つに対する前記クリニックの比較を含む、請求項１に記載の方法。
19. 前記製造者とは独立したインタロゲーションデータからインタロゲーションレポートを生成するステップを更に有し、前記インタロゲーションレポートは、要約された解釈、看護計画、及び前記インタロゲーションのレコードを含む、請求項１に記載の方法。
20. 前記インタロゲーションレポートは、前記心臓埋め込み型電子装置のインタロゲーションレポートのスタック内に含まれており、前記インタロゲーションレポートのスタック内のそれぞれは、別個のインタロゲーションに対応している、請求項１９に記載の方法。

Images