JP6957904B2 - 情報処理システム、情報処理装置及びプログラム - Google Patents

Description

本発明は、情報処理システム、情報処理装置及びプログラムに関する。

従来、複数の医療機関等が、患者に係るデータとして、カルテ、画像データ（Ｘ線写真、ＭＲＩ（Magnetic Resonance Imaging）画像等）、処方箋データ等を、ネットワークを介したサーバを用いて共有する技術が既に知られている（例えば特許文献１）。また、患者データにアクセスするには、パスワードで認証を行うことにより、セキュリティを確保する技術が既に知られている（例えば特許文献２）。

しかしながら、従来の技術では、患者は、医療機関ごとに診察券が必要な場合があり、多数の医療機関を受診する場合は診察券の管理が困難となる。また、パスワードによる認証は、高齢者等の場合パスワードを忘れてしまうリスクもあり、患者データにアクセスできなくなるおそれもある。

本発明は、上記の点に鑑みてなされたものであって、クラウド環境に患者と一意に紐付けされた暗号化データを保持することで、データの消失を防ぎセキュリティを向上させることを目的とする。

そこで上記課題を解決するため、情報処理システムは、ユーザに使用される複数の端末を含み、前記複数の端末において共通して使用できる標準データを記憶する記憶部と、前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行部と、前記キーを用いて前記標準データへのアクセスを許可する許可部と、前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿部とを有する。

複数の医療機関を利用する際、クラウド環境に患者と一意に紐付けされた暗号化データを保持することで、データの消失を防ぎセキュリティを向上させることができる。

本発明の実施の形態における情報処理システム４０００の構成例を示す図である。 本発明の実施の形態におけるサーバ２００１のハードウェア構成例を示す図である。 本発明の実施の形態におけるクラウド２０００の機能構成例を示す図である。 本発明の実施の形態におけるサーバ１００１の機能構成例を示す図である。 本発明の実施の形態における病院固有患者データを標準患者データへ変換する処理手順の一例を説明するためのシーケンス図である。 本発明の実施の形態における病院固有患者データテーブルの一例を示す図である。 本発明の実施の形態における標準患者データテーブルの一例を示す図である。 本発明の実施の形態における病院番号テーブルの一例を示す図である。 本発明の実施の形態における標準患者データを病院固有患者データへ変換する処理手順の一例を説明するためのシーケンス図である。 本発明の実施の形態におけるチケット発行の処理手順の一例を説明するためのシーケンス図である。 本発明の実施の形態におけるチケットによって標準患者データをダウンロードする処理手順の一例を説明するためのシーケンス図である。 本発明の実施の形態におけるチケットによって標準患者データをアップロードする処理手順の一例を説明するためのシーケンス図である。 本発明の実施の形態におけるチケットのアクセス権の一例を示す図である。 本発明の実施の形態における転院時の処理手順の一例を説明するためのシーケンス図である。 本発明の実施の形態における調剤時の処方箋作成に関する処理手順の一例を説明するためのシーケンス図である。 本発明の実施の形態における生体情報を登録する処理手順の一例を説明するためのシーケンス図である。 本発明の実施の形態における生体認証テーブルの一例を示す図である。 本発明の実施の形態における生体認証によるダウンロードの処理手順の一例を説明するためのシーケンス図である。

以下、図面に基づいて本発明の本発明の実施の形態を説明する。

図１は、本発明の実施の形態における情報処理システム４０００の構成例を示す図である。図１において、情報処理システム４０００は、病院Ａ１０００ａ、病院Ｂ１０００ｂ、調剤薬局Ｃ１０００ｃ、患者自宅Ｄ１０００ｄ、クラウド２０００及び広域ネットワーク３０００を含む。病院Ａ１０００ａは、サーバ１００１ａ、端末１００２ａ及びファイアウォール１００３ａを含む。病院Ｂ１０００ｂは、サーバ１００１ｂ、端末１００２ｂ及びファイアウォール１００３ｂを含む。調剤薬局Ｃ１０００ｃは、端末１００２ｃ及びファイアウォール１００３ｃを含む。患者自宅Ｄ１０００ｄは、端末１００２ｄ及びファイアウォール１００３ｄを含む。クラウド２０００は、サーバ２００１ａ、サーバ２００１ｂ及びサーバ２００１ｃを含む。

病院Ａ１０００ａ、病院Ｂ１０００ｂ、調剤薬局Ｃ１０００ｃ及び患者自宅Ｄ１０００ｄは、ＬＡＮ（Local Area Network）等でそれぞれの施設内で相互に接続されたサーバ１００１ａ、サーバ１００１ｂ、端末１００２ａ〜ｄ、ファイアウォール１００３ａ〜ｄ等を含む、オンプレミス環境である。オンプレミス環境とは、ユーザ自身が管理している施設内に、情報処理システムを導入、設置して運用する環境のことをいう。

クラウド２０００は、広域ネットワーク３０００と接続しているサーバコンピュータ群である。クラウド２０００は、サーバ２００１ａ〜ｃ等複数のサーバコンピュータから構成されており、サーバ１００１ａ、サーバ１００１ｂ、端末１００２ａ〜ｄ等と通信を行い、医療情報に関する処理を行う情報処理装置である。これら施設は、病院、診療所、検査機関又は調剤薬局等が想定される。ユーザは、医師、看護師、医療事務又は会計事務の担当者等の病院関係者、患者本人、調剤薬局の薬剤師、検査機関の検査技師又は事務担当者等が想定される。

広域ネットワーク３０００は、例えば、インターネットであり、公開されたネットワークである。広域ネットワーク３０００は、専用回線ではなく、公衆回線であるため、セキュリティ対策をしない場合、改ざん、なりすまし、盗聴等の脅威を受ける可能性が有る。

サーバ１００１ａ、サーバ１００１ｂ（以下、それぞれを区別しない場合「サーバ１００１」という。）は、サーバコンピュータである。サーバ１００１は、サーバ２００１ａ〜ｃと通信を行い、ユーザとの入出力に関する処理及び医療情報に関する処理を行う。

端末１００２ａ〜ｄ（以下、それぞれを区別しない場合「端末１００２」という。）は、例えば、ＰＣ（Personal Computer）、スマートフォン等の端末装置である。端末１００２は、本実施形態においては、サーバ１００１と同様の機能を有する。

ファイアウォール１００３ａ〜ｄ（以下、それぞれを区別しない場合「ファイアウォール１００３」という。）は、広域ネットワーク３０００からのセキュリティの脅威から、病院Ａ１０００ａ、病院Ｂ１０００ｂ、調剤薬局Ｃ１０００ｃ又は患者自宅Ｄ１０００ｄ内に設置されるネットワークを守るために設置される。

サーバ２００１ａ〜ｃは（以下、それぞれを区別しない場合「サーバ２００１」という。）、クラウド２０００に含まれるサーバコンピュータである。サーバ２００１は、クラウド２０００に対して要求される医療情報に関する処理を行う。

図２は、本発明の実施の形態におけるサーバ２００１のハードウェア構成例を示す図である。図２のサーバ２００１は、それぞれ相互に接続されているＣＰＵ（Central Processing Unit）２１０１、ネットワークインタフェース２１０２、入出力インタフェース２１０３、補助記憶装置２１０４及びメモリ装置２１０５等を有する。

サーバ２００１での処理を実現するプログラムは、補助記憶装置２１０４に格納される。補助記憶装置２１０４は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置２１０５は、プログラムの起動指示があった場合に、補助記憶装置２１０４からプログラムを読み出して格納する。ＣＰＵ２１０１は、メモリ装置２１０５に格納されたプログラムに従ってサーバ２００１に係る機能を実行する。

ネットワークインタフェース２１０２は、サーバ１００１及び端末１００２等と通信を行うための有線又は無線のインタフェースである。

入出力インタフェース２１０３は、ＵＳＢ（Universal Serial Bus）機器、ハードウェアキー、状態通知用ＬＥＤ、液晶ディスプレイ等の様々な入出力装置との接続を行うためのインタフェースである。

なお、サーバ１００１、端末１００２も図２と同様のハードウェア構成を有していてもよい。

図３は、本発明の実施の形態におけるクラウド２０００の機能構成例を示す図である。当該機能は、１または２以上のサーバ２００１によって実現される。図３に示されるクラウド２０００は、標準患者データ制御部２０１、標準患者データ蓄積部２０２、病院番号蓄積部２０３、生体情報蓄積部２０４及びチケット発行認証部２０５を有する。これら各部は、サーバ２００１にインストールされた１以上のプログラムがＣＰＵ２１０１に実行させる処理により実現される。また、標準患者データ蓄積部２０２、病院番号蓄積部２０３及び生体情報蓄積部２０４は、さらに補助記憶装置２１０４又はメモリ装置２１０５等を用いて実現可能である。

標準患者データ制御部２０１は、病院Ａ１０００ａ、病院Ｂ１０００ｂ、調剤薬局Ｃ又は患者自宅Ｄ等において共通に使用可能である標準患者データに関する処理等を行う。また、標準患者データ制御部２０１は、病院Ａ１０００ａ又は病院Ｂ１０００ｂそれぞれに固有のデータである病院固有患者データと標準患者データの変換処理、サーバ１００１又は端末１００２と通信を行う。

標準患者データ蓄積部２０２は、標準患者データを記憶する機能を有する。また、標準患者データ蓄積部２０２は、標準患者データ制御部２０１からの制御に基づき、標準患者データの書込み又は読出しを行う。

病院番号蓄積部２０３は、病院に関する情報を記憶する機能を有する。また、病院番号蓄積部２０３は、標準患者データ制御部２０１からの制御に基づき、病院に関する情報の書込み又は読出しを行う。当該情報には、病院を一意に指定するＩＤが含まれる。

生体情報蓄積部２０４は、生体情報を記憶する機能を有する。また、生体情報蓄積部２０４は、標準患者データ制御部２０１からの制御に基づき、生体情報の書込み、読出し又は照合を行う。当該情報には、患者を一意に指定するＩＤが含まれる。

チケット発行認証部２０５は、情報処理システム４０００を使用するユーザの認証に関する処理を行う。ユーザには、医療関係者、調剤薬局、患者等が含まれる。また、チケット発行認証部２０５は、情報処理システム４０００において取り扱うデータへのアクセス権等に係るチケット（詳細は後述）の発行を行う。

図４は、本発明の実施の形態におけるサーバ１００１の機能構成例を示す図である。端末１００２も図４と同様の機能構成を有してもよい。

病院固有患者データ制御部１０１は、病院Ａ１０００ａ、病院Ｂ１０００ｂ、調剤薬局Ｃ１０００ｃ又は患者自宅Ｄ１０００ｄ等においてそれぞれに固有のデータである病院固有患者データに関する処理等を行う。また、病院固有患者データ制御部１０１は、ユーザの入出力処理を行い、クラウド２０００と通信を行う。

病院固有患者データ蓄積部１０２は、病院固有患者データ制御部１０１からの制御に基づき、病院固有患者データの書込み又は読出しを行う。

チケット入出力部１０３は、チケット発行認証部２０５が発行するチケットの入出力を行う。

処方箋制御部１０４は、クラウド２０００と通信を行って、処方箋の作成等の処理を行う。

生体認証制御部１０５は、ユーザから生体情報の入力を受け、クラウド２０００と通信を行って、生体情報の登録又は登録済の生体情報との照合に関する処理を行う。

以下、情報処理システム４０００において実行される処理手順の一例について説明する。

図５は、本発明の実施の形態における病院固有患者データを標準患者データへ変換する処理手順の一例を説明するためのシーケンス図である。病院固有患者データを標準患者データへ変換することにより、サーバ１００１又は端末１００２は、標準患者データを共通に使用できる。図５に示されるシーケンスでは、ユーザは医療関係者であり、ユーザが病院固有患者データを更新する際に、クラウド２０００は、対応する標準患者データを更新する。なお、ユーザは、医療関係者に限られず、患者本人、調剤薬局の薬剤師、検査機関の検査技師又は事務担当者等であってもよい。

ステップＳ１００において、ユーザは、データ更新要求を病院固有患者データ制御部１０１に入力する。

続いて、病院固有患者データ制御部１０１は、病院固有患者データ蓄積部１０２から、病院固有患者データを読み出す。破線で示されるように、病院固有患者データ制御部１０１は、病院固有患者データ蓄積部１０２から、病院固有患者データを受信する。図６は、本発明の実施の形態における病院固有患者データテーブルの一例を示す図である。図６に示されるように、病院固有患者データテーブルには、患者ごとに、「ユーザＩＤ」、「患者名」、「住所」、「健康保険証番号」、「診療履歴」、「処方箋履歴」、「Ｘ線画像群」、「ＭＲＩ（Magnetic Resonance Imaging）画像群」が記録される。「ユーザＩＤ」は、当該病院内で一意に患者を識別するＩＤである。「患者名」は、患者の氏名である。「健康保険証番号」は、患者の健康保険証の番号である。「診療履歴」は、患者の過去の診療記録である。例えば、患者が過去に受診した科、診断された病名等が含まれる。「処方箋履歴」は、患者が過去に受領した処方箋が含まれる。「Ｘ線画像群」は、患者を過去に撮影したＸ線画像の集合である。「ＭＲＩ画像群」は、患者を過去に撮影したＭＲＩ画像の集合である。

病院固有患者データ制御部１０１は、病院固有患者データ蓄積部１０２から、病院固有患者データを読み出すと（Ｓ１０１）、ステップＳ１００においてユーザから入力されたデータに基づいて、当該病院固有患者データを更新する。例えば、患者のＸ線画像を新たに撮影した場合、当該Ｘ線画像を当該病院固有患者データの「Ｘ線画像群」に追加する（Ｓ１０２）。

続いて、病院固有患者データ制御部１０１は、病院固有患者データ蓄積部１０２に、更新された病院固有患者データを書き込む（Ｓ１０３）。破線で示されるように、病院固有患者データ制御部１０１は、病院固有患者データ蓄積部１０２から、書込み結果の完了通知を受けてもよい。

ステップＳ１０４において、病院固有患者データ制御部１０１は、標準患者データ制御部２０１に、更新された病院固有患者データをアップロードする。当該アップロードには、病院名に関する情報もさらに含まれる。

続いて、標準患者データ制御部２０１は、当該病院固有患者データを、標準患者データへ変換する（Ｓ１０５）。図７は、本発明の実施の形態における標準患者データテーブルの一例を示す図である。図７に示されるように、標準患者データテーブルには、患者ごとに、「患者ＩＤ」、「病院番号」、「ユーザＩＤ」、「ＰＷ」、「患者名」、「住所」、「健康保険証番号」、「病名」、「最終診察日」、「処方箋」、「Ｘ線」、「ＭＲＩ」が記録される。「患者ＩＤ」は、標準患者データを一意に識別するＩＤである。「患者ＩＤ」により、患者も一意に識別可能である。「病院番号」は、病院を一意に識別するＩＤである。「ユーザＩＤ」は、「病院番号」によって識別される病院内で、一意に患者を識別するＩＤである。「ＰＷ」は、当該標準患者データを利用する際の認証時に入力するパスワードである。「患者名」は、患者の氏名である。「住所」は、患者の住所である。「健康保険証番号」は、患者の健康保険証番号である。「病名」は、現在の患者の病名である。「病名」は、病名を複数含んでもよい。「最終診察日」は、患者が最後に診察を受けた年月日である。「処方箋」は、患者が受領した最新の処方箋である。「Ｘ線」は、患者が撮影された最新のＸ線画像である。「ＭＲＩ」は、患者が撮影された最新のＭＲＩ画像である。

標準患者データ制御部２０１は、当該病院固有患者データの項目に基づいて、対応する標準患者データの各項目を入力する。例えば、病院固有患者データの「ユーザＩＤ」「患者名」「住所」「健康保険証番号」は、標準患者データの同一の項目名のデータとしてそれぞれ入力される。また、病院固有患者データの「診療履歴」に基づく当該患者の現在の病名が、患者データの「病名」に入力される。また、病院固有患者データの「処方箋履歴」のうち最新の処方箋が、標準患者データの「処方箋」に入力される。同様に、標準患者データ制御部２０１は、病院固有患者データの「Ｘ線画像群」「ＭＲＩ画像群」のうち最新の画像を、標準患者データの「Ｘ線」「ＭＲＩ」にそれぞれ入力する。なお、標準患者データのうち、「病院番号」については、病院固有患者データから入力されない。

続いて、標準患者データ制御部２０１は、ステップＳ１０４で受信した、病院名に関する情報に基づいて、病院番号蓄積部２０３から病院番号を読出し、標準患者データの「病院番号」に入力する（Ｓ１０６）。破線で示されるように、標準患者データ制御部２０１は、病院番号蓄積部２０３から、病院番号を受信する。図８は、本発明の実施の形態における病院番号テーブルの一例を示す図である。図８に示されるように、病院番号テーブルには、「病院番号」、「病院名」、「病院住所」が記録される。「病院番号」は、病院を一意に識別するＩＤである。「病院名」は、医療機関の名称である。「病院住所」は、医療機関の住所である。病院番号テーブルは、予め作成されたものを用いてよい。

標準患者データ制御部２０１は、標準患者データ蓄積部２０２に、当該標準患者データを書き込む（Ｓ１０７）。なお、標準患者データ制御部２０１は、当該標準患者データを暗号化して、標準患者データ蓄積部２０２に書き込んでもよい。破線で示されるように、書込み完了の通知が、標準患者データ制御部２０１及び病院固有患者データ制御部１０１を介して、ユーザに通知されてもよい。以上の手順で、病院固有患者データを標準患者データへ変換する処理手順が完了する。

図９は、本発明の実施の形態における標準患者データを病院固有患者データへ変換する処理手順の一例を説明するためのシーケンス図である。標準患者データを病院固有患者データへ変換することにより、当該病院において、データを参照できるようになる。図９に示されるシーケンスでは、ユーザは医療関係者であり、ユーザが病院固有患者データを取得する際に、クラウド２０００は、標準患者データを病院固有患者データへ変換する。なお、ユーザは、医療関係者に限られず、患者本人、調剤薬局の薬剤師、検査機関の検査技師又は事務担当者等であってもよい。

ステップＳ２００において、ユーザは、データ取得要求を病院固有患者データ制御部１０１に入力する。当該データ取得要求には、患者ＩＤが含まれる。

続いて、病院固有患者データ制御部１０１は、標準患者データ制御部２０１へダウンロードの通知を行う（Ｓ２０１）当該通知には、病院名に関する情報も含まれる。

続いて、標準患者データ制御部２０１は、ステップＳ２０１で受信した、病院名に関する情報に基づいて、病院番号蓄積部２０３から、病院番号を読み出す（Ｓ２０２）。破線で示されるように、標準患者データ制御部２０１は、病院番号蓄積部２０３から、病院番号を受信する。

続いて、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から標準患者データを読み出す（Ｓ２０３）。破線で示されるように、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から、標準患者データを受信する。当該標準患者データは、病院固有患者データへ変換される（Ｓ２０４）。標準患者データ制御部２０１は、当該標準患者データの項目に基づいて、対応する病院固有患者データの各項目を入力する。例えば、標準患者データの「ユーザＩＤ」「患者名」「住所」「健康保険証番号」は、病院固有患者データの同一の項目名のデータとしてそれぞれ入力される。また、標準患者データの「処方箋」が、病院固有患者データの「処方箋履歴」に入力される。同様に、標準患者データ制御部２０１は、標準患者データの「Ｘ線」「ＭＲＩ」の画像を、病院固有患者データの「Ｘ線画像群」「ＭＲＩ画像群」にそれぞれ入力する。このとき必要に応じて、標準患者データ制御部２０１は、当該標準患者データに含まれる病院番号と、ステップＳ２０２で読み出した病院番号とを照合して、照合の結果により、処理を続行するか否かを決定してもよい。

続いて、破線で示されるように、標準患者データ制御部２０１は、病院固有患者データ制御部１０１へ病院固有患者データを送信する。病院固有患者データ制御部１０１は、標準患者データ制御部２０１から受信した病院固有患者データを、病院固有患者データ蓄積部１０２に書き込む（Ｓ２０５）。破線で示されるように、書込み完了通知が、病院固有患者データ制御部１０１を介して、ユーザに通知されてもよい。以上の手順で、標準患者データを病院固有患者データへ変換する処理手順が完了する。

図１０は、本発明の実施の形態におけるチケット発行の処理手順の一例を説明するためのシーケンス図である。図１０に示されるシーケンスでは、ユーザは患者本人を想定するが、ユーザは、患者本人に限られず、医療関係者、調剤薬局の薬剤師、検査機関の検査技師又は事務担当者等であってもよい。図１０に示される各ステップにおいてユーザの入出力が行われる場合、ユーザの入出力インタフェースには、サーバ１００１又は端末１００２が用いられる。

ステップＳ３００において、ユーザは、認証要求を標準患者データ制御部２０１へ入力する。当該認証要求には、「患者ＩＤ」及び「ＰＷ」が含まれる。図１０に示されるステップにおいてユーザの入出力を伴う場合、ユーザの入出力インタフェースには、サーバ１００１又は端末１００２が用いられる。

続いて、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から、標準患者データを読み出す（Ｓ３０１）。破線で示されるように、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から、標準患者データを受信する。

続いて、標準患者データ制御部２０１は、ユーザからの認証要求及び標準患者データに基づいた認証をチケット発行認証部２０５にさせる（Ｓ３０２）。破線で示されるように、認証の結果は、標準患者データ制御部２０１を介して、ユーザへ通知される。

続いて、ユーザは、チケット発行要求を標準患者データ制御部２０１へ入力する（Ｓ３０３）。当該チケット発行要求に基づき、標準患者データ制御部２０１は、チケット発行をチケット発行認証部２０５に通知する（Ｓ３０４）。破線で示されるように、チケットは、標準患者データ制御部２０１を介して、サーバ１００１又は端末１００２のチケット入出力部１０３により、ユーザに取得される。

チケットとは、標準患者データにアクセスするための鍵となるデータである。情報処理システム４０００では、チケットで認証することにより、標準患者データの閲覧、ダウンロード又はアップロード等が可能になる。チケットには、標準患者データを識別する患者ＩＤが少なくとも含まれる。また、図５のステップＳ１０７にて、標準患者データが暗号化されて標準患者データ制御部２０１に書き込まれた場合に、チケットは、暗号化された標準患者データを復号する鍵となる機能を有する。さらに、チケットは、標準患者データを暗号化する鍵となる機能も有する。

また、チケットは、アクセス可能なデータの種別又は可能なデータ処理等を設定するアクセス権、及び生体認証データと関連付けられるチケットＩＤを有する（詳細は後述）。

チケット発行認証部２０５は、チケット発行要求に基づくチケットを発行し、標準患者データ制御部２０１及びチケット入出力部１０３を介して、ユーザに受領される。当該チケットの形態は、スマートフォン等の携帯端末又は記憶媒体等に記憶されるデータであってもよいし、ＱＲコード（登録商標）等が印刷された紙媒体であってもよい。

図１１は、本発明の実施の形態におけるチケットによる患者データをダウンロードする処理手順の一例を説明するためのシーケンス図である。図１１に示されるシーケンスでは、ユーザは患者本人を想定するが、図１０同様に、ユーザは、患者本人に限られない。また、図１１に示されるシーケンスで読み出される標準患者データは、チケットにより暗号化されて記録されているものとする。図１２に示される各ステップにおいてユーザの入出力が行われる場合、ユーザの入出力インタフェースには、サーバ１００１又は端末１００２が用いられる。

ステップＳ４００において、ユーザは、認証要求を標準患者データ制御部２０１へ入力する。当該認証要求には、「患者ＩＤ」及び「ＰＷ」が含まれる。

続いて、標準患者データ制御部２０１は、ユーザからの認証要求に基づいた認証をチケット発行認証部２０５にさせる（Ｓ４０１）。破線で示されるように、認証の結果は、標準患者データ制御部２０１を介して、ユーザへ通知される。認証の結果が、可であった場合は、ステップＳ４０２へ進み、不可であった場合は、シーケンスを終了する。当該認証は、例えば、第３者によるチケットの使用等のなりすまし行為を防止する。

ステップＳ４０２において、ユーザは、チケット読取りを要求する。当該チケット読取りの要求によって、図１０に示される手順により既に発行されたチケットが、チケット入出力部１０３に入力されてデータが取得され、当該データが標準患者データ制御部２０１へ送信される。チケット入出力部１０３は、チケットの形態に応じてデータを取得する。例えば、チケットの形態が、スマートフォン等の携帯端末又は記憶媒体等に記憶されるデータであった場合は、有線又は無線接続による通信等によってデータを読み取り、ＱＲコード等が印刷された紙媒体であった場合は、スキャナ又はカメラ等でデータを読み取る。

続いて、標準患者データ制御部２０１は、チケット読取りを行う（Ｓ４０３）。標準患者データ制御部２０１は、ステップＳ４０２で読取られたチケットのデータを取得する。破線で示されるように、読取り完了通知が、ユーザに通知されてもよい。

ステップＳ４０４において、ユーザは、ダウンロード要求を標準患者データ制御部２０１へ入力する。当該ダウンロード要求を受けて、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から、ステップＳ４０３でチケットから読み取った患者ＩＤに対応する標準患者データを読み出す（Ｓ４０５）。破線で示されるように、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から、標準患者データを読み出す。

続いて、標準患者データ制御部２０１は、暗号化されている標準患者データを、チケットを用いて復号する（Ｓ４０６）。続いて、標準患者データ制御部２０１は、病院番号蓄積部２０３から、復号した標準患者データの病院番号に基づいて病院名を読み出す（Ｓ４０７）。破線で示されるように、標準患者データは、標準患者データ制御部２０１を介して、ユーザに取得される。以上の手順で、チケットによる患者データダウンロードが完了する。

図１２は、本発明の実施の形態におけるチケットによる患者データをアップロードする処理手順の一例を説明するためのシーケンス図である。図１２に示されるシーケンスでは、ユーザは医療関係者を想定するが、ユーザは、医療関係者に限られない。図１２に示される各ステップにおいてユーザの入出力が行われる場合、ユーザの入出力インタフェースには、サーバ１００１又は端末１００２が用いられる。

ステップＳ５００からステップＳ５０３は、図１１のステップＳ４００からステップＳ４０３と同様である。ただし、Ｓ５００においては、ユーザの医療関係者は、「医療関係者ＩＤ」と「ＰＷ」を用いて、認証要求を行う。「医療関係者ＩＤ」は、「患者ＩＤ」と同様にチケット発行認証部２０５での認証に使用される。当該認証は、例えば、第３者によるチケットの使用等のなりすまし行為を防止する。また、ステップＳ５０２のチケット読取り要求に使用されるチケットは、医療関係者がアップロードする患者データに係る患者から当該チケットを受領したものである。

ステップＳ５０４において、ユーザは、アップロード要求を標準患者データ制御部２０１へ入力する。当該アップロード要求には、病院固有患者データの一部又は全部、及び病院名に関する情報が含まれる。

続いて、標準患者データ制御部２０１は、当該アップロード要求に含まれる病院名に関する情報に基づいて、病院番号蓄積部２０３から病院番号を読み出す（Ｓ５０５）。破線で示されるように、標準患者データ制御部２０１は、病院番号蓄積部２０３から病院番号を受信する。続いて、標準患者データ制御部２０１は、当該アップロード要求に含まれる病院固有患者データの一部又は全部を、ステップＳ５０３で読み取ったチケットに含まれる患者ＩＤに対応する標準患者データへ変換する（Ｓ５０６）。また、ステップＳ５０５で読み出した病院番号を標準患者データの項目へ入力する。

続いて、標準患者データ制御部２０１は、変換した標準患者データをステップＳ５０３で読み取ったチケットに含まれる暗号化鍵を用いて暗号化する（Ｓ５０７）。標準患者データ制御部２０１は、暗号化した標準患者データを標準患者データ蓄積部２０２へ書き込む（Ｓ５０８）。破線で示されるように、書込み完了の通知が、標準患者データ制御部２０１を介して、ユーザに通知されてもよい。以上の手順で、チケットによる患者データアップロードが完了する。

図１３は、本発明の実施の形態におけるチケットのアクセス権の一例を示す図である。図１１のステップＳ４０３及び図１２のステップＳ５０３において、標準患者データ制御部２０１は、チケット読取りを行う際に、当該チケットが有するアクセス権を確認する。図１３に示されるように、「アクセス権の種別」ごとに、「閲覧可能データ」、「ダウンロード可能データ」、「アップロード可能データ」が設定される。「アクセス権の種別」は、アクセス権の種別を識別する名称である。「閲覧可能データ」は、閲覧可能なデータ種別又はすべてのデータが閲覧不可であることが設定される。「ダウンロード可能データ」は、ダウンロード可能なデータ種別又はすべてのデータがダウンロード不可であることが設定される。「アップロード可能データ」は、アップロード可能なデータ種別又はすべてのデータがアップロード不可であることが設定される。

例えば、図１３に示される「フルアクセス」は、「閲覧可能データ」はすべてのデータが可能、「ダウンロード可能データ」はすべてのデータが可能、「アップロード可能データ」はすべてのデータが可能、のように設定されている。また、例えば、図１３に示される「リードオンリー」は、「閲覧可能データ」はすべてのデータが可能、「ダウンロード可能データ」はすべてのデータが可能、「アップロード可能データ」はすべてのデータに関して不可、が設定されている。また、例えば、図１３に示される「処方箋オンリー」は、「閲覧可能データ」は処方箋が可能、「ダウンロード可能データ」は処方箋が可能、「アップロード可能データ」はすべてのデータに関して不可、が設定されている。また、例えば、図１３に示される「画像アップロード」は、「閲覧可能データ」はすべてのデータが不可、「ダウンロード可能データ」はすべてのデータが不可、「アップロード可能データ」は画像データが可能、が設定されている。また、例えば、図１３に示される「会計処理」は、「閲覧可能データ」は会計データが可能、「ダウンロード可能データ」は会計データが可能、「アップロード可能データ」は会計データが可能、が設定されている。

すなわち、図１１のステップＳ４０３で読み取られるチケットは、少なくとも標準患者データがダウンロード可能であるアクセス権を有し、図１２のステップＳ５０３で読み取られるチケットは、少なくとも標準患者データがアップロード可能であるアクセス権を有する。

図１４は、本発明の実施の形態における転院時の処理手順の一例を説明するためのシーケンス図である。図１４に示されるシーケンスでは、ユーザは医療関係者を想定するが、ユーザは、医療関係者に限られない。また、図１４に示されるシーケンスで読み出される標準患者データは、チケットにより暗号化されて記録されているものとする。

ステップＳ６００において、ユーザは、転院処理要求を病院固有患者データ制御部１０１へ入力する。ステップＳ６００では、医療関係者が転院する患者から受領したチケットのデータが、チケット入出力部１０３により取得される。続いて、病院固有患者データ制御部１０１は、転院処理を標準患者データ制御部２０１へ通知する（Ｓ６０１）。転院処理要求には、チケットのデータ及び転院先の病院名に関する情報が含まれる。当該チケットは、少なくとも標準患者データがダウンロード可能及びアップロード可能であるアクセス権を有する。続いて、標準患者データ制御部２０１は、当該チケットの読取りを行う（Ｓ６０２）。ステップＳ６０２におけるチケットの読取りは、転院処理要求に含まれるデータに基づいて行われる。

ステップＳ６０３において、標準患者データ制御部２０１は、当該チケットに含まれる患者ＩＤに対応する標準患者データを標準患者データ蓄積部２０２から読み出す。破線で示されるように、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から、標準患者データを受信する。続いて、読み出された標準患者データは、チケットに含まれる復号鍵によって復号される（Ｓ６０４）。続いて、転院先の病院名に関する情報に基づいて、標準患者データ制御部２０１は、病院番号蓄積部２０３から、転院先の病院番号を読み出す（Ｓ６０５）。

ステップＳ６０６において、標準患者データ制御部２０１は、ステップＳ６０１で通知された転院先の病院名に関する情報に基づいて、標準患者データの病院番号をステップＳ６０５で読み出した病院番号に変更する。これにより、当該標準患者データが転院先の病院に関連付けられる。

ここで、転院処理が完了して、クラウド２０００のデータ保持容量を削減する場合、ステップＳ６０７に進み、標準患者データ制御部２０１は、当該標準患者データを標準患者データ蓄積部２０２から削除する。ステップＳ６０７において、破線で示されるように、標準患者データ制御部２０１は、標準患者データを図９に示される手順で病院固有患者データに変換して、病院固有患者データ制御部１０１に送信後、当該標準患者データを削除する。病院固有患者データ制御部１０１は、当該病院固有患者データを病院固有患者データ蓄積部１０２に書き込む（Ｓ６０８）。破線で示されるように、書込み完了通知が、病院固有患者データ制御部１０１を介して、ユーザに通知されてもよい。以上の手順で、転院時の処理手順が完了する。

なお、図１４において、転院時の処理手順は一例であって、例えば、入院時の処理手順等を図１４に示されるシーケンスにて処理してもよい。すなわち、入院処理の開始時に標準患者データがアップロードされ、当該入院処理が完了して、標準患者データが病院固有患者データに変換されて保存された場合、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から当該標準患者データを削除してもよい。当該削除により、クラウド環境におけるデータの過剰な蓄積を防ぐことができる。

図１５は、本発明の実施の形態における調剤時の処方箋作成に関する処理手順の一例を説明するためのシーケンス図である。図１５に示されるシーケンスでは、ユーザは調剤薬局を想定するが、ユーザは、調剤薬局に限られない。また、図１５に示されるシーケンスで読み出される標準患者データは、チケットにより暗号化されて記録されているものとする。

ステップＳ７００において、ユーザは、処方箋ダウンロード要求を処方箋制御部１０４へ入力する。ステップＳ７００では、調剤薬局が処方箋を発行する患者から受領したチケットのデータが、チケット入出力部１０３により取得される。当該チケットは、少なくとも処方箋データがダウンロード可能及びアップロード可能であるアクセス権を有する。

ステップＳ７０１において、処方箋制御部１０４は、処方箋ダウンロードの通知を標準患者データ制御部２０１へ送信する。続いて、標準患者データ制御部２０１は、チケット読取りを行う（Ｓ７０２）。ステップＳ７０２におけるチケットの読取りは、処方箋ダウンロードに含まれるデータに基づいて行われる。

続いて、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から、標準患者データを読み出す（Ｓ７０３）。破線で示されるように、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から、標準患者データを受信する。続いて、読み出された標準患者データは、チケットに含まれる復号鍵によって復号される（Ｓ７０４）。

ステップＳ７０５において、標準患者データ制御部２０１は、復号された標準患者データに基づいて、処方箋を作成する。標準患者データには、図７に示されるように患者の最新の処方箋が含まれている。標準患者データ制御部２０１は、作成した処方箋を、処方箋制御部１０４へ送信する。ステップＳ７０５において、作成した処方箋を、処方箋制御部１０４へ送信した後、直ちに当該処方箋を削除してもよい。破線で示されるように、処方箋制御部１０４は、当該処方箋を受信すると、ユーザに処方箋を提供して調剤を完了すると共に、処方箋削除を標準患者データ制御部２０１に通知する（Ｓ７０６）。続いて、標準患者データ制御部２０１は、標準患者データに含まれる処方箋を削除する（Ｓ７０７）。ステップＳ７０５で処方箋が削除されている場合は、ステップＳ７０７は実行されない。破線で示されるように、削除完了通知が、処方箋制御部１０４に通知されてもよい。当該削除により、クラウド環境におけるデータの過剰な蓄積を防ぐことができる。以上の手順で、調剤時の処方箋作成に関する処理手順が完了する。

図１６は、本発明の実施の形態における生体情報を登録する処理手順の一例を説明するためのシーケンス図である。図１６に示されるシーケンスでは、ユーザは患者本人を想定する。

ステップＳ８００において、ユーザは生体情報読取り要求を生体認証制御部１０５へ入力する。当該生体情報読取り要求には、生体認証制御部１０５によって読み取られた、ユーザの生体情報が含まれる。ユーザの生体情報は、例えば、指紋データ、静脈認証データ等である。破線で示されるように、読取り完了通知が、ユーザに通知されてもよい。

続いて、ユーザは、生体情報登録要求を生体認証制御部１０５へ入力する（Ｓ８０１）。生体情報登録要求には、ユーザの入力或いはチケット入出力部１０３によるチケット読み取りに基づくチケットＩＤ及び患者ＩＤが含まれる。生体認証制御部１０５は、ステップＳ８００で取得されたユーザの生体情報、チケットＩＤ及び患者ＩＤを含む生体情報登録の通知を標準患者データ制御部２０１へ送信する（Ｓ８０２）。

ステップＳ８０３において、標準患者データ制御部２０１は、生体情報登録を生体情報蓄積部２０４に対して行う。図１７は、本発明の実施の形態における生体認証テーブルの一例を示す図である。図１７に示される生体認証テーブルは、生体情報蓄積部２０４に記憶され、「生体認証データ」、「チケットＩＤ」及び「患者ＩＤ」が、ひとつのレコードの要素である。「生体認証データ」は、指紋データ、静脈認証データ等の生体情報を示すデータそのものである。「チケットＩＤ」は、チケットを一意に識別するＩＤであり、「生体認証データ」に関連付けられる「チケットＩＤ」が記憶される。例えば、図１０に示されるチケット発行の際、ユーザが生体情報を送付して「生体認証データ」を生成し、当該チケットと当該「生体認証データ」は関連付けられ、「チケットＩＤ」を含むチケットがユーザに発行される。「患者ＩＤ」は、患者を一意に識別するＩＤであり、「生体認証データ」に関連付けられる「患者ＩＤ」が記憶される。破線で示されるように、登録完了通知が、標準患者データ制御部２０１及び生体認証制御部１０５を介して、ユーザに通知されてもよい。以上の手順で、生体情報を登録する処理手順が完了する。

図１８は、本発明の実施の形態における生体認証によるダウンロードの処理手順の一例を説明するためのシーケンス図である。図１８に示されるシーケンスでは、ユーザは患者本人を想定する。また、図１８に示されるシーケンスで読み出される標準患者データは、チケットにより暗号化されて記録されているものとする。

ステップＳ９００において、ユーザは、生体情報及びチケットを使用するダウンロード要求を生体認証制御部１０５へ入力する。生体認証制御部１０５は、ユーザの生体情報を読み取り、チケット入出力部１０３は、チケットを読み取る。また、当該チケットは、少なくとも標準患者データのダウンロードが可能であるアクセス権を有する。続いて、生体認証制御部１０５は、生体情報及びチケットのデータを含むダウンロードの通知を標準患者データ制御部２０１へ送信する（Ｓ９０１）。続いて、標準患者データ制御部２０１は、チケット読取りを行う（Ｓ９０２）。ステップＳ９０２におけるチケットの読取りは、当該ダウンロードの通知に含まれるデータに基づいて行われる。

ステップＳ９０３において、標準患者データ制御部２０１は、生体情報及びチケット読取り結果に基づいた認証をチケット発行認証部２０５にさせる。例えば、チケット発行認証部２０５は、図１７に示される生体認証テーブルのレコードの「チケットＩＤ」及び「患者ＩＤ」と、チケット読取り結果による「チケットＩＤ」及び「患者ＩＤ」とを比較する。「チケットＩＤ」及び「患者ＩＤ」がそれぞれ一致した場合、チケット発行認証部２０５は、当該レコードに記録されている生体認証データと当該ダウンロードの通知に含まれる生体情報とを照合する。破線で示されるように、チケット発行認証部２０５は、当該照合が成功した場合、標準患者データ制御部２０１へ認証の成功を通知し、当該照合が失敗した場合、標準患者データ制御部２０１へ認証の失敗を通知してシーケンスを終了する。

ステップＳ９０４において、標準患者データ制御部２０１は、当該チケットに含まれる患者ＩＤに対応する標準患者データを標準患者データ蓄積部２０２から読み出す。破線で示されるように、標準患者データ制御部２０１は、標準患者データ蓄積部２０２から、標準患者データを読み出す。続いて、読み出された標準患者データは、チケットに含まれる復号鍵によって復号される（Ｓ９０５）。破線で示されるように、復号された標準患者データは、生体認証制御部１０５を介して、ユーザに通知される。以上の手順で、生体認証によるダウンロードの処理手順が完了する。

上述したように、本発明の実施の形態によれば、情報処理システム４０００は、患者に一意に紐付けられた患者データの利用に係るチケットを発行して使用することで、クラウド２０００にセキュリティが確保された患者データの保存が可能となる。また、情報処理システム４０００は、チケットに関連付けられた生体情報を用いる認証によって、セキュリティが確保された簡便なアクセスが可能となる。その結果、複数の医療機関を利用する際、クラウド環境に患者と一意に紐付けられた暗号化データを保持することで、データの消失を防ぎセキュリティを向上させることができる。

なお、本発明の実施の形態において、サーバ１００１又は端末１００２は、複数の端末の一例である。標準患者データは、標準データの一例である。標準患者データ蓄積部２０２、病院番号蓄積部２０３又は生体情報蓄積部２０４は、記憶部の一例である。チケットは、キーの一例である。チケット発行認証部２０５は、発行部の一例である。標準患者データ制御部２０１は、許可部の一例である。標準患者データ制御部２０１は、秘匿部の一例である。データ種別は、アクセス対象のデータの一例である。アクセス権の種別は、アクセス種別の一例である。クラウド２０００は、装置群の一例である。病院固有患者データ制御部１０１は、送受信部の一例である。病院固有患者データは、個別データの一例である。

なお、本発明の実施の形態は本発明の範囲を限定するものではなく、クラウド２０００が有する機能の一部をサーバ１００１又は端末１００２が有してもよい。また、本発明の実施の形態で説明した情報処理システム４０００の構成は一例であり、情報処理システム４０００は、様々なシステム構成を有してもよい。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０００ａ 病院Ａ
１０００ｂ 病院Ｂ
１０００ｃ 調剤薬局Ｃ
１０００ｄ 患者自宅Ｄ
１００１ａ、ｂ サーバ
１００２ａ〜ｄ 端末
１００３ａ〜ｄ ファイアウォール
２０００ クラウド
２００１ａ〜ｃ サーバ
３０００ 広域ネットワーク
４０００ 情報処理システム
２１０１ ＣＰＵ
２１０２ ネットワークインタフェース
２１０３ 入出力インタフェース
２１０４ 補助記憶装置
２１０５ メモリ装置
２０１ 標準患者データ制御部
２０２ 標準患者データ蓄積部
２０３ 病院番号蓄積部
２０４ 生体情報蓄積部
２０５ 認証部
１０１ 病院固有患者データ制御部
１０２ 病院固有患者データ蓄積部
１０３ チケット入出力部
１０４ 処方箋制御部
１０５ 生体認証制御部

特開２００３−３３７８５８号公報 特開２００１−２９７１５３号公報

Claims (7)

1. ユーザに使用される複数の端末を含む情報処理システムであって、
   前記複数の端末において共通して使用できる標準データを記憶する記憶部と、
   前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行部と、
   前記キーを用いて前記標準データへのアクセスを許可する許可部と、
   前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿部とを有し、
   前記複数の端末のうちいずれかの端末が、前記記憶部に所定の標準データを記憶させた後、所定の条件により前記所定の標準データが前記記憶部から削除され、
   前記所定の標準データは、病院を識別する情報を含み、前記所定の条件は、前記所定の標準データが前記複数の端末のうち前記病院に関連付けられる端末において参照される個別データに変換されて前記病院に関連付けられる端末に送信されることである情報処理システム。
2. 前記所定の標準データは、処方箋に関する情報を含み、前記発行部が前記所定の標準データに基づいて作成した処方箋が前記複数の端末のうち前記処方箋を要求した端末に送信された後、前記発行部は前記作成した処方箋を削除する請求項１記載の情報処理システム。
3. 前記許可部は、前記キーによる標準データへのアクセスを、アクセス対象のデータ及びアクセス種別に基づいて許可する請求項１記載の情報処理システム。
4. 前記許可部は、前記キーによる標準データへのアクセスを、前記キーと関連付けられた生体情報に基づいて許可を行う請求項１記載の情報処理システム。
5. ユーザに使用される複数の端末と、前記複数の端末と接続される情報処理装置で実行可能なプログラムとを含む情報処理システムであって、
   前記端末は、
   個別データを前記情報処理装置へ送信又は前記情報処理装置から受信する送受信部を有し、
   前記プログラムは、
   前記個別データを前記複数の端末において共通して使用できる標準データに変換して、前記標準データを記憶させる制御手順と、
   前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行手順と、
   前記キーを用いて前記標準データへのアクセスを許可する許可手順と、
   前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿手順とを情報処理装置に実行させ、
   前記複数の端末のうちいずれかの端末が、前記制御手順により所定の標準データを記憶させた後、所定の条件により前記所定の標準データが削除され、
   前記所定の標準データは、病院を識別する情報を含み、前記所定の条件は、前記所定の標準データが前記複数の端末のうち前記病院に関連付けられる端末において参照される個別データに変換されて前記病院に関連付けられる端末に送信されることである情報処理システム。
6. ユーザに使用される複数の端末と接続される情報処理装置であって、
   前記複数の端末において共通して使用できる標準データを記憶する記憶部と、
   前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行部と、
   前記キーを用いて前記標準データへのアクセスを許可する許可部と、
   前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿部とを有し、
   前記複数の端末のうちいずれかの端末が、前記記憶部に所定の標準データを記憶させた後、所定の条件により前記所定の標準データが前記記憶部から削除され、
   前記所定の標準データは、病院を識別する情報を含み、前記所定の条件は、前記所定の標準データが前記複数の端末のうち前記病院に関連付けられる端末において参照される個別データに変換されて前記病院に関連付けられる端末に送信されることである情報処理装置。
7. ユーザに使用される複数の端末と接続される情報処理装置で実行可能なプログラムであって、
   前記複数の端末において共通して使用できる標準データを記憶させる制御手順と、
   前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行手順と、
   前記キーを用いて前記標準データへのアクセスを許可する許可手順と、
   前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿手順とを情報処理装置に実行させ、
   前記複数の端末のうちいずれかの端末が、前記制御手順により所定の標準データを記憶させた後、所定の条件により前記所定の標準データが削除され、
   前記所定の標準データは、病院を識別する情報を含み、前記所定の条件は、前記所定の標準データが前記複数の端末のうち前記病院に関連付けられる端末において参照される個別データに変換されて前記病院に関連付けられる端末に送信されることであるプログラム。

Images