JP6671609B1 - 医療システム - Google Patents

Abstract

【課題】高齢者等の見守り対象者の生活状態を早期に把握し、適切な対応をとり、悪化を防止するとともに、自立を促して生活の質を維持しつつ、サービス提供側のコストを抑制することができる技術を提供することにある。【解決手段】住宅９１に設置される家庭内センサ４は、通信機能を備えたルータ一体型で、検出結果は、集約ルータ５を介して医療情報共有サーバ１０に送信される。医療情報共有サーバ１０では地域共有ＤＢ１２が、センシング結果をもとに、利用者９４の在宅の有無、住宅９１の温度・湿度等の環境状態を推定し、利用者端末４０に表示させたり、支援者に通知する。また、医療情報共有サーバ１０は、利用者９４の購入履歴から、栄養の偏りや認知症等の虞を検出し、支援者に通知する。【選択図】図１

Description

本発明は、健康管理システム及び医療システムに係り、例えば、家庭内に設置されたセンサによりその家庭の住人、特に高齢者のように支援が望まれる者を見守る機能を備えた健康管理システム及び医療システムに関する。

高齢化社会が加速し、高齢者のひとり暮らしも拡大し続けている。そのような高齢者を見守るために、カメラを設置したり、電気の使用量をモニタリングする方法が知られている。また、人感センサと加速度センサを有効に組み合わせて住居における居住者の行動を見守る技術も提案されている（例えば、特許文献１参照）。特許文献１に開示の技術では、見守り対象となる居住者の住居に設置した人感センサ、居住者が装着する加速度センサの双方から検出したデータを受信し、これらのセンサからそれぞれ推定される情報を組み合わせて居住者の行動等を判断することによって、人感センサ、加速度センサそれぞれ一方のみのデータからは判断することが困難な、居住者に関するより具体的な生活状態に関する情報を収集する。

特開２０１４−８９４９４号公報

高齢化社会が急激に進む中、ヘルパー・介護者等の支援者の不足が深刻になっている。見守り対象者の自立を促す必要もある。特に認知症の場合は、配偶者や家族、介護者が発症の発症時又は初期の段階で気づく事は非常に困難な病気であり、ある程度進行した状態、すなわち普通の人と違う状態になってからやっと気付き始めることが多い。認知症が発症した場合に、極力症状が軽い段階で早く把握し、支援ステージを調整する必要もある。特許文献１に開示の技術でも、高齢者等の居住者の生活状態を把握できるが、上述のように、高齢者層の大幅な拡大と支援者不足の状況にあっては、十分に対応できず、新たな技術が必要となっていた。すなわち、自立を促し、生活状態が悪化しないうちに対応するといった観点を想定するものでなかった。また、支援する側（そのようなサービスを提供する側）としては自治体や介護施設、リハビリ施設等が想定されるが、高齢者対策の予算の増大が大きな課題となっており、予算を大幅に削減しつつ、支援が望まれる人達にとって、良好な生活の質を維持できることが望まれていた。

本発明は、以上のような状況に鑑みなされたもので、その目的は、高齢者等の見守り対象者の生活状態の生活データ見ながら、生活データの変化いわゆる健康状態の変化を早期に把握することで、適切な対応や又は予防をとり、悪化を防止とともに、自立を促して生活の質を維持しつつ、サービスを提供する側（一般には自治体や介護施設、リハビリ施設）のコストを抑制することができる技術を提供することにある。

（１）本発明は、複数の医療機関が連携して所定の地域において医療を提供する医療システムであって、
前記医療機関に備わる情報処理端末と、
前記医療機関の前記情報処理端末と協働する医療情報共有サーバと、
利用者の健康状態を管理する健康管理システムと、
を有し、
前記医療情報共有サーバは、
前記医療機関を運営する事業者の事業者情報を記録する事業者データベースと、
前記医療機関を利用する利用者の利用者情報を識別情報と関連付けて記録する利用者データベース（例えば患者ＤＢともいう）と、
前記利用者の商取引の履歴（購入履歴や医療決済等）を取得する決済履歴取得部と、
前記商取引の履歴を前記利用者の識別情報と関連付けて記録する利用者購入履歴データベースと、
を有し、
前記健康管理システムは、
前記利用者を住人とする家庭内の環境状態を取得する家庭センサと、
前記家庭センサと接続され外部と通信するセンサ通信部と
前記センサ通信部を介して前記家庭センサのセンシング情報を収集する家庭情報収集部と、
前記センシング情報を蓄積する家庭情報データベースと、
前記センシング情報をもとに前記利用者の生活状態を判定する状態判定部と、
前記状態判定部の判定結果を前記利用者または前記利用者の支援者の少なくとも一方に通知する通知部と、
を備え、
前記状態判定部は、前記商取引履歴をもとに前記利用者の健康状態を推定（例えばＡＩ等の公知の技術を用いた推定）し、
前記通知部は、前記健康状態について対処（例えば改善や支援）が必要であると推定した場合に、前記支援者（例えば、掛り付け医師、栄養士、自治体、近親者等）に対して通知する。
家庭センサとして、環境センサ、人感センサ、ドアセンサ、音響センサ（「音センサ」とも言う）等がある。環境センサは、例えば、気温、湿度、照度のデータを計測し、計測値／計測時刻はクラウド等に保存される。人感センサは、例えば、赤外線で人の接近を検知し、検知した検知時刻／検知回数はクラウドに保存される。これらのセンサのデータは、単独または複数を適宜組み合わせて、判断に用いられる。
家庭センサとセンサ通信部が一体となったルータ一体型センサ（例えばコンセントに挿すタイプのセンサ等）を採用することで、高齢者等の不慣れな者にとっても、簡単に設置できる。そのようなセンサで得られたセンシング情報から、一人暮らしの高齢者のような見守り対象者が、日々どのような生活をしているか、特に安否情報、健康状態、日常の習慣等を推定する。例えば、センシング情報の傾向に変化が生じた場合、特異データが発生した場合に、安否確認が必要と判断し、本人確認の連絡を入れたり、自治体の担当部署（例えば福祉課等）、登録されている健康管理者（例えば親類、ヘルパー、掛り付け医療機関等）へ連絡する。また、ドアセンサのセンシング情報（開閉データ）と地域のゴミ収集スケジュールとを関連づけることで、ドアセンサの開閉データの蓄積から毎回のゴミ出し生活習慣を推測することができる。すなわち、健康的にかつ習慣的に生活が行われていることや安否の確認につながる。そして、ゴミ出しの日の所定時間までに、ゴミ出しが行われない場合に、アラームを発生させることで、高齢者への安全生活ケアを行える。
また、見守り対象者である高齢者等が医療機関や商店等で商取引きをした場合、その履歴から、例えば、毎日同じ物を購入しているようなら、その者に確認の通知をするとともに、ヘルパー等に注意喚起を通知する。特に認知症を発症している場合に、同じ商品等を不必要に繰り返し購入することがある。また、特定の疾患を有するものが、本来は摂取すべきでない物を購入するような場合もある。利用者データベースに医療機関での診断結果が記録されており、そのような物を摂取しないように指導されていれば、診断結果と購入履歴から、本人に注意の通知をしたり、健康管理者に連絡する。
なお、利用者の情報処理端末や電子決済用カード、生体認証による電子マネー（電子決済）を想定するが、事業者（商店等）では、情報処理端末又は電子決済用カードによる電子マネーの商取引システムを導入していない場合もある。そのような場合は、現金支払で購入履歴は紙レシートとして渡される。そこで、利用者端末は、付属のカメラで購入時の紙レシートの画像データを取得し記録してもよい。このとき画像データは、利用者端末でＯＣＲ処理等して購入リストを抽出・整理してサーバ側に送信してもよいし、そのままのデータをサーバ側に送信しサーバ側で抽出・整理してもよい。利用者の決済がＩＣ決済以外の場合でも、商取引の履歴を取り込むことができる。利用者の情報処理端末は、所定のアプリケーションから、または、外部からの通知として、毎日所定の時刻にその日の商取引のレシートを取り込むように利用者に促し、取り込みが無い場合に、健康管理者に通知するといった処理も可能である。自分で取り込む場合には、高齢者は、例えば毎夜レシートを取り込む操作をすることで、その日の出来事を振り返りことになり、記憶力の低下等を防止できる。なお、近年、紙レシートではなく電子レシートを発行する場合もあり、当然に電子レシートから購入履歴が抽出されてもよい。
さらに、利用者の商取引履歴が利用者購入履歴データベースに記録されると、通知部から所定の健康管理者に記録された旨を通知してもよい。健康管理者は、商取引履歴のデータへのアクセス権を有する場合には、そのデータを参照し、見守り対象者の行動（通院していることや、逆に無駄な買い物をしているということ等）を把握できる。
また、近年では、高齢者の生活は、野菜や肉といった素材を買って食事を作るよりも、出来上がった総菜を買って食事をすることが徐々に増えてきている傾向にある。この購買履歴から、総菜の栄養、調味料、味付け等から摂取する栄養を推定する。推定結果から、これから身体に発生すると危惧される病気を、健康診断及び通院時に電子カルテと連動させる。生活における栄耀の摂取状況を担当医師が見ることにより診療の参考にすることができ、また、栄養士による診断によって高齢者への食事ケアをすることができ、日常の食事という側面を地域でサポートし健康維持・増進を進められる。

（２）本発明は健康管理システムであって、
家庭内の環境状態を取得する家庭センサと、
前記家庭センサと接続され外部と通信するセンサ通信部と
前記センサ通信部を介して前記家庭センサのセンシング情報を収集する家庭情報収集部と、
前記センシング情報を蓄積する家庭情報データベースと、
前記センシング情報をもとに前記家庭の住人の生活状態を判定する状態判定部と、
前記状態判定部の判定結果を前記住人及び前記住人の支援者に通知する通知部と、
を備える。

（３）前記家庭センサは音響センサを含み、
前記状態判定部は、前記音響センサのセンシング情報をもとに、前記住人の生活状態を推定してもよい。
例えば、音響センサをベッド横に設置しておき、咳と思われる音が継続して検出されている場合には、本人に通院するように通知したり健康管理者（親類、ヘルパー、掛り付け病院・医師等）へ状況確認するように通知する。同様に、睡眠時に布団がずれる音すなわち寝返り音によりや、いびき音の採取により睡眠時無呼吸や寝返りの回数で睡眠がとれて健康的かを推測できる。これにより、一人暮らしの高齢者のように見守りが必要な者の健康悪化を早期に把握でき、重症化を防止できる。また、キッチンに設置してガス機器の状態を判断する。新しいタイプのガス機器ではガス漏れセンサや過熱センサが備わるが、一昔前のタイプであると、そのようなセンサが設置されていない場合もある。そこで、簡易的ではあるが音響センサでガス漏れ等をセンシングし、注意を促すことができる。

（４）前記家庭センサは環境センサを含み、
前記状態判定部は、前記環境センサのセンシング情報をもとに、前記住人の生活状態を推定してもよい。
環境センサが温度センサや湿度センサを含む場合、それらのセンシング情報から適切な居住環境であるか、すなわち室温や湿度が適切であるか否かを判断する。高齢者は、室内が暑すぎる／寒すぎる等について検知能力・判断力が低下する傾向がある。住人が一人暮らしの高齢者の場合や高齢者のみのグループである場合、指摘してくれる者がいない虞もあり、熱中症等を引き起こす虞がある。そのような場合に早期に対応することができる。

（５）
前記住人の商取引の履歴を取得する決済履歴取得部と、
前記商取引の履歴を記録する利用者購入履歴データベースと、
を有し、
前記状態判定部は、前記家庭センサの前記センシング情報から推定される生活状態または前記購入履歴から推定される健康状態に変化点を検知した場合に、前記通知部は前記生活状態または前記健康状態に変化が生じた旨を、前記住人または前記住人の支援者の少なくとも一方に通知してもよい。

（６）上記（１）の医療システムにおいて、前記健康管理ステムとして、上記（２）〜（５）までのいずれかに記載の健康管理システムと、
前記医療機関に備わり、シンクライアント端末として機能する情報処理端末と、
を有し、
前記医療情報共有サーバは、
前記情報処理端末とともにシンクライアント環境を構築するシンクライアント管理サーバと、
前記シンクライアント環境において稼働させる医療系システムと、
を有する。
医療機関と見守り対象者の家庭内のセンサや決済履歴を記録するような機能（単に「決済参照機能」ともいう）を有する場合、シンクライアント環境においてシステム構成を実現することで運用効率が高まり、見守り機能や決済参照機能がストップしてしまうことを抑制できる。

（７）前記住人の前記商取引の履歴が前記利用者購入履歴データベースに記録されると、前記通知部は前記支援者に記録された旨を通知してもよい。

本発明によると、一人暮らしの高齢者のような者を、効果的に見守ることができる。すなわち、高齢者等の見守り対象者の生活状態を早期に把握することで、適切な対応をとり、悪化を防止するとともに、自立を促す技術を提供できる。また、サービスを提供する側（一般には自治体や介護施設、リハビリ施設）のコストを抑制することができる技術を提供できる。

本実施形態に係る、地域医療連携システムの機能の概要を説明する図である。 本実施形態に係る、地域医療連携システムの機能の概要を説明する図である。 本実施形態に係る、地域医療連携システムの概略構成を示す図である。 本実施形態に係る、医療情報共有サーバのブロック図である。 本実施形態に係る、利用者ＤＢの登録データの例を示す図である。 本実施形態に係る、利用者ＤＢの蓄積データの例を示す図である。 本実施形態に係る、医療関係者ＤＢの例を示す図である。 本実施形態に係る、薬剤師ＤＢの例を示す図である。 本実施形態に係る、介護士ＤＢの例を示す図である。 本実施形態に係る、事業者ＤＢの例を示す図である。 本実施形態に係る、利用者端末のブロック図である。 本実施形態に係る、患者が患者用サイトにアクセスして利用できるサービスの例を示した図である。 本実施形態に係る、利用者が見守りサービスのセンサ設定を行う画面例を示した図である。 本実施形態に係る、見守りサービスにおける購入履歴確認の画面例を示した図である。 本実施形態に係る、医療機関端末のシンクライアント端末に表示される電子カルテの画面例である。 本実施形態に係る、見守りサービスにおける在宅確認処理の例を示したフローチャートである。 本実施形態に係る、見守りサービスにおける環境適正確認処理の例を示したフローチャートである。 本実施形態に係る、見守りサービスにおける音響センサを用いた健康異常確認処理の例を示したフローチャートである。 本実施形態に係る、見守りサービスにおける購入履歴確認処理の例を示したフローチャートである。

次に、本発明を実施するための形態（以下、単に「実施形態」という）を、図面を参照して具体的に説明する。図１及び図２は本実施形態において実現する地域医療連携システム１の機能の概要を説明する図である。利用者９４は、住宅９１に家庭内センサ４を設置する。家庭内センサ４は、環境センサ、人感センサ、ドアセンサ、音響センサ等であり、ベッド９１１、キッチン９１２、照明９１３、玄関ドア９１４、トイレ９１５、風呂場・脱衣所９１６等又はその近傍に設置される。また、家庭内センサ４のひとつとして、風呂場・脱衣所９１６にはネットワーク対応型体重計４ａが設置される。

家庭内センサ４は、通信機能を備えたルータ一体型となっており、コンセントに挿すことで、常時稼働する。家庭内センサ４の検出結果は、集約ルータ５で集約され、ネットワーク経由で地域医療連携システム１の医療情報共有サーバ１０に送信される。医療情報共有サーバ１０では地域共有ＤＢ１２が、センシング結果をもとに、利用者９４の在宅の有無、住宅９１の温度・湿度等の環境状態を推定し、注意が必要なときなどに利用者端末４０に表示させたり、医療情報共有サーバ１０を介して所定の支援者に通知する。例えば、センシング情報の傾向に変化が生じた場合や特異データが発生した場合に、安否確認が必要と判断し、本人確認の連絡を入れたり、所定の支援者、具体的には、自治体の担当部署（福祉課等）、登録されている健康管理者（親類、ヘルパー、掛り付け病院等）へ連絡する。また、風呂場・脱衣所９１６に設置された家庭内センサ４が、大きな音・振動を検出した場合に、ヒートショックにより倒れた可能性があると判断して、上記の支援者に連絡する。

健康管理者としては、親類やヘルパー等の資格を有する者が好ましいが、その他に、キーパーソンとして身の回りの世話をしてくれる人（隣人、友人等）が登録されてもよい。また、利用者９４が冠婚葬祭の積み立てシステムである互助会に入っている場合は、互助会の連絡先が登録されてもよい。利用者９４が互助会に加入していることを親類等が把握していない場合もある。また、利用者９４が亡くなった場合に、互助会に加入していることを把握していないと、搬送された病院が契約している葬儀社に連絡がいってしまい、利用者９４自身の生前の手配が無駄になってしまうこともある。

また、医療情報共有サーバ１０は、利用者９４の購入履歴を取得する機能を有する。利用者９４が、医療機関９２や薬局９６、商業施設９７を利用した際に、利用履歴（すなわち購入履歴、決済履歴）が医療情報共有サーバ１０（地域共有ＤＢ１２）に送信され蓄積される。具体的には、利用者９４、すなわち、見守り対象者である高齢者等が商業施設９７で商取引きをした場合、その履歴から、例えば、毎日同じ物を購入しているようなら、その者に確認の通知をするとともに、所定の支援者に注意喚起を通知する。特に認知症を発症している場合に、同じ商品等を不必要に繰り返し購入することがある。また、特定の疾患を有するものが、本来は摂取すべきでない物を購入するような場合もある。医療情報共有サーバ１０には医療機関９２の診断結果が記録されており、そのような物を摂取しないように指導されていれば、診断結果と購入履歴から、本人に注意の通知をしたり、所定の支援者（親類や掛り付け医師等のような健康管理者）に連絡する。

このようにして、利用者９４（高齢者等の見守り対象者）の生活状態を早期に把握することで、適切な対応をとり、悪化を防止するとともに、自立を促して生活の質を維持しつつ、サービスを提供する側（一般には自治体や介護施設、リハビリ施設）のコストを抑制する。なお、以下では特に言及しない限り「介護施設」及び「リハビリ施設」をまとめて「介護施設」として説明する。

図３は地域医療連携システム１の機能ブロック図である。図４は医療情報共有サーバ１０の概略構成を示す機能ブロック図である。

地域医療連携システム１では、ある範囲の地域において複数の医療機関（ここでは医療機関９２、薬局９６、介護施設９８を運営する事業者）及商業施設９７は、医療情報共有サーバ１０を用いて、利用者９４に対して、医療・福祉の商品・サービスを提供するとともに、一人暮らしの高齢者のような利用者９４に対する見守り機能及び購入履歴検証機能を果たす。

利用者９４とは、医療機関９２や薬局９６を利用する患者や、介護施設９８や商業施設９７を利用する高齢者であって、見守りが必要とされる者を想定する。以下では便宜的に「利用者９４」として説明する。医療機関９２は、病院や診療所、歯科医院や眼科院等を含む広い概念である。なお、法令・ガイドライン等で定められているものについては、当然にそれらに則った処理を行うものであり、例えば、電子カルテや電子処方せん（処方せんデータ）において、医師等の電子署名、タイムスタンプが必須のデータについては、必要とされるタイミングにおいて電子署名等が付与、参照されるものである。

例えば図３に示すように、地域医療連携システム１は、医療情報共有サーバ１０と、それにネットワーク２を介して接続する医療機関９２の医療機関端末２０、薬局９６の薬局端末６０、商業施設９７の商業施設端末７０、介護施設９８の介護施設端末８０、及び利用者９４の利用者端末４０およびその住宅９１に設置された家庭内センサ４と接続する。

ここで、図２に示すように、医療情報共有サーバ１０は、統括装置１１と、地域共有ＤＢ１２と、医療情報共有サイト１００と、を備える。統括装置１１は、医療情報共有サーバ１０の構成要素を統括的に制御するとともに、他装置との通信ＩＦとして機能する。

医療情報共有サイト１００には、ポータルサイト１０１と、利用者９４と事業者のそれぞれのアクセス先となる医療機関用サイト１１０、患者用サイト１４０、薬局用サイト１６０、商業施設用サイト１７０、介護施設用サイト１８０とが設けられている。

ポータルサイト１０１は、医療情報共有サイト１００の玄関として機能し、外部からアクセスする利用者９４や事業者は、それぞれの情報処理端末でこのポータルサイト１０１を経由してそれぞれ目的のサイトにアクセスする。

利用者９４は、自身のＰＣ（パーソナルコンピュータ）やタブレット端末、スマートフォン、ネットワーク接続機能付きの表示装置（例えばネットワーク対応液晶テレビやデジタルサイネージ表示装置）等の利用者端末４０を用いて医療情報共有サーバ１０にアクセスする。ここでは、図３に示すように、利用者９４のそれぞれが利用者端末（１）４０＿１〜利用者端末（ｎ）４０＿ｎを用いて医療情報共有サーバ１０にアクセスする。利用者端末（１）４０＿１〜利用者端末（ｎ）４０＿ｎを区別しない場合は、単に「利用者端末４０」として説明する。利用者端末４０がタブレット端末、スマートフォンの場合、専用のアプリケーションが導入され用いられてもよい。

利用者端末４０は、患者用サイト１４０にアクセスして、事業者が提供する商品・サービスを利用する。例えば、医療機関９２において診察を受ける場合に、医療機関９２のＷＥＢページにアクセスして診察を予約することができる。また、利用者端末４０には、例えば「お薬手帳機能」や「見守り機能」を有するアプリが導入され、医療情報共有サーバ１０と同期されて処方履歴を参照したり、見守り機能の購入履歴を参照することができる。また、医療情報共有サーバ１０は、上述のように高齢者等に対する見守り機能（見守りサービス）を提供しており、そのサービスを受けるに際して、利用者端末４０で各種登録・設定を行ったり、サービス利用時に利用者端末４０を提示する。

また、利用者９４のそれぞれの住宅９１には、家庭内センサ（１）４＿１〜家庭内センサ（ｎ）４＿ｎが設置され、センサ情報は、それぞれの住宅９１の集約ルータ（１）５＿１〜集約ルータ（ｎ）５＿ｎで集約されネットワーク２を介して医療情報共有サーバ１０に送信される。家庭内センサ（１）４＿１〜家庭内センサ（ｎ）４＿ｎを区別しない場合は、単に「家庭内センサ４」として説明する。同様に、集約ルータ（１）５＿１〜集約ルータ（ｎ）５＿ｎを区別しない場合は、単に「集約ルータ５」として説明する。

医療機関９２は、医療機関端末２０を備え、ネットワーク２を介して医療情報共有サーバ１０に接続する。ここでは、図３に示すように、複数の医療機関９２のそれぞれに医療機関端末（１）２０＿１〜医療機関端末（ｎ）２０＿ｎが設置されている。医療機関端末（１）２０＿１〜医療機関端末（ｎ）２０＿ｎを区別しない場合は、単に「医療機関端末２０」として説明する。

医療機関端末２０は、ポータルサイト１０１から医療機関用サイト１１０にアクセスして、医療機関９２用に用意された機能を利用する。医療機関９２用に用意された機能とは、例えば、電子カルテシステム、臨床検査システム、医療会計システム、レセプト支援システム等の医療系システムがある。以下では、主に電子カルテシステムに着目して説明する。詳細は後述するが、電子カルテシステムやその他の機能は、例えば、シンクライアント環境（特にＶＤＩ（バーチャルデスクトップ環境）方式）として医療情報共有サーバ１０と協働で実現している。

医療機関９２は、自己の診療において作成した電子カルテ３０を地域共有ＤＢ１２に記録し、各医療機関９２は地域共有ＤＢ１２に記録されている電子カルテ３０を相互に参照して利用可能になっている。

また、電子カルテシステムは、医療情報共有サーバ１０がＡＳＰ（アプリケーションサービスプロバイダー）として提供する電子処方せんシステムと連係しており、処方せんを出力する際に、電子処方せんとして出力することができる。さらに、他の事業者が医療情報共有サーバ１０の地域共有ＤＢ１２に記録したデータを一定条件下で参照することができる。

なお、地域医療連携システム１は、エッジコンピューティング技術が適用された構成であってもよい。エッジコンピューティング技術や５Ｇ通信技術を適用するシステムを導入することで、地域医療連携システム１の利便性・セキュリティ確保を確保し、さらにシステム構築・変更を容易にできる。具体的には、エッジサーバは地域医療連携システム１の事務局・拠点に分散配置して個人情報関係データ（人ＤＢ１２０、事業者Ｂ１３０のデータ）を処理する。それ以外の処理については、上位クラウドのサーバで処理する。これによって、個人情報保護規制にも柔軟に対応できる。

薬局９６は、薬局端末６０を備え、ネットワーク２を介して医療情報共有サーバ１０に接続する。ここでは、図３に示すように、複数の薬局９６のそれぞれに薬局端末（１）６０＿１〜薬局端末（ｎ）６０＿ｎが設置されている。薬局端末（１）６０＿１〜薬局端末（ｎ）６０＿ｎを区別しない場合は、単に「薬局端末６０」として説明する。

このとき、薬局端末６０は、ポータルサイト１０１から薬局用サイト１６０にアクセスして、薬局９６用に用意された機能を利用する。薬局９６用に用意された機能とは、例えば、電子処方せんシステムがある。電子処方せんシステムは、医療情報共有サーバ１０がＡＳＰサーバとして機能し、医療機関９２が電子処方せんを登録し、薬局９６が電子処方せんを取得する。

商業施設９７は商業施設端末７０を備え、ポータルサイト１０１から商業施設用サイト１７０にアクセスして、商業施設９７用に用意された機能を利用する。商業施設９７用に用意された機能とは、購入履歴通知機能である。複数の商業施設９７のそれぞれに商業施設端末（１）７０＿１〜商業施設端末（ｎ）７０＿ｎが設置されている。商業施設端末（１）７０＿１〜商業施設端末（ｎ）７０＿ｎを区別しない場合は、単に「商業施設端末７０」として説明する。

具体的には、利用者９４が商業施設９７を利用すると、商業施設端末７０からその利用内容が医療情報共有サーバ１０に通知される。すなわち、商業施設端末７０は、ＰＯＳシステムの一部または連動する装置であって、利用者９４が提示する利用者端末４０や所定の物理カードに紐付いたＩＤを読み取り、そのＩＤと利用内容（購入履歴）を医療情報共有サーバ１０（後述の地域共有ＤＢ１２の地域決済装置１９）に通知する。また、地域医療連携システム１が、電子決済サービスを提供する場合には、利用者端末４０や物理カード等に紐付いた電子マネーを受領し、利用者９４の決済内容（すなわち購入履歴内容）を医療情報共有サーバ１０（地域共有ＤＢ１２）に通知する。

なお、購入履歴のデータは、上述のように見守りサービス（購入履歴参照機能）に利用される。したがって、その見守りサービスに有用な項目（例えば購入品目と個数）のみが通知されるようにし、個人情報に関して取り扱いに特に注意を要する項目（例えば具体的金額）については送信内容から省かれてもよい。また、購入品目についても、飲食物についてのみ通知されるようにしてもよい。利用者９４は、通知する項目を決定し設定できる。また、電子決済サービスとして、地域医療連携システム１独自に導入してもよいし、例えば、交通系ＩＣカードに関してＩＤ情報が解放され公共機関や民間企業で入出管理や勤怠管理、企業内の売店等での購入管理に利用可能となっているので、そのような技術を導入してもよい。

介護施設９８は介護施設端末８０を備え、ポータルサイト１０１から介護施設用サイト１８０にアクセスして介護施設９８用に用意された機能を利用する。介護施設９８用に用意された機能とは、例えば、ケアマネジメントシステム（アセスメント・計画書・月間計画を一体入力；介護支援経過記録の取込み機能）、訪問介護・看護支援システム、通所介護・看護支援システム、介護老人ホーム支援システムなどがある。

上述の事業者の情報処理端末、すなわち、医療機関端末２０、薬局端末６０、商業施設端末７０、介護施設端末８０がシンクライアント端末として、医療情報共有サーバ１０がその管理サーバとして、シンクライアント環境が構成される。

そのシンクライアント環境は、例えば、管理サーバの医療情報共有サーバ１０上に仮想デスクトップ環境を生成し事業者の情報処理端末から仮想デスクトップ環境を操作する仮想化技術（以下、「ＶＤＩ方式」）により構築されていることがより好ましい。適用される具体的な仮想化技術として、上述のように本出願人による特許第６３８４８４７号に開示の技術を用いる。なお、全てがシンクライアント環境として実現される必要はない。例えば、商業施設９７は全国展開するチェーン店のように特定の地域医療に特化されないこともあるから、商業施設端末７０は一般的なＰＣで構成され、ウェブ上で所定の機能が実行されてもよい。なお、地域医療連携システム１の一部又は全てがクラウド環境にて構築されても一定の効果を実現できる。

つづいて図４を参照して医療情報共有サーバ１０の構成、特に地域共有ＤＢ１２の構成について説明する。地域共有ＤＢ１２は、事業者システム支援サーバ１３と、クライアント用共通ソフトウェア１４と、登録管理部１５と、認証部１６と、見守り支援制御装置１８と、地域決済装置１９と、人ＤＢ１２０と、事業者ＤＢ１３０と、技術情報ＤＢ１３５とを備える。

事業者システム支援サーバ１３は、シンクライアント環境のシンクライアントサーバ（管理サーバ）として機能する。シンクライアント環境として様々な形式のものが提案されているが、上述のようにＶＤＩ方式を採用する。ＶＤＩ方式は、１台の高性能なサーバ上にハイパーバイザーを導入し、その上で仮想デスクトップ用の仮想マシンを利用者数分動かす。シンクライアント端末は、認証サーバおよび接続ブローカーを経由して、各ユーザに割り当てられた仮想デスクトップに接続する。

クライアント用共通ソフトウェア１４は、シンクライアント環境における各事業者のシンクライアントの情報処理端末（例えば医療機関端末２０）に用いられる各種ソフトウェア（アプリケーション）を保持する。すなわち、事業者システム支援サーバ１３がシンクライアントサーバとして仮想デスクトップを稼働させる場合に、その仮想デスクトップ上で稼働させるアプリケーションを保持する。また、利用者端末４０に導入されるアプリケーションを保持する。

登録管理部１５は、地域医療連携システム１を利用する利用者９４や、医療機関９２や薬局９６等の事業者や、それら事業者に所属する医師、薬剤師等を登録する。利用者９４の利用者情報については、利用者９４自身が登録するか、医療機関９２や薬局９６等の事業者を利用する場合に、利用者９４の同意のもと、それら事業者が登録する。また、利用者９４が見守りサービス（見守り機能）を利用する場合に、家庭内センサ４の登録や決済基本情報の登録も行う。

なお、登録する患者情報、事業者およびそれに所属する者の登録情報・登録処理の具体例については、後述する人ＤＢ１２０や事業者ＤＢ１３０等の説明とともに行う。

認証部１６は、事業者（医療機関９２、薬局９６、商業施設９７、介護施設９８）や利用者９４が地域医療連携システム１にアクセスする際に、登録管理部１５で登録された認証情報（認証手段の種類およびそれによる登録情報）にもとづき、認証処理を行う。また、家庭内センサ４のデータを取得する場合に、事前に登録されたＩＤ（ここではＩＭＥＩ）に基づく家庭内センサ４の認証も行う。

見守り支援制御装置１８は、センサ情報収集部１８１と、状態判定部１８２と、通知部１８３と、決済履歴取得部１８４と、地域イベント管理部１８５とを備える。

センサ情報収集部１８１は、家庭内センサ４からのセンサ情報を取得し、利用者ＤＢ１２１（蓄積データ１２１ｂ）に記録する。

状態判定部１８２は、センサ情報や購入履歴をもとに、利用者９４の生活状態や健康状態等を推定する。なお、状態判定部１８２は、推定の際に、人工知能（artificial intelligence：ＡＩ）を用いる。

通知部１８３は、状態判定部１８２が推定した結果、何らかの対応が必要な状態と判断した場合には、利用者９４本人やその支援者に通知する。具体的な処理は後述する。

決済履歴取得部１８４は、利用者９４が医療機関９２、薬局９６、商業施設９７等を利用したときの購入履歴（決済履歴）を取得する。

地域イベント管理部１８５は、利用者９４の居住地域の行政サービス、例えばゴミ収集日（ゴミ出し日）や、自治会・コミュニティセンターでのイベント等の日程を記録・管理する。家庭内センサ４のセンサ情報から、地域イベント管理部１８５が把握している「ゴミ出し日」の所定時刻までに玄関ドア９１４の開閉が確認できない場合には、利用者９４に通知することができる。また、「運動不足のようです。もっと外出しましょう。〇月×日にコミュニティセンターでイベントがあります。」といった通知もできる。また、防災情報や避難警報、避難経路、避難場所等を通知することもできる。特に、避難警報が出されているのにも拘わらず、家庭内センサ４のセンサ情報から在宅と推定できる場合には、継続して通知する処理も可能である。

地域決済装置１９は、上述したように地域医療連携システム１に参加する事業者（医療機関９２、薬局９６、商業施設９７）で利用可能な電子決済（いわゆる電子マネー）の決済処理を行い、決済履歴は決済履歴取得部１８４に通知される。

人ＤＢ１２０は、地域医療連携システム１を使用する者、すなわち利用者９４および事業者に所属する者の各種情報を記録し保持する。具体的には、人ＤＢ１２０は、利用者ＤＢ１２１と、医療関係者ＤＢ１２２と、薬剤師ＤＢ１２３と、介護士ＤＢ１２４と、電子カルテＤＢ１２５と、処方せんＤＢ１２６とを備える。

利用者ＤＢ１２１は、登録データ１２１ａと、蓄積データ１２１ｂとを備える。登録データ１２１ａは、所定の登録事項（利用者情報）を記録する。蓄積データ１２１ｂは、家庭内センサ４のデータ及び購入履歴を記録する。

ここで、図５に示す登録データ１２１ａの例を参照して、利用者９４の利用者情報の具体的な内容及び登録管理部１５による登録処理について説明する。

利用者９４自身が登録する場合は、利用者９４は地域医療連携システム１が運営するポータルサイト１０１から患者用サイト１４０の登録用ページにアクセスすることで、登録管理部１５による登録処理が行われ、人ＤＢ１２０の利用者ＤＢ１２１に所定事項が登録される。また、未登録の利用者９４が医療機関９２等を利用した場合に、その医療機関９２等が登録してもよい。

図５に示すように、登録データ１２１ａは、基本登録情報エリア１２１１と、登録情報１（医療）エリア１２１２と、登録情報２（電子決済）エリア１２１３と、登録情報３（見守りセンサ）エリア１２１４とを有する。

基本登録情報エリア１２１１には、利用者９４の基本的な情報として、「利用者ＩＤ」、「名前」、「生年月日」、「同居者の有無」、「住所」、「電話番号」、「電子メールアドレス」、「緊急連絡先１，２」、「認証手段および認証情報」が記録されている。上記の他に、例えば「血液型情報」や「身体的特徴（身長、体重、視力等）」等が登録されてもよい。

社会保障番号として、例えば、健康保険番号や政府管理の個人番号があり、その他の公的番号として運転免許証番号が用いられてもよい。現実の運用を考慮すると、健康保険番号が医療機関９２を利用した場合にのみ保険証による確認後に正式登録されることが望ましい。それまでの期間、社会保障番号は未登録状態で利用者情報は仮登録とする運用が想定できる。正式登録に移行することができる場所（機関）として、公的な身分証明書の提示が必要とされる上記の医療機関９２や薬局９６等がある。また、地方公共団体が地域医療連携システム１へ参加する場合には、地方公共団体事務所（役所）で正式登録がなされてもよい。

認証手段および認証情報は、複数種類の認証手段で登録できる。例えば、「パスワード」等の暗号手段や、「指紋認証」、「顔認証」、「声紋認証」、「虹彩認証」などの生体情報がある。スマートフォンやタブレット端末等のモバイル端末では、「指紋認証」、「顔認証」、「声紋認証」、「虹彩認証」などの様々な生体認証機能を利用できる。

図５の例において、基本登録情報エリア１２１１は、利用者ＩＤ「Ｃ０００１」、名前「ＡＢＣＤ」、社会保障番号「１１１１２２２３−１２３」、生年月日「１９５０年０５月０５日」、住所「○○区××１−１」、電話番号「０３−１２３４−ｘｘｘｘ」、電子メールアドレス「ａｂｃｄ１２３ｘｘｘ＠ｘｘｘ．ｘｘ．ｊｐ」、緊急連絡先１「０３−１２３４−ＸＹＺＷ（子）」、緊急連絡先「０３−１２３４−ＸＹＸＹ（ヘルパー）」、認証手段（パスワード）「ＸＸＸＸＸＸＸ」となっている。

登録情報１（医療）エリア１２１２には、医療関係の情報として、「掛り付け病院／薬局」、「ヘルパー」（または介護士）、「延命治療意思の有無」、「臓器提供意思の有無」、「要注意事項」、「注意薬情報／副作用情報」が記録されている。

「掛り付け病院」が記録されていることで、それ以外の病院に掛かったときに、その病院は必要に応じて登録されている「掛り付け病院」と連絡を取り合うことができる。さらに、緊急搬送が生じた場合に、まず「掛り付け病院」に連絡することができ、適切な処置を迅速に行える。また、「掛り付け薬局」があることで、医師が処方せんを出す場合に、薬の在庫状況を事前に把握できたりする。また、後述の医療機関端末２０で稼働する電子カルテシステムや薬局端末６０で稼働する処方せんシステムにおいて、医師や薬剤師が登録してもよい。このとき登録者の情報（医師ＩＤや薬剤師ＩＤ）も関連づけて登録される。

「延命治療意思」「臓器提供意思」について登録があることで、利用者９４が救急車等で医療機関９２に搬送された場合や死亡した場合等に、医療機関９２においてそれら意思の確認が円滑になり、その後の対応がスムーズになる。特に一人暮らしの高齢者の場合、そのような事項について普段からの意思確認が難しい状況も考えられる。このため、予め登録されていることで、見守り機能により高齢者に対して処置が必要となり本人直接の確認ができないときでも、親類等に連絡が行き駆けつけるまでの間に、医療機関９２等は利用者９４の意思を尊重した適切な対応が可能となる。

また、「緊急連絡先１，２」「ヘルパー」が登録されていることで、利用者９４に確認が難しい状態でも、家族・親類等への連絡が可能となる。また、「要注意事項」として既往症や手術歴等を登録することで、利用者９４に確認が難しい状況において、医療機関９２にて避けるべき処置を把握でき、治療を円滑にできる。「注意薬情報／副作用情報」では、利用者９４が自身の薬の履歴から副作用等により避けたいと考える薬があれば理由とともに登録する。

登録情報２（電子決済）エリア１２１３には、電子決済（いわゆる電子マネー）に関する情報として、「ＩＣ決済サービス用のＩＤ及び有効期限」、「ＱＲ決済サービス用のＩＤ及び有効期限」、利用者端末４０の「端末ＩＤ（ＩＭＥＩ）」が記録されている。

登録情報３（見守りセンサ）エリア１２１４には、住宅９１に設置された家庭内センサ４を用いた見守り機能に関する情報として、「伝送タイプ（個別または集約）」、伝送タイプが集約の場合の「集約ルータ５のＩＤ（ＩＭＥＩ）」、センサ（１）〜（５）の「センサタイプ及びＩＤ（ＩＭＥＩ）」が記録されている。センサタイプは、上述した家庭内センサ４のタイプで、環境センサ、人感センサ、ドアセンサ、音響センサ、トイレセンサ等がある。なお、センサ（１）〜（５）に関する情報として、設置位置が登録されてもよい。トイレセンサは、トイレのドアの開閉を判断するセンサであり、ドアセンサや音響センサと同じまたは組み合わせたセンサにより実現できる。

図５の例では、伝送タイプ「集約」、集約ルータ５のＩＤ（親機ＩＭＥＩ）「ＡＡ−ＢＢＢＢＢＢＢ―ＣＣＣＣＣＣ−ＦＦ」、センサ（１）「環境タイプ ＡＡ−ＢＢＢＢＢＢＢ―ＣＣＣＣＣＣ−ＦＡ」、センサ（２）「音響タイプ ＡＡ−ＢＢＢＢＢＢＢ―ＣＣＣＣＣＣ−ＦＢ」、センサ（３）「人感タイプ ＡＡ−ＢＢＢＢＢＢＢ―ＣＣＣＣＣＣ−ＦＣ」、センサ（４）「ドアタイプ ＡＡ−ＢＢＢＢＢＢＢ―ＣＣＣＣＣＣ−ＦＤ」、センサ（５）「トイレタイプ ＡＡ−ＢＢＢＢＢＢＢ―ＣＣＣＣＣＣ−ＦＥ」となっている。

なお、利用者９４は、登録時に、名前等の所定の必須開示項目以外について開示範囲を設定可能にしてもよく、どの項目をどの種の事業者（医療機関９２、薬局９６、商業施設９７、介護施設９８）、さらに事業者のどのような属性の人（医者、看護師、薬剤師、事務担当者など）に開示するかを決めることができる。例えば、医療機関９２に対しては全ての項目を開示し、薬局９６に対して必須開示項目以外は開示しないとすることができる。また、医療機関９２のうち医師には全ての事項を開示し、看護師について必須開示項目以外は開示しないとすることができる。患者情報の各項目は、例えばそれぞれの特性によりオプトイン・オプトアウトのいずれかに初期設定され、ユーザにより設定変更可能であってもよい。また、緊急救命の際の開示項目については、そのような初期設定やユーザが変更した設定に基づいてもよいし、全てを開示するようにしてもよい。

つぎに、図６を参照して、蓄積データ１２１ｂの例を説明する。蓄積データ１２１ｂは、購入履歴データを記録する購入履歴データ部１２１５と、家庭内センサ４のセンサ情報を記録するセンサ履歴データ部１２１６とを有する。

購入履歴データ部１２１５には、利用日（購入日）、決済手段の「種別（電子マネー、現金等）」、利用場所（利用した事業者）、金額計、明細が記録される。図示の例では、利用日「２０１９．０６．０１」では、利用場所「Ａクリニック」「Ｃ薬局」については、種別「現金」、それぞれの金額計「７５０円」「６００円」となっている。明細リストは記録されていない。利用場所「ＸＸＸストア」については種別「電子マネー」で金額計「２１００円」、明細リスト「飲料水 １コ １００円、トマト １コ ２００円、鶏肉 １コ ２５０円、プリン ２コ ２００円、 のり弁 １コ ４００円、・・・」が記録されている。上述した状態判定部１８２は、例えば、「のり弁」を２日連続で購入して履歴から、高血圧（塩分過多）や脂質異常の虞があると判断し、その旨を利用者９４や支援者に通知する。

センサ履歴データ部１２１６には、登録されている家庭内センサ４のセンサ情報データおよび判定結果が記録されている。図では、判定結果のみ例示している。例えば、センシング日「２０１９．０６．０１」は、センサ（１）（環境センサ）「異常無し」、センサ（２）（音響センサ）「０５：３０に咳検出」、センサ（３）（人感センサ）「活動小」、センサ（４）（ドアセンサ）「０回検知」、センサ（５）（トイレセンサ）「１回」となっている。

例えば、センサ（２）（音響センサ）「０５：３０に咳検出」から上述した状態判定部１８２が「この住宅９１の利用者９４が体調不良の可能性あり」と判断すると、通知部１８３が登録されている支援者（例えば、図５の基本登録情報エリア１２１１の緊急連絡先１、２）に判断結果を通知する。

また、センサ（５）（トイレセンサ）「１回」から、状態判定部１８２がトイレの回数が少なくなっており「内臓系の疾患にかかり始めている虞がある」と判断すると、通知部１８３が登録されている支援者に通知する。

通知を受けた支援者は、対象の利用者９４に電話連絡したり、訪問したりする。これによって、一人暮らしの高齢者等が体調不良になった場合でも早期に対応でき重症化を防止できる。

また、センシング日「２０１９．０５．３０」にいて、センサ（１）（環境センサ）「１３：３０ 室温高」となっており、上述した状態判定部１８２は、「熱中症の虞あり」と判断し、利用者９４に注意を促す通知を行い、センサ（１）のデータが改善されない場合（ここでは、室温が下がらない場合、登録されている支援者や行政の担当者に通知する。

利用者９４の蓄積データ１２１ｂは、上記の他に、例えば、後述する利用者端末４０の生体情報取得部４２４で計測した血圧値や心拍データがある。これらデータを蓄積することで、データに特異なデータが生じた時に警告を発したり、関連の者に通知したりすることができ、早期予防が可能となる。また、救急要請を行った場合に、搬送時の救急隊員の判断の助けとなる。

つづいて、図７〜図９を参照して、事業者における登録情報について説明する。医療機関９２や薬局９６、商業施設９７、介護施設９８が登録する場合は、あらかじめ地域医療連携システム１の管理者から所定の権限を与えられた者が、それぞれの機関の所属者を登録する。地域医療連携システム１の管理者として、例えば、その地域の医師会（またはそれから委任された者）がある。

図７に示す医療関係者ＤＢ１２２の例を参照して、医療関係者の登録情報（事業者情報）を具体的に説明する。医療機関９２に所属する者（すなわち医療関係者）の登録項目として、「名前」「属性（医師、看護師、その他等）」「所属（所属１、所属２、・・・）」、「専門」、「認証情報」、「モバイル端末ＩＤ（ＭＡＣアドレスやＩＭＥＩ）」があり、登録されると医療関係者ＩＤが付与される。他の事業者に移動した場合は、所属変更処理がなされる。また、複数の事業者に所属することもでき、「所属１」「所属２」のように所属先が複数登録される。医師に関しては「専門分野」を登録できる。なお、医師や看護師、薬剤師のように国家資格等によって定められる職種については、医師会等の所定の機関によって登録されるようにしてもよい。

図７の例では、医療関係者ＩＤ「Ｄ０００３」で示される者について、名前「ＣＣＤＤ」、属性「医師」、所属１「Ａクリニック」、所属２「Ｂクリニック」、専門「内科」、認証情報「パスワード、顔認証、指紋認証」、モバイル端末ＩＤ「２１：４３：６５：８７：０９：ＢＡ」となっている。この情報から、医療関係者ＩＤ「Ｄ０００３」の者は、内科の医師であり、「Ａクリニック」と「Ｂクリニック」に所属することが分かる。また、ＭＡＣアドレス「２１：４３：６５：８７：０９：ＢＡ」のモバイル端末でシンクライアント端末２１と接続して、または、インターネット等のネットワーク２を経由して直接アクセス可能である。

図８に示す薬剤師ＤＢ１２３の例を参照して、薬局９６の従業者の登録情報（事業者情報）を具体的に説明する。薬局９６に所属する者の登録項目として、「名前」「所属」、「認証情報」があり、登録後に薬剤師ＩＤが付与される。例えば、薬剤師ＩＤ「Ｆ０００１」の薬剤師について、名前「ＧＧＨＨ」、所属「Ａ薬局」、認証情報「パスワード、指紋」が登録されていることが分かる。他の事業者に移動した場合は、所属変更処理がなされる。なお、薬剤師以外についても登録可能としてもよいが、その場合、アクセス可能な利用者９４の利用者情報について制限を持たせてもよい。

つぎに、図９の介護士ＤＢ１２４を参照して、介護施設９８の従業者（介護士やケアマネージャ等）の登録情報（事業者情報）を具体的に説明する。介護施設９８に所属する者の登録情報として、「名前」「所属」「属性」「認証情報」があり、登録後に介護士ＩＤが付与される。例えば、介護士ＩＤ「Ｇ０００４」の従業者について、名前「ＱＱＲＲ」、所属「Ｂ老人ホーム」、属性「ケアマネ、介護士」、認証情報「パスワード、指紋」が登録されていることが分かる。他の事業者に移動した場合は、所属変更処理がなされる。

図４の説明に戻る。電子カルテＤＢ１２５は、医療機関９２で作成された電子カルテのデータが、患者である利用者９４と関連づけられて記録される。処方せんＤＢ１２６は、医療機関９２で作成された処方せんのデータが利用者９４及び管理番号と関連づけられて記録される。処方せんＤＢ１２６は、薬局９６が薬を利用者９４に出すときに薬局端末６０で参照され、実際に出した際の具体的な情報（日時、薬名、メーカ、量等）が追記される。利用者９４の電子カルテや処方履歴が記録されているため、後述の診療等の際に医師の判断が容易になるだけでなく、意識不明の状態の利用者９４が救急車等で搬送されてきた場合に、本人確認さえできればどのような治療がなされてどのような薬が処方されているかが分かるため、無駄な検査を省き、早急な処置が可能となる。

技術情報ＤＢ１３５は、例えば薬事情報ＤＢと、医療情報ＤＢと、機器管理ＤＢと、を備える。薬事情報ＤＢには、医薬品に関する安全情報が記録されている。安全情報は、製薬会社によって登録・更新されたり、地域医療連携システム１の管理者等によって登録・更新される。医療情報ＤＢには、公的機関や医師会による感染症の情報や、地域医療連携システム１に参加している事業者による情報が記録・更新される。機器管理ＤＢは、それぞれの医療機関に設置されている医療機器等、さらにＡＥＤについての設置状況（例えば設置位置、導入時期、メンテナンス状況等）が記録されている。ＡＥＤの設置状況については、利用者端末４０等からの問い合わせがあった場合に、設置場所が容易に分かるように設置状態の画像データが記録されている。

つづいて、図４と図１０を参照して事業者ＤＢ１３０を説明する。事業者ＤＢ１３０は、事業者自体の情報を登録・記録するものであり、地域医療連携システム１の管理者によって登録される。具体的には、事業者ＤＢ１３０は、病院ＤＢ１３１と、薬局ＤＢ１３２と、商業施設ＤＢ１３３と、介護施設ＤＢ１３４とを備える。

図１０（a）の病院ＤＢ１３１に示すように、医療機関９２の登録情報として、「医療機関ＩＤ」「名称」「種別」「診療科」「予約連携」「住所」「電話番号」「代表者（ＩＤ）」「所属者（ＩＤ）」「登録端末（ＭＡＣ）」「予約」「申請」がある。「種別」とは医療機関９２の種別であり、病院であるか診療所（種別：０４）であるかの種別や、病院であれば特定機能病院（種別：０１）、地域医療支援病院（種別：０２）、その他の一般病院（種別：０３）等の種別である。「予約連携」とは、救急患者等が発生した場合等に、電話等の従来の連絡手段の他に、地域医療連携システム１を用いて医療機関９２同士が連絡を取り合う緊急連携機能（連携：１１）や医療機関９２間での予約機能（連携：１２）に参加するか否かである。その他に、医療機関９２のホームページアドレス等が登録されてもよい。「予約」は、利用者９４がその医療機関９２を予約する機能の有無を示す。なお、「申請」は、利用者９４が各種申請を行う機能を提供する機能の有無を示す。

例えば、医療機関ＩＤ「２０００１」の医療機関端末２０について、名称「Ａクリニック」、種別「０４：診療所」、診療科「内科、アレルギー科」、連携「１１：緊急連携、１２：予約連携」、住所「○○市××８−７」、電話番号「ＸＸ−１２３−３４ＸＸ」、代表者の名前（ＩＤ）「ＡＡＢＢ（Ｄ０００１）」、所属者（ＩＤ）「ＢＢＣＣ（Ｄ０００２）、ＣＣＤＤ（Ｄ０００３）、・・・」、登録端末のＭＡＣアドレス「１２：３４：５６：７８：９０：１２、・・・」、予約「〇」、申請「〇」であることが分かる。したがって、例えば、登録端末の情報から、医療機関ＩＤ「２００１」の病院では、ＭＡＣアドレス「１２：３４：５６：７８：９０：１２」の端末（医療機関端末２０）がシンクライアント端末として、医療情報共有サーバ１０にアクセスすることになる。また、医療機関ＩＤ「２００１」の医療機関端末２０は、地域医療連携システム１が提供する緊急連携機能及び医療機関９２間での予約機能に参加していることが分かる。さらに、利用者９４は、Ａクリニックの診療予約や各種の申請を利用できる。

図１０（ｂ）の薬局ＤＢ１３２、図１０（ｃ）の商業施設ＤＢ１３３、図１０（ｄ）の介護施設ＤＢ１３４についても同様に、各事業者の登録情報として、「事業者（薬局ＩＤ、製薬機関ＩＤ、介護施設ＩＤ）」「名称」「住所」「電話番号」「代表者（ＩＤ）」「所属者（ＩＤ）」「登録端末（ＭＡＣ）」がある。それらの事業者からは、登録端末（ＭＡＣ）の情報処理端末（薬局端末６０、商業施設端末７０、介護施設端末８０）からのみ医療情報共有サーバ１０にアクセスできる。

つづいて、図１１に示す利用者端末４０の機能ブロック図を参照して、利用者端末４０の概略構成について説明する。

利用者端末４０は、一般的な情報処理端末（スマートフォンやタブレット端末等）と同じように、ユーザＩＦ４２１と、表示部４２２と、通信ＩＦ４２３と、生体情報取得部４２４と、位置情報取得部４２５と、認証部４２６とを備える。認証部４２６は、指紋認証機能の指紋認証部４２６ａ、顔認証機能の顔認証部４２６ｂ、声紋認証の声紋認証部４２６ｃ、虹彩認証の虹彩認証部４２６ｄを備える。生体情報取得部４２４は、例えば、光センサを用いた血圧センサや脈拍センサ等であって近年スマートフォンに搭載されている公知の機能を用いることができる。また、近年、カメラで顔画像を撮影し、微妙な変化から心拍数を検出する技術も搭載されており、そのような技術を用いることもできる。

利用者端末４０は、さらに、地域医療共有アプリケーション４２７と、家庭センサ管理部４２８と、購入履歴処理部４２９とを備える。

地域医療共有アプリケーション４２７は、地域医療連携システム１を利用する際に用いるアプリケーションであり、この地域医療共有アプリケーション４２７を起動させて、ホーム画面４３０からポータルサイト１０１にアクセスしたり、見守り機能のセンサ設定や購入履歴表示機能を実行する。

家庭センサ管理部４２８は、住宅９１に設置する家庭内センサ４を登録・管理する。家庭内センサ４の登録方法については、図１４で後述する。

購入履歴処理部４２９は、医療機関９２や商業施設９７等で支払をしたときに、支払内容を購入履歴として取得する。電子決済サービス（すなわち電子マネー）を利用する場合に、電子レシートのデータを取得し、地域共有ＤＢ１２の決済履歴取得部１８４に通知する。現金決済等により電子レートのデータ（すなわち直接的に決済履歴取得部１８４に送信できるデータ）が無い場合、所定の入力画面を開いて手入力したり、一般的な紙のレシートをカメラで撮影しＯＣＲ処理等によって電子化データを得て、それを決済履歴取得部１８４に通知する。

以上の構成の地域医療連携システム１によって提供されるサービス等の具体例を説明する。図１２は、利用者９４が医療機関用サイト１１０にアクセスして利用できるサービスの例を示した図である。利用者９４は、利用者端末４０でネット閲覧用アプリケーションを起動し、医療機関用サイト１１０のポータルサイト１０１にアクセスする。また、地域医療共有アプリケーション４２７が導入されている場合は、地域医療共有アプリケーション４２７を起動させてホーム画面４３０からポータルサイト１０１にアクセスする。ネット閲覧用アプリケーションの「患者／一般」ボタン１０１Ａや地域医療共有アプリケーション４２７のホーム画面４３０の「患者／一般」選択アイコン４３１を押下することで、表示は患者／一般用ポータルサイトへ遷移する。

患者／一般用ポータルサイトでは、画面上部に「病院リスト」「薬局リスト」「マイページ」の選択ボタンが設けられている。「病院リスト」が選択されると、地域医療連携システム１に参加している医療機関９２が、診療科毎にリスト表示される。「薬局リスト」が押下されると、同様に、地域医療連携システム１に参加している薬局９６の一覧が表示される。なお、利用者９４が登録済みで認証処理を行ってアクセスしている場合には、利用者９４の住所から近い順や、利用履歴が多い医療機関９２の順で表示されてもよい。

図示の病院リスト画面Ａ１１の例では、内科の病院一覧が示されている。一覧では、病院名、住所が記載されており、さらに、一部の病院名の横には予約ボタンと申請ボタンが設けられている。例えばＡクリニックの予約ボタンが押下されると、Ａクリニックに関する病院個別予約画面Ａ１２に遷移する。図示の病院個別予約画面Ａ１２では、予約登録タブが選択されており、数日間（ここでは１／２３〜１／２６）の予約状況（混雑状況）が「〇（予約枠有り）」、「△（予約枠少）」、「×（予約不可）」、「−（休診）」で示されている。「〇」「△」については押下可能になっており、押下することで、所定の予約画面（図示せず）に遷移する。なお、予約確認タブが選択されると、予約済みの場合には、予約した内容が表示される。

病院リスト画面Ａ１１の下側には、予約可能病院リストボタンが設けられている。このボタンを押下することで、予約可能病院リスト画面Ａ１３が表示される。診療科毎の予約可能病院の予約可能状況／混雑状況が「〇」「△」「×」「−」で選択可能に一覧表示されており、所望の病院／日時を押下することで、所定の予約画面に遷移する。

このように、ポータルに実装し地域の外来予約システムを地域でシェアするサービスを実現できる。利用者９４は、初診外来を希望する日に他の患者の予約状況から混んでいる時間帯を目視で判明でき、また、混み具合から比較的空いている時間帯を選んで予約できる。地域連携のオーダリングであるため、同じ科の病院一覧から現在の病院の混み具合や利用者９４の待ち時間が目視でき、空いている病院をリアルタイムで簡単に探せる。医療機関９２は、予約データから多角的に経営の分析・改善を行える。

また、病院リスト画面Ａ１１において、病院名の横に「申請ボタン」が設けられている場合、そのボタンを押下することで、申請画面Ａ１４に遷移する。申請画面Ａ１４では、申請書関係タブが選択されている場合には、診断書、証明書、紹介状等を申請でき、領収関係タブが選択されている場合には、診療明細書や領収証明書等を申請できる。

「マイページ」が選択されると、その利用者９４の利用者情報が表示される。すなわち、「通院履歴」、「薬の処方履歴」、「登録事項」、「見守りセンサ設定」、「購入履歴」を表示できる。図示のマイページ画面Ａ１５の例では通院タブが選択されており、「２０１８年１月２３日 Ａクリニック」の利用を先頭にして４件の通院履歴が表示されている。それぞれのリストを押下することで、利用時の電子カルテ（医療機関９２が閲覧可とした事項）や処方せんを閲覧できる。すなわち、利用者９４は、電子カルテＤＢ１２５や処方せんＤＢ１２６に記録されている自身のデータを全て又は一定範囲において閲覧できる。また、マイページ画面Ａ１６の例では薬の処方履歴を示す薬タブが選択されており、「２０１８年１月２３日」に、「ＸＹ調剤薬局」で「Ａクリニック」で出された処方せんにより薬を受け取ったことが表示されている。このマイページ画面Ａ１６で下段領域の「一覧表示」ボタンを押下することで、直近の所定期間の処方履歴の一覧が表示される。

図１３は「見守りセンサ設定」タブが選択された時のマイページ画面Ａ１６a〜１６ｃを示す。図１３（ａ）のマイページ画面Ａ１６aでは、センサ（１）、（２）が設定されている。画面下の「センサ追加」ボタンが押下されると、図１３（ｂ）のマイページ画面Ａ１６ｂに遷移する。センサＩＤの「検出」ボタンを押下すると、追加対象のセンサが表示される。ここでは、センサＩＤ「ＡＡ−ＢＢＢＢＢＢ−ＣＣＣＣＣＣ−ＦＣ」が検出されている状態である。この画面で、センサタイプおよび設置場所を選択し、「登録」ボタンを押下することで、登録処理が行われ、図１３（ｃ）のマイページ画面Ａ１６ｃに遷移する。センサ検出及び登録処理は、一般的な処理にて行われる。

図１４は、守りサービスにおける購入履歴確認のマイページ画面Ａ１６ｄの例を示した図であり、「購入履歴」タブが選択されたときに、利用者ＤＢ１２１の購入履歴データ部１２１５の内容が表示される。図示の例において、利用日「２０１９．０６．０１」では、利用場所「Ａクリニック」「Ｃ薬局」については、各金額計「７５０円」「６００円」となっている。利用場所「ＸＸＸストア」については金額計「２１００円」、と明細リストとして「飲料水 １コ １００円、食パン １コ １３０円、トマト １コ ２００円、鶏肉 １コ ２５０円、プリン ２コ ２００円、・・・」が表示されている。高齢者等の利用者９４は、買い物の際に、この画面を確認することで、直近に購入している物を把握でき、重複購入を防げる。

つぎに、図１５を参照して医療機関９２における医師の電子カルテシステム使用例を説明する。図１５は医療機関端末２０のシンクライアント端末２１に表示される電子カルテ３０の画面例である。画面上側領域３０１に、ログインユーザとして担当医の名前「ＡＡＢＢ」及び医療者ＩＤ「Ｄ０００１」が表示されている。その下には、患者プロフィール領域３０２が設けられており、利用者９４の名前「ＡＢＣＤ、生年月日/年齢／性別「１９５０．０５．０５生／６９歳／男性」、患者ＩＤ「Ｃ０００１」、その医療機関９２の診察券番号「０００３５」、既往歴「高血圧」、アレルギー「−（無し）」が表示されている。

患者プロフィール領域３０２の右側には、見守り機能に関する注意欄３２１が設けられている。患者が見守りサービス（見守り機能）を利用している利用者９４であり、購入履歴から対応すべき状態と判断されると、この欄に、所定の表示がなされる。例えば、「栄養」と表示されると、購入履歴から栄養に偏りがある可能性が高いと判断されており、医師や栄養士等の専門家による面談・説明が必要であることを示している。注意欄３２１を押下すると、購入履歴が表示される。

患者プロフィール領域３０２の下側には、「受付」「診察」「会計」の３つのボタン３０３が設けられており、ここでは「診察」が選択されている。さらにそれらボタンの下側領域には、診療記録領域３０４が設けられている。診療記録領域３０４の左１／３が前回診療領域３１１、右２／３が今回診療領域で、その左半分がＳＯＡＰ記載領域３１２、右半分がＯＲＤＥＲ記載領域３１３である。ＯＲＤＥＲ記載領域３１３では、薬選択欄を表示させて処方する薬をリストから選択記入する。

診療記録領域３０４の右側には、利用履歴領域３０５が設けられている。利用履歴領域３０５では、タブ選択により自病院履歴領域３０６と他診察等領域３０７とを指定して表示できる。ここでは他診察等領域３０７が選択されており、他診察等領域３０７では、他診察履歴領域３０８と、処方せん履歴領域３０９が設けられている。

他診察履歴領域３０８には、同じ利用者９４の患者ＩＤ（ここでは「Ｃ０００２」）をキーとして電子カルテＤＢ１２５から電子カルテのデータが参照・抽出され、他の医療機関９２の診察履歴が過去所定期間（例えば１年間）について表示される。処方せん履歴領域３０９には、同じ利用者９４の患者ＩＤをキーとして処方せんＤＢ１２６から処方せんのデータが参照・抽出される他の医療機関９２による処方履歴が過去所定期間（例えば１年間）について表示される。

医師は、利用者９４を診察する場合や薬を処方する場合に、他の医療機関９２の診察履歴や薬の処方履歴を同一画面で参照できる。利用者９４がどのような治療を受けてきたのかを知ることで、適切な治療方法を選択できる。特に、原因が不明の病気にかっていたような場合、紹介状があれば過去の治療履歴をその内容から又は利用者９４から確認できる。しかし、紹介状が無い場合や利用者９４が今回の治療で特にその病気とは異なり意識していない場合でも、診療に当たる医師が、過去の病気を考慮に入れて適切な治療法、処方する薬を選択できる。古い薬を使用している場合や既に無くなってしまった場合に、新たに利用者９４に処方する薬を絞り込む参考になる。

また、様々な疾患を抱えている高齢者等の利用者９４では、複数の薬が処方され多剤服用や多剤併用の状態（いわゆるポリファーマシー）の場合がある。例えば、複数の医療機関９２から合計で５種類の薬が処方されていた場合に、ある医療機関９２の医師は総合的に勘案した場合に３種類で充分と判断し、処方を変更することで、処方量を抑制させることができ、最終的には薬剤費用を低減できる。このようなときに、医療機関端末２０の電子カルテシステムの機能として、先に処方している医療機関９２に対して変更を通知・受信する機能を付与することで、その利用者９４に対する最新の治療方針、処方方針を先の医療機関９２も把握できる。また、利用者９４が介護施設９８を利用している場合に、介護施設９８の介護施設端末８０においても、そのような通知を受信する機能を有することで、利用者９４に関連する人の間で薬の変更を共有できる。

利用者９４は、過去の治療履歴について、記憶が曖昧になって正確な情報（病気名や薬名）を伝えられないこともあり、場合によっては、誤った不適切な情報を伝える虞もあるが、そのような状況を防止できる。さらに、同一・類似の薬効の薬が別の医療機関９２で重複して多く処方されていることを発見しやすい。この種の状況は、不法な薬の転売を目的としたことも多くあるため、医師が早期に不法な処方を防止できる。なお、処方せんＤＢ１２６に、不適切な処方の有無を判断する監視機能を設けてもよい。転売目的となる薬は一定程度判明しているので、監視対象となる薬を登録し、重複処方が発生した場合に、医療機関９２の電子カルテシステムや薬局９６の処方せんシステムで警告を出し、医師等の確認を取ってもよい。

つぎに、図１６〜図１９を参照して、見守りサービス（機能）の処理の例を説明する。
図１６は在宅状態の判断処理のフローチャートである。地域共有ＤＢ１２の状態判定部１８２は、家庭内センサ４から取得したセンサデータをチェックする（Ｓ１０１）。チェック対象のセンサデータは、特定の種類の家庭内センサ４、例えば、人感センサのデータのみでもよいし、複数種類のセンサのデータを組み合わせたものでもよい。以下では、人感センサのデータのみで判断する例を示す。

センサデータのチェックにより利用者９４が在宅していないと判断した場合（Ｓ１０２のＮ）、状態判定部１８２は蓄積データ１２１ｂに「不在」を記録する（Ｓ１０３）。在宅と判断した場合（Ｓ１０２のＹ）、利用者９４が活動中か否かを「高」「低」で判断する（Ｓ１０４）。利用者９４が家事（掃除など）等で活発に活動している状態であると判断すると（Ｓ１０４のＹ）、状態判定部１８２は蓄積データ１２１ｂに活動状態「高」を記録する（Ｓ１０５）。利用者９４が睡眠等で活動していない状態であると判断すると（Ｓ１０４のＮ）、状態判定部１８２は蓄積データ１２１ｂに活動状態「低」を記録する。

図１７は、環境センサのデータチェックにより住宅９１が住環境として適正な状態（ここでは温度・湿度の状態）にあるか否かを判断する処理のフローチャートである。状態判定部１８２は、環境センサのデータをチェックし（Ｓ２０１）、適正な状態であるか否かを判断する（Ｓ２０２）。適正であると判断した場合（Ｓ２０２のＹ）、状態判定部１８２は蓄積データ１２１ｂに環境状態が「適正」を記録する（Ｓ２０３）。

不適正であると判断した場合（Ｓ２０２のＮ）、状態判定部１８２は蓄積データ１２１ｂに「不適正」を記録するとともに、利用者９４本人に住環境が不適正な状態（「温度が高すぎる」や「湿度が低すぎる（乾燥状態）」）を通知する（Ｓ２０４）。利用者９４に通知後一定期間内に環境センサのデータから住環境が適正なレベルに調整されたと判断できる場合（Ｓ２０５のＹ）、状態判定部１８２は、「環境調整済み」を蓄積データ１２１ｂに記録する。

環境センサのデータに変化が無い場合（Ｓ２０５のＮ）、状態判定部１８２は、登録されている支援者に対して環境が不適正な状態であり利用者９４に調整の動きが見られない旨を通知し（Ｓ２０７）、利用者９４に通知後も不適正な状態が続いている旨及び支援者へ通知した旨を蓄積データ１２１ｂに記録する（Ｓ２０８）。高齢者の場合、温度・湿度と言った環境の変化に対して鈍感になりやすく、住宅９１が高温になっていることを感じられず熱中症になってしまうこともある。しかし、上記の処理で、早期に環境が不適切であることを利用者９４本人や支援者に通知でき、重大な自体になる前に対処できる。

図１８は音響センサのデータチェックにより住宅９１またはその住人の利用者９４に対処が必要な状態にあるか否かを判断する処理のフローチャートである。ここでは寝室に設置された音響センサにより咳を検出する。状態判定部１８２は、音響センサのデータをチェックし（Ｓ３０１）、咳と判断できる音が含まれているか否かで利用者９４に病気の兆候があるか否かを判断する（Ｓ３０２）。病気の兆候がなければ（Ｓ３０２のＮ）、状態判定部１８２は蓄積データ１２１ｂに「兆候無し」を記録する（Ｓ３０３）。

病気の兆候があれば（Ｓ３０２のＹ）、状態判定部１８２は利用者９４に通知すると共に（Ｓ３０４）、登録されている支援者にも通知し（Ｓ３０５）、「兆候あり」及び「通知済み」を蓄積データ１２１ｂに記録する（Ｓ３０６）。

なお、寝室に設置された家庭内センサ４の検出処理において、上記の「咳（病気の兆候）」を推定する他に、例えば、睡眠時に布団がずれる音すなわち寝返り音や、いびき音を採取することで、睡眠時無呼吸や寝返りの回数を推定し、実際の睡眠が良好であるかいなか、健康的であるかを推測してもよい。

図１９は見守りサービスにおける購入履歴確認処理の例を示したフローチャートである。利用者９４の購入履歴をもとに栄養の偏りや認知症の早期発見をすることを目的としている。状態判定部１８２は、蓄積データ１２１ｂの購入履歴データ部１２１５に記録されている購入履歴をチェックし（Ｓ４０１）、所定期間（例えば１週間）の飲食物の履歴から、栄養に偏りがあるか否かを判断する（Ｓ４０２）。

栄養に偏りがあると判断した場合（Ｓ４０２のＹ）、状態判定部１８２は、利用者９４に通知するとともに（Ｓ４０３）、掛り付け病院に対して栄養指導の要請を通知する（Ｓ４０４）。掛り付け病院では、上述のように電子カルテ３０において、栄養指導の要請が合った旨が表示される。利用者９４に通知する場合に、例えば、「不規則で偏った食生活をしていませんか。抗酸化作用のある緑黄色野菜や魚などを、毎日積極的にとりましょう。お勧めは、〇〇料理です。」といったアドバイスをすることもできる。

栄養の偏りが無い場合（Ｓ４０２のＮ）または上記通知後（Ｓ４０４）、状態判定部１８２は利用者９４が同じ商品を一般に想定されるより頻繁に購入しているか否かを判断する（Ｓ４０５）。同じ商品を頻繁に購入していない場合、処理は終了する。

同じ商品を頻繁に購入している場合（Ｓ４０５のＹ）、状態判定部１８２は利用者９４本人に通知するとともに登録されている掛り付け病院や介護士等に認知症の発生の有無を確認するように要請の通知をする（Ｓ４０７）。認知症を発症すると、同じものを頻繁に購入し冷蔵庫等に在庫が増えていくことがある。また、認知症までではなくとも老化により記憶が衰えて在庫状況を忘れてしまう場合もある。このような場合に、早期に対応することができる。

高齢者の利用者９４にとって、健康で長生きするには、若い時又は現役時代のように、良く食べ、よく身体を動かし、よく眠り、適度に外出し日光を浴び (骨粗しょう症対策)、人と接触し会話しコミュニケーションを図る、そして勉強して様々な思考や考えることから脳を動かすことが必要である。このようなことを維持していることにより精神的、肉体的、そして病とは無縁に健康的な人生をおくれる。一般に、高齢になると、このような事が自覚なしに衰え始める。

本実施形態の地域医療連携システム１では、生活の中において、家庭内センサ４の情報や購買履歴を、利用者９４が意識しない状態（すなわち、知らず知らずの状態）で、利用者９４毎の生活データを蓄積していく。これによって、高齢者的生活習慣をライフデータとして、蓄積されたデータと比較や解析に対して、生活が変わった変化点、健康維持できなくなった時期、このままいくと体調不調になると考えられる変化時期、認知症の予兆時期、食事等の嗜好の変化時期等から推測し、利用者９４個人にケアや指導する内容をカスタマイズし、自治体の担当者や介護士介護ケアマネ、医師、栄養士、家族がその改善策等を伝える。このような見守りによる改善を継続していくことで、医療機関９２にかかることを抑制し、介護施設９８へ入居せずに自立した生活ができるようにアドバイス・支援することができる。

このように、高齢者ケアをピンポイントで行うことで、高齢者とういう理由だけで本来は必要のない者に対して行っていたケアを省くことができ、そのような高齢者へのケアを行う自治体のコストダウンを実現できる。また、高齢者の病気は、生活における嗜好の変化や行動の変化から推測できることがある。例えば、病気が誘発される変化、反対に医師は嗜好の変化や行動の変化を知りことで検査データと重ね合わせることにより改善策を導き出せるようになる。すなわち、投薬や処方といったことに頼らずとも、生活改善指導として、高齢者の処方費用を減らせる。これは、例えば日本において、後期高齢者医療保険の抑制につながり、処方しないことで大幅なコストダウンにつながる。換言すると、患者は薬代の削減、自治体は健康保険費抑制の恩恵を得られる。

また、介護施設９８では、新たな業務として施設周辺の高齢者（利用者９４）とのパイプ役として、様々なコミュニケーションを行う第二の高齢者生活支援事業としての拡大が見込まれる。

また、状態判定部１８２は、ＡＩ機能によって、購買履歴より、摂取量が多いと高齢者の体に良くない物、例えば醤油等の購入期間が一般より短いサイクルで消費していると推定し、食事の改善を促すことで高血圧症（塩分過多）になるのを防止できる。さらに、購入履歴と医療機関９２の血液データ（電子カルテＤＢ１２５に記録されているデータ）とを電子カルテ上に表示させて照らし合わせることにより、医師は的確な治療や指導を行うことができる。また、ネットワーク対応型体重計４ａのデータを集めている場合には、そのデータの動き、さらに身体的特徴のデータが登録されている場合にはそのデータも反映させて、健康状態の変化を推定することができる。

同様に漬物・佃煮・そばつゆ・塩、ラーメンの購入頻度（摂取）で塩分過多となり胃がんのリスクが上がるため、胃カメラ検査を抑制でき胃癌治療を食事指導で抑制でき処方薬・検査・がん治療の患者負担・国民健康保険料の抑制につながる。

なお、季節によっては問題にならない事をＡＩが答えを出すことも考えられる。例えば、夏場の場合は熱中症を考慮すると冬場より塩分を多くとっても問題ないため冷奴等夏場に欲しがる食品で醤油を多く取るようになる分には高齢者の身体にとって必ずしも悪いことでは無く良い場合もある。夏場の温度管理や熱中症予防として水分や塩分の摂取を監視管理することはとても重要であり熱中症による緊急搬送等を抑制できる。

高齢者の生活習慣病の割合が増加しており、これは認知症にもつながってしまう。認知症につながる主な生活習慣病として、糖尿病、脂質異常症、高血圧等がある。また、認知症になりやすい生活習慣として、バランスの悪い食生活、運動不足、アルコールの飲み過ぎ、たばこ等がある。

例えば、さらに動物性脂肪（牛肉・豚肉・鶏肉）、ラード、バター、マーガリン、生クリームの摂取（購入）が常に頻繁に多いと脂質異常症リスクが高くなる。パン、パスタ、ごはん（米）、うどん、砂糖、果糖品の購入が多いと糖尿病リスクが高くなる。これらが購入履歴に頻繁に現れる場合は、状態判定部１８２は、ＡＩ機能により、脂質異常症リスクや糖尿病リスクが高いと判断する。また、アルコール飲料の購入頻度が多い高齢者（利用者９４）については、通知部１８３による通知の際に、アラーム内容（頻度や警告レベル）を上げることで、アルコール依存症リスクから回避することができる。アルコール依存者は医者に対して正直に話さない傾向がある。購入間隔や内容量から一日当たりの摂取量が推定できるので、アルコールの摂取量が医師に分かり、適切な対応が可能となる。

このように、家庭内センサ４や購買履歴から生活習慣を推定できるので、食生活の改善、積極的な運動、アルコール過多やタバコへの注意喚起をすることで、見守り対象の高齢者である利用者９４の健康的な生活維持を実現できる。また、地域医療連携システムに利用者９４の診療データ・検査データが蓄積されているので、それらデータと家庭内センサ４等からの生活習慣の予測結果から、生活習慣病の予備群を早期に検出・対応することで、生活習慣病にかかることを予防できる。

また、状態判定部１８２は、ＡＩ機能により、医療機関９２の診療情報（電子カルテＤＢ１２５の電子カルテのデータ）から、高齢者自身が持っている病気や病状からこういった物を食べてはいけない物（メニューや材料、調味料、アルコール、タバコ）を判断できる。これらが購買履歴から出てきた場合、状態判定部１８２は要注意食品として、利用者９４（高齢者）本人に直接または支援者を介して、買い物の抑制や食事指導をすることができ、適切な健康管理につながる。

また、状態判定部１８２は、購入履歴から推定される摂取データと外出して帰宅するまでの歩いた時間から運動量を計算して、散歩等で一定の運動が見込める場合は、その運動の分だけ様々なリスクは低く推定できる。

ＡＩが食材から献立を自動提案するシステムも提案されている。この技術を適用し、状態判定部１８２は、ＡＩ機能により、購入した食材（材料）から、作れる献立（メニュー）を推測する。このとき、献立は２種類提案される。ひとつは健康に良い推奨するメニューであり、もう一つは健康に良くないメニューである。例えば、この２種類のメニューを利用者９４の年代毎（６０歳代用、７０歳代用、・・・）につくる。ＡＩ機能は、高齢者の嗜好を学び、高齢者嗜好パターンから高齢者用の献立として推測する。例えば、高齢者達が購入する購買データから、総菜を抽出し、し嗜好献立としてＡＩの学習用素材データとして学習する。毎日の食事と間食、サプリメントに加えて、様々な身体情報をＡＩが総合的に判断し、栄養素の過不足を推定する公知技術が市販化されており、そのような技術を適用することができる。

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

１ 地域医療連携システム
２ ネットワーク
４ 家庭内センサ
５ 集約ルータ５
１０ 医療情報共有サーバ
１１ 統括装置
１２ 地域共有ＤＢ
１３ 事業者システム支援サーバ
１４ クライアント用共通ソフトウェア
１５ 登録管理部
１６ 認証部
１８ 見守り支援制御装置
１９ 地域決済装置
２０ 医療施設端末
２１ シンクライアント端末
３０ 電子カルテ
４０ 利用者端末
５０ 処方せん
６０ 薬局端末
７０ 商業施設端末
８０ 介護施設端末
９２ 医療機関
１００ 医療情報共有サイト
１０１ ポータルサイト
１１０ 医療機関用サイト
１２０ 人ＤＢ
１２１ 利用者ＤＢ
１２２ 医療関係者ＤＢ
１２３ 薬剤師ＤＢ
１２４ 介護士ＤＢ
１２５ 電子カルテＤＢ
１２６ 処方せんＤＢ
１３０ 事業者ＤＢ
１３１ 病院ＤＢ
１３２ 薬局ＤＢ
１３３ 介護施設ＤＢ
１３４ 商業施設ＤＢ
１３５ 技術情報ＤＢ
１４０ 患者用サイト
１６０ 薬局用サイト
１７０ 商業施設用サイト
１８０ 介護施設用サイト
１８１ センサ情報収集部
１８２ 状態判定部
１８３ 通知部
１８４ 決済履歴取得部
１８５ 地域イベント管理部
４２１ ユーザＩＦ
４２２ 表示部
４２３ 通信ＩＦ
４２４ 生体情報取得部
４２５ 位置情報取得部
４２７ 地域医療共有アプリケーション
４２８ 家庭センサ管理部
４２９ 購入履歴処理部

Claims (5)

1. 複数の医療機関が連携して所定の地域において医療を提供する医療システムであって、
   前記医療機関に備わる情報処理端末と、
   前記医療機関の前記情報処理端末と協働する医療情報共有サーバと、
   利用者の健康状態を管理する健康管理システムと、
   を有し、
   前記医療情報共有サーバは、
   前記医療機関を運営する事業者の事業者情報を記録する事業者データベースと、
   前記医療機関を利用する前記利用者の利用者情報を識別情報と関連付けて記録する利用者データベースと、
   前記利用者の商取引の履歴を取得する決済履歴取得部と、
   前記商取引の履歴を前記利用者の識別情報と関連付けて記録する利用者購入履歴データベースと、
   を有し、
   前記健康管理システムは、
   前記利用者を住人とする家庭内の環境状態を取得する家庭センサと、
   前記家庭センサと接続され外部と通信するセンサ通信部と
   前記センサ通信部を介して前記家庭センサのセンシング情報を収集する家庭情報収集部と、
   前記センシング情報を蓄積する家庭情報データベースと、
   前記センシング情報をもとに前記利用者の生活状態を判定する状態判定部と、
   前記状態判定部の判定結果を前記利用者または前記利用者の支援者の少なくとも一方に通知する通知部と、
   を備え、
   前記状態判定部は、前記商取引の履歴をもとに前記利用者の健康状態を推定し、
   前記通知部は、前記健康状態について改善が必要であると推定した場合に、前記支援者に対して通知する
   ことを特徴とする医療システム。
2. 前記医療機関に備わり、シンクライアント端末として機能する情報処理端末を有し、
   前記医療情報共有サーバは、
   前記情報処理端末とともにシンクライアント環境を構築するシンクライアント管理サーバと、
   前記シンクライアント環境において稼働させる医療系システムと、
   を有することを特徴とする請求項１に記載の医療システム。
3. 前記住人の前記商取引の履歴が前記利用者購入履歴データベースに記録されると、前記通知部は前記支援者に記録された旨を通知することを特徴とする請求項１または２に記載の医療システム。
4. 前記家庭センサは音響センサを含み、
   前記状態判定部は、前記家庭情報収集部で前記家庭情報データベースに蓄積した、前記音響センサのセンシング情報をもとに、前記住人の生活状態を推定する
   ことを特徴とする請求項１〜３までのいずれかに記載の医療システム。
5. 前記家庭センサは環境センサを含み、
   前記状態判定部は、前記家庭情報収集部で前記家庭情報データベースに蓄積した、前記環境センサのセンシング情報をもとに、前記住人の生活状態を推定する
   ことを特徴とする請求項１〜４までのいずれかに記載の医療システム。

Images