JP6921177B2 - 医療情報システム、医療情報装置、医療情報装置の制御方法及び制御プログラム - Google Patents

Description

本発明は、医療機関で使用されるカルテなどの医療情報を管理するための医療情報システム、医療情報装置、医療情報装置の制御方法及び制御プログラムに関する。

医療機関で使われるＩＴシステムをクラウド化し、クラウドに蓄えられた医療情報を患者に還元し利活用するような仕組みないし考え方（いわゆるＰＨＲ(Personal Health Record)）が知られている（例えば特許文献１）。

特開２０１７−６８４７９号公報、段落０００４

しかし、現状はＩＴシステムのクラウド化にとどまっており、十分な議論をするには至っていない。例えば、患者の持つ端末（アプリ）と、医科・歯科・調剤等の各業務システムとが、シームレスに連携できるように設計されていないなど、医療に関する業務システム間の連携には課題がある。

そこで、本発明は、患者の持つ端末（アプリ）と、医科・歯科・調剤等の各業務システムとを、シームレスに連携させることを目的とする。

上述した課題を解決すべく、本発明の第１の態様は、
複数の医療情報装置と、前記複数の医療情報装置のそれぞれ及び患者端末の間に介在する統合基盤と、を含む医療情報システムであって、
前記統合基盤は、
患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースと、
前記第１の患者データが前記第１のデータベースに登録されると、前記第１の患者データを前記複数の医療情報装置に対して公開する管理部と、を含み、
前記複数の医療情報装置のそれぞれは、
患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶する第２のデータベースと、
前記統合基盤において公開された前記第１の患者データを取得し、前記第２のデータベースに保存する取得部と、
前記患者端末からアクセスを受け付ける受付部と、
前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、当該第１の患者データに対して、前記スタッフにより選定された特定の患者に関する前記医療記録を紐付ける名寄せ部と、を含むこと、
を特徴とする医療情報システムを提供する。

例えば、前記第１の患者データ及び前記第２の患者データがそれぞれ、少なくとも氏名、性別及び生年月日を含んでいてもよく、
前記候補提示部が、前記氏名、前記性別及び前記生年月日のうち少なくとも１つにおいて前記第１の患者データと部分一致する前記第２の患者データに係る患者を前記候補として選び出してもよい。

上記のような構成を有する本発明の医療情報システムでは、前記複数の医療情報装置のそれぞれが、前記スタッフに前記特定の患者を選定させるべく、候補の一覧を表示させる候補提示部を更に含んでもよい。

また、本発明の第２の態様は、
患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースを含む統合基盤を介して患者端末からアクセスされる医療情報装置であって、
患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶する第２のデータベースと、
前記統合基盤において登録及び公開された前記第１の患者データを取得し、前記第２のデータベースに保存する取得部と、
前記患者端末からアクセスを受け付ける受付部と、
前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、当該第１の患者データに対して、前記スタッフにより選定された特定の患者に関する前記医療記録を紐付ける名寄せ部と、
を含むことを特徴とする医療情報装置を提供する。

本発明の第３の態様は、
患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースをそれぞれ含む複数の医療情報装置と、
前記複数の医療情報装置のそれぞれ及び患者端末の間に介在して、患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶する第２のデータベースを含む統合基盤と、
を含む医療情報システムにおける前記医療情報装置に対して、
前記統合基盤において登録及び公開された前記第１の患者データを取得して、前記第２のデータベースに保存し、
前記患者端末からアクセスを受け付け、
前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、当該第１の患者データに対して、前記スタッフにより選定された特定の患者に関する前記医療記録を紐付ける
手順を実行させる医療情報システムの制御方法を提供する。

本発明の第４の態様は、
患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースをそれぞれ含む複数の医療情報装置と、
前記複数の医療情報装置のそれぞれ及び患者端末の間に介在して、患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶する第２のデータベースを含む統合基盤と、
を含む医療情報システムにおける前記医療情報装置に対して、
前記統合基盤において登録及び公開された前記第１の患者データを取得して、前記第２のデータベースに保存し、
前記患者端末からアクセスを受け付け、
前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、当該第１の患者データに対して、前記スタッフにより選定された特定の患者に関する前記医療記録を紐付ける
手順を実行するための制御プログラムを提供する。

本発明の第４の態様は、
患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースをそれぞれ含む複数の医療情報装置と、
前記複数の医療情報装置のそれぞれ及び患者端末の間に介在して、患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶するとともに、前記統合基盤において登録及び公開された前記第１の患者データを取得して、前記第２のデータベースに保存する第２のデータベースを含む統合基盤と、
を含む医療情報システムにおける前記医療情報装置の表示装置に対して、
前記患者端末から受け付けたアクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、前記アクセスに係る患者に関する前記第１の患者データと所定の関連性を有する前記第２の患者データに係る患者の一覧を画面表示させ、
前記一覧の中から前記スタッフにより選定された特定の患者に関する前記医療記録を、前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データに紐付ける
手順を実行させる医療情報システムの制御方法を提供する。

本発明によれば、患者の持つ端末（アプリ）と、医科・歯科・調剤等の各業務システムとを、シームレスに連携させることができる。また、患者データを取り扱うシステム基盤を各業務システムから切り出して運用することができるとともに、患者がアプリから入力する患者データと医療機関のスタッフが業務システムから入力する患者データ、という二つの類似した情報を適切に管理することができる。

実施形態１に係る医療情報システム１の概略図である。 医療情報システム１を構成するコンピュータ１０の物理構成を示すブロック図である。 統合基盤１０のソフトウェア構成を示すブロック図である。 医療情報装置３０のソフトウェア構成を示すブロック図である。 （Ａ）患者及び（Ｂ）医療機関スタッフが起点となる患者データ登録の概略を示す図である。 業務ＤＢ３５における患者データの統合の概念図である。 医療機関ａの医療情報装置３０における患者受付一覧を表示する画面４０の一例である。 医療機関ａの医療情報装置３０にカルテが登録されていない患者を受け付けるための入力画面５０の一例である。 医療機関ａの医療情報装置３０に登録されている類似の患者の一覧を表示する画面６０の一例である。 実施形態２に係る医療情報システム２の概略図である。 医療情報システム２における連携手順の一例を示すフロー図である。

以下、本発明の代表的な実施形態を、図面を参照しつつ詳細に説明する。ただし、本発明はこれら図面に限定されるものではない。また、図面は、本発明を概念的に説明するためのものであるから、理解容易のために、必要に応じて寸法、比又は数を誇張又は簡略化して表している場合もある。

１．医療情報システムの概要
１−１．医療情報システムの全体構成
本実施形態に係る医療情報システム１の全体構成を説明する。
図１（Ａ）に示すように、医療情報システム１は、統合基盤１０及び複数の医療情報装置３０を含み、複数の患者端末（アプリ）７０と通信可能に構成されている。ここで、「医療」とは、医科、歯科及び調剤を含む概念であり、更に介護等を含んでもよい。また、「医療情報」は、例えば診療記録（カルテ）、処方・服薬記録などに関するＰＨＲ(Personal Health Record)を広く含む。この明細書において、医療記録とは、医療情報のうち、後述する患者データを除いたものを指す。

医療情報装置３０は、医療情報を扱う業務システムであり、医療機関ごとに設けられる。医療情報装置３０は、医科、歯科、調剤など特定の領域を扱う業務システムでもよいし、複数の領域又は医療全般をカバーする複合的な業務システムでもよい。また、医療機関は、例えば、個々の診療所・病院・薬局を１単位としてもよいし、同じ経営母体に属する複数の診療所・病院・薬局を１単位としてもよい。本実施形態では、医療情報装置３０として、クラウド型の業務システムを想定しているが、インターネットに接続できる限り実装方式を問わない。医療情報装置３０の詳細は追って述べる。

アプリ７０は、患者がパーソナルコンピュータ、スマートフォン、タブレット、ウェアラブル端末等のコンピュータ端末（患者端末）を操作することにより利用可能なアプリケーションである。患者は、アプリ７０を介して、医療機関とのコミュニケーションや医療情報の共有を行うことができる。

統合基盤１０は、アプリ７０から入力された患者データと、統合基盤１０に接続される複数の医療情報装置３０にて取り扱われる患者データとを、横断的に管理するシステム基盤である。統合基盤１０は、認証機能、データ管理機能、決済機能等の管理機能を持ち、更に、アプリ７０から入力された患者データと医療機関から入力された患者データとを紐付けるための紐付機能を有していてもよい（後述する実施形態２参照）。これらの機能については追って詳細に述べる。

本実施形態において、アプリ７０と統合基盤１０とは、暗号化した通信路を介して接続されている。暗号化した通信のために、例えばＨＴＴＰＳ、ｇＲＰＣなどのプロトコルを適宜利用することができる。
また、統合基盤１０と各医療情報装置３０とは、暗号化した通信路により接続されている。より具体的には、セキュリティ、障害耐性及び情報連携の非同期性の観点から、図１（Ｂ）に示すように、統合基盤１０から各医療情報装置３０へ向けての情報共有には、パブリッシュ・サブスクライブ（Publish-Subscribe）方式により、各医療情報装置３０から統合基盤１０へ向けての情報共有はＨＴＴＰＳ等のプロトコルに従ったリクエストによる。

１−２．医療情報装置、患者端末及び統合基盤を構成するコンピュータのハードウェア構成
図２を参照して、医療情報装置３０、患者端末７０及び統合基盤１０を構成するコンピュータ１００のハードウェア構成を説明する。図示するように、コンピュータ１００は、ＣＰＵ（演算装置）１０１、メモリ１０２、記憶装置１０３及び通信装置１０４を含み、更に入力装置１０５及び出力装置１０６を含んでいてもよい。

ＣＰＵ１０１は、各種プログラム及びデータをメモリ１０２に読み出して実行することで、統合基盤１０、医療情報装置３０及び患者端末７０としての各種機能を実現する。記憶装置１０３は、各種のデータ、データベース及びプログラムを記憶する、例えばハードディスクドライブやソリッドステートドライブ、フラッシュメモリなどである。

通信装置１０４は、有線及び無線の通信ネットワークに接続するためのインターフェイスであり、例えばイーサネット（登録商標）に接続するためのアダプタ、公衆電話回線網に接続するためのモデム、無線通信を行うための無線通信機、シリアル通信のためのＵＳＢ（Universal Serial Bus）コネクタやＲＳ２３２Ｃコネクタなどである。

入力装置１０５は、データを入力する、例えばキーボード、マウス、タッチパネル、ボタン、マイクロフォンなどであり、特に医療情報装置３０及び患者端末７０としてのコンピュータ１００は、入力装置１０５を備えている。

出力装置１０６は、データを出力する、例えばディスプレイ、プリンタ、スピーカなどであり、特に医療情報装置３０及び患者端末７０としてのコンピュータ１００はディスプレイを備えている。

２．統合基盤のソフトウェア構成
図３を参照して、統合基盤１０を詳細に説明する。図示するように、統合基盤１０は、ゲートウェイ（ＧＷ）１１、認証部１２、管理部１３、決済部１４及び統合データベース（ＤＢ）１５の各機能部を含む。これらの機能部は、単一の装置でもよいし、例えば機能ごとに分かれていてもよい。

ＧＷ１１は、アプリ７０からのアクセスを受け、統合基盤１０のリソースや各医療情報装置３０へのアクセスをコントロールする。ＧＷ１１とアプリ７０との通信は、例えばＨＴＴＰにしたがって行われる。ＧＷ１１はファイヤーウォール機能を有していてもよい。

認証部１２は、アカウントの認証、アクセストークンの発行など、認証・認可を行う。アカウントは、例えば、電話番号又は電子メールアドレスと、パスワードと、によって管理される。

管理部１３は、アカウントに含まれる患者の基本情報（患者情報）を管理する。ここで、患者情報には患者データが含まれ、患者データは、医療情報装置３０間で共通に保有するデータであって、例えば氏名、性別、生年月日である。ただし、医療情報装置３０が個別に必要とする患者のデータは、その医療情報装置３０が保持及び管理することとする。管理部１３は、患者データが新規に登録され、また登録済みの患者データが更新されると、当該の患者データを医療情報装置３０にパブリッシュする。

決済部１４は、医療情報装置３０ごとの決済処理を行い、決済の履歴を管理する。

統合ＤＢ１５は、第１のデータベースに相当する。統合ＤＢ１５に記憶されるデータ項目としては、以下のものを想定しているが、これらに限られない。また、統合ＤＢ１５に以下の全ての項目が記憶される必要はない。
− アカウント情報
− 患者がアプリ７０を利用するために必要最低限な基本情報
− 患者データ（第１の患者データに相当し、氏名、性別、生年月日などを含む）
− 認証情報
− アプリ７０にログインするために必要な情報
− 患者の電話番号、電子メールアドレスなど
− 決済情報
− アプリ７０から支払いを行うために必要な情報
ただし、上記の項目分けは適宜変更されてもよく、例えば、患者データに電話番号等が含まれてもよいし、逆に、患者データから性別等が除かれてもよい。また、統合ＤＢ１５は単一のデータベースであってもよいし、複数に分割されていてもよい。

３．医療情報装置のソフトウェア構成
図４を参照して、医療情報装置３０を詳細に説明する。図示するように、医療情報装置３０は、取得部３１、受付部３２、候補提示部３３、名寄せ部３４及び業務データベース（ＤＢ）３５の各機能部を含む。その他、医療情報装置３０は、業務ＤＢ３５を管理する図示しない管理機能を含むが、ここでは説明を省略する。なお、これらの機能部は、単一の装置でもよいし、例えば機能ごとに分かれていてもよい。

取得部３１は、統合基盤１０からパブリッシュされた患者データを非同期で取得し、業務ＤＢ３５に記憶する。つまり、取得部３１は、サブスクライバーとして機能する。

受付部３２は、アプリ７０からアクセス（例えば診察・調剤等の予約）を受け付けて、業務ＤＢ３５に記憶する。受け付けられたアクセスは、医療情報装置３０の表示装置に表示される（図７Ａ参照）。

候補提示部３３は、業務ＤＢ３５をサーチし、受け付けられたアクセスに係る患者（つまり取得部３１において取得されて業務ＤＢ３５に登録された、当該患者に関する患者データ又はアカウント）に医療記録が紐付けられているかどうかを確認する。その患者に後述の医療記録が紐付けられていない場合には、候補提示部３３は、業務ＤＢ３５から当該患者の候補を選び出し、医療機関のスタッフに確認又は選択させるべく医療情報装置３０の表示装置に一覧表示させる（図７Ｃ参照）。ここで、候補は、医療記録と紐付けられた患者データ（つまり医療機関のスタッフによって患者データが入力された患者データ又はアカウント）であって、アクセスに係る患者の患者データと所定の関連性を有するものである。候補は有効な（無効化されていない）アカウントから抽出されることが好ましい。また、データの関連性は、ここでは類似の程度として評価され、例えば、氏名、性別、生年月日のいずれかの項目が一致（完全一致又は部分一致）する場合に関連性（類似性）が認められてよい。

名寄せ部３４は、医療機関のスタッフによって確認又は選択された候補の医療記録をアクセスに係る患者に対応する患者データに紐付けるとともに、当該確認又は選択された候補の患者データを無効化し（例えば削除し）、今後利用されないようにする。これにより、患者に由来する患者データと、医療機関のスタッフに由来する患者データとが、名寄せされて、患者に由来する患者データに一本化される。

業務ＤＢ３５は第２のデータベースに相当する。業務ＤＢ３５に記憶されるデータ項目としては、以下のものを想定しているが、これらに限られない。また、業務ＤＢ３５に以下の全ての項目が記憶される必要はない。
− 患者データ（第２の患者データに相当し、氏名、性別、生年月日等を含む。）
− 診察するために必要な基本情報
− 保険情報、公費情報など
− 診察情報
− 診察結果を管理するための情報
− 医科、歯科の場合には、主訴・所見、処置・行為など
− 調剤の場合には、薬歴、服薬指導など
− 会計情報
− 患者への請求金額を算出するための情報
− 請求金額、内訳など
ここで、業務ＤＢ３５の登録項目のうち患者データ以外の項目は、上述した医療記録に含まれるものとしてよい。なお、業務ＤＢ３５は単一のデータベースであってもよいし、複数に分割されていてもよい。

４．医療情報システムの動作
次いで、上述した構成を有する医療情報システム１の動作を、幾つかのケースごとに説明する。

４−１． 新規患者データの登録
図５を参照して、アプリ７０経由（患者起点）及び医療情報装置３０経由（スタッフ起点）のそれぞれにおける患者データの保存手順を説明する。

（Ａ）患者起点の患者データ登録
患者が初めてアプリ７０から医療情報システム１にアクセスするとき、患者起点の患者データ登録が行われる。

具体的には、ステップＡ１において、アプリ７０に自身の患者情報（患者データなど）を入力する。アプリ７０は、ステップＡ２において、入力された患者情報をもとに、統合基盤１０に対して患者登録を要求するＨＴＴＰリクエストを送信する。

統合基盤１０（管理部１３）は、患者登録のリクエストを受信すると、ステップＡ３において、例えばアカウントＰ−ａｐｐを生成して当該患者の患者情報を統合ＤＢ１５に保存する。次いで、ステップＡ４において、統合基盤１０（認証部１２）は、アプリ７０に対して認証キーを返答する。以降、アプリ７０は、発行された認証キーをもとに統合基盤１０（認証部１２）への認証を行う。

ステップＡ５において、統合基盤１０（例えば管理部１３）は、統合基盤１０に接続している医療情報装置３０に対して非同期で患者データ（アカウントＰ−ａｐｐ）を公開（パブリッシュ）する。ステップＡ６において、医療情報装置３０は、任意のタイミングで、公開された患者データを取得（サブスクライブ）し、業務ＤＢ３５に保存する。

このようにして、患者起点で患者データが統合ＤＢ１５及び業務ＤＢ３５に登録される。患者起点で業務ＤＢ３５に登録された患者データ（アカウントＰ−ａｐｐ）には、当初、医療記録などは紐付いていない。なお、患者が、登録済みの自己の患者データを変更する場合にも、上記ステップに沿って変更登録が行われる。

（Ｂ）スタッフ起点の患者データ登録
患者がある医療機関に初めて通院するとき（例えば初診のとき）、スタッフ起点の患者データ登録が行われる。

つまり、ステップＢ１において、当該医療機関のスタッフは、医療情報装置３０に対して当該患者の基本患者情報を入力する。なお、ここでいう患者情報は、統合ＤＢ１５に保存される患者データと同じ種類の患者データを含み、その他のデータに関しては、統合ＤＢ１５に保存される患者情報と一致していてもよいし異なっていてもよい。

そして、ステップＢ２において、医療情報装置３０は、例えばアカウントＰを生成して、スタッフによって入力された当該患者の患者情報を業務ＤＢ３５に保存する。

このようにして、医療機関のスタッフ起点で患者の患者データ（アカウントＰ）が業務ＤＢ３５に登録される。したがって、医療機関のスタッフ起点で業務ＤＢ３５に登録された有効な（無効化されていない）患者データには、医療記録が紐付いている。

４−２． 患者データの名寄せ
図６を参照して、患者データの管理方式を説明する。

上述のとおり、アプリ７０経由（患者起点）で入力された患者の患者データ（アカウントＰ−ａｐｐ）は、統合ＤＢ１５への保存後に統合基盤１０により非同期で公開され、統合基盤１０に接続されている全ての医療情報装置３０（取得部３１）において取得可能とされ、各業務ＤＢ３５に保存される。一方、医療情報装置３０経由（スタッフ起点）で入力された患者データ（アカウントＰ）もまた、業務ＤＢ３５に保存されている。つまり、業務ＤＢ３５には、患者起点の患者データとスタッフ起点の患者データといった、２系統の患者データが別アカウントＰ，Ｐ−ａｐｐとして記録される。ただし、これら２系統の患者データの間には、例えば、スタッフ起点の患者データには医療記録が紐付いているが、患者起点の患者データには医療記録が関連付けられていない、といった違いがある。

このような２系統の患者データ（アカウント）の並存状態を解消するべく、両者を名寄せして一本化する。ここでは、医療機関スタッフのオペレーションを介して、業務ＤＢ３５における患者起点の患者データ及びスタッフ起点の患者データを、名寄せする。本実施形態では、正確かつ確実な名寄せを実現するために、スタッフが、例えば氏名、性別、生年月日等の項目の一致を目視で確認したうえで、名寄せを実行することとしている。

図７Ａ〜図７Ｃを参照して、名寄せの手順の具体例を説明する。前提として、業務ＤＢ３５には、既に、患者起点の患者データ（アカウントＰ−ａｐｐ）及びスタッフ起点の患者データ（アカウントＰ）が登録されているものとする。ここでは、患者端末（アプリ）７０から医療情報装置３０へのアクセスの一例として診療予約を挙げて説明するが、アクセスがこれに限られないことは言うまでもない。

ある医療機関ａの医療情報装置３０（受付部３２）は、アプリ７０経由で、患者Ａによる診察予約を受け付ける。この診察予約は、患者起点の患者データ（アカウントＰ−ａｐｐ）を用いて行われているため、医療情報装置３０は、このアカウントＰ−ａｐｐに、業務システムとしての患者情報登録はない（紐付けられた医療記録がない）と判断する。したがって、医療機関ａの端末の受付一覧画面４０には、例えば「カルテ未登録」の表示を含む、患者Ａの予約状況４１が表れる（図７Ａ）。

医療機関ａのスタッフが「受付」ボタン４２を選択すると、医療機関ａの端末には、業務システムへの患者情報（例えば患者の氏名、性別及び生年月日の入力欄５１〜５４などの患者データを含む）の入力又は確認を促す画面５０がポップアップ表示される（図７Ｂ）。スタッフが患者情報を入力又は確認して「次へ」ボタン５５を選択すると、患者Ａの候補として類似患者の一覧画面６０が表示される（図７Ｃ）。候補が一覧表示されることで、スタッフの作業負担が軽減されるとともに、作業ミスが軽減される。

類似患者の一覧画面６０では、アプリ起点の患者データと類似しているデータを持つ、業務システム中の患者（スタッフ起点の患者データ；アカウントＰ）の一覧６１が表示される。一覧表示されるアカウントＰは有効なものだけでよい。そして医療機関ａのスタッフが、一覧６１から、患者Ａと同一と判断した患者を選択することで、名寄せが実施される。つまり、これまでスタッフ起点の患者データに対応する業務ＤＢ３５中のアカウントＰに紐付いていた医療記録が、アプリ起点の患者データ（アカウントＰ−ａｐｐ）に付け替えられるとともに、スタッフ起点の患者データに対応する業務ＤＢ３５中のアカウントＰが無効化（削除等）される。

あるいは、スタッフは、一覧６１に患者Ａと同一と判断できる患者がない場合（一覧６１に候補がリストアップされない場合を含む）には、「新規登録」ボタン６２を選択し、医療記録の新規作成を行う。

４−３．アカウント統合後の利用手順
上記のようにしてアプリ起点及びスタッフ起点の患者データの名寄せが完了すると、例えばアプリ７０が診療予約のために医療機関ａの医療情報装置３０にアクセスする場合、
− 患者Ａがアプリ７０を介して医療情報システム１（統合基盤１０）にアクセス（ユーザ認証）し、
− 患者Ａがアプリ７０を介して医療機関ａに診察等の予約をし、
− 医療機関ａの医療情報装置３０において患者Ａ（アプリ７０）の予約を受け付け、
− 該当する場合には、診察後に、医療情報システム１（統合基盤１０）を介して代金の決済を行う。
なお、この段階では、業務ＤＢ３５において、患者Ａ（アプリ７０）が予約において用いたアカウントと医療記録とが関連付けられている。その他のアクセスの場合でも、上記と同様の手順で処理が行われてよい。

以上のとおり、医療情報システム１では、患者の持つ端末（アプリ７０）と、医科・歯科・調剤等の各業務システムとが、統合基盤１０を介してシームレスに連携される。つまり、患者から見れば、アプリ７０を介して１つのアカウントを準備するだけで、アプリ７０を介して複数の医療機関に対してアクセスすることができ、便利である。

また、医療情報システム１では、名寄せを実行することで、患者が入力した患者自身のデータ（患者由来情報）と、医療機関が入力した当該患者のデータ（医療機関由来情報）とを、区別して管理できる。つまり、患者由来情報は、統合ＤＢ１５に記憶されており、業務ＤＢ３５だけに記憶されることはないから、あるデータが統合ＤＢ１５に記憶されているか否かで、そのデータが患者由来情報かどうかを容易に判断できる。換言すれば、統合ＤＢ１５と業務ＤＢ３５の双方のデータに関連をもたせつつ各ＤＢが記憶することで、データの由来が患者自身であるか又は医療スタッフであるかを明確化している。このような取扱いは、データ管理の責任分担の明確化のみならず、厳格な情報管理の要請に応え得るものである。

したがって、医療情報システム１では、患者データを取り扱うシステム基盤（認証、決済、ＰＨＲ管理等）を各業務システムから切り出して運用することができるとともに、患者がアプリから入力する患者データと医療機関のスタッフが業務システムから入力する患者データ、という二つの類似した情報を適切に管理することができる。とりわけ、データ突合の実現方式の観点、及び、患者・医療機関双方のセキュリティレベルを担保した上でのデータ取扱の観点から、二つの類似した情報を適切に管理することができる。よって、医療現場のクラウド化と患者への情報の還元とをともに実現し、今後も増大する医療費の削減に寄与するものと期待される。

５．実施形態２
図８及び図９を参照して、実施形態２に係る医療情報システム２及び医療情報システム２における情報連携について説明する。

医療情報システム２もまた、統合基盤１０及び複数の医療情報装置３０を含む。ただし、実施形態２では、統合基盤１０は、上述したＧＷ１１、認証部１２、管理部１３、決済部１４及び統合ＤＢ１５に加えて、認証コード取得部１６、連携用トークン取得部１７及び連携用トークン紐付け部１８を有している。また、医療情報装置３０は、取得部３１及び受付部３２のほかに、認証コード生成部３６、認証コード紐付け部３７及び連携用トークン生成部３８を含むが、名寄せ機能、つまり候補提示部３３及び名寄せ部３４を有していなくてもよい。以下、新たに加わった機能部を、連携手順と関連付けて説明する。

医療情報システム２における情報連携の概要について述べると、情報連携は大きく３つのフローから成り立つ。
（１）認証コードの取得（患者Ａから医療機関ａへの連携依頼）
（２）認証コードとユーザの紐付け（医療機関ａ側の同意）
（３）認証処理の実施と連携用アクセストークンの取得（患者Ａの意思確認と連携の実施）
以下、各フローを詳細に述べる。

（１）認証コードの取得
患者Ａはアプリ７０を用いて、医療機関ａの医療情報装置３０（認証コード取得部１６）に対して、アプリ連携のための認証コードの払い出しを求める（ステップＣ１）。認証コード取得部１６は、例えば、患者Ａのアプリ操作に基づいて医療情報装置３０から認証コードを取得するＡＰＩ（Application Programming Interface）として実装される。

認証コード取得部１６は、医療情報装置３０の認証コード生成部３６に対して認証コードの払い出しを求める（ステップＣ２）。認証コード生成部３６は、アプリ７０と医療情報装置３０との間だけで有効な、アプリ固有の有効期限のある認証コードを払い出す（ステップＣ３）。併せて、認証コード生成部３６は、認証コードの払出し結果をデータベース（例えば業務ＤＢ３５）に保存する。

統合基盤１０の認証コード取得部１６は、医療情報装置３０から受領した認証コードをアプリ７０に送信する（ステップＣ４）。このようにして払い出された認証コードは、アプリ７０の画面に表示される。ここで、アプリ固有の認証コードは、一意性を確保するのに十分な文字列、もしくはＱＲコード（登録商標）等のバーコードで表現されてよいが、これらに限られない。

（２）認証コードとユーザの紐付け
患者Ａは、アプリ７０において受け取った認証コードを医療機関ａのスタッフに提示する。医療機関ａのスタッフは、医療情報装置３０に記録された認証コードを確認し、本人確認を実施した後、医療情報装置３０に記録されている患者Ａに対して当該認証コードを関連付ける（紐付ける）べく指示する。認証コード紐付け部３７は、スタッフ操作に応じた認証コードの紐付けを実行する（ステップＤ１）。かかるスタッフ操作は、連携処理に対する医療機関ａの同意又は許可としての意義をも有する。

そして、認証コード紐付け部３７は、上記の関連付けが完了した旨を例えば医療情報装置３０のディスプレイに表示することで、医療機関ａのスタッフに知らせる（ステップＤ２）。そして、スタッフは、関連付けの完了を患者Ａに通知する。併せて、認証コード紐付け部３７は、アプリ７０に関連付けの完了を通知することとしてもよい。

（３）認証処理の実施と連携用アクセストークンの取得
患者Ａは、上記（２）の作業後、認証コードを用いて連携処理を実施する。かかる患者操作は、連携処理に対する患者Ａの最終的な意思確認又は同意としての意義をも有する。具体的には、アプリ７０は、患者Ａの操作に基づいて、統合基盤１０における連携用ＡＰＩ、つまり連携用トークン取得部１７を呼び出す（ステップＥ１）。

連携用トークン取得部１７は、医療情報装置３０における連携用ＡＰＩ、つまり連携用トークン生成部３８を呼び出す（ステップＥ２）。統合基盤１０のリクエストには、患者Ａの認証コードが含まれている。

連携用トークン生成部３８は、受け取った認証コードに対応するユーザ（患者）を抽出し（ステップＥ３）、抽出したユーザの患者情報にアクセスするための固有のアクセストークン（連携用アクセストークン）を払い出す（ステップＥ４）。統合基盤１０（連携用トークン取得部１７）が連携用アクセストークンを受け取ると、連携用トークン紐付け部１８は、統合基盤１０上の患者Ａの患者情報（ＩＤ情報）と連携用アクセストークンを紐付ける（ステップＥ５）。

かかる紐付け作業を完了すると、連携用トークン紐付け部１８は、アプリ７０に紐付け処理の完了を通知する（ステップＥ６）。かかる通知が例えばアプリ７０中に表示されることで、患者Ａは、連携処理の完了を知ることができる。

このように、実施形態２では、患者Ａはアプリ７０を介して、医療情報装置３０との連携依頼を出し、医療機関ａのスタッフによる連携許可を経て、統合基盤１０と医療情報装置３０との紐付けが統合基盤１０に記録される。つまり、患者Ａの情報を医療機関ａ側の情報と相互に結びつけるために、患者Ａ・医療機関ａの双方の同意を必要としている。認証コードの払い出し、アクセス許可、およびアクセストークンの払い出しには既存の標準化された認証連携技術を用い、統合基盤１０では、その認証連携技術を前提に患者データとアクセストークンの紐付けを行うため、既存のシステムと連携しやすいという利点がある。

以上、本発明の代表的な実施形態について説明したが、本発明はこれらに限定されるものではなく、種々の設計変更が可能であり、それらも本発明に含まれる。例えば、医療情報システムには、名寄せ機能を有する医療情報装置と、名寄せ機能を有しない医療情報装置とが、混在していてもよく、統合基盤は、医療情報装置の特性に応じたサービス（機能）を提供することができる。

１・・・医療情報システム、
１０・・・統合基盤、
１１・・・ゲートウェイ（ＧＷ）、
１２・・・認証部、
１３・・・アカウント管理部、
１４・・・決済部、
１５・・・統合データベース（ＤＢ）、
３０・・・医療情報装置、
３１・・・取得部、
３２・・・受付部、
３３・・・候補提示部、
３４・・・名寄せ部、
３５・・・業務データベース（ＤＢ）、
７０・・・患者端末（アプリ）。

Claims (6)

1. 複数の医療情報装置と、前記複数の医療情報装置のそれぞれ及び患者端末の間に介在する統合基盤と、を含む医療情報システムであって、
   前記統合基盤は、
   患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースと、
   前記第１の患者データが前記第１のデータベースに登録されると、前記第１の患者データを前記複数の医療情報装置に対して公開する管理部と、を含み、
   前記複数の医療情報装置のそれぞれは、
   患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶する第２のデータベースと、
   前記統合基盤において公開された前記第１の患者データを取得し、前記第２のデータベースに保存する取得部と、
   前記患者端末からアクセスを受け付ける受付部と、
   前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、当該第１の患者データに対して、前記スタッフにより選定された特定の患者に関する前記医療記録を紐付ける名寄せ部と、を含み、
   前記複数の医療情報装置のそれぞれは、前記スタッフに前記特定の患者を選定させるべく、候補の一覧を表示させる候補提示部を更に含むこと、
   を特徴とする医療情報システム。
2. 前記第１の患者データ及び前記第２の患者データはそれぞれ、少なくとも氏名、性別及び生年月日を含み、
   前記候補提示部は、前記氏名、前記性別及び前記生年月日のうち少なくとも１つにおいて前記第１の患者データと部分一致する前記第２の患者データに係る患者を前記候補として選び出すこと、
   を特徴とする請求項１に記載の医療情報システム。
3. 患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースを含む統合基盤を介して患者端末からアクセスされる医療情報装置であって、
   患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶する第２のデータベースと、
   前記統合基盤において登録及び公開された前記第１の患者データを取得し、前記第２のデータベースに保存する取得部と、
   前記患者端末からアクセスを受け付ける受付部と、
   前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、当該第１の患者データに対して、前記スタッフにより選定された特定の患者に関する前記医療記録を紐付ける名寄せ部と、
   を含み、
   前記スタッフに前記特定の患者を選定させるべく、候補の一覧を表示させる候補提示部を更に含むこと、
   を特徴とする医療情報装置。
4. 患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースをそれぞれ含む複数の医療情報装置と、
   前記複数の医療情報装置のそれぞれ及び患者端末の間に介在して、患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶する第２のデータベースを含む統合基盤と、
   を含む医療情報システムにおける前記医療情報装置に対して、
   前記統合基盤において登録及び公開された前記第１の患者データを取得して、前記第２のデータベースに保存し、
   前記患者端末からアクセスを受け付け、
   前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、前記スタッフに特定の患者を選定させるべく候補の一覧を表示させ、当該第１の患者データに対して、前記スタッフにより選定された特定の患者に関する前記医療記録を紐付ける
   手順を実行させる医療情報システムの制御方法。
5. 患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースをそれぞれ含む複数の医療情報装置と、
   前記複数の医療情報装置のそれぞれ及び患者端末の間に介在して、患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶する第２のデータベースを含む統合基盤と、
   を含む医療情報システムにおける前記医療情報装置に対して、
   前記統合基盤において登録及び公開された前記第１の患者データを取得して、前記第２のデータベースに保存し、
   前記患者端末からアクセスを受け付け、
   前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、前記スタッフに特定の患者を選定させるべく候補の一覧を表示させ、当該第１の患者データに対して、前記スタッフにより選定された特定の患者に関する前記医療記録を紐付ける
   手順を実行するための制御プログラム。
6. 患者ごとに前記患者端末を介して入力された第１の患者データを記憶する第１のデータベースをそれぞれ含む複数の医療情報装置と、
   前記複数の医療情報装置のそれぞれ及び患者端末の間に介在して、患者ごとに医療機関のスタッフを介して入力された第２の患者データ及び医療記録を記憶するとともに、前記統合基盤において登録及び公開された前記第１の患者データを取得して、前記第２のデータベースに保存する第２のデータベースを含む統合基盤と、
   を含む医療情報システムにおける前記医療情報装置の表示装置に対して、
   前記患者端末から受け付けたアクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データが前記医療記録と紐付けられていない場合に、前記アクセスに係る患者に関する前記第１の患者データと所定の関連性を有する前記第２の患者データに係る患者の一覧を画面表示させ、
   前記一覧の中から前記スタッフにより選定された特定の患者に関する前記医療記録を、前記アクセスに係る患者に関して前記第２のデータベースに保存された前記第１の患者データに紐付ける
   手順を実行させる医療情報システムの制御方法。

Images