JP6660655B1 - 医療システム - Google Patents

Abstract

【課題】地域の医療機関が共通で利用できる地域医療連携システムを導入しやすく、導入後のランニングコストを抑える技術を提供する。【解決手段】医療情報共有サーバ１０は、人ＤＢ１２０と事業者ＤＢ１３０とを備える。医療機関９２の医療機関端末２０は、自身をシンクライアント端末とし、事業者システム支援サーバ１３をシンクライアント管理サーバとして、シンクライアント環境にて電子カルテシステムを機能させる。医療機関端末２０で稼働する電子カルテシステムは、電子カルテＤＢ１２５や処方せんＤＢ１２６に診察のデータ（電子カルテ、処方せんデータ）を記録するとともに、それらから他の医療機関９２による記録を参照する。【選択図】図３

Description

本発明は、医療システムに係り、例えば、医療・福祉に関連する商品・サービスを提供する事業者と、前記事業者が提供する商品・サービスを利用する利用者とがアクセスする医療システムに関する。

近年、医療の分野では、医師が作成する書類の電子化が進んでおり、患者の病状や検査内容、薬の処方等の情報を電子化して保存・管理する電子カルテが普及している。さらに、電子カルテをネットワーク上に保存して、複数の医療機関に設置した電子カルテ装置をネットワーク上の電子カルテサーバで接続し、同じ患者に関して医療機関相互に電子カルテを利用可能とした技術も提案されている（例えば特許文献１参照）。

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

上述のように電子カルテをネットワーク上に保存して複数の医療機関で利用する技術が提案されているものの、なかなか導入が進まず、地域医療の共有ができないという課題がある。一般に、それぞれの医療機関は様々なメーカーが提供する電子カルテ装置を独自に調達して運用している。すなわち、販売・契約が個別となって、導入コストが高止まりし、また、医療機関の間でシステムが統一できない傾向がある。当然にランニングコストが嵩み、ＰＣのＯＳの更新により、導入したシステムの更新・買い換えが必要となることもあり、大きな負担になっている。また、地域医療の可視化の観点では、単に医療機関だけでなく、関連する他の事業者、例えば薬局等の連係も重要になってくることから、そのような事業者も利用しやすい技術が必要となっている。

本発明は、以上のような状況に鑑みなされたものであって、その目的は、地域の医療機関が共通で利用できる地域医療連携システムを導入しやすく、また、導入後においてランニングコストを抑える技術を提供することにある。また、ネットワーク上の患者の情報を、適切なセキュリティのもと効果的に利用できる技術を提供することにある。

（１）本発明の医療システムは、医療・福祉に関連する商品・サービスを提供する複数の事業者の事業者情報を記録する事業者データベースと、前記事業者の商品・サービスを利用する利用者の利用者情報を識別情報と関連付けて記録する利用者データベースと、を備えた医療情報共有サーバと、前記事業者の情報処理端末と、を備え、前記事業者は医療機関を含み、前記医療情報共有サーバは、前記事業者の前記情報処理端末の動作を管理する管理サーバを備え、前記管理サーバと前記医療機関の前記情報処理端末である医療機関端末は、前記医療機関端末をシンクライアント端末としたシンクライアント環境にて、電子カルテシステムを機能させ、前記電子カルテシステムは、前記利用者を診察した際の診察情報及び処方内容を記録した電子カルテを前記利用者情報として前記利用者データベースに記録させるとともに、前記利用者データベースに記録されている同じ利用者の前記利用者情報を参照し表示可能である。
医療・福祉に関連する商品・サービスを提供する事業者として、例えば、病院、薬局、介護施設、製薬会社等があり、少なくとも医療機関（病院、クリニック等）を含み、医療機関を中心とした医療システムが構築される。この医療システムは、近年推進されている地域医療連携システムに好適である。利用者とは、患者、高齢者、障がい者を主に想定するが、一般人も含む概念である。これは、健常者であっても健康診断や人間ドック等によって医療機関を利用する場合もあり、また、将来または過去に患者として利用することもあるためである。事業者を利用した場合に利用者情報が利用者データベースに記録され他の事業者と共有されることで、ある事業者で利用された利用者情報（例えば電子カルテや電子化された処方せんのデータ等）を別の事業者が利用できるので、商品・サービスの提供の際に注意すべき事項（重複や忌避事項）の確認漏れを抑制でき、それら提供の品位を向上させることができる。また、少なくとも医療機関において、シンクライアント環境で電子カルテシステム（会計システム、検査システム等のその他院内システムを含んでもよい）を構築でき、事業者の情報処理端末（ＰＣ等）のハードウェアやＯＳに大きく依存することなく、システム更新を行うことができ、システムの実質的寿命を低コストで大幅に伸ばすことができる。商品・サービスの提供とは、医療機関等事業者における医療等の役務（サービス）の提供、医薬品等の商品の提供を指し、一方のみ又は両方を提供する場合を含むものである。なお、電子化された処方せんのデータとは、例えば、国が出している標準化使用である電子処方箋標準フォーマット（電子処方箋ＣＤＡ記述仕様）にもとづく電子処方せんを想定するが、これに限る趣旨ではなく、同様の機能を有するフォーマットで記述されていればよい。また、処方せんデータ（すなわち電子処方せん）の送受信形態についても特に限定するものでは無く、電子カルテシステムで直接的に処方せんデータベースに記録される形態や、電子メールに添付ファイルとして送信され処方せんデータベースがその添付ファイルを取得・記録する形態でもよい。以下では、「電子処方せん」を使用する場合は、具体的形態については特に限定するものではなく、広い意味での「電子化された処方せん（またはそのデータ）」として説明する。

（２）前記電子カルテシステムは、前記利用者に対する処方薬を選択する際に、前記利用者データベースに記録されている前記利用者情報を参照し、同一又は類似の薬効の薬を選択する場合であって処方期間が重複する場合には、その旨を表示し、処方者の確認を取得してもよい。
電子カルテシステムで、利用者データベースの利用者情報（他の病院の電子カルテや電子処方せん）を参照することで、患者へ処方する薬の選択時に、同一・類似の薬を処方する際に、システムから警告が発せられ処方者の確認を必用とすることから、重複処方を回避でき、必要な分量だけ処方でき、医療費の無駄を削減できる。また、処方せんを出力する際に、その旨を注記することで、薬局（薬剤師）から医師への疑義照会といった作業を抑制することができ、病院、薬局双方の業務の効率化に繋がる。

（３）前記電子カルテシステムは、前記利用者に対する処方薬を選択する際に、前記利用者データベースに記録されている前記利用者情報を参照し、処方する薬と忌避すべき薬が処方されているか否かを判断し、忌避すべき薬が処方されている場合には、その旨を表示し、処方する医師の確認を取得してもよい。
忌避すべき薬が処方されている場合には、警告を受けた医師は、別の薬を選択してもよいし、選択の余地が無い場合には、先に処方されている薬を中止させたり別の薬に変更するといったことができる。中止・変更に際し、先の医療機関が分かるので、連絡が円滑にできたり、医療システム内の処理として患者の利用者情報として反映され先の病院は別の病院で薬が中止・変更された旨、その理由を把握することができる。処方せんを出力する際に、変更・中止に関して注記することで、薬局（薬剤師）から医師への疑義照会といった作業を抑制することができ、病院、薬局双方の業務の効率化に繋がる。

（４）前記事業者は薬局を含み、前記薬局の前記情報処理端末である薬局端末と管理サーバとは、前記薬局端末をシンクライアント端末としたシンクライアント環境にて、処方システムを機能させ、前記処方システムは、利用者に対する処方せんの情報を取得し前記利用者情報として前記利用者データベースに記録するとともに、前記利用者データベースに記録されている前記利用者情報を参照して、前記処方せんにより処方が指定されている薬に対して重複又は忌避する薬が処方されているか否かを判断し、重複又は忌避する薬が処方されている場合に、警告を出力しその警告に対する薬剤師の確認を取得してもよい。
薬局に導入されるシステムについても、医療機関と同様にシンクライアント環境で構築され、処方せんの内容が利用者データベースに記録される。薬局のシステムでは、重複／忌避処方を判断し、薬剤師による確認を促し、薬剤師は、処方せんに注記があれば、その内容を患者に伝え、注記が無ければ医師に確認することができる。また、薬局のシステムが医療機関のシステムと連携し、同じ利用者データベース（利用者情報）を参照するので、医師の処方時の判断を一定範囲で把握でき、無駄な疑義照会等の作業を無くすことができ、患者への薬の提供をスムーズに行うことができる。患者が薬を受け取らない場合もあり、地域全体の在庫管理を行うことができる。

（５）前記医療情報共有サーバは、前記医療機関に所属する医師の情報を記録する医師データベースを備え、前記電子カルテシステムは、前記利用者である患者を別の医療機関に紹介する紹介機能と、患者の治療に適した医師を前記医師データベースから検索する医師検索医療機関検索機能と、を備え、前記紹介機能は、紹介処理の際に、前記患者の情報を電子化したデータとして、前記別の医療機関に提供する情報提供機能と、前記医師検索医療機関検索機能により選択した医療機関の医師への診察日時（診察日、時間又は時間帯）を予約する予約機能と、を備えてもよい。
医療システムにて、医療機関（医師）が医療機関端末を用いて他の医療機関の予約を行うことで、医療機関や診療科、担当医の選択を適切行うことができる。また、予約処理において、電子化した患者情報（電子カルテや処方せんデータ、検査データ等）を直接またはデータベース経由で間接的に提供するので、紹介先の医療機関も迅速な対応が可能となる。

（６）前記医療関係者の前記医療機関端末は、前記シンクライアント端末と接続可能なモバイル端末を含み、前記シンクライアント端末と前記モバイル端末が接続状態にあり前記モバイル端末に設けられた認証手段によってユーザ認証が確立された場合に、前記電子カルテシステムはユーザ認証に用いられた前記認証手段に応じて前記電子カルテシステムにおける利用を制限してもよい。
医療機関端末のシンクライアント端末は、医者のモバイル端末（スマートホンやタブレット端末）を接続してそのモバイル端末の認証手段を用いて認証することができる。そして、認証手段の種類や数に応じて、利用制限が付され、「全ての機能を利用可能」、「参照可能だけ」、「参照範囲限定」（自医院のみ、他の医院も等）等が決めることができる。

（７）前記事業者は介護機関を含み、前記介護機関の前記情報処理端末である介護施設端末と管理サーバとは、前記介護施設端末をシンクライアント端末としたシンクライアント環境にて、介護支援システムを機能させ、前記介護支援システムは、前記利用者の前記介護施設における利用状況を利用者情報として前記利用者データベースに記録するとともに、前記利用者データベースに記録されている前記利用者情報を参照可能であってもよい。
事業者として介護施設が参画することで、医療機関と介護機関との間の連携がスムーズになる。医療機関が介護施設を運営する場合であっても、導入するシステムのベースが異なって連携が難しい場合も有り、運営者が異なる場合にはなおさらである。しかし、医療機関や薬局、介護施設が同じ医療システムを利用し同じ利用者データベースを参照できるため、連携が円滑になる。特に、老人介護施設では、入所者が医療機関の患者であることも多い。そのような場合に、医療機関との連携を密にすることが望まれており、同じ医療システムをシンクライアント環境で実現できるため、導入・運用を効率的に実現できる。なお、介護施設の利用状況とは、介護施設に入居した利用者が、介護施設において提供される介護サービスについてどのようなサービスを利用しているかの状況や、そのようなサービスに付随して使用される医薬品や医療用品、オムツや防水シート等の衛生用品（介護用品）の使用状況を想定する。

（８）前記管理サーバは、前記事業者の商品・サービスの提供状況を取得し、提供可能状況が一定水準以下になった場合に、商品の発注処理又は一定水準以下になった旨の通知処理を実行してもよい。
医療システムに参加している事業者が提供する商品等の使用状況を共通に管理することで、共通在庫水準が一定以下となった場合に、発注処理や在庫管理者への在庫確認の警告を出すことで、一括発注によるコスト低減、在庫管理工数の削減が実現できる。また、医療システム全体の情報蓄積・利用により在庫管理を行いコスト削減等が実現できているので、上記コスト削減等の還元は特定の事業者ではなくシステム運用費用への充当と言った全体への貢献に還元でき、多くの事業者にとって当該医療システムへの参入のインセンティブになる。

（９）前記シンクライアント環境は、前記管理サーバ上に仮想デスクトップ環境を生成し前記事業者の情報処理端末から前記仮想デスクトップ環境を操作する仮想化技術により構築されてもよい。
シンクライアント環境を特に仮想デスクトップ環境として実現することで、システムの管理や更新において、ユーザ（事業者）の負担が少なくなる。
本発明の医療システムの概要は次の通りである。
本発明の医療システムは、医療・福祉に関連する商品・サービスを提供する複数の事業者の事業者情報を記録する事業者データベースと、前記事業者の商品・サービスを利用する利用者の利用者情報を識別情報と関連付けて記録する利用者データベースと、を備えた医療情報共有サーバと、
前記事業者の情報処理端末と、
を備え、
前記事業者は医療機関を含み、
前記医療情報共有サーバは、前記事業者の前記情報処理端末の動作を管理する管理サーバを備え、
前記管理サーバと前記医療機関の前記情報処理端末である医療機関端末は、前記医療機関端末をシンクライアント端末としたシンクライアント環境にて、電子カルテシステムを機能させ、
前記電子カルテシステムは、前記利用者を診察した際の診察情報及び処方内容を記録した電子カルテを前記利用者情報として前記利用者データベースに記録させるとともに、前記利用者データベースに記録されている同じ利用者の前記利用者情報を参照し表示可能であり、前記利用者に対する処方薬を選択する際に、前記利用者データベースに記録されている前記利用者情報を参照し、同一又は類似の薬効の薬を選択する場合であって処方期間が重複する場合には、その旨を表示し、処方者の確認を取得し、かつ、既に診療した医療機関の処方を変更した場合に、前記利用者情報に変更内容を反映させ、発行する処方せんに処方を変更した旨とその理由を注記するとともに、前記利用者データベースに処方を変更した旨とその理由を注記し、前記既に診療した医療機関に前記変更を通知する。
本発明の医療システムは、医療・福祉に関連する商品・サービスを提供する複数の事業者の事業者情報を記録する事業者データベースと、前記事業者の商品・サービスを利用する利用者の利用者情報を識別情報と関連付けて記録する利用者データベースと、を備えた医療情報共有サーバと、
前記事業者の情報処理端末と、
を備え、
前記事業者は医療機関を含み、
前記医療情報共有サーバは、前記事業者の前記情報処理端末の動作を管理する管理サーバを備え、
前記管理サーバと前記医療機関の前記情報処理端末である医療機関端末は、前記医療機関端末をシンクライアント端末としたシンクライアント環境にて、電子カルテシステムを機能させ、
前記電子カルテシステムは、前記利用者を診察した際の診察情報及び処方内容を記録した電子カルテを前記利用者情報として前記利用者データベースに記録させるとともに、前記利用者データベースに記録されている同じ利用者の前記利用者情報を参照し表示可能であり、さらに、不正処方の監視対象となる薬を記録し、その薬について重複処方が発生した場合に、不正処方の虞がある旨を前記電子カルテシステムにおいて通知する監視機能を備える。
本発明の医療システムは、医療・福祉に関連する商品・サービスを提供する複数の事業者の事業者情報を記録する事業者データベースと、前記事業者の商品・サービスを利用する利用者の利用者情報を識別情報と関連付けて記録する利用者データベースと、を備えた医療情報共有サーバと、
前記事業者の情報処理端末と、
を備え、
前記事業者は医療機関を含み、
前記医療情報共有サーバは、前記事業者の前記情報処理端末の動作を管理する管理サーバを備え、
前記管理サーバと前記医療機関の前記情報処理端末である医療機関端末は、前記医療機関端末をシンクライアント端末としたシンクライアント環境にて、電子カルテシステムを機能させ、
前記電子カルテシステムは、前記利用者を診察した際の診察情報及び処方内容を記録した電子カルテを前記利用者情報として前記利用者データベースに記録させるとともに、前記利用者データベースに記録されている同じ利用者の前記利用者情報を参照し表示可能であり、
前記医療情報共有サーバは、前記医療機関に所属する医師の情報を記録する医師データベースを備え、
前記電子カルテシステムは、前記利用者である患者を別の医療機関に紹介する紹介機能と、前記患者の症例から治療を行える医師を前記医師データベースから検索する医師検索医療機関検索機能と、を備え、
前記紹介機能は、紹介処理の際に、前記患者の情報を電子化したデータとして、前記別の医療機関に提供する情報提供機能と、前記医師検索医療機関検索機能により選択した医療機関の医師への診察日時を予約する予約機能と、を備える。
本発明の医療システムは、医療・福祉に関連する商品・サービスを提供する複数の事業者の事業者情報を記録する事業者データベースと、前記事業者の商品・サービスを利用する利用者の利用者情報を識別情報と関連付けて記録する利用者データベースと、を備えた医療情報共有サーバと、
前記事業者の情報処理端末と、
を備え、
前記事業者は医療機関を含み、
前記医療情報共有サーバは、前記事業者の前記情報処理端末の動作を管理する管理サーバを備え、
前記管理サーバと前記医療機関の前記情報処理端末である医療機関端末は、前記医療機関端末をシンクライアント端末としたシンクライアント環境にて、電子カルテシステムを機能させ、
前記電子カルテシステムは、前記利用者を診察した際の診察情報及び処方内容を記録した電子カルテを前記利用者情報として前記利用者データベースに記録させるとともに、前記利用者データベースに記録されている同じ利用者の前記利用者情報を参照し表示可能であり、
前記複数の医療機関にて使用される医薬品の在庫状況を共通に記録する共通在庫データベースを備え、
前記共通在庫データベースは、感染症に適用の医薬品の在庫状況の変化をもとに感染症の発生を予測する機能を備え、
前記電子カルテシステムは、前記共通在庫データベースが感染症発生と判断した場合、電子カルテ上に感染症発生の警告を表示する。

本発明によると、シンクライアント環境で、医療・福祉関連の事業者の情報処理端末を構成し、管理サーバで医療情報システムを共有し管理・運用することから、事業者は、導入・管理運用・セキュリティの費用負担だけでなく技術的な観点においても費用低減でき、導入が容易になる。また、地域医療関係者で共通のシステムまたは連携を前提としたシステムを導入することなり、この点でも導入・運用時の負担低減となる。

本実施形態に係る、地域医療連携システムの概略構成を示す図である。 本実施形態に係る、地域医療連携システムのブロック図である。 本実施形態に係る、医療情報共有サーバのブロック図である。 本実施形態に係る、患者ＤＢの例を示す図である。 本実施形態に係る、医療関係者ＤＢの例を示す図である。 本実施形態に係る、薬剤師ＤＢの例を示す図である。 本実施形態に係る、介護士ＤＢの例を示す図である。 本実施形態に係る、事業者ＤＢの例を示す図である。 本実施形態に係る、医療機関端末のブロック図である。 本実施形態に係る、患者が医療機関用サイトにアクセスして利用できるサービスの例を示した図である。 本実施形態に係る、医療機関端末のシンクライアント端末に表示される電子カルテの画面例である。 本実施形態に係る、電子カルテのＯＲＤＥＲ記載領域に処方する薬を記入する際の処理例を示すフローチャートである。 本実施形態に係る、患者が処方せんを薬局へ持参した際の処理を説明するチャート図である。 本実施形態に係る、医療機関間の予約機能の画面例を示す図である。

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

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

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

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

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

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

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

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

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

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

このとき、医療機関端末２０は、ポータルサイト１０１から医療機関用サイト１１０にアクセスして、医療機関９２用に用意された機能を利用する。医療機関９２用に用意された機能とは、例えば、電子カルテシステム、臨床検査システム、医療会計システム、レセプト支援システム等がある。以下では、主に電子カルテシステムに着目して説明する。詳細は後述するが、電子カルテシステムやその他の機能は、例えば、シンクライアント環境（特にＶＤＩ（バーチャルデスクトップ環境）方式）として医療情報共有サーバ１０と協働で実現している。医療機関９２は、自己の診療において作成した電子カルテ３０を地域共有ＤＢ１２に記録し、各医療機関９２は地域共有ＤＢ１２に記録されている電子カルテ３０を相互に参照して利用可能になっている。また、電子カルテシステムは、医療情報共有サーバ１０がＡＳＰ（アプリケーションサービスプロバイダー）として提供する電子処方せんシステムと連係しており、処方せんを出力する際に、電子処方せんとして出力することができる。さらに、他の事業者が医療情報共有サーバ１０の地域共有ＤＢ１２に記録したデータを一定条件下で参照することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図４の患者ＤＢ１２１に示すように、患者９４が登録する患者情報の項目として、「名前（氏名）」「社会保障番号」「生年月日」「住所・電話番号」「認証情報」を必須登録情報とし、必須登録情報が登録されると、患者共通ＩＤが付される。また、任意登録情報として、例えば「緊急連絡先」「延命治療意思」「臓器提供意思」「要注意事項」「注意薬情報／副作用情報」「ヘルパー」「介護先」「かかりつけ薬局」などがある。「延命治療意思」「臓器提供意思」について登録があることで、患者９４が死亡した場合等に、医療機関９２においてそれら意思の確認が円滑になる。また、「緊急連絡先」「ヘルパー」「介護先」が登録されていることで、患者９４に確認が難しい状態でも、家族・親類等への連絡が可能となる。また、「要注意事項」として既往症や手術歴等を登録することで、患者９４に確認が難しい状況において、医療機関９２にて避けるべき処置を把握でき、治療を円滑にできる。「注意薬事項／副作用情報」では、患者９４が自身の薬の履歴から副作用等により避けたいと考える薬があれば理由とともに登録する。「かかりつけ薬局」があることで、医師が処方せんを出す場合に、薬の在庫状況を事前に把握できたりする。また、後述の医療機関端末２０で稼働する電子カルテシステムや薬局端末６０で稼働する処方せんシステムにおいて、医師や薬剤師が登録してもよい。このとき登録者の情報（医師ＩＤや薬剤師ＩＤ）も関連づけて登録される。

認証情報は、複数種類の認証手段で登録できる。例えば、「パスワード」（図中「ｐａｓｓ」と表記する）、「指紋認証」、「顔認証」、「声紋認証」などがある。スマートフォンやタブレット端末等のモバイル端末２２では、「指紋認証」、「顔認証」「声紋認証」などの様々な認証機能を利用できる。また、単なる複数の認証手段でなく、「記憶（パスワード等）」「所持（ＩＣカード等）」「生体情報（指紋等）」を組み合わせた二要素認証が用いられてもよい。

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

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

なお、患者９４は、登録時に、名前等の所定の必須開示項目以外について開示範囲を設定可能にしてもよく、どの項目をどの種の事業者（医療機関９２、薬局９６、製薬会社９７、介護施設９８）、さらに事業者のどの属性の人（医者、看護師、薬剤師、事務担当者など）に開示するかを決めることができる。例えば、医療機関９２に対しては全ての項目を開示し、薬局９６に対して必須開示項目以外は開示しないとすることができる。また、医療機関９２のうち医師には全ての事項を開示し、看護師について必須開示項目以外は開示しないとすることができる。

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

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

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

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

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

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

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

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

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

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

図３に戻り、共通在庫ＤＢ１３８は、地域医療連携システム１に参加している事業者で共通で使用し調達している物品の在庫に関するデータが記録される。対象となる物品として、例えば、医薬品（処方箋医薬品及び一般用医薬品）、包帯やマスク等の医療品等がある。例えば、処方箋医薬品については、薬局９６で患者９４に出されると、そのデータが共通在庫ＤＢ１３８に反映される。在庫水準が一定以下になると、所定の在庫管理者に警告が出力され、設定によって自動発注するといった処理もできる。参加する事業者で一括して発注し在庫管理するため、調達工数の低減（事務工数の低減）及発注コストの低減が実現できる。また、在庫減少速度が過去データ比べて速い場合に、感染症の流行の可能性があると判断し、医療機関９２等の警告を発してもよい。単一の医療機関９２ではなく地域医療連携システム１全体でのデータのため、警告を受けた医療機関９２等は早期の対応が可能となる。

つづいて図９を参照して医療機関端末２０の構成を具体的に説明する。医療機関端末２０は、医療機関９２に固定され利用されるシンクライアント端末２１と、医師等が携帯するモバイル端末２２とを備える。必要に応じてローカル記憶装置２３も設けられる。

シンクライアント端末２１は、上述したようにシンクライアントサーバ（管理サーバ）として機能する事業者システム支援サーバ１３とともに、ＶＤＩ方式のシンクライアント環境を実現する。具体的な機能構成として、シンクライアント端末２１は、キーボードやマウス等のユーザＩＦ２１１と、液晶ディスプレイ等の表示部２１２と、共通ソフトウェア実行部２１３と、ＬＡＮやＵＳＢ、ＨＤＭＩ（登録商標）等の通信ＩＦ２１４と、モバイル端末接続ＩＦ２１５とを備える。

共通ソフトウェア実行部２１３は、事業者システム支援サーバ１３の仮想デスクトップに所定の画面転送プロトコルを使って接続する。すなわち、事業者システム支援サーバ１３の仮想デスクトップで稼働する電子カルテシステム（会計システム、検査システム等のその他院内システムを含む）を、シンクライアント端末２１に操作可能に表示する。

モバイル端末接続ＩＦ２１５は、スマートフォンやタブレット端末等のモバイル端末２２（外部機器接続ＩＦ２２５）と接続するＩＦであって、通信ＩＦ２１４と共通化されてもよく、近年では一般的なＰＣにおいて、モバイル端末２２の一種であるｉＯＳ（登録商標）端末やＡｎｄｒｏｉｄ（登録商標）端末との接続ＩＦが導入されており、シンクライアント端末２１の表示部２１２にモバイル端末２２の表示と同じものを表示させ操作することができる。

モバイル端末２２は、一般的な構成として、ユーザＩＦ２２１と、表示部２２２と、通信ＩＦ２２３と、外部機器接続ＩＦ２２５と、認証装置２２６とを備える。認証装置２２６は、指紋認証部２２６ａと、顔認証部２２６ｂと、声紋認証部２２６ｃとを有する。なお、モバイル端末２２は、そのＭＡＣアドレスが登録済みの場合にのみ、地域医療連携システム１において利用可能となる。

さらに、モバイル端末２２は、本実施形態の特徴的構成、すなわち医療機関端末２０として機能するための構成として医療情報サービスアプリケーション２２７を有する。医療情報サービスアプリケーション２２７は、シンクライアント端末２１と接続した際に、モバイル端末２２を認証手段として機能させたり、モバイル端末２２自体をシンクライアント端末として機能させたり、また、単独で医療情報共有サーバ１０へ接続する際に、専用のアプリケーションとして機能させたりする。

例えば、医師が認証情報として「指紋情報」と「顔認証情報」を登録している場合であって、シンクライアント端末２１にそれら認証情報を取得する認証装置が設けられていない場合に、モバイル端末２２を認証装置として機能させる。

技術情報ＤＢ１３５は、薬事情報ＤＢ１３６と、医療情報ＤＢ１３７とを備える。薬事情報ＤＢ１３６には、医薬品に関する安全情報が記録されている。安全情報は、該当の製薬会社９７によって登録・更新されたり、地域医療連携システム１の管理者等によって登録・更新される。医療情報ＤＢ１３７には、公的機関や医師会による感染症の情報や、地域医療連携システム１に参加している事業者による情報が記録・更新される。

以上の構成の地域医療連携システム１によって提供されるサービス等の具体例を説明する。図１０は、患者９４が医療機関用サイト１１０にアクセスして利用できるサービスの例を示した図である。患者９４は、患者端末４０でネット閲覧用アプリケーションを起動し、医療機関用サイト１１０のポータルサイト１０１にアクセスする。患者９４がサイト一番上に設けられた「患者／一般」ボタンを押下することで、表示は患者／一般用ポータルサイトへ遷移する。

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

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

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

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

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

「マイページ」が選択されると、その患者９４の利用者情報が表示される。すなわち、通院履歴、薬の処方履歴、登録事項を表示させることができる。図示のマイページ画面Ａ１５の例では通院タブが選択されており、「２０１８年１月２３日 Ａクリニック」の利用を先頭にして５件の通院履歴が表示されている。それぞれのリストを押下することで、利用時の電子カルテ（医療機関９２が閲覧可とした事項）や処方せんを閲覧することができる。すなわち、患者９４は、電子カルテＤＢ１２５や処方せんＤＢ１２６に記録されている自身のデータを全て又は一定範囲において閲覧することができる。また、マイページ画面Ａ１６の例では薬の処方履歴を示す薬タブが選択されており、「２０１８年１月２３日」に、「ＸＹ調剤薬局」で「Ａクリニック」で出された処方せんにより薬を受け取ったことが表示されている。このマイページ画面Ａ１６で下段領域の「一覧表示」ボタンを押下することで、直近の所定期間の処方履歴の一覧が表示される。さらにまた、他の機能として、例えば、患者９４が血圧、血糖値等日常で測定したデータを入力可能なページ（タブ）を設けてもよい。このとき、入力されたデータは、患者ＤＢ１２１に記録・蓄積され、蓄積されたデータの推移をグラフ表示させることもできるようにする。このとき、医療機関９２で測定され患者ＤＢ１２１に記録されているデータや、医師の指導内容（コメント）等を一緒に表示させてもよい。

（追加／以降段落番号繰り下がり）
従来の地域医療連携システムでは医師や医療機関９２による患者診療情報を主体とした相互連携だけに偏っており、患者９４も含めた医療情報の授受が地域連携には施されていなかった。つまり、患者９４が自身の患者情報をネットワーク２上で参照することは、従前ではあまり行われていなかった。しかし、本実施形態の地域医療連携システム１では、患者９４は、患者端末４０よりネットワーク２を通じて患者ＤＢ１２１にアクセスし、自身の患者情報を参照することができる。患者９４が、自身の患者情報を見ることができることで、医師からの指示などの診察結果の確認を行うことができる。患者９４が、血圧、血糖値等日常で測定したデータを患者端末４０より地域医療連携システム１の患者ＤＢ１２１に入力することで、医療機関９２側で患者９４の日常データを見ることができる。また、患者９４が入力することにより、患者９４の日常の測定結果の推移を患者端末４０上で容易に確認することもできる。

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

患者プロフィール領域３０２の右側には、「連携病院予約」ボタン３２１が設けられている。「連携病院予約」ボタン３２１を押下することで、図１４に示す連携病院予約フレーム３２３がポップアップする。詳細は後述するが、連携病院予約フレーム３２３で医師は電子的な診療情報提供書（いわゆる紹介状）を作成し、ネットワーク２を介して紹介先の医療機関９２に患者９４に関するデータ（もしくは参照先）を送信する。

患者プロフィール領域３０２の下側には、「受付」「診察」「会計」の３つのボタン３０３が設けられており、ここでは「診察」が選択されている。さらにそれらボタンの下側領域には、診療記録領域３０４が設けられている。診療記録領域３０４の左１／３が前回診療領域３１１、右２／３が今回診療領域で、その左半分がＳＯＡＰ記載領域３１２、右半分がＯＲＤＥＲ記載領域３１３である。ＯＲＤＥＲ記載領域３１３では、薬選択欄を表示させて処方する薬をリストから選択記入する。詳細は後述するが、薬選択のときに、電子カルテＤＢ１２５や処方せんＤＢ１２６が参照されて、患者９４に対して重複処方や忌避薬の処方が直ちに選択できないようになっている。

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

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

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

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

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

つづいて図１２のフローチャートを参照して、上述の電子カルテ３０においてＯＲＤＥＲ記載領域３１３に処方する薬を記入する際の処理例を説明する。医師がＯＲＤＥＲ記載領域３１３において、薬選択欄を表示させ薬名を入力開始すると（Ｓ１００）、入力文字に応じた候補となる薬名が選択可能にリストとして表示される（Ｓ１０１）。

医師が所望の薬を選択すると（Ｓ１０２）、患者９４の忌避チェックがなされる（Ｓ１０３）。例えば、アレルギー、年齢、既往症から忌避される薬か否かがチェックされる。忌避の該当がある場合（Ｓ１０４のＹ）、警告が表示され（Ｓ１０５）、医師による警告確認が要求される（Ｓ１０６）。医師が別の薬を処方する場合は、別な薬の選択処理に戻る（Ｓ１００）。

自医院のカルテチェックで忌避該当が無い場合（Ｓ１０４のＮ）、または警告確認がなされた場合（Ｓ１０６）、他の医療機関９２での電子カルテのチェックがなされ、同じく忌避チェックがなされる（Ｓ１０７）。忌避の該当がある場合（Ｓ１０８のＹ）、警告が表示され（Ｓ１０９）、医師による警告確認が再度要求される（Ｓ１１０）。医師が別の薬を処方する場合は、別な薬の選択処理に戻る（Ｓ１００）。

他医院のカルテチェックで忌避該当が無い場合（Ｓ１０８のＮ）、または警告確認がなされた場合（Ｓ１１０）、他の医療機関９２で出され薬局９６で処理された処方せんのチェックがなされる（Ｓ１１１）。重複・忌避の該当ありの場合（Ｓ１１２）、警告が表示され（Ｓ１１３）、医師による警告確認が再度要求される（Ｓ１１４）。医師が別の薬を処方する場合は、別な薬の選択処理に戻る（Ｓ１００）。医師が確認後、必要に応じて数量を調整すると（Ｓ１１５）、また、重複・忌避が無い場合（Ｓ１１２のＮ）、処方する期間（すなわち薬の量）が確定する（Ｓ１１６）。

例えば、処方する期間が重複する場合に、同一の薬又は薬効が同一・類似の薬が処方されていれば、処方が不要となったり、処方する期間（すなわち数量）を少なくする。より具体的には、歯科医院で抜歯した患者９４が痛み止めとしてロキソプロフェンが処方されており、１週間分の薬が残っていると想定され、内科医が今回の診察で１週間分の痛み止めの処方が適切と判断した場合であっても、既に処方している同じ薬効（痛み止め）があることから、痛み止めの処方を行わない、といった処置ができる。また、他の医療機関９２である抗生物質の薬が処方されている場合、抗生物質の重複処方は禁止されていることから、今回の診察に関連した抗生物質の処方は行わないという決定ができる。自らの医療機関９２の過去の履歴であれば自らの電子カルテを参照することでチェックは可能である。本実施形態のように、他の医療機関９２による同一の患者９４の電子カルテや処方せんの内容が、電子カルテＤＢ１２５や処方せんＤＢ１２６から参照することができるので、患者９４が医師に認識・通知しないような場合であっても、適切な医療サービスの提供及び医療費の低減を実現できる。また、重複処方に伴う処方量の調整等を行った際に、処方せんにその旨を注記してもよい。

つづいて、図１３のフローチャートを参照して、患者９４が処方せんを薬局９６へ持参した際の処理を説明する。患者９４が医療機関９２で診察を受けると、医療機関９２は処方せん５０を発行するとともに、処方せんＤＢ１２６に記録される（Ｓ２１）。処方せん５０には、処方せん情報が暗号化された二次元コード５１が付されている。処方せん情報として、患者９４の識別情報（例えば名前、患者ＩＤ）及び処方せんＤＢ１２６に記録した際に付されている管理番号である。なお、二次元コード５１自体に具体的な処方内容（薬名、処方量等）が含まれてもよい。

患者９４が処方せん５０を受け取り薬局９６に持参すると（Ｓ２２）、薬局９６では、薬局端末６０に設けられたコードスキャナー５５で処方せん５０の二次元コード５１の読み取り復号が行われる（Ｓ２３）。薬局端末６０は、復号したデータをもとに、処方チェックを行う（Ｓ２４）。より具体的には、薬局端末６０は、処方せんＤＢ１２６にアクセスし、処方履歴を行い、医療機関９２で処方された内容のチェックとともに、別の診療の際に処方された処方せんとの重複処方等の確認を行う（Ｓ２４ａ）。さらに、薬局端末６０は、薬事情報１３６にアクセスして処方する薬の併用等に忌避・注意すべき事項があるか否かをチェックする（Ｓ２４ｂ）。薬局９６の薬剤師は、必要に応じて処方した医療機関９２に疑義照会をする。

処方チェックが終わり患者９４に薬が渡されると、実際に処方した日付、薬名、処方量、担当薬剤師等の情報が処方せんＤＢ１２６の処方データに反映される（Ｓ２５）。患者９４は、患者端末４０で「お薬手帳」アプリを用いて、または、ポータルサイト１０１経由で自身の処方履歴を閲覧することができる（Ｓ２６）。

つづいて、図１４を参照して医療機関９２の間の予約システム（緊急連携機能及び予約機能）について説明する。上述のように、電子カルテ３０の「連携病院予約」ボタン３２１を押下することで、図示の連携病院予約フレーム３２３がポップアップする。

＜段落改行位置調整＞
一般的な診療予約システムでは、患者９４が所望の医療機関９２に電話やウェブ上の予約ページで予約する。必要に応じて医師に診療情報提供書（紹介状）を書いてもらい、それを持参する。しかし、本電子カルテシステムの予約システムは、利用者である患者９４を別の医療機関９２に紹介する紹介機能と、患者９４の治療に適した医師を医療関係者ＤＢ１２２（医師データベース）から検索する医師検索医療機関検索機能と、を備える。さらに、紹介機能は、紹介処理の際に、患者９４の情報を電子化したデータとして、別の医療機関９２に提供する情報提供機能と、医師検索医療機関検索機能により選択した医療機関の医師への診察日時を予約する予約機能と、を備える。また、紹介機能は、紹介処理の際に、患者９４の情報を電子化したデータ（電子カルテや処方せんデータ）として、別の医療機関９２（すなわち紹介先の医療機関９２）に提供する情報提供機能と、医師検索医療機関検索機能により選択した医療機関９２の医師への診察日時を予約する予約機能と、を備える。

具体的に次の通りである。本予約システムでは、ある医療機関９２において、診察の結果、高度な医療又はより専門的な治療を受けることが望ましいと医師が判断した場合に、特定機能病院（種別：０１）や地域医療支援病院（種別：０２）等の基幹病院、一般的な病院（種別：０３）や診療所（種別：０４）であっても専門的な知見を有する医療機関９２での診療を医師が予約するものである。

図示のように、連携病院予約フレーム３２３では、フレーム上部領域に基本情報として予約元の情報（医療機関９２及び担当医の情報）が表示される。その下に、医療機関９２の基本情報が表示される。

患者情報の下には、予約種別選択領域３３０が設けられている。ここで「通常予約」か「救急予約」を選択する。図示では、「通常予約」が選択されている。「通常予約」は、緊急を有しない病気の予約であり、数日〜１ヶ月程度先の予約を想定する。「救急予約」は、一刻を争う状態で、生命に直結する脳卒中、心筋梗塞（急性冠症候群）が疑われる場合や、重症度・緊急度が高く即日の入院／転院が必要とされるような外傷、熱傷、中毒、腹痛（急性腹症）、白血病などの病気に対するものを想定する。なお、ここでは２種類の区分としたが、当然に３種類以上の区分でもよい。

予約種別選択領域３３０の下には、予約先医療機関指定領域３３１が設けられている。予約先医療機関指定領域３３１では、医師が患者９４と相談し、適切な病院を選定する。必要に応じて診療科、担当医を選定することができる。なお、選定可能な医療機関９２は、図８の説明で上述したように、「予約連携」に参加する旨を登録していることが必要となる。

予約先医療機関指定領域３３１の下には、「予約日時」を指定する予約日時指定領域３３２が設けられている。予約日が決定していない場合は、「未定」を入力できる。予約種別選択領域３３０で「救急予約」が選択されている場合は、「救急」と自動入力される。

予約日時指定領域３３２の下には、診療情報提供書（紹介状）の種別を選択する紹介状種別指定領域３３３が設けられている。ここで、診療情報提供書（紹介状）を電子データとしたものとするか、従来のように紙媒体とするかを選択する。電子データが選択されている場合、検査データや保険証番号等の電子データまたはそのデータへのアクセス情報が添付されて送信される。なお、紙媒体の場合には、バーコード等の暗号化情報にて患者情報（特に電子カルテ）へのアクセス情報が付与される。

紹介状種別指定領域３３３の下には、患者ＤＢアクセス権指定領域３３４が設けられている。ここで、該当の患者９４の患者情報について、紹介元の医療機関９２の電子カルテの情報等を全て開示するか、当該診療のみの電子カルテの情報とするかを指定できる。

患者ＤＢアクセス権指定領域３３４の下には、２次紹介先依頼事前連絡指定領域３３５が設けられている。ここでは、紹介先の医療機関９２において、症状やタイミングにより、適切な他の医療機関９２があると判断した場合に、紹介元の医療機関９２や患者９４の確認が必要であるか否かを選択する。例えば、健康診断で胃がんが見つかり、某大学病院に紹介したところ、健康診断の結果を見たその大学病院が腹腔鏡での手術を勧め、さらにその大学病院から、別の癌専門病院の方がキャパがあり早期に手術が可能で、再度紹介されるという事案が想定される。２次紹介先依頼事前連絡指定領域３３５で「要」が選択されている場合は、予約先の医療機関９２（大学病院）が予約元の医療機関９２に対して、２次紹介先となる別の医療機関９２（癌専門病院）に直接予約するように通知する。「不要」の場合、２次紹介先へ直接予約する予定はない旨の意思表示となる。

２次紹介先依頼事前連絡指定領域３３５の下には、紹介目的を指定する紹介目的指定領域３３６が設けられている。ここでは、「検査」「入院」「手術」「その他」を選択する。「その他」の場合、具体的な内容を記入する。

紹介目的指定領域３３６の下には、病名／治療履歴概要指定領域３３７が設けられている。「電子カルテに記載の通り」または「追加情報あり」を選択する。「電子カルテに記載の通り」の場合は、病名／治療履歴については電子カルテの参照を依頼する。「追加情報あり」の場合は、医師が空欄に申し送りが必要と考える事項を記入する。

最下領域には、確定ボタン３３８が設けられ、この確定ボタン３３８を押下することで、予約先の医療機関９２に予約連携に関する依頼（通常予約紹介または救急予約）が通知される。依頼の通知には、この連携病院予約フレーム３２３において指定した内容が添付される。

このような医療機関９２の間の予約システムの機能によって、紹介時の医療機関９２の間の問い合わせ処理等を低減できる。また、患者９４の情報をネットワーク２を介して円滑に送受することができる。また、この予約システムを用いた場合に、両方の医療機関９２に手数料（紹介料）を発生させることで、紹介作業にタダ働きが発生することが防止できる。また、紹介作業に保険点数の設定をしてもよい。

また、生命に直結しないものの重症度・緊急度が高く即日の対応が必要な状況においても、医療機関９２の間、より具体的には所属の医師同士の連絡を円滑に効果的でき、入院先や転院先の医療機関９２への情報伝達を的確に行える。また、救急搬送時の救急車の乗務員に対する説明等も無駄なく行える。すなわち、例えば、ある医療機関９２で、外来にて発熱が続くと受診した患者９４が白血病と分かり、移植も視野に入れた病院に転院することが望ましと判断する。このとき、各病院で血液内科のキャパは僅かの状況を想定する。従来では、電話でのやり取りを医師同士が行っており、病院探しには非常に時間がかかる作業であり、特に混雑時において医師のリソース分配に早急な改善が必要とされていた。特に、その日のうちに緊急で入院しなければならない状況の場合、医師はその作業に時間を割く必要となり、他の診療が滞ってしまう場合もあった。診療所（クリニック等）から基幹病院に救急患者を送る場合、必ず診療所の医師が、基幹病院の救急科の担当医師に電話で引き受けてくれる確約をとり、ＯＫが取れたら、紹介状を作成し、救急車に連絡し、到着した救急隊に説明をする、という流れとなり、非常に手間のかかる作業であった。しかし、このような作業を抑制し、患者９４の搬送をいち早く行え、また、他の患者９４の診察も遅れることを防止できる。

以上、本実施形態の特徴の概要を纏めると次の通りである。
事業者のうち少なくとも医療機関９２については、その医療機関端末２０が、ＶＤＩ方式のシンクライアント端末２１として医療情報共有サーバ１０の事業者システム支援サーバ１３とともにシンクライアント環境（特にＶＤＩ方式）にて、電子カルテシステムを稼働させ、電子カルテや処方せんのデータは医療情報共有サーバ１０に記録・保持される。これによって、医療機関９２における医療機関端末２０（情報処理端末）の導入・運用コストの低減が図れる。特に、ＶＤＩ方式のシンクライアント環境とすることで、多数の医療機関端末２０が異なる医療機関９２で稼働する状態でも、医療機関端末２０の数に応じて大幅にコスト増となることがない。また、地域で同じ環境の医療機関端末２０を用いるため、医療機関９２（医療機関端末２０を操作する医師や看護師等）同士が、運用・操作に対する情報交換が容易で、習熟が進みやすい。また、医療機関端末２０のセキュリティ確保が容易になる。

（２）医療機関端末２０で稼働する電子カルテシステムは、患者９４に処方する薬を選択する際に、利用者ＤＢ（電子カルテＤＢ１２５や処方せんＤＢ１２６）に記録されている情報を参照し、同一又は類似の薬効の薬を選択する場合であって処方期間が重複する場合には、その旨（警告）を表示し、処方者である医師の確認をとる。重複処方を回避でき、必要な分量だけ処方でき、医療費の無駄を削減できる。処方せんを出力する際に、その旨を注記することで、薬局９６（薬剤師）から医師への疑義照会といった作業を抑制することができ、病院、薬局双方の業務の効率化に繋がる。

（３）医療機関端末２０で稼働する電子カルテシステムは、患者９４に処方する薬を選択する際に、利用者ＤＢ（電子カルテＤＢ１２５や処方せんＤＢ１２６）に記録されているデータを参照し、併用が忌避すべき薬が処方されている場合には、その旨を表示し、処方する医師の確認を取得する。中止・変更に際し、先の医療機関９２が分かるので、連絡が円滑にできたり、地域医療連携システム１内の処理として患者９４の利用者情報として反映され先の医療機関９２は別の医療機関９２で薬が中止・変更された旨、その理由を把握することができる。処方せんを出力する際に、変更・中止に関して注記することで、薬局９６（薬剤師）から医師への疑義照会といった作業を抑制することができ、医療機関９２、薬局９６双方の業務の効率化に繋がる。

（４）薬局９６に導入されるシステムについても、医療機関９２と同様にシンクライアント環境で構築され、処方せんの内容が利用者ＤＢ（処方せんＤＢ１２６）に記録される。薬局９６のシステムでは、重複／忌避処方を判断し、薬剤師による確認を促し、薬剤師は、処方せんに注記があれば、その内容を患者９４に伝え、注記が無ければ医師に確認することができる。また、薬局９６のシステムが医療機関９２のシステムと連携し、同じ利用者ＤＢ（処方せんＤＢ１２６）を参照するので、医師の処方時の判断を一定範囲で把握できるので、無駄な疑義照会等の作業を無くすことができ、患者９４への薬の提供をスムーズに行うことができる。

（５）電子カルテシステムの予約システムは、図１４の連携病院予約フレーム３２３で示したように、利用者である患者９４を別の医療機関９２に紹介する紹介機能と、患者９４の治療に適した医師を医療関係者ＤＢ１２２（医師データベース）から検索する医師検索医療機関検索機能と、を備える。さらに、紹介機能は、紹介処理の際に、患者９４の情報を電子化したデータとして、別の医療機関９２に提供する情報提供機能と、医師検索医療機関検索機能により選択した医療機関の医師への診察日時を予約する予約機能と、を備える。また、紹介機能は、紹介処理の際に、患者９４の情報を電子化したデータ（電子カルテや処方せんデータ）として、別の医療機関９２（すなわち紹介先の医療機関９２）に提供する情報提供機能と、医師検索医療機関検索機能により選択した医療機関９２の医師への診察日時を予約する予約機能と、を備える。地域医療連携システム１では、このように医療機関９２（医師）が医療機関端末２０を用いて他の医療機関９２の予約を行う。その結果、医療機関９２やその診療科、担当医の選択を適切行うことができる。また、予約処理において、電子化した患者情報（電子カルテや処方せんデータ）を直接または電子カルテＤＢ１２５や処方せんＤＢ１２６経由で間接的に提供するので、紹介先の医療機関９２も迅速な対応が可能となる。

（６）医療機関端末２０のシンクライアント端末２１は、医者のモバイル端末２２（スマートホンやタブレット端末）を接続してそのモバイル端末２２の認証手段を用いて認証することができる。そして、認証手段の種類や数に応じて、利用制限が付され、「全ての機能を利用可能」、「参照可能だけ」、「参照範囲限定」（自医院のみ、他の医院も等）等が決めることができる。

（７）介護施設９８の情報処理端末である介護施設端末８０についてもシンクライアント環境にて、介護支援システムを機能させる。事業者として介護施設９８が参画することで、医療機関９２と介護施設９８との間の連携がスムーズになる。医療機関９２が介護施設９８を運営する場合であっても、導入するシステムのベースが異なって連携が難しい場合も有り、運営者が異なる場合にはなおさらであった。しかし、医療機関９２と介護施設９８が同じ地域医療連携システム１を利用し同じ利用者ＤＢを参照できるため、連携が円滑なる。特に、老人介護施設では、入所者が同じ地域の医療機関９２の患者９４であることも多い。そのような場合に、医療機関９２との連携を密にすることが望まれており、同じ地域医療連携システム１のシンクライアント環境で実現できるため、導入・運用を効率的に実現できる。

（８）医療情報共有サーバ１０の共通在庫ＤＢ１３８は、事業者の商品・サービスの提供状況を取得し、提供可能状況が一定水準以下になった場合に、商品の発注処理又は一定水準以下になった旨の通知処理を実行する。一括発注によるコスト低減、在庫管理工数の削減が実現できる。在庫共通化により浮いた費用を、地域医療連携システム１の運用費用に当てることで、事業者の負担を抑制できる。また、在庫状況から地域全体の病気の流行状態を把握できるため、地域医療連携システム１に参加する医療機関９２等は、早いタイミングで流行状態を把握できる。

以上、本発明を実施形態をもとに説明した。この実施形態は例示であり、それらの各構成要素の組み合わせにいろいろな変形例が可能なこと、また、そうした変形例も本発明の範囲にあることは当業者に理解されるところである。例えば、上記実施形態では、保険診療を想定して説明したが、自由診療についても適用可能である。その場合には、新たに「自由診療用情報システム」を導入してもよいし、現状の法令・ガイドライン等により保険診療と自由診療とを区別して扱うことが定められている内容に基づきシステムを調整してもよい。例えば、保険診療では診療報酬が、いわゆるレセプトで管理・算出され明細が管理・出力等される。一方、自由診療はではレセプトの制約がないためそれに対応した機能を追加し明細が管理されたり領収書等が出力されるようになる。

１ 地域医療連携システム
２ ネットワーク
１０ 医療情報共有サーバ
１１ 統括装置
１２ 地域共有ＤＢ
１３ 事業者システム支援サーバ
１４ クライアント用共通ソフトウェア
１５ 登録管理部
１６ 認証部
２０ 医療機関端末
２１ シンクライアント端末
２２ モバイル端末
２３ ローカル記憶装置
３０ 電子カルテ
４０ 患者端末
５０ 処方せん
５１ 二次元コード
５５ コードスキャナー
６０ 薬局端末
７０ 製薬機関端末
８０ 介護施設端末
９２ 医療機関
９４ 患者
９６ 薬局
９７ 製薬会社
９８ 介護施設
１００ 医療情報共有サイト
１０１ ポータルサイト
１１０ 医療機関用サイト
１２０ 人ＤＢ
１２１ 患者ＤＢ
１２２ 医療関係者ＤＢ
１２３ 薬剤師ＤＢ
１２４ 介護士ＤＢ
１２５ 電子カルテＤＢ
１２６ 処方せんＤＢ
１３０ 事業者ＤＢ
１３１ 病院ＤＢ
１３２ 薬局ＤＢ
１３３ 製薬機関ＤＢ
１３４ 介護施設ＤＢ
１３５ 技術情報ＤＢ
１３６ 薬事情報ＤＢ
１３７ 医療情報ＤＢ
１３８ 共通在庫ＤＢ
１３９ 機器管理ＤＢ
１４０ 患者用サイト
１６０ 薬局用サイト
１７０ 製薬機関用サイト
１８０ 介護施設用サイト
２２６ 認証装置
２２６ａ 指紋認証部
２２６ｂ 顔認証部
２２６ｃ 声紋認証部
２２７ 医療情報サービスアプリケーション
３０７ 他診察等領域
３０８ 他診察履歴領域
３０９ 処方せん履歴領域

Claims (3)

1. 医療・福祉に関連する商品・サービスを提供する複数の事業者の事業者情報を記録する事業者データベースと、前記事業者の商品・サービスを利用する利用者の利用者情報を識別情報と関連付けて記録する利用者データベースと、を備えた医療情報共有サーバと、
   前記事業者の情報処理端末と、
   を備え、
   前記事業者は医療機関を含み、
   前記医療情報共有サーバは、前記事業者の前記情報処理端末の動作を管理する管理サーバを備え、
   前記管理サーバと前記医療機関の前記情報処理端末である医療機関端末は、前記医療機関端末をシンクライアント端末としたシンクライアント環境にて、電子カルテシステムを機能させ、
   前記電子カルテシステムは、前記利用者を診察した際の診察情報及び処方内容を記録した電子カルテを前記利用者情報として前記利用者データベースに記録させるとともに、前記利用者データベースに記録されている同じ利用者の前記利用者情報を参照し表示可能であり、前記利用者に対する処方薬を選択する際に、前記利用者データベースに記録されている前記利用者情報を参照し、同一又は類似の薬効の薬を選択する場合であって処方期間が重複する場合には、その旨を表示し、処方者の確認を取得し、かつ、既に診療した医療機関の処方を変更した場合に、前記利用者情報に変更内容を反映させ、発行する処方せんに処方を変更した旨とその理由を注記するとともに、前記利用者データベースに処方を変更した旨とその理由を注記し、前記既に診療した医療機関に前記変更を通知することを特徴とする医療システム。
2. 前記電子カルテシステムは、前記利用者に対する処方薬を選択する際に、前記利用者データベースに記録されている前記利用者情報を参照し、処方する薬と忌避すべき薬が処方されているか否かを判断し、忌避すべき薬が処方されている場合には、その旨を表示し、処方する医師の確認を取得することを特徴とする請求項１に記載の医療システム。
3. 前記事業者は薬局を含み、前記薬局の前記情報処理端末である薬局端末と管理サーバとは、前記薬局端末をシンクライアント端末としたシンクライアント環境にて、処方システムを機能させ、
   前記処方システムは、利用者に対する処方せんの情報を取得し前記利用者情報として前記利用者データベースに記録するとともに、前記利用者データベースに記録されている前記利用者情報を参照して、前記処方せんにより処方が指定されている薬に対して重複又は忌避する薬が処方されているか否かを判断し、重複又は忌避する薬が処方されている場合に、警告を出力しその警告に対する薬剤師の確認を取得することを特徴とする請求項１または２に記載の医療システム。

Images