特許 7566234 完全自律型医療ソリューション（ＭＹＤＯＣＴＯＲ）

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

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

(11)【特許番号】

(24)【登録日】2024-10-04

(45)【発行日】2024-10-15

(54)【発明の名称】完全自律型医療ソリューション（ＭＹＤＯＣＴＯＲ）

(51)【国際特許分類】

   G16H 50/20 20180101AFI20241007BHJP

【ＦＩ】

G16H50/20

【請求項の数】 17

【外国語出願】

(21)【出願番号】P 2020142174

(22)【出願日】2020-08-25

(65)【公開番号】P2021197122

(43)【公開日】2021-12-27

【審査請求日】2023-04-11

(31)【優先権主張番号】16/904,219

(32)【優先日】2020-06-17

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

(73)【特許権者】

【識別番号】520325740

【氏名又は名称】マゼン エイ．アル－シナン

【氏名又は名称原語表記】Ｍａｚｅｎ Ａ． Ａｌ－Ｓｉｎａｎ

(73)【特許権者】

【識別番号】520325751

【氏名又は名称】ホ－サン ディビット クオ

【氏名又は名称原語表記】Ｈｏ－Ｈｓｕｎ Ｄａｖｉｄ Ｋｕｏ

(74)【代理人】

【識別番号】100086461

【弁理士】

【氏名又は名称】齋藤 和則

(72)【発明者】

【氏名】マゼン エイ．アル－シナン

(72)【発明者】

【氏名】ホ－サン ディビット クオ

【審査官】今井 悠太

(56)【参考文献】

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

【文献】米国特許出願公開第２０１７／０１４７７６８（ＵＳ，Ａ１）

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

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

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

【請求項1】

さまざまなサービスを１つの自律型プラットフォームに統合し、人工知能と自然言語を利用して医師の役割を模倣するための仮想医師（ＭｙＤｏｃｔｏｒ）自律型ソフトウェアプラットフォーム（６００）であって：
（ａ）仮想医師ソフトウェアを含み、そして実行する手段と；
（ｂ）考えられる病気にマッピングされている症候、を有する病気データベースと；
（ｃ）複数のユーザからの病気のデータおよび回復データと;
（ｄ）外部記憶素子（９０００）と；
を有し、
前記仮想医師ソフトウェアは：
（ｉ）ユーザアカウントモジュール（２００）であって、
Ａ）ユーザの一般情報（２０００）を保存し、
Ｂ）外部通信機モジュール（９００）から前記ユーザの医療記録
（２１００）を受け取り、
Ｃ）前記ユーザの前記医療記録（２１００）を保存し、
Ｄ）前記ユーザの報告された状態（２２００）を保存し、
Ｅ）前記ユーザの習慣（２３００）を保存し、そして
Ｆ）支払いゲートウェイ（２４００）を使用して外部ソースに支払いを送信する、
ための命令を有する、ユーザアカウントモジュール（２００）と；
（ｉｉ）対話モジュール（３００）であって、
Ａ）口頭入力要素と自然言語処理アルゴリズムの使用を介して、前記ユーザと口頭でコミュニケーションし、そして
Ｂ）前記ユーザからの指示に基づいてアクションを送信するモジュールを決定する、
ための命令を有する、対話モジュール（３００）と；
（ｉｉｉ）診断モジュール（４００）であって、
Ａ）考えられる原因にマッピングされている症候、を有する前記病気データベースにアクセスし、
Ｂ）前記ユーザにより前記対話モジュール（３００）に提供された、ユーザ症候のリストを受け入れ、
Ｃ）試験分析器モジュール（５００）から１組の試験結果を受け入れ、
Ｄ）それぞれの前記ユーザ症候を、考えられる全ての原因にマッピングする、第１のテーブル（４１０）を生成し、
Ｅ）すべての前記ユーザ症候を共有する、前記考えられる全ての原因（４５０）を表示する、第２のテーブルを生成し、
Ｆ）医療記録データベース（２１００）からデータを受け入れ、ここで、前記医療記録データベース（２１００）は、複数の外部医療ソース（９３０）から受け入れた前記ユーザに紐づけられた医療記録を有し、各前記医療記録は前記仮想医師ソフトウェアにより受け入れられた時に標準フォーマットに変換され、および
Ｇ）それぞれの前記考えられる原因の存在確率に基づいて、前記考えられる全ての原因（４５０）を順位付けした確率テーブルを生成する、
ための命令を有する、診断モジュール（４００）と；
（ｉｖ）試験分析器モジュール（５００）であって、
Ａ）試験装置から前記１組の試験結果を受け入れ、
Ｂ）前記１組の試験結果を自律的に分析し、
Ｃ）分析された前記１組の試験結果を前記ユーザアカウントモジュール
（２００）に送信して保存し、そして
Ｄ）分析された前記１組の試験結果を前記診断モジュール（４００）に送信する、
ための命令を有する、試験分析器モジュール（５００）と；
(ｖ）処置モジュール（７００）であって、
Ａ）前記ユーザアカウントモジュール（２００）および前記診断モジュール（４００）に格納されている前記医療記録（２１００）から入力を受け取り、
Ｂ）前記診断モジュール（４００）によって診断された病気、および 前記医療記録（２１００）からの情報に基づいて処置方法を自律的に決定し、ここで、前記処置方法は処方箋と複数の推奨事項を含み、そして
Ｃ）前記ユーザに対し、前記処方箋を提供できる薬局と、前記処方箋の価格情報と、そして前記複数の推奨事項と、を自律的に提供する、
ための命令を有する、処置モジュール（７００）と；
（ｖｉ）症例監視モジュール（８００）であって、
Ａ）前記ユーザが前記診断モジュール（４００）によって決定された処置（４７５）を実行するときに、ユーザの健康と回復を自律的に監視し、
Ｂ）前記処置（４７５）に関連する処方箋を実行するよう前記ユーザに
思い出させ、
Ｃ）予想される回復時間と実際の回復時間を比較して、第２の行動方針
が必要かどうかを判断し、
Ｄ）前記処方箋を前記第２の行動方針として調整し、そして
Ｅ）前記第２の行動方針に基づいて予想回復時間を調整する、
ための命令を有する、症例監視モジュール（８００）と；
（ｖｉｉ）外部通信機モジュール（９００）であって：
Ａ）データ暗号化モジュール（９１０）と；
Ｂ）データ圧縮モジュール（９２０）と；
を有し、
前記データ暗号化モジュール（９１０）は、
イ）ソースからデータを受け入れ、そして
ロ）前記データを標準フォーマットに暗号化する、
ための命令を有し、
ここで、前記データ暗号化モジュール（９１０）は、ユーザから、または複数の外部医療ソース（９３０）から直接データを受け入れることができ、
前記データ圧縮モジュール（９２０）は、
イ）前記データ暗号化モジュール（９１０）から標準フォーマットデータを受け入れ、
ロ）前記標準フォーマットデータを圧縮データに圧縮し、そして
ハ）前記圧縮データを外部記憶素子（９０００）または複数の外部医療ソース（９３０）に送信する、
ための命令を有し、
ここで前記外部通信機モジュール（９００）は、前記処置モジュール（７００）により決定された前記処方箋のリクエストを、前記処置モジュール（７００）により提供された前記薬局に発行する、ための命令を有する、
外部通信機モジュール（９００）と；
（ｖｉｉｉ）栄養士モジュール（１１００）であって、
Ａ）前記ユーザが食物消費データを入力できるようにし、
Ｂ）前記食物消費データに基づいてカロリー摂取量のテーブルを生成
し、そして
Ｃ）前記食物消費データを前記ユーザアカウントモジュール（２００）
に交換可能に送信する、
ための命令を有する、栄養士モジュール（１１００）と；
（ｉｘ）健康モジュール（１３００）であって、
Ａ）前記ユーザアカウントモジュール（２００）からの情報に基づいて
前記ユーザの一般的な健康に関する推奨を提供する、
ための命令を有する、健康モジュール（１３００）と；
（ｘ）身体活動モジュール（１４００）であって、
Ａ）ユーザの身体活動を追跡し、そして
Ｂ）前記ユーザアカウントモジュール（２００）からの情報に基づいて前記ユーザの身体活動の推奨を提供する、
ための命令を有する、身体活動モジュール（１４００）と；
（ｘｉ）呼吸装置モジュール（１５００）であって、
Ａ）ユーザの呼吸を補助するための換気装置、および
Ｂ）前記ユーザの一組の肺に薬剤を送達するためのネブライザー、
を有する、呼吸装置モジュール（１５００）と；
（ｘｉｉ）前記ユーザの心臓を電気的に刺激するための除細動装置を含む除細動器モジュール（１６００）であって、
Ａ）前記除細動装置をいかに使用するかの指示を提供し、および
Ｂ）早急な対応が必要なバイタルサインの検出直後に救急医療補助に連絡する、
ための命令を有する、除細動器モジュール（１６００）と；
（ｘｉｉｉ）心理療法モジュール（１７００）であって、
Ａ）前記対話モジュール（３００）により収集された、前記ユーザの声
の調子または顔の表情に基づいて前記ユーザの心理的状態を分析し、
Ｂ）前記ユーザが自殺願望を話すと、救急医療補助に連絡し、そして
Ｃ）前記ユーザに長期心理療法を提供する、
ための命令を有する、心理療法モジュール（１７００）と；
を有し、
ここで、前記ソフトウェアの各モジュールは、前記ソフトウェアの他の全てのモジュールにデータを送信することができる、
ことを特徴とする仮想医師（ＭｙＤｏｃｔｏｒ）自律型ソフトウェアプラットフォーム（６００）。

【請求項2】

前記外部通信機モジュール（９００）は：
ａ）前記ユーザの医療記録と予約を手配するためのスケジュール情報を受け取り、そしてユーザデータと予約要求を病院に送信するために、前記病院と通信し、
ｂ）ユーザの医療記録、予約を手配するためのスケジュール情報、およびラボの検査結果を受け取り、そしてユーザデータと予約要求を医療ラボに送信するために、前記医療ラボと通信し、
ｃ）ユーザの医療記録と予約を手配するためのスケジュール情報を受け取り、そしてユーザデータと予約要求をクリニックに送信するために、前記クリニックと通信し、
ｄ）救急車を要請し、そしてユーザデータとユーザの位置を緊急センターに送信するために、前記緊急センターと通信し、そして
ｅ）ユーザの医療記録と前記処方箋に対する価格情報を受け取り、そしてユーザデータ、複数の前記処方箋、および前記処方箋の送達場所を前記薬局に送信するために、前記薬局と通信する、
ことを特徴とする請求項１に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項3】

ユーザの医学的問題を診断するための複数の試験をユーザが実行できるようにするための試験装置を含む仮想医師（ＭｙＤｏｃｔｏｒ）自律型ソフトウェアプラットフォーム（６００）であって、
前記プラットフォームは：
（ａ）仮想医師ソフトウェアを含み、そして実行する手段と；
（ｂ）診断モジュール（４００）と；そして
（ｃ）考えられる病気にマッピングされている症候、を有する病気データベースと；
を有し、
前記（ａ）仮想医師ソフトウェアは：
Ａ）前記ユーザの病歴、
Ｂ）前記ユーザの既往症のリスト、および
Ｃ）前記ユーザが現在服用している薬のリスト
を有する、医療記録データベース（２１００）を有し、
ここで前記医療記録データベース（２１００）で発見されたデータは 複数の外部医療ソース（９３０）から受け取られ、各医療記録は仮想医師ソフトウェアに受け取られた時に標準フォーマットに変換され、
前記（ｂ）診断モジュール（４００）は：
Ａ）考えられる原因にマッピングされた症候の、病気データベースにアクセスし、
Ｂ）ユーザ症候のリストをユーザから受け入れ、
Ｃ）それぞれの前記ユーザ症候を、当該ユーザ症候に対して考えられる全ての原因にマッピングする、第１のテーブル（４１０）を生成し、
Ｄ）すべての前記ユーザ症候を共有する、考えられる全ての原因（４５０）を表示する、第２のテーブルを生成し、
Ｅ）複数の外部医療ソース（９３０）から受け入れた前記医療記録データベース（２１００）からデータを受け入れ、
Ｆ）各前記考えられる原因の存在確率に基づいて、前記考えられる全ての原因（４５０）を順位付けした確率テーブルを生成し、
Ｇ）前記考えられる原因をより適切に特定するために、前記ユーザからの複数の試験を要求し、
Ｈ）前記ユーザから１組の試験結果を受け取り、
Ｉ）前記１組の試験結果に基づいて前記確率テーブルを狭め、
Ｊ）前記医療記録データベース（２１００）からのデータ、前記ユーザ症候のリスト、および前記１組の試験結果に基づいて、ランダム フォレスト分類アルゴリズムを実行することにより、前記考えられる原因に対する処置（４７５）を自律的に決定する、
ための命令を有し、
ここで、前記ソフトウェアの各モジュールは、前記ソフトウェアの他の全てのモジュールにデータを送信することができる、
ことを特徴とする仮想医師（ＭｙＤｏｃｔｏｒ）自律型ソフトウェアプラットフォーム（６００）。

【請求項4】

前記試験装置は、個人用バイタルサインモニタ、個人用心電図、血糖計、超音波画像装置、心臓モニタ、および皮膚画像カメラを含む、ことを特徴とする請求項３に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項5】

前記試験装置の使用を介して前記ユーザから試験を受け入れ、そして当該試験を処理して１組の試験結果を生成し、診断プラットフォームが前記考えられる原因を生成するのを助けるための試験分析器モジュール（５００）をさらに含む、ことを特徴とする請求項３に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項6】

前記症候の病気データベースがクラウドサーバに格納され、前記診断モジュール（４００）によってアクセスされる、ことを特徴とする請求項３に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項7】

前記確率テーブルは、すべての前記ユーザ症候について生成される、ことを特徴とする請求項３に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項8】

確率重みが、前記ユーザ症候と前記考えられる原因の症候との間で一致した症候の数をユーザ症候の総数で除することによって計算され、そして前記症候は、最も可能性の高い原因を特定するため、試験とユーザとのコミュニケーションによりさらに絞り込まれる、ことを特徴とする請求項３に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項9】

前記第１のテーブル（４１０）は、前記ユーザの年齢、性別、体重、および病歴を含む前記医療記録データベースからのデータを使用してフィルタリングされる、ことを特徴とする請求項３に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項10】

複数のソースからのユーザの病歴を編集し、前記病歴を使用してユーザの医学的問題を診断するための仮想医師（ＭｙＤｏｃｔｏｒ）自律型ソフトウェアプラットフォーム（６００）であって、前記プラットフォームは：
（ａ）仮想医師ソフトウェアを含み、そして実行する手段と；
（ｂ）考えられる病気にマッピングされている症候、を有する病気データベースと；
（ｃ）外部記憶素子（９０００）と；
を有し、
前記仮想医師ソフトウェアは：
（ｉ）外部通信機モジュール（９００）と；
（ｉｉ）複数の外部医療ソース（９３０）から受け入れた医療記録データベース（２１００）と；
（ｉｉｉ）診断モジュール（４００）と；および
（ｉｖ）症例監視モジュール（８００）と；
を有し、
前記（ｉ）外部通信機モジュール（９００）は：
Ａ）データ暗号化モジュール（９１０）であって、
イ）ソースからのデータを受け入れ、そして
ロ）データを標準フォーマットに変換する、
ための命令を有し、そして
ユーザから、または前記複数の外部医療ソース（９３０）から直接データを受け入れることができる、データ暗号化モジュール（９１０）と：
Ｂ）データ圧縮モジュール（９２０）であって、
イ）前記データ暗号化モジュール（９１０）から標準フォーマットデータを受け入れ、
ロ）前記標準フォーマットデータを圧縮データに圧縮し、および
ハ）前記圧縮データを前記外部記憶素子（９０００）または前記複数の外部医療ソース（９３０）に送信する、
ための命令を有する、データ圧縮モジュール（９２０）と：
を有し、
前記（ｉｉ）医療記録データベース（２１００）は、
Ａ）ユーザの病歴、
Ｂ）ユーザの既往症のリスト、および
Ｃ）ユーザが現在服用している薬のリスト
を有し、
ここで、前記医療記録データベース（２１００）で発見されたデータは前記複数の外部医療ソース（９３０）から受け取ったものであり、各前記医療記録は前記仮想医師ソフトウェアにより受け入れられた時に標準フォーマットに変換され、
前記（ｉｉｉ）診断モジュール（４００）は、
Ａ）考えられる原因にマッピングされている症候、を有する前記病気データベースにアクセスし、
Ｂ）前記ユーザからユーザ症候のリストを受け入れ、
Ｃ）それぞれの前記ユーザ症候を、考えられる全ての原因にマッピングする、第１のテーブル（４１０）を生成し、
Ｄ）すべての前記ユーザ症候を共有する、前記考えられる全ての原因（４５０）を表示する第２のテーブルを生成し、
Ｅ）前記医療記録データベース（２１００）からデータを受け入れ、
Ｆ）それぞれの前記考えられる原因の存在確率に基づいて、前記考えられる全ての原因（４５０）を順位付けした確率テーブル（４３０）を生成し、そして
Ｇ）前記考えられる原因をより適切に特定するために、前記ユーザからの複数の試験を要求し、
Ｈ）前記ユーザから１組の試験結果を受け取り、
Ｉ）前記１組の試験結果に基づいて前記確率テーブルを狭め、
Ｊ）前記医療記録データベース（２１００）からのデータ、前記ユーザ症候のリスト、および前記１組の試験結果に基づいて、ランダム フォレスト分類アルゴリズムを実行することにより、前記考えられる原因に対する処置（４７５）を自律的に決定する、
ための命令を有し、
前記（ｉｖ）症例監視モジュール（８００）は、
Ａ）前記ユーザが前記診断モジュール（４００）によって決定された処置（４７５）を実行するときに、ユーザの健康と回復を自律的に監視し、
Ｂ）前記処置（４７５）に関連する処方箋を実行するようユーザに思い出させ、
Ｃ）予想される回復時間と実際の回復時間を比較して、第２の行動方針が必要かどうかを判断し、
Ｄ）前記処方箋を前記第２の行動方針として調整し、そして
Ｅ）前記第２の行動方針に基づいて予想回復時間を調整する、
ための命令を有し、
ここで、前記仮想医師ソフトウェアの各モジュールは、前記ソフトウェアの他の全てのモジュールにデータを送信することができる、
ことを特徴とする仮想医師（ＭｙＤｏｃｔｏｒ）自律型ソフトウェアプラットフォーム（６００）。

【請求項11】

前記診断モジュール（４００）は、前記考えられる原因をよりよく決定するために、前記ユーザからの複数の検査を要求する、命令をさらに含む、ことを特徴とする請求項１０に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項12】

前記ユーザが前記複数の試験を実行することを可能にするための試験装置をさらに備える、ことを特徴とする請求項１１に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項13】

前記試験装置は、個人のバイタルサインモニタ、個人の心電図、血糖計、超音波画像装置、ＤＮＡサンプラ、心臓モニタ、および皮膚画像カメラを含む、ことを特徴とする請求項１２に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項14】

前記試験装置の使用を介して前記ユーザから試験を受け入れ、そして診断プラットフォームが前記考えられる原因を生成するのを助けるため、前記試験を処理して前記１組の試験結果を生成するための、試験分析器モジュール（５００）をさらに備える、ことを特徴とする請求項１２に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項15】

前記診断モジュール（４００）によって生成された複数の前記考えられる原因に対する複数の処置を自律的に生成し、前記ユーザが処置方針を選択することを可能にする、処置モジュール（７００）をさらに含む、ことを特徴とする請求項１０に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項16】

前記外部通信機モジュール（９００）は、前記処方箋を前記ユーザに送達するように要求するための命令をさらに含む、ことを特徴とする請求項１０に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【請求項17】

前記医療記録データベース（２１００）に追加されるべきデータとしての前記ユーザの食事習慣を追跡し、そして前記プラットフォームによって決定された処置に従って、健康的な食事を維持し、体重を減らし、医学的相互作用を防ぐことについて前記ユーザを支援するための、栄養士モジュール（１１００）をさらに含む、ことを特徴とする請求項１０に記載の仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、パーソナルコンピューティング装置内における、１つのプラットフォームの下での様々なサービスの統合、および医師の役割の模倣に関する。

【0002】

（関連アプリケーションの相互参照）
本出願は、２０２０年３月２３日に出願された米国特許出願公開第６２／９９３，４３７号（特許文献１）の利益を主張し、その明細書は参照により全体として本明細書に組み入れられる。

【背景技術】

【0003】

本発明は、インテリジェント医療自動化の技術分野にある。より具体的には、本発明は、個人に対し診断し処置を提供するための自律型医療ソリューションの技術分野にある。医療ケアを求める現在の実践には多くの課題がある。個人が健康状態に異常を経験すると、次のシナリオのいずれかが発生する可能性がある：

【0004】

１．症状が軽度で一時的なものであり、医師の診察を必要としない、または市販薬を服用するか、非薬剤処置によって問題を解決できる状態で、医師の診察を受ける。ただし、適切な市販薬を特定することは困難である。

【0005】

２．多くの人が、金銭的費用、時間の制約、医師の診察への不安などの様々な理由で医師の診察を避けているという事実を考慮して、医師に会う必要が本当にあるのに、症状を無視するか、または市販薬を服用する。

【0006】

結果として、必要がないときに医師に会うことは、資源の浪費であり、一方で、必要なときに医師に会うことを避けることは、状態を悪化させ、患者の生命を危険にさらす可能性がある。

【0007】

さらに、多くの個人が一人暮らしであり、特に病気のときに、医療が必要な場合に、市販薬の注文と取得、適切な医療センターの特定、医師との面会の設定、または、深刻なケースでは、救急車を呼ぶのは難しいかもしれない。

【0008】

別の問題は、いつでも医学的疾患が発生する可能性がある一方で、患者が緊急処置室に行くことを決定しない限り、医師は勤務時間中にのみ利用可能であることである。多くの場合、緊急事態に行くことは避けられる：患者は、一時的な救済、または緊急に行く必要があるかどうかを彼／彼女に助言する誰かが単に必要な場合がある。

【0009】

例えば、高齢者および心臓発作を生じやすい人または緊急医療介入の必要性の非常に高い人々は、緊急の医学的介入を必要とするバイタルサインが異常の際に救急車を呼ぶべき看護師または同伴者などの誰かによって２４時間監視されるべきである。

【0010】

さらに、疾患の多くは類似または非特異的な徴候および症状を有するため、医師は通常、疾患の診断において困難に直面する。たとえば、皮膚の赤い斑点は腎臓の問題の兆候である可能性がある。医師は、経験や、不必要な可能性のある多くの試験や検査の結果に基づいて状態を診断できる。医師は、あらゆる病状を診断するため、自分の経験と、の検査や検査の結果に依存している。しかし、人工知能（Ａ．Ｉ．）と機械学習（Ｍ．Ｌ．）は、試験と検査の結果が提供されている場合、患者の状態の診断において医師よりも優れている可能性がある。

【0011】

一方、患者の病歴は、医師が診断し、適切な処置を処方するために重要である。医師は病歴の確認に時間がかかり、患者の状態に関連する多くの重要な情報を見落とす可能性がある。緊急の場合、医師は患者の医療記録を確認せずに措置を講じる。同様に、医療記録が利用できない場合、患者の病歴に関係なく、不必要な検査を要求したり、処置を処方したりすることがある。医師は、問題が解決することを期待して薬を処方することもでき、そして通常１週間後の予約フォローアップで、医師は薬が機能していないことを発見し、代替の薬物療法または処置法を見つけなければならない場合がある。

【0012】

場合によっては、重度の風邪の場合など、患者の状態が病院への入院を必要としないが、一人暮らしであれば、認定看護師などの誰かが彼らを助けることを依然として必要とする場合、患者は、一時的に在宅介護を必要とするかもしれない。これらの場合、短期間でフリーランスの看護師を見つけることは困難な場合がある。

【0013】

上記の課題はすべて、不必要な検査を行うことによるリソースの浪費から、市販薬で問題を解決できるのに医師の診察を受けることまで、医療介入の差し迫った必要があるのに医療を求めることが遅れたために患者を致命的なリスクまたは患者の健康状態を悪化にさらす可能性まで、重要な影響を及ぼす。

【0014】

Ｃｏｖｉｄ－１９のパンデミックと類似の状況では、提案された発明は、特に、医療処置を行う必要のない病状の場合、ほとんどの日常的な医療サービスのための医療サービスを維持することができる。拡大した医療リソースはパンデミックに集中することができ、患者は依然としてパンデミックのために危険でありうる医療センターに行くことを避けながら医療サービスを受けることができる。本発明はまた、何千もの自己隔離された患者に必要な医療相談をその場で提供できる。

【0015】

Ａ．Ｉ．は、以前は診断および健康サービスで利用されてきたが、医療サービスの基本的な課題は、Ａ．Ｉアプリケーションの進歩に比例して全般に、特に医療サービスにおいて克服されていない。Ａ．Ｉ．技術を統合された方法で適用することにより、医療サービスのリソースの質と最適化を全体的に向上させる可能性がある。ブロックチェーン、機械学習（Ｍ．Ｌ．）、モノのインターネット（ＩｏＴ）、自然言語処理（ＮＬＰ）、データサイエンスなどの技術をさらに統合および採用して、個人に完全な医療ソリューションを提供する１つの統合された同期化ＭｙＤｏｃｔｏｒプラットフォームを実現できる。

【0016】

本発明は、システムと相互作用し、医師の役割を模倣して医師の存在なしに医療を提供するために人工知能、機械学習、病歴および自然言語を利用する。

【先行技術文献】

【特許文献】

【0017】

【文献】米国特許出願公開第６２／９９３，４３７号

【発明の概要】

【0018】

本発明の目的は、独立請求項に明記されているように、１つのプラットフォームの下で様々なサービスの統合を可能にし、パーソナルコンピューティング装置内の医師の役割を模倣するシステムを提供することである。本発明の実施形態は、従属請求項に記載されている。本発明の実施形態は、相互に排他的でなければ、自由に組み合わせることができる。

【0019】

本発明は、ＭｙＤｏｃｔｏｒプラットフォームを特徴とする。プラットフォームは、外部通信機モジュールを含み得る。外部通信機モジュールは、複数のソースからデータを受け取り、データを標準フォーマットに暗号化するためのデータ暗号化モジュールを含み得る。データ暗号化モジュールは、ユーザから、または複数の外部医療ソースからの情報を受け入れることができる。外部通信機モジュールは、暗号化されたデータを圧縮および送信するためのデータ圧縮モジュールをさらに含み得る。データ圧縮モジュールは、複数の外部医療ソースまたは外部記憶素子にデータを送信することができる。複数の外部医療ソースは、病院、クリニック、研究室、救急センター、および薬局を含み得る。

【0020】

ＭｙＤｏｃｔｏｒプラットフォームは、診断モジュールをさらに特色とすることができる。診断モジュールは、考えられる原因にマッピングされた疾患症状のデータベースを含むことができる。診断モジュールは、疾患症状のデータベースにアクセスし、ユーザからのユーザ症状のリストを受け入れるための命令を含み得る。診断モジュールはさらに、各ユーザの症状を各症状のすべての考えられる原因にマッピングするテーブルを生成し、すべてのユーザの症状を共有するすべての考えられる原因を表示する第２のテーブルを生成することを含む。診断モジュールは、ユーザの医療記録のデータベースからデータを受け入れること、および考えられる各原因の存在の確率に基づいてすべての考えられる原因を順位付けする確率テーブルを生成することをさらに含み得る。最後に、診断モジュールは、医療記録のデータベースからの情報に基づいて、考えられる原因の処置を決定できる。いくつかの実施形態では、診断モジュールはさらに、考えられる原因をより適切に判断するために、ユーザに試験を要求することができる。

【0021】

本発明のＭｙＤｏｃｔｏｒプラットフォームは、症例監視モジュールをさらに特徴とすることができる。症例監視モジュールは、ユーザが診断モジュールによって決定された処置を実行するときのユーザの健康および回復を監視するための命令を含み得る。症例監視モジュールは、処置に関連する処方を実行するようにユーザに思い出させるための指示を含み、予想される回復時間を実際の回復時間と比較して、二次的な処置が必要かどうかを判断し、二次的な処置としての処方を調整し、そして二次的な処置に基づいて予想される回復時間を調整する。

【0022】

本発明の独特で進歩的な技術的特徴の１つは、ユーザと複数の外部医療ソースの両方からのデータを、双方が交換可能に使用できる標準フォーマットに暗号化することである。本発明を特定の理論またはメカニズムに限定することを望まないが、本発明の技術的特徴は、有利には、ユーザの病歴および状態の包括的なソースを提供してユーザの問題のより効率的な診断を可能にし、ＭｙＤｏｃｔｏｒプラットフォームが診断情報を、後の記録と使用のために外部の医療ソースに送信することを可能にする。この機能の自律的な側面は、ユーザの病歴をコンパイルして送信する時間とリソースの効率的な方法を提供する。現在知られている以前の参考文献または研究のいずれも、本発明の独特の発明の技術的特徴を有していない。さらに、本発明の特徴は直観に反する。直感に反するのは、その機能が驚くべき結果に貢献したためである。当業者は、ユーザと複数の外部医療ソースとの間の複数の異なるフォーマット間でのデータの変換には、適切に実行するために大量の計算と時間を必要とし、それにより、単純にデータを手動で表示し、コンパイルし、そして送信するのが全体的により効率的になることを期待する。驚くべきことに、本発明は、遭遇した各フォーマットのスクリプトを生成して同じフォーマットの将来のインスタンスに対して迅速に実行することにより、複数のソースと複数のフォーマット間でデータを効率的に表示、コンパイル、および送信することができる。したがって、本発明の特徴は、驚くべき結果に貢献し、直観に反している。

【0023】

本発明の別の独特で進歩的な技術的特徴は、疾患症状のデータベースおよびユーザの病歴を使用して、医学的問題を自動的に診断し、診断のための処置オプションを生成することである。本発明を特定の理論またはメカニズムに限定することを望まないが、本発明の技術的特徴は、ユーザが自宅の快適さから実行できる自動診断および処置の効率的で包括的かつ正確な形態を有利にも提供すると考えられる。現在知られている以前の参考文献または研究のいずれも、本発明の独特の発明の技術的特徴を有していない。さらに、本発明の特徴は直観に反する。直感に反するのは、驚くべき結果に貢献したためである。例えば、当業者は、疾患データベースおよびユーザの医療記録からの情報を与えられたとしても、ユーザの複数の疾患に対応する症状を報告する状況をシステムが処理することができないことを予期するであろう。驚いたことに、この状況は、ＭｙＤｏｃプラットフォームによって、ユーザの病歴と、診断モジュールによって要求された追加の試験とを使用して、ユーザの状態に最も一致する可能性が高いものをリストする確率テーブルを使用して克服され、正確な診断のために時間の大多数を提供する。したがって、本発明の特徴は、驚くべき結果に貢献し、直観に反している。

【0024】

本発明の別の独特で進歩的な技術的特徴は、処置の回復時間の予測と、二次的な処置行動の適用時の回復時間の調整である。本発明を特定の理論または機構に限定することを望まないが、本発明の技術的特徴は、ユーザが回復時間を計画し、処置が正しいペースで進行しているか否かを追跡するための効率的かつ正確な方法を有利にも提供すると考えられる。現在知られている以前の参考文献または研究のいずれも、本発明の独特の発明の技術的特徴を有していない。さらに、本発明の特徴は直観に反する。直感に反するのは、驚くべき結果に貢献したためである。例えば、当業者は、ユーザが既に服用している薬物が、データベース上の平均回復時間から回復を早くしたり遅くしたりする場合など、特定の場合に計画回復時間が完全に不正確であると予想する。驚くべきことに、本発明は、ユーザに対する回復時間を個別化するアクティブな監視および計算の使用を通じて、特定のユーザの回復時間を正確に予測することができ、より正確な予測をもたらす。したがって、本発明の特徴は、驚くべき結果に貢献し、直観に反している。

【0025】

本明細書に記載の特徴または特徴の組み合わせは、文脈、本明細書、および当業者の知識から明らかであるように、そのような組み合わせに含まれる特徴が相互に矛盾しない限り、本発明の範囲内に含まれる。本発明のさらなる利点および態様は、以下の詳細な説明および特許請求の範囲において明らかになろう。

【図面の簡単な説明】

【0026】

本発明の特徴および利点は、添付の図面に関連して提示される以下の詳細な説明を検討することから明らかになるであろう：

【図1】本発明の外部通信機モジュールの概略図を示す図である。

【図2】医療記録およびユーザ症状を使用して、ユーザ症状の考えられる原因のリストを生成する本発明の診断モジュールの概略図である。

【図3】疾患情報のデータベースを使用して複数のテーブルを作成し、ユーザ症状の考えられる原因のリストを生成する本発明の診断モジュールの概略図である。

【図4】本発明のＭｙＤｏｃｔｏｒプラットフォームの概略図である。

【図5】個人用の完全自律型医療ソリューションの一般的なスキームを示すブロック図である。

【図6】ユーザ口座モジュールおよびその全体の発明との統合を示すブロック図である。

【図7】一般情報のブロック図である。

【図8】医療記録のブロック図である。

【図9】報告された状態のブロック図である。

【図10】ユーザ習慣のブロック図である。

【図11】支払いゲートウェイのブロック図である。

【図12】対話モジュールのブロック図である。

【図13】対話モジュールの挨拶事例のブロック図である。

【図14】診断モジュールのブロック図である。

【図15】診断モジュールの特性分析のブロック図である。

【図16】試験分析モジュールのブロック図である。

【図17】処置モジュールのブロック図である。

【図18】症例監視モジュールのブロック図である。

【図19】外部通信機モジュールのブロック図である。

【図20】看護サービスモジュールのブロック図である。

【図21】栄養士モジュールのブロック図である。

【図22】中央調査モジュールのブロック図である。

【図23】健康モジュールのブロック図である。

【図24】身体活動モジュールのブロック図である。

【図25】呼吸装置モジュールのブロック図である。

【図26】除細動器モジュールのブロック図である。

【図27】心理療法モジュールのブロック図である。

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

【0027】

図１を参照すると、本発明は、複数のソースからのユーザの病歴を編集するための仮想医師（ＭｙＤｏｃｔｏｒ）プラットフォーム（６００）を特徴とする。いくつかの実施形態では、プラットフォームは、複数のソースからのユーザの病歴に関する情報を収集するための外部通信機モジュール（９００）を含み得る。外部通信機モジュール（９００）は、ソースからのデータを受け入れ、データを標準フォーマットに暗号化するための命令を備えたデータ暗号化モジュール（９１０）を含み得る。データ暗号化モジュール（９１０）は、ユーザから、または複数の外部医療ソース（９３０）から直接データを受け入れることができる。いくつかの実施形態では、プロセスは人が各病院／フォーマット／医療グループのデータを処理するためのものであり、プラットフォームは各フォーマットから学習し、変換手順をスクリプトとして処理し、同じフォーマットの将来のすべての情報に対してプロセスを繰り返すことができる。たとえば、データ形式Ａをデータ形式Ｚに変換する必要がある場合、人または機械学習を利用するシステムがデータを処理して、個人情報、医療記録などを引き出す。情報の場所とデータ形式Ａとして情報を保存する方法を保存でき、将来のすべてのデータ形式Ａについても同じ方法で変換できる。このプロセスは、他のすべてのフォーマットで繰り返すことができる。画像データの場合、画像をソースからエクスポートし、機械学習を使用して画像を読み取って分析することにより、プラットフォームで処理できる。画像はＮｉｆｔｉまたはＤｉａｃｏｍにフォーマットできる。

【0028】

外部通信機モジュール（９００）は、データ暗号化モジュール（９１０）から暗号化データを受け取り、暗号化データを圧縮データに圧縮し、圧縮データを外部記憶（９０００）素子または複数の外部医療ソース（９３０）に送信するための命令を有するデータ圧縮モジュール（９２０）をさらに備えることができる。複数の外部医療ソース（９３０）は、病院、医療研究所、クリニック、救急センター、および薬局であり得る。外部通信機モジュール（９００）は、病院と通信して、ユーザの医療記録および予約を手配するためのスケジュール情報を受信し、ユーザデータおよび予約要求を病院に送信することができる。外部通信機モジュール（９００）は、医療研究所と通信して、ユーザの医療記録、予約を手配するためのスケジュール情報、および研究所での結果を受信し、ユーザデータおよび予約要求を医療研究所に送信することができる。外部通信機モジュール（９００）は、クリニックと通信して、ユーザの医療記録および予約を手配するためのスケジュール情報を受信し、ユーザデータおよび予約要求をクリニックに送信することができる。外部通信機モジュール（９００）は、救急センターと通信して救急車を依頼し、ユーザデータおよびユーザの位置を緊急センターに送信することができる。外部通信機モジュール（９００）は、薬局と通信して、ユーザの医療記録および処方の価格設定情報を受信し、ユーザデータ、複数の処方箋、および処方箋の配達場所を薬局に送信することができる。

【0029】

ここで図２～３を参照すると、本発明は、ユーザの医学的問題を診断するためのＭｙＤｏｃｔｏｒプラットフォームを特徴とする。一部の実施形態では、プラットフォームは、医療記録（２１００）のデータベースを含み得る。医療記録（２１００）のデータベースは、ユーザの病歴、ユーザの既存の状態のリスト、およびユーザが現在服用している薬物のリストを含むことができる。プラットフォームはさらに、考えられる原因にマッピングされた疾患症状のデータベースにアクセスし、ユーザからのユーザ症状のリストを受け入れるための命令を有する診断モジュール（４００）を含むことができる。診断モジュール（４００）は、各ユーザ症状をユーザ症状の考えられるすべての原因にマッピングする第１のテーブル（４１０）を生成するための命令をさらに含み得る。第１のテーブル（４１０）は、ユーザの年齢、性別、体重、および病歴を含む医療記録のデータベースからのデータを使用してフィルタリングされ得る。診断モジュール（４００）は、すべてのユーザの症状を共有するすべての考えられる原因（４５０）を表示する第２のテーブルを生成し、医療記録（２１００）のデータベースからデータを受け入れ、それぞれの考えられる原因の存在確率に基づいて、すべての考えられる原因（４５０）を順位付けする確率テーブルを生成し、医療記録（２１００）のデータベースからのデータに基づいて考えられる原因の処置（４７５）を決定する。確率テーブルは、すべてのユーザ症状に対して生成される。確率の重みは、ユーザの症状と考えられる原因の症状の間で一致する症状の数をユーザの症状の総数で割ることによって計算できる。いくつかの実施形態では、確率重みは、ユーザの場所の周りの半径内で報告された病気に従って調整されてもよい。いくつかの実施形態では、診断モジュール（４００）は、考えられる原因をよりよく判断するためにユーザに複数の試験を要求するための命令をさらに含み得、そしてＭｙＤｏｃｔｏｒプラットフォーム（６００）は、ユーザが複数の試験を実行できるようにするための試験装置をさらに含み得る。試験装置は、個人のバイタルサインモニタ、個人の心電図、血糖計、超音波画像装置、心臓モニタ、および皮膚画像カメラを含み得る。いくつかの実施形態では、ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、ユーザからの試験結果を受け入れ、その試験結果を処理して診断プラットフォームが考えられる原因を生成するのを助けるための試験分析器モジュール（５００）をさらに含むことができる。１つの症状のみを報告する患者の場合、プラットフォームは患者の病歴、地域で報告された病気をチェックし、最も可能性の高い病気を特定するために、より多くの情報を取得するためにさらに試験を実行する。いくつかの実施形態では、疾患症状のデータベースは、クラウドサーバに格納され、診断モジュール（４００）によってアクセスされる。

【0030】

図４を参照すると、本発明は、複数のソースからのユーザの病歴を編集し、その病歴を使用してユーザの医学的問題を診断するためのＭｙＤｏｃｔｏｒプラットフォーム（６００）を特徴とする。プラットフォームは、複数のソースからユーザの病歴に関する情報を収集するための外部通信機モジュール（９００）を含み得る。外部通信機モジュール（９００）は、ソースからのデータを受け入れ、データを標準フォーマットに暗号化するための命令を有するデータ暗号化モジュール（９１０）を含み得る。データ暗号化モジュール（９１０）は、ユーザから直接、または複数の外部医療ソース（９３０）からデータを受け入れることができる場合がある。外部通信機モジュール（９００）は、データ暗号化モジュール（９１０）から暗号化データを受け取り、暗号化データを圧縮データに圧縮し、圧縮データを外部記憶素子（９０００）または複数の外部医療ソース（９３０）に送信するための命令を有するデータ圧縮モジュール（９２０）をさらに含み得る。プラットフォームは、医療記録（２１００）のデータベースをさらに含み得る。医療記録（２１００）のデータベースは、ユーザの病歴、ユーザの既存の状態のリスト、およびユーザが現在服用している薬物のリストを含むことができる。

【0031】

プラットフォームは、考えられる原因にマッピングされた疾患症状のデータベースにアクセスし、ユーザからユーザ症状のリストを受け入れるための命令を有する診断モジュール（４００）をさらに含み得る。診断モジュール（４００）は、各ユーザ症状をユーザ症状の考えられるすべての原因にマッピングする第１のテーブル（４１０）を生成するための命令をさらに含み得る。第１のテーブル（４１０）は、ユーザの年齢、性別、体重、および病歴を含む医療記録のデータベースからのデータを使用してフィルタリングされ得る。診断モジュール（４００）は、すべてのユーザの症状を共有するすべての考えられる原因（４５０）を表示する第２のテーブルを生成し、医療記録（２１００）のデータベースからデータを受け入れ、各考えられる原因の存在の確率に基づいて、すべての考えられる原因（４５０）を順位付けする確率テーブルを生成し、そして医療記録（２１００）のデータベースからのデータに基づいて考えられる原因の処置（４７５）を決定する、ための命令を有する。確率テーブルは、すべてのユーザの症状に対して生成される。確率の重みは、ユーザの症状と考えられる原因の症状の間で一致する症状の数をユーザの症状の総数で割ることによって計算できる。いくつかの実施形態では、診断モジュール（４００）は、考えられる原因をよりよく判断するためにユーザに複数の試験を要求するための命令をさらに含み得、そしてＭｙＤｏｃｔｏｒプラットフォーム（６００）は、ユーザが複数の試験を実行できるようにするための試験装置をさらに含み得る。試験装置は、個人のバイタルサインモニタ、個人の心電図、血糖計、超音波画像装置、心臓モニタ、および皮膚画像カメラを含み得る。いくつかの実施形態では、ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、ユーザからの試験結果を受け入れ、その試験結果を処理して診断プラットフォームが考えられる原因を生成するのを助けるための試験分析器モジュール（５００）をさらに含むことができる。いくつかの実施形態では、疾患症状のデータベースは、クラウドサーバに格納され、診断モジュール（４００）によってアクセスされる。

【0032】

プラットフォームはさらに、ユーザが診断モジュール（４００）によって決定された処置（４７５）を実行するときにユーザの健康と回復を監視し、処置（４７５）に関連する処方を実行するように促し、予想される回復時間と実際の回復時間を比較して二次的な医療行動が必要かどうかを判断し、処方を二次的な行動として調整し、そして二次的な行動に基づいて予想される回復時間を調整する、ための命令を有する症例監視モジュール（８００）を含む。

【0033】

いくつかの実施形態では、ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、診断モジュール（４００）によって生成された複数の考えられる原因に対して複数の処置を生成し、ユーザが処置の経路を選択できるようにする処置モジュール（７００）をさらに含むことができる。いくつかの実施形態では、外部通信機モジュール（９００）は、処方箋をユーザに送達するように指示するための命令をさらに含み得る。いくつかの実施形態では、ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、ユーザが登録看護師または認可医療提供者に医療問題、検査、または処置についてユーザを支援することを依頼できるようにする看護サービスモジュール（１０００）をさらに含み得る。いくつかの実施形態では、ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、医療記録（２１００）のデータベースに追加されるデータとしてユーザの食習慣を追跡し、プラットフォームによって決定された処置法に従ってユーザが健康な食事を維持するのを支援する、栄養士（１１００）モジュールをさらに含み得る。一部の実施形態では、ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、プラットフォームの複数のインスタンスによって記録されたデータのデータベースと通信し、試験結果、診断、および回復時間を送受信し、プラットフォームの計算と全体的なパフォーマンスを改善するための、中央研究モジュール（１２００）をさらに含むことができる。

【0034】

本発明は、クラウド上にアップロードすることができるＭｙＤｏｃｔｏｒプラットフォーム（６００）を特徴とし、アップロードおよび統合することができる様々なモジュールおよび周辺機器（個人診断装置）もプラットフォームに接続することができる。ＭｙＤｏｃｔｏｒプラットフォーム（６００）には、インターネットにリンクされたスマートフォンアプリケーションまたはスタンドアロン装置からアクセスできる。図５は、本発明の全体的なスキームを示す図である。

【0035】

ＭｙＤｏｃｔｏｒプラットフォーム（６００）のモジュールは、Ｐｙｔｈｏｎなどのバックエンドとしての適切なプログラミング言語、または類似の言語およびフロントエンドとしてのＰＨＰなどのより使いやすい言語を使用して統合することができる。ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、クリニック、病院、薬局、研究所、救急センター（９１１など）を含む医療センターなどのさまざまな関係当事者と通信するためのアクセシビリティを持つことができる。接続および統合されたさまざまなモジュールがＭｙＤｏｃｔｏｒプラットフォーム（６００）にアップロードされる。

【0036】

図６は、ユーザアカウントのレイアウトを示している。ユーザアカウントモジュールは、他のすべてのモジュールに接続でき、そこでは患者アカウントとの間でデータを交換できる。各ユーザ（１００）は、ユーザ（１００）に関する情報を入力するアカウントを持っている必要がある。登録に必要な情報は、口頭または手動で入力できる。リクエストが口頭である場合、システムは対話モジュール（３００）を介して音声認識アルゴリズム（Ｌｉｎｕｘ（登録商標）音声認識ソフトウェア－オープンソースなど）を使用してテキストに変換する場合がある。ユーザ（１００）はアプリケーションをオンにし、初めての場合はスマートフォームに入力する必要がある。システムは、ユーザ（１００）に質問を（音声で）尋ねて、名前、年齢、性別などのフォームに入力するよう求める。スマートフォームに入力し、すべての必須の質問に回答し、要件に入力すると、ユーザ（１００）はアクティブなアカウントを持つ。

【0037】

登録プロセスを促進するための別のオプションは、国民ＩＤ番号（例えば、社会保障番号）にリンクすることであり、国民ＩＤが挿入されると、システムは、名前、年齢、個人の写真および指紋などの一般情報を記入することができる。したがって、ユーザ（１００）は、医療履歴情報および請求のための支払情報に記入または取得を許可するだけでよい。緊急事態では、権限のある担当者または緊急対応チームが、音声／ユーザの指紋／ユーザの顔認識を介してユーザ（１００）のアカウントにログインできる。ここでこの機能は、ユーザ（１００）の意識がない場合にユーザアカウントモジュール（２００）に入るために重要である。毎回、ユーザ（１００）はシステムと対話し、声のトーンおよび顔の表情を記録することができる。ユーザ（１００）がシステムを使い続けると、声のトーンと顔の表情のデータベースは、機械学習を使用して処理され、ユーザ（１００）の感情と気分を特定できる。

【0038】

声調分析は、ユーザ（１００）の気分、ストレス、痛み、不安、およびうつ状態を決定する上で重要である。ユーザ（１００）上により多くのデータが収集されると、ＭｙＤｏｃｔｏｒプラットフォーム（６００）はユーザ（１００）の要求の緊急性を即座に判断できる。ユーザアカウントモジュール（２００）は、次のような多くの機能とオプションで構成される：
１．一般情報（２０００）
２．医療記録（２１００）
３．報告された状態（２２００）
４．ユーザの習慣（２３００）
５．支払いゲートウェイ（２４００）

【0039】

ユーザアカウントモジュール（２００）の一部として、ユーザ（１００）の一般情報（２０００）は、ユーザ（１００）を識別するための情報を含み得る。この情報を他の医療プロバイダーと共有して、ユーザ（１００）を特定し、ユーザ（１００）の医療記録を取得することもできる。

【0040】

ユーザ（１００）からの医療記録（２１００）は、より優れた迅速な診断を提供し、中央研究モジュール（１２００）を支援するために保持される場合がある。同時に、電子医療記録（ＥＨＲ）または病院情報サポートシステム（ＨＩＳＳ）をＭｙＤｏｃｔｏｒプラットフォーム（６００）に接続することにより、ユーザ（１００）の外部医療記録をユーザの医療記録（２１００）にアップロードできる。医療記録（２１００）は、ユーザ（１００）の健康状態を経時的に追跡するために、病気、ストレス、不快感、アレルギーのあらゆるケースに対して更新される場合がある。医療記録（２１００）は症例監視モジュール（８００）と通信して、処置の進行を記録できる。試験分析器モジュール（５００）は、試験と検査の結果を記録するために、医療記録にもリンクされている。外部通信機モジュール（９００）は医療記録にリンクされており、ラボなどの外部施設からや医師の入力の医療記録をフィードする。

【0041】

同時に、外部通信機モジュール（９００）は、医師などの外部医療施設に患者の医療記録（２１００）へのアクセスを提供することができる。医療記録はまた、診断モジュール（４００）と通信して診断プロセスをサポートし、処置モジュール（７００）と通信して処方された処置を記録する。また、中央研究モジュール（１２００）にフィードするために、一方向の通信チャネルを介してリンクされる。

【0042】

未成年者（例えば乳幼児）またはＭｙＤｏｃｔｏｒプラットフォーム（６００）を使用する能力がない人々のために、何らかの理由で、受託者はユーザ（１００）に代わってＭｙＤｏｃｔｏｒプラットフォーム（６００）と対話することができる。

【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】

ソリューションが効果的に機能するために、病院、薬局、研究室、救急センター、看護サービスプロバイダーなどの外部関係者は、システムに登録して要求を受信し、データを共有する必要がある。さまざまなタスクが実行され、データは各当事者により共有されるべきである。薬局は、販売品目を含む価格設定情報を外部通信機モジュール（９００）と共有できる必要がある。支払いゲートウェイ（２４００）は、外部の各当事者と通信して、支払い期日に支払いを行うことができる。病院のスケジュールシステムはソリューションと互換性がなければならないため、予約は自動的に、またはデータ暗号化モジュール（９１０）で変換できる形式で予約できる。病院の医療記録（２１００）もシステムにフィードでき、その逆も可能である。

【0084】

薬局は、処置モジュール（７００）によって開発された、処方薬送達のための場所などの指示を有する、処方を受け取ることができなければならない。ラボのスケジュールシステムもソリューションに接続して、予定をスケジュールできるようにする必要がある。診断モジュール（４００）によって決定された試験と手順は、ラボに提出する必要がある。同時に、ラボは結果をアップロードするか、試験分析モジュール（５００）からラボシステムにアクセスできる。緊急センターは、緊急事態の説明を含む救急車のリクエストを受信できる必要があり、ユーザ（１００）の位置は、スマートフォンまたはスタンドアロン装置から自動的に送信される必要がある。単純化された形式で、かつ、さまざまな医療施設がソリューションを採用する前に、システムは緊急センター（９１１など）への自動呼び出しを実行し、その場所に関する音声メッセージを介して支援を要求できる必要がある。このような緊急電話は、ユーザ（１００）によって、または、ユーザ（１００）が心臓発作などの緊急事態の影響を受けやすいときに、バイタルサインの読み取りの結果としてトリガーされる。

【0085】

図２０は、看護サービスモジュール（１０００）を示している。看護サービスモジュール（１０００）は、登録看護師または認可医療提供者と連携して働き、サインインし、オンデマンドサービスとしてユーザ（１００）により雇用されうるようにする。ボランティアも、必要なユーザ（１００）にサービスを提供するために登録し、提供されたサービス時間のログを受け取ることもできる。ボランティアは、これを慈善活動、プロボノ、またはコミュニティサービスとして宣言できる。ユーザ（１００）は、彼／彼女の近所で利用可能な看護師またはボランティアを検索するか、または彼／彼女のニーズで広告を開始することができ、関心のある看護師またはボランティアは、彼らのサービスを提供するために応答および申請することができる。

【0086】

ボランティアであるか登録看護師であるかにかかわらず、彼らの医療サービスを提供することに興味がある人は、アプリケーションを介して、またはウェブページを介して登録するべきである。基本的な情報は、簡単な生い立ち、写真、資格、履歴書とともに入力する必要がある。登録看護師またはボランティアは、身元調査を受ける。身元調査では、機関やセキュリティオフィスからの推奨など、さまざまなシナリオが考えられる。履歴チェックは、ユーザ（１００）のセキュリティにとって重要であり、サービスプロバイダーとして最低限必要な経験を保証するために重要である。登録が完了すると、看護師またはボランティアは、カバレッジの場所とともに彼または彼女の空席状況をトリガーできる。ユーザ（１００）が看護サービスを要求すると、アプリケーションは近隣の利用可能なすべてのサービスプロバイダーを表示する。ボランティアは割り当て可能な時間数を提供することができるが、看護師は時間給を決定できる。ユーザ（１００）が看護師を選択すると、患者の状態、病歴、患者の場所、および求められているサービスについての簡単な情報を含むメッセージが看護師に送信される。看護師は、割り当てを拒否または受け入れることができる。次に、看護師またはサービス提供者がユーザ（１００）の場所に派遣され、サービスの後に、ユーザ（１００）は、サービス提供者を評価して、評価を他のユーザと共有することができる。

【0087】

図２１は、栄養士モジュール（１１００）を示す。栄養士モジュール（１１００）は栄養士の役割を果たし、健康の目標、食品の好み、ライフスタイルに合った計画を立てることができる。たとえば、栄養士モジュール（１１００）は、ユーザ（１００）の炭水化物の摂取量を監視し、血糖値をより安定させるために、食事やスナックごとに摂取する必要のある炭水化物の量を決定する。

【0088】

栄養士モジュール（１１００）は、医療記録（２１００）のチェックと共に、ユーザ（１００）の食習慣の初期評価を行うことができる。ユーザ（１００）と栄養士モジュール（１１００）の間で行われる可能性のある対話は、食習慣評価フォームの記入である。ユーザ（１００）の入力に基づいてアンケートに記入することができる。アンケートの目的は、患者が食べる食べ物、量、好みを決定することである。たとえば、栄養士モジュール（１１００）は、ユーザ（１００）に次の質問をする場合がある：
・毎日何回食事をするか？
・通常、各食事には何を食べるか？
・昨日は何を食べたか？

【0089】

いくつかの応答では、栄養士モジュール（１１００）は、量が与えられていない場合に量を要求することがある。また、数量は説明的な形式にすることもできる。たとえば、ユーザ（１００）がカシューナッツを食べていると述べた場合、栄養士モジュール（１１００）は、ユーザ（１００）が一握りまたは数口などの回答を受け入れることで、数量の大まかな見積もりを提供するのに役立つ。ユーザ（１００）の応答は、２つのテーブルに入力されてもよい。１つは、過去２４時間のユーザ（１００）の食べ物（１つの例が表６として表示される）とユーザ１００が通常食べる典型的な食べ物である。多くの人は、非日常的な食物を食している。栄養士モジュール（１１００）は、そのような情報を抽出し、分析のためにそれらを表にすることができる。

【0090】

栄養士モジュール（１１００）には、すべての食品の成分とカロリーのテーブルがある場合がある。ユーザ（１００）の入力に基づいて、栄養士モジュール（１１００）は、食品をカロリーおよび成分に変換することができる。たとえば、患者が定期的にカシューナッツを食べる場合、ユーザ（１００）の平均摂取量が約１００ ｍｇであれば、栄養士モジュール（１１００）が１００ ｇｍのカシューナッツをその成分に変換することがある。ユーザ（１００）がパスタなどのレシピを入力すると、システムはレシピの内訳を含むテーブルを有することができる。料理が事前定義されていない場合、モジュールはユーザ（１００）に料理の材料を提供するよう要求する場合がある。栄養士モジュール（１１００）は、成分の摂取量の分析に基づいて、患者が十分な量を摂取していない特定のビタミンなどの要素を特定し、不足している要素を含む食品を推奨する場合がある。

【0091】

図２２は、中央研究モジュール（１２００）を示している。中央研究モジュール（１２００）はバックオフィスで動作し、そこでは医学研究の目的でデータが収集される。ＭｙＤｏｃｔｏｒ プラットフォーム（６００）のすべてのユーザから収集された大量のデータにより、症例監視モジュール（８００）からの医薬品の有効性が向上する可能性がある。そのユーザ（１００）に対する試験と診断の間の相関を分析することにより、不要な試験を排除できる。各ユーザ（１００）の病気と処置が分析される。収集されたデータを使用して、民族性とＤＮＡによってユーザ（１００）を分離し、再発する病気の確率を分析し、機械学習（Ｍ．Ｌ．）とともにデータサイエンスを利用して予防医学を提供することができる。データは、世界中の研究者向けのオープンソースとして利用できる可能性がある。

【0092】

図２３は、健康モジュール（１３００）を示している。健康モジュール（１３００）は、ユーザ（１００）の健康を改善できる一般的な推奨事項を提供し、栄養士モジュール（１１００）および身体活動モジュール（１４００）と協力して、ユーザ（１００）の特別の要求に基づいて、ユーザ（１００）の年齢、健康状態、および遺伝性疾患を含む医療記録（２１００）を考慮して決定される、特定のサプリメントを推奨する。

【0093】

図２４は、身体活動モジュール（１４００）を示す。身体活動モジュール（１４００）は、身体活動の追跡および指示をユーザ（１００）に提供することができる。身体活動モジュール（１４００）は、ユーザ（１００）が１日に行った運動量に関するデータを追跡および収集し、結果をフィードバックして、ユーザ（１００）が求める結果を取得するための改善をユーザ（１００）に指示することができる。

【0094】

身体活動モジュール（１４００）はまた、理学療法でユーザ（１００）を支援し、指導ビデオおよびユーザ（１００）のバイタルサインの監視を通じてユーザ（１００）の可動域を改善することができる。

【0095】

図２５は、呼吸装置モジュール（１５００）を示す。呼吸装置モジュール（１５００）は、呼吸可能な空気を非侵襲的な換気マスクまたはバッグバルブマスクに移動して、物理的に呼吸できない、または呼吸が不十分なユーザ（１００）に呼吸を届ける人工呼吸器として機能できる。呼吸装置モジュール（１５００）は、ネブライザーとして機能し、換気マスクを介してミストで薬液を投与することにより、喘息のあるユーザ（１００）を支援する。呼吸装置モジュール（１５００）は、最初からユーザ（１００）の長期呼吸サポートシステムとして設定できる。または、ユーザ（１００）が呼吸支援を必要とする症状を要求した場合、ユーザ（１００）が起動できる。

【0096】

図２６は、除細動器モジュール（１６００）を示す。除細動器モジュール（１６００）は、心臓に一定量の電流を供給することにより、生命にかかわる心不整脈を処置する。このモジュールは、誰でも緊急装置として使用して、必要とする人を助けることができる。または、緊急医療支援を必要とする可能性のあるユーザ（１００）を支援するために誰かが利用できる。緊急事態では、ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、ユーザ（１００）または対話モジュール（３００）を通じて緊急医療を提供できる人に、除細動器モジュール（１６００）を利用するように指示できる。ＭｙＤｏｃｔｏｒプラットフォーム（６００）を他の人を救う緊急装置として利用する。バイタルサインの読み取り値に基づくプラットフォームが患者の状態を「コードブルー」と決定した場合、ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、緊急センターへの通話をアクティブにすることに加えて、サイレンをアクティブにすることができ、ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、ユーザ（１００）または緊急ケアを提供できる人に、除細動器を使用して、必要とする人またはユーザ（１００）に緊急医療サービスを実行する方法を指示することができる。

【0097】

図２７は、心理療法モジュール（１７００）を示す。心理療法モジュール（１７００）は、診断および心理学的評価をユーザ（１００）に提供して、状態を判断し、推奨を拡張する。顔の感情と声のトーンを使用して、状態の進行度合を評価できる。対話モジュール（３００）を利用して、ユーザ（１００）の声の調子が分析され、ユーザ（１００）が苦痛、痛み、不安、抑うつ状態または怒りであるかどうかが判断される。ＭｙＤｏｃｔｏｒプラットフォーム（６００）は、機械学習を利用してユーザ（１００）に適応し、ユーザアカウントモジュール（２００）から構築されたベースで、ユーザ（１００）の医療記録（２１００）、その他の報告された習慣や状態を特定する。ユーザ（１００）は対話モジュール（３００）を使用して、ＭｙＤｏｃｔｏｒプラットフォーム（６００）に感情的および心理的な問題を伝えることができる。たとえば、ユーザ（１００）は、不安定な声、発話に影響を与える息切れ、発汗、胸の痛みと窒息の訴えで震えている可能性がある。診断モジュール（４００）は、これが不安またはパニック発作であるとすぐに判断し、ユーザ（１００）に応答して呼吸運動の自己療法を実行すると同時に、心地よい声と音楽、または、自然な音で積極的な励ましを提供する。より厳しい状況では、ユーザ（１００）は、自殺したいとＭｙＤｏｃｔｏｒプラットフォーム（６００）に話しかけることができる。ＭｙＤｏｃｔｏｒプラットフォーム（６００）はすぐに緊急サービスに通知し、ユーザ（１００）を質問や励ましで紛らわせ、緊急サービスにユーザ（１００）に到達する時間を与える。

【0098】

プラットフォームは、多くの場合、人の心理に影響を与える可能性のある体調の分析を行うことができる。診断モジュールは、心理に影響を与える可能性のある化学物質の不均衡などの物理的状態の可能性を追跡するために使用できる。物理的な診断テーブルと同様の診断テーブルは、患者の苦情が感情的な懸念に関連する場合にトリガーされる。診断後、特定の事前定義された生理学的試験を実行すると、システムは、さまざまな処置計画を決定できる処置サブモジュールをトリガーできる。別の例では、ユーザ（１００）は、心理療法モジュール（１７００）を利用して長期の心理療法を受けることができる。セラピーは、自己改善、自信の構築、恐怖の克服、オーディオブックの再生、または単にＭｙＤｏｃｔｏｒプラットフォーム（６００）に話しかけストレスを解放し心の平静を得ることである。ＭｙＤｏｃｔｏｒプラットフォーム（６００）はこのユーザ（１００）データを収集し、機械学習を通じてユーザ（１００）の改善を追跡し、処置セッションを調整する。

【0099】

本発明の好ましい実施形態を示して説明してきたが、添付の特許請求の範囲を超えない修正を行うことができることが当業者には容易に明らかであろう。したがって、本発明の範囲は、以下の特許請求の範囲によってのみ制限されるべきである。いくつかの実施形態では、この特許出願に提示される図は、角度、寸法の比率などを含む縮尺で描かれている。いくつかの実施形態では、図は代表的なものにすぎず、特許請求の範囲は図の寸法によって限定されない。いくつかの実施形態では、「有する」という語句を使用して本明細書に記載される発明の説明は、「から本質的に構成される」または「から構成される」と説明できる実施形態を含み、したがって、「から本質的に構成される」または「から構成される」という語句を使用する本発明の１つまたは複数の実施形態を主張するための書面による記載要件は適合する。

【0100】

以下の特許請求の範囲に記載されている参照番号は、この特許出願の検討を容易にするためのものであり、例示であり、図中に対応する参照番号を有する特定の特徴に特許請求の範囲を限定することを決して意図しない。

【符号の説明】

【0101】

以下は、ここで参照される特定の要素に対応する要素のリストである:
１００ ユーザ
２００ ユーザアカウントモジュール
３００ 対話モジュール
４００ 診断モジュール
４１０ 第１のテーブル
４２０ 第２のテーブル
４３０ 確率テーブル
４５０ 考えられる原因
４７５ 処置
５００ 試験分析器モジュール
６００ ＭｙＤｏｃｔｏｒプラットフォーム
７００ 処置モジュール
８００ 症例監視モジュール
９００ 外部通信機モジュール
９１０ データ暗号化モジュール
９２０ データ圧縮モジュール
９３０ 外部医療ソース
１０００ 看護サービスモジュール
１１００ 栄養士モジュール
１２００ 中央研究モジュール
１３００ 健康モジュール
１４００ 身体活動モジュール
１５００ 呼吸装置モジュール
１６００ 除細動器モジュール
１７００ 心理療法モジュール
２０００ 一般情報
２１００ 医療記録
２２００ 報告された状態
２３００ ユーザの習慣
２４００ 支払いゲートウェイ
９０００ 外部記憶素子

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】