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

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

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

(11)【公開番号】P2023010519

(43)【公開日】2023-01-20

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

(51)【国際特許分類】

   G16H 40/00 20180101AFI20230113BHJP

【ＦＩ】

G16H40/00

【審査請求】未請求

【請求項の数】4

【出願形態】ＯＬ

(21)【出願番号】P 2021201311

(22)【出願日】2021-12-12

(62)【分割の表示】P 2021201305の分割

【原出願日】2021-12-12

(31)【優先権主張番号】P 2021113941

(32)【優先日】2021-07-09

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

(71)【出願人】

【識別番号】717007181

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

(72)【発明者】

【氏名】川崎 智子

(72)【発明者】

【氏名】相坂 真仁

(72)【発明者】

【氏名】川崎 功

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

5L099

【Ｆターム（参考）】

5L099AA21

(57)【要約】

【課題】医療機関で使用する医療情報システムと経営に関するシステムとで発生する様々な情報を利用し、医療に関する物流や決済を行うサービスの提供、医療機関への経営支援や医療支援、利用者への健康支援、患者へのサービスの提供をプラットフォーム型医療機関支援システムを用いて持続化経営と収益の技術を提供する。
【解決手段】
１つの大きなデータベースであるプラットフォーム型医療機関支援システムの電子カルテで扱う様々な情報と経営支援システムによる様々な情報とがあり、これらの情報を利用して収益の得られる仕組みを揃えたビジネスモデルとすることで医療機関の経営改善による事業の持続化とシステムの持続化できるシステムとデータベースの提供をする。
【選択図】図４

【特許請求の範囲】

【請求項1】

医療機関の数を増やさず、地域内の医師の減少させずに地域における医療体制を再編成し充実するため又は人口減少へ対応した医療体制にするために、複数の個人事業医師が既存の医療設備を共有し診察を行う、新しい医療経営形式の医療機関としてリニューアルすることにより、持続化する医療機関経営を行うことを目的とし、
前記目的を実現するための、多くの医療機関や多くの個人事業医師が利用できるようにした医療機関共同利用システムを構築することを目的とし、
新しい医療経営形式の医療機関は、
２４時間診療医療機関または多診察科診察医療機関の経営に適応したシステムが、前記医療機関共同利用システムであり、
前記医療機関共同利用システムは、
プラットフォーム型医療機関支援システムに上で動作している、
医療情報システムと、医療機関経営事業支援システムと、医療機関決済支援システムと、診療報酬計算システムと、診療報酬自動請求システムとの５つのシステムで構成されており、
前記２４時間診療医療機関へのリニューアルの場合において、
２４時間診療医療機関で診療を行う医師が
２４時間診療医療機関で診療を行う複数の個人事業医師との間で共有して使用する
同一住所・同一医療機関にある端末から
前記医療機関共同利用システムに接続すると
２４時間診療医療機関で診療を行う複数の個人事業医師との間で共有する情報と
２４時間診療医療機関で診療を行う複数の個人事業医師との間で共有しない情報との両方の情報が個人事業医師の利用に合わせて表示され
前記共有する情報と前記共有しない情報とを利用する複数の個人事業医師が
同一住所・同一医療機関で時間帯を変えて営業するそれぞれ個人事業医師の事業経営を行えることを特徴とし、
既存の医療機関から前記多診察科診察医療機関へのリニューアルの場合において、
多診察科診察医療機関で診療を行う複数の個人事業医師との間で共有して使用する
同一住所・同一医療機関にある端末から
前記医療機関共同利用システムに接続すると
多診察科診察医療機関で診療を行う複数の個人事業医師との間で共有する情報と
多診察科診察医療機関で診療を行う複数の個人事業医師との間で共有しない情報との両方の情報が表示され
前記共有する情報と前記共有しない情報とを利用する複数の個人事業医師が
それぞれ医療機関の事業経営を行えることを特徴とし、
同一住所・同一医療機関で営業するそれぞれ個人事業医師の事業経営を行えることを特徴とし、
前記医療機関共同利用システムを用いて
同一住所・同一医療機関で２４時間診療医療機関として時間帯を変えて診療を行う複数の個人事業医師との間、もしくは、
同一住所・同一医療機関での多診察科診察医療機関として診療を行う複数の個人事業医師との間で共有する情報は、
電子カルテと言われる、患者の個人データや患者診療情報と処方箋情報、診療受付情報と、診療予約情報と、患者紹介情報と、医薬購入品情報といったと診療に関する診療情報であることを特徴とし、
前記医療機関共同利用システムを用いて
２４時間診療医療機関で診療を行う複数の個人事業医師との間、もしくは、
多診察科診察医療機関で診療を行う複数の個人事業医師との間で共有しない情報は、
経理情報、経費情報、事業経営情報、従業員情報、給与情報、税情報といったそれぞれの個人事業医師の医療機関経営に関する経営情報であることを特徴とし、
前記医療機関共同利用システムを利用した
前記２４時間診療医療機関の医療機関経営、及び前記多診察科診察医療機関の医療機関経営は、
リニューアル前の医療機関の事業主が、
医療機関内の一部の場所と施設を個人事業医師に貸すことにより
店子の個人事業医師からの賃料収入が受けられ、
２４時間診療医療機関または多診察科医療機関で診察を行う複数の個人事業医師は、
医療施設を間借りするため開業資金が抑えられるビジネスモデルであり、
医療施設を間借りするため開業資金が抑えられるビジネスモデルであることを特徴とし、
前記医療機関共同利用システムを利用して、
人口減少化地域で既存の医療機関を２４時間診療医療機関として経営支援を行う医療経営支援サービスの提供と、
人口減少化地域で既存の医療機関を多診察科医療機関として経営支援を行うサービスの提供とを行う
ビジネスモデルを実現するプラットフォーム型医療機関支援システム

【請求項2】

請求項１に記載のプラットフォーム型医療機関支援システムにある、診療報酬計算システムは、
同一住所・同一医療機関での２４時間診療医療機関または、同一住所・同一医療機関での
多診察科診察医療機関で診療事業を行う個人事業医師が診察した患者の診療点数を計算した結果の診療報酬は、同一住所・同一医療機関の診療報酬としての計算処理するのではなく、それぞれの個人事業医師の診療報酬として扱い、
保険者及び自治体に対して個人事業医師として診療報酬の請求を特徴とする
２４時間診療医療機関または多診察科診察医療機関への経営支援サービスの提供を行うビジネスモデルを実現するプラットフォーム型のシステム

【請求項3】

プラットフォーム型医療機関支援システム上にある、診療報酬自動請求システムは
同一住所・同一医療機関に複数の個人事業医師の保険医が存在する場合に
前記同一住所、前記同一医療機関に複数の個人事業医師それぞれの診療報酬を合算する処理を行い、保険者及び自治体に対して合算した診療報酬を請求する処理を行う事を特徴とし、
保険者及び自治体からの診療報酬は、プラットフォーム型医療機関支援システムの医療決済口座を使用して前記同一医療機関の医療決済口座に支払情報の移動処理がされ、前記複数の個人事業医師の診療報酬は、前記同一医療機関の医療決済口座から、個人事業医師の診療報酬相当額が移動処理されそれぞれ受取れる事を特徴とし、
保険者及び自治体に対して診療報酬の請求と診療報酬の受取ができる２４時間診療医療機関または多診察科診察医療機関への経営支援サービスの提供を行うビジネスモデルを実現する
請求項１に記載のプラットフォーム型のシステム

【請求項4】

多診療科医療機関において、医療機関で働くスタッフの雇用を個人事業医師との間で共有することで、各個人事業医師の人権費の軽減が行われる、プラットフォーム型医療機関支援システムにあるスタッフ共有機能は、複数の個人事業医師との間で共有するスタッフの給与管理を複数の個人事業医師との間で行わることを特徴とする
多診療科医療機関内で働くスタッフの雇用を個人事業医師との間で共有するサービスを個人事業医師への経営支援サービスの提供を行うビジネスモデルを実現する
請求項１に記載のプラットフォーム型のシステム
多診療科医療機関において、複数の個人事業医師が医療機関で働く事務スタッフの雇用を共有で行うことで、各個人事業医師の人権費の負担軽減を目的とし、
プラットフォーム型医療機関支援システムにある共同雇用システムにおいて、
事務スタッフの勤務日時の情報と個人事業医師の診察日時の情報とから
各個人事業医師が事務スタッフの雇用日時を算出し
算出した事務スタッフの雇用日時から、各個人事業医師が負担する給料の割合を計算することを特徴とし
多診療科医療機関内で働くスタッフの雇用を共有するサービスを個人事業医師への経営支援サービスの提供を行うビジネスモデルを実現する
請求項１に記載のプラットフォーム型のシステム

【発明の詳細な説明】

【技術分野】

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

医療情報共有データベースにある予約ＤＢに保存されている予約状況情報を利用して、プラットフォーム型医療機関支援システム上の予予約売上算出システムは、予約DBから予測したい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】

医療機関支援システムは、患者が初めて受診する医療機関での受付の場合、初めて医療機関に来院した患者の基礎情報を手入力せずに、患者情報DBにある患者の基礎情報を医療機関の患者情報に紐づけることで受付処理と電子カルテの診察情報の保存ができるようになる基礎情報の紐づけを行う。患者が初めて受診した医療機関では、従来のように新規に診察カードの発行を行うすなわち医療機関の管理番号を新規に採番する方法と、診察カードの発行をせずに他の医療機関の診察カードとその診察カードに記載の管理番号を使用する方法と、診察カードの代わりに「発行先が明確なカード」を診察カードとして代用し、そのカードの記載された番号を医療機関の管理番号として代用する方法とをネットワーク受付システムが医療機関の受付にある受付端末の画面に表示し処理の選択を求める。患者又は受付従業員は受付端末の画面に表示された中から選択したその内容の処理を行った管理番号で医療機関の診療情報を管理する患者の管理番号として患者情報DBに保存する。

【0063】

医療機関支援システムは、患者が受付端末に付いているマイクに向かって名前を話すことから、話した名前を音声認識により名前情報として取得し、取得した名前情報を用いて、患者情報DBに保存されている診察カード紐づけ情報から名前情報と一致する名前情報を検索する処理を行い、この検索処理で一致した名前情報に紐づいている顔写真情報と管理番号情報と名前情報を取得する処理を行い、取得した情報を受付端末の画面へ表示する処理を行う。表示された情報から患者自身，患者の家族，患者の付添人，医療機関の受付員のいずれかが受付端末に表示された患者の情報を見て患者本人であることの確認することで、医療機関の受付処理が完了する。

【0064】

医療機関支援システムは、取得した名前情報を用いて、患者情報DBに保存されている診察カード紐づけ情報から名前情報と一致する名前情報を検索する処理時に、一致した結果が複数人居る場合、同性同名の名前情報に紐づいている顔写真情報と管理番号情報とを複数名分取得する処理を行い、取得した複数人の情報を受付端末の画面へ複数名分表示する処理を行う。表示された複数人情報の中から患者自身，患者の家族，患者の付添人，医療機関の受付員のいずれかが受付端末に表示された患者の情報を選択することで、医療機関の受付処理が完了する。

【0065】

患者情報DB内に保存する診察カード紐づけ情報にある管理番号情報と診察カードの情報に診察カードの代わりとなるカード発行先が明確なカードの番号情報と、携帯端末の画面に表示するバーチャルコードの数値情報と、患者の顔写真の情報と、患者の名前のよみがなの情報と、診察カード紐づけ情報にそれぞれ紐づけて患者が登録を行う。登録を行うことで、「カード発行先が明確なカード」と「携帯端末の画面に表示したバーチャルコード」と
「患者の顔と及び患者の名前」が、それぞれ医療機関で使用する管理番号を導き出せることで、診察カードとして遜色なく利用できる。また、別々のカード発行先が明確なカードの番号情報の同士も紐づいている。

【0066】

医療情報共有データベースにある医療経済圏ＤＢに保存されている個人情報にある利用者の情報と紐づけされた患者情報ＤＢがある。この患者情報ＤＢには、利用者が契約している複数の金融機関の情報と利用者が複数所有しているキャッシュカードの情報とが、それぞれ利用者により登録されている。患者情報ＤＢに登録された１つのキャッシュカードの情報に複数の前記金融機関の情報が紐づけると１対N（Nは１以上の自然数）の紐づけとなり、さらに、残りのキャッシュカードについても同様に複数の前記金融機関の情報銀を紐づけることにより、キャッシュカードの情報と前記金融機関の情報とのN対Nに紐づけられたキャッシュカードとなる。これらの紐づけは、利用者が携帯端末や利用者端末を用いて行われ、この紐づけが行われた各情報は、キャッシュカード紐づけ情報として患者情報DBに登録される。複数枚ある紐づけられたキャッシュカードのうちどれか１枚をATMで利用した時に、その利用したキャッシュカードに紐づいている全ての金融機関の口座を利用できるようになり、ATMの画面に、そのキャッシュカードに紐づけられた金融機関の口座情報の一覧が表示され、利用する金融機関のキャッシュカードを複数枚携帯することが無く用を済ませられる。

【0067】

銀行口座情報を紐づけたキャッシュカードのうち、どれか１枚のキャッシュカードをＡＴＭで利用時に、預金の移動を、ATMの画面上に表示されたキャッシュカードに紐づけられた金融期間の口座情報の一覧の中から、送金元の金融機関の口座情報の選択と、移動先の金融機関の口座情報の選択と、移動する預金額の入力だけの３つの項目を設定するだけで預金の移動が行え、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】

ひらめきとして頭の中にあるアイデアの概要は、医師や看護師や介護士や医療機関で働く事務職や医療に従事する企業、医療関係の研究者WEBシステム入力することで取得する開発プロセスシステム。

【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】内製化システムを開発に必要な資金フロー図である。

【図60】診察予約の例を示す図である

【図61】診察予約変更の例を示す図である

【図62】診察予約変更の例を示す図である

【図63】プラットフォーム事業社と第３実施液体の考案とを接続構成を示す図である

【図64】事業者システムとスマートスピーカー（電子機器７３）との接続例示す図である

【図65】電子機器利用システムの構成するデータべースと情報の一覧である

【図66】自宅からの距離で設定した要支援エリアの例を示す図である

【図67】町名や番地で設定した要支援エリアの例を示す図である

【図68】遺言作成プロセスを示す図である

【図69】遺言作成の情報一覧である

【図70】遺言執行プロセスを示す図である

【図71】デジタル通貨の場合のシステム構成図を示す図である

【図72】医療機関決済支援システムの情報を利用したクレジットカードの発行方法を示

【図73】診察カードや携帯端末を使用する無形コー、医療保険証、マイナンバーカードや名前や顔などが患者情報ＤＢに紐づいていることを示す図である

【図74】診察カードや携帯端末を使用する無形コー、医療保険証、マイナンバーカードや名前や顔などが診察カードや管理番号に紐づいていることを示す図である

【図75】ATM画面の表示例の図である

【図76】従来及び第５実施形態の考案における預金の移動の処理フローを示す図である

【図77】利用者が利用している複数のキャッシュカードと複数の金融機関が紐づいているイメージ図である

【図78】複数の診察カードをマイナンバーカードにまとめたイメージ図である1

【図79】構築したシステムやプログラムの所有権や財産権の例を示す図である

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

【0114】

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

【0115】

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

【0116】

しかしながら社会ではデジタルトランスフォーメーション（ＤＸ）といった概念による事業構造の変革が動き始めている。
従来、医療従事者５が利用する電子カルテ９ａを主体にしたネットワーク上のサービスは複数存在し利用されている。これでは社会に普及し始めたＤＸといった事業構造の変革はできない。
個人経営の医療機関４が医療版ＤＸを導入するには様々な負担により事業構造の変革は遠いものである。
グループの垣根を越えて、各種情報システムが連携するには、医療機関４を運営している企業やそのグループに縛られることはない、第三者が医療機関４に関係する情報システムを運営しプラットフォームサービスとして医療機関４に経営と事業構造とを主体とした医療経営サービスを提供することにより実現できる。
別の側面で考えると、それぞれの医療機関４で使用している上記のシステムは、メーカーの違いで事業収益の具合が変わる物なのでしょうか？システムの開発メーカーの違いで事業収益に影響が出るものではないでしょう。これは、医療業界に限らず他業種でも使用しているシステムも同様で人事システムや給与システムの違いで競合会社と事業収益の差が出るというものではないのと同じである。どこの医療機関４でも同じものを使用しても体制の影響や事業収益上の差は出ないと言ってよい。金融業界（銀行）においても、銀行間の共創により行内システムを開発して相互に利用し、個別に所有することで発生していた、開発費・維持費・メンテナンス費・リプレース費等のコストを銀行グループの枠を超えて同業種一丸となって行う取り組みは数年前から実施されている。医療業界も同じではないでしょうか。販売されているシステムの権利は開発側が持っているため改善を受けるバージョンアップを受けるためには、それに相当する代金を払い続けなければならない。医療業界で使用するシステムを医療機関が作成すれば、それに相当する代金を払い続ける必要は無い。複数の医療機関と共同で作成すれば開発コストの１医療機関あたりの負担は少なくなる。より多くの医療機関で共同作成すれば開発コストはさらに下がり、１医療機関でも複数医療機関でも目的や機能には変わりは無い。
医療業界で使用するシステムを共有利用できる基盤システムとして一括開発し、それをプラットフォームサービス化することで医療機関４はそれを利用できるようになる。小さな医療機関４やクリニック４ｅでは、開院コストの大幅な削減にもなり、経営に圧迫を与えたCＯＶＩＤ－１９下では医療機関４から外に出ていく費用の削減となり医療経営の圧迫から少しは解放できる事に繋がると考えている。前記したＤＸについて簡単に考えてみても、大きな医療機関同士がＤＸを使用して情報の共有を行うことができても、個人開業医によるＤＸを使用した情報の共有は資金という厚い壁が立ちはだかる。これも同様に１つの個人開業医によるＤＸの構築では無く複数医療機関で行えば構築のコストは下がると推定できる。それよりも複数の医療機関で、ＤＸ機能が装備されている医療情報システムを前記したように複数の医療機関の資金で開発した方が良い。また、メンテナンス費や追加機能を盛り込むための費用すなわち維持費を下げるための工夫を考えることが必要である。本考案は、プラットフォーム化した医療情報システムの運営を賄うための収益を得るサービスも備えたプラットフォーム型医療機関支援システム１である。

【0117】

前記プラットフォームサービスは、プラットフォーム型医療機関支援システム１（医療機関支援システム１）として利用者３に提供され、システムの中核を担うデータベースとして、大きな１つのデータベースである医療情報共有データベース２がある。
この医療情報共有データベース２には、複数の医療機関４で利用する電子カルテ９ａ内にある診療情報と紐づいた情報が保存された様々なデータベースがあり、前記様々なデータベース内にある情報を患者や、医療機関４や、介護機関や、事業者でシェア（共有）して利用するができる。医療情報共有データベース２上にある様々なデータベースとしては、医療経済圏ＤＢ２１、経理業務ＤＢ３１、リカーリングＤＢ４１、サブスクＤＢ４４、診察所要時間ＤＢ５１、予約ＤＢ６１、利用者音声ＤＢ７１、会話台本ＤＢ９１、行動情報ＤＢ９３、決済関係ＤＢ１０１、消耗時期情報ＤＢ１１１、生活環境ＤＢ１１３、服薬管理ＤＢ１２１、防犯ＤＢ１３１、災害時行動ＤＢ１５１、患者情報ＤＢ１６１、地域処方ＤＢ１９１、処方リカーリングＤＢ２０１、処方サブスクＤＢ２０５、師士業従事者評価ＤＢ２４１、地域処方ＤＢ１９１、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１、医療従事関連ＤＢ２３１、師士業従事者評価ＤＢ２４１、師士業業務情報ＤＢ２５１、開発プロセスＤＢ２６１がある。これらのデータベースの説明は、本実施形態並びに第２実施形態以降の各実施形態にて適宜説明する。プラットフォーム型医療機関支援システムの構成を図１に示し、医療情報共有データベース２の構成を図２に示す。
本実施形態では、上記ＤＢのうち医療経済圏ＤＢ２１、経理業務ＤＢ３１、リカーリングＤＢ４１、サブスクＤＢ４４の４つのデータベース内の情報を利用している。医療経済圏ＤＢ２１には、企業の事業情報、個人情報２２、認識情報が保存されている。経理業務ＤＢ３１には、経営上の情報、設備機材情報、設備投資情報、廃棄物情報、在庫量情報、消費量情報、総消費量情報が保存されている。リカーリングＤＢ４１には、包括情報、包括回答情報 、包括総消費量情報、包括契約査定情報、包括契約先候補企業、希望契約価格情報が保存されている。サブスクＤＢ４４には、サブスク情報、サブスク回答情報、サブスク総消費量情報、サブスク契約査定情報、サブスク契約先候補企業、希望契約価格情報が保存されている。ここに挙げた４つＤＢ上の情報の説明は、情報の使用時時に記載する。第１実施形態のデータベース構成を図３に示す。

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

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

【0123】

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

【0124】

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

【0125】

ここから医療機関の経営を支える手段として、医療機関内で使用する「医療品をはじめとする備品」の購入価格を従来よりも安く購入することにより医療機関から外への支払い額を減らすことのできる契約方法について説明していく。
まず現在の医療機関４での「医療品をはじめとする備品」の発注量と購入価格（仕入価格）について説明すると、発注に問題があると気がつく。
それは、殆どの医療機関４では、「医療品をはじめとする備品」の発注は「少なくなったら」発注する。在庫がなくなってしまう前に発注する行為である。「少なくなったら」は、人間の感や経験値をコンピュータシステムに設定した閾値である。
この「少なくなったら」という閾値は、人間が設定する。時系列的（時間軸）に見ると発注スイッチを入れる時間（時期）でもある。実際に発注する量は、どうやってきまるか？
それは、発注した量が納品され、どれだけの納品される量を置けるか、又は消費するまでにいくら時間がかかるか、のいずれかになる。この「少なくなったら」という時間軸で発注スイッチを入れると、その時期（時間軸）での提供価格（仕入価格）での発注になる。こういった発注方法では発注するたびに提供価格（仕入価格）が変わる場合がある。また、小さな医療機関４と大きな医療機関での備品の発注量は違う。この発注量に対しても提供価格（仕入価格）は違う。これらの、「少なくなったら」発注する仕入価格と、発注する「量」に対する仕入価格に対して医療機関４では手の出しようがない。忍耐による我慢するだけとなる。ここにテコ入れをしたのが本考案である。

【0126】

本考案の発端となる考え方について説明する。
いままで説明したように医療機関４は、発注する「量」に対する仕入価格の値下げに対して医療機関４が何も手を出せないことに手を出したものである。現実の世界に存在している医療機関をバーチャルな環境で統合して１つの仮想医療機関にしてしまい、この１つの仮想医療機関により医療経済を回すことをバーチャルな医療経済圏として医療機関の経営を行うことを考えた。このバーチャルな医療経済圏にいる仮想医療機関が、卸売事業社や製薬会社に対して発注を行うということは、このバーチャルな医療経済圏を利用している全ての医療機関４の発注ということになる。この仮想医療機関が、全ての医療機関を代表して、従来の発注量に左右された仕入単価から、仮想医療機関による大量発注で仕入単価を下げることを行う契約を行う考えによるものである。この契約は、バーチャルな医療経済圏の利点を活かして「包括契約」「サブスクリプション契約」がメリットを活かせるとした。以下の説明では、「包括契約」「サブスクリプション契約」の対象を医療機関４と記載するが、医療機関４に限らず医療経済圏ＤＢ２１を形成する介護施設などでも「包括契約」「サブスクリプション契約」の対象とすることができる。

【0127】

包括契約について説明する。
「包括契約」とは、字のごとく、複数の医療機関を包括し、その医療機関のそれぞれが必要としているアイテム（今回は備品）を包括して一定期間において契約することが包括契約である。
例えば、１つの医療機関で１年間に消費した包帯が１０個、１０の医療機関で合わせて１年間に消費した包帯が１８０個のような考え方だが、この量では規模が低すぎる。この算出値をバーチャルな医療機関で消費した消費量としてバーチャルな医療機関が包括契約を代行して行うことになる。
バーチャルな医療機関の中で大量に消費するスケールメリットを活かして、備品を安く購入する交渉ができることが期待できる。（これを社会では、ボリュームディスカウントとも呼ばれている。）
そして、この包括契約に必要とする最適な消費量を計算処理することが必要となる。
そのためには、複数の医療機関での発注量の情報を取得し計算できる、ネットワーク型のプラットフォーム型の医療情報システムを利用する事で実現できる。

【0128】

医療機関の経営を支える方法の１つである包括契約について説明していく。
従来、医療機関４では、医療機関内で使用する「医療品をはじめとする備品」の購入価格（仕入価格）を従来よりも安くする契約での取組みは一切行っていない。本考案はこの契約、すなわち包括契約を行い価格を下げ医療機関４からの外への支払い額を削減するものである。
包括契約とは、医療品をはじめとする備品の中から契約の対象とするアイテムを選び販売している企業（卸事業社）、又は製造している企業と「価格と数量」を交渉し契約を行う。この契約は、契約期間中に契約した金額で契約した数量を購入することができる契約形態である。備品の発注に対する単価（仕入単価）は、変動する場合もある。また発注する量によっても単価が変わる。大きな医療機関４と個人事業医師の医療機関とは発注量が違うために仕入単価が違う。また調剤薬局でも同様である。全国規模のドラッグストアー店内に併設している処方薬販売と、複数の店舗を持つ調剤薬局店と、個人の調剤薬局店とでは発注量（仕入数）が全く違うため仕入単価に偏りがでている。発注量（仕入量）が多ければ仕入単価が安いのは社会のルールのようなものである。
但し、「包括」という言葉が含まれているため、医療機関を複数の医療機関で包括するアイテムを決めた商品の包括した量を、包括した価格で契約することを言う。包括契約の場合、契約期間中に利用する量（必要な量）になる。
本開示のプラットフォーム型医療機関支援システム１にある医療機関経営事業支援システム１０は、医療機関４が従来から使用している経営システムから医療機関４内で使用している包帯やマスクなどの医療品をはじめとする備品の消費量や在庫量を取得し、それぞれを経理業務ＤＢ３１に消費量情報と在庫量情報として保存する。医療機関４内で使用している医療品の消費量や在庫量を取得する方法としては、出願人考案の特開２０２０－１１３１４３に開示の共通在庫ＤＢを利用した方法がある。

【0129】

前記では、医療機関４内で使用している備品の消費量や在庫量とした。地域内の医療機関４など複数の医療機関４が従来から使用している経営システムから、それぞれの医療機関４で使用している備品の消費量を取得する。各医療機関４が従来から使用している経営システムから取得した消費量を経理業務ＤＢ３１に消費量情報として保存する。また地域全ての医療機関４で使用している備品の消費量を合算する算出処理を行い、この算出結果も経理業務ＤＢ３１に総消費量情報として保存する処理が行われる。この総消費量情報は、地域にある複数の医療機関４の全てで使用している備品の消費量である。この総消費量情報の消費量を利用して、卸売事業社又は製造企業と包括契約を行うための情報となる。この消費量について説明する。包括契約を行うには、各医療機関４にて一定期間における消費量を契約の目安として使用する。
１か月間、半年間、１年間どちらも使用するが、一般的には１年間の消費量を基本に契約が行われている。１年間の消費量を見て、翌年から契約する量、すなわち地域全体の医療機関へのディスカウントプライスで購入する契約を行う量として扱われる。1か月間で消費した量を１２倍して12か月分として計算することも、半年間で消費した量を２倍して1年分として計算することもどちらでも構わない。

【0130】

医療機関経営事業支援システム１０にある、医療経済圏２４を利用する医療機関４において、一定地域内に所在している複数の医療機関４で備品の発注を包括契約で行い備品を購入するリカーリングシステム４２について記載する。
リカーリングシステム４２は、地域の医療機関を包括して備品を包括契約により購入する包括契約である。このリカーリングシステム４２の一連のプロセスは、地域の消費量（1か月半年、１年での）の算出、包括契約する対象の備品の選定や、包括契約先の企業の選定、契約前見積依頼、包括契約の契約書の作成、選定・契約見積・契約までの一連のプロセスを行うシステムとなっている。
このシステムを利用して契約の受注を行う事業社は医療経済圏ＤＢ２１の企業の事業情報に登録されている医療機関４と備品の販売事業者又は備品を製造している製造企業である。
医療経済圏２４を利用する医療機関４が使用している備品の種類や備品の消費量又は払い出された量の情報は、経理業務ＤＢ３１に消費量情報として保存されている。
この地域の複数の医療機関４の消費量を合計した地域全体の消費量（使用量）が、ボリューム発注量となる。
従来、医療機関が単体で発注していた量（数）よりも大幅に増やした消費量（ボリューム発注量）になることから、医療機関が単体で購入していた仕入単価よりも安くなる契約となる。契約には期限がある。１年、２年、3年、５年など。長くなると物価や原材料費などの関係で医療機関側や提供する側の双方にリスクが生じるため長い期間の契約は行なわない。
リカーリングシステム４２は、包括する備品の選定と購入先となる包括契約先を選定するために包括選定ＡＩという人工知能（ＡＩ）を利用して行う。
リカーリングシステム４２は、地域の医療機関４の備品の消費量を全て計算処理した結果の消費量の合計値を、地域で消費した備品名とその内容と各医療機関の消費量とその備品の購入先と仕入単価と、消費量の合計値とが紐づいた備品の総消費量の情報としてリカーリングＤＢ４１の包括情報の中に包括総消費量情報を保存する。すなわち、仮想空間上の医療機関の包括総消費量情報である。
備品の購入先は、複数の医療機関のそれぞれによって違う、そのため購入先は複数ある。それぞれの医療機関４がが従来から使用している経営システムから従来から利用していた発注先（提供先）の情報を、「備品の購入先」とする。
リカーリングシステム４２は、備品の包括契約を行う契約先（包括契約先企業）を選定する必要がある。
この選定する処理方法に、包括選定ＡＩという人工知能（ＡＩ）を利用することで煩わしい選定の自動化が図れる。
包括選定ＡＩは、包括契約を行う備品の選定とその契約先となる候補企業の選定と最終的に契約を行う契約先の選定を行うものである。

【0131】

ここで、包括選定ＡＩについて説明する。
包括契約を行うには、契約の対象となる備品を選ぶ必要がある。地域全体の医療機関４においては数百種類の備品を使用している。この中から包括契約の対象とする備品を選定する方法に包括選定ＡＩを利用して備品の選定を自動化して行う。
包括選定ＡＩは、包括契約を行う備品の選定とその契約先となる候補企業の選定と、最終的に契約を行う契約先の選定を行うものである。
包括選定ＡＩによる、備品の選定は、従来複数の医療機関で購入していた備品のうち医療機関ごとに仕入価格に大幅なバラツキのある備品の情報、それぞれの医療機関での消費量が多い備品（反対に消費量の少ない備品は除く方が良い）の情報、従来から提供されている備品で新製品として出回り始めた備品の情報、それぞれの医療機関で購入実績が多い企業が販売している備品の情報、それぞれの医療機関で購入実績が少ない企業（あまり利用していない企業）が販売している備品の情報、過去に包括契約実績のある備品の情報を利用して、備品と契約先候補の企業が選定される。これらの情報の入手は、既に保存してあるリカーリングＤＢ４１の包括情報から取得する。
また、選定した備品に紐づいている備品の購入先情報から包括契約を結ぶ包括契約先候補企業を取得しどちらの企業と契約を結ぶかの契約先企業の選定を行う。
ここまで説明した情報、すなわち包括情報に保存されている情報を利用して包括選定ＡＩは学習する。
包括選定AIが用いる機械学習の手法は、包括情報として保存された情報を利用して教師なし学習のうちアソシエーション分析の手法を用いる。
この学習した包括選定ＡＩにより、仕入れ価格のバラツキがあり、消費量が多く、新しい製品が出る、購入実績が多い企業、購入実績が少ない企業の情報から選定される結果として、備品の選定とその備品の購入先候補企業の選定とその備品の仕入単価（推奨仕入単価）が算出される。その備品情報に紐づいた消費量情報と購入先候補企業情報と仕入単価（推奨仕入単価）情報とをリカーリングＤＢ４１の包括契約査定情報として保存する。
この選定までが包括選定ＡＩによるものである。
この包括契約査定情報を利用して包括契約の見積を行う。
ここで、包括選定ＡＩの学習方法について説明する。
リカーリングＤＢ４１内に包括情報として保存されている包括総消費量情報から地域で消費した備品の情報と、その備品の内容の情報と、各医療機関の消費量の情報と、消費量の合計値の情報と、全ての医療機関での備品の消費量を合計した包括総消費量情報を取得し学習情報とする。
企業の情報として、過去に備品の購入先として取引していた企業や、備品の製造企業又は、過去に包括契約実績のある企業を包括情報にある包括契約先企業情報から取得し、過去に包括契約実績のある企業をサブスク情報にあるサブスク契約先企業情報から取得し学習情報とする。
ここで挙げた情報を、人工知能に学習させる学習情報源とし、人工知能は教師の無い自己学習によるアソシエーション分析の手法を利用した学習を行う人工知能を利用する。
包括契約用に選定した備品が、正しい選び方だったとは限らない場合がある。包括契約よりもサブスクリプション契約の方が最適な選択だったと後で判明する場合がある。この判断に利用する情報が、医療機関４の在庫情報である。元来、包括契約は消費する量（数）にフォーカスして契約を行う。契約期間が終了する間際に在庫量が多すぎる場合は、包括契約の選択が間違っていたことになる。反対に消費量が多く足らずに、通常の追加注文をした場合も包括契約を選択が間違っていたことになる。包括選定ＡＩでは、こういったことも学習していき最適な契約を選択できるようになっている。

【0132】

包括契約価格と契約先を決めるため、リカーリングシステム４２は、包括情報に保存されている包括契約先候補企業に対して、包括契約の契約価格の見積依頼を送る処理を行う。
包括見積とは、企業に対して包括契約の依頼するための契約金の算出を依頼するものである。リカーリングシステム４２は、包括契約査定情報から、購入先候補企業情報に紐づいている備品情報を取得し、消費量情報（ここでは契約する量になる）とその備品情報の単価（一番安い仕入単価）を取得し、見積依頼書を作成する。包括契約の見積依頼書に記載される例は、備品Ａ・年間消費量１００箱・仕入単価１００円、備品B・年間消費量５００箱・仕入単価３００円の見積に必要な情報が記載された見積依頼の内容である。
さらに見積を依頼した全ての備品に対する備品情報の単価と消費量情報の量とから算出した、その包括契約内容における総額価格を算出する。その算出した総額価格の情報は、依頼する見積書の希望契約価格情報として、以下に説明する電子化された包括契約の見積依電子文書と一緒にリカーリングＤＢ４１の希望契約価格情報に保存される。この希望契約価格情報は、回答のあった見積内容に記載されている契約価格を評価するのに利用する。
見積依頼書は、電子文書のテンプレート利用し、テンプレートに備品情報と消費量情報をテンプレートに付加することで包括契約の見積依電子文書が作成される。
この電子文書化された包括契約の見積依頼電子文書の送付先は、購入先候補企業情報にある企業へ送付する。送付先の情報は医療経済圏ＤＢ２１にある企業情報の連絡先情報を使用して送られる。各企業から見積の返答が順次くることになる。
リカーリングシステム４２は、この見積依頼に対する回答を包括契約先候補企業から受信し、回答内容を包括回答情報としてリカーリングＤＢ４１に保存する。包括回答情報には、企業から送られてきた企業名、備品名、契約する備品の数量、契約金額、支払条件などの契約に必要な情報が保存されている。
ここで、商品を提供する企業について説明する。
まず、何故企業は包括契約を行うのでしょうか？その答えは「独占」です。備品は、様々なメーカー（製造企業）が製造している多品種商品、そして様々な卸事業社が販売している多卸事業となっている。また、メーカーが直接販売しているケースもある。包括契約とは、数多くある多品種商品の中から１銘柄に絞られます。例えば、包帯を製造する企業が２０社、絆創膏を製造する企業が１０社あったとします、これらが地域全体で消費する量（数）を包括し、包括契約を、包帯はA社と契約、絆創膏はC社と契約することで、備品を提供していた複数社の卸事業社や複数メーカーの直接販売は、包括契約の契約期間中に、この地域への備品販売が一切できないことになる。契約した卸事業社又は製造企業だけの１社独占提供となる。他社からの参入（受注活動）が一切できない独占の状態になることで売上が上がる。契約できなかった他社は、契約期間中は手を出せずに見ているだけとなる。よって、次の契約時期を狙い次回の契約はさらに激しくなる。１度包括契約を勝ち取ってしまい独占状態を味わってしまうとそこから抜け出せなくなる。医療機関４側も全く同じで安く買えることの経営体制を味わってしまうとそこから抜けられない。
包括契約の見積依頼に対する見積書の返答について記載する。
見積依頼を受けた各企業は、見積を行い見積書の提出することになる。リカーリングシステム４２は、返答されてくる見積書内に記載されている見積価格と契約期間と備品とその備品の提供価格とを見積を作成した企業ごとに取得し、企業情報に見積価格の情報と契約期間の情報と備品の情報と提供価格の情報と、その見積書の電子文書とをリカーリングＤＢ４１の見積返答情報に各社保存する。返答のあった見積価格と希望契約価格情報とを比較する。比較により見積価格の方が高い見積書は対象外とする。希望契約価格情報よりも安く価格差がある見積書を採用する。このことにより契約先の企業が選定されたことになる。リカーリングシステム４２により選定された契約先の企業は、包括契約先企業としてリカーリングＤＢ４１の包括情報に、包括契約先企業情報として保全される。
次は、契約書を作成するプロセスになる。

【0133】

包括契約における契約書の作成について説明する。
包括契約書の作成は２種類となる。１つは、バーチャルな大きな医療機関と契約を行う事業者との間で交わす契約書。もう１つは、バーチャルな大きな医療機関と実際の医療機関４との間で交わす契約書になる。どちらの契約書の作成も同じやり方になる。
包括契約の締結は、リカーリングシステム４２による電子契約で行われる。電子契約の手法は既存技術を利用する。
デジタル契約書を自動作成する処理には、契約書のテンプレートを用いて、契約書作成のＲＰＡ技術に契約書作成プログラムを利用した方法で行う。テンプレート及びＲＰＡは既存の技術である。
１つ目の、バーチャルな大きな医療機関と契約を行う事業者との間で交わす契約書について。
この契約書作成に予め用意したテンプレートを使用し、リカーリングＤＢ４１の見積返答情報からリスト表示した備品情報と、見積価格の情報と、契約期間の情報、契約する企業情報を取得し、ＲＰＡ技術により左記の情報とテンプレートとを使用して作成された電子契約書の電子文が作成される。作製された電子契約書の締結は、企業が端末を利用してＷＥＢにアクセスし契約書締結ページに表示された「契約締結ボタン」を押すことで電子契約書に電子署名が行われ、電子契約書が作成される。リカーリングシステム４２の電子署名はRPAプログラムにより自動で行われている。
２つ目の、バーチャルな大きな医療機関と実際の医療機関４との間で交わす契約書の作成について説明する。
この契約に必要な情報は、リカーリングＤＢ４１の包括情報内に保存されている包括総消費量情報から医療機関４における備品の情報と消費量の情報を取得する。ここで取得した、備品の情報と消費量の情報は、医療機関４ごとに、備品の内容や消費量が違う。よって、医療機関毎に、備品とその消費量（契約する量）との情報が違うことになる。契約書のテンプレートに、医療機関４が契約するリスト表示した備品情報と、包括情報の中にある消費量の情報（契約する量）と、その備品の提供価格と、契約期間の情報と、ＲＰＡが算出した医療機関４が契約する契約金額を使用し、さらに備品提供者として契約する企業名とが、ＲＰＡ技術とテンプレートとを使用して作成された電子契約書の電子文が作成される。
契約書の契約者には、医療機関４とバーチャルな大きな医療機関の名称が転載される。作製された電子契約書の締結は、医療機関４が端末を利用してＷＥＢにアクセスし契約書締結ページに表示された「契約締結ボタン」を押すことで電子契約書に電子署名が行われ、電子契約書が作成される。リカーリングシステム４２の電子署名はRPAプログラムにより自動で行われている。これを地域の医療機関４の全医療機関４の締結を行うことになる。契約が締結された電子契約書は、リカーリングＤＢ４１の包括契約情報に保存される。またNFTにより所有者（所有権）を医療機関４とリカーリングシステム４２とに管理設定された電子契約書を医療機関に送付をすることもできる。
包括契約に関わる詳細情報が、リカーリングＤＢ４１に包括情報として保存されている。
包括契約のイメージを図６に示す。

【0134】

医療経済圏２４を利用する医療機関４において、一定地域内に所在している複数の医療機関４で備品の発注とその備品の仕入価格（購入価格）を下げることができる方法のサブスクリプション契約による備品の購入により、医療機関４からの支払額が少なくなる。
このサブスクリプション契約について記載する。
サブスクリプション契約での備品の購入は、医療機関経営事業支援システム１０にある、サブスクリプションシステム４３を用いて行う。このサブスクリプションシステム４３の一連のプロセスは、地域の消費量（1か月半年、１年での）の算出、サブスクリプション契約する対象の備品の選定や、サブスクリプション契約先の企業の選定、契約前見積依頼、サブスクリプション契約の契約書の作成、選定・契約見積・契約までの一連のプロセスを行うシステムとなっている。
このサブスクリプションシステム４３を利用して契約の受注を行う事業社は医療経済圏ＤＢ２１の企業の事業情報に登録されている医療機関４と備品の販売事業者又は備品を製造している製造企業である。
医療経済圏２４を利用する医療機関４が使用している備品の種類や備品の消費量と仕入価格（購入価格）又は払い出された量の情報は、経理業務ＤＢ３１に消費量情報として保存されている。
この地域の複数の医療機関４の消費量（使用量）を合計した地域全体の消費量（使用量）が、一定年期間は通常の購入価格よりディスカウウントされた定額で購入できる契約を行うことになる。サブスクリプションシステム４３は、この消費量（使用量）を、備品の発注量の情報としてサブスクＤＢ４４のサブスク情報に保存する。
さらにサブスクリプション契約は、契約に適する備品と購入先企業（サブスクリプションシステム契約先企業）を選定する必要がある。この選定する処理方法に、サブスク選定ＡＩという人工知能（ＡＩ）を利用することで煩わしい選定の自動化が図れる。
サブスク選定ＡＩは、サブスクリプションシステム契約を行う企業の選定と、サブスクリプションシステム契約を行う備品の選定を行う機能となる。
サブスク選定ＡＩは、一定年期間のボリュームディスカウウントでの購入に適切な備品、契約ができそうな備品、過去に購入実績のある備品、消費している量（発注する量）、通常価格、過去にサブスクリプション契約の実績のある備品、から備品を選定し、発注する備品名の情報としてサブスクＤＢ４４のサブスク情報に保存する。また、選定した備品をサブスクリプション契約でボリュームディスカウウント価格での提供を行ってくれそうな企業又は、過去に契約実績のある企業をサブスク契約先候補企業として選定をする処理を行い、選定したサブスク契約先候補企業の情報をサブスクＤＢ４４のサブスク情報に保存する。サブスク契約先候補として選定する対象の企業は、医療経済圏ＤＢ２１にある企業の事業情報に備品の発注先企業として登録されている企業（卸会社や生産メーカーなど）である。
さらに、サブスク選定ＡＩは、選定するために必要な情報として、選定したサブスク契約先候補企業のシステムから、備品の最少発注量の目安の情報と納期の情報とを取得しサブスクＤＢ４４のサブスク情報に保存する。
サブスクリプション契約を行うには、各医療機関４にて一定期間における消費量を契約の目安として使用する。１か月間、半年間、１年間の消費量（発注量）どちらも使用するが、一般的には１年間の消費量を基本に契約が行われている。この医療機関４の消費量（発注量）を地域全体の医療機関４で消費した備品ごとの総消費量を算出する。この算出した地域全体の総消費量をサブスクＤＢ４４のサブスク情報の中にサブスク総消費量情報を保存する。すなわち、仮想空間上の医療機関のサブスク総消費量情報である。
リカーリングＤＢ４１の包括情報の中に備品の包括総消費量情報が保存されているのでそちらを使用しても良い。
この消費量は、１年間の消費量を見て、翌年から契約する購入金額（仕入金額）、すなわち地域全体の医療機関へのディスカウントプライスの契約価格が決められる。1か月間で消費した量を１２倍して1年分として計算することも、半年間で消費した量を２倍して1年分として計算することもどちらでも構わない。

【0135】

サブスク選定ＡＩによる備品の選定について説明する。
サブスク選定ＡＩは、サブスク契約を行う備品の選定とその契約先となる候補企業の選定と、を行うものである。
サブスクリプション契約を行うには、契約の対象となる備品を選ぶ必要がある。地域全体の医療機関４においては数百種類の備品を使用している。この中からサブスクリプション契約の対象とする備品を選定する方法にサブスク選定ＡＩを利用して備品の選定を自動化して行う。
サブスク選定ＡＩによる、備品の選定に利用する情報は、従来複数の医療機関で購入していた備品のうち医療機関ごとに仕入価格に大幅なバラツキのある備品、それぞれの医療機関での消費量が多い備品（反対に消費量の少ない備品は除く方が良い）の情報、従来から提供されている備品で新製品として出回り始めた備品の情報、それぞれの医療機関で購入実績が多い企業が販売している備品の情報、それぞれの医療機関で購入実績が少ない企業（あまり利用していない企業）が販売している備品の情報、過去にサブスクリプション契約実績のある備品の情報を利用して、備品と契約先候補の企業が選定される。これらの情報の入手は、既に包括契約のところで説明しているが、これらの情報を保存しているのは、リカーリングＤＢ４１の包括情報である。この包括情報はここまで説明した備品を選定する為に必要な情報であり包括選定ＡＩでもサブスク選定ＡＩでもこの情報を利用する。ここではサブスクリプション契約の説明をしているため、説明上この包括情報をサブスク情報に置き換えて説明をしていきたい。包括情報の内容とサブスク情報の内容も全く同じものである。
また、選定した備品に紐づいている備品の購入先情報からサブスクリプション契約を結ぶ包括契約先候補企業を取得しどちらの企業と契約を結ぶかの契約先企業の選定を行う。
ここまで説明した情報、すなわちサブスク情報（包括情報）に保存されている情報を利用してサブスク選定ＡＩは学習する。
包括契約用に選定した備品が、正しい選び方だったとは限らない場合がある。包括契約よりもサブスクリプション契約の方が最適な選定だったと後で判明する。
ここで、サブスク選定ＡＩの学習方法について説明する。
サブスクＤＢ４２内にサブスク情報として保存されているサブスク総消費量情報から地域で消費した備品の情報と、その備品の内容の情報と、各医療機関の消費量の情報と、消費量の合計値の情報と、全ての医療機関での備品の消費量を合計したサブスク総消費量情報を取得し学習情報とする。
企業の情報として、過去に備品の購入先として取引していた企業や、備品の製造企業又は、過去に包括契約実績のある企業を包括情報にある包括契約先企業情報から取得し、過去にサブスクリプション契約実績のある企業をサブスク情報にあるサブスク契約先企業情報から取得し学習情報とする。
ここで挙げた情報を、人工知能に学習させる学習情報源とし、人工知能は教師の無い自己学習によるアソシエーション分析の手法を利用した学習を行う人工知能を利用する。
サブスクリプション契約用に選定した備品が、正しい選び方だったとは限らない場合がある。サブスクリプション契約よりも包括契約の方が最適な選択だったと後で判明する場合もある。
この判断に利用する情報が、医療機関４の消費量情報である。元来、サブスクリプション契約は消費する量（数）にフォーカスして契約を行う。契約期間が終了する間際に地域の医療機関の消費量と、サブスクリプション契約の参考にした契約前の消費量との差を見ることで判明する。サブスクリプション契約前の消費量よりも、契約後の消費量の方が少なかった場合は、サブスクリプション契約の選択が間違っていたことになる。又は包括契約を選択した方が正しかったと判明する場合もある。反対に、契約後の消費量の方が多かった場合は、サブスクリプション契約を選択して正しかったと判明する。サブスク選定ＡＩでは、こういったことも学習していき最適な契約を選択できるようになっている。
ここで、包括契約とサブスクリプション契約の違いについて説明する。
包括契約とは、包括した医療機関４を、今回は地域の医療機関としている。この地域の医療機関において一定期間で消費した量、すなわち医療機関が使用する量が契約対象の量としている。この量は提供側が提供する量であり、この量に対しての単価を決めたものが包括契約である。量を超えて注文した場合は、超えた量が通常の提供価格となる。契約量重視の契約である。それに対してサブスクリプション契約には、「量」の契約範囲は無い。一定期間においていくら量を注文しても、契約期間内は契約した価格で提供される。契約期間重視の契約である。よって、備品によっては、選択する契約が違う。間違って契約をすると、メリットを活かせないことになる。例えば福島震災で多くの包帯を消費した年があった。その消費量を元に翌年の調達に契約を使用した調達をしても、翌年は全く消費せず契約をする意味がなさない場合もある。包括契約をした場合、翌年は前年度を超える消費は見込めない、結果前年度の消費を超える消費にはいたらず、在庫を抱える契約となってしまい無駄となる。反対にサブスクリプション契約を選定した場合、量（数）に制限がないため前年度より消費が少なくても契約期間中の価格は安いまま必要な量（数）が提供され、包括契約とは違い大幅な在庫を抱えることもない。この例とは逆のケースもある。
こういった契約をしてしまい十分に契約が活かせなかった備品の情報と契約方法の情報も利用して、サブスク選定ＡＩ（包括選定ＡＩ）は選定を行う。在庫情報を見て、契約した備品の在庫が多ければ、契約が活かせない失敗した契約だったことが判明する。
また、選定した備品に紐づいている備品の購入先情報から包括契約を結ぶ包括契約先候補企業を取得しどちらの企業と契約を結ぶかの契約先企業の選定を行う。
ここまで説明した情報、すなわちサブスク情報（包括情報）に保存されている情報を利用してサブスク選定ＡＩは学習する。
サブスク選定ＡＩが用いる機械学習の手法は、サブスク情報（包括情報）として保存された情報を利用して教師なし学習のうちアソシエーション分析の手法を用いる。
この学習したサブスク選定ＡＩにより、仕入れ価格のバラツキがあり、消費量が多く、新しい製品が出る、購入実績が多い企業、購入実績が少ない企業の情報から選定される結果として、備品の選定とその備品の購入先候補企業の選定とその備品の仕入単価（推奨仕入単価）が算出される。ここでいう仕入単価（推奨仕入単価）は、地域の医療機関で仕入価格となっている一番低い価格を参考にさらに算出される。その備品情報に紐づいた消費量情報と購入先候補企業情報と仕入単価（推奨仕入単価）情報とをサブスクＤＢ４４のサブスク契約査定情報として保存する。
ここまでが、備品と購入先候補企業（契約先の候補企業）の選定までがサブスク選定ＡＩによるものである。

【0136】

サブスクリプション契約の価格と契約先を決めるため、サブスクリプションシステム４３は、サブスク情報に保存されているサブスク契約先候補企業に対して、サブスクリプション契約の契約価格の見積依頼を送る処理を行う。
サブスクリプション契約の見積とは、企業に対してサブスクリプション契約の依頼するための契約金の算出と契約期間の算出を依頼するものである。サブスクリプションシステム４３は、サブスク契約査定情報から、購入先候補企業情報に紐づいている備品情報を取得し、消費量情報（ここでは契約金を算出する量になる）とその備品情報の単価（一番安い仕入単価）を取得し、見積依頼書を作成する。サブスク契約の見積依頼書に記載される例は、備品Ａ・年間消費量１００箱・仕入単価１００円、備品B・年間消費量５００箱・仕入単価３００円の見積に必要な情報が記載された見積依頼内容である。
さらに見積を依頼した全ての備品に対する備品情報の単価と消費量情報の量を使用して算出した、そのサブスクリプション契約内容における総額価格を算出する。その算出した総額価格の情報は、依頼する見積書の希望契約価格情報として、以下に説明する電子化されたサブスクリプション契約の見積依電子文書と一緒にサブスクＤＢ４４の見積依頼情報に保存される。この希望契約価格情報は、回答のあった見積内容を評価するのに利用する。
見積依頼書は、電子文書のテンプレート利用し、テンプレートに備品情報と消費量情報をテンプレートに付加することでサブスクリプション契約の見積依電子文書が作成される。
この電子文書化されたサブスクリプション契約の見積依頼電子文書の送付先は、購入先候補企業情報にある企業へ送付する。送付先の情報は医療経済圏ＤＢ２１にある企業情報の連絡先情報を使用して送られる。各企業から見積の返答が順次くることになる。
サブスクリプションシステム４３は、この見積依頼に対する回答をサブスク契約先候補企業から受信し、回答内容をサブスク回答情報としてサブスクＤＢ４４に保存する。サブスク回答情報には、企業から送られてきた企業名、備品名、契約する備品の数量、契約金額、支払条件などの契約に必要な情報が保存されている。
ここで、商品を提供する企業について説明する。
何故、企業はサブスクリプション契約を行うのでしょうか？その答えは「独占」です。備品は、様々なメーカー（製造企業）が製造している多品種商品である。そして、沢山の卸事業社（提供業者）が販売している多卸事業となっている。また、メーカーが直接販売しているケースもある。サブスクリプション契約とは、数多くある多品種商品の中から１銘柄に絞られます。例えば、包帯を製造する企業が２０社、絆創膏を製造する企業が１０社あったとします、これらが地域全体で消費する量（数）を包括し、サブスクリプション契約を、包帯はA社と契約、絆創膏はC社と契約することで、備品を提供していた複数社の卸事業社や複数メーカーの直接販売は、サブスクリプション契約の契約期間中に、この地域への備品販売が一切できないことになる。契約した卸事業社又は製造企業だけの１社独占提供となる。他社からの参入（受注活動）が一切できない独占の状態になることで売上が上がる。契約できなかった他社は、契約期間中は手を出せずに見ているだけとなる。よって、次の契約時期を狙い次回の契約はさらに激しくなる。１度サブスクリプション契約を勝ち取ってしまい独占状態を味わってしまうとそこから抜け出せなくなる。医療機関４側も全く同じで安く買えることの経営体制を味わってしまうとそこから抜けられない。
サブスクリプション契約の見積依頼に対する見積書の返答について記載する。
見積依頼を受けた各企業は、見積の算出を行い見積書の提出を行うことになる。サブスクリプションシステム４３は、各企業から見積書を受信することになる。サブスクリプションシステム４３は、返答されてくる見積書内に記載されている見積価格と契約期間と備品とその備品の提供価格との情報を、見積を作成した企業ごとに取得し、企業情報に見積価格の情報と契約期間の情報と備品の情報と提供価格の情報と、その見積書の電子文書とをサブスクＤＢ４４の見積返答情報に各社保存する。サブスク選定ＡＩにより、返答のあった見積価格と希望契約価格情報とを比較する。この比較により見積価格の方が高い見積書は対象外とする。また、過去にサブスクリプション契約を行った企業からの見積価格の情報も参照して、希望契約価格情報よりも安く価格差がある見積書だけが絞り込まれていき採用を決める。このことにより契約先の企業が選定されたことになる。サブスクリプションシステム４３により選定された契約先の企業は、サブスク契約先企業としてリカーリングＤＢ４１のサブスク情報に、サブスク契約先企業情報として保全される。
次は、契約書を作成するプロセスになる。

【0137】

サブスクリプション契約における契約書の作成について説明する。
サブスクリプションシステム４３が行うサブスクリプション契約書の作成は２種類となる。１つは、バーチャルな大きな医療機関と契約を行う事業者との間で交わす契約書。もう１つは、バーチャルな大きな医療機関と実際の医療機関４との間で交わす契約書になる。どちらの契約書の作成も同じ方法になる。
サブスクリプションの締結は、サブスクリプションシステム４３による電子契約で行われる。電子契約の手法は既存技術を利用する。
デジタル契約書を自動作成する処理には、契約書のテンプレートを用いて、契約書作成のＲＰＡ技術に契約書作成プログラムを利用した方法で行う。テンプレート及びＲＰＡは既存の技術である。
１つ目の、バーチャルな大きな医療機関と契約を行う事業者との間で交わす契約書について。
この契約書作成に予め用意したテンプレートを使用し、サブスクＤＢ４４の見積返答情報からリスト表示した備品情報と、見積価格の情報と、契約期間の情報、契約する企業情報を取得し、ＲＰＡ技術により左記の情報とテンプレートとを使用して作成された電子契約書の電子文が作成される。
作製された電子契約書の締結は、契約する企業が端末を利用してＷＥＢにアクセスし契約書締結ページに表示された「契約締結ボタン」を押すことで電子契約書に電子署名が行われ、電子契約書が作成される。サブスクリプションシステム４３の電子署名はRPAプログラムにより自動で行われている。
２つ目の、バーチャルな大きな医療機関と実際の医療機関４との間で交わす契約書の作成について説明する。この契約に必要な情報は、サブスクＤＢ４４のサブスク情報内に保存されているサブスク総消費量情報から医療機関４における備品の情報と消費量の情報を取得する。ここで取得した、備品の情報と消費量の情報は、医療機関４ごとに、備品の内容や消費量が違う。よって、医療機関毎に契約する、備品とその消費量（契約する量や数）との情報が違うことになる。契約書のテンプレートに、医療機関４が契約するリスト表示した備品情報と、その備品の提供価格と、契約期間の情報と、契約する企業名とがＲＰＡ技術とテンプレートとを使用して作成された電子契約書の電子文が作成される。
契約書の契約者には、医療機関４とバーチャルな大きな医療機関の名称が転載される。作製された電子契約書の締結は、医療機関４が端末を利用してＷＥＢにアクセスし契約書締結ページに表示された「契約締結ボタン」を押すことで電子契約書に電子署名が行われ、電子契約書が作成される。サブスクリプションシステム４３の電子署名はRPAプログラムにより自動で行われている。これを地域の医療機関４の全医療機関４の締結を行うことになる。契約が締結された電子契約書は、サブスクＤＢ４４のサブスク契約情報に保存される。またNFTにより所有者（所有権）を医療機関４とサブスクリプションシステム４３に管理設定された電子契約書を医療機関に送付をすることもできる。
サブスクリプション契約に関わる詳細情報が、サブスクＤＢ４４にサブスク情報として保存されている。
サブスクリプション契約のイメージを図7に示す。

【0138】

ここまで、医療機関４が備品購入の際に利用する包括契約やサブスクリプション契約の手法について説明してきた。この手法は、備品購入だけでなく、医療機関４や介護機関が共同利用している設備機材（設備）の購入にも使用できる。設備機材としては、例えば、「MRIやＣＴ、除細動器といった高額な医療機器」、「院内での連絡に使用するスマートフォンや業務用タブレット、パソコン、ディプレイといった少額だが大量に使用するＯＡ用機材全般」、「ＯＳ（オペレーティングシステム）やソフトウェアといった無形物資産」などがある。すなわち、仮想空間上の医療機関の設備機材情報である。このような設備機材をまとめたものを、設備機材システム３２は、仮想空間上の医療機関での設備機材として扱う。設備機材システム３２は、仮想空間上の医療機関の設備機材として、それぞれの契約の処理を行う。
医療機関４や介護機関が設備機材を共同利用することにより経営上の設備機材投資費及び設備機材経費削減が期待できる。設備機材を共同利用するにあたり、経理業務ＤＢ３１の設備機材情報には、医療機関４及び介護機関毎に所有している設備機材の品名、メーカー、所有数、管理者、購入年月、導入価格、定期校正予定時期、リプレース予定時期、使用者、借用者、利用予約患者の設備機材に関係する情報が保存されている。
プラットフォーム型医療機関４支援システム１にある設備機材システム３２は、設備機材情報に保存されている情報を利用して、医療機関４や介護機関が共同利用する設備機材の運用管理を行うことができる。
設備機材システム３２が行う、設備の運用管理としては、医療機関４や介護機関が所有している設備の予約状況の管理とその設備の予約を受け付けることできる。この予約は、設備を所有する医療機関４や介護施設６内からの予約だけでなく、設備を共同利用しているほかの機関からの予約を受け付け、受け付けた予約を設備機材情報に保存する。
また、設備機材システム３２は、設備の検索機能もあり、設備機材情報にある情報から利用したい設備機材の検索が行え、検索した設備機材の詳細情報や予約状況の提供を医療機関４や介護機関に対して行うことができる。
結果、バーチャルな医療経済圏２４内で事業を行う医療経済圏２４を利用する企業が、設備機材を貸す事で設備投資費の回収を早める事と、機材を借りる事で設備機材の設備投資費の削減が行える。
前述の通り、医療機関４が備品購入の際に利用する包括契約やサブスクリプション契約の手法は、設備機材の購入にも活用でき、包括選定ＡＩやサブスク選定AIを利用することで行える。手法自体は、備品の購入時と同様のため説明を割愛する。

【0139】

従来、医療機関４や介護機関における設備機材（設備）の導入方法は、「固定資産として設備を購入」「リース会社とリース契約して設備を導入」うちどちらかの方法で行われていた。固定資産として購入した場合、医療機関４や介護機関は、国が定めた法定耐用年数に記載された期間、固定資産税を払い続ける必要がある。リース契約して導入した場合、医療機関４や介護機関は、資産として保有していないため固定資産税を払う必要はない。これは、リース契約して導入した場合における資産の保有者はリース会社のためとなっている。しかしながら、リース会社は、物理的には資産を保有していないため、固定資産税を払うべき資産ではないとして固定資産税を払っていない。よって、リース契約の場合、だれも固定資産税を払っていない現状がある。国は、リース契約によるこの現状を問題視している。
このような現状から、サブスクリプション契約が生まれた。
サブスクリプション契約の場合、医療機関４や介護機関は、設備を保有せず、利用権のみを有している。そのため、固定資産税の支払う必要がない。よって、サブスクリプション契約は、医療機関及び介護機関の固定資産税の削減につながる。

【0140】

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

【0141】

本考案のシステムを維持する運営費は必要不可欠である。システムの運営費をシステムで賄うビジネスモデルとして提供できるスタイルが望ましい。医療経済圏を利用する企業が経営上の経費削減が行えるサービスを有料で提供するビジネスモデルであることによりシステムの運営が行える。有料化するサービスは、医療機関や介護施設のバーチャルな医療経済圏を利用する企業が経営改善から経費削減の一環として備品や設備機材の調達コスト（仕入れ価格）を引き下げるサービスを有料で提供する。廃棄回収における廃棄回収コストを引き下げる同様なサービスを有料で提供する。さらに医療経済圏を利用している医療機関や介護施設が実在する地域全体の販売シェアを勝ち取りたい企業を対象。すなわち１軒１軒廻る手間と時間をかけず、営業活動もせず人件費もかけずに根こそぎ地域の販売シェアを勝ち取りたい企業に対して、包括契約やサブスクリプション契約による販売の契約書作成から契約の締結、契約書管理までのサービスを有料で提供する。このサービスの申込は、ＷＥＢを利用しサービス申込ページにより企業からの申込を受けるようにする。説明してきたように、調達価格の恩恵が受けられる包括契約やサブスクリプション契約は、それぞれを提供する企業との契約により成立するものである。本サービスは、このそれぞれの契約を締結することがサービスである。有料サービスの支払いは既存技術により支払いを行うのでここでは記載はしない。既存技術は、例としてキャッシュレスやＥＣサイトやネット決済や出願人考案の特開２０２１－１１３９２７などである。出願人考案の特開２０２１－１１３９２７を利用する理由は、現在の法定通貨から次世代のデジタル通貨に代わっても、利用方法を変えずそのまま利用できるメリットがある。
この契約により、提供を受ける側と提供する側がｗｉｎｗｉｎの関係になる。
この有料サービスは、プラットフォーム型医療機関支援システムの持続化を行うための収益が得られる仕組みであり、ビジネスモデルである。

【0142】

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

【0143】

＜第２実施形態＞
医療機関４における病院経営及び診療・診察の付帯業務の改善は喫緊の課題の１つといえる。
現在、多くの医療機関４では、「来院後、待合室で数時間待たされ、数分診察」と言われている。とくに、大きな医療機関４では朝早く受付開始時間前に待ち、診察前に大きな待合室で診察待ち、名前が呼ばれると中待合室で診察待ち、診察が終われば長い会計待ち、調剤薬局４ｂで処方薬待ち、こういった「患者が待たされる」ということに対して、患者への配慮をしないこと慢性化してしまっていることである。
このことにより、待合室では、大勢の患者が待っている。さらに、病院４ａの診察予約を行っていても、大勢の診察待ちの患者がいる待合室で一緒に待たされることとなっている。これらは、診療・診察の付帯業務の一環として改善すべきことである。医療機関４の待ち時間としては、「開院時間の前に開院待ち」や「受付開始時間前の受付待ち」、「長い会計待ち」、「処方薬待ち」だけでなく、「処方薬の受付待ち」、「処方薬の会計待ち」などの待ち時間もある。
さらに、感染症が蔓延している状況では、患者は、院内での感染を恐れ病院４ａへ行かなくなる。特に高齢の患者は院内での感染を恐れ病院４ａへ行かなくなったのは2020年に発生した事案は出願時前年既成事実である。これはＴＶによる「密閉・密集・密接の３密を避ける」報道から、特に高齢の患者は医療機関内にある待合室が患者同士による密になり、待合室で感染するのではないかと精神的に恐れ、患者自身や家族との話し合いで悩んだ末の感染予防策として、「多くの高齢患者が医療機関に行かなくなった」ものである。
よって、患者数の減少により病院経営は悪化していく。本開示の医療情報システム９では、「待合室を密にしない」又は「待合室を利用しない診察」を実施できるように、待たずに診察「NoWaitConsultation」を行うことを基本に考案した。また、待ち時間を減らすために、病院への診察料の支払いを薬局への調剤料の支払と合わせて、調剤薬局でまとめて行う考案がある。この考案は、第４実施形態に記載の手法となっている。病調剤薬局でまとめて支払いを行うことにより、院での会計待ちを無くすことができる。
患者が精神的にも院内感染を恐れずに、目に見える仕組みを患者に提供し精神的にも安心して病院４ａに行ける体制を作り、従来の医療の商慣習を改善し病院経営を改善させる方法でもある。

【0144】

第一に、病院４ａの待合室での診察待ちの患者数を減らす事と、長い診察待ち時間を無くす事と、または、診察待ち患者を待合室では無く病院周辺の商業施設や飲食などの他の場所へ分散し誘導する事、院内の患者同士の密を無くす事と、外来患者が集中する時間帯の診察待ちを別の時間へ分散する事を次回の診察予約に予約患者の予約した時間に診察開始を行うことで解決する考案をした。第二に、予約した診察時間に合わせて通院できるシステムで、待合室での待機時間を減らす又は待合室の利用を無くす方法を考案した。この二つにより、院内での診察待ちや会計待ちの患者による「密状態からの感染を恐れて来院を避けていた患者が、安全に診察が受けられると見直し、再び来院することの期待がもてる。よって、パンデミックの状況下においても病院４ａの経営に影響を与えなくなる。本考案により医療機関４での「待たない診察『NoWaitConsultation』」を推奨していきたい。

【0145】

ここで、2020年に発生した事案より以前における患者の状況を整理してみると。
以前からも診察待ちの患者が多く利用は明確となっている。従来から医療機関の診察時間は曖昧で医師と患者との面談や診察から長い時間診察がかかったり、かといえば薬の処方依頼や服薬報告だけで簡単に診察が済み５分もかからずに診察が終わったりしていた。こういった曖昧な診察時間の積み重ねにより、患者は自分の診察時間を予測（推測）できずに長い時間診察を待つ昔からの習慣がある。患者は、この曖昧な診察時間から発生している長い待ち時間に対して無意識に反応し又は予測し「時間より早めに病院に来る」、そして「長い時間待つ忍耐や覚悟」から身体的に精神的に疲労が発生することもある。何故患者は早く来るのか？働く世代においては「５分前行動」という社会的習慣があるが、それが医療の場合「１時間前行動」を起こす精神的な深層心理があるともいえる。患者は、「朝早く行けば待ち時間が短くてすみ診察してもらえる」という商慣習になっている。患者が朝一番の受付時間前に、大勢並んでいる事がそれを物語っている。まるで朝早く店頭に並ぶバーゲンセールと同じ現象です。さらに一般的にこういった事を耳にする、「病院に行くには、半日かかりだよ」や「長い時間待たされる」などの患者の苦痛を口癖として聞くことができる。待つ事の肉体的精神的な負担（苦痛）となっている。
この昔からの苦痛を無くすことが必要であり、無くさなければならない事である。
今まで患者側の目線で、精神的又は肉体的な苦痛について説明したが、ここから医療側目線で説明する。
患者が待つ、ということに対して現在の医療機関側の対応はどうでしょうか？患者が「あとどれくらい待ちますか？」という問いかけに、医療従事者の回答は「診察の番が来たら呼びますから、それまで待っていてください。」という対応は昔から変わらず行われていた。この点が第２ステージに突入したと言えるのは、順番が可視化されるようになったことである。現在診察している受付ナンバーと次に控える直近の受付ナンバーがディスプレーに表示されるようになり、自分の番号が表示されれば「あと何番目だ」と順番だけわかりますが、自分の受付ナンバーが表示されなければ一考に待ち時間がわからない。順番は可視化されたが、待時間は可視化も待ち時間の短縮も改善はされてはいないのが現状です。従来、患者が知りえる情報は、「開院時間」「受付開始時間」「診察開始時間」「診察終了時間」「閉院時間」だけでした。これに対して、近年の院内情報化により患者に提供している可視化された情報は、「開院時間」「受付開始時間」「診察開始時間」「受付ナンバー」「直近の受付ナンバー順番」「診察終了時間」になり、「受付ナンバー」を色々な形で可視化されたが、待つ事に対する患者の負担は変わっていない。
医療機関は、ＩＴに高額投資をしてもそれが患者目線に繋がっていないことではないでしょうか。患者は（特に高齢者）長い間待合室のシートに座って診察待ちをしなければならない被害に合っているものである。
可視化される情報により、人間の行動や、精神的な負担や苦痛、が変わることについて説明する。
患者や人は状況が把握できれば、また状況が可視化されれば、それに合わせて推測や憶測で行動をとることや苦痛から回避行動をとることが可能である。その一番の良い例が、指定席列車又は旅客飛行機ではないでしょうか。これらは出発時間が決まっているため、可視化又は提供される「出発時間」や天候や家を出る時間帯に合わせて人は、考え行動を推測し決定し、無意識に行動を起こすことができる。さらにあるインターネットのシステムでは運行している列車の混雑状況や、さらに列車の車両毎の混雑状況などを知ることで、空いている時間帯の電車を選んだり、空いている車両を選んだりする。このように、自分の診察開始時間が決まっていればその時間に合わせて行動を起こすことができるし、混雑状況が分れば混雑の苦痛から回避する行動を取ることができる。但し、医療機関側で時間どおりに診察が始まり、時間通りに終わるというプロセスが動いている上での患者の行動となるでしょう。

【0146】

ここから、医療機関で使用している従来の予約システムに目線を向けて説明していく。
医療機関の情報システムのうち、患者が利用し尚且つ診察時間に関係するシステムは診察予約を行う予約システム９ｄくらいかと思います。ここでは患者の診察時間に関係する従来の予約システム９ｄにフォーカスし説明する。予約システム９ｄは、一定時間に患者の予約を詰め込むロジックになっている。例えば、３０分間の中で２～３人予約を受け付けるロジックの場合、午前１０時診察予約の患者が２～３人、１０時３０分診察予約の患者が２～３人予約していることになる。この３０分間における予約患者の数は、医師一人が３０分間の診察においてシステムが詰め込んだ人数であり、そしてその他の診療科の医師の数が増えれば、３０分間では医師N人に対して患者２～３人の診察待患者が発生する。そして待合室には予約していない外来患者の人数が加わることになる。これにより当然ながら待合室では診察待ち患者同士による密が発生していることは想像がつく。この密を招いている原因の1つが医師の診察にかかる時間を考慮しておらず、ただ３０分に２～３人の患者予約を受け付けている予約システム９ｄであることがわかる。さらに予約システム９ｄは、患者が朝早く来る原因と、患者の待合室での長い診察待ちと、患者の診察待ち苦痛等の待ち時間に対して考慮していない単純なロジックによるシステムだとわかる。ここまで現在の予約システムの内容とそのシステムの欠点を説明した。
また、ここまでくるとだんだんと患者の行動を制御できるようにするにはどうすれば良いかがわかってくる。鉄道を例に説明していくと、乗車予約した列車の出発時間に患者がホームに居れば良い、そして出発する時間に医師が電車を走らせ次の駅に運行時間通りに止まれるシステムであれば良いことになる。さらに全席指定で混雑情報があれば良い。
さらに、それらの情報と状況情報を患者に提供することで、その情報から推測し憶測で苦痛から逃れる回避行動をそれぞれの患者が取れるようになるが、取らない者もいるだろう。しかし、自ら予約した列車に乗れない人はいない。患者に自発的に行動をとるようにするには、できる限りの情報を患者に提供することが必要になる。
それでは、医療機関は今後どんなシステムを用意する必要があるか？
医師の情報をできる限りシステムで利用できるように算出し数値化する。
医療機関の運営を鉄道会社のように数値化し時間割をする。
個々の患者ごとの病状におけるデータを利用し、医師の情報と掛け合わせた結果の情報から、患者が行動を起こすための判断材料を提供すればよい。
医療機関の状況から患者が苦痛からの回避行動を自ら決められる情報の提供と、患者の諸情報の情報から医療機関側の従業員が、患者の行動を推測することも新しいシステムとして必要になる。
医療機関側の従業員が、患者の行動を推測することも新しいシステムとして必要になる。
救急で運ばれて来る患者以外は、医師の診察時間を数値化することはできる。
このような情報が必要になる。
患者が取る行動は、医療機関内での待合室での「密」と「そこで長い間待つ」ということからの精神的な恐怖により通院しないことである。これを払拭すれば良いだけである。
日本中の医師５ａや医療機関４経営者が、もっと患者目線で患者に寄り添った医療行為を行えば本件で指摘している「患者が病院４ａに来ない」という事が、医療機関自らが招いた弊害で起きていることに気がつき、自ら対策をとる必要があると考えなおすのが重要である。
現在の予約システム９ｄによる診察待ち滞留を招く問題点を解決するには、医師は患者自身の診察所要時間を用いたロジックによる診察予約を行うことで、一日の診察スケジュールが診察予約されたスケジュールの工程（時間配分）で行われることになれば、患者は無意識のうちに鉄道の時刻表のように自分の時間に合わせて通院するようになる。この予約システムで予約された時間通りに診察が行えれば、待合室を利用する患者の数を減らすことができ、長い診察待ちを無くすことが可能となる。
どのようにしたら医療機関内の運営を時間通りに行えるのか。個々の患者の所要診察時間で1日の運営を組み立てる（スケジュール）こと、すなわち鉄道の時刻表のように1日に運行する電車の数を来院する患者の数とし、１駅間の運行時間を始発駅から終点駅までの分を表にしたものが時刻表であり、医療機関の場合の時刻表は１日に来院する個々の患者の所要診察時間を表にしたものであり、その表を作り上げるものが予約システムである。
しかしながら、この時刻表（医療機関の１日分の診察所要時間）には、現段階で外来患者の診察所要時間は入っていない。鉄道の時刻表のように正確な時刻表を予約システムで時刻表を作ることが必要となる。
それには、それぞれの患者毎の適切な診察にかかる診察所要時間を計算し数値化することが必要となる。この診察所要時間は、医師の働く時間すなわち診察時間を算出すればよい。
ここで必要な患者の診察所要時間は、担当医と担当している患者の病状による治療内容や診察内容と過去の診察所要時間の実績の情報を使用することで算出が可能となると推測できる。
医師の診察時間の算出には、患者の診察内容と、診察内容を決める医師の考え方と、それぞれの医師毎に違う力量いわゆる熟練度や技能と、これら３つを可視化又は数値化する事が必要である。これは意外と難しくはない。診察予約した患者を診察する時の医師の診察業務の細分化を情報化し可視化する。
医師の診察業務の細分化は、患者の次回診察の内容は意外と簡単に細分化ができる。次回診察する患者のタイプにより大きく分けると、（１）外来で訪れた患者、（２）慢性患者又は経過観察や術後観察の患者、との２つに分類される。ここからさらに絞込みをかけて例として説明する。「（１）急性期外来で訪れた患者」の次回診察の細分化した診察内容は、（Ａ）処方された処方薬を服用しての作用確認、（Ｂ）患部の再処置又は経過、（C）病状からの経過観察や検査・確認などの診察内容に分けられる。次に、「（２）慢性患者又は経過観察や術後観察の患者」の次回診察の細分化した診察内容は、（D）身体の経過検査、（E）術後の経過検査と術後処置、（F）定期検査と服用薬の継続処方や、（G）固有の慢性患者においては治療や処置、（H）慢性的な処置（透析患者が例）などの診察内容に分けられる。簡単に分けても８つに分類されることができる。但し、この分類をもう少し深く掘り下げればさらに分類数は増えるが、説明上ここまでとしておく。これらの例のように次回診察の細分化した診察内容は、ある程度の細分化を行うことができる。
診察所要時間を算出するために、次に必要なのはそれぞれの患者の病状である。この患者の病状は、電子カルテから情報を引き出す。急性期外来で来た患者なのか、定期的に来る慢性患者又は経過観察や術後観察の患者に分けられる。
ここでプラットフォーム型医療機関支援システム１内の診察時間システム５２が電子カルテから取得出来る情報を整理する。診察時間システム５２が電子カルテ９ａから取得出来る情報は、患者名、年齢、性別、初診時の来院の病状程度、初診時の該当部位、担当医師名、患者の病名及び慢性疾患名（病名情報）、担当医師が患者の電子カルテ９ａを開いた時間、担当医師が患者の端末にキー入力した診断内容を保存して終了した時間の情報を取得することができる。また、診察時間システム５２は、この情報を使って計算を行う。診察時間システム５２が電子カルテ９ａから取得した情報は、算出基礎情報として診察所要時間ＤＢ５１に保存する。

【0147】

ここで医師の経験や熟練度について考える。
民間企業で働くエンジニアは、スキルズチェックシートによりエンジニアのランクや熟成度が決まる。しかし医療の場合は、それが無い。医師の場合の力量又はや熟練度は治療実績くらいしか無い。医師の治療実績、いわゆる経験値は電子カルテから担当している患者数と担当した患者数から取得できる。当然ながら医師の経験値は医師の年齢に比例しているが、ある年齢に到達すると反転していく。電子カルテから取得できる診察所要時間について説明する。
ここで必要となる患者の診察所要時間は、電子カルテ９ａ上に記載がないため、予約に使用することができない。よって、診察時に記録される様々な情報の中から「担当医師が患者の電子カルテ９ａを開いた時間」と、「担当医師が患者の診断内容を保存して終了した時間」の情報が取得できる。この情報の差の時間が、診察所要時間になる。この診察所要時間は、その日その時の電子カルテに記載してある患者年齢と、性別と、その患者の病名と、担当医師と、その日の診察内容による実際の数値である。この実際の診察所要時間を計算で算出しようとすると、患者年齢と、性別と、その患者の病名と、担当医師と、診察内容とを数値化し、その数値化された情報を使用すれば診察所要時間を算出することが可能ということになる。ここで言う診察内容とは、前記した「次回診察の細分化した診察内容」と同等になる。
医師の経験値を数値化して計算に入れると求める答えの正確性が上がると推測できる。
インターンの医師と、４０代の医師、５０代の医師とでは熟練度が違うため病気を治す解決策を出す時間が違うと推測する。
しかしながら良く考えると、電子カルテから取得する時間の情報には、医師が文章を組み立て記載（キー入力）した内容と保存した時間である。確かに熟練度の高い医師の方が的確な答え（診察）を出す時間は早いでしょう。そしてカルテに記載する文章を構成する能力も経験から素早く組み立てると推測できる。しかしながら、キーボードによる日本語のタイピング入力速度や漢字変換までの総合的なキー入力までの時間を考慮すると、年齢の高い熟練医師よりも胴体視力の高い若い医師の方が、キー入力時間が早いと考える。よって、この考えから電子カルテから取得できる時間においては、医師の熟練度や年齢による医師のファクターを考慮する必要が無いと判断した。あくまでも電子カルテから時間という情報を取得する限りにおいてである。
特定の患者Aさんと担当医による過去の患者Aさんのカルテから過去の全ての通院日の情報から、「次回診察の細分化した診察内容」の診察内容毎の「担当医師が患者の電子カルテ９ａを開いた時間」と、「担当医師が患者の診断内容を保存して終了した時間」の情報から診察内容毎の診察所要時間を算出し、診察内容毎の平均値を求める。この次回の診察内容毎の平均値を利用して患者Aさんの次回の診察内容の診察所要時間とする方法もある。
さらに精度を上げるには、患者Aさんの担当医師が担当した全患者の情報へと範囲を広げる事で算出される精度が上がる。さらに病名毎に算出し、病名毎の診察内容毎で算出し、さらに患者の年齢毎に分けて算出する方法でも精度が上がると推測する。例えば、糖尿病患者の経過検査・処方箋での診察内容と、患者１０代未満、１０代、２０代、３０代、４０代、５０代、６０代、高齢者、のように年齢毎に算出する。
医師が１人しかいない開業医院などの場合は、この方法となる。
診察時間システム５２は、複数人いる医師毎に、それぞれが担当した患者の全ての情報から、病名毎に、そして診察内容毎に診察所要時間の平均値を算出する方法と、その算出には前記した患者の年齢毎に時間を算出する方法とにより診察所要時間を算出する。算出した診察所要時間は、診察所要時間情報として、診察所要時間ＤＢ５１に保存する。
また、さらに診察所要時間の精度を上げるには、プラットフォーム型医療機関支援システム１を利用している、医療情報システム９（電子カルテ９ａ）から、複数医療機関の複数医師とその医師が担当した患者の情報を使用して前記した計算と同様に病名毎に、そして診察内容毎に、患者の年齢毎に分けて算出する方法により診察所要時間を算出する。算出した診察所要時間は、診察所要時間情報として、診察所要時間ＤＢ５１に保存する。
さらに正確性を求めるのであれば、人工知能（ＡＩ）を使用し、電子カルテへの保存が終わった時点で機械学習を繰り返すことにより算出された診察所要時間が満足な値になる。
この人工知能（ＡＩ）を利用した方法は、別の項で説明する。
急性期の外来患者の場合は、朝早くに医療機関の開院前に並んでしまう心理を解消し、並ぶより並ばない方が「得」だという心理を与えることで、それが慢性化していく。
朝早く並んで、開院して受付処理を済まし、そのまま待合室で長い間過ごすことからの意識改革は、自宅から当日の受付処理を済まし、診察を始める時間を決めてしまう方法へと変更することで待合室の人数は減らせる。また前日に翌日分の診察予約を行う事も可能となる。
この自宅や携帯端末を利用して受付や診察予約を行う方法は、既存技術である。
自宅や携帯端末を利用して受付や診察予約を出来る患者は、既に診察カードを所有している者に限られる。但し、他の医療機関の診察カードを利用して診察受付をする場合は、第５実施形態の手法を用いることで、他の医療機関の診察カードで診察の受付を済ませることができる。
自宅や携帯端末を利用して受付を行うには、問診表への入力が必要となる。このネットワークを介した問診表の入力も既存技術であり、この問診に記載された内容から情報を取得し診察時間を算出方法は、後記する。

【0148】

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

【0149】

診察所要時間の算出結果を出すための学習方法は、診察所要時間ＤＢ５１に学習源情報として保存された情報と、算出した診察所要時間とを教師データとして用いた学習を行う。学習させた結果、病状ごとの診察所要時間または症状ごとの診察所要時間を算出できるモデルが作成できる。モデルは、医師診察所要時間情報を用いた場合の「医師診察所要予測モデル」と用いらない場合の「診察所要予測モデル」との２つを作成する。作成した２つのモデルは、診察所要時間ＤＢ５１に更新保存する。これらのモデルに、予測したい患者病状や性別などの情報を使用することにより、同一病状の患者の診察所要時間の算出が可能となる。

【0150】

診察予約管理システム６２は、作成した診察所要予測モデルに、診察所要時間を予想したい患者の病状や年齢、性別の情報を使用することで、患者の診察所要時間を予測した、診察所要予測時間を算出する。算出した診察所要予測時間は、診察所要予測時間情報として診察所要時間ＤＢ５１に保存する。
診察所要予測モデルに代え医師診察所要予測モデルを使用することで、医師ごとに算出した診察所要予測時間の算出ができる。医師ごとに算出した診察所要予測時間は、医師診察所要予測時間情報として診察所要時間ＤＢ５１に保存される。
決まった主治医がいる場合の診察所要時間の扱いは、主治医の時間を予測した医師診察所要予測時間情報を使用して診察所要時間とすることになる。
また、決まった主治医がいない場合は、医師の時間を予測した診察所要予測時間情報を使用して、診察所要時間とすることになる。

【0151】

リアルタイムでの学習について説明する。
人工知能のシステムを採用すると、システムの維持費は高くなってしまう。すなわちプラットフォーム型医療情報システムの維持費が高くなってしまうことになる。人工知能システムを省力化するために、リアルタイムに、システム自ら学習することが必要となる。このリアルタイム学習は、診療をしている医師の行動を利用して学習の操作を行うようにした。人工知能のリアルタイムの自己学習（リアルタイムの機械学習）は、医師が電子カルテ９ａに患者の診察内容を保存することで行われる。診察時間システム５２は、医師が電子カルテ９ａに患者の診察内容を保存する行動を行なったことを検知すると、リアルタイムに診察時間の終了時間の情報を取得する。取得した診察時間の終了時間の情報と、電子カルテから取得できる診察開始の時間から患者の診察に実際に要した診察時間を算出する。人工知能は、学習源情報に保存されている予約時に算出した診察所要時間と実際に診察に要した時間と学習源情報に保存されている病状の情報とをもとに自己学習を行い、診察所要時間の算出を行うモデルを更新する。更新されたモデルは、更新前に比べて診察所要時間の算出精度が向上することが期待できる。この自己学習は、システムを運用する側の人間が情報を入力するのではなく、システムを利用する側（今回の場合は医師）が、日常の業務の中の行動から取得した情報を利用している。そのため、システムの運用側・システムの利用者側双方の負担なくシステムの省力化を行うことができる。
学習結果がすぐに反映できた場合は、その診察時に行う次回の診察予約に用いる診察所要時間を算出するモデルとして使用することもできる。リアルタイムで学習が行わることで、常に最新の学習結果を利用できる。
リアルタイムの自己学習とは、アメリカのAmazon.com社が運営しているAmazonGo（商標）という無人店舗で用いられている、「会計結果の間違いを指摘するとシステムに用いている人工知能が即座に学習しシステムに反映する」手法などのことであり、人工知能に追加の情報を与えると即座に学習しシステムに反映すえることを示す。このリアルタイム学習には、事業者側で学習させる人員が介在しないことが特徴である。
本開示のシステムとAmazon.com社のシステムのリアルタイムの自己学習では、以下の２点が異なっている。
Amazon.com社のシステムは、システムの運営側又は専門の従業員により人工知能への学習を続けるのではなく、無人店舗に来る「客」を利用して、客に人工知能の学習をさせるという発想のものである。買い物を行った人すなわち利用者３がスマホで作業を行うことによりその作業が人工知能への学習として行われる。一方、本開示のシステムの場合は、医療機関４の予約時点に、すなわち人工知能を運用する事業者側の診察時間システム５２が自動で算出処理を行うことにより人工知能への学習が行われる。いわゆる学習にかかる人件費をかけずとも永久にリアル学習が持続され、学習経費の大幅に削減につながっている方法である。
また、Amazon.com社のシステムは誤認識による間違いを防ぐための画像認識の精度向上のみを目的としている。一方、本開示のシステムは、診察所要時間の精度向上を目的としている。

【0152】

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

【0153】

第２実施形態のデータベース構成を図８に示す。本実施形態では、情報に接続可能な大きな１つのデータベース（医療情報共有データベース）にある、医療経済圏ＤＢ２１、予約DB６１、診療情報ＤＢ５３、診察所要時間ＤＢ５１の各データベースに保存されている情報を参照し利用している。医療経済圏ＤＢ２１の情報には、個人情報２２，患者予定情報、遅刻情報が保存されている。予約DB６１の情報には、予約情報，予約状況情報、予約可能日時情報が保存されている。診療情報ＤＢ５３の情報には、診療点数情報が保存されている。診察所要時間ＤＢ５１の情報には、病名情報、病状名情報、学習源情報、診察所要時間情報、医師診察所要予測時間情報、診察所要予測時間情報が保存されている。各情報の説明は、情報の使用時に記載する。

【0154】

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

【0155】

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

【0156】

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

【0157】

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

【0158】

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

【0159】

医療機関４が診察予約管理システムを用いて行う予約は、患者の診察所要時間の算出結果と医療機関の予約状況情報と患者予定情報とを利用した算出処理方法により予約可能日時の算出を行い、その算出結果を用いて予約を行う。
予約可能時間の算出する処理方法は、患者予定情報から取得できる患者の都合の悪い日時（すでに予定が入っている日時）と医療機関の予約状況情報から取得できる既に予約が入っている日時とを除外する処理を行う。この処理の結果に、算出した患者の診察所要時間が確保できる日時を検索による算出処理を行う。この算出処理の結果が、予約可能日時となる。診察予約管理システムは、医療機関４の端末に患者の予約可能日時を表示する。さらに、診察予約管理システムは、算出した予約可能日時を予約可能日時情報として予約ＤＢ６１に保存する。
予約の方法について説明する。
予約の方法は、２種類あり、「予約日の早い時間から順次予約する」「予約日のアトランダムに予約する」がある。予約に使用する診察所要時間は、患者の診察所要時間に医師の準備時間を付加したものを診察所要時間として予約時間に使用される。例えば、患者Ａさんの診察所要時間は８分、Ｃ医師の準備時間を３分としていたとすると、患者Ａさんの予約に使用する予約時間は、８分＋３分＝１１分で、診察予約管理システムは予約される。
この準備時間とは、医師は患者の前では電子カルテに記載できない、患者の耳に入れられない診察の情報があるため、患者が診察室を退室してから入力する時間と、次に診察室に入出する患者の情報を見て診察を始められる準備をしなければならない。こういった事に利用される時間を準備時間としている。準備時間は、医師が任意に決められ、患者ごとに時間を変えてもよい。
「予約日の診察開始時間から順次予約する」は、従来から使用されている予約システムの方法で、予約日の診察開始時間から順番に予約処理を行っていく方法。
「予約日のアトランダムに予約する」は、予約日の診察開始時間帯から診察終了時間までの間で予約が入っていない時間から患者の希望する時間に予約処理を行っていく方法。
予約を行う際、他の患者の予約時間を調整して予約を行うこともできる。
予約可能日時の算出時に、予約を可能とする時間の調整ができる。患者の希望通りに予約を行っていくと、予約が空いている空白の時間幅が出てくる。普通に考えれば、その空白の時間幅で、予約ができる診察所要時間の患者しか予約をする事はできない。本考案では、この空白の時間を調整することができる。この空白時間帯の前後に既に予約されている患者の予約時間をずらす処理により、空白の時間幅を広げることが可能となり、元の空白時間帯より若干診察所要時間の長い患者の予約を行うことができるようになる。但し、診察当日での予約時間の調整は現実的ではない。
「予約日のアトランダムに予約する」について、診察予約の例を図６０に示す。また、予約変更の例と、予約時間繰り上げの例を図６１に示す。
図６０及び図６１において、予約可能な時間は実線の四角で示す。図６１で示すように、患者が４日の予約を８日に移したとする。そうすると４日に予約時間の空きが発生する。結果、「空き時間」-「予約が入っている時間」-「空き時間」となっている。空き時間に挟まれた患者に対して、予約時間の変更を依頼し、予約時間が繰り上がるとまとまった空き時間になる。
図６２は、予約時間の調整の例を示す図である。図６２に示すように、予約時間の調整を行う例として、既に予約が入っている患者Ａと患者Ｂがある。この患者Ａと患者Ｂの診察時間には１５分間の空白の時間が予約可能となっていた。患者Ｃさんは、この空白の時間に予約を入れたいが、患者Ｃさんの診察所要時間と準備時間は１８分であると診察予約管理システムは算出している。この場合、３分間の時間幅作ることにより患者Ｃさんの予約処理ができることになる。この場合の予約時間の調整は、診察予約管理システムにより、（１）既に予約を入れている患者Ａと患者Ｂの予約時間をそれぞれ１．５分ずらす方法と、（２）既に予約が入っている患者Ｂさんよりあとに予約を入れている患者さんの全てを３分間ずらす方法がある。
診察予約管理システムは、こういった方法の処理により予約時間の調整を行う処理ができる。時間がズレたことは、該当する患者に知らせることが必須となり通知で行う。
医療機関４の予約が入っていない時間（予約ができる時間）の長さが、算出した診察所要時間に５分など若干足りず、前後の予約時間を動かすことで診察所要時間を確保できる場合に行う。この時間調整は、予約時間の変更を行う患者の予定情報を確認し、通院前後に別の予定が入っているなど患者の都合の悪い日時となっていない場合に限り行うようにする。予約時間の調整を行った場合は、予約時間の変更を行った患者に対し、診察予約管理システムからメールなどを用いて新しい予約時間の連絡を行う。また、１０分以上などシステムで予め定めている時間以上、予約時間を動かす場合、変更後の予約時間を仮の予約時間とし、予約時間の変更を連絡する際に、予約時間の変更の許可（了承）を求める。予約時間の変更が了承された場合、仮の予約時間を正式な予約時間とする。予約時間の変更が了承しない場合、変更前の予約時間のままとする。
例えば、予約を入れたい時間の直後の予約の後に、診察所要時間に足りない時間以上の空き時間があるとする。診察所要時間に足りない時間の分だけ次の患者の予約時間の予約時間を遅らせることにより、診察所要時間を確保して予約を行う。
例示では、直後としたが、数人の予約をずらして診察所要時間の確保を行ってもよい。
予約可能日時の算出に用いる、医療機関の予約状況情報の取得は、医療機関４が使用している医療情報システム９にある予約システム９ｄから予約状況を取得もしくは、医療情報共有データベース２にある予約ＤＢ６１から予約状況を取得することにより行われる。
予約可能日時が複数ある場合は、医療機関の端末に患者が通院可能な日時を表示し、表示された中から患者が選択した日時で予約を行うこともできる。診察予約管理システムは、予約する日時が決定し予約が行われると、予約日時と患者の前記診察所要予測時間情報と診察終了時間とを患者の予約情報として予約ＤＢ６１に記録保存する。患者の予定情報と算出した診察所要時間と次回の診察予約をおこなったことで、診察所要時間の算出と患者の予定を加味した診察予約となり、予約の変更が減ることが期待できる。
患者の予定を加味した診察予約であっても、様々な事情で患者の予定が関わり、予約変更をする必要も出てくる。
患者が予約時間の変更を行うと、別の患者の予約が入らない限り、数分から数十分の空白の時間ができてしまう。そこで、前述した他の患者の予約時間を調整して予約を行う手法を応用して、予約の調整を行い、空白の時間の削減を行うこともできる。
空白の時間の削減は、予約変更で空いた時間の前後の時間に予約した患者の予約時間の変更を実施し行う。
説明を加筆
予約に準備時間をとっている
患者を定刻通りに診察開始するために
診察の準備をする時間は医師が任意に設定できる時間であることを特徴
突っ込む場所は、準備時間の範囲にあてはまれば予約ができる
前後の準備時間を合わせた時間（準備時間X2）で埋め込める
通知を行うことができ
通知の内容は予約時間が変わったという内容であることを特徴
この予約システムが空白時間帯に予約を入れるために調整する時間は、診察開始時間のずれる時間であり、
そのずれる時間は、患者にとって影響しない時間であることを特徴とする
予約可能日時の算出にあたり、診察所要予測モデルまたは医師診察所要予測モデルを利用した人工知能により算出した診察所要時間を用いることもできる。人工知能での算出結果を利用することにより、算出する診察所要時間の精度向上が期待できる。

【0160】

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

【0161】

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

【0162】

上記では、医療機関４の診察予約を行う際、患者予定情報を加味して予約できると記載した。患者予定情報を加味して予約した場合、次回の診察予約の日時などを医療機関支援システム１上の医療経済圏ＤＢ２１にある個人情報２２、または、外部のスケジュールを管理するシステムにある患者予定情報に追記することができる。この追記を医療経済圏２４のポータルサイトで追記することができても良い。ポータルサイトの例として出願人考案の特許第６５５８６６９号の図１０に開示の技術などがある。患者は、ポータルサイトで患者のスケジュールを見ることや予約の変更などが行える。患者がポータルサイトで行う予約の変更は、前述した医療機関４が診察予約管理システムを用いて行う実際の予約と同様に、患者の診察所要時間の算出結果と医療機関の予約状況情報と患者予定情報とを利用した２ステップで行う方法で患者が通院可能な日時を絞り込んで行う。

【0163】

従来、医療機関４での予約は、１時間に複数人の予約を受け付け、患者の診察時間が長引きズレ込みが始まると、診察時間のズレ込み時間が拡大し患者の待ち時間が長く待合室での診察待ち患者も増えて待合室が「密」となっていた。
考案のシステムは、診察所要時間に合わせて予約を行っていく。このことは、予約した診察時間のスケジュールに合わせて患者を診察することとなり、正しい診察所要時間を導き出すことにより、患者を待たせることなく、スケジュール通りに診察することができる。しかし、予約時間に合わせて患者が来院しなければ、精度よく診察時間を算出しても、スケジュール通りの診察は行えない問題が残る。
患者を予約時間までに来院させるには、患者に対して来院時間であることを忘れさせずに通知するなどして、患者に予約時間どおりの受診を促す必要があり、本開示のシステムで実現できる。また、病院４ａは、予約時間までに患者が来るのか、患者が遅れる場合どの位の時間遅れるのか、そもそも患者が来院するのか否か、などの情報が分かれば、より病院４ａの運営は円滑に行える。
そこで、患者が医療機関４での予約時間に間に合うように、家を出る移動開始時間が分れば良い。移動開始時間は、患者の居住地住所から病院住所へ向かうルートと、そのルートの移動距離と、来院方法（移動方法）による所要移動時間と到着時間（医療機関４の診察予約時間）により、家を出る時間（通院開始時間）を算出することによりわかる。それぞれを算出して求める方法を以下に示す。
患者の居住地住所を求めるには、医療機関支援システム１は、ネットワークで連携している電子カルテ９ａや医療情報システム９などから患者の住所を取得する処理を行う。また、診察予約時間の取得は、医療経済圏ＤＢ２１上の予約ＤＢ６１に保存されている診察の予約情報から取得できる。
これら取得した情報と、外部システムを利用すれば、患者が家を出る出発時間（通院開始時間）や、移動ルートや、移動所要時間も同時にわかる。
外部システムとは、例えば、ドライブナビ機能のシステムやGoogleマップ（商標）等のインターネットサービス等である。この外部システムは、出発地と到着地が分れば、移動方法による最適なルート、移動方法による所要時間、移動方法による到着時間、到着時間に合わせた出発時間を提供してくれるサービスである。移動経路算出の例を図１０に示す。
医療機関支援システム１は、医療経済圏ＤＢ２１上から出発地（患者居住地取得部が取得した患者宅住所）と、到着地（病院住所）と到着時間（診察予約時間）を外部システムへ提供する処理を行うことで外部システムから移動方法（歩行、車両等）毎による移動所要時間と通院開始時間（患者が家を出る出発時間）を取得することができる。
医療機関支援システム１は、外部から取得した通院開始時間またはその時間の少し前に患者に対して家を出る時間（予測した通院開始時間）であることをスマートスピーカーや携帯端末など患者の所有する端末に対して自動的に通知する処理を行う。ここで言うスマートスピーカーは、第３実施形態に記載する電子機器７３などのことを示す。
この通知に患者が患者の所有する端末等で応答を行い、病院４ａの医療機関支援システム１が応答したことを受信処理が行われると、病院４ａは、患者が来院すると判断の処理を行い、その段階で仮の事前受診受付の処理を行う。
また、医療機関支援システム１は、患者へ予測した通院開始時間であることを通知する機能に加え、患者の持つ端末から、患者の現在地（位置情報）を取得する処理ができる機能を患者現在位置情報取得部として用意する。この患者現在位置情報取得部は、予測した通院開始時間において、患者の現在値の情報を取得する処理を行い、取得した現在値が患者の居住地から離れ、かつ病院４ａの方向に居る場合、既に病院４ａに向けて移動していると判断の処理を行い、通知なしに仮の事前受診受付の処理を行い、診察の受付の処理を行う。患者の現在地の取得は、ＧＰＳやモバイル通信網の電波、wifiの電波、ネットワークＩＰアドレスの情報などを用いて行う。このような情報を利用した位置情報の取得は、GeolocationAPIとして一般に知られており、民間サービスやプログラムなど様々な場所で使用されている。
前記では、予測した通院開始時間での位置としたが、予測した通院開始時間から診察予約時間の間の時間でもよい。さらに、病院４ａを中心に一定距離（半径）に３６０°円形ゾーンを設け、そのゾーンより病院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（登録商標）といった一般にスマートスピーカーと呼ばれる電子機器７３を動作させるために利用している外部ネットワーク上システムのことを示す。
ここまでのスマートスピーカーの説明の中で、「利用者３に対し自然言語で簡単に会話できる機能」とあった。この説明の中にある「自然言語で簡単に会話」というのは、利用者３からの一方的な問いかけや、質問や、依頼に対し、スマートスピーカーからの回答、依頼の反応を「自然言語で簡単に会話」と説明したものであり、決して利用者３とスマートスピーカーとの会話ラリーでは無い。
ここで、スマートスピーカーを展開しているプラットフォーム事業社の事業者システムについて説明する。事業者システムは、クラウド上（外部ネットワーク上）にあるシステムで、一般にスマートスピーカーと呼ばれる電子機器７３と利用者３とが会話をするのに必要なＡＩアシスタントシステムや、利用者３の趣味嗜好などの個人情報などが保存されたＤＢ、スマートスピーカーを利用したサービスを提供するための情報が保存されているシステムとなっている。ＡＩアシスタントシステムとしては、Alexa（登録商標）、Googleアシスタント（商標）、Siri（登録商標）、Clova（登録商標）などが一般に知られている。この事業者システムが用いているＡＩアシスタントシステムは総じて、１問１答といった簡単な会話しか行えず、スマートスピーカー（AIアシスタントシステム）から話しかけることはない。また、スマートスピーカーから利用者３へ何か伝える必要がある場合（例えば、アップデート通知など）はスマートスピーカーのランプが光るなどして利用者３に通知を行う。通知を見た利用者３は、スマートスピーカーに話しかけることで、初めて通知の内容を伝えることができる。
さらに、市場で既に使われている電子機器７３として、スマートデバイスという電子機器７３がある。
スマートデバイスについて簡単に説明する。利用者３の身体にスマートデバイスを直接装着し、体重、体温、血圧、心拍、血糖、血中酸素濃度などの身体の状態を測定する機能を持つ、ネットワークに接続できる機器である。
このスマートデバイスを販売している事業者の中には、外部ネットワーク上にAIシステムを展開している事業者もある。これはスマートデバイスが身体から測定したデータを外部ネットワーク上に設置したサーバーに蓄積し、利用者３の端末を使用してAIシステムに蓄積した測定データを見ることと、AIシステムによる測定データの評価を見ることができる事業者もある。
スマートデバイスの一例としては、衣服状や腕時計状などの形状で体に装着したまま生活が行える、ウェアラブルデバイスなどもある。
本考案では、スマートスピーカーやスマートデバイスの機能では、できないことや、さらに一歩踏み込んだことを考案したものである。

【0175】

本考案を実現するために必要な連携について説明する。
スマートスピーカーを展開するプラットフォーム事業社には、ＡＩアシスタントシステムが稼働している事業者システムを利用するために連携が必要となる。スマートスピーカーを利用するために利用者のＩＤやパスワードはプラットフォーム事業社が保有している。スマートスピーカーを利用するためのＩＤやパスワードと運用状態はそのままプラットフォーム事業社の形態を利用する。プラットフォーム事業社の事業者システムによる動作は、利用者側からウェイクワードを電子機器に「呼びかける」ことで利用開始となる。例えば、Amazonの場合「アレクサ」と「呼びかけ」をする、またGooglの場合「オッケーグーグル」と「呼びかけ」をする、ことでプラットフォーム事業社の事業者システムと接続される。
本考案を利用する場合も同様に「ウェイクワードを呼びかける」、コミュニケーションシステム７４に接続するためのウェイクワードの情報を受信したプラットフォーム事業社の事業者システムは、本考案のコミュニケーションシステム７４へ接続をする又は接続を切り替える。このことにより、利用者３の自宅にあるスマートスピーカーと「コミュニケーションシステム７４」が接続されたことになる。この接続から、会話を行うことができ会話から欲しい情報が取得できる。反対に事業社側から利用者３へ繋ぎコミュニケーションを確立した上で情報を伝える方法は、本考案を利用する場合も同様に「ウェイクワードを呼びかける」、コミュニケーションシステム７４に接続するためのウェイクワードの情報を受信したプラットフォーム事業社の事業者システムは、本考案のコミュニケーションシステム７４へ接続をする又は接続を切り替える。このことにより、利用者３の自宅にあるスマートスピーカーと「コミュニケーションシステム７４」が接続されたことになる。この接続から、会話を行うことができ会話から欲しい情報が取得できる。反対に事業社側から利用者３へ繋ぎコミュニケーションを確立した上で情報を伝える方法は、従来プラットフォーム事業社側から利用者３へ情報を伝える又はコミュニケーションを確立する方法は、自宅にある電子機器に「伝えたい情報がある」という動作メッセージを送り、利用者３がそれに気づいた後に、先ほど説明した「呼びかけ」をすることで電子機器とプラットフォーム事業社の事業者システムと接続が確立し情報の伝達が事業者システムから行われる。その方法に対して、本考案のコミュニケーションシステム７４から利用者３へ情報を伝える場合は、コミュニケーションシステム７４からプラットフォーム事業社を経由しそのまま対象とする利用者３の自宅にある電子機器へ接続される。但し接続されたからといって即座に話しかける訳ではない。自宅内に人が居るかを確認し人が居る場合のみに話しかけ、そこから会話が始まる。部屋に人が居る居ないの確認方法は別で記載している。このように、従来のプラットフォーム事業社のバックアボーンを利用して、利用者３からの会話による情報の取得と利用者３への話しかけから会話による情報の取得を行う本考案のビジネスモデルである。ここで説明したプラットフォーム事業社と本考案とを接続構成を図６３に示す。
本考案では、一般にスマートスピーカーと呼ばれる電子機器７３とその運営事業者の事業者システムとは別に、ネットワーク上のプラットフォーム型医療機関支援システム１に設置した電子機器利用システム７２を接続することにより、以下の基本機能が使用できる。基本機能には、「（１）利用者３との会話により会話の情報を収集する機能」、「（２）収集した会話の情報から利用者３の状態を分析する機能」、「（３）利用者３の状態の分析を行うための会話台本９２を作成する機能」、「（４）分析した情報を利用して利用者３に対し助言を行う機能」、「（５）収集した会話の情報を医療機関４と共有する機能」の５つがある。
本考案は、事業者システムと連携して動作し、この５つの基本機能を利用して、利用者との会話の結果を分析して社会支援・生活支援・健康支援・診療支援等のサービスとして展開することを目的としている。特に、利用者３が電子機器７３の近くいると、電子機器７３側から話しかけることと電子機器７３と利用者３との会話が複数回リターンする会話のラリーが行えることとが、従来プラットフォーム事業社が展開している物とは明確に異なっている点である。

【0176】

ここで、事業者システムを含めた本考案のシステムの構成について説明する。
事業者システムとスマートスピーカー（電子機器７３）との接続例を図６４に示す。図６４に示すように、事業者システムとスマートスピーカーとは、ネットワークを介して接続している。事業者システムと電子機器７３との接続例に本開示の電子機器利用システムを接続した場合の全体図を図１２に示す。図１２に示すように、電子機器７３は、利用者宅に設置され、インターネットなどのネットワークを利用して、ネットワーク上のプラットフォーム型医療機関支援システム１上にある電子機器利用システム７２と接続されている。また、電子機器利用システム７２は、ネットワークを介して事業者システムや、医療経済圏２４に属する機関などと接続している。従来、電子機器７３は、テレビ受像機などの家庭内にある機器と接続している。
さらに、電子機器７３は、電話機やインターフォンの家庭内にある機器と接続できるようにしたインターフェース（コネクタ）を備えた物となっている。
この、電話機やインターフォンを接続できるようにした利用は、電話機からは送信者番号の取得、インターフォンからは来訪者画像の取得を目的とした事で別途記載し説明している。
電子機器７３と家庭内の機器との接続は、無線LANや有線LANなどの家庭内ネットワークを利用して行う機器もある。
図１２に示した全体図のうち、電子機器利用システム７２にフォーカスして説明する。電子機器利用システム７２は、図６５に示すように、１０個のデータベース、１０個のデータベース内にある２１個の情報で構成されている。
さらに、電子機器７３は、電話機やインターフォン、テレビ受像機などの家庭内にある機器と接続している。電子機器７３と家庭内の機器との接続は、無線LANや有線LANなどの家庭内ネットワークを利用して行う機器もある。

【0177】

前記した１０個のデータベース、１０個のデータベース内にある２１個の情報、について説明する。
電子機器利用システム７２は、医療情報共有データベース２の中にある１０個のデータベースを参照して処理を行っている。電子機器利用システム７２による情報の参照先データベースは、（１）利用者音声DB１７１、（２）服薬管理DB１２１、（３）決済関係DB１０１、（４）消耗時期情報DB１１１、（５）会話台本DB９１、（６）防犯ＤＢ１３１、（７）災害時行動ＤＢ１５１、（８）医療経済圏ＤＢ２１、（９）生活環境ＤＢ１１３、（１０）行動情報ＤＢ９３の１０個のデータベースで構成されている。この１０個のデータベースは、医療経済圏ＤＢ２１の中に保存されている情報のうち１つの情報をキーとして、医療経済圏ＤＢ２１とリレーショナルに接続されている１０個のデータベースとなっている。
電子機器利用システム７２が参照している１０個のデータベースに保存している情報のカテゴリは、電子機器７３と利用者３との会話から取得される情報毎の情報や、会話の為に作成した情報や、スマートスピーカーに接続した電子機器から取得した情報毎の情報、の分類に構成されて、
分類された情報は、「会話病状情報，会話生活情報，行動補助情報，会話外出情報，外出中情報，病状会話台本９２ａ，生活会話台本９２ｂ，買物履歴情報，消耗時期情報，服薬状況情報，残薬情報，犯罪者等顔写真情報，犯罪者等の音声情報，犯罪に関連するキーワード情報，発信者番号情報，注意発信者番号情報，災害に合わせた行動情報，避難状況情報，個人情報２２，生活環境情報，行動情報」の２１個の情報がある。
前記した１０個のデータベースに含まれる各データベースの詳細や、前記した２１個の情報の保存先となるデータベースと、２１個の情報の詳細は、順次説明していく。
図２に示した１つの大きな医療情報共有データベース２の中にある１０個のデータベースに、
利用者音声ＤＢ７１がある。この利用者音声ＤＢ７１には、利用者３とスマートスピーカーとの会話から取得した会話による音声の情報が保存され、この情報を利用してサービスを提供する基本のデータベースになる。
電子機器利用システム７２は、電子機器７３から取得した会話による音声の情報を前記利用者音声ＤＢ７１に保存する機能を有している。
１０個のデータベースが構成されている１つの大きなデータベース、いわゆるビッグデータベースである医療情報共有データベース２を利用するのは、医療経済圏２４で事業を行う、「人や医療機関４・企業・事業者」となっており、この利用者３の個人情報２２が医療経済圏データベース（以下、医療経済圏ＤＢ２１）で管理される。
この医療経済圏ＤＢ２１は、医療情報共有データベース２の中にある１０個のデータベースがリレーショナル連携している中核になるマスターデータベースとなっている。
２１個の情報を使用することにより利用者３にヘルスケアサービスを提供する情報主導型の事業となっている。
ここでは、ヘルスケアサービスを行う上で２１個の情報を説明したが、他の事業体いわゆるヘルスケア分野以外の事業でのサービスを行うには、その分野に適合する情報とデータベースを改めて追加することにより、ヘルスケア分野以外の事業でのサービスを行うことが可能となる。

【0178】

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

【0179】

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

【0180】

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

【0181】

１つ目の基本機能は、利用者３との会話により会話の情報を収集する機能である。これは、電子機器７３と利用者３との会話が複数回リターンする会話のラリーにより、利用者３から聞き出したい答えを会話から導きだすことである。また、電子機器７３は、その会話から必要な答えとなる会話の音声情報を抽出し、医療情報共有データベース２にある利用者音声ＤＢ７１に会話病状情報または会話生活情報へ蓄積していく。
上記の説明の中に「必要な答えとなる会話の音声情報を抽出」と記載しているが、この音声情報を抽出する方法は、会話のラリー内容を作成したシナリオ（台本）通りに電子機器７３が会話の進行を行い、利用者３から答えを聞き出すための質問を話した直後に利用者３が話す音声が欲しい必要な答えでありその音声情報となる。この部分の音声情報を抽出した物が、会話病状情報または会話生活情報である。ここでシナリオ（台本）は、これ以降に説明が記載されている。
また、「音声情報を抽出した物が、会話病状情報または会話生活情報である。」と説明している。ここで、音声情報を抽出した物が会話病状情報なのか、会話生活情報であるのか、音声情報を抽出した物がいずれかであるかの判別について説明する。ことらの判別は、会話のラリー内容のシナリオ（台本）を作成する時に、欲しい回答が病状に関係する病状況や病状態の答えならば会話病状情報として抽出するように設定したシナリオを作成し、また、欲しい回答が生活に関係する生活状況の答えならば会話生活情報として抽出するように設定したシナリオを予め作成することで情報内容を分けて取り扱うことができる。
例えば例として、金融事業者がこのシナリオを作成して利用者３から貯蓄方法や資産状況を聞き出したいシナリオを作成した場合は、会話から欲しい答えを抽出した情報を例えば会話貯蓄情報としたり、会話資産情報としたりすればよい。このようにすれば多岐に渡る業態で利用できることになる。
一般にスマートスピーカーと呼ばれる電子機器７３の場合は、利用者３からの質問に対して回答する会話で、すなわち１リターンによる簡単な会話（１問１答の簡単な会話）を行い、その会話の内容をそのまま保存しているものである。

【0182】

ここで、電子機器７３が利用者３との会話から取得した音声情報から文字データとして置換について説明する。
電子機器利用システム７２は、公知の音声認識技術（例えば、事業者システムにあるAIアシスタントシステム）を用いて利用者３と電子機器７３との会話により取得した音声（音声情報）を文字データに置換する。その後、置換した文字データを公知の手法（例えば、形態素解析）を用いて単語単位に分解する。単語単位に分解した文字データの中から、要点を抽出し、会話病状情報または、会話生活情報として利用者音声ＤＢ７１に保存する。
以降、利用者音声ＤＢ７１に保存されている会話病状情報、会話生活情報といった、電子機器７３と利用者３との会話で取得した音声情報は、文字データ化し単語単位まで分解した情報としても扱う。会話病状情報、会話生活情報だけでなく、今後出てくる電子機器７３と利用者３との会話で取得した音声情報も文字データ化し単語単位まで分解した情報としても扱う。
この際、利用者３との会話で取得した音声情報から声量や会話のピッチ、質問に対する回答するまでの間の時間などの数値情報を取得し、文字データ化した音声情報（例えば、文字データ化した会話病状情報や会話生活情報）に紐づけて利用者音声ＤＢ７１に保存する。
音声から単語認識する方法は、既存技術として特許第６７３３８９１号に記載された技術などが一般に知られている。

【0183】

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

【0184】

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

【0185】

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

【0186】

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

【0187】

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

【0188】

利用者３へ話しかけにより会話中から取得した外出内容が会話外出情報として利用者音声ＤＢ７１に保存し蓄積されている。
この会話外出情報には、会話の内容から、外出の所要時間や移動方法や知人との会話や外食などの外出に関連する様々な情報が含まれており、サービスの利用開始の過去から現在までの推移として医療機関４と情報を共有する事もできる。本開示の電子機器利用システム７２には前記会話外出情報に含まれる前記で説明した外出に関する情報を利用することにより、運動した時間、散歩した時間、ウオーキングした時間又は距離、外出した時間、運動量のデータが取れる場合の運動量と、食事の内容、食事の回数、食事の量、メインの食事内容、等の運動量や食事に関する情報を会話で取得することにより、食からは量や内容（傾向）の推移と、運動量の推移、外出回数の推移、外出距離の推移などから、健康状態や老化の分析が行える。
この分析は、利用者３の出の所要時間や移動方法や知人との会話や外食などの外出に関連する様々な情報を過去から現在までの時間推移 により見つけることにより行われる。
会話外出情報から外出内容を取得することにより、利用者３の行動範囲や面会相手などがわかり、利用者３の行動能力や外出傾向などを推定することがきる。本開示の電子機器利用システム７２は、長いスパンで長期に渡って外出内容を保存し続け取得することにより、行動能力や外出傾向の変化などの傾向も把握することができる。行動能力や外出傾向が変化を電子機器利用システム７２が把握した場合は、理由を聞く会話台本９２を作成して利用者３に会話で問うこともできる。

【0189】

ここから、自動車から情報を取得しその情報から状態を判断することについて説明する。
利用者３が外出中に話した内容や外出中での行動は、外出中情報として保存するように会話の台本を作り、利用者音声ＤＢ７１に保存処理し蓄積する。たとえば、車の運転の場合、外出中情報には、車での外出先の情報、運転中に発した言葉、車を急発進または急制動させた回数、衝突被害軽減ブレーキ（AEBS）を発動させた回数、法定速度を著しく逸脱した速度で運転した回数などが含まれる。車が情報を取得するにはどうするか方法を説明する。保険会社当が、車から情報を取得するドライブナビゲーターを販売し車内に設置し情報を取得しているが、このドライブナビゲーターでは利用者３（ドライバー）と会話ができない為に情報を取得することが不可能である。本考案の説明でプラッフォーム事業者のバックボーンを利用し、接続する事ができるコミュニケーションシステム７４の説明をした。出願時現在、車はプラッフォーム事業者が開発した独自のカーナビゲーションシステムが搭載されている。このカーナビゲーションシステムは、本考案で説明している自宅に設置するスマートスピーカーの自動車版であり同じ機能となっている。よって、このカーナビゲーションシステムも、コミュニケーションシステム７４を利用することで接続が可能となる。電子機器利用システム７２から社内にいる利用者３と会話が可能となる。
車の場合、これらの情報は、AIが搭載できるまたは搭載されているカーナビゲーションシステムやモバイル端末と連携することによりAIが使用できるカーナビゲーションシステムにより取得できる。
現行の車両には、前記で説明したプラッフォーム事業者が開発したAndroid Automotive（商標）や、Apple CarPlay（登録商標）といった、AIが搭載されているカーナビゲーションシステムやモバイル端末と連携することができるものとなっており、利用者３（運転者）側からＡＩへの質問や依頼は、車両の無線通信を通じて事業者側のＡＩによる処理が利用者３へ伝わるようになっている。例えば、利用者３が「この近くのレストランを教えて」と質問すると、事業者にあるＡＩが反応しレストラン名を利用者３の運転している車両のディスプレーに表示処理される。この機能を使えば、家庭に設置する電子機器７３と全く同様に、利用者３から音声による情報を入手することは可能である。また、利用者３の音声だけでなく、車両に搭載されたナビゲーションシステムに設置されている各種センサーからの情報も取得することが可能となる。
また、車内にいる利用者３から情報を取得するための台本（シナリオ）を作成し、利用者３と車両に搭載されたナビゲーションシステムを通じて会話をすることで欲しい情報を取得し保存する事ができる。
本開示の電子機器利用システム７２は、取得した外出中情報を組み合わせることにより、車の運転者（利用者３）の体の状態や、運転中の返答遅延などの回答を長い年月かけて取得しその取得した情報から状態の推移を判定することができ、認知症などの早期発見や体の衰えに起因する事故の防止などに役立つ。
認知症の初期段階では、２４時間認知できない時間が発症しているのではない。初期段階では１日のうちに数時間だけ認知できない症状を発症する時間があり、その時間以外は普通に認知できるが、感情が病状発生前とは違うような症状である。このような状態で車の運転中に認知できない時間が始まると大変な事になる。道路を認知できずどこにいるのか認知できない、どこを走っているのか認知できない、どっちに向かって走っているのか認知できない、アクセルやブレーキが認知できない、信号や標識が認知できくなり、運転していた人が突然認知できない状態に入ってしまう人が毎日のように日本中の道路で逆走したり、ブレーキを踏めずに突っ込んでしまう事故が起きています。
数時間だけ認知でいない症状を見つけ出す方法の１つとして、急制動や急発進の回数を取得し利用することもできる。急制動や急発進を行ったという情報は、ドライブレコーダーの内蔵されている加速度ジャイロセンサーにより検知し、ドライブレコーダーとナビゲーションシステムとを連携させることで取得できる。取得方法の例として、テレコム社のDr.ライセンス（登録商標）サービスに使用されるAIによる自動検知技術などを利用する方法がある。
車に乗って運転している状態から認知できない状態が始まってしまい、運転している事自体が車での徘徊に変わってしまい、運がよければ時間経過により何事も無く認知できる時間が自然に訪れ安全に家に帰れることになる。ただ認知症の進行が進むと認知できない時間がだんだん長くなってくる。こういった状況からどうやって守るかが社会貢献になる。プラッフォーム事業者のナビゲーションシステムが搭載されていることから、車両の位置や走行状況の情報は取得でき内容が分る、さらに電子機器利用システム７２を使用して車内ドライバーとの運転中の会話から、突然返答がなくなったり、予期して無いおかしな返答を取得したことで利用者が認知できなくなったと判断する処理はできる。ここまで情報が分っても、ここから事故を抑制することは難しい。ここまでの情報から、家族や後見人へ通知を行う、又は警察や消防へも通知を行いこのような状況を伝えるロジックでの処理ができる。通知する連絡先は患者情報DBに保存されているためその情報を使う。警察や消防は車の位置と進行方向の位置情報から地域の警察や消防を検索することで通知を行う事ができる。
さらに、電子機器利用システム７２は車を止めることができないため、会話というよりも「車を止めろー」と叫ばせる処理を行うことしかできない。
将来、自動運転技術が進化すれば、本考案とのコラボで安全に車を止め家族や救急車、警察を自動で呼ぶことは可能となる。
そういった自動運転技術が進化するまでは、認知できる時間を計測しその時間に相当する家からの運転距離や安全に運転できるエリアを利用者の家族や後見人が設定し、エリア外に車が出た場合や、認知できなくなったと判断した場合は緊急通報する事くらいしか手段は無い。
早期発見は、作成したシナリオで会話を始め、会話中の返答から無意識に発する言葉、いわゆる会話として想定してない言葉の変化を取得することで可能となる。会話が認知できなくなっている。
認知症の患者は、認知症発症後に性格が攻撃的に変化することが多い。そのため、外出中情報の１つである、運転中に発した言葉を利用することにより認知症発症の推定ができ、運転中に攻撃的な言葉をあまり発しなかった運転者が、攻撃的な言葉を言う回数が増えている場合、認知症を疑うことができる。
認知症の疑いや認知機能の低下の推定、運動機能の低下の推定の結果を利用者３本人に伝えたたしても、運転をやめるとは限らない。そこで、本開示の電子機器利用システム７２は、利用者３の家族に対して、認知症を疑いや認知機能の低下の推定、運動機能の低下の推定の結果を通知する処理も行う。
本開示の機能を利用して運転をやめることを促すことにより、「２０１９年４月に東京都豊島区で８０代男性が発生させた車両暴走事故」「２０１２年１０月に静岡県内の東名高速道路上で９０代男性が発生させた車両逆走事件」などの事故や事件が無くなることが期待できる。２０１９年の事故は、運転手７の操作ミスが原因であると推定されており、２０１２年の事件は、認知能力の低下が原因とされている。

【0190】

電子機器利用システム７２から自宅にいる利用者３への話しかけの方法について説明する。
プラットフォーム事業者が運営している事業者システムでは、スマートスピーカーから利用者へ直接に会話で話しかけない。本考案も直接に話しかけない。電子機器７３から利用者３へ話しかけるには、利用者３が自宅に居ない不在時又は誰も居ない時に話しかけても意味が無い。電子機器７３は、利用者３が自宅に居ると判断した時にのみ話しかけることができる。本考案は利用者３へ話しかける以前に居るか居ないかの判定処理を行う。電子機器７３は、利用者３が自宅に居るか居ないか、外出から戻ったかを判定処理する必要がある。この判定方法について説明する。利用者３が所持している携帯端末を使用し、携帯端末が発する無線信号を受信して使った接続することによる状態を判定に利用する。
利用者３が所持している携帯端末と本開示の電子機器７３とが直接の無線信号で接続されている状態（ペアリンク）の時は利用者３が滞在していると電子機器７３は判定処理 し、携帯端末と電子機器７３とが無線信号で接続されていた状態から切断状態へと切り替わった時に利用者３が外出したと電子機器７３は判定処理 し、携帯端末と本開示の電子機器７３とが無線信号で切断されている状態から接続状態へと切り替わった時に利用者３が外出から戻ったと電子機器７３は 判定処理をする。ここで利用者が居るという情報を電子機器利用システム７２へ送信することにより、電子機器利用システム７２は利用者３との会話が設定されていれば会話を始める。
さらに接続（ペアリンク）の方法には、電子機器７３と携帯端末とが他の機器を介さず直接通信するなどの電子機器７３と利用者３が所持している携帯端末との直接的な接続の他に、家庭内ネットワークを利用した間接的な接続によることも有する。利用者３が在宅中か外出中の判断の方法や、利用者３が外出から帰宅したかの判断の方法は、あくまで一例であり、電子機器７３が直接または間接的に取得できる情報で判断処理を行う別な方法でも構わない。また、利用者３が携帯端末を自宅に置き忘れて家を空けてしまった場合に、電子機器利用システム７２から話しかけても返答が無い場合は自宅に居ないと判定処理を行い、一定時間後にもう一度利用者３へ話しかけを行う。

【0191】

５つ目の機能である、収集した会話の情報を医療機関４と共有する機能は、利用者音声ＤＢ７１に保存し蓄積してきた、会話病状情報、会話生活情報などの情報は、本開示の電子機器利用システム７２に接続している医療機関４の端末を使用して電子機器利用システム７２にアクセス（接続）して、利用者音声ＤＢ７１内の情報の参照または取得するにより、医療機関４と情報共有することもできる。
医療機関４と情報共有する情報は、会話台本９２により作成したシナリオで利用者３から聞き出した、食事内容や運動状況や起床時間や就寝時間や体調や体重や体脂肪率や血圧や体温や持病の状態等の情報で、利用者音声ＤＢ７１の会話生活情報または会話病状情報のうち前記会話台本９２に対応した保存先に保存し蓄積されている情報となっている。
医師５ａが、欲しい情報がある場合は、会話台本９２を利用して欲しい情報を取得するための会話シナリオを作成し、会話台本ＤＢに登録することで利用者３と会話が行へ情報を取得することができる。
ここで会話台本９２を利用して会話を行うシナリオ（台本）の作り方を説明する。
欲しい情報があるならば、欲しい情報を取得するための質問をＡＩより提供してもらう。
例えば、利用者３の塩分摂取を医師５ａが知りたい場合。医師５ａが、「夕食メニューから塩分がどれくらい摂取しているか知りたい。」と、ＡＩにキーボードでタイプする。すると、ＡＩが出力するシナリオは、「質問『昨晩、夕食は食べましたか？』「利用者３返答」 質問『一番おいしかったのは何ですか？』「利用者３返答から食べた料理の情報を取得」質問『みそ汁の具は何でしたか？』「利用者３返答からみそ汁を飲んだら具の情報を取得」質問『一番しょっぱかった食べ物派は何でしたか？』「利用者３返答から食べた料理の情報を取得」」、このようなシナリオがＡＩから出力される。さらに付け加えたい会話シナリオをキーボードで入力し台本を仕上げる。さらに取得したい利用者３を設定する。会話をしたい相手を設定する。患者情報ＤＢより電子機器利用システムを利用して医師５ａと契約している利用者のなかから選びだし対象とする利用者３を設定する。例えば、田中さん、佐藤さん、吉田さん、山田さん含め５０人とかを設定する。次に会話を始める時間を設定する。例えば、「毎日夜７時」や「日曜日の夜７時」や「月水金の夜８時」のように設定する。シナリオ作成と、会話相手、会話する時間、会話する曜日や日、これらの設定を作成した会話台本９２に設定する。設定し終わった会話台本９２は、会話台本ＤＢ９１へ登録する。これにより設定した時間と曜日に会話が行われる。
利用者音声ＤＢ７１内の情報を医療機関４と共有することにより、医師５ａは、利用者３の日常の生活状況や血圧などの測定結果の変化状況を見ることができ、診察や治療などに役立てることもできる。
起床時間や就寝時間や体調や体重や体脂肪率や血圧や体温などの数値データの場合は、医療機関４が数値の閾値を個人情報２２に設定・保存しておき会話から取得した情報が、閾値を超えた場合に取得した情報を医療機関４と共有することができる。閾値は、明示された値ではなく、会話生活情報または会話病状情報に過去から現在まで保存した情報の推移取得した情報との間の特異的な差異とすることもできる。特異的な差異の検出は、既存技術として広く利用されている機械学習のうち教師なし学習を用いた異常検知技術を利用する。ここで言う、特異的な差異とは、「正常値内ではあるが、日常の値と乖離している（図１５の矢印で示した値など、血圧の値が普段は、正常値内のうち高値だが、測定値は、正常値内のうち低値など）」「測定値の変化が、右下がりに減少する形で減少していいたが、減少から大幅に減少すぎる値となっている（ダイエット中に体重が、右下がりに減少する形で減少していいたが、右下がりに減少する値が逸脱した値となった）」などのことを示す。
例として、会話生活情報として取得している体重が、右下がりに減少する形で減っていいたが、右下がりに減少する値が基準値より逸脱した値となった例を図１６に示す。図の矢印で示した点の直前までは右肩下がりの減少で減量していた。しかし図の矢印で示した点では、大きく減少する値が基準値より外れた値となった。
利用者３の日常測定値を治療に役立てる例として血圧を例に説明する。自宅で測定した血圧より、医療機関４で測定してもらうと血圧が高くなることがある。このような場合、従来は、医療機関４で測定した通常より高い血圧を用いて治療を行うことが多かった。そこで、日常の血圧を把握するために、血圧手帳を利用して把握する方法が用いられている。
利用者３の日常の測定値が電子カルテ９ａを経由して確認することができる。

【0192】

医療機関４と情報共有の結果、医療機関４が利用者３に対し、前記利用者３の会話生活情報または会話病状情報を利用した情報の取得から利用者３に問題と思われる部分があり利用者３へ改善を促す事を伝えたい場合、伝えたい内容を入力（登録）することで会話台本９２が作成れ、作成した会話台本９２を利用して、利用者３に改善を促す内容の連絡（例えば、体重が増加傾向で運動をしていない場合、運動を行うよう連絡）を行うこともできる。
この連絡は、利用者３が、電子機器７３近傍に居なくても行うことができる。
利用者３が電子機器７３近傍に居ない場合は、利用者３が電子機器７３近傍に居るタイミングで又は利用者３が外出から戻ったと認識できた時点で、利用者３に対して会話で伝える処理をする。また、同改善が複数利用者３又は複数患者までに及ぶ改善を促す内容を伝える連絡の場合も、患者や利用者３の都合に関係なく連絡を伝える処理を行い、電子機器７３が自宅に利用者３が居ると判断する処理をした時に電子機器７３が会話で伝える処理ができることになるが、これは全ての利用者３や患者は非同期で行われる。複数の対象者に対して医師５ａが内容を伝えられることは、遠隔リモート診療ではできないことである。いわゆる医師５ａが利用者３へ一斉に会話で伝える処理をした場合は、利用者３全員が自宅にいれば一斉に同期した形で会話が伝わるが、一部の利用者３が不在の場合は利用者３の帰宅が確認されて会話が伝わるために非同期で伝わることになる。
電子機器７３を利用して、医療機関４が利用者３を呼び出すことを、会話台本９２を作成し電子機器７３を利用して連絡することもできる。
会話台本プログラムで作成した台本を利用し、電子機器７３を用いた、医療従事者５と利用者３との会話の例を図１７に示す。

【0193】

医療機関４と情報を共有する機能は、現在病気を患っていない利用者３の健康管理や、未病の状態を維持することにも役立つ。医療機関４にとっては、健康な利用者３の健康管理と健康維持を行うことにより、病院４ａに無縁であった、健康な利用者３という新しい利用者３（顧客）の開拓につながっていく。
病気は、日常生活から発生する。日常の生活状況や日常から計測できるデータの推移がわかれば、予防や健康管理としての改善を薦めることができる。

【0194】

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

【0195】

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

【0196】

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

【0197】

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

【0198】

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

【0199】

上記の説明においては、外気温と室温との差よる悪環境となっている場合に、電子機器７３が会話で助言を行うとした。しかし、利用者３が外出していれば、利用者宅内が悪環境となっても、害がないため助言を行う必要はない。
また、電子機器システム７２が、悪環境と判断した場合、電子機器７３と接続した家庭内ネットワーク上の機器を利用し適切な生活環境になるように機器を制御する方法もある。 この方法は、会話台本９２を利用し電子機器７３を用いた会話による助言をせずに、適切な生活環境になるように制御することである。
例えば、スマートスピーカーで操作できるエアコンがある場合、エアコンを始動し設定温度を適切な温度にする。

【0200】

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

【0201】

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

【0202】

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

【0203】

（２）購入支援機能
利用者３が買物をする時に行う支援を本開示の電子機器利用システム７２が行う購入支援機能である。
本開示の電子機器利用システム７２には、医療情報共有データベース２上の決済関係ＤＢ１０１に蓄積されている買物履歴情報を利用して電子機器７３を介して利用者３に買い物支援を行う機能を有している。買い物支援を行う購入支援機能は、利用者３が買物をする時に行う支援である。
買物履歴情報とは、電子機器７３を利用した会話により買物をした決済の履歴と、店舗で買物にキャッシュレス決済をした履歴が蓄積されている情報である。この買物履歴情報を利用者が決済を行われる度に蓄積している。
この買物履歴情報は、従来のキャッシュレス決済による店舗にある決済端末から送信される決済情報を利用して、その決済情報に含まれている情報を買物履歴情報に保存している。電子機器７３を利用した会話により買物も同様に店舗にある決済端末から送信される決済情報を利用して作成される。
電子機器利用システム７２は、店舗にある決済端末から送信される決済情報の内容から、決済場所（住所や店舗名や連絡先）と決済時間と決済金額と決済管理番号（伝票番号）を取得して、電子機器利用システム７２はそれぞれを決済場所情報、決済時間情報、決済金額情報、決済管理番号情報として、買物履歴情報に保存し１回の決済毎に蓄積される。
店舗で決済を行った場合の決済情報の中には、購入した内容の情報が無い。買物をした内容が記載されている決済情報は、医療機関決済支援システム１０２のキャッシュレスシステム１０３を利用した決済になる。
電子機器利用システム７２を利用した購入は、医療経済圏２４で利用できるプラットフォーム型医療機関支援システム１にある医療機関決済支援システム１０２のキャッシュレスシステム１０３を利用した決済の決済情報には購入内容が含まれている。電子機器７３との会話により決済を行った時の決済情報から、電子機器利用システム７２は購入内容を取得して、購入内容情報として買物履歴情報に保存し１回の決済毎に蓄積される。
この買物履歴情報に蓄積されている購入内容を利用して利用者３への買物の支援を電子機器利用システム７２が行う。電子機器利用システム７２が行う買物の購入支援は、電子機器７３を介して利用者３との会話で購入支援が行われる。
電子機器利用システム７２を利用した購入とは、利用者３が電子機器７３との会話により、商品を購入する方法で、一般にスマートスピーカーと呼ばれる電子機器７３の機能の１つである。
医療機関決済支援システム１０２のキャッシュレスシステム１０３を利用した購入とは、医療機関４で発行した医療決済媒体や生体情報などを用いて買い物を行う方法のことを示す。
医療決済媒体とは、保険証や診察カード、利用者３が所有する端末などを用いて医療機関４などの決済を行うための決済用端末のことで、医療機関４で保険証や診察カード、利用者３が所要する端末などと紐づけることにより発行されるものとなっている。
本考案では、利用者３への購入支援内容を決める事が重要な機能であり特徴である。

【0204】

電子機器利用システム７２による、買物の支援について説明する。電子機器利用システム７２は、決済関係ＤＢ１０１に蓄積された買物履歴情報から情報を取得し、決済関係ＤＢ１０１に購入制限情報として保存している情報により支援処理が行える。
電子機器利用システム７２は、消費期間を求め利用者３の買物履歴情報に蓄積されている購入内容情報から、消耗品に相当するアイテム（商品名）を取得し、利用者がその消耗品に相当する商品を購入する年月日の情報を取得し、その年月日から消耗品を消費する消費時期がわかる。いわゆる１回目に購入した年月日から２度目に購入した年月日を逆算すると、利用者３が消費し終わるまでの消費時期がわかる。消耗品に相当する商品のそれぞれの消費時期を算出し、電子機器利用システム７２は、消耗時期情報DB１１１にある消耗時期情報に利用者３が購入する消耗品に相当する商品情報と消費時期とを紐づけて保存する。
消耗品の例とし、食べ物ではお米や調味料、牛乳などが代表例として、日用品ではトイレットペーパーや石鹸、ハブラシ、シャンプー、紙おむつなどが代表例としてある。
消耗時期算出システム１１２の構成を図１８に示す。
ここでこの消費時期を利用した利用者３への購入支援機能について説明する。
電子機器利用システム７２は、利用者３へ消耗する商品の消費時期が来る前に 利用者３に消耗品が消費時期を近いづいた事を電子機器７３を使用して利用者３へ話しかけにより通知する。
消費時期は、利用者３の購入した消耗品により それぞれ違うため、
電子機器利用システム７２は、利用者３の消耗品に対する消費時期の情報を医療情報共有データベース２の消耗時期情報ＤＢ１１１の消耗時期情報に保存している消費時期の情報と消耗品の商品情報を取得し、消費時期会話台本に取得した消耗品の商品情報を合わせた会話台本で電子機器７３との会話を利用して通知する。ここでいう通知とは、電子機器７３との会話で知らせるという内容である。また、この消耗品を会話で知らせる商品を、予めメッセージで知らせる内容のテンプレートに消耗品の商品情報を添付して利用者３の形態端末に送信することもできる。また、利用者３の電子機器７３を介して自宅にあるテレビ画面に表示することもできる。
利用者３へ購入機能（利用者３への購入をサポートする機能）として、利用者３が高齢者の場合、生活する上での消耗品で定期的に購入しているが遠方まで移動しないと購入できない物、食生活上の消耗品で高齢者が持ち帰るには重量があり負担となる物、生活上の消耗品で高齢者が持ち帰るには大きくて持ち運びに負担のかかるものを対象としている。
このような消耗する品で大きさ・重量・入荷未定品等に高齢者が持ち歩くには負担となる商品は、消耗時期情報ＤＢ１１１の消耗時期情報にある消耗する商品に負担商品情報としての紐づいている。
重たい物の購入例を記載する。利用者３の購入履歴から白米５Kgを購入していることがわかる。さらにこのお米はだいたい3カ月サイクルで購入していることが購入履歴情報から判明できる。
電子機器利用システム７２は、医療経済圏DB２１から利用者３の年齢と運動量や健康状態や病状から消耗時期情報にある消耗する商品（お米）に負担商品情報の紐づけとなっている場合は、店舗での購入では無く電子機器利用システム７２を通じた購入の判断処理をする。電子機器利用システム７２は、利用者３へお米の購入について会話台本を用いて電子機器７３と会話により購入を行う。
自宅まで届けてもらえるようになる。電子機器７３を利用した購入の例を図１９に示す。

【0205】

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

【0206】

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

【0207】

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

【0208】

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

【0209】

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

【0210】

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

【0211】

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

【0212】

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

【0213】

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

【0214】

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

【0215】

防犯ＤＢ１３１にある犯罪に関連するキーワード情報を取得する処理をし、防犯対応の助言を行う方法について説明する。まず、電子機器利用システム７２に接続された電話機を用いて、電話口の相手の相手が話す音声のデータを取得する処理を行う。取得した相手の音声をキーワードごとに分解する処理しキーワードの詳細情報を取得する。分解する処理及びキーワードの詳細情報を取得は、前述した「電子機器７３が利用者３との会話から取得した音声情報から文字データとして置換」と同様の方法を用いて行う。電子機器利用システム７２は、分解したキーワードの詳細情報が防犯ＤＢ１３１に登録されていないかサーチする処理を行い、サーチの結果、防犯ＤＢ１３１上に分解したキーワードが存在する場合、電子機器利用システム７２は、利用者３に対し、防犯対応を行うための会話台本９２である「内容の防犯台本」を用いて、相手が犯罪に関係している人である可能性が高いことを話しかけで伝え、また、利用者３に起こしてほしい行動を伝える行うための会話台本９２である「行動の防犯台本」を用いて通話を切り替えることを利用者３に話しかけで伝える。電子機器７３は、利用者に切り替えることを伝えた後、通話の途中で相手との通話を利用者３から電子機器７３へ切り替える。利用者から切り替えた通話は、会話台本９２である防犯代替台本のシナリオを用いて電子機器７３が会話を行う。また、取得した電話相手の音声を、犯罪者等の音声情報に登録する処理を行う。
また、電話機に代え、電子機器利用システム７２に接続されたインターフォンでもよい。
さらに、カメラ等で相手の顔の画像が取得できた場合、取得した顔写真を、犯罪者等の顔写真情報に登録する処理を行う。

【0216】

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

【0217】

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

【0218】

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

【0219】

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

【0220】

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

【0221】

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

【0222】

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

【0223】

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

【0224】

本考案のシステムを維持する運営費は必要不可欠である。システムの運営費をシステムで賄うビジネスモデルとして提供できるスタイルが望ましい。医療経済圏を利用するヘルスケア事業以外の企業が、利用者から欲しい情報を電子機器利用システムを利用した会話で情報を取得が行えるサービスを有料で提供するビジネスモデルであることによりシステムの運営が行える。有料化するサービスの内容は、利用者から欲しい情報を取得するために必要な台本を作る会話台本作成プログラムの利用をサービスとして有料で提供する。この会話台本作成プログラムで作成した台本を保存する領域と、利用者との会話から取得した情報を保存する領域とのネットワーク上の保存領域を提供する。
さらに、作成した台本を利用して電子機器と利用者との会話が行える環境を利用できるサービスとして有料で提供する。
例えば、選挙中に有権者である利用者にアンケートを行うビジネスの利用が見込めたり、
文書メールの代わりに音声会話でメッセージのやり取りを行うシステムや、テレビショッピングで注文を電話で受け付けている電話応答の代替方法として考えられる。
このサービスの申込は、ＷＥＢを利用しサービス申込ページに企業からの申込を受けるようにする。
有料サービスの支払いは既存技術により支払いを行うのでここでは記載はしない。既存技術は、例としてキャッシュレスやＥＣサイトやネット決済や出願人考案の特開２０２１－１１３９２７などである。出願人考案の特開２０２１－１１３９２７を利用する理由は、現在の法定通貨から次世代のデジタル通貨に代わっても、利用方法を変えずそのまま利用できるメリットがある。
この契約により、提供を受ける側と提供する側がｗｉｎｗｉｎの関係になる。
この有料サービスは、収益が得られるビジネスモデルである。

【0225】

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

【0226】

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

【0227】

本開示の医療機関決済支援システム１０２は、医療経済圏DB２１，患者情報ＤＢ１６１，決済関係ＤＢの各データベース内の情報を利用している。医療経済圏DB２１には、個人情報２２、認証情報、決済場所情報、遺言者遺言情報、信託情報、後見人情報が保存されている。患者情報ＤＢ１６１には、連絡先情報、捜索情報が保存されている。決済関係ＤＢ１０１には、買物履歴情報、決済手段情報、購入制限情報、購入地域制限情報が保存されている。各情報の説明は、 後に記載する。

【0228】

第４実施形態のデータベース構成を図２３に示す。また、本開示の医療機関決済支援システムのシステム構成図を図２４に示す。

【0229】

医療機関決済支援システム１０２を利用するための医療決済口座１０４の開設について説明する。
医療決済口座１０４の開設は、受付にある端末上で行い、ワンクリックで行う。このワンクリックの内部処理は、受付端末で開設手続きをすると医療機関決済支援システム１０２内で患者の医療決済口座１０４を作成し、医療経済圏DB２１に患者の個人情報２２として保存してある、氏名・生年月日・住所・電話・性別・診察券番号・健康保険証番号など開設に必要な情報を、医療決済口座１０４に紐づける。医療決済口座１０４を開設時点の状態だと、決済に必要な情報がないため、医療機関が患者に渡し、患者が決済使用する医療決済媒体を識別するためのユニークな管理番号の情報を医療決済口座１０４に紐づける。医療決済媒体の詳細は後記する。
医療決済口座１０４の作成方法の例を図２５に示す。
医療決済口座１０４へ入金する手段の情報として、銀行口座やクレジットカード・暗号通貨・デジタル通貨・ポストペイ決済・プリベイド決済などの決済手段情報も医療経済圏ＤＢ２１にある決済関係ＤＢ１０１に登録する。さらに、患者の指紋や顔といった生体情報を認証情報として決済関係ＤＢ１６１に保存する。決済手段情報の登録や生体情報の保存は、患者の端末から設定する。この設定は、医療経済圏２４のポータルサイトを利用することで利用者により設定することができても良い。ポータルサイトの例として出願人考案の特許第６５５８６６９号の図１０に開示の技術がある。

【0230】

ここから医療機関決済支援システム１０２の概要や内容について説明する。
医療機関決済支援システム１０２は、診察料や調剤料など患者が医療機関４へ支払う費用のやり取りを患者の医療決済口座１０４と医療機関の医療決済口座１０４との間で行うシステムとなっている。お金のやり取りは、患者が医療機関４での支払い時に、医療機関４の決済用端末が患者の持つ医療決済媒体の情報を読み込むことで行う。この際、患者は本人確認を行うための情報として、患者の生体情報を追加で提示する。
医療機関４の決済用端末は、患者の持つ医療決済媒体の情報と患者の生体情報とを読み込むと、医療機関決済支援システム１０２に対し、読み込んだ情報をもとに本人確認と決済を依頼する。医療機関決済支援システム１０２が行う本人確認は、患者情報ＤＢ１６１に保存してある患者の生体情報と取得した生体情報とが同一であるかの比較により行う。本人確認が終わると、医療機関決済支援システム１０２は、医療機関４の決済用端末から送られてきた決済依頼の内容に基づき、患者の医療決済口座１０４から医療機関４の医療決済口座１０４へお金を移動するという振替情報を記録する。振替情報に記録される情報は、支払いを行った患者の医療決済口座１０４の情報と支払い先の医療機関４の医療決済口座１０４の情報と支払いにより発生する金額移動情報などの支払いの明細情報が記録する処理が行われる。
患者が上記の方法で決済を行うには、患者の医療決済口座１０４に前払金として事前にお金を入金しておく必要がある。前払金の説明は後述する。
上記では、患者が医療機関４への支払う費用として、診察料や調剤料を例として記載したが、病院４ａにおける医科報酬、歯科４ｆにおける歯科報酬、薬局４ｂにおける調剤報酬、薬価や医療材料費など、患者が医療機関４に支払うすべての費用のことを示す。
医療機関決済支援システム１０２は、患者の診療で利用した一連の医療機関４の決済をまとめて行うこともできる。患者は、患者が診療で利用した一連の医療機関４の中から、実際に決済を行う医療機関４を選択する。まとめて行う決済は、患者が選択した医療機関４の決済用端末に医療決済媒体と生体情報とを読み込ませることで行う。選んだ医療機関４以外への決済は、医療機関決済支援システム１０２を経由して他の医療機関４に患者３の医療決済口座１０４の情報を送ることにより行う。

【0231】

決済をまとめて行うことの例を記載する。
普通、医療機関４に診療に行くと診察内容から薬を処方される。院外薬局の場合は、医師から院外薬局用の処方箋を渡される。医療機関４の会計での会計待ちになる。やっと診察費の支払いを済ませ、処方箋を持って院外薬局（調剤薬局）へ向かう。院外薬局で処方されるまで待ち、やっと薬を渡され支払いを済ませて帰宅する。このような流れが通常となっている。これを効率よく行うには、医療機関４の医師の診察が終わり、処方箋を渡されたならば、会計で会計待ちをせずにそのまま院外薬局へ向かい、処方薬を渡され薬の支払い時に医療機関での診療費も含めて同時に１回にまとめて支払うことにより待ち時間を効率的に使えるようになる。さらに、数年前より医療機関で処方箋が出ると掛かりつけの調剤薬局へ処方箋を送ってくれるサービスを行っている。医療機関４での診察が終わってそのまま調剤薬局へ行けば薬を受け取って支払いを済ますだけで「待つ」という無駄な時間が無くなり効率よく過ごせる。

【0232】

ここから患者が医療機関決済支援システム１０２を利用するメリットについて説明する。
特に集中力が欠落しはじめた症状のある認知症や依存症や高齢者にとって、長い間座って待つという忍耐力が欠落しているため精神的にできない。そして苦痛だと体や言動で表現する。歩き回ったり声を出したり意識を紛らわせる。そうなると同行している家族やケアヘルパーにとっても苦痛となる。本考案の医療機関決済支援システム１０２により、一連の支払いをまとめて１回で行うことで、医療機関４での会計待ちを無くせる。そのため、ここで記載した病状の患者さんや患者に同行する家族やケアヘルパーにとっても苦痛なく時間を無駄にせず効率的に通院が行えるメリットがある。

【0233】

ここから医療機関決済支援システム１０２を医療機関が採用する利用するメリットについて説明する。
医療機関４が、決済支援システム１０２を利用するメリットとしては、医療機関４の窓口で現金を扱う必要が無くなるということからのメリットがある。医療機関４は、受付で現金を扱わなくなることにより、「医療機関での会計作業がなくなる」「医療機関の事務担当者が行う、患者から受け取ったお金の銀行への入金やおつりの用意といった事務仕事を行う必要がなくなる」といった事務作業の削減というメリットを受けることができる。長い会計待ちによる苦情もなくなります。

【0234】

医療機関決済支援システム１０２の応用について説明する。
医療機関決済支援システム１０２は、患者が金融機関やクレジットカード会社等の決済手段の作成申請の代行を行うことができる。金融機関やクレジットカード会社等の決済媒体の作成を申請する時に、基礎情報として個人の諸情報（氏名・生年月日・住所・電話・性別）に、就業先情報や金融機関口座情報と場合によっては氏名・住所を証明する公的機関の情報も合わせて申請し、審査を通るとクレジットカード会社等の決済媒体を所有することができる仕組みになっている。
この申請に必要な情報の全ては医療機関４に備わっているため、医療機関にある情報で決済媒体の申請が行える。
患者が、金融機関やクレジットカード会社等の決済媒体の作成を申請する際、患者は、医療経済圏２４のポータルサイトから医療機関決済支援システム１０２に対し作成申請の代行依頼を行う。作成申請を受けた医療機関決済支援システム１０２は、患者情報ＤＢ１６１に保存されている個人情報２２を参照する。医療機関決済支援システム１０２は、患者に代わり金融機関やクレジットカード会社に対し参照した情報を利用して、金融機関やクレジットカード会社等の決済媒体の作成申請を行う。すなわち、患者は、クレジットカード等を新規に作成する時に申請用紙に記載していた個人情報２２に相当する箇所を省略して、申請することができる。患者は、クレジットカード等を新規に作成する際の申請を医療機関決済支援システムに申請することになる。この申請の接続図を図７２に示す。

【0235】

医療機関４が患者に渡す医療決済媒体について説明する。
この医療決済媒体は、医療機関支援システム１０２を利用した決済の際に利用する決済用の媒体のことで、この媒体にはユニークな管理番号が付与されている。医療決済媒体には、決済用カードや決済に用いるコード情報が表示できる患者の端末の2種類がある。
この媒体にあるユニークな管理番号は、医療決済口座１０４の口座番号として紐づけている。
医療機関４の受付窓口で、患者情報DB１６１内にある患者情報を利用して、患者に渡される決済媒体にあるユニークな管理番号と患者情報とを紐づけた情報を口座情報として、医療決済口座１０４にある患者の口座番号の情報に保存することで、患者と媒体のユニークな管理番号と医療決済口座１０４の患者の口座番号とが繋がった形になり、決済媒体を窓口で患者に渡すことができる。
決済用カードとは、磁気カードや接触型ＩＣカード、非接触ＩＣカードのように、従来からあるカード型の決済手段と同様のカードとなっている。決済用カードの発行は、医療機関４でカードを渡 されて利用できるようになる。
この医療決済媒体は、医療機関４での決済だけでなく、医療機関４の受付処理にも利用できる。いわゆる従来の診察カードになる。クレジットカードや図書館カードを診察カードとして、医療機関４の受付処理に利用する方法は、第５実施形態に記載の方法となっている。第５実施形態の考案を利用することで本考案の決済媒体を診察カードとして利用することができる。
また、本出願人の特願２０２１―１１３９２７に開示の手法を利用することにより、医療決済媒体なしで決済を行えるようになる。

【0236】

医療決済口座１０４へ事前に入金する前払金について説明を行う。
患者が、医療機関４で作成した医療決済媒体を利用して決済を行うには、医療決済口座１０４へ事前にお金を入金しておく前払金が必要である。初回前払金の入金は、決済媒体を渡された病院４ａの窓口で行う。２回目以降の前払金の入金方法は、病院設置の端末や病院４ａの窓口での入金、銀行振り込みによる入金、決済手段情報に記録された決済手段からの振替による入金などの方法で行う。この振替は既存技術で行われている方法により行い、「一定期間毎に自動で入金する。」「前払金の残額が設定した下限を下回ったら入金する」といった自動的に振替を行う方法でも行える。
利用者３の医療決済口座１０４に前払金の残額がない場合、一時的に決済媒体及び医療決済口座１０４を無効にする機能があってもよい。

【0237】

ここでは、医療経済圏２４を利用している医療機関４が医療決済口座を利用する例について説明する。
医療機関４は、「医療用部材や薬品などの購入など医療経済圏２４を利用している医療関係企業との取引」に金融機関を利用して支払いを行っている。この場合、医療関係企業が医療決済口座を開設することで前記の支払い内容の受取に利用することができる。
さらに、医療機関４は、「健保組合や国保からの診療費や調剤報酬費の入金」に金融機関を利用して入金をされている。この場合にも、健保組合や国保が医療決済口座を開設することで前記の支払いや受取に利用することができる。
金融機関を利用してお金の移動（銀行での振り込み・振替など）の手数料は回数や移動金額が多ければ手数料は増える。この手数料を削減するために医療決済口座を利用するメリットがある。金融機関は、移動するお金は都度全額を移動している。それに対して医療決済口座では、移動元から移動先への出入金の情報すなわち取引の情報が容易に取得でき医療決済口座１０４に保存され蓄積されていくことになる。この蓄積された取引の情報をある時又はある期間のタイミングで取得し取引の内容の収支計算をすることにより、その期間における利用者の医療決済口座への入出金の差分が判明し、この期間での入出金した金額の差分の金額を移動することで、従来の金融機関を利用したその都度の移動回数は減り、且つその都度の移動に伴う手数料は減る。さらに、医療決済口座１０４に保存されている取引の情報が蓄積されることにより、医療機関や企業では取引の履歴を容易に取得でき電子帳簿としての作成が簡略し、税申告にも簡単に対応できるようになる。
よって、従来の金融機関を使用した時よりも簡易的になり且つ省力化ができるため、経理に係る医療事務従事者の省人化や人件費の削減にもつながっていくメリットがある。

【0238】

ここまで、医療機関決済支援システム１０２は、医療機関4が関わるお金のやり取りを前程に説明してきた。
医療機関決済支援システム１０２を利用した決済は、市中でも行うことができる。医療決済媒体は、従来からあるカード型の決済媒体ード決済と同様のため、はプリペイド方式のためそのまま市中の店舗など病院外での決済に利用できる。決済は、市中の店舗の決済端末に決済媒体を提示することにより行われ、前払金から、市中の店舗の口座に対してお金を移動することにより行う。このお金の移動は、振替情報として患者（利用者３）の医療決済口座１０４から市中の店舗の口座へお金を移動するという振替情報を記録する。実際のお金の移動は、医療決済口座１０４側で一時的に決済された金額をプールし、指定期日にまとめて市中の店舗の口座に送るという、従来の決済手段で行われている方法で送ることもできる。市中の店舗の口座は、手数料削減の点から医療決済口座１０４であることが望ましいが、銀行口座といった既存の金融機関口座でもよい。市中の店舗の口座が、既存の金融機関口座の場合の送金方法は、医療決済口座１０４が金融機関の口座に従来からある銀行振り込みを行うことで行われる。
決済媒体を利用している人の、前払金や追加でチャージするお金は、前述の方法に加え、従来のプリベイド方式の決済で行っている市中の店舗で行う入金の方法を利用して行い、医療決済口座１０４への入金が行われる。入金時に利用する決済媒体にあるユニークな番号に紐づいている医療決済口座１０４の患者の口座には入金された情報が保存される。

【0239】

ここでは、この決済に認知症等の病気を持った人への安全な決済のサポートを行うセキュリティ機能について説明する。
医療機関決済支援システム１０２は、市中での決済時の資金管理と、決済位置により決済制限を行うことができる、認知症等の病気を持った人への安全な決済のサポートを行うセキュリティ機能がある。
捜索情報とは、決済カードの利用者が、サポートが決済時の安全なサポートを必要な人、すなわち認知症などの病気を患わっている人を対象とし、安全な決済のサポートを必要とする人と、必要としない人のいずれかの設定をする情報となっている。ここの設定によりこれ以降の説明である様々な設定により安全な決済を行うサポートをするものである。サポートを要らない設定では以下の様々な設定が不要なため、ここから先はサポートが必要と設定された場合、すなわち病気を患わっている人が決済カードを利用する場合について説明を進めて行く。

【0240】

購入制限情報とは、商品の購入を制限また禁止している事を示す情報である。利用者３が病状による買物依存により商品購入の金額に制限をかける情報の設定である。また、この設定で利用者３が購入を使用した場合に、利用者３の買物依存内容を見て制限する内容を変えるかの判断に利用する決済場所と金額の通知をする。この通知は、利用者の家族や後見人を対象としているが、利用者３がどこにいるかを知る情報にもなっている。

【0241】

購入地域制限情報は、利用者による決済ができない地域すなわち商品の購入ができない制限をかける地域を設定した情報である。
決済制限を地域に設定する理由は、利用者３が徘徊又は散歩しながら遠くに行ってしまった、いわゆるここまで遠くに行ってしまうと帰ってこられなくなる地域を設定している。もし設定したこの地域から帰ってこられた場合は、決済が出できる地域として範囲を広げ直す。すなわち自宅から少し遠くに範囲を広げ再設定を行うことにより、徘徊から帰ってこられないエリアを見つけ出し、このエリアに入って決済したら散歩では無く迎えに行かなければいけないと判断する地域である。購入ができる地域は徘徊よりもむしろ散歩で自宅に帰ってこられる地域である。一方、決済ができる地域内であっても、帰ってこられない場合は、決済できる地域を狭め、すなわち自宅から近くに狭め再設定することでも、徘徊から帰ってこられないエリアを見つけ出す。この制限地域に入り決済を行った場合は、連絡先に「制限エリアの決済場所に居るため迎えに行く準備が必要です。」という旨の通知をする。制限のかかってない散歩のエリアで決済した場合は、連絡先に「散歩中に決済場所で買物をした。」という旨の通知をする。
また、メッセージの通知先である連絡先の設定について説明する。
購入制限情報の設定や、購入地域制限情報の設定によりメッセージが通知される連絡先は患者の連絡先情報の登録先に通知される。この患者の連絡先への通知は、患者情報DB１６１に設定し登録されている情報を医療機関決済支援システム１０２が取得し通知の連絡先として利用する。この連絡先情報の設定は、利用者３や家族や後見人など関係者により、それぞれ所有している端末で患者情報DB１６１へ設定することで登録される。設定される通知先は、家族や後見人や信託契約者等の身内とその関係者に設定することが望ましい。

【0242】

認知症とは、物忘れや記憶が欠落するだけの病状だけではない。感情が急変してしまうこともある。例えば、訳も分からず急に怒鳴りはじめたり、身内（妻や子供達）が誰だか分からなくなったり、身内の人間を認知できずお客（第三者）が家にいると誤認知したり、お客に怒鳴り、お客に危害を加えたり、大切な物や現金が盗まれたと錯覚したり、逆に大切な物や現金が盗まれないように家の中に隠し、さらに隠した事さえ忘れてしまい身内が盗んだと身内を疑うようになったりする人もいる。
こういった事が徘徊中に発生し、見ず知らずの人に危害を加えたり、他人の所有物を壊したり、他人が自分の現金を奪ったと抽象し暴力を与えたりしてしまう事から、徘徊中の移動先を家族や後見人に早期に通知するために決済を通して場所を知ることができれば迎えにいくことができる。それならば、病状者を外に出ないようにしてしまえばいい、そうすると徘徊という運動が無くなり体力が落ち不健康になり、更に認知症の病状が悪くなるため、外に安全に出られる環境を作る事は良いことである。
病院４ａで決済媒体を作成しており、利用者３（患者）の情報を医療機関４がもつ医療情報システム９から取得できるため、認知症などの理由により徘徊や物忘れの症状がある利用者３に対して適切な支援を行う付加機能として、捜索情報や購入制限情報や購入地域制限情報の設定により、利用者３とその家族や後見人に対して適切なサポート支援を行うことができる。

【0243】

従来様々なキャッシュレス決済を行う事業者が決済媒体を世にだしているが、病状者の利用申請は許可されないし、病状の情報を事業者は持っていない。また病状のある利用者３への配慮をした決済を行う決済事業者は無かった。
たとえば、認知症により衝動買いや買い物依存の症状がでることが多い人もいる。この場合、買い物をする欲求を楽しむ症状であり、買った商品には興味がない場合もある。また、通信販売で購入の欲求を楽しむ症状の場合、認知症患者は、自分宛に届いた荷物には興味が無く支払いや返品に家族が苦労する場合や、市中での買い物以上に通販での買物に満足する場合もある。このような症状がでている患者が、買い物を行うと購入店や家族に迷惑がかかるため、購入の制御を行う、または、特定地域内でしか購入できないようするといった対策もできるようになっている。また、購入を行った場合において、購入した店の情報が、家族や後見人など予め連絡先情報として設定されている連絡先に連絡されるので、必要ない商品の購入を行っても迅速に対応がおこなえる。このように従来には存在しない医療社会目線での決済が行える医療機関決済支援システム１０２のプラットフォーム基盤を社会に取り入れることがとても重要である。

【0244】

医療機関決済支援システム１０２は、安全に買い物を行うために、決済端末の住所情報と決済端末を設置している住所とがほぼ同一地点でなければ、決済の制限を行う。
決済端末の住所情報は、店舗での決済時に決済端末から送られてくる決済情報に記載されている決済場所（住所や店舗名）の情報を利用する。
決済支援システム１０２は、医療経済圏ＤＢ２１に決済場所情報として登録してある決済端末の設置している住所から緯度経度などの位置情報を算出し、医療経済圏ＤＢ２１に決済場所位置情報として、決済場所情報に紐づけて保存する。
医療機関決済支援システム１０２は、決済時に決済端末から送られてくる決済端末の住所情報と、決済端末の設置した場所の住所から算出した位置情報とがほぼ同一であるかの判定を医療機関決済支援システム１０２が行い、ほぼ同一地点であると判定されれば、決済が許可される。
位置情報の取得例を図２６に示し、決済端末を設置した住所位置情報データベースのシステム図を図２７に示す。

【0245】

医療機関決済支援システム１０２は、決済端末の住所情報と、決済端末の設置した場所の住所から算出した位置情報とがほぼ同一地点であれば決済ができるようにした条件を設定した。医療機関決済支援システム１０２は、利用者３の購入金額を抑制するために、決済関係ＤＢ１０１にある購入制限情報に、事業者（販売店）や業種ごとに購入できる上限金額を設定 をしておくことで、決済時に購入金額の抑制をかける。
この設定は、患者（利用者３）の持つ端末で行うことができる。利用制限情報の設定に使用する事業者リストは、決済端末の設置した場所の住所が保存してある決済場所情報を使用して事業社を選択して行う。
衝動買いや買い物依存を抑制するために、事業社ごとに購入品目の制限をかける。また、事業者や業種ごとの設定には、購入できる品目だけを設定する制限の仕方もある。
こういった金額上限や購入品目を設定する理由は、この決済媒体は医療機関で発行しているために色々な病状を持っている場合もある。医療機関で発行する目的の1つには、病状の1つであり依存症や認知症患者が安全に決済や生活がおくれるようにする狙いがある。とくに、依存症などを発症している精神的な疾患のある患者には買物依存に対する懸念がある。依存症の内容も様々であり一例を紹介すると、とにかく買物をすることで欲求を満たす買物依存や、店員からの勧めや持ち上げ言葉により特別な優越感にひたる自己満足からの買物依存や、何かのきっかけから同じ物ばかりを何度も購入してしまう依存や、甘い物ばかりを購入する買物依存と、このような内容以外にも人により違った買物依存がある。
こういった人達の生活を少しでも守る為に設定する内容である。
設定の例は、事業社で購入する品目を設定することで購入品の抑制を行う。例えば、Ａ事業社では「食料品のみ」、Ｂ事業社では「生活雑貨のみ」のように設定する。
ここで言う、同一の事業を営む業種とは、小売業など広い業種だけでなく、百貨店，スーパーマーケット，コンビニエンスストアといった細かい業種で設定することもできる。

【0246】

医療機関決済支援システム１０２は、利用者３が生活圏外での商品の購入を抑制するために、決済関係ＤＢ１０１にある購入地域制限情報に、利用者３が決済できる範囲を設定 をしておくことで、生活圏外での商品の購入の抑制をかける。
この設定は、患者（利用者３）や家族や後継人が持つ端末で行うことができる。
購入地域制限情報を設定することにより、家族や後見人などの関係者が認知症患者を見守ることができる。

【0247】

ここで、認知症や痴呆症の患者による徘徊対策のロジック（処理）について説明する。
認知症や痴呆症の患者が（徘徊のエリア）を設定する必要がある。家から出かけて行ったものの、どこまで行ったのかわからない。また帰ってこられる場合もある。徘徊と言葉で言っても、どこからどこまでの範囲が徘徊範囲なのかグレーゾーンである。また、家から出かけて行ったものの、きちんと家に帰ってこられる範囲がどこまでなのか、また、帰ってこられなくなるラインは何処のラインを超えると帰ってこられなくなるのかが全く見当もつかないもの（グレー）である。どこに居るか分っても迎えに行って良いのか、それとも帰ってこられるのかわからない。
徘徊のエリアの設定方法は２つの方法がある。１つ目の方法（ロジック）は、自宅を中心に円を設定する、半径に自宅からの距離を設定した円で描かれる範囲を設定する方法。２つ目は、自宅を中心に徘徊していく方向を推測して、徘徊していく住所、すなわち町名や番地で徘徊する方向にある町名や番地を指定していき領域とする方法。認知症の場合は後者の方法が望ましいかもしれない。理由は、認知症の症状のある人は利き腕の反対の方向に行く性質があるため、その方向に進む町名と番地をしてした方が良い。反対に円で指定する場言いは何処に行ってしまうか予想ができない場合となる。依存症の人は、買物が沢山できそうなエリアや、美味しい食べ物の飲食店がある所などを住所で指定する後者の方法が良い。
認知症の場合、帰ってこられる範囲のエリア（安全なエリア）と、帰ってこられるかどうか不明なグレーゾーンと、グレーゾーンよりさらに遠く帰っては来られない必ず迎えに行かなければならないエリア（要支援エリア）の設定が必要になる。
１つ目の方法の設定例を図６６に示す。
図６６では、２つの同心円の中心を利用者３の自宅とする。内側の円より自宅側の地域は、帰ってこられる範囲のエリア「安全なエリア」として設定する。外側の円より外側の地域は、帰っては来られない必ず迎えに行かなければならないエリア「要支援エリア」として設定する。内側と外側の円の挟まれた地域（「安全なエリア」と「要支援エリア」とに挟まれた地域）がグレーゾーンとなる。
２つ目の方法の設定例を図６７に示す。図６７では、縦線部を帰ってこられる範囲のエリア「安全なエリア」として設定し、横線部を帰っては来られない必ず迎えに行かなければならないエリア「要支援エリア」として設定する。「安全なエリア」と「要支援エリア」とに挟まれた地域が１つ目の方法と同様にグレーゾーンとなる。
利用者が決済をすると、店舗での決済時に決済端末から送られてくる決済情報の内容から決済場所（住所や店舗名）と決済時間が判明する。
医療機関決済支援システム１０２は、医療経済圏ＤＢ２１にある決済場所情報に登録している情報の中から、決済場所の住所情報と同一の決済済端末の設置場所の住所の情報を取得し、取得した決済端末の設置場所の住所に紐づいている決済端末の決済場所位置情報を取得する。
この位置情報を、徘徊のエリアの地図に利用者の現在位置として表示することで、利用者の現在位置を可視化する。この地図に表示させた情報及び、決済時間を利用者現在値情報として医療経済圏ＤＢ２１に保存する。
この利用者現在値情報と、購入地域制限情報の設定の設定内容により、医療機関決済支援システム１０２から送られる通知されるメッセージの内容が変わる。
ここではっきりさせないといけない内容がある。認知症や健忘症や依存症など、病気には初期段階から重度の段階までと大きな見えない幅がある。ここで分かり易く説明するために認知症を例に説明する。認知症の初期段階では、２４時間認知できない時間が発症しているのではない、１日のうちに数時間だけ認知できない症状を発症する時間があり、その時間以外は普通に認知できるが、感情が病状発生前とは違うような症状である。そのため認知できない時間が始まってしまい徘徊が始まってしまう。徘徊が始まっても時間経過により認知できる時間が自然に訪れることになる。また反対の場合もある、散歩に出たつもりでいるが、散歩の途中で認知できない状態が始まり歩いてきた道順や何処にいるか認知できずに帰れなくなる。ただ認知症の進行が進むと認知できない時間がだんだん長くなる。その歩いてきた時間に相当する家からの距離やエリアを利用者の家族や後見人が設定する事の内容が前記で説明した内容である。さらに、認知症患者は時計を持っていない、家に帰ろうとする行為が何処で、どの時間に起きるのかグレー（不明）である。家を出てどれくらいの時間、どれくらい距離で認知できなくなり身体的に動けなくなってしまうのかわからない。
これらを解決するための手段として、決済した場所が分かることにより、利用者３が今どこにいるかもわかる。この決済した時の決済情報を蓄積していくことで 認知症や健忘症や依存症の徘徊に関しての傾向が分ってくる。
この決済手段には、決済方法についていくつかの設定ができるようになっている。さらにその設定による通知機能により、危険な徘徊から患者を守ることができる。
また、医療機関決済支援システム１０２は、利用者３が買い物を行い、自力で自宅に帰ってこられたという、利用者３の徘徊や散歩の結果を利用し蓄積することにより、より安全な徘徊エリアの設定を行える。この設定は、利用者３の徘徊や散歩の結果により何度でも設定しなおすことができる。例えば、グレーゾーンまで徘徊や散歩を行い、常に自宅へ帰ってこられるようになった場合は、自宅からの距離が長くなるよう帰ってこられる範囲のエリア「安全なエリア」を再設定する。一方、帰ってこられる範囲のエリア（安全なエリア）でも自宅まで帰ってこられない場合は、自宅からの距離が短くなるよう帰ってこられる範囲のエリア「安全なエリア」を再設定する。

【0248】

以前にも通知について軽く触れたが、ここから設定した状況によりメッセージが送られる通知機能について説明する。
この予め患者情報DB１６１に連絡先情報として登録した先へメッセージを送る通知機能は、決済関係ＤＢ１０１に 購入地域制限情報の設定や購入制限情報の設定が行われている場合に、医療機関決済支援システム１０２が通知を送る処理するものである。
従来、店舗で決済媒体を使用して決済を行うと、決済した内容を情報化した決済情報が決済事業社へ送信される。本考案も同様に、医療機関で発行された医療機関決済支援システム１０２を利用する専用の決済媒体を使用して決済を行った時も、従来と同じ決済情報が医療機関決済支援システム１０２に送られてくる。これは従来の仕組みや技術をそのまま使用しているためである。この決済情報の内容から取得できる情報には、住所情報（決済場所の住所や店舗の連絡先電話番号）や決済金額情報がある。この情報を利用して医療機関決済支援システム１０２が利用する。

【0249】

「今ここにいる」メッセージの通知について説明する。
購入制限情報の設定がされている場合、医療経済圏ＤＢ２１内の利用者現在値情報及び決済情報は、利用者が「今ここにいる」情報として扱う。
「今ここにいる」情報には、利用者３が決済を行った場所（店舗）の住所と連絡先電話番号が記載され、購入制限情報に設定した店舗で決済（買物）をしたか否かの情報も記載されている。また決済された金額が購入制限情報に設定した金額情報で決済されたか判断しその結果が記載されている。これらのメッセージを医療機関決済支援システム１０２が処理する。メッセージはテンプレート化されたメッセージを使用して処理を行う。例えば、今ここにいる場所で決済された金額が購入制限情報に設定した金額以内で決済されたか、反対に設定した金額より超えて購入しようとし決済が不処理として処理された状況や購入制限をかけた店舗かの情報も通知されるメッセージに記載されている。
また、
購入地域制限情報の設定がされている場合、通知されるメッセージの内容には地域制限の地図情報と行動を起こす内容が付加されている。利用者３が決済した決済情報にある決済場所の情報を取得し利用する。さらに使用する地図は、外部インターネツトの地図サイトを利用して、決済場所の情報を地図上にプロットした情報を利用する。
購入地域制限情報に設定した場所（エリア）と決済場所の情報とを比較して、制限エリアとして設定した地域で有るか否かの判断を医療機関決済支援システム１０２がする。さらに連絡先に設定している家族や後見人が受信した今ここにいるメッセージには、迎えに行くために決済場所がプロットされた地図情報と、決済した店舗名や店舗の連絡先や決済日時の情報と、受信者が行動を起こさなければならない内容が付加されているメッセージを医療機関決済支援システム１０２が作成処理をする。
受信者が行動を起こさなければならない内容の例として、
購入地域制限情報に設定した地域の情報と決済場所の情報を比較して、帰ってこられる地域に居る場合は、「今ここにいるので帰れる地域だから心配しないで」と行動を起こさなくてもよいメッセージの作成処理を医療機関決済支援システム１０２が行う。患者がグレーゾーン内に居る場合は、「今ここにいるのはグレーゾーン地域だから帰れるか不安」、と行動を起こす準備が必要なメッセージの作成処理を医療機関決済支援システム１０２が行う。
グレーゾーンのエリア外に居る場合は、「今ここにいる、帰れないから迎えに来て」、と直ぐに行動を起こさせるメッセージの作成処理を医療機関決済支援システム１０２が行う。

【0250】

決済が行われると連絡先情報に登録されている連絡先に通知が行くため、徘徊癖のある利用者３など高齢者や一部の病状を持った人が１人で外出しても、安心して見守ることができる。万が一、遠くへ行くなどの理由により行方不明になっても、今ここにいる情報から探し出すこともできるし、メッセージに記載されている連絡先へ連絡することで確保してもらうこともできる。
今ここにいる情報を活用することにより、利用者３の家族など関係者は、利用者３の行動を見守ることができる。特に、利用者３が、決済できる範囲から出ても利用者３の決済を行えば、現在地が分かるので、利用者３を迎えに行くことができる。
決済の履歴情報の解析について説明する。
利用者３の家族などの関係者は、過去の決済場所の履歴を見ることで利用者３がよく利用する店舗を知ることもできる。利用者３の行動を予測することにもつながる。利用者３の行動を予測することにより、利用者３の家族などの関係者は、利用者３が決済できる範囲外に出ていく前に迎えに行くなどの対応を行うこともできるようになる。依存症の場合も何処（地域）の店舗によく行くか、どんな形態の店舗に行くか、何を販売している店舗にいくかにより、どんな店舗で食事をするか、このような決済履歴から欲しがる嗜好のパターンや、行動のパターンがわかるようになる。

【0251】

ここまで、医療機関４が患者に渡した決済媒体を用いて決済を行う方法説明してきた。
ここからは、医療機関４が発行するポイントについて説明する。
よくコンビニエンスストアの店舗数と歯科医院数を比べる事を耳にする。ほぼ同等と言われている。しかし歯科医院より多いのが医療機関である。特に内科医療機関の医院数は、コンビニエンスストアより７０％も多く、コンビニエンスストアよりも激戦状態である。こんな状態でも開業しようとする医師は多く増加する傾向にある中で、医院数を増やさずに開業する方法として第６実施形態に記載の手法もある。このような激戦の中で患者から選んでもらえる医療機関経営をするには、患者へのサービスが必要と考える。その一つが本考案である。
医療機関決済支援システム１０２を使用することで、決済にかかる手数料（経費）が減る。さらに、医療機関決済支援システム１０２を使用したキャッシュレス決済時に、医療機関４による医療機関用のポイントを発行し患者へポイントを提供することで患者数を増やす事をもくろむ内容のことである。この医療機関用ポイントは、患者が喜ぶような形で還元することが望ましく、見かけ上の医療費の負担軽減を行うポイントとすることで、他の医療機関と差別化が図れる患者へのポイントサービス提供により顧客の拡大を見込むものである。他の方法による還元の仕方も医療機関の考え方次第で行うことができる。
ポイントを事業に活用した開示は、本出願人の特願２０２１―１１３９２７などがある。ポイントを事業に活用することにより、患者を増やすことの期待ができる。
ポイントを医療事業に活用することにより、患者特に高齢者を増やすことの期待ができる。医療機関の経営を支えているのは高齢者であると言っても過言では無い。高齢者はポイント集めが大好きである。昭和にあったブルーチップ（登録商標）やグリーンスタンプ（登録商標），ベルマーク（登録商標）といった物は現代のポイントに相当する物を集めていたのは、戦後の昭和から始まった日本の文化である。日本人にとって集める行為は生活の一部とするということは昔も今も変わらないものである。決済時におけるポイントの発行方法やポイントシステムの構築に関しては特願２０２１―１１３９２７により行うことができるので省略する。

【0252】

現在、新しい決済方法として国家が次世代通貨として検討しているデジタル通貨を利用した決済が始まろうとしている。本考案の医療機関決済支援システム１０２は、近々に利用が始まろうとしているデジタル通貨の利用ができることを考案に含めている。
医療機関決済支援システム１０２は、今まで説明してきた決済に対しての利用条件や決済時に抑制を加えるなどの設定に関してもデジタル通貨を対象とした決済にも適応ができる。例えば、位置情報の不一致を利用したセキュリティ機能，予め指定した地域の中でしか決済が行えないセキュリティ機能などのここまで説明してきた安全な決済のサポートを行うセキュリティ機能や事業者または業種ごとの決済金額の上限の設定、購入可能な品目を設定、決済場所の制限の設定をそのまま用いて高齢者や一部の病状を持った人が安心してデジタル通貨を利用してもできるようになる。
医療決済口座１０４は、決済金額の移動情報を扱う口座となっているために、現金を扱う金融機関と医療決済口座１０４との間では決済総額の現金の移動指示を金融機関へ行うためとなっている。この金融機関に相当する接続や処理をデジタル通貨を扱うシステムに置き変えることにより本考案の医療機関決済支援システム１０２は、デジタル通貨を利用した決済を行うことができる。
デジタル通貨の場合のシステム構成図を図７１に示す。

【0253】

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

【0254】

本開示の決済ステムは、１回の決済毎に発生し決済端末から送られてくる決済情報に含まれる、決済場所の決済場所情報、決済した日時の決済日時情報、決済を管理している決済管理番号（伝票番号）、決済に利用した決済媒体のユニークな管理番号、決済時の金額の決済金額情報といった情報を決済関係ＤＢ１０１に買物履歴情報として蓄積している。買物履歴情報として蓄積した情報を利用して、決済履歴の情報から電子機器７３は患者や高齢者などの利用者３と会話を利用したサービスを利用者３へ提供することもできる。この機能は、第３実施形態の拡張機能のうち「（２）購入支援機能」に記載した機能となっている。

【0255】

医療機関決済支援システム１０２とそのデータベースの医療経済圏ＤＢ２１、患者情報ＤＢ１６１、決済関係ＤＢ１０１の運営を長期に渡り維持しなければならない責任がある。その責任を果たすには運営費の確保が重要である。そのためプラットフォーム型医療機関支援システム１にあるシステムの持続化を行うために収益化できるサービスを備えている。ここからは持続化を目的としたサービスについて説明していく。
医療機関決済支援システム１０２は、認知症や依存症、健忘症の一部の病気を患った患者やその家族に安全に生活をしてもらうための決済手段としている。物を買うだけでは無く、さらに認知症や依存症、健忘症の一部の病気を患った患者の生涯資産を守る事と、その資産を利用して家族が患者の生活を不自由無く過ごせるようにする事と、生涯を終えた後の遺言を家族や相続人に執行する事をサポートするサービスを備えている。

【0256】

ここまで本実施形態で説明してきた機能を活用することにより、患者や患者家族が患者生活資金と患者個人資産を生涯に渡り安全に管理することを早い段階（病状が進まない）で望んだ場合、信託管理と相続管理（遺言管理）のいずれかの資産管理のサポートを行うサービスである。この信託サービスは、従来の信託契約を医療機関決済支援システム１０２が患者や患者家族に信託契約のサポートするサービスである。患者の病状が進行すると本考案の決済媒体を利用した決済でも役不足と感じてしまう。決済媒体を利用できるうちに将来の生活に備えて計画しておくことが必要になる。願わくは後見人制度しか残されていない、そんな状況になる前の早い段階に良い方法を選択しておく事が重要である。患者の病状がさらに悪くなる前に本サービスを利用する事が望ましい。信託契約の延長線には患者の遺言もある。信託に遺言を含めるケースもある。また病状が進んでしまい患者本人の意思で契約ができなくなってしまった状態での後見人契約のサポートも含まれている。信託サービスの概要は、信託契約又は遺言契約の場合、患者の資産を調べことが必要となる。医療機関決済支援システム１０２を使用して、患者と患者家族が契約書の作成を行う。契約書は電子契約書で作成され契約内容に記載された契約執行日から終了日まで管理とその契約書に記載されている関係者へのアナウンス（通知）を行う。又は契約締結日から執行開始日まで保存され契約内容の執行開始をその契約書に記載されている関係者へアナウンス（通知）を行うサービスである。
後見人契約の場合、後見人を指名した場合の指名した理由を電子文化して管理を行うことと、後見人契約を行った契約書の電子文での管理と、後見人契約終了を患者の家族にアナウンス（通知）を行うサービスである。後見人契約を行う後見人制度は、任意後見人または指名後見人の委託者（利用者）が後見人を選定できる制度に限る。
さらに第３実施形態にあるスマートスピーカーを利用したシステムで病気への傾向がありそうだと判明したら、病状の早い段階でこのサービスを利用して将来の生活を整えておくことも良い。
金融機関へ患者の情報提供処理と信託契約管理処理とを医療機関決済支援システム１０２が信託サービスとして行うことができる。信託契約利用のシステム図を図２８に示す。医療機関決済支援システム１０２による信託契約書の作成を後に記載している。

【0257】

この信託サービスは、従来行われてきた預金資産の信託サービスに加え、利用者３が亡くなった後に生じる遺産相続（財産分与）の準備となる遺言の管理も行うことができる。遺言の管理は、従来弁護士や司法書士が行う場合や、法務局や公証人役場など公的機関に預ける方法で行われてきた。ここにデジタルベースの信託契約書や遺言書（遺言契約書）、後見人契約書の管理や保存も医療機関決済支援システム１０２が行うことができる。
また、遺言の執行には、被相続人からみた親や子、兄弟姉妹などの家系の情報も必要となる。本考案の信託サービスと、出願人考案の特許第６８８６２０９号に記載の 医療情報提供システムと連携させることにより家系の情報の取得もシステム上で容易に行えるようになる。家系の情報には、被相続人からみた親や子、兄弟姉妹といった、家族の情報が記載されているため、家系の情報を取得することにより、従来行っていた戸籍謄本や除籍謄本、改正原戸籍を集めて行う相続人の特定作業をせずとも相続人の特定を容易に行うことができる。
認知症と診察されてしまうと、こういった書類や契約書の作成はとても困難であるため、早い段階で準備することが重要である。患者の意思の欠落が始まってしまう前に。
利用者３の中には疾患を持った方もいる、本開示の第３実施形態に記載のスマートスピーカーを利用することで現在は認知症の兆候が何もなくとも変化を見つけられるために何事にも早い段階での準備が必要。特に利用者３の預貯金は金融機関の判断で口座ロックをかけられることもあり、早めに手を付けることで回避できるようになる。信託の契約書（信託契約書）や高齢者の遺言書の作成処理を行うプログラムを医療機関決済支援システム１０２は有している。契約書や遺言書の作成処理を行うプログラムは、テンプレート化された電子文情報とＲＰＡ技術により電子契約書を作成することが可能である。テンプレートやＲＰＡは既存の技術である。電子契約書を作成する際、非代替性トークン（NFTまたはnon-fungible token）技術を用いた契約者（利用者）の電子署名を電子契約書に付与する。契約者とは、後見人契約や信託契約の場合委託者と示し、遺言書の場合は、遺言人のことを示す。非代替性トークンによる電子署名により、契約者本人で行ったことを証明することができる。
また本プログラムにより作成された遺言を執行する遺言執行者を指名し指名された遺言執行者の情報を登録することで医療機関決済支援システム１０２は登録された遺言執行者へ遺言の執行を行う連絡の通知や行政（自治体や税務署）への通知を行う処理も可能である。
遺言の作成の例を図２９に示す。

【0258】

医療機関決済支援システム１０２を用いた遺言書の作成のプロセスを説明する。
本プロセスは、「（１）遺言に必要な情報の登録」「（２）遺言書の作成」「（３）遺言書の確認」「（４）セキュリティを担保した形での保管」の４プロセスで構成されている。ここから、順次作成のプロセスを記載する。１番目のプロセス「遺言に必要な情報の登録」及び２番目のプロセス「遺言書の作成」は、利用者３と利用者３の家族が利用者の所有する端末などの医療機関決済支援システム１０２に接続できる端末を用いて行う。
遺言作成のプロセスを図６８に示す。
遺言作成の情報一覧を図６９に示す。
遺言執行のプロセスを図７０に示す。

【0259】

（１）遺言に必要な情報の登録
利用者３が利用者の所有する端末で行い、医療機関決済支援システム１０２で遺言書を作成するのに必要な情報の登録方法を説明する。
利用者３と家族は、医療機関決済支援システム１０２で遺言書を作成する ために必要な情報として、遺言者情報，遺言執行者情報，遺言関係者情報，遺言資産情報の各情報を医療経済圏ＤＢ２１内の遺言者遺言情報に登録保存する。
遺言者遺言情報に登録する遺言者情報には、利用者３本人の住所や氏名を登録する。
遺言者遺言情報に登録する遺言執行者情報には、遺言執行者を指名する場合に、遺言執行者の氏名または名称や住所などの遺言執行者を特定するための情報を登録保存する。
遺言者遺言情報に登録する遺言関係者情報には、推定相続人及び遺贈受ける受遺者（以下、推定相続人と受遺者と合わせて相続人）の氏名や住所，生年月日などの相続人を特定するための情報と相続人の連絡先の情報を登録保存する。相続から排除する推定相続人がいる場合、排除する推定相続人を合わせて登録する。この登録にあたり、推定相続人の情報は、医療情報提供システムから取得できる家系の情報を利用して登録してもよい。
遺言者遺言情報に登録する遺言資産情報には、利用者３が所有する預貯金額や預け先金融機関や有価証券などの金融資産内容の情報と、土地や建物による不動産の場合は地番地、坪数、土地評価額などの情報と、貴金属やなどのその他資産の情報と、車両などの動産の情報を登録保存する。
預入先金融機関の情報は、金融資産を預けている金融機関の名称や口座番号のことで、医療経済圏ＤＢ２１の遺言者遺言情報の内に金融機関情報にも登録する。

【0260】

（２）遺言書の作成
医療機関決済支援システム１０２での遺言書の作成方法を説明する。
医療機関決済支援システム１０２での遺言書の作成は、端末を用いて遺言者により情報登録された遺言資産情報に登録された情報と、遺言書の内容テンプレート情報と遺言内容の文章を組み立てるＲＰＡ技術とを用いて自動で遺言書の文章を作成していく。電子文章で作製された遺言書は遺言書情報として医療経済圏ＤＢ２１の遺言者遺言情報の中に保存される。
例えば、資産の分配部分の作成を見てみると、遺言資産情報から取得された預貯金や株券などをどのように分配するかを指定できる。関係者の複数人に分かられる資産の場合は、割合や具体的な数値を入力または指定することで資産の分配部分の遺言文章が 作成される。また、不動産などの分けられない資産で共有相続させたい場合は、複数人の相続人を指定することで不動産部分の遺言文章が作成される。
登録し忘れなどの理由により遺言資産情報に登録していない資産が見つかった場合に備えて、その他の資産の相続人の指定を合わせて行う。
遺言執行者情報に遺言執行者が登録されている場合は、遺言書に遺言執行者が追記される。
遺言資産情報に登録された資産の全てに対して、相続人の指定することにより、遺言書の作成が完了する。この際、利用者３の思いやメッセージなどの付記事項を追加してもよい。
作成した遺言書は、医療経済圏ＤＢ２１の遺言者遺言情報の 中に遺言書情報として保存する。

【0261】

（３）遺言書の確認
医療経済圏ＤＢ２１に保存した遺言書は、法務局または公証人役場で正しい書式で書かれているかの確認を受ける必要がある。法務局または公証人役場での確認は、法務局または公証人役場から医療機関決済支援システム１０２にアクセスするためのログインＩＤ及びパスワードを用いて医療経済圏ＤＢ２１に保存した遺言書のデータを参照して内容の確認を行う。このログインＩＤ及びパスワードは、医療機関決済支援システム１０２が、法務局または公証人役場での確認のため専用の１度しか使用できないものとして発行する。
法務局または公証人役場は、遺言書の確認と審査の結果、問題ないと判断した場合、問題ない旨を返答し、問題があるとした場合、問題点を医療機関決済支援システム１０２に返答する。
返答を受けた医療機関決済支援システム１０２は、問題があると返答を受けた場合、利用者３に対し、２番目のプロセスの「遺言書の作成」を再度行うよう通知し、合わせて問題の内容を通知する。問題ないとの返答を受けた場合は、次のプロセスに進む。また、確認と審査を受けた法務局または公証人役場の名称を医療経済圏ＤＢ２１の遺言者遺言情報内の自治体情報に登録する。
法務局または公証人役場による確認が済んだ電子文書の遺言書は、医療機関決済支援システム１０２による非代替性トークン（NFTまたはnon-fungible token）を利用する設定を行ってから医療経済圏ＤＢ２１の遺言者遺言情報の内に遺言書情報として保存する。この非代替性トークン（NFTまたはnon-fungible token）を利用する設定については、後に記載している。
法務局または公証人役場を利用しない遺言書の作成もできる。

【0262】

（４）セキュリティを担保した形での保管
医療機関決済支援システム１０２は、法務局または公証人役場で遺言書の確認を受けた遺言書を利用者３が死去し遺言の執行が行われるまでの間、管理保管する必要がある。また遺言執行されるまでは誰も閲覧することはできない。
医療機関決済支援システム１０２及び医療経済圏ＤＢ２１を含む、プラットフォーム型医療機関支援システム１は、情報銀行などの法令に基づき情報の預託が行える機関が運用を行う必要がある。また、医療経済圏ＤＢ２１内に保存する遺言内容は、情報流出などが原因で万が一第三者が取得しても内容が判別できないよう、暗号化して保存する。
また、利用者３の遺志を守るためには、作成された遺言書が改変されてはいけない。
利用者３の遺言を確実に執行するために、遺言書の内容が相違する偽遺言書や、関係者以外の入手を防がなければならない。そのため、利用者３が作成した電子文書化された遺言書は医療機関決済支援システム１０２により作成された物であることの証明が必要になる。さらに、利用者３が医療機関決済支援システム１０２で作成した電子文書化された遺言書は、医療機関決済支援システム１０２に登録した相続人と遺言執行者、いわゆる医療機関決済支援システム１０２から電子文書化された遺言書が送付されてきた人だけに、遺言書（遺言契約書）の扱いに関する権利を管理する必要がある。
遺言の執行により渡される電子化された遺言書は、医療機関決済支援システム１０２により作成された証明を管理するために遺言内容の情報に、非代替性トークン（NFTまたはnon-fungible token）技術を用いたデジタルサインを付与することで医療機関決済支援システム１０２により管理されている電子文書であることを証明する。デジタルサインを付与することにより、医療機関決済支援システム１０２のオリジナルデータであることを担保する。
さらに医療機関決済支援システム１０２は、遺言執行者情報と遺言関係者情報にある遺言執行者と相続人に対して電子文書である遺言書（遺言契約書）を渡す（通知）場合も、非代替性トークン（NFTまたはnon-fungible token）技術を用いて、所有者権利の設定に遺言執行者の情報と相続人の情報を設定登録することでこの電子文書の遺言書の権利は設定した遺言執行者と相続人だけになる。
ここで記載した非代替性トークン（NFTまたはnon-fungible token）は、既存技術である。
この既存技術を利用することにより、私的に作成され、法務局や公証人役場での確認を受けていない遺言書も有効な遺言書となる。本開示の医療機関時決済支援システム１０２は、法務局や公証人役場での確認を受けない私的な遺言書の作成も行うことができる。この場合、２番目のプロセス「遺言書の作成」で遺言書を作成後、３番目のプロセス「遺言書の確認」を行わず、そのまま遺言の執行が行われるまでの間の保管のプロセスを行う。また、私的に作成した遺言書の場合、相続人間でのドラブルが多々発生するため、遺言執行者を定めておくことが望ましい。

【0263】

ここからは、医療機関決済支援システム１０２で作成した遺言書の執行プロセスを説明する。
遺言書は、利用者３が死去することで医療機関決済支援システム１０２による遺言執行プロセスが開始される。そのため、医療機関決済支援システム１０２が利用者３が死去したという情報を取得する必要が生じる。
遺言契約書の作成を行った利用者３が死去した情報の取得は、
「（１）医療機関４において医療情報システムの診療情報より取得する、これは患者の死亡により死亡診断結果の情報が医療機関４の診療情報に追加された情報を利用する。」
「（２）遺族など利用者３の関係者が端末を用いて医療機関決済支援システム１０２に接続し、利用者３の死亡の設定が行われることで医療経済圏ＤＢ２１の個人情報に死亡情報が登録される。この死亡情報を利用する。」
「（３）市区町村役所のシステムとのDX（デジタルトランスフォーメーション：既存技術）によるシステム連接を行うことにより取得した利用者３が死亡した情報を利用する。」
３つのうちもっと早く取得できた情報を利用する。この「利用者３が死去した情報の取得方法」は、信託契約においても同様の方法で行われる。
医療機関決済支援システム１０２は、利用者３が死去したという情報を取得すると、医療経済圏ＤＢ２１に電子文書の遺言書が保存されているかを参照する処理が行われる。電子文書の遺言書があることが確認された場合、通知の処理が行われる。通知の宛先は、遺言関係者情報に保存されている各相続人の情報にある連絡先と、遺言執行者情報に保存されている遺言執行者の情報にある連絡先とに通知処理される。通知の内容は、利用者３が死去したことと、遺言書の執行日の情報及び執行場所の情報を医療機関決済支援システム１０２に登録することを依頼する内容の通知である。この通知の内容を作成する処理は、医療機関決済支援システム１０２が、用意してあるテンプレートの通知文情報と利用者３の情報をテンプレートに付加する作成処理が行われる。相続人又は遺言執行者により医療機関決済支援システム１０２に端末を利用して登録された遺言書の執行日及び執行場所を、遺言書の執行日情報及び執行場所情報として医療経済圏DB２１の遺言者遺言情報に保存する。
医療機関決済支援システム１０２は、テンプレート化された通知文情報に執行日情報及び執行場所情報を付加して遺言執行通知文を作成する。作成した遺言執行通知文は、遺言関係者情報に保存されている各相続人の情報にある連絡先と、遺言執行者情報に保存されている遺言執行者の情報にある連絡先とに通知処理される。
医療機関決済支援システム１０２は、遺言の執行日に合わせて、電子文書の遺言書の内容を、遺言執行者及び相続人に送付することで開示が行われる。遺言書の開示をする方法は、メールなどの電磁気的手法を用いて電子文章で送付する。
又は，医療機関決済支援システム１０２から電子文書の遺言書を取得するため専用ログインＩＤ及びパスワードを通知し医療機関決済支援システム１０２から遺言書を取得してもらうなど電磁気的方法で行う。
いずれの方法で開示する場合であっても、取得した（開示した）遺言書に対して、相続人及び遺言執行者のうちだれが取得したかを特定するための情報として開示内容証明を付与する。遺言書の開示と同時に、開示内容証明として遺言書に付与した情報と誰が取得したかの情報とを、医療経済圏ＤＢ２１内の遺言証明情報に保存する。
遺言執行者または、相続人は、遺言の執行が完了した後、執行が完了したことを医療機関決済支援システム１０２に登録することにより、遺言執行プロセスが完了する。

【0264】

医療機関決済支援システム１０２は、信託契約の関係者に対し、信託契約の開始及び終了を通知することができる。信託契約の関係者とは、信託契約の受託者や契約書に記載の受益者、受託した資産を保管している金融機関のことであり、各関係者の通知先を医療経済圏ＤＢ２１内の信託情報に別途登録することになる。
信託契約の開始日（信託契約執行日）は、端末を使用して、医療機関決済支援システム１０２により作成した信託契約書の内容を利用者３と契約を交わす受託者が契約内容に同意する表示または同意する動作の履歴を残した瞬間に信託契約が締結され信託契約のプロセスがスタートし、信託関係者へ信託契約が執行された内容が通知される。
信託契約開始の通知は、医療経済圏ＤＢ２１内の信託情報から取得した信託契約の関係者に通知される。通知の内容は、テンプレート化された通知文情報が使用される。
信託契約終了の通知は、信託契約書に記載の終了条件を満たしたとき、もしくは、医療機関決済支援システム１０２が信託契約の委託者である利用者３が死去したという情報を取得したときに通知される。医療機関決済支援システム１０２が通知を行う文書の作成は、テンプレートを用いて自動で行う。信託契約終了の通知に付加する、信託契約の終了日（信託契約終了日）は、信託契約書に記載の終了条件を満たした日または、利用者３が死去した日となる。
利用者３が死去したという情報の取得は、
遺言契約における「利用者３が死去した情報の取得方法」と同様の方法で行われる。
信託契約の履行にあたり、渡される電子化された信託契約書は、遺言契約書と同様に医療機関決済支援システム１０２により作成された証明を管理するために信託契約の情報に、非代替性トークン（NFTまたはnon-fungible token）技術を用いたデジタルサインを付与することで医療機関決済支援システム１０２により管理されている電子文書であることを証明する。

【0265】

医療機関決済支援システム１０２は、後見人契約の関係者に対し、後見人契約の開始及び終了を通知することができる。後見人契約の関係者とは、後見人契約の後見人や利用者３家族のことであり、各関係者の通知先を医療経済圏ＤＢ２１内の後見人情報に別途登録することになる。
後見人契約の履行にあたり、渡される電子化された後見人契約書は、遺言契約書と同様に医療機関決済支援システム１０２により作成された証明を管理するために後見人契約の情報に、非代替性トークン（NFTまたはnon-fungible token）技術を用いたデジタルサインを付与することで医療機関決済支援システム１０２により管理されている電子文書であることを証明する。

【0266】

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

【0267】

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

【0268】

ここで説明した「キャッシュレス決済」は、一部の病状を持った患者や高齢者にとって決済カードを作ることが出来なかったが、医療機関４にある情報から瞬時に決済媒体と医療用決済口座の作成ができる。このことで患者はキャッシュレスに伴う様々なサービスを受けられるようになり、医療機関４も院内における恩恵を得ることができる。
プラットフォーム化されているシステムを医療経済圏２４の中で、沢山の医療機関４が利用し、その中から発生する情報を共有することで患者への様々なサービスを考案し提供することができる、他の実施形態で説明しているサービスはキャッシュレスを前提にした患者へのサービスになっている。やはり現金決済ではサービスは成り立たなくなってきています。
医療経済圏２４を利用し様々なシステムを利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者は、患者へのサービスを提供していない医療機関４は選ばなくなる、これが患者へ寄り添うことの効果になると推測する。患者へ医療サービスを提供する時代が始まると考える。
いままで患者へのサービスをないがしろにしていた医療機関が、患者へのサービスを提供することにより、多くの医療機関の中から患者へのサービスを提供する医療機関を患者が選択するようになり患者数が増え経営が安定し医療経営の持続化が可能になる。
また、本考案のシステムを維持する運営費は必要不可欠である。システムの運営費をシステムで賄うビジネスモデルとして提供できるスタイルが望ましい。有料化するサービスは、後見人契約の委託者、信託契約の委託者、遺言人からの依頼により後見人契約書、信託契約書、遺言契約書といった契約書作成を行うサービスを有料で提供を行う。また、作成した契約書の管理を行うサービスも有料で提供を行う。契約書の管理を行うサービスは、「契約書に付与されている契約者の電子署名による契約者本人が作成した契約書であることの証明」「契約内容の開示時に付与するシステムのデジタルサインによるシステムにより作成された電子文書で有ることの証明」「契約の関係者に対し、契約の執行が行われることを連絡」の３つで構成されている。有料サービスの支払いは既存技術により支払いを行うのでここでは記載はしない。既存技術は、例としてキャッシュレスやＥＣサイトやネット決済や出願人考案の特開２０２１－１１３９２７などである。出願人考案の特開２０２１－１１３９２７を利用する理由は、現在の法定通貨から次世代のデジタル通貨に代わっても、利用方法を変えずそのまま利用できるメリットがある。
この有料サービスは、プラットフォーム型医療機関支援システムの持続化を行うための収益が得られる仕組みであり、ビジネスモデルである。

【0269】

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

【0270】

＜第５実施形態＞
従来医療機関４は、医療機関４ごとに独自の診察カードを発行し、患者（利用者３）が医療機関４を受診する際、その診察カードを持参し受付で提示することにより診療を行っていた。患者は、受診した医療機関４が増えてくると、所有する診察カードもそれに伴い増えていく。診察カードが増えていくと、カードケースや財布などの診察カードを持ち歩くために保管する場所を圧迫していき煩わしくなってくる。また、診察カードが増えてくると、他の医療機関４の診察カードを間違えて持参したり、受付で間違えて提示したりする。また、一部の病状を患わっている患者にとっては、診察カードを紛失することが起こることが日常茶飯事となっている。そのため、患者にとっては、所有する診察カードは少ないほうがよい。一部の病状を患わっている患者は、診察カード無くしてしまい再発行を繰り返しており、患者は「大事な物を盗まれてしまうから盗まれないように隠す。」といった精神的な病状意識から来る行為であり病状が完治しなければ紛失は末永く続くものである。そういった病状の患者や共に暮らす家族にとっては「無くしても心配のない診察カード」が出来るのを待ち望んでいるでしょう。
本考案は、管理番号にフォーカスしたものである。ここで、管理番号について説明する。この管理番号は、医療機関４が発行した従来の診察カードに記載されている番号を使用する。医療機関４は、名前で患者を管理できないため、管理番号（診察券に記載の番号）を用いて、患者を管理している。

【0271】

本開示では、他の医療機関で発行した診察カードで受診受付が行えるサービス/仕組みを提供する「ネットワーク受付システム９ｈ」について説明する。

【0272】

本開示のネットワーク受付システム９ｈを利用した診察カードを必要としない受診受付方法は、医療機関４の受付に設置した受付端末を使用し、患者が医療機関４の患者の管理番号または、患者の名前（姓名）や顔を受付端末に提示することにより行える。このネットワーク受付システム９ｈは、プラットフォーム型医療機関支援システム１の医療情報共有データベース２にある医療経済圏ＤＢ２１にある患者情報ＤＢ１６１に保存されている情報を利用している。例えば、患者情報ＤＢ１６１にある個人情報２２や診察カードの情報や管理番号などの受付処理時に使用する情報のことである。
第５実施形態のデータベース構成を図３０に示す。
ネットワーク受付システム９ｈには、患者を識別するシステムが備わってあり、その認証を行うシステムは患者認証処理システム１６２が実施し、患者情報ＤＢ１６１内の情報を使用して識別を行う。
ここから、患者認証処理システム１６２について説明する。
患者認証処理システム１６２は、プラットフォーム型医療機関支援システム１内に構成され、患者情報ＤＢ１６１に保存されている名前や顔の情報や診察カードに記載されている管理番号や医療機関名の情報を利用して識別の処理を行う。
患者情報ＤＢ１６１に保存され名前の情報と顔の情報は、名前の「よみがな又はふりがな」情報と、顔の情報は自ら取得した顔写真の情報を利用者が登録したものである。
ここで説明した識別の処理のうち、顔の情報を利用した識別する方法は、顔認証システムとして広く一般に知られている技術を用いる。
ここで従来の医療機関の受付作業とは、来院した患者の診察カードから管理番号を医療事務員が読み取り、当医院の患者である事を確認する受付業務を行う。それに対して、患者認証処理システム１６２は、患者の診察カードの情報や患者の名前や顔を使用して患者を識別して受付が行える医療機関の受付業務として、代行できる受付サービスを提供するものである。
この受付サービスを様々な医療機関へネットワークを利用した、プラットフォーム型医療機関支援システム１のネットワーク受付システム９ｈとしたサービスである。

【0273】

本考案のネットワーク受付システム９ｈを使用することで、患者が患者情報DB１６１に登録した、診察番号（管理番号）や医療機関名などの診察カードに記載されている情報を、他の医療機関の診察カードに紐づけることができる。他の医療機関から、診察カードに紐づけた情報を取得できるため、他の医療機関４の管理番号（他の医療機関４が発行した診察カードに記載の番号）を提示しても受付することができる。
いわゆる他の病院４ａの診察カードを提示しても本人と識別され受付ができる。これは患者情報ＤＢ１６１に、患者が所有している複数医療機関の診察カードの情報を診察カード同士紐づけて登録している診察カード紐づけ情報により他の医療機関の診察カードを利用しても患者を特定することができ、受付を行うことができる。
診察カード紐づけ情報には、医療機関の名称や住所、標榜科、管理番号など診察カードに記載に記載されている複数医療機関の情報が登録されており、医療機関の名称情報、管理番号の情報と、他の医療機関の名称情報、管理番号の情報とが紐づいている。
プラットフォーム型医療機関支援システム１内の患者情報ＤＢ１６１にある個人情報２２には、複数の医療機関名の情報とその医療機関４に該当する管理番号の情報が保存されている。このデータベースにより医療機関名から、今患者がいる医療機関の管理番号を検索処理することで管理番号が取得でき受付処理を行うことができる。 また、管理番号からどこの医療機関４の管理番号か検索処理を行うことができる。この検索にも診察カード紐づけ情報を利用して検索処理ができる。

【0274】

ここでは、初めて病院に行く２つの受付ケース「他の病院の診察カードを持っているがその病院を初めて受診する患者の受付」と、「今まで一度も医療機関を受診していない患者の受付」で、本考案のネットワーク受付システム９ｈを利用した場合の処理について順次説明する。
１つ目の「他の病院の診察カードを持っているがその病院を初めて受診する患者の受付」の受付対応処理について説明する。ネットワーク受付システム９ｈは患者が提示した他の医療機関４の診察カードの管理番号を受付に設置されている受付端末で読み込み処理を行う。読み込んだ管理番号の情報を利用して、患者情報ＤＢ１６１にある患者の診察カード紐づけ情報から検索処理を行う。この検索処理により患者が今来院している医療機関の情報が検索されない場合は、この患者が初めて来院した初診患者である事をネットワーク受付システム９ｈは認識する。ネットワーク受付システム９ｈは、初めて来た患者の名前や性別などの基礎情報を患者情報ＤＢ１６１に紐づける形で医療機関４が使用する電子カルテ９ａに登録する。
ネットワーク受付システム９ｈは、患者情報ＤＢ１６１に保存の初めて来た患者の名前や性別などの基礎情報を、医療機関４が使用する電子カルテ９ａが参照できるようにする。
合わせて、患者情報DB１６１に医療機関４で使用する管理番号の登録処理を行う。登録処理に用いる管理番号は、３種類あり、「ネットワーク受付システム９ｈが、新しい診察カードを発行し新規に管理番号を採番発行する番号」と、「他の医療機関の管理番号」と、「後述する、診察カードの代用をする発行元が明確な様々カードに記載の番号を管理番号に代用する番号」を使用することができる。
この３つの方法の中から１つを選んで、患者情報ＤＢ１６１に登録し、診察カード紐づけ情報に紐づけて使用する。
ネットワーク受付システム９ｈは、「患者の基礎情報を紐づけて電子カルテ９ａを利用して患者の診療情報を保存できるようにする紐づけ登録」と、上記３つの中から選んだ管理番号の選択により、管理番号の登録する処理を行う。
患者の基礎情報を紐づけたことと管理番号を作成したことにより受付が完了し、電子カルテ９ａから患者の診療情報（診察情報）を保存できるようになる。
ここまでで、「他の病院の診察カードを持っているがその病院を初めて受診する患者の受付」の受付処理の説明が終わる。
２つ目の「今まで一度も医療機関を受診していない患者の受付」で来院した患者の受付処理について説明する。今までにどこの医療機関にも一度も受診していない患者の場合、まず、ネットワーク受付システム９ｈで患者情報ＤＢ１６１に患者の個人情報を登録し保存する必要がある。この登録は、患者が医療機関の受付で提示した保険証などの身分証明書の内容や患者が記載した診察申請書類に記載内容（患者の基礎情報）を入力することで行われ、受付担当者が患者情報ＤＢ１６１に入力する。また、今まで一度も医療機関を受診していない患者の場合、他の病院を含めて管理番号が１つも存在しないので、管理番号を登録する必要がある。ネットワーク受付システム９ｈは、前記した３つの方法の中から２つの方法による管理番号の作成となる。新規に診察カードを発行し同時に新規に管理番号を採番発行する方法と、「後述する、診察カードの代用をする発行元が明確な様々カードに記載の番号を管理番号に代用する番号」とのうちいずれかを使用して管理番号の登録が行われる。
ネットワーク受付システム９ｈは、「に患者の基礎情報を紐づけて電子カルテ９ａを利用して患者の診療情報を保存できるようにする紐づけ登録」と、上記２つの中から選んだ管理番号の選択により、管理番号の登録する処理を行う。
患者の基礎情報を紐づけたことと管理番号を作成したことにより受付が完了し、電子カルテ９ａから患者の診療情報（診察情報）を保存できるようになる。
新規の診察カードの発行を選んだ場合は、今回以降に他の医療機関で新規診察する時にその医療機関で診察カードを発行せずに最初に発行された診察カードを使用して管理番号を紐づけて利用することで受付が行え、患者は新規の診察カードを受け取らず、医療機関は診察カードを渡さずに済む。
今まで一度も医療機関を利用したことない患者の一例として、乳児の場合を説明する。乳児の場合、出生時点では、個人情報も何も登録がされていない。日本の場合、乳幼児健診やワクチンの予防接種があるため、乳児の時点で医療機関４を受診する。前記理由を含む何らかの理由で乳児が初めて、プラットフォーム型医療機関支援システム１を利用している医療機関４を受診すると患者情報ＤＢ１６１に患者の基礎情報の登録が行われる。
このことは、乳児時代からの医療に関する情報が記録されていることにもなり、人生における医療に関する重大な事項が全て記録されていることなる。医療に関する重大な事項の一例としては、アレルギー歴や手術歴、先天性疾患の治療歴、臓器移植や輸血歴などがある。
ネットワーク受付システム９ｈを含むプラットフォーム型医療機関支援システム１を利用することは、患者と医療機関４の双方にメリットがある。
患者のメリットとしては、新規患者または久しぶりに受診した際に、従来必要であった新患扱いのため診察申請書類や問診票に個人情報を書かずに受診依頼が行えるメリットがある。これは、ネットワーク受付システム９ｈの情報参照先である、患者情報ＤＢ１６１に個人情報や医療に関する重大な事項などの、診察申請書類や問診票に書き込む事項が保存されていることから、不要となる。
医療機関４のメリットとしては、受付で患者に申請書類や問診票を記載してもらい、記載してもらった内容の基礎情報を電子カルテ９ａに受付担当者が入力しなければならないという簡単な人的業務に人を充当しないとことと、法律に従って患者が記載した申請書類や問診票などの紙媒体の管理業務を行う煩わしさとの、２つのことから解放されるメリットがある。これは、個人情報や医療に関する重大な事項などの必要な情報が、患者情報ＤＢ１６１に保存されており、参照することができることから、不要となる。

【0275】

ネットワーク受付システム９ｈを利用することのメリットとして、２つの医療情報システムの併用ができる。
従来から医療機関４で使用している院内医療情報システム９gと、本考案のプラットフォーム型医療機関支援システム１にある医療情報システム９との２つの医療情報システムを診療業務に併用して使用することが、本考案のネットワーク受付システム９ｈを使用して受付処理により行う事ができる。
いわゆる、患者情報ＤＢ１６１にある複数の診察カードに記載の情報と管理番号を紐づけた「診察カード紐づけ情報」を利用することにより行える。
医療機関では、患者の診療情報を管理する管理番号は、使用している院内の医療情報システムによって番号の管理体型が違う。例えば、６桁又は８桁数字のみや、英数８文字や、様々な番号の管理体型の医療情報システムが存在している。
異なった医療情報システムを併用し診察を行う、又は、古い医療情報システムから将来新しく本考案のプラットフォーム型医療機関支援システム１の医療情報システムへ切り替えて行く、又は他社の医療情報システムへ切り替えて行く。このような場合は、併用した「ネットワーク受付システム９ｈ」が利用できる。併用する２つの医療情報システムで利用する管理番号は、管理番号を複数紐づけた「診察カード紐づけ情報」に登録することで、医療機関で使用する医療情報システムの管理番号体系に合わせた患者の管理番号を登録することができ、患者の管理番号の検索処理を行うとこの医療機関で使用する２つの管理番号が算出される。この２つの管理番号を使用することで２つの医療情報システムで管理された患者の診療情報を診察に利用することができる。
ここから認知症や健忘症の症状を持った患者が診察カードを紛失した状態で来院した時のネットワーク受付システムの動作について説明する。
認知症患者などの診察カードを無くした忘れた状態で来院され受付に来た時に、受付に設置された受付端末で名前を入力する、又は受付端末に付いているマイクに向かって「名前」を話すと、音声認識により名前の読みが文字データ化の処理がされた名前情報となる。音声認識は既存技術である。この文字データ化された名前情報を患者情報ＤＢ１６１に保存されている「診察カード紐づけ情報」から名前に相当する情報を検索処理により見つけ出し管理番号と顔写真などの生体情報と患者の漢字での名前を受付端末の画面に表示する処理を行う。診察カードを無くしてしまいそうな患者は、予め診察カードと管理番号が紐づけられている患者情報ＤＢ１６１に保存されている「診察カード紐づけ情報」に名前情報と顔写真情報などの生体情報を紐づけておく設定をしておくことで名前情報から顔写真や管理番号の情報を引き出すことができる。患者情報ＤＢ１６１に保存されている患者の基礎情報のうち受付端末に表示される情報又は内容は、生年月日、住所、管理番号等の「個人を識別する情報」となる情報が対象であり、表示された情報が正しいいわゆる患者本人の情報であれば患者による確認や同意又は受付員や、家族や、付添人により表示された情報が患者のものであることを確認することで受付処理は完了する。ただ異例なケースの名前の読みが同性同名の患者がいる場合は、受付端末の画面に該当する全ての患者の顔写真や漢字での名前、管理番号を表示し、患者本人や受付員や、家族や、付添人により表示した中から選択することで受付処理が完了されることになる。
ここで既存技術である生体認識を利用すると、受付端末のカメラを利用して患者の顔から顔写真情報を取得することで、患者情報ＤＢ１６１に保存されている「診察カード紐づけ情報」にある顔写真情報と受付で取得した顔写真情報との生体認証技術を使用して患者の識別処理を行い顔写真情報に紐づいている管理番号の情報を引き出す処理により管理番号がわかる。これにより受付処理が完了する。
このように、診察カードを無くしてしまっても受付処理を行うことができる。
この診察カードを無くしてしまっても受付処理方法は、認知症や健忘症の症状を持たない患者も使用することができる。
システムを併用しているシステムでの利用イメージを図３１に示す。

【0276】

本考案は、様々なカードを医療機関の診察カードの代用として利用することができる。
その方法は、医療機関４が発行した診察カードとは別に、利用者３がまたは所有している医療保険証やマイナンバーカードやクレジットカードや自治体が発行した図書館カード等の固有の番号が記載されているその番号やカード発行先が明確なカードを利用して医療機関の管理番号に患者情報ＤＢ１６１の患者の診察カードと前述の医療保検証などのカードの管理番号を登録した診察カード紐づけ情報に紐づけて登録することで、医療機関４の診察カードの代用として使用できる。
さらに、番号を目視できないバーコードやＱＲコード（登録商標）が印刷されているカードが代用できる。ここまで説明した代用できるカードは、形のある有形物のカードである。有形物のカードに対して形の無い無形物のスマートフォンの画面に表示できるアプリで表示させた本人固有のコード（バーチャルコード）も代用してすることができる。登録するには、バーコードやＱＲコード（登録商標）、バーチャルコードから記載されている数値を読み取り読み取った数値情報を患者情報ＤＢ１６１にある診察カード紐づけ情報にある管理番号の情報に紐づけて登録することで、医療機関４の診察カードの代用として使用できる。
利用者３が用意したカードとバーコードやＱＲコード（登録商標）の数値情報とをプラットフォーム医療機関支援システム１の患者認証処理システム１６２に利用者の携帯端末やパソコンに接続して、カード情報を患者情報ＤＢ１６１に登録し、既に登録され情報が紐づいている「診察カード紐づけ情報」にある管理番号の情報と利用者３が用意したカードの番号とを紐づけることで、医療機関４の受付で診察カードの代わりとして利用することができるようになる。例えば、図書館カードを使用して医療機関４の受付で受付処理が行えるようになる。
この場合の図書館カードを使用したネットワーク受付システム９ｈの処理は、受付の受付端末に提示した図書館カードから、図書館カードに記載されている番号を読み込み、読み込んだ番号の情報は管理番号の情報として代用し、患者情報ＤＢ１６１に登録されている「診察カード紐づけ情報」から図書館カードから読み込んだ番号（管理番号の情報として代用した番号） に紐づいている今受付をする医療機関４で使用する患者の管理番号の検索処理を「診察カード紐づけ情報」から取得する。取得した管理番号の情報を用いて受付処理が行われる。
結果、ネットワーク受付システム９ｈの提供により、今後医療機関４で診察カードの発行をしなくとも受付処理は行われ、従来の医療機関で発行した診察カードを使用した時と遜色なく使用することができ、診察カードを新規に発行し患者に渡すことが無くなる。
その他カードと顔の紐づけについて説明する。
その他カードを紐づけることとは、患者情報ＤＢ１６１の中で、診察カードの情報は利用者に紐づいている、この診察カードの情報と管理番号とを紐づける。診察カードの情報には医療機関名も含まれている。さらに複数の医療機関の管理番号も紐づける。複数の医療機関の管理番号とは、複数の医療機関で発行された診察カードに記載された管理番号である。これらの紐づけた情報は、診察カード紐づけ情報として患者情報ＤＢ１６１に保存されていることは、ここまでに説明してきた。
この診察カード紐づけ情報に診察カードの情報では無く診察カードの代用となる様々なカードも紐づけて利用することができる。診察カード以外のカードを診察カードに代用すると、診察カード以外のカードを代用したカードと診察カード同士が紐づくこととなる。例をあげると、「医療保険証に記載の番号から内科病院で使用する管理番号が分かる」「マイナンバーカードに記載の番号から外科病院で使用する管理番号が分かる」「自治体が発行した図書館カードに記載の番号から○○クリニックで使用する管理番号が分かる」「免許証の番号から○○クリニックで使用する管理番号が分かる」「クレジットカードの番号から○○クリニックで使用する管理番号が分かる」これらのように紐づけられている情報から医療機関で使用する管理番号をたどることができる。
また、「医療保険証から登録されているマイナンバーカードが分かる」「診察カードから自治体が発行した図書館カードの番号も分かる」「免許証からクレジットカードが分かる」などのように診察カード以外のカードを代用したカード同士の情報も紐づいている。
これは1枚のカード情報に複数枚のカード情報が紐づいた１対Nの形で紐づいている。この状態からさらに、全てのカードに対してそれぞれのカード情報を紐づけることにより N対Nで紐づけが行われたことになる。結果、どのカードを利用しても患者が通院する医療機関での受付に必要な管理番号を特定することができ受付処理ができることになる。
さらに名前の情報と顔の情報を患者情報ＤＢ１６１にある診察カード紐づけ情報に紐づけることができる。利用者３は、診察カードの紐づけ又は代用するカードの紐づけを、利用者の名前を利用して行う。
利用者の「よみがな」を名前情報として登録し、この名前情報に様々な医療機関の管理番号や医療機関名情報や診察カード情報を紐づけし、この紐づけた情報を患者情報ＤＢ１６１にある診察カード紐づけ情報に登録する。この紐づけにより、名前（よみがな）情報を利用して名前情報に紐づいている管理番号の情報や医療機関の情報を引き出すことが可能になる。また、患者の顔の写真を登録し、登録した顔写真情報にも様々な医療機関の管理番号や医療機関名情報や診察カード情報を紐づけし、この紐づけた情報を患者情報ＤＢ１６１にある診察カード紐づけ情報に登録する。この紐づけにより、顔写真情報を利用して顔写真情報に紐づいている管理番号の情報や医療機関の情報を引き出すことが可能になる。患者情報ＤＢ１６１にある診察カード紐づけ情報を利用して、名前情報から顔写真情報と医療機関の管理番号を引き出すことも可能になり、患者情報ＤＢにある患者の基礎情報に紐づいていることから基礎情報にある患者の氏名の情報（漢字）や住所の情報も引き出すことが可能となる。今まで紐づけられたカードのうちどれか1枚を使用すれば何処の医療機関でも受付ができるとしていたが、
このことにより、患者は診察カードや代用したカードが無くとも名前や顔を使用することで何処の医療機関でも受付ができるようになる。
複数の医療機関で発行された診察カードや利用者３が所有する携帯端末を使用する無形コードや、利用者３が用意し持ち合わせている医療保険証、マイナンバーカードや名前や顔などが患者情報ＤＢ１６１に紐づいて保存されているイメージを図７２に示し、診察カードや管理番号に紐づいているイメージを図７４に示す。
この図では、病院名の共有を行っていない。実際には、診察カードや顔，図書館カードなどの受付に用いるもの種類と病院名と管理番号との少なくとも３つの情報が診察カードの情報として共有されている。
また、１枚の診察カードを複数の医療機関で利用できるシステムのシステム図を図３２に示す。

【0277】

ここで説明した「無くしても心配のない診察カード」は、一部の病状を持った患者やその家族にとって、今まで無くした診察カードを当事者や家族が家の中を探しまくるということから解放される。そのことにより、「無くしても心配のない診察カード」サービスを提供することは、当事者の家族にとって、「家の中を探しまくる」ことからの解放は家族しか味わえない解放感を与えるサービスである。
また、診察カードを複数保有している患者にとっては、診察カードが増えていくことの弊害を無くせ、普段利用している１枚のカードを持ち歩くだけで複数の医療機関の受付ができる利便性のあるサービスである。
本考案は、一見すると、複数の医療機関の診察カードの情報を
それぞれ紐づけることで、どの診察カード利用しても利用しても何処の医療機関でも受付ができる事を目的とした、１枚の診察カードになるように見える。
この内容ではまだ、考案の目的である「無くしても心配のない診察カード」を実現することはできない。なぜならば、紐づけた１枚のカードを無くしてしまっては意味がない。無くしてしまうと、この診察カードを認知症や健忘症の当事者やその家族が家の中を探しまくることに一切の改善が図られることはない。
よって本考案は、所有している複数の診察カードの情報同士を紐づけているため、診察カードを無くしても他の医療機関の診察カードで代用できる。さらに、診察カードの代用として、カード発行先が明確な、医療保険証やマイナンバーカードやクレジットカード、自治体が発行した図書館カード、住民基本台帳カードなどの有形物のカードと、有形物に対してスマートフォンの画面上にアプリで表示させたコード情報（バーチャルコード）などの無形物の情報とが利用できる。
さらに、患者の名前や顔でも受付を行えるため、「無くしても心配のない診察カード」の診察受付の環境を作ることができる。
さらに、医療機関４のコスト削減ができる。
本考案により、医療機関４の受付や患者の診療情報管理に使用していた診察カードの発行をしなくてよい診察カードの削減と、医療機関４の診察カードを受付端末に提示する受付業務による受付人員の削減とによる経営環境ができることでコスト削減が行える。
本考案のこのサービスは、１つの医療機関だけがサービスを利用しても患者や医療機関４にとってメリットが少ないのは言うまでもない。複数の医療機関で実施することで初めてメリットが生まれる。よってこの仕組みを広域に広めるには、プラットフォーム型医療機関支援システム１で提供するネットワーク型のサービスが望ましい。医療機関４、歯科４ｆ、調剤薬局４ｂ、自治体が発行していた図書館カードや住民基本台帳カードの代替としても、医療に関係している企業等と番号で管理をしている企業や自治体にこのプラットフォーム型医療機関支援システム１によるビジネスモデルのサービスを提供できる。
この考案は、他の業態での利用を考えると金融機関での利用が最適と考えている。銀行や信託銀行、証券会社などの金融機関は、医療業態と同様にそれぞれ固有のキャッシュカードを発行している。これらに対して、本考案の仕組みを利用し、利用者３自らが金融機関の情報を患者情報ＤＢ１６１に登録しキャッシュカードに紐づけることによりどれか１枚のキャッシュカードでだけ持ち歩けばどこの金融機関のＡＴＭでも、事をなすことができる。また、窓口の利用が工夫でき、どこの銀行のキャッシュカードでも銀行窓口で手続きが行える。
利用者３は、利用者３が所有している携帯端末などを用いて、医療経済圏ＤＢ２１内の患者情報ＤＢ１６１に複数契約している、金融機関のキャッシュカードに記載された金融機関名，金融機関番号，支店番号，口座番号などの金融機関口座の情報を登録する。登録した複数の金融機関の情報を紐づけることにより、キャッシュカード紐づけ情報となる。
１枚のキャッシュカードに対して、複数の金融機関の口座が紐づけ、１つのキャッシュカードにN箇所の金融機関の口座が紐づけられたことにある。さらに、複数のキャッシュカードに同様のことを行うことにより、N枚のキャッシュカードにN箇所の金融機関が紐づけられたこととなる。これらの例として、利用者３がATMを利用する時に、この紐づけたキャッシュカードを利用すると、キャッシュカード共有システム１６３に接続し、利用したキャッシュカードがキャッシュカード紐づけ情報に紐づいているかの確認を行う。紐づけられたキャッシュカードの場合は、キャッシュカードに紐づいている複数の金融機関の口座の情報をATMの画面に表示するための処理を行う。紐づけられていないキャッシュカード、すなわちキャッシュカード共有システム１６３に登録していないキャッシュカードを使用した場合は、キャッシュカードの金融機関にそのまま接続が渡され、キャッシュカード共有システム１６３は関与しなくなる。このシステムは、ATMに導入する３つのプログラム「ATMからキャッシュカード共有システム１６３へアクセスするためのプログラム（プログラム１）」「キャッシュカード共有システム１６３からATMへ送られてきた複数の金融機関名を表示させるプログラム（プログラム２）」「ATM画面に表示され利用者が選択した金融機関へアクセスするプログラム（プログラム３）」との３つのプログラムにより処理が行われる。プログラム１は、前記したキャッシュカード紐づけ情報に紐づいているかの確認を行う処理を行うために、利用者が使用したキャッシュカードの情報をキャッシュカード共有システム１６３へ送るプログラムとなっている。プログラム２はキャッシュカード共有システム１６３から、キャッシュカード紐づけ情報に紐づいている金融機関面をATM画面へ表示させるプログラムとなっている。プログラム３は、ATM画面上で利用者が選択した金融機関へアクセスするプログラムで、コンビニATMにおいてキャッシュカードをいれるとキャッシュカードの金融機関の操作画面が出るのと同様の動作を行うプログラムとなっている。

【0278】

また、先行技術を応用することにより、キャッシュカードが無くともスマホや生体情報などを用いて金融機関の口座を利用することもできる。
先行技術としては、本出願人の特願２０２１―１１３９２７などがある。
例えば、この仕組みで作成したキャッシュカードを用いてATMを利用すると、ATMの画面上に利用者３が所有している金融機関のうち、キャッシュカード共有システム１６３に紐づいている全ての金融機関の口座が一覧で表示される。表示された金融機関から出入金や金融機関の間での預金の移動、などの手続きを行いたい金融機関の口座を選ぶことで、その金融機関の口座を利用することができる。ATM画面の表示例を図７５に示す。
本考案により、患者情報ＤＢ１６１に登録された金融機関の間の預金の移動は、ATMの利用により、１枚のキャッシュカードを利用し、１台のATMの１画面で移動元の金融機関の口座と移動先の金融機関の口座の２つを選択し、移動する金額を入力することで、預金の移動が容易に行うことができる（１アクションで行えることができる）。
従来同様な事をすると、移動先の「金融機関」と「支店」を絞り込み、次に「口座」「口座番号」「口座名」「移動金額」を入力して同様のことが行われていたプロセスに対して、本考案は「移動元金融機関口座」「移動先金融機関口座」を画面上で選択し、「移動金額」を入力するだけのシンプルな形になる。従来及び本考案における預金の移動の処理フローを図７６に示す。
１枚のキャシュカードで銀行口座を共有するシステム図を図３３に示す。
また、患者情報ＤＢ１６１内のキャッシュカード紐づけ情報により、利用者３が利用している複数のキャッシュカードと複数の金融機関が紐づいているイメージを図７７に示す。

【0279】

ここで、政府主導で行われているマイナンバーカードへの統合に触れたい。マイナンバーカードに記載されている国が管理する番号（マイナンバー）に対して、免許証や保険証に番号等の紐つけが行われている。しかし、マイナンバーカードをマスターとしてマスターに紐づける取り組みを行っても、それぞれ紐づける機関のコストは下がらない。コストが下がらない例として、保険組合は保険証の発行コストや保険証の管理コストも下がらず、公安委員会の免許証の発行コストや免許証の管理コストは下がらず、従来と何も変わらない。
マイナンバーカードへの紐づけの例として、 複数の診察カードをマイナンバーカードにまとめたイメージを図７８に示す。
マイナンバーカードと本考案の相違は、マイナンバーカードをピラミッドの頂点としてマイナンバーカードに他のカードを紐つけているものです。この事は、マイナンバーカードを紛失してしまうと、何も効果を発揮しないことになり、マイナンバーカードの仕組みでは「無くしても心配のない診察カード」にはなれないということになる。
それに対して本考案は、様々な医療機関４で発行された診察カードの管理番号と医療機関名と生体認証とを相方向に紐づけられていることで、どの診察カードを無くしても１枚あれば目的は達成できるし、さらに顔があれば目的にたどり着くことができるこの仕組みはまさに「無くしても心配のない診察カード」と言えることができる。
診察カード以外のカードやコードが使えることも自由度が広がる仕組みとなっている事もマイナンバーカードとは相違している。
「無くしても心配のない診察カード」は、医療機関４へのサービスと患者へのサービスを備えたもので、特にこれからの医療は、患者へのサービスを提供することが重要と考えています。
そのために１つの医療機関４だけで無く、医療経済圏２４を利用する全ての医療機関４が情報を共有することで患者へサービスを提供することができる。
プラットフォーム化されているシステムを医療経済圏２４の中で、沢山の医療機関４と情報を共有することでそれぞれの医療機関４が、患者へサービスを提供することとなり、
さらに他の実施形態で説明しているサービスを医療経済圏２４の中で利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者はこのシステムを利用していない医療機関４、すなわち患者へのサービスを提供していない医療機関４は選ばなくなる。本考案を利用することにより、患者へ寄り添うことの効果になると推測し、患者への様々な医療サービス提供の時代が始まると考える。

【0280】

＜第６実施形態＞
現在、医療機関４の診療科の偏りや診察時間の偏りが酷いため、地域によっては夜間や休日に対応できる病院４ａがない場合もある。
例えば、平成２９年に厚生労働省が調査した結果によると、全国で一般内科を標榜する病院４ａや医院が約７１０００軒ある一方、産科または産婦人科を標榜する病院４ａや医院が約４６００軒となっている。また、歯科医師５ｄを標榜する病院４ａや医院が約６８０００軒となっている。歯科４ｆの数はコンビニの出店数を若干上回り、一般内科の数は、コンビニエンスストアの出店数よりも３割多い。しかし、産科または産婦人科は非常に少ない。これでは人口減少が進むと医療機関４が多く適切な医療体制とは言えない。
前記した説明を整理し、医療機関を「数・量」という切り口で分析していくと、地域によっては人口比からすると医療機関の数が多い所もあり、されとは反対に地域によっては医療機関が足らない。また、医療機関を「診療科」という切り口で分析すると、診療科の多い医療機関があれば、それとは反対に診療科の少ない医療機関もある。今度は医療機関を「営業時間」という切り口で分析していくと、昼の時間帯だけ開院している医療機関が圧倒的に多く、昼と夜間を営む医療機関は少ない、さらに深夜を含め２４時間営む医療機関はさらに少なく地域によっては存在しないところもある。今度は、医療機関を「営業日」という切り口で分析すると、平日の営業を行っている医療機関が圧倒的に多く、休日も営業している医療機関は少ない。今度は人口を年齢別に分析すると、一番人口が多い「生産労働人口帯」の人達は働く労働者であるため勤務中である平日の昼間に医療機関へ行く事が会社に対して気が引ける又は有給や阪急を使って通院している。生産労働人口帯以外の人口年齢帯が昼間に医療機関に通院できている。このことから、医療機関における開院や経営のウィークポイントが判明する。沢山の医療機関は、時間帯・曜日帯においてひしめき合う営業を行っている。患者を人口帯に合わせておらず、昼間に動ける高齢者や幼児・子供や学生に絞り込んでいる。
今後、人口減少化が進むと高齢者の数も減ってくることで現在のような医療経営を行っていると、昼間の患者（高齢者）の取り合いから医療機関の経営が悪化していくことは現時点から推測できる。
満足にできなくなる医療機関が出てくる。医療経営の問題は、医療機関が増え過ぎた地域では医療機関数の抑制を行うことになる。すなわち、医療機関数の抑制を行うことは、すなわち医師の働く場を減少させることになる。
ウィークポイントから医療経営を見直すと、生産労働人口帯が、仕事終わりにいつでも利用できる。子育てママが子供の病状が出た時間にいつでも利用できる。早起き高齢者が一番空いている時間帯に診てもらう。学校の帰りに寄れる。さらに診療科が豊富な医療機関が求められる。それってコンビニエンスストア？ そう医療機関のコンビニエンス化が一番の解決策ではないかとなる。例えば、生産労働人口帯が毎年行う健康診断や人間ドックは、昼間の時間いわゆる労働時間を会社が割いて行っている。これが、医療機関のコンビニエンス化が行えれば、帰宅途中や通勤前早朝に最寄りの２４時間医療機関で人間ドックを受信することが可能となる。また１泊する人間ドックも会社帰りに受信し翌朝には通常通り会社に出勤ができるため、会社の経費負担は少なくなる。
また、医療機関を「医師の年齢」という切り口で分析していくと、地域によっては医師の年齢が高齢化しており、閉院する医療機関もある。この点においても、各地域や自治体において医師の年齢とその医師の診療科をきちんと把握し、医療機関の事業継承計画を立てることで医療機関の数を減らすことにはならない。事業継承においても、リニューアル時に医療のコンビニエンス化を意識することで、１つの医療機関を２４時間で複数の個人事業開業医や医療スタッフ（個人事業看護師）で支えることで１つの働く場所で多くの人が働けることになる。地域に１つ以上のコンビニエンス化した医療機関は必要であると考える。
本開示では、夜間や休日など医師５ａが少ない時間を含む２４時間診療できる病院４ａの開設と地域内で不足している診療科の開設することによって、新しい地域医療体制を再編成や人口減少へ対応した医療機関数や医療体制にする事を目的としている。この目的を実現するために、「医療機関数を増やすのでは無く医療提供時間を広げるという目的での２４時間診察を行う医療機関４（２４時間医療機関４ｇ）に変えていく方法や、もう一つの方法も医療機関数を増やすのではなく不足している診療科を有する医療機関４（多診療科医療機関４ｈ）に変えていく方法」と「２４時間医療機関４ｇや多診療科医療機関４ｈに変えていく上で、必要となる医療情報システム（医療機関共同利用システム１７２）」とを本実施形態で説明する。

【0281】

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

【0282】

第６実施形態のデータベース構成を図３４に示す。本実施形態では、情報に接続可能な大きな１つのデータベース（医療情報共有データベース）にある、医療経済圏ＤＢ２１に保存されている情報を参照し利用している。医療経済圏ＤＢ２１の情報には地域医療情報、地域医療計画情報、給料負担情報が保存されている。各情報の説明は、情報の使用時に記載する。

【0283】

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

【0284】

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

【0285】

域医療情報に地域内に診療科が不足している情報が保存されている場合や、地域内に２４時間医療機関４ｇが不足している情報が保存されている場合は、現在の医療機関の立地状況をネットワーク上の外部システムの地図サイト上に表示させ情報地域内のうちどこがより不足しているかを可視化する。
また、地域内のうちどこがより不足しているかを可視化したものと、地域の現在人口状況と将来の推測した人口状況に合わせ、２４時間医療機関４ｇを増やすことや不足している診療科を有する医療機関を増やすことで、地域医療に最適な医療体制と医療機関４の持続化につながる。

【0286】

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

【0287】

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

【0288】

既存の医療機関４を２４時間診療医療機関４ｇとしてリニューアルする場合において、従来の医療機関４で利用している医療情報システムは、１つの医療機関４での医師５ａによる利用を前提にした医療情報システムとなっている。この医療情報システムを使用した場合、診察に関する情報は、問題なく利用でき共有もきる。しかし、機能がないために、各個人事業医師５ａの医療機関経営に関する情報は、情報セキュリティを担保して利用できるものではない。本考案の医療機器間共同利用システム１７２は、同一住所・同一医療機関にあるパソコンやタブレットなどの端末から接続すると２４時間診療医療機関４ｇで診療を行う複数の個人事業医師５ａとの間で共有する情報と２４時間診療医療機関４ｇで診療を行う複数の個人事業医師５ａとの間で共有しない情報との両方の情報が表示される。２４時間診療医療機関４ｇで診療を行う個人事業医師５ａは、表示されている２つの情報を利用して、診察と２４時間診療医療機関４ｇの医療機関の経営を行う。
２４時間診療医療機関４ｇの例を図３５に示す。

【0289】

既存の医療機関４を前記多診察科診察医療機関４ｈへのリニューアルの場合において、従来の医療機関４で利用している医療情報システムは、１つの医療機関４での医師５ａによる利用を前提にした医療情報システムとなっている。この医療情報システムを使用した場合、診察に関する情報は、問題なく利用でき共有もきる。しかし、機能がないために、各個人事業医師５ａの医療機関経営に関する情報は、情報セキュリティを担保して利用できるものではない。本考案の医療機器間共同利用システム１７２は、同一住所・同一医療機関にあるパソコンやタブレットなどの端末から接続すると多診察科診察医療機関４ｈで診療を行う複数の個人事業医師５ａとの間で共有する情報と多診察科診察医療機関４ｈで診療を行う複数の個人事業医師５ａとの間で共有しない情報との両方の情報が表示される。多診察科診察医療機関４ｈで診療を行う個人事業医師５ａは、表示されている２つの情報を利用して、診察と多診察科診察医療機関４ｈの医療機関の経営を行う。
多診察科診察医療機関４ｈの例を図３６に示す。

【0290】

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

【0291】

２４時間診療医療機関４ｇの医療機関経営や多診察科診察医療機関４ｈの医療機関経営により、リニューアル前の医療機関４の事業主は、複数の個人事業医師５ａからの賃料収入が受けられ、複数の個人事業医師５ａは、医療施設を間借りするため開業資金が抑えられるビジネスモデルなっている。このビジネスモデルは、医療機器間共同利用システム１７２を利用しておこなわれる。

【0292】

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

【0293】

２４時間診療医療機関４ｇや多診察科医療機関４ｈでは、医師５ａごとに別々の医療機関４となっている。別々の医療機関４となっているため、医療機関４毎に行う事務作業も別々に行う必要がある。しかし、本開示の２４時間診療医療機関４ｇや多診察科医療機関４ｈでは共通のシステムを利用しているため、同一住所・同一医療機関の事務作業を一括で行うことができる。一括して行う事務作業の例としては、受付事務や会計事務、診療報酬の請求事務などがある。
一括で行う事務作業の具体例として、診療報酬の請求を用いて説明を行う。
本開示で医療機関４は、医療機器間共同利用システム１７２を利用している。このシステム内には診療報酬の計算を行う機能をもつ診療報酬計算システム１７３がある。従来の医療機関４での診療報酬の計算は人による計算となっている。また、診療報酬の計算をコンピュータで行う方法は沢山の考案も出ている。本開示では、計算方法自体ではなく、計算のさせ方と計算結果の出し方に対しての考案となっている。
診療報酬計算システム１７３は、健保組合などの保険者や自治体に対し、同一住所・同一医療機関の診療報酬として請求するのではなく、それぞれの個人事業医師５ａの診療報酬として請求を行う。
診療報酬計算システム１７３は、医療情報システムから２４時間診療医療機関４ｇや多診察科医療機関４ｈで診察事業を行う個人事業医師５ａが診察した患者の診察内容の情報を取得する。取得した診察内容の情報をもとに診療点数の計算を行い、診療報酬の金額を算出する。診察内容の情報から診療点数の計算し診療報酬を算出する方法は、従来からあるレセプトコンピュータを用いて算出する方法と変わらない。診療報酬の計算処理には既存技術が多く出ているそれを利用する。また、診療報酬計算システム１７３は、医療情報システムが利用する医療経済圏ＤＢから利用者３が加入している健康保険の情報も取得しておく。健康保険の情報とは、保険者名や保険者番号など健康保険証に記載されている情報のことを示す。
診療報酬計算システム１７３は、算出した診療報酬の金額のうち保険者負担分の金額情報と利用者３が加入している健康保険の情報とを、個人事業医師５ａ毎に、健保組合などの保険者や自治体に対して個人事業医師５ａとして診療報酬の請求するための情報として、保存を行う。診療報酬計算システム１７３は、診療報酬の請求するための情報をもとに、健保組合などの保険者や自治体に対して診療報酬の請求を行う。この請求自体は、従来から各々の病院がレセプトコンピュータを用いて行ってきた方法と何ら変わらない。
診療報酬計算システム１７３は、診療報酬の請求するための情報を個人事業医師５ａ毎に保存している。健保組合などの保険者や自治体に対して診療報酬の請求は、同一住所・同一医療機関の診療報酬として処理するのではなく、それぞれの個人事業医師５ａの診療報酬として処理する。
診療報酬計算システム１７３は、この請求処理を２４時間診療医療機関４ｇまたは多診察科診察医療機関４ｆへの経営支援を行うためのサービスとして提供を行う。結果、従来の診療報酬の請求は、１医療機関１請求を行っていたが、本開示では、１医療機関の個人事業医師５ａごとに請求する形となっている。

【0294】

前項では、健保組合などの保険者や自治体に対して診療報酬の請求を、個人事業医師５ａ毎に行うとした。しかしながら、健保組合などの保険者や自治体に対して診療報酬の請求をプラットフォーム型医療機関支援システム１に上にある、診療報酬自動請求システム１７４を用いて同一住所・同一医療機関で取りまとめて診療報酬の請求を行ってもよい。
同一住所・同一医療機関で取りまとめて請求を行う場合、診療報酬自動請求システム１７４は、診療報酬計算システム１７３で管理している診療報酬の請求するための情報を同一住所・同一医療機関で取りまとめ健保組合などの保険者や自治体に対して診療報酬の請求の処理を行う。
２４時間病院での個人事業医師から診療報酬を請求するイメージ図を図３７示し、多診療科病院での個人事業医師からそれぞれ診療報酬を請求するイメージ図を図３８に示す。
診療報酬自動請求システム１７４は、同一住所・同一医療機関に複数の個人事業医師５ａの保険医が存在する場合に、複数の個人事業医師５ａのそれぞれの診療報酬の請求するための情報を取りまとめる。この取りまとめは、同一住所・同一医療機関の別々の個人事業医師５ａを受診している患者の名寄などを行い、１つの医療機関として請求できるようにする処のことを示す。
診療報酬自動請求システム１７４は、取りまとめた診療報酬の請求するための情報を用いて健保組合などの保険者や自治体に対して診療報酬の請求の処理を行う。この際、現行制度の都合上、大家の医療機関４または店子の個人事業医師５ａが同一住所・同一医療機関を代表して請求することになる。
同一住所・同一医療機関で取りまとめて診療報酬の請求を行うと、保険者から支払われる診療報酬は、同一住所・同一医療機関全体の診療報酬が代表して請求した医療機関４または個人事業医師５ａにまとめて支払われる。代表して請求した医療機関４または個人事業医師５ａは、まとめて支払われた診療報酬を同一住所・同一医療機関の他の個人事業医師５ａへ分配する必要がある。
他の個人事業医師５ａへの診療報酬分配は、従来からある銀行振り込みなどの現金を用いた方法で行っても問題ないが、振込手数料などの手数料がもったいない。
手数料の問題は、プラットフォーム型医療機関支援システム１の医療決済口座１０４を利用することにより気にする必要が無くなる。医療決済口座とは、第４実施形態に記載の医療機関決済支援システム１０２を利用するための医療決済口座のことを示す。
医療決済口座１０４を用いた診療報酬分配は、医療機関決済支援システム１０２を用いて行う。
医療機関決済支援システム１０２は、診療報酬計算システム１７３で管理している診療報酬の請求するための情報を取得し、取得した情報を用いて、代表して請求した医療機関４または個人事業医師５ａの医療決済口座１０４から他の個人事業医師５ａ医療決済口座１０４へ支払情報が移動する処理を行う。支払情報が移動を行うことで、個人事業医師５ａは、診療報酬相当額がそれぞれ受取れる。
また、医療決済口座１０４を用いることで、将来、デジタル通貨が主流になってもこのシステムを使い続けられる。
結果、保険者及び自治体に対して請求する診療報酬の自動請求と診療報酬の受取までができるサービスとなり、２４時間診療医療機関または多診察科診察医療機関への経営支援として提供を行う。

【0295】

多診療科医療機関４ｈの場合は、同一の時間帯の複数の個人事業医師５ａが診察を行っている。通常は、各々の個人事業医師５ａが事務スタッフや警備スタッフ、清掃スタッフなどのスタッフを雇うことになる。
例えば、個人事業医師５ａが５人おり、診察を行うのに少なくとも２人の事務スタッフが必要だとする。この場合、少なくとも１０人の事務スタッフが１つの施設内で雇われていることになる。しかなしながら、受付事務など、個人事業医師５ａ毎に事務スタッフを雇わずに共同で事務スタッフ雇って、業務を依頼しても問題ない事務作業もある。
本開示の医療機関共同利用システム１７２には、複数の個人事業医師５ａが共同で雇う事務スタッフを管理するシステムとして、共同雇用システム１７５がある。
共同雇用システム１７５は、個人事業医師５ａが事務スタッフなどのスタッフを共同で雇う際の給与管理や勤怠管理を行うシステムとなっている。
共同雇用システム１７５は、各スタッフをどの個人事業医師５ａ雇用しているかの情報を取得する。情報を取得する方法は、各スタッフの勤務日時の情報と、診察を行っている個人事業医師５ａの診察日時の情報を利用して行う。
事務スタッフ（事務員）を例に説明する。
共同雇用システム１７５は、各スタッフの勤務日時の情報と、診察を行っている個人事業医師５ａの診察日時の情報を以下のように取得している。
事務員Aは、月曜と木曜に勤務している。
事務員Bは、火曜と水曜に勤務している。
個人事業医師Ｃは、月曜と火曜に診察を行っている。
個人事業医師Ｄは、木曜に診察を行っている。
個人事業医師Ｅは、火曜と水曜に診察を行っている。
共同雇用システム１７５は、取得した各スタッフの勤務日時の情報と、診察を行っている個人事業医師５ａの診察日時の情報から、どの個人事業医師５ａが何曜日にどの事務員を雇っているかの情報を算出する。
今回の場合、事務員Aは、「月曜日は、個人事業医師Ｃが」「木曜日は、個人事業医師Ｄが」それぞれ雇用しており、
事務員Bは、「火曜日は、個人事業医師Ｃと個人事業医師Ｅが共同で」「水曜日は、個人事業医師Eが」それぞれ雇用しているという情報（雇用日時の情報）となる。
共同雇用システム１７５は、雇用日時の情報をもとに各個人事業医師５ａが負担する給料の割合の計算を行い、給料負担情報として医療経済圏ＤＢ２１に保存する。
上記例では、火曜日に事務員Bを個人事業医師Ｃと個人事業医師Ｅとが共同で雇用しているため、事務員Bに対する火曜日の分の負担する給料の割合は、個人事業医師Ｃと個人事業医師Ｅともに１／２となる。残りの曜日は、１人で雇用しているため、給料の割合は、１０割となる。
共同雇用システム１７５は、各個人事業医師５ａが使用する医療機関経営事業支援システム１０に対し、給料負担情報として計算した負担する給料の情報を送る。
医療機関経営事業支援システム１０は、送られてきた給料負担情報をもとに、事務スタッフへの給料の支払い手続きを行う。
結果、多診療科医療機関４ｈ内で働くスタッフの雇用を共有するサービスとなり、個人事業医師５ａへの経営支援のビジネスモデルとして提供を行う。

【0296】

市立病院や県立病院などの比較的に病床数が多い大型の部類においても本考案の利用を行うことができる。経営改善を行うことを考えると、市立病院や県立病院は経営のスリム化を行うことと２４時間３６５日の診療の稼働へと変革していくことが必要である。そして救急を無くす。コンビニエンス病院へ移行する。医師や看護師、そして技師による個人開業医師や個人開業看護師や個人開業検査技師へ医療施設を貸し出すことにより、医療機関は経営上のスリム化ができる。例えば、現在の常勤医の数を半分に減らし、減らした分の医師を個人事業開業医とし医療機関を提供する。また、常勤看護師や常勤検査技師も同様に半分減らし、減らした分を個人事業看護師と個人事業検査技師に医療機関を提供することにより、減らした数（半分の医師、半分の看護師、半分の検査技師）の人件費だけ売り上げが出なくとも良い。見かけ上人件費が少なくなる。患者の診察に手が行きとどかなくなるわけではない。外来を個人事業医師が担当し、入院患者を常勤医師が担当することもできる。夜間診療を個人事業医師が担当することもできる。看護師においても同様である。
病院を増やさずに２４時間３６５日の医療施設となり、医師や看護師、検査技師の働く場を増やすことができる。製品を製造する企業のリーン生産が医療施設内で行うことになる。
そもそも医療機関の経営が満足に回らないのは人権費が原因である。
また大学病院においても本考案を利用することができる。常勤医を減らし個人事業開業医へ施設を提供することで、常勤医の人件費を下げられることになる。
昭和の時代から変わっていない医療経営を変えていかなければならない。

【0297】

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

【0298】

本開示の薬情報システム２０４は、は、医療経済圏DB２１，患者情報ＤＢ１６１，地域処方ＤＢ１９１、処方リカーリングＤＢ２０１、処方サブスクＤＢ２０５の各データベース内の情報を利用している。医療経済圏DB２１には、疾病処方情報、企業の事業情報、個人情報２２が保存されている。患者情報ＤＢ１６１には、病状情報が保存されている。地域処方ＤＢ１９１には、地域処方情報、地域処方量情報、地域総処方量情報、同一薬品情報が保存されている。処方リカーリングＤＢ２０２には、処方包括情報、包括回答情報 、包括総処方量情報、処方包括契約査定情報、処方包括契約先企業情報、希望契約価格情報、慢性処方薬契約情報が保存されている。処方サブスクＤＢ２０２には、処方サブスク情報、サブスク回答情報、サブスク総処方量情報、処方サブスク契約査定情報、処方サブスク包括契約先企業情報、処方サブスク契約先企業情報、慢性処方薬契約情報が保存されている。各情報の説明は、情報の使用時時に記載する。
第７実施形態のデータベース構成を図４０に示す。

【0299】

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

【0300】

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

【0301】

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

【0302】

医療経済圏２４を利用する医療機関４において、一定地域内に所在している複数の医療機関４で患者へ処方する薬品の発注を包括契約で行い薬品を購入する処方リカーリングシステム２０２について記載する。
処方リカーリングシステム２０２は、地域の医療機関を包括して薬品を包括契約により購入する包括契約である。この処方リカーリングシステム２０２の一連のプロセスは、地域の処方量（1か月、半年、１年での）の算出、包括契約する対象の薬品の選定や、包括契約先の企業の選定、契約前見積依頼、包括契約の契約書の作成、選定・契約見積・契約までの一連のプロセスを行うシステムとなっている。
このシステムを利用して契約の受注を行う事業社は医療経済圏ＤＢ２１の企業の事業情報に登録されている医療機関４とい薬品販売の事業者又は薬品を製造している製造企業である。
医療経済圏２４を利用する医療機関４で患者へ処方する薬品の種類ごとや薬品名ごとに薬の使用量の情報は、地域処方ＤＢ１９１に地域処方情報として保存されている。
この地域の複数の医療機関４の使用量を合計した地域全体の使用量（処方量）が、ボリューム使用量となる。
従来、医療機関が単体で発注していた量（数）よりも大幅に増えたボリューム使用量発注量になることから、医療機関が単体で購入していた仕入単価よりも安くなる契約となる。契約には期限がある。１年、２年、3年、５年など。長くなると物価や原材料費などの関係で医療機関側や提供する側の双方にリスクが生じるため長い期間の契約は行なわない。
処方リカーリングシステム２０２は、包括する薬品の選定と購入先となる包括契約先を選定するために処方包括選定ＡＩという人工知能（ＡＩ）を利用して行う。
処方リカーリングシステム２０２は、地域の医療機関４の薬品の処方量を全て計算処理した結果の処方量の合計値を、地域で消費した薬品名とその内容と各医療機関の処方量とその薬品の購入先と仕入単価と、処方量の合計値とが紐づいた薬品の総処方量の情報として処方リカーリングＤＢ２０１の処方包括情報の中に包括総処方量情報を保存する。
薬品入先は、複数の医療機関のそれぞれによって違う、そのため購入先は複数ある。それぞれの医療機関４が従来から使用している経営システムから従来から利用していた発注先（提供先）の情報を、「薬品の購入先」とする。
処方リカーリングシステム２０２は、薬品の包括契約を行う契約先（包括契約先企業）を選定する必要がある。
この選定する処理方法に、処方包括選定ＡＩという人工知能（ＡＩ）を利用することで煩わしい選定の自動化が図れる。
処方包括選定ＡＩは、包括契約を行う薬品の選定とその契約先となる候補企業の選定と最終的に契約を行う契約先の選定を行うものである。

【0303】

ここで、処方包括選定ＡＩについて説明する。
包括契約を行うには、契約の対象となる薬品を選ぶ必要がある。地域全体の医療機関４においては数百種類の薬品を使用している。この中から包括契約の対象とする薬品を選定する方法に処方包括選定ＡＩを利用して薬品の選定を自動化して行う。
処方包括選定ＡＩは、包括契約を行う薬品の選定とその契約先となる候補企業の選定と、最終的に契約を行う契約先の選定を行うものである。
処方包括選定ＡＩによる、薬品の選定は、従来複数の医療機関で購入していた薬品のうち医療機関ごとに仕入価格に大幅なバラツキのある薬品の情報、それぞれの医療機関での処方量が多い薬品（反対に処方量の少ない薬品は除く方が良い）の情報、従来から提供されている薬品でジェネリックなど後発品として出回り始めた薬品の情報、それぞれの医療機関で購入実績が多い企業が販売している薬品の情報、それぞれの医療機関で購入実績が少ない企業（あまり利用していない企業）が販売している薬品の情報、過去に包括契約実績のある薬品の情報を利用して、薬品と契約先候補の企業が選定される。これらの情報の入手は、既に保存してある処方リカーリングＤＢ２０１の処方包括情報から取得する。
また、選定した薬品に紐づいている薬品の購入先情報から包括契約を結ぶ包括契約先候補企業を取得しどちらの企業と契約を結ぶかの契約先企業の選定を行う。
ここまで説明した情報、すなわち処方包括情報に保存されている情報を利用して包括選定ＡＩは学習する。
処方包括選定AIが用いる機械学習の手法は、処方包括情報として保存された情報を利用して教師なし学習のうちアソシエーション分析の手法を用いる。
この学習した処方包括選定ＡＩにより、仕入れ価格のバラツキがあり、処方量が多く、後発品が出る、購入実績が多い企業、購入実績が少ない企業の情報から選定される結果として、薬品の選定とその薬品の購入先候補企業の選定とその薬品の仕入単価（推奨仕入単価）が算出される。その薬品情報に紐づいた処方量情報と購入先候補企業情報と仕入単価（推奨仕入単価）情報とを処方リカーリングＤＢ２０１の処方包括契約査定情報として保存する。
この選定までが処方包括選定ＡＩによるものである。
この処方包括契約査定情報を利用して包括契約の見積を行う。
ここで、処方包括選定ＡＩの学習方法について説明する。
処方リカーリングＤＢ２０１内に処方包括情報として保存されている包括総処方量情報から地域で消費した薬品の情報と、その薬品の内容の情報と、各医療機関の処方量の情報と、処方量の合計値の情報と、全ての医療機関での薬品の処方量を合計した包括総処方量情報を取得し学習情報とする。
企業の情報として、過去に薬品の購入先として取引していた企業や、薬品の製造企業又は、過去に包括契約実績のある企業を処方包括情報にある処方包括契約先企業情報から取得し、過去にサブスクリプション契約実績のある企業をサブスク情報にある処方サブスク契約先企業情報から取得し学習情報とする。
ここで挙げた情報を、人工知能に学習させる学習情報源とし、人工知能は教師の無い自己学習によるアソシエーション分析の手法を利用した学習を行う人工知能を利用する。
包括契約用に選定した薬品が、正しい選び方だったとは限らない場合がある。包括契約よりもサブスクリプション契約の方が最適な選択だったと後で判明する場合がある。この判断に利用する情報が、医療機関４の在庫情報である。元来、包括契約は使用する量（数）にフォーカスして契約を行う。契約期間が終了する間際に在庫量が多すぎる場合は、包括契約の選択が間違っていたことになる。反対に処方量が多く足らずに、通常の追加注文をした場合も包括契約を選択が間違っていたことになる。処方包括選定ＡＩでは、こういったことも学習していき最適な契約を選択できるようになっている。

【0304】

包括契約価格と契約先を決めるため、処方リカーリングシステム２０２は、処方包括情報に保存されている処方包括契約先候補企業に対して、包括契約の契約価格の見積依頼を送る処理を行う。
包括見積とは、企業に対して包括契約を交わすため処方量に対する契約金の算出を依頼するものである。処方リカーリングシステム２０２は、処方包括契約査定情報から、購入先候補企業情報に紐づいている薬品情報を取得し、処方量情報（ここでは契約する量になる）とその薬品情報の単価（一番安い仕入単価）を取得し、見積依頼書を作成する。包括契約の見積依頼書に記載される例は、薬品Ａ・年間処方量１００箱・仕入単価１００円、薬品B・年間処方量５００箱・仕入単価３００円の見積に必要な情報が記載された見積依頼の内容である。
さらに見積を依頼した全ての薬品に対する薬品情報の単価と処方量情報の量とから算出した、その包括契約内容における総額価格を算出する。その算出した総額価格の情報は、依頼する見積書の希望契約価格情報として、以下に説明する電子化された包括契約の見積依電子文書と一緒に処方リカーリングＤＢ２０１の希望契約価格情報に保存される。この希望契約価格情報は、回答のあった見積内容に記載されている契約価格を評価するのに利用する。
見積依頼書は、電子文書のテンプレート利用し、テンプレートに薬品情報と処方量情報をテンプレートに付加することで包括契約の見積依電子文書が作成される。
この電子文書化された包括契約の見積依頼電子文書の送付先は、購入先候補企業情報にある企業へ送付する。送付先の情報は医療経済圏ＤＢ２１にある企業情報の連絡先情報を使用して送られる。各企業から見積の返答が順次くることになる。
処方リカーリングシステム２０２は、この見積依頼に対する回答を処方包括契約先候補企業から受信し、回答内容を包括回答情報として処方リカーリングＤＢ２０１に保存する。包括回答情報には、企業から送られてきた企業名、薬品名、契約する薬品の数量、契約金額、支払条件などの契約に必要な情報が保存されている。
ここで、商品（薬）を提供する企業について説明する。
まず、何故企業は包括契約を行うのでしょうか？ その答えは「独占」です。薬品は、様々なメーカー（製造企業）が製造している多品種商品（特に後発薬（ジェネリック））、そして様々な卸事業社が販売している多卸事業となっている。また、メーカーが直接販売しているケースもある。包括契約とは、数多くある多品種商品の中から１銘柄に絞られます。例えば、アセチルサリチル酸を製造する企業が２０社、イブプロフェンを製造する企業が１０社あったとします、これらが地域全体で消費する量（数）を包括し、包括契約を、アセチルサリチル酸はA社と契約、イブプロフェンはC社と契約することで、薬品を提供していた複数社の卸事業社や複数メーカーの直接販売は、包括契約の契約期間中に、この地域への薬品販売が一切できないことになる。契約した卸事業社又は製造企業だけの１社独占提供となる。他社からの参入（受注活動）が一切できない独占の状態になることで売上が上がる。契約できなかった他社は、契約期間中は手を出せずに見ているだけとなる。よって、次の契約時期を狙い次回の契約はさらに激しくなる。１度包括契約を勝ち取ってしまい独占状態を味わってしまうとそこから抜け出せなくなる。医療機関４側も全く同じで安く買えることの経営体制を味わってしまうとそこから抜けられない。
包括契約の見積依頼に対する見積書の返答について記載する。
見積依頼を受けた各企業は、見積を行い見積書の提出することになる。処方リカーリングシステム２０２は、返答されてくる見積書内に記載されている見積価格と契約期間と薬品とその薬品の提供価格とを見積を作成した企業ごとに取得し、企業情報に見積価格の情報と契約期間の情報と薬品の情報と提供価格の情報と、その見積書の電子文書とを処方リカーリングＤＢ２０１の見積返答情報に各社保存する。返答のあった見積価格と希望契約価格情報とを比較する。比較により見積価格の方が高い見積書は対象外とする。希望契約価格情報よりも安く価格差がある見積書を採用する。このことにより契約先の企業が選定されたことになる。処方リカーリングシステム２０２により選定された契約先の企業は、包括契約先企業として処方リカーリングＤＢ２０１の処方包括情報に、処方包括契約先企業情報として保全される。
次は、契約書を作成するプロセスになる。

【0305】

包括契約における契約書の作成について説明する。
包括契約書の作成は２種類となる。１つは、バーチャルな大きな医療機関と契約を行う事業者との間で交わす契約書。もう１つは、バーチャルな大きな医療機関と実際の医療機関４との間で交わす契約書になる。どちらの契約書の作成も同じ方法になる。
包括契約の締結は、処方リカーリングシステム２０２による電子契約で行われる。電子契約書（デジタル契約書）の作成は、既存技術を利用する。
デジタル契約書を自動作成する処理には、契約書のテンプレートを用いて、契約書作成のＲＰＡ技術に契約書作成プログラムを利用した方法で行う。テンプレート及びＲＰＡは既存の技術である。
１つ目の、バーチャルな大きな医療機関と契約を行う事業者との間で交わす契約書について。
この契約書作成に予め用意したテンプレートを使用し、処方リカーリングＤＢ２０１の見積返答情報からリスト表示した薬品情報と、見積価格の情報と、契約期間の情報、契約する企業情報を取得し、ＲＰＡ技術により左記の情報とテンプレートとを使用して作成された電子契約書の電子文が作成される。作製された電子契約書の締結は、企業が端末を利用してＷＥＢにアクセスし契約書締結ページに表示された「契約締結ボタン」を押すことで電子契約書に電子署名が行われ、電子契約書が作成される。処方リカーリングシステム２０２の電子署名はRPAプログラムにより自動で行われている。
２つ目の、バーチャルな大きな医療機関と実際の医療機関４との間で交わす契約書の作成について説明する。
この契約に必要な情報は、処方リカーリングＤＢ２０１の処方包括情報内に保存されている包括総処方量情報から医療機関４における薬品の情報と処方量の情報を取得する。ここで取得した、薬品の情報と処方量の情報は、医療機関４ごとに、薬品の内容や処方量が違う。よって、医療機関毎に、薬品とその処方量（契約する量）との情報が違うことになる。契約書のテンプレートに、医療機関４が契約するリスト表示した薬品情報と、処方包括情報の中にある処方量の情報（契約する量）と、その薬品の提供価格と、契約期間の情報と、ＲＰＡが算出した医療機関４が契約する契約金額を使用し、さらに薬品提供者として契約する企業名とが、ＲＰＡ技術とテンプレートとを使用して作成された電子契約書の電子文が作成される。
契約書の契約者には、医療機関４とバーチャルな大きな医療機関の名称が転載される。作製された電子契約書の締結は、医療機関４が端末を利用してＷＥＢにアクセスし契約書締結ページに表示された「契約締結ボタン」を押すことで電子契約書に電子署名が行われ、電子契約書が作成される。処方リカーリングシステム２０２の電子署名はRPAプログラムにより自動で行われている。これを地域の医療機関４の全医療機関４の締結を行うことになる。契約が締結された電子契約書は、処方リカーリングＤＢ２０１の包括契約情報に保存される。またNFTにより所有者（所有権）を医療機関４と処方リカーリングシステム２０２とに管理設定された電子契約書を医療機関に送付をすることもできる。
包括契約に関わる詳細情報が、処方リカーリングＤＢ２０１に処方包括情報として保存されている。

【0306】

医療経済圏２４を利用する医療機関４において、一定地域内に所在している複数の医療機関４で患者へ処方する薬品の発注とその薬品の仕入価格（購入価格）を下げることができる方法のサブスクリプション契約による薬品の購入により、医療機関４からの支払額が少なくなる。
このサブスクリプション契約について記載する。
サブスクリプション契約での薬品の購入は、処方サブスクリプションシステム２０３を用いて行う。この処方サブスクリプションシステム２０３の一連のプロセスは、地域の処方量（1か月半年、１年での）の算出、サブスクリプション契約する対象の薬品の選定や、サブスクリプション契約先の企業の選定、契約前見積依頼、サブスクリプション契約の契約書の作成、選定・契約見積・契約までの一連のプロセスを行うシステムとなっている。
この処方サブスクリプションシステム２０３を利用して契約の受注を行う事業社は医療経済圏ＤＢ２１の企業の事業情報に登録されている医療機関４と薬品の販売事業者又は薬品を製造している製造企業である。
医療経済圏２４を利用する医療機関４が使用している薬品の種類や薬品の処方量と仕入価格（購入価格）又は払い出された量の情報は、地域処方ＤＢ１９１に地域処方情報として保存されている。
この地域の複数の医療機関４の処方量（使用量）を合計した地域全体の処方量（使用量）が、一定年期間は通常の購入価格よりディスカウウントされた定額で購入できる契約を行うことになる。処方サブスクリプションシステム２０３は、この処方量（使用量）を、薬品の発注量の情報として処方サブスクＤＢ２０５の処方サブスク情報に保存する。
さらにサブスクリプション契約は、契約に適する薬品と購入先企業（サブスクリプションシステム契約先企業）を選定する必要がある。この選定する処理方法に、処方サブスク選定ＡＩという人工知能（ＡＩ）を利用することで煩わしい選定の自動化が図れる。
処方サブスク選定ＡＩは、サブスクリプションシステム契約を行う企業の選定と、サブスクリプションシステム契約を行う薬品の選定を行う機能となる。
処方サブスク選定ＡＩは、一定年期間のボリュームディスカウウントでの購入に適切な薬品、契約ができそうな薬品、過去に購入実績のある薬品、消費している量（発注する量）、通常価格、過去にサブスクリプション契約の実績のある薬品、から薬品を選定し、発注する薬品名の情報として処方サブスクＤＢ２０５の処方サブスク情報に保存する。また、選定した薬品をサブスクリプション契約でボリュームディスカウウント価格での提供を行ってくれそうな企業又は、過去に契約実績のある企業をサブスク契約先候補企業として選定をする処理を行い、選定したサブスク契約先候補企業の情報を処方サブスクＤＢ２０５の処方サブスク情報に保存する。 サブスク契約先候補として選定する対象の企業は、医療経済圏ＤＢ２１にある企業の事業情報に薬品の発注先企業として登録されている企業（卸会社や生産メーカーなど）である。
さらに、処方サブスク選定ＡＩは、選定するために必要な情報として、選定したサブスク契約先候補企業のシステムから、薬品の最少発注量の目安の情報と納期の情報とを取得し処方サブスクＤＢ２０５の処方サブスク情報に保存する。
サブスクリプション契約を行うには、各医療機関４にて一定期間における処方量を契約の目安として使用する。１か月間、半年間、１年間の処方量（発注量）どちらも使用するが、一般的には１年間の処方量を基本に契約が行われている。この医療機関４の処方量（発注量）を地域全体の医療機関４で消費した薬品ごとの総処方量を算出する。この算出した地域全体の総処方量を処方サブスクＤＢ２０５の処方サブスク情報の中にサブスク総処方量情報を保存する。
処方リカーリングＤＢ２０１の処方包括情報の中に薬品の包括総処方量情報が保存されているのでそちらを使用しても良い。
この処方量は、１年間の処方量を見て、翌年から契約する購入金額（仕入金額）、すなわち地域全体の医療機関へのディスカウントプライスの契約価格が決められる。1か月間で消費した量を１２倍して1年分として計算することも、半年間で消費した量を２倍して1年分として計算することもどちらでも構わない。

【0307】

処方サブスク選定ＡＩによる薬品の選定について説明する。
処方サブスク選定ＡＩは、サブスク契約を行う薬品の選定とその契約先となる候補企業の選定と、を行うものである。
サブスクリプション契約を行うには、契約の対象となる薬品を選ぶ必要がある。地域全体の医療機関４においては数百種類の薬品を使用している。この中からサブスクリプション契約の対象とする薬品を選定する方法に処方サブスク選定ＡＩを利用して薬品の選定を自動化して行う。
処方サブスク選定ＡＩによる、薬品の選定に利用する情報は、従来複数の医療機関で購入していた薬品のうち医療機関ごとに仕入価格に大幅なバラツキのある薬品、それぞれの医療機関での処方量が多い薬品（反対に処方量の少ない薬品は除く方が良い）の情報、従来から提供されている薬品でジェネリックなど後発品として出回り始めた薬品の情報、それぞれの医療機関で購入実績が多い企業が販売している薬品の情報、それぞれの医療機関で購入実績が少ない企業（あまり利用していない企業）が販売している薬品の情報、過去にサブスクリプション契約実績のある薬品の情報を利用して、薬品と契約先候補の企業が選定される。これらの情報の入手は、既に包括契約のところで説明しているが、これらの情報を保存しているのは、処方リカーリングＤＢ２０１の処方包括情報である。この処方包括情報はここまで説明した薬品を選定する為に必要な情報であり処方包括選定ＡＩでも処方サブスク選定ＡＩでもこの情報を利用する。ここではサブスクリプション契約の説明をしているため、説明上この処方包括情報を処方サブスク情報に置き換えて説明をしていきたい。包括情報の内容と処方サブスク情報の内容も全く同じものである。
また、選定した薬品に紐づいている薬品の購入先情報からサブスクリプション契約を結ぶ処方サブスク契約先候補企業を取得しどちらの企業と契約を結ぶかの契約先企業の選定を行う。
ここまで説明した情報、すなわち処方サブスク情報（処方包括情報）に保存されている情報を利用して処方サブスク選定ＡＩは学習する。
包括契約用に選定した薬品が、正しい選び方だったとは限らない場合がある。包括契約よりもサブスクリプション契約の方が最適な選定だったと後で判明する。
ここで、処方サブスク選定ＡＩの学習方法について説明する。
サブスクＤＢ４２内に処方サブスク情報として保存されているサブスク総処方量情報から地域で消費した薬品の情報と、その薬品の内容の情報と、各医療機関の処方量の情報と、処方量の合計値の情報と、全ての医療機関での薬品の処方量を合計したサブスク総処方量情報を取得し学習情報とする。
企業の情報として、過去に薬品の購入先として取引していた企業や、薬品の製造企業又は、過去に包括契約実績のある企業を処方包括情報にある包括契約先企業情報から取得し、過去にサブスクリプション契約実績のある企業を処方サブスク情報にある処方サブスク契約先企業情報から取得し学習情報とする。
ここで挙げた情報を、人工知能に学習させる学習情報源とし、人工知能は教師の無い自己学習によるアソシエーション分析の手法を利用した学習を行う人工知能を利用する。
サブスクリプション契約用に選定した薬品が、正しい選び方だったとは限らない場合がある。サブスクリプション契約よりも包括契約の方が最適な選択だったと後で判明する場合もある。
この判断に利用する情報が、医療機関４の処方量情報である。元来、サブスクリプション契約は消費する量（数）にフォーカスして契約を行う。契約期間が終了する間際に地域の医療機関の処方量と、サブスクリプション契約の参考にした契約前の処方量との差を見ることで判明する。サブスクリプション契約前の処方量よりも、契約後の処方量の方が少なかった場合は、サブスクリプション契約の選択が間違っていたことになる。又は包括契約を選択した方が正しかったと判明する場合もある。反対に、契約後の処方量の方が多かった場合は、サブスクリプション契約を選択して正しかったと判明する。処方サブスク選定ＡＩでは、こういったことも学習していき最適な契約を選択できるようになっている。
ここで、包括契約とサブスクリプション契約の違いについて説明する。
包括契約とは、包括した医療機関４を、今回は地域の医療機関としている。この地域の医療機関において一定期間で消費した量、すなわち医療機関が使用する量が契約対象の量としている。この量は提供側が提供する量であり、この量に対しての単価を決めたものが包括契約である。量を超えて注文した場合は、超えた量が通常の提供価格となる。契約量重視の契約である。それに対してサブスクリプション契約には、「量」の契約範囲は無い。一定期間においていくら量を注文しても、契約期間内は契約した価格で提供される。契約期間重視の契約である。よって、薬品によっては、選択する契約が違う。間違って契約をすると、メリットを活かせないことになる。例えば福島震災で多くの包帯を消費した年があった。その処方量を元に翌年の調達に契約を使用した調達をしても、翌年は全く消費せず契約をする意味がなさない場合もある。包括契約をした場合、翌年は前年度を超える消費は見込めない、結果前年度の消費を超える消費にはいたらず、在庫を抱える契約となってしまい無駄となる。反対にサブスクリプション契約を選定した場合、量（数）に制限がないため前年度より消費が少なくても契約期間中の価格は安いまま必要な量（数）が提供され、包括契約とは違い大幅な在庫を抱えることもない。この例とは逆のケースもある。
こういった契約をしてしまい十分に契約が活かせなかった薬品の情報と契約方法の情報も利用して、処方サブスク選定ＡＩ（処方包括選定ＡＩ）は選定を行う。在庫情報を見て、契約した薬品の在庫が多ければ、契約が活かせない失敗した契約だったことが判明する。
また、選定した薬品に紐づいている薬品の購入先情報から包括契約を結ぶ包括契約先候補企業を取得しどちらの企業と契約を結ぶかの契約先企業の選定を行う。
ここまで説明した情報、すなわち処方サブスク情報（処方包括情報）に保存されている情報を利用して処方サブスク選定ＡＩは学習する。
処方サブスク選定ＡＩが用いる機械学習の手法は、処方サブスク情報（処方包括情報）として保存された情報を利用して教師なし学習のうちアソシエーション分析の手法を用いる。
この学習した処方サブスク選定ＡＩにより、仕入れ価格のバラツキがあり、処方量が多く、新しい製品が出る、購入実績が多い企業、購入実績が少ない企業の情報から選定される結果として、薬品の選定とその薬品の購入先候補企業の選定とその薬品の仕入単価（推奨仕入単価）が算出される。ここでいう仕入単価（推奨仕入単価）は、地域の医療機関で仕入価格となっている一番低い価格を参考にさらに算出される。その薬品情報に紐づいた処方量情報と購入先候補企業情報と仕入単価（推奨仕入単価）情報とを処方サブスクＤＢ２０５の処方サブスク契約査定情報として保存する。
ここまでが、薬品と購入先候補企業（契約先の候補企業）の選定までが処方サブスク選定ＡＩによるものである。

【0308】

サブスクリプション契約の価格と契約先を決めるため、処方サブスクリプションシステム２０３は、処方サブスク情報に保存されているサブスク契約先候補企業に対して、サブスクリプション契約の契約価格の見積依頼を送る処理を行う。
サブスクリプション契約の見積とは、企業に対してサブスクリプション契約の依頼するための契約金の算出と契約期間の算出を依頼するものである。処方サブスクリプションシステム２０３は、処方サブスク契約査定情報から、購入先候補企業情報に紐づいている薬品情報を取得し、処方量情報（ここでは契約金を算出する量になる）とその薬品情報の単価（一番安い仕入単価）を取得し、見積依頼書を作成する。サブスク契約の見積依頼書に記載される例は、薬品Ａ・年間処方量１００箱・仕入単価１００円、薬品B・年間処方量５００箱・仕入単価３００円の見積に必要な情報が記載された見積依頼内容である。
さらに見積を依頼した全ての薬品に対する薬品情報の単価と処方量情報の量を使用して算出した、そのサブスクリプション契約内容における総額価格を算出する。その算出した総額価格の情報は、依頼する見積書の希望契約価格情報として、以下に説明する電子化されたサブスクリプション契約の見積依電子文書と一緒に処方サブスクＤＢ２０５の見積依頼情報に保存される。この希望契約価格情報は、回答のあった見積内容を評価するのに利用する。
見積依頼書は、電子文書のテンプレート利用し、テンプレートに薬品情報と処方量情報をテンプレートに付加することでサブスクリプション契約の見積依電子文書が作成される。
この電子文書化されたサブスクリプション契約の見積依頼電子文書の送付先は、購入先候補企業情報にある企業へ送付する。送付先の情報は医療経済圏ＤＢ２１にある企業情報の連絡先情報を使用して送られる。各企業から見積の返答が順次くることになる。
処方サブスクリプションシステム２０３は、この見積依頼に対する回答をサブスク契約先候補企業から受信し、回答内容をサブスク回答情報として処方サブスクＤＢ２０５に保存する。サブスク回答情報には、企業から送られてきた企業名、薬品名、契約する薬品の数量、契約金額、支払条件などの契約に必要な情報が保存されている。
ここで、商品を提供する企業について説明する。
何故、企業はサブスクリプション契約を行うのでしょうか？ その答えは「独占」です。薬品は、様々なメーカー（製造企業）が製造している多品種商品である。そして、沢山の卸事業社（提供業者）が販売している多卸事業となっている。また、メーカーが直接販売しているケースもある。サブスクリプション契約とは、数多くある多品種商品の中から１銘柄に絞られます。例えば、アセチルサリチル酸を製造する企業が２０社、イブプロフェンを製造する企業が１０社あったとします、これらが地域全体で消費する量（数）を包括し、サブスクリプション契約を、アセチルサリチル酸はA社と契約、イブプロフェンはC社と契約することで、薬品を提供していた複数社の卸事業社や複数メーカーの直接販売は、サブスクリプション契約の契約期間中に、この地域への薬品販売が一切できないことになる。契約した卸事業社又は製造企業だけの１社独占提供となる。他社からの参入（受注活動）が一切できない独占の状態になることで売上が上がる。契約できなかった他社は、契約期間中は手を出せずに見ているだけとなる。よって、次の契約時期を狙い次回の契約はさらに激しくなる。１度サブスクリプション契約を勝ち取ってしまい独占状態を味わってしまうとそこから抜け出せなくなる。医療機関４側も全く同じで安く買えることの経営体制を味わってしまうとそこから抜けられない。
サブスクリプション契約の見積依頼に対する見積書の返答について記載する。
見積依頼を受けた各企業は、見積の算出を行い見積書の提出を行うことになる。処方サブスクリプションシステム２０３は、各企業から見積書を受信することになる。処方サブスクリプションシステム２０３は、返答されてくる見積書内に記載されている見積価格と契約期間と薬品とその薬品の提供価格との情報を、見積を作成した企業ごとに取得し、企業情報に見積価格の情報と契約期間の情報と薬品の情報と提供価格の情報と、その見積書の電子文書とを処方サブスクＤＢ２０５の見積返答情報に各社保存する。処方サブスク選定ＡＩにより、返答のあった見積価格と希望契約価格情報とを比較する。この比較により見積価格の方が高い見積書は対象外とする。また、過去にサブスクリプション契約を行った企業からの見積価格の情報も参照して、希望契約価格情報よりも安く価格差がある見積書だけが絞り込まれていき採用を決める。このことにより契約先の企業が選定されたことになる。処方サブスクリプションシステム２０３により選定された契約先の企業は、サブスク契約先企業としてリカーリングＤＢ４１の処方サブスク情報に、処方サブスク契約先企業情報として保全される。
次は、契約書を作成するプロセスになる。

【0309】

サブスクリプション契約における契約書の作成について説明する。
処方サブスクリプションシステム２０３が行うサブスクリプション契約書の作成は２種類となる。１つは、バーチャルな大きな医療機関と契約を行う事業者との間で交わす契約書。もう１つは、バーチャルな大きな医療機関と実際の医療機関４との間で交わす契約書になる。どちらの契約書の作成も同じ方法になる。
サブスクリプションの締結は、処方サブスクリプションシステム２０３による電子契約で行われる。電子契約書（デジタル契約書）の作成は、は既存技術を利用する。
デジタル契約書を自動作成する処理には、契約書のテンプレートを用いて、契約書作成のＲＰＡ技術に契約書作成プログラムを利用した方法で行う。テンプレート及びＲＰＡは既存の技術である。
１つ目の、バーチャルな大きな医療機関と契約を行う事業者との間で交わす契約書について。
この契約書作成に予め用意したテンプレートを使用し、処方サブスクＤＢ２０５の見積返答情報からリスト表示した薬品情報と、見積価格の情報と、契約期間の情報、契約する企業情報を取得し、ＲＰＡ技術により左記の情報とテンプレートとを使用して作成された電子契約書の電子文が作成される。
作製された電子契約書の締結は、契約する企業が端末を利用してＷＥＢにアクセスし契約書締結ページに表示された「契約締結ボタン」を押すことで電子契約書に電子署名が行われ、電子契約書が作成される。処方サブスクリプションシステム２０３の電子署名はRPAプログラムにより自動で行われている。
２つ目の、バーチャルな大きな医療機関と実際の医療機関４との間で交わす契約書の作成について説明する。この契約に必要な情報は、処方サブスクＤＢ２０５の処方サブスク情報内に保存されているサブスク総処方量情報から医療機関４における薬品の情報と処方量の情報を取得する。ここで取得した、薬品の情報と処方量の情報は、医療機関４ごとに、薬品の内容や処方量が違う。よって、医療機関毎に契約する、薬品とその処方量（契約する量や数）との情報が違うことになる。契約書のテンプレートに、医療機関４が契約するリスト表示した薬品情報と、その薬品の提供価格と、契約期間の情報と、契約する企業名とがＲＰＡ技術とテンプレートとを使用して作成された電子契約書の電子文が作成される。
契約書の契約者には、医療機関４とバーチャルな大きな医療機関の名称が転載される。作製された電子契約書の締結は、医療機関４が端末を利用してＷＥＢにアクセスし契約書締結ページに表示された「契約締結ボタン」を押すことで電子契約書に電子署名が行われ、電子契約書が作成される。処方サブスクリプションシステム２０３の電子署名はRPAプログラムにより自動で行われている。これを地域の医療機関４の全医療機関４の締結を行うことになる。契約が締結された電子契約書は、処方サブスクＤＢ２０５のサブスク契約情報に保存される。またNFTにより所有者（所有権）を医療機関４と処方サブスクリプションシステム２０３に管理設定された電子契約書を医療機関に送付をすることもできる。
サブスクリプション契約に関わる詳細情報が、処方サブスクＤＢ２０５に処方サブスク情報として保存されている。
サブスクリプション契約のイメージを図４１に示す。

【0310】

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

【0311】

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

【0312】

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

【0313】

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

【0314】

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

【0315】

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

【0316】

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

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

ここから、特殊な車両を必要とする患者の予約について説明する。
診察が終了し、次回診察の予約を診察予約管理システム６２で行う。この際、診察予約管理システム６２は、患者情報ＤＢ１６１に保存されている利用者３の移動手段情報を参照して、利用者３が通院には特殊な車両を必要とする患者であることを認識し、運行管理システム２１１を利用して移動手段の予約を行うことが必要であることを認識する。
診察予約管理システム６２は、運行管理システム２１１をキック（稼働）させて、予約が可能なそれぞれの事業社の予約可能日時情報の返答待ち（提供待ち）となる。ここでいう「それぞれの事業社」とは、複数ある介護タクシー会社や介添人８会社や、看護師５ｂや医師５ａを派遣する会社の事である。
ここからは運行管理システム２１１の処理になる。
診察予約管理システム６２からキック（稼働）され予約可能日時情報の提供を求められた運行管理システム２１１は、患者情報ＤＢ１６１に保存されている利用者３の病状情報と移動手段情報を参照し、利用者３に必要な車両タイプや介添人８や看護師５ｂや医師５ａの中の必要な内容が判明する。移動手段情報には、利用者３の移動手段に必要な内容が紐づいて保存されている。例えば、利用者Ａさんの場合の移動手段情報には、車椅子で車両タイプとして車椅子が収納できる介護タクシー（含む運転手）、介添人８が必要と保存されている。利用者Ａさんの場合は、看護師５ｂや医師５ａの付添いの必要は無い。更に、病状情報から病状が悪化し前回移動より病状の変化が無いかの確認を行う。病状の変化がある場合は、看護師５ｂや医師５ａの医療関係者の付添が必要になる。
運行管理システム２１１は、診察予約管理システム６２が算出した利用者３と医療機関４の予約可能日時情報を予約ＤＢ６１から取得する。この予約可能日時情報を基本に予約可能なそれぞれの事業社の予約情報と一致させる。それぞれの事業者の予約情報は、事業社が利用している予約システム９ｄから予約情報を取得する方法と、運行管理システム２１１を使用している事業からは、予約ＤＢ６１から事業社の予約情報を取得する方法とで予約情報の取得を行う。それぞれの事業社から取得した予約情報から、診察予約管理システム６２から入手した利用者３の予約可能日時情報と比較し一致している予約可能な日時をそれぞれの事業社をまとめた事業社予約可能日時情報として算出し、予約ＤＢ６１の予約可能日時情報に紐づけて保存する。
予約ＤＢ６１への保存が終わると、運行管理システム２１１は、診察予約管理システム６２に対して処理を完了したフラグを返す。
運行管理システム２１１からの処理完了のフラグを受け取った診察予約管理システム６２は、患者予定・医療機関予定から算出した予約可能日時情報から、患者予定・医療機関予定・事業者予定の３つの予定から算出した事業社予約可能日時情報を使用して患者の予約を行うことになる。診察予約管理システム６２は、事業社予約可能日時情報が紐づいている予約可能日時情報を予約ＤＢ６１から取得して、医療機関にある端末の画面に表示を行う。利用者３は、端末に表示された予約可能日時から次回診察の日時を選択する。その日時（次回の診察日時）に予約可能な事業社を選択していく。表示される事業者には、介護タクシー会社や介添人８会社や看護師５ｂや医師５ａを派遣する会社が表示され、その中から選択をする。
例えば、利用者Ａさんの場合の移動手段情報には、車両タイプとして介護タクシー（含む運転手）、介添人８と保存されているため、予約を行う端末の画面には、介護タクシー会社や介添人８会社が表示される。看護師５ｂや医師５ａを派遣する会社は、表示されない。
この事業社を選択する画面には、簡単な利用価格を表示することができる。運行管理ＤＢの運行管理情報にある労務時間情報を使用してそれぞれの利用価格を算出し表示することができる。
それぞれの事業社のローディング費を運行管理ＤＢの事業社情報に保存することで利用価格の算出は可能となる。
例えば、あるＡ事業社（車両）のローディング費が5000円／ｈと、Ｂ事業社の介添人のローディング費が3000円／ｈと、Ｃ事業社の看護師のローディング費が5000円／ｈと、医師のローディング費が10000円／ｈとが登録されていた場合、労務時間情報がわかれば利用価格を算出することができる。
当然の事であるが、同じビジネスをする複数の事業社の場合、安い利用価格を提供する事業社から選ばれていくことになる。高い事業社は、サービスの内容を差別化しなければ選択されることは無くなっていく。
端末に表示された事業社の選択が終われば、選んだ事業社の人員における労務借上げ予約が確実に行われたことになる。事業社から、この予約が完了した（承った）内容の電子文またはメッセージを利用者３又は利用者３の家族への通知を行う。
利用者３又は利用者３の家族は、次回予約した診察日までに、介護タクシー会社や介添人８会社の情報や、看護師５ｂや医師５ａを派遣する会社に電話をして予約する疲労感と煩わしさがなくなる。
ここまでが、診察予約管理システム６２と運行管理システム２１１を利用して、次回診察の予約時に、診察日と通院に必要な車両や介添人や看護師や医師とをほぼ同時に予約することを説明した。

【0326】

ここからは、運行管理システム２１１による、運行管理に必要な時間の算出について説明する。
利用者３が病院４ａに行くために必要な車両や介添人８の労務借上時間（労務拘束する時間）を算出するには、「ナビシステムやインターネットサービスなどの外部システムを利用して、別途取得したルートでの利用者宅から病院４ａまでの移動所要時間を取得」「ナビシステムやインターネットサービスなどの外部システムを利用して、予約時間に間に合わせるための、出発時間を取得」「病院４ａに到着後、受付を行い、診察を受け、会計を行うまでの一連の流れに要する院内所要時間を算出」「ナビシステムやインターネットサービスなどの外部システムを利用して、別途取得したルートでの病院４ａから利用者宅までの移動所要時間を取得」が必要となる。
外部システムから取得した利用者宅から病院４ａまでの移動所要時間の情報を往路の移動所要時間情報とし、外部システムから取得した病院４ａから利用者宅までの移動所要時間の情報を復路の移動所要時間情報とし、予約した診療時間に間に合うように出発する時間の情報を出発時間情報とする。医療機関の院内に滞在している時間である院内所要時間を算出し院内所要時間情報とする。院内所要時間情報は、受付にかかる時間を受付時間情報とし、診察の時間に診察所要時間情報を利用し、会計が済むまでの時間を会計時間情報とを合算した時間が院内に滞在している時間を表す院内所要時間情報となる。さらに、この出発から医療機関で診察を受けて帰宅するまでの合計時間は、介護タクシーや介添人８や看護師５ｂや医師５ａを拘束した労務借上げ時間となり労務時間情報とする。
これらの情報は、運行管理ＤＢ２１４の患者情報に紐づいて運行管理情報に保存されている。

【0327】

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

【0328】

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

【0329】

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

【0330】

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

【0331】

ここまで患者の通院とは別に表面化していなかった車両と介添人８の労務時間の算出を説明した。ここからは、それぞれのトータル（全行程）における時間を算出し、それを運行管理システム２１１に適応することを説明する。
このトータル時間を算出する目的は、利用者の診察が受けられるようにするには複数社の事業社の協力により行われる。算出または取得し運行管理情報に保存した移動所要時間情報や労務借上時間などの時間の情報を利用して予約を受けた複数の事業社との間で連携して、利用者へのサポートが同調して行えるように指示を出す仕組みが運行管理システム２１１にある。本システムが連携させ利用者の通院におけるサポートを複数社の事業社から派遣されてくる全員で行う目的での連携を行う仕組みが必要になる。複数社の事業社から派遣されてくる人員は、１台の車両を介して利用者の通院におけるサポートを遂行する。この１台の車に複数社の事業社から派遣されてくる全員が同乗し利用者をサポートするため各人員の連携が必要になる。まず、複数社の事業社から派遣されてくる全員が揃うための指示が必要となる。運行管理システム２１１は、運行管理として、複数社の事業社び予約の管理と、運行管理情報に保存されている時間の情報を利用して複数社の事業社間の時間の連携と、複数社の事業社から派遣されてくる全員に対し指示を行い、複数社の事業社の管理と複数社の事業社から派遣されてくる人員の管理を行う。
まず、車両（運転手７）の労務時間は、「（１）会社から合流地点（ピックアップ地点）までと、そこから患者宅までの移動所要時間」と、「（２）患者宅から医療機関４までの移動所要時間」と、「（３）患者が医療機関４で受付・診察・会計までの時間」と、「（４）医療機関４から患者宅までの移動所要時間」と、「（５）患者宅から合流地点（ピックアップ地点）までと、そこから会社までの移動所要時間」の合計が労務時間となる。
さらに車両（運転手７）の労務の開始時間すなわち出発時間の算出は、「患者の診療予約時間から往路の所要時間の合計『（１）＋（２）』を逆算した時間となる。
この説明のように車両（運転手７）は、全ての工程を時間通りに進行させる役目を請負った人である。この工程の中で、合流地点で利用者へのサポートを一緒に行う人員をピックアップしなければ工程は進まない。且つ遅れは利用者の予約時間に影響を与える為に許されるものではない。よって会社を出る時間と途中の走行時間が重要となる。車両（運転手７）が会社を出発する時間の情報を会社出発時間情報として求めるには、合流地点（ピックアップ地点）が決まらなければならない。この合流地点（ピックアップ地点）を決めるには、利用者自宅を合流地点とする方法と、会社から利用者宅の間を合流地点とする方法と、会社を合流地点とする方法とに限られる。それぞれの場合の、会社から合流地点までの距離Ａ１と合流地点から利用者宅までの距離Ａ２を「ナビシステムやインターネットサービスなどの外部システムを利用して取得することで取得できる。会社を出発する時間の算出は、利用者宅を医療機関へ向けて出発する時間から、距離Ａ１＋距離Ａ２を法定速度で走行する時間を減算した結果が出発時間となり会社出発時間情報を算出したことになる。運行管理ＤＢ２１４に、運転手が会社を出発する時間の会社出発時間情報が、出発時間情報に紐づいて運行管理情報に保存されている。また、同様に合流地点（ピックアップ地点）へ到着する時間も、距離Ａ１を法定速度で走行した時間を算出し、会社出発時間情報に加算した結果が合流地点（ピックアップ地点）へ到着しなければならない時間として合流地点時間情報を算出したことになる。
運行管理システム２１１は、車両（運転手７）又は車両（運転手７）の事業社に対して、会社を出発する時間（会社出発時間情報）と合流地点へ行く時間（合流地点時間情報）と利用者宅を出発する（出発時間情報）を知らせ連携をとる。
次に、介添人８や医療従事者５の労務時間は、「（１）合流地点（ピックアップ地点）から患者宅までの所要時間」と「（２）患者宅から医療機関４までの所要時間」と「（３）患者が医療機関４で受付・診察・会計までの時間」と「（４）医療機関４から患者宅までの所要時間」と「（５）患者宅から合流地点（ピックアップ地点）までの所要時間」の合計『（１）＋（２）＋（３）＋（４）＋（５）』が労務時間となる。
さらに介添人８や医療従事者５の労務の開始時間の算出は、患者の診療予約時間から往路の所要時間の合計『（１）＋（２）』から逆算した時間となる。
この算出した結果が、運行管理システム２１１に反映される事になる。
車両（運転手７）の労務開始時間と労務時間、介添人８や医療従事者５における労務開始時間と労務時間が、患者が医療機関４内での次回診察予約とほぼ同時に、連携している運行管理システム２１１に何時何分から何時間と登録されることになる。
運行管理システム２１１は、車両（運転手７）を除いた介添人８や医療従事者５又は介添人８や医療従事者５の事業社に対して、合流地点（ピックアップ地点）の場所情報と、時間（合流地点時間情報）とを知らせ連携をとる。
車両及び介添人８等の労務時間の算出方法の概略図を図４７に示す。

【0332】

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

【0333】

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

【0334】

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

【0335】

上記までの説明は、１つの医療機関４における患者さんの移動手段を包括契約でコストを下げる考案であるが、さらに価格交渉を優位にすることができる。
まず、医療機関４は、医療経済圏２４でのプラットフォーム型医療機関支援システム１にある医療情報システム９を利用することと、医療経済圏２４での一定地域の複数医療機関４と連携され、それぞれの複数の医療機関４の患者を対象とすることで、運送包括システムは契約対象の患者数を増やすことができる。契約対象の患者数を増やすことで価格交渉を優位にすることができる。
運送包括システムによる、包括契約を行う処理の流れについて説明する。
第１実施形態で包括契約のリカーリングシステムを説明している。プロセスは変わらない。（１）特殊な方法で来院する患者の移動内容の情報を取得し移動内容を整理し、運行管理ＤＢ６１の包括契約情報に保存する。（２）整理した移動内容の情報（運行管理ＤＢ６１の包括契約情報）を事業社へ提示して見積の作成依頼を行う。見積作成依頼の方法は、メッセージ送信やＷＥＢにより行う。（３）見積回答が返送された見積書に記載されている内容から、包括契約価格を算出して契約価格を並べ替え、契約価格が最小値を提示した事業社を選定する。（３）選定した事業社に対して、電子契約書の作成を行い、ＮＦＴ技術により電子契約書の対象者を紐づけし、電子契約書のソースから複製や契約無視を起こさないようにする。（４）電子契約書の締結を行う。締結は、事業社と運送包括システムと、利用者との間で電子契約書の締結を行う。運送包括システムの締結は、システムが電子契約書を作成した時点で既に行っている。利用者と事業者の締結方法は、ＷＥＢを利用しＷＥＢの契約書締結ページにアクセスして、締結ボタンを押すことで包括契約の締結が完了する。電子契約書の作成方法や締結方法は第１実施形態と変わりはない。
複数医療機関４へと対象を広げることと、第１実施形態によるシステムを利用することで、包括的な交渉が優位になるのは言うまでもない。さらに価格を優位にするには、さらに拡大した地域の範囲にある医療機関４の患者数へと拡大していくことで患者のコストが下がりや、固定客の増加により事業者の経営が安定することに繋がる。さらに運送サブスクリプションシステム２１２よりサブスクリプション契約を利用することで患者の利用の仕方の自由度が広がる可能性もある。
事業社側からすると、契約期間中の固定客を持つことになる。事業者は事業地域を広げることで多くの契約者を持つことが可能となり、経営の安定化に繋がる。患者の通院は、病状にもよるが慢性患者であれば2か月に１回（６回／年）又は3カ月に１回（４回／年）となる。
これにより、移動に用いる車両と介添人８等との労務時間が効率化され、患者は、実際に利用に要する時間に合わせた利用料金で利用でき、無駄な待機時間に対する利用料金を払う必要が無くなる。本システムは、予約手配を、単独の医療機関４や地域内の複数の医療機関４など様々な範囲で包括的に行うために必要な、移動に用いる車両と介添人８等と医療機関４との間の契約を管理する機能も有している。

【0336】

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

【0337】

ここまで、医療機関４で次回診察の予約を行うとほぼ同時に、予約した次回通院時の移動に用いる車両や介添人８、医療従事者５の予約をほぼ同時に行うと説明してきた。
この予約行為は、医療機関４での次回診察の予約を行う予約時に限らず、利用者３の端末（患者の所有する端末）を利用したて行っても良い。この利用者３の端末を利用する場合は、プラットフォーム型医療機関支援システム１にある運行管理システム２１１に接続し予約を行い、その予約とほぼ同時に移動に用いる車両や介添人８、医療従事者５の予約を行ってもよい。利用者３端末を利用した予約とは、すでに行っている診察予約の予約変更や新規の診察予約を行うなどの予約のことを示している。利用者３端末を利用した予約の例として、出願人考案の特開２０２０－１１３１４３に記載の手法などがある。この手法を利用することで、自分のポータル（マイポータル）に端末を利用して接続することで自分に関係することの情報が確認でき変更できるため、マイポータルで予約変更を行うことができる。診察予約の変更を行うと、通常の予約処理と同じように予約可能な事業社が抽出され、その中から選択することで予約変更が可能となる。よって診察予約の変更を行うとほぼ同時に移動手段の変更が行える。

【0338】

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

【0339】

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

【0340】

また、本考案の運行管理システム２１１は、医療機関４への通院だけでなく、通院以外の利用にも、移動手段や介添人８等の予約に用いてもよい。
予約は、患者の所有する端末、又はポータルサイトなどのＷＥＢでアクセスにより行い、予約方法は利用者３端末を利用した医療機関４の予約と同様に行う。患者の所有する端末、又はＷＥＢを用いた予約法の例として、出願人考案の特許第６５５８６６９号に記載の方法がある。ポータルサイトを利用しての特殊な車両と介添人や医療関係者とを予約し利用することで、通院以外の利用を予約することができる。また、ここまでの説明で医療機関への通院を行うには、病状に合わせて医療関係者の付添が必要になるとしていた。これは地域の条例によるもので地域により多少のズレがある。しかしながら、医療機関への通院以外に医療関係者を付き添わせる必要はない。利用者や利用者の家族の判断で医療関係者の付き添いの有無を決められる。

【0341】

本考案のここまでの説明は、移動に用いる手段として介護タクシーや民間救急車などの貸し切り自動車を用いてきた。移動に用いる手段に使う車両は、貸し切り自動車だけでなく、バスや鉄道などの公共交通機関を用いてもよい。公共交通機関を利用する場合、「患者宅から駅やバス停など公共交通機関の乗車場所までの移動手段」「公共交通機関に乗車時の支援」「公共交通機関の降車時の支援」「公共交通機関の乗車場所から目的地までの移動手段」「公共交通機関内での支援」および「公共交通機関の結節点における乗り換え時の支援」のうちから、病状に合わせた手配の処理を本考案の運行管理システム２１１が行う。
手配処理の内容は、公共交通機関の乗車場所や降車場所に乗降の支援を行う（目的）のための人の確保（予約）する処理や、公共交通機関内に患者が乗る場所を確保（予約）する処理を行うなどである。
簡単に説明すると、手配は乗車する車両番号の発車時刻の乗車場所と、到着時刻の降車場所とでの人の予約を行う。
現状のインターネットを利用した公共交通機関（JRなどの鉄道）の乗車券の購入システムでは、車椅子を利用する乗車券の購入や専用予約ができない。特急車両によっては車椅子の乗車が出来ない編成車両や、編成車両のうち一部の車両でしか車椅子の乗車ができない編成車両もある。乗降する場所が決められている。このため車椅子を利用する利用者は、電話で予約を伝えることが行われている。出発時刻と到着時刻時に、乗降場所に人の手配が必要になる。電話で行っていた予約（人の手配や乗車券）をシステムにより公共交通機関へ自動で知らせる。運行管理システム２１１からの通知を行う。又はインターネットのネットワークを利用した乗車券の予約購入システムに、予約ＡＰＩを実装させることにより運行管理システム２１１から車椅子が利用できる車両の乗車券予約とサポートする人の予約（乗車駅と降車駅）を行うことが可能になる。
また、公共交通機関と貸し切り車両とを利用して目的地まで移動する場合、自宅から貸し切り車両を用いて公共交通機関の駅まで移動し、公共交通機関に乗り換えてから目的の駅に到着し、駅から目的地までの貸し切り車両を用いた移動手段を利用する場合、公共交通機関への手配とほぼ同時に車両などの予約処理も行ってもよい。公共交通機関などを利用した場合のイメージを図４８に示す。この公共交通機関を利用できる患者の病状は、通院にストレッチャーを利用する患者には利用することができないのは残念なことである。
運行管理システム２１１による、公共交通機関を利用した移動の予約を行うことができる。運行管理システム２１１は、車両（特殊な車両）と介添人を予約することができるシステムであるため、公共交通機関の予約はできない。公共交通機関や第三者が提供する外部のシステムを利用して行う。第三者が提供する外部システムの例としては、旅行代理店が提供する航空券の予約サイトや発車オ〜ライネット（商標）といった高速バス予約システムなどがある。
運行管理システム２１１は、自宅から公共交通機関に乗り換えるまでの車両（特殊な車両）の予約と、公共交通機関に乗り公共交通機関から乗り換える公共交通機関の予約と、公共交通機関から車両（特殊な車両）に乗り換え目的地まで行く予約を行う。
公共交通機関に乗車している時も介添人の同乗が必要かどうかは利用者が決めることになる。利用者は運行管理システム２１１に端末を利用して接続し、出発地と出発時間と目的地の情報を入れる。出発地情報と目的地情報を、外部システムに引き渡す。処理結果から、出発日の出発時間に出発地から公共交通機関に乗車する駅までの車両と介添人が予約される。車両（介護タクシー）の複数の事業社とその利用料と、介添人の複数の事業社と利用料が表示され、その表示された中から選択を行う。また、目的地に近い公共交通機関の駅から目的地までに利用する車両（介護タクシー）のの複数の事業社とその利用料と、介添人の複数の事業社と利用料が表示され選択により選ぶ。帰りも同様に同じことを行うことで、往復の車両と介添人との予約を行うことができる。
例として、利用者Aさんは運行管理システム２１１に端末を利用して接続し、六本木の自宅から、熱海の温泉ホテルに静養に出かけるための車両と介添人の予約を行う。出発地を入力、家を出る時間を入力、目的地を入力すると、運行管理システム２１１は、患者情報ＤＢ１６１に保存されている利用者Aさんの移動手段情報を参照して移動に必要な車両を認識する。自宅から東京駅までの移動には介護タクシーが選ばれている。利用者Aさんは、普段車椅子での移動である。介護タクシーと介添人の事業社リストと利用料が端末に表示され事業社を選択する。東京駅からは東海道新幹線に乗車し熱海駅で下車することになっている。東京駅から乗る新幹線の車椅子が乗車できる車両が選ばれている。東京駅から乗車する車両番号の列車の乗車位置には乗車をサポートする駅員が手配されている。また熱海駅では降車する場所に降車をサポートする駅員が手配されている。
熱海駅から熱海の温泉ホテルまでの移動として介護タクシーと介添人の事業社リストと利用料が表示され事業社を選択する。これにより行きの分の車両と介添人の予約が簡単に終わったことになる。同様に帰りの分を行えばよい。

【0342】

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

【0343】

第２実施形態の診察予約管理システム６２と本開示の手法を組わせることにより、診察予約した日における、特殊な方法で通院する患者に対する、特殊な車両と介添人８と医療従事者５との予約と、医療機関４で次回診療の予約を一緒に行う予約サービスと、医療機関４で長い時間診察待ちをしないように利用者宅と医療機関４との間の車両の運行管理を行うサービスを行うビジネスモデルを提供するものである。
有料のサービスについて説明する。本考案のシステムを維持する運営費は必要不可欠である。システムの運営費をシステムで賄うビジネスモデルとして提供できるスタイルが望ましい。
医療経済圏を利用する企業が車両（含む運転手）や介添人や医療関係者の労務借上げのスケユールが医療機関にいる患者の診察予約とほぼ同時に人の介在が無しに行えるサービスを有料で提供するビジネスモデルであることによりシステムの運営が行える。
有料化するサービスの内容は、バーチャルな医療経済圏を利用する車両（含む運転手）や介添人や医療関係者の派遣を行う企業に対して、患者からの予約が待受けている状態で自動でスケジュールに入れられる事と、包括契約又はサブスクリプション契約により契約年間における固定客が付き経営安定に繋がる契約である。このサービスを有料で提供する。
従来、電話やホームページによる予約に頼っていた状態から、固定客を持つことができる包括契約又はサブスクリプション契約は魅力的である。本来であれば患者、一人、一人に廻り手間と時間をかけて説明する営業活動を行い固定客としての契約を取ることになるが、営業活動もせず人件費もかけずに根こそぎ地域の固定客を勝ち取りたい企業に対して包括契約又はサブスクリプション契約のサービスを有料で提供する。このサービスの申込は、ＷＥＢを利用しサービス申込ページにより企業からの申込を受けるようにする。包括契約又はサブスクリプション契約は、患者（利用者）と提供する企業との契約により成立するものである。本サービスは、このそれぞれの契約を締結することもサービスの一環である。有料サービスの支払いは既存技術により支払いを行うのでここでは記載はしない。既存技術は、例としてキャッシュレスやＥＣサイトやネット決済や出願人考案の特開２０２１－１１３９２７などである。出願人考案の特開２０２１－１１３９２７を利用する理由は、現在の法定通貨から次世代のデジタル通貨に代わっても、利用方法を変えずそのまま利用できるメリットがある。

【0344】

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

【0345】

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

【0346】

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

【0347】

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

【0348】

このシステムは、医療情報共有データベース２にあるＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１を利用することにより提供される。

【0349】

本開示のシステム「人工多能性幹細胞治療支援システム２２２」の構成について説明する。クラウドベースのバーチャルな環境の中で構成されている「プラットフォーム型医療機関支援システム１」は、システムとデータベースで構成されている。
このプラットフォーム型医療機関支援システム１の全体構成を図１に示す。このプラットフォーム型医療機関支援システム１が扱う情報が保存されているデータベースの構成を図２に示す。
そのうちの１つのシステムが本考案の「人工多能性幹細胞治療支援システム２２２」となっている。この「人工多能性幹細胞治療支援システム２２２」が扱うデータベースは、「ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１」である。
第９実施形態のデータベース構成を図４９に示す。
また、本開示の人工多能性幹細胞治療支援システム２２２のシステム構成図を図５０に示す。
ここに記載されているシステムはその実施形態で説明されているがシステムで作られた情報はデータベースに保存され、必要な情報は、他のシステムからでもデータベースに接続ができ、データベースに保存されている必要な情報を参照（引用）することができる。
人工多能性幹細胞治療支援システム２２２は、情報に接続可能な大きな１つのデータベース（医療情報共有データベース）にある、医療経済圏ＤＢ２１、経理業務ＤＢ３１、医療従事関連ＤＢ２３１の各データベースに保存されている情報も参照し利用している。
ここまでが、システムとデータベースの説明である。
「ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１」の情報には、移植患者情報、移植候補患者情報、人工臓器ＤＮＡ情報、人工多能性幹細胞治療情報、広告情報、臓器マッチ情報、移植患者抽出条件情報、移植臓器未定患者情報、移植治療総括情報、人工臓器契約情報が保存されている。各情報の説明は、情報の使用時 に記載する。
本考案は、人工多能性幹細胞治療支援システム２２２は、移植候補の患者と、その患者のかかりつけ医と、執刀医と手術を行う医療機関と、人工臓器作製事業者２２３により利用され、適合検索（人工臓器と患者の適合）と、情報管理と情報販売と広告を行うものである。
さらに、人工多機能性細胞治療を受けられる患者を１つの医療機関の患者の中から探すよりも広範囲な医療機関の中から探した方が良い、そのため情報基盤のシステムとして展開ができるクラウドベースのプラットフォーム型医療機関支援システム１とした。
人工多能性幹細胞移植治療を受けられる可能性のある患者の抽出について説明する。
患者の診療情報から人工多能性幹細胞移植治療を行える可能性がある患者を抽出することから始まる。その抽出の方法は、「プラットフォーム型医療機関支援システム１と連携している医療機関４が使用している医療情報システム９にある患者の診療情報」と、「プラットフォーム型医療機関支援システム１の電子カルテ９ａにある患者の診療情報」の２つを利用し、病状情報として「臓器不全」などの検索するワード（キーワード）の設定により患者を検索し探す。例として、人工透析患者による臓器は「腎臓器不全」を設定することで、該当する患者がサーチされる。ここでは、人工で作られる全ての臓器への移植を想定しているため、それに該当するワードを設定することで全ての臓器の、臓器に対する患者がリストアップされることになる。この診療情報の中からサーチした患者の情報と、それぞれの患者のかかりつけ医又は担当医の情報も同時に診療情報から取得し、患者の情報にかかりつけ医の情報を紐づけた情報をＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に移植候補患者情報として保存される。この移植候補の患者探しは定期的に行われ、新しくサーチされた情報は移植候補患者情報に追加保存される。
この移植候補患者情報に保存されている患者が、人工多能性幹細胞移植治療を行える可能性がある候補患者の情報（移植候補患者情報）となっている。
さらに、患者のかかりつけ医（主治医）は、人工多能性幹細胞治療支援システムを利用し移植患者抽出条件情報を使用して移植候補患者情報の中にある自分が担当する複数の患者候補の中から人工多能性幹細胞移植治療を行う移植患者を抽出する。
移植患者抽出条件情報は、患者のかかりつけ医が、人工多能性幹細胞治療支援システムを使用して人工多能性幹細胞治療の移植患者を抽出する際の必要な条件を情報として設定した情報で、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に登録し保存する。。移植患者抽出条件情報として登録する条件の内容は、他の病状の有無、年齢範囲、健康状態、精神状態、ワクチン接種歴、過去の手術歴や、医師が気になる事を条件として登録し、さらに医師の判断で条件を追加し登録してもよい。
この条件を医師により登録を行い、人工多能性幹細胞治療支援システム２２２が抽出を行う。この抽出結果から、全患者を対象とするか、又は順番に対応するかの判断をかかりつけ医（主治医）が行い、その判断した情報も含めて、移植を行う患者を移植患者情報として保存される。
移植治療を受ける患者が決まったら、次にIPS細胞が必要となる。
IPS細胞を作成するための情報と適合する人工臓器を抽出する情報として、患者のHLA（ヒト白血球型抗体）やABO式血液型、Rｈ式血液型の血液のデータとＤＮＡデータを移植候補患者情報にある患者の情報に紐づけて登録することが必要となる。
ＤＮＡデータは、研究機関又は医療機関で体細胞から提供してもらい、そのＤＮＡデータを移植候補患者情報に保存されている患者の情報に紐づけて保存する。このＤＮＡデータを保存する作業は、研究機関又は医療機関から端末を使用してプラットフォーム型医療機関支援システム１にある人工多能性幹細胞治療支援システム２２２に接続し、該当する患者のＤＮＡデータを登録する方法や、従来のようにメディア媒体で提供された物からかかりつけ医が自ら情報を登録する方法になる。このＤＮＡデータにより患者に適合する人工臓器を探し出すことになる。
ＤＮＡデータが保存されると、ここからは、患者に適合する臓器を探し出す方法、又は新規に人工臓器作製事業者２２３へ作成の依頼をするする方法、のいずれかの方法となる。
患者に適合する臓器を探し出すには、人工臓器の情報が必要になる。ここからは人工臓器の情報について説明していく。
人工臓器作製事業者２２３による在庫している人工臓器、又は作成中の人工臓器の情報を人工多能性幹細胞治療支援システム２２２のＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１への登録する必要がある。登録する情報の内容は、後に説明している。
また、人工臓器作製事業者２２３へ患者に適合する人工臓器の製造を新規に依頼する内容は後に説明している。
ここでは、既に人工臓器作製事業者２２３等が製造中又は在庫として既にある人工臓器のＤＮＡデータや遺伝子データ及び血液データなどの情報がＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の人工臓器ＤＮＡ情報に登録されており、その人工臓器ＤＮＡ情報を利用して適合を探す方法について記載していく。今後の抽出（マッチング）処理は、患者につけられている患者ＩＤと人工臓器ＩＤにより結果が出てくる。例えば、抽出結果の表示例として、患者ＩＤ「０８７６９」と人工臓器ＩＤ「ＸＦＧＴＡＲＧ」とが、マッチ表示を行い。コンピュータで扱い易いＩＤによる表示である。
適合する人工臓器を探す方法は、２通りある。１つは、かかりつけ医が選定した移植患者情報にある患者のＤＮＡデータに適した人工臓器を探す方法。２つ目の方法は、複数の人工臓器作製事業者２２３が作成した又は作成中の人工臓器に適合する患者を探す方法の２つがある。２つ目の方法は、後で説明している。
プラットフォーム型医療機関支援システム１にある人工多能性幹細胞治療支援システム２２２は、移植候補患者情報から別途定めた条件で適合できる人工臓器を探しだす抽出処理が行われる。
この処理により適合する人工臓器と患者が見つかった場合、人工多能性幹細胞治療支援システム２２２は、適合する患者ＩＤと人工臓器ＩＤを出力する。
適合した患者ＩＤに紐づけられている患者の主治医（かかりつけ医）と適合した人工臓器を所有する事業者に対し通知処理を行う。
事業社の通知先は、医療経済圏ＤＢ２１の企業の事業情報から取得し、かかりつけ医の連絡先は移植候補患者情報の患者情報から取得され、人工多能性幹細胞治療を勧めるメッセージ情報を自動で通知する処理を行う。この通知するメッセージ内容の「人工多能性幹細胞治療を勧めるメッセージ情報」は、テンプレート化された情報を使用して送られる。
人工多能性幹細胞治療を勧めるメッセージの内容は、「患者に適合する人工臓器が見つかりました。次にシステムで執刀医や医療機関を選定してください」といった次に進むことを勧める内容となっている。
この適合の抽出処理に用いる「別途定めた条件」は、患者のHLA（ヒト白血球型抗体）やABO式血液型、Rｈ式血液型の血液データとＤＮＡデータとが、人工臓器作製事業者２２３が所有している（在庫として抱えている）人工臓器のＤＮＡデータとの適合を比較する条件である。
この抽出の際、主治医が移植患者の情報に付加情報に人工多能性幹細胞治療の候補者抽出する際の条件を登録している場合、登録されている条件を追加して候補者の抽出処理を行う。
適合した候補患者とその患者の主治医に、適合する人工臓器が見つかり人工多能性幹細胞治療を勧める情報の通知により、患者が移植治療を受けると決断した場合、患者は人工多能性幹細胞治療支援システム２２２に端末を利用してアクセスし移植治療を受ける表示に同意する操作を行う。
この操作により、人工多能性幹細胞治療支援システム２２２は、患者が移植治療に同意した事から次の処理へと進めていく。
人工多能性幹細胞治療支援システム２２２は、移植治療を行う関係者を探す事と、移植治療を行う移植関係者との情報共有を行う事を進めていく。
移植関係者との間でＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１にある人工多能性幹細胞治療情報の共有を行う。移植関係者とは、患者（含む家族）と患者の主治医と移植治療する医療機関４と執刀する医師５ａ（執刀医）と人工臓器作製事業者２２３と関連事業者のことである。また、関連事業者とは、患者が加入する医療保険を運営する保険会社や患者が治療を受けるための資金を融資する銀行などのことである。
人工多能性幹細胞治療情報にある患者情報に患者（含む家族）と患者の主治医と移植治療する医療機関４と執刀する医師５ａ（執刀医）と人工臓器作製事業者２２３の連絡先を紐づけて登録し、関連事業者の連絡先情報をも紐づけて登録する。
人工多能性幹細胞治療情報とは、患者の人工多能性幹細胞移植治療に関する情報と、人工臓器の製造に関する情報と、移植治療後の日常生活でのモニタリング情報と、携わる患者家族医療関係者全ての連絡先を含めた情報と、関連事業社の連絡先情報とを蓄積した情報のことで、IPSによる作製した人工臓器を使用する移植治療で発生した情報及び治療後の情報のことである。移植治療後の日常生活でのモニタリング情報とは、第３実施形態に記載した手法、すなわち、利用者３（患者）と電子機器７３との会話により日常の測定結果や食事の内容などを取得する方法により取得できる情報のことを示す。

【0350】

人工多能性幹細胞治療支援システム２２２が対象とする臓器は、腎臓、膵臓、肝臓、心臓などの内臓だけでなく、眼球などの体を構成する部位も対象とする。
本考案の人工多能性幹細胞治療支援システム２２２による「人工臓器」としている範囲に、人工臓器にＩＰＳ細胞を用いた製造に、動物を利用したiPS細胞を動物の体のなかで臓器に育ててもらう手法（胚盤胞補完法）の臓器も本考案の対象に含まれる。例として、動物の胚盤胞（はいばんほう）を利用しラット・マウスの胚性幹細胞（Embryonic Stem Cell：ES細胞）により作成された臓器がある。
人工臓器の他にＩＰＳ細胞から作られたＩＰＳ細胞シートも本考案の対象に含まれる。例として。心臓に使う心筋細胞シートがある。
さらに、本考案による「移植治療」としている治療の範囲に、ＩＰＳ細胞シートを使用した治療も含まれる。例として、心筋細胞シートを使用した心臓治療がある。
これらの全てを人工多能性幹細胞治療支援システム２２２が対象としている。

【0351】

かかりつけ医療機関４と移植治療する医療機関４と執刀医と人工臓器作製事業者２２３と関連事業者との間で情報の共有は、セキュリティ対策を行う。セキュリティ対策を移植関係者の間で個別に行うのは、費用の面からもセキュリティレベルの維持の面からも得策ではない。そこで、サービスとして利用者３の個人情報２２の管理を行っている法令に基づき個人情報２２の保管と第三者への提供が行える機関（例えば情報銀行）に情報の管理を委託する、もしくは、本開示のシステムの一部としてセキュリティを担保できるネットワーク上のサーバーを提供することで行う。

【0352】

患者・かかりつけ医・執刀医・医療機関・医療スタッフ・人工臓器作製事業者２２３による情報の共有について説明する。
本開示のシステムは、人工臓器作製事業者２２３が使用している既存技術による人工臓器作製時に使用する情報システム又はプラットフォーム化されたシステムで扱われる様々な情報がある。この様々な情報のうち、細胞の採取検体の個体識別情報と、作成開始から品質管理情報と、生産過程中の品質管理検査データの情報と、生産過程中の検査データの情報と、
生産に関わる進捗情報、トレーサビリティーに関係する情報と、
患者への臓器提供のスケジュール情報と、患者の臓器培養スケジュール情報とが、
移植関係者の間において重要な情報であるため人工多能性幹細胞治療情報の一部として保存し扱うことで情報共有することが必要となる。この情報を取得するために既存技術のＤＸ（データトランスフォーメーション）を使用して行うとよい。このＤＸにより、人工臓器作製事業者２２３の社内の情報も、人工多能性幹細胞治療支援システム２２２が管理している移植関係者との間で共有することができる。すなわちＤＸにより、患者、かかりつけ医、執刀医、医療機関４、移植治療に携われる医療スタッフ、人工臓器作製事業者２２３が情報共有できることになる。
また移植治療関係者により作成され、移植治療関係者との間で情報の共有する医療情報も人工多能性幹細胞治療情報に保存する処理を行い、人工多能性幹細胞治療情報の共有を行う。医療情報には、移植治療を行う医療機関や、執刀する医師や移植治療に携われる医療スタッフの移植治療スケジュール情報や、病床スケジュールの情報も人工多能性幹細胞治療情報に保存する処理を行い、人工多能性幹細胞治療情報の共有を行う。
この共有する人工多能性幹細胞治療情報は、移植治療を行う患者３の医療の個人情報２２となる。その個人情報をサービスとして個人情報２２の管理を行い法令に基づき個人情報２２の保管と第三者への提供が行える機関（例えば情報銀行）を利用し情報の管理委託をする。この情報銀行で情報の共有を行うことが望ましい。もしくは、本開示のシステム（人工多能性幹細胞治療支援システム２２２）の一部としてセキュリティを担保できるネットワーク上のサーバーを提供することで行う。
情報銀行で情報の共有を行う理由は、人工多能性幹細胞治療情報に対して匿名加工処理が行えるためとなっている。情報の内容から本人が特定できないように処理した情報を匿名加工した情報という。また、匿名加工処理を行うことにより、システムは、第三者へ情報を提供できるようになり、後述するサービスによる情報の提供が行えるようにするためとなっている。
また、複数の人工臓器作製事業者２２３が在庫している人工臓器、又は作成中の人工臓器の人工臓器ＤＮＡ情報は、本開示のシステムとプラットフォーム型医療情報システムのＤＸ技術とを用いて「個人情報２２の保管と第三者への提供が行える機関」がもつ人工臓器ＤＢ保存する。個人情報２２の保管と第三者への提供が行える機関がもつ人工臓器ＤＢに保存することで、このデータベースは、１つのプラットフォーム上のデータベースに集約した人工臓器データベースとなる。
このようにデータの一元管理を行うことにより、各移植関係者が使用しているシステムの違いから発生する煩雑な管理が軽減されることが期待できる。

【0353】

患者の主治医がほかの医師５ａに患者の移植治療を依頼する際、患者にとってもっとも良い治療を行え、かつ信頼できる医師５ａに依頼したいと考えている。信頼できる医師５ａの選定方法の１つとして第１０実施形態に記載する医療従事者５の評価結果を用いることができる。
ここまで、患者の移植治療に関する情報、すなわち人工多能性幹細胞治療情報を移植関係者の間で共有と、人工臓器作製事業者２２３の情報も人工多能性幹細胞治療情報に保存し共有することと、セキュリティの担保について説明した。
ここからは、移植治療に関わる移植関係者の選定について説明する。
移植治療をかかりつけ医が実施できる場合は、かかりつけ医の医療機関４で移植治療を行うため、このかかりつけ医と医療機関４の医療スタッフが移植関係者になるため選定を行うことは無くなる。かかりつけ医が移植治療を行えない場合が選定となる。
かかりつけ医は、患者の移植治療を行うために、執刀する医師５ａと、手術を行う医療機関４と、移植治療に携われる医療スタッフとを選定する必要がある。但し、医療スタッフは医療機関４側での従業員を使用する場合が多い。よって医療スタッフだけを選定するケースは少ない。この選定には、患者とかかりつけ医が、端末を利用して人工多能性幹細胞治療支援システム２２２が用意する、ＷＥＢの関係者選定ページにアクセスして選定を行う。
人工多能性幹細胞治療支援システム２２２は、執刀する医師５ａ、手術を行う医療機関４、移植治療に携われる医療スタッフを選定するために、第１０実施形態に記載の医療従事者５の評価結果を利用して端末の画面に表示している。さらに、この画面に表示されている対象には、予めシステム側でフィルターをかけている。このフィルターは、患者の住まいに近い医療機関まで出向き移植治療が行える執刀医、このシステムを利用して移植治療の実績がある執刀医の一覧が画面に表示されている。また患者の住まいを中心に移植治療が行える医療機関と、このシステムを利用して移植治療の実績がある医療機関の一覧が、画面に表示されている。利権を無くすためシステムで予めフィルターをかける。画面に表示された一覧の中から最終的に、選択するのは患者とかかりつけ医とで行う。
人工多能性幹細胞治療支援システム２２２は、移植治療を行う医療機関４などの選定に、医療従事関連ＤＢ２３１に保存されている移植治療を行った実績のある医療機関４の情報と、医療情報共有データベース２の経理業務ＤＢ３１に保存されている設備機材情報から移植治療を確実に行える医療機器を所有している医療機関４の情報とから医療機関４の選定をするための情報として端末に表示している。この端末に表示された情報から医療機関４を選定することになる。また医療機関４を選定すると移植治療をサポートしてくれる医療機関４の看護師はじめ医療スタッフも必然的に選定されたことになる。
人工多能性幹細胞治療支援システム２２２は、人工臓器作製事業者２２３の選定に、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の移植候補患者情報にある患者の血液データと前記人工臓器作製事業者２２３が製造した臓器を保有している人工臓器のＤＮＡデータや遺伝子データ及び血液データとの照合処理を行い一致した場合に、その製造した臓器を保有している人工臓器作製事業者２２３を選定する処理を行う。この場合の人工臓器作製事業者２２３が社内で所有している人工臓器のＤＮＡデータや遺伝子データ及び血液データの情報を情報共有して照合処理を行う。この情報共有については、ＤＸ技術を利用して行う情報共有として説明しているので、ここでは割愛する。人工臓器作製事業者の選定時に、医療経済圏ＤＢ２１にある医療経済圏２４を利用する企業の事業情報に保存されている人工臓器作製事業者２２３の情報を取得し、この情報には、企業名や連絡先、担当者などが含まれている。この人工臓器作製事業者２２３の情報を、患者とかかりつけ医の端末に表示する。
ここまで説明した選定により、人工多能性幹細胞治療支援システム２２２を介して、選定される側の情報を利用したコンピュータ処理も交えた選定を行うことで利権が働かない選定ができる。
ここまで選定した、医師５ａや看護師５ｂ、医療機関４、人工臓器作製事業者２２３は、患者の移植治療を優先し情報から選定したため、相互に利権が働ない形での選定となる。利権に関して、例をあげると、先輩医師や医療機関からの圧力や、人工臓器作製事業者２２３から医師５ａへのキックバックがないこと確認できている組み合わせや利害関係（たとえば、当該医師５ａが人工臓器作製事業者２２３の出資者や役員など）がない組み合わせで選定を行う。

【0354】

人工多能性幹細胞治療支援システム２２２による、人工臓器作製事業者２２３の選定について説明した。
適合する臓器が事業者に無い場合、改めて患者に適合する臓器作製を事業者に依頼し、作成ができたら移植治療を行うまでの内容を記載する。まず必要とする人工臓器を作成している人工臓器作製事業者２２３の選定を、人工多能性幹細胞治療支援システム２２２による行う。選定した人工臓器作製事業者２２３の情報を人工多能性幹細胞治療情報に保存する処理を行う。人工臓器作製事業者２２３に対して患者の自身の血液と一部の皮膚を提供し、ＤＮＡデータを共有することになる。共有の方法は既に説明している。人工臓器ができるまでに数年を要する場合がある。この製造過程を見るために人工臓器作製事業者２２３の情報が必要となる。この情報により作成過程を見ていくことができる。作製の完了が見えてきた頃に、執刀医や移植治療を行える医療機関や移植治療に携われる医療スタッフの選定を行う。この選定の方法は既に説明をした。

【0355】

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

【0356】

人工多能性幹細胞の移植治療は、最先端の治療のため、患者の費用負担が多い治療となることが予想される。さらに、従来から医療産業のコストは高額のためより一層患者の費用負担が多い治療となることも予想される。再生医療へ参入し、移植治療を行う執刀医や医療機関、人工臓器作製事業者２２３を増やすことを目的に、再生医療参入者の知識を取得するための情報提供や、さらに再生医療自体が改善し進化してうけるように情報を提供と共有をしていくことと、人工多能性幹細胞治療支援システム２２２には、人工多能性幹細胞の移植治療における患者が負担する費用を下げることと、
人工多能性幹細胞治療支援システム２２２とＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の運営を長期に渡り維持しなければならない責任がある。その責任を果たすには、運営費の確保もある。そのためプラットフォーム型医療機関支援システム１にあるシステムでは、システムの持続化を行うために収益化できるサービスを備えている。ここからは持続化を目的としたサービスについて説明していく。
人工多能性幹細胞の移植治療は、最先端の治療のため、患者の費用負担額が多い治療となることが予想される。さらに、従来から医療産業のコストは高額のためより一層患者の費用負担が多い治療となることも予想される。
人工多能性幹細胞治療支援システム２２２には、人工多能性幹細胞の移植治療における患者が負担する費用を下げることと、人工多能性幹細胞治療支援システム２２２とＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の運営を長期に渡り維持しなければならない目的の運営費の確保もある。そのためプラットフォーム型医療機関支援システム１にあるシステムでは、システムの持続化を行うために収益化できるサービスを備えている。ここからは持続化を目的としたサービスについて説明していく。
ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に保存されている人工多能性幹細胞治療情報には重要な情報が保存されている。
人工多能性幹細胞治療情報に保存されている貴重な情報には、医療関係側の情報と人工臓器生産者側の情報の２種類がある。
医療関係側の情報として、「移植治療中の診療情報」、「移植治療に関わった医師や医療機関スタッフの情報とそれらによる患者を診察した診療情報」、「IPSによる作製した人工臓器の移植治療での治療実績情報」、「移植手術中の映像」、「患者の移植治療の前と後の身体機能や血液データ・肝機能データ・心電図データ・MRIデータ・CTデータ・体重の前と後の検査値の変化情報」、「移植治療スケジュールの情報」、「病床スジュールの情報」とがある。
人工臓器の生産者側の情報として、「人工臓器作製事業者２２３での臓器作製情報として、細胞の採取検体の個体識別情報」、「人工臓器作製開始からの品質管理情報」、「生産過程中の検査データの情報」、「生産過程中の品質管理検査データの情報」、「生産に関わる進捗情報」、「トレーサビリティーに関係する情報」、「移植治療における治療前と治療後の情報が詰まった移植治療に成功した情報」、「患者への臓器提供のスケジュール情報」、「患者の臓器培養スケジュール情報」とがある。
「人工臓器作製開始から品質管理情報」とは、人工臓器の作製を始めて定期的に行う臓器事業社社内で定義している品質管理の内容を情報化した物である。
「生産過程中の検査データの情報」とは、過程中の品質を確認するために行う検査内容や検査方法のデータである。「生産過程中の品質管理検査データの情報」とは、過程中に定期的に行う品質を管理するために行う検査の検査結果のデータである。「生産に関わる進捗情報」とは、生産中の品質検査から製作過程の進捗具合を表した情報である。「トレーサビリティーに関係する情報」とは、培養に使用した採取細胞の入手先と入手方法と出来上がった人工臓器の輸送先と利用者と輸送方法の情報である。
「移植治療における治療前と治療後の情報が詰まった移植治療に成功した情報」とは、治療前及び治療後における患者の様々な医療検査データや病状日誌や食事内容や身長体重排泄回数の情報である。
「患者への臓器提供のスケジュール情報」とは、かかりつけ医と患者が患者に合った人工臓器を探した日から移植治療を行う日までの人工臓器作製事業者の社内スケジュールの情報である。「患者の臓器培養スケジュール情報」とは、かかりつけ医と患者が患者に合った人工臓器の培養を依頼した日から移植治療を行う日までの人工臓器作製事業者の社内スケジュールの情報。
これらの情報は、人工多能性幹細胞治療支援システム２２２によりＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の「移植治療総括情報」として保存されている。
移植治療総括情報が貴重な情報である理由は、移植治療中の診療情報と移植治療前後の検査データ情報と移植手術中の情報と生産者側の全ての工程が見られるスケジュール情報と品質情報や検査情報が含まれている。いわゆる、今迄にない、医療側と生産者側の情報がスケジュールという時系列になっている情報であることと、生産者側の社内の情報は今までに社外には出てこないことからこそ貴重となっている移植治療総括情報である。
但しこの情報は情報銀行相当で扱っているため匿名加工が施されている。
人工多能性幹細胞治療支援システム２２２は、この情報を、これから人工多能性幹細胞治療支援システム２２２を使用した移植治療を行う患者への移植治療プロデユースの検討をはじめている開業医、又は治療はできるものの人工多能性幹細胞治療支援システム２２２を使用する移植治療の患者に対しても活路を広げようとしている執刀医、又は人工多能性幹細胞治療支援システム２２２を使用した移植治療が行える設備や施設の提供を検討している医療機関４、または人工多能性幹細胞治療支援システム２２２を使用したＩＰＳ細胞による人工臓器提供への参入を検討している人工臓器作製事業者２２３に対して販売を行う。
この販売により、これから移植治療を行う患者への移植治療プロデユースの検討をはじめている開業医、又は治療はできるものの移植治療の患者に対しても活路を広げようとしている執刀医、又は移植治療が行える設備や施設の提供を検討している医療機関４、またはＩＰＳ細胞による人工臓器提供への参入を検討している人工臓器作製事業者２２３は、人工多能性幹細胞治療支援システム２２２を使用した移植治療のノウハウ（知識）の習得を行う。
また、この販売により、得た収益を患者が負担する費用の削減と医療機関４への収益と本考案のシステムの維持運営のそれぞれに充て処理を行う。ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１内に保存されている既に移植治療を実施し成功した患者の治療に関する情報は、治療前後の診療情報、病状の情報、臓器作製情報、治療方法に関する動画情報、治療実績情報なども含まれている。
販売を行うために、既存技術であるＷＥＢサーバーによる販売や、ＥＣサイトによる販売となる。いずれの販売にしても、商品である情報を購入側へ送る際に人工多能性幹細胞治療支援システム２２２は、情報を提供する際、患者の治療に関する人工多能性幹細胞治療情報は、非代替性トークン（NFT）により、情報ソースと情報の所有者である患者とかかりつけ医と手術をした医療機関４と執刀した医師５ａ等と情報の購入者又は複数の情報の購入者とを紐づけて権利の管理を行い、情報の複製を抑制する。NFTを利用した情報の管理方法は、後記する第１１実施形態に記載されているので、ここでは説明を割愛する。
また、患者の治療に関する情報は、患者の匿名加工したうえで、セキュリティの担保ができるサーバー又は法令に基づき個人情報２２の保管と第三者への提供が行える機関を使用して購入者が情報を閲覧できるようにしてもよい。

【0357】

さらに 人工多能性幹細胞治療支援システム２２２には、収益を得るサービスがある。人工多能性幹細胞治療支援システム２２２を使用して、移植治療をプロデュース実績の患者のあるかかりつけ医、移植治療実績のある執刀医、移植治療実績のある医療機関、移植治療実績のあるスタッフと、人工臓器の提供実績のある人工臓器作製事業者２２３を対象としたサービスがある。
このサービスは、人工多能性幹細胞治療支援システム２２２には、人工多能性幹細胞の移植治療の実績のある医師５ａや、医療機関４や、人工臓器作製事業者２２３がさらなる業績を上げる事を目的とした広告の依頼を請負う機能（サービス）がある。
移植治療実績のある医師５ａ（執刀医）、移植治療実績のある医療機関４、人工臓器の提供実績のある人工臓器作製事業者２２３等は、さらに実績や業績を上げるために、これから移植治療を行う患者やそのかかりつけ医から選定されるように人工多能性幹細胞治療支援システム２２２が広告をとりはからうサービスである。この有料サービスに申し込みは、人工多能性幹細胞治療支援システム２２２の広告受付ＷＥＢページにアクセスして申込を行う。この有料サービスに申し込みをした場合の処理について説明する。このサービスの申込は、人工多能性幹細胞治療支援システム２２２を使用して移植治療実績のある医師５ａ、医療機関４、人工臓器の提供実績のある人工臓器作製事業者２２３による、人工多能性幹細胞治療支援システム２２２へアクセスした時にこのサービスの申込を行うスイッチを入力することで申し込みが行われる。
移植治療を行う患者のかかりつけ医が、執刀医や医療機関４や人工臓器作製事業者２２３の選定を端末を使用し人工多能性幹細胞治療支援システム２２２ に接続して行う際に、サービスの申込をした実績ある執刀医や医療機関４や人工臓器作製事業者２２３については人工多能性幹細胞治療支援システム２２２が推奨する執刀医や医療機関や人工臓器作製事業者２２３として端末の画面に表示する処理を行う。
人工多能性幹細胞治療支援システム２２２による、広告内容の受付は端末を利用して広告申込をした執刀医（医師５ａ）、医療機関４、人工臓器作製事業者２２３がアピールしたい内容の登録を行う。
医師の場合は、ＷＥＢにあるアピール情報登録ページより医師がアピールしたい内容を入力し登録する。ＷＥＢページで登録したアピールしたい内容は、医師アピール情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１内の広告情報に保存される。人工多能性幹細胞治療支援システム２２２は、医師アピール情報と、医師の実績回数（人工多能性幹細胞治療情報から取得した移植治療を計算処理した回数）の情報と、医師が移植治療をした患者の回復までの期間を診療情報から取得した情報と、医師が移植治療をした患者の入院期間を診療情報から取得した情報とを、医師に紐づけた広告資料情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１にある広告情報に保存する。この広告情報が、執刀医のさらなる実績をあげるための広告情報となる。
医療機関４の場合は、ＷＥＢにあるアピール情報登録ページより医療機関４としてアピールしたい内容と、移植治療を行う医療設備と医療機関の施設と医療スタッフとの紹介を入力し登録する。又は、医療機関側からのアピール内容として、移植治療を行う医療設備と医療機関の施設と担当する医療スタッフの紹介をまとめて作った動画の情報を登録しても良い。
ＷＥＢページで登録したアピールしたい内容は、医療機関アピール情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１内の広告情報に保存される。ＷＥＢページで登録した医療施設を紹介する内容や動画は、医療機関施設紹介情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１内の広告情報に保存される。
人工多能性幹細胞治療支援システム２２２は、医療機関アピール情報と医療機関施設情報と医療機関の実績回数（人工多能性幹細胞治療情報から取得した移植治療を計算処理した回数）の情報と、医療機関で移植治療をした患者の回復までの期間を診療情報から取得した情報と、医療機関で移植治療をした患者の入院期間を診療情報から取得した情報とを、医療機関４に紐づけた広告資料情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１にある広告情報に保存する。この広告情報が、医療機関のさらなる実績をあげるための広告情報となる。
人工臓器作製事業者２２３の場合は、ＷＥＢにあるアピール情報登録ページより人工臓器作製事業者２２３としてアピールしたい内容と人工臓器の作成までにかかる期間と人工臓器作製事業者２２３の会社説明と品質に関する紹介も入力しそれぞれ登録する。ＷＥＢページで登録したアピールしたい内容は、人工臓器作製事業者アピール情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１内の広告情報に保存される。ＷＥＢページで登録した人工臓器の作成までにかかる期間は、人工臓器作製期間情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１内の広告情報に保存される。ＷＥＢページで登録した人工臓器作製事業者２２３の会社説明と品質に関する紹介は、人工臓器事業者紹介情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１内の広告情報に保存される。
人工多能性幹細胞治療支援システム２２２は、人工臓器作製事業者アピール情報と人工臓器作製期間情報と人工臓器事業者紹介情報とを、人工臓器作製事業者２２３に紐づけた広告資料情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１にある広告情報に保存する。この広告情報が、人工臓器作製事業者２２３のさらなる実績をあげるための広告情報となる。
この広告資料情報の中に計算処理した実績回数がある、この実績回数は非常に重要な値である。例えば医師の場合、医師の経験値が移植治療の実績回数で表わされたものである。医療機関で働いている医師の経験値を目にすることは無い、それをシステム上で経験値を表示したものである。また医療機関も同様でこの病院の医療設備で治療を患者が受けたい、この医療機関のスタッフのケアを患者が受けたいと選ばれた回数が実績回数として表示される。患者に選ばれた医療機関の回数は貴重である。人工臓器作製事業者も同様に患者が選んでくれている回数があからさまに数字としてでる。この実績回数を表示することはコマーシャル的に効果がある。
患者やそのかかりつけ医が、人工多能性幹細胞治療支援システム２２２を使用した選定時に、この広告依頼を受けた執刀医や医療機関や人工臓器作製事業者２２３の広告資料情報を端末に表示する。
執刀医を選定する時に、実績ある医師を紹介する実勢広告ページに「広告情報」が表示され、医療機関４を選定する時に、実績ある医療機関を紹介する実勢広告ページに「広告情報」が表示され、人工臓器作製事業者２２３を選定する時に、実績ある人工臓器作製事業者を紹介する実勢広告ページに「広告情報」が表示される。
患者やそのかかりつけ医は、端末に表示された実績のある執刀医や医療機関や人工臓器作製事業者２２３の広告資料情報を見て選定することが可能となる。また、実績やアピールが表示されていない執刀医や医療機関や人工臓器作製事業者２２３を選定することも可能である。
この申し込みによる人工多能性幹細胞治療支援システム２２２による広告の対応は有料であり、一定期間又は一定回数の表示により解除される。このサービスの利用料は、既存技術の支払い方法で対応する。実績のある執刀医や医療機関や人工臓器作製事業者２２３は追加で申し込むことは可能である。
ここまで、本考案のシステムを利用し実績のある執刀医や医療機関や人工臓器作製事業者２２３の広告請負について説明した。ここから、実績が無く、この移植治療を始める執刀医や医療機関や、本考案のシステムを利用したことの無い人工臓器作製事業者２２３に対して、これから実績を上げる事を目的とした同様の広告サービスについて説明する。
他の治療においては認知されていて有名であっても、初めて移植治療を始める執刀医や医療機関にとっては、認知も公知もされていない。まずは広く知ってもらうことが重要となる。
移植治療を始める執刀医や医療機関は、患者やかかりつけ医に対して、医師として専門分野、執刀医として移植治療以外での実績、医療機関として地域からの治療の認識内容、医療機関として誇る治療設備と移植治療を行う理由により任せてもらっても安心だという事を知ってもらい実績と収益を狙う事が目的で広告を依頼するものである。
本考案のシステムを利用したことの無い人工臓器作製事業者２２３は、患者やかかりつけ医や執刀医や医療機関に対して、会社概要、社内の製造品、衛生内容、安全内容、品質管理内容、人工臓器製造方法、人工臓器製造期間、製品価格、実績のある他社との差別内容、他社と遜色無く利用してもらえる事を知ってもらう。従来この分野はＭＲ（薬剤情報提供者）や営業員が一軒一軒医療機関に足を運び医師に説明をしている事が昭和から現在でも続いている。こういった事が本考案を利用することで対象となる患者や医師にピンポイントで行えることになる。よって、ＭＲや営業員の人件費が削減されるため、削減した人件費を製品費に反映することで製品費が下がり医療費自体を下げることに繋がる。医療分野が高額なのはこういった昔ながらの展開を行う人件費の積み重ねによるものである。
こういった移植治療に参入またはシステムの利用を始める執刀医や医療機関や人工臓器作製事業者２２３から、サービスを受け付ける事ができるようになっている。
人工多能性幹細胞治療支援システム２２２は、システムの利用をＷＥＢサービスで受け付けている。ここからは従来の方法となってしまうが、ＷＥＢサービスの受付ページを用意し、このＷＥＢサービスの受付ページに端末を利用して接続し、個人情報を登録し、システムからアクセスするための諸情報を取得し、その内容により利用が可能となる。アクセスするための諸情報はテンプレート化されている情報でアクセスを行う方法の内容が記載されている。本考案のシステムを初めて利用する医師（執刀医）や医療機関にとっては、本システムを利用した実績が無い。
本システムを初めて利用する医師（執刀医）や医療機関は、本システムを利用して移植治療を行った実績はゼロであると患者やかかりつけ医の端末に公開される。
実績が無いことから、患者やかかりつけ医から選定される確率は低い。そのため本システムを始めて利用する執刀医や医療機関や人工臓器作製事業者２２３からの情報提供を受付けて、その情報を患者やかかりつけ医の端末に公開するサービスを用意している。このサービスを利用するには、ＷＥＢサービスを介して情報を登録することになる。この患者やかかりつけ医に公開する情報の内容は、執刀医や医療機関の場合は、患者とかかりつけ医から安心して選んでもらえるように、人工臓器作製事業者２２３も場合は患者とかかりつけ医と執刀医と医療機関から安心して選んでもらえるような内容の情報を公開（広告）することにある。
それぞれが情報を登録する方法は、医師の場合、医師として専門分野、医師として移植治療以外での実績、移植治療を行う理由、移植治療を任せても安全な理由の内容をＷＥＢページを介して登録し、人工多能性幹細胞治療支援システム２２２は、登録された内容を、医師として専門分野情報、医師として移植治療以外での実績情報、移植治療を行う理由情報、
移植治療を任せても安全な理由情報とし、これらの情報は医師に紐づけた広告資料情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１にある広告情報に保存される。この広告情報が、執刀医として選定してもらうための広告情報となる。
医療機関の場合は、医療機関として専門治療、地域からの治療認識状況、医療機関として誇る治療設備、移植治療を行う理由や移植治療を任せても安全な理由の内容をＷＥＢページを介して登録し、人工多能性幹細胞治療支援システム２２２は、登録された内容を、医療機関として専門治療情報、地域からの治療認識状況情報、医療機関として誇る治療設備情報、移植治療を行う理由情報や移植治療を任せても安全な理由情報とし、これらの情報は医療機関に紐づけた広告資料情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１にある広告情報に保存される。この広告情報が、医療機関として選定してもらうための広告情報となる。
また、人工臓器作製事業者２２３の場合は、会社概要、社内の製造品、衛生内容、安全内容、品質管理内容、人工臓器製造方法、人工臓器製造期間、製品価格、実績のある他社との差別内容、他社と遜色無く利用してもらえるアピール内容を、ＷＥＢページを介して登録し、
人工多能性幹細胞治療支援システム２２２は、登録された内容を、会社概要情報、社内の製造品情報、衛生内容情報、安全内容情報、品質管理内容情報、人工臓器製造方法情報、人工臓器製造期間情報、製品価格情報、実績のある他社との差別内容情報、他社と遜色無く利用してもらえるアピール内容情報とし、これらの情報は人工臓器作製事業者２２３に紐づけた広告資料情報として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１にある広告情報に保存される。この広告情報が、人工臓器作製事業者２２３として選定してもらうための広告情報となる。
ここに登録された広告情報にある広告資料情報を広告内容として公開する方法と、人工多能性幹細胞治療支援システム２２２を使用して移植治療を行う執刀医や医療機関を選定する時に情報を公開する事と、患者の人工臓器の作成依頼をする際に人工臓器作製事業者２２３の情報を公開し選定前の１社に加えることになる。情報の公開期間により広告を行うサービスを有料で行う。このサービスの利用料は、既存技術の支払い方法で対応する。

【0358】

移植候補患者情報を利用した広告の例を示す。
人工多能性幹細胞治療支援システム２２２は、人工腎臓移植治療の実績（経験）のある医師５ａ（執刀医）からＷＥＢページより広告の依頼を受けたとする。人工多能性幹細胞治療支援システム２２２は、移植候補患者情報に登録された履歴から実績があると判断する。
人工多能性幹細胞治療支援システム２２２は、医師５ａ（執刀医）の広告資料情報から実績回数、移植治療をした患者の回復期間、患者の入院期間、執刀医のアピールを端末に表示する。この表示は、患者やかかりつけ医が端末を利用して医師５ａ（執刀医）を選定するために人工多能性幹細胞治療支援システム２２２を利用した時に、端末に表示される。患者やかかりつけ医が、表示されている実績のある医師５ａ（執刀医）を選定しても良いし、他の広告情報が表示されない医師５ａ（執刀医）を選定してもよい。
また、新規に人工多能性幹細胞治療支援システム２２２に新規に登録し、広告サービスの申込をしていた。この時に患者やかかりつけ医が、人工臓器作製事業者２２３を選定する時に、端末の画面には、この人工臓器作製事業者２２３が登録した広告資料情報が表示される。患者やかかりつけ医は、広告資料が表示された人工臓器作製事業者２２３を選定することができる。企業情報や品質情報などの広告資料が表示されない人工臓器作製事業者２２３を選定することもできる。

【0359】

人工多能性幹細胞治療支援システム２２２の別のサービスについて説明する。
移植治療を受ける患者自身に適合する人工臓器がなければ、いつまでたっても人工臓器作製事業者２２３に在庫としてある人工臓器の出番は無い。このサービスの概要は、従来の逆の発想による客（患者）を見つけに行くものである。人工臓器作製事業者２２３に在庫としてある人工臓器又は製造中の人工臓器に適合する患者を探すサービスである。
このサービスを提供する人工多能性幹細胞治療支援システム２２２は、ＷＥＢページにこのサービスを受け付けるページがある。人工臓器作製事業者２２３は、このＷＥＢページよりサービスの利用申込みを行う。自社が在庫している人工臓器に適合する患者の情報が欲しい場合は、人工臓器の情報を人工多能性幹細胞治療支援システム２２２に提供することになる。人工臓器の情報を提供する人工臓器情報登録ＷＥＢページで、自社の在庫として管理している人工臓器のロット番号（製品シリアル番号）とその番号のＤＮＡデータや血液データをセットとして、順番に記載又は転載、又は予め作っておいた定型フォームに情報を記載した情報（例えばエクセルシート上のフォームに記載した情報）を人工臓器情報登録ＷＥＢページに登録することで、人工臓器の情報提供は終わる。
人工多能性幹細胞治療支援システム２２２は、人工臓器情報登録ＷＥＢページ登録された情報の1つ1つを人工多能性幹細胞治療支援システム２２２で管理する人工臓器ＩＤ番号で管理する。この人工臓器ＩＤ番号に人工臓器作製事業者２２３が登録した人工臓器のロット番号（製品シリアル番号）とその番号のＤＮＡデータや血液データと会社名情報をセットで紐づけて、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に人工臓器ＤＮＡ情報に保存する。
この状態で、人工臓器ＤＮＡ情報にある人工臓器作製事業者２２３の人工臓器のＤＮＡデータや血液データと、移植候補患者情報にある患者のＤＮＡデータ又は血液データの情報が揃ったことになる。人工多能性幹細胞治療支援システム２２２は、人工臓器ＤＮＡ情報にある人工臓器のＤＮＡデータや血液データと、移植候補患者情報にある患者のＤＮＡデータ又は血液データとを比較する処理により、ＤＮＡデータが一致した適合する患者をサーチすることができる。比較する処理後、人工多能性幹細胞治療支援システム２２２は、一致した人工臓器ＩＤに対する患者ＩＤを紐づけた「臓器マッチ情報」として、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に保存する。臓器マッチ情報には、患者の個人情報は含まれていない、患者ＩＤだけとなっている。
この臓器マッチ情報を、人工多能性幹細胞治療支援システム２２２が、人工臓器作製事業者２２３に適合結果として、適合結果ＷＥＢページで臓器マッチ情報を表示、又は臓器マッチ情報をダウンロードする形で提供し、この適合結果を人工臓器作製事業者２２３に渡したことでサービスは一旦終了となる。臓器マッチ情報を受け取った人工臓器作製事業者２２３は、適合内容を確認し今後の戦略を練る形となる。前に進むには、この適合する患者とかかりつけ医にコンタクトを取ることで在庫を無くせる第一歩になる。そのために、人工多能性幹細胞治療支援システム２２２は、適合患者やかかりつけ医へのアポイントサービスを提供している。引き続き適合患者やかかりつけ医へのアポイントサービスを利用するには、アポイントサービス申込ＷＥＢページで申込を行う。
申込を受けた人工多能性幹細胞治療支援システム２２２は、臓器マッチ情報にある患者ＩＤの患者への連絡先と、そのかかりつけ医の連絡先を移植候補患者情報から取得する。患者に適合する人工臓器がある旨の内容が書かれたメッセージをテンプレートから取得して、患者とかかりつけ医に通知して、移植治療の検討をしてもらう。この通知した履歴の情報をアポイント情報としてＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に保存する。保存したアポイント情報はサービスの依頼を受けた人工多能性幹細胞治療支援システム２２２へ通知する。事業者の通知先は、医療経済圏ＤＢ２１の企業の事業情報から取得して通知する。この適合患者をサーチするサービス、適合した患者とかかりつけ医に適合した人工臓器がある事を知らせるサービス、この２つのサービスも有料で行われる。
このサービスの利用料は、既存技術の支払い方法で対応する。

【0360】

人工臓器作製事業者２２３に対して、任意の患者への人工臓器の製造計画を提供するサービスについて説明する。
ここまでは、患者に適合する人工臓器が人工臓器作製事業者２２３に在庫してある場合や製造中の場合、在庫して抱えている臓器に適合する患者が居る場合について説明してきた。人工臓器作製事業者２２３に在庫している人工臓器に適合する患者を探し出しても、それでも適合しない患者は大勢いる。
さらに、完成まで長い年月がかかる人工臓器を、これから移植治療を行いそうな患者を我先にと探し出し、その患者用に人工臓器を作ることをセールスし前倒しで作るというものである。いわゆる客を先に見つけて、その客用の商品を作る約束（契約）をして人工臓器作製事業者２２３の業績を助けるサービスである。移植候補患者情報の中から、移植治療を行うか決まってない患者、または、患者に適合する人工臓器がまだ決まっていない患者を探し出し、この探し出した患者の情報が必要となる。この情報にある患者の人工臓器を長い年月をかけて作成しても、その患者が他社の人工臓器を使用して移植治療を受けてしまっては意味がないため、患者へのアポイントは必要となり、患者との契約により無駄は無くなる。このことにより人工臓器作製事業者２２３にとっては、確実な生産スケジュールを建てられることと、このスケジュールにより確実な収益計算ができる。よって、このサービスは、移植を行うか決まってない患者または患者に適合する人工臓器が決まっていない患者の情報を販売（提供）すること、任意の患者へのアポイントと、その患者へ人工臓器を提供することに承諾を得た患者との契約を交わすことと、その契約書の管理を行う有料のサービスである。
人工臓器作製事業者２２３は、在庫していた人工臓器に適合する患者への提供の見込みが立てられると、適合が無い患者への臓器の製造を行うことで事業拡大に繋がる事に気付く。患者の中には、どこかの人工臓器作製事業者２２３へ製造の依頼を約束し契約をしている患者も出てくることが考えられる。人工臓器作製事業者２２３は、患者がいればその患者に合わせた人工臓器を製造することで在庫を抱えることが無くなる。いわゆる人工臓器のカスタマイズ製造を行うことができる。人工臓器作製事業者２２３からすると、これから移植治療を行う計画となっていない患者と、人工臓器作製事業者２２３と人工臓器の製造契約を結んでいない患者、いわゆる将来に人工臓器の行方が未定である患者がどれくらいいるかが判明することで、人工臓器作製事業者２２３とって事業計画が立てられる。人工臓器の製造には何年もかかるため、将来に人工臓器の行方が未定である患者とそのかかりつけ医に対して早期にアポイントを取り、将来の人工臓器を提供する約束する契約を交わすことで人工臓器作製事業者２２３は無駄なく製造でき事業拡大が見込める。さらに生産スケジュールを建てられることと、このスケジュールによりロスの無い確実な収益計算ができる。
人工多能性幹細胞治療支援システム２２２は、人工臓器作製事業者２２３に対するサービスとして、将来に人工臓器の行方が未定である患者の情報（個人情報は含まれていない情報）を提供（販売）するサービスと、患者とそのかかりつけ医にアポイントを取り仲介を行うアポイントサービスと、人工臓器の提供に承諾した患者との契約（電子契約）を請負うサービスと、その電子契約の管理を行うサービスを用意している。
このサービスを提供する人工多能性幹細胞治療支援システム２２２は、ＷＥＢページにこのサービスを受け付けるページがある。人工臓器作製事業者２２３は、このＷＥＢページよりサービスの利用申込みを行う。サービスを申し込むと、人工多能性幹細胞治療支援システム２２２は、人工臓器作製事業者２２３に対して、匿名加工された状態で、将来に人工臓器の行方が未定である患者を移植候補患者情報からサーチし、その情報を「移植臓器未定患者情報」としてＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に保存する。
「移植臓器未定患者情報」には、患者ＩＤと移植候補患者情報に保存されているＤＮＡデータの情報が含まれている。 この移植臓器未定患者情報を、人工多能性幹細胞治療支援システム２２２は、人工臓器作製事業者２２３にサーチ結果として、サーチ結果ＷＥＢページで「移植臓器未定患者情報」を表示、又は「移植臓器未定患者情報」をダウンロードする形で提供し、
このサーチ結果を人工臓器作製事業者２２３に渡したことでサービスは一旦終了となる。
患者の情報を受け取った人工臓器作製事業者２２３は、患者が希望している臓器を確認しいつ頃作製できるかなど今後の戦略を練る形となる。前に進むには、作製可能な人工臓器の移植を受けたい患者とかかりつけ医にアポイントを取ることが第一歩になる。そのために、人工多能性幹細胞治療支援システム２２２は、患者やかかりつけ医へのアポイントサービスを提供している。引き続き患者やかかりつけ医へのアポイントサービスを利用するには、アポイントサービス申込ＷＥＢページで申込を行う。
アポイントサービス申込ＷＥＢページにあるサービス申込スイッチを入れることでサービスが申込まれる。
申込を受けた人工多能性幹細胞治療支援システム２２２は、患者ＩＤの患者への連絡先と、そのかかりつけ医の連絡先を移植候補患者情報から取得し通知を送る。通知の内容は、「患者に適合する人工臓器を提供したい」という内容のテンプレートから取得して、患者とかかりつけ医に通知して、移植治療の人工臓器の検討をしてもらう。
この通知した履歴の情報をアポイント情報としてＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１に保存する。保存したアポイント情報はサービスの依頼を受けた人工多能性幹細胞治療支援システム２２２へ通知する。事業者の通知先は、医療経済圏ＤＢ２１の企業の事業情報から取得して通知する。又はメッセージを送信する。この通知またはメッセージの送信が終わった時点で、アポイントサービスは一旦終了する。
人工臓器作製事業者２２３による人工臓器の提供に患者とかかりつけ医が承諾した場合、患者とかかりつけ医と人工臓器作製事業者２２３との3者による電子契約を人工多能性幹細胞治療支援システム２２２は、電子契約サービスとして提供している。口約束ではなくシステムによる契約で双方の確認を交わすことになる。人工多能性幹細胞治療支援システム２２２での電子契約サービスの申込は、電子契約サービス申込ＷＥＢページよりサービスの利用申込みを行う。電子契約サービス申込ＷＥＢページにあるサービス申込スイッチを入れることでサービスが申込まれる。サービスを申し込むと、人工多能性幹細胞治療支援システム２２２は、人工臓器作製事業者２２３に対して「患者が承諾した臓器をいつ頃作製できるか？」の質問受け取り、回答することになる。この回答を予定納期情報とする。
契約を行うために、患者、かかりつけ医、人工臓器作製事業者２２３に対して通知を送る。通知の内容は、契約を交わしましょうという内容のテンプレートを取得しこのテンプレートに納期予定情報を含めた内容となる。
契約の交わし方は、契約ＷＥＢページで患者とかかりつけ医と人工臓器作製事業者２２３との3者がそれぞれ契約のスイッチを入れることで契約が交わせたことになる。この契約は、既存技術の電子契約を利用しておこない、既存技術により作成された電子文による契約書は、ＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の「人工臓器契約情報」に保存される。この「人工臓器契約情報」の保存処理により、電子契約サービスは一旦終了する。
人工臓器を製造するには数年かかる。人工臓器契約情報の内容に納期予定情報の年月まで患者は待つことになる。そのため人工多能性幹細胞治療支援システム２２２は、交わした電子契約書の管理を行う「電子契約管理サービス」を用意している。
この電子契約書の管理は、既存技術である非代替性トークン（NFT）を利用して行われる。人工多能性幹細胞治療支援システム２２２は、電子契約書の電子文のソースと、情報の契約者である患者とかかりつけ医と人工臓器作製事業者２２３とを紐づけて情報の管理を行い、電子契約書の契約者であることを証明する。NFTを利用した情報の管理方法は、後記する第１１実施形態に記載されているので、ここでは説明を割愛する。
人工臓器作製事業者２２３が電子契約管理サービスを利用するには、電子契約管理サービス申込ＷＥＢページで申込を行う。
電子契約管理サービス申込ＷＥＢページにあるサービス申込スイッチを入れることでサービスが申込まれる。
申込を受けた人工多能性幹細胞治療支援システム２２２は、納期予定情報の年月まで人工臓器契約情報の管理を行う。
人工多能性幹細胞治療支援システム２２２は、人工臓器作製事業者２２３に対するサービスとして、将来に人工臓器の行方が未定である患者の情報（個人情報は含まれていない情報）を提供（販売）するサービスと、患者とそのかかりつけ医にアポイントを取り仲介を行うアポイントサービスと、人工臓器の提供に承諾した患者との契約（電子契約）を請負うサービスと、その電子契約の管理を行うサービスを用意している。これらのサービスも有料で行われる。
このサービスの利用料は、既存技術の支払い方法で対応する。

【0361】

ここまで、人工多能性幹細胞の移植治療における患者が負担する費用の削減と、人工多能性幹細胞治療支援システム２２２とＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の運営を長期に渡り維持し、システムの持続化を行うために収益化できる５つのサービスとして、「人工多能性幹細胞治療情報に保存されている情報の販売」、「人工多能性幹細胞の移植治療の実績のある医師５ａや、医療機関４や、人工臓器作製事業者２２３から業績を上げる事を目的とした広告請負」、「実績が無く、この移植治療を始める執刀医や医療機関や、本考案のシステムを利用したことの無い人工臓器作製事業者２２３からの広告請負」、「人工臓器に適合患者をサーチするサービス及び、適合した患者とかかりつけ医に適合した人工臓器がある事を知らせるサービスの提供」、「移植を適合する人工臓器が無い患者の移植臓器未定患者情報を提供するサービス及び、患者とかかりつけ医に人工臓器が作製できる事を知らせるサービスの提供」を説明してきた。
この５つのサービスの収益を利用することで、人工多能性幹細胞治療支援システム２２２とＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の運営を行っていく。このシステムは患者に依存したサービスである。他の治療方法や、生涯に渡り薬の服用を続ける方法よりも、本システムを利用してもらえるようにする事が重要となる。そのため患者がこのシステムを選択してもらうために、患者が負担する費用の削減も検討の対象となる。
また、収益に余剰が出た場合、これから移植治療を受ける患者が負担する費用の削減にも収益を使用していく。結果、複数の医療機関４が持続可能な大きな１つのデータベースである医療経済圏ＤＢ２１の情報を利用した、患者とかかりつけ医療機関４と移植治療を行う医療機関４と事業者とそして患者への移植治療支援と、移植治療実績のある医師５ａ、医療機関４、人工臓器作製事業者２２３が行う広告の支援を行うプラットフォームを構築し提供することができるビジネスモデルとなる。

【0362】

コンピュータを設置する環境について触れてみる。社内や院内に設置していたレガシーなコンピュータシステムが、時代の流れによりＧＡＦＡ（「Google(登録商標)」「Amazon(登録商標)」「Facebook(登録商標)」「Apple(登録商標)」）又はＧＡＦＡＭ（「Google(登録商標)」「Amazon(登録商標)」「Facebook(登録商標)」「Apple(登録商標)」「Microsoft（登録商標）」）と言われる大きな企業のクラウドサービスの利用が始まった。クラウドサービスを利用することにより社内や医療機関内での人的負担や設備投資における経費負担は軽減される。この「負担軽減」という側面だけを見てレガシーなコンピュータシステムからクラウドサービスへ移行しているのは事実である。しかしながらクラウドサービスを利用することにより発生する重大な問題をないがしろにしているのは事実である。クラウドサービスを利用すること発生するデータはクラウド事業者の持ち物になってしまうことに目を背けてはいけない。特に医療機関で扱うデータは、患者の診療情報、すなわち個人情報である。クラウドサービスの恩恵を受けることで患者の診療情報（個人情報）がクラウド事業者に取られてしまうことに注目して欲しい。それでは、どうしたら良い？ 本考案では、医療機関が自らクラウドサービスを展開すれば良いとしている。そのためには医療機関が自らクラウドシステムを所有することが簡単な回答である。そのためには、プログラムシステムと発生する情報とを長期に渡り運営する為に必要な財源を、収益を確保できるビジネスモデルを持たせたクラウドシステムであることが求められる。クラウドシステムの中でバーチャルな医療機関をプラットフォーム型医療情報システムにより構築し、大勢の患者の診療情報と多くの医療機関が利用できるバーチャルな医療経済圏を構築し、この医療経済圏を長期に渡り持続可能なシステムを維持するための収益源となるビジネスモデルを備えたプラットフォーム型医療情報システムが本考案となっている。
第７実施形態では、このプラットフォーム型医療情報システムを構築するための資金調達や資金管理に関して記載している。ＧＡＦＡ又はＧＡＦＡＭによるクラウドシステムに頼らなくとも、収益のあるビジネスモデルを備えたことにより持続可能となるプラットフォーム型医療情報システムを運営していくことが可能となる。
ここで説明した「人工多能性幹細胞治療支援システム２２２を使用したＩＰＳ幹細胞の人工多能性幹細胞治療」を望んでいる患者や家族は少ないと考えます。さらにかかりつけ医がＩＰＳ幹細胞の人工多能性幹細胞治療を進める医師５ａも少ないと思います。例えば人工透析を行っている患者へ進めないその理由は、完治への治療保証が持てない、自分は透析医なので人工多能性幹細胞治療ができない、人工透析でもいいではないか、人工多能性幹細胞治療を行っている病院４ａへ廻してしまうと自分の患者が減る、医師５ａ自らの最新知識の問題、等の難しい問題により患者に進めないのでしょう。
このシステムは、現在治療を行っているかかりつけ医が、人工多能性幹細胞治療の最後まで患者をフォローしケアすることで、従来の治療から最新医療による治療まで患者をフォローしケアした実績を付けられることも狙っています。医師５ａが自分のできることだけを行う治療から、患者をケアしながら完治させるまでを学び実績をつけ患者を社会に戻していくことが新しい医師５ａの仕事であり患者へのサービスになると考えます。今まで医療において、患者へのサービスは無かったのです、これは治療に関するサービスです。かかりつけ医は開業医が多いと思います、人工透析に毎週通院してくれる患者を完治してしまえば患者は減り医療経営に影響が出てくると思います。
その為に医療経済圏２４には利益を生み出す様々なシステムを用意し、本件のような患者へのサービスを提供し、医療機関４も利益をとれるような内容となっています。
プラットフォーム化されているシステムに「人工多能性幹細胞治療支援システム２２２」を医療経済圏２４の中でサービスを提供することで、沢山の人工多能性幹細胞移植治療を受けられそうな患者を見つけ出し、かかりつけ医が自ら、人工臓器作製事業者２２３、手術を行える医療機関４、執刀できる医師５ａ、を探し出し、患者を完治させるプロデュースを行い、沢山の患者を社会に戻す一部の病気を患わっている患者へのサービスです。
患者に人工透析や処方しか行っていない医療機関４には使用していただきたいサービスである。さらに他の実施形態で説明しているサービスを医療経済圏２４の中で利用することにより医療機関４からの支出は無くなり医療経営の持続化と患者へのサービスは向上することになる。患者は「患者へのサービス」を提供していない医療機関４を選ばなくなると推測する。患者への様々な医療サービスを提供する時代が始まると考える。

【0363】

本実施形態において、ここまで説明した手法を利用することにより、人工多能性幹細胞治療支援システム２２２は、ビジネスモデルとして次の５つを提供することができる。
１）移植候補患者情報に保存されている移植候補患者の患者とかかりつけ医に対して、人工多能性幹細胞治療を促す情報を提供することができる。
２）移植候補患者情報に保存されている臓器移植を決めた患者とかかりつけ医に対して、医療経済圏ＤＢ２１から、人工臓器の移植治療を行える医師５ａと、人工臓器の移植治療を行える医療機関４と、患者の人工臓器を作製する事業者とをサーチし提供することができる。
３）臓器作製事業者とかかりつけ医療機関４と移植治療する医療機関４と、執刀医と主治医と移植治療に携われる医療スタッフと患者との間で、患者の診療情報の共有を行える仕組みによるサービスの提供することができる。
４）患者の治療費又は移植治療入院費を削減する事を行うために、医療経済圏ＤＢ２１内にある情報からサーチした移植治療を行いたい医療機関４、臓器作製事業者、執刀する医師５ａやその他に対して、患者の臓器移植に成功した診療情報の全てを販売提供することができる。ここで販売提供した利益を、患者の治療費又や移植治療入院費に充当することで、患者の負担が軽減される。
５）人工多能性幹細胞治療支援システム２２２とＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の運営を維持するために５つ（人工多能性幹細胞治療情報に保存されている情報の販売」、「人工多能性幹細胞の移植治療の実績のある医師５ａや、医療機関４や、人工臓器作製事業者２２３から業績を上げる事を目的とした広告請負」、「実績が無く、この移植治療を始める執刀医や医療機関や、本考案のシステムを利用したことの無い人工臓器作製事業者２２３からの広告請負」、「人工臓器に適合患者をサーチするサービス及び、適合した患者とかかりつけ医に適合した人工臓器がある事を知らせるサービスの提供」、「移植を適合する人工臓器が無い患者の移植臓器未定患者情報を提供するサービス及び、患者とかかりつけ医に人工臓器が作製できる事を知らせるサービスの提供」）のサービスを行い、その報酬で人工多能性幹細胞治療支援システム２２２とＩＰS人工多能性幹細胞移植治療候補患者ＤＢ２２１の維持を行う。

【0364】

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

【0365】

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

【0366】

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

【0367】

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

【0368】

医療経済圏２４を利用する利用者３が、実績ある優秀な人材を探し業務依頼を行うことを目的に本開示の師士業従事者システム２４３を利用する。本開示の師士業従事者システム２４３を利用する際の検索条件として、利用者３の居住地や利用者３の依頼目的など、様々な要素の条件を用いる。居住地を検索条件に用いる理由は、師士業の業務では、利用者の居住地域の役所で手続きなど利用者の居住地付近での作業が発生する場合や、利用者と対面でやり取りを行う必要がある場合が多々あるため利用者の居住地から遠い師士業従事者を選択しないためとなっている。弁理士のように、利用者の居住地と離れていても問題のない師士業従事者の場合は、検索条件に含めてく手もよい。
例えば、利用者３のロケーションから探すには、利用者３の居住地などの様々な情報を利用して検索を行うことにより、業務達成評価指数を目安に多次元的視覚効果により、目的にあった実績があり評価されているが埋もれていた師士業従事者を発掘することができる。このシステムは、業務達成評価指数をネットワーク上に公表するシステムの一部となっている。また、絞り込んだ、また検索された結果の師士業に対して、システム上で容易に業務を依頼することもできる。容易に業務の依頼とは、「ネットワーク上に公表するシステムの画面上（例えばWEB画面上）で簡単な依頼内容を入力することで依頼が行える」「ネットワーク上に公表するシステムの画面上（例えばWEB画面上）でワンクリックすることで依頼が行える」などのことを示す。
実績ある優秀な人材を探すシステムを利用価値が高まるシステムへスケールアップを行うために、師士業業務情報ＤＢ２５１に蓄積し保存されている師士業業務の業務履歴情報を利用する。
師士業従事者システム２４３は、多くの情報が蓄積された業務履歴情報を用いることで、多くの情報を利用した、より信頼度の高い師士業従事者の検索を行うことができる。これは、同一の師士業従事者に対する保存されている案件の数が少ない（情報が少ない）と取得できる数値情報の数値のブレ幅が大きいため、信頼度が低いが、保存されている案件が増えれば増えるほど、取得できる数値情報の数値が収束していくことが期待できるためとなっている。例えば、業務達成評価指数が同じ０．９だとしても、登録されている案件数が１０件と１０００件だと意味が違う。前者は、次の案件が成功すると指数は０．９１となるが、案件に失敗すると指数が０．８２となり大幅に下がる。一方、後者は、成功しても失敗しても０．９から変わらない。このように同一の師士業従事者に対する保存されている案件の数が増えるほど、数値が安定するため信頼度が高い検索結果が表示されるようにある。

【0369】

利用者３が師士業従事者に対し行なってきた評価は、利用者３からの一方的な評価であった。そのため。利用者３つ付けた評価は、師士業事業者が全力を尽くしたとても、師士業従事者にとって不本意な評価や師士業従事者を貶める内容となることあった。
従来の評価方法では意図しない評価を書かれた師士業従事者は大勢いた。何を記載しようが評価を記載する側の自由であった。こういった内容の評価でよく見かける例では、「時間がかかり過ぎ、態度が悪い、同じ内容を何度も話さないといけない、高い、」成果を出していても、成果が出たことよりも別のネガティブな内容を評価にかかれマイナス効果に繋がる内容を書かれる事もある。
本開示の場合における利用者３が行う評価（レビュー）は、業務を達成した師士業従事者から、利用者に対し依頼した内容に対して行う。
業務を達成した師士業従事者が、利用者に依頼する評価の内容は、師士業従事者が任意に設定する評価を行ってもらいたい項目や評価を行ってもらいたい内容となっている。
評価の依頼を受けた利用者３は、文章によるレビューを行う。
受けた業務に対する評価の例として、弁理士Ａさんは、依頼された業務に対する姿勢や、工夫した点や、自分が依頼を受けて良かった点と難しかった点について自己評価し、弁理士Ａさんは自分がした仕事に対して評価して欲しい内容や、これから仕事を依頼する人にアピールとなる評価を自分で決めて３テーマを挙げた。この３テーマの内容は、「1つ目に師士業従事者を選んだ理由、2つ目に成果内容の感想、３つ目に仕事が完了するまでにかかった期間」であった。弁理士Ａさんは、利用者Bさんにこの３点の評価依頼をした。
業務を依頼した利用者の評価の例として弁理士Aさんから評価依頼を受けた利用者Bさんは、依頼された３点のテーマについて評価を記載した。利用者Bさんの評価の内容は、１つ目のＡさんを選んだ理由が「医療機器に強い弁理士であったため選択した」を記載し、２つ目成果の内容として、「特許の明細書に記載されている内容がよくわからない。知らない内容が多い。でも請求できた。」、３つ目の期間について、「初めて依頼してから２カ月で、書類が出来上あがった。５０ページ資料が2か月でこのページ数では若干時間がかかった感じだと思う」このように評価を記載した。
利用者３が評価を行うと、師士業事業者は、利用者３が書いたレビューに対する評価を行う。この評価は、コメントなどの文章や、５段階など数値で評価するなどで行う。
師士業従事者システムは、利用者３が書いたレビューの内容と、レビューに対する師士業事業者の評価をとをネットワーク上に公表するシステムの画面上（例えばWEB画面上）に公開する。このような評価とすることで、利用者３と師士業従事者双方の視点からの評価となる。また、利用者が、師士業従事者を貶める内容など悪意ある内容のレビューを書いたとしても、師士業事業者は、内容の否定などの対処を行うことができる。
先ほどの例で評価を受け弁理士Ａさんは、利用者Bさんの評価に対して、意図していた評価内容のため5段階での数値評価で５をつけた。また、５０ページ資料が2か月かかった理由をコメントで追記した。
弁理士Ａさんと利用者Bさんとのこの一連の評価の内容は、ネットワーク上に公表するシステムで公開する。

【0370】

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

【0371】

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

【0372】

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

【0373】

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

【0374】

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

【0375】

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

【0376】

実績ある優秀な人材を探すシステムを利用価値が高まるシステムへスケールアップを行うために、師士業業務情報ＤＢ２５１に蓄積し保存されている師士業業務の医療業務履歴情報を利用する。
師士業業務ＤＢ２５１にある師士業業務の医療業務履歴情報には、これまでの相談件数や案件受諾件数、各案件における相談回数、相談からの回答の満足度、各案件における対応回数、各案件の初相談から完治までの期間、各案件における報酬、治療開始から完治までの期間、利用者３からの完了後の評価等の利用者３側から提供された情報を蓄積されている。
社会業務結果情報と師士業従事者属性情報に加え、医療業務履歴情報を紐づけたリレーションのデータベースとすることにより、利用者３による利用者成果の情報が付加された事で幅広い師士業者の業務に関する情報のソースとなる。
師士業従事者システム２４３は、多くの情報が蓄積された医療業務履歴情報を用いることで、多くの情報を利用した、より精度の高い師士業従事者の検索を行うことができる。
また、医療以外の師士業従事者と同様に、師士業従事者は、利用者３に対し、レビューを依頼できる。また、利用者３が行ったレビューに対し、師士業従事者は評価をおこない、利用者３のレビューと師士業従事者の評価とをネットワーク上に公表するシステムの画面上（例えばWEB画面上）に公開する。
受けた業務（治療）に対する評価の例として、医師Cさんは、依頼された人工臓器移植治療に対する姿勢や、工夫した点や、自分が依頼を受けて良かった点と難しかった点について自己評価し、医師Cさんは自分がした仕事に対して評価して欲しい内容や、これから仕事を依頼する人にアピールとなる評価を自分で決めて２テーマを挙げた。この２テーマの内容は、「1つ目に医師を選んだ理由、2つ目に治療内容の感想」であった。医師Cさんは、患者Dさんにこの２点の評価依頼をした。
業務を依頼した利用者の評価の例として医師Cさんから評価依頼を受けた患者Dさんは、依頼された２点のテーマについて評価を記載した。利用者Dさんの評価の内容は、１つ目のCさんを選んだ理由が「人工臓器移植治療の実績がある医師であったため選択した」を記載し、２つ目成果の内容として、「治療はきつかった。でも、辛い副作用やリスクある処置を行う場合は十二分に説明してくれた。」このように評価を記載した。
評価を受けた医師Cさんは、患者Dさんの評価に対して、意図していた評価内容のため5段階での数値評価で５をつけた。また、辛い副作用やリスクある処置を行う場合の説明は、常に患者さんの納得がいくまで行っていることをコメントで追記した。
医師Cさんと患者Dさんとのこの一連の評価の内容は、ネットワーク上に公表するシステムで公開する。
この評価の内容は、第９実施形態に記載の人工多能性幹細胞治療支援システム２２２に提供することにより、人工臓器移植治療に携わる医師や医療機関の選定に用いることができる。

【0377】

本実施形態でここまで説明してきた実績ある優秀な人材を探すシステムは、実績ある優秀な人材を探し業務依頼を行うビジネスモデルを実現するシステムでとなっている。師士業従事者システム２４３の利用料は、実績ある優秀な人材を探し業務依頼を行うビジネスモデルを実現するシステム（師士業従事者システム２４３）を利用し業務依頼した利用者３と、業務を受けた師士業従事者の双方からの成功報酬として徴収することにより行われる。業務依頼した利用者３と、業務を受けた師士業従事者の双方から受け取る利用料は、既存技術により支払いを行うのでここでは記載はしない。既存技術は、例としてキャッシュレスやＥＣサイトやネット決済や出願人考案の特開２０２１－１１３９２７などである。出願人考案の特開２０２１－１１３９２７を利用する理由は、現在の法定通貨から次世代のデジタル通貨に代わっても、利用方法を変えずそのまま利用できるメリットがある。

【0378】

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

【0379】

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

【0380】

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

【0381】

本実施形態では、情報に接続可能な大きな１つのデータベース（医療情報共有データベース）にある、開発プロセスＤＢ２６１に保存されている情報を参照し利用している。開発プロセスＤＢ２６１には、資金分類情報、利用者情報、資金調達情報、資金調達方法情報、資金調達先候補情報、資金調達先情報、調達方法情報、広告情報、応募情報、権利情報、考案概要情報、開発基本情報が保存されている。各情報の説明は、情報の使用時に記載する。
ここから、開発プロセスＤＢ２６１に保存されている情報やその情報を利用した機能について順次説明する。

【0382】

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

【0383】

ここから企画段階時の資金調達における開発プロセスシステム２６２の動きについて説明する。
大きなシステムの内製化の企画段階における資金について考える。１つの医療機関での資金捻出（投資）よりも、同業者における参加を増やし投資額を増やす方法が望ましい。これは内製化するシステムを利用する同業医療機関と共創する上でも重要である。
開発プロセスシステム２６２は、企画段階での資金源拡大のために資金提供をしてもらう企業を探すためや、システムの開発に関わる企業を探すために、開発予定のシステムの概要などの開発基本情報を開発プロセスＤＢ２６１から取得し公開する。情報の公開先は、助成金や補助金を提供する自治体や国、いずれ参加する事をにらみ出資や投資を検討している企業、投資を検討している投資家や企業、開発の請負いを考える企業、興味や関わりを持ちたい個人、海外企業など、多種多様な相手に公開する。
開発プロセスシステム２６２が開発基本情報を多種多様な相手に公開することにより、公開した先のうち興味がある個人や企業から問い合わせが来ると予測される。
開発プロセスシステム２６２は、個人や企業からの問い合わせ時に取得できる相手の名称や連絡先などの情報を、資金調達先候補情報として開発プロセスＤＢ２６１に保存する。この資金調達先候補情報は、調達する資金の資金調達先の情報として利用する。
個人や企業から問い合わせは、公募機能を用いて受け付ける。
公募機能は、開発プロセスシステム２６２が募集したい内容を公開し、公開した内容に対する返答を受け付ける機能となっている。
公開した内容に対する返答を受け付けは、開発プロセスシステム２６２上の返答を受け付けるポータルサイトを用いて行う。受け付ける方法は、受け付ける内容に合わせ、文字データや音声データなどで受け取る。
上記説明では、資金調達の募集で記載した。しかしながら、公募機能は、資金調達に限らず、システムの開発する企業の募集や開発したシステムの運用者の募集、開発したシステムの利用者の募集などにも利用できる。

【0384】

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

【0385】

資金調達の流れについて説明する。
本開示の開発プロセスシステム２６２は、資金調達先情報から資金を調達する相手（資金調達先）と資金分類情報から調達する資金の種類とを選択する。次に、開発プロセスシステム２６２は、選択した調達する資金の種類に対応した資金調達の方法を、資金調達方法情報から取得する。取得した資金調達方法情報が、資金調達の方法となる。
資金を調達する相手には、自治体や資金調達前から関係のある企業などある程度具体化した相手だけでなく、一般投資家などの抽象的な相手も含んでいる。
開発プロセスシステム２６２は、資金調達の方法が決まると、資金調達先に決定した資金調達の方法で資金提供の依頼する連絡を入れる。連絡方法は、ある程度具体化した相手なら、ダイレクトメールなど直接連絡できる方法を利用する。一方、一般投資家などの抽象的な相手の場合は、WEBを利用した方法やクラウドファンディングを利用した方法、広告を利用した方法などの不特定多数に連絡できる（知らせる）方法を利用する。
決定した資金調達の方法が、広告を利用した方法の場合、広告情報に保存している広告手段で細分化し、細分化した方法で調達を行っていることを公知する内容の広告を実施する。
開発プロセスシステム２６２が、資金提供の依頼する連絡を行う際、資金調達を行うための説明資料として、開発基本情報を公開する。開発基本情報を公開方法は、ダイレクトメールなど直接連絡できる方法の場合、ダイレクトメールに添付するなどして資金調達先に公開する。不特定多数に連絡できる（知らせる）方法の場合は、「資金調達先から問い合わせを受けた場合に公開」「WEB上に公開用サイトを用意して広く公開」などで行う。
開発基本情報は、これから内製化するプログラムの概要を記されている概要情報などの内製化するプログラムの情報であり、開発プロセスＤＢ２６１に保存されている。

【0386】

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

【0387】

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

【0388】

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

【0389】

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

【0390】

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

【0391】

開発プロセスシステム２６２は、内製化して構築したシステムのライセンスや権利に関する情報として、所有権と、財産権と、著作権と、使用権と、複製権とを権利情報として開発プロセスＤＢ２６１に基本登録する。この権利情報に内製化して構築したシステムのライセンスや権利に関する情報の保存処理をする。構築したシステムやプログラムの所有権や財産権の例を示す図を図７９に示す。
内製化したシステムの所有権や財産権を所有している団体以外の団体、すなわち別の地域の医療機関４や別の自治体が、内製化したシステムを利用したい場合は、開発プロセスシステム２６２上のライセンス管理システム２６３に使用申請を行う。
使用申請が行われると、ライセンス管理システム２６３は、内製化したシステムの所有権や財産権を所有している団体に代わり、権利情報に保存された情報をもとに使用許可を与える処理を行う。この使用許可には、システムの複製権や使用権が含まれている。また、ライセンス管理システム２６３は、使用許可を与えると、構築した内製化システムを複製により提供または販売を行い、提供または販売先の情報を提供先情報として、開発プロセスＤＢ２６１の権利情報に保存する処理を行うことで管理（権利の管理）を行う。
構築した内製化したシステムの提供方法をプラットフォーム化したシステムへのネットワークを使用した接続に変更することもできる。この場合、利用を希望する利用者３や団体に対して権利情報からシステムの使用権のみをライセンス管理システム２６３に登録する処理で管理する形で使用が与えられる。（一般にパブリッククラウドと呼ばれる形式やホステッド型プライベートクラウドと呼ばれる形式でシステムの使用権を提供する。）
結果、無形物である内製化したシステムやシステムを構成しているソフトウェアプログラムにおけるライセンスや使用権の権利の管理を行うことができる。

【0392】

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

【0393】

「ひらめきとして頭の中にあるアイデア」の概要のデジタル化について説明する。
アイデアのデジタル化するために、ライセンス管理システム２６３上にアイデアを登録するためのポータルサイトを用意する。
医師５ａや看護師５ｂなどアイデアを登録したい人は、アイデアを登録するためのポータルサイトにアイデアの概要を入力する。ライセンス管理システム２６３は、ポータルサイトに入力した内容を考案概要情報として開発プロセスＤＢ２６１に保存することによりデジタル化を行う。
アイデアの概要を入力方法について説明する。
医師５ａや看護師５ｂなどアイデアを登録したい人がポータルサイトにアクセスすると、まずアイデアの入力方法を選択する。入力方法としては、「文字（文章）で入力」「音声で入力」「画像（映像）データで入力」などがあり、複数を選択（例えば、文字と画像）してもよい。
医師５ａや看護師５ｂなどアイデアを登録したい人は、選択した方法でアイデアを入力する。
文字で入力する場合は、「ポータルサイトの入力フォームに内容を書く」「テキストファイルやワープロ文章をポータルサイトにアップロードする」などで行う。
音声で入力する場合は、「Web Speech APIを使用しポータルサイト上で入力」「音声ファイルをポータルサイトにアップロードする画像データで入力」などで行う。
画像データで入力する場合は、「画像に類するデータをポータルサイトにアップロードする」などで行う。
画像に類するデータとしては、アイデアの説明を手書きで書いた絵などをスキャンしたデータ、アイデアの説明をグラフィックソフトで描いたデータ、アイデアのプレゼンテーション資料のデータ、アイデアのシミュレーションデータ、アイデアのアニメーションデータ、アイデアの２Ｄ―ＣＡＤや３Ｄ―ＣＡＤのデータ、アイデアを簡単なロジック化したフローチャートのデータなどがある。
ポータルサイトへ入力する「ひらめきとして頭の中にあるアイデア」の概要は、ひらめきのタイトルやキーワードといった簡単なものでもよい。この場合は、ライセンス管理システム２６３を運用する側から入力を行った医師５ａや看護師５ｂなどアイデアを登録したい人へコンタクトを取り、詳細の聴取（図面や文字データなどをもらうことを含む）を行う。聴取した内容をライセンス管理システム２６３へ入力することでデジタル化を行う。
ライセンス管理システム２６３で行う考案概要情報の管理について説明する。
ライセンス管理システム２６３で行う考案概要情報の管理は、考案概要情報に対する権利侵害や考案概要情報の複製行為や盗用行為から保護するために非代替性トークン（NFTまたはnon-fungible token）を用いて行う。NFTは、偽造不可な鑑定書・所有証明書付きのデジタルデータのことであり、アイデアの概要をデジタル化した考案概要情報をNFT用いて管理することによりアイデアの盗用などから守ることができる。また、NFTとライセンス管理システム２６３は、考案概要情報と考案者の情報と開発事業社とを紐づけて管理する機能も有している。NFTの利用は、デジタルアート等の販売に近年では利用されている。

【0394】

上記では、医師５ａや看護師５ｂなどの医療機関４で働く医療従事者５、介護士、医療機関４で働く事務職、医療に従事する企業、医療関係の研究者５ｉなどが考案した、開発した内製化したシステムの改善案などの「ひらめきとして頭の中にあるアイデア」の権利管理が行えると記載した。しかし、医師５ａや看護師５ｂなどの医療機関４で働く医療従事者５、介護士、医療機関４で働く事務職、医療に従事する企業、医療関係の研究者５ｉなどの考案は、開発した内製化したシステムの改善案などに限らず、医療機器や製薬や介護機器などの医療に関連する考案のひらめきを対象としたアイデアの権利管理も行える。本開示のライセンス管理システム２６３は、医療機器や製薬や介護機器などのアイデアをデジタル化したうえで考案概要情報に保存し、デジタル化した考案概要情報の権利管理をNFTを利用した同様の手法により行うことができる。本考案で「ひらめきとして頭の中にあるアイデア」にNFTを利用する目的は、アイデアの考案者とそのアイデアの開発を行う開発事業社の権利保護を行うことと、デジタル化したアイデアのデータを無断複製することからの権利侵害を防ぐことも目的のうちである。

【0395】

また、本開示の開発プロセスシステム２６２は、医師５ａや看護師５ｂなどの医療機関４で働く医療従事者５、介護士、医療機関４で働く事務職、医療に従事する企業、医療関係の研究者５ｉなどが考案した医療機器や製薬や介護機器などアイデアを製品化や知的財産の権利化するための資金調達と製品化するものづくり企業を探すことができる。資金調達と製品化する企業又はプログラム開発を行う企業を探す方法は、資金調達方法情報にある手段を使用して行い、広告情報にある広告方法を利用して考案概要情報を広く公知することで行う。この募集時にも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】

【図60】

【図61】

【図62】

【図63】

【図64】

【図65】

【図66】

【図67】

【図68】

【図69】

【図70】

【図71】

【図72】

【図73】

【図74】

【図75】

【図76】

【図77】

【図78】

【図79】