特表 2024-532641 緊急度ベースの患者スケジューリング

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-09-10

(54)【発明の名称】緊急度ベースの患者スケジューリング

(51)【国際特許分類】

   G16H 10/00 20180101AFI20240903BHJP

【ＦＩ】

G16H10/00

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023557398

(86)(22)【出願日】2022-08-08

(85)【翻訳文提出日】2023-09-19

(86)【国際出願番号】 US2022074674

(87)【国際公開番号】W WO2023019112

(87)【国際公開日】2023-02-16

(31)【優先権主張番号】63/231,504

(32)【優先日】2021-08-10

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

２．ＡＮＤＲＯＩＤ

３．ｉＯＳ

(71)【出願人】

【識別番号】504016422

【氏名又は名称】デックスコム・インコーポレーテッド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】スブライ・パイ

(72)【発明者】

【氏名】トマス・ウォーカー

(72)【発明者】

【氏名】アフシャン・クラインハンツル

(72)【発明者】

【氏名】ジェームズ・バーメトラー

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

5L099AA15

(57)【要約】

本開示の特定の態様は、患者スケジューリング情報を更新する方法に関する。一態様では、本方法は、将来の日付にスケジューリングされた予約を有する患者についての患者データであって、患者データは、バイオマーカーについてのメトリック値と、スケジューリングされた予約と関連付けられた日時情報とを含む、患者データを受信することを含む。本方法は、メトリック値を、患者の患者病歴、又は母集団健康データに少なくとも部分的に基づいて確立された１つ以上の条件と比較することを更に含む。本方法はまた、メトリック値が１つ以上の条件のうちの少なくとも１つを満たすと判定した後に、スケジューリングされた予約を再スケジューリングすることも含む。

【特許請求の範囲】

【請求項1】

患者スケジューリング情報を更新するための方法であって、前記方法は、
将来の日付にスケジューリングされた予約を有する患者についての患者データであって、前記患者データが、バイオマーカーについてのメトリック値と、前記スケジューリングされた予約と関連付けられた日時情報とを含む、患者データを受信することと、
前記メトリック値を、前記患者の患者病歴、又は母集団健康データに少なくとも部分的に基づいて確立された１つ以上の条件と比較することと、
前記メトリック値が前記１つ以上の条件のうちの少なくとも１つを満たすと判定した後に、前記スケジューリングされた予約を再スケジューリングすることと、を含む、方法。

【請求項2】

前記スケジューリングされた予約が、医師との健診、外来患者処置、又は入院患者処置のうちの１つ以上を含む、請求項１に記載の方法。

【請求項3】

前記バイオマーカーが、分析物、体温、健康状態、コレステロール測定値、血圧、又は心拍数のうちの１つ以上を含む、請求項１に記載の方法。

【請求項4】

前記メトリック値が、センサデバイスによって測定された値、又はある期間にわたって前記センサデバイスによって生成された傾向データを含む、請求項１に記載の方法。

【請求項5】

前記メトリック値が前記１つ以上の条件のうちの少なくとも１つを満たさないと判定した後に、前記スケジューリングされた予約を維持することを更に含む、請求項１に記載の方法。

【請求項6】

患者スケジューリング情報を更新するための方法であって、前記方法は、
将来の日付にスケジューリングされた予約を有する患者についての患者データであって、前記患者データが、ある期間にわたって診断デバイスによって測定されたバイオマーカーについてのメトリック値を含み、前記スケジューリングされた予約が、日時情報を含む、患者データを受信することと、
前記バイオマーカーについての閾値基準であって、前記閾値基準が、前記患者の患者病歴、又は母集団健康データに少なくとも部分的に基づいて確立されている、閾値基準を前記メトリック値と比較することと、
前記メトリック値が前記閾値基準を満たさないと判定すると、前記メトリック値が前記閾値基準を満たさないという第１の指標と、前記スケジューリングされた予約を、前記将来の日付に対して、より早い日付又はより遅い日付のうちの一方に再スケジューリングするための第１の提案と、前記第１の提案の確認についての要求とを含む、第１の通知を自動的に生成することと、
前記メトリック値が前記閾値基準を満たすと判定すると、前記メトリック値が前記閾値基準を満たすという第２の指標と、前記スケジューリングされた予約を、前記将来の日付に対して、より早い日付又はより遅い日付のうちの他方に再スケジューリングするための第２の提案と、前記第２の提案の確認についての要求とを含む、第２の通知を自動的に生成することと、
前記第１の通知を生成すると、前記第１の通知を医師に伝達することと、
前記第２の通知を生成すると、前記第２の通知を前記医師に伝達することと、を含む、方法。

【請求項7】

前記スケジューリングされた予約が、前記医師との健診、外来患者処置、又は入院患者処置のうちの１つ以上を含む、請求項６に記載の方法。

【請求項8】

前記バイオマーカーが、血糖測定値、測定された体温、健康状態、栄養詳細、薬物投与計画、コレステロール測定値、血圧、又は心拍数のうちの１つ以上を含む、請求項６に記載の方法。

【請求項9】

前記メトリック値が、前記診断デバイスによって測定された値、又はある期間にわたって前記メトリック値に基づいて生成された傾向データを含む、請求項６に記載の方法。

【請求項10】

前記スケジューリングされた予約を再スケジューリングするための前記第１の提案が、前記スケジューリングされた予約を前記将来の日付から前記将来の日付の前の日付に早めること、又は前記スケジューリングされた予約を前記将来の日付から前記将来の日付の後の日付に遅らせること、のうちの１つを含む、請求項６に記載の方法。

【請求項11】

前記スケジューリングされた予約を再スケジューリングするための前記第２の提案が、前記スケジューリングされた予約を前記将来の日付からより遅い日付に遅らせること、又は前記スケジューリングされた予約を前記将来の日付からより早い日付に早めることを含む、請求項６に記載の方法。

【請求項12】

前記第１の通知を伝達することが、前記第１の通知を前記患者に伝達することを更に含み、前記第２の通知を伝達することが、前記第２の通知を前記患者に伝達することを更に含む、請求項６に記載の方法。

【請求項13】

前記閾値基準が、前記患者との少なくとも１つの類似性を有する１つ以上の他の患者病歴からの集約データに基づいて、更に確立されている、請求項６に記載の方法。

【請求項14】

患者スケジューリング情報を更新するための方法であって、前記方法は、
将来の日付にスケジューリングされた予約を有する患者についての、診断デバイスによって測定された患者データであって、前記患者データが、バイオマーカーについての値を含む、患者データを受信することと、
前記バイオマーカーについての閾値基準であって、前記閾値基準が、前記患者の患者病歴、及び少なくとも１人の他の患者についての対応する患者データに少なくとも部分的に基づいて確立されている、閾値基準を受信することと、
前記スケジューリングされた予約についての日時情報を含む、前記患者についてのスケジューリング情報を受信することと、
前記スケジューリングされた予約を有する前記患者についての前記患者データを受信すると、前記閾値基準を、前記スケジューリングされた予約についての前記スケジューリング情報に関する前記バイオマーカーについての前記値、及び現在の日付に基づく、比較値と比較することと、
前記比較値が前記閾値基準を満たさないと判定すると、
保健医療提供者への第１の通知であって、前記第１の通知は、前記バイオマーカーが前記閾値基準を満たさないという第１の指標と、前記スケジューリングされた予約を新しい日付に再スケジューリングするための第１の提案とを含む、第１の通知を自動的に生成することと、
前記新しい日付についての新しいスケジューリングされた予約を自動的に生成することと、
前記比較値が前記閾値基準を満たすと判定すると、
前記保健医療提供者への第２の警告であって、前記第２の警告は、前記バイオマーカーが前記閾値基準を満たすという第２の指標と、前記新しい日付についての前記スケジューリングされた予約を、前記将来の日付よりも遅い日付に再スケジューリングするための第２の提案とを含む、第２の警告を自動的に生成することと、
前記新しい日付についての前記新しいスケジューリングされた予約を自動的に生成することと、
前記第１の通知を生成すると、前記第１の通知を前記保健医療提供者に伝達することと、
前記第２の警告を生成すると、前記第２の警告を前記保健医療提供者に伝達することと、
前記第１の提案又は前記第２の提案の確認を受信すると、前記新しいスケジューリングされた予約に関する詳細を保健医療提供者に伝達することと、を含む、方法。

【請求項15】

前記比較値が前記閾値基準を満たすという判定に起因して、前記スケジューリングされた予約が再スケジューリングされているという第３の警告を前記患者に伝えることを更に含む、請求項１４に記載の方法。

【請求項16】

前記比較値が前記閾値基準を満たさないという判定に起因して、前記スケジューリングされた予約が再スケジューリングされているという第３の警告を前記患者に伝えることを更に含む、請求項１４に記載の方法。

【請求項17】

前記比較値を、
第１の期間にわたって前記値についての予想された変化率を識別することと、
前記将来の日付に鑑みて、前記値についての前記予想された変化率を、前記値についての複数の値のうちの１つ以上の値に適用することによって前記比較値を判定することと、に基づいて生成することを更に含む、請求項１４に記載の方法。

【請求項18】

前記新しい日付は、前記バイオマーカーが前記閾値基準及び前記現在の日付をいつ満たすかについての予測に基づいて識別される、請求項１４に記載の方法。

【請求項19】

前記バイオマーカーが、血糖測定値、測定された体温、健康状態、栄養詳細、薬物投与計画、コレステロール測定値、血圧、又は心拍数のうちの１つ以上を含む、請求項１４に記載の方法。

【請求項20】

前記スケジューリングされた予約が、医師との健診、外来患者処置、又は入院患者処置のうちの１つ以上を含む、請求項１４に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、２０２１年８月１０日に出願された米国特許仮出願第６３／２３１，５０４号に対する優先権を主張し、この特許仮出願は、本明細書によって本明細書の譲受人に譲渡され、以下に完全に記載されているかのように、かつ全ての適用可能な目的のために、その全体が参照により本明細書に明示的に組み込まれる。

【背景技術】

【0002】

患者の健康の管理には、例えば、健診、入院患者処置、外来患者処置などのための、患者による医師への来院が含まれ得る。そのような来院又は予約は、数日、数週間、又は数ヶ月、前もってスケジューリングされ得る。いくつかの例では、スケジューリングされた来院が近づくにつれて、患者の健康状態、及び／又はその変化により、来院が疑問視されるか、又は他の例では、来院の緊急度が変化する可能性がある。例えば、糖尿病患者は、定期健診のためにスケジューリングされ得、その間、医師は、その患者が自身のグルコースレベル及び全体的な健康を許容可能な（すなわち、閾値）レベル内に維持しているかどうかを検証するように計画することができる。しかしながら、患者が自身のグルコースレベル及び全体的な健康を許容可能なレベル内に正常に維持している場合、健診は、スケジューリングされる必要がない可能性がある。したがって、そのような場合に医師を訪問することは、患者の時間及び医師の時間の両方、並びに来院を必要とする他の患者に提供されていたかもしれない医療資源を無駄にする。

【0003】

特定の他の場合には、来院がスケジューリングされた後に、患者の健康が著しく悪化し始めることがあり、その場合、スケジューリングされた来院より前に医師を訪問することは、人命を救助することができるか、又は患者にとって少なくとも有益であり得る。更に他の場合には、患者が、スケジューリングされた来院が近づくにつれて、スケジューリングされた来院（入院患者処置又は外来患者処置など）のための特定の要件にかなわない場合がある。例えば、特定の処置は、患者の健康（例えば、分析物測定値、又は患者の健康の他のパラメータ）が特定の状態にある（例えば、特定の範囲内にある、又は特定の閾値にかなう）ことが必要であり得る。例えば、糖尿病患者は、特に、患者の測定されたグルコースレベルが範囲外にある場合、手術による又は手術後の感染症にもっとかかりやすい。したがって、患者のグルコースレベルは、患者のスケジューリングされた処置がスケジューリングされたとおりに行われ得るか、又は遅らせるべきかを示すことができる。患者のグルコースレベルがスケジューリングされた処置の日に測定されたときに、グルコースレベルが上昇又は低下などの範囲内にない場合、その処置は、延期され得る。しかしながら、患者のグルコースレベルを測定して、スケジューリングされた処置の日にその処置をキャンセルすることは、スケジューリングされた日の処置を前もってキャンセルすることと比較して、結果として、患者の時間を無駄にし、診療所の処置の時間枠を無駄にすることになり得る。

【0004】

この背景技術は、後に続く発明の概要及び発明を実施するための形態の簡単な文脈を紹介するために提供されている。この背景技術は、特許請求される主題の範囲を判定する助けとなることも、特許請求される主題を、上に提示された欠点又は問題のうちのいずれか又は全てを解決する実装形態に限定するものとしてみなされることも、意図されていない。

【発明の概要】

【課題を解決するための手段】

【0005】

特定の実施形態は、患者スケジューリング情報を更新するための方法を提供する。本方法は、将来の日付にスケジューリングされた予約を有する患者についての患者データであって、患者データは、バイオマーカーについてのメトリック値と、スケジューリングされた予約と関連付けられた日時情報とを含む、患者データを受信することを含む。この方法はまた、メトリック値を、患者の患者病歴、又は母集団健康データに少なくとも部分的に基づいて確立された１つ以上の状態と比較することも含む。この方法は、メトリック値が１つ以上の条件のうちの少なくとも１つを満たすと判定した後に、スケジューリングされた予約を再スケジューリングすることを更に含む。

【0006】

特定の実施形態では、スケジューリングされた予約は、医師との健診、外来患者処置、又は入院患者処置のうちの１つ以上を含む。特定の実施形態では、バイオマーカーは、分析物、体温、健康状態、コレステロール測定値、血圧、心拍数、又は心臓電気活動のうちの１つ以上を含む。特定の実施形態では、メトリック値は、センサデバイスによって測定された値、又はある期間にわたってセンサデバイスによって生成された傾向データを含む。

【0007】

特定の他の実施形態は、患者スケジューリング情報を更新するための別の方法を提供する。他の方法は、将来の日付にスケジューリングされた予約を有する患者についての患者データであって、患者データは、ある期間にわたって診断デバイスによって測定されたバイオマーカーについてのメトリック値を含み、スケジューリングされた予約は、日時情報を含む、患者データを受信すること、を含む。他の方法は、バイオマーカーについての閾値基準であって、閾値基準は、患者の患者病歴、又は母集団健康データに少なくとも部分的に基づいて確立されている、閾値基準をメトリック値と比較することを更に含む。他の方法はまた、メトリック値が閾値基準を満たさないと判定すると、メトリック値が閾値基準を満たさないという第１の指標、スケジューリングされた予約を、将来の日付を基準にしてより早い日付又はより遅い日付のうちの一方に再スケジューリングするための第１の提案、及び第１の提案の確認についての要求を含む、第１の通知を自動的に生成することも含む。

【0008】

他の方法は、メトリック値が閾値基準を満たすと判定すると、メトリック値が閾値基準を満たすという第２の指標、スケジューリングされた予約を、将来の日付を基準にしてより早い日付又はより遅い日付のうちの他方に再スケジューリングするための第２の提案、及び第２の提案の確認についての要求を含む、第２の通知を自動的に生成することを更に含む。更に、他の方法は、第１の通知を生成すると、第１の通知を医師に伝達することと、第２の通知を生成すると、第２の通知を医師に伝達することと、を含む。

【0009】

特定の実施形態では、スケジューリングされた予約は、医師との健診、外来患者処置、又は入院患者処置のうちの１つ以上を含む。特定の実施形態では、バイオマーカーは、血糖測定値、測定された体温、健康状態、栄養詳細、薬物投与計画、コレステロール測定値、血圧、心拍数、又は心臓電気活動のうちの１つ以上を含む。特定の実施形態では、メトリック値は、診断デバイスによって測定された値、又はある期間にわたってメトリック値に基づいて生成された傾向データを含む。特定の実施形態では、スケジューリングされた予約を再スケジューリングするための第１の提案は、スケジューリングされた予約を将来の日付から将来の日付の前の日付に早めること、又はスケジューリングされた予約を将来の日付から将来の日付の後の日付に遅らせること、のうちの１つを含む。特定の実施形態では、スケジューリングされた予約を再スケジューリングするための第２の提案は、スケジューリングされた予約を将来の日付からより遅い日付に遅らせること、又はスケジューリングされた予約を将来の日付からより早い日付に早めることを含む。特定の実施形態では、第１の通知を伝達することは、第１の通知を患者に伝達することを更に含み、第２の通知を伝達することは、第２の通知を患者に伝達することを更に含む。特定の実施形態では、閾値基準は、患者との少なくとも１つの類似性を有する１つ以上の他の患者の病歴からの集約データに基づいて、更に確立される。

【0010】

特定の実施形態は、患者スケジューリング情報を更新するための追加の方法について記載する。追加の方法は、将来の日付にスケジューリングされた予約を有する患者についての、診断デバイスによって測定された患者データであって、患者データは、バイオマーカーについての値を含む、患者データを受信することと、バイオマーカーについての閾値基準であって、閾値基準は、患者の患者病歴、及び少なくとも１人の他の患者についての対応する患者データに少なくとも部分的に基づいて確立されている、閾値基準を受信することと、を含む。追加の方法は、スケジューリングされた予約の日時情報を含む、患者についてのスケジューリング情報を受信することと、スケジューリングされた予約を有する患者についての患者データを受信すると、閾値基準を、スケジューリングされた予約についてのスケジューリング情報に関するバイオマーカーの値、及び現在の日付に基づく、比較値と比較することと、を更に含む。

【0011】

追加の方法はまた、比較値が閾値基準を満たさないと判定すると、保健医療提供者への第１の通知であって、第１の通知は、バイオマーカーが閾値基準を満たさないという第１の指標と、スケジューリングされた予約を新しい日付に再スケジューリングするための第１の提案とを含む、第１の通知を自動的に生成することと、新しい日付についての新しいスケジューリングされた予約を自動的に生成することと、含む。追加の方法は、比較値が閾値基準を満たすと判定すると、保健医療提供者への第２の警告であって、第２の警告は、バイオマーカーが閾値基準を満たすという第２の指標と、新しい日付についてのスケジューリングされた予約を、将来の日付よりも遅い日付に再スケジューリングするための第２の提案とを含む、第２の警告を自動的に生成することと、新しい日付についての新しいスケジューリングされた予約を自動的に生成することと、を更に含む。更に、追加の方法は、第１の通知を生成すると、第１の通知を保健医療提供者に伝達することと、第２の警告を生成すると、第２の警告を保健医療提供者に伝達することと、第１の提案又は第２の提案の確認を受信すると、新しいスケジューリングされた予約に関する詳細を保健医療提供者に伝達することと、を含む。

【0012】

特定の実施形態では、この方法は、比較値が閾値基準を満たすという判定に起因して、スケジューリングされた予約が再スケジューリングされているという第３の警告を患者に伝えることを更に含む。特定の実施形態では、この方法は、比較値が閾値基準を満たさないという判定に起因して、スケジューリングされた予約が再スケジューリングされているという第３の警告を患者に伝えることを更に含む。特定の実施形態では、この方法は、比較値を、第１の期間にわたって値についての予想された変化率を識別すること、及び、将来の日付に鑑みて、値についての予想された変化率を、値についての複数の値のうちの１つ以上の値に適用することによって比較値を判定すること、に基づいて生成することを更に含む。特定の実施形態では、新しい日付は、バイオマーカーが閾値基準及び現在の日付をいつ満たすかについての予測に基づいて識別される。

【0013】

特定の実施形態は、患者又は医師のうちの少なくとも１人に事前対策的に通知するための追加の方法を提供する。追加の方法は、患者についての患者データを受信することを含む。追加の方法はまた、バイオマーカーについてのメトリック値が１つ以上の条件を満たすと判定することも含む。追加の方法はまた、判定に基づいて、患者への第１の通知、及び医師への第２の通知を生成することも含む。追加の方法はまた、判定に関して患者に尋ねるための質問のセットを生成及び提示することも含む。追加の方法は、質問のセットに対する１つ以上の回答を受信及び送信することを更に含む。

【0014】

特定の実施形態は、医師へのスケジューリングされた来院に向けて患者に準備をさせるための追加の方法を提供する。追加の方法は、患者についての患者データを受信することを含む。追加の方法はまた、患者データに少なくとも部分的に基づいて、患者が医師に尋ねるための質問のセットを生成することも含む。追加の方法は、その質問のセットを、患者と関連付けられたコンピューティングデバイスに送信することを更に含む。

【図面の簡単な説明】

【0015】

【図1】本明細書に開示される特定の実施形態による、例示的な健康データシステムのブロック図を示す。

【図2】本明細書に説明される特定の実施形態による、図１の例示的な健康データシステムと関連付けられたグルコース監視システム及び例示的なモバイルデバイスをより詳細に示す。

【図3】本明細書に説明される特定の実施形態による、医師が、図１の例示的な健康データシステムによって使用するためのルールを作成及び／又は修正することを可能にする例示的なＵＩを示す。

【図4】本明細書に説明される特定の実施形態による、対応する患者健康データにルールを適用するために行われる動作のフローチャートを示す。

【図5】本明細書に説明される特定の実施形態による、患者の健康を監視し、その患者の来院について医師に通知し、かつ／又は、その患者について現在スケジューリングされている来院を再スケジューリングするために行われる動作のフローチャートを示す。

【図6】本明細書に説明される特定の実施形態による、患者の健康を監視し、その患者の健康の変化について患者及び／又は医師に事前対策的に警告するために行われる動作のフローチャートを示す。

【図7】本明細書に説明される特定の実施形態による、患者の健康を監視し、患者の医師へのスケジューリングされた来院に向けて患者に事前対策的に準備をさせるために行われる動作のフローチャートを示す。

【図8A】本明細書に説明される特定の実施形態による、医師へのスケジューリングされた来院に向けて患者に準備をさせるための例示的なシナリオを示す。

【図8B】本明細書に説明される特定の実施形態による、医師へのスケジューリングされた来院に向けて患者に準備をさせるための例示的なシナリオを示す。

【図8C】本明細書に説明される特定の実施形態による、医師へのスケジューリングされた来院に向けて患者に準備をさせるための例示的なシナリオを示す。

【図9】本明細書に説明される特定の実施形態を実行又は具現化する処理システムの実施形態の略図である。

【図10】本明細書に説明される特定の実施形態を実行又は具現化する処理システムの実施形態の略図である。

【図11】本明細書に説明される特定の実施形態を実行又は具現化する処理システムの実施形態の略図である。

【0016】

理解を容易にするために、可能な場合には、同一の参照数字を使用して、図面に共通である同一の要素を指定する。一実施形態の要素及び特徴は、更なる詳述なしで、他の実施形態に有益に組み込まれ得ることが想定される。

【発明を実施するための形態】

【0017】

上述したように、患者の健康状態及びその変化により、スケジューリングされた来院が無意味になるか、又は他の場合には、来院の緊急度が変更される場合がある。しかしながら、既存の患者健康データ監視及びスケジューリングシステムは、非効率的であり、並びに患者の健康を動的に監視すること、患者のスケジューリングされた来院が再スケジューリングされるべきかどうかを自動的に判定すること、患者の健康について患者に自動的に警告及び問い合わせすること、患者のスケジューリングされた来院に関して患者に自動的に準備をさせること、及び／又は患者の健康について医師に自動的に通知することは技術的に不可能である。そのような非効率性は、他のマイナス材料の中でもとりわけ、患者及び保険会社の医療費の増加、医師の収入の損失、及び患者の時間の損失をもたらし得る。

【0018】

本明細書に説明される特定の実施形態は、システム、方法、及び装置を提供し、それらは、患者のスケジューリングされた来院が早まっている（現在の日付により近い新しい日付に移動された）可能性があるか、遅くなっている（現在の日付から更に遠い新しい日付に移動された）可能性があるか、又は維持されている（スケジューリングされた日付に保たれた）可能性があるかどうか、並びに患者の健康について医師に通知するべきかどうか、患者の健康と関連付けられた変化する状態に関して患者に警告するべきかどうか、患者の健康と関連付けられた変化する状態に関して患者に問い合わせる（質問する）べきかどうか、質問のセットを患者に提供して患者のスケジューリングされた来院中に医師に尋ねることによって、患者のスケジューリングされた来院について患者に事前対策的に準備をさせるべきかどうかなどを、事前対策的にかつ動的に判定する。

【0019】

例えば、特定の実施形態におけるシステム、方法、及び装置により、診療所（又は同様の組織体）が、次回の来院を有する患者の健康データ（例えば、継続的に）を遠隔でかつ動的に監視及び分析し、患者の来院が再スケジューリング若しくは維持され得るか又はされるべきかを判定することを可能にする。上で考察されたように、糖尿病患者の例では、スケジューリングされた来院は、医師が患者のグルコースレベルを確認し、後続の来院を適宜スケジューリングすることを計画することができる健診とすることができる。そのような来院の場合、システム、方法、及び装置は、ある期間（例えば、患者の来院より前の期間、患者の最後の来院と、患者の次回のスケジューリングされた来院との間の期間、又は何らかの他の期間）にわたって、患者のグルコースレベルの自動的かつ優先的な監視及び分析を可能にする。典型的なシナリオでは、システム、方法、及び装置は、患者のグルコース管理インジケータ（glucose management indicator、ＧＭＩ）（糖化ヘモグロビンＡ１ｃ（glycated hemoglobin A1c、ＨｂＡ１ｃ）の近似として）が患者の最後の来院以来、又は以前の期間（例えば、直前３ヶ月）中に上昇若しくは下降したかどうかを判定することができる。システム、方法、及び装置が、患者のグルコースレベルが特定の条件を満たす（例えば、患者のグルコースレベルが所定の閾値範囲内にある）と判定した場合、システム、方法、及び装置は、患者の来院を遅らせることができると判定することができる。このシナリオにおいて、患者の来院を遅らせることは、医師への不必要な本人じきじきの来院を省くことによって、患者及び医師の時間、並びに費用を節約する。これに対して、システム、方法、及び装置は、患者のグルコースレベルが特定の条件を満たす（例えば、患者のグルコースレベルが所定の閾値範囲外にある）場合、システム、方法、及び装置は、患者の来院を維持又は早めることができる。このシナリオにおいて、患者の来院を早めることは、医師が患者の健康における関連する変化に対処することを可能にする。

【0020】

同様に、患者の来院が入院患者の外科的処置である場合、特定の実施形態におけるシステム、方法、及び装置は、ある期間（例えば、患者の来院より前の期間、患者の最後の来院と、患者の次回のスケジューリングされた来院との間の期間など）にわたって、患者のグルコースレベルの自動的かつ優先的に監視及び分析することを可能にする。この監視及び分析に基づいて、システム、方法、及び装置は、特定の健康メトリックが、患者がその処置に対して適切な健康状態にあるであろうことを示しているかどうかを判定することができる。例えば、患者のグルコースレベルがその期間中に高すぎる場合、システム、方法、及び装置は、入院患者の外科的処置を後日に向けて再スケジューリングすることができ、それによって、患者及び医師のリソースを節約する。別の例では、ある期間にわたって患者のグルコースレベルを自動的かつ優先的に監視及び分析することにより、患者が、その患者の状態に対処するための応急手当、又は少なくともより早急な来院を必要としていることが示され得る。

【0021】

加えて、特定の実施形態におけるシステム、方法、及び装置は、ある期間にわたって患者のグルコースレベルを監視及び分析することに基づいて、患者の健康と関連付けられた変化する状態に対して、患者及び／又は医師に事前対策的に警告することを可能にする。例えば、ある期間にわたって患者のグルコースレベルを自動的かつ優先的に監視及び分析することにより、患者の状態に伴う潜在的なリスク（例えば、患者が入院するリスクにあることを示している再発生低血糖若しくは低血糖メトリック）、又は患者の状態の制御悪化（例えば、患者のグルコースレベルが閾値を上回る範囲に悪化時間を有する）が示され得る。患者の状態に伴う潜在的なリスク、又は患者の状態の制御悪化を検出することに応答して、システム、方法、及び装置は、患者の状態における関連する変化が検出されていることを患者に通知（又は警告）することができる。患者に通知することに加えて、システム、方法、及び装置は、患者の状態において検出された変化に関して、患者に自動的に問い合わせることができる。例えば、システム、方法、及び装置は、患者の状態における変化に関する情報を収集して、患者の変化する状態の潜在的な原因を判定するように設計されている質問のセットを生成することができる（例えば、患者は、患者の現在の健康、患者の健康における顕著な傾向などについて尋ねられ得る）。システム、方法、及び装置は、質問のセットに対する患者の応答を収集し、その患者の応答を医師と共有することができ、医師に関連情報を提供して、患者のスケジューリングされた来院中に患者と議論する。このようにして、システム、方法、及び装置は、例えば、患者の変化する状態について患者及び／又は医師に通知することを事前対策的に介在させることによって、また、患者の変化する状態に関して（動的に生成された質問のセットに対するユーザの応答に基づいて、）医師に関連情報を提供することによって、患者の介護を大幅に改善することができる。

【0022】

加えて、特定の実施形態では、システム、方法、及び装置は、期間（例えば、患者の来院より前の期間、患者の最後の来院と、患者のスケジューリングされた来院との間の期間）にわたって、患者のグルコースレベルを監視及び分析することに部分的に基づいて、患者のスケジューリングされた来院について患者に事前対策的に準備をさせることができる。例えば、システム、方法、及び装置は、患者のための質問のセットを生成して、患者の来院中に医師に尋ねることができる。特定の実施形態では、質問のセットは、期間にわたって患者のグルコースレベルにおける傾向に基づくことができる。例えば、システム、方法、及び装置は、患者がその期間中に低血糖レベルを有していたことを検出することができ、ユーザが低血糖レベルに関して医師に尋ねるための提案された質問を生成することができる。このようにして、システム、及び方法、及び装置は、例えば、患者の来院中に議論される情報の品質を改善することによって、患者の来院の効率を改善すること（例えば、時間を節約すること）によって、患者が医師に尋ねる特定の質問を忘れてしまった、かつ／又は医師にどの質問を尋ねたらよいかわからない場合がある状況において、患者と医師との間の対話を導くように患者に質問を提供することによって、患者の来院中での医師との患者の意思疎通を大幅に改善することができる。

【0023】

本明細書における特定の例及び実施形態は、糖尿病患者、したがって、患者のグルコース測定値及び関連データを監視及び分析することに関連して説明されているが、本明細書に説明されるシステム、方法、及び装置は、任意の状態を有する任意の患者について任意の健康メトリック（例えば、分析物測定値、心拍数、呼吸数など）を遠隔で監視及び分析すること、患者のスケジューリングされた来院が変更される必要があり得るかどうかを判定すること、患者の状態に関して患者かつ／又は医師に事前対策的に通知するべきかどうかを判定すること、及び、患者のスケジューリングされた来院について患者に事前対策的に準備をさせるべきかどうかを判定することを可能にすることに留意されたい。

【0024】

例示的なシステム
図１は、本明細書に開示された特定の実施形態による、例示的な健康データシステム１００のブロック図を示しており、これは、例えば、患者コンピューティングデバイス（以降、患者デバイスと称される）１０７によって収集され、かつ診療所コンピューティングシステム（以降、診療所システムと称される）１２０によって、並びに／又はサーバコンピューティングシステム（以降、サーバシステムと称される）１３０によってアクセス可能である健康データの処理を可能にする。患者１０２は、患者デバイス１０７を使用して、患者の健康を監視し、患者健康データを収集することができる。この健康データは、例えば、患者１０２と関連付けられた患者プロフィール１１０の一部として、患者データストア１４０に格納することができる。患者デバイス１０７は、患者１０２の１つ以上の解剖学的パラメータを監視し、その監視の結果としてのデータを生成し、そのデータを患者デバイス１０７に送信するように構成されている患者監視システム１０４に通信可能に更に結合されている。患者監視システム１０４によって生成されたデータは、アプリケーション１０６によって患者健康データの一部として、同様に監視及び収集され、患者データストア１４０に格納される。

【0025】

患者監視システム１０４は、分析物測定システム、心拍数センサ、呼吸センサ、加速度計、任意の他の同様のタイプの健康監視システム、又はこれらのセンサ及び／若しくはシステムのうちの１つ以上の組み合わせなどの任意のウェアラブル若しくは非ウェアラブルデバイス、又はシステムを含むことができる。いくつかの例では、患者監視システム１０４は、連続的、定期的、又は要求に応じた原則のうちの１つ以上に基づいて、患者１０２の１つ以上の解剖学的パラメータの測定値を生成するように構成されているセンサを含む。例えば、患者監視システム１０４がグルコース監視システムである場合、センサは、患者の血糖濃度を測定するように構成されたグルコースセンサである。患者監視システム１０４は、無線（例えば、Ｂｌｕｅｔｏｏｔｈ）又は有線接続を介して測定値を患者デバイス１０７に送信するように構成されているセンサ電子機器モジュールを更に含むことができる。特定の実施形態では、患者監視システム１０４は、例えば、アプリケーション１０６によって使用するための測定値を患者デバイス１０７に送信する。グルコース監視システムに関する更なる詳細が、図２に関して以下に提供される。

【0026】

特定の実施形態では、アプリケーション１０６は、患者デバイス１０７のディスプレイ上に表示するためのユーザインターフェース（user interface、ＵＩ）を提供し、それを介して、患者１０２は、患者デバイス１０７及び／又は患者監視システム１０４のうちの１つ以上と対話する。上述したように、アプリケーション１０６は、（例えば、患者１０２、患者１０２の保健医療提供者、患者監視システム１０４などから）健康データを収集し、その健康データを患者プロフィール１１０に格納する。患者プロフィール１１０には、患者の名前、住所、生年月日などの患者１０２についての情報を識別する患者データ１１１が含まれる。患者プロフィール１１０はまた、患者の年齢、肥満度指数（body mass index、ＢＭＩ）、民族性、性別などのうちの１つ以上など、患者１０２についての人口統計データ１１２も含む。

【0027】

患者プロフィール１１０は、上で紹介したように、患者の健康に関する健康データ１１３を更に含み、そこでは、健康データ１１３は、患者監視システム１０４によって自動的に測定され、患者１０２によって手動で入力され、診療所システム１２０及び／又はサーバシステム１３０によって提供されたなどの様々なデータポイント若しくはメトリックを含む。特定の実施形態では、健康データ１１３は、複数の患者監視システム１０４からの、又は患者の健康の様々な側面に関連する、データポイントを含む。特定の実施形態では、健康データ１１３は、リアルタイム健康メトリック、過去の健康メトリック、傾向データ、及び／又はある期間にわたって１つ以上の分析物のセンサ測定値、他の解剖学的パラメータなどに基づいて展開された経時的な変化率を含む。健康データ１１３の例としては、経時的に収集された患者の分析物（例えば、グルコース、乳酸塩、ケトン、カリウムなど）測定値、分析物レベル及び傾向、活動データ、摂食量データ、代謝率、体温、心拍数、心臓電気活動（例えば、心電図（electrocardiogram、ＥＣＧ））、身体全体の健康又は病気情報、インスリン感受性、インスリンオンボードなどが挙げられ得る。特定の実施形態では、健康データ１１３は、患者の異なる解剖学的パラメータについての患者固有閾値を更に含むことができる。例えば、健康データ１１３は、テーラーメード分析物閾値（例えば、グルコース範囲、心拍数範囲など）を含んでもよい。これらの閾値のうちの１つ以上は、特定の患者について医師によって指定又は設定され得、人工知能（artificial intelligence、ＡＩ）／機械学習（machine learning、ＭＬ）技法などを使用して、サーバシステム１３０によって生成され得る。

【0028】

患者プロフィール１１０は、患者１０２によって服用される任意の薬物の投与計画又は処方と関連付けられた情報、運動療法の詳細、食事情報などの治療情報１１４を更に含み、例えば、患者の健康管理を支援する。患者プロフィール１１０は、医師との健診又は身体検査、入院患者処置、外来患者処置など、患者１０２についてのスケジューリングされた将来の来院の詳細を含む、患者１０２についてのスケジュール情報１１５を更に含む。将来の来院の詳細には、来院がいつスケジューリングされるか、来院に関連する患者の健康データの側面などに関する詳細が含まれ得る。

【0029】

患者プロフィール１１０は、患者１０２の来院中に医師に尋ねるための、患者１０２について生成された質問のセットなどの質問情報１１６を更に含む。質問情報１１６は、医師によって（診療所システム１２０を介して）提供される質問のセット、サーバシステム１３０によって提供される質問のセット、又はこれらの組み合わせを含むことができる。特定の実施形態では、質問情報１１６は、患者１０２が患者の来院中に医師に尋ねるための質問のセット、患者１０２が患者の来院より前に回答するべき患者の状態に関する質問のセット、又はこれらの組み合わせを含む。患者プロフィール１１０は、質問情報１１６内の質問のセットのうちの１つ以上に対する応答のセットなどの応答情報１１７を更に含む。例えば、応答情報１１７は、患者の状態において検出された変化に関する情報を収集するように生成された質問に対する回答を含むことができる。

【0030】

患者データストア１４０は、複数の患者についての患者プロフィール１１０を格納する。特定の実施形態では、患者データストア１４０は、パブリッククラウド又はプライベートクラウドで動作するストレージサーバに対応する。特定の実施形態では、患者データストア１４０は、診療所システム１２０及び／又はサーバシステム１３０内に含まれ得る（又はそれ以外の場合は、それらによってアクセス可能であり得る）。

【0031】

診療所システム１２０は、患者の医師の診療所において動作可能である。診療所システム１２０は、メモリ１２２に格納された１つ以上のソフトウェアアプリケーションを実行するように構成されたプロセッサ１２１を含む。例えば、プロセッサ１２１は、スケジューリング及び通知アプリケーション（以降、「Ｓ＆Ｎアプリケーション」と称される）を実行することができる。このＳ＆Ｎアプリケーションは、診療所システム１２０が患者のスケジュールを動的に管理することを可能にすることができる。例えば、特定の実施形態では、診療所システム１２０は、Ｓ＆Ｎアプリケーションを使用して、患者のプロフィール１１０内の情報に基づいて、患者のスケジューリングされた来院を早め、遅くし、又は維持することができる。同様に、Ｓ＆Ｎアプリケーションは、プロセッサ１２１が、患者のプロフィール１１０内の情報に基づいて、通知又はメッセージを医師、患者などに自動的かつ動的に生成することを可能にすることができる。

【0032】

診療所システム１２０は、Ｓ＆Ｎアプリケーションによって使用されるスケジューリング及び通知ルール、診療所についてのスケジュールデータ、患者プロフィール１１０など、診療所システム１２０によって使用されるデータを格納するためのデータストア１２３を更に含む。スケジューリングルールは、Ｓ＆Ｎアプリケーションが、患者のプロフィール１１０内の情報に基づいて、患者のスケジューリングされた来院を早めるべきか、遅らせるべきか、又は維持するべきかどうかを判定することを可能にすることができる。特定の実施形態では、スケジューリングルールはまた、来院をいつスケジューリングするべきか又は再スケジューリングするべきかについて定義することもできる。通知ルールは、Ｓ＆Ｎアプリケーションが患者に関する通知を生成するべきかどうかを判定することを可能にすることができる。スケジューリングルール及び通知ルールは、例えば、医師によって生成することができる。特定の実施形態では、スケジューリングルール及び通知ルールは、患者固有とすることができる。Ｓ＆Ｎアプリケーション、並びに対応するスケジューリングルール及び通知ルールに関する更なる詳細は、以下で更に説明される。

【0033】

サーバシステム１３０は、クラウドコンピューティング環境（例えば、プライベートクラウド又はパブリッククラウド）において動作可能であり、アプリケーションサービス及び／又は機能を患者監視システム１０４及び／又はアプリケーション１０６に提供することができる。例えば、サーバシステム１３０は、患者監視システム１０４によって生成されたデータを（アプリケーション１０６を介して）受信及び格納し、患者監視システム１０４の動作パラメータを（アプリケーション１０６を介して）監視し、アプリケーション１０６に対する更新を推し進めることなどができる。サーバシステム１３０は、メモリ１３２に格納された１つ以上のソフトウェアアプリケーションを実行するように構成されたプロセッサ１３１を含む。例えば、プロセッサ１３１は、患者の健康データを監視及び分析して、患者の状態の変化に関して患者１０２かつ／若しくは医師に事前対策的にいつ警告するべきか、引き続いて患者の状態の変化に関して患者１０２をいつ追跡するべきか、及び／又はスケジューリングされた来院に関して患者１０２に準備をさせるべきかを判定するように、一般に構成された臨床支援アプリケーションを実行することができる。特定の実施形態では、患者１０２は、アプリケーション１０６を介して、サーバシステム１３０によって提供されたサービスを受けることを選択することができる。例えば、患者１０２がサーバシステム１３０によって提供されたサービスを受けることを選択すると、サーバシステム１３０は、患者のプロフィール１１０内の情報、診療所システム１２０（例えば、データストア１２３）に格納された情報などにアクセスすることが可能であり得る。

【0034】

臨床支援アプリケーションは、サーバシステム１３０が、患者のスケジューリングされた来院より前の期間中の、患者の健康データ（例えば、健康データ１１３）の監視及び分析に基づいて、患者の状態の変化に関して患者１０２及び／又は医師に事前対策的に警告することを可能にすることができる。臨床支援アプリケーションは、ルールのセットを使用して、患者の健康データが患者１０２及び／又は医師に警告するための条件をいつ満たすかを判定することができる。このルールのセットは、（クライアントシステム１２０を介して）医師によって提供された１つ以上の所定のルール、（サーバシステム１３０を介して）人工知能／機械学習（ＡＩ／ＭＬ）技法を使用して生成された１つ以上のルール、又はこれらの組み合わせを含むことができる。

【0035】

特定の実施形態では、臨床支援アプリケーションはまた、サーバシステム１３０が、質問のセットを生成して患者の状態において検出された変化に関して、患者１０２に尋ねることを可能にすることもできる。そのような質問のセットには、標準アンケート（例えば、糖尿病治療満足度アンケート、ＣＧＭ（continuous glucose monitor、連続的グルコース監視）利便性アンケート、ＳＰＯＴＬＩＧＨＴアンケートなどの標準的なアンケート形式）、医師によって提供される１つ以上の所定の質問、ＡＩ／ＭＬ技法を使用して生成される１つ以上の質問、又はこれらの組み合わせからの１つ以上の所定の質問が含まれ得る。

【0036】

追加的に又は代替的に、臨床支援アプリケーションはまた、サーバシステム１３０に、患者のスケジューリングされた来院中に患者１０２が医師に尋ねるための質問のセットを生成することによって、スケジューリングされた来院について患者１０２に事前対策的に準備をさせることを可能にすることができる。そのような質問のセットは、患者のスケジューリングされた来院より前の期間における患者の健康データの分析に基づいて、所定の質問のセットのうちのセットから選択された質問を含むことができる。例えば、患者１０２が患者のスケジューリングされた来院より前の期間において低グルコースレベルを有すると仮定すると、臨床支援アプリケーションは、所定の質問リストから、患者１０２のグルコースレベルに関係する質問を選択して、患者のスケジューリングされた来院中に医師に尋ねることができる。

【0037】

サーバシステム１３０は、臨床支援アプリケーションによって使用される所定のルール及び／又はＡＩ／ＭＬモデル、診療所のスケジュールデータ、患者プロフィール１１０などの、サーバシステム１３０によって使用されるデータを格納するためのデータストア１３３を更に含む。患者１０２及び／又は医師に事前対策的に警告すること、患者の状態における変化に関して患者１０２に尋ねるための質問を生成すること、患者のスケジューリングされた来院について患者１０２に準備をさせるための質問を生成することなどを行うための、サーバシステム１３０によって実行される技法については、以下で更に説明されることに留意されたい。

【0038】

診療所システム１２０、患者デバイス１０７、患者データストア１４０、及びサーバシステム１３０は、ネットワーク１５０を介して、通信可能に結合されている。このネットワーク１５０は、ローカルエリアネットワーク（local area network、ＬＡＮ）、イントラネット、ワイドエリアネットワーク（wide area network、ＷＡＮ）、インターネット、又は、患者デバイス１０７及び診療所システム１２０などの接続されたコンピューティングデバイスの任意の他のグループであってもよい。特定の実施形態では、図示されてはいないが、システム１００において、ネットワーク１５０は、同じ患者若しくは他の患者のための追加の患者デバイス１０７を通信可能に結合し、かつ／又は、同じ診療所若しくは異なる診療所のための追加の診療所コンピューティングシステム１２０を結合する。

【0039】

図２は、本明細書で説明される特定の実施形態による、図１の例示的な健康データシステム１００の患者監視システム１０４及び例示的なモバイルデバイス１０７ａ～１０７ｄの例をより詳細に示している。図１の患者デバイス１０７は、モバイルデバイス１０７ａ～１０７ｄのうちの任意の１つであってもよいことに留意されたい。言い替えると、モバイルデバイス１０７ａ～１０７ｄのうちの任意の１つは、アプリケーション１０６などのアプリケーションを実行するように構成され得る。図２の例では、患者監視システム１０４は、モバイルデバイス１０７ａ～１０７ｄのうちの１つ以上に通信可能に結合されているグルコース監視システムである。ただし、患者監視システム１０４は、患者を監視及び／若しくは処置するために使用され得る任意の他のタイプの生理学的監視システムを代わりに含むか、又はそれに加えて含むことができる。例示的な生理学的監視システムは、電気的又は光学的心拍数監視システム、パルス酸素濃度計、体温監視装置、血圧監視装置、水分補給監視装置、様々な分析物センサ（例えば、乳酸塩センサ、ケトンセンサ、グルコースセンサ、コレステロールセンサなど）などを含み、それらは、とりわけ、血糖、体温、健康状態、栄養詳細、薬物投与計画、コレステロール、血圧、心拍数、及び心臓電気活動（例えば、electrical cardiac activity、ＥＣＧ）などのバイオマーカー（バイオメトリックマーカーとも称される）又は解剖学的パラメータを測定するように構成される。

【0040】

概要及び例として、患者監視システム１０４がグルコース監視システム２０４と仮定すると、グルコース監視システム２０４は、マイクロコントローラとして実装することができ、そのマイクロコントローラは、センサ測定を実行し、（例えば、連続的なグルコース監視データについての値を計算することによって）分析物データを生成し、かつ（例えば、Ｂｌｕｅｔｏｏｔｈ及び／又は他の無線プロトコルを介して）無線通信と結合して、そのようなデータをモバイルデバイス１０７ａ～１０７ｄのうちの１つ以上などの遠隔デバイスに送信する。特定の実施形態では、皮膚上センサアセンブリ又は植え込み型センサアセンブリなどの様々なグルコースセンサが、グルコース監視システム２０４と関連して使用される。

【0041】

特定の実施形態では、グルコース監視システム２０４は、センサ電子機器モジュール２３８、及びそのセンサ電子機器モジュール２３８と関連付けられたグルコースセンサ２３９を含む。特定の実施形態では、センサ電子機器モジュール２３８は、グルコースセンサ２３９によって生成されたセンサデータ又は情報の測定及び処理と関連付けられた電子回路を含み、そのセンサデータ／情報の測定及び処理と関連付けられたアルゴリズムを含む。センサ電子機器モジュール２３８は、グルコースセンサ２３９に電気的かつ機械的に接続されており、グルコースセンサ２３９に統合化され得る（すなわち、取り外し不可能に取り付けられる）か、又は取り外し可能に取り付けられ得る。

【0042】

センサ電子機器モジュール２３８は、ハードウェア、ファームウェア、並びに／又は、グルコースセンサ２３９を介して患者のグルコースレベルの測定及び／若しくは推定を可能にするソフトウェアを含む。例えば、センサ電子機器モジュール２３８は、電力をグルコースセンサ２３９に供給するための電源、信号処理及びデータ格納に有用な他の構成要素、及びセンサ電子機器モジュール２３８から１つ以上の表示デバイスにデータを送信するための遠隔計測モジュールを含むことができる。電子機器は、グルコース監視システム２０４内のプリント回路基板（printed circuit board、ＰＣＢ）又はプラットフォームなどに取り付けられ得、様々な形態を採ることができる。例えば、電子機器は、特定用途向け集積回路（Application-Specific Integrated Circuit、ＡＳＩＣ）などの集積回路（integrated circuit、ＩＣ）、マイクロコントローラ、プロセッサ、及び／又はステートマシンの形態を採ることができる。

【0043】

センサ電子機器モジュール２３８は、センサデータなどのセンサ情報を処理し、かつ変換されたセンサデータ、及び表示可能なセンサ情報を生成するように構成されているセンサ電子機器を含むことができる。グルコースセンサ２３９は、患者１０２内のグルコースの濃度又はレベルを測定するように構成されている。特定の実施形態では、グルコースセンサ２３９は、皮下、経皮（例えば、経皮性のある）、又は血管内のデバイスなど、連続的なグルコースセンサを含む。グルコースセンサ２３９は、酵素法、化学法、物理法、電気化学法、分光測光法、旋光分析法、熱量測定法、イオン泳動法、放射分析法、免疫化学法などを含む、任意のグルコース測定法を使用することができる。

【0044】

更に図２を参照すると、モバイルデバイス１０７ａ～１０７ｄのうちの１つ以上は、センサ電子機器モジュール２３８によって送信され得る表示可能なセンサ情報を（例えば、それぞれの選好に基づいて表示デバイスに送信されるカスタマイズされたデータパッケージにおいて）表示（及び／又は警告）するように構成され得る。モバイルデバイス１０７ａ～１０７ｄは、それぞれ、アプリケーション１０６のグラフィカルＵＩを表示するための、タッチ画面ディスプレイ１０９ａ～１０９ｄなどのディスプレイを含み、このディスプレイは、センサ情報及び／又はデータを患者１０２に提示し、患者１０２から入力を受信し、かつ／若しくは患者プロフィール１１０の詳細を更新することができる。特定の実施形態では、アプリケーション１０６のグラフィカルＵＩは、患者１０２が患者の状態における変化に関して回答するための質問を提示し、提示された質問に対する患者１０２からの回答を受信し、スケジューリングされた来院中にユーザが医師に尋ねるための質問を提示することができる。特定の実施形態では、モバイルデバイスは、センサ情報をモバイルデバイスの患者１０２に伝達し、かつ／若しくはユーザ入力を受信するためのタッチ画面ディスプレイの代わりに、など又はそれに加えて、オーディオインターフェースなどの他のタイプのユーザインターフェースを含む。特定の実施形態では、モバイルデバイス１０７ａ～１０７ｄのうちの１つ、いくつか、若しくは全ては、センサデータの較正及び／又はリアルタイム表示のために要求されるいかなる追加の予想される処理を伴わずに、センサ情報がセンサ電子機器モジュール２３８から伝達されたときに（例えば、それぞれの表示デバイスに送信されるデータパッケージ内で）、そのセンサ情報を表示若しくは伝達するように構成されている。

【0045】

図２に図示されるモバイルデバイス１０７ａ～１０７ｄのうちの１つ以上は、カスタム又は独自開発の表示デバイス、例えば、センサ電子機器モジュール２３８から受信されたデータと関連付けられた特定のタイプの表示可能なセンサ情報（例えば、特定の実施形態では、数値及び／又は矢印）を表示するように特に設計された分析物表示デバイス１０７ｂを含むことができる。特定の実施形態では、モバイルデバイス１０７ａ～１０７ｄのうちの１つ以上は、Ａｎｄｒｏｉｄ、ｉＯＳ、又は（例えば、現在及び／又は履歴データを含む）連続的なセンサデータのグラフィカル表現を表示するように構成された別のオペレーティングシステムに基づく、携帯電話１０７ｃなどのスマートフォンを含む。

【0046】

上で紹介したように、診療所システム１２０は、患者に関する通知を生成するべきかどうかを判定するための通知ルール、及び、患者のスケジューリングされた来院を早めるか、遅らせるか、又は維持することができるかどうかを判定するためのスケジューリングルールを採用する。そのようなルールを生成及び編集するために使用されるＵＩの例が、図３に関して提供される。

【0047】

図３は、医師がルール（例えば、通知ルール及び／又はスケジューリングルール）を生成及び／又は修正して、健康データ１１３及びスケジュール情報１１５などの、患者プロフィール１１０内に格納された情報を患者に問い合わせることを可能にする例示的なＵＩ３００を示している。特定の実施形態では、このＵＩ３００は、診療所システム１２０の表示デバイス上に表示するためのＳ＆Ｎアプリケーションによって提供され得る。ＵＩ３３０は、複数のフィールドを提供することができ、それらのフィールドは、ルールを作成／修正すること、各ルールがどの１人以上の患者に適用するかを識別すること、並びに、ある状態、その状態が発生した場合／発生したときに取るべき対応動作、及び各ルールについての関連する詳細のうちの１つ以上を定義することを可能にする。

【0048】

図３の例示的なＵＩ３００は、ユーザが通知ルール並びにスケジューリングルールの両方であるルールを作成することを可能にする。上で考察されたように、ＵＩ３００を通じて作成された通知ルールは、診療所システム１２０によって使用されて、患者について医師にいつ通知するべきかを判定することができる。例えば、診療所システム１２０は、ユーザによって作成された条件（例えば、フィールド３０６Ａ～３０６Ｃによって示されているように）を患者のプロフィール内の情報に適用して、医師が患者の状態について通知されるべきかどうか／いつ通知されるべきかを確認することができる。これに対して、ＵＩ３００を通じて作成されたスケジューリングルールは、診療所システム１２０によって使用されて、患者の来院を再スケジューリングするべきかどうか／いつ再スケジューリングするべきかを判定することができる。例えば、診療所システム１２０は、ユーザによって作成された条件（例えば、フィールド３０６Ａ～３０６Ｃ及び３１２～３１６によって示されているように）を患者のプロフィール内の情報に適用して、患者の来院を再スケジューリングするべきか否かを確認することができる。ＵＩ３００を通じて作成されたルールは、そのルールが、通知並びに再スケジューリングが行われる必要があるかどうか／いつ行われる必要があるかについての条件を定義するため、通知ルール並びにスケジューリングルールの両方である。

【0049】

図に示すように、ＵＩ３００は、ＵＩ３００を介して作成又は修正されているルールと関連付けられた名前についてのフィールド３０２を含む。医師は、フィールド３０２を使用して、任意の英数字の名前を入力して、ルールを一意に識別することができる。フィールド３０４において、医師は、ルールが適用される（例えば、患者データストア１４０に格納された患者プロフィール１１０を有する）１つ以上の患者のグループを識別することができる。場合によっては、医師は、全ての診療所患者（図３に示すように）、その医師のための患者のみ、その診療所の特定の患者、次回の期間内にスケジューリングされた来院を有する患者などを識別する。特定の実施形態では、フィールド３０４は、複数の利用可能な選択項目を有するドロップダウンメニューを含む。スケジューリングルールの場合、フィールド３０４は、指定された期間内にスケジューリングされた来院を有する患者の識別を可能にすることができる。図３の例示的なＵＩ３００に示されているように、ルールは、フィールド３０２において「緊急度低い」と名前が付けられ、フィールド３０４において「全患者」に適用されている。

【0050】

ＵＩ３００は、医師がルールについて特定の条件を識別するフィールド３０６Ａ～Ｃを更に含む。より具体的には、フィールド３０６は、医師がフィールド３０２内に名前が付けられたルールがフィールド３０４の識別された患者にいつ適用されることになるかについての条件を確立することを可能にする。例えば、それらの条件は、（１）医師への通知がプロセッサ１２１によって患者について生成されるべきであること、及び（２）患者のスケジューリングされた来院が再スケジューリングされるべきであること、の状況を定義する。

【0051】

フィールド３０６Ａは、医師が「血糖」、「推定されたＨｂＡ１ｃ（ｅＡ１ｃ）」、「体重」、「インスリン」などのバイオマーカーを識別することを可能にする。フィールド３０６Ｂは、医師が「以下」、「以上」、「下回る」、「上回る」「同等」などの比較器、及びバイオマーカー閾値を定義することを更に可能にする。フィールド３０６Ｃは、各フィールドについて複数の利用可能な選択項目を有するドロップダウンメニューを提供する。特定の実施形態では、フィールド３０６の比較器及び／又は閾値についての利用可能な選択項目は、選択されたバイオマーカーに依存してもよく、その場合、異なるバイオマーカーは、比較器及びバイオマーカー閾値についての異なる利用可能な選択項目を有する。特定の実施形態では、バイオマーカー閾値は、患者のプロフィール１１０（例えば、患者の健康データ１１３など）によって示されるような患者の特定の健康状況及び病歴に基づいて、又は同様の患者と関連付けられた母集団健康データに基づいて確立される。例えば、５５歳である糖尿病患者についての血糖バイオマーカー閾値は、年齢が５０～６０歳の多数の他の糖尿病患者についての平均血糖レベルに基づいて生成されてもよい。図３の例示的なＵＩ３００に示されているように、ルールは、フィールド３０６Ｂ内の比較器「≦」、及びフィールド３０６Ｃにおける対応する値「５５ｍｇ／ｄＬ」を用いて、フィールド３０６Ａにおける「血糖」のバイオマーカーを識別する。

【0052】

フィールド３０８Ａは、医師が、ルールが適用する持続時間を確立することを可能にする。例えば、医師は、ルールが解除されるまで適用されることを意味する「無条件」又は「常時」、ルールが所定の時間の間適用されることを意味する「［ｆ］又は少なくとも．．．」などとして、持続時間を確立することができる。フィールド３０８Ｂは、医師がフィールド３０８Ａにおける「無条件」又は「常時」以外の選択項目のための持続時間を定義することを可能にする。フィールド３０８Ａ及び３０８Ｂは、選択項目が医師によって行われるドロップダウンメニューを含むことができる。図３の例示的なＵＩ３００に示されているように、ルールは、フィールド３０８Ｂにおいて持続時間が識別されない状態で、フィールド３０８Ａにおいて持続時間を「常時」として識別する。

【0053】

ＵＩ３００は、フィールド３１０を更に提供することができ、これは、ドロップダウンメニューから医師によって選択されるように、定義されたルールの緊急度の選択を可能にする。この緊急度は、ルールに基づいて生成された任意の通知の緊急度インジケータのうちの１つ以上、又は通知がどのくらい迅速に生成され、かつ医師に伝えられるかを識別することができる。緊急度選択項目は、「非常に高い」、「高い」、「中程度」、「低い」、「非常に低い」などを含むことができる。図３の例示的なＵＩ３００に示されているように、ルールは、フィールド３１０において緊急度を「高い」として識別している。

【0054】

ＵＩ３００は、適宜、患者来院を再スケジューリングするための条件を定義するためのフィールドを更に提供する。例えば、フィールド３１２～３１６は、フィールド３０６Ａ～３０６Ｃによって定義されているように、健康関連条件が満たされた場合に、既存の患者来院をいつ再スケジューリングするべきかを更に定義することができる。例えば、医師は、フィールド３１２（例えば、セレクタボックス）を使用して、既存の患者来院の再スケジューリングを可能にする。フィールド３１２が再スケジューリングを可能にするときに、医師は、フィールド３１４を使用して、どんな来院を再スケジューリングするべきか（例えば、２日間などの特定の期間内にスケジューリングされる来院）を識別し、フィールド３１６を使用して、来院が再スケジューリングされ得る時間の枠（例えば、「ＡＳＡＰ」、「次週」、「来月」など）を識別する。図３に示されている例では、フィールド３１２の選択項目は、患者の来院を再スケジューリングするための条件を定義する。フィールド３１２が選択されない場合、ＵＩ３００を通じて作成されたルールは、通知のみのルールとなるであろう。ただし、フィールド３１２を選択することは、ルールを通知ルール及びスケジューリングルールに変換する。フィールド３１４は、患者の来院が３日以上先にスケジューリングされている場合、フィールド３１６を使用して医師によって選択されるように、患者来院が「ＡＳＡＰ」に再スケジューリングされる必要があることを示している。言い替えると、図３は、患者の状態が悪化しており、患者が次の２日間内に医師を訪問することを未だスケジューリングしていない場合に、患者の来院を早めるルールの例を示している。

【0055】

ＵＩ３００は、詳細セレクタ３１７及び設定セレクタ３１８を更に含むことができる。この詳細セレクタ３１７は、医師がフィールド３１０の緊急度選択項目の詳細など、ルールについての詳細を選択することを可能にすることができる。そのような詳細の例としては、通知が医師に提供され得る方式（例えば、識別された電話番号で、１つ以上の電子メールアドレスでの電子メール通知で、通知ルールに基づいて連絡される医師の名前及び連絡先情報などで）が挙げられる。この設定セレクタ３１８は、表示設定、表示単位などの様々なＵＩ３００設定の選択を可能にする。

【0056】

特定の実施形態では、ＵＩ３００は、特定の医師又は診療所についての既存のルールを示す画面又は部分３２０を含むことができる。この画面３２０は、既存のルールの様相の概要、及び各既存のルールの様相を編集するか、又は各既存のルールを削除するためのオプションを示すことができる。上で紹介したように、選択されたバイオマーカーは、フィールド３０６の比較器及び／又はバイオマーカー閾値についての利用可能な選択項目を判定する。更に、選択されたバイオマーカーの利用可能な範囲又は値は、スケジューリングされた来院までの時間量に基づいて変化する可能性がある。例えば、患者の来院が１ヶ月離れている場合、患者の来院が１週間離れている場合と比較して、より多くの閾値バイオマーカー値が、選択について利用可能であり得る。ＵＩ３００は、ドロップダウンメニュー及び選択項目ボックスを図示しているが、ＵＩ３００は、様々なモードのユーザデータ入力及び選択項目を利用することができる。

【0057】

図３は、ルールを作成するための、ＵＩ３００の一例のみを示していることに留意されたい。他の例では、ＵＩは、スケジューリングルールのみを作成するために提供され得る。更に他の例では、ＵＩは、通知ルールのみを作成するために提供され得る。更に他の例では、サーバシステム１３０は、患者１０２についての通知ルール及び／又はスケジューリングルールを提供（又は生成）することができる。そのような例では、サーバシステム１３０は、１つ以上のＡＩ／ＭＬ技法を使用して、フィールド３０６Ａ～３０６Ｃ及び３１２～３１６に自動的に値を代入し、患者１０２についての通知ルール及び／又はスケジューリングルールを作成することができる。また、図３は、ルール（この場合、通知ルール及びスケジューリングルール）の一例のみを示している。１人以上の患者の健康／状態を（例えば、連続的、定期的などに基づいて）自動的に監視するための多種多様なルールが作成され得、医師かつ／若しくは患者１０２にいつ／通知するべきかどうか、及び／又は１人以上の患者の来院をいつ／再スケジューリングするべきかどうかを判定することができる。

【0058】

診療所システム１２０は、Ｓ＆Ｎアプリケーションを使用して、患者のプロフィール１１０内に提供される情報を（例えば、連続的に、定期的に、要求に応じてなど）検査することによって患者の健康及び状態を監視することができ、対応する医師に通知すること、及び／又は、ルールによって定義されるように任意の患者来院をスケジューリング若しくは再スケジューリングすることを目的として、患者に対して定義されている対応するルールを適用することができる。診療所システム１２０は、ルールを、定期的に、連続的に、又は要求に応じて、患者プロフィール１１０に適用することができる。例えば、診療所システム１２０は、定義された将来の期間中にスケジューリングされた来院を有する患者の患者プロフィール１１０内の健康データ１１３及びスケジュール情報１１５を再検討して、スケジューリングされた来院が維持されるべきか又は再スケジューリングされるべきかどうかを判定することができる。スケジュール情報１１５及び健康データ１１３の詳細に基づいて、診療所システム１２０は、スケジューリングされた来院が再スケジューリングされるべきであるそれらの患者を識別することができる。更なる詳細は、以下の図４に関して以下に提供される。

【0059】

図４は、本明細書に説明される実施形態による、ルールを患者データに適用するために実行される動作４００のフローチャートを示している。例えば、動作４００は、上で紹介されたＳ＆Ｎアプリケーションを使用して、診療所システム１２０によって適用されたアルゴリズムの少なくとも一部に対応する。動作４００のブロックは、図１の診療所システム１２０によって実行されるものとして本明細書に説明されているが、動作４００は、異なる構成要素を有する任意の他のシステム又は診療所システムによって同様に実行することができることに留意されたい。

【0060】

ブロック４０５において、診療所システム１２０は、１つ以上のルールを自動的に適用するためのトリガーを識別する。このトリガーは、データストア１４０内の１つ以上の患者プロフィールに格納されている新しい健康データ、スケジューリングされたイベント、医師からの要求などのうちの１つ以上に基づいて生成され得る。例えば、スケジューリングされたイベントは、次週の間にスケジューリングされた患者来院を有する患者を識別するための、自動的な毎日の再検討を含んでもよい。この毎日の再検討は、次週にスケジューリングされた来院を有する識別された患者についての患者健康データ１１３に、１つ以上のルールの適用を自動的にトリガーすることができる。この例では、毎日、例えば、次の７日間にスケジューリングされた来院を有する患者が、自動的に識別され、１つ以上のルールが、その識別された患者に自動的に適用される。

【0061】

ブロック４１０において、診療所システム１２０は、識別されたルールを、例えば、データストア１２３からロードする。ルールが一度に１つ適用される場合、ルールは、別々にロードされてもよい。複数のルールが並列に一度に適用される場合（図示せず）、複数のルールは、並列にロードすることができる。例えば、（例えば、図３のフィールド３０６Ａにおける）体温のバイオマーカーを有するルール、及び血糖のバイオマーカーを有するルールは、患者の体温及び血糖が患者来院を再スケジューリングする際に両方とも考慮される可能性があるため、（例えば、図３のフィールド３０４における）同じ識別された患者のグループに並列に適用され得る。したがって、ルールが両方とも同じ患者に適用される場合、並列のアプリケーションは、同じ患者データを複数回ロードすることを省くことができる。ルールは、以下で更に説明されるように、プロセッサ１２１による患者データへの適用のために、メモリ１２２にロードされ得る。

【0062】

ブロック４１５において、診療所システム１２０は、ロードされたルールが適用される現在の患者についてのそれぞれの健康データ（例えば、健康データ１１３）を、例えば、現在の患者のプロフィール１１０からメモリ１２２にロードする。例えば、診療所システム１２０は、患者が患者の識別された患者のグループの一部であると判定することに基づいて、ロードされたルールが現在の患者に適用すると判定することができる。ルールが「全ての患者」を示す場合、診療所システム１２０は、診療所の各患者についての健康データを１つずつロードすることができる。ルールが「糖尿病患者」を識別する場合、診療所システム１２０は、患者のプロフィール１１０において識別されたときに、診療所の糖尿病患者の各々についての健康データを１つずつロードすることができる。特定の実施形態では、ロードされた健康データは、ロードされたルールの１つ以上の条件のバイオマーカーに関連するデータポイント、傾向などを含む。例えば、ルールによって識別されたバイオマーカーが血糖である場合、患者についてのロードされた健康データは、患者の最新の血糖レベル、又は、患者の最新の血糖レベルの最近の傾向示す傾向データのうちの少なくとも１つ以上を含むことができる。

【0063】

ブロック４２０において、診療所システム１２０は、ロードされたルールを、メモリ１２２にロードされた患者データに適用する。特定の実施形態では、ロードされたルールを、ロードされた患者データに適用することは、ルールによって識別されたバイオマーカー（例えば、図３のフィールド３０６Ａにおける）についてのロードされた患者健康からのメトリック値を、定義された比較器、及びロードされたルールからの対応する値（例えば、図３のフィールド３０６Ｂ及び３０６Ｃからの）と比較することを含む。例えば、図３のＵＩ３００は、「血糖」というバイオマーカー、並びに比較器、及び「５５ｍｇ／ｄＬ以上」という対応する値を有するルールを示している。このルールを、ロードされたルールとして、ロードされた患者データに適用することは、比較器「以上」を使用して、患者の血糖レベル（例えば、最新の血糖レベル、又は直前の特定の数の血糖レベルの平均）を、５５ｍｇ／ｄＬと比較することを含む。特定の実施形態では、メトリック値を比較することは、単一データポイント、又は複数のデータポイントに基づいて生成された傾向を、バイオマーカーに対して比較することを含む。

【0064】

ブロック４２５において、診療所システム１２０は、ブロック４２０におけるルールの適用に基づいて、現在の患者についての来院を再スケジューリングするべきか又は医師に通知するべきかどうかを判定する。ロードされたルールが通知ルールである場合、診療所システム１２０は、ブロック４２０に基づいて医師に通知するべきかどうかを判定する。ロードされたルールがスケジューリングルールである場合、診療所システム１２０は、ブロック４２０に基づいて来院を再スケジューリングするべきかどうかを判定する。ロードされたルールが通知ルール及びスケジューリングルールの両方である場合、診療所システム１２０は、ブロック４２０に基づいて、医師に通知し、かつ来院を再スケジューリングするべきかどうかを判定する。

【0065】

一例として、ルールがバイオマーカーとして「血糖」を識別し、かつ、比較器及び対応する値が「上回る」及び「２００ｍｇ／ｄＬ」である場合、診療所システム１２０は、例えば、患者についてロードされた健康データからの最新の血糖レベル、又は最近のグルコースデータ測定値の平均が、２００ｍｇ／ｄＬバイオマーカー閾値を超えるかどうかを判定する。患者の血糖レベルが２００ｍｇ／ｄＬを上回り、かつ患者のスケジューリングされた来院が外科的処置である場合、手術中の高血糖レベルは、より高い感染リスクをもたらす可能性があり、診療所システム１２０は、外科的処置をより遅い日付に再スケジューリングして、患者の血糖レベルを、許容できる値に低減する時間を与えることができる。

【0066】

別の例では、ルールがバイオマーカーとして「血糖」を識別し、かつ、比較器及び対応する値が「１５０ｍｇ／ｄＬを下回り、かつ９０ｍｇ／ｄＬを上回る」場合、診療所システム１２０は、患者についてロードされた健康データからの最新の血糖レベル又は健康データが当該範囲内に入るかどうかを判定する。そうである場合、当該範囲内の血糖レベルは、患者の血糖レベルが予想された又は健康な状態にあることを示し得る。したがって、患者の来院が患者のグルコースレベルに対処する医師にとって単なる通常の来院である場合、診療所システム１２０は、患者の血糖レベルが概ね予想された範囲にあることを前提として、来院をより遅い日付に再スケジューリングすることができる。

【0067】

更に別の例では、ルールがバイオマーカーとして「血糖」を識別し、かつ、比較器及び対応する値が「下回る」及び「５５ｍｇ／ｄＬ」である場合、診療所システム１２０は、例えば、患者についてロードされた健康データからの最新の血糖レベル又は最近のグルコースデータ測定値の平均が、５５ｍｇ／ｄＬバイオマーカー閾値を下回るかどうかを判定する。５５ｍｇ／ｄＬを下回る血糖レベルは、患者の血糖レベルが懸念すべきレベルにあることを示し得るため、診療所システム１２０は、懸念を前提として、患者の来院をより早い日付に再スケジューリングすることができる。特定の例では、この状況にある患者は、スケジューリングされた予約さえも全く有していない場合がある。そのような例では、診療所システム１２０は、患者の血糖レベルが関係していると判定したときに、診療所システム１２０は、その患者について最初の利用可能な予約を（例えば、自動的に）スケジューリングすることができる。

【0068】

ブロック４３０において、診療所システム１２０は、患者の来院を再スケジューリングし、かつ／又は医師に通知する。例えば、患者の来院を再スケジューリングすることは、診療所システム１２０が、データストア１２３内の診療所のスケジュールデータから、患者の来院に適切である次回の利用可能な日時を識別することを含むことができる。例として、ルールが、来院が将来の２週間を超える間に再スケジューリングされるべきであると定義する場合、Ｓ＆Ｎアプリケーションを実行する診療所システム１２０は、将来の２週間を超えるスケジュールデータから次回の利用可能な日時を識別することができる。

【0069】

特定の実施形態では、診療所システム１２０は、来院を自動的に再スケジューリングすることができ、特定の他の実施形態では、診療所システム１２０は、医師からの確認を受信することに応答して、来院を自動的に再スケジューリングすることができる。例えば、来院を再スケジューリングすると判定した後に、診療所システム１２０は、提案された再スケジューリングに関する情報を含み、かつ医師が再スケジューリングされた来院を確認又は承認することを要求するメッセージを、医師に対して生成することができる。特定の実施形態では、このメッセージは、来院が何のためのものであるか、関連付けられたバイオマーカーなどの、来院の詳細とともに、例えば、カレンダー上に、現在のスケジューリングされた来院の視覚的表示を含むことができる。このメッセージは、ブロック４２０において行われた比較の結果を含む、来院が再スケジューリングされている理由に関する詳細とともに、カレンダー上などに、提案された再スケジューリングされた来院の視覚的表示を更に含むことができる。特定の実施形態では、視覚的表示は、現在のスケジューリングされた来院が、提案された再スケジューリングされた来院に置き換えられるか又は再スケジューリングされるように提案されていることを示すことができる。

【0070】

メッセージが医師に送信されると、診療所システム１２０は、医師からの確認を受信して来院を再スケジューリングすることができ、それに応答して、診療所システム１２０は、来院を再スケジューリングし、データストア１２３内のスケジュールデータ、及び、患者のプロフィール１１０内のスケジュール情報１１５を、再スケジューリングされた来院とともに更新することができる。特定の実施形態では、データストア１２３内のスケジュールデータ、及び、患者プロフィール１１０内のスケジュール情報１１５を更新すると、診療所システムは、患者の来院が再スケジューリングされていることを示すメッセージを患者に対して生成することができる。患者の来院の再スケジューリングを引き起こす条件の例は、来院を早めるか又は来院を遅らせるための状況について、以下に提供される。

【0071】

特定の実施形態では、Ｓ＆Ｎアプリケーションを実行する診療所システム１２０は、例えば、ロードされたルールの詳細３１７に基づいて、医師への通知を生成することができる。

【0072】

ブロック４３５において、診療所システム１２０は、ロードされたルールが任意の追加の患者に適用可能であるかどうかを判定する。例えば、ロードされたルールが現在の患者についてロードされた健康データに適用された場合、診療所システム１２０は、ロードされたルールが任意の追加の患者に適用されるべきかどうかを判定する。ロードされたルールが追加の患者に適用可能である場合、動作４００は、ブロック４３５に進む。そうでない場合、動作４００は、ブロック４４０に進む。

【0073】

ブロック４４０において、診療所システム１２０は、ロードされたルールが適応される次の患者についての次の健康データを、対応する患者プロフィール１１０からメモリ１２２にロードする。ブロック４２０及び４２５は、次の患者、及び次の患者のロードされた健康データについて、繰り返される。ブロック４２０～４３５は、ロードされたルールが全ての関連患者に適用されるまで、ロードされたルールが適用される全ての後続の患者について繰り返され、その時点で、動作４００は、ブロック４４０に進む。

【0074】

ブロック４４５において、診療所システム１２０は、メモリ１２２にロードして、患者健康データに対して適用するための追加のルールが存在するかどうか判定する。ロードするための追加のルールが存在する場合、動作４００は、ブロック４４５に進む。ロードするための追加のルールが存在しない場合、動作４００は、終了する。

【0075】

ブロック４５０において、診療所システム１２０は、次のルールをデータストア１２３からメモリ１２２にロードする。次のルールがロードされると、動作４００は、次のルール（及びメモリ１２２にロードされた後続の各ルール）についてブロック４１５～４４５を繰り返し、この動作は、ブロック４２０～４３５に関して上述したように、各ルールを各対応する患者健康データに適用することを含む。

【0076】

図５は、本明細書に説明される特定の実施形態による、患者の健康を監視して、１つ以上の条件が満たされるかどうかに基づいて患者の健康について医師に通知し、かつ／又は、患者の来院をスケジューリング／再スケジューリングするために行われる動作５００のフローチャートを示している。この動作５００は、診療所システム１２０によって行うことができる。

【0077】

ブロック５１０において、診療所システム１２０は、患者についての患者データを受信する。この患者データは、患者健康データ１１３などの患者健康データ（例えば、少なくとも（例えば、ある期間にわたって監視システムによって測定されるような）血糖などの、バイオマーカーについてのグルコース測定値などのメトリック値）を含むことができる。患者データは、将来のデータに関して、患者について既にスケジューリングされている来院についての情報を更に含むことができる。来院についての情報は、日時情報、及び関連する患者状態の詳細などを含み得る。ブロック５１０の動作と関連付けられた更なる詳細については、図４のブロック４１５に関連して説明された。

【0078】

ブロック５２０において、診療所システム１２０は、バイオマーカーについてのメトリック値がルールの条件を満たすと判定する。上述したように、それらの条件は、医師によって患者について、上述したように作成されるルールによって定義されてもよい。図３の例では、条件は、フィールド３０６Ａ～３０６Ｃ内に定義された条件に対応する。ブロック５２０の動作と関連付けられた更なる詳細については、図４のブロック４１０に関連して説明された。

【0079】

ブロック５３０において、診療所システム１２０は、メトリック値が条件を満たすと判定すると、任意選択的に（例えば、自動的に）通知を生成し、その通知を医師に送信する。通知は、メトリック値がそれらの条件を満たすという指標を含むことができる。通知はまた、提案された再スケジューリングされた来院を含むこともできる。ブロック５３０の動作と関連付けられた更なる詳細については、図４のブロック４３０に関連して説明された。

【0080】

ブロック５４０において、診療所システム１２０は、患者の来院をスケジューリングするか、又はスケジューリングされた来院を再スケジューリングする。特定の実施形態では、診療所システム１２０は、患者データからのバイオマーカーについてのメトリック値が条件を満たすと判定すると、スケジューリング又は再スケジューリングを自動的に実行する。特定の実施形態では、診療所システム１２０は、ブロック５４０において医師に送信された通知に応答して医師から確認を受信すると、スケジューリング又は再スケジューリングを実行する。ブロック５１０の動作と関連付けられた更なる詳細については、図４のブロック４３０に関連して説明された。

【0081】

図６は、本明細書に説明される特定の実施形態による、患者の健康を監視して、その患者の健康の変化について患者及び／又は医師に事前対策的に警告するために行われる動作６００のフローチャートを示している。動作６００は、サーバシステム１３０によって実行することができる。

【0082】

ブロック６１０において、サーバシステム１３０は、患者についての患者データを受信する。この患者データは、患者のプロフィール（例えば、患者プロフィール１１０）内の任意の情報を含み得る。例えば、サーバシステム１３０は、連続的、定期的、又は要求に応じた原則のうちの１つ以上に基づいて、患者の健康データ（例えば、健康データ１１３）を受信することができる。特定の実施形態では、サーバシステム１３０は、ある期間（例えば、患者の医師へのスケジューリングされた来院より前の期間、患者の最後のスケジューリングされた来院と、患者の次回のスケジューリングされた来院との間の期間など）における患者データを受信することができる。その期間は、７～１４日又は何らかの他の期間であってもよい。患者の健康データは、（ある期間にわたって監視システムによって測定されるような）血糖測定値など、バイオマーカーについての少なくとも１つのメトリック値を含み得る。例えば、患者のグルコース測定値を示すメトリックは、絶対グルコース値、ある期間にわたる平均グルコース値、期間にわたるグルコース値の標準偏差、期間にわたるグルコース管理インジケータ（ＧＭＩ）、期間にわたるヘモグロビンＡ１Ｃ（ＨｂＡ１ｃ）などを含み得る。サーバシステム１３０はまた、患者のスケジューリング情報（例えば、患者の次回の医師へのスケジューリングされた来院の指標を含むスケジューリング情報１１５）を受信することもできる。

【0083】

ブロック６２０において、サーバシステム１３０は、バイオマーカーについてのメトリック値が１つ以上の条件を満たすと判定する。特定の実施形態では、１つ以上の条件のうちの少なくとも１つが、閾値を上回る範囲内時間（time in range、ＴＩＲ）を有するメトリック値に基づく。例えば、サーバシステム１３０は、患者の絶対グルコース値が時間の５％を超える範囲外にある（例えば、ＴＩＲが９５％を下回る）と判定することができる。特定の他の実施形態では、条件は、特定の閾値を超える高血糖メトリック（例えば、高血糖レベル）に基づく。特定の他の実施形態では、条件は、特定の閾値を超える低血糖メトリック（例えば、低血糖レベル）に基づく。特定の他の実施形態では、条件は、ＨｂＡ１ｃが閾値を超えることに基づく。例えば、サーバシステム１３０は、患者のＨｂＡ１ｃが、以前のＨｂＡ１ｃを閾値より大きく（例えば、０．４％だけ高く）超えていると判定することができる。別の例では、サーバシステム１３０は、患者が閾値（例えば、０．５％）を超えるＧＭＩの増加を有すると判定することができる。特定の他の実施形態では、条件は、異なる期間における、バイオマーカーについてのメトリック値の比較に基づく。例えば、サーバシステム１３０は、第１の期間中の患者の絶対グルコース値と、第２の期間中の患者の絶対グルコース値との間の比較が閾値を超えると判定することができる。

【0084】

ブロック６３０において、サーバシステム１３０は、その判定に基づいて、第１の通知を生成して患者に送信し、第２の通知を生成して医師に送信する。第１の通知は、患者の健康における懸念すべき変化が検出されているという指標を含むことができる。第２の通知はまた、患者の健康における特定の変化の指標（例えば、条件を満たすメトリック値の指標）とともに、患者の健康における懸念すべき変化が検出されているという指標を含むこともできる。典型的な第２の通知は、「患者は、低血糖範囲に費やされた時間の増加を経験している」、「患者は、制御の改善を示唆する、低血糖範囲に費やされた時間の減少を経験している」、又は「患者は、制御の悪化を示唆する、ＧＭＩ＞０．５％の増加を有している」ことを示すことができる。特定の実施形態では、第２の通知を医師に送信するのではなく、サーバシステム１３０は、患者の健康における特定の変化の指標とともに、患者の健康における懸念すべき変化が検出されているという指標を含むレポートを生成することができる。そのような実施形態では、このレポートは、（例えば、患者のスケジューリングされた来院より前又は来院中に）医師に対して表示又は提供することができる。

【0085】

ブロック６４０において、サーバシステム１３０は、その判定に関して患者１０２に尋ねるための質問のセット（例えば、質問情報１１６）を生成する。特定の実施形態では、サーバシステム１３０は、標準アンケート（例えば、糖尿病治療満足度アンケート、ＣＧＭ利便性アンケート、ＳＰＯＴＬＩＧＨＴアンケートなど）からの所定の質問のセットを患者１０２に提示することができる。特定の実施形態では、サーバシステム１３０は、ＡＩ／ＭＬ技法を使用して生成された質問のセットを患者１０２に提示することができる。選択／生成された質問のセットを使用して、判定のための潜在的な原因に関する情報を取得することができる。例えば、患者がある期間中に低血糖の増加を有していると仮定すると、サーバシステム１３０は、その期間中の摂食量、その期間中の活動、患者監視システム１０４の動作ステータス（例えば、患者監視システム１０４が機能不良となっているか、又は適切に動作しているかどうか）などについて患者に問い合わせることができる。

【0086】

ブロック６５０において、サーバシステム１３０は、質問のセットに対する１つ以上の回答を受信し、それらの回答を、（ｉ）医師と関連付けられたコンピューティングシステム（例えば、診療所システム１２０）、又は（ｉｉ）ストレージシステム（例えば、患者データストア１４０）のうちの少なくとも１つに送信する。患者の健康の変化に関するユーザからのフィードバックとともに、特定の条件を満たす患者の健康の変化の指標を医師に提供することによって、本明細書の特定の実施形態は、医師が、患者が患者のスケジューリングされた来院中に経験している可能性がある問題に関して、集中的な決定を行い、患者との集中的な議論を実行することを可能にする。

【0087】

図７は、本明細書に説明される特定の実施形態による、患者の健康を監視して、患者の医師へのスケジューリングされた来院に向けて患者に事前対策的に準備をさせるために行われる動作７００のフローチャートを示している。この動作７００は、サーバシステム１３０によって実行することができる。

【0088】

ブロック７１０において、サーバシステム１３０は、患者についての患者データを受信する。この患者データは、患者のプロフィール（例えば、患者プロフィール１１０）内の任意の情報を含み得る。例えば、サーバシステム１３０は、連続的、定期的、又は要求に応じた原則のうちの１つ以上に基づいて、患者の健康データ（例えば、健康データ１１３）を受信することができる。特定の実施形態では、サーバシステム１３０は、患者の医師へのスケジューリングされた来院より前の、ある期間（例えば、７～１４日又は何らかの他の期間）における患者データを受信することができる。

【0089】

ブロック７２０において、サーバシステム１３０は、患者データに少なくとも部分的に基づいて、患者が医師に尋ねるための質問のセットを生成する。例えば、患者の健康データが、患者が患者のスケジューリングされた来院より前のある期間において高い／低い血糖値を有することを示す場合、サーバシステム１３０は、患者がスケジューリングされた来院中に医師に尋ねるための、高い／低い血糖値に関して提案された質問のセットを生成することができる。

【0090】

ブロック７３０において、サーバシステム１３０は、その質問のセットを、患者と関連付けられたコンピューティングデバイス（例えば、患者デバイス１０７）に送信する。このようにして患者のスケジューリングされた来院のための質問のセットを提供することによって、本明細書の特定の実施形態は、患者が、スケジューリングされた来院中にどの質問を尋ねるべきかを忘れる可能性を低減することができる。

【0091】

図８Ａ～図８Ｃは、本明細書に説明される特定の実施形態による、医師へのスケジューリングされた来院に向けて患者に準備をさせるための例示的なシナリオを示している。特に、図８Ａ～図８Ｃは、患者デバイス１０７上に表示するために、サーバシステム１３０によって提供される臨床支援アプリケーション（例えば、モバイルアプリケーション、ウェブベースのアプリケーションなど）によって提供され得る例示的なＵＩ８００－１を示している。図８Ａに示すように、ＵＩ８００－１は、患者１０２が医師に尋ねるための質問のリストを提供することができる。特定の実施形態では、図８Ａに図示してあるＵＩ８００－１は、患者１０２が、提案された質問のリストから選択し、かつ／又は患者が定義した（若しくは個別仕様の）質問を追加することを可能にする。加えて、図８Ａに図示してあるＵＩ８００－１は、患者がメモを追加して、医師が来院と来院との間で助言したことを患者が思い出すことを支援することを可能にする。

【0092】

図８Ｂに示すように、ＵＩ８００－２は、スケジューリングされた来院より前の期間中の、患者の健康データ内の傾向に関連する論点提案を提供する。ここで、図８Ｂにおいて、例えば、ＵＩ８００－２は、患者がスケジューリングされた来院より前の期間中に低血糖を有していたことを示し、患者がスケジューリングされた来院中に自身の低血糖レベルについて議論することを希望しているかどうかを問い合わせる。図８ＢのＵＩ８００－２は、患者が、スケジューリングされた来院の準備リストにその論点提案を追加することを可能にするプロンプトを提供する。図８Ｃに示すように、ＵＩ８００－３はまた、患者のスケジューリングされた来院のリマインダを医師に提供して、患者がスケジューリングされた来院の状況を常に把握することを支援することもできる。

【0093】

図９は、本明細書に説明される特定の態様を実行又は具現化する処理システムの一実施形態の略図である。例えば、システム９００は、図１に示された患者デバイス１０７に対応し得る。

【0094】

図に示すように、システム９００は、中央処理ユニット（central processing unit、ＣＰＵ）９０２、システム９００への様々なＩ／Ｏデバイス９１４（例えば、キーボード、ディスプレイ、マウスデバイス、ペン入力など）の接続を可能にすることができる１つ以上のＩ／Ｏデバイスインターフェース９０４、システム９００がネットワーク１５０に接続されるネットワークインターフェース９０６、メモリ９０８、データストア９１０、及び相互接続９１２を含む。

【0095】

ＣＰＵ９０２は、メモリ９０８内に格納されたプログラミング命令を取り出して実行することができる。同様に、ＣＰＵ９０２は、メモリ９０８内に常駐するか、又はネットワーク１５０を介してアクセス可能である、アプリケーションデータを取り出して格納することができる。相互接続９１２は、ＣＰＵ９０２、Ｉ／Ｏデバイスインターフェース９０４、ネットワークインターフェース９０６、及びメモリ９０８の間で、プログラミング命令、対話、及びアプリケーションデータを伝達する。メモリ９０８は、ランダムアクセスメモリなどの揮発性メモリ、及び／又は、不揮発性ランダムアクセスメモリ、相変化ランダムアクセスメモリなどの不揮発性メモリを表す。図に示すように、メモリ９０８は、アプリケーション９２０（例えば、アプリケーション１０６）を含み、これは、ＣＰＵ９０２によって実行されたときに、アプリケーション１０６に関して本明細書に説明された動作を行う。データストレージ９１０は、ローカルに格納された患者プロフィール９５０、個別化された閾値などの様々なデータを格納することができる。

【0096】

図１０は、本明細書に説明される特定の態様を実行又は具現化する処理システムの実施形態の略図である。例えば、システム１０００は、図１に示された診療所システム１２０に対応し得る。

【0097】

図に示すように、システム１０００は、中央処理ユニット（ＣＰＵ）１００２、システム１０００への様々なＩ／Ｏデバイス１０１４（例えば、キーボード、ディスプレイ、マウスデバイス、ペン入力など）の接続を可能にすることができる１つ以上のＩ／Ｏデバイスインターフェース１００４、システム１０００がネットワーク１５０に接続されるネットワークインターフェース１００６、メモリ１００８、データストア１０１０、及び相互接続１０１２を含む。

【0098】

ＣＰＵ１００２は、メモリ１００８内に格納されたプログラミング命令を取り出して実行することができる。同様に、ＣＰＵ１００２は、メモリ１００８内に常駐するか、又はネットワーク１５０を介してアクセス可能である、アプリケーションデータを取り出して格納することができる。相互接続１０１２は、ＣＰＵ１００２、Ｉ／Ｏデバイスインターフェース１００４、ネットワークインターフェース１００６、及びメモリ１００８の間で、プログラミング命令、対話、及びアプリケーションデータを送信する。ＣＰＵ１００２は、単一のＣＰＵ、複数のＣＰＵ、複数の処理コアを有する単一のＣＰＵなどを表すように含まれる。ＣＰＵ１００２は、図１のプロセッサ１２１に対応し得る。

【0099】

メモリ１００８は、ランダムアクセスメモリなどの揮発性メモリ、及び／又は、不揮発性ランダムアクセスメモリ、相変化ランダムアクセスメモリなどの不揮発性メモリを表す。メモリ１００８は、メモリ１２２に対応し得る。図に示すように、メモリ１００８は、Ｓ＆Ｎアプリケーション１０２０を格納する。データストア１０１０は、データストア１２３に対応し得、ルール１０５０及びスケジュールデータ１０７０などの様々なデータを格納し得る。

【0100】

図１１は、本明細書に説明される特定の態様を実行又は具現化する処理システムの実施形態の略図である。例えば、システム１１００は、図１に示されたサーバシステム１３０に対応し得る。

【0101】

図に示すように、システム１１００は、中央処理ユニット（ＣＰＵ）１１０２、システム１１００への様々なＩ／Ｏデバイス１１１４（例えば、キーボード、ディスプレイ、マウスデバイス、ペン入力など）の接続を可能にすることができる１つ以上のＩ／Ｏデバイスインターフェース１１０４、システム１１００がネットワーク１５０に接続されるネットワークインターフェース１１０６、メモリ１１０８、データストア１１１０、及び相互接続１１１２を含む。

【0102】

ＣＰＵ１１０２は、メモリ１１０８内に格納されたプログラミング命令を取り出して実行することができる。同様に、ＣＰＵ１１０２は、メモリ１１０８内に常駐するか、又はネットワーク１５０を介してアクセス可能である、アプリケーションデータを取り出して格納することができる。相互接続１１１２は、ＣＰＵ１１０２、Ｉ／Ｏデバイスインターフェース１１０４、ネットワークインターフェース１１０６、及びメモリ１１０８の間で、プログラミング命令、対話、及びアプリケーションデータを送信する。ＣＰＵ１１０２は、単一のＣＰＵ、複数のＣＰＵ、複数の処理コアを有する単一のＣＰＵなどを表すように含まれる。ＣＰＵ１１０２は、図１のプロセッサ１２１に対応し得る。

【0103】

メモリ１１０８は、ランダムアクセスメモリなどの揮発性メモリ、及び／又は、不揮発性ランダムアクセスメモリ、相変化ランダムアクセスメモリなどの不揮発性メモリを表す。メモリ１１０８は、メモリ１３２に対応し得る。図に示すように、メモリ１１０８は、Ｓ＆Ｎアプリケーション１１２０を格納する。データストア１１１０は、データストア１３３に対応し得、ルール１１５０及びスケジュールデータ１１７０などの様々なデータを格納し得る。ルール１１５０は、通知（又は警告）が生成されて、患者１０２及び／又は医師に送信されるべきである条件を定義することができる。典型的なルール１１５０は、患者の血糖レベルが閾値を超えたときに（例えば、高血糖条件）、通知が生成されて、患者１０２及び／又は医師に送信されるべきであることを定義することができる。別の典型的なルール１１５０は、患者の血糖レベルが閾値を下回って降下したときに（例えば、低血糖条件）、通知が生成されて、患者１０２及び／又は医師に送信されるべきであることを定義することができる。スケジュールデータ１１７０は、概して、患者のスケジューリングされた来院に関する情報（例えば、患者のスケジューリングされた来院の日時）を含む。

【0104】

これらの非限定的な例の各々は、それ自体で独立することができるか、又は他の例のうちの１つ以上との様々な順列若しくは組み合わせにおいて組み合わせることができる。上記の発明を実施するための形態には、発明を実施するための形態の一部を構成する添付の図面への参照が含まれている。図面は、例解として、本発明を実施することができる具体的な実施形態を示している。これらの実施形態は、本明細書では「例」とも称される。このような例は、図示又は記載される要素に加えて要素を含み得る。しかしながら、本発明者らは、図示又は記載される要素のみが提供される例も企図している。更に、本発明者らは、特定の例（又はその１つ以上の態様）に関して、又は本明細書に図示又は記載される他の例（又はその１つ以上の態様）に関して、図示又は記載されるそれらの要素（又はその１つ以上の態様）の任意の組み合わせ又は順列を使用する例も企図している。

【0105】

本文書と参照することにより組み込まれるいずれかの文書との間で使用法が一致しない場合、本文書の使用法が優先される。

【0106】

本文書では、「ａ」又は「ａｎ」という用語は、特許文書で一般的であるように、「少なくとも１つ」又は「１つ以上」の他の事例又は使用法とは無関係に、１つ、又は２つ以上を含むように使用される。本文書では、「又は」という用語は、別途示されていない限り、「Ａ又はＢ」には「ＡであるがＢではない」、「ＢであるがＡではない」、「Ａ及びＢ」が含まれるように、非排他的なものを指すために使用されている。本文書では、「含む（including）」及び「ここで／式中（in which）」という用語は、それぞれの用語の平易な英語の同等語である「含む（comprising）」及び「ここで／式中（wherein）」として使用される。また、以下の特許請求の範囲において、「含む（including）」及び「含む（comprising）」という用語は、オープンエンドであり、すなわち、ある請求項において、かかる用語の後に記載されたものに加えて要素を含むシステム、デバイス、物品、組成物、配合物、又はプロセスは、依然としてその請求項の範囲に収まるものとみなされる。更に、以下の特許請求の範囲において、「第１」、「第２」、及び「第３」などの用語は、単に標識として使用されており、その対象に数値的な要件を課すことを意図するものではない。

【0107】

「平行」、「垂直」、「円形」、「正方形」などの幾何学的用語は、文脈が別途示していない限り、絶対的な数学的精度を要求することを意図したものではない。代わりに、このような幾何学的用語は、製造又は同等の機能に起因する変動を許容する。例えば、ある要素が「円形」又は「概ね円形」と記載されている場合、正確には丸形ではない構成要素（例えば、わずかに楕円形であるか、又は多辺形の多角形であるもの）は、依然としてこの記載に包含される。

【0108】

本明細書に記載されている方法の例は、少なくとも部分的には機械又はコンピュータで実施することができる。いくつかの例は、上記の例において記載される方法を遂行するように電子デバイスを構成するように動作可能な命令でコード化されたコンピュータ可読媒体又は機械可読媒体を含むことができる。このような方法の実装形態は、マイクロコード、アセンブリ言語コード、高級言語コードなどのコードを含むことができる。そのようなコードは、様々な方法を実行するためのコンピュータ可読な命令を含むことができる。このコードは、コンピュータアプリケーション製品の部分を形成し得る。更に、例では、コードは、実行中又は他の時間などに、１つ以上の揮発性、非一時的、又は不揮発性の有形コンピュータ可読媒体に有形的に格納することができる。これらの有形コンピュータ可読媒体の例としては、ハードディスク、リムーバブル磁気ディスク、リムーバブル光ディスク（例えば、コンパクトディスク及びデジタルビデオディスク）、磁気カセット、メモリカード又はスティック、ランダムアクセスメモリ（random access memories、ＲＡＭ）、読み取り専用メモリ（read only memories、ＲＯＭ）などを挙げることができるが、これらに限定されない。

【0109】

上記の説明は、例解的であることを意図したものであり、制限的なものではない。例えば、上記の例（又はその１つ以上の態様）は、互いに組み合わせて使用され得る。上記の説明を再検討する際の当業者によるものなど、他の実施形態を使用することができる。本要約は、米国特許法施行規則（３７Ｃ．Ｆ．Ｒ．）第１．７２条（ｂ）に準拠し、読者が技術的開示の性質を迅速に把握することを可能にするように提供されている。これは、特許請求の範囲の範囲若しくは趣旨を解釈又は限定するために使用されるものではないことを理解した上で提出されている。また、上記の「発明を実施するための形態」では、様々な特徴を一緒にグループ化して、本開示を合理化することができる。これは、特許請求されていない開示された特徴がいずれの請求項にも不可欠であることを意図するものとして解釈されるべきではない。むしろ、本発明の主題は、特定の開示された実施形態の全ての特徴よりも少ない特徴にあり得る。したがって、以下の特許請求の範囲は、例又は実施形態として「発明を実施するための形態」に組み込まれており、各請求項は別個の実施形態として独立しており、そのような実施形態は、様々な組み合わせ又は順列で互いに組み合わせることができることが企図される。本発明の範囲は、添付の特許請求の範囲を、そのような特許請求の範囲が権利を有する均等物の全範囲と併せて参照して判定されるべきである。

【符号の説明】

【0110】

110 患者プロフィール
111 患者データ
112 人口統計データ
113 健康データ
114 薬物情報
115 スケジュール情報
116 質問情報
117 応答情報
120 診療所システム
121 プロセッサ
122 メモリ
123 データストア
130 サーバシステム
131 プロセッサ
132 メモリ
133 データストア
140 患者データストア
150 ネットワーク
238 センサ電子機器モジュール
239 連続分析物センサ
900 システム
902 ＣＰＵ
904 Ｉ／Ｏデバイスインターフェース
906 ネットワークインターフェース
908 メモリ
910 データストレージ
914 Ｉ／Ｏデバイス
920 アプリケーション
950 患者プロフィール
1000 システム
1002 ＣＰＵ
1004 Ｉ／Ｏデバイスインターフェース
1006 ネットワークインターフェース
1008 メモリ
1010 データストレージ
1014 Ｉ／Ｏデバイス
1020 Ｓ＆Ｎアプリケーション
1050 ルール
1070 スケジュールデータ
1100 システム
1102 ＣＰＵ
1104 Ｉ／Ｏデバイスインターフェース
1106 ネットワークインターフェース
1108 メモリ
1110 データストレージ
1114 Ｉ／Ｏデバイス
1120 臨床支援アプリケーション
1150 ルール
1170 スケジュールデータ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図8C】

【図9】

【図10】

【図11】

【国際調査報告】