特許 6987417 プラットフォーム型医療機関支援システムの医療情報共有データベース

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

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

(11)【特許番号】6987417

(24)【登録日】2021年12月3日

(45)【発行日】2022年1月5日

(54)【発明の名称】プラットフォーム型医療機関支援システムの医療情報共有データベース

(51)【国際特許分類】

   G16H 10/00 20180101AFI20211220BHJP

【ＦＩ】

   G16H10/00

【請求項の数】6

【全頁数】117

(21)【出願番号】特願2021-114925(P2021-114925)

(22)【出願日】2021年7月12日

(62)【分割の表示】特願2021-113941(P2021-113941)の分割

【原出願日】2021年7月9日

【審査請求日】2021年7月12日

【早期審査対象出願】

(73)【特許権者】

【識別番号】717007181

【氏名又は名称】Ａｄｖａｎｃｅｄ Ｍｅｄｉｃａｌ ＩｎｆｏＴｅｃ株式会社

(72)【発明者】

【氏名】川崎 智子

(72)【発明者】

【氏名】相坂 真仁

(72)【発明者】

【氏名】川崎 功

【審査官】 岡北 有平

(56)【参考文献】

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

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

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

【文献】 特開２００６−２９３７５２（ＪＰ，Ａ）

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

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

Ｇ１６Ｈ １０／００ − ８０／００

Ｇ０６Ｑ １０／００ − ９９／００

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

【請求項1】

プラットフォーム型医療機関支援システムの医療情報共有データベースにある医療経済圏ＤＢに保存されている個人情報と認証情報とに紐づけされた
患者情報DBがあり、
決済媒体を作るために個人情報を提供せずに、代わりに患者情報ＤＢ内に保存されている患者の個人情報を利用して
この患者の前記個人情報を患者の医療決済口座を作るための基礎情報に宛てることで
医療機関での決済が行える決済媒体の発行と医療用決済口座の開設が行われることを特徴とし、
さらに、医療機関で使用する患者情報DBの情報を利用することで前記決済媒体の発行と前期開設は医療機関の受付窓口で迅速に行えることを特徴とし、
前記患者の医療決済口座の情報と決済媒体の情報は
医療経済圏ＤＢにある決済関係ＤＢに保存されることを特徴とし
医療機関における決済は、前記決済媒体または、認証情報にある患者の生体情報を使用して行えることを特徴とし、
決済の結果情報を医療機関決済支援システム上の
決済関係ＤＢに保存することを特徴とし、
複数の医療機関で利用できるようにネットワーク上の決済共通基盤となる
サービスの提供を行うビジネスモデルを実現するプラットフォーム型医療機関決済支援システム

【請求項2】

請求項１に記載の医療機関決済支援システムにおいて
前記医療決済口座を利用して、医療経済圏内における決済の効率化を行うことを目的とし、
医療経済圏内の医療機関での支払いは、医療機関決済支援システムで開設されている医療機関の医療決済口座及び患者の医療決済口座である決済関係ＤＢに保存された口座で行われ、
患者の医療決済口座から支払い情報を送ることにより
患者の支払い情報を受け取った医療機関の医療決済口座には、
様々な支払い情報が蓄積されていき、
蓄積された支払い情報は、医療機関決済支援システムの決済関係ＤＢへ請求することで現金を受け取れる、又は電子化した情報のまま決済が行える
サービスの提供を行うビジネスモデルを実現するプラットフォーム型医療機関決済支援システム

【請求項3】

請求項２に記載の医療機関決済支援システムにおいて
医療決済口座を利用することによる、
医療経済圏内における決済の効率化を行うことを目的とし、
複数の医療機関への支払いを
支払い先の医療機関の中から任意の医療機関で決済の代行が行えることを特徴とし、
複数の医療機関への支払いが一括で行える
サービスの提供を行うビジネスモデルを実現するプラットフォーム型医療機関決済支援システム

【請求項4】

請求項２に記載の医療機関決済支援システムにおいて
医療経済圏内における決済の効率化を行うことを目的とし、
医療機関以外での支払い時に
前記決済媒体または、患者の生体情報を利用し
決済用端末に提示することにより
医療機関以外での支払いが行えることを特徴とし、
医療機関以外の事業者の決済口座に対し
患者の医療決済口座から支払い金額に応じた情報を送ることにより
医療機関以外の事業者への支払いが行えることを特徴とし、
支払い内容や支払い結果と購入したモノの情報が買物履歴情報として医療機関決済支援データベース上の医療経済圏ＤＢにある決済関係ＤＢに蓄積されることを特徴とした
サービスの提供を行うビジネスモデルを実現するプラットフォーム型医療機関決済支援システム

【請求項5】

請求項１から４のいずれかに記載の医療決済支援システムにおいて
決済関係ＤＢを含む医療決済支援システムは、
患者や患者家族が患者生活資金と患者個人資産を生涯に渡り安全に管理することを望んだ場合、信託管理と相続管理と遺言管理とのうちいずれかの依頼処理を機関へ行い、依頼を受けたい機関へ患者の情報提供処理と信託契約管理処理等の信託サービスを行うことを特徴としたサービスの提供を行うビジネスモデルを実現するプラットフォーム型医療機関決済支援システム

【請求項6】

請求項５に記載の医療決済支援システムを利用し
患者本人による個人情報の提供が病状から難しい患者でも
医療情報共有データベースの患者情報ＤＢにあるこの患者の前記個人情報を患者の医療決済口座を作るための前記基礎情報を利用することで簡単かつ迅速に決済手段が作成できるサービスの提供と、
病状から決済媒体を常に紛失や忘れてしまう患者でも
医療情報共有データベースの医療経済圏ＤＢにある患者の認証情報により決済ができる決済サービスの提供と、
複数の医療機関にまたいだ支払いを一か所で行える決済サービスの提供と
病状から患者の生活資金を保護し患者が安心決済利用できる制限機能を持つ決済サービスの提供と
病状の進行から患者の個人資産を安全に守るため信託を行う機関をサーチし、サーチ結果の期間へ患者の情報提供処理と信託契約管理処理までを行う事を特徴としたサービスの提供を行うビジネスモデルを実現するプラットフォーム型医療機関決済支援システム

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、プラットフォーム型医療機関支援システムの医療情報共有データベースに関する。

【背景技術】

【0002】

現在、医療分野において医療情報システムを積極的に活用し、効率的かつ質の高い医療提供体制の構築を積極的に行おうとしている動きがある。しかしながら、医療機関にとって、現在の医療情報システムは、医療情報システムの標準化が図られていないため、各医療機関でシステム開発をカスタムメイドで行い、システムの導入及び入替のコストが膨大となっている等の現状がある（例えば、非特許文献１）。また、医療業界のIT対する考え方が古く、かつ、業務の特性上個人情報の扱いが難しく、取得するデータのセキュリティ対策が必要などの理由によりIT化による業務効率化が進んでいない現状もある（例えば、非特許文献２）。

【0003】

また、２０２０年に流行したCＯＶＩＤ−１９においては、２０１９年と２０２０年の同時期の同時期を比較すると医療機関を受診した人数の減少が発生している（例えば、非特許文献３）。この文献は、神奈川県を調査対象としたものの結果となっているが、同様の傾向が日本全国で発生していると推定される。

【0004】

医療機関への受診人数の減少が発生しているため、医療機関は、収益の減少が発生しており、結果、医療情報システムの導入や更新などへの投資が行われていないと推定される。

【先行技術文献】

【非特許文献】

【0005】

【非特許文献1】“日本における医療情報システムの標準化に係わる実態調査研究 報告書” 、［online］、厚生労働省［２０２１年７月２日検索］、インターネット＜ＵＲＬ：https://www.mhlw.go.jp/content/10808000/000685907.pdf＞

【非特許文献2】“IT化が遅れている業界はどこ？その理由やIT化のポイントを解説” ［online］、Urchin&Company株式会社［２０２１年７月２日検索］、インターネット＜ＵＲＬ：https://start-it.jp/business/it-delay/＞

【非特許文献3】“受診控えによる健康悪化懸念 救急搬送、がん診断遅れ、炎症増悪で抜歯...など重症化事例も”、［online］、神奈川県保険医協会［２０２１年７月２日検索］、インターネット＜ＵＲＬ：https://www.hoken-i.co.jp/outline/20200811_covid19AK-part3.pdf＞

【発明の概要】

【発明が解決しようとする課題】

【0006】

現在の医療機関の収益構造は、患者数に依存したビジネスモデルとなっているため、非特許文献３で開示した事象など、何らかの事情により多くの患者が通院を控えると経営状況が悪くなる。非特許文献２で開示のように、近年多くの業態で一般化している業務効率化が医療分野では遅れているため、経営悪化の要因ともなっている。

【0007】

本発明は、医療に関する物流や決済を行うサービスの提供、医療機関への経営支援や医療支援、利用者への健康支援、患者へのサービスの提供などをプラットフォーム型医療機関支援システムを用いて提供することを目的としている。

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

【0008】

医療機関にある医療情報システム内にある情報やプラットフォーム型医療機関支援システムの電子カルテで扱う医療経済圏ＤＢにある情報などの様々な情報が医療情報共有データベース上の様々なデータベースに保存されている。この情報を利用した収益の得られる仕組みを揃えたことで医療機関の経営改善による事業の持続化とシステムの持続化できるシステムとデータベースの提供を行う。

【0009】

医療情報共有データベース上の様々なデータベースの１つである、医療経済圏ＤＢには、医療経済圏を利用する人の個人情報や医療経済圏を利用する企業の事業情報、前記個人情報に紐づいた個人を認識する認識情報などが保存されている。また、経理業務ＤＢには、医療経済圏を利用する企業がバーチャルな環境で事業を行ううえでプラットフォーム型医療機関支援システムにあるシステムを利用すると発生する経理や経費などの各種情報が保存されている。

【0010】

本開示のプラットフォーム型医療機関支援システムは、前記医療経済圏ＤＢと前記経理業務ＤＢとに保存された情報と、プラットフォーム型医療機関支援システム内の様々なシステムとを利用することにより医療経済圏を利用する企業の経営支援を行う。

【0011】

本開示のプラットフォーム型医療機関支援システム上の医療情報共有データベースは、医療経済圏ＤＢに保存されている患者の個人情報に紐づけられた様々なデータベースで構成されており、医療経済圏ＤＢに保存されている認識情報には人を認識する情報が保存されている。この認識情報は、医療機関で患者を管理する管理番号を使用することができ、この情報を利用することにより、従来の医療情報システムの電子カルテとプラットフォーム型医療機関支援システムとを併用して利用することができる。

【0012】

バーチャルな医療経済圏を利用する企業が経営に利用する経営システムに、プラットフォーム型医療機関支援システムにある経営支援システムを利用することができる。このシステムは、医療経済圏ＤＢ内に企業情報として保存されている医療機関及び介護機関と企業・事業者と紐づけられている経理業務ＤＢにある備品経費情報に医療経済圏を利用する企業のそれぞれで消費する備品の消費量又は払い出された量の消費状況や在庫量などが保存されている。

【0013】

プラットフォーム型医療機関支援システムにある経営支援システムは、備品の消費状況又は在庫状況が、別途定める閾値に達した場合に、自動で発注先に発注処理を行い、発注した備品の決済を医療機関決済支援システムを用いて自動で行う。この閾値は、在庫量または消費量の推移傾向により可変である。

【0014】

プラットフォーム型医療機関支援システムにある経営支援システムは、備品の消費状況又は在庫状況を算出し別途定める量での発注量で、自動で発注先に発注処理を行い、発注した備品の決済を医療機関決済支援システムを用いて自動で行う。

【0015】

医療経済圏を利用する複数の企業がバーチャル化された医療経済圏の中で、リカーリングシステムは、複数の企業で消費する備品の発注量を合計した備品の中から選定した物をボリュームプライスで購入できる包括契約を行うために、備品の中から契約するもの包括選定ＡＩにより自動選択し、契約の候補先へ包括契約の価格見積金額の依頼を行い、 回答から有利な包括契約を行える契約先を自動で選定し、選定した契約先に自動で発注を行い、納品後の決済を医療機関決済支援システムを用いて自動で行う。

【0016】

医療経済圏を利用する複数の企業がバーチャル化された医療経済圏の中で、サブスクリプションシステムを使用することで、複数の企業で消費する備品の発注量を合計した備品の中から選定した物を一定年期間に定額で購入できるサブスクリプション契約を行うために、備品の中から契約するものサブスクＡＩにより自動選択し、契約の候補先へ包括契約の価格見積金額の依頼を行い、回答から有利なサブスクリプション契約を行える契約先を自動で選定し、選定した契約先に自動で発注を行い、契約後の決済を医療機関決済支援システムを用いて自動で行う。

【0017】

医療経済圏を利用する複数の企業がバーチャル化された医療経済圏の中で、複数の企業が経理業務ＤＢにある企業の事業経営上の設備投資額の削減を行う。リカーリングシステムを使用することで、複数の企業が設備投資を行う設備機材の発注量を合計した設備機材の中から選定した物をボリュームプライスで購入できる包括契約を行うために、設備機材の中から契約するもの包括選定ＡＩにより自動選択し、契約の候補先へ包括契約の価格見積金額の依頼を行い、回答から有利な包括契約を行える契約先を自動で選定し、選定した契約先に自動で発注を行い、納品後の決済を医療機関決済支援システムを用いて自動で行う。

【0018】

医療経済圏を利用する複数の企業がバーチャル化された医療経済圏の中で、企業の事業経営上の設備投資額の削減と固定資産税の削減を行う。サブスクリプションシステムを使用することで、複数の企業で経理業務ＤＢに保存されている経営上の設備投資を行う設備機材の発注量を合計した設備機材の中から選定した物を一定年期間において毎年定額で使用できるが企業の資産とならないことから固定資産税を支払う必要が無いサブスクリプション契約を行うために、設備機材の中から契約するものサブスクＡＩにより自動選択し、契約の候補先へ包括契約の価格見積金額の依頼を行い、回答から有利なサブスクリプション契約を行える契約先を自動で選定し、選定した契約先に自動で発注を行い、契約後の決済を医療機関決済支援システムを用いて自動で行う。

【0019】

医療経済圏を利用する複数の企業がバーチャル化された医療経済圏の中で、複数の医療機関及び複数の介護機関の廃棄コストの経費削減をする経営支援を行う。
経理業務ＤＢに保存された廃棄物情報と備品経費情報とを共有し、廃棄回収システムを使用することで、医療機関及び介護機関及び企業事業者が備品として購入した物の中で特別管理産業廃棄物として特別に廃棄する廃棄物の廃棄量を予測し、予測した結果を医療機関及び介護機関及び企業事業者の分を合計したボリューム廃棄量での包括契約を行う契約の候補先へ包括契約の価格見積金額の依頼を行い、回答から有利な包括契約を行える契約先を自動で選定し、廃棄コストの経費削減をする経営支援を行う。

【0020】

診察所要時間ＤＢの情報（データ）を利用し、患者の診察所要時間の予測を行う。
診察時間システムによる予測は、病名情報と病状名情報と診察所要時間情報を用いて機械学習させた結果を診察所要予測時間情報として予測する。
また、担当医師が変わった場合等の診察所要予測時間情報は、前記診察所要時間ＤＢにある病名情報と病状名情報と診察所要時間情報と医師診察所要時間情報を用いて機械学習させた医師ごと医師診察所要予測時間情報として予測する。
予測した時間は、次回の診察所要時間として患者が医療機関で滞在する目安時間として提供するサービスを様々な医療機関で利用できるようにプラットフォーム化したサービスでの提供することで、医療機関内での診察待ち時間を無くす事と、待合室での患者どうしの密を避ける事と、診察予約をした時間どおりに診察を始められるようになるプラットフォーム型医療機関支援システム。

【0021】

医療機関での診察時に次回の診察予約を行う際に、診察時間システム上にある診察所要時間を利用する予約サービスは、診察開始時間から診察終了時間までの所要時間に予測した診察所要予測時間情報を当てはめて患者固有の診察所要時間で予約を行い、診察当日に予約時間通りに診察が始まり診察が終わることで、医療機関内の待合室での待ち時間を減らすことと、待合室で待つ患者どうしの感染防止を行う事が可能となる予約サービスを様々な医療機関で利用できるようにプラットフォーム化したサービスの提供をする。

【0022】

医療機関での診療終了後に次回の診察予約を行う際に、医療機関の予約状況の情報と患者のスケジュール情報を自動的に反映させ、患者の都合に合わせた新しい予約処理のシステムにより予約した日以降に患者からの予約変更を無くすことを目的とした、予約サービスである。患者のスケジュール情報は、外部システムにあるスケジュールシステムにある患者の予定情報と、医療情報共有データベースの医療経済圏ＤＢにある患者の患者予定情報との、２つの患者の情報を利用することで次回診察の予約ができる。患者が予約した日・時の診察開始時間と診察終了時間は患者のスケジュール情報に反映することができる予約システムである。

【0023】

医療情報共有データベースにある予約ＤＢに保存されている予約状況情報を利用して、プラットフォーム型医療機関支援システム上の予約売上算出システムは、予約状況情報から1日分の予約患者が予約時に行った診察の診療報酬点数情報を診療情報ＤＢから取得し、1日分の診療報酬点数を集計し、予約患者1日分の売り上げの状況を把握することができる。

【0024】

医師診察所要予測時間を算出する人口知能を備えた診察時間システムとは別に、記憶させる機械学習作業を、リアルタイムの自己学習による方法で、算出する診察所要時間の制度を上げる処理がリアルタイムで行う。

【0025】

プラットフォーム型医療機関支援システムの電子機器利用システムは、利用者の自宅に設置したスマートスピーカー又は電子機器と接続されている。利用者とスマートスピーカー又は電子機器は、会話をするために作成されたシナリオ（台本）を使用して会話を行うことができる。作成したシナリオ（台本）を使用して行う会話は、病状を知るシナリオにより会話を行い会話の内容から病状に関するキーワードを抽出した会話の情報を利用者音声ＤＢ上の会話病状情報に保存し蓄積する。
また、生活状況を知るシナリオにより会話を行い会話の内容から生活状況に関するキーワードを利用者音声ＤＢに保存し蓄積する。
保存し蓄積した会話病状情報や会話生活情報を利用して利用者の状況または利用者の状態の分析を行う。

【0026】

電子機器利用システムは、利用者と会話し会話病状情報を利用して利用者の病状の変化の分析を行う。
利用者音声ＤＢにある会話病状情報には、利用者の病状に関するキーワードが保存され蓄積している。利用者の病状況または利用者の病状態に関するキーワードの情報が会話病状情報に保存されている。
利用者から病に関する事を導き出す病状会話台本は、台本作成プログラムで作成し、病状状態の答えを聞き出したい会話台本が、会話台本ＤＢに保存される。
電子機器は、電子機器利用システムで作成した病状会話台本を実行し利用者と会話できる。

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

医療情報共有データベースにある医療経済圏ＤＢに保存されている個人情報にある利用者の情報と紐づけされた患者情報ＤＢがある。この患者情報ＤＢには、利用者が所有している複数の金融機関が発行したキャッシュカードに記載された金融機関名と金融機関番号と支店番号・口座番号と口座の情報とが、銀行口座情報として保存されている。
各金融機関が発行するキャッシュカードをATMで利用した時に、銀行口座情報に紐づいているキャッシュカードを発行した金融機関以外の金融機関の口座が紐づいている事から紐ついている全ての金融機関の口座を利用できるようになり、複数所有しているキャッシュカードのうちどれか１枚を利用することで、全ての金融機関の口座が利用できる。

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

医療産業のコストは高額でありこの人工多能性幹細胞の移植手術における患者が負担する費用の削減とシステムの維持運営を目的とし、移植手術当事者である患者と移植手術を行った医療機関と人工臓器作製事業者等による移植手術に成功した様々な情報を匿名加工とNFT（非代替性トークン）とセキュリティを担保した状態で、これから再生医療への参入に検討している医療機関及び人工臓器作製事業者に対して販売する人工多能性幹細胞治療支援システムである。

【0095】

移植手術に関する広告を行いたい、移植手術実績のある医師、移植手術実績のある医療機関、人工臓器の提供実績のある人工臓器作製事業者等は、業績を上げる事を目的とした広告を請負う人工多能性幹細胞治療支援システムである。

【0096】

人工臓器作製事業者や医療機関の業績を上げるため、自社で保有している人工臓器に適合する患者を探しだし移植手術への道を早期に示すせる機能と、
人工臓器作製事業者が在庫として保有している人工臓器のデータと、適合する患者の適合情報を人工臓器作製事業者へ販売し、適合した患者とそのかかりつけ医に対して人工多能性幹細胞治療の勧める通知と、人工臓器ＤＮＡ情報を使い人工臓器作製事業者の人工臓器と患者を結びつける人工多能性幹細胞治療支援システムである。

【0097】

患者が病院に来るのを待っている従来から、患者を探しに行く形態として、当医療機関で手術ができそうな患者をデータベースから探しだす依頼を受ける機能と、
移植候補患者情報から人工多能性幹細胞治療の実施ができる患者をサーチし、その患者とそのかかりつけ医に対して人工多能性幹細胞治療の勧めと、移植手術ができる医療機関とを結びつける機能の人工多能性幹細胞治療支援システムである。

【0098】

人工多能性幹細胞による移植治療を支援するために、医療情報共有データベースの情報を利用し、患者とかかりつけ医療機関と、移植治療を行う医療機関と、事業者と、そして患者への移植治療支援と、移植治療実績のある医師を、人工多能性幹細胞を使用した移植治療の広告方法の利用により人工多能性幹細胞治療支援を目的としたビジネスモデルである。

【0099】

移植候補患者の患者とかかりつけ医に対して、一生涯の治療から人工多能性幹細胞治療へシステムがサーチした、人工臓器の移植手術を行える医師と、人工臓器の移植手術を行える医療機関と、患者の人工臓器を作製する事業者とを提供することと、
患者の診療情報の共有を行える仕組みと、
患者の臓器移植に成功した診療情報の全てを販売提供を行うことと、
これから移植手術を請負いたい医療機関、実績を上げたい臓器作製事業者、実績を上げたい執刀する医師等に対して、患者を紹介するサービスとその報酬と、
移植手術を請負いたい医療機関や臓器作製をしたい事業者からの広告を請負うことの
IPS移植治療のサポートサービスを提供するビジネスモデル。

【0100】

社会のシステム又は社会のサイトから実績ある優秀な人材を探すにはややハードルが高いため、師士業者の業務成果情報から優秀な人材を見つけ、依頼する業務の成果を確実に出す師士業者へ業務を依頼するために、実績ある優秀な人材を探しだすビジネスモデル。

【0101】

師士業従事者の情報を充実することとして、師士業従事者評価ＤＢに社会業務結果情報に情報を付加して、社会業務結果情報から取得する情報により、優秀な師士業者を人材を探し業務依頼ができるビジネスモデルと
実際に業務を依頼した利用者からの業務の達成状況を情報として追加し充実していくことでさらに優秀な埋もれている師士業者を探せるビジネスモデル。

【0102】

自分の病状を治してくれる師士業を探せるために、医療情報共有データベース上の医療経済圏ＤＢにある様々な情報を利用して、利用者の居住地や、利用者の利用目的、病名、治療、専門性、使用した新薬、様々な要素を用いて絞り込んで検索をかけることにより、目的にあった実績があり業務結果が評価されているが水面下に埋もれていた師士業従事者を発掘することができることを特徴とし、実績ある優秀な人材を探し業務依頼を行う師士業従事者システムを利用したビジネスモデル。

【0103】

利用者と師士業従事者の双方の師士業従事システムの利用価値と利用者の拡大を高めるために師士業従事者システムをスケールアップするために、実績ある優秀な人材を探し業務依頼を行った結果を利用者から取得しデータベースに登録し師士業従事者システムに反映することで、利用者による利用者成果の情報が付加された事で幅広い師士業者の実績ある優秀な人材を探し業務依頼を行える師士業従事者システムを利用したビジネスモデル。

【0104】

システムの内製化を進める上で必要な、資金調達に関する様々な情報と、契約に関する様々な情報と、ライセンスや権利に関する様々な情報を持った開発プロセスＤＢと開発プロセスシステムにより内製化を行い、ライセンスや権利を管理するライセンス管理機能を持った開発プロセスシステム。

【0105】

ネットワーク上に設置するシステムを内製化するために利用する開発プロセスＤＢにある、資金を分類した資金分類情報と、内製化するシステムを利用する利用者情報と、資金調達に関する資金調達情報と、資金の調達先を分類した資金調達方法情報と、資金の調達を行う手段を分類した広告情報等を利用して内製化を支援する開発プロセスシステム。

【0106】

開発プロセスＤＢにある、これから内製するプログラムの概要情報や説明情報などの情報を資金調達を行うための説明資料とし、開発プロセスシステムは、調達する資金の選定し、調達する資金の調達先を決め、調達先にどのような方法で調達を行うか調達方法を決め、説明資料を添付して調達を開始する開発プロセスシステム。

【0107】

調達を開始した調達先からの回答の内容が、資金分類毎や資金調達先毎に調達する資金の調達状況が可視化される開発プロセスシステム。

【0108】

内製化したシステムのライセンスや権利に関する情報を管理し、内製化したシステムの所有権財産権を所有している団体は、複製による販売または提供もライセンス管理システムにより管理ができることと、内製化したシステムをプラットフォーム化したシステムで運用することで、利用希望する利用者や団体に対して使用権のみをライセンス管理システムが管理しシステムを利用できる権利を与えられるライセンス管理システムと開発プロセスシステム。

【0109】

医師や看護師や介護士や医療機関で働く事務職や医療に従事する企業、医療関係の研究者の、ひらめきとして頭の中にあるアイデアの概要をデジタル化して権利侵害や前記考案概要情報の考案者と開発事業社の権利保護と無断複製の権利侵害から保護し管理する
開発プロセスシステム。

【0110】

医師や看護師や介護士が従事する仕事で使える医療機器や製薬や介護機器やプログラムなどの様々なひらめきとして頭の中にあるアイデアの概要をデジタル化し、NFT管理により医師会と、医療介護機関と、企業名と、金融機関名と、一般投資家に対して製品化するための資金調達と製品化する企業を探す機能と、製品化するために開発事業社や製造業者や製薬会社などをＮＦＴにより権利の管理を行う機能とを有しているライセンス管理システムと開発プロセスシステム。

【0111】

資金調達した資金及び投資家による投資した資金は、円通貨だけに拘らず汎用決済システムを利用することで暗号通貨やデジタル通貨や、医療用決済口座利用した医療決済システムを利用して行われる開発プロセスシステム。

【発明の効果】

【0112】

本発明によると、プラットフォーム型医療機関支援システム１を用いることにより、医療機関４は、従来から受診している急性期の患者や慢性疾患患者だけでなく、健康を維持したい利用者や普段は病院へ行かない程度の病気となっている患者も医療機関を受診するようになる。

【図面の簡単な説明】

【0113】

【図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】決済端末を設置した住所位置情報データベースのシステム図である。

【図28】信託契約利用のシステム図である。

【図29】遺言の作成の例を示す図である。

【図30】第５実施形態で使用しているデータベース内の情報の構成図である。

【図31】患者の生体情報を使用した受付により旧医療医療情報システムと本考案医療情報システムが併用して使えるイメージ図である。

【図32】１枚の診察券を共有し医療機関で利用するシステム図である。

【図33】１枚のキャシュカードで銀行口座を共有するシステム図である。

【図34】第６実施形態で使用しているデータベース内の情報の構成図である。

【図35】２４時間診療病院へのイメージ図である。

【図36】多診療科病院へのイメージ図である。

【図37】２４時間病院での個人事業医師から診療報酬を請求するイメージ図である。

【図38】多診療科病院での個人事業医師からそれぞれ診療報酬を請求するイメージ図である。

【図39】同一病院として診療報酬を一括請求し、分配受領するイメージ図である。

【図40】第７実施形態で使用しているデータベース内の情報の構成図である。

【図41】処方薬をサブスクリプション契約するイメージ図である。

【図42】病状と必要な介添人などの例を示す図である。

【図43】第８実施形態で使用しているデータベース内の情報の構成図である。

【図44】予約システムと運行管理システムと各事業者との連携フロー図である。

【図45】各社の予約システムから情報を入手する場合のフロー図である。

【図46】共有予約システムを利用した場合のフロー図である。

【図47】労務借り上げ時間の算出方法の概略図である。

【図48】公共交通機関などを利用した場合のイメージを図である。

【図49】第９実施形態で使用しているデータベース内の情報の構成図である。

【図50】人工臓器作製事業者が保有している培養臓器の適合患者を探すシステム図である。

【図51】データべースの形式を説明する図である。

【図52】第１０実施形態で使用しているデータベース内の情報の構成図である。

【図53】師士業従事者（弁理士）の成果情報の検索のイメージ図である。

【図54】師士業従事者（弁理士）へ業務依頼した成果実績の検索イメージ図である。

【図55】医療従事者の成果情報の検索のイメージ図である。

【図56】医療従事者へ業務依頼した成果実績の検索イメージ図である。

【図57】第１１実施形態で使用しているデータベース内の情報の構成図である。

【図58】パッケージ製品と内製化品との権利の違いを示す図である。

【図59】内製化システムを開発に必要な資金フロー図である。

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

【0114】

次に、本発明を実施するための１１の形態を、図面を参照して具体的に説明する。説明において同様の要素には同一の符号を付して、重複する説明を適宜省略する。

【0115】

＜第１実施形態＞
病院４ａをはじめとる医療機関４内には、診察予約管理システム６２や受付システム９ｆ、会計システムといった事務に関係する情報システムと給与システムや経費管理システム、在庫管理システム、個人情報管理システム、税務管理システムなど病院経営に特化した情報システムと電子カルテ９ａや検査オーダーシステムなどの診療に特化した医療情報システム９とが存在している。医療機関４内にある各種情報システムや医療情報システム９は、医療機関４内ではそれぞれのシステム同士が連携して動いている場合が多い。しかし、地域医療連携システムなど医療機関４同士で連携しているシステムは少ない。医療機関４同士で連携しているとしても、同一企業や同一グループ内の医療機関４同士など限られた範囲内で収まっていた。特に、個人経営の医療機関４との連携はできていない。
すでにそれぞれの地域で運用が行われている地域医療連携システムにおいても問題がある。しかし、医療機関はそれに気が付かずに運用を行っている。地域医療連携システムの問題は、資金を提供する側、資金を受け取る側、利用する側の３つに分かれており、いくら資金を提供してもその資金は受け取る側すなわちＩＴメーカーが全て持っていくという構造となっている。資金を提供する側（自治体や政府）もいつかは資金提供が停止又は枯渇していくことは分かっているが、地域医療連携の運用を行っている。医師達は資金の枯渇が始まって悩み中止となる地域も出てきている。
この運用における資金の問題を解決するには、しっかりとしたビジネスモデルを企画段階から持続化する立案をすることが一番重要であり、立ち上げに資金を提供していた自治体や政府の助けは数年で断てるという計画とが必要となる。本開示は、自律化した地域医療のビジネスモデルにより医療経営の持続化が行える考案である。

【0116】

しかしながら社会ではデジタルトランスフォーメーション（DX）といった概念による事業構造の変革が動き始めている。
従来、医療従事者５が利用する電子カルテ９ａを主体にしたネットワーク上のサービスは複数存在し利用されている。これではＤＸといった事業構造の変革はできない。
個人経営の医療機関４が医療版ＤＸを導入するには様々な負担により事業構造の変革は遠いものである。
グループの垣根を越えて、各種情報システムが連携するには、医療機関４を運営している企業やそのグループに縛られることはない、第三者が医療機関４に関係する情報システムを運営しプラットフォームサービスとして医療機関４に経営と事業構造とを主体とした医療経営サービスを提供することにより実現できる。
別の側面で考えると、それぞれの医療機関４で使用している上記のシステムは、メーカーの違いで事業収益の具合が変わる物なのでしょうか？システムの違いで事業収益に影響が出るものではないでしょう。これは、医療業界に限らず他業種でも使用しているシステムも同様で人事システムや給与システムの違いで競合会社と事業収益の差が出るというものではないのと同じである。どこの医療機関４でも同じものを使用しても体制の影響や事業収益上の差は出ないと言ってよい。金融業界（銀行）においても、銀行間の共創により行内システムを開発して相互に利用し、個別に所有することで発生していた、開発費・維持費・メンテナンス費・リプレース費等のコストを銀行グループ枠を超えて同業種一丸となって行う取り組みは数年前から実施されている。医療業界も同じではないでしょうか。
医療業界で使用するシステムを共有利用できる基盤システムとして一括開発し、それをプラットフォームサービス化することで医療機関４はそれを利用できるようになる。小さな医療機関４やクリニック４ｅなど開院コストの大幅な削減にもなり、経営に圧迫を与えたCＯＶＩＤ−１９下では医療機関４から外に出ていく費用の削減となり医療経営の圧迫から少しは解放できる事に繋がると考えている。
この医療経営における目に見えないＩＴコストの問題を解決するには、医療機関同士が連携し、「共同システムとしての利用又は、業界標準システムの利用」という従来の考え方から脱却した考え方によるビジネスモデルに移行し、新たな収益が生まれるシステムにより医療機関から外へ出ていく資金（コスト）を無くすことができる本開示は、自律化した地域医療のビジネスモデルにより医療経営の持続化と新しく患者へのサービスが行える考案である。

【0117】

前記プラットフォームサービスは、プラットフォーム型医療機関支援システム１（医療機関支援システム１）として利用者３に提供され、システムの中核を担うデータベースとして、大きな１つのデータベースである医療情報共有データベース２がある。
この医療情報共有データベース２には、複数の医療機関４で利用する電子カルテ９ａ内にある診療情報と紐づいた情報が保存された様々なデータベースがあり、前記様々なデータベース内にある情報を患者や、医療機関４や、介護機関や、事業者や、他業種等でシェアして利用するができる。医療情報共有データベース２上にあるデータベースとしては、医療経済圏ＤＢ２１、経理業務ＤＢ３１、診察所要時間ＤＢ５１、利用者音声ＤＢ７１、決済関係ＤＢ１０１、師士業従事者評価ＤＢ２４１、地域処方ＤＢ１９１、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１、開発プロセスＤＢ２６１、リカーリングＤＢ４１などがある。各データベースの説明は、本実施形態並びに第２実施形態以降の各実施形態にて適宜説明する。プラットフォーム型医療機関支援システムの構成を図１に示し、医療情報共有データベース２の構成を図２に示す。また、第１実施形態のデータベース構成を図３に示す。

【0118】

まず、医療情報共有データベース２にある様々なデータベースに共通する事項について説明する。医療情報共有データベース２にある様々なデータベースは、医療機関４にある医療情報システム９内にある情報の一部に紐づけた情報、または、プラットフォーム型医療機関支援システム１の電子カルテ９ａで扱う医療経済圏ＤＢ２１にある情報の一部紐づけた情報に加えて、様々な新しい情報を追加することにより構成させたものとなっている。
医療経済圏ＤＢ２１とは、医療経済圏２４を利用する人の個人情報２２や医療経済圏２４を利用する企業の事業情報が含まれたデータベースとなっている。医療経済圏ＤＢ２１の詳細については後述する。

【0119】

本考案は、医療情報共有データベース２ある様々なデータベースに蓄積保存された情報を利用することにより、医療機関４が収益を得て、医療機関４の経営改善による事業の持続化とシステムの持続化を可能とするビジネスモデルを作ることを目的としている。
第１実施形態では、このビジネスモデルを作るうえで必要な、情報共有の仕組みを説明する。第２実施形態以降では、共有した情報を利用することにより行えるビジネスモデルについて説明する。

【0120】

前述した、医療経済圏ＤＢ２１は、医療経済圏２４を利用する人の個人情報２２や医療経済圏２４を利用する企業の事業情報が含まれると説明した。ここで言う医療経済圏２４を利用する人とは、患者、働く生産労働者、介護施設６の入所者、医療機関４で働く人、年金受給者、医療保険受給者対象者など医療経済圏２４内のサービスを利用している人や、医療経済圏２４内のサービスの提供に関わっている人のことを示す。また、医療経済圏２４を利用する企業とは、医療機関４、介護機関、製薬会社、医療会社、事業者、他業種の様々な企業や団体のうち、医療経済圏２４内の事業に関わっている法人及び個人事業主、地方公共団体などのことを示す。
医療経済圏ＤＢ２１に保存される個人情報２２としては、患者、働く生産労働者、介護施設６の入所者、医療機関４で働く人、年金受給者、医療保険受給者対象者などがある。
医療経済圏ＤＢ２１に保存される企業情報２３としては、医療経済圏２４を利用する医療機関４、介護機関、製薬会社、医療会社、事業者、他業種の様々な企業などの事業情報などがある。医療経済圏の構成の概略図を図４に示し、医療経済圏の例を図５に示す。
ここまで、説明なしに医療経済圏２４という言葉を利用してきた。医療経済圏２４とは、地域で区切った一般的な経済圏とは違い、第４実施形態で説明する医療機関決済支援システム１０２を利用している人や企業、地域などにより構成された経済圏であり、ネットワーク上にある仮想的な（バーチャルな）経済圏となっている。
また、医療経済圏ＤＢ２１には、利用者３の個人情報２２に紐づけた形で、利用者個人を識別するための情報も保存されている。この利用者個人を識別するための情報は、利用者３の顔や指紋、声紋といった生体認証を行うための情報や利用者３の所有する機器を用いていた認証を行うための情報で構成されている。

【0121】

次に経理業務ＤＢ３１について説明する。経理業務ＤＢ３１には、医療経済圏２４を利用する企業がバーチャルな環境で事業実施する過程で、プラットフォーム型医療機関支援システム１にあるシステムを利用することにより発生した様々な情報が蓄積保存されている。蓄積保存される情報は、医療経済圏２４を利用する企業の経理や経費や勤怠や給与や備品や設備投資や設備機材や廃棄費等などとなっている。

【0122】

医療情報共有データベース２は、少なくとも医療経済圏ＤＢ２１と経理業務ＤＢ３１とにそれぞれ保存された情報と、医療経済圏ＤＢ２１と経理業務ＤＢ３１とに保存されている情報に紐づいた、複数のデータベースとで構成され、プラットフォーム型医療機関支援システム１を構成する要素の１つとなっている。
また、医療情報共有データベース２にある様々なシステムと、前記システムで利用することでるデータベースに保存されている様々な情報とを利用することにより、医療経済圏２４を利用する企業の経営支援を行うこともできる。

【0123】

前記プラットフォームサービス上では、診療を行う上で各医療機関４が必ず所有している医療情報システム９をネットワーク上の電子カルテシステム９ａ、レセプトコンピュータシステム９ｂと、さらに決済を行う決済システム９ｃをも連携した状態でのシステムに各医療機関４から共有利用できる。
プラットフォームサービス上では、次の４つの情報を基本として、それぞれのシステムで取り扱われる。中核となる基本情報として「患者の個人情報２２」があり、患者の診療内容を扱う情報として「患者の診療情報履歴」がある。この「患者の診療情報履歴」から、診察内容を自動で採取して「保険機関へ請求するレセプト情報」と「患者への診療費請求情報」を算出する。そして「患者への診療費請求情報」を元に患者が決済を行う「患者決済情報」が取り扱われる。
これらの情報は、プラットフォームサービス上の各システムで扱われる。「患者の診療情報履歴」は、電子カルテシステム９ａで扱われ、この情報がマスターとして扱われる。電子カルテシステム９ａと連携するレセプトコンピュータシステム９ｂでは、電子カルテシステム９ａにある「患者の診療情報履歴」から医師５ａが登録した受診日の診察内容が列記された物又は診察した点数情報を取得し、「保険機関へ請求するための点数情報（レセプト情報）」と「患者への診療費請求情報」の２つを算出し保存される。電子カルテシステム９ａ（電子カルテ９ａ）及びレセプトコンピュータシステム９ｂと連携している決済システム９ｃでは、レセプトコンピュータシステム９ｂで算出された「患者への診療費請求情報」を元に、診察費の決済処理が行われると、「患者決済情報」が保存される。これら４つの情報（データ）は、プラットフォームシステム上の３つのシステムで、それぞれが必要な情報を相互に連携し処理をすることができる。また、プラットフォームサービス上にあるここでは説明していない様々なシステムとも連携されており、ここで説明した情報が相互に利用される。
このシステム連携によるプロセスは、従来の医療機関４内で使用されているシステムと結果的には変わらない。しかし、持続利用費、リプレース費などを比べると比にならないものである。従来の医療機関４内で行われている「電子カルテ９ａに医師５ａが記載した情報が、自動的にレセプトコンピュータに取り込まれ診療点数が計算される。」「レセプトコンピュータで計算した診療点数から患者が支払う金額を計算される。」ものと、なんら変わりなく、同じ処理がプラットフォーム上で行われているものである。
プラットフォームサービス上で扱われるそれぞれの情報は、利用する病院単位で扱われるが、各データは作成元の医療機関４のソースデータとして扱われ、ソースデータはその情報を作成した医療機関４以外では一切の閲覧や利用をすることはできない通常のクラウドシステムのようにデータは取り扱われる。各システムは共有であるが、データは共有されない。但し、ＤＸという扱いから患者情報の共有には患者自身の許可により共有は可能となる。プラットフォームサービス上での共有は可能である。

【0124】

医療機関４には、上記の医療情報システム９以外に医療機関４の経営に使用する各種経営システムがある。前記プラットフォームサービスには、前記各種経営システムと同等な医療機関経営支援システム１０ａや医療機関事業支援システム１０ｂなどから構成される医療機関経営事業支援システム１０がある。この医療機関経営事業支援システム１０（経営支援システム）は、経営上発生する、経理情報・経費情報・勤怠情報・給与情報等の経営上の様々な情報をプラットフォームサービスで扱えるシステムである。これら情報は様々な事業分析を行うデータウェアハウス（DWH）により行うことができる。
それぞれの情報は、利用する病院単位で扱われるが、各情報は作成元の医療機関４のソースデータとして扱われ、そのソースデータはその情報を作成した医療機関４以外では一切の閲覧や利用をすることはできない通常のクラウドシステムのようにデータは取り扱われる。各システムは共有であるが、データは共有されない。
この医療機関経営事業支援システム１０は、電子カルテ９ａとレセプトコンピュータシステム９ｂと医事向けの決済システム９ｃとも連携が行える。
医療機関経営支援システム１０ａでは、院内の経理における出入金管理や医療従事者５の給与管理などをキャッシュレスで行うための機能や、医療従事者５の労務管理機能などが含まれている。
ここで言う医療従事者５とは、医師５ａや歯科医師５ｄ，コメディカル５ｊだけでなく、医療クラークや医療事務などを含む医療機関４に勤務している人のことを示す。
医療機関事業支援システム１０ｂには、患者の診療予約管理や医療用部材の発注及び在庫管理、医薬品の発注及び在庫管理などの機能が含まれている。医療用部材の発注及び在庫管理システムの一例として、本出願人の特許第６６２０３０２号に開示の技術などがある。
前記プラットフォームサービスは、事務に関係する情報システムと診療に特化した医療情報システム９と病院経営に特化した情報システムが含まれており、医療機関４における支払いのキャッシュレス化を目的とするシステム（医療機関決済支援シスムテム）も含まれている。このプラットフォームサービスは、プラットフォーム型医療機関支援システム１として、複数の医療機関４からアクセス可能な、ネットワーク上のシステムであるため、複数の医療機関４において１つのシステムを共有して利用することができる。
診療に特化した医療システムと経営に特化したシステムとを連携させることにより、医療機関４で行う必要がある事務作業のうち受付からレセプト請求，税申告までのすべてをカバーできることになり、医療事務が省人化され、経営の収支を改善させることができる。
今までレセプト請求などの定型化された事務処理は、医療機関４ごとにシステムの調達を行ってきた。本開示の医療機関支援システム１を利用することにより定型化された事務処理をプラットフォーム上で行うことができ、さらに、調達やシステムの維持継続のコストも削減が行え、複数の医療機関４の処理を１か所でまとめて行うこともできる。また、本プラットフォームサービスには、自動決済機能が含まれているので、病院４ａの受付で現金を扱わないようにすることもできる。その結果、医療機関４の受付や事務に割いていた人員の効率化や削減（省人化）ができ、医療事務の働き方改革や人件費・固定費のコスト削減により、病院４ａの経営改善につながる。
前記プラットフォームサービス上では、電子カルテ９ａとレセプトコンピュータシステム９ｂと医事向けの決済システム９ｃとが相互に連携して動いている。
この連携は、「電子カルテ９ａに記載されたものが、自動的にレセプトコンピュータに取り込まれ診療点数が計算される。」「レセプトコンピュータで計算した診療点数から患者が支払う金額を計算される。」などがある。
また、前記プラットフォームサービスには、医療機関経営支援システム１０ａや医療機関事業支援システム１０ｂなどから構成される医療機関経営事業支援システム１０がある。この医療機関経営事業支援システム１０は、電子カルテ９ａとレセプトコンピュータシステム９ｂと医事向けの決済システム９ｃとも連携が行える。
医療機関経営支援システム１０ａでは、院内の経理における出入金管理や医療従事者５の給与管理などをキャッシュレスで行うための機能や、医療従事者５の労務管理機能などが含まれている。ここで言う医療従事者５とは、医師５ａや歯科医師５ｄ，コメディカル５ｊだけでなく、医療クラークや医療事務などを含む医療機関４に勤務している人のことを示す。
医療機関事業支援システム１０ｂには、患者の診療予約管理や医療用部材の発注及び在庫管理、医薬品の発注及び在庫管理などの機能が含まれている。医療用部材の発注及び在庫管理システムの一例として、本出願人の特許第６６２０３０２号に開示の技術などがある。
前記プラットフォームサービスは、事務に関係する情報システムと診療に特化した医療情報システム９と院経営に特化した情報システムが含まれており、医療機関４における支払いのキャッシュレス化を目的とするシステム（医療機関決済支援システム１０２）も含まれている。このプラットフォームサービスは、プラットフォーム型医療機関支援システム１として、複数の医療機関４からアクセス可能な、ネットワーク上のシステムであるため、複数の医療機関４において１つのシステムを共有して利用することができる。
診療に特化した医療システムと経営に特化したシステムとを連携させることにより、医療機関４で行う必要がある事務作業のうち受付からレセプト請求，税申告までのすべてをカバーできることになり、医療事務が省人化され、経営の収支を改善させることができる。
今までレセプト請求などの定型化された事務処理は、医療機関４ごとにシステムを調達し行ってきた。本開示の医療機関支援システム１を利用することにより定型化された事務処理をプラットフォーム上で行うことができ、さらに、調達やシステムの維持継続のコストも削減が行え、複数の医療機関４の処理を１か所でまとめて行うこともできる。また、本プラットフォームサービスには、自動決済機能が含まれているので、病院４ａの受付で現金を扱わないようにすることもできる。その結果、医療機関４の受付や事務に割いていた人員の効率化や削減（省人化）ができ、医療事務の働き方改革や人件費・固定費のコスト削減により、病院４ａの経営改善につながる。

【0125】

本開示のプラットフォーム型医療機関支援システム１には、医療機関４がもつ医療機関経営事業支援システム１０から医療機関４内で使用している包帯やマスクなどの医療品をはじめとする備品の消費量や在庫量を取得する機能を有している。医療機関４内で使用している医療品の消費量や在庫量を取得する方法としては、出願人考案の特開２０２０−１１３１４３に開示の共通在庫ＤＢを利用した方法などがある。
本開示のシステムは、取得した前記消費量や前記在庫量が予め設定された閾値に到達したと検知した場合、検知した備品について、予め設定してある契約先に対して当該備品の発注を自動で行うことができる。

【0126】

前記では、医療機関４内で使用している備品の消費量や在庫量としたが、地域内の医療機関４など複数の医療機関４の合計の消費量や在庫量を取得してもよい。
複数の医療機関４の合計消費量や合計在庫量を取得した場合は、複数の医療機関４で合計した在庫量や消費量に対し閾値を設定してもよく、複数の医療機関４での合計が閾値に到達した場合、複数の医療機関４で包括して備品の発注を行えるようにしてもよい。複数の医療機関４で包括して発注する場合においても、予め設定してある契約先に対して自動で発注を行うことができる。

【0127】

備品の自動発注を行うために設定する備品の消費量や在庫量の閾値は、発注してから医療機関４に到着するまでの期間を考慮して設定する。すなわち、医療機関４において備品の在庫が枯渇する時期の算出し、在庫が枯渇しないように発注を行う。
備品の在庫が枯渇する時期の算出は、備品を使用することよる消費量の増加傾向や在庫量の減少傾向を利用して行う。在庫量の減少傾向を利用した枯渇時期の算出例を図６に示す。図６では、備品Aは、消費が激しくこのままだと３月１２日頃に在庫がなくなり、備品Bは５月２１日頃に在庫がなくなるとの予測となっている。
また、備品メーカーや卸売り業者の倉庫の在庫状況や備品メーカーの生産状況、分納の可否情報などを取得し、閾値に反映してもよい。
たとえば、備品メーカーや卸売り業者の倉庫の在庫状況が潤沢で、発注から数日で注文した備品が到着する場合は、消費量の閾値を大きく（在庫量の閾値を小さく）する。一方、備品の在庫が少ないなど、生産されるのを待つ必要がある場合は、消費量の閾値を小さく（在庫量の閾値を大きく）する。分納により注文した備品を受け取れる場合、分納予定に合わせて閾値を調整する。
これは、出願人考案の特開２０２０−１１３１４３に開示した方法とは明確に違っており、閾値が設定した固定値であったものが、状況に合わせた可変の閾値となっている。
図６で用いた備品Ａを用いて閾値設定の例を示す。今日が２月１日と仮定し、備品Ａは、注文から納品まで２週間かかると仮定する。備品Ａは４週間で約４００個使用しており納期を鑑みると、遅くとも在庫が枯渇する２週間前（２月２６日頃）には、発注する必要がある。２週間前だと在庫が約２００個とぎりぎりのため、在庫が枯渇しないようにするための閾値は、あと２００個消費（在庫量が約４００個）と設定した。

【0128】

上記説明では、本開示のシステムが、備品の消費量や在庫量の閾値に到達したと判断した場合に発注を行う発注先は、予め設定するとしていた。しかし、予め指定した発注先への発注ではなく、本開示システムが発注先を自動選定し発注してもよい。
発注先の選定は、いくつかある発注先の候補に対して、希望購入量を提示のうえ見積もり依頼を行う処理をする。見積もりの依頼の結果、発注先の候補から返答があった業者の中から一番有利な条件を提示した業者を発注先とする。一番有利な条件を提示した業者とは、通常は、見積額が一番安価な業者のことを示す。しかし、事情により価格が多少高くても優先すべき事項「例えば、医療機関４の在庫量が少ないため、即時納品が必要」がある場合、即時納品ができる業者が一番有利な条件を提示した業者となる。
備品の希望購入量は、納品時期における、在庫量と基準在庫との差分量を基本とするが、これに限らない。
発注先の候補は、予め指定している業者の他、一定条件を満たす企業「例えば、第４実施形態に記載の医療用決済口座を開設している業者」でもよい。
発注先が医療用決済口座を開設している業者の場合、発注した備品に対する決済は、医療用決済口座を利用した決済システム９ｃを用いてもよい。

【0129】

備品によっては、日常的に使用するものもある。日常的に使用するものは、消費量もおのずと多くなり、定期的に購入していることも多い。
購入量が多い備品は、購入量に関わらず定額で契約期間中購入できるサブスクリプションで購入できるようにしてもよい。
本開示のシステムは、サブスクリプション購入先の事業者を自動で選定する機能を有している。この機能は、備品の消費量や在庫量をもとに、サブスクリプション契約先の候補業者にサブスクリプションでの契約の見積もりを依頼し、見積もりを集める。集まった見積もりの中から契約期間や契約価格の観点から一番条件がいいものを選び、サブスクリプション契約先をして選定する。
本開示のシステムは、消費量の増加傾向や在庫量の減少傾向から、在庫枯渇時期が予測できるので、在庫を切らさないように、適宜サブスクリプション契約先に発注を行う。

【0130】

医療経済圏２４を利用する医療機関４において、一定地域内に所在している複数の医療機関４で備品の発注を包括契約で行い備品を購入するリカーリングシステム４２について記載する。
包括契約での備品の購入は、プラットフォーム型医療機関支援システム１のリカーリングシステム４２を用いて行う。このシステムを利用して契約の受注を行う事業社は医療経済圏ＤＢ２１の企業の事業情報に登録されている医療機関４と備品の販売事業者である。
医療経済圏２４を利用する医療機関４が使用している備品の種類や備品の消費量又は払い出された量の情報は、経理業務ＤＢ３１に備品経費情報として保存されている。
この地域の複数の医療機関４の使用量を合計した地域全体の使用量が、ボリューム発注量となって、従来購入価格より安く購入できる価格での契約を行うことになる。
さらに包括契約に適する備品と購入先企業（包括契約先企業）を選定する必要がある。この選定する処理方法に、包括選定ＡＩという人口知能（ＡＩ）を利用することで煩わしい選定の自動化が図れる。
包括選定ＡＩのプログラムは、ボリュームディスカウウントでの購入ができそうな備品、過去に購入実績のある備品及び発注量、過去に包括契約実績のある備品等から対象となる備品を選定し、包括契約によるボリュームディスカウウント価格を受けてくれそうな企業又は、過去に契約実績のある企業を包括契約先候補企業として選定をする処理を行う。
候補選定する対象の企業は、医療経済圏ＤＢ２１にある企業の事業情報に備品の発注先企業として登録されている企業（卸会社や生産メーカーなど）である。
選定するために必要な情報として、備品の最少発注量の目安の情報、発注する備品名の情報、備品の発注量の情報、包括契約先候補企業の情報、納期の情報が、医療経済圏ＤＢ２１にあるリカーリングＤＢ４１の包括情報として保存処理される。
複数の医療機関４で包括した備品において一部の備品の発注量が、備品の最少発注量の目安までに足りなかった場合は、医療機関４の数を増やして発注量を調整するか、その備品だけ包括する品目から削除するかのいずれかを選択する処理を行う機能も有している。
包括契約価格を決めるため、リカーリングシステム４２は、包括情報に保存されている包括契約先候補企業に対して、包括契約の価格見積依頼を行う通知を送る処理を行う。この通知には、包括情報に保存されている発注する備品名の情報、備品の発注量の情報等の包括契約に必要な様々な情報が記載されている。この通知に対する回答を包括契約先候補企業から受信した包括回答情報はリカーリングＤＢ４１に保存する処理が行われる。

【0131】

包括契約の見積依頼を受け取った包括契約先候補企業は、従来のような形で見積書を作成すればよいという訳ではない。包括契約とは、ある意味契約備品の独占契約を行うもので、その契約数量は地域で包括した地域で発注する総数量となっている。この契約を死守できないと契約期間中の地域からの受注は「ゼロ」となるのはわかりきっているため、競合他社との談合等が成り立たない仕組みとなっている。地域の発注する総数量は大口な数量のため営業部門の契約というよりも企業が契約するという形になるため、企業トップクラス同士の談合は成り立たないし、見積者の契約金額だけを機械処理して選定するものでは無い。包括契約先候補企業は、契約を得るために契約内容にも力を注いだものとなるのが普通である。

【0132】

包括契約の締結は、リカーリングシステム４２による電子契約で行われる。
リカーリングシステム４２は、リカーリングＤＢ４１上の包括回答情報から包括契約を行うに有利な企業を自動選定し、その選定した企業を契約先としたデジタル契約書を自動で作成し、契約先企業とリカーリングシステム４２の双方がデジタル署名により締結の処理を行う。
リカーリングシステム４２によるデジタル契約書を自動作成する処理は、契約書テンプレートを利用し、契約書作成に必要な情報は、包括回答情報に保存されている回答企業名、備品名、備品の数量、契約金額等の情報、支払条件を取得し契約書テンプレートにインプットする処理によりデジタル契約書が作成される。
締結完了とともに備品の発注を自動で処理を行う機能を有している。この契約に関わる契約先企業や契約金額等や契約年月日や契約に必要な様々な情報も包括情報として保存する処理が行われる。
すなわち、包括契約に関わる様々な詳細情報が、リカーリングＤＢ４１に包括情報として保存されている。包括契約のイメージを図７に示す。

【0133】

包括選定ＡＩについて説明する。
包括選定ＡＩは、機械学習の手法を用いて、ボリュームディスカウウントでの購入ができそうな備品と包括契約先候補企業とを選定する人工知能である。
これらの選定は、備品経費情報として保存された情報や包括情報として保存された情報を利用して教師なし学習のうちアソシエーション分析の手法を用いて行う。

【0134】

医療経済圏２４を利用する医療機関４において、一定地域内に所在している複数の医療機関４で備品の発注をサブスクリプション契約により備品を購入する、サブスクリプション契約について記載する。
サブスクリプション契約での備品の購入は、プラットフォーム型医療機関支援システム１のサブスクリプションシステム４３を用いて行う。このサブスクリプションシステム４３を利用して契約の受注を行う事業社は医療経済圏ＤＢ２１の企業の事業情報に登録されている医療機関４と備品の販売事業者である。
医療経済圏２４を利用する医療機関４が使用している備品の種類や備品の消費量又は払い出された量の情報は、経理業務ＤＢ３１に備品経費情報として保存されている。
この地域の複数の医療機関４の使用量を合計した地域全体の使用量が、一定年期間は通常の購入価格よりディスカウウントされた定額で購入できる契約を行うことになる。
さらにサブスクリプション契約に適する備品と購入先企業（包括契約先企業）を選定する必要がある。この選定する処理方法に、サブスク選定ＡＩという人口知能（ＡＩ）を利用することで煩わしい選定の自動化が図れる。
サブスクＡＩのプログラムは、一定年期間のボリュームディスカウウントでの購入ができそうな備品、過去に購入実績のある備品、発注する量、通常価格、過去にサブスクリプション契約の実績のある備品、等からから備品を選定し、選定した備品をサブスクリプション契約でボリュームディスカウウント価格を受けてくれそうな企業又は、過去に契約実績のある企業をサブスク契約先候補企業として選定をする処理を行う。
候補選定する対象の企業は、医療経済圏ＤＢ２１にある企業の事業情報に備品の発注先企業として登録されている企業（卸会社や生産メーカーなど）である。
選定するために必要な情報として、備品の最少発注量の目安の情報、発注する備品名の情報、備品の発注量の情報、包括契約先候補企業の情報、契約期間の情報、契約執行日の情報が、医療経済圏ＤＢ２１にあるリカーリングＤＢ４１のサブスク情報として保存の処理が行われる。
複数の医療機関４でまとめた備品において一部の備品の発注量が、備品の最少発注量の目安量までに足りなかった場合は、医療機関４の数を増やして発注量を調整するか、その備品だけ包括する品目から削除するかのいずれかを選択する処理を行う機能も有している。
サブスクリプション契約の価格を決めるため、リカーリングシステム４２は、サブスク情報に保存されているサブスクリプション契約先候補企業に対して、サブスクリプション契約の価格見積依頼を行う通知を送る処理を行う。この通知には、サブスク情報に保存されている発注する備品名の情報、備品の発注量の情報等のサブスクリプション契約に必要な様々な情報が記載されている。この通知に対する回答をサブスクリプション契約先候補企業から受信したサブスク回答情報はリカーリングＤＢ４１に保存する処理が行われる。

【0135】

サブスクリプション契約の見積依頼を受け取ったサブスクリプション契約先候補企業は、従来のような形で見積書を作成すればよいという訳ではない。サブスクリプション契約とは、ある意味一定年期間（１年〜５年）における長期に渡る備品提供の独占契約を行うものである。サブスクリプション契約先候補企業は、この契約を勝ち取るためのプライスを提供しなければならない課題がある。契約がとれなければ、長い年月に渡りこの地域からの受注は「ゼロ」となるのはわかりきっているために、企業は自社製品の優位性をアピールするため契約者（医療機関４）にとっても価格以外にメリットのある様々なアイデアを入れた契約内容に力を注ぐ形で契約を勝ち取ろうとする。サブスクリプション契約は、いわば企業側のアイデアの結集ともいえる契約体系となっている。

【0136】

サブスクリプション契約の締結は、リカーリングシステム４２による電子契約で行われる。
リカーリングシステム４２は、リカーリングＤＢ４１上のサブスク回答情報からサブスクリプション契約を行うに有利な企業を自動選定し、その選定した企業を契約先としたデジタル契約書を自動で作成し、契約先企業とリカーリングシステム４２の双方がデジタル署名により締結の処理を行う。
リカーリングシステム４２によるデジタル契約書を自動作成する処理は、契約書テンプレートを利用し、契約書作成に必要な情報は、包括回答情報に保存されている回答企業名、備品名、備品の数量、契約金額等の情報、支払条件を取得し契約書テンプレートにインプットする処理によりデジタル契約書の作成処理がされる。

締結完了とともに備品の発注を自動で処理を行う機能を有している。この契約に関わる契約先企業や契約金額等や契約年月日や契約に必要な様々な情報もサブスク情報として保存する処理が行われる。
すなわち、サブスクリプション契約に関わる様々な詳細情報が、リカーリングＤＢ４１にサブスク情報として保存されている。

【0137】

サブスクＡＩについて説明する。
サブスクＡＩは、機械学習の手法を用いて、サブスクリプションでの購入ができそうな備品とサブスクリプション契約先候補企業とを選定する人工知能である。
これらの選定は、備品経費情報として保存された情報やサブスク情報として保存された情報を利用して教師なし学習のうちアソシエーション分析の手法を用いて行う。

【0138】

ここまで、医療機関４が備品購入の際に利用する包括契約やサブスクリプション契約の手法について説明してきた。この手法は、備品購入だけでなく、医療機関４や介護機関が共同利用している様々な設備機材（設備）の購入にも使用できる。

【0139】

医療機関４や介護機関が様々な設備機材を共同利用することにより経営上の設備機材投資費及び設備機材経費削減が期待できる。設備機材を共同利用するにあたり、経理業務ＤＢ３１の設備機材情報には、各医療機関４及び介護機関毎に所有している設備機材の品名、メーカー、所有数、管理者、購入年月、導入価格、定期校正予定時期、リプレース予定時期、使用者、借用者、利用予約患者等の設備機材に関係する様々な情報が保存されている。
プラットフォーム型医療機関４支援システム１にある設備機材システム３２は、設備機材情報に保存されている様々な情報を利用して、医療機関４や介護機関が共同利用する様々な設備機材の運用管理を行うことができる。
設備機材システム３２が行う、設備の運用管理としては、各設備の予約状況の管理とその設備の予約を受け付けることできる。この予約は、設備を所有する医療機関４や介護施設６内からの予約だけでなく、設備を共同利用しているほかの機関からの予約を受け付け、受け付けた予約を設備機材情報に保存する。
また、設備機材システム３２は、設備の検索機能もあり、設備機材情報にある情報から利用したい設備機材の検索が行え、検索した設備機材の詳細情報や予約状況の提供を医療機関４や介護機関に対して行うことができる。
結果、バーチャルな医療経済圏２４内で事業を行う医療経済圏２４を利用する企業が、設備機材を貸す事で設備投資費の回収を早める事と、機材を借りる事で設備機材の設備投資費の削減が行える。

【0140】

前述の通り、医療機関４が備品購入の際に利用する包括契約やサブスクリプション契約の手法は、設備機材の購入にも活用でき、包括選定ＡＩやサブスクAIを利用することで行える。手法自体は、備品の購入時と同様のため説明を割愛する。

【0141】

医療機関４や介護施設６などにおいて事業を行っていくと、廃棄物が当然のように発生する。この廃棄物は、一般的な廃棄物だけでなく、針や体液付着物、生体片など患者の持つ病原体と接触している可能性があり、生物学的な危険がある感染性廃棄物やレントゲン定着液などの廃酸などもある。このような一般的な廃棄物以外の廃棄物は、特別管理廃棄物と呼ばれ、限られた業者した処理が行えず、かつ厳格な処理が求められている。そのため、医療機関４などが廃棄する廃棄物は、処理費用が高いという現状がある。
本開示のシステムには、地域内の医療機関４や介護施設６などから廃棄物の情報を取りまとめ、地域で包括して処理を依頼できる廃棄回収システム３３がある。
廃棄回収システム３３は、医療経済圏２４に属する地域の医療機関４などから経理業務ＤＢ３１に保存された廃棄物情報と備品経費情報とを共有することにより取得する。取得した情報をもとに備品として購入した物の中で特別管理産業廃棄物として特別に廃棄する廃棄物の廃棄量をそれぞれの備品の消費状況から廃棄量の予測を行う。予測した結果を合計し算出した値は、ボリューム廃棄量として廃棄物処理の包括契約を行うための廃棄量とする。このボリューム廃棄量をもとに廃棄物処理業者と医療経済圏２４に属する地域の医療機関４などとの間で包括での廃棄物処理契約を行うことにより個別に廃棄物処理業者と契約していた時よりも安く廃棄物の処理できることが期待できる。
廃棄物情報には、廃棄物の種類と、医療機関４などの排出事業者と、廃棄量と、廃棄物処理業者と、廃棄費用となどの情報が保存されている。また、排出事業者と廃棄物処理業者の情報は、医療経済圏ＤＢ２１に保存されている企業情報２３にある医療機関４及び介護機関及び企業事業者の情報と紐づけられいる。
廃棄回収システム３３は包括契約するにあたり、経理業務ＤＢ３１にある包括情報から、有利な包括契約の締結が行える廃棄物処理業者の中から自動で選定する処理を行う。また、廃棄後の決済を医療機関決済支援システム１０２を用いて行う。

【0142】

ここで説明した「複数の医療機関４の情報を共有するシステム」は、医療経済圏２４というバーチャルな環境にある様々なシステムを複数の医療機関４が共有利用することができる。同じように共有するシステムを提供しているものに米国のGAFAと呼ばれている４つの企業「Google(登録商標)」「Amazon(登録商標)」「Facebook(登録商標)」「Apple(登録商標)」がある。この米国のＧＡＦＡは、システムを企業に提供しているが、企業がシステムを利用することで発生するデータはＧＡＦＡの所有物になってしまう側面がある。本来日本の常識からすれば企業のデータ（企業の所有物）と思いがちだが、システム上で発生するものは企業の所有物にはならない、それがクラウドシステムというビジネスモデルである。このＧＡＦＡのクラウドシステムを利用している日本企業は、ビジネス上のデータを取られてしまっても構わないという企業や、ビジネス上発生しているデータの所有者がクラウド側であることに無頓着な企業が利用しており、一度米国のクラウドを利用してしまうと発生したデータが戻ってこない事から一生クラウドを使い続けなければならない、首に鎖がついたペットのようなものとなってしまう。このことは、いつか日本企業にとってそれが問題になる時が来ると予想しており、データをＧＡＦＡに取られない意味でも日本で同様なシステムを構築する意味があり、医療のデータは個人情報２２である側面からも外国企業には渡せないものである。
本考案は、医療経済圏２４の中にあるシステムを複数の医療機関４や企業が利用することで、医療機関４や企業から発生するデータを医療経済圏２４の中で共有利用することで、そのデータを利用し様々な処理方法でデータを作り出し、その処理したデータを利用し、システムから利益を産出すことができる。その産出した利益を、システム費や医療機関４や企業や利用者３に対して還元すること、利益を出すシステムやサービスを考案し利益追求から還元していくビジネスモデルはＧＡＦＡとの違いである。ＧＡＦＡに並ぶ医療経済圏２４を構築することは日本にとって必要なものであると考える。
ここで説明した「複数の医療機関４の情報を共有するシステム」は、医療経済圏２４の中で複数の医療機関４から発生するデータを共有利用する事で、従来経営に直接関わる備品の薬や設備投資に纏わるコストや固定資産税を抑える事や産業廃棄物処理の契約に関するシステムである。医療機関４の経営を安定させ、患者へのサービスを拡大させていくために考案したものである。比較的に小規模の医療機関４でも、バーチャルな環境で小規模な複数の医療機関４を集めてしまえばそれはバーチャルナ大きな医療機関４となり、リアルな大きな医療機関４の規模よりもまさる医療機関４ができてしまう。このメリットを活かすことが医療経済圏２４である。
将来、人口減少から病院４ａは余る。医療機関４同士による患者の取り合いの時代がくる、そんな時代になった時に、患者から選ばれる医療機関４とは、患者にサービスを提供する医療機関４である。今まで患者へのサービスを怠っていた医療機関４には患者へのサービスを提供してもらいたい。この医療経済圏２４を利用することで患者への様々なサービスを提供することができる。他の実施形態で説明しているサービスを医療経済圏２４の中で利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者はサービスを提供する医療機関４を選ぶようになる。患者への様々な医療サービスを提供する時代が始まると考える。

【0143】

＜第２実施形態＞
医療機関４における病院経営及び診療・診察の付帯業務の改善は喫緊の課題の１つといえる。
現在、多くの医療機関４では、「来院後、待合室で数時間待たされ、数分診察」と言われている。とくに、大きな医療機関４では朝早く受付開始時間前に待ち、診察前に大きな待合室で診察待ち、名前が呼ばれると中待合室で診察待ち、診察が終われば長い会計待ち、調剤薬局４ｂで処方薬待ち、こういった「患者が待たされる」ということに対して、患者への配慮をしないこと慢性化してしまっていることである。
このことにより、待合室では、大勢の患者が待っている。さらに、病院４ａの診察予約を行っていても、大勢の診察待ちの患者がいる待合室で一緒に待たされることとなっている。これらは、診療・診察の付帯業務の一環として改善すべきことである。
さらに、感染症が蔓延している状況では、患者は、院内での感染を恐れ病院４ａへ行かなくなる。特に高齢の患者は院内での感染を恐れ病院４ａへ行かなくなったのは2020年に発生した事案は出願時前年既成事実である。よって、患者数の減少により病院経営は悪化していく。本開示の医療情報システム９では、「待たない診察」により、科学的な予防策がなく治療法もない感染症に対応すべく、患者が院内感染を恐れず、安心して病院４ａに行ける体制を作り、病院経営を改善させる方法でもある。

【0144】

第一に病院４ａの待合室などでの、診察待ち患者を減らすまたは、診察待ち患者を病院周辺の商業施設や飲食などの他の場所へ分散する方法と外来患者が集中する時間帯の診察待ちを別の時間へ分散する方法として、診察予約の方法を考案した。第二に、診察時間に合わせて通院できるシステムで、待合室での待機時間を減らす方法を考案した。この二つにより、感染を恐れて来院を避けていた患者が、安全であると見直し、再び来院することの期待がもてる。よって、パンデミックの状況下においても病院４ａの経営に影響を与えなくなる。本考案により医療機関４での「待たない診察」を推奨していきたい。

【0145】

従来、医療機関４で使用されている診察予約は、一定時間に数名の患者を詰め込む予約システム９ｄであり、患者の診察時間前に、診察予約で詰め込まれた患者同士の診察待ちにより密が発生しており、この密を招く原因は予約システム９ｄが患者同士の診察待ちによる滞留には、全く考慮していない単純なロジックによるシステムになっているからである。
日本中の医師５ａや医療機関４経営者が、もっと患者目線で患者に寄り添った医療行為を行えば本件で指摘している「患者が病院４ａに来ない」という事が、自らが招いた弊害で起きていることに気がつき、自ら対策をとる必要があると考えなおすのが必要である。
現在の予約システム９ｄによる診察待ち滞留を招く問題点を解決するには、患者自身の診察所要時間を用いたロジックによる診察予約をすることで、患者同士の診察待ちを無くすことが可能となる。
それには、患者自身の適切な診察にかかる診察所要時間を予測したうえで、その予測した診察所要時間を利用して次回診察の予約を行い、予約した患者が予約時間に来るようにする方法と、患者が予約した時間に診察を開始し予測診察所要時間で診察が終了する方法とを実施することで、待合スペースに人を滞留させない環境が構築でき「待たない診察」を行うことができる。
しかし、ここで必要な患者の診察所要時間は、電子カルテ９ａ上に記載がないため、予約に使用することができない。よって、診察時に記録される様々な情報の中から適切な物を使用して診察所要時間を予測することが必要となる。予測した診察所要時間を使用して、次回診察を患者の診察所要時間帯で予約することができる。診察所要時間の予測は、病状とその病状による診察時間などの情報を利用した人工知能を利用する。

【0146】

ここで、診察所要時間の予測に用いる人工知能について説明を行う。診察所要時間の予測に用いる人工知能は、機械学習のうちニューラルネットワークを利用した人工知能を用いる。
診察所要時間の予測結果を出すための、学習に必要な情報源である情報源情報について説明する。情報源情報は、医療機関４で使用している電子カルテ９ａから取得できる以下の情報で、取得した情報は診察所要時間ＤＢ５１に保存される。電子カルテ９ａから取得する情報は、患者名、年齢、性別、初診時の来院の病状程度、初診時の該当部位と、複数患者の慢性疾患名及び病名（病名情報）、病名の病状の程度（病状名情報）、担当医師名、患者通院時の医師５ａが患者の電子カルテ９ａを開いた時間、その医師５ａが患者の診断を保存して終了した時間、これらの情報を使用して人口知能の機械学習を行うものとする。
診察している時間すなわち診察所要時間のうち医師５ａに関係なく、病名情報もしくは病状名情報ごと診察所要時間である診察所要時間情報を算出するには、「診察の終了時間」から「診察の開始時間」を引いた時間を基本とし、これを電子カルテ９ａ上の情報に置き換えた場合、「患者の診断を保存して終了した時間」から「患者の電子カルテ９ａを開いた時間」を引いた時間となる。診察所要時間情報は、情報源情報の１つであり、診察所要時間ＤＢ５１に保存される。また、病名情報もしくは病状名情報だけでなく医師５ａを特定した診察所要時間を上記の方法で算出した場合、情報源情報の１つである医師診察所要時間情報となり、診察所要時間ＤＢ５１に保存される。

【0147】

学習に必要な情報源の取得方法は、プラットフォーム型医療機関支援システム１上の診察時間システム５２が、ネットワークで連携した医療機関４が使用している電子カルテ９ａから、年齢、性別、初診時の来院の病状程度、初診時の該当部位と、複数患者の慢性疾患名及び病名、病名の病状の程度、担当医師名、患者通院時の医師５ａが患者の電子カルテ９ａを開いた時間、その医師５ａが患者の診断を保存して終了した時間などの情報を取得し、学習源情報として診察所要時間ＤＢ５１に保存する。

【0148】

診察所要時間の予測結果を出すための学習方法は、診察所要時間ＤＢ５１に学習源情報として保存された情報と、算出した診察所要時間とを教師データとして用いた学習を行う。学習させた結果、病状ごとの診察所要時間または症状ごとの診察所要時間を予測できるモデルが作成できる。このモデルに、予測したい患者病状や性別などの情報を入力することにより、同一病状の患者の診察所要時間の予測が可能となる。
このモデルに同一病状の複数の患者の診察所要時間など学習源情報のうち患者の年齢や性別など医師診察所要時間情報以外の情報を用いて前記相関関係に当てはめて予測処理を行う。この予測処理の結果は、診察所要予測時間情報として診察所要時間ＤＢ５１に保存される。
上記では、学習源情報のうち患者の年齢や性別など医師診察所要時間情報以外の情報を用いてが、医師診察所要時間情報を含めた情報を用いて前記相関関係に当てはめて予測処理を行うこともできる。この場合の予測処理の結果は、医師診察所要予測時間情報として診察所要時間ＤＢ５１に保存される。
診察所要予測時間情報または、医師診察所要予測時間情報が患者の診察所要時間の予測結果となる。

【0149】

リアルタイムで学習することにより、常に最新の学習結果を利用して診察時間の予測を行うことができる。例えば、予測した時間と実際に診察に要した時間に乖離が生じた場合、予想したときの病状と現状の病状との違いなどをリアルタイムで取得し、自己学習行うことで学習制精度が向上する。この場合、患者の診察が終わった時点で診察時間システム５２は、学習を開始し、学習結果を更新する。また、学習結果がすぐに反映できた場合は、その診察時に行う次回の診察予約に用いる診察所要時間の予測結果として使用することもできる。リアルタイムで学習が行わることで、常に最新の学習結果を利用できる。
リアルタイムの自己学習とは、アメリカのAmazon.com社が運営しているAmazon Go（商標）という無人店舗で用いられている、「会計結果の間違いを指摘するとシステムに用いている人工知能が即座に学習しシステムに反映する」手法などのことであり、人工知能に追加の情報を与えると即座に学習しシステムに反映すえることを示す。このリアルタイム学習には、事業者側で学習させる人員が介在しないことが特徴である。
本開示のシステムとAmazon.com社のシステムのリアルタイムの自己学習では、以下の２点が異なっている。
Amazon.com社のシステムは買い物を行った人すなわち利用者３がスマホで作業を行うことによりその作業が人工知能への学習として行われる。一方、本開示のシステムの場合は、医療機関４の予約時点に、すなわち人工知能を運用する事業者側の診察時間システム５２が自動で算出処理を行うことにより人工知能への学習が行われる。
また、Amazon.com社のシステムはご認識による間違いを防ぐための画像認識の精度向上のみを目的としている。一方、本開示のシステムは、診察所要時間の精度向上を目的としている。

【0150】

診察所要時間の予測結果を出すための学習方法は、患者が初診の場合に用いることができる。患者が初診（新規外来患者）の場合は、診察所要時間ＤＢ５１に学習源情報のうち、過去に初診として新規に来院した患者が問診表に記載された症状及び症状が現れている部位の情報とその患者の年齢や性別などの情報と、初診時の診察所要時間と教師データとして利用した学習を行う。学習させた結果、症状及び症状が現れている部位ごとの診察所要時間を予測できるモデルを作成することがでる。
初診の新規外来患者など、予約をしていない患者にも適応する場合、本開示システム上の問診票のデータを利用する。この問診票は、患者が症状に合わせてプルダウン形式で症状を選択していく方法や、予め記載された症状の選択項目から、あてはまる症状を選択してく方式、症状を自由記入する方式などが想定されるが、これらに限らない。また、この問診票への入力は、患者が新規の診察予約を行うためのポータルサイトなどのＷＥＢサイトや携帯端末にインストールしたアプリケーション上で入力を行う方法と、医療機関４への電話により医療従事者５が聴取し本システムに入力する方法とで行われる。ポータルサイトの例として出願人考案の特許第６５５８６６９号の図１０に開示の技術などがある。
診察所要時間を予測できるモデルに上記の方法で取得した問診票のデータを入力することにより、診察所要時間を予測する。

【0151】

第２実施形態のデータベース構成を図８に示す。

【0152】

腹痛を訴えている初診の患者の診察所要時間の予測及び予約方法の例を示す。
初診の患者は、本開示システム上の問診票に、年齢や性別などの情報と腹部全体が痛いという情報入力した。入力された情報をもとに、本開示のシステムは、診察所要時間ＤＢ５１の学習源情報から、過去に腹部全体が痛いと訴えて来院した複数の患者の情報を取得した。取得した情報をもとに人工知能を用いた診察時間の予測処理を行ったところ、診察所要時間は１０分と予測した。

【0153】

また、診察所要時間の予測結果を出すための学習方法は、慢性患者など定期的に通っている患者などの診察所要時間の予測に用いることができる。

【0154】

慢性患者など定期的に通っている患者の予測方法の例として糖尿病患者を例に示す。
似た病状の糖尿病患者データが１０人分あり、１０人の患者に対し２人の医師５ａが診察を行っている。１０人は、Ａ医師５ａとＢ医師５ａのどちらかまたは両方の診察を受けている。１０人の患者の過去４回の診察時間と担当した医師５ａは、図９に示した時間と医師５ａであった。
図９に示した情報を用いて機械学習を行うと、年齢が若いほど、男女間では男性の方が、担当医ではA医師５ａだと診察時間が短くなると学習する。
図示した病状と同一の病状の５４歳の女性がいたとする。この女性を次回B医師５ａが診察する場合、人工知能は、学習の結果を利用して次回の診察時間を、１０分と予測する。

【0155】

病状の変化がなく同一病院４ａで同一医師５ａによる診察の場合、又は電子カルテ９ａの情報に同じ病名でほぼ同一の病状の患者が居ないため患者データが無かった場合は、患者自身の診察が行われたときの過去の診察所要時間のみを用いて診察所要時間の平均時間を予測した時間として使用してもよい。
病状の変化がなく同一病院４ａで同一医師５ａによる診察で平均時間を使用する理由は、自身の過去の診察所要時間の平均を利用したほうが、人工知能を利用と同等かそれ以上の精度が高い診察所要時間が求められるため、人工知能を用いる必要が無いためとなっている。
電子カルテ９ａの情報に同じ病名でほぼ同一の病状の患者が居ない場合に平均時間を使用する理由は、人工知能に学習させるために必要な情報が学習源情報に存在しないため、人工知能を用いた予測が行えないためとなっている。

【0156】

自身の診察が行われたときの診察所要時間に、電子カルテ９ａから取得した同一病状の患者や同一症状の患者の診察所要時間を組み合わせることで、診察所要時間の予測結果の精度が上がることが期待できる。また、同一症状の患者の診察所要時間を利用せず自身の診察が行われたときの診察所要時間のみを用いて診察所要時間の予測を行ってもよい。

【0157】

初診の新規外来患者や、既に病院４ａにかかっている既存患者の次回の診察予約を行う際、医療機関４は、医療機関支援システム１で予測した診察所要予測時間情報を利用して予約を行うことができる。この予約の完結により患者が予約変更を行うと、当日に予約変更やキャンセルを行った予約患者の診察所要時間分の診察の空き時間ができてしまう。この空き時間が医療経営にマイナスを及ぼす。その為に、この空き時間となってしまう予約変更やキャンセルを無くすための処理が次に説明する方法である。診療予約時に患者の予定をマージして予約を行う方法である。この際、患者が医療機関支援システム１上の医療経済圏ＤＢ２１にある個人情報２２に患者の予定である患者予定情報を入力し保存していれば、その予定を加味して来院できる候補の日時を算出し、算出した候補のうち病院４ａで診察が行える時間の予約機能を持つ病院４ａの端末や患者の持つ端末に表示処理をさせ、患者の希望日時に合わせて予約を行う。患者が予約した情報は予約ＤＢ６１に予約情報として登録されている。診察時間の予測を利用して予約を行うことにより、効率よく診察が行えるようになる。上記では、患者が医療機関支援システム１上の医療経済圏ＤＢ２１に患者予定情報を入れていればとしたが、外部のスケジュールを管理するシステムから患者の予定を患者予定情報として取得し、利用してもよい。

【0158】

医療機関４で行う実際の予約は、予測した診察所要予測時間情報と患者予定情報とこれら２つの情報をマージした結果と、病院４ａの予約の空き状況（予約状況）である予約状況情報とをあわせた予約可能な日・時の候補を端末に表示する処理をし、表示された中から患者が選択した日・時の診察開始時間と患者の前記診察所要予測時間情報と診察終了時間とを患者の予約情報として予約ＤＢ６１に記録保存されることにより行われる。患者の予定情報と予測した診察所要時間と次回の診察予約をおこなったことで、予約した日以降に患者からの予約変更を無くすことが期待できる。予約状況情報の取得は、医療機関４が使用している医療情報システム９にある予約システム９ｄから予約状況を取得もしくは、医療情報共有データベース２にある予約ＤＢ６１から予約状況を取得することにより行われる。
診察予約時に患者の都合に合わせた診察予約を行う目的は、予約完了後に患者からの予約変更又はキャンセルが無くなり予約されたスケジュールのまま診療ができるが、予約日変更があると数分から数十分の空白の時間ができてしまい、空白時間を無くすために行うものである。

【0159】

ここで、診察所要時間の予測を利用した診察予約の運用例を記載する。
Ａ医師５ａが診察する予約が９時からの１時間に患者３件あり、それぞれの患者の診察所要時間は、Ｃさん１０分、Ｄさん１５分、Ｅさん２０分となっている。また、患者と患者との診察の間に、余裕時間（前の患者への診察の片付けや次の診察の準備などを行うための時間）を用意する。
９：００〜９：１０の１０分間が、Ｃさんの診察時間
５分間の余裕時間
９：１５〜９：３０の１５分間が、Ｄさんの診察時間
５分間の余裕時間
９：３５〜９：５５の２０分間が、Ｅさんの診察時間
５分間の余裕時間
本考案の診察予約管理システム６２では、このような運用例となる。

【0160】

慢性患者の場合、かかりつけ医による過去の診察時間などを用いて、診察時間を予測しているため、診察する医師５ａにとっては、十分な診察時間が与えられたこととなる。十分な診察時間が与えられているため、病院４ａは、１日の予約通りに診察が行え、結果患者は待合室で長く待つことが無くなり、また待合室を患者同士で密にすることが無くなり、患者は感染を恐れ、病院４ａを避けることが無くなり、
病院４ａに行けば「待たない診察」が受けられるという新しい診察となり経営の安定化につながる。

【0161】

上記では、医療機関４の診察予約を行う際、患者予定情報を加味して予約できると記載した。患者予定情報を加味して予約した場合、次回の診察予約の日時などを医療機関支援システム１上の医療経済圏ＤＢ２１にある個人情報２２、または、外部のスケジュールを管理するシステムにある患者予定情報に追記することができる。この追記を医療経済圏２４のポータルサイトで追記することができても良い。ポータルサイトの例として出願人考案の特許第６５５８６６９号の図１０に開示の技術などがある。ポータルサイトで患者のスケジュールを見ることや予約の変更などが行える。

【0162】

従来、医療機関４での予約は、１時間に複数人の予約を受け付け、患者の診察時間が長引きズレ込みが始まると、診察時間のズレ込み時間が拡大し患者の待ち時間が長く待合室での診察待ち患者も増えて待合室が「密」となっていた。
考案のシステムは、診察所要時間に合わせて予約を行っていく。このことは、予約した診察時間のスケジュールに合わせて患者を診察することとなり、正しい診察所要時間を導き出すことにより、患者を待たせることなく、スケジュール通りに診察することができる。しかし、予約時間に合わせて患者が来院しなければ、精度よく診察時間を予測しても、診察時間の予測精度を上げても、スケジュール通りの診察は行えない問題が残る。

【0163】

患者を予約時間までに来院させるには、患者に対して来院時間であることを忘れさせずに通知するなどして、患者に予約時間どおりの受診を促す必要があり、本開示のシステムで実現できる。また、病院４ａは、予約時間までに患者が来るのか、患者が遅れる場合どの位の時間遅れるのか、そもそも患者が来院するのか否か、などの情報が分かれば、より病院４ａの運営は円滑に行える。
そこで、患者が医療機関４での予約時間に間に合うように、家を出る移動開始時間が分れば良い。移動開始時間は、患者の居住地住所から病院住所へ向かうルートと、そのルートの移動距離と、来院方法（移動方法）による所要移動時間と到着時間（医療機関４の診察予約時間）により、家を出る時間（通院開始時間）を算出することによりわかる。それぞれを算出して求める方法を以下に示す。
患者の居住地住所を求めるには、医療機関支援システム１は、ネットワークで連携している電子カルテ９ａや医療情報システム９などから患者の住所を取得する処理を行う。また、診察予約時間の取得は、医療経済圏ＤＢ２１上の予約ＤＢ６１に保存されている診察の予約情報から取得できる。
これら取得した情報と、外部システムを利用すれば、患者が家を出る出発時間（通院開始時間）や、移動ルートや、移動所要時間も同時にわかる。
外部システムとは、例えば、ドライブナビ機能のシステムやGoogleマップ（商標）等のインターネットサービス等である。この外部システムは、出発地と到着地が分れば、移動方法による最適なルート、移動方法による所要時間、移動方法による到着時間、到着時間に合わせた出発時間を提供してくれるサービスである。移動経路算出の例を図１０に示す。
医療機関支援システム１は、医療経済圏ＤＢ２１上から出発地（患者居住地取得部が取得した患者宅住所）と、到着地（病院住所）と到着時間（診察予約時間）を外部システムへ提供する処理を行うことで外部システムから移動方法（歩行、車両等）毎による移動所要時間と通院開始時間（患者が家を出る出発時間）を取得することができる。
医療機関支援システム１は、外部から取得した通院開始時間またはその時間の少し前に患者に対して家を出る時間（予測した通院開始時間）であることをスマートスピーカーや携帯端末など患者の所有する端末に対して自動的に通知する処理を行う。ここで言うスマートスピーカーは、第３実施形態に記載する電子機器７３などのことを示す。
この通知に患者が患者の所有する端末等で応答を行い、病院４ａの医療機関支援システム１が応答したことを受信処理が行われると、病院４ａは、患者が来院すると判断の処理を行い、その段階で仮の事前受診受付の処理を行う。
また、医療機関支援システム１は、患者へ予測した通院開始時間であることを通知する機能に加え、患者の持つ端末から、患者の現在地（位置情報）を取得する処理ができる機能を患者現在位置情報取得部として用意する。この患者現在位置情報取得部は、予測した通院開始時間において、患者の現在値の情報を取得する処理を行い、取得した現在値が患者の居住地から離れ、かつ病院４ａの方向に居る場合、既に病院４ａに向けて移動していると判断の処理を行い、通知なしに仮の事前受診受付の処理を行い、診察の受付の処理を行う。患者の現在地の取得は、ＧＰＳやモバイル通信網の電波、wifiの電波、ネットワークＩＰアドレスの情報などを用いて行う。このような情報を利用した位置情報の取得は、Geolocation APIとして一般に知られており、民間サービスやプログラムなど様々な場所で使用されている。
前記では、予測した通院開始時間での位置としたが、予測した通院開始時間から診察予約時間の間の時間でもよい。さらに、病院４ａを中心に一定距離（半径）に３６０°円形ゾーンを設け、そのゾーンより病院4ａ側に患者がいれば、仮の事前受診受付処理を行う。例として、予約時間の３０分前でゾーン１の１ｋｍ以内，予約時間の１０分前でゾーン２の２５０ｍ以内など複数のゾーンを設定してもよい。また、医療機関支援システム１は、患者がどのゾーンに居るかを病院４ａに設置の端末に表示処理する機能を有してもよい。外部の地図システムを使用して表示を行う処理をする。位置情報をもとに到着時間を予測する考案は、例えば特表２０１９-５２１４３２などがある。この考案と本開示の考案との違いは、患者の動きに合わせて予測を行う方法と、決まった到着時間から逆算して出発時間を算出する方法との違いが明らかである。ゾーンの例を図１１に示す。
仮の事前受診受付を行った患者が来院した際、医療機関４に設置されたカメラの画像情報や指紋センサーで取得できる指紋の情報と、予め医療機関支援システム１に保存してある顔写真データや指紋のデータなどの生体情報を用いた生体認証や受付に診察券を提示し記載されている管理番号から紐づいた患者の認証情報を用いて患者と判別する処理を行い、仮の事前受診受付を正式の受診受付に読み替える処理をする機能があってもよい。
説明では、病院４ａ到着後に正式の受診受付に読み替えるとしたが、説明上の仮の事前受診受付の時点で正式な受診受付としてもよい。
仮の事前受診受付や正式の受診受付処理が行われた際、患者の持つ端末に受付が行われことを通知する処理を行い。その際、病院４ａへの到着予想時刻を病院４ａに設置の端末に表示処理する機能を有してもよい。

【0164】

従来、医療機関においては、来院し診察の受付を行ったけた順（予約時間ごとに診察の受付を行った順）で診察を行っていた。本開示の場合、病院４ａに行く行動を行った段階や病院４ａを中心に一定距離以内に居る場合などに仮の事前受診受付や正式の受診受付を行っている。そのため、従来の「来院し診察の受付を行ったけた順に診察」を行うといった従来の受付ではなく患者自身の診察時間帯を確保してからその時間に合わせて来院するという新しい病院４ａの文化になる。また、診察予約の運用例に示した通り時間ごとに診察する患者が決まっている。そのため、受付順に関係なく、予約時間に合わせた順番で診察を行っていく。朝早く行って受付の順番待ちをし、受付後は長い時間の診察待ちをするという昔からの文化は、高齢者や病気を患っている人には負担であり、患者を待たせることに対して配慮や改善を考えることをしてこなかった、いわゆる診療以外のことに関しては患者目線でものを考えないことが慢性化してしまっていた。本考案は患者に寄り添い、すなわち、レストランなど一般的な予約と同様で、座って食べられるテーブルと時間を予め確保するものとなんら変わらない考えである。

【0165】

上記説明における、経路及び所要時間の取得は、距離以外の要素を使わずに行っている。医療情報システム９上の外部情報取得部がインターネットなどの外部ネットワーク上から取得した天候の情報や道路状況、外気温を加味して経路及び所要時間の予測の処理を行ってもよい。この予測は、一般に「屋根が多いルートの検索」や「雨に濡れないルートの検索」として使われている技術を利用して行う。さらに、電子カルテ９ａなど患者の情報が記録され、患者の状態の情報と通常の移動手段が記録されている情報システムから、患者の状態の情報と通常の移動手段とを取得し、経路及び所要時間の予測の処理を行ってもよい。この予測は、一般に「段差が少ないルートの検索」や「バリアフリーなルートの検索」として使われている技術を利用して行う。患者の情報が記録されている医療経済圏ＤＢ２１には、患者の状態や患者の移動手段なども保存されている。
経路及び所要時間の予測を行った結果は、病院４ａの医療機関支援システム１及び患者が所有する端末へ通知される機能を有してもよく、病院４ａへは経路と所要時間と到着予定時間が通知され、患者へは移動の所要時間が通知する処理が行われる。病院４ａの医療機関支援システム１に到着予定時間などの予測結果が通知される処理により、病院４ａは到着予定時間の予測結果により何分程度遅れるかがわかり、別の患者の診察を行うなどが行える。患者に予測結果が送られることにより、何分ぐらい遅れるのかを把握することができる。患者に対し、病院４ａへの移動所要時間が送られる処理が行われ、予約時間に間に合わないと分かった場合、患者は、移動手段の変更を行うなど、予約時間に間に合わせるための行動を行うこともできる。例えば、徒歩で病院４ａに向かっている患者が、所要時間から予約時間に間に合わないと分かった場合、バスやタクシーを利用して病院４ａに向かうなどの対応が行える。
また、患者が診察時間に間に合わなかった場合、その履歴を医療経済圏ＤＢ２１上の遅刻情報に保存する処理を行う。この場合は、家を出る時間の通知から家を実際に出るまでに時間がかかるなど患者が原因の理由なのか、それとも外的要因によるものなのかなどを含む、想定される遅刻要因も合わせて遅刻情報に保存する処理を行う。
患者が原因の理由、又は患者の病状によって診察時間に間に合わないことが多い患者には、通常より早く通院開始時間の通知を行うなどの処理を行ってもよい。
患者の状態とは、「普通に歩ける」「杖やシルバーカーがあれば歩ける」「シニアカーで移動」「車いすのため介助が必要」などのことを示す。通常の移動手段とは、普段の来院手段が、徒歩なのか、自家用車やタクシーなどの車なのか、バスなどの公共交通機関なのかなどのことを示す。
例えば、患者は、現在、病院４ａから１ｋｍ離れた場所に住んでおり、杖があれば歩けるとする。普段の通院は徒歩で行っている。通常であれば病院４ａまで１７分程度で病院４ａに到着すると予測がされている。しかしながら、インターネットなどの外部ネットワーク上から取得した天候の情報は、雨天であったため、通常より通院に時間がかかると本開示のシステムは判断処理した。また、想定経路上で交通事故が発生しているとの情報もインターネットなどの外部ネットワーク上から取得しており、事故現場を迂回する都合でさらに遅れると本開示のシステムは判断処理した。医療機関支援システム１は、雨天と交通事故という二つの情報から、患者が通る経路を予測し、結果、通常より１０分長い２７分を要する予測処理した。この結果を患者及び病院４ａへ通知の処理をする。

【0166】

本実施形態で示した、「診察所要時間の予測と患者の予定を加味した診察予約」と「位置情報を利用した自動受付」により、患者が待合室で長時間待たされない「待たない診察」を行うことができる。また、患者の予定を加味した予約を行っているため、医療機関４側としては、患者都合による予約の変更や予約のキャンセルが無くなり、効率的な診察も行えるようになる。

【0167】

本開示の自動受付の拡張として、医療機関４周辺の商業施設や飲食店と協力のもと、医療機関４周辺の商業施設や飲食店へ誘導して診察待ちしてもらうこともできる。これも待合室での密を防ぐ方法の一つである。例えば、医療機関４の自動受付完了の連絡の際、診察予約時間前のみ有効な医療機関４周辺の商業施設や飲食店で使用できるクーポンを配布する処理を行う。患者は、そのクーポンを利用して診察待ちを行う。患者がクーポンを利用して医療機関４周辺の商業施設や飲食店で診察待ちを行った場合、予約時間になる少し前に「患者に予約時間であることを声掛けする」や「患者の所有する端末へ通知処理を行う」などのサービスを行うことにより、患者が予約時間に遅れることを防ぐこともできる。
医療機関４の診察待ちを医療機関４周辺の商業施設や飲食店を行うことで、医療機関４周辺の商業施設や飲食店は、利用者３（患者）が増えることも期待される。

【0168】

ここまで、「診察所要時間予測し患者の予定を加味した診察予約」や「位置情報を利用した自動受付」を行うビジネスモデルの説明をしてきたが、「診察所要時間予測し患者の予定を加味した診察予約」の情報を利用することにより、医療機関４は売上の予想も行うことができる。
プラットフォーム型医療機関支援システム１上の予約売上算出システム６３は、予約状況情報から1日分の予約患者が予約時に行った診察の診療報酬点数情報を診療情報ＤＢ５３から取得する。この予約状況情報は、医療情報共有データベース２にある予約ＤＢ６１に保存されている予約状況または、医療機関４が使用している医療情報システム９にある診察予約管理システム６２から取得した予約状況となっている。
取得した、1日分の診療報酬点数を合計することにより処理を行うことにより、予約患者1日分の売り上げの状況を把握することできる。

【0169】

ここで説明した「待たない診察」を実現するための「診察所要時間を予測して予約を行うシステム」「患者を予約時間通りに通院させるシステム」等を、医療機関４でシステム開発する投資を行ったとしても、投資額の回収を患者から診察費の中から回収することはできないと考える。そのためにプラットフォーム化されているシステムを医療経済圏２４の中で、沢山の医療機関４と共有することでそれぞれの医療機関４の支出は少なくなり、１つの医療機関４だけで無く医療経済圏２４を利用する全ての医療機関４が支出は少なくなる。さらに他の実施形態で説明しているサービスを医療経済圏２４の中で利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者はこのシステムを利用していない医療機関４は選ばなくなる、これが患者へ寄り添うことの効果になると推測する。患者への様々な医療サービスの時代が始まると考える。

【0170】

本実施形態で説明してきた「診察所要時間予測し患者の予定を加味した診察予約」「予約状況情報を利用した売り上げ予測」や「位置情報を利用した自動受付」を利用するサービスを提供するビジネスモデルにより、患者へ寄り添った、医療機関４としての経営改善を行うことが実現できる。

【0171】

＜第3実施形態＞
病院経営は、従来から患者数に依存した医療経営となっている。患者が多ければ利益を上げられる。毎回通院する患者（すなわち慢性疾患の患者）を大勢抱えれば良いことになる。しかし、本考案の出願時点では世界的な感染症の蔓延により、患者が病院４ａでの感染を恐れ病院４ａに来なくなる事象が起こり、病院経営に影響が出た。病院４ａは、患者に安心して来院してもらう安全策を講じることで来院者を増やす取り組みだけに拘らず、事業形態を見直し来院する患者数に依存しなくとも経営が満足に行える新しい発想での事業経営を行う事が必要となる。病気を治すことと、未病な患者を増やす事、病気になる前に手を施す事、有病者の安全生活支援を行う事、長生きへの長寿生活支援を行う事など、様々な側面での新しいビジネスがあり、これらにより持続可能な医療経営を行うことができる。

【0172】

昨今、遠隔リモート診療を診察に取り入れる医療機関４が増えてきた。遠隔リモート診療は従来の診察室での１：１の対面診察を遠隔リモートにしただけであり、従来の患者が来院するのを待っている従来のスタイルと変わらず、患者が目に見えて増えるわけでもなく経営改善には至らない側面である。また、高齢者や一部の有病患者にとって遠隔リモート診療に使用する機器の操作は敷居が高いものであり操作ができる患者に限られてしまい、遠隔リモート患者が特段に増加するものではない。よって、リモート診療は、感染には安全であるが、医療経営という側面では経営状態が良くなるものではなく、医師５ａの医療業務における利便性が改善されるだけのＩＴツールでもある。医療経営は改善するには、治療を必要とする患者数を増やす事よりも、治療を必要としない患者にフォーカスを充て、未病者（未病患者）を増やす医療こそが社会にとっては望ましい事であると考えます。

【0173】

本開示は、利用者３の健康管理や未病社会形成への貢献も含め、健康な高齢者や有病者の生活支援における様々なサービスを利用者３の自宅に設置した電子機器７３を利用して、利用者３と会話するのは医療機関４で働く医師５ａや看護師５ｂ達が利用者３の為に考えたシナリオ（台本）を使用した「バーチャルな対話又は会話」を行い、その対話又は会話から様々なデータを取得し、その取得したデータを解析して社会支援・生活支援・健康支援・診療支援等のサービスとして展開できることが考案である。これは、病気を患っている患者を対象としていた事業から、病気では無い未病者や、健康を意識している未病者、将来の病気や生活に不安を感じる人、病気になりたく無いと健康意識の高い人、満足に人生を終えたいと考えている人等、対象を患者から多岐に渡る利用者３へとマーケット対象を広げることで医療機関４の持続型経営へと改善するのは言うまでもない。遠隔リモート診療と同じように、遠隔で会話を行うことであるが対象としている会話の相手は有病者だけよりも対象者が拡大しているため様々なサービスへ応用ができるものである。遠隔リモート診療と違う点は、遠隔リモート診療では、患者と医療機関４や医師５ａとのお互いの時間を合わせ同期させて向かい合う事に対して、本考案は利用者３と医療機関４や医師５ａとがお互い時間を合わせることなく非同期による会話で行う事が相違点である。さらに遠隔リモート診療と違う点は、医師５ａと患者との１：１による画面上の対面であることに対して、本考案は医師５ａと利用者３との１：Ｎにより利用者３から取得した様々なデータを利用した健診を行うことが相違点である。この２点が遠隔リモート診療との最大の違いとなる。
また、利用者３が病院４ａに来なくても、利用者３の日常のデータが保存されるため、そのデータを見て利用者３を支援することは病院経営の新しいビジネスモデルであり、このことは医療機関４だけに限らず自治体や様々な事業体においても、利用者３を対象に様々なビジネスに展開し参入できるプラットフォームである。このプラットフォームビジネスは、遠隔にいる利用者３と会話を行い、会話から情報を集め保存し、日常の生活から採取できる様々な情報を利用して利用者３に対する診察や、様々な支援等のサービスや、全ての利用者３の情報を解析しデータから統計等を取る事から新しいサービスや、データを活かしたビジネスとしての展開できることや参入が容易にできるものとなっている。

【0174】

市場で既に使われているスマートスピーカーについて簡単に説明すると、利用者３の自宅に設置した電子機器７３は、利用者３の音声を認識できる機能と、利用者３に対し自然言語で会話できる機能と、事業を展開している事業者が外部ネットワーク上に用意しているAIシステムとを音声で動作させる機能と、外部ネットワーク上の情報を検索し取得する機能とを有している。このような機能を有する電子機器７３は、一般にスマートスピーカーと呼ばれ、AmazonEcho（登録商標）、GoogleHome（登録商標）、HomePod（登録商標）、ClovaWAVE（商標）などが、一般に知られている。同様の機能を備えている電子機器７３であれば、その呼び名はスマートスピーカーに限らず、ホームスピーカー、AIスピーカー、などの呼称であってもよい。また、Android Automotive（商標）や、Apple CarPlay（登録商標）といった、AIが搭載できるまたは搭載されているカーナビゲーションシステムやモバイル端末と連携することによりAIが使用できるカーナビゲーションシステムも電子機器７３に含まれる。本開示において、事業者システムとは、AmazonEcho（登録商標）、GoogleHome（登録商標）といった一般にスマートスピーカーと呼ばれる電子機器７３を動作させるために利用している外部ネットワーク上システムのことを示す。
さらに、市場で既に使われている電子機器７３として、スマートデバイスという電子機器７３がある。
スマートデバイスについて簡単に説明する。利用者３の身体にスマートデバイスを直接装着し、体重、体温、血圧、心拍、血糖、血中酸素濃度などの身体の状態を測定する機能を持つ、ネットワークに接続できる機器である。
このスマートデバイスを販売している事業者の中には、外部ネットワーク上にAIシステムを展開している事業者もある。これはスマートデバイスが身体から測定したデータを外部ネットワーク上に設置したサーバーに蓄積し、利用者３の端末を使用してAIシステムに蓄積した測定データを見ることと、AIシステムによる測定データの評価を見ることができる事業者もある。
スマートデバイスの一例としては、衣服状や腕時計状などの形状で体に装着したまま生活が行える、ウェアラブルデバイスなどもある。
本考案では、スマートスピーカーやスマートデバイスの機能では、できないことや、さらに一歩踏み込んだことを考案したものである。

【0175】

本考案では、一般にスマートスピーカーと呼ばれる電子機器７３とその運営事業者のシステムとは別に、ネットワーク上のプラットフォーム型医療機関支援システム１に設置した電子機器利用システム７２を接続することで、以下の基本機能を実現する考案である。実現できる基本機能は、「（１）利用者３との会話により会話の情報を収集する機能」、「（２）収集した会話の情報から利用者３の状態を分析する機能」、「（３）利用者３の状態の分析を行うための会話台本９２を作成する機能」、「（４）分析した情報を利用して利用者３に対し助言を行う機能」、「（５）収集した会話の情報を医療機関４と共有する機能」の５つがある。

【0176】

ここで、本開示の電子機器７３及び電子機器利用システム７２の全体図を図１２に示す。電子機器７３は、利用者宅に設置され、インターネットなどのネットワークを利用して、ネットワーク上のプラットフォーム型医療機関支援システム１上にある電子機器利用システム７２と接続されている。また、電子機器７３及び電子機器利用システム７２は、ネットワークを介して事業者システムや、医療経済圏２４に属する機関などともつながっている。さらに、電子機器７３は、電話機やインターフォン、テレビ受像機などの家庭内にある機器と接続している。電子機器７３と家庭内の機器との接続は、無線LANや有線LANなどの家庭内ネットワークを利用して行う機器もある。

【0177】

前記５つの基本機能は、電子機器利用システム７２上の医療情報共有データベース２の情報を利用して実現している。会話から取得される情報の保存先となるデータベースにフォーカスして説明をする。本考案は、利用者３との会話から様々な情報を取得し、その様々な情報を様々なプロセスを使用することにより利用者３にサービスを提供する情報主導型の事業となっており、
プラットフォーム型医療機関支援システム１には、複数の様々なデータベースで構成されている１つの大きなデータベースとして医療情報共有データベース２が構成されている。この１つの大きな医療情報共有データベース２の中にある複数のデータベースの１つに「利用者音声ＤＢ７１」がある。この「利用者音声ＤＢ７１」には、利用者３とスマートスピーカーとの会話から取得した情報が保存され、この情報を利用してサービスを提供する基本のデータベースになる。
複数の様々なデータベースで構成されている１つの大きなデータベース、いわゆるビッグデータベースである医療情報共有データベース２を利用するのは、医療経済圏２４で事業を行う、「人や医療機関４・企業・事業者」となっており、この利用者３の個人情報２２が医療経済圏データベース（以下、医療経済圏ＤＢ２１）で管理される。
この医療経済圏ＤＢ２１は、医療情報共有データベース２の中にある複数のデータベースと連携している中核のデータベースとなっている。
さらに、医療経済圏ＤＢ２１に保存されている個人情報２２と連携した「利用者音声ＤＢ７１」がある。この利用者音声ＤＢ７１には、利用者３の情報として電子機器７３から取得した様々な情報が保存されている。
電子機器利用システム７２は、電子機器７３から取得した様々な情報を前記利用者音声ＤＢ７１に保存する機能を有している。

【0178】

本開示の医療情報共有データベース２にある利用者音声ＤＢ７１には、会話病状情報と、会話生活情報と、行動補助情報と、会話外出情報の情報が保存されている。
会話病状情報は、利用者３とスマートスピーカーとの会話の内容から病状に関するキーワードを抽出した会話情報である。会話生活情報は、利用者３とスマートスピーカーとの会話の内容から生活状況に関するキーワードを抽出した会話情報である。
行動補助情報は、病状に関するキーワード又は生活状況に関するキーワードから利用者３の状況を分析して、利用者３が行うべき行動内容の情報である。
会話外出情報は、利用者３が外出した外出先や、外出先へ行くまでの所要時間やその移動方法、外出目的や内容、外出先で合った人、外出先で知人との覚えている会話内容、外出先での外食内容、外出時に関して覚えている様々な情報である。
ビッグデータである医療情報共有データベース２と、その中核データベ−スである医療経済圏ＤＢ２１と、それと連携した利用者音声ＤＢ７１を説明した。さらに利用者音声ＤＢ７１にある様々な情報についても説明した。

【0179】

第３実施形態のデータベース構成を図１３に示す。

【0180】

ここで５つの基本機能に話を戻す。ここから、５つの基本機能について順次説明していく。

【0181】

１つ目の基本機能は、利用者３との会話により会話の情報を収集する機能である。これは、電子機器７３と利用者３との会話が複数回リターンする会話のラリーにより、利用者３から聞き出したい答えを会話から導きだすことである。また、電子機器７３は、その会話から必要な答えとなる会話の音声情報を抽出し、医療情報共有データベース２にある利用者音声ＤＢ７１に会話病状情報または会話生活情報へ蓄積していく。
一般にスマートスピーカーと呼ばれる電子機器７３の場合は、利用者３からの質問に対して回答する会話で、すなわち１リターンによる簡単な会話を行うその会話の内容をそのまま保存しているものである。

【0182】

音声から単語認識する方法は、既存技術として特許第６７３３８９１号に記載された技術などが一般に知られている。

【0183】

プラットフォーム型医療機関支援システム１の電子機器７３利用システム７２により、電子機器７３は利用者３と会話が行え、利用者３の自宅に設置した電子機器７３と利用者３との複数回リターンによる会話から会話の要点すなわち欲しかった回答部分の情報のみを抽出しネットワーク上のシステム上（プラットフォーム型医療機関支援システム１上にある電子機器利用システム７２の医療情報共有データベース２）にある利用者音声ＤＢ７１に情報を蓄積する機能となっている。
利用者音声ＤＢ７１上には、会話病状情報と会話生活情報とが保存される。
会話病状情報には、利用者３との会話から、病状況や病状態を知るための会話の内容から要点を抽出した、病状に関する会話の情報を保存し蓄積されている。
会話生活情報には、利用者３との会話から、生活状況や生活状態を知るための会話の内容から要点を抽出した、生活に関する会話の情報を保存し蓄積されている。
病状況や病状態には、体温や血圧といった利用者３が測定を行った測定の結果や頭痛など体調の情報、咳や痰やケガなど発生している症状の情報など、病気自体や病気の症状などに関連する状態または状況、測定に関する情報のことである。
生活状況や生活状態とは、睡眠時間や食事の内容と食べた量、運動の内容、外出内容、一日の出来事、不安な事など、生活に関係する状態または状況に関する情報のことである。
一般にスマートスピーカーと呼ばれている従来の電子機器７３では会話の内容をそのまま保存していた。しかし、本開示の電子機器７３では、電子機器利用システム７２が、会話の中から有意なものを抽出した情報を保存するという明確な違いがある。
従来のホームスピーカーと考案の電子機器の違いを図１４に示す。

【0184】

２つ目の基本機能は、収集した会話の情報から利用者３の状態を分析する機能である。これは、本開示の電子機器７３と接続されたシステム上（プラットフォーム型医療機関支援システム１上にある電子機器利用システム７２の医療情報共有データベース２）にある、利用者音声ＤＢ７１に保存し蓄積された会話の情報と、会話生活情報に保存し蓄積された生活に関する会話の情報の状況とを利用して、利用者３の状況または利用者３の状態を分析する機能となっている。この機能は、電子機器利用システム７２上のプログラムを利用して提供される。
分析する機能とは、利用者３との会話で取得した会話病状情報や会話生活情報などをもとに、利用者３の体調や趣味嗜好、行動パターンなどありとあらゆるものを対象に分析する機能となっている。電子機器利用システム７２が行う分析は、会話病状情報と会話生活情報とを教師データとして利用した機械学習を用いて行う。この機械学習は、会話病状情報と会話生活情報とに保存された情報から相関している情報を見つけ出し、その相関から利用者３の状況または利用者３の状態を算出（分析）する。この際、相関している情報に加え、一般に因果関係があるとされる情報を利用して、利用者３の状況または利用者３の状態の算出（分析）を行ってもよい。
会話病状情報や会話生活情報を利用した分析の例いくつか示す。
例１「血圧データと事の内容と運動内容とを利用した分析」
会話病状情報として過去１週間分の血圧のデータと会話生活情報として過去１週間分の食事の内容と運動内容を取得していたとする。過去１週間分の血圧のうち、１日だけ血圧が高く、血圧が高くなった前日は、普段に比べ塩分が高い食事をとっており、日常生活動作以外の運動を行っていなかった。一般に食事の塩分量や運動内容と血圧とは相関があるとされ、塩分が高い食事や運動不足は血圧が高くなるとされている。このことから、血圧が高くなった原因は、食事と運動不足とが原因であると、電子機器利用システム７２上のＡＩプログラムは分析の算出処理をした。この例は、簡単な例のため人工知能を使わなくとも行える。
例２「生活パターンと症状からの病気の予想」
会話病状情報として３日前にキズの治りが遅いという情報と２日前に疲労感が残っているという情報と、会話生活情報として過去１週間分の食事の内容と運動内容と最近のどがよく渇くという情報とを取得していたとする。過去１週間の食事は、炭水化物などの糖質が多い食事であった。また、日常生活動作以外の運動は行っていなかった。これらの情報を組み合わさると一般に糖尿病を疑うことなる。このため、ＡＩプログラムは、利用者３が糖尿病を患ったのでないかと推定すると同時に、糖尿病が原因でキズの治りが遅く疲労感などの症状が出たと、電子機器利用システム７２上のＡＩプログラムは分析の算出処理をした。
機械学習させた人工知能は、会話病状情報と会話生活情報とに保存された複数の情報を組み合わせ、相関を取ることによって今まで表面化していなかった患者に関する分析の処理をおこう。上記の例１の場合は、血圧と塩分量と運動量との相関を用いており、例２の場合は、糖質の摂取量と運動との相関を用いている。

【0185】

３つ目の基本機能は、利用者３の状態の分析を行うための会話台本９２を作成する機能である。これは、利用者３の状態の分析を行うために必要な情報を、利用者３との会話から得るための会話台本９２を電子機器利用システム７２上にある台本作成プログラムで作成することである。この台本作成プログラムで作製された台本を使用して電子機器７３は利用者３と会話の処理を行い会話の内容から要点を抽出する処理をし、会話の内容が病状に関する会話の場合は、利用者音声ＤＢ７１にある会話病状情報へ、会話の内容が生活に関する会話の場合は、利用者音声ＤＢ７１にある会話生活情報へそれぞれ蓄積する処理がされる。
この台本作成プログラムは、聞き出したい答えを利用者３から聞き出すための会話シナリオをテキスト文章で作成するプログラムである。このプログラムに取得したい内容、すなわち聞き出したい内容の入力を行うと、取得したい内容の回答を会話で取得できる質問の作成を行う。また、本プログラムは、作成した質問に対するいくつかの想定回答を推定し、推定した回答に合わせて会話の展開による質問会話の内容の作成も行う。
前記会話台本９２には、病状会話台本９２と生活会話台本９２とがある。病状会話台本９２は、利用者３の病状況または利用者３の病状態に関係する欲しい回答を聞き出したキーワードの情報である病に関するキーワードの情報を取得し会話病状情報に蓄積することを目的とした会話台本９２である。生活会話台本９２は、利用者３の生活状況または利用者３の生活状態に関係する欲しい回答を聞き出したキーワードの情報である生活に関するキーワードの情報を取得し会話生活情報に蓄積することを目的とした会話台本９２である。作成した病状会話台本９２及び作成した生活会話台本９２は、医療経済圏ＤＢ２１にある会話台本ＤＢ９１に保存される。
本開示の電子機器７３は、前記病状会話台本９２または、前記生活会話台本９２を利用して利用者３と会話を行い、病に関するキーワードの情報または生活に関するキーワードの情報をキーワードの取得に利用した前記会話台本９２に対応する利用者音声ＤＢ７１上にある保存先に保存し蓄積する。すなわち、病に関するキーワードの情報の場合は会話病状情報に、生活に関するキーワードの情報の場合は会話生活情報にそれぞれ保存し蓄積処理をする。
会話台本９２の作成に必要な、取得したい内容の回答を会話で取得できる質問の作成や質問に対するいくつかの想定回答を推定するのに、AI（人工知能）を利用して行ってもよい。AIを利用する場合は、教師データとして、過去の会話台本９２の質問内容とその回答を利用する。この教師データを利用した学習は、質問に対して想定された回答が来た場合、的を射た回答とAＩは学習し、想定外の回答が来た場合、不適切な回答であったとAＩは学習する。このAIは、学習の結果を利用し、的を射た質問を利用して利用者３に対する会話台本９２を作成する。
作成した会話台本９２は、医療経済圏ＤＢ２１にある会話台本ＤＢ９１に保存される。
様々な回答を得るために作製した様々な会話台本９２を使っての会話から回答が取得できその回答が蓄積されていくことから、様々な回答を得る台本とそれに対応した回答の情報が蓄積されていくことになる。このことからチャットボットを利用したＡＩと逆のＡＩを作れることに気が付く。機械学習の用途に回答とその回答を得る台本とを学習させていくことで、チャットボットとは逆のＡＩにより、回答から精度の高い会話台本９２を作製することができるようになる。

【0186】

４つ目の基本機能は、分析した情報を利用して利用者３に対し助言を行う機能である。これは、本開示の電子機器利用システム７２が、ここまで利用者音声ＤＢ７１に保存・蓄積してきた、病状に関するキーワードの情報や、生活に関するキーワード情報が、会話病状情報と、会話生活情報などに保存されている利用者３の情報から利用者３の状況を２つ目の基本機能により分析することがき、分析した状況から利用者３が行うべき行動の情報である行動補助情報を作成する機能である。この行動補助情報が利用者３への助言する内容となる。
例として、利用者３から体温を聞く病状会話台本９２を利用した会話から取得した会話病状情報から利用者３の体温情報と、生活状況を聞く生活会話台本９２を利用した会話から取得した会話生活情報から利用者３の食事の情報とから判断（分析）処理した状況から利用者３が行うべき行動の情報である行動補助情報での具体例を示す。
本開示の電子機器利用システム７２は、利用者３と電子機器７３との会話により利用者３の会話病状情報の体温情報から体温が「３７度５分」であるという情報と、会話生活情報から「食事があまりとれない」という情報とが、取得できたとする。この場合、電子機器利用システム７２は、利用者３が感冒を患ったと判断（分析）処理し、早く寝る感冒薬の服用を促す内容又は翌日も同じ容態ならば医療機関４への受診を促す内容の行動補助情報を作成し保存する。助言をする会話台本９２により利用者３と会話を行い行動補助情報に保存された情報を利用者３に助言として会話で伝える。
このほかにも、体重の変化や睡眠時間の変化、食事の量や、就寝・起床時間のルーティンや、味付けやし好が変わったなどの場合等の、行動補助情報の作成を行う。
作成した行動補助情報は、本開示の電子機器７３を利用した「電子機器７３が利用者３に対して音声による問いかけを行い、会話にて行動補助情報伝える」「電子機器７３上の画面に行動補助情報の画像または映像の表示することにより伝える」「電子機器７３の外部にある機器上の画面に行動補助情報の画像または映像の表示することにより伝える」などの方法を用いて利用者３に伝えることができる。

【0187】

利用者３の行動補助情報に保存された助言は、利用者３本人だけに伝えるものでは無く、一緒にくらす家族や、連絡先が登録されている遠方に住む家族に通知する機能も含まれる。
利用者３の情報を長期に渡って取得しデータベースに保存する構造になっている事から、過去から累積された情報の中から変化点を見つけることが簡単にできる。この変化点が重要な問題を回避することになる。例えば、利用者３との会話から取得した情報から、質問に対して回答する時間（回答までに間のあく時間）が長くなり始めた時期、質問に対して回答内容がズレ始めた時期、知っているはずの簡単な回答を間違えた時期、公知の回答が出てこなくなった時期、外出などの約束を忘れた時期、これらの変化した時期を見つけそれ以降の回答がどうなっていくか総合的に見ていくことができる。そしてこれらの変化は、体力的、年齢的、疲労からくる反応や物忘れ等のことから、記憶障害、単発性記憶障害、老人性記憶障害、認知症初期、様々な事を電子機器利用システム７２は判断処理することができ、医療機関４の医師５ａにデータを送り医師５ａによる医療的判断を仰ぐことができる。結果早期の判定を下せる。現在の社会では、認知症と疑える人は決して一人で病院４ａに診療を受けに来る人は絶対にいない。ほとんどのケースは、家族が認知症を疑い家族に連れられて診療に行くが、その時点では既に認知症の進行は進んでいるのである。
認知症の進行は、緩やかなために短期的には些細な変化しか発生しない。そのため、家族が初期段階で認知症の症状だとわからず、家族は気が付きにくい。家族が気が付いたときには、認知症が進行しており、その進行してしまっている状態で診療に行く事が多いのが現在の社会における間違いとなっている。
早い段階で医療機関４に足を運んでいれば、もっと初期の段階で判定できていれば、早い段階の治療により回復の道はあったかもしれない。本考案では、身近な家族が気が付かなくとも日常の会話から取得した利用者３の情報から変化点を見つけることができ、電子機器利用システム７２が判断処理した結果、医師５ａがデータを診て診断を行うことができ、家族が認知症と分らなくてもシステムが気が付き、医師５ａに知らせることで早期に医師５ａが認知症と疑うことができる。この場合の助言は、家族に対して行うものである。医師５ａは、「病院４ａに検査を受けに来なさい。」という助言を送信することができる。
とても悪い表現になってしまうが、逆の目線で話をすると、医師５ａは電子機器利用システム７２に患者を紹介してもらったと言える。電子機器利用システム７２が、未病者の日常の変化点から患者への移り変わりを捕らえたことになります。
一般に、「ミニメンタルステート検査」や「長谷川式認知症スケール」などを用いて、認知症の診断及び進行状況の検査を診察室で医師５ａが行う。これらの方法は、「自分の生年月日や本日の日付、自宅の住所、出身地など、健康な人なら簡単に答えられる質問に答えるテスト」「いくつかの単語を示し、その後別の作業を行った後、先に示した単語を回答する記憶テスト」「単語を示し、その単語から連想されるものを答えるテスト」などで構成されている。これらの検査方法は、口頭試問で行えるため、本開示の電子機器７３の機能として、日常会話から「ミニメンタルステート検査」や「長谷川式認知症スケール」と同等のことが診察室では無く、診察室から離れた利用者３の自宅で電子機器利用システム７２の会話で行える機能があってもよい。この同等のテストも台本作成プログラムで予め作製した会話台本９２を使用することができる。さらにこのシステムでは、診察室やリモート診察のような１：１の診察では無く、診察室と電子機器利用システム７２を経由した利用者宅に居る利用者３との回答したデータを使用した非同期の状態の１:Nによる複数の利用者３のデータを診察ができる。
例えば、夕食の内容を食事の後と翌朝の２回質問して記憶しているかの確認を行う。利用者３の故郷で桜の開花などがあった場合、会話台本９２を利用して「XXさんの故郷で桜が咲きました」と言って、その回答から故郷につながるとなる言葉が回答されるかの回答を行う。故郷につながる言葉での判断の場合、回答が出身地の地方名や地名などが回答されれば正常と判断し、出身地の地方名や地名とは違う場所の名称が回答されれば疑いがあると判断する。
特に利用者３が、「病気では無い未病者」や「健康を意識している未病者」、「将来の病気や生活に不安を感じる人」の場合、このようなサービスを望む利用者３は多いと考える。定期的に検査を実施する処理を組むこともできる。こういった生活上の会話データから初期診断するものは今までになかった発想の診療システムであり新しいサービスのビジネスモデルである。
会話を利用した認知症診断支援システムとして、特許第６７３３８９１号に記載された技術などがある。この技術は、ミニメンタルステート検査の代わりに医師５ａとの自由会話で認知症の診断支援を行うとしている。「医師５ａとの会話」すなわち病院４ａに行かなければ検査が行えることと、文章ベクトルや単語ベクトルによる学習査定を行い判定している。
一方、本開示で示した方法は、日常会話の中で、利用者３の会話情報を長いスパンで長期に渡って取得しているデータベースから様々なことの変化していく変化点を見つけることで認知症への道を早期に疑うことができること。すなわち病院４ａに行かなくとも長いスパンで認知症診断のサポートが行える技術となっている。
また、病気になりたく無いと健康意識の高い人や、満足に人生を終えたいと考えている人に疑いが出た場合は、早期の段階で、ベータアミロイド検査や血液検査で老化が始まった確認と対策を始められ、ＰＥＴなどで脳の血流を測定検査することでも早期認知症対策検査の推奨を医師５ａの判断でしてもらうことができる。健康をマネージする担当医師は、利用者３の希望に沿った対策のサービスをすることができる。
食事においても早期発見ができる。食事に対する質問の回答から「食事がまずい」「おいしくない」「妻や嫁の作った食事はまずい」妻や嫁の悪口のような回答が出てくるようになった場合は、「味覚が悪くなっている」「妻や嫁の不満」と判断した処理結果が出すこともできる。
また、外出時間においても発見することができる。普段生活用品や食材を買いにいくスーパーから自宅に戻るまでの移動時間（歩行所要時間）が、ある時期から時間がかかるようになったなどの変化を見つけた処理をした場合、医師５ａにデータの変化点を提示する処理を行い「老化による体力不足で歩行時間がかかるようになった」、「初期段階の認知症又は突発性記憶障害などにより帰り道を一瞬間違えて遠回りして帰宅している」などと医師５ａは疑うことができる。

【0188】

利用者３へ話しかけにより会話中から取得した外出内容が会話外出情報として利用者音声ＤＢ７１に保存し蓄積されている。
この会話外出情報には、会話の内容から、外出の所要時間や移動方法や知人との会話や外食などの外出に関連する様々な情報が含まれており、過去からの推移として医療機関４と情報を共有する事もできる。本開示の電子機器利用システム７２には前記会話外出情報に含まれる外出に関する情報を利用することにより、運動量や食事や病状や精神状態など「医療と健康管理」の２つの側面で分析する事もできる。この分析は、利用者３の出の所要時間や移動方法や知人との会話や外食などの外出に関連する様々な情報を用いて相関を見つけることにより行われる。
たとえば、意味もなく恒常的に特定の場所を通って散歩をしていると、本開示の電子機器利用システム７２が判断した場合、痴呆による徘徊の疑いがあると判断処理し、医療機関４と情報を共有するなど行う。
会話外出情報から外出内容を取得することにより、利用者３の行動範囲や面会相手などがわかり、利用者３の行動能力や外出傾向などを推定することがきる。本開示の電子機器利用システム７２は、長いスパンで長期に渡って外出内容を保存し続け取得することにより、行動能力や外出傾向の変化などの傾向も把握することができる。行動能力や外出傾向が変化を電子機器利用システム７２が把握した場合は、理由を聞く会話台本９２を作製して利用者３に会話で問うこともできる。

【0189】

利用者３が外出中に話した内容や外出中での行動は、外出中情報として、利用者音声ＤＢ７１に保存処理し蓄積する。たとえば、車の運転の場合、外出中情報には、車での外出先の情報、運転中に発した言葉、車を急発進または急制動させた回数、衝突被害軽減ブレーキ（AEBS）を発動させた回数、法定速度を著しく逸脱した速度で運転した回数などが含まれる。車の場合、これらの情報は、AIが搭載できるまたは搭載されているカーナビゲーションシステムやモバイル端末と連携することによりAIが使用できるカーナビゲーションシステムにより取得できる。
現行の車両には、前記で説明したAndroid Automotive（商標）や、Apple CarPlay（登録商標）といった、AIが搭載されているカーナビゲーションシステムやモバイル端末と連携することができるものとなっており、利用者３（運転者）側からＡＩへの質問や依頼は、車両の無線通信を通じて事業者側のＡＩによる処理が利用者３へ伝わるようになっている。例えば、利用者３が「この近くのレストランを教えて」と質問すると、事業者にあるＡＩが反応しレストラン名を利用者３の運転している車両のディスプレーに表示処理される。この機能を使えば、家庭に設置する電子機器７３と全く同様に、利用者３から音声による情報を入手することは可能である。また、利用者３の音声だけでなく、車両に搭載されたナビゲーションシステムに設置されている各種センサーからの情報も取得することが可能となる。
本開示の電子機器利用システム７２は、取得した外出中情報を組み合わせることにより、車の運転者（利用者３）の体の状態が推測でき、認知症などの早期発見や体の衰えに起因する事故の防止などに役立つ。
認知症などの早期発見は、運転中に無意識に発する言葉の変化などを用いて行う。認知症の患者は、認知症発症後に性格が攻撃的に変化することが多い。そのため、外出中情報の１つである、運転中に発した言葉を利用することにより認知症発症の推定ができ、運転中に攻撃的な言葉をあまり発しなかった運転者が、攻撃的な言葉を言う回数が増えている場合、認知症を疑うことができる。
また、高齢運転者は、加齢に伴う運動機能の低下による操作ミスや認知機能の低下による標識等の見落としなどもある。加齢に伴う運動機能の低下による操作ミスや認知機能の低下による標識等の見落としが発生すると、「アクセルとブレーキの踏み間違い」「道路の逆走」といった行動を起こす場合がある。「アクセルとブレーキの踏み間違い」「道路の逆走」などは、交通事故の原因となる。加齢に伴う運動機能の低下による操作ミスや認知機能の低下が発生した段階で運転すること止める、すなわち運転免許の返納を行えば、事故を未然に防ぐことができる。加齢に伴う運動機能の低下による操作ミスや認知機能の低下を見つけ出す方法として、外出中情報に含まれる車を急発進または急制動させた回数、AEBSを発動させた回数などを利用する。急発進または急制動させた回数やAEBSを発動させた回数が多い場合の原因は、「脳が事象の発生の認知まで時間がかかり、結果として実際に反応するまでに時間がかかる」、「脳が事象の発生の認知は正常に行えているが、運動機能の低下により反応するまでに時間がかかる」の２つに分けられ、前者は認知機能の低下、後者は運動機能の低下が原因となる。外出中情報を利用すると、急発進または急制動させた回数などの発生回数の変化から認知機能の低下や運動機能の低下が発生していることを推定することができる。過去からの情報を蓄積し続けることで、変化が分り行動や能力の低下の推定がわかるようになる。
認知症を疑いや認知機能の低下の推定、運動機能の低下の推定の結果を利用者３本人に伝えたたしても、運転をやめるとは限らない。そこで、本開示の電子機器利用システム７２は、利用者３の家族に対して、認知症を疑いや認知機能の低下の推定、運動機能の低下の推定の結果を通知する処理も行う。
本開示の機能を利用して運転をやめることを促すことにより、「２０１９年４月に東京都豊島区で８０代男性が発生させた車両暴走事故」「２０１２年１０月に静岡県内の東名高速道路上で９０代男性が発生させた車両逆走事件」などの事故や事件が無くなることが期待できる。２０１９年の事故は、運転手７の操作ミスが原因であると推定されており、２０１２年の事件は、認知能力の低下が原因とされている。

【0190】

電子機器７３から利用者３へ話しかけるには、利用者３が自宅に居ない不在時又は誰も居ない時に話しかけても意味が無い。電子機器７３は、利用者３が居ると判断した時にのみ話しかけることができる。電子機器７３は利用者３が自宅に居るか居ないか、外出から戻ったかを自動で判断処理する必要がある。この判断方法に、利用者３が所持している携帯端末の無線信号を使った接続状態を利用する。
利用者３が所持している携帯端末と本開示の電子機器７３とが直接の無線信号で接続されている状態（ペアリンク）の時は利用者３が滞在していると電子機器７３は判断し、携帯端末と電子機器７３とが無線信号で接続されていた状態から切断状態へと切り替わった時に利用者３が外出したと電子機器７３は判断し、携帯端末と本開示の電子機器７３とが無線信号で切断されている状態から接続状態へと切り替わった時に利用者３が外出から戻ったと電子機器７３は判断処理をする。
さらに接続（ペアリンク）の方法には、電子機器７３と携帯端末とが他の機器を介さず直接通信するなどの電子機器７３と利用者３が所持している携帯端末との直接的な接続の他に、家庭内ネットワークを利用した間接的な接続によることも有する。利用者３が在宅中か外出中の判断の方法や、利用者３が外出から帰宅したかの判断の方法は、あくまで一例であり、電子機器７３が直接または間接的に取得できる情報で判断処理を行う別な方法でも構わない。

【0191】

５つめの機能である、収集した会話の情報を医療機関４と共有する機能は、利用者音声ＤＢ７１に保存し蓄積してきた、病状に関するキーワードの情報や会話生活情報、会話病状情報、会話生活情報などの情報は、本開示の電子機器利用システム７２に接続している医療機関４の端末が利用者音声ＤＢ７１内の情報の参照または取得するにより、医療機関４と情報共有することもできる。
医療機関４と情報共有する情報は、会話台本９２により作成したシナリオで利用者３から聞き出した、食事内容や運動状況や起床時間や就寝時間や体調や体重や体脂肪率や血圧や体温や持病の状態等の情報で、利用者音声ＤＢ７１の会話生活情報または会話病状情報のうち前記会話台本９２に対応した保存先に保存し蓄積されている情報となっている。
利用者音声ＤＢ７１内の情報を医療機関４と共有することにより、医師５ａは、利用者３の日常の生活状況や血圧などの測定結果の変化状況を見ることができ、治療などに役立てることもできる。
起床時間や就寝時間や体調や体重や体脂肪率や血圧や体温などの数値データの場合は、予め閾値を設定しておき、取得した値が、閾値を超えた場合に値を医療機関４と共有してもよい。閾値は、明示された値ではなく、会話生活情報または会話病状情報に保存された過去からの連続した値の推移と取得した値に特異的な差異としてもよい。ここで言う、特異的な差異とは、「正常値内ではあるが、日常の値と乖離している（図１５の矢印で示した値など、血圧の値が普段は、正常値内のうち高値だが、測定値は、正常値内のうち低値など）」「測定値の変化が、右下がりに減少する形で減少していいたが、減少から大幅に減少すぎる値となっている（ダイエット中に体重が、右下がりに減少する形で減少していいたが、右下がりに減少する値が逸脱した値となった）」などのことを示す。
例として、体重が、右下がりに減少する形で減っていいたが、右下がりに減少する値が基準値より逸脱した値となった例を図１６に示す。図の矢印で示した点の直前までは右肩下がりの減少で減量していた。しかし図の矢印で示した点では、大きく減少する値が基準値より外れた値となった。
利用者３の日常測定値を治療に役立てる例として血圧を例に説明する。自宅で測定した血圧より、医療機関４で測定してもらうと血圧が高くなることがある。このような場合、従来は、医療機関４で測定した通常より高い血圧を用いて治療を行うことが多かった。そこで、日常の血圧を把握するために、血圧手帳を利用して把握する方法が用いられている。
利用者３の日常の測定値が電子カルテ９ａを経由して確認することができる。

【0192】

医療機関４と情報共有の結果、医療機関４が利用者３に対し、前記利用者３の会話生活情報または会話病状情報を利用した前記調査から利用者３に問題と思われる部分があり利用者３へ改善を促す事を伝えたい場合、会話台本９２を利用して、利用者３に改善を促す内容の連絡を行うこともできる。
例えば、医師５ａが利用者３へ治療に関するアドバイスを行う場合や、看護師５ｂが季節の変化による生活上の注意点などを連絡や栄養士が患者の病状を考慮した季節ごとのおすすめの食材（例えば、夏バテ防止に鰻や豚肉を食べること勧める）の連絡、などに用いる。
この連絡は、医療機関４が任意のタイミングで行え、利用者３が、電子機器７３近傍に居なくても行うことができる。
利用者３が電子機器７３近傍に居ない場合は、利用者３が電子機器７３近傍に居るタイミングで又は利用者３が外出から戻ったと認識できた時点で、利用者３に対して会話で伝える処理をする。また、同改善が複数利用者３又は複数患者までに及ぶ改善を促す内容を伝える連絡の場合も、患者や利用者３の都合に関係なく連絡を伝える処理を行い、電子機器７３が自宅に利用者３が居ると判断する処理をした時に電子機器７３が会話で伝える処理ができることになるが、これは全ての利用者３や患者は非同期で行われる。複数の対象者に対して医師５ａが内容を伝えられることは、遠隔リモート診療ではできないことである。いわゆる医師５ａが利用者３へ一斉に会話で伝える処理をした場合は、利用者３全員が自宅にいれば一斉に同期した形で会話が伝わるが、一部の利用者３が不在の場合は利用者３の帰宅が確認されて会話が伝わるために非同期で伝わることになる。
電子機器７３を利用して、医療機関４が利用者３を呼び出すことを、会話台本９２を作成し電子機器７３を利用して連絡してもよい。
会話台本プログラムで作成した台本を利用し、電子機器７３を用いた、医療従事者５と利用者３との会話の例を図１７に示す。

【0193】

医療機関４と情報を共有する機能は、現在病気を患っていない利用者３の健康管理や、未病の状態を維持することにも役立つ。医療機関４にとっては、健康な利用者３の健康管理と健康維持を行うことにより、病院４ａに無縁であった、健康な利用者３という新しい利用者３（顧客）の開拓につながっていく。

【0194】

本開示のプラットフォーム型医療機関支援システム１にある電子機器利用システム７２には、本考案の電子機器７３の処理を補う様々なプログラムがある。その中でも、本考案の電子機器７３が、外部の機器や外部のシステム、外部のプログラムと連携する機能を有しており、この連携機能は、ＡＰＩ（Application Programming Interface）を用いて行ってもよい。このＡＰＩは、電子機器７３または、電子機器７３と接続した外部ネットワーク上の電子機器利用システム７２のサーバーの少なくともどちらかで動作すればよい。

【0195】

本開示の電子機器７３の基本機能を利用することにより、医療機関４は、５つの基本機能に加え、次の５つの拡張機能、「（１）取得情報を利用した助言機能」「（２）購入支援機能」「（３）服薬状況管理機能」「（４）防犯対応機能」「（５）利用者安否確認機能」を提供することができる。
各拡張機能について順次説明する。

【0196】

（１）取得情報を利用した助言機能
本開示の電子機器７３は、利用者３との会話により情報のやり取りを行うほかにも、電子機器７３は自身が持つセンサーなどの入力デバイスにより取得した情報やネットワーク上の機器から取得した情報、外部ネットワークから取得した情報などを基に利用者３に対して、適切な生活環境に導く助言を行うこともできる。電子機器利用システム７２は、取得した情報を基に助言を行う処理を行うことにより、早期に必要な助言を行う処理が行えることが期待され、利用者３が大事（病気など）になる前に、又は利用者３が病院４ａへ行こうと意識が傾く前に対応が行えることが期待される。利用者３に対する助言の実施方法は、利用者３と電子機器７３との会話により行われ、会話台本９２を利用した会話で行ってもよい。ここでは、利用者３と電子機器７３との会話により伝えるとしたが、電子機器７３上の画面に内容を表示する方法やテレビ受像機などの電子機器７３と接続されている外部の機器を用いて画面に内容を表示する方法でもよい。

【0197】

本開示では、「電子機器７３が取得した外気温と室温とを用いて助言を行う手法」と「電子機器７３が取得した音声を用いて助言を行う手法」との２つ手法を開示する。

【0198】

「電子機器７３が取得した外気温と室温とを用いて助言を行う手法」は、外気温情報と利用者宅内の室温情報との２種類の温度を取得し、取得した２種類の温度の温度差を算出し、この算出した温度差を利用し電子機器７３を用いて助言を行う。外気温情報の取得は、電子機器７３又は電子機器利用システム７２のいずれかが、気象庁データベースなど公衆に公開されたシステムから、利用者３が住んでいる地域の外気温を自動的に取得することにより行う。室温情報は、家庭内ネットワークを利用して外部の室温が測定できる機器や電子機器自体が持つ温度測定機能を用いて取得を行う。
本開示の電子機器利用システム７２は、取得した２つの温度差を算出し、取得した温度及び温度差による、生活上好ましくない環境（悪環境）となっていないかの判断処理を行う。
例えば、「夏季に外気温と室温の差が少なく、室温が高温となっているため、熱中症の懸念される状況の場合」や「冬季に外気温と室温の差が少なく、室温が低温となっているため、低体温症の懸念される状況の場合」など、自宅内での生活環境が悪環境となっており、悪環境で生活をしていると判定処理をする。
悪環境で生活をしている場合、電子機器７３は、適切な生活環境になるように調整するように自動で助言を行う処理をする。
助言を行う処理の例として、外気温と室内温との温度差より室温が高い場合は、「冷房機器を利用するよう促す」「部屋に日光を入れないようカーテンを閉める」「冷たい飲み物や食べ物を進める」など助言し、室温が低い場合は、「一枚厚着をするように勧める」、「暖房機器を利用するよう促す」、「体が温まる飲み物や食べ物を進める」をなどがある。ここでいう、適切な生活環境とは、一般に冷暖房がいらないとされる室温は、１５度から２５度のことを示す。特に、利用者３が認知症又はそれに近い症状を患わっている場合、室温の変化を感じず寒くても暑くてもそのままでいる傾向や、室内の着衣のまま外に出てしまう傾向が多いため、本考案による注意喚起を促す必要性がある。
ここまで、夏季や冬季において、外気温と室温との差が小さいことが原因でおこった悪環境を用いて説明した。夏季や冬季だけでなく、春季や秋季を含め、外気温と室温との差が大きい、または小さいことによる悪環境がおきている場合も、適切な生活環境助言を行う対象に含む。

【0199】

上記の説明においては、外気温と室温との差よる悪環境となっている場合に、電子機器７３が会話で助言を行うとした。しかし、利用者３が外出していれば、利用者宅内が悪環境となっても、害がないため助言を行う必要はない。
また、電子機器システムが悪環境と判断した場合において、電子機器７３と接続した家庭内ネットワーク上の機器を利用することにより悪環境が改善され、適切な生活環境にできる場合、助言なしに家庭内ネットワーク上の機器を動作させ、適切な生活環境に導いてもよい。

【0200】

「電子機器７３が取得した音声を用いて助言を行う手法」は、利用者音声ＤＢ７１上の会話病状情報と会話生活情報とに蓄積されている過去から現在までの日常の生活に関する会話の情報と直近に取得した利用者３の会話生活情報にある生活に関する会話の情報とを利用して比較し、比較の結果を利用して電子機器利用システム７２は電子機器７３を用いて助言する処理を行う。
本開示の電子機器利用システム７２は、利用者音声ＤＢ７１上にある日常の音声情報と直近に取得した利用者３の音声情報とを比較し、「音声ピッチが日常とは違う」「声量が日常とは違う」「話はじめる間が日常とは違う」「会話中の質問に対する回答がちぐはぐで、日常の回答とは違う」「居るのに回答が無い（無視又は聞こえていない）」など、利用者３の様子の変化や体調変化があると電子機器利用システム７２が判断した場合、適切な生活環境に導く助言の処理を行う。
特に「居るのに回答が無い（無視又は聞こえていない）」等の情報があった場合は、同じことが起きているか監視することで、発生・発症の間隔から病状の疑いのフラグをたてることで医療機関４と共有して管理していくことが可能となる。
電子機器７３が「声量が日常とは違い声がかすれている」判断した処理をしたとする。この場合において電子機器７３が行う適切な生活環境に導く助言の例は、「うがいなどで喉を潤すことを促す」「喉を潤しても改善しない場合、医療機関４への受診を促す」などがある。
さらに「体調を改めて聞く」など絞り込む場合もある。

【0201】

最初に「認知症」に関して社会の状況を説明すると、単身で生活している人は、認知症は身体に痛みなどの症状が出るものでないため自分が認知症になったと気が付かないことから、医療機関４に診察に行かずに一生を終えます。認知症が進行すると攻撃的な発言や態度を示すようになり周囲の人から「あの人は認知症に違いない」と思われ、避けられ、そういったことに気が付かずに人生を終えていくことになります。
また、家族と住んでいる場合、家族全員が対象者を「認知症ではないか？」と疑わない限り対象者を医療機関４に診察に連れて行かないケースがとても多いです。この場合、対象者を家族が医療機関４に診察に連れて行っても、既に対象者の病状は進行しています。いわゆる認知症になり始めた時を見逃してしまい、認知症の進行が進んでしまってから医療機関４で診療を始めることが、この病気における現代社会で今行われている状況です。
また、医師５ａの前で診察が始まっても、対象者は自分で自分の病状を説明できません、家族が対象者の病状を医師５ａに説明しますが、その説明は家族の目に見えている部分の説明しかできず、目に見えてない部分の詳細を説明することはできません。理想は、対象者の変化など目に見えない変化に気付き注意してみていく、そして早期に診療を始めることが回復の道になると感じています。本考案は生活上の会話データから変化点を見つけ早期に医療機関４へ足を運ばせる、そして医療機関４の医師５ａは提供する日常データの詳細を診て早期に診療を始められることができる電子機器利用システム７２になっています。電子機器利用システム７２が日常生活のデータから病状への始まりを見守る事となる。
長期的なスパンで、利用者音声ＤＢ７１上にある日常の音声情報を取得することで、日常では気が付きにくい認知症の発症を早期に推察することもできる。
利用者３の周りの人は、直感的に直近（数日から数週間程度）の音声と比較することはできる。しかし、認知症の場合は、進行が穏やかに進行することが多く、数週間程度では音声の内容の差異が小さく、変化に気が付くことが難しい。
本開示のシステムの場合は、会話から取得したデータさえあれば、任意の期間（例えば、数年前のデータ）と現在のデータとで比較でき、音声の内容の差異に気が付くことができる。また、連続的（毎日や毎週）なデータを比較することより、些細な変化から発生したかなどもわかるため、早期に変化に気が付くこともできる。

【0202】

電子機器７３が利用者３に対して適切な生活環境に導く助言を行ったとしても、利用者３が対応を行わなければ意味がない。また、熱中症などの理由により利用者３が家庭内で倒れている場合など、助言に対して対応や反応が行えない場合も想定される。
そのため、本開示の電子機器７３が利用者３に対して行った助言を、利用者３が行わない場合や対応を行っても改善しない場合、最悪の事態も想定し、利用者３に異常があると電子機器利用システム７２が判断し、電子機器利用システム７２は、システム内に予め保存してある通知先（緊急時連絡先）に通知する機能があってもよい。

【0203】

（２）購入支援機能
本開示の電子機器利用システム７２には、医療情報共有データベース２上の決済関係ＤＢ１０１に蓄積されている買物履歴情報を利用して電子機器７３を介して利用者３に買い物支援を行う機能を有している。
決済関係ＤＢ１０１への買物履歴情報の蓄積は、電子機器利用システム７２を利用した購入した購入履歴や医療経済圏２４で利用できるプラットフォーム型医療機関支援システム１にある医療機関決済支援システム１０２のキャッシュレスシステム１０３を利用した際の購入履歴が保存され蓄積されている。この情報を解析して利用者３への買い物支援を電子機器利用システム７２が電子機器７３を介して行われることである。
電子機器利用システム７２を利用した購入とは、利用者３が電子機器７３との会話により、商品を購入する方法で、一般にスマートスピーカーと呼ばれる電子機器７３の機能の１つである。
医療機関決済支援システム１０２のキャッシュレスシステム１０３を利用した購入とは、医療機関４で発行した医療決済媒体や生体情報などを用いて買い物を行う方法で、後述する第４実施形態に記載の手法のことを示す。第４実施形態に詳細が記載されているため、本項では説明を割愛する。
医療決済媒体とは、保険証や診察カード、利用者３が所要する端末などを用いて医療機関４などの決済を行うための決済用端末のことで、医療機関４で保険証や診察カード、利用者３が所要する端末などと紐づけることにより発行されるものとなっている。
本考案では、利用者３への購入支援内容を決める事が重要な機能であり特徴である。

【0204】

電子機器利用システム７２は、決済関係ＤＢ１０１に蓄積された買物履歴情報から様々な情報を取得し、別途設定してある条件情報により様々な支援処理が行える。
利用者３へ通知する機能として、買物履歴情報から消耗品に相当するアイテムの情報を取得し、利用者３が消耗品を購入する頻度から利用者３が消耗品を消耗する消耗時期を算出し、消耗時期の直前に利用者３に消耗品が消耗時期であることを通知する処理を行う。消耗時期は、利用者３の家族構成やし好によってそれぞれ違うため、利用者３の消耗品に対する消耗時期の情報を医療情報共有データベース２の消耗時期情報ＤＢ１１１に保存する。
「消耗品の消耗時期を算出し、消耗時期の直前に利用者３に消耗時期であることを通知する」「商品の重量や何度も購入する商品の購入時期を利用者３に知らせる」「季節に販売される商品等の利用者３にとって季節毎に買っていた商品が販売されるようになった事を利用者３に知らせる」「利用者３に購入を抑制すべきものがある場合、その情報を利用者３に知らせる」などの通知する支援を行う。
利用者３へ購入機能（利用者３への購入をサポートする機能）として、
利用者３が高齢者の場合、生活する上での消耗品で定期的に購入しているが遠方まで移動しないと購入できない物、食生活上の消耗品で高齢者が持ち帰るには重量があり負担となる物、生活上の消耗品で高齢者が持ち帰るには大きくて持ち運びに負担のかかるもの、このような消耗する品で大きさ・重量・入荷未定品等に関して従来の購入間隔から消耗時期を算出することができる、電子機器利用システム７２の消耗時期算出システム１１２を用いて算出処理をし、電子機器７３を利用して会話で購入する機能を有している。消耗時期算出システム１１２の構成を図１８に示す。
この際の支援内容は、利用者３の状態を考慮した条件情報を利用して決める。
条件情報とは、医療情報共有データベース２上にある、利用者３が罹患している疾病の情報や家族構成の情報などをもとに利用者３毎に設定している買い物の条件のことを示す。
重たい物の購入例を記載する。利用者３の購入履歴から白米５Kgを購入していることがわかる。さらにこのお米はだいたい3カ月サイクルで購入していることが購入履歴からサーチすることができる。電子機器利用システム７２は、利用者３の年齢と運動量や健康状態や病状から店舗での購入では無く電子機器利用システム７２を通じた購入に切り替えた方が良いとの判断処理をした場合は、利用者３へその旨の助言の処理を行う。利用者３が助言に応じた場合は、電子機器利用システム７２を利用した購入を消費が来た頃に会話で購入を行い、自宅まで届けてもらえるようになる。
電子機器７３を利用した購入の例を図１９に示す。

【0205】

購入支援機能として開示した技術は、本出願人の特許である特許第６６７１６０９号に記載の機能を拡張した機能でもある。この技術は、利用者３の生活状態や買い物履歴などを取得し健康状態について改善が必要であると推定した場合、ヘルパー・介護者等の支援者に通知する技術である。

【0206】

（３）服薬状況管理機能
本開示の電子機器利用システム７２には、医療情報共有データベース２上の服薬管理ＤＢ１２１を利用することにより、利用者３が服薬したかどうかの情報である服薬状況を知ることができ、服薬の習慣付けや、残薬量から次回処方量の調整などを行うことができる。それにより利用者３の処方薬費用を減らすことができる。

【0207】

利用者３の服薬状況の取得は、服薬状況を知るための会話台本９２を使用して、電子機器７３と利用者３との会話で服薬の状況を所得し、取得した情報を活かして助言する処理をおこなう機能の電子機器利用システム７２である。
会話台本９２により取得した利用者３の服薬状況の情報は、服薬状況情報として医療情報共有データベース２上の服薬管理ＤＢ１２１に保存し、記録保管される。服薬状況の情報を取得するための会話は、１日１回や、服薬のタイミング毎や、次回通院日の直前など、定期的に行うほか、医療機関４などが指定した種々の条件によるタイミングで行ってもよい。確認の例を図２０に示す。
電子機器利用システム７２は、取得した服薬状況の情報を基に、利用者３が正しく薬を服用しているか確認し、服薬忘れが多い場合、電子機器利用システム７２が作成した服薬を促す内容の会話台本９２である服薬習慣台本を用いて、定期的または、不定期に患者に対して服薬するよう助言する処理を行う。
定期または不定期に服薬状況を確認すること、前記確認の結果、服薬し忘れが多い場合に助言する処理を行うことで、服薬の習慣付けや服薬し忘れの防止につながることが期待できる。

【0208】

前記では、服薬したかどうかの情報を確認したが、
次回の定期通院前に、前回処方された薬の残薬量の確認（棚卸）を行い、処方時に服薬忘れた在庫分から差し引きした処方される薬の量（処方量）で薬代を下げる事を目的とした機能の電子機器利用システム７２である。
次回通院日の直前などにおいては、残薬量の確認を会話台本９２により行い、利用者３から取得した残薬量の情報を残薬情報として、服薬管理ＤＢ１２１に保存し、記録保管してもよい。残薬量を確認するここにより、薬の服薬状況が正しいかどうかの確認が行える。また、服薬状況や残薬量が分かれば、次回診察における処方時に服薬状況や残薬量に合わせて処方される薬の量（処方量）を調整することができる。
次回診察における処方時に服薬状況や残薬量に合わせて薬の量を調整するには、服薬管理ＤＢ１２１に保管された情報を病院４ａや薬局４ｂなどの医療機関４の情報システムが参照する又は、服薬管理ＤＢ１２１に保管された情報を医療機関４の情報システムに送信するなどして医療機関４の情報システムと前記電子機器利用システム７２との間で連携すれば行える。
服薬状況や残薬量を医療機関４が把握することで、処方量の調整が行えるとしたが、この結果、利用者３が病院４ａや薬局４ｂに支払う薬の処方費用の削減と健保の負担軽減が行える。また、服薬状況や残薬量を医療機関４が把握することで、患者への治療の参考にもできる。
例えば、薬の飲み忘れが多く、診察結果や検査結果が芳しくない場合は、薬の飲み忘れが、芳しくない要因の１つではないか推察が行える。健忘症などが発症し初めて忘れる場合も考えられる。
医師５ａが使用する医療情報システム９（電子カルテ処方システム９ｅ）において、残薬量の表示または自動で処方される量に残薬量を加味して再計算する処理もできる。
服薬状況や残薬量に合わせて薬の量を調整方法について簡単な例を挙げる。
例えば、利用者３には、４週間分の薬が処方されていたとする。服薬状況や残薬量の確認する処理を行うと１週間分の飲み忘れがあり、１週間分の薬が余っていることがわかった。次回診察時に、医師５ａが同じ薬を４週間分処方しようとすると、本システムは、残薬量を考慮し、３週間分の処方でいいと判断の処理を行い、医師５ａに対して３週間分の処方でいいことを医療機関４の情報システムを利用して伝える処理を行う。この時に、医師５ａが既に残薬量を考慮して処方を行っている場合もある。このため、次回診察日の情報を別途取得し、次回診察日を考慮して、処方量の調整を行ってもよい。例えば、前記例の場合、次回診察が４週間後の場合は、医師５ａが考慮していないと判断し、３週間分の処方でいい旨を連絡するが、次回診察が５週間後の場合は、医師５ａが考慮したとして、処方量を調整する連絡をおこなわない。

【0209】

処方時に残薬量を加味して再計算を行うことには、薬局４ｂにとっても利点がある。
薬の調剤を行う際、以下の３ステップの内容で行われている。
（１）処方された薬が患者に使用して問題ないか確認を行う
これは、「過去に副作用が発生した薬ではないか」「既に服用している薬と相性が悪い薬ではないか」「同じ薬効や同一成分の薬が複数の医療機関４から処方されてないか」「医師５ａから指示された用法用量が薬の使い方として正しいか」などの確認のことである。
（２）薬の調剤を行う
個包装された薬の場合は、収納棚から取り出すだけで終わる。しかし、バルク提供されている薬や複数の薬を混ぜて提供する薬、錠剤を割って提供する薬などの場合、医師５ａから指示に合わせて計量し混合などの作業を行って調剤を行う。また、患者などの要望によっては、１回に飲む複数の錠剤やカプセル剤を１回分ずつに梱包して調剤を行っている。
（３）薬の調剤が正しく行われたかの確認を行う
個包装の薬の場合は、数を数える作業であり、シート単位の数と１シート以下の半端の数を合計して行うため、比較的簡単に行える。しかし、バルク提供されている薬や複数の薬を混ぜて提供する薬の場合、計量結果などを照合して、出来上がった量や個数を確認するなどして行っている。１回に飲む複数の錠剤やカプセル剤を１回分ずつに梱包して調剤する場合、各梱包内の薬の種類を数が正しいかまで確認を行う。
この３ステップのうち、２及び３のステップは、薬の量や種類が増えれば増えるほど時間がかかる。このため、処方される薬の量が減ることにより、調剤に要する時間が減るため、薬局４ｂにとってメリットがあると言える。
また、従来、薬局４ｂで行っていた残薬調整業務に要する時間の削減にもつながる。残薬調整は、薬局４ｂの薬剤師が患者から残薬量を確認し、余っている薬の量に合わせて処方量を減らすことで行われる。残薬調整を行うには、処方箋に残薬調整を行っていい旨の記載があるか、医療機関４に疑義紹介という連絡を行う必要がある。処方箋に残薬調整を行っていい旨の記載あった場合は、調剤前に医療機関４へ連絡を行う必要はないが、調剤後に報告する必要がある。
残薬調整を行うと、調剤の前後の差はあるが医療機関４への連絡が必要なため薬局４ｂにおける業務時間を使ってしまう。処方時に残薬量を加味して再計算することは、残薬調整業務に要する時間が無くなるので、この点においても薬局４ｂにとってメリットがあると言える。

【0210】

（４）防犯対応機能
本開示の電子機器利用システム７２には、医療情報共有データベース２上の防犯ＤＢ１３１にある様々情報を利用することにより、来訪者の画像や音声、電話の相手の音声から相手が犯罪に関係している人かを判定処理し、電子機器７３を用いて防犯対応の助言する処理を行う機能を有している。

【0211】

防犯ＤＢ１３１には、「犯罪者等の顔写真情報」「犯罪者等の音声情報」「犯罪に関連するキーワード情報」の防犯に関する様々な情報が、防犯ＤＢ１３１に保存されており、これらのうち少なくとも１つを利用して防犯対応の助言する処理を行う。犯罪者等の顔写真情報とは、過去に犯罪を起こしたもしくは、犯罪に加担した人の顔写真のことを示す。犯罪者等の音声情報とは、過去に犯罪を起こしたもしくは、犯罪に加担した人の音声情報のことを示す。犯罪に関連するキーワード情報とは、特殊詐欺に頻繁に用いられるワードや、悪質な訪問販売や悪質な電話による通信販売に頻繁に用いられるワードのことを示し、「XX銀行の者です」「〇〇役所から来ました」「〇〇消防署の方から来ました」「〇〇水道局の方から来ました」「ガスの定期検診」「XXの集金」などのことを示す。

【0212】

犯罪者等の顔写真情報を用いて防犯対応の助言を行う方法について説明する。まず、カメラ付きインターフォンや、インターフォンに連動するカメラ、電子機器７３に付属しているカメラ、防犯カメラなどの電子機器利用システム７２に接続されたネットワークワーク上の機器を用いて、来訪者等の相手の顔のデータを取得する。電子機器利用システム７２は、ネットワークワーク上の機器を用いて相手の顔のデータを取得すると、防犯ＤＢ１３１にある情報と取得した顔データとを比較サーチの処理を行う。比較サーチの結果、防犯ＤＢ１３１上に相手の顔の情報があった場合、電子機器利用システム７２は、利用者３に対し、防犯対応を行うための会話台本９２である防犯台本を用いて、相手が犯罪に関係している人である可能性が高いことを通知する処理を行い、必要な助言する処理を行う。
助言の内容は、「玄関を開けないでください。」「信頼できる第三者や警察に連絡してください。」などの助言を行う。
防犯DBに登録された顔写真を利用した防犯対策の例を図２１に示す。

【0213】

犯罪者等の音声情報を用いて防犯対応の助言を行う方法について説明する。まず、インターフォンや電子機器７３に付属しているマイク、電話機などの電子機器利用システム７２に接続されたネットワークワーク上の機器を用いて、来訪者や電話口の相手等の相手が話す音声のデータを取得する。電子機器利用システム７２は、ネットワークワーク上の機器を用いて相手の音声のデータを取得すると、防犯ＤＢ１３１にある犯罪者等の音声情報と取得した音声データとを比較サーチ処理を行う。比較サーチの結果、防犯ＤＢ１３１上に相手の音声の情報があった場合、電子機器利用システム７２は、利用者３に対し、防犯対応を行うための会話台本９２である防犯台本を用いて、相手が犯罪に関係している人である可能性が高いことを通知する処理を行い、必要な助言する処理を行う。
この音声の比較処理は、話者照合に使われる技術のうち特定フレーズに依存せず非定型の自然な発話データを登録し、認証に用いる方式（テキスト独立方式）を用いて行う。テキスト独立方式を用いて話者照合の例として日本電気社のBio-IDiom（登録商標）に使われている技術などがある。
また、電話口の相手に対しては、利用者３が電話を取る前の段階で、電子機器７３が利用者３に変わり電話応答の処理を行う機能を有してもよく、電話口の相手が犯罪に関係している人である可能性が高い場合は、電話を終話させる処理を行う機能を有してもよい。この電話応答は、電話対応を行うための会話台本９２である防犯代替台本を用いて行ってもよい。

【0214】

送信者の発信者番号を利用した防犯機能について説明する。発信者番号を利用したフィルター機能となる。
利用者宅の電子機器７３は、電話をかけてきた送信者の発信者番号を防犯ＤＢ１３１に保存処理を行い蓄積する。
電話で詐欺を行う詐欺のプロセスは、１回の電話で詐欺が完結する訳ではない。１日ないし２日のうちに様々な発信者番号から電話がかかってくるケースが多い。この間の着信回数が普段日常の着信回数よりも増えることにも注目する。この詐欺プロセスを整理すると、事件は２日以内、時間にするとファーストコールから２４時間内で完結、１〜３種類の発信者番号を利用しているか、又は発信者番号拒否している場合があり、同じ発信者番号で複数の高齢者宅へコールする、ということが事例でわかっているため、これを電子機器利用システム７２が対処すればよいことがわかる。
まず、電話機器と電子機器７３が接続されことからはじまる。固定電話の接続は有線で接続し、携帯電話の場合はアプリをインストールすることが必要となる。
携帯電話にインストールするアプリとは、かかって来た発信者番号を電子機器利用システム７２へ送信する簡単なＡＰＩである。
電子機器利用システム７２にある防犯システム１３２は、利用者３にかかって来た電話の発信者番号や日時の情報を発信者番号情報として防犯ＤＢ１３１に保存する処理を行い蓄積し、この情報が防犯に役立つことになる。
防犯システム１３２は、防犯ＤＢ１３１の情報から利用者３が高齢者で高齢者宅又は高齢者の携帯にばかりに発信している発信者番号をサーチする処理をする、さらにそのサーチした発信者番号から２４時間以内に高齢者に複数回電話をかけている番号だけをフィルターにかけサーチする処理を行い。こられのフィルターで残った発信者番号を注意発信者番号情報として防犯ＤＢ１３１に蓄積していく。ここから利用者３の本システムの利用について説明を始める。外部から電話がかかって来た時に電子機器７３は発信者番号を取得する処理をし、防犯ＤＢ１３１の注意発信者番号情報とサーチ処理を行う。サーチ処理の結果、発信者番号が存在しない場合は、注意する発信者番号でないため電話を利用者３に繋ぐ処理をする。サーチの結果、発信者番号が存在した場合は、利用者３には接続しない処理を行い、電子機器７３が変わって電話の相手と会話をする処理に切り替えることで、高齢者を守る防犯対策を行う。電子機器７３が行う切り替え処理は、用意されている防犯者用の会話台本９２により会話を行い、電話を終了する処理を行う。
また発信者番号の通知が無い場合は、利用者３の電話に接続しない処理を行い電子機器７３側で対応する処理を行う。その切り替えは、利用者３は電話がかかってきたことすら知らない。これは、とくに高齢者の場合に限り、詐欺師からの電話に恐怖を感じるからである。この場合の電子機器７３の対応も用意されている防犯者用の会話台本９２により会話の処理を行い発信者番号の提示を求め再度電話をかけてもらうように促す対応の処理を行う。
また、注意発信者番号は、電子機器７３が収集している発信者番号だけでなく、警察などの行政機関や通信業者が収集している犯罪に関する発信者番号も利用してもよく、警察などの行政機関や通信業者が収集している発信者番号を取得するために警察などの行政機関や通信業者と犯罪に関する発信者番号を共有する機能があってもよい。
電子機器７３を利用した防犯対策の例を図２２に示す。

【0215】

防犯ＤＢ１３１にある犯罪に関連するキーワード情報を取得する処理をし、防犯対応の助言を行う方法について説明する。まず、電子機器利用システム７２に接続された電話機を用いて、電話口の相手の相手が話す音声のデータを取得する処理を行う。取得した相手の音声をキーワードごとに分解する処理を行う。電子機器利用システム７２は、分解したキーワードが防犯ＤＢ１３１に登録されていないかサーチする処理を行い、サーチの結果、防犯ＤＢ１３１上に分解したキーワードが存在する場合、電子機器利用システム７２は、利用者３に対し、防犯対応を行うための会話台本９２である防犯台本を用いて、相手が犯罪に関係している人である可能性が高いことを通知する処理を行い、必要な助言の処理を行う。助言を行うと同時に取得した電話相手の音声を、犯罪者等の音声情報に登録する処理を行う。
また、電話機に代え、電子機器利用システム７２に接続されたインターフォンでもよい。
さらに、カメラ等で相手の顔の画像が取得できた場合、取得した顔写真を、犯罪者等の顔写真情報に登録する処理を行う。

【0216】

上記説明では、会話台本９２を用いて通知や助言を行うとしたが、「テレビ受像機や電子機器７３などの画面に助言内容表示させる」などの他の方法を用いて助言する処理を行ってもよい。

【0217】

ここまで、防犯DB１３１に登録されている場合、「相手が犯罪に関係している人である可能性が高いことを通知する処理を行い、必要な助言の処理する」と記載してきた。しかし、その逆をサービスとして提供することも安全で重要な事であると考える。水道やガス、電気などの点検などの理由で利用者宅に来訪者が来る場合もある。この場合、事前に来訪のアポイントの連絡があるので、来訪者予定者の音声情報や顔写真を防災DB１３１に来訪許可者として登録し、来訪予定日時も合わせて保存しておく。
来訪予定日時に登録された来訪者が来訪した場合、犯罪に関するキーワード情報に該当していても、電子機器利用システム７２は、問題ない来訪者と判断する。

【0218】

（５，緊急情報提供）
本開示の電子機器利用システム７２には、医療情報共有データベース２上の災害時行動ＤＢ１５１を利用することにより、利用者３に対して災害時に適切な行動を促す機能を有している。また、避難が必要になった際に、避難実施の有無や避難を行っていない理由を災害時行動ＤＢ１５１に保存する処理を行う機能もあり、保存した内容を自治体が確認できる機能も有している。ここでいう災害には、地震や豪雨といった自然災害、火災などの事故、断水や停電といった生活に支障をきたす事象などを含んでいる。

【0219】

災害時行動ＤＢ１５１を利用した災害時に適切な行動を促す機能は、災害ケースごとに必要な行動情報と、利用者３の利用者３の居住地情報と、災害の情報の３点がそろうことで実現できる。
災害ケースごとに必要な行動とは、「火災の場合は火災現場に近づかない」「大雨の場合は、山や崖から離れる」などのことである。この情報は、災害ケースごとに必要な行動情報として、予め災害時行動ＤＢ１５１に保存しておく。
利用者３の利用者３の居住地情報は、医療情報共有データベース２上にある医療経済圏ＤＢ２１に保存されている情報を利用する。
災害の情報は、災害情報と気象警報情報と避難情報とのうちいずれかであり、自治体や気象庁などが運用するシステム（公共システム）から取得する処理を行う。災害情報とは、火災や断水、停電、地震、大雨などの事象自体の情報を示す。気象警報情報とは、気象庁が発表する気象警報や注意報などのことを示す。避難情報とは、避難指示や避難命令、避難準備情報などの情報のことを示す。
電子機器利用システム７２は、利用者３の居住地付近で災害の情報が発表されると、発表された災害に合わせた行動情報を災害時行動ＤＢ１５１から取得する処理を行い、利用者３に対し、電子機器７３を利用して、発生した災害の情報と取得した行動情報とを通知連絡する処理を行う。
電子機器７３、通知連絡した内容が、避難を行うべき内容の場合は、避難の有無や避難できない理由を取得する機能を有してもよい。
この機能は、電子機器７３と利用者３が所有する端末との接続が外れた場合は避難を開始したと災害時行動ＤＢ１５１に記録する機能と、避難していない場合、避難できないまたは避難を行っていない理由を会話台本９２を用いて利用者３に確認し、前記理由と避難していないという情報を災害時行動ＤＢ１５１に記録する機能で構成されている。
災害時行動ＤＢ１５１に記録された情報は、ネットワークを介して自治体が確認できるようにしてもよい。自治体が確認できることにより、避難開始しているのに避難所に来ていない利用者３や避難していない利用者３の捜索救助を優先して行えることが期待できる。
災害時行動ＤＢ１５１に記録される避難できない理由の例としては、
「大雨で避難指示が出ているときに、自宅前が既に冠水しているため安全に避難を行うことができない」などがある。

【0220】

本開示において説明してきた、電子機器７３の５つの基本機能と５つの拡張機能を用いることにより、利用者３が安全安心に暮らせるための電子機器７３となる。
利用者３（患者）の日常の情報を取得することができるため、医療機関４としては、日常の情報を用いることで、より高度な診察や治療を行う判断材料とすることができる。
医療機関４において、担当している既存の患者へ本考案の電子機器利用システム７２を提供することにより、患者の日常のデータを電子機器利用システム７２が収集し医療機関４の医師５ａへ患者の情報を提供することで、医師５ａは大勢の患者を診ることができる。さらに電子機器利用システム７２が日常データの変化点や基準値とは違う検査値を見極め医師５ａに情報を伝える処理を行うために、医師５ａによる見逃しを防ぎ一層患者の診察を深く診られるようになり、結果、患者の病状改善に繋がるようになる。患者でなくともデータを使用した身体の見守りやデータ診断ができるため、医師５ａが自ら病気ではないかと推測できる患者を探しアプローチをかけることで医療機関４の経営が良くなると推測できる。
また、患者の日常データを利用することで遠隔診療サービスより多くの患者（利用者３）を診ることで収益が上がると推測できる。
健康管理を目的とした医療機関４でのサービスに利用することで、患者以外に病気で無い利用者３を取り込むことができ、経営はさらに良くなると推測できる。

【0221】

本開示の電子機器７３に、利用者３から医療機関４への連絡機能があってもよい。この機能は、体調不良時や処方されている薬に疑義があるときなど利用者３が医療機関４へ連絡や相談したいときに、利用者３が電子機器７３に話しかけることで医療機関４へ連絡が行えるものとなっている。連絡する内容は、会話台本９２を利用して利用者３から聞き取りを行う。聞き取った内容は、音声やテキストなどの情報として医療機関４へ送られる。送られてきた医療機関４は、利用者３からの問い合わせ内容を確認し、電子機器７３を用いて同期または非同期で利用者３へ回答を行う。

【0222】

第８実施形態に記載する「医療版ＭａａＳシステム２１３」と、本開示の電子機器利用システム７２を併用することで、特殊な車両を利用している患者は、音声で車両や介添人８を確保することができるようになる。
例えば、木曜に買い物に行きたい場合、「木曜に新宿で買い物したい」などと利用者３がスマートスピーカーに問いかけると、スマートスピーカーは、買い物の所要時間やお迎えの希望時間などの質問を含む会話を利用者３と行う。質問の結果を利用して、車両や介添人８などを確保する時間を割り出し、割り出した時間で車両や介添人８などの確保を行う。

【0223】

ここで説明した「電子機器利用システム７２」は、利用者３である患者に対して、医療機関４の医師５ａが病状を会話データから確認できる事で医療ケアのサポートを行えるようになる。さらに、本来、医療機関４とはあまり縁のない未病な利用者３にとって、会話から健康状態や病気の疑いを見守ってもらえるサービスは、
病気にならずに生涯を終えられることを希望している利用者３にとって、認知症になりたくないと願い、また早期に治療を始められ認知症からの改善に希望が期待できるサービスである。
プラットフォームによるサービスを提供することで、沢山の医療機関４がサービスを利用できることになり、その医療機関４の患者にとっては望ましい事と考える。
人口が減っていき、これから医療機関４同士の患者の取り合いが始まり医療機関４の淘汰の時代が来る。
病気が治れば去っていく患者だけを相手にしていたビジネスモデルから、このサービスは医療機関４とは縁の無い未病者がいる新しい畑で収穫を始めるような試みのビジネスモデルとなる。
患者から利用者３へとサービスを広げて提供していく「電子機器利用システム７２」は、医療機関４に使用してもらいたいサービスである。
今後、患者や利用者３は、医療サービスを選ぶ時代になる。
他の実施形態で説明しているサービスを医療経済圏２４の中で利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。
患者への様々な医療サービスを提供する時代が始まると考える。

【0224】

本考案のシステムに参入する事業者は、幅広いマーケットからお客を探す遠回りのビジネスから、予め対象者を絞った利用者３に対して様々な事業を短い時間で展開することができる。例えば、
広告を行う場合、どの年齢層、性別、職業、病状者、健康志向者、等を絞込み広告を間接的な利用者３との会話を行うことができ、その広告の会話から得ることができる会話の情報は、様々な利用者３の回答情報を得ることが可能となる。その会話には意見や要望なども直接的に収集することが可能となる。
さらに、商品を販売店に卸しているメーカーは、広告や直接利用者３との会話で販売することが可能となる。ビジネスの参入は期待できる。

【0225】

＜第４実施形態＞
従来、医療機関４の窓口や事務処理において現金を扱って、支払いなどを行っていた。この事務所処理などに割かれていた医療事務に従事する人の人件費が医療機関４においてのコストとして無視できない割合となっている。
医療機関４の経営を安定させるには、「医療機関４の窓口での会計作業」や「薬や医療用部材の購入に伴う決済作業」「医療従事者５への給与支払い作業」などお金を扱う作業の自動化によっても行える。お金を扱う作業の自動化により、この作業に従事していた事務員の省人化が行えるためとなる。
これを実現するためには、医療機関４において現金を扱わず、キャッシュレスで決済を行っていく必要がる。しかし、医療機関４における決済のキャッシュレス化は、大病院を除き進んでいない。中小の病院やクリニック４ｅにおいては、キャッシュレスで支払える場合もあるが、支払いに使用できたとしても、５千円以上など決済金額が最低金額を上回っている場合や自由診療の場合など、限定された条件でしか使えない場合も多い。個人医院において、キャッシュレス化は皆無である。キャッシュレス化が進まない理由としては、「決済手数料が高いと医療機関４が思っている」「保険診療で返戻が発生した場合の手続きが煩雑になる」「保険証忘れ等に起因する、一旦全額自費で支払い後日保険を適応させ払い戻しを行う作業が大変」「患者によっては年齢や病状から決済カードを作る審査が得られず使えないなどの起因もある」などがある。
医療機関４全体のキャッシュレス化が進めば、経理プロセスの自動化を行え、税申告が自動化で行えるようなり、医療機関４における事務スタッフの省人化となる。また、患者と病院４ａが共通で使える、決済システム９ｃとそれに付随する決済口座を用意することにより、システム内では振替情報の記録による電磁気的なお金の移動で支払いが行えるようになる。また、決済ステムに健康保険の保険証情報や公的機関による医療費助成の医療証情報などが紐づくことより、保険証や医療証の情報が変わっても決済システム９ｃ内での処理で終わり、決済は滞りなく行え、医療機関４や患者は煩雑な手続きを行う必要が無くなっていく。
さらに、医療従事者５への給与支払いや、薬や医療用部材の購入などに伴う医療機関４の経費の支払いなどにも決済システム９ｃとそれに付随する決済口座を利用することにより、医療機関４におけるお金のやり取りの共通プロセスとなり、本考案のシステムが医療決済のプラットフォームとなる。
従来の決済は、健常者を基本とした決済であり病状を患った人が利用すると財産を一瞬に無くしてしまう場合もあり、医療目線から見ても様々な病状の患者や高齢の患者でも所有できる安全に使える決済はこれからの社会では必要となる決済である。

【0226】

本開示の医療機関決済支援システム１０２（決済支援システム１０２）は、専用の決済媒体（決済用カードや決済情報か表示できる患者の端末など）を病院４ａから患者へ渡すことで利用できる。
また、決済媒体の作成に必要な個人情報２２（個人の基礎情報）は、プラットフォーム型医療機関支援システム１の医療情報共有データベース２にある医療経済圏ＤＢ２１内に保管された情報を利用する。この情報を利用することにより医療機関４で瞬時に決済媒体を作ることができる。一般の人が決済カードの作成を金融機関やクレジット会社へ申請する時に個人を特定するための基礎情報としてパスポートや保険証や免許証を提示して作られる。医療機関４で作る決済媒体を瞬時に作ることができる理由もまさにこれと同じであり、医療経済圏ＤＢ２１内に保管された情報には、患者の情報として保険証の情報が登録されている。そのため医療機関４にある情報を使うことで瞬時に決済媒体を作ることが可能となる。保険証について説明すると、保険証を自治体又は健保組合が承認して配布しているためそれを元に２度目の審査をする必要は無いとの理論となっている。病院４ａで媒体を患者に渡すことにより、患者は自然と決済システム９ｃを利用する流れを作れ、即座に患者が現金決済からキャッシュレス決済へ移行する流れを作ることができる。また、このキャッシュレスシステム１０３は決済媒体だけでなく医療用の決済口座も同時に作ることが特徴となっている。病院４ａで決済口座を作るため、従来のキャッシュレス決済口座作成時に発生していた、煩わしい口座の開設待ち時間なく口座が即時に作成できる。この本開示の医療情報を使って決済媒体を作る方法については金融機関も気がつていなかった。
この本開示の特許出願時点において、病気を患っている患者に配慮しているキャッシュカード、クレジットカード、デビットカードなどの決済手段は、存在していない。
ここでは将来増加していく病状者において利用できる又は期待できる内容を記載する。
病院４ａで患者に渡した決済媒体を街中でも利用できるようにし、認知症や物忘れなどの症状がある患者の場合、その症状に合わせて街中での利用を支援していく仕組みを提供することで、患者の利便性が上がり、病気の症状に起因する買い物を抑制することができる。特に、認知症という病状では、認識のない衝動買いや、買い物依存などの症状による買い物をしてしまう事や、認知していない支払いをしてしまう事や、病気症状である妄想から現金や財布を盗まれないように隠してしまい隠したことすら忘れてしまう場合がある。

【0227】

また、この決済支援システム１０２の決済口座は医療従事者５も、自身の医療情報が医療経済圏ＤＢ２１にある基礎情報を作成し適応することにより医療従事者５への給料支払いへ利用することもできるし、医療従事者５が病院４ａを受診する際の支払いの利用や街中での買い物の決済にも使える。

【0228】

さらに、この決済支援システム１０２の決済口座を医療経済圏２４をビジネス目的で利用している製薬会社や薬問屋、医療資材会社などの医療機関４の取引先でも作成することはできる。会社の代表が医療機関４に診療したことがあれば、医療経済圏ＤＢ２１に個人情報２２や健康保険証の情報が登録されているためそれらが基礎情報となり決済媒体と医療決済口座１０４を作成することができる。取引先企業の決済口座の作成も医療経済圏２４の支払い口座として利用できる。

【0229】

本開示の決済支援システム１０２は、経営と事業構造とを主体とした医療経営サービス上にあるいくつかのサブシステムにより構成されている。

【0230】

金融機関やクレジットカード会社等の決済媒体の作成を申請する時に、基礎情報として個人の諸情報（氏名・生年月日・住所・電話・性別）に、就業先情報や金融機関口座情報と場合によっては氏名・住所を証明する公的機関の情報も合わせて申請し審査により所有することができるプロセスとなっている。この申請に必要な情報の全ては医療機関４に備わっている。
この療機関にある医療情報システム９には、患者の個人情報２２として、氏名・生年月日・住所・電話・性別・診察券番号・健康保険証番号などが保存されているため、この情報をそのまま利用しない手はない。この情報を流用すればワンクリックで瞬時に決済媒体を作ることができる。
本開示の決済支援システム１０２では、前記医療情報システム９から取得できる個人情報２２に加え、マイナンバー・免許証番号・旅券番号・在留カード番号なども個人情報２２として保存されている。また、患者が本システムでの決済に用いる決済手段の情報である決済手段情報として、患者が指定した銀行口座やクレジットカード・金融機関口座情報・暗号通貨情報・デジタル通貨情報・ポストペイ決済情報・プリベイド決済情報なども医療経済圏ＤＢ２１にある決済関係ＤＢ１０１に保存することができる。
この決済手段の情報は、患者の端末から設定することもできる。さらに、患者の指紋や顔といった生体情報も認証情報として決済関係ＤＢ１０１に保存されている。この設定は、医療経済圏２４のポータルサイトで設定することができても良い。ポータルサイトの例として出願人考案の特許第６５５８６６９号の図１０に開示の技術などがある。
クレジットカード等を新規に作成する時に申請用紙に記載していた個人情報２２を省略して、今後は本開示の決済支援システム１０２を利用すれば、申請するクレジットカード会社や金融機関や信販会社へ必要な基礎情報の全てをワンクリックで通知することができる。

【0231】

第４実施形態のデータベース構成を図２３に示す。

【0232】

本考案の医療情報システム９には患者の個人情報２２として、生体情報も認証情報などの情報が含まれている。この情報を用いることで旧来の電子カルテ９ａを使用している医療機関４の相互において、患者データの閲覧等によるデータ共有を行うことができる。医療機関４の間で情報を共有する手法は、出願人考案の特許第６６６０６５５号に開示の手法などがある。
共有の例として、Ａ内科病院に来た患者がＢクリニックでの医師５ａの所見を参考にしたい場合に、Ｂクリニック内で使用されている旧来の電子カルテ９ａに患者の診察番号（管理番号）をキーに検索され閲覧することができる。

【0233】

本開示の決済支援システム１０２は、病院４ａの受付において、決済媒体を患者に渡すことを特徴とし、この決済媒体の情報が基本口座情報となる。決済媒体の基本口座情報は、病院４ａなどに保管されている患者の情報を管理する医療情報システム９から個人情報２２を取得し、取得したものを利用する。決済媒体を患者に渡す際、決済媒体のユニークな管理番号と紐づいた医療決済口座１０４の作成が行われる。この医療決済口座１０４には、医療情報システム９から取得した患者の生体情報が付加されている。さらに、患者が本システムでの決済に用いる決済手段情報が登録されている。決済支援システム１０２の構成を図２４に示す。

【0234】

本開示の決済支援システム１０２を用いた医療機関４における決済は、決済用端末に前記媒体の提示を行い、患者の個人情報２２または患者の生体情報を追加で提示することにより行える。決済用端末は、読み込んだ決済媒体の情報や患者の個人情報２２または患者の生体情報を本開示の医療機関決済支援システム１０２上の認証サーバーへ送る処理をする。生体情報を受信した認証サーバーは、医療経済圏ＤＢ２１内の認証情報として保管している患者の生体情報との比較により本人認証を行い、認証結果を医療機関決済支援システム１０２上の決済サーバーに送る処理をする。
キャッシュレスによる支払いは、決済サーバーにある医療決済口座１０４に前払金を入金することで決済を行う。前払金の詳細は後記する。

【0235】

医療決済口座１０４を使用している医療機関決済支援システム１０２の決済された資金情報と現金の流れを説明する。
決済が行われると診察料や調剤料など患者が医療機関４へ支払う費用が医療機関決済支援システム１０２上にある患者の医療決済口座１０４から医療機関決済支援システム１０２上にある医療機関４の医療決済口座１０４へ移動したという振替情報が医療決済口座１０４に情報として記録される処理により行われる。この振替情報の記録は、患者が支払い行為を行うのとほぼ同時に行われる。振替情報に記録される情報は、支払いを行った患者の医療決済口座１０４の情報と支払い先の医療機関４の医療決済口座１０４の情報と支払いにより発生する金額移動情報などの支払いの明細情報が記録する処理が行われる。
患者が医療機関４への支払う費用として、診察料や調剤料などを例として記載したが、病院４ａにおける医科報酬、歯科４ｆにおける歯科報酬、薬局４ｂにおける調剤報酬、薬価や医療材料費など、患者が医療機関４に支払うすべての費用のことを示す。

【0236】

医療機関決済支援システム１０２には、患者の診療で利用した一連の医療機関４の決済を一度に行える機能を有してもよい。この機能は、患者が診療で利用した一連の医療機関４のうち任意の医療機関４を患者が選び、選んだ医療機関４で一連の医療機関４への決済が行える。
選んだ医療機関４以外への決済は、医療機関決済支援システム１０２を経由して他の医療機関４に決済手段など決済に必要な情報が送られることにより行われる。
例えば、医療機関４で診察を受け処方箋がだされた場合、通常であれば、医療機関４で診察料を支払い、次に調剤薬局４ｂへ行き処方薬の費用を支払う。ここで説明している「一連の医療機関４の決済を一度に行える機能」は、診察が終わり医療機関４で決済を行う時に次の調剤薬局４ｂで支払う処方薬の費用も一緒に医療機関４で支払ってしまう事を言います。

【0237】

ここまで決済媒体と患者の個人情報２２または患者の生体情報のどちらかを提示することで決済が行われると説明してきた。決済媒体なしでの決済が行われるとした、本出願人の特願２０２１―１１３９２７などがある。これにより、患者の生体情報を医療機関決済支援システム１０２上の認証サーバーに送り、本人の認証を行うことにより、決済媒体なしで決済を行ってもよい。

【0238】

また、本開示の医療機関決済支援システム１０２には、領収書や診療明細書などの医療機関４が発行する決済に関連する文章を発行する機能があってもよい。また、一定期間内の受診履歴とその合計金額を算出し、一定期間内の受診履歴と合計金額とが記載された文章を発行する機能があってもよい。
文章の発行は、医療機関４に設置された決済用端末などの端末などで印刷するほか、電子文章として発行してもよい。電子文章の発行は、医療機関４に設置された端末，患者の持つパソコンやスマートフォンなどの端末などから、医療機関決済支援システム１０２に対し、送付先を指定することにより行う。文章の送付は、必要に応じて都度端末を操作して送付を行うほか、予め送付先を指定しておくことにより、決済が行われた場合など文章の発行できるタイミングにおいて自動で文章を送付してもよい。

【0239】

ここからは、決済媒体及び医療決済口座１０４と前払金について説明を行う。
医療機関決済支援システム１０２で作られる決済媒体は、病院４ａで患者に渡される決済媒体には、ユニークな管理番号が採番されている。
医療機関決済支援システム１０２で作られる医療決済口座１０４は、患者に渡した決済媒体の管理番号に紐づいた医療決済口座１０４が自動的に作成される。その医療決済口座１０４には、医療機関決済支援システム１０２上の患者情報ＤＢ１６１に保存されている患者の個人情報２２及び患者の生体情報と自動的に紐づく機能がある。
決済媒体で決済を行えるようにするには、決済媒体をアクティブ化（有効化）する必要がある。まず、アクティブ化する前に、患者の生体情報を取得し医療決済口座１０４に紐づけてある事の確認を行う。生体情報の確認ができたら、アクティブ化を行うために医療決済口座１０４に、初回の前払金の入金を病院４ａの受付で行う必要である。この前払金の入金は、決済媒体を渡された病院４ａの窓口で行える。
決済媒体の作成方法の例を図２５に示す。
前払金について説明する。
前払金は、医療決済口座１０４に予め入金する金額の事を指し、実際の決済を行うためのお金のことである。前払金が、無い又は決済金額に足りなければ決済は行えない。初回前払金の入金は、病院４ａの受付で行う。２回目以降の前払金の入金方法は、病院設置の端末や病院４ａの窓口での入金、銀行振り込みによる入金、決済手段情報に記録された決済手段からの振替による入金などで行う。この振替は「一定期間毎に自動で入金する。」「前払金の残額が設定した下限を下回ったら入金する」など、既存技術で行われている方法により行われる。
利用者３の医療決済口座１０４に前払金の残額がない場合、一時的に決済媒体及び医療決済口座１０４を無効にする機能があってもよい。

【0240】

ここまで決済媒体を病院４ａで使用する前提で記載してきた。ここからは市中で利用する患者に目線を合わせ、医療を主体にした決済手段が何故必要なのかを説明する。
決済媒体自体は、既存技術となっているプリペイドや電子マネーと大差ないものであるため、そのまま市中の店舗など病院外での決済に利用できる機能があってもよい。決済は、市中の店舗の決済端末に決済媒体を提示することにより行われ、前払金から、市中の店舗の口座に対してお金を移動することにより行う。このお金の移動は、振替情報として患者（利用者３）の医療決済口座１０４から市中の店舗の口座へ送られ、実際のお金の移動は、締め日ごとなどにまとめて行ってもよい。
患者（利用者３）の医療決済口座１０４へ前払金への入金は、前述の方法に加え、市中の店舗で行えるようにしてもよい。

【0241】

市中での決済の機能には、生活する上での資金管理する機能があってもよい。患者の中には病状から発生する依存症により買物をし続けることがあり、病状のある患者にはシステム上でセーブする機能が必要不可欠となる。患者の病状に合わせて患者に寄り添った決済システム９ｃとなっている。
生活する上での資金管理する機能には、「生活品目ごとや購入場所ごとに生活資金の上限を設定する機能」や「一定期間内の生活資金の上限を設定する機能」などがあり、生活資金の計画をする家計費管理機能として利用でき、利用者３にとって安心した暮らしがおくれることにつながる。また、患者情報ＤＢ１６１上の属性情報に認知症などの情報が付与されている利用者３に対する、症状に合わせた機能も有している。
「生活品目ごとや購入場所ごとに生活資金の上限を設定する機能」の詳細を具体例交えて４例を以下に示す。

【0242】

（１）病院４ａで患者に渡した決済媒体を利用しているＡさんは、生活資金として、毎月の決済額の総額として３万円と設定した食品に５千円、日用品に３千円、アルコールや菓子嗜好品に５千円、外食に３千円を設定した。また、購入場所ごとの上限としてＢ商店５千円、Ｃマート１万円、Ｄストア１万円を設定し、医療費として１万円設定している。このように設定している場合、Ａさんは、月末の医療決済口座１０４の残高が、トータルで７千円残っていた。Cマートで、食料品と肉類を合計で４千円買おうとして、予めシステムに設定してある設定値を超えた為に決済後に買物改善を促すアラーム通知の処理により自動的に利用者３の携帯端末に届く。家計費管理機能により利用者３に現状把握のアラーム通知を行う。アラーム通知の内容には、利用者３への現状の報告として、〇月〇日の時点で既に食料品は月の上限設定額よりも１千円を超えてしてしまった事と、Cマートでの購入上限設定を２千円を超えてしまった事と、上限決済額の残金が〇千円であと〇日までの利用できる残金と現状までの決済集計の報告と、警告の内容として翌月までの買い物金額と買い物品目と買い物場所との改善と、買物全般の抑制を求める内容のアラーム通知となっている。このように、生活品目ごとや購入場所ごとに生活資金の上限を設定する機能は、品目ごとの上限金額や購入場所ごとの上限金額を設定する機能のことを示す。
上記の設定金額は、「当日を含め過去１週間や過去１か月間の設定金額とする」、「毎月１日から月末までの１か月や日曜から土曜までの１週間の設定金額とする」など、一定の期間を決めてその期間内の上限金額としてもよい。
すなわち、家計費管理機能とは、一般的な生活費の管理と同様に、一定期間で使える金額や細目ごとに使える金額を決められ、実際に使っていける機能のことを示す。
また、金額を指定して設定する例を上記で説明したが、金額ではなく割合で設定してもよい。割合とは、生活資金の全体を１００％とすると、品目ごとに何％や購入場所単位に何％等と設定することをいう。

【0243】

（２）本開示の医療機関決済支援システム１０２にある固有のセキュリティについて説明する。本開示の決済支援システム１０２には、決済端末の位置情報と決済端末が設置している住所とがほぼ同一地点でなければ、決済の制限を行う、決済のセキュリティ機能を有している。
決済端末は、位置情報の取得にＧＰＳやモバイル通信網の電波、wifiの電波、ネットワークＩＰアドレスの情報などを用いて行う。位置情報の取得は、決済端末にある決済位置取得部が取得した位置情報をプラットフォーム型医療機関支援システム１内の位置情報取得システム１０５に対して送ることにより行われ、Geolocation APIとして一般に知られている手法を用いる。
決済端末の設置している住所は、医療経済圏ＤＢ２１に決済場所情報として予め登録してあり、住所から緯度経度といった位置情報を算出してある。
位置情報の取得例を図２６に示し、決済端末を設置した住所位置情報データベースのシステム図を図２７に示す。
決済端末が取得した位置情報と、決済端末の設置した場所の住所から算出した位置情報とがほぼ同一であるかの判定を決済支援システム１０２が行い、ほぼ同一地点であると判定されれば、決済が許可される。これは位置情報の不一致を利用したセキュリティ機能である。
決済が許可されると、患者をはじめとする利用者３は、医療決済口座１０４に入金済みの前払金や、決済手段情報として登録している決済手段を用いて決済を行う。
すなわち、決済場所情報に住所が登録されていない決済端末からの決済は、決済が行えないセキュリティ機能を有している。
例として、システムに登録してある決済場所以外では決済ができないことから、Aさんは雑居ビルの中のB店舗で決済を行おうとしたが、決済はできなかった。このB店舗は営業登録をされていないことから決済端末の設置は許可していないため決済ができないように保護していた。

【0244】

（３）決済端末が取得した位置情報と、決済端末の設置した場所の住所から算出した位置情報とがほぼ同一地点でなければ決済の制限する機能をもつ決済支援システム１０２には、利用者３が決済支援システム１０２上の決済手段データベースに、事業者（販売店）ごとに購入金額の上限を設定する機能があってもよい。この設定は、患者（利用者３）の持つ端末などで行うことができる。事業者リストは、決済端末の設置した場所の住所の決済場所情報から利用できる。事業者ごとの購入できる金額の上限は、同一の事業を営む業種ごとに設定できてもよい。また、事業者や業種ごとに設定した品目のみ購入できる機能があってもよい。ここで言う、同一の事業を営む業種とは、小売業など広い業種だけでなく、百貨店，スーパーマーケット，コンビニエンスストアといった細かい業種としてもよい。このセキュリティは、利用者３の自制と犯罪対策が備わっている。例として、利用者３が決済媒体を落としたり又は決済媒体を盗まれたりした場合、第三者が決済媒体を利用しようとした店舗が利用店舗として登録されていなかった場合は、盗んだ決済媒体での決済はできない。家計費管理機能により利用者３に設定されていない店舗での決済が行われようとしたアラーム通知がされる。登録されている店舗で決済ができるが上限金額までの決済しかできない。

【0245】

（４）決済端末が取得した位置情報と、決済端末の設置した場所の住所から算出した位置情報とがほぼ同一地点でなければ制限する機能をもつ決済支援システム１０２において、利用者３が予め指定した地域の中でしか決済が行えないセキュリティ機能があってもよい。地域の登録は、決済支援システム１０２上の決済範囲データベースに対して行う。この地域の登録は、患者の持つ端末などで行うことができる。登録した地域内であるかの判定は、決済支援システム１０２が行い、決済端末の位置情報と決済端末が設置している住所のどちらかの情報を用いて行う。
地域の設定方法としては、「利用者３の自宅や利用者３の通院先などの特定の地点から直線距離で一定の距離以内」「指定した市区町村内や町域内」などが想定されるが、これに限らない。
この決済支援ステムにおいて、登録した地域外で決済を行おうとした場合、決済結果の可否にかかわらず、決済の結果を利用者３の端末に通知する機能があってもよい。

【0246】

ここまで説明してきた「生活品目ごとや購入場所ごとに生活資金の上限を設定する機能」で利用者３の買い物を制限するために設定する項目は、決済関係ＤＢ１０１に利用制限情報として保存されている。

【0247】

ここでは、この決済に認知症等の病気を持った人への安全保護セキュリティ機能について説明する。
決済端末が取得した位置情報と、決済端末の設置した場所の住所から算出した位置情報とがほぼ同一地点でなければ決済を制限する機能をもつ決済支援システム１０２の付加機能として、利用者３の属性情報が保存されている利用者３情報データベースがあってもよい。この属性情報に捜索情報や購入制限情報が記載されている。捜索情報とは、徘徊や行方不明などの理由により家族や公的機関が利用者３を探している情報を示し、購入制限情報とは、認知症などの理由により商品の購入を制限また禁止しているという情報を示している。利用者３が商品などの購入を行おうとした場合、予め登録されている連絡先に対し決済を行おうとした場所を通知の処理をする機能である。また、この属性情報に商品などの購入が可能な地域を制限する購入地域制限情報が記載されている利用者３が商品などの購入が可能な地域外で購入を行おうとした場合、予め登録されている連絡先に対し決済を行おうとした場所を通知する機能である。
病院４ａで決済媒体を作成しており、利用者３（患者）の情報を医療機関４がもつ医療情報システム９から取得できるため、認知症などの理由により徘徊や物忘れの症状がある利用者３に対して適切な支援を行う付加機能として、捜索情報や購入制限情報が記載されている利用者３や購入地域制限情報が記載され、利用者３の制限により適切な支援を行うことができる。従来様々なキャッシュレス決済を行う事業者が決済媒体を世にだしているが、病状者の申請は通らないし病状の情報を事業者は持っていない。また病状のある利用者３への配慮を行う事業者は無かった。
たとえば、認知症により衝動買いや買い物依存の症状がでることがある。この場合、買い物自体が目的であり、買った商品には興味がない。また、通信販売で購入の場合、認知症患者は、自分宛に勝手に荷物が届いたと誤認し、市中での買い物以上に満足する場合もある。このような症状がでている患者が、買い物を行うと購入店や家族に迷惑がかかるため、購入の制御を行う、または、特定地域内でしか購入できないなどの対策もできるようになっている。また、購入を行った場合において、購入した店などの情報が、家族や後見人など予め登録されている連絡先に連絡されるので、必要ない商品の購入を行っても迅速に対応がおこなえる。このように従来には存在しない医療社会目線での決済が行える医療機関決済支援システム１０２のプラットフォーム基盤を社会に取り入れることがとても重要である。

【0248】

ここまで、使用できる決済の上限金額を設定する「生活資金の上限を設定する機能」と登録した地域でしか決済が行えない「利用者３が予め指定した地域の中でしか決済が行えないセキュリティ機能」とを説明したがこの２つを併用、すなわち登録した地域内で設定した上限金額までしか使えない決済のセキュリティ機能を有してもよい。

【0249】

ここまで、利用者３視点での医療決済口座１０４や決済支援システム１０２の説明を行ったが、医療経済圏２４を利用している医療機関４の、「医療用部材や薬品などの購入となど企業との取引」、「保険者や自治体などからの入金」などにも医療決済口座１０４を利用してもよい。多くのの出入金に医療決済口座１０４が利用され、医療機関決済支援システム１０２がセントラル・カウンターパーティとなることにより、医療機関４の持つ銀行口座などの出入金が医療機関決済支援システム１０２計算した差分でよくなるため、お金の移動（銀行での振り込み・振替など）の手数料が減る。また、医療決済口座１０４で出入金が行われていると、医療決済口座１０４から出入金の履歴を取得することで取引の履歴が容易に取得できる。取引の履歴を容易に取得できると、帳簿の作成が簡略になり、税申告なども簡単に行えるようになる。結果として経理に係る医療事務従事者の省人化につながっていく。

【0250】

ここまで、医療機関４が患者に渡した決済媒体を用いて決済を行う方法説明してきた。決済に加え、医療機関４が発行するポイントを発行し事業に活用してもよい。ポイントを事業に活用した開示は、本出願人の特願２０２１―１１３９２７などがある。ポイントを事業に活用することにより、患者を増やすことの期待ができる。昭和にあったブルーチップ（登録商標）やグリーンスタンプ（登録商標），ベルマーク（登録商標）といった物は現代のポイントに相当する物を集めていたのは、戦後の昭和から始まった日本の文化である。日本人にとって集めて生活の一部とするということは昔も今も変わらないものである。

【0251】

ここまで、本開示の決済支援システム１０２の機能について説明してきた。この決済支援システム１０２を利用することにより、現金を使わない支払いすなわち「支払いのキャッシュレス化」を行うことができる。

【0252】

本開示の決済支援システム１０２を利用した、支払いのキャッシュ化には、患者情報ＤＢ１６１に保存された利用者３の属性情報に合わせて購入を制限する機能がある。また、利用者３が行った決済により発生した情報を決済関係ＤＢ１０１に買物履歴情報として保存する機能もある。
ここで保存される買物履歴情報には、決済した場所や、決済内容（買い物内容）、決済した時間などが保存される。

【0253】

キャッシュレス化は、利便性が重視され安易に何処でもキャッシュレス決済が行えてしまうため、病状者や高齢者など一部の人々には好ましいとは言えない。これは、決済に使用する端末などさえあればどこででも決済が行えてしまうためとなる。認知症の利用者３は決済媒体を落としても無くしても覚えていない、本人が無くなった事に気が付くまでは、第三者に利用されてしまう。そこで、病状者や高齢者の生活資金や自己財産の喪失を防ぐ事を目的として決済を制限する機能も本開示の決済支援システム１０２は有している。
この機能は、決済を制限する情報を利用制限情報に保存することにより実現する、
利用者３が安全保護を目的に様々な事業者または様々な業種ごとの決済金額の上限の設定や、購入可能な品目を設定する情報も利用制限情報に保存されている。この決済金額の上限や購入可能な品目の設定は、利用者３が所有する携帯端末などを利用して利用者３自身が設定するほか、利用者３の家族などが設定してもよい。
この情報が設定されている利用者３は、設定した事業者や業種ではその金額までしか決済を行うことができない。

【0254】

また、決済できる地域を制限してもよい。これは、決済（買い物）できる地域を予め設定し決済範囲情報として決済関係ＤＢ１０１に保存しておく。設定した地域外では決済が行えない。
決済できる範囲外で決済を試みた場合、決済関係ＤＢ１０１に地域外で決済したという記録が保存される。決済関係ＤＢ１０１への記録とほぼ同時に決済不可である旨の通知が、利用者３本人の携帯端末や利用者３の家族の携帯端末など決済関係ＤＢ１０１に予め登録されている通知先にも連絡する。この通知には、決済内容や決済場所、決済時間などの情報も含まれている。

【0255】

このように、事業者または業種ごとの決済金額の上限の設定や、購入可能な品目を設定、決済場所の制限を行うことにより、従来決済カードを持つことができなかった患者や高齢者にもキャッシュレスな社会環境を提供することができる。
患者や高齢者が、決済カードを持つことができなかった理由としては、収入が低いために信用情報低いと決済カード発行側が判断しているためや、認知症など病状によっては銀行口座が引き出し制限され支払うことができないためとなっている。

【0256】

決済した場所が分かることにより、利用者３が今どこにいるかもわかる。この機能は、患者情報ＤＢ１６１に属性情報として捜索情報や購入制限情報が記載されている場合において活用できる。
本開示の決済支援システム１０２には、利用者３が本開示の決済支援システム１０２を用いて決済を行うと決済場所などの情報が取得できる機能がある。この機能で取得した位置情報のうち、患者情報ＤＢ１６１に属性情報として捜索情報や購入制限情報が登録されている場合、この位置情報は今ここにいる情報として扱う。
今ここにいる情報は、患者情報ＤＢ１６１の信託情報に利用者３（患者）の家族や後見人など患者の信託関係者の情報として登録されている連絡先に通知される。この通知には、決済を行おうとした場所の住所や地図と、決済した場所や時決済内容などの情報が含まれている。
この信託情報には、家族信託などを用いて利用者３の資金管理の代理契約を結んでいる情報や、任意後見人、成年後見人などの情報も含まれている。
また、患者情報ＤＢ１６１に属性情報として購入地域制限情報が登録されている患者にも利用できる。購入地域制限情報が登録さえている利用者３の場合、決済範囲情報に登録されている地域外で決済を行おうとすると、信託情報に登録されている連絡先に今ここにいる情報や決済の内容などが通知される。
決済が行われると信託情報に記載の連絡先に連絡が行くため、徘徊癖のある利用者３など高齢者や一部の病状を持った人が１人で外出しても、安心して見守ることができる。万が一、遠くへ行くなどの理由により行方不明になっても、今ここにいる情報から探し出すこともできる。

【0257】

買物履歴情報や決済場所情報、利用制限情報に保存されている生活品目ごとや購入場所ごと決済金額の上限情報や一定期間内の決済金額の上限情報、利用者３の自宅の位置情報、外部システムから取得できる決済日時の天候の情報などを組み合わせて利用することにより、「行動や発言の思考や志向と食べ物の嗜好や志向の推移の移り変わりから認知症などの病状の早期発見及び認知症などの病気にならずに安全な健やかな高齢者生活がおくれること」や「行動や食べ物などの思考や志向、嗜好から認知症などの病状を有する利用者３が安全な徘徊や買い物を行える社会環境の構築」を目的としたシステムを構築することもできる。
上記で記載した各情報を組み合わせて利用すると、利用者３の様々な思考や志向、嗜好などの行動パターンの情報である、利用者３が買い物を行う頻度情報と利用者３が買い物に向かう方角情報と利用者３が買い物を行う範囲の情報と利用者３の買い物の嗜好のなどの情報がおのずとわかる。これに、決済範囲情報を組み合わせ、外部システムから取得した地図上に決済を行った場所を決済範囲情報で指定された地域内か地域外かを含めプロットすることで、行動範囲が分かる。行動パターンの情報と行動範囲は、行動パターン情報として、医療経済圏ＤＢ２１に保存する。

【0258】

「行動や発言の思考や志向と食べ物の嗜好や志向の推移の移り変わりから認知症などの病状の早期発見及び認知症などの病気にならずに安全に健やかな高齢者生活がおくれること」を目的とした場合について説明する。
まず、本開示の決済支援システム１０２は、患者情報ＤＢ１６１から利用者３の病状を取得する。取得した病状とほぼ同一の病状をもつ複数の利用者３の行動パターン情報を過去からの変化を含め医療経済圏ＤＢ２１から取得する。また、取得した病状となっておらず健康なもつ複数の利用者３の行動パターン情報を過去からの変化を含め医療経済圏ＤＢ２１から取得する。取得した取得した病状とほぼ同一の病状をもつ複数の利用者３の行動パターン情報と取得した病状となっておらず健康なもつ複数の利用者３の行動パターン情報とを用いて機械学習を行う。決済支援システム１０２は、この機械学習により、病状を持つ人の行動パターンと病状を持たない人の行動パターンの違いを導き出す。導き出した行動パターンの違いが病気の要因であると推定し、病状になっていない人に、推定した病気の要因となる行動を行わないように促す。また、推定した行動パターンが見つかった場合、病気なっている疑いがあると判断し、利用者３に病院４ａへいき医師５ａの判断を受けるように促す。結果、病状の早期発見及び認知症などの病気にならずに安全な健やかな高齢者生活がおくれるようになる。

【0259】

「行動や食べ物などの思考や志向、嗜好から認知症などの病状を有する利用者３が安全な徘徊や買い物を行える社会環境の構築」を目的とした場合について説明する。
まず、対象となる利用者３の行動パターン情報を過去からの変化を含め取得する。取得した行動パターンの情報を利用して機械学習を行う。この機械学習により、利用者３が認知症による徘徊の範囲の予測を行う。徘徊の範囲が分かることで、認知症などの病状を有する利用者３の行動を推定し安全な徘徊や買い物を行える社会環境の構築し提供するサービスが行える。
取得した行動パターンの情報を利用して行う機械学習は、レイ・フロンティア社のSilentLog Analytics（商標）に用いられる方法などを用いて行う。

【0260】

現在、新しい決済方法として中央銀行などが発行するなど国家が裏付けを行っているデジタル通貨を利用した決済が始まろうとしている。本開示の決済ステムは、デジタル通貨を利用した決済にも適応ができ、ここまで示してきたセキュリティ機能や事業者または業種ごとの決済金額の上限の設定、購入可能な品目を設定、決済場所の制限などを用いてことにより高齢者や一部の病状を持った人が安心してデジタル通貨を利用できるになる。

【0261】

本開示の決済ステムは、今ここにいる情報による通知や決済の場所の通知、決済内容の通知などを備えていることにより、家族や信託者やその他に知ってもらえ、利用者３が安心して決済できるサービスを提供することができる。

【0262】

本開示の決済ステムは、買物履歴情報として蓄積した情報を利用して、済履歴の情報から電子機器７３は患者や高齢者などの利用者３と会話を利用したサービスを利用者３へ提供することもできる。この機能は、第３実施形態の拡張機能のうち「（２）購入支援機能」に記載した機能となっている。

【0263】

本開示の決済支援システム１０２を小売店などの事業者が設置して利用することにより、事業者は
成年後見人が設定されている一部の病状を抱えた患者や、身体機能が衰えた高齢者、事業者からは、外見上認知症とはわからない患者への対応を行うことができる。
本開示の決済支援システム１０２の利用することにより、上記のような利用者３の余計な買い物が抑制でき、事業者は返品処理などの煩わしい業務を減らすことができる。

【0264】

ここまで本実施形態で説明してきた機能を組み合わせて活用することにより、患者や患者家族が患者生活資金と患者個人資産を生涯に渡り安全に管理することを望んだ場合、信託管理と相続管理と遺言管理とのうちいずれかの依頼処理を機関へ行い、受けたい機関へ患者の情報提供処理と信託契約管理処理等の信託サービスを行うことができる。信託契約利用のシステム図を図２８に示す。

【0265】

この信託サービスは、従来行われてきた預金資産の信託サービスに加え、利用者３が亡くなった後に生じる遺産相続（財産分与）の準備となる遺言の管理も行うことができる。遺言の管理は、従来弁護士や司法書士が行う場合や、法務局や公証人役場など公的機関に預ける方法で行われてきた。
また、遺言の執行には、被相続人からみた親や子、兄弟姉妹などの家系の情報も必要となる。本考案の信託サービスと、出願人考案の特許第６８８６２０９号に記載の 医療情報提供システムと連携させることにより家系の取得もシステム上で容易に行えるようになる。
認知症と診察されてしまうと、こういった書類や契約書の作成はとても困難であるため、早い段階で準備することが重要である。
利用者３の中には疾患を持った方もいる、本開示の第３実施形態に記載のスマートスピーカーを利用することで現在は認知症の兆候が何もなくとも変化を見つけられるために何事にも早い段階での準備が必要。特に利用者３の預貯金は金融機関の判断で口座ロックをかけられることもあり、早めに手を付けることで回避できるようになる。信託の契約や高齢者の場合は遺言の作成を行うプログラムを有している。遺言の作成の例を図２９に示す。

【0266】

第一生命経済研究所の分析によると２０３０年頃には、認知症を有する患者が保有する金融資産の合計が２１５兆円になると言われている。何も対策を行わないと、GDPの約４割に相当する２１５兆円が金融機関に塩漬け状態となり、消費や投資に回されるはずの金融資産がそれだけ減ってしまい、不動産取引が低下することが予想され、結果、経済循環がうまくいかなくなり、ＧＤＰの減少も懸念される。社会に与えるインパクトもあるが、一家の大黒柱の預貯金が凍結してしまうことで家族に与えるインパクトは大きく、金利が無いと言ってもよい普通預金であるならば前もって信託契約を家族で行うことが最善だと考えます。認知症が発症するまでに信託契約することにより、金融資産が塩漬け状態にならず、使える状態を維持できるため、金融資産の保有者のための財産の運用や処分も行えるようになる。

【0267】

この信託サービスを活用することにより、以下のサービスの提供も行える。
患者本人による個人情報２２の提供が病状から難しい患者でも医療情報共有データベース２の患者情報ＤＢ１６１にある患者の基礎情報を利用することで簡単かつ迅速に決済手段が作成できるサービスの提供ができる。
また、病状から決済媒体を常に紛失や忘れてしまう患者でも医療情報共有データベース２の医療経済圏ＤＢ２１にある患者の認証情報により決済ができる決済サービスの提供もできる。
結果、複数の医療機関４にまたいだ支払いを一か所で行える決済サービスの提供と病状から患者の生活資金を保護し患者が安心決済利用できる制限機能を持つ決済サービスの提供となり、病状の進行から患者の個人資産を安全に守るため信託を行う機関をサーチし患者の情報提供処理と信託契約管理処理までを行えるサービスとなる。

【0268】

ここで説明した「キャッシュレス決済」は、一部の病状を持った患者や高齢者にとって決済カードを作ることが出来なかったが、医療機関４にある情報から瞬時に決済媒体と医療用決済口座の作成ができる。このことで患者はキャッシュレスに伴う様々なサービスを受けられるようになり、医療機関４も院内における恩恵を得ることができる。
プラットフォーム化されているシステムを医療経済圏２４の中で、沢山の医療機関４が利用し、その中から発生する情報を共有することで患者への様々なサービスを考案し提供することができる、他の実施形態で説明しているサービスはキャッシュレスを前提にした患者へのサービスになっている。やはり現金決済ではサービスは成り立たなくなってきています。
医療経済圏２４を利用し様々なシステムを利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者は、患者へのサービスを提供していない医療機関４は選ばなくなる、これが患者へ寄り添うことの効果になると推測する。患者へ医療サービスを提供する時代が始まると考える。

【0269】

本実施形態の説明では、高齢者や病気を有している人をターゲットに説明してきた。高齢者や病気を有している人以外にも未成年者をターゲットに本開示の決済支援システム１０２を用いてもよい。未成年者をターゲットにした場合、決済などの通知先は、保護者にしてもよい。通知にする内容は、年齢により内容を変える機能があってもよい。例えば、利用者３が小学校低学年ならすべての決済の結果を通知するが、中高校生なら、予め定めた金額以上の決済の結果のみ通知するなどとなる。

【0270】

＜第５実施形態＞
従来医療機関４は、医療機関４ごとに独自の診察カードを発行し、患者（利用者３）が医療機関４を受診する際、その診察カードを持参し受付で提示することにより診療を行っていた。患者は、受診した医療機関４が増えてくると、所有する診察カードもそれに伴い増えていく。診察カードが増えていくと、カードケースや財布などの診察カードを持ち歩くために保管する場所を圧迫していき煩わしくなってくる。また、診察カードが増えてくると、別の医療機関４の診察カードを間違えて持参したり、受付で間違えて提示したりする。また、一部の病状を患わっている患者にとっては、診察カードを紛失することが起こることが日常茶飯事となっている。そのため、患者にとっては、所有する診察カードは少ないほうがよい。一部の病状を患わっている患者は、診察カード無くしてしまい再発行を繰り返しており、患者は「大事な物を盗まれてしまうから盗まれないように隠す。」といった精神的な病状意識から来る行為であり病状が完治しなければ紛失は末永く続くものである。そういった病状の患者や共に暮らす家族にとっては「無くすことが出来ない診察カード」が出来るのを待ち望んでいるでしょう。
また、医療機関４は、発行した診察カードに記載されている番号（管理番号）を用いて院内で患者を管理している。医療機関４が、カルテを電子化する際、この番号で患者を管理する電子カルテ９ａの管理番号として用いている。
本開示では、医療機関４ごとに発行されている診察カードのどこの病院４ａの診察カードでも使える、又は診察カードが無くても医療機関４の受診受付が行え、認知症や物忘れの一部患者にでも優しい診察環境を作ることを目的としたサービスのビジネスモデルを提供するものとしている。

【0271】

本開示の手法を用いた診察カードのいらない受診受付を行うために、患者は、プラットフォーム型医療機関支援システム１の医療情報共有データベース２にある医療経済圏ＤＢ２１にある患者情報ＤＢ１６１に自身の個人情報２２が登録されている必要がある。この登録は、第四実施形態に記載の医療決済口座１０４を作成することにより行える。

【0272】

診察カードを必要としない受診受付は、医療機関４の受付で、患者が、医療機関４の患者の管理番号か患者の指紋や顔といった生体情報を提示することにより行われる。医療機関４の受付で管理番号か生体情報が提示されると、プラットフォーム医療機関支援システム１と連携している医療機関４の受付システム９ｆは、ネットワーク上のプラットフォーム型医療機関支援システム１にある患者情報ＤＢ１６１を参照して個人を識別し、医療機関４内での管理番号を検索し受付を行う。管理番号や生体情報は、医療経済圏ＤＢ２１上の患者情報ＤＢ１６１にある認証情報に保存されている。この処理は、管理番号か生体情報を提示することに個人を認証できる患者認証処理システム１６２を用いて行う。
生体情報を利用した認証は、指紋認証システムや顔認証システムとして広く一般に知られている技術を利用する。第５実施形態のデータベース構成を図３０に示す。

【0273】

この診察カードのいらない受診受付が行える医療機関４同士で、管理番号の情報共有を行うことにより、別の医療機関４の管理番号を提示しても受付できるようにしてもよい。いわゆる別の病院４ａの診察カードを提示しても本人認証され受付ができるというものである。
プラットフォーム型医療機関支援システム１内の患者情報ＤＢ１６１にある個人情報２２には、複数の医療機関名とその医療機関４に該当する管理番号が保存されている。このデータベースにより医療機関名から患者の管理番号をサーチすることができるし、管理番号からどこの医療機関４の番号かもサーチすることができる。
この患者認証処理システム１６２を利用して、別の医療機関４が発行した診察カードを持参して医療機関４の受付に行った場合、患者が別の医療機関４の診察カードに記載の管理番号と管理番号を発行した医療機関名を提示すると、プラットフォーム医療機関支援システム１と連携している医療機関４の受付システム９ｆは、プラットフォーム型医療機関支援システム１内の患者情報ＤＢ１６１を参照し、提示した医療機関名と管理番号から、受付を行おうとする医療機関４の管理番号を検索処理により自動で管理番号が取得され受付を行うことができる。

【0274】

患者が、別の医療機関４の管理番号を提示や、又は生体情報を提示して受付を行おうとした際、医療機関４の管理番号が見つからなければ、新患（新規の外来患者）と判断処理をする。前記の理由で新患と判断された場合、プラットフォーム医療機関支援システム１上の患者認証処理システム１６２と連携している医療機関４の受付システム９ｆは、受付で提示された管理番号や生体情報を利用してプラットフォーム型医療機関支援システム１内の患者情報ＤＢ１６１をサーチする処理を行い患者の個人情報２２を取得する処理を行い、受付処理を行ってもよい。この受付の際、新規の診察カードの発行や、それに記載されている新規の管理番号の発行をしなくともよく、患者情報ＤＢ１６１に新規に医療機関名と医療機関４内で使用する管理番号を保存する処理がされる。
このことにより、従来では新規患者として受付に行くと診察申請書類に個人情報２２を書き込んで申請し、医療機関４は診察申請書類に書き込まれた個人情報２２を法律に従って煩わしい個人情報管理をしなければならなかった。この方法によりそれらは無くなることになる。

【0275】

従来より医療機関４で使用している医療情報システム９と、プラットフォーム型医療機関支援システム１にある医療情報システム９とが連携してシステムを併用して業務を行っている医療機関４でも本開示のこの診察カードのいらない受診受付を行うことができる。患者が、受付を行う医療機関４の管理番号の提示や別の医療機関４の管理番号の提示、生体情報の提示により受付を行おうとすると、プラットフォーム型医療機関支援システム１と連携している医療機関４の受付システム９ｆは、プラットフォーム型医療機関支援システム１内の患者情報ＤＢ１６１を参照して個人を識別する処理を行い、医療機関４内での管理番号を検索する処理を行い、検索した管理番号を従来の医療情報システム９に渡す処理を行うことにより受付が行える。システムを併用しているシステムでの利用イメージを図３１に示す。

【0276】

この機能を利用すると、医療機関４が発行した診察カードとは別に、利用者３が用意した持ち合わせの医療保険証やマイナンバーカードやクレジットカードや自治体が発行した図書館カード等の固有の番号が記載されているその番号を代替して管理番号とし、さらにカード発行先が判明できるカードを利用して患者情報ＤＢ１６１の認証情報に登録しても良い。バーコードやＱＲコード（登録商標）がカードに印刷されている物や、スマートフォンで左記のような本人固有のコードを表示できるアプリ等で画面表示できるものを利用してもよい。これら前記利用者３が用意したカードをプラットフォーム医療機関支援システム１の患者認証処理システム１６２に登録することで、医療機関４の受付で前記利用者３が用意したカードを提示することで受付が行われる。このサービスの提供により、今後医療機関４で診察カードを発行することが無くなる。１枚の診察券を複数の医療機関で利用できるシステムのシステム図を図３２に示す。

【0277】

複数の医療機関４で発行された管理番号は、医療機関４で登録するだけでなく、利用者３自身が、自らの所有する携帯端末などを用いて登録してもよい。また、利用者３が用意した持ち合わせの医療保険証やマイナンバーカードやクレジットカードや自治体が発行した図書館カード等の管理番号とカード発行先が判明できるカードの登録も利用者３が所有する携帯端末などで行える。

【0278】

ここで説明した「無くすことが出来ない診察カード」は、一部の病状を持った患者やその家族とって、今まで無くした診察カードを当事者や家族が家の中を探しまくるということから解放されることは当事者の家族にとって、「家の中を探す」ことからの解放は、患者と生活を共にしている家族しか味わえない解放感を与えるサービスである。
また、診察カードを複数保有している患者にとっても診察カードが増えていくことの弊害を無くせる利便性のあるサービスである。
また医療機関４の受付や患者の診療情報管理に関係するコストの削減ができることと、患者にとってはこのサービスは１つの医療機関４だけが実施しても全く意味の無いことであるのは言うまでも無い。医療機関４、歯科４ｆ、調剤薬局４ｂ、行政発行していた図書カードの代替としても、医療に関係している企業等と番号で管理をしている企業や自治体に利用できる。
銀行や信託銀行、証券会社などの金融機関は、それぞれ固有のキャッシュカードを発行している。これらに対して本開示の仕組みを用いることにより、どれか１枚のカードでだけ持ち歩けばどこの金融機関の窓口でもＡＴＭでも事をなすことができる。
この仕組みは、プラットフォーム型医療機関支援システム１にあるキャッシュカード共有システム１６３として下記の方法で提供される。
金融機関の情報は、銀行口座情報として医療経済圏ＤＢ２１内の患者情報ＤＢ１６１に登録されている。利用者３が、銀行口座情報に紐づいている銀行口座のキャッシュカードを利用すると、キャッシュカードに紐づいている口座だけでなく、銀行口座情報に登録されている他の口座の情報も参照できる。参照できたキャッシュカードに紐づいていない口座についても、ャッシュカードに紐づいている口座と同様に利用することができる。また、キャッシュカードが無くともスマホや生体情報などを用いて金融機関の口座を利用できるようにしてもよい。
例えば、この仕組みで作成したキャッシュカードを用いてATMを利用すると、ATMの画面上に利用者３が所有している口座のうち、キャッシュカード共有システム１６３に参加している全ての金融機関の口座が一覧で表示される。表示された口座から出入金や登録された口座間のお金の移動、振り込みなどの手続きを行いたい口座を選ぶことで、その口座を利用することができる。
特に、登録された口座間のお金の移動は、出金する口座と入金先の口座を選択することで容易に行うことができる。通常、口座間のお金の移動は、出金元口座のキャッシュカードを利用して出金を行った後、入金先口座のキャッシュカードを利用して入金を行う。この作業は、全国キャッシュサービス（登録商標）に接続している金融機関の場合１台のATMで行うことができるが、手数料などの理由により多くの場合、出金元の金融機関のATMで出金を行った後、入金先の金融機関のATMへ移動して入金を行うため非常に面倒である。
１枚のキャシュカードで銀行口座を共有するシステム図を図３３に示す。
ここで似たような事を行っている政府主導のマイナンバーカードに触れたい。
マイナンバーカードに記載されている国が管理する番号（マイナンバー）に対して、免許証や保険番号等の紐つけが行われているが、国民にとってその利便性は、免許証の１枚が財布から消えることを感じる事くらいでしょうか。その反面、紐付けされる番号の所有事業者においては番号管理という業務は無くならず従来のカード発行や管理コストも下がらず事業側の利便性は感じられない。
マイナンバーカードと本考案の相違は、マイナンバーカードをピラミッドの頂点としてマイナンバーカードに他のカードを紐つけているものです。この事は、マイナンバーカードを紛失してしまうと、何も効果を発揮しないことになり、マイナンバーカードの仕組みでは「無くすことが出来ない診察カード」にはなれないということになる。
それに対して本考案は、様々な医療機関４で発行された診察カードの管理番号と医療機関名と生体認証とを相方向に紐づけられていることで、どの診察カードを無くしても１枚あれば目的は達成できるし、さらに顔があれば目的にたどり着くことができるこの仕組みはまさに「無くすことが出来ない診察カード」と言えることができる。
診察カード以外のカードやコードが使えることも自由度が広がる仕組みとなっている事もマイナンバーカードとは相違している。
「無くすことが出来ない診察カード」は、医療機関４へのサービスと患者へのサービスを備えたもので、特にこれからの医療は、患者へのサービスを提供することが重要と考えています。
そのために１つの医療機関４だけで無く、医療経済圏２４を利用する全ての医療機関４が情報を共有することで患者へサービスを提供することができる。
プラットフォーム化されているシステムを医療経済圏２４の中で、沢山の医療機関４と情報を共有することでそれぞれの医療機関４が、患者へサービスを提供することとなり、
さらに他の実施形態で説明しているサービスを医療経済圏２４の中で利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者はこのシステムを利用していない医療機関４、すなわち患者へのサービスを提供していない医療機関４は選ばなくなる、これが患者へ寄り添うことの効果になると推測する。患者への様々な医療サービスの時代が始まると考える。

【0279】

ここまで開示した手法を利用することにより、医療機関４は、診察カードを発行しなくても受付を行えるようになり、診察カードを発行するために必要なコストの削減につながる。また、他の医療機関４の診管理番号や生体情報を用いて受付が行えるため、一部の病状を持った患者が、診察カードの紛失や忘れや他の医療機関４の診察カードを間違えて提示しても受付が行えるようになる。従来、診察カード忘れた時などで行われていた、患者から氏名などの個人情報２２を聞き出してカルテの情報から患者を探すなどを行っていた受付の人員の削減ができるようになるため、人件費削減による医療経営の負担軽減にもつながる。また、患者にとって、特に一部の病状を患った患者にとって、診察券を必要としない医療機関４の受付処理と管理番号による患者の情報管理のプロセスは利便性のあるものであり、最適なビジネスモデルとして複数の医療機関４に提供が行えるものである。
また、本開示システムを多くの医療機関４で導入することにより、国内医療機関４が共通に行っている診察受付システム９ｆの共通基盤となり、受付における受付人員削減と医療経営の負担軽減の提供と、患者に対して保有する複数診察券の管理の簡素化をするシステムを使用したサービスの提供は、患者にとって診察券を必要としない医療機関４の受付処理と管理番号による患者の情報管理のプロセスのビジネスモデルの提供が行える。

【0280】

＜第６実施形態＞
現在、医療機関４の診療科の偏りや診察時間の偏りが酷いため、地域によっては夜間や休日に対応できる病院４ａがない場合もある。
例えば、平成２９年に厚生労働省が調査した結果によると、全国で一般内科を標榜する病院４ａや医院が約７１０００軒ある一方、産科または産婦人科を標榜する病院４ａや医院が約４６００軒となっている。また、歯科医師５ｄを標榜する病院４ａや医院が約６８０００軒となっている。歯科４ｆの数はコンビニの出店数を若干上回り、一般内科の数は、コンビニエンスストアの出店数よりも３割多い。しかし、産科または産婦人科は非常に少ない。これでは人口減少が進むと医療機関４が多く適切な医療体制とは言えない。
本開示では、夜間や休日など医師５ａが少ない時間を含む２４時間診療できる病院４ａの開設と地域内で不足している診療科の開設することによって、新しい地域医療体制を再編成や人口減少へ対応した医療機関数や医療体制にする事を目的としている。この目的を実現するために、医療機関数を増やすのでは無く医療提供時間を広げるという目的での２４時間診察を行う医療機関４（２４時間医療機関４ｇ）に変えていく方法や、もう一つの方法も医療機関数を増やすのではなく不足している診療科を有する医療機関４に変えていく方法と２４時間医療機関４ｇや多診療科医療機関４ｈに変えていく上で、必要となる情報システムとを本実施形態で説明する。

【0281】

２４時間診察を行う医療機関４に変えていく方法や、不足している診療科を有する医療機関４に変えていく方法について、又は地域における医療機関４や医療体制の検討を取得できる様々な情報から行う方法について説明する。
まず、本開示の医療機関開業支援システム１７１は、地域内の医療情報である地域医療情報を取得する。地域医療情報は、プラットフォーム型医療機関支援システム１の医療情報共有データベース２にある医療経済圏ＤＢ２１にある情報で、地域自治体の情報と地域の医療機関４の医療情報システム９より取得できる情報とであり、毎年蓄積される情報となっている。
地域自治体の情報は、人口と、年間外来患者数、年間入院患者数、世代別人数と、診療科別の医療機関数と、各医療機関４の年間患者数と、診療科別の医療機関数と、診療科別の年間患者数、緊急病院数と、緊急病院の年間患者数と、緊急病院で扱った病名と患者数と、診療科別の医師５ａの人数と、看護職の人数などの情報のことを示す。
地域の医療機関４の医療情報システム９より取得できる情報は、年間外来患者の年齢毎の病名と数、年間入院患者の年齢毎の病名と数などの情報のことを示す。

【0282】

プラットフォーム型医療機関支援システム１にある医療機関開業支援システム１７１は、地域医療情報に保存されている情報から取得し、地域の医療機関計画に必要とする様々な分析値や再計画するために必要な様々な計画値の算出する処理を行う。
また、自治体や医師会は、本開示の医療機関開業支援システム１７１を用いて地域内の現在の医師５ａの年齢から医師５ａとして働ける定年時期とを見据えて、事業継承計画や事業継承診療科計画の作成を自治体や医師会で行う。作成するこれらの計画は、事業継承に関係する情報であり、自治体や医師会が決めた医師５ａの定年時期に間に合うように、病院４ａや病院内の個別の診療科の事業継承を行う計画となっている。
計画した事業継承に関係する情報や算出した地域の医療機関計画に必要とする様々な分析値や再計画の内容は、地域医療計画情報として医療経済圏ＤＢ２１に保存される。
さらに、地域住民への最適な医療体制と医療機関４の持続化を構築するための計画立案に必要な情報を導き出す算出処理を行うために、医療機関開業支援システム１７１は、地域医療情報に保存された様々な情報を取得する処理を行い、医療体制を計画する上で必要な様々な目線や視点で考察が行える情報として導き出せる算出方法による処理を行い、算出処理された情報を使用して、自治体や医師会が立案する様々な計画値を入力し、その入力された情報も地域医療計画情報として医療経済圏ＤＢ２１に保存し蓄積される。
医療機関開業支援システム１７１は、毎年更新される地域医療情報を利用して、前年の計画値との差異から計画の進行状況と再計画の指標を表示する処理をし、さらに関係者へ通知する処理も行う。

【0283】

第６実施形態のデータベース構成を図３４に示す。

【0284】

計画値の情報において、地域内に診療科が不足している場合は、医療機関４を増やす方法や、コスト配慮し医療機関４同士の患者の取り合いを防ぐ既存の医療機関４に診療科に変更する方法なども地域医療計画情報に保存される。

【0285】

計画値の情報において、地域内に２４時間医療機関４ｇが不足している場合は、２４時間医療機関４ｇや医師５ａ及び看護師５ｂを増やす方法と、将来の人口減少を見据えて医療機関４を増やさずそして開院コスト重視した既存の医療機関４に複数の個人事業医師５ａにより２４時間医療機関４ｇに変更する方法と、人権費削減する無人化や自動化の計画と、医療コスト削減計画と、医療技術の分散化や逆に集中化なども地域医療計画情報に保存される。

【0286】

地域内に診療科が不足している場合、または、地域内に２４時間医療機関４ｇが不足している場合は、ネットワーク上の外部システムの地図サイトや統計処理サイトへの情報を連携することにより、再計画した情報の表示を可視化する処理を行う。計画の進行状況と再計画を行うかの指標を表示する処理を行い合わせて、計画値との差異の有無と、差異の大きさが確認できる表示処理も行う。まこの差異をもとに、毎年繰り返し目標値を修正しながら計画を遂行していく。
また、指標を表示する処理により確認ができる事と関係者へ計画値の通知処理をする事もでき、結果、地域の現在人口状況と将来の推測した人口状況に合わせ、地域医療に最適な医療体制と医療機関４の持続化を行うための計画立案や計画修正を行うための見える化した情報サービスの提供が行え、２４時間医療機関４ｇを増やすことや不足している診療科を有する医療機関を増やすことにつながる。

【0287】

２４時間医療機関４ｇや多診察科診察医療機関４ｈを増やした医療機関４での事務を効率化する提案について説明する。
地域における医療体制を再編成し充実するため又は人口減少へ対応した医療体制にするために、医療機関数を増やさずに既存の医療機関４を利用して複数の個人事業医師５ａが医療設備を共有し診療を行う新しい医療経営形式とした２４時間診療医療機関４ｇや多診察科診察医療機関４ｈに変える。このことにより医師５ａも余る事は無く働ける場を保つことができる。２４時間診療医療機関４ｇや多診察科診察医療機関４ｈにすることにより、持続化する医療機関経営を行う医療機関４となることが期待できる。
既存の医療機関４を複数の個人事業医師５ａが医療設備を共有し診療を行うとは、既存の医療機関４が診察を行っていない朝や夜などの時間帯に既存の医療機関４の医師５ａとは別の医師５ａにスペース（診察室）を貸して診察を行ってもらう、または、既存の医療機関４が診察を行っている時間帯でも使用していない診察室を既存の医療機関４の医師５ａとは別の医師５ａにスペースを貸して診察を行ってもらうことを示す。このことは、夕刻から夜間しか営業しない居酒屋が眠っているランチの時間帯を別の業者へ間貸しにより居酒屋収益以外に賃料を得る事の変化版と同じである。既存の医療機関４が別の医師５ａにスペースを貸す際、既存の医療機関４と貸出先とは別々の医療機関４とする。別々の医療機関４とすることで、大きな総合病院４ａの大きな組織の病院４ａを作らずに大きな病院４ａと同等の標榜科をもつ医療機関４となる。また、１つ１つの医療機関４は、規模が小さいため、法人税の抑制効果も期待できる。

【0288】

複数の個人事業医師５ａが医療設備を共有し診療を行う際、従来のＩＴシステムを使用するには問題となる事がある。また、医師５ａごとに別々のITシステムを利用してはコストパフォーマンスが悪くなる。そこで、既存の医療機関４と貸出先の医師５ａとが共有して利用でき、他の医療機関４でも利用できるプラットフォーム型のシステムである医療機器間共同利用システム１７２を構築する。
医療機器間共同利用システム１７２は、プラットフォーム型医療機関支援システム１に上にある、医療情報システム９、医療機関経営事業支援システム１０、医療機関決済支援システム１０２、診療報酬計算システム１７３、診療報酬自動請求システム１７４の５つのシステムにより構成される。

【0289】

既存の医療機関４を２４時間診療医療機関４ｇとしてリニューアルする場合において、従来の医療機関４で利用しているＩＴは、１医療機関４での医師５ａによる利用を前提にしたＩＴのために、同一医療機関４にある端末パソコンを時間毎の時系列的に共有利用して複数個人事業医師５ａの間で診察と経営の両方のＩＴが利用できず、特に病院経営上の経営情報は個人事業医師５ａの間でのプライバシーを保って利用できるものではない。そこで、医療機器間共同利用システム１７２を利用し、同一住所・同一医療機関４の複数個人事業医師５ａとの間で情報の共有部分と非共有部分と病院経営上の経営情報はプライバシーを備え、診療と経営に関して時間毎に複数個人事業医師５ａとの間でそれぞれ時系列型事業経営を行えるようにする。２４時間診療医療機関４ｇの例を図３５に示す。

【0290】

既存の医療機関４を前記多診察科診察医療機関４ｈへのリニューアルの場合において、従来の医療機関４で利用しているＩＴは、１医療機関４での医師５ａによる利用を前提にしたＩＴのために、同一住所・同一医療機関４の複数人の個人事業医師５ａによる多診察科による並列型事業経営で、複数個人事業医師５ａの間で診察と経営の両方のＩＴが共有利用できず、特に病院経営上の経営情報はプライバシーを保って利用できるものではない。そこで、医療機器間共同利用システム１７２を利用し、同一住所・同一医療機関４の複数個人事業医師５ａとの間で、情報の共有部分と非共有部分を備え、診療と経営に関して多診察科による複数の個人事業医師５ａとの間でそれぞれが同時に並列型事業経営を行えるにする。多診察科診察医療機関４ｈの例を図３６に示す。

【0291】

医療機器間共同利用システム１７２を利用することで、時系列的に複数個人事業医師５ａとの間で共有する情報や、多診察科による複数個人事業医師５ａとの間で共有する情報は、電子カルテ９ａと言われる、患者の個人データや患者診療情報と処方箋情報、診療受付情報、診療予約情報、患者紹介情報、医薬購入品情報などであある。一方、時系列的に複数個人事業医師５ａとの間で非共有する情報や、多診察科による複数個人事業医師５ａとの間で非共有とする情報は、経理情報、経費情報、事業経営情報、従業員情報、給与情報、税情報などの医療機関経営に関する情報となっている。

【0292】

２４時間診療医療機関４ｇの前記時系列事業、及び前記多診察科診察医療機関４ｈの前記並列型事業のそれぞれの仕組みを説明する。リニューアル前の医療機関４の事業主は、複数個人事業医師５ａからの賃料収入が受けられるメリットがあり、複数個人事業医師５ａは、医療施設を間借りするため開業資金が不要となるメリットを兼ね備えている仕組みとなっている。この仕組みは医療機器間共同利用システム１７２を利用しておこなわれる。

【0293】

結果、地域の人口減少化における地域で既存の医療機関４を２４時間診療医療機関４ｇとして経営支援を行う医療経営支援サービスの提供と、地域の人口減少化における地域で既存の医療機関４を多診察科医療機関４ｈとして経営支援を行う医療経営支援サービスの提供が行える。

【0294】

２４時間診療医療機関４ｇや多診察科医療機関４ｈでは、医師５ａごとに別々の医療機関４となっている。別々の医療機関４となっているため、医療機関４毎に行う事務作業も別々に行う必要がある。しかし、本開示の２４時間診療医療機関４ｇや多診察科医療機関４ｈでは共通のシステムを利用しているため、事務作業をまとめて行うこともできる。事務作業をまとめて行う例として、診療報酬の請求を用いて説明を行う。
本開示で医療機関４は、医療機器間共同利用システム１７２を利用している。このシステム内には診療報酬の計算を行う機能をもつ診療報酬計算システム１７３がある。従来の医療機関４での診療報酬の計算は人による計算となっている。また、診療報酬の計算をコンピュータで行う方法は沢山の考案も出ている。本開示では、計算方法は請求せず、計算のさせ方と計算結果の出し方に対しての考案となっている。
診療報酬計算システム１７３は、２４時間診療医療機関４ｇや多診察科医療機関４ｈで診察事業を行う個人事業医師５ａが診察した患者の診療点数を計算した結果の診療報酬を、同一住所・同一医療機関４の診療報酬として処理するのではなく、それぞれの個人事業医師５ａの診療報酬として処理する。この処理は、健保組合などの保険者や自治体に対して個人事業医師５ａとして診療報酬の請求であり、２４時間診療医療機関４ｇまたは多診察科診察医療機関４ｆへの経営支援を行うためのサービスとして提供を行う。従来の診療報酬の請求は、１医療機関１請求を行っていたが、本開示では、１医療機関の個人事業医師５ａごとに請求する形となっている。

【0295】

診療報酬計算システム１７３で計算した結果は、プラットフォーム型医療機関支援システム１に上にある、診療報酬自動請求システム１７４による処理がされる。診療報酬自動請求システム１７４は、送られてきた計算結果をもとに健保組合なの度保険者や自治体に対して診療報酬の請求の処理を行う。
２４時間病院での個人事業医師から診療報酬を請求するイメージ図を図３７示し、多診療科病院での個人事業医師からそれぞれ診療報酬を請求するイメージ図を図３８に示す。
この診療報酬の請求処理は、医療経済圏ＤＢ２１内の企業情報２３の１つとして保存されている効率医療機関情報を参照し、同一住所、同一医療機関４に複数の個人事業医師５ａの保険医が存在する場合に複数の個人事業医師５ａのそれぞれの診療報酬を合計する処理を行いして健保組合などの保険者や自治体に対して診療報酬の自動請求する処理を行う。
効率医療機関情報には、同一住所、同一医療機関４の個人事業主の情報と、個人事業主の保険医としての情報が保存されている。
保険者や自治体から受け取る診療報酬は、プラットフォーム型医療機関支援システム１の医療決済口座１０４を使用して行い、同一医療機関４の医療決済口座１０４に支払情報が移動され、複数の個人事業医師５ａの診療報酬は、同一医療機関４の医療決済口座１０４から、個人事業医師５ａの診療報酬相当額がそれぞれ受取れる。同一病院として診療報酬を一括請求し、分配受領するイメージ図を図３９に示す。
結果、保険者及び自治体に対して請求する診療報酬の自動請求と診療報酬の受取までができるサービスとなり、２４時間診療医療機関または多診察科診察医療機関への経営支援として提供を行う。

【0296】

多診療科医療機関４ｈの場合は、同一の時間帯の複数の個人事業医師５ａが診察を行っている。１つの施設内で個人事業医師５ａがスタッフを雇用するのは人件費の無駄となる。そのため、医療機関４で働くスタッフの雇用を共有することで、各個人事業医師５ａの人権費の軽減が行える。各個人事業医師５ａがスタッフの共有するにあたり勤怠や給与の管理を各個人事業医師５ａが共同で行う必要がある。この管理は、プラットフォーム型医療機関支援システム１にあるスタッフ共有機能を用いて行うことができ、複数の個人事業医師５ａはスタッフ給与管理が軽減された形で自動で行われる。
結果、多診療科医療機関４ｈ内で働くスタッフの雇用を共有するサービスとなり、個人事業医師５ａへの経営支援として提供を行う。

【0297】

＜第７実施形態＞
本開示のプラットフォーム型医療機関支援システム１は、医療情報共有データベース２にある医療経済圏ＤＢ２１にある患者情報ＤＢ１６１から患者ごとに使用している薬の名称や薬の使用量（処方量）や患者の年齢・性別といった属性情報、患者の既往歴や疾病の転帰などを地域処方情報として取得できる機能を有している。また、ネットワーク上の外部システムを利用することにより、取得した薬の名称から効能などを含む薬の種類を取得する機能も有している。医療機関４の電子カルテ９ａから薬の使用量を取得する機能の一例として、出願人考案の特開２０２０−１２３１０６などがある。また、ネットワーク上の外部システム利用することにより、取得した薬の名称から効能などを含む薬の種類を取得する機能も有している。例えば、取得した薬の名称がアセチルサリチル酸（アスピリン）やイブプロフェンの場合、薬の種類は鎮痛剤となり、取得した薬の名称がオルセタミビルやザナミビルの場合、薬の種類はインフルエンザに対する抗ウィルス薬となる。医療機関４において、患者に対し使用が指示される薬は、院内で患者に投薬することにより使用するものと、医師５ａが患者に処方せんを渡して患者が処方薬を直接購入して使用してもらうものとに分かれる。本開示では、外来患者と入院患者に処方せんを渡して患者に使用してもらっている薬の「薬の処方量又は使用量」と記載する。
また、１つの医療機関４を受診している患者全体の薬の使用量は、取得した薬の使用量を、薬品名毎に合計することにより算出でき、医療機関４における薬の使用量とすることができる。
医療機関４の患者全体の薬の使用量は、集計対象の医療機関４の電子カルテ９ａから患者ごとの薬の使用量を取得し、薬品名毎に合計する処理となる。医療機関４の患者全体の薬の種類ごとや薬品名ごとに合計する処理した薬の使用量を地域処方量情報として医療経済圏ＤＢ２１に保存する。
また、１つの医療機関４に限らず、一定地域内にある複数の医療機関４での処方した薬の使用量も算出の処理を行う。
また、地域処方ＤＢ１９１には、同一薬品情報として製薬メーカー違いの同一有効成分の薬を１種類の薬とみなす情報が保存されている。同一薬品情報を用いて地域処方量情報として合計した医療機関４の患者全体の薬の種類ごとや薬品名のうち同一有効成分の薬を１種類の薬として再集計し、疾病処方情報として医療経済圏ＤＢ２１に保存する。
一定地域とは、市区町村などの行政地域や経済圏や商圏などの機能地域、医療圏などのことを示す。また、これらを複数組み合わせた地域も一定地域に含んでいる。この一定地域内に存在している医療機関４全体で扱っている薬品をまとめて地域の統合した薬品として扱う、という考えである。
一定地域内に合計対象となる医療機関４が１つないし少数しかない場合は、後述する理由により、あまり好ましくない。そのため、集計対象となる一定地域を拡大して複数の地域とした複数の医療機関４を合計し数を増やして薬品名毎に合計を算出する処理を行うことでもよい。一方、一定地域内に合計対象となる医療機関４が多くより小さい単位の地域でも薬品名毎に合計することによるスケールメリットが十分得られる場合や規模が大きすぎるためにスケールデメリットが発生する場合は、地域を分割または縮小して、薬品名毎に合計を算出の処理をするようにしてもよい。

【0298】

第７実施形態のデータベース構成を図４０に示す。

【0299】

地域処方量情報や疾病処方情報として一定地域内で薬品名毎に合計することにより、地域内にある複数の医療機関４の全てで処方される薬をまとめて一括購入する包括契約による購入など、スケールメリットを生かし、薬を安く購入することが期待できる。（これをボリュームディスカウントとも社会では呼ばれている）スケールメリットを生かすためには、ある程度まとまった量が必要となるため、一定地域内に合計対象となる医療機関４が１つないし数少ない場合、スケールメリットが受けにくくなる。
また、包括契約による購入以外にも、購入量に関わらず、契約期間内は定額で購入できるサブスクリプション購入でもよい。契約期間は協議により年度単位で決められる。
従来、医療機関４は、医療機関４ごとに薬を購入しており、購入単位は一箱などの小口であった。本開示の手法の場合、複数の医療機関４と共同し、大量購入契約となるため、全ての医療機関４が同一価格となり価格を下がることは従来とは全く違う処方薬の購入方法となる。
包括契約による購入やサブスクリプション購入は、医療機関４や患者視点からすると、薬の価格が安くなることが期待できる。サブスクリプション契約で薬の使用量が安くなる例として、出願人考案の特願２０２１−０２０７１９に開示の手法などがある。この考案は、身体のサイズから薬量を算出し生涯服用する患者の薬代をサブスクリプション契約により薬代を下げるものである。それに対して本考案は、対象を地域全体の医療機関４が扱う薬品へと変えたことによる地域の医療経営効果を狙った考案となっている。

【0300】

今まで医療機関４目線による購入メリットと、患者目線による処方薬が安くなることを記載したが、薬の提供業者である製薬会社側においてはどう影響がでるのか説明すると、メリットがある。
また、薬の製造者側からすると、包括契約では、契約により数量は全て契約した製薬会社からの提供となるため、この地域全での医療機関４からの大型契約のため契約した数量までは他社への発注は無く契約した一社が地域を独占する提供状態となり、大量受注できるため、工場側で生産スケジュールを建て易く工場での資材調達も計画し易い、さらに売り上げの予定が立てやすい。また、サブスクリプション契約においては、契約期間中は競合他社からの販売参入を許さず地域の医療機関４の全てを一社独占販売状態で営業できることになり売上は上がる、さらに、年間受注量と需要が多い時期が分かれば、さらに、生産スケジュールが立て易くなる。
このように、患者、医療機関４、製造側においてメリットとなる提供方法である。
しかしながら、デメリットもある。
医療機関４は、包括契約及びサブスクリプション契約のどちらも安い価格での購入になるため止められなくなる。
包括契約及びサブスクリプション契約のどちらも契約ができなかった場合、どちらにおいても契約が切れるまでの間の大型受注は全く無いことになる。先行して契約した企業との契約が切れる頃になると、敵対会社との間で自然な形で競争が始まるのは医療機関４や患者にとって望むことである。
大手の民間企業は2000年より包括契約及びサブスクリプション契約による資材やソフトウェアの調達が始まったが、今現在においても止められずに続いている。さらに大手のみだった範囲から資本系列会社に、そして下請け会社へと範囲は拡大してきている。

【0301】

一定地域内の医療機関４のうち医療経済圏２４に属する医療機関４が薬を包括またはサブスクリプションで購入する方法は、医療経済圏ＤＢ２１にある企業の事業情報から、薬の発注先の候補に、見積もりを依頼し、見積もりの依頼の結果、発注先の候補から返答があった業者の中から一番有利な条件を提示した業者を発注先とする。一番有利な条件を提示した業者とは、通常は、見積額が一番安価な業者のことを示す。この手法は、第１実施形態に開示のシステムと同様の手法である。

【0302】

医療経済圏２４を利用する医療機関４において、一定地域内に所在している複数の医療機関４で患者へ処方する薬品の発注を包括契約で行い薬品を購入する処方リカーリングシステム２０２について記載する。
包括契約での薬の購入は、プラットフォーム型医療機関４支援システム１の処方リカーリングシステム２０２を用いて行う。このシステムを利用して契約の受注を行う事業社は医療経済圏ＤＢ２１の企業の事業情報に登録されている医療機関４と医薬品販売の事業者である。「医療経済圏２４を利用する医療機関４で患者へ処方する薬品の種類ごとや薬品名ごとに薬の使用量の情報は、医療経済圏ＤＢ２１に地域処方情報として保存されている。
この地域の複数の医療機関４の使用量を合計した地域全体の使用量が、ボリューム発注量となって、従来購入価格より安く購入できる価格での契約を行うことになる。
さらに包括契約に適する薬品と購入先企業（包括契約先企業）を選定する必要がある。この選定する処理方法に、処方薬包括選定ＡＩという人口知能（ＡＩ）を利用することで煩わしい選定の自動化が図れる。
処方薬包括選定ＡＩのプログラムは、ボリュームディスカウウントでの購入ができそうな薬品、過去に購入実績のある薬品及び発注量、過去に包括契約実績のある薬品等から薬品を選定し、包括契約によるボリュームディスカウウント価格を受けてくれそうな企業又は、過去に契約実績のある企業を包括契約先候補企業として選定をする処理を行う。
候補選定する対象の企業は、医療経済圏ＤＢ２１にある企業の事業情報に薬の発注先企業として登録されている企業（製薬卸会社や製薬会社や製薬企業）である。
選定するために必要な情報として、薬の最少発注量の目安の情報、発注する薬品名の情報、薬品の発注量の情報、包括契約先候補企業の情報、納期の情報が、医療経済圏ＤＢ２１にある処方リカーリングＤＢ２０１の包括情報として保存処理される。
複数の医療機関４で包括した薬において一部の薬品の発注量が、薬の最少発注量の目安までに足りなかった場合は、医療機関４の数を増やして発注量を調整するか、その薬品だけ包括する品目から削除するかのいずれかを選択する処理を行う機能も有している。
包括契約価格を決めるため、処方リカーリングシステム２０２は、包括情報に保存されている包括契約先候補企業に対して、包括契約の価格見積依頼を行う通知を送る処理を行う。この通知には、包括情報に保存されている発注する薬品名の情報、薬品の発注量の情報等の包括契約に必要な様々な情報が記載されている。この通知に対する回答を包括契約先候補企業から受信した包括回答情報は処方リカーリングＤＢ２０１に保存する処理が行われる。

【0303】

包括契約の見積依頼を受け取った包括契約先候補企業は、従来のような形で見積書を作成すればよいという訳ではない。包括契約とは、ある意味契約薬品の独占契約を行うもので、その契約数量は地域で包括した地域で発注する総数量となっている。この契約を死守できないと契約期間中の地域からの受注は「ゼロ」となるのはわかりきっているため、競合他社との談合等が成り立たない仕組みとなっている。地域の発注する総数量は大口な数量のため営業部門の契約というよりも企業が契約するという形になるため、企業トップクラス同士の談合は成り立たないし、見積者の契約金額だけを機械処理して選定するものでは無い。包括契約先候補企業は、契約を得るために契約内容にも力を注いだものとなるのが普通である。

【0304】

包括契約の締結は、処方リカーリングシステム２０２による電子契約で行われる。
処方リカーリングシステム２０２は、処方リカーリングＤＢ２０１上の包括回答情報から包括契約を行うに有利な企業を自動選定し、その選定した企業を契約先としたデジタル契約書を自動で作成し、契約先企業と処方リカーリングシステム２０２の双方がデジタル署名により締結の処理を行う。
処方リカーリングシステム２０２によるデジタル契約書を自動作成する処理は、契約書テンプレートを利用し、契約書作成に必要な情報は、包括回答情報に保存されている回答企業名、薬品名、薬品の数量、契約金額等の情報、支払条件を取得し契約書テンプレートにインプットする処理によりデジタル契約書が作成される。

締結完了とともに薬の発注を自動で処理を行う機能を有している。この契約に関わる契約先企業や契約金額等や契約年月日や契約に必要な様々な情報も包括情報として保存する処理が行われる。
すなわち、包括契約に関わる様々な詳細情報が、処方リカーリングＤＢ２０１に包括情報として保存されている。

【0305】

処方薬包括選定ＡＩについて説明する。
処方薬包括選定ＡＩは、機械学習の手法を用いて、ボリュームディスカウウントでの購入ができそうな薬品と包括契約先候補企業とを選定する人工知能である。
これらの選定は、地域処方情報として保存された情報や包括情報として保存された情報を利用して教師なし学習のうちアソシエーション分析の手法を用いて行う。

【0306】

医療経済圏２４を利用する医療機関４において、一定地域内に所在している複数の医療機関４で患者へ処方する薬品の発注量をサブスクリプション契約により薬品を購入する、サブスクリプション契約について記載する。
サブスクリプション契約での薬の購入は、プラットフォーム型医療機関支援システム１の処方サブスクリプションシステム２０３を用いて行う。この処方サブスクリプションシステム２０３を利用して契約の受注を行う事業社は医療経済圏ＤＢ２１の企業の事業情報に登録されている医療機関４と医薬品販売の事業者である。
医療経済圏２４を利用する医療機関４で患者へ処方する薬品の種類ごとや薬品名ごとに薬の使用量の情報は、医療経済圏ＤＢ２１に地域処方情報として保存されている。
この地域の複数の医療機関４の使用量を合計した地域全体の使用量が、一定年期間は通常の購入価格よりディスカウウントされた定額で購入できる契約を行うことになる。
さらにサブスクリプション契約に適する薬品と購入先企業（包括契約先企業）を選定する必要がある。この選定する処理方法に、処方薬サブスク選定ＡＩという人口知能（ＡＩ）を利用することで煩わしい選定の自動化が図れる。
処方薬サブスクＡＩのプログラムは、一定年期間のボリュームディスカウウントでの購入ができそうな薬品、過去に購入実績のある薬品、発注する量、通常価格、過去にサブスクリプション契約の実績のある薬品、等からから薬品を選定し、選定した薬品をサブスクリプション契約でボリュームディスカウウント価格を受けてくれそうな企業又は、過去に契約実績のある企業をサブスク契約先候補企業として選定をする処理を行う。
候補選定する対象の企業は、医療経済圏ＤＢ２１にある企業の事業情報に薬の発注先企業として登録されている企業（製薬卸会社や製薬会社や製薬企業）である。
選定するために必要な情報として、薬の最少発注量の目安の情報、発注する薬品名の情報、薬品の発注量の情報、現在の薬価の情報、包括契約先候補企業の情報、契約期間の情報、契約執行日の情報が、医療経済圏ＤＢ２１にある処方リカーリングＤＢ２０１の処方サブスク情報として保存の処理が行われる。
複数の医療機関４でまとめた薬において一部の薬品の発注量が、薬の最少発注量の目安量までに足りなかった場合は、医療機関４の数を増やして発注量を調整するか、その薬品だけ包括する品目から削除するかのいずれかを選択する処理を行う機能も有している。

サブスクリプション契約を行う薬品は、包括契約を行う薬品とは選定の基準が違う。サブスクリプション契約を利用する薬は、使用量ジェネリック薬品として同種効能の薬品が複数の企業から販売されている場合、企業側が独占提供を狙う。
癌の免疫療法に使用する薬（ニボルマブ）、高価な抗がん剤、脊髄性筋萎縮症遺伝子治療薬、等の薬を長い期間で安く購入できる契約を結んだ方が有利である。

サブスクリプション契約の価格を決めるため、処方リカーリングシステム２０２は、処方サブスク情報に保存されているサブスクリプション契約先候補企業に対して、サブスクリプション契約の価格見積依頼を行う通知を送る処理を行う。この通知には、処方サブスク情報に保存されている発注する薬品名の情報、薬品の発注量の情報等のサブスクリプション契約に必要な様々な情報が記載されている。この通知に対する回答をサブスクリプション契約先候補企業から受信したサブスク回答情報は処方リカーリングＤＢ２０１に保存する処理が行われる。

【0307】

サブスクリプション契約の見積依頼を受け取ったサブスクリプション契約先候補企業は、従来のような形で見積書を作成すればよいという訳ではない。サブスクリプション契約とは、ある意味一定年期間（例えば１年〜５年）における長期に渡る薬品提供の独占契約を行うものである。サブスクリプション契約先候補企業は、この契約を勝ち取るためのプライスを提供しなければならない課題がある。契約がとれなければ、長い年月に渡りこの地域からの受注は「ゼロ」となるのはわかりきっているために、企業は自社製品の優位性をアピールするため契約者（医療機関４）にとっても価格以外にメリットのある様々なアイデアを入れた契約内容に力を注ぐ形で契約を勝ち取ろうとする。サブスクリプション契約は、いわば企業側のアイデアの結集ともいえる契約体系となっている。

【0308】

サブスクリプション契約の締結は、処方リカーリングシステム２０２による電子契約で行われる。
処方リカーリングシステム２０２は、処方リカーリングＤＢ２０１上のサブスク回答情報からサブスクリプション契約を行うに有利な企業を自動選定し、その選定した企業を契約先としたデジタル契約書を自動で作成し、契約先企業と処方リカーリングシステム２０２の双方がデジタル署名により締結の処理を行う。
処方リカーリングシステム２０２によるデジタル契約書を自動作成する処理は、契約書テンプレートを利用し、契約書作成に必要な情報は、包括回答情報に保存されている回答企業名、薬品名、薬品の数量、契約金額等の情報、支払条件を取得し契約書テンプレートにインプットする処理によりデジタル契約書が作成される。
締結完了とともに薬の発注を自動で処理を行う機能を有している。この契約に関わる契約先企業や契約金額等や契約年月日や契約に必要な様々な情報も処方サブスク情報として保存する処理が行われる。
すなわち、サブスクリプション契約に関わる様々な詳細情報が、処方リカーリングＤＢ２０１に処方サブスク情報として保存されている。処方薬をサブスクリプション契約するイメージを図４１に示す。

【0309】

処方薬サブスクＡＩについて説明する。
処方薬サブスクＡＩは、機械学習の手法を用いて、サブスクリプションでの購入ができそうな薬品とサブスク契約先候補企業とを選定する人工知能である。
これらの選定は、地域処方情報として保存された情報や処方サブスク情報として保存された情報を利用して教師なし学習のうちアソシエーション分析の手法を用いて行う。

【0310】

ここまでの包括契約とサブスクリプション契約とによる購入で、契約先に選定される企業はほぼ製薬会社等の薬品製造企業が必然的に契約相手となってしまう。それは、契約前の見積の時点で契約価格に優位性がでてしまう。薬品製造企業と医療機関４との中間に位置することで中間コストがかかってしまう薬品卸企業からの見積では価格的に劣ってしまう。中間コストをそぎ落とした流通構造を狙った、出願人考案の特願２０２１−０２０７１９に記載の流通コスト等の中間コストを削減するために薬の生産業者と利用者３（患者や医療機関４）を直接結ぶことで医療業界の流通構造を変えて薬品価格が下がるなどとした発明のことである。
人的に営業活動受注活動を行っている医療業界では昭和の時代から目に見えない様々な利権関係が働いており、様々な業務の面でコストを落とす事をそれぞれの医療機関４が真剣に考えてはこなかった。本考案の医療経済圏２４のシステムを利用することにより、人を介さないシステムによる発注になることでコストを削減することができるようになる。
これは、外来患者への処方薬に一般的な総合感冒薬として風邪をひいた時に医師５ａから外来患者へ処方されるPL剤という処方薬を算出モデルに選び、その他に入院患者が一番入院費のかからない盲腸で手術を行った時に使用される一般的な薬品を算出モデルに選び、この２つのモデルを利用した。年間の外来患者数と入院患者数でシミュレーションした結果である。このシミュレーションでは、薬品卸事業社の中間コストのみ対象とし、実際の効果が期待されるディスカウント価格は算出が不明であるためシミュレーションの算出には付加していません。対象とした都市は、東京都新宿区、外来患者数４４万人、入院患者数２０万人として算出したものである。この結果だけでも年間１億５千万円の削減ができることが確認でき、実際に包括契約とサブスクリプション契約による効果は期待できる以上のものになると推測できます。これは患者、医療機関４にとってはとても良い結果が出せると考えている。特に医療機関４の経営改善には一番の特効薬になると思います。今回の薬品モデルは１包十数円という安い総合感冒薬を選択したが、実際の診察で使用される薬品はもっと高価な薬品もあるためさらなる効果は期待できる。
このシミュレーションより、今回は流通コスト削減だけの算出結果からみても、契約する薬品の数量を増やせば増やすほど効果は大きくなることはわかりますし、ボリューム価格を加味すれば効果はもっと大きくなるのは明らかです。それは地域の複数医療機関４の数を増やすために、さらに拡大した地域の複数の医療機関４としているのはそのためです。
どんなに新しい最新の医療器具を揃えても、産業構造自体が古いままなので手を入れるところを医療機関４には気が付いて欲しいと考えている。
さらに、患者へ処方する薬だけではなく、他の実施形態に記載されている医療機関４が施術や治療時に使用する医薬品における調達を包括契約とサブスクリプション契約で行うと説明している。よって、患者への処方薬と、施術治療に使う医薬品との両方の調達方法を変えることで、相乗効果は大きくなります。よって、患者への保険診療から保険を使用しない定額診療へ改善しても経営上はおかしくないかもしれませんし、そうなる事が期待している。

【0311】

ここで、薬品の調達価格を下げたことによる経営方針の見直しについて記載する。
１）コストカット部分を全て院内の経営上の削減効果として利益に計上する方法。医療機関４から出ていく出費は減らずに増える。
２）医療機関４の売り上げから外部への支払いに充当し外部への支払いを経営上ゼロにし、医療経済圏２４の利用料金に充当する方法。
３）医療機関４の売り上げから外部への支払いをゼロに近づけることと、仕入原価を下げた分の売り上げ分との割合換算による方法、いわゆる１＋２の混合利用する方法。
この３種類の方法のうち、理想は出費を抑える３番、次に２番となる。大手民間企業が経営悪化になり始めると一番最初に行う対策が「経費削減」、いわゆる外に支払う出費を抑えることから始まる、これと同じである。
本来、医療機関４における薬品の購入先は、薬品卸会社からの購入が圧倒的に多い。これは小口発注になりため発注量を吸収できるのはどうしても薬品卸会社からになってしまう。それに対して、包括契約及びサブスクリプション契約により大口発注になると、契約価格の交渉をすると製造元である製薬会社との契約になる。しかし、製薬会社が契約に提示する価格は卸会社へ提供している価格となんら変わらず、薬品卸会社の流通コストがかからない分、製薬会社との契約締結が自然な形で出来てしまう。これは、従来の人的発注から、院内にある医療情報を共有する事と、発注行為を共同して行う事との本考案のビジネスモデルによる契約方法で、システムが自然に中間業者を挟まない薬品を工場直送とすることでコストを下げる医療産業構造を変革することができるものである。
また、大口の発注であれば、左記の契約方法でなくとも、薬品卸会社が提示する価格と製薬企業が提示する価格には開きが発生し、医療機関４は仕入原価を抑えられることになる。社会の産業形態を見ると、昭和の時代は小売店が多く卸業が小口の調達をサポートしていたが、平成より郊外の大型店舗が増え流通や調達も大型店舗が直接行うようになり、プライベート商品までに拡大し、大型店舗が直接メーカーを動かし商品まで作るようになってきた。農業や漁業においても産地直送といった仲卸を通さない流通はいまや当たり前の時代となり、本考案は大型店舗に相当する医療機関４は無いが、バーチャルな医療経済圏２４において医療機関４を統合することにより大口取引として薬品を発注するのは、大型店舗による発注と同じ考えである。

【0312】

一定地域内の薬を包括またはサブスクリプションで購入する際、薬の発注先と一定地域内の医療機関４との間で契約を結ぶ必要がある。この契約時に作成する契約書は、複数のテンプレート化し電子化された契約書（デジタル契約書）で提供し、契約書の管理は、プラットフォーム型医療機関支援システム１が行って良い。また、電子化された契約書で契約する際、契約書の契約相手が、薬の発注先と医療機関４側で異なってもよく、例えば、「薬の発注先の契約先は、前記の一定地域」、「医療機関４側の契約先は、薬の発注先」という形で異なってもよい。
契約書のサイン（署名）は、デジタル署名にて行い、契約書の全てがデジタルにより管理処理がし易くセキュリティ機能を付加することで堅牢な管理が行える。この管理は、包括契約の場合、処方リカーリングシステム２０２で行い、サブスクリプション契約の場合、処方サブスクリプションシステム２０３で行う。またこの契約は、システムが自動で行っているため、医療産業における見えない人的利権が排除された契約にもなる。

【0313】

上記の薬の発注における支払いは、第４実施形態に記載の医療決済口座１０４を利用した医療機関決済支援システム１０２を利用してもよい。
発注先を医療決済口座１０４を利用している企業に限定することにより、医療決済口座１０４を利用した医療経済圏２４内で完結した取引となる。

【0314】

本実施形態で開示した手法を用いると、一定地域内で購入する薬の値段が安くなることが期待できる。まず、一定地域で包括またはサブスクリプションで薬の購入契約を行う。そうすると、前述したように、当該一定地域内において、契約した薬は、１社から独占で提供されるようになる。そうすると、契約先以外の薬の納入者は、一定地域全体で薬の納入が無くなる。地域全体で薬の納入が無くなるのは、不思議に思うことは当然であり、納入が無くなった理由の調査が行われることが期待できる。調査の結果、本開示のシステムを利用した包括またはサブスクリプションで購入されていることが原因であると突き止めた場合、当初の契約先以外の薬の納入者は、次回の契約に向け対策を行うことが期待できる。そうなると、契約を行うために、医療機関４に有利な条件で納入する提案が来ることが期待でき、結果、一定地域内で購入する薬の値段が安くなることが期待できる。

【0315】

ここまで、一定地域で包括契約またはサブスクリプション契約で薬の購入を行う手法を説明してきた。この手法は、一生処方薬を服用しなければならない基礎疾患や慢性疾患を患っている患者にとって、一生涯にわたる薬の費用負担の軽減につながる手法となっている。

【0316】

慢性疾患などを患っている患者は、一生涯薬を飲み続ける必要がある。しかし、1つの医療機関４において慢性疾患などを患っている患者の人数が少なく、処方される薬品名も薬品の数も少ない。そのため、１つの医療機関４において包括やサブスクを用いて薬品を安く買うことが困難となっている。
医療機関４がバーチャルな医療経済圏２４を利用すると、複数の医療機関４が１つにまとまって医療経済圏２４が構成され、プラットフォーム型医療機関支援システム１にある慢性処方薬システム１９２を利用することにより、慢性患者に処方する薬品を一生涯服用する費用負担から、少しでも処方薬の費用負担を抑えることができ、慢性患者の消費量が少ない薬品でも調達価格を少しでも改善する方法で患者に寄り添った形の薬を提供をすることができる。
慢性処方薬システム１９２は、バーチャルな医療経済圏２４を利用する医療機関４が使用している患者情報ＤＢ１６１から、慢性患者の病名、慢性患者に処方している処方薬名と、その処方量と、その購入価格とを取得し、地域の複数医療機関４の慢性患者に処方している処方薬に対する処方量とを合計の処理を行う機能を有している。この機能で合計した処方薬と処方量から、慢性処方ルートＡＩは、包括契約による購入方法と、サブスクリプション契約による購入方法のうち一方を自動選択の処理が行われ、自動選択された契約手段で薬の購入契約を行う。契約先の選定にあたり、慢性処方薬システム１９２は、製薬会社や薬の卸売業者などの購入先候補事業者から、その契約金額と、その契約期間と、包括かサブスクリプション化を含む契約条件を取得し、処方リカーリングＤＢ２０１上の慢性処方薬契約情報に登録保存の処理をする。
この薬の購入契約を行う方法は、包括契約の場合、処方リカーリングシステム２０２を用いた方法を、サブスクリプション契約の場合、処方サブスクリプションシステム２０３を用いた方法をそれぞれ用いる。
慢性処方ルートＡＩは、慢性患者の病名、通常の薬品価格、慢性患者の年間処方する量を処方箋から年間処方数として算出処理した情報、処方薬の調達先事業者、調達先事業者の情報、包括契約を行う事業者、サブスクリプション契約を行う事業者などの情報を用いて学習を行い、購入に用いる契約方法の選定を行うモデル（慢性薬契約方法選定モデル）を作成する。慢性処方薬システム１９２は包括またはサブスクリプションで購入する薬の情報を購慢性薬契約方法選定モデルに適応させることにより、包括契約を行う事業者とサブスクリプション契約を行う事業者とから自動選定処理をする。
結果、基礎疾患や慢性疾患を患っている患者にとって、一生涯にわたる薬の費用負担の軽減が実現できる。

【0317】

基礎疾患や慢性疾患を患っている患者に対する薬の費用負担軽減の手法は、患者だけでなく製薬会社や薬の卸売業者などにもメリットがある。
包括やサブスクリプションによる一括契約により、製薬会社や薬の卸売業者は、１年間など一定期間における購入予定の量が分かるため、薬の在庫を過不足なく用意することができる。薬の在庫が過剰な場合は、売れなった分だけ不良在庫となる。一方不足した場合、患者に薬を渡せないため患者に迷惑がかかる。特に、製薬会社の場合は、薬の不足に備え、多く生産した場合に生産ロット単位で過剰に在庫を抱えるリスクもある。薬の購入予定の量が分かれば、購入量に合わせて生産スケジュールを立案し製造すればよく、生産の効率化にもつながる。

【0318】

本開示のシステムの活用例の１つとして、患者情報ＤＢ１６１より、患者への薬の使用量だけでなく、患者の年齢・性別といった属性情報、患者の既往歴や転帰などを取得できる機能もある。
これらの情報を組み合わせることにより、以下に示す活用方法などが期待できる。
医師５ａにとって病名・病状・年齢・外形が同じ患者のその他検査データから、それら患者の担当医（他の医療機関４）が出す処方箋と、を自分の似たような患者と比べることを活用できると診察に期待が持てる。
患者の病名や症状、患者の転帰、患者の属性情報、患者の身体形状などの情報（身長体重）、処方されている薬などを組み合わせることにより、当該患者に関する薬の効果の有無が推定できる。１人の患者の推定結果では、意味がないが、同じ薬を使用している複数の患者の推定結果を利用すると、意味のあるデータとなる。
患者の身体形状の情報とは、出願人考案の特願２０２１−０２０７１９に記載の身体形状センサーを用いて計測し取得した計測結果などのことである。
たとえば、一定年代のみ転帰がいい場合は、その年代のみその薬が特に有効であるため、優先して使用すべき薬となる。一方、一定年代のみ、転帰が悪い場合は、その年代だけは別の薬を選択する必要がある。転帰としたが、無視できない副作用の出現などでも含めてもよい。また、薬の投与後に複数の患者に共通してでている有害事象がある場合、その有害事象が薬の副作用ではないかと疑こともできる。
このほかに、「インフルエンザ治療薬のオセルタミビルやザナミビルなどの使用量が増えてきた」など、特定に疾患に対する治療薬の使用が増えてきた場合、当該疾病が流行していると推定することもできる。

【0319】

ここで説明した「薬の調達価格を下げる、各システム」は、医療経済圏２４というバーチャルな環境にある様々なシステムを複数の医療機関４が共有利用することができる。同じように共有するシステムを提供しているものに米国のGAFAと呼ばれている４つの企業「Google(登録商標)」「Amazon(登録商標)」「Facebook(登録商標)」「Apple(登録商標)」がある。この米国のＧＡＦＡは、システムを企業に提供しているが、企業がシステムを利用することで発生するデータはＧＡＦＡの所有物になってしまう側面がある。本来日本の常識からすれば企業のデータ（企業の所有物）と思いがちだが、システム上で発生するものは企業の所有物にはならない、それがクラウドシステムというビジネスモデルである。このＧＡＦＡのクラウドシステムを利用している日本企業は、ビジネス上のデータを取られてしまっても構わないという企業や、ビジネス上発生しているデータの所有者がクラウド側であることに無頓着な企業が利用しており、一度米国のクラウドを利用してしまうと発生したデータが戻ってこない事から一生使い続けなければならない、首に鎖がついたペットのようなものとなってしまう。このことは、いつか日本企業にとってそれが問題になる時が来ると予想しており、データをＧＡＦＡに取られない意味でも日本で同様なシステムを構築する意味があり、医療のデータは個人情報２２である側面からも外国企業には渡せないものである。
本考案は、医療経済圏２４の中にあるシステムを複数の医療機関４や企業が利用することで、医療機関４や企業から発生するデータを医療経済圏２４の中で共有利用することで、そのデータを利用し様々な処理方法でデータを作り出し、その処理したデータを利用し、システムから利益を産出すことができる。その産出した利益を、システム費や医療機関４や企業や利用者３に対して還元すること、利益を出すシステムやサービスを考案し利益追求から還元していくビジネスモデルはＧＡＦＡとの違いである。ＧＡＦＡに並ぶ医療経済圏２４を構築することは日本にとって必要なものであると考える。
ここで説明した「薬の調達価格を下げる各システム」は、医療経済圏２４の中で複数の医療機関４から発生するデータを共有利用する事で、従来の薬に纏わるコストを抑えるシステムである。医療機関４の経営を安定させ、患者へのサービスを拡大させていくために考案したものである。患者に対して「この薬を飲めば治るよ」といった昔からの考え方から、この薬はどこよりも安く提供できたり、一生服用する患者の生涯服用費用を少しでも下げてあげようと配慮することは患者にとっては望ましい事と考える。将来、人口減少から病院４ａは余る。医療機関４同士で患者の取り合いの時代がくる、そんな時代に患者から選ばれる医療機関４とは患者にサービスを提供する医療機関４である。今まで患者へのサービスを怠っていた医療機関４には患者へのサービスを提供してもらいたい。この医療経済圏２４を利用することで患者への様々なサービスを提供することができる。他の実施形態で説明しているサービスを医療経済圏２４の中で利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者はサービスを提供する医療機関４を選ぶようになる。患者への様々な医療サービスを提供する時代が始まると考える。

【0320】

本実施形態で説明してきた手法を用いることで、医療経済圏２４を利用している医療機関４がまとまって薬を包括またはサブスクリプションで購入できるサービスを提供するビジネスモデルとなり、処方薬の費用負担を下げる事ができる。

【0321】

＜第８実施形態＞
全ての考案は、医療機関４における経営を良くし持続可能な医療機関４へと改善するために新しい医療の産業構造を模索し医療機関４と患者を中心にした医療経済圏２４の構築を目指すために必要な考案となっていますが、本考案では社会の水面下であまり表に出てこない一部の患者の利便性を良くするために医療機関４が患者へ医療行為以外の面で手助けを行うものの考案である。
昨今、社会における様々な交通手段をプログラムでまとめて交通手段同士を携帯端末を利用してスムースに移動し、便利な移動を実現する動きとしてMaaS（マース、Mobility as a Service）が始まろうとしている。このMaaSの動きは、健常者にとってはとても良い発想のサービスであると思います。しかしながら、病状を抱えた人には縁のないサービスであると考えます。本考案は、最初に記載した一部の患者とは、病状から移動に特殊な手段を利用する人をターゲットに考案した、医療版のMaaSと言っても良いものである。
医療機関４への通院方法は、一般に徒歩や公共交通機関を利用して行う。しかし、患者（利用者３）の状態によっては、車いすから容易に乗り移って乗車できる車両や、車いすのままで乗車することができる介護タクシー、患者の病状によってはストレッチャー付き車両を利用するなどの特殊な車両で通院する必要がある。
車いすから車両へ自力で容易に乗り移れる場合は運転手７と車両の手配でよいが、介護タクシーを利用して通院する場合は、ヘルパーなどの介護関連の資格を保有する運転手７や介護士などの介護従事者なのどの介添人８が必要となる。患者の病状によりストレッチャー付きの車両を利用して通院する場合や、病気を患わっている状態でストレッチャー付きの車両で移動する場合は、介添人８にとして医師５ａ、看護師５ｂといった医療従事者５の同行が地域の条例で必要となっている場合もある。病状と必要な介添人８などの例を図４２に示す。
患者が通院のために介護タクシーや介添人８、医療従事者５などをそれぞれに依頼し手配するとなると、車両や介添人８、医療従事者５等が所属している様々な企業と患者が通院する日程でのスケジュール確保における労力は大変なものである。このことを医療機関４で働く医師５ａ達は知らない。水面下のことなので世間においても知らない人は多いでしょう。
依頼をする介護タクシーや介添人８、医療従事者５のスケジュールを、半日または1日単位で労務を押さえる必要がある。これは、医療機関４での診察時間が予測できないことに起因し、想定される最大の時間でスケジュールを確保しているためとなっている。半日または1日単位という長時間のスケジュールを確保（労務時間を確保）しているため、利用料金が高額となっており一部の患者には費用負担が重くのしかかっている患者もいる。本考案の特許では、通院に必要な車両と介添人８とを効率的に確保し運行する事と、車両と介添人８を利用する時間を最小限とする事と、患者の通院手段コストを少しでも軽減する事と、何よりも従来このような通院手段の確保には相当な労力がかかっていたことを大幅に軽減する事などの手段を提案する。

【0322】

本考案の運行管理システム２１１は、プラットフォーム型医療機関支援システム１の医療情報共有データベース２にある医療経済圏ＤＢ２１に保存されている個人情報２２に紐づいている患者情報ＤＢ１６１に保存されている利用者３の病状情報と移動手段情報を用いて移動手段の手配や介添人８などの手配を行う機能がある。移動手段情報には、患者の通院手段が記録されており、患者が一人で通院できないなどの理由で特殊な移動方法が必要な場合、車いすで乗車することができる介護タクシーやストレッチャー付きの車両などの特殊な車両のうち通院手段に必要なものの情報が登録されている。第８実施形態のデータベース構成を図４３に示す。
医療機関４において次回の診察予約を医療機関４の診察予約管理システム６２で行う際、患者の状態に合わせた移動手段の確保と、介護士や医師５ａ、看護師５ｂなどの介添人８等の確保とが行え、確保した移動手段や介添人８などの運行管理、すなわち時間の管理が行える機能を有している。さらに利用者宅から医療機関４までの最適なルートと移動時間をドライブナビ機能のシステムや、Googleマップ（商標）等のインターネットサービスなどからの取得できる機能と、医療機関４に到着後に診察が終了し診察後の会計を済ませ帰るまでの利用者３の滞在時間の推定算出と、医療機関４から利用者宅に到着するまでの最適なルートとその移動時間の算出と、運転手７や介添人８のそれぞれの労務借上時間（労務拘束時間）の算出がそれぞれできる機能を有している。
車いすから容易に乗り移れるまたは車いすのまま乗れる車両さえ手配すれば、介添人８なしで通院できる患者の場合、車両のみの手配を行ってもよい。

【0323】

また、プラットフォーム型医療機関支援システム１の医療情報共有データベース２にある予約ＤＢ６１と連携することにより、患者が医療機関４の次回診療予約を行う際、その予約と同時に、上記で説明した車両と介添人８や医療従事者５を扱っている沢山の事業者の中から患者が通院をする日程と時間に労務の借上（労務時間の拘束）が可能な企業を自動に選びだす処理を行い医療機関４内の予約用端末上に表示処理する機能を有している。この際に、利用者３が診察を受けたい時間帯で労務借上（労務拘束）ができる介添人８の一覧を表示処理し、その中から利用者３が最終的に介添人８を選択できるようにしてもよい。
本考案の利用者宅には、利用者３（患者）の自宅だけでなく、利用者３が入居している、老人福祉施設や老人ホーム、グループホームなどが含まれる。

【0324】

プラットフォーム型医療機関支援システム１にある運行管理システム２１１は、医療情報共有データベース２にある予約ＤＢ６１と連携している。前記運行管理システム２１１は、医療機関４の予約システム９ｄとネットワーク連携し、ネットワーク連携することで、医療機関４の予約システム９ｄのデータから予約確認が行える。前記運行管理システム２１１は、複数ある介護タクシー会社や介添人８会社や、看護師５ｂや医師５ａを派遣する会社と将来の予約状況なるデータを扱っている予約システム９ｄとネットワーク連携することで、それぞれの会社の予約状況のデータが、医療機関４の予約システム９ｄ上で連携がされ予約や予約確認が行える。このことでプラットフォーム型医療機関支援システム１の運行管理システム２１１と医療機関４の予約システム９ｄと介護タクシー会社や介添人８会社や、看護師５ｂや医師５ａを派遣する会社とのデジタルトランスフォーメーション（ＤＸ）が行えたことになる。
また、もう一つの連携方法として、医療機関４の予約システム９ｄと連携している運行管理システム２１１は、プラットフォーム型医療機関支援システム１により情報基盤化されたプラットフォームであるため、複数ある介護タクシー会社や介添人８会社や、看護師５ｂや医師５ａを派遣する会社等は端末を利用してブラットフォーム化している運行管理システム２１１の利用に変えて接続することで予約状況の確認が行え、予約データの一元管理ができる。
上記に挙げた2つの方法のどちらであっても、様々な会社の予約状況が医療機関４の診察予約管理システム６２上で予約データ連携を行えることが可能となるため、どちらの方法を用いても良い。医療機関４の予約システム９ｄと運行管理システム２１１と各事業者との連携フローを図４４に示す。また、各社の予約システムから情報を入手する場合のフローを図４５に、共有予約システムを利用した場合のフローを図４６にそれぞれ示す。
ここまで説明してきた医療機関４の予約システム９ｄは、レガシー的な考えの予約システム９ｄである。ここから医療機関４のＤＸ化を行うことを考えると、第２実施形態で説明している「診察予約管理システム６２」に変更することで、診察所要時間と患者のスケジュール・データを利用した診察予約を行うことにより、「待たない診察」と待合室での待ち蜜を防ぎ、予約変更の無い予約により、一層ＤＸ化が進んだこととなる。

【0325】

利用者３が病院４ａに行くために必要な車両や介添人８の労務借上時間（労務拘束する時間）を算出するには、「ナビシステムやインターネットサービスなどの外部システムを利用して、別途取得したルートでの利用者宅から病院４ａまでの移動所要時間を取得」「予約時間に間に合わせるための、出発時間の算出」「病院４ａに到着後、受付を行い、診察を受け、会計を行うまでの一連の流れに要する院内所要時間を算出」「ナビシステムやインターネットサービスなどの外部システムを利用して、別途取得したルートでの病院４ａから利用者宅までの移動所要時間を取得」が必要となる。

【0326】

患者が診察を予約した時間に遅刻しないように家を出る事が重要となる。患者が家を出る出発時間を算出するには、第２実施形態に記載した、予約ＤＢ６１内の診察の予約情報に保存されている診察予約時間と外部システムなどで予測した移動に要する時間から、患者が家から出るべき時間を導きだす処理を行う。

【0327】

病院４ａから帰る際、患者の希望等などの理由により、商店や役所などの経由地で用事を済ませ帰宅する場合もある。この場合、目的地を利用者宅から経由地に変えてもよい。この場合のルート及び移動所要時間も外部システムから取得する処理を行う。さらに、寄り道した地点から利用者宅ないし次の寄り道地点へルートと移動所要時間も外部システムから同様に取得する処理を行う。病院４ａから利用者宅までの移動所要時間は、経由地を含んだ時間でもよく、移動に用いる車両や介添人８などの労務時間に含めてもよい。

【0328】

病院４ａでの院内所要時間すなわち「病院４ａに到着後、受付を行い、診察を受診し、会計を行うまでの一連の流れに要する院内所要時間を算出」は、「到着から予約時間までの時間」と「診察に要する時間（診察所要時間）」と「診察後、会計計算にかかる時間」の３つの時間の合計と考えることができる。
すなわち、患者が病院４ａに到着し、診察が終えて会計を終えて帰宅する時間までの時間と等しい。行動を共にしている移動手段と介添人８等の労務時間の算出も同じ考えで改めて算出する必要は無い。
最初に考えなければいけないのは、「診察後会計計算にかかる時間」は、受診した病院４ａにおける平均的な会計計算に要する時間会計が完了したまでの時間を基本とする。
ここで、出願人考案の特願２０２１―１１３９２７を使用することができる。特願２０２１―１１３９２７は、顔認証を使用して決済が行われ、受付や会計場所でなくとも診察室で決済が完結し、移動の動線が短い動線で院外へ出られる考案である。ここでいう動線とは、医療施設内での患者の移動の事を指しており、ここで対象にしている患者や患者に付き添っている者の医療施設内の移動が負担を与え、患者の負担に対応させた動線（移動）として設計している医療機関４は数少ない。患者の動線を短くするという事は患者の負担軽減につながり、ある意味バリアフリーの一環と言ってもよい重要な対策のことである。
出願人考案の特願２０２１―１１３９２７を使用することにより、車椅子又は歩行に医療機具を使用して院内を移動する患者は、通常より短い動線で移動することができること、受付窓口での支払い行為をせずに診察後その場で会計が自動化される。また診察後は、短い動線を通って院外へ出られスムースに帰宅することができる。よって、「病院４ａに到着後、受付を行い、診察を受け、会計を行うまでの一連の流れに要する院内所要時間を算出」は、労務時間の算出の観点から見ると実質「診察に要する時間」となる。
次に、「診察に要する時間」は、第２実施形態に記載の方法を利用して行う。第２実施形態に記載の方法とは、「病状情報取得部で取得した病状と、その病状に対応する所要時間情報取得部で算出した診察所要時間とを利用する。」という考え方から方法となる。

【0329】

上記では、病院４ａに到着後「受付」をしているが、第２実施形態に記載の手法を用いることにより移動中に自動的に事前診療受付を行うこともできる。
この手法とは、運行管理システム２１１で管理し、通院中の患者、移動に用いる車両、介添人８、医療従事者５のそれぞれが所持している携帯端末などの端末のうち少なくとも１つの端末から位置情報を、端末にインストールしたプログラムを経由して病院４ａ内の医療機関支援システム１に送付し、送付されてきた位置情報が、病院４ａを中心に一定距離（半径）に３６０°円形ゾーンを設け、そのゾーンより病院４ａ側に患者が入ると自動的に事前診療受付の処理をおこなう。この際、位置情報の取得処理に必要な各々の所持する携帯端末の情報は、運行管理システム２１１から医療機関支援システム１への送信処理により行われる。

【0330】

今までの説明では、患者宅と医療機関４での診察し患者宅に帰宅するまでの労務借上時間を算出していたがそれ以外に不足している労務借上時間が発生しており、ここではその表面化されず不足している労務時間の算出を行う。
表面化されていない労務時間は、車両（運転手７）・介添人８・医療従事者５のそれぞれに発生しており、それぞれ同一時間ではない。よって、それぞれ算出する必要がある。
まず、車両（運転手７）の表面化されていない労務時間は、会社から患者宅へ向かうまでの途中で必要に応じて介添人８や医療従事者５をピックアップする必要がある。
ここまでの労務を計算するには、会社から介添人８・医療従事者５をピックアップする場所までのルートと移動時間を算出し、合流地点（ピックアップされた場所）から患者宅までのルートと移動時間を算出する。車両（運転手７）の労務時間には、この２つの所要時間を加算する必要がある。
次に、介添人８又は医療従事者５の表面化されていない労務時間は、ピックアップから患者宅までの時間を加算する必要がある。復路の場合も往路同様に、患者宅からそれぞれ往路で使用した合流地点（ピックアップされた場所）までの移動時間と、合流地点（ピックアップされた場所）から車両（運転手７）会社までの移動時間をそれぞれに加算されることで表面化されていない労務時間の算出をすることができる。復路における車両と介添人８・医療従事者５とが分かれる地点は、合流地点と別の地点でもよい。
また、表面化されていない労務時間以外の時間として次のような時間も発生する場合もあるが、これは労務時間としてカウントされない時間である。介添人８や医療従事者５の場合、「前の業務地点（合流地点）や事務所など介添人８や医療従事者５が出発する場所から次の合流地点までの所要時間」「患者を利用者宅へ送り届けあとの、移動に用いる車両と別れる合流地点から、次の業務地点（合流地点）までの時間や事務所などへ戻る移動所要時間」も考慮する必要がある。
ここまでの説明では、労務時間を算出するために、「ルートと移動時間を算出」と記載して説明しているが、ルートや移動時間を求めるにはナビシステムやインターネットサービスなどの外部システムを利用して行うため、実際には外部システムからルート情報と移動時間情報の取得となる。

【0331】

ここまで患者の通院とは別に表面化していなかった車両と介添人８の労務時間の算出を説明した。ここからは、それぞれのトータル（全行程）における労務借上時間を算出し、それを運行管理システム２１１に適応することを説明する。
まず、車両（運転手７）の労務借上時間は、「（１）会社から合流地点（ピックアップ地点）までと、そこから患者宅までの移動所要時間」と、「（２）患者宅から医療機関４までの移動所要時間」と、「（３）患者が医療機関４で受付・診察・会計までの時間」と、「（４）医療機関４から患者宅までの移動所要時間」と、「（５）患者宅から合流地点（ピックアップ地点）までと、そこから会社までの移動所要時間」の合計が労務借上時間となる。
さらに車両（運転手７）の労務借上の開始時間すなわち出発時間の算出は、「患者の診療予約時間から往路の所要時間の合計『（１）＋（２）』を逆算した時間となる。
次に、介添人８や医療従事者５の労務借上時間は、「（１）合流地点（ピックアップ地点）から患者宅までの所要時間」と「（２）患者宅から医療機関４までの所要時間」と「（３）患者が医療機関４で受付・診察・会計までの時間」と「（４）医療機関４から患者宅までの所要時間」と「（５）患者宅から合流地点（ピックアップ地点）までの所要時間」の合計『（１）＋（２）＋（３）＋（４）＋（５）』が労務借上時間となる。
さらに介添人８や医療従事者５の労務借上の開始時間の算出は、患者の診療予約時間から往路の所要時間の合計『（１）＋（２）』から逆算した時間となる。
この算出した結果が、運行管理システム２１１に反映される事になる。
車両（運転手７）の労務借上開始時間と労務借上時間、介添人８や医療従事者５における労務借上開始時間と労務借上時間が、患者が医療機関４内での次回診察予約と同時に、連携している運行管理システム２１１に何時何分から何時間と登録されることになる。
車両及び介添人８等の労務借り上げ時間の算出方法の概略図を図４７に示す。

【0332】

移動に用いる車両や介添人８等が往路と復路で違う場合を説明する。
患者が医療機関４に到着後、診察が終わるまでの間、移動に用いる車両と介添人８等とを待機させておくことは、短時間ならともかく長時間となる場合、移動に用いる車両と介添人８等との労務時間がもったいない。そこで、医療機関４での診察所要時間の予測結果を利用して、診察が終わる時間に合わせて移動に用いる車両と介添人８等とを再度手配すればよい。
この手配は、患者を病院４ａに送り届けた車両（運転手７）と介添人８と同一の車両及び人物である必要はない。例として、患者を病院４ａに送り届けるのは、Ａ介護タクシーとＢ介添人８の組み合わせ、患者を医療機関４から患者の居所へ送るのは、Ｃ介護タクシーとＤ介添人８の組み合わせをそれぞれ手配してもよい。この場合、「移動手段及び介添人８が病院４ａへ到着し次の業務場所等への移動時間」「移動手段及び介添人８が、出発地点から病院４ａへの移動時間」も本考案の労務時間の算出に含まれる。

【0333】

往復で利用するEさんの通院を例に具体例を説明する。
Eさんの場合、患者情報ＤＢ１６１の移動手段情報にトレッチャーが乗せられる民間救急車と保存されているとする。そのため、病院４ａへの通院時、ストレッチャーが乗せられる民間救急車を手配する必要がある。また、Ｅさんをストレッチャーに乗せる行為は、民間救急車の運転手７１人では行えず、別途介助する人も必要となる。そのため、通院には、民間救急車と看護師５ｂの両方を予約する必要がある。
医療機関４にて、Ｅさんの次回の通院予約を行おうとすると、医療機関４の予約管理システムは、医療機関４の診察空き状況からＥさんの次回通院候補日時を抽出する。抽出した候補日時の中から、M事業者の民間救急車とＺ派遣事業社の看護師５ｂが手配できる時間を抽出し予約を行う。
また、Ｅさんの診療所要時間は一時間と予測されているため、医療機関４とＥさんの自宅との移動に関して往路と復路とは別々の事業者となり復路は、K事業者の民間救急車とＴ派遣事業社の看護師５ｂが担当する予約となった。

【0334】

ここでは特殊な移動手段で来院する患者の費用軽減についての考案内容を説明する。
医療機関４への通院に特殊な方法で来院する患者は複数名いる。この複数名の移動手段である車両や介添人８の事業者（以下、事業者と呼ぶ）と包括契約することでコストを下げる考案となる。
通院に特殊な方法で来院する複数患者の移動内容を運行管理システム２１１から複数患者分の情報をサーチして抽出する。
運行管理システム２１１より抽出した情報は、「利用者宅方面、医療機関４までの距離、車両タイプ、病状から必要な介添人８等。」となる。
さらに、医療機関４内にある医療情報システム９より、特殊な方法で来院する患者の情報をサーチしまとめる。
医療情報システム９より患者情報ＤＢ１６１に保存された利用者３の病状情報と移動手段情報を取得し、取得した情報は、「病状、性別、年齢、移動手段、移動日、等」となる。
運送包括システムは、これら２つのシステムから抽出または取得した情報を複数患者人分まとめ、全ての事業者へこの医療機関４に来院するための移動手段の包括情報として送信される。
持ち掛けられた事業者は、固定客が確保されることにより経営の安定化に繋がるため何処の事業者よりも優先的に契約したいという自然な競争原理により価格交渉が進められ、患者自らが予約した時の価格よりも安くなることは言うまでもない。

【0335】

上記までの説明は、１つの医療機関４における患者さんの移動手段を包括契約でコストを下げる考案であるが、さらに価格交渉を優位にすることができる。
まず、医療機関４は、医療経済圏２４でのプラットフォーム型医療機関支援システム１にある医療情報システム９を利用することと、医療経済圏２４での一定地域の複数医療機関４と連携され、それぞれの複数の医療機関４の患者を対象とすることで、運送包括システムは契約対象の患者数を増やすことができる。契約対象の患者数を増やすことで価格交渉を優位にすることができる。
複数医療機関４へと対象を広げることと、第１実施形態によるシステムを利用することで、包括的な交渉が優位になるのは言うまでもない。さらに価格を優位にするには、さらに拡大した地域の範囲にある医療機関４の患者数へと拡大していくことで患者のコストが下がりや、固定客の増加により事業者の経営が安定することに繋がる。さらに運送サブスクリプションシステム２１２よりサブスクリプション契約を利用することで患者の利用の仕方の自由度が広がる可能性もある。
これにより、移動に用いる車両と介添人８等との労務時間が効率化され、患者は、実際に利用に要する時間に合わせた利用料金で利用でき、無駄な待機時間に対する利用料金を払う必要が無くなる。本システムは、予約手配を、単独の医療機関４や地域内の複数の医療機関４など様々な範囲で包括的に行うために必要な、移動に用いる車両と介添人８等と医療機関４との間の契約を管理する機能も有している。

【0336】

プラットフォーム型医療機関支援システム１にある運送サブスクリプションシステム２１２を利用したサブスクリプション契約とは、医療経済圏２４を利用している利用者３が車両や介添人８の事業者とサブスクリプション契約を結ぶことができる。契約の内容の例として、一定年期間の契約により、通院以外に、月に数回までは利用することができるプランや、月に１回は親戚の家にまで行くプランや、年に数回長距離の旅行に行くプランなど、利用者３の希望や要望を受けてもらう契約の可能性も広がる。これにより移動することに制限された利用者３の人生は、移動から解放される。

【0337】

ここまで、医療機関４で次回診察の予約を行うと同時に、予約した次回通院時の移動に用いる車両や介添人８、医療従事者５の予約を同時に行うと説明してきた。
この予約行為は、医療機関４での次回診察の予約を行う予約時に限らず、利用者３の端末（患者の所有する端末）を利用したて行っても良い。この利用者３の端末を利用する場合は、プラットフォーム型医療機関支援システム１にある運行管理システム２１１に接続し予約を行い、その予約と同時に移動に用いる車両や介添人８、医療従事者５の予約を行ってもよい。利用者３端末を利用した予約とは、すでに行っている診察予約の予約変更や新規の診察予約を行うなどの予約のことを示している。利用者３端末を利用した予約の例として、出願人考案の特開２０２０−１１３１４３に記載の手法などがある。

【0338】

従来、このような複数の機関が関係する予約は、電話やＦＡＸなどアナログな方法で行われ、車両や介添人８など機関ごとに個別に予約を進めていく方法で行われてきた。そのため、予約日時の変更を行おうとすると、各機関に個別に連絡を行い調整する必要があり、関係する各機関の日程調整を行いながら予約を確定することが重労働で困難であった。結果、患者の都合など、患者の希望が叶わず、業者側の都合に合わせて予約になる場合も多い。
本開示の運行管理システム２１１を用いた場合、システム側ですべての予約が管理できるので、患者の都合により予約日時が変わった場合でも、車両や介添人８などの事業者を変更して予約の変更を行うこともできる。結果、患者の都合など、患者の希望が叶う予約となる。

【0339】

本考案の運行管理システム２１１には、付加機能として、「移動に用いる車両や介添人８等が利用者宅に到着する直前に利用者３に対して間もなく到着する旨の連絡する機能」を有してもよい。
移動に用いる車両や介添人８等が利用者宅に到着する直前に利用者３に対して間もなく到着する旨連絡する機能とは、運行管理システム２１１が外部システムから取得した患者宅を出発する時間の少し前、または、移動に用いる車両や介添人８等が所持する携帯端末による位置情報を利用して移動に用いる車両や介添人８等が患者宅近傍に到着した際に、患者が所有する端末または患者宅のスマートスピーカー等から患者に対して、もうすぐお迎えが到着する旨を伝える機能となっている。携帯端末の位置情報を利用して患者宅近傍に到着したかを取得する方法は、第２実施形態に記載のGeolocation APIを利用した方法を用いて行う。

【0340】

また、本考案の運行管理システム２１１は、医療機関４への通院だけでなく、通院以外の利用にも、移動手段や介添人８等の予約に用いてもよい。
予約は、患者の所有する端末、又はポータルサイトなどのＷＥＢでアクセスにより行い、予約方法は利用者３端末を利用した医療機関４の予約と同様に行う。患者の所有する端末、又はＷＥＢを用いた予約法の例として、出願人考案の特許第６５５８６６９号に記載の方法がある。

【0341】

本考案のここまでの説明は、移動に用いる手段として介護タクシーや民間救急車などの貸し切り自動車を用いてきた。移動に用いる手段に使う車両は、貸し切り自動車だけでなく、バスや鉄道などの公共交通機関を用いてもよい。公共交通機関を利用する場合、「患者宅から駅やバス停など公共交通機関の乗車場所までの移動手段」「公共交通機関に乗車時の支援」「公共交通機関の降車時の支援」「公共交通機関の乗車場所から目的地までの移動手段」「公共交通機関内での支援」および「公共交通機関の結節点における乗り換え時の支援」のうちから、病状に合わせた手配の処理を行う。
手配処理の内容は、公共交通機関の乗車場所や降車場所に乗降の支援を行う（目的）のための人の確保（予約）する処理や、公共交通機関内に患者が乗る場所を確保（予約）する処理を行うなどである。
また、公共交通機関と貸し切り車両とを利用して目的地まで移動する場合、自宅から貸し切り車両を用いて公共交通機関の駅まで移動し、公共交通機関に乗り換えてから目的の駅に到着し、駅から目的地までの貸し切り車両を用いた移動手段を利用する場合、公共交通機関への手配と同時に車両などの予約処理も行ってもよい。公共交通機関などを利用した場合のイメージを図４８に示す。

【0342】

移動に用いる車両や介添人８、医療従事者５への利用料金の支払いは、「利用の都度現金で支払う」、「１か月分など一定期間の利用分をまとめて支払う」のどちらかが一般的となっている。どちらの場合もデメリットがあり、前者の場合は、都度支払う都合上、患者は利用のたびに現金が必要になる。後者の場合は、移動に用いる車両や介添人８、医療従事者５に利用料金が入金されるまで時間がかかる。さらに預金口座から現金を引き出すだけで手数料が取られる時代になり、手数料や現金化する行為のどちらも負担である。クレジットカード等の現金を使用しないキャッシュレス決済方法を利用する方が便利である。しかしながらこのシステムを利用する患者はキャッシュレスを利用できないため、第４実施形態に記載の医療決済口座１０４を利用した決済方法を用いると、上記のデメリットなく支払いが行えるようになる。
医療決済口座１０４を利用した決済方法を以下に示す。まず、本考案の運行管理システム２１１と連携した医療機関決済支援システム１０２に患者及び各事業者それぞれに医療決済口座１０４を作成する。患者は、作成した医療決済口座１０４にお金を入金しておく。
患者が、移動に用いる車両や介添人８、医療従事者５を利用すると、運行管理システム２１１から、医療機関決済支援システム１０２に対し、利用料金の支払を依頼するが依頼を受けた医療機関決済支援システム１０２は、患者の医療決済口座１０４から各事業者の医療決済口座１０４に対し、利用料金を即座に移動し支払いが行われる。この支払い時に、移動に用いる車両や介添人８、医療従事者５への支払いだけでなく、通院した医療機関４への診察費の支払いと、調剤薬局４ｂへの処方箋薬費用の支払いも合わせて行なえ、患者の医療決済口座１０４から医療機関４や薬局４ｂの医療決済口座１０４に対し、利用料金を即座に移動し支払いが行われる。
この決済方法を用いると、患者は予め入金をしておけば、利用の度に現金を用意する必要がなく、各事業者は、即時入金されるため、入金を待つ必要が無くなる。患者が予め入金する必要があることは、一見デメリットに見えるが、第４実施形態に記載の医療決済口座１０４を利用した決済方法は、日常生活の決済や病院４ａなどでの決済にも利用でき、決済の一元化ができるためメリットの方が大きい。事業社は医療決済口座１０４の作成ができたことで、事業社も情報の共有ができる医療経済圏２４の中での決済が行えることになる。医療経済圏２４での医療決済口座１０４の開設により、患者も医療機関４も様々な事業者や小売店で様々な情報共有ができることとなる。

【0343】

本開示の手法を組わせることにより、特殊な方法で通院する患者に対する、特殊な車両と介添人８と医療従事者５との予約と、医療機関４で次回診療の予約を一緒に行う予約サービスと、医療機関４で長い時間診察待ちをしないように利用者宅と医療機関４との間の車両の運行管理を行うサービスを行うビジネスモデルを提供するものである。

【0344】

執筆時現在社会で考案されているＭaaＳは、利用者３が乗り物を効率よくつなぎ合わせて利用するといった目的の物が多く検討されている。利用者３へ時間と利便性をどう追求するかというのがこのＭaaＳのシステムだと考えられる。将来的にそこには無人による自動運転も含まれていると想像している。
それに対して、ここまで説明してきた本考案は、前記ＭaaＳと明確に違う点は、利用者３の不便さの解消といったことと、利用者３の目的が違う点ある。本考案の利用者３の目的は、本人が移動するには沢山の助けを必要とされ、その助けを言葉で求めるには、相当な時間と労力を費やして移動の準備が整うものであった。その準備の詳細は、移動する手段、利用者３の病状、介添する職種等のそれぞれを、利用者３が移動したい日と時間に合わせて言葉（電話）で調整をとる必要があり、その調整が大変な労力であったことである。この調整をシステムで完結するには、医療経済圏２４内で患者の医療情報、医療機関４の診察予約情報、事業者の事業（予約状況）スケジュール、患者スケジュール、病状患者の決済方法を経済圏内でのそれぞれの医療機関４や事業社とＤＸによりデータを共有することで、人や車両の手配と決済まで行えることが特徴となる。これにより、特殊な移動が必要な利用者３とサービスを提供する事業者にとって利便性は良くなるものである。
また無人（自動運転）の車両を利用すると、ルート情報と時間情報と利用者３情報を自動運転車両に提供するだけで済みさらに利便性は向上するでしょう。
さらにこれを、航空や船舶とホテルとを繋いだ、出願人考案の特許第６６４７５００号を利用することで、特殊な移動が必要な利用者３は、医療機関４での治療を継続しつつ国内旅行や海外旅行を行う事も可能となる。

【0345】

ここで説明した「医療版ＭａａＳシステム２１３」を望んでいる患者やその家族はいます。煩わしかったことを簡単に且つ便利にする人はいませんでした。それはこういったシステムの開発に投資をしても、投資を回収するために短期で回収しようとすると利用料に反映され利用料が高く患者や家族は利用しないことになる。また長期間で回収しようとするとＩＴの欠点であるシステムの維持費や技術の陳腐化からくるリプレースにより更なる投資が必要となる要因があり手を出す事業者はいない。こういった福祉的なシステムは、患者や家族から投資額を回収する考えでは無く、様々な利益が出るシステムから充当するといった方法でないとうまくビジネスとしては回らないし利益は出ない。その為に医療経済圏２４には利益を生み出す様々なシステムを用意していることでこういった福祉的なシステムをサービスとして提供することができる。
プラットフォーム化されているシステムに「医療版ＭａａＳ」を医療経済圏２４の中でサービスを提供することで、沢山の医療機関４と、沢山の車両や介添人８、医療従事者５を扱っている事業者が利用できることになり、その医療機関４の患者にとっては望ましい事と考える。今まで患者へのサービスを怠っていた医療機関４には使用してもらいたいサービスである。さらに他の実施形態で説明しているサービスを医療経済圏２４の中で利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者はこの「医療版ＭａａＳシステム２１３」を利用していない医療機関４を患者は選ばなくなる、これが患者へ寄り添うことの効果になると推測する。患者への様々な医療サービスを提供する時代が始まると考える。

【0346】

従来、旅行に行くには利用者３が利用する交通機関や宿を予約する必要がある。これを利用者３が「ここに行きたい」と目的地を決めるだけで、そこに行くまでの移動手段や介添人８までのルートの選定と移動手段の選定とその日程での手配や予約と労務の借上げまでの予約等の全ての手配予約をＡＩで行うことができる。航空機や船舶を使った海外も可能となる。ＡＩの学習は、今まで説明してきた情報と公共の交通機関のルート情報等の外部システムの情報を学習することで算出されることになる。

【0347】

＜第９実施形態＞
本実施形態で開示する人工多能性幹細胞治療支援システム２２２は、プラットフォーム型医療機関支援システム１にある複数の医療機関４が持続可能（サスティナブル）な大きな１つのデータベースとなる医療情報共有データベース２を共有利用することにより、ＩＰＳすなわち人工多能性幹細胞を使用した移植治療の支援を行う事ことを目的としているシステムである。

【0348】

このシステムは、医療情報共有データベース２にあるＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１を利用することにより提供される。ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１には、「医療情報共有データベース２の医療経済圏ＤＢ２１にある診療情報から患者の病状情報と患者の属性情報に紐づけされ移植候補患者の情報」または「プラットフォーム型医療機関支援システム１と連携している医療機関４が使用している情報システムから患者の病状情報と属性情報に紐づけされ移植候補患者の情報」とが移植候補患者情報として保存されている。この移植患者情報が、人工多能性幹細胞移植治療を行える可能性がある候補患者の情報となっている。第９実施形態のデータベース構成を図４９に示す。
患者のかかりつけ医（主治医）は、移植患者の情報に付加情報として、人工多能性幹細胞治療の候補者抽出する際の条件を登録してもよい。登録する条件は、IPS細胞を採取した人の年齢範囲など医師５ａが設定した条件のことを示す。
プラットフォーム型医療機関支援システム１にある人工多能性幹細胞治療支援システム２２２は、移植患者情報から別途定めた条件で移植治療の候補患者を抽出する処理を行う。この処理により適合する人工臓器が見つかり候補患者となった場合、人工多能性幹細胞治療支援システム２２２は、適合した候補患者とその患者の主治医（かかりつけ医）と適合する人工臓器を所有する事業者に対し、人工多能性幹細胞治療を勧める情報を自動で通知する処理を行う。この抽出する処理に用いる別途定めた条件は、患者のHLA（ヒト白血球型抗体）やABO式血液型、Rｈ式血液型などの血液のデータと人工臓器作製事業者２２３が所有している（在庫として抱えている）人工臓器のＤＮＡ情報とが適合するか否かなどのことである。この抽出の際、主治医が移植患者の情報に付加情報に人工多能性幹細胞治療の候補者抽出する際の条件を登録している場合、登録されている条件を追加して候補者の抽出処理を行う。
適合した候補患者とその患者の主治医に人工多能性幹細胞治療を勧める情報の通知により、患者が移植手術を受けると決断した場合、移植関係者の間でＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１にある人工多能性幹細胞治療情報の共有を行う。移植関係者とは、患者と患者の主治医と移植手術する医療機関４と執刀する医師５ａ（執刀医）と人工臓器作製事業者２２３と関連事業者のことである。また、関連事業者とは、患者が加入する医療保険を運営する保険会社や患者が治療を受けるための資金を融資する銀行などのことである。人工多能性幹細胞治療情報とは、患者の人工多能性幹細胞移植治療に関する情報と、人工臓器の培養に関する情報と、移植手術後の日常生活でのモニタリング情報と、その他の様々な情報を蓄積した情報のことで、IPSによる作製した人工臓器を使用する移植治療で発生した情報及び治療後の情報のことである。移植手術後の日常生活でのモニタリング情報とは、第３実施形態に記載した手法、すなわち、利用者３（患者）と電子機器７３との会話により日常の測定結果や食事の内容などを取得する方法により取得できる情報のことを示す。

【0349】

上記の説明では、人工臓器作製事業者２２３が在庫として抱えている人工臓器がある場合とした。しかし適合する人工臓器の在庫が常にあるとは限らない。そのため、人工臓器作製事業者２２３が在庫として抱えていない場合は、新たに適合する人工臓器を新しく作る。作製後は、在庫がある場合と同様に移植関係者の間で人工多能性幹細胞治療情報などの情報の共有を行う。

【0350】

人工多能性幹細胞治療支援システム２２２が対象とする臓器は、腎臓、膵臓、肝臓、心臓などの内臓だけでなく、眼球などの体を構成する部位も対象とする。

【0351】

患者が臓器の移植手術を決断し人工多能性幹細胞の培養を行うと決めた場合、移植候補患者情報にある、移植候補患者情報や人工多能性幹細胞治療情報などの情報は、個人情報２２扱いとなる。これは、患者の病状情報などは、一般に他人に知られたくないセンシティブな情報のためとなっている。そのため、かかりつけ医療機関４と移植手術する医療機関４と執刀医と人工臓器作製事業者２２３と関連事業者との間で情報の共有は、セキュリティ対策を行って行う必要がある。
セキュリティ対策を移植関係者の間で個別に行うのは、費用の面からもセキュリティレベルの維持の面からも得策ではない。そこで、サービスとして利用者３の個人情報２２の管理を行っている法令に基づき個人情報２２の預託及び提供が行える機関（例えば情報銀行）に情報の管理を委託する、もしくは、本開示のシステムの一部としてセキュリティを担保できるネットワーク上のサーバーを提供することで行う。

【0352】

本開示のシステムは、人工臓器作製事業者２２３が使用している人工臓器作製時に使用する情報システム又はプラットフォーム化されたシステムで扱われる様々な情報から、細胞の採取検体の個体識別情報と、品質管理情報と、生産に関わる進捗情報、トレーサビリティーに関係する情報を取得する処理を行い、取得した情報を移植関係者の間で共有することができる。この共有も、サービスとして利用者３の個人情報２２の管理を行っている法令に基づき個人情報２２の預託及び提供が行える機関（例えば情報銀行）に情報の管理を委託する、もしくは、本開示のシステムの一部としてセキュリティを担保できるネットワーク上のサーバーを提供することで行う。

【0353】

このようにデータの一元管理を行うことにより、各移植関係者が使用しているシステムの違いから発生する煩雑な管理が軽減されることが期待できる。

【0354】

患者の主治医がほかの医師５ａに患者の治療を依頼する際、患者にとってもっとも良い治療を行え、かつ信頼できる医師５ａに依頼したいと考えている。信頼できる医師５ａの選定方法の１つとして第１０実施形態に記載する医療従事者５の評価結果を用いることができる。
主治医が移植手術を行う医療機関４又は移植手術を依頼する医師５ａや移植手術に携われる医療スタッフと、さらに人工臓器作製事業者２２３とを選定は、人工多能性幹細胞治療支援システム２２２にある選定機能を利用して行う。この選定機能は、第１０実施形態に記載の医療従事者５の評価結果を利用している。
人工多能性幹細胞治療支援システム２２２は、移植手術を行う医療機関４などの選定するにあたり、医療情報共有データベース２内の医療従事関連ＤＢ２３１に保存されている医療機関評価データから、移植手術を行った実績のある医療機関４の情報と、医療経済圏ＤＢ２１に保存されている業務履歴情報から移植手術を行った経験のある医師５ａや看護師５ｂの情報とを取得する処理を行う。
移植手術を行う医療機関４などの選定は、医療従事関連ＤＢ２３１に保存されている医療機関４を基本とし、患者の自宅と医療機関４との距離が遠すぎる場合や、患者の要望がある場合は、医療情報共有データベース２の経理業務ＤＢ３１から医療機関４が所有する設備の設備機材情報から移植手術を確実に行える医療機器を所有している医療機関４の情報から移植手術をする医療機関４の選定処理を行う。
人工臓器作製事業者２２３の選定は、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の移植候補患者情報にある患者の血液データと前記人工臓器作製事業者２２３が培養した臓器を保有している人工臓器のＤＮＡデータや遺伝子データ及び血液データとの照合処理を行い一致した場合に、その培養した臓器を保有している人工臓器作製事業者２２３を選択する処理を行う。人工臓器製作事業者の選定時に、医療経済圏ＤＢ２１にある医療経済圏２４を利用する企業の事業情報に保存されている人工臓器作製事業者２２３の情報を取得し、この情報には、企業名や連絡先、担当者などが含まれている。
ここまで取得または選定した、医師５ａや看護師５ｂ、医療機関４、人工臓器作製事業者２２３との間で相互に利権が働ない形で選定を行う。例えば、人工臓器作製事業者２２３から医師５ａへのキックバックがないこと確認できている組み合わせや利害関係（たとえば、当該医師５ａが人工臓器作製事業者２２３の出資者や役員など）がない組み合わせで選定を行う。
本開示のシステムが利害関係のない組み合わせで医師５ａや人工臓器作製事業者２２３の選定処理を行い、その結果として選定された人工臓器作製事業者２２３は、患者への臓器提供のスケジュール又は患者の臓器培養スケジュールと様々な情報と臓器の前記ＤＮＡ情報を人工多能性幹細胞治療情報に保存する処理を行う。
また、本開示のシステムは、選定した人工多能性幹細胞の移植手術を行う医療機関４や執刀医や移植手術に携われる医療スタッフなどの移植手術スケジュール情報や病床スジュール情報などの医療機関４や人選までの日程調整の情報を医療機関４の医療情報システム９などから取得し人工多能性幹細胞治療情報に保存する処理を行う。
人工多能性幹細胞治療情報した患者への臓器提供のスケジュール又は患者の臓器培養スケジュールと様々な情報や医療機関４や人選までの日程調整の情報の情報を、移植関係者の間で情報共有する処理が行える。

【0355】

本開示のシステムは、患者の血液データと人工臓器作製事業者２２３が所有人工臓器のＤＮＡデータ及び血液データとの照合処理を行うことができる。この処理の結果、人工臓器作製事業者２２３が培養した臓器と一致しなかった場合、人工多能性幹細胞治療支援システム２２２は、移植候補患者情報から患者のＤＮＡデータや遺伝子データ及び血液データと一致する患者を検索する処理を行う。この検索の結果、一致する患者が存在した場合、一致する患者の情報を匿名加工処理したうえで、人工臓器作製事業者２２３に対し提供または販売を行う。人工臓器作製事業者２２３は、提供したＤＮＡデータや遺伝子データ及び血液データと一致する複数の患者の情報から人工臓器の培養（作製）を行うことで、新しい販売先とすることできる。

【0356】

ここまで、IPSを用いた人工臓器の作製及びその人工臓器を使用した治療にかかわる情報共有などを説明してきた。
人工多能性幹細胞の移植手術治療は、最先端の治療のため、患者の費用負担が多い治療となることが予想される。さらに、従来から医療産業のコストは高額のためより一層患者の費用負担が多い治療となることも予想される。
人工多能性幹細胞治療支援システム２２２には、人工多能性幹細胞の移植手術における患者が負担する費用の削減と、人工多能性幹細胞治療支援システム２２２とＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の維持運営を目的とした機能もある。
人工多能性幹細胞治療支援システム２２２は、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に保存されている移植手術当事者である患者と移植手術を行った医療機関４と人工臓器作製事業者２２３等による移植手術に成功した様々な情報を、これから再生医療への参入に検討している医療機関４及び人工臓器作製事業者２２３に対して販売を行う。この販売により、得た収益を患者が負担する費用の削減と医療機関４への収益と本考案のシステムの維持運営のそれぞれに充て処理を行う。ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１内に保存されている既に再生医療を実施し成功した患者の治療に関する情報は、治療前後の診療情報、病状の情報、臓器作製情報、治療方法に関する動画情報、治療実績情報なども含まれている。
人工多能性幹細胞治療支援システム２２２が情報を販売する際、患者の治療に関する情報は、非代替性トークン（NFT）により、情報ソースと情報の所有者である患者とかかりつけ医と手術をした医療機関４と執刀した医師５ａ等と情報の購入者又は複数の情報の購入者とを紐づけて権利の管理を行い、情報の複製を抑制する。NFTを利用した情報の管理方法は、後記する第１１実施形態に記載されているので、ここでは説明を割愛する。
また、患者の治療に関する情報は、患者の匿名加工したうえで、セキュリティの担保ができるサーバー又は法令に基づき個人情報２２の預託及び提供が行える機関を使用して購入者が情報を閲覧できるようにしてもよい。

【0357】

人工多能性幹細胞治療支援システム２２２には、人工多能性幹細胞の移植治療の実績のある医師５ａや、医療機関４や、人工臓器作製事業者２２３、等から業績を上げる事を目的とした広告の依頼を請負う機能がある。
移植手術実績のある医師５ａ、移植手術実績のある医療機関４、人工臓器の提供実績のある人工臓器作製事業者２２３等は、広告には移植治療の経験から移植治療を請負える内容で作成した広告資料をＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の広告情報に広告資料の情報として保存する処理をし、
人工多能性幹細胞治療支援システム２２２に広告依頼の申請を行うことができ、
この機能は、広告を行う対象者を移植候補患者情報にある患者のかかりつけ医の医療機関４を患者情報ＤＢ１６１から取得した医療機関４と、
さらに
患者情報ＤＢ１６１から病状に臓器障害の患者を抱えている医療機関４を抽出し取得した医療機関４と、
これら取得した医療機関４へ広告資料の情報を提供する広告機能を持っている、
この機能は、医療経済圏ＤＢ２１から臓器障害の患者を抱えている医療機関４を抽出する処理を行い、抽出した医療機関４に対し移植手術実績のある医師５ａ、移植手術実績のある医療機関４、人工臓器の提供実績のある人工臓器作製事業者２２３等から広告を送る処理を行う機能となっている。移植手術実績のある医師５ａ、移植手術実績のある医療機関４、人工臓器の提供実績のある人工臓器作製事業者２２３等から広告の依頼は、人工多能性幹細胞治療支援システム２２２が請け負うことで行われ、広告の内容は、移植候補患者情報に含まれる情報を含む、移植治療を請負える内容となっている。

【0358】

移植候補患者情報を利用した広告の例を示す。
人工多能性幹細胞治療支援システム２２２は、人工腎臓移植手術を行いたい医師５ａから広告の依頼を受けたとする。
人工多能性幹細胞治療支援システム２２２は、腎臓移植が必要な慢性腎不全患者を抱えている医療機関４を医療経済圏ＤＢ２１から抽出処理を行う。抽出されたその医療機関４に対し、IPSを利用した人工腎臓移植手術を行えるという広告を送る。この広告には、人工腎臓移植手術の治療実績の情報が含まれている。

【0359】

人工多能性幹細胞治療支援システム２２２には、人工臓器作製事業者２２３が自らの事業の促進を行うために自社で保有している人工臓器の適合する患者を探し他社よりも先に適合する患者に自社の人工臓器を使ってもらい人工臓器作製事業者２２３の業績を上げる事を目的とする、患者検索機能もあり、臓器移植を希望する患者側が自分に適合する人工臓器を探すこととは反対に、人工臓器作製事業者２２３が患者を探す機能となっている。
この患者検索機能について説明する。まず、人工臓器作製事業者２２３は、人工多能性幹細胞治療支援システム２２２に対し、保有している人工臓器のＤＮＡ情報や血液データを送り、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に人工臓器ＤＮＡ情報として保存する。人工多能性幹細胞治療支援システム２２２は、人工臓器ＤＮＡ情報と移植候補患者情報にある患者のＤＮＡデータ又は血液データとを比較し適合することにより患者をサーチする。サーチの結果は、適合する患者の情報を適合患者情報として取りまとめる。適合患者情報は臓器ごとに作成される。作成した適合患者情報は、依頼した人工臓器作製事業者２２３に対し有償で提供を行う。
適合患者情報の提供を受けた人工臓器作製事業者２２３は、人工多能性幹細胞治療支援システム２２２を用いて、適合した患者と主治医に対して人工多能性幹細胞治療の勧める通知処理を自動で行う。
人工臓器作製事業者が保有している培養臓器の適合患者を探すシステム図を図５０に示す。
同一の人工臓器に適合する患者が複数見つかった場合、より年齢が若い患者を優先する。これは、年齢の高い患者よりも、若い患者に対して臓器移植を行うことで、若い段階で社会に戻り、仕事をしながら生活をする環境を取り戻すことができる。若い段階で社会に戻した患者は、社会において年齢の高い患者に比べより多くの社会の場での活躍が行われることが期待できるためとなっている。
また、この検索処理で見つけ出した患者に対し、人工臓器移植を行うことを促すことで、患者に移植手術への道を早期にみつけることができるようにもなる。

【0360】

上記では、人工臓器作製事業者２２３が検索を行い、人工多能性幹細胞治療を行う患者を見つける手法を説明した。人工多能性幹細胞治療を行う患者を見つけるのは、人工臓器作製事業者２２３に限らず、医療機関４が行ってもよい。医療機関４が人工多能性幹細胞治療を行う患者を見つけることで、患者が病院４ａに来るのを待っている従来の医療ビジネスから、患者を探しに行くといういわゆる新しい医療ビジネスに切り替わる。新しい医療ビジネスに切り替えることで、医療機関４は、人工多能性幹細胞治療の実績の増加や経営業績を上がることも期待できる。
医療機関４が人工多能性幹細胞治療を行う患者を見つける手法を説明する。人工多能性幹細胞治療支援システム２２２は、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１にある移植候補患者情報にある患者の診療情報から人工多能性幹細胞治療の実施ができる患者を検索する処理を行う。この処理は、医療機関４からの依頼で行われ、対象とする患者は、検索を依頼した医療機関４以外に通う患者を対象とする。
この検索を依頼した医療機関４は、人工多能性幹細胞治療支援システム２２２を用いて、この検索処理により見つかった患者と主治医に対し、検索を行った医療機関４にて人工多能性幹細胞治療の勧める連絡の処理を自動で行う。この連絡は、電子メールで連絡やプラットフォーム型医療機関４支援システム１を利用した連絡など電磁気的方法で行う。
連絡することにより、適合する患者主治医と移植手術ができる医療機関４（検索を行った医療機関４）とを結びつけることで、手術ができる医療機関４の業績を上げる事ができる。

【0361】

本実施形態において、ここまで説明した内容を組み合わせることにより、複数の医療機関４が持続可能な大きな１つのデータベースである医療経済圏ＤＢ２１の情報を利用した、患者とかかりつけ医療機関４と移植治療を行う医療機関４と事業者とそして患者への移植治療支援と、移植治療実績のある医師５ａ、医療機関４、人工臓器作製事業者２２３の様々な広告方法による支援を行うプラットフォームを構築し提供することができるビジネスモデルとなる。

【0362】

ここで説明した「人工多能性幹細胞治療支援システム２２２を使用したＩＰＳ幹細胞の人工多能性幹細胞治療」を望んでいる患者や家族は少ないと考えます。さらにかかりつけ医がＩＰＳ幹細胞の人工多能性幹細胞治療を進める医師５ａも少ないと思います。例えば人口透析を行っている患者へ進めないその理由は、完治への治療保証が持てない、自分は透析医なので人工多能性幹細胞治療ができない、人口透析でもいいではないか、人工多能性幹細胞治療を行っている病院４ａへ廻してしまうと自分の患者が減る、医師５ａ自らの最新知識の問題、等の難しい問題により患者に進めないのでしょう。
このシステムは、現在治療を行っているかかりつけ医が、人工多能性幹細胞治療の最後まで患者をフォローしケアすることで、従来の治療から最新医療による治療まで患者をフォローしケアした実績を付けられることも狙っています。医師５ａが自分のできることだけを行う治療から、患者をケアしながら完治させるまでを学び実績をつけ患者を社会に戻していくことが新しい医師５ａの仕事であり患者へのサービスになると考えます。今まで医療において、患者へのサービスは無かったのです、これは治療に関するサービスです。かかりつけ医は開業医が多いと思います、人口透析に毎週通院してくれる患者を完治してしまえば患者は減り医療経営に影響が出てくると思います。
その為に医療経済圏２４には利益を生み出す様々なシステムを用意し、本件のような患者へのサービスを提供し、医療機関４も利益をとれるような内容となっています。
プラットフォーム化されているシステムに「人工多能性幹細胞治療支援システム２２２」を医療経済圏２４の中でサービスを提供することで、沢山の人工多能性幹細胞移植治療を受けられそうな患者を見つけ出し、かかりつけ医が自ら、人工臓器作製事業者２２３、手術を行える医療機関４、執刀できる医師５ａ、を探し出し、患者を完治させるプロデュースを行い、沢山の患者を社会に戻す一部の病気を患わっている患者へのサービスです。
患者に人口透析や処方しか行っていない医療機関４には使用していただきたいサービスである。さらに他の実施形態で説明しているサービスを医療経済圏２４の中で利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者は「患者へのサービス」を提供していない医療機関４を選ばなくなると推測する。患者への様々な医療サービスを提供する時代が始まると考える。

【0363】

本実施形態において、ここまで説明した手法を利用することにより、人工多能性幹細胞治療支援システム２２２は、ビジネスモデルとして次の５つを提供することができる。
１）移植候補患者情報に保存されている移植候補患者の患者とかかりつけ医に対して、一生涯の治療から人工多能性幹細胞治療への切り替えの勧めをする情報の斡旋サービスを提供することができる。
２）移植候補患者情報に保存されている臓器移植を決めた患者とかかりつけ医に対して、医療経済圏ＤＢ２１から、人工臓器の移植手術を行える医師５ａと、人工臓器の移植手術を行える医療機関４と、患者の人工臓器を作製する事業者とをサーチし提供することができる。
３）臓器作製事業者とかかりつけ医療機関４と移植手術する医療機関４と、執刀医と主治医と移植手術に携われる医療スタッフと患者との間で、患者の診療情報の共有を行える仕組みによるサービスの提供することができる。
４）患者の治療費又は移植手術入院費を削減する事を行うために、医療経済圏ＤＢ２１内にある情報からサーチした再生医療を行いたい医療機関４、臓器作製事業者、執刀する医師５ａやその他に対して、患者の臓器移植に成功した診療情報の全てを販売提供することができる。ここで販売提供した利益を、患者の治療費又や移植手術入院費に充当することで、患者の俯瞰が軽減される。
５）プラットフォーム型医療機関４支援システム１と医療情報共有データベース２の運営を維持するために次の２つのサービスを行い、その報酬でプラットフォーム型医療機関４支援システム１と医療情報共有データベース２の維持を行う。
１つ目のサービスは、これから移植手術を請負いたい医療機関４、実績を上げたい臓器作製事業者、実績を上げたい執刀する医師５ａ等に対し移植候補患者情報に保存されている移植候補患者から臓器移植を受けたい患者を紹介行う。
２つ目のサービスは、移植手術を請負いたい医療機関４、及び、臓器作製をしたい事業者からの広告請負を行い、移植候補患者情報に保存されている移植候補患者とそのかかりつけ医に対して広告の展開を行う。

【0364】

＜第１０実施形態＞
現在、師士業に携わる人の評価や業務達成の成績を知るには社会のシステム又は社会のサイトから知ることができる。しかし、実績ある優秀な人材を探すにはややハードルが高く時間をかける必要もある。そのため、社会のシステム又は社会のサイトにある師士業者の業務成果情報から優秀な人材を見つけ依頼する業務の成果を確実に出す師士業者へ業務を依頼しても希望する結果に到達しない場合もある。
本開示の業務結果取得システム２４２は、実績ある優秀な人材を探し業務依頼を行うビジネスモデルを実現することを目的としている。
ここで言う師士業は、弁護士や弁理士などの職務上必要な場合において職務上請求を行う権限がある８士業をはじめ、技術士や建築士、獣医師などの職業名の最後に「士」または「師」が付く職業のことを示す。ただし、医師５ａや歯科医師５ｄ、助産師５ｅ、薬剤師５ｃ、理学療法士５ｆ、臨床工学技士５ｇなどの医療に関わる職業を除くものとする。
インターネットの検索エンジンを利用し、検索結果から師士業従事者を見つけると、そのホームページに記載された内容は、師士業従事者の自らが記載した自画自賛による内容が記載されており、業務達成の成績を見つけることはできない。

【0365】

弁理士について記載すると、特許出願において書類の作成を依頼すると、弁理士又は特許事務所により料金はまちまちである。弁理士や弁護士や調査員を多く抱えている事務所に限り代金は高い、それとは反対に個人で業を営んでいる弁理士の代金は安い。その代金の違いに依頼された業務の達成度という評価基準はあるのだろうかと疑問に思う依頼者は多いと推測する。高い代金を支払っても特許庁から拒絶される。拒絶の理由が先行技術として存在するため新規性や進歩性が否定だと、腹立たしくなることもある。金額の内訳には、調査料や図作成など形状されているが、調査など満足に行っていない、きちんと調査行っている所もありますが、今話題にしているのは代金です。さらに外部に図の作成を行った代金それは会計監査上、計上してはいけない事だが実際には行われており依頼した側は逆らうことができず支払う選択肢しかない。外部に図の作成を出した代金を依頼者に負担するのは間違いであり、それでも外部に出すなら依頼者の許可をとる事が必要。このように依頼側に逃げ道の無いビジネスを行っているのが師士業のビジネスである。
そんな中で個人が営んでいる弁理士は頑張っているが、個人だからと称賛する訳ではない。とにかく個人でも依頼者への成果「特許権利の取得」、この結果を出せない弁理士が高い代金を請求することに疑問を感じる。依頼した業務の成果を出すことが対価である。現在では成果を出せる師士業従事者を見つけることができない。依頼者への成果をどれくらい果たせたかを知るすべがない。どれくらいの仕事を依頼されているか知るすべがない。今わかるのは成果が出せるかわからない料金だけ。依頼者の目的を達成する世間に埋もれている師士業従事者を見つけ出すシステムが必要だと考えている。

【0366】

本開示の業務結果取得システム２４２は、プラットフォーム型医療機関支援システム１上にあり、ネットワーク上で師士業従事者の業務結果の情報を公表している社会のシステム又は社会のサイトにある情報から業務結果の情報を取得したことから各処理が開始されるようになる。
ここで、「師士業従事者の業務結果」と「業務結果の情報を公表している社会のシステム又は社会のサイト」について、弁護士と弁理士を例に説明する。
弁護士の場合、業務結果は、依頼者からうけた民事や刑事裁判の弁護や調停の対応などの案件の結果のことを示す。業務結果の情報を公表している社会のサイトとしては、弁護士ドットコムなどがある。
弁理士の場合、業務結果は、依頼人から受けた知的財産権の出願などの案件の結果のことを示す。業務結果の情報を公表している社会のサイトとしては、J-PlatPatなどがある。
業務結果取得システム２４２が取得した業務結果の情報は、データベースで処理可能な形式に変換し、社会業務結果情報として、師士業従事者評価ＤＢ２４１に保存する処理を行う。業務結果の情報は、師士業従事者ごとの依頼された業務の件数やその業務の達成した件数のことを示す。データベースで処理可能な形式とは、データベースのテーブル上にカラムとロウとしてマトリックス状に構成され社会業務結果情報にある師士業従事者の業務成果を評価するために必要な複数の構成要素がそれぞれデータベースのマトリックス状テーブルにあてはめる処理をされた構造のことを示す。データベースで処理可能な形式で保存されたデータの例を図５１に示す。
業務結果取得システム２４２は、データベースで処理可能な形式で保存した社会業務結果情報を関数を用いて、師士業従事者ごとの依頼された業務の件数値と、その業務の達成した件数値とを関数を用いて集計する処理を行う。また、業務結果取得システム２４２は、師士業従事者ごとの依頼された業務の件数値と、その業務の達成した件数値から、複数の師士業者ごとの業務達成評価指数値を算出し評価する処理を行う。この処理の結果も、医療情報共有データベース２の師士業従事者評価ＤＢ２４１に社会業務結果情報として保存される。
師士業従事者ごとの依頼された業務の件数値と、その業務の達成した件数値について弁護士と弁理士を例に説明する。第１０実施形態のデータベース構成を図５２に示す。
弁護士の場合の依頼された業務の件数値とは、依頼を受けた件数を示し、業務の達成した件数値とは、依頼を受けたうち依頼者の要望に応えられた件数を示す。一見業務の達成に見えないが、業務の達成に含まれる例をいくつか示す。刑事事件で有罪がほぼ確実な場合、想定される量刑より軽い刑罰となった場合、依頼者の要望に応えられていると推定されるため業務達成したと言える。民事事件で、損害賠償請求の被告となった場合、請求額より少ない判決となり、依頼者の要望に応えられている場合も業務達成したと言える。
弁理士の場合の依頼された業務の件数値とは、代理人として出願した件数を示し、業務の達成した件数値とは、登録査定となった件数を示す。
業務達成評価指数値を算出は、依頼された業務の件数値と、その業務の達成した件数値との比率を基本に算出する。しかし、知的財産のように、出願したけど審査しない場合もある。この場合は、業務の件数値を出願した件数に代え、審査請求をした件数にしてもよい。
業務達成評価指数値を算出の例を示す。依頼された業務の件数値が１００件であり、その業務の達成した件数値が７５件の場合は、業務達成評価指数値は、０．７５（75％）となる。
業務結果取得システム２４２は、社会業務結果情報として保存された業務達成評価指数値などの情報を業務成果の評価としてネットワーク上に公表する。この公表の際、士業従事者ごとの依頼された業務の件数値と、その業務の達成した件数値を合わせて公開してもよい。
ネットワーク上に公表とは、インターネット上のWEBサイトに公開するなどのことを示す。

【0367】

業務結果取得システム２４２が保存した社会業務結果情報を医療情報共有データベース２の師士業従事者評価ＤＢ２４１に付加する処理を行う。師士業従事者評価ＤＢ２４１に付加することにより、優秀な師士業者を見つけやすく、そして師士業者の詳細を表示処理することで更に実績ある優秀な人材を探し業務依頼を行うビジネスモデルを実現するシステムの情報をスケールアップすることができる。
スケールアップするために、医療経済圏ＤＢ２１に保存されている師士業従事者属性情報と社会業務結果情報と業務履歴情報と業務履歴情報との情報により、これら師士業従事者の名前をキーに紐づけられたリレーションのデータベースに幅広い情報が付加されているのが師士業従事者評価ＤＢ２４１である。
師士業従事者属性情報は、保存されている個人情報２２の中に師士業従事者の業務地や師士業従事者の専門分野、師士業従事者の経歴、師士業従事者などの師士業従事者の属性情報などが保存されている。
業務履歴情報には、これまでの相談件数や案件受諾件数、各案件における相談回数、各案件における対応回数、各案件の初相談から案件完了までの期間、各案件における報酬、利用者３からの完了後の評価等の利用者３側から提供された成果情報との情報が保存されている。
これらにより師士業従事者評価ＤＢ２４１には、一人の師士業従事者に対して十数項目の情報が保存されているため、多岐に渡る深層検索により優れた人材を探すことができる。
弁理士の場合の検索のイメージを図５３に示し、依頼した場合のイメージを図５４に示す。

【0368】

医療経済圏２４を利用する利用者３が、実績ある優秀な人材を探し業務依頼を行うことを目的に本開示のシステムを利用する。本開示のシステムを利用する際の検索条件として、利用者３の居住地や利用者３の利用目的などの要素や、様々な要素の条件を用いる。
これらにより師士業従事者評価ＤＢ２４１には、一人の師士業従事者に対して十数項目の情報が保存されているため、多岐に渡る深層検索により優れた人材を探すことができる。
例えば、利用者３のロケーションから探すには、利用者３の居住地などの様々な情報を利用して検索を行うことにより、業務達成評価指数を目安に多次元的視覚効により、目的にあった実績があり評価されているが埋もれていた師士業従事者を発掘することができる。このシステムは、業務達成評価指数値をネットワーク上に公表するシステムの一部となっている。また、絞り込んだ、また検索された結果の師士業に対して、システム上で容易に業務を依頼することもできる。容易に業務の依頼とは、「ネットワーク上に公表するシステムの画面上で簡単な依頼内容を入力することで依頼が行える」「ネットワーク上に公表するシステムの画面上でワンクリックすることで依頼が行える」などのことを示す。

【0369】

実績ある優秀な人材を探すシステムを利用価値が高まるシステムへスケールアップを行うために、師士業業務情報ＤＢ２５１に蓄積保存されている師士業業務の業務履歴情報を利用する。
実績ある優秀な人材を探すシステムに業務履歴情報も利用することにより、目的にあった実績があり評価されているが埋もれていた師士業従事者を発掘の精度向上することができ利用者３の業務達成度満足度が上がる。

【0370】

本実施形態でここまで説明してきた実績ある優秀な人材を探すシステムは、実績ある優秀な人材を探し業務依頼を行うビジネスモデルを実現するシステムとなっている。利用者３は、確実に成果を出してくれる師士業従事者を探し出せるシステムである事、師士業従事者は確実に求められた結果を出せる師士業従事者として選び出させるシステムである事によりシステムが成立する。
本システムの利用料は、業務依頼した利用者３と、業務を受けた師士業従事者の双方からの成功報酬として徴収することにより行われる。

【0371】

ここまで、師士業は、医師５ａや歯科医師５ｄ、助産師５ｅ、薬剤師５ｃ、理学療法士５ｆ、臨床工学技士５ｇなどの医療に関わる職業を除いてきた。しかし、本開示のシステムを利用することができる。また、ＭＳＷ５ｈ（医療ソーシャルワーカー）、医療系研究者５ｉなどの医療に関わる職業名に「士」または「師」が付かない職業に拡大できる。
なぜ、ここまで医療に関わる職業を除外してきた理由は、医療においてネットワーク上で師士業従事者の業務結果の情報を公表している社会のシステム又は社会のサイトがないためとなっている。また医科大学や医療機関４においてはホームページで師士業従事者の紹介をしているが、これは自ら作成した情報でありこの情報だけで結果をだしてくれる師士業従事者にたどり着く可能性は低く、社会のシステム又は社会のサイトが公表している実際の業務実績はないものとなっている。

【0372】

そこで、本開示のシステムを医療に関わる職業で利用する場合は、「師士業従事者の業務結果の情報を公表している社会のシステム又は社会のサイト」に代え「プラットフォーム型医療機関支援システム１にある医療情報共有データベース２上の医療情報ＤＢに保存されている患者の診療内容が保存されている電子カルテ９ａ」を利用して業務結果の情報を取得する。

【0373】

医療に関わる職業の場合の業務結果取得システム２４２を説明する。
業務結果取得システム２４２は、医療情報ＤＢに保存されている患者の診療内容が保存されている電子カルテ９ａから師士業従事者が扱った患者数、師士業従事者が扱った病名とその患者数、師士業従事者が扱った完治または寛解した患者数、師士業従事者が扱った難病の治療に使った治療方法、師士業従事者が扱った難病名、師士業従事者が携わった手術名と回数、等の情報を取得して師士業従事者評価ＤＢ２４１の社会業務結果情報に保存する。
この情報を利用して、医療以外の師士業と同じ方法で業務達成評価指数値を算出し社会業務結果情報として保存された業務達成評価指数値などの情報を業務成果の評価としてネットワーク上に公表する。業務達成評価指数値の算出に用いる依頼された業務の件数値と、その業務の達成した件数値は、それぞれ師士業従事者が扱った患者数と師士業従事者が扱った完治した患者数を利用する。

【0374】

さらに、医療経済圏ＤＢ２１に保存されている師士業従事者属性情報と社会業務結果情報とが紐づけられたリレーションのデータベースに幅広い情報が付加されている。
師士業従事者属性情報は、保存されている個人情報２２の中に師士業者自身で記録した医療従事者５の勤務地履歴や、医療従者の専門分野、師士業従事者の経歴、師士業従事者の研究内容、師士業従事者の研究内容、師士業従事者の開発関係、師士業従事者などの師士業従事者の属性情報などが保存されている。

【0375】

医療経済圏２４を利用する利用者３が、実績ある優秀な人材を探し業務依頼を行うことを目的に本開示のシステムを利用する。本開示のシステムを利用する際の検索条件として、
利用者３の居住地や、利用者３の利用目的、病名、治療、専門性、使用した新薬、様々な要素を用いる。利用者３の居住地などの様々な情報を利用して検索を行うことにより、業務達成評価指数を目安に多次元的視覚効により、目的にあった実績があり評価されているが埋もれていた師士業従事者を発掘することができる。このシステムは、業務達成評価指数値をネットワーク上に公表するシステムの一部となっている。医療従事者５場合の検索のイメージを図５５に示し、依頼した場合のイメージを図５６に示す。
また、前記絞り込んで検索された結果の師士業に対して、システム上で容易に問合せや診療予約、相談などを依頼することができる事と、問合せや相談した回答などから容易に診察予約が行えるプラットフォーム型医療機関支援システム１にある師士業従事者システム２４３によるサービスを提供する。容易に問合せや診療予約、相談などを依頼とは、「ネットワーク上に公表するシステムの画面上で相談内容や問合わせ内容などを入力することで医療機関４に連絡が行える」などのことを示す。また、問合せや相談した回答などから容易に診療予約などの利用予約が行えるとは、「医療機関４からの回答の画面上で日時などを選択することにより診察予約が行える。」などのことを示す。

【0376】

実績ある優秀な人材を探すシステムを利用価値が高まるシステムへスケールアップを行うために、師士業業務情報ＤＢ２５１に蓄積保存されている師士業業務の医療業務履歴情報を利用する。師士業業務の医療業務履歴情報には、これまでの相談件数や案件受諾件数、各案件における相談回数、相談からの回答の満足度、各案件における対応回数、各案件の初相談から完治までの期間、各案件における報酬、治療開始から完治までの期間、利用者３からの完了後の評価等の利用者３側から提供された情報を蓄積されている。
社会業務結果情報と師士業従事者属性情報に加え、医療業務履歴情報を紐づけたリレーションのデータベースとすることにより、利用者３による利用者成果の情報が付加された事で幅広い師士業者の業務に関する情報のソースとなる。
実績ある優秀な人材を探すシステムに医療業務履歴情報も利用することにより、目的にあった実績があり評価されているが埋もれていた師士業従事者を発掘の精度向上することができ利用者３の業務達成度満足度が上がる。

【0377】

本実施形態でここまで説明してきた実績ある優秀な人材を探すシステムは、実績ある優秀な人材を探し業務依頼を行うビジネスモデルを実現するシステムでとなっている。本システムの利用料は、業務依頼した利用者３と、業務を受けた師士業従事者の双方からの成功報酬として徴収することにより行われる。

【0378】

＜第１１実施形態＞
ここまでの実施形態で、医療機関４の経営支援や医療支援を行っていくために必要なシステムの考案の説明を行ってきた。これらのシステムを、医療機関４の経営者や医療機関４で働く医師５ａや看護師５ｂなどの意見を取り入れ自分自身で構築を行う（システムを内製化する）ことで医療の現場で使いやすいシステムになることが期待できる。システムを内製化することは、従来の医療機関システムの構築手法と大きく異なっている。しかしながら大手の民間企業の社内システムは内製化により構築が行われているのは、コンピュータのダウンサイジングが始まったころの約25年前からである。民間企業は社内の事業に合わせた仕様の内製化で構築しグループ企業でもそれぞれが内製化した専用システムを構築していた、2000年前後のネットバブル崩壊から社内システムの徹底的なコスト管理により、内製化したシステムの所有権財産権からグループ各社も同じ社内システムを共通化し複製権により全社で利用するようになり、現在ではそのシステムがクラウドを使用した使用権を譲り受けた形での全社内同一システムをプラットフォーム化された共有利用のシステムとなっている。それに対して医療機関４では、ITベンダーに対し、システムの仕様を伝え、その仕様に合わせてITベンダーがパッケージ化されたソフトをカスタマイズして構築していた。場合によっては、カスタマイズを行わずパッケージ化されたソフトウェアのまま納品されることもある。今までITベンダーがパッケージ化されたソフトをカスタマイズして構築してきた結果、現場が使いにくいシステムとなる場合もある。それぞれの医療機関４がパッケージ化されたソフトウェアを購入して利用している。
また、システム開発が失敗した事例もある。開発が失敗した事例としては、北海道地方の医科大学が大手通信企業に発注し、平成２０年１１月から開発がはじまり、平成２２年４月に医科大学側が開発契約を終了させた事例がある。この事例の場合、利用者３である医科大学側の現場の声と決定した仕様との乖離が原因で開発が失敗した。本開示のシステムは、自分自身で構築を行うためこのようなことは発生しないようになる。
大手の民間企業の社内システムを内製化する理由の一つに「縛り」の理由がある。パッケージメーカーの意思に事業が左右されてしまう事である。パッケージ製品のサポートの中止や、プロダクトの中止により、別製品へ移行させられる。オペレーティングシステムの一種であるWindows（登録商標）をサポート期限以降も使用している場合に障害が発生するとサポート期間中に比べ数倍の対策費用を請求される。製品の改善を要求しても受け付けられなかったり高額なカスタマイズ料を請求される。老朽化から更新に使い勝手の良い他社製品を選ぶとデータベースの移行作業を断り無理矢理に他社製品への移行を阻止される。パッケージソフトの購入なのにコンピュータもセットで買わされる。パッケージソフトの購入なのにコンピュータの保守費まで高額となる。このように一度購入したパッケージメーカーに縛られてしまうという事が起きており、このことは１９９０年代初頭に民間企業で起きていたが、今では見られない事が医療業界では未だに起きている。
そんな状況の中で、一部の医療機関４では、パッケージ品を購入してしまう事から発生する「縛り」、この社会の煩わしさに気が付き、「縛り」から逃れるために、既に開業医師５ａの一部は自らの手により自力で内製化を行い、場合によっては医師５ａが内製化したシステムの販売も行っている。
また、医療機関４で働く医師５ａや看護師５ｂなど利用者３自身が追加機能の開発を行い、開発したものを公開し広く使っていくことでも、同じ畑で働く者からの意見や要望をシステムに取り入れることでどんどん成熟したシステムになり手放すことができなくなっていき、民間企業の社内システムのように関連会社へ提供したり、銀行金融業のように同業者他社と共同開発し共同で利用したりする、このようなことが医療業界で起きる事を望んでおり、本考案のシステムはより良いものになると考えている。

【0379】

医療機関４の経営者や医療機関４で働く医師５ａや看護師５ｂなどの意見を取り入れ自ら考案を自分自身で内製化を行うには、システムの内製化を支援するためのシステムが必要となる。また、自身でシステム構築を行った場合や、システムを利用する利用者３自身が追加機能の開発を行った場合、構築したシステムや開発した追加機能の財産権や所有権などの管理も行う必要がある。財産権や所有権の管理を行わないと、構築したものや開発したものを第三者が勝手に使用した場合に気が付かない場合や、第三者が知財権等を主張した場合法的に対抗することが難しくなる。自ら内製化したことにより複製権を行使し販売や共有による利用量等による、医療機関４の第二の収入源を得ることもできる。

【0380】

システムの内製化を支援するためのシステム（開発プロセスシステム２６２）について説明する。
このシステムは、プラットフォーム型医療機関支援システム１の医療情報共有データベース２にある開発プロセスＤＢ２６１を利用して構成されている。開発プロセスＤＢ２６１には、システムの内製化を進める上で必要な、資金に関する様々な情報と、医療機関４はじめ企業や個人に関する様々な情報と、資金調達に関する様々な情報と、契約に関する様々な情報と、ライセンスや権利に関する様々な情報となどの情報が保存されている。ここで言う企業とは、私企業だけでなく、公企業や地方公共団体など法令上法人とみなされる団体や個人事業主なども含んでいる。
また、本開示のシステムは、システムの内製化に要する期間を、「企画段階」、「開発段階」、「内製化が完了した後の運用段階」に及ぶ３つのフェーズ毎に分類処理し、各段階で使用する様々な機能のプログラムにより発生する情報を取得し前記開発プロセスＤＢ２６１に保存処理を行う。さらに、本開示のシステムは、開発プロセスＤＢ２６１にある情報を利用して、公開募集する公募機能と、資金の調達を行う機能と、ライセンスや権利を管理するライセンス管理機能なども有している。第１１実施形態のデータベース構成を図５７に示す。また、従来と本開示の内製化の権利の違いを図５８に示す。

【0381】

ここから、開発プロセスＤＢ２６１に保存されている情報やその情報を利用した機能について順次説明する。

【0382】

システムの内製化を支援するためのシステム（開発プロセスシステム２６２）のうち資金調達に関する部分について説明する。
システムを内製化するにあたり、内製化を行うための資金を調達する必要がある。医療機関４などの自己資金のみで行える場合は資金調達を行う必要はない。しかし、システムを一から開発するとなると多くの資金が必要となり、自己資金のみでは難しい。そのため、外部からの資金を調達する必要がある。
外部から調達する資金は、投資や、融資、寄付、クラウド出資などである。調達する資金の資金調達先や資金を調達する手段、調達するために公告する方法などを管理するシステムを作ることより「資金調達の支援」を行う。開発プロセスシステム２６２は、この「資金調達の支援」を行うことができる。

【0383】

大きなシステムの内製化に必要とする開発資金を集めるための支援をするシステム（開発プロセスシステム２６２）は、企画段階の時期に、この内製化する上で関わってもらえる企業探しとして、参加して医療事業を検討している企業、システムの利用目的の企業・自治体や、助成金や補助金を提供する自治体や国、いずれ参加する事をにらみ出資や投資を検討している企業、投資を検討している投資家や企業、開発の請負いを考える企業、興味や関わりを持ちたい個人、海外企業、等に対して興味を持ってもらう事と繋がりを作る事の為に、概要情報や説明情報などの情報の開発基本情報を開発プロセスＤＢ２６１から取得し公開し公知する。それにより個人や企業からのアクセス状況や問い合わせの情報から、アクセス先の情報を取得し資金調達先候補情報として開発プロセスＤＢ２６１に保存し、この情報を元に調達する資金の資金調達先の情報として利用する。

【0384】

開発プロセスＤＢ２６１に保存されている前記フェーズ毎に前記資金に関する様々な情報には資金分類情報と資金調達情報と利用者情報とがある。
資金分類情報は、システムの構築にかかわる様々な資金を分類した情報で、資本出資による資金情報と、投資による資金情報と、融資による資金情報と、寄付による資金情報と、クラウド出資による資金情報などの資金に関する情報が分類され登録保存されている。
利用者情報は、本開示のシステムの構築に関わる医療機関４などの企業や人の情報のことで、自治体、医師会、医療機関４、介護機関、企業名、金融機関名、一般投資家などの情報や構築に関わる医師５ａや看護師５ｂなどの医療従事者５の情報が保存されている。
資金調達情報は、資金調達先情報と、資金調達方法情報と、広告情報の３つの情報で構成されている。
資金調達先情報は、本開示のシステムの構築などに関わる資金の調達先の情報を分類した情報で、資本参加する者の情報、産業に従する所の情報、産業に従さない所の情報、スポンサーの情報、金融機関の情報、一般投資家情報などの情報が保存されている。
開発プロセスシステム２６２は、資金調達先候補情報に保存された情報と、分類された資金調達先情報を利用して、資金調達先に自動で連絡することができる。
資金調達方法情報は、資金分類情報として分類し保存した各資金情報の調達する方法に関する情報で、ＷＥＢ利用した資金調達の公開募集や、ダイレクトメールによる資金調達募集、クラウドファンディングよる資金調達募集、広告よる資金調達募集、FinTechよる資金調達募集などの資金調達の方法の情報が保存されている。
広告情報は、システムの概要や資金調達している事を知らせる広告の手段を分類した情報で、新聞雑誌で広告を行うための情報、ホームページで広告を行うための情報、メディア動画広告で広告を行うための情報、ＳＮＳ掲載で広告を行うための情報などに分類した情報が保存されている。
開発プロセスシステム２６２は、資金分類情報と資金調達情報と利用者情報とを利用し、資金調達をする上で資金調達先の絞り込みや、資金の調達を行う手段を分類して資金調達先毎に絞り込み、資金調達先に様々な情報を広告する方法、資金調達の計画を立てる、調達する資金の状況を管理しモニタリングするなどの処理を行うことでフェーズ毎に資金に関する様々な情報の管理が行える。

【0385】

また、開発プロセスＤＢ２６１には、これから内製するプログラムの概要情報や説明情報などの情報が開発基本情報として保存されており、この情報が、資金調達を行うための説明資料となる。
本開示の開発プロセスシステム２６２は、資金分類情報から取得した調達する資金の分類から絞り込みと選定を行う処理を行う。また、調達する資金の分類で調達する調達先の情報を資金調達先情報から取得する処理を行う。調達先の情報の取得結果を利用して絞り込みによる選定する処理を行うことで、資金の分類で調達する調達先を決定する。
決定した調達先から資金を調達する方法として、資金調達方法情報に保存された調達先に対応した調達方法を取得する処理することで調達方法を決定する。
開発プロセスシステム２６２は、決定した調達先から決定した調達方法の資金を用いて資金調達するにあたり、説明資料である開発基本情報を調達先に送る処理を行う。この処理を行うことで資金の調達が開始される。
また、開発プロセスシステム２６２は、資金調達を公知するために広告情報から取得した広告手段を用いた広告を展開する処理を行う。この広告を利用した資金調達計画の立案処理と実施も行うことができる。

【0386】

開発プロセスシステム２６２が広告による資金調達を実施し、資金調達に対する応募が行われると、応募された情報が、開発プロセスＤＢ２６１上の応募情報に保存される処理が行われる。応募された情報には、応募を行った資金調達先の情報と資金金額や契約に関する内容が保存されている。この応募情報は、資金分類ごとや資金調達先ごとに分けて保存処理されており、資金分類毎や資金調達先毎の調達する資金の調達状況を端末に可視化する処理をして確認することもできる。

【0387】

ここまで説明してきた機能を組み合わせることでシステムの内製化を支援するためのシステムのうち構築するための資金の調達を支援するシステムを構築することができる。内製化システムを開発に必要な資金フロー図を図５９に示す。

【0388】

開発プロセスシステム２６２は、企画段階から運用開始後の収支予想の計算処理を行う機能を有している。この機能は、企画段階、開発段階、運用段階のそれぞれのフェーズで収入予定金額と支出予定金額とをそれぞれ総計（合計）する処理を行い、その差を比較する処理を行う。処理をすることで行う。
収入予定金額は、出資を受けた金額、融資を受けた金額、構築したシステムの外部提供によるライセンス料や利用料などの各フェーズで予定される収入のことを示す。
支出予定金額は、開発費支払いや開発機材購入費、融資の返済、人件費、賃料、雑費などの各フェーズで予定する支出のことを示す
また、ここまで記載してきた各実施形態で削減した費用による収益も含めて収支予想を行ってもよい。

【0389】

内製化して構築したシステムは、ネットワーク上で稼働することで、利用する医療機関４や介護施設６や企業やそれらに従する人達を含む医療経済圏２４に属する者が利用できる

【0390】

システムの内製化を支援するためのシステム（開発プロセスシステム２６２）のうちライセンス管理に関する部分について説明する。
前述の通り、構築したものや開発したものを第三者が勝手に使用した場合に気が付かない場合や、第三者が知財権等を主張した場合、合法的に対抗することが難しくなる。このため、構築や開発したシステムの権利管理を行う必要がある。

【0391】

開発プロセスシステム２６２には、ライセンスや権利に関する様々な情報には、所有権と、財産権と、著作権と、使用権と、複製権等が開発プロセスＤＢ２６１に権利情報としてマスター登録されている。この権利情報に内製化して構築したシステムのライセンスや権利に関する情報の保存処理をする。
医療経済圏２４に属する者、すなわち別の団体や別の地域の医療機関４や別の自治体が、医療経済圏２４の構築を行うために構築し内製化したシステムを利用したい場合、開発プロセスシステム２６２上のライセンス管理システム２６３に使用申請を行うことができる。
使用申請が行われると、ライセンス管理システム２６３は、内製化したシステムの所有権財産権を所有している団体に対して権利情報に保存された情報をもとに使用許可を与える処理を行う。この使用許可には、システムの複製権と使用権などが含まれている。また、ライセンス管理システム２６３は、使用許可を与えると、構築した内製化システムを複製により提供または販売を行い、提供または販売先の情報を開発プロセスＤＢ２６１に権利情報に保存する処理を行うことで管理を行う。
構築した内製化したシステムの提供方法をプラットフォーム化したシステムへのネットワークを使用した接続に変更することもできる。この場合、利用を希望する利用者３や団体に対して権利情報からシステムの使用権のみをライセンス管理システム２６３に登録する処理で管理する形で使用が与えられる。
結果、無形物である内製化したシステムやシステムを構成しているソフトウェアプログラム等におけるライセンスや使用権の権利の管理を行うことができる。

【0392】

ライセンス管理システム２６３は、構築した内製化したシステムの複製権と使用権など管理だけでなく、医師５ａや看護師５ｂなどの医療機関４で働く医療従事者５、介護士、医療機関４で働く事務職、医療に従事する企業、医療関係の研究者５ｉなどが考案した、開発した内製化したシステムの改善案、プログラムの追加機能案などの「ひらめきとして頭の中にあるアイデア」の権利管理を行うことができる。「ひらめきとして頭の中にあるアイデア」などの権利の管理方法は、構築した内製化したシステムの複製権と使用権などの管理と同様の方法で行える。
「ひらめきとして頭の中にあるアイデア」の概要などのデジタル化を行い、デジタル化された物をライセンス管理システム２６３に入力し、その入力した内容をライセンス管理システム２６３が考案概要情報として開発プロセスＤＢ２６１に保存する処理をすることで行われる。この考案概要情報は、権利情報に紐づいた情報あり、医療経済圏２４の中だけを対象とした権利となっている。

【0393】

「ひらめきとして頭の中にあるアイデア」の概要などのデジタル化は、アイデアを口頭で説明した音声を録音しデジタル化した情報や、アイデアの説明をワープロなどで文章化したデジタル文章や、アイデアの説明を手書きで書いた絵などをスキャンしたデータや、アイデアの説明をグラフィックソフトで描いたデータや、アイデアのプレゼンテーション資料のデータや、アイデアのシミュレーションデータや、アイデアのアニメーションデータや、アイデアの２Ｄ―ＣＡＤや、３Ｄ―ＣＡＤのデータや、アイデアを簡単なロジック化したフローチャートのデータ等のデジタルデータをＮＦＴで管理するデータの対象とする。

【0394】

ライセンス管理システム２６３で行う考案概要情報の管理は、考案概要情報に対する権利侵害や考案概要情報の複製行為や盗用行為から保護するために非代替性トークン（NFTまたはnon-fungible token）を用いて行ってもよい。NFTは、偽造不可な鑑定書・所有証明書付きのデジタルデータのことであり、アイデアの概要をデジタル化した考案概要情報をNFT用いて管理することによりアイデアの盗用などから守ることができる。また、NFTとライセンス管理システム２６３は、考案概要情報と考案者の情報と開発事業社とを紐づけて管理する機能も有している。NFTの利用は、デジタルアート等の販売に近年では利用されている。

【0395】

上記では、医師５ａや看護師５ｂなどの医療機関４で働く医療従事者５、介護士、医療機関４で働く事務職、医療に従事する企業、医療関係の研究者５ｉなどが考案した、開発した内製化したシステムの改善案などの「ひらめきとして頭の中にあるアイデア」の権利管理が行えると記載した。しかし、医師５ａや看護師５ｂなどの医療機関４で働く医療従事者５、介護士、医療機関４で働く事務職、医療に従事する企業、医療関係の研究者５ｉなどの考案は、開発した内製化したシステムの改善案などに限らず、医療機器や製薬や介護機器など様々なもののひらめきを対象としたアイデアの権利管理も行える。本開示のライセンス管理システム２６３は、医療機器や製薬や介護機器など様々なもののアイデアをデジタル化したうえで考案概要情報に保存し、デジタル化した考案概要情報の権利管理をNFTを利用した同様の手法により行うことができる。本考案で「ひらめきとして頭の中にあるアイデア」にNFTを利用する目的は、アイデアの考案者とそのアイデアの開発を行う開発事業社の権利保護を行うことと、デジタル化したアイデアのデータを無断複製することからの権利侵害を防ぐことも目的のうちである。
また、本開示の開発プロセスシステム２６２は、医師５ａや看護師５ｂなどの医療機関４で働く医療従事者５、介護士、医療機関４で働く事務職、医療に従事する企業、医療関係の研究者５ｉなどが考案した医療機器や製薬や介護機器などアイデアを製品化や知的財産の権利化するための資金調達と製品化する企業を探すことができる。資金調達と製品化する企業又はプログラム開発を行う企業を探す方法は、資金調達方法情報にある手段を使用して行い、広告情報にある広告方法を利用して考案概要情報を広く公知することで行う。この募集時にもNFTを用いてアイデアの権利管理を行い、製品化するために募集した開発事業社や製造業者や製薬会社などを考案概要情報に紐づけて権利の管理を行う。
医師５ａや研究者や技師や看護師５ｂの場合、学会への文献もNFT管理し、文献から製品化されることも考えられる、さらに場合によっては特許申請へのルートも考えられる。特に薬の場合、特許を取得して２０年以内に製品化した薬品に投資した額を取り戻すために薬価が高い。特許の取得が研究中ではなく、製品化前に特許取得ができると本来の２０年から２５年程度に延ばすことも考えられる。

【0396】

本開示の開発プロセスシステム２６２において、資金調達した資金及び投資家による投資した資金などから開発などに利用する資金の受けとる方法は、円通貨を利用した一般的な方法だけでなく、それ以外の方法を用いて行うこともできる。円通貨を利用した一般的な方法とは、「現金で資金を渡す」「資金を銀行口座に振り込むことにより渡す」「小切手で渡す」など円通貨を直接渡す方法のことを示す。
本開示で利用可能な資金のやり取りする円通貨を利用しない方法は、次の２つの方法となっている。１つ目の方法は、第４実施形態に記載されている医療用決済口座を利用した医療機関決済支援システム１０２を利用して資金のやり取りをする方法で、医療機関決済支援システム１０２が資金調達先の医療用決済口座から開発を行う医療機関４などの医療用決済口座へ資金を移動する処理を行うことで行われる。２つめの方法は、汎用決済システム９ｃを利用する方法で暗号通貨やデジタル通貨を用いて資金のやり取りを行うことができる。汎用決済システム９ｃとは、出願人考案の特願２０２１―１１３９２７に記載されている暗号通貨やデジタル通貨などを利用して決済が行えるシステムのことを示す。
また、資金の提供は円通貨建てだけでなく、外国通貨建てで行われてもよい。

【0397】

ここまで、開発プロセスシステム２６２は、内製化して構築したシステムを構築するための資金調達の方法や、医療従事者５が考えたアイデアの管理について説明してきた。しかしながら、資金調達をしたり、アイデアの管理をしても、実際にシステムを開発する企業を選定しなければ意味がない。システムを開発する企業は、過去に発注したことがある企業や各種媒体から開発可能な企業を抽出し、資金調達の方法と同様の方法でシステムを開発する企業を選定する。

【0398】

ここまで、アイデアの権利管理を行う対象として医師５ａや看護師５ｂなどの医療機関４で働く医療従事者５、介護士、医療機関４で働く事務職、医療に従事する企業、医療関係の研究者５ｉなどと記載してきた。アイデアの権利管理を行う対象は、上記の対象者だけでなく、医療経済圏２４を利用している、利用者３などの人や医療に直接関係していない企業などを対象として権利管理を行ってもよい。
また、本システムはアイデアの権利管理を行うサービスを提供するビジネスモデルとしてプラットフォーム化したシステムにより提供することで、様々な利用者３のアイデアの権利管理を行うビジネスモデルとなる。

【0399】

ここで説明した「システムを内製化するための資金調達」は、医療経済圏２４というバーチャルな環境を利用しビジネスに必要なシステムを共有することができる。同じようにシステムを提供している米国のGAFAと呼ばれている４つの企業「Google(登録商標)」「Amazon(登録商標)」「Facebook(登録商標)」「Apple(登録商標)」がある。この米国のＧＡＦＡは、システムを利用している企業から発生する企業のデータはＧＡＦＡの所有物になってしまう側面があるクラウドシステムである。ＧＡＦＡを利用している日本企業は、ビジネス上のデータを取られてしまっても構わないという企業や、取られていることに無頓着な企業が利用しており、いつか日本企業にとってそれが問題になる時が来ると予想している。保存したデータをＧＡＦＡに取られない意味でも日本で構築する意味はあるし、医療のデータは個人情報２２である側面からも外国企業には渡せない意味がある。本考案は、医療経済圏２４の中にあるシステムを利用することで医療機関４や企業で発生するデータを医療経済圏２４の中で共有利用することで、そのデータを利用して利益を生み出す様々なデータ処理からシステムにより利益を産出することができ、その利益は利用者３に対して還元されるところがＧＡＦＡとの違いである。ＧＡＦＡに並ぶ医療経済圏２４を構築することは日本にとって必要なものであると考える。
ここで説明した様々なシステムにより構成された医療経済圏２４では利用する医療機関４や企業に対して利益を産出するシステムの構築には相当な高額資金が必要とされるのは言うまでもない。このシステムを医療機関４のだけで構築することは、構築に必要な資金の調達を行うにしろ、構築に必要な複数のプログラム開発企業やハードウェアシステムを支える企業、システムメンテナンスを行う企業等、開発の企画段階から長期にわたりサポートを専門に行う企業を選定することも医療機関４としては困難であると推測できる。そういった事を回避する目的の本考案は、必要な開発資金を集めるために、資金調達する資金内容や、調達対象先の医療機関４や企業や、公募方法等をシステムで管理し計画をたてて行うことで、開発に必要な資金や企業を集めることができる。また開発するシステムやプログラムの権利管理を行うことで、開発したシステムやプログラムは医療機関４や医師会などが権利の全てを所有することにより、医療機関４の一存でシステムをどんなようにも変更でき拡大することもできるようになることは、1990年代から始まった民間企業の社内システムに追いつき並んだことになる。

【0400】

本考案の開発プロセスシステム２６２で行う資金調達時に、開発するシステムを債権化して投資者を募ってもよい。この債権化は、必要とする資金を募集する口数で割り、割った金額が１株の金額とする。投資者は、株を買うことにより、開発完了後、開発したシステムの優先利用権やインセンティブなどを受け取ること等を債権化システムで行うことができる。この手法は、競馬の種牡馬におけるシンジゲートを組む方法と同じであり、種牡馬における種付権や余勢種付による分配が、本開示の、開発したシステムの優先利用権やインセンティブなどに相当します。

【0401】

以上、本発明の実施形態をもとに説明した。各実施形態は例示であり、それらの各構成要素の組み合わせにいろいろな変形例が可能なこと、また、そうした変形例も本発明の範囲にあることは当業者に理解されるところである。

【符号の説明】

【0402】

１ プラットフォーム型医療機関支援システム
２ 医療情報共有データベース
３ 利用者
４ 医療機関
５ 医療従事者
６ 介護施設
７ 運転手
８ 介添人
９ 医療情報システム
１０ 医療機関経営事業支援システム
２１ 医療経済圏ＤＢ
２２ 個人情報
２３ 企業情報
２４ 医療経済圏
３１ 経理業務ＤＢ
３２ 設備機材システム
３３ 廃棄回収システム
４１ リカーリングＤＢ
４２ リカーリングシステム
４３ サブスクリプションシステム
５１ 診察所要時間ＤＢ
５２ 診察時間システム
５３ 診療情報ＤＢ
６１ 予約ＤＢ
６２ 診察予約管理システム
６３ 予約売上算出システム
７１ 利用者音声ＤＢ
７２ 電子機器利用システム
７３ 電子機器
９１ 会話台本ＤＢ
９２ 会話台本
１０１ 決済関係ＤＢ
１０２ 医療機関決済支援システム
１０３ キャッシュレスシステム
１０４ 医療決済口座
１０５ 位置情報取得システム
１１１ 消耗時期情報ＤＢ
１１２ 消耗時期算出システム
１２１ 服薬管理ＤＢ
１３１ 防犯ＤＢ
１３２ 防犯システム
１５１ 災害時行動ＤＢ
１６１ 患者情報ＤＢ
１６２ 患者認証処理システム
１６３ キャッシュカード共有システム
１７１ 医療機関開業支援システム
１７２ 医療機器間共同利用システム
１７３ 診療報酬計算システム
１７４ 診療報酬自動請求システム
１９１ 地域処方ＤＢ
１９２ 慢性処方薬システム
２０１ 処方リカーリングＤＢ
２０２ 処方リカーリングシステム
２０３ 処方サブスクリプションシステム
２１１ 運行管理システム
２１２ 運送サブスクリプションシステム
２１３ 医療版ＭａａＳシステム
２２１ ＩＰＳ人工多能性幹細胞移植治療候補患者ＤＢ
２２２ 人工多能性幹細胞治療支援システム
２２３ 人工臓器作製事業者
２３１ 医療従事関連ＤＢ
２４１ 師士業従事者評価ＤＢ
２４２ 業務結果取得システム
２４３ 師士業従事者システム
２５１ 師士業業務情報ＤＢ
２６１ 開発プロセスＤＢ
２６２ 開発プロセスシステム
２６３ ライセンス管理システム

【要約】      （修正有）

【課題】医療機関が所有している患者の個人情報を利用した決済が行えるプラットフォーム型医療機関支援システム及び医療情報共有データベースを提供する。
【解決手段】医療経営支援サービスの提供するプラットフォーム型医療機関支援システム１は、医療情報システム９と、医療機関経営事業支援システム１０と、医療機関決済支援システム１０２と、診療報酬計算システム１７３と、診療報酬自動請求システム１７４とを備え、多診察科医療機関の複数の個人事業医師との間で夫々が同時に並列型事業経営を行う。
【選択図】図１

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

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【図49】

【図50】

【図51】

【図52】

【図53】

【図54】

【図55】

【図56】

【図57】

【図58】

【図59】