JP2024525495A - 監視間隔トラッカを備えた心臓監視装置を管理するためのシステム及び方法 - Google Patents

Abstract

システム及び方法には、心臓監視装置から発信される送信データを管理するための監視間隔トラッカが含まれる。監視間隔トラッカは、複数の異なる患者ケア様式（例えば、院内ケア様式、遠隔監視ケア様式及び／又は心不全ケア様式）に対応する監視間隔を生成する。送信データ、送信データに対応する診療記録レポート及び／又は診療記録レポートの承認を受信すると、監視間隔トラッカは、監視間隔を延長するか、業務の日付を生成するか及び／又は新たな監視間隔を作成するかを判定する。複数の異なる患者ケア様式に対する送信データ、診療記録レポート及び承認タイムスタンプを追跡するために、複数の監視間隔を同時に有効にしてもよい。監視間隔トラッカの結果を、対話型監視間隔ビジュアライザ及び／又は送信ダッシュボードとして出力して、患者への追跡管理の失敗を防止し、課金の精度と効率を向上させることで患者ケアを向上させてもよい。【選択図】図１

Description

関連出願の相互参照
本出願は、「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｍａｎａｇｉｎｇ ａ Ｃａｒｄｉａｃ Ｍｏｎｉｔｏｒｉｎｇ Ｄｅｖｉｃｅ ｗｉｔｈ ａ Ｍｏｎｉｔｏｒｉｎｇ Ｉｎｔｅｒｖａｌ Ｔｒａｃｋｅｒ（監視間隔トラッカを備えた心臓監視装置を管理するためのシステム及び方法）」と題し、２０２１年６月２８日に出願された米国仮特許出願第６３／２１５，６４７号の３５ Ｕ．Ｓ．Ｃ． §１１９（ｅ）に基づく優先権を主張し、その利益を主張する。この米国仮特許出願は、その全体が参照により本明細書に組み込まれる。
本開示の態様は、１人又は複数の患者のための患者医療装置の管理に関し、さらに具体的には、心臓監視装置を管理するためのシステム及び方法に関する。

埋め込み型医療装置を、さまざまな身体疾患の治療及び／又は監視に定期的に使用している。例えば、心臓埋め込み型電子装置（ＣＩＥＤ）などの心臓監視装置である。
ＣＩＥＤには、低エネルギー電気パルスを使用して心拍数の低下を防ぐペースメーカ（ＰＭ）と、異常な心臓不整脈を検出し、突然の心停止を防ぐために救命用の衝撃を与えるために使用される埋め込み型除細動器（ＩＣＤ）と、心臓データを継続的に監視し、臨床医の処方及び患者の裁量に従ってデータを診療所に送信する埋め込み型ループレコーダ（ＩＬＲ）及び埋め込み型心臓モニタ（ＩＣＭ）、などが挙げられるが、ここに挙げたものに限定されない。そのようなＣＩＥＤは、分析、プログラミングなどのために体外の装置の動作に関する情報を保存し、定期的に送信する場合がある。さらに具体的には、ＣＩＥＤは、医療提供者による院内監視又は遠隔監視のための情報を保存し、送信する。

しかし、医療提供者は、多くの場合、さまざまな種類の装置及びさまざまな種類の患者ケアを必要とする多数の患者を管理する責任を負っている。各種の装置では、心臓監視情報を診療所に報告する送信頻度が異なる場合がある。一部の装置では、他の装置よりも一貫して心臓監視情報を送信する場合がある。さらに、患者ケアの種類ごとに、患者の監視に関する固有の要件がある場合がある。例えば、ある種の患者ケア（例えば、遠隔監視）では、心臓監視装置からの四半期ごとの送信が必要な場合があり、他の種類の患者ケア（例えば、院内監視）では、年に一度の通院が必要な場合がある。さらに、あらゆる送信には、送信に対して業務の日付を設定する前に、対応する診療記録レポートと診療記録レポートの承認が必要になる場合がある。単一の心臓監視装置を複数の種類の患者ケア（例えば、遠隔監視及び心不全監視）に使用する場合、心臓監視装置の送信管理の複雑さはさらに複雑なものになる。そのため、あらゆる心臓監視装置のあらゆる送信を追跡し、送信に関する診療記録レポートを作成し、診療記録レポートを承認し、患者ケアを低下させることなくタイムリーに送信に対して業務の日付を設定することは、このような業務を提供する診療所にとって大きな負担となる。

とりわけ、このような観察を念頭に置いて、本開示のさまざまな態様を考案し、開発した。

本明細書に記載し、特許請求する実装例では、患者装置の管理のためのシステム及び方法を提供することによって、前述の問題に対処する。

典型的には、専門家による心臓監視を患者の生涯にわたって実施している。そのような監視は、償還及びケアのガイドラインの対象となる。心臓ケアは、患者ケアの種類によって異なることがある。例えば、心臓ケアには、ペースメーカー（ＰＭ）又は埋め込み型除細動器（ＩＣＤ）を装着している患者に対して年４回の遠隔データチェック（「遠隔監視患者ケア」）、ＰＭ又はＩＣＤ装着患者に対して少なくとも年に１回の院内チェック（「院内患者ケア」）及び埋め込み型心臓モニタ（ＩＣＭ）又は埋め込み型ループレコーダ（ＩＬＲ）装着患者に対する年間１１回の遠隔データチェック（「心不全患者ケア」）が含まれる。米国の健康保険は、このようなガイドラインに概ね準拠している。しかし、健康保険の払い戻しはあるが、多くの場合、装置の送信の取得、審査及び文書化にかかる人件費は網羅していない。新たなＩＬＲ及びＩＣＭの急速な導入とデータ量の増大により、このようなガイドラインの推定送信負荷では、今後５年間にわたる心臓監視送信が８億回を超えることがあり得る。このようなガイドラインを遵守することで、患者の転帰が改善され、医療システムのコストが削減され、ＰＭ装着患者の死亡率が２．５倍近く減少し、ＩＣＤ装着患者の入院が６５%以上減少する。しかし、このようなガイドラインに伴う負担のため、このようなガイドラインに従って監視されている患者は３０%未満であると推定されている。

一実装例では、心臓監視装置を管理するための医療装置管理プラットフォームには、送信データをもう１つの監視間隔に関連付けることによって心臓監視装置からの送信データを追跡する監視間隔トラッカが含まれる場合がある。１つ又は複数の監視間隔は、心不全患者ケア、院外患者ケア及び／又は院内患者ケアなどの１つ又は複数の患者ケア様式に対応する場合がある。監視間隔トラッカは、必要に応じて監視間隔の延長を計算し、患者ケア様式及び監視間隔延長に従って送信データと、送信データに対する診療記録レポートと、診療記録レポートの承認と、を分類して、業務の日付ＤＯＳ計算の精度を向上させながら、送信に対する適切な追跡管理の注意を喚起することができない状態を最小限に抑える。

このほか、他の実装例を本明細書で説明し、引用する。さらに、複数の実装例を開示するが、ここで開示する技術のさらに他の実装例が、ここで開示する技術の例示的な実装例を示し、記載する以下の詳細な説明から当業者には明らかになるであろう。以下の記載からわかるように、ここで開示する技術は、ここで開示する技術の精神及び範囲から逸脱することなく、さまざまな態様にて修正が可能である。このため、図面及び詳細な説明は、本質的に例示的なものと考えられるべきものであり、限定するものではない。

図１は、１つ又は複数の心臓埋め込み型電子装置を管理するために、ネットワークに結合されたサーバ又は他の計算装置上で動作する医療装置マネージャを含むネットワーク環境のブロック図例を示す。

図２は、例示的な医療装置データプラットフォームを含む医療装置データ通信システムのブロック図を示す。

図３は、例示的な医療装置データプラットフォームのブロック図を示す。

図４は、１つ又は複数のデータベース及び医療提供者ポータルと相互作用する例示的な監視間隔トラッカのブロック図を示す。

図５は、患者装着式医療装置を管理するために監視間隔トラッカによって実施される例示的な動作のタイムライン図を示す。

図６は、患者の医療装置を管理するために監視間隔トラッカによって実施される例示的な動作のタイムライン図を示す。

図７は、患者の医療装置を管理するために監視間隔トラッカによって実施される例示的な動作のタイムライン図を示す。

図８は、患者の医療装置を管理するために監視間隔トラッカによって実施される例示的な動作のタイムライン図を示す。

図９は、患者の医療装置を管理するために監視間隔トラッカによって実施される例示的な動作のタイムライン図を示す。

図１０は、患者の医療装置を管理するために監視間隔トラッカによって実施される例示的な動作のタイムライン図を示す。

図１１は、患者の医療装置を管理するために監視間隔トラッカによって実施される例示的な動作のタイムライン図を示す。

図１２は、患者の医療装置を管理するために監視間隔トラッカによって実施される例示的な動作のフローチャートを示す。

図１３は、患者の医療装置を管理するための例示的な監視トラッカ可視化装置ユーザインターフェースを示す。

図１４は、患者の医療装置を管理するための例示的な監視トラッカ可視化装置ユーザインターフェースを示す。

図１５は、患者の医療装置を管理するための例示的な監視トラッカ可視化装置ユーザインターフェースを示す。

図１６は、患者の医療装置を管理するための例示的な監視間隔設定ユーザインターフェースを示す。

図１７は、患者の医療装置を管理するための例示的な送信ダッシュボードユーザインターフェースを示す。

図１８は、患者の医療装置を管理するための例示的な送信ダッシュボードユーザインターフェースを示す。

図１９は、患者の医療装置を管理するための例示的な課金レポートダッシュボードユーザインターフェースを示す。

図２０は、本明細書で考察するさまざまなシステム及び方法を実装し得る例示的な計算システムを示す。

本開示の態様には、１つ又は複数の埋め込み型又は着用型の電子装置を管理するための医療装置管理プラットフォームのためのシステム、方法、コンピュータプログラム製品などが含まれる。電子装置は、１つ又は複数の心臓監視装置（例えば、心臓埋め込み型電子装置（ＣＩＥＤ））などの医療装置を含んでもよい。医療装置管理プラットフォームは、一般に、ＣＩＥＤなどの１つ又は複数の患者の医療装置から操作上の送信を受信して、そのような患者のケアを管理する監視間隔トラッカを含む場合があり、医療提供者が患者のケア戦略を評価し、文書化し、報告し、生成することができるように、そのような装置からのデータ、レポート及び情報の受信を含む場合がある。そのような操作の送信は、対応する装置、装置プログラミングマシン、患者又は製造業者からの報告又は装置から送信を受信する第三者組織からの報告を含む、多くの情報源を介して、監視間隔トラッカにて、送信データとして受信されてもよい。送信データを受信すると、監視間隔トラッカは、送信データを対応する監視間隔に関連付けて、タイムリーな診療記録レポート、診療記録レポートの承認及びＤＯＳを確実に受信できるようにすることができる。

例えば、監視間隔トラッカは、登録手順の一部として送信データを受信する前か、送信データの受信に応答して、心臓監視装置に関連する監視間隔を生成してもよい。監視間隔は、特定の種類の患者ケア（例えば、遠隔監視ケア、院内ケア及び／又は心不全ケア）に対応し、規則データベースからアクセスされる患者ケア様式規則に基づく時間の長さを有してもよい。送信データには、診療所が送信データを受信した日付及び／又は時刻（即ち、「受信日」）を示すタイムスタンプを付けてもよい。監視間隔トラッカは、受信日が監視間隔の終了日より前であるか後であるかを計算することによって、受信日が監視間隔内であるかを判定してもよい。受信日が終了日より後である場合、監視間隔トラッカは、後に受信した送信データを取り込むために監視間隔を調整する方法を示す規則データベースから間隔延長規則にアクセスしてもよい。例えば、終了日が発生しても、監視間隔のために送信データがまだ受信されていない場合、監視間隔トラッカは、監視間隔が日ごとに延長されることを示す第１の間隔延長規則にアクセスしてもよく、送信データを受信するまで毎日、監視間隔の延長された終了日を作成してもよい。延長された監視間隔中に送信データが受信された場合、延長された監視間隔が終了する場合があり、場合によっては、（延長された終了日である場合もある）受信日に延長された監視間隔の業務の日付（ＤＯＳ）を生成してもよい。これに加えて、あるいはこれとは別に、監視間隔トラッカは、終了日に達すると、終了日より前に送信データを受信することなく、監視間隔（例えば、第１の監視間隔）が終了する予定であり、（例えば、患者ケア様式規則によって指示されるように、第１の監視間隔と同じ時間の長さを有する）第２の監視間隔が新たな第２の終了日で生成され得ることを示す規則データベースからの第２の間隔延長規則にアクセスしてもよい。

いくつかの例では、監視間隔トラッカは、ＤＯＳを生成するためにＤＯＳ基準が満たされているかどうかを判定してもよい。例えば、ＤＯＳ基準は、送信データの受信日が監視間隔の終了日（又は延長された終了日）より前であること、送信データに対して診療記録レポートを終了日（又は延長された終了日）より前に生成すること、受信日よりも後であり、診療記録レポートの日付よりも後であるが、終了日（又は延長された終了日）よりも前の承認日を示す診療記録レポートに対する承認タイムスタンプを受信することを含んでもよい。監視間隔トラッカは、患者ケアの種類に応じて監視間隔を生成し、延長するための１つ又は複数の患者ケア様式規則及び／又は間隔延長規則など、規則データベースから複数の規則にアクセスして、ＤＯＳ基準を確実に満たすようにしてもよい。例えば、監視間隔トラッカは、終了日より前に送信データを受信し、終了日より前に診療記録レポートを生成する場合があるが、終了日の発生時に診療記録レポートの承認日を示す承認タイムスタンプをまだ受信していない場合がある。このため、監視間隔トラッカは、承認タイムスタンプが受信され、監視間隔のＤＯＳ基準が満たされるまで、監視間隔が日ごとに延長され、延長された終了日を毎日作成することを示す規則データベースからの第３の間隔延長規則にアクセスしてもよい。

いくつかの例では、監視間隔トラッカは、心臓監視装置に対して複数の同時に有効になる監視間隔を生成してもよく、同時に有効になる監視間隔のそれぞれは、異なる患者ケア様式規則に対応し、このため、異なる時間長及び異なる終了日を有する。同時に有効になる監視間隔ごとの診療記録レポートなど、送信データに対して複数の診療記録レポートを受信しても、生成してもよい。場合によっては、監視間隔トラッカは、複数の診療記録レポートのうちの第１の診療記録レポートに対する第１の承認タイムスタンプを、終了日より前、終了日又は延長された終了日に受信する一方で、複数の診療記録レポートのうちの第２の診療記録レポートに対する第２の承認タイムスタンプが依然として不足している場合がある。例えば、心不全患者のケアに関する第１の監視間隔に関する第１の診療記録レポートは、第１の監視間隔内で承認される可能性があるが、遠隔監視による患者のケアに関する第２の監視間隔に関する第２の診療記録レポートが未承認のままである。監視間隔トラッカは、第２の診療記録レポートが未承認のままである場合でも、承認された診療記録レポートの送信データのＤＯＳを生成する場合がある。さらに、監視間隔トラッカは、（例えば、第１の監視間隔の後に生成される）第３の監視間隔中に、第２の診療記録レポートに対する第２の承認タイムスタンプを受信してもよい。さらに、監視間隔トラッカは、第２の承認タイムスタンプが（第１の診療記録レポートの第１の承認タイムスタンプに基づいて）既にＤＯＳを受信した送信データに対応することを認識し、第２の承認タイムスタンプに基づいて第２のＤＯＳを生成するステップを省略してもよい。

いくつかの例では、医療装置管理プラットフォームは、グラフィカルユーザインターフェース（ＧＵＩ）を介して、患者ケアを提供する診療所のディスプレイ上に監視間隔トラッカによって生成された情報を提示するための監視間隔可視化装置などのインターフェースツールを含んでもよい。例えば、監視間隔可視化装置は、監視間隔を１つ又は複数のタイムライン上の対話型間隔形状（例えば、バー、ブロック、ラインなど）として提示してもよい。対話型間隔形状は、受信日、診療記録レポートステータス、診療記録レポートの日付及び／又は承認日に対応する指標又はアイコンを含んでもよい。ユーザ入力を受信すると、対話型間隔形状及び／又は指標は、送信データの受信日、診療記録レポートの日付、承認日、（診療記録レポートを作成した医療関係者及び／又は診療記録レポートを承認した医療関係者の名前を含む）診療記録レポート及び／又は監視間隔に対応する１つ又は複数の行動要求指標などのさまざまな送信関連データを許可されたユーザに提示してもよい。いくつかの例では、インターフェースツールは、送信データベースから特定の診療所の送信関連データを集約し、特定の診療所の１つ又は複数の送信メトリクスを生成し、特定の診療所のディスプレイ上に送信メトリクスを提示するための送信ダッシュボードを含んでもよい。このほか、受信した送信及び結果として得られるケアプロトコルの統計値をはじめとする測定値を、診療所の運営と効率を改善するか、患者へのケアを改善するか、インターフェースにアクセス可能な別の組織とデータを共有するために、インターフェースツールを通じて提供してもよい。このようにして、装置管理プラットフォームインターフェースのユーザにとって装置送信の管理が簡素化され、改善される。

ここで、図１を参照する。図１は、１つ又は複数の心臓埋め込み型電子装置１０４を管理するために、ネットワーク１０６に結合されたサーバ１１２上又は他の計算装置上で稼働する医療装置マネージャ１０２を含む、例示的なネットワーク環境１００を示す。一実装例では、医療チームのメンバー及び／又は管理業務を管理するか完了するためにアクセスが委任されている第三者などのユーザが、ユーザ装置１０８を使用して医療装置マネージャ１０２のためのポータルにアクセスし、対話して、ネットワーク１０６（例えば、インターネット）を介して１つ又は複数の医療装置にアクセスするか同装置を管理する。ユーザ装置１０８は、一般に、パーソナルコンピュータ、端末、ワークステーション、ポータブルコンピュータ、モバイル装置、スマートフォン、タブレット、マルチメディアコンソールなど、ネットワーク１０６と相互作用することができる任意の形態の計算装置である。ネットワーク１０６は、ネットワーク環境１００内に医療装置マネージャ１０２をはじめとするサービス、データ構造、アプリケーション又はモジュールを実装するために、１つ又は複数の計算装置又はデータ記憶装置（例えば、本明細書に記載の１つ又は複数のデータベース１１０又は他の計算ユニット）によって使用される。

一実装例では、ネットワーク環境１００は、ユーザが医療装置マネージャ１０２にアクセスするためにアクセスし得るウェブサイト又はアプリケーションをホストする少なくとも１つのサーバ１１２及び／又は医師の診療室に存在し、患者の面前で利用される装置プログラミングマシンを含む他のネットワークコンポーネントを含む。サーバ１１２は、単一のサーバであっても、そのようなサーバそれぞれが物理サーバ又は仮想マシンである複数のサーバであっても、物理サーバと仮想マシンの両方の集合であってもよい。別の実装例では、クラウドがネットワーク環境１００の１つ又は複数のコンポーネントをホストする。ネットワーク１０６に接続されたユーザ装置１０８、サーバ１１２をはじめとする情報源は、統合された医療提供のために使用される１つ又は複数のウェブサイト、アプリケーション、ウェブサービスインターフェース、記憶装置、計算装置などにアクセスするために、１つ又は複数の他のサーバにアクセスしてもよい。サーバ１１２はこのほか、医療装置マネージャ１０２が患者データ、チームメンバーデータ、教育データをはじめとするデータにアクセスし、同データを検索し、変更するために使用する検索エンジンをホストしてもよい。一実装例では、医療装置マネージャ１０２は、心臓監視装置などの１つ又は複数の医療装置１０４のデータ及び／又は他の情報へのアクセスを提供する。

医療装置１０４は、ネットワーク１０６と通信して、医療装置マネージャ１０２に動作データを提供してもよい。例えば、上記で説明したように、埋め込み型除細動器（ＩＣＤ）などの心臓埋め込み型電子装置（ＣＩＥＤ）が、分析、プログラミングなどのために、体外の装置の動作に関連する情報を送信することが多い。場合によっては、診療所が、医療装置１０４のためのデータを、装置製造業者の安全なウェブサイトから読み出したり、及び／又は医療提供者の診療室に物理的に位置づけられた装置プログラミングマシンから読み出したりする。医療装置１０４によって生成されたデータは、典型的には、医療提供者によって検討され、その後、医療提供者が診療記録レポートを生成する。典型的には、医療提供者が、埋め込んで、あらゆる製造業者、装置のモデル及びタイプからの送信を監視する。
医療提供者が単一の装置タイプを埋め込んで監視することはほとんどない。データ送信と、データ送信の審査の様式に関して、各製造業者は、独自かつ専有のデータ形式、ディスプレイ、アクセスプロトコル、レポート及びプログラミングマシンを使用している。医療提供者がこの広範囲にわたる独自かつ異種の形式でデータを受信するため、医療提供者が患者のケアを効率的に管理することは困難である。データのアクセスと管理の負担は、患者ケアの向上の大きな妨げとなっている。煩雑なワークフローにより過剰なコストが発生し、優れたケア様式である遠隔ケアの導入が妨げられ、償還の機会の逸失につながり、一部の診療所は遠隔ケアを断念し、その代わりに患者をさらに少ない量の院内ケアに押しやることになり、患者のコンプライアンスが低くなることと、入院の増加に伴う医療システムの負担が増大することにより、さらにケアが低下することになる。これにより、以下でさらに詳細に説明するように、医療装置マネージャ１０２は、ユーザが、ＤＯＳ計算を改善し、追跡管理の失敗を低減しながら、さまざまな装置のタイプ及び異なる製造業者にわたる１つ又は複数の医療装置１０４からのデータを管理したり、分析したり、及び／又は保存したりすることができるようにする。

図２を参照すると、医療装置マネージャ１０２は、医療装置データ通信システム２００を含んでもよい。一実装例では、医療装置データ通信システム２００は、複数の埋め込み型医療装置製造業者システム２０６及び複数の診療所システム２０２と通信する医療装置プラットフォーム２０４を含む。医療装置プラットフォーム２０４は、例えば、インターネットなどの広域ネットワーク（ＷＡＮ）を介して製造業者システム２０６及び診療所システム２０２に通信可能に結合されてもよい。いくつかの実装例では、製造業者システム２０６のそれぞれは、固有の埋め込み型医療装置製造業者と関連付けられてもよい。他の例では、製造業者システム２０６のそれぞれは、埋め込み型医療装置製造業者と特定の診療所又は診療室との固有の組み合わせに関連付けられてもよい。図２のシステム２００の例では、製造業者システム２０６は、複数の埋め込み型医療装置から以前にアップロードされた診断データ及び関連データを装置データベース２１４から読み出す、例えば、ウェブサーバなどの製造業者プラットフォーム２１２を含んでもよい。そのようなデータは、上述したように、診療所又は診療室を経由して、あるいは遠隔モニタを経由して、さまざまな埋め込み型医療装置からあらかじめ読み出されていてもよい。

図２に示すように、医療装置プラットフォーム２０４は、各製造業者システム２０６からの埋め込み型医療装置のための診断データ及び関連データにアクセスする統合マネージャ２１０を含んでもよい。一例では、統合マネージャ２１０は、特定の診療所に関連付けられた臨床情報システム（ＣＩＳ）識別子を製造業者プラットフォーム２０６に提供して、診断データ及び関連情報を読み出してもよい。このような情報は、Ｉｍｐｌａｎｔａｂｌｅ Ｄｅｖｉｃｅ Ｃａｒｄｉａｃ Ｏｂｓｅｒｖａｔｉｏｎ（ＩＤＣＯ）メッセージの形式であってもよい。いくつかの実装例では、統合マネージャ２１０と製造業者プラットフォーム２１２との間のメッセージが、代替データメッセージ、強化データメッセージ又は拡張データメッセージの形式であってもよい。例えば、ＩＤＣＯメッセージには、Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ（ＰＤＦ）の概要レポートとしてフォーマットされた情報が含まれることが多い。他の例では、ＩＤＣＯ様メッセージが、整数、浮動小数点又は別のデータ形式で埋め込み型装置によって検出された不整脈又は他の心臓発作に関する数値データ及び／又はグラフィック電気記録図（ＥＧＭ）データなど、さらに詳細なデータ又は「生の」データを提供してもよい。そのような情報は、医療装置プラットフォーム２０４内での機器データのさらに容易な処理及び／又はさらに詳細な処理を促進してもよい。

次いで、統合マネージャ２１０は、読み出した情報を処理して、患者向けの情報及び／又は医療提供者向けの情報を生成してもよい。いくつかの例では、さまざまな埋め込み型医療装置から読み出された情報は、全製造業者及び／又は特定の種類の装置にわたって統一されるか一般化されるフォーマットに処理されてもよい。次に、統合マネージャ２１０は、処理された情報を、診療所システム２０２に１つ又は複数のウェブポータルを提供し得るクラウド計算システム２０８に転送してもよい。他の例では、統合マネージャ２１０は、読み出した装置データをクラウド計算システム２０８に転送してもよく、その後、クラウド計算システム２０８は、データを処理する情報プロセッサとして動作してもよい。クラウド計算システム２０８はこのほか、ウェブポータルを介して、処理された情報に基づいて、分析結果をはじめとする高度な情報を生成し、提供してもよい。ウェブポータルの例と、情報の分析の生成と提供については、以下でさらに詳細に説明する。いくつかの例では、クラウド計算システム２０８は、本明細書にてクラウド計算システム２０８に起因するさまざまな動作を実施するように構成された複数のコンピュータ装置又はシステムを含んでもよい。

図２に示すように、ユーザ（例えば、１人又は複数の医師、看護師、技術者、分析者など）が、診療所システム２０２を採用して、場合によっては１つ又は複数の埋め込み型医療装置の監視間隔追跡、分析結果をはじめとする高度な情報を含む、処理された装置情報を読み出してもよい。いくつかの例では、診療所システム２０２は、診療所アクセスシステム２１８（例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォンなど）を含んでもよい。診療所アクセスシステム２１８から、ユーザがクラウド計算システム２０８によって提供されるウェブポータルにアクセスして、医療装置マネージャ１０２などの医療提供者向けの情報を読み出してもよい。図２に示すように、診療所システム２０２はこのほか、診療所の患者の医療記録を保存してアクセスを容易にするように構成された電子医療記録マネージャシステム２１６と、診療所システム２０２の外部にある他の計算システムを用いて診療所の患者のための健康医療情報を交換するように構成された健康情報交換（ＨＩＥ）システム２２０と、のうちの１つ又は複数を含んでもよい。一実装例では、ユーザが、シングルサインオン（ＳＳＯ）手順を使用して、クラウド計算システム２０８、医療レコーダマネージャ２１６及び／又はＨＩＥシステム２２０にサインオンするか、ログオンすることにより、ユーザがこのようなシステムのそれぞれに個別にアクセスするのに通常必要とする時間を短縮してもよい。

いくつかの例では、統合マネージャ２１０は、埋め込み型医療装置のうちの１つ又は複数との通信接続によって受信される送信データを介して、装置診断データをはじめとする装置情報を読み出してもよく、このため、場合によっては、製造業者システム２０６のうちの１つ又は複数の必要性を低減する場合がある。このような例をはじめとする例では、統合マネージャ２１０及び／又はクラウド計算システム２０８は、未処理の装置情報及び／又は処理された装置情報のほか、分析結果をはじめとする高度な情報を、装置の対応する製造業者によって使用される製造業者システム２０６のうちの１つ又は複数に転送しても、「プッシュ」してもよい。

いくつかの例では、医療装置プラットフォーム２０４は、監視間隔トラッカ２２２を含んでもよい。監視間隔トラッカは、統合マネージャ２１０などの医療装置マネージャ１０２の他のコンポーネントからデータ（例えば、送信データ及び送信関連データ）を受信してもよい。監視間隔トラッカ２２２は、アクセスシステム２１８などの診療所システム２０２からデータを受信してもよい。場合によっては、監視間隔トラッカ２２２は、送信データの発信元の心臓監視装置、（例えば、心臓監視装置又は心臓監視装置によって監視されている患者との関連に基づいて）送信データに関連付けられた一種の患者ケア（例えば、「患者ケア様式」）及び／又は心臓監視装置のための１つ又は複数の監視間隔に従って、送信データを分類してもよい。監視間隔トラッカは、データベース１１０からの１つ又は複数の規則にアクセスし、監視間隔の延長及び監視間隔のためのＤＯＳを生成するための計算を実施してもよい。場合によっては、監視間隔トラッカ２２２は、送信データ及び送信関連データの分析を実施し、結果を医療提供者ポータルに出力してもよい。監視間隔トラッカ２２２は、（例えば、登録プロセス中に）患者が特定の患者ケア様式に関連付けられているという指示を受信したり、及び／又は患者と患者ケア様式との関連付けを１つ又は複数のデータベース１１０に保存したりしてもよい。監視間隔トラッカ２２２は、１つ又は複数の間隔延長規則と、１つ又は複数のデータベース１１０の特定の患者及び／又は特定の診療所との間の関連性を判定し、保存してもよい。監視間隔トラッカ２２２の動作については、以下でさらに詳細に考察する。

図３は、図２の医療装置プラットフォーム２０４の一例のブロック図である。図３に示すように、医療装置プラットフォーム２０４は、送信アナライザ３００、トラッカ３０２、アグリゲータ３０４、医療提供者ポータル３０６、スケジューラ３０８、診療記録ジェネレータ３１０、ワークフローエンジン３１２、課金エンジン３１４及び／又は記録インテグレータ３１６のうちの1つ又は複数を含んでもよい。このほか、他の例では、本明細書に特に説明していない他のソフトウェアコンポーネント、データ構造、アプリケーション又はモジュールが医療装置プラットフォーム２０４に含まれてもよい。さらに、このようなソフトウェアコンポーネントのそれぞれは、図２に示すように、監視間隔トラッカ２２２、統合マネージャ２１０及び／又はクラウド計算システム２０８内に組み込まれてもよい。

いくつかの例では、送信アナライザ３００は、１つ又は複数の心臓監視装置から受信した情報及びデータを分析し、分析された情報の傾向の自動スナップショットを提供するように構成されてもよい。いくつかの実施形態では、そのような情報は、特定の診療所又は複数の診療所について分析されてもよい。上述したように、１つ又は複数の心臓監視装置は、埋め込み型装置の性能又は動作に関する保存された情報又は取得された情報又はデータを送信してもよい。この情報は、医療装置プラットフォーム２０４に送信されるか、ダウンロードされ、送信アナライザ３００によって分析される。情報の分析により、ポータルを通じて分析された情報及び／又は集約された情報の特定のスナップショットが提供される場合がある（さらに詳細について以下で説明する）。例えば、送信アナライザ３００は、情報又はデータに関連付けられた装置の種類、装置の製造業者又は特定の装置モデルに基づいて情報を提供してもよい。同じように、トラッカ３０２は、受信データの経時的傾向を追跡するために医療装置プラットフォーム２０４に含まれてもよい。送信アナライザ３００と、トラッカ３０２と、他のソフトウェアコンポーネントとの組み合わせを通じて、承認の受信又は承認の欠落に関する診療記録レポートの傾向、延長されたＤＯＳによる監視間隔、受信されたデータの全体的な送信及び特定の監視間隔など、装置情報のスナップショットを提供してもよい。１つ又は複数の医療装置から受信され、送信アナライザ３００によって分析されたデータに関する分析結果及び情報についてはさらに、以下でさらに詳細に考察する。

いくつかの例では、アグリゲータ３０４はこのほか、医療装置プラットフォーム２０４に含まれてもよい。一般に、アグリゲータ３０４は、上記で考察した各製造業者システム２０６から診断データをはじめとする装置関連データを読み出したり、及び／又は心臓監視装置から情報を読み出したりするように構成されてもよい。一例では、アグリゲータ３０４は、製造業者固有の宅配エンジンを利用して、特定のセキュリティ対策と、通信プロトコルと、データフォーマットと、クーリエエンジンからデータを読み出すのに必要な特定の製造業者システム２０６の他の特性と、を使用してデータを読み出してもよい。少なくともいくつかの例では、アグリゲータ３０４の使用により、診療所内の情報技術（ＩＴ）専門家、特に、独自のデータ形式、通信プロトコルなどをそれぞれが採用し得る複数の製造業者からの装置が、埋め込み型医療装置から診断データをはじめとする情報を読み出す必要性が低減される場合がある。

いくつかの例では、医療提供者ポータル３０６は、診療所スタッフによるその診療所の患者に対応する医療提供者向けの装置データ情報へのアクセスを容易にするウェブインターフェースを診療所システム２０２に提示するように構成されてもよい。医療提供者ポータル３０６は、診療所スタッフ及び患者のログオンをそれぞれ利用して、必要に応じて医療提供者向け又は患者向けの情報へのアクセスを許可してもよい。いくつかの例では、上記のように、医療提供者ポータル３０６へのログオンにより、シングルサインオン（ＳＳＯ）機能を介した診療所スタッフによる診療所システム２０２の外部又は内部に位置する他のシステム（例えば、図２の医療記録マネージャ２１６及び／又はＨＩＥシステム２２０）へのアクセスが容易になる場合がある。さらに、医療提供者ポータル３０６は、例えば、埋め込みウェブリンクなどの装置関連情報へのアクセスポイントを含み得る患者の電子健康記録（ＥＨＲ）への患者又は医療提供者のアクセスを促進するアプリケーションプログラミングインターフェース（ＡＰＩ）を提供してもよい。医療提供者ポータル３０６は、以下でさらに詳細に考察するように、監視間隔、診療記録レポート、承認日及びＤＯＳを表すタイムライン、間隔形状、インジケータ、ブロック及び／又はアイコンなどの監視間隔トラッカ２２２の１つ又は複数の視覚化を提示してもよい。

いくつかの例では、医療装置プラットフォーム２０４は、診療所又は保険会社に関連する管理担当者、診療所又は保険会社に関連する役員、１つ又は複数の心臓装置製造業者の従業員などのためのポータルなど、医療提供者ポータル３０６以外の他の情報ポータルを提供しても、含んでもよい。そのような例では、医療装置プラットフォーム２０４の潜在的なユーザの特定のクラス又はグループのそれぞれは、特定のアクセス範囲又はアクセス権のセット、セキュリティ要件のセット（例えば、ユーザ名、パスワード、コンピュータシステムなどの要件）に関連付けられてもよい。その結果、ユーザの各グループは、医療提供者ポータル３０６とほぼ同じ対応するユーザポータルを採用してもよい。特定のポータルそれぞれには、異なる（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）ＵＲＬを介してアクセス可能であってもよく、同ポータルは１つ又は複数の他の方法で区別されてもよい。

いくつかの例では、スケジューラ３０８は、患者及び／又は診療所スタッフがアクセス可能なウェブインターフェース（例えば、上記のウェブポータル又は別のウェブポータル）を提示して、院内装置又は自宅装置のチェック又は診療所の患者の通院のプログラミングなどの予約をするように構成されてもよい。いくつかの例では、スケジューリングウェブポータルは、特定の診療所ごとにカスタマイズされてもよく、診療所によって提供される業務、診療所スタッフのメンバーの説明などに関する追加情報を提供する可能性がある。例えば、監視間隔トラッカ２２２は、院内ケアを有する心臓監視装置に対応する行動要求指標を生成してもよい。行動要求指標にてユーザ入力を受信すると、スケジューラ３０８は、心臓監視装置によって監視されている特定の患者に対するスケジューリング手順を開始してもよい。

診療記録ジェネレータ３１０は、患者又は受信データの集合に関連する１つ又は複数の診療記録（例えば、「診療記録レポート」）を作成するように構成されてもよい。一般に、診療記録レポートは、受信した患者ＣＩＥＤ送信の解釈及び記録を要約するか、さもなければ提供するある種の報告書である。診療記録レポートの全部又は一部には、送信中に受信した情報が入力され、診療記録レポートの全部又は一部を分析と承認のために診療所スタッフに提供する場合がある。診療記録レポートは、装置製造業者情報、診療所スタッフの承認、臨床データ、ケア計画、装置の追跡記録、患者情報、データ分析の概要などの情報を含んでもよい。患者情報に関するあらゆる情報、あるいは複数の医療装置から受信した情報を、診療記録ジェネレータ３１０を通じて診療記録に含めてもよい。場合によっては、監視間隔トラッカ２２２は、送信データの受信に応答して、診療記録レポートを必要とする指標を生成してもよい。この指標は、ユーザ入力を受信すると、診療記録ジェネレータ３１０に、受信した送信に対する診療記録作成プロセスを開始させる。

ワークフローエンジン３１２は、定期的な装置チェックに関する情報、結果として得られる診断データをはじめとする１人又は複数の患者の心臓監視装置に関連する情報を監視し、その情報に基づいて、診療所のワークフローへの変更、例えば、装置チェックスケジュールへの変更、埋め込み型医療装置から読み出された特定の種類の情報への変更、読み出された情報の処理方法への変更などを推奨し、これにより、場合によっては、診療所の業務をさらに効率的にするように構成されてもよい。

課金エンジン３１４は、臨床スタッフが、心臓監視装置などの患者の埋め込み型医療装置に対して実施される１つ又は複数の臨床行為の指示を入力し得るインターフェースであって、その行為を表す現在適切な課金コードを生成するインターフェースを（例えば、医療提供者向けのウェブポータルを介して）提示するように構成されてもよい。さらに、１つ又は複数のそのような行動に対して結果として生じる課金コードは、患者、医療保険会社などに提示するための課金コード要約シート又は他のフォーマットにさらに挿入されてもよい。いくつかの例では、課金エンジン３１４は、定額償還方式（ＰＰＳ）で採用可能なＣｅｎｔｅｒｓ ｆｏｒ Ｍｅｄｉｃａｒｅ ａｎｄ Ｍｅｄｉｃａｉｄ Ｓｅｒｖｉｃｅｓ（ＣＭＳ）から課金コードの変更に関する情報を受信しても、読み出してもよく、そのような変更を利用して、埋め込み型医療装置に関連する臨床行為に対応する課金コードを更新してもよい。

記録インテグレータ３１６は、例えば、処理された装置関連データへのアクセスを容易にするウェブリンクを患者のＥＨＲに埋め込むことによって、ＥＨＲを更新するか、処理された診断データをはじめとする埋め込み型医療装置に関連する情報をＥＨＲに投入するように構成されてもよい。そのようなデータには、例えば、埋め込み型医療装置に関して実施された診断の日付、診断結果の数値データ及び／又はグラフ、診断結果に基づいて推奨された行動及び／又は実施された行動、装置によって検出されたデータに基づく装置の動作に対する患者の健康状態又は生物学的反応、などが含まれる場合がある。

図４は、図２の監視間隔トラッカ２２２の一例のブロック図である。監視間隔トラッカ２２２は、受信した送信データを分析して送信データの発信元の心臓監視装置を特定するために図３に関して上記で考察したソフトウェアコンポーネントの多くを含んだり、心臓監視装置に提供されている１つ又は複数の患者ケア様式に従って送信データを分類したり、送信データ用の１つ又は複数の診療記録を生成したり、心臓監視装置の１つ又は複数の監視間隔を延長したり、及び／又は送信データのＤＯＳを生成したりしてもよい。監視間隔トラッカ２２２は、データベース１１０に保存された情報にアクセスしてもよい。例えば、データベース１１０は、１つ又は複数の患者ケア様式規則４０２及び／又は１つ又は複数の間隔延長規則４０４を保存するための規則データベース４００を含んでもよい。患者ケア様式規則４０２は、監視間隔が心不全患者ケアに関連付けられている場合、監視間隔が３１日の時間長を有することを示す、心不全患者ケアのための第１の患者ケア様式規則を含んでもよい。患者ケア様式規則４０２は、監視間隔が遠隔監視患者ケアに関連付けられている場合、監視間隔が９１日の時間長を有することを示す、遠隔監視患者ケアのための第２の患者ケア様式規則を含んでもよい。患者ケア様式規則４０２は、監視間隔が院内患者ケアに関連付けられている場合、監視間隔の時間長は９１日であることを示す院内患者ケアのための第３の患者ケア様式規則を含んでもよい。患者ケア様式規則４０２は、監視間隔が他の時間長であることを示す、他の種類の患者ケアのための追加の患者ケア様式規則を含んでもよい。患者ケア様式規則によれば、監視間隔中に全ＤＯＳ基準が満たされた場合、監視間隔の終了日が、監視間隔中（即ち、終了日より前）に受信された送信データの予測ＤＯＳになる場合がある。しかし、場合によっては、終了日までにＤＯＳ基準が満たされない可能性があり、その場合、監視間隔トラッカ２２２は、間隔延長規則にアクセスして、監視間隔の延長された終了日を生成してもよい。

いくつかの例では、間隔延長規則４０４は、送信データ及び送信関連データに基づいて、監視間隔がどのように延長されるか、延長されないか、閉じられるかを示してもよい。例えば、間隔延長規則４０４は、ＤＯＳが監視期間の終了日又は送信データの受信日（どちらか遅い方）であることを示す第１の間隔延長規則（例えば、「日ごと送信ロール」規則）を含んでもよい。日ごと送信ロール規則によれば、監視間隔の終了日が発生し、送信データがまだ受信されていない場合、監視間隔トラッカ２２２は、送信データを受信するまで毎日、監視間隔に１日を加えて、延長された終了日を生成することになる。送信データが受信された時点で、監視間隔が終了し、（監視間隔の最終延長終了日でもある）送信の受信日として監視間隔に対してＤＯＳが生成され、第２の監視間隔が、終了するか閉じた監視間隔の後に有効になるように生成されることになる。日ごと送信ロール規則によれば、送信データには課金目的で診療記録レポートとその診療記録レポートの承認がさらに必要な場合があるが、第２の監視間隔は、医師又は医療関係者がタイムリーに送信データの診療記録レポートを作成し承認することに依存しないように、送信の受信日後の日付にさらに開始されることになる。

いくつかの例では、間隔延長規則４０４は、監視期間中に送信データが受信されたかどうかに関係なく、ＤＯＳが監視期間の終了日であることを示す第２の間隔延長規則（例えば、「間隔ごとロール」規則）を含んでもよい。間隔ごとロール規則によれば、監視期間の終了日が発生して、送信データが未だ受信されていない場合、監視間隔は、延長されずに終了することになり、患者追跡調査及び課金手続きに対する監視間隔の「欠落」として分類される場合がある。終了するか閉じた監視間隔の後に実施されるように第２の監視間隔が生成されることになる。第２の監視間隔は、閉じた監視期間の時間長と同じ時間長を有してもよい。閉じた監視期間の間は診療記録レポート又は承認要件が生成されないことになる。

いくつかの例では、間隔延長規則４０４は、ＤＯＳが監視期間の終了日、あるいは送信データに対応する診療記録レポートの（例えば、承認タイムスタンプによって示される）承認日のいずれか遅い方であることを示す第３の間隔延長規則（例えば、「日ごと承認ロール」規則）を含んでもよい。日ごと承認ロール規則によれば、監視間隔の終了日が発生し、診療記録レポートの承認タイムスタンプが未だ受信されていない場合、監視間隔トラッカ２２２は、承認タイムスタンプを受信するまで毎日、監視間隔に１日を追加して、延長された終了日を生成することになる。承認タイムスタンプが受信された時点で、監視間隔が終了し、ＤＯＳが（監視間隔の最終延長終了日でもある）診療記録レポートの承認日として監視間隔に対して生成され、第２の監視間隔が、終了するか閉じた監視間隔の後に有効になるように生成されることになる。場合によっては、医療装置プラットフォーム２０４は、監視間隔中に複数の診療記録レポートを生成してもよく、その場合、複数の診療記録レポートのうちの１つに対応する最も早い承認タイムスタンプが、監視間隔のＤＯＳ日付であると判定されることになる。

いくつかの例では、患者ケア様式規則４０２及び／又は間隔延長規則４０４は、例えば、医療政策データベース４０６に保存された１つ又は複数の医療政策に基づくものであってもよい。医療政策データベース４０６は、１つ又は複数のＨｅａｒｔ Ｒｈｙｔｈｍ Ｓｏｃｉｅｔｙ（ＨＲＳ）ケアガイドライン及び／又はＣｅｎｔｅｒ ｆｏｒ Ｍｅｄｉｃａｒｅ ａｎｄ Ｍｅｄｉｃａｉｄ Ｓｅｒｖｉｃｅｓ（ＣＭＳ）ケアガイドラインを保存してもよい。例えば、ＣＭＳケアガイドラインは、１つ又は複数の専門家コード（ＰＣ）を含んでもよい。例えば、ＰＣ９３２９４には、「問診装置の評価（遠隔）、最大９０日間、医師又は他の資格のある医療専門家による中間分析、レビュー及びレポートを備えたシングルリード、デュアルリード又はマルチリードのペースメーカーシステム（９３２９４を９３２８８、９３２９３と併せて報告しないよう求める）（９３２９４を９０日ごとに１回のみ報告されたい）」と記述されたり、ＰＣ９３２９５には、「問診装置の評価（遠隔）、最大９０日間、医師又は他の資格のある医療専門家による中間分析、レビュー及びレポートを備えたシングルリード、デュアルリード又はマルチリードの埋め込み型除細動器システム（ＩＣＤから得られる生理学的心血管データ要素の遠隔監視の場合、９３２９７を使用されたい）（９３２９５を９３２８９と併せて報告しないよう求める）（９３２９５を９０日ごとに１回のみ報告されたい）」と記述されたり、ＰＣ９３２９７には、「問診装置の評価（遠隔）、最大３０日間、あらゆる内部センサ及び外部センサから記録された１つ又は複数の生理学的心血管データ要素の分析、医師又は他の資格のある医療専門家による分析、レビュー及びレポートを含む埋め込み型心血管モニタシステム（心拍リズム由来のデータ要素の場合、９３２９５を使用されたい）（９３２９７を９３２９０、９３２９８と併せて報告しないよう求める）（９３２９７を３０日ごとに１回のみ報告されたい）」と記述されたり、及び／又はＰＣ９３２９８には、「問診装置の評価（遠隔）、最大３０日間、記録された心拍リズムデータの分析、医師又は他の資格のある医療専門家による分析、レビュー及びレポートを含む埋め込み型ループレコーダシステム（９３２９８を３３２８２、９３２９１、９３２９７と併せて報告しないよう求める）（９３２９８を３０日ごとに１回のみ報告されたい）」と記述されたりしている。監視間隔トラッカ２２２（及び／又は医療装置プラットフォーム２０４の他のコンポーネント）は、ＰＣコードなどの医療政策にアクセスし、（例えば、手動入力及び／又は機械学習技術を使用した自動テキスト及びコンテンツ認識を介して）ＰＣコードに対応するように患者ケア様式規則及び／又は間隔延長規則を生成してもよい。医療政策データベースは、患者ケア様式規則及び／又は間隔延長規則４０４が継続的に最新の状態に保たれて、高効率の課金手法に対応する正確な監視間隔追跡を提供するように、ＨＲＳ又はＣＭＳ政策の変更を反映するために、定期的な間隔（例えば、毎週、毎月、毎年など）で更新されてもよい。

いくつかの例では、データベース１１０は、送信データと、送信データに関連付けられた送信関連データとを保存するための送信データベースを含んでもよい。例えば、送信に関連する送信関連データは、送信データの受信日を示す受信日タイムスタンプ、送信データの送信元の心臓監視装置に対応する心臓監視装置識別子、患者識別子、診療所識別子、診療記録レポート作成日のタイムスタンプ、承認タイムスタンプ、ＤＯＳ基準ステータスの表示及び／又は送信データに関連する医療装置プラットフォーム２０４の他のコンポーネント（例えば、統合マネージャ２１０、クラウド計算システム２０８、送信アナライザ３００、トラッカ３０２、アグリゲータ３０４など）によって生成されるか受信された任意のデータを含んでもよい。

いくつかの例では、監視間隔トラッカ２２２は、監視間隔と、終了日、延長された終了日、診療記録作成日、承認日及び／又はＤＯＳの表示を提示するための監視間隔ビジュアライザ４１０を生成してもよい。監視間隔ビジュアライザ４１０は、特定の監視間隔が送信を必要とするか、診療記録レポートを必要とするか、診療記録レポートの承認を必要とすることを医療関係者に警告するために、「行動が必要」の表示を提示してもよい。表示は、ユーザ入力の受信時に追加情報を提供するために、医療提供者ポータルを介して、選択可能な形状及び／又は対話型グラフィカルユーザインターフェース（ＧＵＩ）指標として提示されてもよい。監視間隔ビジュアライザ４１０については、以下でさらに詳細に考察する。

いくつかの例では、監視間隔トラッカ２２２は、送信ダッシュボード４１２を生成してもよい。例えば、監視間隔トラッカ２２２は、送信データベース４０８から送信データ及び／又は送信関連データにアクセスし、送信データ及び／又は送信関連データを集約し、集約された送信データ及び／又は送信関連データに対して分析を実施し、分析の結果を送信ダッシュボード４１２に提示してもよい。いくつかの例では、送信データ及び／又は送信関連データは、結果が特定の診療所識別子に対応する特定の診療所に対する送信メトリクスとなるように、特定の診療所識別子に従って集約されてもよい。送信ダッシュボード４１２は、医療提供者ポータル３０６を介して提示されてもよい。送信ダッシュボード４１２については、以下でさらに詳細に考察する。

図５は、１つ又は複数のＤＯＳを生成するために、日ごと送信ロール規則を使用して監視間隔トラッカ２２２によって実施される動作の複数の例示的なタイムライン図を示す。図６は、１つ又は複数のＤＯＳを生成するために間隔ごと送信ロール規則を使用して監視間隔トラッカ２２２によって実施される動作の例示的なタイムライン図を示す。図７～図１１は、１つ又は複数のＤＯＳを生成するために、日ごと承認ロール規則を使用して監視間隔トラッカ２２２によって実施される動作の複数の例示的なタイムライン図を示す。

図５を参照すると、１つ又は複数のＤＯＳを生成したり、新たな監視間隔を生成したり、及び／又は監視間隔の延長を生成したりするために、日ごと送信ロール規則を使用して監視間隔トラッカ２２２によって実施される動作を示す２つの例示的なタイムライン図を示している。例えば、第１の例示的なシナリオ５００では、第１の監視間隔５０２が生成されてもよい。送信データ５０４が発生したときにトリガが発生してもよい。これは、第１の監視間隔５０２の間に（即ち、第１の監視間隔５０２の終了日５０６より前に）送信データ５０４が受信されたときに「成功」として定義される。「成功」に応答して、監視間隔トラッカは、第１の監視間隔５０２の終了日５０６であるとしてＤＯＳを生成し、第１の監視間隔に続いて有効となる新たな監視間隔５０８又は第２の監視間隔５０８を生成する。第２の監視間隔５０８は、第１の監視間隔５０２の時間長と同じ時間長を規定する第２の終了日５１０を有する（これは、患者ケア様式規則４０４に基づくものであってもよい）。第２の例示的なシナリオ５１２を図示する。ここでは、送信データ５０４は第１の監視間隔５０２の間に（即ち、終了日５０６より前に）受信されていない。これは、日ごと送信ロール規則に従って「失敗」として定義される。このため、監視間隔トラッカ２２２は、間隔延長５１４を生成し、例えば、延長された終了日５１６に送信データ５０４が受信されるまで間隔を１日延長してもよい。間隔延長５１４の間に、延長された終了日５１６にて送信データ５０４を受信すると、監視間隔トラッカは、ＤＯＳ（例えば、間隔延長を生成する前の初期の予測されたＤＯＳとは対照的に確定されたＤＯＳ）を、送信データ５０４の受信日（即ち、延長された終了日５１６）であるとして生成し、第１の監視間隔５０２に続いて有効となる新たな監視間隔５０８又は第２の監視間隔５０８を生成する。第２の監視間隔５０８は、間隔延長５１４を追加する前の第１の監視間隔５０２の時間長と同じ時間長を規定する第２の終了日５１０を有する。

図６は、１つ又は複数のＤＯＳを生成し、新たな監視間隔を生成するために、間隔ごと送信ロール規則を使用して監視間隔トラッカ２２２によって実施される動作を示す例示的なタイムライン図を示す。例示的なシナリオ６００では、送信データ５０４は、第１の監視間隔５０２の間に（即ち、終了日５０６より前に）受信されていない。これを、間隔ごと送信ロール規則は「失敗」として定義する。失敗に応答して、監視間隔トラッカ２２２は、第１の監視間隔５０２を閉じて、その結果、閉じられるか欠落した監視間隔６０２となり、監視間隔は、欠落した監視間隔６０２に続いて有効となる新たな監視間隔５０８又は第２の監視間隔５０８を生成する。監視間隔トラッカ２２２は、欠落した監視間隔の間はＤＯＳを生成しない。第２の監視間隔５０８は、欠落した監視間隔６０２の時間長と同じ時間長を規定する第２の終了日５１０を有する。

図７は、１つ又は複数のＤＯＳ、間隔延長及び／又は新たな監視間隔を生成するために、日ごと承認ロール規則を使用して監視間隔トラッカ２２２によって実施される動作を示す２つの例示的なタイムライン図を示す。例えば、第１の例示的なシナリオ７００では、監視間隔トラッカ２２２は、第１の監視間隔５０２を生成してもよい。診療記録レポート７０２及び診療記録レポート７０２の承認日７０４が第１の監視間隔５０２の間に（即ち、第１の監視間隔５０２の終了日５０６より前に）生成されたときに、「成功」が定義される。成功に応答して、監視間隔トラッカ２２２は、終了日５０６としてＤＯＳを生成し、第２の監視間隔５０８を生成する。しかし、（第１の例示的なシナリオ７００に示すように）承認日が日付５０６より前に発生していない場合、「失敗」が発生し、監視間隔トラッカ２２２は間隔延長５１４を生成して、承認日７０４が発生するまで第１の監視間隔５０２を１日延長する。監視間隔トラッカ２２２は、第１の監視間隔に対するＤＯＳを承認日７０４（即ち、延長された終了日５１６）として生成し、第１の監視間隔５０２に続いて有効となる第２の監視間隔５０８を生成する。第２の監視間隔５０８は、間隔延長５１４を追加する前の第１の監視間隔５０２の時間長と同じ時間長を規定する第２の終了日５１０を有する。第２の例示的なシナリオ７０６では、第１の監視間隔５０２は、第１の診療記録レポート７０８が終了日５０６より前に作成され、第１の診療記録レポートの第１の承認日７１０が終了日５０６より前に発生するため、日ごと承認ロール規則によって「成功」として定義される。そのため、第１の監視間隔５０２のＤＯＳ基準が満たされ、第１のＤＯＳが終了日５０６として生成され、第２の監視間隔５０８が生成される。第２の送信データ７１２を、第２の監視間隔５０８の間に（即ち、第２の終了日５１０の前に）受信し、第２の診療記録レポート７１４を、第２の送信データ７１２に対して第２の監視間隔５０８の間に（即ち、第２の終了日５１０の前に）生成する。しかし、第２の終了日５１０より前に第２の監視間隔５０８の承認日が受信されないため、監視間隔トラッカ２２２は、第２の監視間隔５０８の間にＤＯＳ基準を満たす第２の承認日７１６が発生するまで、第２の監視間隔５０８の間隔延長５１４を生成する。このため、監視間隔トラッカ２２２は、第２の監視間隔５０８の第２の承認日７１６（即ち、延長された終了日５１６）として第２のＤＯＳを生成し、間隔延長５１４の前の第２の監視間隔５０８と同じ長さの時間長を有し得る第３の監視間隔７１８を生成する。

図８は、１つ又は複数のＤＯＳ、間隔延長及び／又は新たな監視間隔を生成するために、日ごと承認ロール規則を使用して監視間隔トラッカ２２２によって実施される動作を示す２つの例示的なタイムライン図を示す。例えば、第１の例示的なシナリオ８００では、監視間隔トラッカ２２２は、第１の監視間隔５０２を生成してもよい。第１の送信データ５０４、第１の送信の第１の診療記録レポート７０８及び第１の診療記録レポート７０８の第１の承認日７１０が第１の監視間隔５０２の間に（即ち、第１の監視間隔５０２の終了日５０６より前に）生成されるため、「成功」が発生する。このほか、第２の送信データ７１２、第３の送信データ８０２及び（例えば、第２の送信データ７１２又は第３の送信データ８０２のための）第２の診療記録レポート７１４は、終了日５０６より前の第１の監視間隔５０２の間に発生する場合がある。第２の診療記録レポート７１４には、第１の監視間隔内に（即ち、終了日５０６より前に）第２の承認日７１６が欠けている場合がある。しかし、少なくとも第１の送信データ５０４に関してＤＯＳ基準が満たされているため、ＤＯＳは、第２の承認日７１６が第１の監視間隔５０２内に発生しないことに関係なく、第１の監視間隔５０２に対して間隔延長なしの終了日５０６に生成される。第２の承認日７１６は、第２の監視間隔５０８内に発生する可能性があるが、第２の承認日７１６は、以前の第１の監視間隔５０２での第２の診療記録レポート７１４に対するものであるため、第２の承認日７１６は第２の監視間隔５０８のＤＯＳを起動しないことになる（第２の承認日７１６だけでは、第２の監視間隔５０８での対応する送信データ又は診療記録レポートのない状態で、第２の監視間隔５０８のＤＯＳ基準を満たさない）。第２の例示的なシナリオ８０４では、第１の送信データ５０４、第２の送信データ７１２及び第３の送信データ８０２は、第１の監視間隔５０２の間に受信されてもよい。第１の診療記録レポート７０８は、第１の送信データ５０４に対して生成されてもよく、第２の診療記録レポート７１４は、第３の送信データ８０２に対して生成されてもよい。終了日５０６が発生すると、第１の診療記録レポート７０８及び第２の診療記録レポート７１４に対する承認が未だ受信されていないため、監視間隔トラッカ２２２は、第１の承認日７１０が受信されるまで、日ごとに間隔延長５１４を生成し、ＤＯＳは、第１の承認日７１０（即ち、延長された終了日５０６）として生成される。第２の承認日７１６はこのほか、延長された終了日５１６にも同じように受信される可能性があるが、第１の承認日７１０がすでに第１の監視間隔５０４のＤＯＳ基準を満たしているため、第２の承認日７１６は、第１の監視間隔５０４のＤＯＳ計算に影響を及ぼさない。

図９は、１つ又は複数のＤＯＳ、間隔延長及び／又は新たな監視間隔を生成するために、日ごと承認ロール規則を使用して監視間隔トラッカ２２２によって実施される動作を示す２つの例示的なタイムライン図を示す。例えば、第１の例示的なシナリオ９００では、第１の送信データ５０４及び第１の送信データ５０４に対する第１の診療記録レポート７０８は、第１の監視間隔５０２の間に受信されてもよい。監視間隔トラッカ２２２は、第１の終了日５０６より前の第１の承認日７１０の欠如に基づいて間隔延長５１４を生成してもよい。第２の送信データ７１２及び第３の送信データ８０２は、第１の監視間隔５０２の間隔延長５１４の間に受信されてもよい。第２の診療記録レポート７１４は第２の送信データ７１２に対して生成されてもよく、間隔延長５１４の間に、第３の診療記録レポート９０２を第３の送信データ８０２に対して生成してもよい。間隔延長５１４は、第１の承認日７１０が受信され、ＤＯＳが第１の承認日７１０（即ち、延長された終了日５０６）として生成されるまで、第１の監視間隔を日ごとに延長してもよい。第２の診療記録レポート７１４の第２の承認日７１６及び第３の診療記録レポート９０２の第３の承認日９０４は、第２の監視間隔５０８の間に発生する可能性がある。さらに、第４の送信データ９０６及び第４の診療記録レポート９０８は、第２の監視間隔５０８の間に発生する可能性がある。しかし、第２の承認日７１６及び第３の承認日９０４が（第２の監視間隔５０８の間に発生した）第４の送信データ９０６又は第４の診療記録レポート９０８に対応していないが、（第１の監視間隔５０２の間及び／又は第１の監視間隔の間隔延長５１４の間に発生した）第２の診療記録レポート７１４及び第３の診療記録レポート９０２に対応しているため、第２の監視間隔５０８のＤＯＳ基準が未だ満たされていない。日ごと承認ロール規則によれば、以前の監視間隔で発生する診療記録の承認日及び／又は送信日が、現在の監視間隔のＤＯＳ基準を満たしていない。第２の例示的なシナリオ９１０では、第１の送信データ５０４及び第１の送信データ５０４に対する第１の診療記録レポート７０８は、第１の監視間隔５０４の間に受信されてもよい。監視間隔トラッカ２２２は、第１の終了日５０６より前の第１の承認日７１０の欠如に基づいて間隔延長５１４を生成してもよい。第２の送信データ７１２は、間隔延長５１４の間に発生する可能性がある。第１の承認日７１０は、第１の監視間隔５０２のＤＯＳ基準を満たし得る延長された終了日５１６に発生し、監視間隔トラッカに第１の監視間隔５０２のＤＯＳを生成させ、第２の監視間隔５０８を生成してもよい。第２の送信データ７１２は報告診療記録又は承認を受信していない可能性があるが、ＤＯＳ基準は第１の送信データ５０４、第１の診療記録レポート７０８及び第１の承認７０４によって既に満たされているため、第１の監視間隔に対するＤＯＳに影響を及ぼさないことになる。第３の送信データ８０２は、第２の監視間隔５０８の間に受信されてもよく、第２の診療記録レポート７１４は、第２の監視間隔５０８の間に生成されてもよく、第２の監視間隔５０８の第３の送信データ８０２のほか、（第１の監視間隔５０２の間に診療記録レポートを受信しなかった）第１の監視間隔の第２の送信データ７１２に対応してもよい。第２の診療記録レポート７１４の第２の承認日７１６は、第２の監視間隔のＤＯＳ基準を満たし、ＤＯＳを終了日５１０として生成させる第２の監視間隔５０８の間に発生してもよい。

図１０は、１つ又は複数のＤＯＳ、間隔延長及び／又は新たな監視間隔を生成するために、日ごと承認ロール規則を使用して監視間隔トラッカ２２２によって実施される動作を示す２つの例示的なタイムライン図を示す。例えば、第１の例示的なシナリオ１０００では、第１の送信データ５０４、第１の送信データ５０４に対する第１の診療記録レポート７０８及び第１の承認日７１０は、第１の監視間隔５０２の間に受信されてもよい。第２の送信データ７１２及び第２の診療記録レポート７１４はこのほか、第１の監視間隔５０２の間に受信されてもよいが、第１の監視間隔内に第２の承認日７１６を受信しなくてもよい。しかし、第１の送信データ５０４、第１の診療記録レポート７０８及び第１の承認日７１０がＤＯＳ基準を満たしているため、第１の監視間隔５０２は延長されず、ＤＯＳは第１の終了日５０６として生成される。第２の送信データ７１２及び第２の診療記録レポート７１４は、第１の監視間隔に影響を及ぼさない。第２の診療記録レポート７１４に対する第２の承認７１６は、第２の監視間隔５０８の間に受信されてもよい。さらに、第３の送信データ８０２、第４の送信データ９０６及び第３の送信データ８０２及び／又は第４の送信データ９０６に対する第３の診療記録レポート９０２は、第２の監視間隔５０８の間に受信されてもよい。しかし、第２の終了日５１０が発生すると、監視間隔トラッカ２２２は、（第２の監視間隔５０８の間に発生した）第２の承認日７１６が、第２の監視間隔５０８で同じく発生した送信データ又は診療記録レポート（例えば、第３の送信データ８０２、第４の送信データ９０６又は第３の診療記録レポート９０２）に対応しないため、承認日が受信されるまで、第２の監視間隔５０８の間隔延長５１４を日ごとに生成することになる。むしろ、第２の承認日７１６は、以前の第１の監視間隔５０２からの第２の診療記録レポート７１４に対応する。第２の監視間隔５０８ではＤＯＳ基準が満たされていない。第２の例示的なシナリオ１００２では、第１の送信データ５０４及び第１の送信データ５０４に関する第１の診療記録レポート７０８は、第１の監視間隔５０２の間に受信されてもよい。ＤＯＳ基準が満たされ、監視間隔トラッカ２２２は、ＤＯＳを、第１の終了日５０６であるとして生成し、第１の監視間隔５０２の後に有効となる第２の監視間隔５０８を生成する。第２の監視間隔５０８は、第１の監視間隔５０２の時間長と同じ時間長を規定する第２の終了日５１０を有する。第２の送信データ７１２、第３の送信データ８０２及び第４の送信データ９０６は、第２の監視間隔５０８の間に受信される。第２の送信データ７１２に関する第２の診療記録レポート７１４及び第２の診療記録レポート７１４に関する第２の承認日７１６はこのほか、第２の監視間隔５０８の間に受信され、第２の監視間隔５０８に関するＤＯＳ基準を満たしている。第３の診療記録レポート９０２は、第３の送信データ８０２又は第４の送信データ９０６について受信されてもよいが、第３の診療記録の第３の承認日９０４は、第２の監視間隔５０８の第２の終了日５１０より前に受信されない可能性がある。それにもかかわらず、監視間隔トラッカ２２２は、第２の承認日７１６、第２の診療記録レポート７１４及び第２の送信データ７１２によって以前に満たされていたＤＯＳ基準に基づいて、第２の終了日５１０としてＤＯＳを生成してもよい。第３の承認日９０４は、第３の監視間隔７１８の間に受信される可能性があるが、第３の承認日９０４は、以前の監視間隔からの診療記録レポート（例えば、第３の診療記録レポート９０２）に対応するため、第３の監視間隔７１８のＤＯＳ基準とは考えられないことになる。それにもかかわらず、第５の送信データ１００２、第５の送信データ１００２に関する第４の診療記録レポート１００４及び第４の診療記録レポート１００４に関する第４の承認日１００６は、第３の監視間隔７１８の間に依然として生成されてもよく、その結果、ＤＯＳ基準が第３の監視間隔７１８では満たされ、間隔の延長は必要なく、第３の監視間隔７１８のＤＯＳは、第３の監視間隔の第３の終了日１００８として生成される。第３の監視間隔７１８のＤＯＳを生成すると、監視間隔トラッカ２２２はこのほか、第４の監視間隔１０１０を生成してもよい。第４の監視間隔では、第６の送信データ１０１２と、第６の送信データ１０１２に関する第５の診療記録レポート１０１４とを受信してもよい。第４の監視間隔１０１０の第４の終了日は、第５の診療記録レポート１０１４に対応する承認日を受信することなく発生する可能性があるため、監視間隔トラッカ２２２は、日ごと承認ロール規則に従って、第５の診療記録レポート１０１４の承認日が受信され、ＤＯＳ基準が第４の監視間隔１０１０に対して満たされるまで、第４の監視間隔１０１０に対して日ごとに間隔延長５１４を生成してもよい。

図１１は、１つ又は複数のＤＯＳ、間隔延長及び／又は新たな監視間隔を生成するために、日ごと承認ロール規則を使用して監視間隔トラッカ２２２によって実施される動作を示す例示的なタイムライン図を示す。例えば、例示的なシナリオ１１００では、第１の送信データ５０４及び第１の送信データ５０４に関する第１の診療記録レポート７０８は、第１の監視間隔の間に受信される。しかし、ＤＯＳ基準は第１の終了日５０６の発生時に満たされないため、監視間隔トラッカ２２２は、第１の承認日７１０が受信されるまで第１の監視間隔５０２への間隔延長５１４を生成する。ＤＯＳは、第１の監視間隔５０２に対して第１の承認日（即ち、延長された終了日５１６）として生成され、第２の監視間隔５０８が生成され、第１の承認日７１０は第１の監視間隔５０２の間に受信されてもよい。第２の監視間隔５０８の間に、監視間隔トラッカ２２２は、第２の送信データ７１２、第３の送信データ８０２及び第２の送信データ７１２及び／又は第３の送信データ８０２に関する第３の診療記録レポート９０２を受信してもよい。第２の監視間隔５０８の第２の終了日５１０が発生すると、第２の診療記録レポート７１４及び第３の診療記録レポート９０２の承認日が未だ受信されていないことになるため、監視間隔トラッカは、第２の監視間隔５０８に対する第２の間隔延長１１０２を生成し、第２の承認日７１６が受信されるまで第２の監視間隔を日ごとに延長する。第２の承認日７１６を受信すると、監視間隔トラッカは、第２の監視間隔のＤＯＳ基準が満たされていると判定し、第２の承認日７１６としてＤＯＳを生成する。第３の診療記録レポート９０２の第３の承認日９０４はこのほか、第２の承認日７１６に受信される場合があるが、第３の承認日及び第３の診療記録レポートは、第２の監視間隔５０８のＤＯＳ基準が、第２の承認日７１６、第２の診療記録レポート７１４及び第２の送信データ７１２によってすでに満たされているため、第２の監視間隔５０８のＤＯＳに影響を及ぼさない。第２の監視間隔５０８のＤＯＳの生成に応答して、監視間隔トラッカ２２は、患者ケア様式規則によって判定された時間長を有する第３の監視間隔７１８を生成する。

いくつかの例では、図５～図１１に示す例示的なシナリオのいずれもが、異なる患者ケア様式の異なる監視間隔を同時に表すために、他の例示的なシナリオと同時に実施されてもよい。例えば、第１の例示的なシナリオ７００は心不全ケア様式を表す場合がある一方、第２の例示的なシナリオ７０６は遠隔監視治療様式を表す場合がある。そのため、第１の例示的なシナリオ７００の監視間隔は３１日の時間長を有する場合がある一方、第２の例示的なシナリオ７０６の監視間隔は９１日の時間長を有する場合がある。単一の送信データ（例えば、第１の送信データ５０４）が、各種類の患者ケア様式の各監視間隔など、複数の同時に実施される監視間隔に含まれてもよい。第１の送信データ５０４が受信された時点で、異なる患者ケア様式に対して別個の診療記録作成レポート及び承認日が必要となる場合があり、その結果、同時に実施されている両方の監視間隔が同じ送信データを追跡しているにもかかわらず、１つの患者ケア様式（例えば、心不全ケア様式）のＤＯＳ基準が満たされ得るが、別の患者ケア様式（例えば、遠隔監視ケア様式）のＤＯＳ基準が満たされない場合がある。異なる時間長を有する異なる患者ケア様式を互いに独立して追跡する能力により、単一の心臓監視装置からの１回の送信データに対して、患者ケアの追跡、患者の追跡管理及び監視間隔の欠落及び追跡管理の失敗の低減の効率が大幅に向上する。特に、それぞれが独自の伝送速度及び異なる患者ケア様式の組み合わせを有する、数百又は数千の異なる心臓監視装置を備えた数百又は数千の異なる患者を管理するためにシステムが拡大される場合に、大幅に向上する。

図１２は、心臓監視装置を管理するために、例えば、上記で考察したように、１つ又は複数のＤＯＳ、間隔延長及び／又は新たな監視間隔を生成するために、監視間隔トラッカ２２２によって実施される動作の例示的なフローチャートを示す。監視間隔トラッカ２２２は、心臓監視装置からの送信を表す着信送信データ１２０２を受信してもよい。監視間隔トラッカ２２２は、送信データ１２０２の受信日を示す受信日タイムスタンプを受信するか生成してもよい。監視間隔トラッカ２２２は、（例えば、着信送信データからの患者識別子、心臓装置識別子又は他の情報を、１つ又は複数のデータベースに保存されている情報と比較することによって）送信データ１２０２を１つ又は複数の患者ケア様式規則、例えば、院内ケア様式１２０４、遠隔監視ケア様式１２０６及び／又は心不全ケア様式１２０８に分類してもよい。着信送信データ１２０２が遠隔監視治療様式１２０６及び／又は心不全治療様式１２０８に対応する場合、監視間隔トラッカ２２２は、受信日が心臓監視装置に関連する（例えば、１つ又は複数のデータベース１１０に保存されている関連付け）埋め込み日から１０日後又は３０日後よりも後であるかを計算してもよい。「いいえ」の場合、監視間隔トラッカ２２２は、何もしない（即ち、送信データに対する応答の生成を省略する）と判定してもよいが、着信送信データ１２０２が遠隔監視ケア様式１２０６及び「間隔ごと」延長規則（例えば、間隔ごと送信ロール規則）にさらに対応する場合には、監視間隔トラッカ２２２は、新たな終了日（例えば、予測ＤＯＳ）を有する新たな監視間隔を生成することを判定してもよい。監視間隔トラッカが、受信日が埋め込み日から１０日又は３０日よりも後であると計算した場合、監視間隔トラッカ２２２は、「今日」（即ち、受信日）が終了日（例えば、監視間隔の予測ＤＯＳ）よりも後かどうかの計算を開始してもよい。同じように、送信データ１２０２が院内ケア様式１２０４の下に分類される場合、監視間隔トラッカ２２２は、「今日」（即ち、受信日）が終了日（例えば、監視間隔の予測ＤＯＳ）よりも後かどうかの計算に直接進んでもよい。「いいえ」の場合、監視間隔トラッカ２２２は、何もしない（即ち、送信データに対する応答の生成を省略する）と判定してもよいが、着信送信データ１２０２が遠隔監視ケア様式１２０６及び「間隔ごと」延長規則（例えば、間隔ごと送信ロール規則）にさらに対応する場合には、監視間隔トラッカ２２２は、新たな終了日（例えば、予測ＤＯＳ）を有する新たな監視間隔を生成することを判定してもよい。「はい」の場合、即ち、監視間隔トラッカ２２２が「今日」（即ち、受信日）が実際に終了日（例えば、監視間隔の予測ＤＯＳ）よりも後であると計算した場合、監視間隔トラッカは、それに応じて、監視間隔の間隔延長規則４０４にアクセスしたり、及び／又は同規則を使用したりしてもよい。監視間隔トラッカ２２２が「日ごと」延長規則（例えば、日ごと送信ロール規則又は日ごと承認ロール規則）にアクセスしたり、及び／又は同規則を使用したりする場合、監視間隔トラッカ２２２は、現在の監視間隔のＤＯＳ基準が満たされているかの判定に進んでもよく、「はい」の場合、現在の監視間隔の以前のＤＯＳに、患者ケア様式規則（例えば、院内ケア様式１２０４については１年、遠隔監視ケア様式１２０６については９１日及び／又は心不全ケア様式１２０８については３１日）に基づく時間長を加えた新たな終了日（例えば、予測ＤＯＳ）を有する新たな監視間隔を生成する。「いいえ」の場合、即ち、監視間隔トラッカ２２２が、「日ごと」規則を使用している間にＤＯＳ基準が満たされていないと判定した場合、監視間隔トラッカ２２２は、ＤＯＳ基準が満たされるまで現在の監視間隔を日ごとに延長し続けてもよい。監視間隔トラッカ２２２が「間隔ごと」規則にアクセスし、同規則を使用する場合、監視間隔は、「今日」（即ち、受信日）に患者ケア様式規則（例えば、院内ケア様式１２０４については１年、遠隔監視ケア様式１２０６については９１日及び／又は心不全ケア様式１２０８については３１日）に基づく時間長を加算した新たな監視間隔に対する新たな終了日（例えば、予測ＤＯＳ）を計算することによって、新たな監視間隔を生成してもよい。監視間隔トラッカ２２２がＤＯＳ基準が満たされていると判定した場合、監視間隔トラッカ２２２は、「今日」（即ち、受信日）である、現在の監視に対するＤＯＳをさらに生成してもよい。いくつかの例では、第１の診療記録が監視間隔に対して承認された時点で、同じ監視間隔内の後続の任意の診療記録を含む、監視間隔内の全診療記録に対してＤＯＳが生成されてもよい。

場合によっては、監視間隔トラッカ２２２によって実施される計算が、監視間隔の１つ又は複数の状態を判定したり、及び／又は（例えば、以下でさらに詳細に考察するように、監視間隔ビジュアライザ４１０及び／又は送信ダッシュボード４１２を介して報告したり、及び／又は視覚化したりするために）その状態を監視間隔に関連付けたりしてもよい。例えば、遠隔監視ケア様式１２０６の監視間隔を、送信が必要な状態（監視間隔の間に送信データが受信されない場合）、診療記録レポートが必要な状態（監視間隔の間に診療記録レポートが生成されない場合）、承認が必要な状態（監視間隔の間に受信した診療記録レポートに対する承認がない場合）又は満たされている状態（ＤＯＳ基準が満たされている場合）を含む１つ又は複数の状態に関連付けてもよい。心不全ケア様式１２０８の監視間隔を、送信が必要な状態（監視間隔の間に送信データが受信されない場合）、所感が必要な状態（送信データに対する所感が受信されない場合）、診療記録レポートが必要な状態（監視間隔の間に診療記録レポートが生成されなかった場合）、承認が必要な場合（監視間隔の間に受信した診療記録レポートに対する承認がなかった場合）又は満たされた状態（ＤＯＳ基準が満たされた場合）を含む１つ又は複数の状態に関連付けてもよい。院内ケア様式１２０４の監視間隔を、通院が必要な状態（監視間隔の間の通院から送信データを受信しなかった場合）、診療記録レポートが必要な状態（監視間隔の間に診療記録レポートが生成されなかった場合）、承認が必要な状態（監視間隔の間に受信した診療記録レポートに対する承認がない場合）又は満たされている状態（ＤＯＳ基準が満たされている場合）を含む１つ又は複数の状態に関連付けてもよい。

ここで図１３～図１９を参照すると、心臓監視装置から医療装置プラットフォーム２０４にて受信されたり、及び／又は監視間隔トラッカ２２２によって生成されたりした情報及びデータにアクセスするか、情報及びデータを分析するか、観察するか、他の方法で管理するためのポータル又はユーザインターフェースのさまざまな例を提供している。ユーザインターフェースは、図１に関連して上述した装置などのユーザ装置１０８上に表示されてもよい。ユーザ装置１０８上に表示されたさまざまなユーザインターフェースは、ユーザ装置によってネットワーク１０６を介してアクセスされ、ネットワーク環境１００の１つ又は複数のサーバ１１２によって実行されてもよい。さらに、1人又は複数人の患者からの１つ又は複数の心臓監視装置及び／又は埋め込み型医療装置などの１つ又は複数の医療装置１０４が、情報又は他の動作データを医療装置マネージャ１０２に提供し、データベース１１０に保存してもよい。例えば、健康水準７（ＨＬ７）プロトコルを利用して、医療装置マネージャ１０２は、機器及び／又は患者固有のデータ及び装置の種類及びモデルの装置分野を含む装置製造業者の遠隔送信からの通信を受信してもよい。次に、この情報は、上記で考察したように、監視間隔トラッカ２２２によってさまざまな方法で処理され、ユーザインターフェースを介してユーザによって提示されても管理されてもよい。このため、ユーザ（診療所の看護師又は医師など）が、これまで利用することができなかった方法で、患者ごとに、あるいは複数の患者にわたって、１つ又は複数の医療装置１０４からデータを受信したり、データにアクセスしたり、データを分析したり、及び／又は管理したりすることができる。

本明細書で説明するように、医療装置マネージャ１０２は、院内の問診と遠隔の問診の両方を含む、ＣＩＥＤ装置の送信及び問診を管理する。一実装例では、院内問診は、医療装置マネージャ１０２によって生成された院内アップロードインターフェースを利用し、このインターフェースを使用して、ユーザが、インポートするために１つ又は複数のファイルをドロップしても選択してもよい。ファイルには、ネットワークを通じて、メモリ（例えば、フラッシュドライブ）などを介してアクセスしてもよい。ファイルが選択された時点で、インターフェースは、医療装置マネージャ１０２が問診データを処理するにつれて、アップロードの進行ステータスの視覚化を生成してもよい。一実装例では、組織内インターフェースが生成され、データ抽出に対応する接触日、患者名、患者の生年月日、診療所名、装置の製造業者、装置の種類、装置のシリアル番号を含むがここに挙げたものに限定されない接触情報を検証するか、追加するか、編集するために使用されてもよい。データが欠落している場合、ユーザは組織内インターフェースを介してデータを入力することができる。医療装置マネージャ１０２は、患者が新規の患者であるか既存の患者であるかを判定し、それに応じて処理を進めてもよい。問診データの処理の進行状況と、手続き、編集又は取り消しのオプションと、医療装置マネージャ１０２へのデータのアップロードの進行状況と、を含む複数の視覚化が、インターフェースを介して提供される。ユーザには、問診から、関連するＰＤＦをアップロードするかを含むオプションがさらに提供される場合がある。処理及びアップロードの間に、データファイルが解析され、解析されたデータファイルから個別データがインポートされる。インポート時に、ユーザはユーザインターフェースを介してインポートされたデータを追加し、編集し、検討することができる。ＰＤＦがインポートされる場合、ＰＤＦは、インポートされたデータと共に提示されるか、インターフェース経由でアクセス可能であってもよい。インポートされたデータは、自動又は手動で保存されてもよい。送信が既存の患者に関連付けられている場合、一連のキー識別子が照合される。患者記録には、院内送信（存在する場合）が院内問診のスタックに追加されることが示されている。遠隔送信のスタックのみが存在する場合、あるいは現在の院内問診スタックが存在しない場合、医療装置マネージャ１０２は新たな診療記録インスタンスを生成する。そのため、医療装置マネージャ１０２は、遠隔の問診とは別個の院内の問診のためのワークフローを生成し、追跡してもよい。そのため、医療装置マネージャ１０２は、院内診療記録及び遠隔診療記録を、院内診療記録が固有のＣＰＴ及びＩＣＤ－１０コードを含んだ状態で、生成してもよい。いくつかの例では、医療装置マネージャ１０２は、患者の院内での問診の検討及び技術者による所感及び医療提供者の承認の痕跡を文書化したレポート（例えば、診療記録）を生成する。このレポートは、患者情報、独自の病歴提示、査読者によって添付された場合には送信されたＰＤＦファイルなどを組み合わせることにより、院内又は遠隔の問診のために医療装置マネージャ１０２によって生成される。レポートは、医療装置マネージャ１０２によってクラウド内で生成され、保存されてもパッケージ化されても、ＰＤＦダウンロードとして利用可能になってもよい。この情報のいずれも、本明細書での動作を実施するために監視間隔トラッカ２２２に送信されてもよい。さらに、監視間隔トラッカ２２２は、動作の出力に基づいて、以下でさらに詳細に考察するように、監視間隔ビジュアライザ４１０及び／又は送信ダッシュボード４１２を生成してもよい。

図１３は、例示的な監視間隔ビジュアライザ４１０を示す。一般に、監視間隔ビジュアライザ４１０は、ユーザの役割（診療所の看護師又は医師、あるいは自身の装置データを分析する患者など）へのユーザ固有のポータルとなり得るデータ及びデータ管理オプションを、複数の監視間隔のグラフ表示として提供する。このため、監視間隔ビジュアライザに表示されるデータ管理オプションは、ユーザインターフェースにアクセスするユーザの役割に応じて変更されても、異なるものであってもよい。医療装置マネージャ１０２は、システムへのアクセス時にユーザによってシステムに提供されるログイン情報に基づいて、監視間隔ビジュアライザ４１０のスタイル及び／又はコンテンツを判定してもよい。以下でさらに詳細に考察する他のインターフェースを、ほぼ同じ識別情報に基づいて特定のユーザが利用できる場合とできない場合がある。

図１３に示す特定の例では、監視間隔ビジュアライザ４１０は、複数のタイムラインを提示するための第１の部分１３０２を含んでもよい。例えば、第１のタイムラインが院内ケア様式１２０４に対応したり、第２のタイムラインが遠隔監視ケア様式１２０６に対応したり、及び／又は第３のタイムラインが心不全ケア様式１２０８に対応したりしてもよい。さらに、送信データの１つ又は複数の受信日を表す第４のタイムラインが第１の部分１３０２に提示されてもよい。監視間隔は、複数のタイムライン上でブロックなどの１つ又は複数の形状として提示されてもよい。グラフィック要素又はアイコンなどの複数の対話型指標及び／又は選択可能な指標を複数のタイムライン上に提示して、送信データをはじめとする送信関連データの受信日を表してもよい。例えば、タイムライン上の四角形が診療記録レポート（例えば、診療記録レポートの作成日）を表してもよく、四角形内のチェックマークが、診療記録レポートが承認されたこと（例えば、承認タイムスタンプに関連付けられたこと）を示してもよい。ブロックは、第１の色がＤＯＳ基準が満たされていることを示したり、及び／又は第２の色がＤＯＳ基準が満たされていないことを示したりするように色分けされてもよい。いくつかの例では、第１の部分１３０２は、複数のタイムラインの横に、１つ又は複数の行動要求指標１３０４を提示してもよい。行動要求指標は、患者ケア様式に対応してもよいため、同じ患者ケア様式に対応するタイムラインと同じ行に存在してもよい。監視間隔トラッカ２２２は、ＤＯＳ基準が満たされているかなど、各タイムラインの現在の監視間隔の状態を判定してもよく、監視間隔トラッカ２２２が特定のＤＯＳ基準が満たされていないと判定した場合、監視間隔の状態を示し、満たされていない特定のＤＯＳ基準に対応する行動要求指標を提示してもよい。例えば、第１の行動要求指標が、特定の患者ケア様式（例えば、心不全ケア様式）に診療記録レポートが必要であることを示してもよい。これに加えて、あるいはこれとは別に、行動要求指標１３０４は、現在の監視間隔に対して送信データが必要であること、現在の監視間隔に対して診療記録レポートの承認が必要であること及び／又は現在の監視間隔に対してＤＯＳ基準が満たされていることを示してもよい。

いくつかの例では、第１の部分１３０２の対話型指標及び／又は選択可能指標は、対話型指標及び／又は選択可能指標をクリックするか、カーソルをその上に置くなどのユーザ入力又は選択に応答して、追加の送信関連情報を提供してもよい。例えば、（例えば、ユーザ装置１０８のディスプレイ上の第１の部分１３０２の下に位置決めされた）第２の部分１３０６が、第１の部分１３０２でのユーザ入力に対応する送信関連情報を提示してもよい。第２の部分１３０６は、特定の監視間隔の選択に応答して、選択された監視間隔に関連付けられた患者名の表示、患者の年齢、患者の生年月日、担当医師の名前及び／又は選択された監視間隔の間に発生した送信の数を含んでもよい。第２の部分１３０６は、選択された監視間隔の送信及び／又は送信日を表す選択可能な送信指標を提示する送信サイドバー１３０８を含んでもよい。選択可能な送信指標にてユーザ入力を受信すると、第２の部分１３０６は、診療記録レポート及び送信に関する過去の所感、患者の記録、心臓監視装置の詳細など、選択可能な送信指標によって表される特定の送信に対応する追加情報を提示してもよい。第２の部分１３０６は、第１の部分１３０２及び／又は送信サイドバー１３０８でのユーザ入力に対応する送信関連情報を表示するための１つ又は複数の表示ウィンドウ１３１０を含んでもよい。場合によっては、第２の部分１３０６は、ＤＯＳ基準が満たされた監視間隔についての完成した診療記録レポートを提示してもよい。いくつかの例では、ＤＯＳ基準が未だ満たされていない監視間隔の選択を受信すると、第２の部分１３０６は、監視間隔内に含まれる送信、所感、計画及び医師の記録を要約する間隔レポートを提示してもよい。患者ケア様式の種類ごとに、即ち、承認を必要とせずに間隔レポートを自動生成してもよい。間隔レポートは、（例えば、心不全診断に関して「安定」ステータス又は「向上」ステータスを示す）診断情報及び／又はどの情報が承認を待っている（例えば、「保留中」ステータスを有している）か、医師から承認を受け取った（例えば、「承認済み」ステータスを有している）かを示してもよい。場合によっては、監視間隔ビジュアライザ４１０は、監視間隔内の診療記録が承認されるまで、監視間隔のＤＯＳ（例えば、予測ＤＯＳ）を表示しない場合がある。他の例では、予測ＤＯＳを表示する場合がある。いくつかの例では、監視間隔は、監視間隔の第１の診療記録が承認されるまで表示されない場合がある。

図１４は、第２の部分１３０６に診療記録積み重ねウィンドウ１４００を有する例示的な監視間隔ビジュアライザ４１０を示す。例えば、特定の送信データの第１部分の選択を受信すると、監視間隔ビジュアライザの第２部分１３０６は、選択された送信データに対応する診療記録積み重ねウィンドウ１４００に複数の診療記録レポートを提示してもよい。例えば、診療記録積み重ねウィンドウは、院内ケア様式１２０４に対応する第１の診療記録、遠隔監視ケア様式１２０６に対応する第２の診療記録レポート及び／又は心不全ケア様式１２０８に対応する第３の診療記録レポートを提示してもよい。複数の診療記録レポートは、複数の診療記録レポートが重なって見えるように、送信サイドバー１３０８の選択可能な送信指標と整列して提示されてもよい。診療記録積み重ねウィンドウ１４００及び／又は送信サイドバー１３０８から特定の診療記録レポートの選択を受信すると、監視間隔ビジュアライザは、選択された診療記録レポートの遮るもののないバージョン又は完全なバージョンを提示してもよい。

図１５は、第１の部分１３０２に提示され得る送信詳細グラフ１５００を含む例示的な監視間隔ビジュアライザ４１０を示す。例えば、選択可能なグラフィック指標は、ユーザ入力を受信すると、選択可能なグラフ化オプションのリストを提示させてもよい。グラフ化オプションは、送信データに含まれるか、送信データに関連する任意の特定の値又は測定基準（例えば、検出値、インピーダンス、パルス振幅、パルス幅、心房細動（ＡＴ）負荷、心房ペーシング、左心室ペーシングなど）を含んでもよい。グラフ化オプションの１つ又は複数の選択を受信すると、監視間隔ビジュアライザ４１０は、グラフ（例えば、折れ線グラフ、棒グラフなど）を第１の部分１３０２上に（例えば、タイムラインの代わりに）、各送信によって定義されたデータポイントを伴って配置させてもよい。監視間隔トラッカ２２２は、（例えば、各送信に関連付けられたタイムスタンプ及び／又は識別子に基づいて）送信データベースに保存されたデータにアクセスして、送信詳細グラフ１５００を生成してもよい。

図１６は、監視間隔トラッカ２２２のためのパラメータを生成するための例示的な監視間隔設定インターフェース１６００を示す。監視間隔設定インターフェース１６００は、パラメータを生成するため、及び／又は患者ケア様式規則４０２及び／又は間隔延長規則４０４のいずれを特定の送信データに使用するかを示すための１つ又は複数の入力フィールド又は選択可能アイコンを提示してもよい。監視間隔設定インターフェース１６００によって生成されたパラメータは、場合によっては、特定の患者名又は識別子あるいは特定の心臓監視装置識別子に関連付けられ、送信データベース４０８に保存されてもよい。送信データが受信されると、送信データに含まれた患者名又は識別子あるいは心臓監視装置識別子を、送信データベース４０８に保存されているものと照合することができ、関連するパラメータを読み出して送信データに適用してもよい。いくつかの例では、監視間隔設定インターフェース１６００は、第１のセクション１６０２にて、この種類の患者ケア様式に対するオプトイン又はオプトアウト、間隔長さ（例えば、９１日又は別の間隔長さ）、初期監視間隔の初期予測ＤＯＳ（例えば、終了日）及び／又は間隔延長規則４０４が間隔ごとの規則であるか、日ごとの規則であるか、などの遠隔監視ケア様式１２０６に関連する情報を受信してもよい。監視間隔設定インターフェース１６００は、第２のセクション１６０４にて、この種の患者ケア様式に対するオプトイン又はオプトアウト、間隔長さ（例えば、３１日又は別の間隔長さ）、初期監視間隔の初期予測ＤＯＳ（例えば、終了日）、間隔延長規則４０４が間隔ごとの規則であるか、日ごとの規則であるか、及び／又は患者ケアに関連する国際疾病分類（ＩＣＤ）－１０コードなどの心不全監視ケア様式１２０８に関連する情報を受信してもよい。監視間隔設定インターフェース１６００は、第３のセクション１６０６にて、この種の患者ケア様式に対するオプトイン又はオプトアウト、間隔長さ（例えば、３６５日又は別の間隔長さ）及び初期監視間隔の終了日などの院内ケア様式１２０４に関連する情報を受信してもよい。いくつかの例では、監視間隔設定インターフェース１６００は、任意の間隔長さ、初期間隔監視期間、初期ＤＯＳ、将来のＤＯＳ、間隔延長規則及び／又はＩＣＤ－１０コードを有する新たな設定可能な患者ケア様式を生成し、設定可能な患者ケア様式を患者に関連付けられた送信データベース４０８に追加するための対話型コンポーネントを含んでもよい。監視間隔設定インターフェース１６００は、患者のグループ及び／又は装置タイプのクラスを選択し、選択された患者のグループ及び／又は装置タイプのクラスに特定の規則、設定及びパラメータを適用するためのオプションを含んでもよい。いくつかの例では、監視間隔設定インターフェース１６００は、患者が診療所を変更する（例えば、第１の診療所から第２の診療所まで移動する）ことに応答して、患者の患者ケア様式規則４０２及び／又は間隔延長規則４０４を変更するためのオプションを提示してもよい。

図１７は、送信データベース４０８から特定の診療所の送信関連データを集約し、特定の診療所の１つ又は複数の送信メトリクスを生成し、特定の診療所のユーザ装置１０８上に送信メトリクスを提示するための例示的な送信ダッシュボード４１２を示す。例えば、送信ダッシュボード４１２は、送信メトリクスがどの診療現場に関連することになるか、送信メトリクスがどの患者ケア様式に関連することになるかを示す１つ又は複数の対話型グラフィック要素にて入力を受信してもよい。送信メトリクスは、第１のセクション１７００にて提示されてもよく、選択された患者ケア様式についての送信を必要とする現在有効な監視間隔の数、選択された患者ケア様式についての診療記録レポートを必要とする送信の数、選択された患者ケア様式の承認が必要な診療記録レポートの数、選択された患者ケア様式の全ＤＯＳ基準を満たした現在有効な監視間隔の数、選択された患者ケア様式にオプトインした患者の数、選択された患者ケア様式からオプトアウトした患者の数及び選択された患者ケア様式に必要なＤＯＳの数の表示を含んでもよい。いくつかの例では、送信メトリクスは、送信メトリックにて選択又はユーザ入力を受信すると、選択された送信メトリックに対応する患者のリスト（例えば、送信が必要な患者、診療記録レポートが必要な患者など）及び／又は患者のリストに関連する追加情報など、選択された送信メトリックに関連する追加の詳細が送信ダッシュボードの第１のセクション１７００の下の第２のセクション１７０２に提示されるように、対話型グラフ指標を含んでもよい。場合によっては、送信メトリクスは、現在有効な監視間隔の課金要件（例えば、ＤＯＳ基準）を満たすために必要な送信メトリクスを示す第１の色と、現在有効な監視間隔の課金要件を満たしている（例えば、第２のセクション１７０２に列挙された）患者を示す第２の色とで色分けされてもよい。

図１８は、送信データベース４０８から特定の診療所の送信関連データを集約し、特定の診療所の１つ又は複数の送信メトリクスを生成し、特定の診療所のユーザ装置１０８上に送信メトリクスを提示するための例示的な送信ダッシュボード４１２を示す。送信ダッシュボード４１２は、診療所が、現在有効な監視間隔についてのＤＯＳ基準を満たすために必要なステップと、特定の診療所が監視コンプライアンスに関する全体的な追跡方法と、課金基準を満たした患者と、を確認し、理解するのに役立ってもよい。送信メトリクスは、（例えば、複数の送信に関連付けられた共通の診療所識別子に基づいて）患者ケア様式の種類ごとのほか、診療所ごと、（例えば、ドロップダウンメニュー、テキストフィールド、選択可能なアイコン、スライドバーなどの１つ又は複数の対話型グラフィック要素でのユーザ入力を介して）現場ごと、装置タイプごと及びサービスの日付ごとに並べ替えられてもよい。送信メトリクスは、経過するか延長されたＤＯＳの数、（任意の患者ケア様式ラッキングにオプトインされていない患者を含む）ＤＯＳなしの患者の数、１０日以内に必要な行動の数、１１日以降に必要な行動の数及び／又はＤＯＳ基準が満たされており、ＤＯＳが発生するのを待っている監視間隔の数の表示のうちの１つ又は複数が含まれてもよい。さらに、送信ダッシュボードは、予測ＤＯＳ（例えば、終了日）までの日数ごと、ステータス（例えば、ＤＯＳ基準を満たしている、診療記録レポートの承認が必要、診療記録レポートなし、ＤＯＳなし、送信なし及び／又はＤＯＳの経過又は延長）ごと、及び／又は患者名の入力ごとに分類された患者のリストを生成するための患者フィルタリングを提供してもよい。

図１９は、監視間隔トラッカ２２２によって生成され得る課金レポートダッシュボード１９００を示す。課金レポートダッシュボードは、診療記録レポートのない監視間隔の数、承認が必要な診療記録レポートのある監視間隔の数及び／又はＤＯＳ基準が満たされているため課金可能な監視間隔である監視間隔の数など、ＤＯＳ基準に関連する１つ又は複数の送信メトリクスを提示してもよい。課金レポートダッシュボード１９００は、ＤＯＳ基準に関連する送信メトリクスの根拠であるユーザ入力（例えば、診療所、現場、装置タイプ、患者ケア様式、開始日及び／又は終了日）を受信するための１つ又は複数の対話型フィルタを提示する第１のセクション１９０２を含んでもよい。第１のセクション１９０２は、ＤＯＳ基準に関連する送信メトリクスを対話型指標（例えば、選択可能なブロック）として提示してもよく、対話型指標は、選択されると、第１のセクションの下の第２のセクション１９０４に送信メトリックに関連する追加情報を提示する。例えば、課金可能な監視間隔指標にてユーザ入力を受信すると、第２のセクションは、診療所名、患者名、ＤＯＳ、患者ケア様式、ステータス、一致する日付及び／又は第１の承認日など、監視間隔に関連する追加情報を含む監視間隔のリストを提示してもよい。課金レポートダッシュボードは、入力を受信すると、患者の監視間隔が現在課金可能であるか、患者の監視間隔を課金可能にするようにＤＯＳ基準を満たすために必要な行動は何かを示すために、送信メトリクスを（例えば、ダウンロード可能、送信可能及び／又は印刷可能な）１つ又は複数の課金レポートに変換するための１つ又は複数の対話型要素を提示してもよい。課金レポートを毎週生成しても、課金可能なレポートを生成する頻度を選択するユーザ入力に基づいて生成してもよい。課金レポートのデータ（例えば、送信メトリクス）は、ダウンロード可能なスプレッドシートとして生成されてもよい。課金レポートは、患者の名前、生年月日、医療記録番号（ＭＲＮ）、装置のタイプ、装置のモデル、装置の埋め込み日、監視間隔の開始日と終了日、患者ケア様式（例えば、院内ケア様式１２０４、遠隔監視ケア様式１２０６及び／又は心不全ケア様式１２０８）の種類へのオプトイン、医療提供者の承認、承認日、専門的及び技術的なＣＰＴコード及び／又はＩＣＤ－１０コードを含むダウンロード可能なレポートであってもよい。場合によっては、課金レポートジェネレータが、本明細書で考察した変数の多くを考慮に入れてもよく、患者名を課金レポートに表示するためにＤＯＳ基準が満たされていることを確認してもよい。これにより、患者ごとの監視間隔ごとに１つの課金レポートのみが生成され、診療所がそのような関連データの追跡に費やす時間が削減される。いくつかの例では、監視間隔の第１の承認日を（その後の承認日ではなく）ＤＯＳ基準を満たすものとして認識することにより、その監視間隔の課金要件が満たされていることを知るためのコンプライアンスの追加保証が提供される。課金レポートダッシュボード１９００は、（例えば、監視間隔のＤＯＳ基準は満たされているという）コンプライアンスを確保するために診療所がとることのできる実践及び／又は遡及的行動を示す課金レポート及び／又は患者ケアレポートなど、（例えば、送信メトリクスを示す）１つ又は複数のレポートを出力してもよい。

いくつかの例では、監視間隔ビジュアライザ４１０、送信ダッシュボード４１２及び／又は課金レポートダッシュボードを生成するために監視間隔トラッカ２２２によって実施される動作が、データ傾向、完了し保留中のケアのレベル及び複雑なデータとパラメータを潜在的に何百万もの独自の組み合わせに単純化することができるグラフィカルインターフェースのワークフロー行動を視覚化する結果となってもよい。このほか、視覚化を生成すると、現在有効な監視間隔のＤＯＳ基準を満たすためにどのような行動を実施する必要があるかを、患者ケア様式の種類ごとに記述する「コンプライアンスＴｏ－Ｄｏリスト」が提供される場合がある。

監視間隔トラッカ２２２、監視間隔ビジュアライザ４１０、送信ダッシュボード４１２及び／又は医療装置プラットフォーム２０４の他のコンポーネントのさまざまな非限定的で例示的な実施形態について、以下で考察する。

場合によっては、心臓監視装置を管理する方法には、心臓監視装置に関連付けられた監視間隔を判定するステップと、１つ又は複数の患者ケアモードに対応する１つ又は複数のタイムライン上の監視間隔を表すブロックをディスプレイに提示するステップと、心臓監視装置から発信される送信データにアクセスするステップと、１つ又は複数のタイムラインに、送信データの受信日を表す送信アイコンと、送信データに対応する診療記録アイコンとを含む１つ又は複数のアイコンを提示するステップと、診療記録アイコンに関連付けられた診療記録レポートの承認日を少なくとも示す１つ又は複数の入力を受信するステップと、受信日、１つ又は複数の患者ケアモード及び承認日に少なくとも部分的に基づいて、送信データに対する業務の日付（ＤＯＳ）を判定するステップと、を含んでもよい。

さらに、１つ又は複数のタイムラインは、ディスプレイに同時に提示され、水平に延びる複数のタイムラインを含んでもよい。複数のタイムラインは、１つ又は複数の患者ケアモードのうちの院内ケアモードに対応する第１のタイムラインと、１つ又は複数の患者ケアモードのうちの心不全ケアモードに対応する第２のタイムラインと、１つ又は複数の患者ケアモードのうちの遠隔監視ケアモードに対応する第３のタイムラインと、心臓監視装置からの送信に対応する第４のタイムラインと、を含む。

さらに、第１のタイムラインは監視間隔を１つ又は複数の１年ブロックとして表し、第２のタイムラインは監視間隔を１つ又は複数の３１日ブロックとして表し、第３のタイムラインは監視間隔を９１日ブロックとして表してもよい。

さらに、１つ又は複数の入力を受信するステップは、診療記録レポートの所感を提供する第１の入力を受信するステップと、診療記録レポートの承認を提供する第２の入力を受信するステップと、を含んでもよく、１つ又は複数のアイコンは、所感の第１の表示及び承認の第２の表示を含んでもよい。

さらに、この方法は、心臓監視装置に関連付けられた患者を登録するための１つ又は複数の入力要素をディスプレイに提示するステップをさらに備えてもよく、１つ又は複数の入力要素は、１つ又は複数の患者ケアモードのうちの特定の患者ケアモードを示すための第１の選択可能アイコンと、間隔延長規則を示す第２の選択可能アイコンと、監視間隔の長さを示すための第１の入力フィールドと、業務の日付を示す第２の入力フィールドと、のうちの１つ又は複数が含まれる。

さらに、受信日は監視間隔の終了後に発生してもよく、方法は、監視間隔の終了後に発生した受信日に少なくとも部分的に基づき、間隔延長規則に少なくとも部分的に基づいて、監視間隔の延長を生成するステップをさらに含んでもよい。

さらに、方法は、１つ又は複数の患者ケアモードに少なくとも部分的に基づいて、承認が受信されるまで間隔延長規則が監視間隔を日ごとに延長すると判定するステップをさらに含んでもよい。

さらに、ブロックは第１のブロックを含んでもよく、方法は、１つ又は複数の患者ケアモードに少なくとも部分的に基づいて、受信日が監視間隔外のときの監視間隔を表す第１のブロックと同じ長さを有する第２のブロックによって表された延長監視間隔を間隔延長規則が追加すると判定するステップをさらに含んでもよい。

さらに、監視間隔は第１の監視間隔を含んでもよく、送信データは第１の送信データを含んでもよい。方法はさらに、１つ又は複数のタイムラインの横に、第２の監視間隔が第２の送信データを必要としていること、心不全ケアモードに対応する第３の送信データが所感を必要としていること、院内ケアモードに関連する患者が通院を必要としていること、あるいは心不全ケアモード、院内ケアモード又は遠隔監視ケアモードに対応する第４の送信データが診療記録レポートを必要としていること、のうちの少なくとも１つを示す１つ又は複数の行動要求アイコンを提示するステップをさらに含んでもよい。

さらに、方法は、診療記録アイコンの選択を受信するステップと、診療記録アイコンの選択に少なくとも部分的に応答して、送信データに関連付けられた１つ又は複数の診療記録レポートをディスプレイにて１つ又は複数のタイムラインの下に提示するステップと、をさらに含んでもよい。

場合によっては、心臓監視装置を管理する方法には、心臓監視装置に関連付けられた複数の監視間隔を判定するステップと、タイムライン上の複数の監視間隔を表す一連のブロックであって、一連のブロックのうちの１つのブロックは、タイムラインに対応する患者ケアモードに基づく長さを有する、一連のブロックをディスプレイに提示するステップと、心臓監視装置から発信される送信データにアクセスするステップと、タイムラインにて、送信データの受信日を表す送信アイコンと、送信データに対応する診療記録アイコンと、を含む１つ又は複数のアイコンを提示するステップと、受信日、患者ケアモード及び承認日に少なくとも部分的に基づいて、送信データの業務の日付（ＤＯＳ）を判定するステップと、を含んでもよい。

さらに、方法は、複数の監視間隔のうちの１つの監視間隔を表すブロックの選択を受信するステップと、ブロックの選択に少なくとも部分的に応答して、間隔レポートを提示するステップと、をさらに含んでもよい。監視間隔は、完了した監視間隔及び完了した監視間隔に関連する履歴情報を示す間隔レポートであるか、有効な監視間隔及び保留中の必要な承認を示す間隔レポートである。

さらに、方法は、診療所に対して送信レポートを生成するための１つ又は複数の入力要素をディスプレイに提示するステップをさらに備えてもよく、１つ又は複数の入力要素は、ケアモード、診療現場又はＤＯＳまでの日数に対応する。

さらに、方法は、１つ又は複数の入力要素にて入力を受信するステップと、ディスプレイにて、入力に少なくとも部分的に応答して、診療所に対する集約された送信データを表す１つ又は複数の送信関連メトリクスを提示するステップと、をさらに含んでもよい。

さらに、１つ又は複数の送信関連メトリクスは、送信の受信を待機している監視間隔の数、診療記録レポートの受信を待機しているの送信の数、承認を待機している診療記録レポートの数、完了した監視間隔の数、患者ケアモードにオプトインした患者の数、患者ケアモードからオプトアウトした患者の数、ＤＯＳを必要とする監視間隔の数のうちの１つ又は複数をさらに含んでもよい。

さらに、方法は、ディスプレイ上のサイドバーに提示された監視レポートアイコンの選択を受信するステップをさらに含んでもよく、送信レポートを生成するための１つ又は複数の入力要素を提示するステップは、監視レポートアイコンの選択に少なくとも部分的に応答したものである。

さらに、方法は、診療所、診療現場、ケアモード、心臓監視装置の種類、業務の日付、ＤＯＳまでの日数、監視間隔ステータス又は患者名に対応する１つ又は複数のフィルタ入力要素を含むDOS分析ダッシュボードをディスプレイに提示するステップと、１つ又は複数のフィルタ入力要素にて入力を受信するステップと、１つ又は複数のフィルタ入力要素での入力の受信に少なくとも部分的に基づいて、集約されたＤＯＳデータを表す１つ又は複数のＤＯＳ関連メトリクスをディスプレイに提示するステップと、をさらに含んでもよい。

さらに、ＤＯＳ関連メトリクスは、ＤＯＳを通過したか、ＤＯＳの欠如した監視間隔の数、１０日以内に行動が必要な監視間隔の数、１１日以降に行動が必要な監視間隔の数及びＤＯＳ基準を満たした監視間隔の数のうちの１つ又は複数を含んでもよい。

さらに、方法は、診療所、診療現場、心臓監視装置の種類、ケアモード、日付範囲、ＤＯＳ又は患者名に対応する１つ又は複数のフィルタ入力要素を含む、完了した監視間隔に対する課金レポートダッシュボードをディスプレイに提示するステップと、１つ又は複数のフィルタ入力要素にて入力を受信するステップと、１つ又は複数のフィルタ入力要素にて入力を受信するステップに少なくとも部分的に基づいて、診療記録レポートを必要とする監視間隔の数、承認が必要な診療記録レポートの数又は課金の準備ができている監視間隔の数の表示のうちの１つ又は複数をディスプレイに提示するステップと、をさらに含んでもよい。

場合によっては、心臓監視装置を管理する方法には、心臓監視装置に関連付けられた第１の監視間隔であって、第１の患者ケアモードに対応する第１の長さを有する第１の監視間隔を判定するステップと、患者に関連する第２の監視間隔であって、第２の患者ケアモードに対応する第２の長さを有する第２の監視間隔を判定するステップと、第１の監視間隔を、第１の患者ケアモードに対応する第１のタイムライン上の第１のブロックとしてディスプレイに表示し、同時に第２の監視間隔を、第２の患者ケアモードに対応する第２のタイムライン上の第２のブロックとして表示するステップと、心臓監視装置から発信される送信データにアクセスするステップと、送信に対応する第３のタイムラインに、送信データの１つ又は複数の受信日を表す１つ又は複数の送信アイコンを提示するステップと、第１のタイムラインに、送信データに対応する第１の診療記録アイコンを提示するステップと、第２のタイムラインに、送信データに対応する第２の診療記録アイコンを提示するステップと、第１の診療記録アイコン又は第２の診療記録アイコンに関連付けられた診療記録レポートの承認日を少なくとも示す１つ又は複数の入力を受信するステップと、１つ又は複数の受信日及び承認日に少なくとも部分的に基づいて、送信データの業務の日付（ＤＯＳ）を判定するステップと、がさらに含まれてもよい。

図２０を参照すると、本明細書で考察するさまざまなシステム及び方法を実装し得る１つ又は複数の計算ユニットを有する例示的な計算システム２０００の詳細な説明を提供する。計算システム２０００は、医療装置マネージャ１０２及び／又はユーザ計算装置１０８をはじめとする計算装置又はネットワーク装置に適用可能であってもよい。このような装置の特定の実装例が、本明細書でその全部を具体的に考察するわけではないが、当業者には理解されるであろう、異なる可能な特定の計算アーキテクチャであり得ることが理解されよう。

コンピュータシステム２０００は、コンピュータプログラム製品を実行してコンピュータプロセスを実行することができる計算システムであってもよい。データファイル及びプログラムファイルをコンピュータシステム２０００に入力してもよい。コンピュータシステム２０００はファイルを読み取ってその中のプログラムを実行する。１つ又は複数のハードウェアプロセッサ２００２、１つ又は複数のデータ記憶装置２００４、１つ又は複数のメモリ装置２００６及び／又は１つ又は複数のポート２００８～２０１０をはじめとするコンピュータシステム２０００の要素のいくつかを図２０に示す。さらに、当業者には認識されるであろう他の要素を計算システム２０００に含んでもよいが、図２０に明示的に示すことも、本明細書でさらに考察することもない。コンピュータシステム２０００のさまざまな要素が、図２０に明示的に示していない１つ又は複数の通信バス、２地点間通信経路又は他の通信手段を介して互いに通信してもよい。

プロセッサ２００２は、例えば、中央処理装置（ＣＰＵ）、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）及び／又は１つ又は複数の内部レベルのキャッシュを含んでもよい。プロセッサ２００２が、単一の中央処理装置、あるいは一般に並列処理環境と呼ばれる、命令を実施し互いに並行して動作を実施することができる複数の処理装置を備えるように、１つ又は複数のプロセッサ２００２があってもよい。

コンピュータシステム２０００は、従来のコンピュータ、分散コンピュータ、あるいはクラウド計算アーキテクチャを介して利用可能となる１つ又は複数の外部コンピュータなどの任意の他の種類のコンピュータであってもよい。ここで説明している技術は、データ記憶装置２００４に記憶されたり、メモリ装置２００６に記憶されたり、及び／又はポート２００８～２０１０のうちの１つ又は複数を介して通信されたりするソフトウェアに任意に実装され、それによって図２０のコンピュータシステム２０００を、本明細書で説明する動作を実施するための専用マシンに変換する。コンピュータシステム２０００の例には、パーソナルコンピュータ、端末、ワークステーション、携帯電話、タブレット、ラップトップ、パーソナルコンピュータ、マルチメディアコンソール、ゲームコンソール、セットトップボックスなどが挙げられる。

１つ又は複数のデータ記憶装置２００４は、コンピュータプロセスを実施するためのコンピュータ実行可能命令など、計算システム２０００内で生成されるか採用されたデータを記憶可能な任意の不揮発性データ記憶装置を含んでもよい。不揮発性データ記憶装置は、計算システム２０００のさまざまなコンポーネントを管理するアプリケーションプログラムとオペレーティングシステム（ＯＳ）の両方の命令を含んでもよい。データ記憶装置２００４は、磁気ディスクドライブ、光ディスクドライブ、ソリッドステートドライブ（ＳＳＤ）、フラッシュドライブなどを含むが、ここに挙げたものに限定されない。データ記憶装置２００４は、取り外し可能なデータ記憶媒体、取り外し不可能なデータ記憶媒体、及び／又は１つ又は複数のデータベース管理製品、ウェブサーバ製品、アプリケーションサーバ製品及び／又は他の追加のソフトウェアコンポーネントを含むそのようなコンピュータプログラム製品を備えた有線又は無線のネットワークアーキテクチャを介して利用可能にされる外部記憶装置を含んでもよい。取り外し可能なデータ記憶媒体の例には、コンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク読み取り専用メモリ（ＤＶＤ－ＲＯＭ）、光磁気ディスク、フラッシュドライブなどが挙げられる。取り外し不可能なデータ記憶媒体の例には、内蔵磁気ハードディスク、ＳＳＤなどが挙げられる。１つ又は複数のメモリ装置２００６は、揮発性メモリ（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）など）及び／又は不揮発性メモリ（例えば、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリなど）を含んでもよい。

ここで説明した技術によるシステム及び方法を実現する機構を含むコンピュータプログラム製品が、機械可読媒体と呼ばれるデータ記憶装置２００４及び／又はメモリ装置２００６に常駐してもよい。機械可読媒体には、機械によって実行される本開示の動作のうちの１つ又は複数を実施するための命令を保存するか符号化することができるか、そのような命令によって利用されるか、そのような命令に関連付けられたデータ構造及び／又はモジュールを符号化することができる任意の有形の非一時的な媒体が含まれ得ることが理解されよう。機械可読媒体には、１つ又は複数の実行可能な命令又はデータ構造を保存する単一の媒体又は複数の媒体（例えば、集中型又は分散型のデータベース及び／又は関連するキャッシュ及びサーバ）が含まれてもよい。

いくつかの実装例では、コンピュータシステム２０００は、他の計算装置、ネットワーク装置又は車両装置と通信するための入出力（Ｉ／Ｏ）ポート２００８及び通信ポート２０１０などの１つ又は複数のポートを含む。ポート２００８～２０１０は結合されても分離されてもよく、コンピュータシステム２０００に含まれるポートがこれより多くても少なくてもよいことが理解されよう。

Ｉ／Ｏポート２００８は、情報が計算システム２０００に入力されるか、計算システム２０００から出力されるＩ／Ｏ装置又は他の装置に接続されてもよい。そのようなＩ／Ｏ装置には、１つ又は複数の入力装置、出力装置及び／又は環境トランスデューサ装置が含まれるが、ここに挙げたものに限定されない。

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

環境トランスデューサ装置は、Ｉ／Ｏポート２００８を介して計算システム２０００に入出力するために、ある形態のエネルギー又は信号を別の形態に変換する。例えば、計算システム２０００内で生成された電気信号を、別の種類の信号に変換してもよく、及び／又はその逆に変換してもよい。一実装例では、環境トランスデューサ装置は、光、音、温度、圧力、磁場、電場、化学的性質、物理的動き、方向、加速度、重力など、計算装置２０００の近くの環境又は同装置から離れた環境の特徴又は態様を感知する。さらに、環境トランスデューサ装置は、何らかの物体（例えば、機械的アクチュエータ）の物理的な動き、物質の加熱又は冷却、化学物質の添加など、例示的な計算装置２０００の近くの環境又は同装置から離れた環境に何らかの影響を及ぼす信号を生成してもよい。

一実装例では、通信ポート２０１０をネットワークに接続し、ネットワークを介してコンピュータシステム２０００は、本明細書に記載の方法及びシステムを実行するほか、情報及びそれによって判定されるネットワーク構成変更を送信することに有用なネットワークデータを受信してもよい。言い換えれば、通信ポート２０１０は、１つ又は複数の有線又は無線の通信ネットワーク又は接続を介して、コンピュータシステム２０００と他の装置との間で情報を送信したり、及び／又は受信したりするように構成された１つ又は複数の通信インターフェース装置にコンピュータシステム２０００を接続する。そのようなネットワーク又は接続の例には、ユニバーサルシリアルバス（ＵＳＢ）、イーサネット、Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信（ＮＦＣ）、ロングタームエボリューション（ＬＴＥ）などが挙げられるが、ここに挙げたものに限定されない。１つ又は複数のそのような通信インターフェース装置を、通信ポート２０１０を介して、利用して、１つ又は複数の他のマシンと、２地点間通信経路を介して直接通信するか、ワイドエリアネットワーク（ＷＡＮ）（例えば、インターネット）を介して通信するか、ローカルエリアネットワーク（ＬＡＮ）を介して通信するか、セルラー（例えば、第３世代（３Ｇ）又は第４世代（４Ｇ））ネットワークを介して通信するか、別の通信手段を介して通信してもよい。さらに、通信ポート２０１０は、電磁信号の送信及び／又は受信のためのアンテナ又は他のリンクと通信してもよい。

図２０に示すシステムは、本開示の態様に従って採用されるか構成され得るコンピュータシステムの可能な一例にすぎない。ここで開示する技術を計算システム上で実装するためのコンピュータ実行可能命令を保存する他の非一時的な有形のコンピュータ可読記憶媒体が利用され得ることが理解されよう。

本開示では、開示の方法は、装置によって読み取り可能な命令のセット又はソフトウェアとして実装されてもよい。さらに、開示の方法ではステップの特定の順序又は階層は、例示的な手法の一例であることが理解される。設計の好みに基づいて、開示した主題の範囲内に留まりながら、方法のステップの特定の順序又は階層を再配置可能であることが理解される。添付の方法の請求項は、さまざまなステップの要素を見本の順序で提示しており、必ずしも提示した特定の順序又は階層に限定されることを意味するものではない。

記載した開示は、コンピュータシステム（又は他の電子装置）をプログラムして、本開示によるプロセスを実施するために使用され得る命令が保存された非一時的な機械可読媒体を含み得るコンピュータプログラム製品又はソフトウェアとして提供されてもよい。機械可読媒体には、機械（例えば、コンピュータ）によって読み取り可能な形式（例えば、ソフトウェア、処理アプリケーション）で情報を保存するための任意の機構が含まれる。機械可読媒体は、磁気記憶媒体、光記憶媒体、光磁気記憶媒体、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、消去可能なプログラマブルメモリ（例えば、ＥＰＲＯＭ及びＥＥＰＲＯＭ）、フラッシュメモリ又は電子命令を保存するのに適した他の種類の媒体を含むが、ここに挙げたものに限定されない。

本開示をさまざまな実装例を参照して説明してきたが、このような実装例は例示的なものであり、本開示の範囲が実装例に限定されないことが理解されよう。多くの変形、変更、追加及び改良が可能である。さらに一般的には、本開示による実装例を、特定の実装例に関連して説明してきた。機能を、本開示のさまざまな実装例にて異なる形で分離しても、ブロックに結合してもよく、異なる用語で説明してもよい。このような変形、修正、追加及び改良をはじめとする変形、修正、追加及び改良が、特許請求の範囲で定義される本開示の範囲内に含まれる可能性がある。

Claims (20)

1. 心臓監視装置を管理する方法であって、前記方法は、
   規則データベースから患者ケア様式規則にアクセスするステップと、
   前記心臓監視装置に関連する監視間隔を生成するステップであって、前記監視間隔は少なくとも部分的に前記患者ケア様式規則に基づいた終了日を有する、ステップと、
   受信日を有し、前記心臓監視装置から発信された送信データにアクセスするステップと、
   前記受信日が前記終了日より後であるかを計算するステップと、
   前記送信データの診療記録レポートを生成するステップと、
   前記診療記録レポートに対応する承認タイムスタンプを受信するステップと、
   前記承認タイムスタンプが前記終了日より後の承認日を示しているかを計算するステップと、
   規則データベースから間隔延長規則にアクセスするステップと、
   前記間隔延長規則に従って、前記受信日が前記終了日より後か、あるいは前記承認日が前記終了日より後かに少なくとも部分的に基づいて延長された終了日を有する監視間隔延長を生成するステップと、
   前記送信データに対する業務の日付（ＤＯＳ）を生成するステップであって、前記ＤＯＳは、前記監視間隔延長の前記延長された終了日である、ステップと、を含む、方法。
2. 前記受信日が前記終了日より後であるかを計算するステップは、前記終了日の発生時に、前記送信データが未だ受信されていないと判定するステップを含み、
   前記監視間隔延長を生成するステップは、前記延長された終了日に前記送信データが受信されるまで前記監視間隔に対して日ごと延長を生成するステップを含む、請求項１に記載の方法。
3. 前記終了日は、前記監視間隔の初期ＤＯＳ予測であり、前記延長された終了日は、前記監視間隔に対する最終的なＤＯＳである、請求項２に記載の方法。
4. 前記承認日が前記終了日より後であるかを計算するステップは、前記終了日の発生時に、前記承認タイムスタンプが未だ受信されていないと判定するステップを含み、
   前記監視間隔延長を生成するステップは、前記延長された終了日に前記承認タイムスタンプが発生するまで、前記監視間隔に対して日ごと延長を生成するステップを含む、請求項１に記載の方法。
5. 前記監視間隔は第１の監視間隔を含み、前記終了日は第１の終了日を含み、前記方法は、前記延長された終了日に発生する前記承認タイムスタンプに応答して、少なくとも部分的に前記患者ケア様式規則に基づく第２の終了日を有する第２の監視間隔を生成するステップをさらに含む、請求項４に記載の方法。
6. 前記診療記録レポートは第１の診療記録レポートであり、前記患者ケア様式規則は第１の患者ケア様式規則であり、前記承認タイムスタンプは第１の承認タイムスタンプであり、前記ＤＯＳは第１のＤＯＳであり、前記第１の診療記録レポートは第１の患者ケア様式規則に関連付けられる、請求項５に記載の方法であって、前記方法は、
   前記規則データベースから第２の患者ケア様式規則にアクセスするステップと、
   前記送信データの第２の診療記録レポートを生成するステップであって、前記第２の診療記録レポートは第２の患者ケア様式規則に関連付けられる、ステップと、
   前記延長された終了日より後であって、前記第２の終了日より前の承認日を示す第２の承認タイムスタンプを受信するステップと、
   前記第２の承認タイムスタンプが前記第２の診療記録レポートに対応していると判定するステップと、
   前記第２の診療記録レポートに対応する前記第２の承認タイムスタンプに少なくとも部分的に基づいて、第２のＤＯＳを生成しないと判定するステップと、を含む、方法。
7. 前記監視間隔は第１の監視間隔であり、
   前記第１の患者ケア様式規則は、心不全ケア様式に対応し、前記第１の監視間隔が３１日の長さであることを示し、
   前記第２の患者ケア様式規則は、遠隔監視ケア様式に対応し、第２の監視間隔が９１日の長さであることを示し、
   前記第２の監視間隔は、前記第１の監視間隔と同時に有効となる、請求項６に記載の方法。
8. 心臓監視装置を管理する方法であって、前記方法は、
   規則データベースから複数の患者ケア様式規則にアクセスするステップと、
   前記心臓監視装置に関連する第１の監視間隔を生成するステップであって、前記第１の監視間隔は、前記複数の患者ケア様式規則のうちの第１の患者ケア様式規則に少なくとも部分的に基づく第１の終了日を有する、ステップと、
   前記心臓監視装置に関連付けられた第２の監視間隔を生成するステップであって、前記第２の監視間隔は、前記複数の患者ケア様式規則のうちの第２の患者ケア様式規則に少なくとも部分的に基づく第２の終了日を有し、前記第２の終了日は、前記第１の終了日とは異なる、ステップと、
   受信日を有し、前記心臓監視装置から発信された送信データにアクセスするステップと、
   前記送信データに対して、前記第１の患者ケア様式規則に関連付けられた第１の診療記録レポートを生成するステップと、
   前記送信データに対して、前記第２の患者ケア様式規則に関連付けられた第２の診療記録レポートを生成するステップと、
   前記受信日の後に承認タイムスタンプを受信し、前記第１の診療記録レポート又は前記第２の診療記録レポートのいずれか１つのみに対応する承認日を示すステップと、
   前記承認日が前記第１の終了日より後かを計算するステップと、
   前記規則データベースから間隔延長規則にアクセスするステップと、
   前記間隔延長規則に従って、前記承認日が前記第１の終了日より後であるかに少なくとも部分的に基づいた延長された終了日を有する監視間隔延長を生成するかを判定するステップと、
   前記送信データに対して業務の日付（ＤＯＳ）を生成するステップであって、前記ＤＯＳは前記承認日である、ステップと、を含む、方法。
9. 前記承認日が前記第１の終了日より後であるかを計算するステップは、前記第１の終了日の発生時に、前記承認タイムスタンプが未だ受信されていないと判定するステップを含み、
   前記監視間隔延長を生成するステップは、前記延長された終了日に前記承認タイムスタンプが発生するまで、前記第１の監視間隔に対して日ごと延長を生成するステップを含む、請求項８に記載の方法。
10. 前記延長された終了日に発生する前記承認タイムスタンプに応答して、前記第１の監視間隔に続いて有効となり、前記第１の患者ケア様式に少なくとも部分的に基づく第３の終了日を有する第３の監視間隔を生成するステップをさらに含む、請求項９に記載の方法。
11. 前記第１の患者ケア様式規則は、心不全ケア様式に対応し、
    前記第１の監視間隔が前記監視間隔延長を生成する前に３１日の長さを有し、
    前記第３の監視間隔が前記３１日の長さを有する、ことを示す、請求項１０に記載の方法。
12. 前記第２の患者ケア様式規則は、遠隔監視ケア様式に対応し、前記第２の監視間隔が９１日の長さを有することを示す、請求項１１に記載の方法。
13. 前記第２の患者ケア様式規則は、院内ケア様式に対応し、前記第２の監視間隔が１年の長さを有することを示す、請求項１１に記載の方法。
14. 前記承認タイムスタンプは第１の承認タイムスタンプであり、前記承認日は前記第１の診療記録レポートに対応する第１の承認日であり、前記ＤＯＳは第１のＤＯＳであり、前記方法は、
    前記第３の監視間隔の前記第３の終了日より前に、第２の承認日を示す第２の承認タイムスタンプを受信するステップと、
    前記第２の承認日が前記第２の診療記録レポートに対応すると判定するステップと、
    前記第２の承認日が前記第２の診療記録レポートに対応すること及び前記第２の診療記録レポートが前記延長された終了日より前であることに少なくとも部分的に基づいて前記第２の承認タイムスタンプに対する第２のＤＯＳを生成するステップを省略するステップを、さらに含む、請求項１０に記載の方法。
15. 心臓監視装置を管理する方法であって、前記方法は、
    規則データベースから複数の患者ケア様式規則にアクセスするステップと、
    前記複数の患者ケア様式規則に少なくとも部分的に基づいて、同時に有効となり、前記心臓監視装置に関連付けられた複数の監視間隔を生成するステップであって、前記複数の監視間隔のうちの第１の監視間隔が第１の終了日を有し、前記複数の監視間隔のうちの第２の監視間隔が前記第１の終了日とは異なる第２の終了日を有する、ステップと、
    前記第１の終了日より前の受信日を有し、前記心臓監視装置から発信された送信データにアクセスするステップと、
    前記送信データに対して、前記第１の監視間隔又は前記第２の監視間隔に関連付けられた診療記録レポートを生成するステップと、
    前記受信日より後の承認日を示し、前記診療記録レポートに対応する承認タイムスタンプを受信するステップと、
    前記承認日が前記第１の終了日より後であることを計算するステップと、
    前記規則データベースから間隔延長規則にアクセスするステップと、
    前記間隔延長規則に従って、前記承認日が前記受信日よりも後であり、前記第１の終了日よりも後であることに少なくとも部分的に基づいて、延長された終了日を有する監視間隔延長を生成するステップと、
    前記送信データに対する業務の日付（ＤＯＳ）を生成するステップであって、前記ＤＯＳは承認日である、ステップと、を含む、方法。
16. 前記承認日が前記第１の終了日より後であることを計算するステップは、前記第１の終了日の発生時に、前記承認タイムスタンプが未だ受信されていないと判定するステップを含み、
    前記監視間隔延長を生成するステップは、前記延長された終了日に前記承認タイムスタンプが発生するまで、前記第１の監視間隔に対して日ごと延長を生成するステップを含む、請求項１５に記載の方法。
17. 前記承認タイムスタンプが前記延長された終了日に発生することに応答して、前記複数の患者ケア様式規則のうちの特定の患者ケア様式規則に少なくとも部分的に基づいた第３の終了日を有する第３の監視間隔を生成するステップをさらに含む、請求項１６に記載の方法。
18. 前記第１の監視間隔のＤＯＳ基準が満たされていることを、
    前記送信データの前記受信日が前記第１の終了日より前であることと、
    前記診療記録レポートは、前記第１の終了日より前に前記送信データに対して生成されることと、
    前記承認タイムスタンプは、前記承認日が前記受信日より後であり、前記診療記録レポートに対応していることを示すことと、に少なくとも部分的に基づいて、判定するステップであって、
    前記ＤＯＳを生成するステップは、前記ＤＯＳ基準が満たされていることに部分的に基づくものである、ステップをさらに含む、請求項１５に記載の方法。
19. 複数の心臓監視装置から発信される複数の送信を表す送信関連データに送信データベースからアクセスするステップであって、前記送信関連データは共通診療所識別子に関連付けられる、ステップと、
    前記送信関連データ及び前記共通診療所識別子に少なくとも部分的に基づいて、前記共通診療所識別子に関連付けられた診療所に対応する１つ又は複数の送信メトリクスを生成するステップであって、前記１つ又は複数の送信メトリクスは、
    送信の受信を待機する監視間隔の第１の数と、
    ＤＯＳ基準が満たされている監視間隔の第２の数と、
    ＤＯＳを必要とする監視間隔の第３の数と、
    １０日以内に行動が必要な監視間隔の第４の数と、
    １１日以降に行動が必要な監視間隔の第５の数と、
    診療記録レポートの受信を待機している送信の数と、
    承認の受信を待機している診療記録レポートの数と、
    特定の患者ケア様式にオプトインした患者の第１の数と、
    特定の患者ケア様式からオプトアウトした患者の第２の数と、のうちの１つ又は複数を含む、ステップと、
    前記１つ又は複数の送信メトリクスを前記診療所に関連付けられたディスプレイに提示させるステップと、をさらに含む、請求項１５に記載の方法。
20. 同時に提示された複数のタイムライン上の対話型ブロックとして前記複数の監視間隔のグラフィック表現を生成するステップであって、前記同時に提示された複数のタイムラインは、
    心不全ケア様式に対応し、３１日の長さの前記第１の監視間隔を含む第１のタイムラインと、
    遠隔監視ケア様式に対応し、９１日の長さの前記第２の監視間隔を含む第２のタイムラインと、
    院内ケア様式に対応し、１年の長さの第３の監視間隔を含む第３のタイムラインと、を含む、ステップをさらに含む、請求項１５に記載の方法。

Images