JP6910016B1 - 医療システム - Google Patents

Abstract

【課題】地域の医療機関が連携して共通で利用できる医療システムにおいて、患者の身体特徴のうち外形に関する身体特徴を取得して、治療に役立てる技術の提供と患者の生涯生計を提案する医療システムを提供する。【解決手段】地域医療連携システム１は、ユーザ（患者９４）の身体特徴（身体特徴情報）の一つとして外形寸法を取得する身体特徴取得部（身体形状センサ９０）と、医療施設９２の医療機関端末２０で稼働する電子カルテシステムと、を有する。電子カルテシステムは、製薬会社９７が提供する医薬品情報と医療機関９２がもつ症例情報とから薬の処方量に関する相関情報を算出する機能を有し、少なくとも外形寸法を含むユーザの身体特徴情報を前記相関情報に当てはめて最適な薬の分量を算出する処方量算出部を備える。【選択図】図２

Description

本発明は、医療システムに係り、例えば、医療・福祉に関わる複数の医療機関が連携して医療を提供する医療システムに関する。

近年、医療の分野では、地域における医療機関等の間で必要な情報連携を進めていくことが求められている。そのような地域医療連携ではＩＣＴ（Information and Communication Technology）が重要な役割を果たすことになり、様々な技術が提案されている。例えば、多くの医療現場では、病院情報システム(ＨＩＳ)や画像保管通信システム(ＰＡＣＳ)、放射線科情報システム（ＲＩＳ）等の医療情報システムの普及に伴い、医用画像及び医用文書の電子化が進んでいる。患者自身の身体特徴（例えば身長や体重など）の情報は、健康診断時には比較的正確なデータを得ることができるが、日常のデータについても正確なデータが求められる。そこで、ユーザが日常的に使用できる機器、例えば、体重計、活動量計、体脂肪計、脈拍計といった健康に関する健康情報を測定する健康機器のデータをネットワーク上に吸い上げ、医師の判断に利用する技術が提案されている（例えば特許文献１参照）。

特開２０１８−１０１２５５号公報

高齢化に伴う医療費の増大が社会問題として以前にも増して認識されるようになってきている。医療財源は限られており、診療や治療、処方をできるだけ過不足なく行うことが求められている。過不足行うには、患者の身体特徴を把握することが重要になる。特許文献１に開示の技術では、一定の正確性で患者の身体特徴を把握できる。しかし、これらは主に患者の身体内部特徴であり外形に関する身体特徴ではない。すなわち、患者の外形については把握することができない。

本発明は、以上のような状況に鑑みなされたもので、その目的は、地域の医療機関が連携して共通で利用できる医療システムにおいて、患者の身体特徴のうち外形に関する身体特徴を取得して、治療に役立てる技術を提供することにある。

本発明の医療システムは、
複数の医療機関が連携して所定の地域において医療を提供する医療システムであって、
ユーザの身体特徴の一つとして外形寸法を取得する身体特徴取得部と、
医療機関の医療機関端末で稼働する電子カルテシステムと、
を有し、
前記電子カルテシステムは、
製薬会社が提供する医薬品情報と医療機関がもつ症例情報とから薬の処方量に関する相関情報を算出する機能を有し、少なくとも前記外形寸法を含むユーザの身体特徴情報を前記相関情報に当てはめて最適な薬の分量を算出する処方量算出部を備える。

本発明によると、地域の医療機関が連携して共通で利用できる医療システムにおいて、患者の身体特徴のうち外形に関する身体特徴を取得して、治療に役立てる技術を提供することがきる。

本実施形態に係る、地域医療連携システムにおける患者の身体形状を計測して医療サービスに適用する例を示す図である。 本実施形態に係る、地域医療連携システムの概略構成を示す図である。 本実施形態に係る、地域医療連携システムのブロック図である。 本実施形態に係る、医療情報共有サーバのブロック図である。 本実施形態に係る、患者端末の概略構成を示す図である。 本実施形態に係る、身体形状センサによる身体形状（身体寸法）の算出処理例を示すフローチャートである。 本実施形態に係る、患者ＤＢの例を示す図である。 本実施形態に係る、医療関係者ＤＢの例を示す図である。 本実施形態に係る、薬剤師ＤＢの例を示す図である。 本実施形態に係る、介護士ＤＢの例を示す図である。 本実施形態に係る、事業者ＤＢの例を示す図である。 本実施形態に係る、患者が患者用サイトにアクセスして利用できるサービスの例を示した図である。 本実施形態に係る、医療機関端末のシンクライアント端末に表示される電子カルテの画面例である。 本実施形態に係る、処方システムの概略構成を示す図である。 本実施形態に係る、患者端末に表示される提供条件の一覧の例を示す図である。 本実施形態に係る、ある薬提供者（製薬会社Ｂ）の提供条件の詳細な例を示す図である。 本実施形態に係る、薬のサブスクリプション契約における一連の流れを統括したイメージの一例を示す図である。

次に、本発明を実施するための形態（以下、単に「実施形態」という）を、図面を参照して具体的に説明する。まず、図１を参照して本実施形態の概要を説明する。

患者９４は、伸縮可能な素材からなる着衣タイプの身体形状センサ９０を装着する。身体形状センサ９０は、上半身に装着する身体形状センサ（上）９０ａと下半身に装着身体形状センサ（下）９０ｂとに分かれている。以下、身体形状センサ（上）９０ａと身体形状センサ（下）９０ｂを特に区別しない場合は、身体形状センサ９０として説明する。

身体形状センサ９０は、伸縮可能な素材により構成される本体部に、複数ポリゴン状に配置された相対位置関係（伸長量）から装着している患者９４の外形寸法を計測するセンサ部と、を有する。伸縮性のある着衣として、スポーツ用のコンプレッションウエアがリーズナブルに入手可能である。このようなコンプレッションウエア（本体部に相当）にメッシュ状（ポリゴン状）に複数のセンサ（例えばポジションセンサや画像処理用マーカ）を取り付けて、センサの相対位置をセンシングし、形状を算出する。ポイント間の伸長により電気出力が変わる伸長センサや歪みセンサを適用してもよい。専門的な採寸技術のない者（患者や介護者、医師、看護師等）でも簡単に取り扱え、容易に採寸可能であり、更に局所的な形状についても一定の精度で把握できる。このような身体形状センサ９０として、例えば、特開２０１８−１４７０１３号公報に記載の技術を利用することができる。

患者端末４０には、身体形状センサ９０を制御するアプリケーション（図５で後述する）が導入されている。患者端末４０は、この身体形状収集アプリケーション４２７を起動させ、身体形状センサ９０のセンサ値を取得する（Ｓ１）。身体形状収集アプリケーション４２７は、取得したセンサ値から患者９４の身体寸法及び形状を算出し（Ｓ２）、医療情報共有サーバ１０の地域共有ＤＢ１２に送信する（Ｓ３）。なお、患者端末４０は、計測したセンサ値を地域共有ＤＢ１２に送信し、地域共有ＤＢ１２が身体寸法及び形状を算出してもよい。

地域共有ＤＢ１２は、患者９４の身体寸法及び形状を蓄積する（Ｓ４）。地域共有ＤＢ１２には、身体寸法及び形状と疾病の関連がデータベースとして蓄積されており、医療情報共有サーバ１０に接続する医療機関（医師）は、その身体寸法及び形状を診療時等において利用する（Ｓ５）。例えば、身体寸法及び形状から疾病を推定したり、それらの推移から特異な傾向が出来た場合に疾病発生を推定したり、健康管理（例えば肥満防止の生活習慣プログラム作成）に用いたり、薬の処方量最適化、薬の処方費用と生涯処方費用の算出などに利用する。医療機関で診察の結果、すなわち確定した疾病とそのときの身体寸法及び形状が地域共有ＤＢ１２にフィードバックされ、地域共有ＤＢ１２は、そのフィードバックを学習に反映させ、疾病推定精度を向上させる。学習として、機械学習やＡＩ学習等の公知の技術を利用することができる。

医師などの医療従事者が家族歴等の患者情報を熟知することで、家族歴が重要な遺伝性疾患（血友病、特定のガン等）や体質性疾患（糖尿病、高血圧等）について、疾患の特定及びその治療を早期に行えるようになる。

現在の医療現場では、蓄積データと医師による処方とを対応付けた学習を行うものではなく、データの解析結果をガイドライン等予め決められた指標に照らし合わせて処方を決定し、それが医師処方量となる。このため、解析の結果、同じような状態と判断した対象者には、処方の時期と種類を一律に設定する。しかし、対象者（患者９４）の詳細な状態は身体特徴や家族歴などにおいて様々であるため、処方が過剰になる者と不十分な者とが出てきてしまう。過剰な処方を行えばその分だけ医療費が無駄にかかってしまうことになるし、処方が足りなければ医療の質が足りていないということになる。近年、医療現場では患者それぞれの個性にかなった医療の取り組みとして、オーダメイド医療が進んでいる。オーダメイド医療では、患者の遺伝子情報を利用する等、個々人の医療情報に基づいて治療等を行うため、より患者に適した医療行為になり得ることが期待されており、患者の納得度や満足度を高めるための医療行為は近年重要視されている。医療現場では、患者の状況を把握するための医療行為として、医療面接を実施する。医療面接では、患者像をはじめ、主訴、現病歴、既往歴、家族歴等を患者に尋ね、電子カルテ等の診療録に記載する。一般に、現在の医療現場では、医療面接時に患者の家族歴等の患者情報を確認する手段は患者との対話に限られる。そのため、患者が医療従事者に患者情報を伝え忘れたり、医療従事者が聞き逃したりと、情報の漏れが多い。更に、患者自身が家族歴等を正確に把握していない場合や、医療面接の頻度が少ないことからも、従来の医療面接だけでは患者情報を十分に得ることが難しく、正確な診断をするための患者情報が不足する。これらの課題に対して、本実施形態では、客観的なデータ（身体形状や家族歴等）が医療現場に提供できる。

また、地域医療連携システムに、シンクライアント環境やエッジコンピューティング技術、５Ｇ通信技術を適用する。これらにより、高いセキュリティ確保を実現しつつ、低コストで導入する。すなわち、医療機関等の情報処理端末をシンクライアント端末とし、運営側の装置をシンクライアントサーバとすることで、各医療機関は低コストでシステム参入・運用を行える。また、エッジコンピューティング技術や５Ｇ通信技術により、緊急時の通信遅延といった懸念を解消する。

図２は本実施形態において実現する地域医療連携システム１の概略構成を示し、図３はその機能ブロック図である。図４は医療情報共有サーバ１０の概略構成を示す機能ブロック図である。

地域医療連携システム１では、ある範囲の地域において複数の医療機関（ここでは医療施設９２、薬局９６、介護施設９８を運営する事業者及び製薬会社９７）は、医療情報共有サーバ１０を用いて、患者９４等の利用者に対して、医療・福祉の商品・サービスを提供する。なお、医療・福祉の商品・サービスを提供する者として、これらに限る趣旨ではなく、ここでは特に説明していないが、例えば、医療用品、歯科材料、衛生用品などの医療機器を提供するものについても適用でき、その場合には製薬会社９７と同様の位置づけとすることができる。

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

また、上述のように、患者９４は、身体形状センサ９０で自身の身体形状を計測し、計測結果を患者端末４０を介して医療情報共有サーバ１０に送信し蓄積する。

図２や図４に示すように、医療情報共有サーバ１０は、統括装置１１と、地域共有ＤＢ１２と、医療情報共有サイト１００と、通信ＩＦ１９と、処方システム２００と、を備える。統括装置１１は、医療情報共有サーバ１０の構成要素を統括的に制御する。

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

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

患者９４は、自身のＰＣ（パーソナルコンピュータ）やタブレット端末、スマートフォン等の患者端末４０を用いて医療情報共有サーバ１０にアクセスする。ここでは、図２に示すように、患者９４のそれぞれが患者端末（１）４０＿１〜患者端末（ｎ）４０＿ｎを用いて医療情報共有サーバ１０にアクセスする。患者端末（１）４０＿１〜患者端末（ｎ）４０＿ｎには、身体形状センサ（１）９０＿１〜身体形状センサ（ｎ）９０＿ｎが接続され、それぞれの患者９４の身体形状を計測する。患者端末（１）４０＿１〜患者端末（ｎ）４０＿ｎを区別しない場合は、単に「患者端末４０」として説明する。
身体形状センサ（１）９０＿１〜身体形状センサ（ｎ）９０＿ｎを区別しない場合は、単に「身体形状センサ９０」として説明する。

患者端末４０がタブレット端末、スマートフォンの場合、専用のアプリケーションが導入され用いられてもよい。患者端末４０は、患者用サイト１４０にアクセスして、事業者が提供する商品・サービスを利用する。例えば、医療施設９２において診察を受ける場合に、医療施設９２のＷＥＢページにアクセスして診察を予約することができる。また、患者端末４０には、例えば「お薬手帳」アプリや「身体データ管理」アプリが導入され、医療情報共有サーバ１０と同期されて処方履歴を参照することができたり、身体形状センサ９０による身体形状の計測結果を管理できたりする。

ここで図５を参照して、患者端末４０の具体的構成について簡単に説明する。図４（ａ）が患者端末４０の機能ブロック図であり、図４（ｂ）が患者端末４０に導入された専用のアプリケーション（地域医療共有アプリケーション）のホーム画面４３０の例である。ここでは、スマートフォンを例に説明し、主に地域医療連携システム１のサービスに関連する部分について説明し、一般的な機能・構成については適宜省略する。

患者端末４０は、ユーザＩＦ４２１と、表示部４２２と、通信ＩＦ４２３と、生体情報取得部４２４と、ＧＮＳＳ（ＧＰＳ）等を用いた位置情報取得部４２５と、地域医療連携システム１を利用する際に用いる地域医療共有アプリケーション４２７とを備える。

生体情報取得部４２４は、例えば、光センサを用いた血圧センサや脈拍センサ等であって近年スマートフォンに搭載されている公知の機能を用いることができる。また、近年、カメラで顔画像を撮影し、微妙な変化から心拍数を検出する技術も搭載されており、そのような技術を用いることもできる。

認証装置４２６は、一般的なＩＤ/パスワードによる認証処理の他、生体情報を用いた認証処理機能を備える。すなわち、認証装置４２６は、指紋認証を行う指紋認証部４２６ａと、顔画像による認証を行う顔認証部４２６ｂと、声紋による認証を行う声紋認証部４２６ｃと、虹彩による認証を行う虹彩認証部４２６ｄとを有する。なお、認証に用いる生体情報はいずれか一つでもよいし複数組み合わせてもよい。

患者９４の操作によって地域医療共有アプリケーション４２７が起動すると、図４（ｂ）に示すように、患者端末４０の表示部４２２には、ホーム画面４３０が表示される。この例では、「患者／一般」選択アイコン４３１と、「救急１１９」アイコン４３２と、「救急かかりつけ病院」アイコン４３３と、「身体データ管理」アイコン４３４とが、選択可能に設けられている。

「患者／一般」選択アイコン４３１が押下されると、図１０で後述するサービス例（画面例）による処理が行われる。「救急１１９」アイコン４３２が押下されると、携帯電話回線によって救急指令センター装置５に接続される。「救急かかりつけ病院」アイコン４３３が押下されると、登録済みのかかりつけ病院と接続される。なお、かかりつけ病院については、病院ＤＢ１３１に診察時間等が登録されている。そこで、診察時間以外の時間帯には、アイコン表示を診察時間外である旨が判別可能に表示してもよい。なお、かかりつけ医療機関として「かかりつけ病院」を選択可能のアイコンを例示したが、その他に「かかりつけ薬局」や「介護福祉士やヘルパー」等の常習的に利用している医療機関や、さらに「親族」への接続アイコンが設けられてもよい。

「身体データ管理」アイコン４３４が押下されると、身体形状センサ９０により患者９４の身体形状を計測する処理が起動する。図６を参照して患者９４の身体形状を取得する処理例を説明する。「身体データ管理」アイコン４３４の押下により（Ｓ１１）、身体形状のデータ取得手段の選択画面が表示される（Ｓ１２）。例えば、患者９４は、身体形状センサ９０を用いるか、外部データベース５等の他装置に記録されているデータを用いるかを選択する。外部データベース５が選択されると（Ｓ１３のＮ）、所定の外部データベース５に記録されている身体形状のデータを取得する（Ｓ１４）。このとき、データ自体でなく、データのアクセス先を入手してもよい。

身体形状センサ９０を用いる場合（Ｓ１３のＹ）、身体形状センサ９０を装着してオン状態にし（Ｓ１５）、データ計測を行い（Ｓ１６）、計測したデータを用いて身体形状を算出する（Ｓ１７）。身体形状のデータが取得できたら（Ｓ１４，Ｓ１７）、身体形状のデータは、患者９４のＩＤと紐付けられて患者端末４０から医療情報共有サーバ１０（地域共有ＤＢ１２）に送信される（Ｓ１８）。なお、医療機関９２や介護施設９８で計測する場合には、当然に医療機関端末２０や介護施設端末８０に同様の機能が導入され実行される。

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

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

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

なお、地域医療連携システム１は、エッジコンピューティング技術が適用された構成であってもよい。エッジコンピューティング技術や５Ｇ通信技術を適用するシステムを導入することで、地域医療連携システム１の利便性・セキュリティ確保を確保し、さらにシステム構築・変更を容易にできる。特に緊急救急システムでは、患者９４の緊急性を考慮すると通信遅延を避けつつビデオ通信や詳細画像の通信といった重い通信を行い、かつ、人ＤＢ１２０や事業者Ｂ１３０のようなデータ保管場所をその地域内（またはその近隣）にしておきたいというニーズに応えることができる。具体的には、エッジサーバは地域医療連携システム１の事務局・拠点に分散配置して個人情報関係データ（人ＤＢ１２０、事業者Ｂ１３０のデータ）を処理する。それ以外の処理については、上位クラウドのサーバで処理する。これによって、個人情報保護規制にも柔軟に対応できる。

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

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

製薬会社９７は製薬機関端末７０を備え、ポータルサイト１０１から製薬機関用サイト１７０にアクセスして、製薬会社９７用に用意された機能を利用する。製薬会社９７用に用意された機能とは、医薬品の在庫管理・受発注機能、処方せん蓄積情報、薬事情報の登録機能、医療関係者への通知機能などである。ここでは、図３に示すように、複数の製薬会社９７のそれぞれに製薬機関端末（１）７０＿１〜製薬機関端末（ｎ）７０＿ｎが設置されている。製薬機関端末（１）７０＿１〜製薬機関端末（ｎ）７０＿ｎを区別しない場合は、単に「製薬機関端末７０」として説明する。

介護施設９８は介護施設端末８０を備え、ポータルサイト１０１から介護施設用サイト１８０にアクセスして介護施設９８用に用意された機能を利用する。介護施設９８用に用意された機能とは、例えば、ケアマネジメントシステム（アセスメント・計画書・月間計画を一体入力；介護支援経過記録の取込み機能）、訪問介護・看護支援システム、通所介護・看護支援システム、介護老人ホーム支援システムなどがある。ここでは、図３に示すように、複数の介護施設９８のそれぞれに介護施設端末（１）８０＿１〜介護施設端末（ｎ）８０＿ｎが設置されている。介護施設端末（１）８０＿１〜介護施設端末（ｎ）２０＿ｎを区別しない場合は、単に「介護施設端末８０」として説明する。

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

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

つづいて主に図４を参照して地域共有ＤＢ１２の具体的構成について説明する。地域共有ＤＢ１２は、事業者システム支援サーバ１３と、クライアント用共通ソフトウェア１４と、登録管理部１５と、認証部１６と、疾病推測部１７と、センサデータ取得部１８と、人ＤＢ１２０と、事業者ＤＢ１３０と、技術情報ＤＢ１３５と、を備える。

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

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

登録管理部１５は、地域医療連携システム１を利用する患者９４や、医療施設９２や薬局９６等の事業者や、それら事業者に所属する医師、薬剤師等を登録する。より具体的には、患者９４の患者情報（利用者情報）については、患者９４自身が登録するか、医療施設９２や薬局９６等の事業者を利用する場合に、患者９４の同意のもと、それら事業者が登録する。

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

認証部１６は、事業者（医療施設９２、薬局９６、製薬会社９７、介護施設９８）や患者９４が地域医療連携システム１にアクセスする際に、登録管理部１５で登録された認証情報（認証手段の種類およびそれによる登録情報）にもとづき、認証処理を行う。

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

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

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

図示のように、患者９４が登録する患者情報の項目として、「名前（氏名）」「社会保障番号」「生年月日」「住所・電話番号」「認証情報」を必須登録情報とし、必須登録情報が登録されると、患者共通ＩＤが付される。また、任意登録情報として、例えば「緊急連絡先」「延命治療意思」「臓器提供意思」「要注意事項」「注意薬情報／副作用情報」「ヘルパー」「介護先」「かかりつけ病院」などがある。「延命治療意思」「臓器提供意思」について登録があることで、患者９４が死亡した場合等に、医療施設９２においてそれら意思の確認が円滑になる。

また、「緊急連絡先」「ヘルパー」「介護先」が登録されていることで、患者９４に確認が難しい状態でも、家族・親類等への連絡が可能となる。また、「要注意事項」として既往症や手術歴等を登録することで、患者９４に確認が難しい状況において、医療施設９２にて避けるべき処置を把握でき、治療を円滑にできる。「注意薬情報／副作用情報」では、患者９４が自身の薬の履歴から副作用等により避けたいと考える薬があれば理由とともに登録する。「かかりつけ薬局」があることで、医師が処方せんを出す場合に、薬の在庫状況を事前に把握できたりする。また、後述の医療機関端末２０で稼働する電子カルテシステムや薬局端末６０で稼働する処方せんシステムにおいて、医師や薬剤師が登録してもよい。このとき登録者の情報（医師ＩＤや薬剤師ＩＤ）も関連づけて登録される。

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

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

図７の例では、患者共通ＩＤ「Ｃ０００２」の患者９４の利用者情報は、必須登録情報として名前「ＥＦＧＩ」、社会保障番号「１１１１２２２３−１２３」、生年月日「１９３９年０１月２３日」、住所・電話番号「△○区×□９−９」、認証情報「パスワード、指紋」であることが分かる。さらに、任意登録情報として、緊急連絡先「０３−２３４−ｘｘｘｘ／子」、生活状況「一人暮らし、施設入居」、認知症「〇」、感染症「Ｃ型、×（無）」、延命治療意思「×（無し）」、臓器提供意思「角膜」、要注意事項「ボルト」が登録されている。この患者９４を初めて治療する際に、要注意事項「ボルト」とあることから、例えば、ＭＲＩ治療時にＭＲＩ適合か否かを事前に確認することができる。また、注意薬情報「アレロック／頭痛」とあることから、この患者９４がアレロックを服用した際に頭痛が発生する副作用があることが分かる。

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

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

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

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

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

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

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

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

身体形状ＤＢ１２７は、患者９４毎に、身体形状センサ９０で計測した身体形状のデータが計測日時とともに記録されている。

家系図ＤＢ１２８には、患者９４の家系図情報が記録されている。すなわち、ある患者９４と親類関係（より具体的には遺伝的な繋がりがある血族関係）にある所定親等数内の他の患者９４のＩＤ、親等数、性別が関連づけられ記録されている。他の患者９４の同意が得られている場合には、医師の診断において、例えば電子カルテ上に「他の患者９４」の既往歴等とともに開示される。

技術情報ＤＢ１３５は、薬事情報ＤＢ１３６と、医療情報ＤＢ１３７と、疾病身体形状関連ＤＢ１３８と、症例情報ＤＢ１３９とを備える。薬事情報ＤＢ１３６には、医薬品に関する安全情報が記録されている。安全情報は、該当の製薬会社９７によって登録・更新されたり、地域医療連携システム１の管理者等によって登録・更新される。医療情報ＤＢ１３７には、公的機関や医師会による感染症の情報や、地域医療連携システム１に参加している事業者による情報が記録・更新される。疾病身体形状関連ＤＢ１３８には、身体形状と疾病の関係が記録されている。例えば、短期間で身体形状が大きくなった「体全体が浮腫む」状態であれば、何らかの「腎臓疾患」が発生している可能性があるや、「膝が変形している」場合に「変形性膝関節症」の虞があるといった関係が記録されている。身体形状の変化の程度や、変化のスピード等も関連づけられ記録されている。医師が診療した場合に、フィードバックされ、学習が行われる。症例情報ＤＢ１３９には症例情報が記録・更新される。症例情報とは、例えば、患者の症状や治療内容、転帰など、およびその患者の身体特徴情報（性別や年齢，身長，体重，体格など）とを関連づけられたデータである。また、症例情報ＤＢ１３９の症例情報は、電子カルテＤＢ１２５や処方せんＤＢ１２６、身体形状ＤＢ１２７と関連づけられるが、患者を特定する個人情報については必要に応じて匿名化又は無効化（関連づけしない状態）される。

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

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

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

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

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

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

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

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

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

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

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

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

患者プロフィール領域３０２の右側には、「身体形状データ」ボタン３２１と「家系図データ」ボタン３２２とが設けられている。

「身体形状データ」ボタン３２１が押下されると、身体形状ＤＢ１２７に蓄積されている身体形状データが表示される。例えば、身体形状データを用いて描画された立体人体モデルを３６０度回転可能な態様で表示させたり、異常が見られる部位や過去の傾向と異なる傾向を示す部位をマークして表示させたりする。また、疾病推測部１７が推測した疾病についても警告を表示させる。医師は、患者９４を診察する際に、この身体形状のデータあることで、患者９４が申告しない／意識していない身体の変化を客観的に把握でき、疾病の早期発見に繋がる。また、遠隔医療の際にも、直接目視できない部位について、画像等では認識が難しい場合でも、例えば「腫れ」の程度を客観的に把握できる。

「家系図データ」ボタン３２２が押下されると、家系図ＤＢ１２８から、親族（血族）関係にある他の患者９４のデータ（年齢、性別、既往歴等）が参照される。例えば、近親者に糖尿病患者がいれば、診察している患者９４についても糖尿病になる可能性が高いと判断し、早期の治療、注意を行える。また、診断が難しい場合でも、近親者のデータを参照することで、的確な診断や検査を行える。

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

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

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

医師は、患者９４を診察する場合や薬を処方する場合に、身体形状データから患者９４の客観的な体型を把握でき、処方量の調整が可能である。また、体形の変化に合わせた処方量の調整も行える。投薬の作用又は副作用により、体重や筋肉量，脂肪量，骨密度などが変わることがある。薬の作用が要因で変化した場合は、効果の出方により薬の量を調整できる。副作用が原因で変化した場合は、薬の変更や減量等の対応が行える。また、他の医療施設９２の診察履歴や薬の処方履歴を同一画面で参照できる。さらに、患者９４がどのような治療を受けてきたのかを知ることで、適切な治療方法を選択できる。特に、原因が不明の病気にかっていたような場合、紹介状があれば過去の治療履歴をその内容から又は患者９４から確認できる。しかし、紹介状が無い場合や患者９４が今回の治療で特にその病気とは異なり意識していない場合でも、診療に当たる医師が、過去の病気を考慮に入れて適切な治療法、処方する薬を選択できる。古い薬を使用している場合や既に無くなってしまった場合に、新たに患者９４に処方する薬を絞り込む参考になる。また、家系図データから近親者の既往歴を把握できることで、遺伝的な傾向を示す疾患について正しく考慮にいれ診断できる。また、患者９４の体形の歪みを検出することもできるため、いわゆる未病の段階でも、矯正治療を行える。小さな歪みの段階で発見できるので、簡単な治療で済み、治療費も抑制できる。

処方量の調整は、医療情報共有サーバ１０内にある処方システム２００の機能（処方量算出部）として、薬事情報ＤＢ１３６に記録されている医薬品情報（製薬会社が持つ治験データや製造販売後調査データ，有害事象データなどおよび薬品被投与者の身体特徴情報（性別や年齢，身長，体重，体格など）と医療機関がもつ症例情報ＤＢ１３９に記録されている患者の症例情報（症状や治療内容，転帰など）および患者の身体特徴情報（性別や年齢，身長，体重，体格など）とを基礎データとして算出される。これらのデータをもとに相関情報を解析することで最適な処方量の処方量１を算出することができる。

実際の処方量１は、患者９４の身体特徴情報を前記相関情報に当てはめて算出された、最適な薬の分量となる。
前記相関情報に当てはめて算出の一例としては、「患者の年齢における標準的な体格（身長，体重、脂肪量など）より著しく差がある患者の場合、標準的な薬の処方量では、過不足又は過剰となる場合がある。よって、患者の体格に合わせて薬の量を増減する必要がある。当該患者に処方すべき薬の量を、当該患者の身長と体重から算出できるBMI（ボディマス指数）や過去の類似症例における患者の身体特徴情報，過去の類似症例における患者の症例情報などを用いた相関情報から導く。」「薬によっては、患者の身体特徴情報により細かく投与量が決まっているものもある。このような薬の場合、患者の身体特徴情報と過去の類似症例における患者の身体特徴情報，過去の類似症例における患者の症例情報などを用いた相関情報から導く。」「身長や体重が同程度の身体特徴情報を持つ患者同士でも、体重の増減などによる体格の変化や加齢などによる筋肉量の変化などの要因で、患者ごとに薬の量を調整する必要がある。この場合でも、患者の身体特徴情報と過去の類似症例における患者の身体特徴情報，過去の類似症例における患者の症例情報などを用いた相関情報から導く。」などがある。

前記処方量１は、相関情報をもとに算出しているため、流通している薬の分量（単位投与量）と必ずしも一致しない。処方システム２００は、医薬品の処方上限量や単位投与量などを考慮し、処方量１に近似する実際に処方可能な薬の分量を算出したものが処方量２である。

処方量１や処方量２，医師処方量における薬の価格（処方費用）の算出は、処方システム２００の機能の１つである、処方費用算出部で行える。
処方費用算出部は、算出した処方費用と、患者の年齢と平均寿命とから一生涯における薬の費用の総額（生涯処方費用）の算出を行なってもよい。一生涯としたが、５年や１０年など一定期間における薬の費用の総額の算出を行ってもよい。
例えば、月に千円かかる薬を生涯服用する必要がある患者がいたとする。患者の年齢が５０歳で平均寿命が８０歳とされている場合、３０年間薬を飲むため、一生で３６万分の薬を飲むこととなる。
しかし、従来この３６万円という金額について患者以外に注視されることが無かった。３６万円という金額を下げようと取り組む機関はなかった。

図１４は、処方量算出部と処方費用算出部とを備えた処方システム２００の概略構成を示す機能ブロック図である。

電子カルテシステム上で医師が処方の指示を行うと、地域医療連携システム１を介して前記処方量２（処方データ）を患者９４があらかじめ登録している薬局９６に自動送付する。薬局９６は、送付されてきた処方データをもとにして患者９４へ薬の提供を行う。なお、電子カルテシステム上では、自動送付の登録の有無や送付先の薬局９６が表示されるようになっている。登録薬局は、患者９４のかかりつけ薬局９６のほか、提供可能な薬局９６が薬の提供条件を患者９４に提示し、患者９４が選んでもよい。なお、本実施形態では、「処方量を送付する」とは、「処方せんに処方量を記載した処方データを送付する」という意味であり、より具体的には、処方データの取り扱いが許されている対象の端末（薬局端末６０など）に送信する、またはそれら対象がアクセス可能なＤＢに保存する、という意味である。また、「処方データの取り扱いが許されている対象」とは、現時点において法令等で処方データを扱うことが許されている対象にかぎらず、将来的に許される可能性がある対象者も含むものとして説明する。

図１５に、患者端末４０に表示される提供条件の一覧の例を示す。また、図１６に、ある薬提供者（製薬会社Ｂ）の提供条件の詳細な例を示す。図１５の製薬会社Ｂの「詳細を見る」を押下することで、図１６の内容が患者端末４０に表示される。

薬局９６は、薬の販売価格や薬の受け渡し方法，薬の処方量などの薬の提供条件を決めるために、薬局端末６０を用いて、患者９４の処方情報や疾病名などの情報を医療情報共有サーバ１０にアクセスして取得してもよい。医療情報共有サーバ１０から取得できるデータは、年代，性別，疾病名，身長体重，処方薬と処方量など、個人を特定できないデータのみとしてもよい。

地域医療連携システム１上の処方提案ＤＢ２１０は、薬局９６上の薬局端末６０にて作成された薬の提供条件を保存する。処方提案ＤＢ２１０は、例えば処方せんＤＢ１２６に備わる。

患者９４は、薬の提供を受ける薬局９６の設定を患者端末４０から行う。また、複数の薬局９６から提供条件の提示を受ける場合、薬局９６ごとの提供条件の一覧が患者端末４０上に選択可能に表示される。

電子カルテシステムにおいて、薬局９６に代え、製薬会社９７（製薬機関端末７０）に処方データを送付し、製薬会社から直接患者９４に薬を提供してもよい。この際、製薬会社９７に送付する処方データは匿名加工されたものを送る。製薬会社９７（製薬機関端末７０）に前記処方量２を送付する際、合わせて前記処方量１を送付してもよい。また、製薬会社９７は、患者９４へ薬の提供を行う際、前記処方量２の用量に代え、前記処方量１の用量で提供を行ってもよい。製薬会社９７は、患者９４に対し前記処方量１で薬の提供を行った場合、実際の処方量を医療機関９２（電子カルテシステム）に提供してもよい。製薬会社９７が患者９４に提供する際の前記処方量１は、前記相関情報により算出した量だけでなく、前記処方量２との間の量としてもよい。

上記では、薬の処方量は、前記相関情報で算出した量（処方量１），処方量１をもとに算出した実際に処方可能な量（処方量２）及び処方量１と処方量２との間の量としたが、これらに限定されず、医師が指示した量でもよい。

算出した処方量１および処方量２および、処方した患者９４の身体特徴情報や症例をシステムに保存してもよい。また、保存したものをより適切な単位投与量の薬を作成してもらうために製薬会社９７に提供してもよい。

製薬会社９７は、患者９４に対し定期的に薬の提供を行う、サブスクリプション方式の契約（サブスクリプション）を行ってもよい。
サブスクリプション方式の契約の内容は、一定期間以上、同一の薬の処方が見込まれる場合、製薬会社９７から患者９４に対して定期的に薬を送る契約。契約期間中に用法用量が変わっても、薬が変わらない限り値段の変更を行わないようにしてもよい。

サブスクリプションの契約先は、製薬会社９７に限定されず、薬局９６や製薬卸業者，病院などの薬の流通にかかわるありとあらゆる業者でもよい。

製薬会社９７等のサブスクリプション契約提供者は、地域医療共有システム１を用いて対象利用者を検索してもよい。
前記検索は、人ＤＢ１２０上にある電子カルテＤＢ１２５や処方せんＤＢ１２６に対して、薬品名や疾病名を用いて行う。製薬会社９７等は、検索で得られた情報をもとに、直接または、情報を管理している機関や地域医療システム参加機関を通じて患者９４に連絡を行う。

高血圧患者の処方を例に説明すると、高血圧患者に対して医療機関９２で利用者（患者９４）に対して「薬Ａ」を１日３回１回５ｍｇ１錠と、「薬Ｂ」を１日３回１０ｍｇ（５ｍｇ２錠）とをそれぞれ１か月分（４週間分）を医師が出した医師処方量である。薬Ａ、薬Ｂとも流通品の単位処方量は、１錠２．５ｍｇと５ｍｇの薬しか流通していないためにこの処方量となる。そのため、医師処方量はこのような２．５ｍｇの整数倍での処方量となる。これを肝機能が正常化し血圧が正常値になるまでの服用が生じる。または生涯に亘る服用となる。
処方システム２００による処方量の違いの例を説明する。利用者の体形等の統計情報をもとに処方システム２００では、薬Ａを１回４ｍｇ、薬Ｂを９ｍｇ処方するのが理想である（処方量１）と算出した。しかし、前述のように、単位処方量は、１錠２．５ｍｇと５ｍｇのため、処方システム２００が算出した処方可能な処方量は、いわゆる流通約薬における処方量とすると、医師処方量と同じ、薬Ａを１回５ｍｇ、薬Ｂを１０ｍｇとなる（処方量２）。「医師処方量や処方量２」と、「処方システム２００が利用者の体形等の統計情報で算出した処方量１」とを比較すると、薬Ａは１日３ｍｇ、薬Ｂは１日３ｍｇ、１年おいては、薬ＡやＢ共に１０９５ｍｇの処方量の違いが出る。（十年という尺度でみると、服用量が各１１ｇの違いがでる。薬の代金が安くなると推測される。）
この処方量と一生涯服用するための生涯処方費用に着目したのが本考案である。
患者が、この薬を薬局又は製薬会社から提供を受けるための提供方法をサブスクリプションによる契約を締結により安く提供することが可能となる。

ここから生涯服用する薬の生涯処方費用に着目し、サブスクリプションにおける薬の提供契約により生涯処方費用を下げられる例を説明する。
薬局９６と製薬会社９７との２つの契約先によるサブスクリプション契約方法となる。
（１）薬局９６とのサブスクリプション
薬局９６とのサブスクリプション契約の場合、医師処方量や処方量２による、流通薬の提供方法になる。この提供方法だと、流通構造が変わらないため、薬局が薬を仕入れる価格に変化は生じない、そのため、推定される契約は、薬局との長期にわたる専属契約を行うことにより処方する薬の費用を下げるような契約となり、せいぜい数パーセントから数十パーセント程度の処方費用削減が限界と推測されますが、生涯処方費用からするとサブスクリプションのメリットは多少恩恵を得ることができます。
（２）製薬会社９７とのサブスクリプション
製薬会社９７とのサブスクリプション契約の場合は、上記同様に医師処方量や処方量２による、流通薬による提供方法と、処方システム２００が利用者の体形等の統計情報で算出した処方量１による提供方法との２種類による提供を行うことができる。ここでは「医師処方量」と「処方システム２００が相関情報を用いて算出した量」との違いになる。この量の違いが金額に反映されることとなる。さらに、別の側面から見ると薬の流通構造が大幅に簡略されることがわかる。流通構造という側面においては、サブスクリプション契約において、生産者と利用者がつながるため、大幅なコスト削減にとなる。
薬局Ａや製薬会社Ｂが、作成したサブスクリプション方式による提供条件の具体例を次に示す。
（１）薬局Ａの提案
５年間の契約が必要だが、薬Ａと薬Ｂとも通常の価格の１割引きで提供する。（生涯処方費用より安くなる価格で提供する。）
（２）製薬会社Ｂの提案
薬Ａ及び薬Ｂを５年間処方量が変わっても価格を変えずに提供を行い、製薬会社９６から利用者へ直接提供する。処方量の違いで、医師が処方した医師処方量（薬Ａ５ｍｇ、薬Ｂ１０ｍｇ）と、処方システム２００で理論的に算出した処方量１（薬Ａ４ｍｇ、薬Ｂ９ｍｇ）との２種類になる。
この２種類によるサブスクリプション契約の場合は、どちらも利用者と製薬会社とが直接結ぶ流通構造となるため従来の流通構造より中間コストが大幅削減された価格での提供となる。また、医師処方量で提供する方法よりも、処方量１で提供する方法の方が、薬の量が少ないため前記よりも安く提供できることは言うまでもない。この場合、流通構造により中間コストが削減される分と、薬の量が少ないコストによる分との相乗により、５割引（推定）での提供となる。（生涯処方費用より大幅に安くなる価格での提供ができる。）

従来の薬の流通は、「製薬会社→薬局→利用者」という流通構造に卸という中間業者の存在がある。それに対して、サブスクリプション契約になると、「製薬会社→利用者」という新しい流通構造が自然に構築できる事になる。このように、サブスクリプション契約を行うことで、製薬会社と利用者の間にあった中間マージンの削減といった事が本システムのサブスクリプション契約により可能となる。結果、利用者にとっては大幅なコスト削減に繋がることになる。利用者にとっては生涯処方費用の削減は喜ばしいことである。今まで利用者の生涯処方費用についてのコンサルタントを受ける事や、薬の提供方法である流通構造の変化とを、システムで実現する物はなかった。
さらに、サブスクリプション契約を行う薬局９６や製薬会社９７にとって、契約者（固定客）により利益確定に繋がるメリットが発生する。こういった契約を増やすことで利益を事業計画に盛り込め、契約者を増やすと事業の安定にも繋がることになる。

各薬の提供者が作成し提案したサブスクリプション契約の内容は、処方提案ＤＢ２１０に記録される。記録された提案は、利用者端末（患者端末４０）で確認でき、図１５に示すような、上述した提案条件の一覧が表示される。利用者は、利用者端末（患者端末４０）上に表示される上記条件のうち、購入（契約）したいものを選択し薬の購入（契約）を行う。

サブスクリプション契約により患者９４に薬を提供することは、製薬会社９７と患者９４との両方に利点がある。
（１）製薬会社９７は、患者９４とサブスクリプション契約を結ぶことによりある程度の薬の需要を読むことができ、その分の利益見込みができること、結果として、工場の原料調達計画や生産調整が行いやすくなる。固定客を増やすことで経営が安定させることへのシフトが始まる。
（２）患者９４は、製薬会社９７とサブスクリプション契約することにより、生産者から直接購入できる流通となり、生涯服用する薬を従来より安く買えることができる。また、製薬会社から購入することにより、正規の薬を使用することができる。

地域医療連携システム１上のサブスクリプション契約ＤＢ２２０は、契約したサブスクリプションの内容を保存する。サブスクリプション契約ＤＢ２２０は、例えば、処方せんＤＢ１２６に備わる。サブスクリプション契約ＤＢ２２０に保存される内容は、患者のかかりつけ病院や医師に加え契約先の薬の提供者が提案した内容（図１６に記載の内容）、すなわち、サブスクリプションの契約先（製薬会社９７や薬局９６，製薬卸業者，病院など）と薬の提供価格や提供方法，契約期間，解約条件、契約日などが保存される。
サブスクリプション契約ＤＢ２２０に保存された情報は、患者端末４０や医療機関端末２０、薬局端末６０などを用いることにより確認することができる。

サブスクリプション契約の支払いは、「薬局９６などで薬を受け取る際に支払う」「クレジットカード払いや銀行引き落としなどの自動決済で支払う」などを用いて行う。製薬会社との契約における支払いは本システムが対応してもよい。自動決済は、クレジットカード払いや銀行引き落としに限らず、本システムと連携して発行された決済手段を用いてもよい。本考案のサブスクリプション契約ＤＢ２２０は、支払いにおける管理もしてもよい。

前述の考案では、製薬会社９７等のサブスクリプション契約提供者が、地域医療共有システム１を用いて対象利用者を匿名加工されている状態で検索することにより、サブスクリプション契約を提案したい患者９４を見つけ、患者９４に対しサブスクリプション契約の提案を行う形で説明してきた。医療情報共有サーバ１０の運用管理者は、患者９４やその患者の処方薬を探しだし、患者９４への薬のサブスクリプション契約の提案依頼を製薬会社９７等に対して依頼し、患者９４に対してもサブスクリプション契約の提案を行い、製薬会社９７と患者９４とのサブスクリプション契約の仲介を行ってもよい。
医療情報共有サーバ１０の運用管理者が、製薬会社９７等に対して、患者９４への薬のクリプション契約の提案依頼するにあたり、対象となる患者９４を検索で見つけ、情報を取得する必要がある。この情報の取得方法は、製薬会社９７等が情報取得に用いた手法と同様に、人ＤＢ１２０上にある電子カルテＤＢ１２５や処方せんＤＢ１２６を匿名加工されている状態で検索し取得する。

また、前述の考案では、サブスクリプションの提案の内容を患者端末４０に表示することで患者９４に提案するとしたが、医療機関端末２０にサブスクリプションの提案の内容を表示させて、医師が患者９４にサブスクリプションの提案する形でもよい。

医療情報共有サーバ１０の運用管理者が、本システムと連携して発行された決済手段の運用を行い、製薬会社９７等に対する患者９４への薬のクリプション契約の提案依頼することにより、患者９４の患者情報の取得保存から、薬のサブスクリプション提案やサブスクリプション契約の管理までの一連の流れを医療情報共有サーバ１０の運用管理者が統括することができる。図１７に一連の流れを統括したイメージの一例を示す。

従来、処方薬を製造する製薬会社の顧客は医療機関であり、医療機関で働く医師に対して商品を紹介し提供するというのが製薬会社のビジネスモデルとなっていた。また慢性患者が生涯に亘り服用し続ける処方薬を計算し、利用者へ生涯処方薬コストを見直す提案やアドバイスする事業は存在しなかった。これら２つを融合するため患者の症例情報などのデータベースを管理運営している、医療情報共有サーバ１０の運用管理者が行うことで、薬の生産者である製薬会社と、薬を服用する利用者とを直接結ぶ新しい構造を創るビジネスモデルである。
また、利用者のかかりつけ病院の医師が、自分の患者に飲ませる「薬の生涯価格」を見るようになれば患者の将来飲む薬のコストに、配慮することが可能となる。このようになれば、医師自身が、サブスクリプション契約を推奨していき、患者への医療コストを下げていく医師のコストダウン意識が浸透していくようになると推測できる。利用者が生涯にわたり従来より安い値段で薬を服用できるようになる。これは、医療業態における流通は、複数のしがらみで高コストとなっており、この構造を医師が自ら流通を変えることにより医療における構造改革が起こり、患者にとってメリットがあると考えている。

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

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

患者９４は、災害による避難、疾病による入院など様々な理由で居所を一時的に変える場合がある。居所の変更をサブスクリプション契約先に連絡をする必要があるが、連絡手段がないなどの理由により連絡できないことがある。サブスクリプション契約先に連絡できないと、薬の送付先の変更が行えずサブスクリプション契約した薬の受け取れないこととが想定される。一定期間以上、薬の受け取りが行われない場合において、サブスクリプション契約先は、患者９４及びの患者９４関係者に対し連絡を行い状況確認する機能を地域医療連携システム１に設けてもよい。患者９４の関係者とは、家族やかかりつけ病院，かかりつけ薬局、利用介護施設などがあげられる。連絡すべき相手は、患者９４の状況により異なるため、あらかじめ地域医療連携システム１上に登録してもよい。患者９４の状況と連絡先の例として、「患者９４は認知症のため、患者９４本人に連絡せず患者９４の家族や患者９４の後見人に連絡する」「患者９４は介護施設に入居しているため、患者９４と介護施設に連絡する」などがあげられる。サブスクリプション契約先に代わり地域医療連携システム１が自動的に行うようしてもよい。上記では、一定期間以上薬の受け取りが行われない場合としたが、大規模災害発生時等、多くの利用者が薬の受取りが困難になると予想される場合に、安否確認と送付先の確認を行うために利用者及び利用者の関係者に連絡する機能を有してもよい。

地域医療連携システム１において身体形状ＤＢ１２７に蓄積されている身体形状データは、処方量の調整の他に、例えば、身体障がい者が使用する義肢などの装具の作成に用いられてもよい。一般に、装具の作成時に利用者の装具を作成する部分に石膏包帯を巻いて陰性モデルを作成する。陰性モデルに石膏を流し入れて、陽性モデルを作り、そのモデルを利用して装具を作成する。装具の再作成のたびに陰性モデルから作成するため利用者の負担が大きい。そこで、陽性モデルのデータを保存しておくまたは、身体スキャンデータ（身体形状データ）を保存しておけば、次回作成時そのデータを利用して装具を作成できる。

装具の作成以外にも、ガンマナイフ，重粒子線治療，陽子線治療などの放射線治療を行う際に作成するプロテクターや固定器具などの作成にも身体形状ＤＢ１２７に蓄積されている身体形状データ用いることができる。プロテクターや固定器具などの作成時において、プロテクターや固定器具などを作るための型取りを行わず、身体形状データを利用してプロテクターや固定器具などの作成を行う。
また、宇宙服や潜水服といった利用者の体形に合わせる必要がある特殊作業服の調製にも身体形状ＤＢ１２７に蓄積されている身体形状データ利用できる。例えば、「服の各部位ごとに、複数の大きさのパーツの中から利用者の体形に合わせた最適なパーツが自動的に選定される」「体型に合わせて特殊作業服を作成する」などの利用法がある。

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

本実施形態では、医療情報共有サーバ１０内の各種ＤＢに情報を保存するとしている。保存先は、例示であり、行動履歴や購買履歴といったものを含んだり又はひも付いたデータを個人から預託され、他の事業者とのマッチングや匿名化したうえでの情報提供を行う機関（情報銀行）内のＤＢなどでもよい。情報銀行という固有名詞を記載したが本考案の出願時点では個人情報を用いてビジネスを正当に扱える業態は情報銀行である事が政府より公表されている。

以下、本実施形態の変形例の特徴を以下に付記する。
（１）本発明は、複数の医療機関が連携して所定の地域において医療を提供する医療システムであって、
ユーザの身体特徴の一つとして外形寸法を取得する身体特徴取得部と、
疾病と外形寸法との関連情報を記録する疾病外形関連ＤＢと、
計測した前記外形寸法と前記関連情報とから前記ユーザに疾病の発生又はその可能性の有無を推測する疾病推測部と、
を備えることを特徴とする。
外形寸法とは、単なる身長や腹囲といった値ではなく、外形形状をおおよそ特定可能な程度のポイントの値である。例えば、身体の表面をメッシュ状に分割したときの交点（ノード）をポイントとして、それらポイントの相対位置関係を取得して人体モデルに適用することで、外形寸法が特定される。また、レーザスキャニング装置により外形寸法が特定されてもよい。さらに、伸縮性の素材で出来た密着性のウェアに複数のセンサを取りつけた装着タイプ測定装置で、それらセンサの相対位置関係（伸縮状態）から外形寸法が特定されてもよい。
患者の外形寸法から外形形状を特定できるので、患者の身体特徴をより正確に把握でき、医師の診療の際、また健康管理の際に、より適切な判断が可能となる。近年、遠隔医療の導入が始まっているが、画面上に映し出される画像（映像）だけでは正確な判断ができないことが多い。そのような場合、ユーザの申告値を採用することもできるが、正確性に欠けたり、そもそも身長体重以外の値については把握していないため、医師が身長体重の申告値を信用したうえで想像することになる。しかし、外形寸法を得られ人体モデルに適用することで、患者の外形を精度高く把握できる。疾病を早期または未病の段階で発見できるので、医療費の抑制にも繋がる。また、体形の歪みを検出することもできるため、いわゆる未病の段階でも、矯正治療を行うこともできる。小さな歪みの段階で発見できるので、簡単な治療で済み、治療費も抑制できる。
地域医療連携システムにおいて、このような技術を導入することで、システム参画者間でデータの共用ができ、例えば、介護施設で計測した高齢者の外形寸法のデータを医療施設（クリニックや病院等）で診断に利用するという連携により、その地域の健康維持・向上を低コストで効率的に行える。また、遠隔診療のようにビデオ画像を介した診察においても、患者の身体特徴を一定の精度で把握できる。すなわち、医師が触診できないような場合でも、患者に身体に異変が生じたことを外形からある程度把握できる。

（２）前記ユーザの身体の表面に設定された複数のポイントと、前記ポイントの位置関係を計測することで前記外形寸法を計測し、計測結果を前記身体特徴取得部へ送信する身体特徴計測部を備えてもよい。
身体特徴計測部は、例えば上述したレーザスキャニング装置や装着タイプ測定装置に通信機能を持たせたもので、ネットワーク経由で、計測値が前記身体特徴取得部へ送信される。

（３）前記複数のポイントは、ユーザの身体の表面の代わりに、前記ユーザの身体の全体または一部を再現した模型の表面に設定されてもよい。
すなわち、前記身体特徴計測部の計測対象をユーザの身体に代え、ユーザの体形の全体または一部を再現した模型としてもよい。

（４）前記身体特徴計測部は、
伸縮可能な素材により構成される本体部と、
前記本体部に、前記ポイントとして複数ポリゴン状に配置され相対位置関係（伸長量）から前記ユーザの外形寸法を計測するセンサ部と、
を有し、ユーザが装着した身体部分のサイズ及び形状を測定してもよい。
また、ユーザが装着した身体部分に代え、ユーザの体形を再現した模型に装着してサイズ及び形状を測定してもよい。
この身体特徴計測部は、例えば上述の装着タイプ測定装置に適用されるものである。近年、伸縮性のある着衣として、スポーツ用のコンプレッションウエアがリーズナブルに入手可能である。このようなコンプレッションウエアにメッシュ状（ポリゴン状）に複数のセンサ（例えばポジションセンサや画像処理用マーカ）を取り付けて、センサの相対位置をセンシングし、形状を算出することができる。また、ポイント間の伸長により電気出力が変わる伸長センサや歪みセンサを適用してもよい。専門的な採寸技術のない者（患者や介護者、医師、看護師等）でも簡単に取り扱え、容易に採寸可能である。

（５） 前記疾病推測部は、前記複数のポイントをもとに計測した前記外形寸法において局所的な特異形状を検知することで疾病の発生の有無を推測してもよい。
例えば、皮膚軟部腫瘍として、ほくろやアザ、いぼといった様に皮膚表面に変化を生じるものから、「脂肪のかたまり」の様な皮膚の下に出来た固まりで皮膚が盛り上がっているものまであります。原因となる細胞には実に様々なものがあり、中には悪性のものも存在する。癌や肉腫は早期に切除することが求められ、早期に対応が可能となる。局所的な特異形状、例えば、腎臓近くが腫れている、腫瘍により一部が膨出している等の形状を検知したときに、疾病の可能性が高いので、検査を提案するといったプロセスに迅速に移れる。

（６）前記外形寸法のデータを前記ユーザと関連づけて蓄積するユーザデータ記憶部を有し、
前記疾病推測部は、蓄積された前記外形寸法のデータの傾向に変化が生じた場合に、その変化に対応した疾病が発生したと推測してもよい。
疾病推測部は、蓄積されたデータをもとに学習（例えば機械学習やＡＩ学習等の公知の学習技術を用いた学習）を行う。蓄積データが多くなるにしたがって推測精度向上が期待できる。例えば膨出した部位があっても変化が無い場合は特に問題ない場合もある。悪性腫瘍の場合は、変化が早いことが多く、時系列のデータが疾病特有の傾向を示した場合に、早期に疾病の有無の検査が必要であると推測し、例えば電子カルテ上に警告を表示することができる。時系列の変化として、身体の一部が膨出した場合や、特定部位（例えば肝臓部分）が膨出した場合、姿勢が曲がった場合等に、健康管理上問題となる変化が生じたものと判断する。あらかじめ対応関係を記したＤＢを用意し、反映・学習させる。精度が向上する。これは病院に導入するに留まらず、例えば、介護施設に導入することで、高齢者等が意識していない症状であっても、医師が遠隔で判断できたり、介護施設の職員による計測で要注意の状態が判明した場合に、医師の診察に委ねるという対応が早期に可能になる。なお、ユーザデータ記憶部は定期健康診断等の定期的な検査データが含まれてもよい。

（７）前記ユーザデータ記憶部は、前記ユーザの身体特徴の一つとして体重を記憶し、
前記疾病推測部は、前記疾病の推測に、前記ユーザの体重を反映させてもよい。
身体特徴として、外形形状とともに体重、さらには体脂肪率等のデータを反映させることで、一層精度向上が期待できる。また、健康指導等をきめ細かに行える。また、例えば慢性疾患の薬の処方量は患者の体重と表面積から算出することがある。このような場合、医師が頭の中で又は計算機等を用いて計算している場合もあれば、経験則から単に見た目で判断する医師もいる。しかし、患者の身体特徴である外形寸法や体重等から処方量（又はその範囲）を自動的に電子カルテシステムに表示させることで、実質的なバラツキを抑え患者に均一な医療を提供できる。また、患者の身体特徴である外形寸法や体重等から処方量の上限を定めることで、例えば、処方する点滴や注射の量を適正な範囲に抑え、いわゆるヒヤリ・ハットといった医療事故に繋がる事態を確実に回避できる。

（８）前記疾病推測部は、近親者の医療データまたは生物学的特徴データを取得し、前記疾病を予測する際に反映させてもよい。
家系のデータを疾病の予測に反映することで、疾病推測の精度を向上させることができる。家族歴・既往歴などは重要な医療情報であるが、近親者の生物学的特徴データ（言い換えると家系図情報）は、疾病予測において家族歴・既往歴以上に重要な要因である。従来遺伝的要因の関与がまったく考えられなかった疾患が、実は遺伝性疾患であることが明らかとなる場合もあり、明らかになる前の状態であっても、疾病の予測に家系図情報を反映させることで精度を向上させることができる。近親者が同じ地域に居住していることも多く、地域医療連携システムで同じデータベースに治療履歴や生物学的特徴データ（家系図情報）が蓄積されることが想定される。そのような場合、高いセキュリティを確保したまま相互のデータ利用が容易となる。当然、別の機関（バイオバンクや他の地域医療連携システム）のデータベースのデータが利用されてもよく、そのような場合、相互接続専用ＡＰＩを導入し、セキュリティと利便性との両立を図ることが望ましい。

医療機関の情報処理端末と医療情報共有サーバを、上述のようなシンクライアント環境（例えば仮想デスクトップ環境等）で構築するような場合の他に、エッジコンピューティング技術や５Ｇ通信技術を適用するシステムを導入することで、地域医療連携システムのような医療システムの利便性・セキュリティ確保・システム構築容易性と言った効果を奏する。特に緊急救急システムでは、患者の緊急性を考慮すると通信遅延を避けつつビデオ通信や詳細画像の通信といった重い通信を行い、かつ、利用者ＤＢのような情報記録場所をその地域内（またはその近隣）にしておきたいと言うニーズがあり、そのようなニーズに応えることもできる。

１ 地域医療連携システム
９ ネットワーク
１０ 医療情報共有サーバ
１１ 統括装置
１３ 事業者システム支援サーバ
１４ クライアント用共通ソフトウェア
１５ 登録管理部
１６ 認証部
１７ 疾病推測部
１８ センサデータ取得部
１９ 通信ＩＦ
２０ 医療施設端末
２１ シンクライアント端末
３０ 電子カルテ
４０ 患者端末
５０ 処方せん
６０ 薬局端末
７０ 製薬機関端末
８０ 介護施設端末
９０ 身体形状センサ
９２ 医療機関
９４ 患者
９６ 薬局
９７ 製薬会社
９８ 介護施設
１００ 医療情報共有サイト
１０１ ポータルサイト
１１０ 医療機関用サイト
１２０ 人ＤＢ
１２１ 患者ＤＢ
１２２ 医療関係者ＤＢ
１２３ 薬剤師ＤＢ
１２４ 介護士ＤＢ
１２５ 電子カルテＤＢ
１２６ 処方せんＤＢ
１２７ 身体形状ＤＢ
１２８ 家系図ＤＢ
１３０ 組織ＤＢ
１３１ 病院ＤＢ
１３２ 薬局ＤＢ
１３３ 製薬機関ＤＢ
１３４ 介護施設ＤＢ
１３５ 技術情報ＤＢ
１３６ 薬事情報ＤＢ
１３７ 医療情報ＤＢ
１３８ 疾病身体形状関連ＤＢ
１３９ 症例情報ＤＢ
１４０ 患者用サイト
１６０ 薬局用サイト
１７０ 製薬機関用サイト
１８０ 介護施設用サイト
２００ 処方システム
２１０ 処方提案ＤＢ
２２０ サブスクリプション契約ＤＢ
４２１ ユーザＩＦ
４２２ 表示部
４２３ 通信ＩＦ
４２４ 生体情報取得部
４２５ 位置情報取得部
４２６ 認証装置
４２７ 地域医療共有アプリケーション

Claims (5)

1. 複数の医療機関が連携して所定の地域において医療を提供する医療システムであって、
   ユーザの身体特徴の一つとして身体各部の外形寸法を取得する身体特徴取得部と、
   医療機関の医療機関端末で稼働する電子カルテシステムと、
   を有し、
   前記電子カルテシステムは、
   製薬会社が提供する医薬品情報と医療機関がもつ症例情報とから薬の処方量に関する相
   関情報を算出する機能を有し、少なくとも前記身体各部の外形寸法を含むユーザの身体特
   徴情報を前記相関情報に当てはめて最適な薬の分量を算出する処方量算出部を備え、
   前記身体特徴取得部は、前記ユーザに装着し、身体各部の寸法及び形状を計測し前記身
   体各部の外形寸法を取得する
   ことを特徴とする医療システム。
2. 前記処方量算出部は、算出した分量と、薬の単位投与量とから処方可能な薬の分量を算出する、ことを特徴とする請求項１に記載の医療システム。
3. 前記ユーザの身体特徴情報を前記相関情報に当てはめて算出した、前記最適な薬の分量又は、前記薬の単位投与量とから処方可能な薬の分量における処方費用を算出する処方費用算出部を備え、
   前記算出した処方費用と平均寿命から
   一生涯に亘る薬の費用を算出することを特徴とする
   請求項１または２に記載の医療システム。
4. 前記ユーザの身体特徴情報を前記相関情報に当てはめて算出した、最適な薬の分量又は、
   前記薬の単位投与量による処方と、
   前記一生涯に亘る薬の費用から少なくなるよう、前記ユーザに対するサブスクリプション方式による薬の提供とを
   薬の提供者に提案の依頼をし
   薬の提供者が一定期間において従来の処方より低価格となる処方費用を算出して、
   薬の提供方法をサブスクリプション方式による契約内容と
   サブスクリプション契約の完了までとを
   記録するサブスクリプション契約ＤＢを備える
   ことを特徴とする請求項３に記載の医療システム。
5. 請求項４に記載の医療システムにより、薬の提供者から利用者に対し
   薬を直接提供し、
   その結果、中間マージンを削減することができ、薬を安く提供することを目的とし、
   医療情報共有サーバ上の
   サブスクリプション契約DBに保存されている薬の提供者が提案した内容の情報から、
   医療情報共有サーバ上の医療システムは、
   最適な処方量と処方費用を算出した
   サブスクリプション契約を締結することにより
   薬の提供者から薬を服用する利用者に対して、
   最適な処方量と処方費用で薬を利用者に提供することを特徴とする方法。

Images