JP2022000819A - Information processing system, information processing device and program - Google Patents
Information processing system, information processing device and program Download PDFInfo
- Publication number
- JP2022000819A JP2022000819A JP2021164255A JP2021164255A JP2022000819A JP 2022000819 A JP2022000819 A JP 2022000819A JP 2021164255 A JP2021164255 A JP 2021164255A JP 2021164255 A JP2021164255 A JP 2021164255A JP 2022000819 A JP2022000819 A JP 2022000819A
- Authority
- JP
- Japan
- Prior art keywords
- standard data
- data
- hospital
- patient data
- key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 36
- 238000000034 method Methods 0.000 claims description 61
- 230000005540 biological transmission Effects 0.000 claims description 2
- 238000012545 processing Methods 0.000 description 41
- 238000013500 data storage Methods 0.000 description 31
- 238000010586 diagram Methods 0.000 description 27
- 238000002595 magnetic resonance imaging Methods 0.000 description 13
- 230000008569 process Effects 0.000 description 13
- 238000012546 transfer Methods 0.000 description 13
- 201000010099 disease Diseases 0.000 description 8
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 8
- 230000036541 health Effects 0.000 description 8
- 238000007689 inspection Methods 0.000 description 6
- 238000012217 deletion Methods 0.000 description 4
- 230000037430 deletion Effects 0.000 description 4
- 238000012360 testing method Methods 0.000 description 3
- 238000009825 accumulation Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 210000003462 vein Anatomy 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Images
Landscapes
- Medical Treatment And Welfare Office Work (AREA)
Abstract
Description
本発明は、情報処理システム、情報処理装置及びプログラムに関する。 The present invention relates to an information processing system, an information processing device and a program.
従来、複数の医療機関等が、患者に係るデータとして、カルテ、画像データ(X線写真、MRI(Magnetic Resonance Imaging)画像等)、処方箋データ等を、ネットワークを介したサーバを用いて共有する技術が既に知られている(例えば特許文献1)。また、患者データにアクセスするには、パスワードで認証を行うことにより、セキュリティを確保する技術が既に知られている(例えば特許文献2)。 Conventionally, a technique for sharing medical records, image data (X-ray photographs, MRI (Magnetic Resonance Imaging) images, etc.), prescription data, etc. as data related to patients by a plurality of medical institutions using a server via a network. Is already known (for example, Patent Document 1). Further, in order to access patient data, a technique for ensuring security by performing authentication with a password is already known (for example, Patent Document 2).
しかしながら、従来の技術では、患者は、医療機関ごとに診察券が必要な場合があり、多数の医療機関を受診する場合は診察券の管理が困難となる。また、パスワードによる認証は、高齢者等の場合パスワードを忘れてしまうリスクもあり、患者データにアクセスできなくなるおそれもある。 However, in the conventional technique, a patient may need a medical examination ticket for each medical institution, and it is difficult to manage the medical examination ticket when he / she visits a large number of medical institutions. In addition, password authentication has a risk of forgetting the password in the case of elderly people and the like, and there is a risk that patient data cannot be accessed.
本発明は、上記の点に鑑みてなされたものであって、クラウド環境に患者と一意に紐付けされた暗号化データを保持することで、データの消失を防ぎセキュリティを向上させることを目的とする。 The present invention has been made in view of the above points, and an object of the present invention is to prevent data loss and improve security by holding encrypted data uniquely associated with a patient in a cloud environment. do.
そこで上記課題を解決するため、情報処理システムは、ユーザに使用される複数の端末を含み、前記複数の端末において共通して使用できる標準データを記憶する記憶部と、前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行部と、前記キーを用いて前記標準データへのアクセスを許可する許可部と、前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿部とを有し、前記複数の端末のうちいずれかの端末が、前記記憶部に所定の標準データを記憶させた後、所定の条件により前記所定の標準データが前記記憶部から削除され、前記所定の条件は、前記所定の標準データが前記複数の端末のうち病院に関連付けられる端末において参照される個別データに変換されて前記病院に関連付けられる端末に送信されることである。 Therefore, in order to solve the above problems, the information processing system includes a plurality of terminals used by the user, and has a storage unit for storing standard data that can be commonly used by the plurality of terminals, and access to the standard data. An issuing unit that issues a key that enables encryption and decryption of the standard data and identification of the user, a permission unit that permits access to the standard data using the key, and the key. It has a secret unit that encrypts standard data and decrypts the encrypted standard data using the key, and one of the plurality of terminals stores the predetermined standard data in the storage unit. After that, the predetermined standard data is deleted from the storage unit under a predetermined condition, and the predetermined condition is the individual data in which the predetermined standard data is referred to in the terminal associated with the hospital among the plurality of terminals. It is to be converted and transmitted to the terminal associated with the hospital.
複数の医療機関を利用する際、クラウド環境に患者と一意に紐付けされた暗号化データを保持することで、データの消失を防ぎセキュリティを向上させることができる。 When using multiple medical institutions, it is possible to prevent data loss and improve security by retaining encrypted data that is uniquely associated with the patient in the cloud environment.
以下、図面に基づいて本発明の本発明の実施の形態を説明する。 Hereinafter, embodiments of the present invention of the present invention will be described with reference to the drawings.
図1は、本発明の実施の形態における情報処理システム4000の構成例を示す図である。図1において、情報処理システム4000は、病院A1000a、病院B1000b、調剤薬局C1000c、患者自宅D1000d、クラウド2000及び広域ネットワーク3000を含む。病院A1000aは、サーバ1001a、端末1002a及びファイアウォール1003aを含む。病院B1000bは、サーバ1001b、端末1002b及びファイアウォール1003bを含む。調剤薬局C1000cは、端末1002c及びファイアウォール1003cを含む。患者自宅D1000dは、端末1002d及びファイアウォール1003dを含む。クラウド2000は、サーバ2001a、サーバ2001b及びサーバ2001cを含む。
FIG. 1 is a diagram showing a configuration example of the
病院A1000a、病院B1000b、調剤薬局C1000c及び患者自宅D1000dは、LAN(Local Area Network)等でそれぞれの施設内で相互に接続されたサーバ1001a、サーバ1001b、端末1002a〜d、ファイアウォール1003a〜d等を含む、オンプレミス環境である。オンプレミス環境とは、ユーザ自身が管理している施設内に、情報処理システムを導入、設置して運用する環境のことをいう。
The hospital A1000a, the hospital B1000b, the dispensing pharmacy C1000c, and the patient's home D1000d have
クラウド2000は、広域ネットワーク3000と接続しているサーバコンピュータ群である。クラウド2000は、サーバ2001a〜c等複数のサーバコンピュータから構成されており、サーバ1001a、サーバ1001b、端末1002a〜d等と通信を行い、医療情報に関する処理を行う情報処理装置である。これら施設は、病院、診療所、検査機関又は調剤薬局等が想定される。ユーザは、医師、看護師、医療事務又は会計事務の担当者等の病院関係者、患者本人、調剤薬局の薬剤師、検査機関の検査技師又は事務担当者等が想定される。
The
広域ネットワーク3000は、例えば、インターネットであり、公開されたネットワークである。広域ネットワーク3000は、専用回線ではなく、公衆回線であるため、セキュリティ対策をしない場合、改ざん、なりすまし、盗聴等の脅威を受ける可能性が有る。
The
サーバ1001a、サーバ1001b(以下、それぞれを区別しない場合「サーバ1001」という。)は、サーバコンピュータである。サーバ1001は、サーバ2001a〜cと通信を行い、ユーザとの入出力に関する処理及び医療情報に関する処理を行う。
The
端末1002a〜d(以下、それぞれを区別しない場合「端末1002」という。)は、例えば、PC(Personal Computer)、スマートフォン等の端末装置である。端末1002は、本実施形態においては、サーバ1001と同様の機能を有する。
The
ファイアウォール1003a〜d(以下、それぞれを区別しない場合「ファイアウォール1003」という。)は、広域ネットワーク3000からのセキュリティの脅威から、病院A1000a、病院B1000b、調剤薬局C1000c又は患者自宅D1000d内に設置されるネットワークを守るために設置される。
Firewalls 1003a to d (hereinafter referred to as "
サーバ2001a〜cは(以下、それぞれを区別しない場合「サーバ2001」という。)、クラウド2000に含まれるサーバコンピュータである。サーバ2001は、クラウド2000に対して要求される医療情報に関する処理を行う。
The
図2は、本発明の実施の形態におけるサーバ2001のハードウェア構成例を示す図である。図2のサーバ2001は、それぞれ相互に接続されているCPU(Central Processing Unit)2101、ネットワークインタフェース2102、入出力インタフェース2103、補助記憶装置2104及びメモリ装置2105等を有する。
FIG. 2 is a diagram showing a hardware configuration example of the
サーバ2001での処理を実現するプログラムは、補助記憶装置2104に格納される。補助記憶装置2104は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
The program that realizes the processing in the
メモリ装置2105は、プログラムの起動指示があった場合に、補助記憶装置2104からプログラムを読み出して格納する。CPU2101は、メモリ装置2105に格納されたプログラムに従ってサーバ2001に係る機能を実行する。
The
ネットワークインタフェース2102は、サーバ1001及び端末1002等と通信を行うための有線又は無線のインタフェースである。
The
入出力インタフェース2103は、USB(Universal Serial Bus)機器、ハードウェアキー、状態通知用LED、液晶ディスプレイ等の様々な入出力装置との接続を行うためのインタフェースである。
The input /
なお、サーバ1001、端末1002も図2と同様のハードウェア構成を有していてもよい。
The
図3は、本発明の実施の形態におけるクラウド2000の機能構成例を示す図である。当該機能は、1または2以上のサーバ2001によって実現される。図3に示されるクラウド2000は、標準患者データ制御部201、標準患者データ蓄積部202、病院番号蓄積部203、生体情報蓄積部204及びチケット発行認証部205を有する。これら各部は、サーバ2001にインストールされた1以上のプログラムがCPU2101に実行させる処理により実現される。また、標準患者データ蓄積部202、病院番号蓄積部203及び生体情報蓄積部204は、さらに補助記憶装置2104又はメモリ装置2105等を用いて実現可能である。
FIG. 3 is a diagram showing a functional configuration example of the
標準患者データ制御部201は、病院A1000a、病院B1000b、調剤薬局C又は患者自宅D等において共通に使用可能である標準患者データに関する処理等を行う。また、標準患者データ制御部201は、病院A1000a又は病院B1000bそれぞれに固有のデータである病院固有患者データと標準患者データの変換処理、サーバ1001又は端末1002と通信を行う。
The standard patient
標準患者データ蓄積部202は、標準患者データを記憶する機能を有する。また、標準患者データ蓄積部202は、標準患者データ制御部201からの制御に基づき、標準患者データの書込み又は読出しを行う。
The standard patient
病院番号蓄積部203は、病院に関する情報を記憶する機能を有する。また、病院番号蓄積部203は、標準患者データ制御部201からの制御に基づき、病院に関する情報の書込み又は読出しを行う。当該情報には、病院を一意に指定するIDが含まれる。
The hospital
生体情報蓄積部204は、生体情報を記憶する機能を有する。また、生体情報蓄積部204は、標準患者データ制御部201からの制御に基づき、生体情報の書込み、読出し又は照合を行う。当該情報には、患者を一意に指定するIDが含まれる。
The biological
チケット発行認証部205は、情報処理システム4000を使用するユーザの認証に関する処理を行う。ユーザには、医療関係者、調剤薬局、患者等が含まれる。また、チケット発行認証部205は、情報処理システム4000において取り扱うデータへのアクセス権等に係るチケット(詳細は後述)の発行を行う。
The ticket
図4は、本発明の実施の形態におけるサーバ1001の機能構成例を示す図である。端末1002も図4と同様の機能構成を有してもよい。
FIG. 4 is a diagram showing a functional configuration example of the
病院固有患者データ制御部101は、病院A1000a、病院B1000b、調剤薬局C1000c又は患者自宅D1000d等においてそれぞれに固有のデータである病院固有患者データに関する処理等を行う。また、病院固有患者データ制御部101は、ユーザの入出力処理を行い、クラウド2000と通信を行う。
The hospital-specific patient
病院固有患者データ蓄積部102は、病院固有患者データ制御部101からの制御に基づき、病院固有患者データの書込み又は読出しを行う。
The hospital-specific patient
チケット入出力部103は、チケット発行認証部205が発行するチケットの入出力を行う。
The ticket input /
処方箋制御部104は、クラウド2000と通信を行って、処方箋の作成等の処理を行う。
The
生体認証制御部105は、ユーザから生体情報の入力を受け、クラウド2000と通信を行って、生体情報の登録又は登録済の生体情報との照合に関する処理を行う。
The biometric
以下、情報処理システム4000において実行される処理手順の一例について説明する。
Hereinafter, an example of the processing procedure executed in the
図5は、本発明の実施の形態における病院固有患者データを標準患者データへ変換する処理手順の一例を説明するためのシーケンス図である。病院固有患者データを標準患者データへ変換することにより、サーバ1001又は端末1002は、標準患者データを共通に使用できる。図5に示されるシーケンスでは、ユーザは医療関係者であり、ユーザが病院固有患者データを更新する際に、クラウド2000は、対応する標準患者データを更新する。なお、ユーザは、医療関係者に限られず、患者本人、調剤薬局の薬剤師、検査機関の検査技師又は事務担当者等であってもよい。
FIG. 5 is a sequence diagram for explaining an example of a processing procedure for converting hospital-specific patient data into standard patient data according to the embodiment of the present invention. By converting the hospital-specific patient data into the standard patient data, the
ステップS100において、ユーザは、データ更新要求を病院固有患者データ制御部101に入力する。
In step S100, the user inputs a data update request to the hospital-specific patient
続いて、病院固有患者データ制御部101は、病院固有患者データ蓄積部102から、病院固有患者データを読み出す。破線で示されるように、病院固有患者データ制御部101は、病院固有患者データ蓄積部102から、病院固有患者データを受信する。図6は、本発明の実施の形態における病院固有患者データテーブルの一例を示す図である。図6に示されるように、病院固有患者データテーブルには、患者ごとに、「ユーザID」、「患者名」、「住所」、「健康保険証番号」、「診療履歴」、「処方箋履歴」、「X線画像群」、「MRI(Magnetic Resonance Imaging)画像群」が記録される。「ユーザID」は、当該病院内で一意に患者を識別するIDである。「患者名」は、患者の氏名である。「健康保険証番号」は、患者の健康保険証の番号である。「診療履歴」は、患者の過去の診療記録である。例えば、患者が過去に受診した科、診断された病名等が含まれる。「処方箋履歴」は、患者が過去に受領した処方箋が含まれる。「X線画像群」は、患者を過去に撮影したX線画像の集合である。「MRI画像群」は、患者を過去に撮影したMRI画像の集合である。
Subsequently, the hospital-specific patient
病院固有患者データ制御部101は、病院固有患者データ蓄積部102から、病院固有患者データを読み出すと(S101)、ステップS100においてユーザから入力されたデータに基づいて、当該病院固有患者データを更新する。例えば、患者のX線画像を新たに撮影した場合、当該X線画像を当該病院固有患者データの「X線画像群」に追加する(S102)。
When the hospital-specific patient
続いて、病院固有患者データ制御部101は、病院固有患者データ蓄積部102に、更新された病院固有患者データを書き込む(S103)。破線で示されるように、病院固有患者データ制御部101は、病院固有患者データ蓄積部102から、書込み結果の完了通知を受けてもよい。
Subsequently, the hospital-specific patient
ステップS104において、病院固有患者データ制御部101は、標準患者データ制御部201に、更新された病院固有患者データをアップロードする。当該アップロードには、病院名に関する情報もさらに含まれる。
In step S104, the hospital-specific patient
続いて、標準患者データ制御部201は、当該病院固有患者データを、標準患者データへ変換する(S105)。図7は、本発明の実施の形態における標準患者データテーブルの一例を示す図である。図7に示されるように、標準患者データテーブルには、患者ごとに、「患者ID」、「病院番号」、「ユーザID」、「PW」、「患者名」、「住所」、「健康保険証番号」、「病名」、「最終診察日」、「処方箋」、「X線」、「MRI」が記録される。「患者ID」は、標準患者データを一意に識別するIDである。「患者ID」により、患者も一意に識別可能である。「病院番号」は、病院を一意に識別するIDである。「ユーザID」は、「病院番号」によって識別される病院内で、一意に患者を識別するIDである。「PW」は、当該標準患者データを利用する際の認証時に入力するパスワードである。「患者名」は、患者の氏名である。「住所」は、患者の住所である。「健康保険証番号」は、患者の健康保険証番号である。「病名」は、現在の患者の病名である。「病名」は、病名を複数含んでもよい。「最終診察日」は、患者が最後に診察を受けた年月日である。「処方箋」は、患者が受領した最新の処方箋である。「X線」は、患者が撮影された最新のX線画像である。「MRI」は、患者が撮影された最新のMRI画像である。
Subsequently, the standard patient
標準患者データ制御部201は、当該病院固有患者データの項目に基づいて、対応する標準患者データの各項目を入力する。例えば、病院固有患者データの「ユーザID」「患者名」「住所」「健康保険証番号」は、標準患者データの同一の項目名のデータとしてそれぞれ入力される。また、病院固有患者データの「診療履歴」に基づく当該患者の現在の病名が、患者データの「病名」に入力される。また、病院固有患者データの「処方箋履歴」のうち最新の処方箋が、標準患者データの「処方箋」に入力される。同様に、標準患者データ制御部201は、病院固有患者データの「X線画像群」「MRI画像群」のうち最新の画像を、標準患者データの「X線」「MRI」にそれぞれ入力する。なお、標準患者データのうち、「病院番号」については、病院固有患者データから入力されない。
The standard patient
続いて、標準患者データ制御部201は、ステップS104で受信した、病院名に関する情報に基づいて、病院番号蓄積部203から病院番号を読出し、標準患者データの「病院番号」に入力する(S106)。破線で示されるように、標準患者データ制御部201は、病院番号蓄積部203から、病院番号を受信する。図8は、本発明の実施の形態における病院番号テーブルの一例を示す図である。図8に示されるように、病院番号テーブルには、「病院番号」、「病院名」、「病院住所」が記録される。「病院番号」は、病院を一意に識別するIDである。「病院名」は、医療機関の名称である。「病院住所」は、医療機関の住所である。病院番号テーブルは、予め作成されたものを用いてよい。
Subsequently, the standard patient
標準患者データ制御部201は、標準患者データ蓄積部202に、当該標準患者データを書き込む(S107)。なお、標準患者データ制御部201は、当該標準患者データを暗号化して、標準患者データ蓄積部202に書き込んでもよい。破線で示されるように、書込み完了の通知が、標準患者データ制御部201及び病院固有患者データ制御部101を介して、ユーザに通知されてもよい。以上の手順で、病院固有患者データを標準患者データへ変換する処理手順が完了する。
The standard patient
図9は、本発明の実施の形態における標準患者データを病院固有患者データへ変換する処理手順の一例を説明するためのシーケンス図である。標準患者データを病院固有患者データへ変換することにより、当該病院において、データを参照できるようになる。図9に示されるシーケンスでは、ユーザは医療関係者であり、ユーザが病院固有患者データを取得する際に、クラウド2000は、標準患者データを病院固有患者データへ変換する。なお、ユーザは、医療関係者に限られず、患者本人、調剤薬局の薬剤師、検査機関の検査技師又は事務担当者等であってもよい。
FIG. 9 is a sequence diagram for explaining an example of a processing procedure for converting standard patient data into hospital-specific patient data according to the embodiment of the present invention. By converting standard patient data into hospital-specific patient data, the data can be referenced at the hospital. In the sequence shown in FIG. 9, the user is a medical personnel, and when the user acquires hospital-specific patient data,
ステップS200において、ユーザは、データ取得要求を病院固有患者データ制御部101に入力する。当該データ取得要求には、患者IDが含まれる。
In step S200, the user inputs a data acquisition request to the hospital-specific patient
続いて、病院固有患者データ制御部101は、標準患者データ制御部201へダウンロードの通知を行う(S201)当該通知には、病院名に関する情報も含まれる。
Subsequently, the hospital-specific patient
続いて、標準患者データ制御部201は、ステップS201で受信した、病院名に関する情報に基づいて、病院番号蓄積部203から、病院番号を読み出す(S202)。破線で示されるように、標準患者データ制御部201は、病院番号蓄積部203から、病院番号を受信する。
Subsequently, the standard patient
続いて、標準患者データ制御部201は、標準患者データ蓄積部202から標準患者データを読み出す(S203)。破線で示されるように、標準患者データ制御部201は、標準患者データ蓄積部202から、標準患者データを受信する。当該標準患者データは、病院固有患者データへ変換される(S204)。標準患者データ制御部201は、当該標準患者データの項目に基づいて、対応する病院固有患者データの各項目を入力する。例えば、標準患者データの「ユーザID」「患者名」「住所」「健康保険証番号」は、病院固有患者データの同一の項目名のデータとしてそれぞれ入力される。また、標準患者データの「処方箋」が、病院固有患者データの「処方箋履歴」に入力される。同様に、標準患者データ制御部201は、標準患者データの「X線」「MRI」の画像を、病院固有患者データの「X線画像群」「MRI画像群」にそれぞれ入力する。このとき必要に応じて、標準患者データ制御部201は、当該標準患者データに含まれる病院番号と、ステップS202で読み出した病院番号とを照合して、照合の結果により、処理を続行するか否かを決定してもよい。
Subsequently, the standard patient
続いて、破線で示されるように、標準患者データ制御部201は、病院固有患者データ制御部101へ病院固有患者データを送信する。病院固有患者データ制御部101は、標準患者データ制御部201から受信した病院固有患者データを、病院固有患者データ蓄積部102に書き込む(S205)。破線で示されるように、書込み完了通知が、病院固有患者データ制御部101を介して、ユーザに通知されてもよい。以上の手順で、標準患者データを病院固有患者データへ変換する処理手順が完了する。
Subsequently, as shown by the broken line, the standard patient
図10は、本発明の実施の形態におけるチケット発行の処理手順の一例を説明するためのシーケンス図である。図10に示されるシーケンスでは、ユーザは患者本人を想定するが、ユーザは、患者本人に限られず、医療関係者、調剤薬局の薬剤師、検査機関の検査技師又は事務担当者等であってもよい。図10に示される各ステップにおいてユーザの入出力が行われる場合、ユーザの入出力インタフェースには、サーバ1001又は端末1002が用いられる。
FIG. 10 is a sequence diagram for explaining an example of a ticket issuing processing procedure according to the embodiment of the present invention. In the sequence shown in FIG. 10, the user is assumed to be the patient himself / herself, but the user is not limited to the patient himself / herself, and may be a medical personnel, a pharmacist at a dispensing pharmacy, a testing engineer at a testing institution, a clerical staff, or the like. .. When the user's input / output is performed in each step shown in FIG. 10, the
ステップS300において、ユーザは、認証要求を標準患者データ制御部201へ入力する。当該認証要求には、「患者ID」及び「PW」が含まれる。図10に示されるステップにおいてユーザの入出力を伴う場合、ユーザの入出力インタフェースには、サーバ1001又は端末1002が用いられる。
In step S300, the user inputs an authentication request to the standard patient
続いて、標準患者データ制御部201は、標準患者データ蓄積部202から、標準患者データを読み出す(S301)。破線で示されるように、標準患者データ制御部201は、標準患者データ蓄積部202から、標準患者データを受信する。
Subsequently, the standard patient
続いて、標準患者データ制御部201は、ユーザからの認証要求及び標準患者データに基づいた認証をチケット発行認証部205にさせる(S302)。破線で示されるように、認証の結果は、標準患者データ制御部201を介して、ユーザへ通知される。
Subsequently, the standard patient
続いて、ユーザは、チケット発行要求を標準患者データ制御部201へ入力する(S303)。当該チケット発行要求に基づき、標準患者データ制御部201は、チケット発行をチケット発行認証部205に通知する(S304)。破線で示されるように、チケットは、標準患者データ制御部201を介して、サーバ1001又は端末1002のチケット入出力部103により、ユーザに取得される。
Subsequently, the user inputs a ticket issuance request to the standard patient data control unit 201 (S303). Based on the ticket issuance request, the standard patient
チケットとは、標準患者データにアクセスするための鍵となるデータである。情報処理システム4000では、チケットで認証することにより、標準患者データの閲覧、ダウンロード又はアップロード等が可能になる。チケットには、標準患者データを識別する患者IDが少なくとも含まれる。また、図5のステップS107にて、標準患者データが暗号化されて標準患者データ制御部201に書き込まれた場合に、チケットは、暗号化された標準患者データを復号する鍵となる機能を有する。さらに、チケットは、標準患者データを暗号化する鍵となる機能も有する。
Tickets are key data for accessing standard patient data. In the
また、チケットは、アクセス可能なデータの種別又は可能なデータ処理等を設定するアクセス権、及び生体認証データと関連付けられるチケットIDを有する(詳細は後述)。 In addition, the ticket has an access right for setting the type of accessible data or possible data processing, and a ticket ID associated with the biometric authentication data (details will be described later).
チケット発行認証部205は、チケット発行要求に基づくチケットを発行し、標準患者データ制御部201及びチケット入出力部103を介して、ユーザに受領される。当該チケットの形態は、スマートフォン等の携帯端末又は記憶媒体等に記憶されるデータであってもよいし、QRコード(登録商標)等が印刷された紙媒体であってもよい。
The ticket
図11は、本発明の実施の形態におけるチケットによる患者データをダウンロードする処理手順の一例を説明するためのシーケンス図である。図11に示されるシーケンスでは、ユーザは患者本人を想定するが、図10同様に、ユーザは、患者本人に限られない。また、図11に示されるシーケンスで読み出される標準患者データは、チケットにより暗号化されて記録されているものとする。図12に示される各ステップにおいてユーザの入出力が行われる場合、ユーザの入出力インタフェースには、サーバ1001又は端末1002が用いられる。
FIG. 11 is a sequence diagram for explaining an example of a processing procedure for downloading patient data by a ticket according to an embodiment of the present invention. In the sequence shown in FIG. 11, the user assumes the patient himself / herself, but as in FIG. 10, the user is not limited to the patient himself / herself. Further, it is assumed that the standard patient data read out in the sequence shown in FIG. 11 is encrypted and recorded by the ticket. When the user's input / output is performed in each step shown in FIG. 12, the
ステップS400において、ユーザは、認証要求を標準患者データ制御部201へ入力する。当該認証要求には、「患者ID」及び「PW」が含まれる。
In step S400, the user inputs an authentication request to the standard patient
続いて、標準患者データ制御部201は、ユーザからの認証要求に基づいた認証をチケット発行認証部205にさせる(S401)。破線で示されるように、認証の結果は、標準患者データ制御部201を介して、ユーザへ通知される。認証の結果が、可であった場合は、ステップS402へ進み、不可であった場合は、シーケンスを終了する。当該認証は、例えば、第3者によるチケットの使用等のなりすまし行為を防止する。
Subsequently, the standard patient
ステップS402において、ユーザは、チケット読取りを要求する。当該チケット読取りの要求によって、図10に示される手順により既に発行されたチケットが、チケット入出力部103に入力されてデータが取得され、当該データが標準患者データ制御部201へ送信される。チケット入出力部103は、チケットの形態に応じてデータを取得する。例えば、チケットの形態が、スマートフォン等の携帯端末又は記憶媒体等に記憶されるデータであった場合は、有線又は無線接続による通信等によってデータを読み取り、QRコード等が印刷された紙媒体であった場合は、スキャナ又はカメラ等でデータを読み取る。
In step S402, the user requests a ticket read. In response to the ticket reading request, the ticket already issued by the procedure shown in FIG. 10 is input to the ticket input /
続いて、標準患者データ制御部201は、チケット読取りを行う(S403)。標準患者データ制御部201は、ステップS402で読取られたチケットのデータを取得する。破線で示されるように、読取り完了通知が、ユーザに通知されてもよい。
Subsequently, the standard patient
ステップS404において、ユーザは、ダウンロード要求を標準患者データ制御部201へ入力する。当該ダウンロード要求を受けて、標準患者データ制御部201は、標準患者データ蓄積部202から、ステップS403でチケットから読み取った患者IDに対応する標準患者データを読み出す(S405)。破線で示されるように、標準患者データ制御部201は、標準患者データ蓄積部202から、標準患者データを読み出す。
In step S404, the user inputs a download request to the standard patient
続いて、標準患者データ制御部201は、暗号化されている標準患者データを、チケットを用いて復号する(S406)。続いて、標準患者データ制御部201は、病院番号蓄積部203から、復号した標準患者データの病院番号に基づいて病院名を読み出す(S407)。破線で示されるように、標準患者データは、標準患者データ制御部201を介して、ユーザに取得される。以上の手順で、チケットによる患者データダウンロードが完了する。
Subsequently, the standard patient
図12は、本発明の実施の形態におけるチケットによる患者データをアップロードする処理手順の一例を説明するためのシーケンス図である。図12に示されるシーケンスでは、ユーザは医療関係者を想定するが、ユーザは、医療関係者に限られない。図12に示される各ステップにおいてユーザの入出力が行われる場合、ユーザの入出力インタフェースには、サーバ1001又は端末1002が用いられる。
FIG. 12 is a sequence diagram for explaining an example of a processing procedure for uploading patient data by a ticket according to the embodiment of the present invention. In the sequence shown in FIG. 12, the user is assumed to be a medical person, but the user is not limited to the medical person. When the user's input / output is performed in each step shown in FIG. 12, the
ステップS500からステップS503は、図11のステップS400からステップS403と同様である。ただし、S500においては、ユーザの医療関係者は、「医療関係者ID」と「PW」を用いて、認証要求を行う。「医療関係者ID」は、「患者ID」と同様にチケット発行認証部205での認証に使用される。当該認証は、例えば、第3者によるチケットの使用等のなりすまし行為を防止する。また、ステップS502のチケット読取り要求に使用されるチケットは、医療関係者がアップロードする患者データに係る患者から当該チケットを受領したものである。
Steps S500 to S503 are the same as steps S400 to S403 in FIG. However, in S500, the user's medical personnel makes an authentication request using the "medical personnel ID" and "PW". The “medical person ID” is used for authentication by the ticket issuing
ステップS504において、ユーザは、アップロード要求を標準患者データ制御部201へ入力する。当該アップロード要求には、病院固有患者データの一部又は全部、及び病院名に関する情報が含まれる。
In step S504, the user inputs an upload request to the standard patient
続いて、標準患者データ制御部201は、当該アップロード要求に含まれる病院名に関する情報に基づいて、病院番号蓄積部203から病院番号を読み出す(S505)。破線で示されるように、標準患者データ制御部201は、病院番号蓄積部203から病院番号を受信する。続いて、標準患者データ制御部201は、当該アップロード要求に含まれる病院固有患者データの一部又は全部を、ステップS503で読み取ったチケットに含まれる患者IDに対応する標準患者データへ変換する(S506)。また、ステップS505で読み出した病院番号を標準患者データの項目へ入力する。
Subsequently, the standard patient
続いて、標準患者データ制御部201は、変換した標準患者データをステップS503で読み取ったチケットに含まれる暗号化鍵を用いて暗号化する(S507)。標準患者データ制御部201は、暗号化した標準患者データを標準患者データ蓄積部202へ書き込む(S508)。破線で示されるように、書込み完了の通知が、標準患者データ制御部201を介して、ユーザに通知されてもよい。以上の手順で、チケットによる患者データアップロードが完了する。
Subsequently, the standard patient
図13は、本発明の実施の形態におけるチケットのアクセス権の一例を示す図である。図11のステップS403及び図12のステップS503において、標準患者データ制御部201は、チケット読取りを行う際に、当該チケットが有するアクセス権を確認する。図13に示されるように、「アクセス権の種別」ごとに、「閲覧可能データ」、「ダウンロード可能データ」、「アップロード可能データ」が設定される。「アクセス権の種別」は、アクセス権の種別を識別する名称である。「閲覧可能データ」は、閲覧可能なデータ種別又はすべてのデータが閲覧不可であることが設定される。「ダウンロード可能データ」は、ダウンロード可能なデータ種別又はすべてのデータがダウンロード不可であることが設定される。「アップロード可能データ」は、アップロード可能なデータ種別又はすべてのデータがアップロード不可であることが設定される。
FIG. 13 is a diagram showing an example of ticket access rights according to the embodiment of the present invention. In step S403 of FIG. 11 and step S503 of FIG. 12, the standard patient
例えば、図13に示される「フルアクセス」は、「閲覧可能データ」はすべてのデータが可能、「ダウンロード可能データ」はすべてのデータが可能、「アップロード可能データ」はすべてのデータが可能、のように設定されている。また、例えば、図13に示される「リードオンリー」は、「閲覧可能データ」はすべてのデータが可能、「ダウンロード可能データ」はすべてのデータが可能、「アップロード可能データ」はすべてのデータに関して不可、が設定されている。また、例えば、図13に示される「処方箋オンリー」は、「閲覧可能データ」は処方箋が可能、「ダウンロード可能データ」は処方箋が可能、「アップロード可能データ」はすべてのデータに関して不可、が設定されている。また、例えば、図13に示される「画像アップロード」は、「閲覧可能データ」はすべてのデータが不可、「ダウンロード可能データ」はすべてのデータが不可、「アップロード可能データ」は画像データが可能、が設定されている。また、例えば、図13に示される「会計処理」は、「閲覧可能データ」は会計データが可能、「ダウンロード可能データ」は会計データが可能、「アップロード可能データ」は会計データが可能、が設定されている。 For example, in "full access" shown in FIG. 13, "viewable data" can be all data, "downloadable data" can be all data, and "uploadable data" can be all data. Is set to. Further, for example, in "read only" shown in FIG. 13, "viewable data" can be all data, "downloadable data" can be all data, and "uploadable data" cannot be all data. , Is set. Further, for example, in "prescription only" shown in FIG. 13, "viewable data" can be prescription, "downloadable data" can be prescription, and "uploadable data" cannot be set for all data. ing. Further, for example, in the "image upload" shown in FIG. 13, all data cannot be used for "viewable data", all data cannot be used for "downloadable data", and image data can be used for "uploadable data". Is set. Further, for example, in the "accounting process" shown in FIG. 13, "viewable data" can be accounting data, "downloadable data" can be accounting data, and "uploadable data" can be accounting data. Has been done.
すなわち、図11のステップS403で読み取られるチケットは、少なくとも標準患者データがダウンロード可能であるアクセス権を有し、図12のステップS503で読み取られるチケットは、少なくとも標準患者データがアップロード可能であるアクセス権を有する。 That is, the ticket read in step S403 of FIG. 11 has at least the access right to download the standard patient data, and the ticket read in step S503 of FIG. 12 has the access right to upload at least the standard patient data. Has.
図14は、本発明の実施の形態における転院時の処理手順の一例を説明するためのシーケンス図である。図14に示されるシーケンスでは、ユーザは医療関係者を想定するが、ユーザは、医療関係者に限られない。また、図14に示されるシーケンスで読み出される標準患者データは、チケットにより暗号化されて記録されているものとする。 FIG. 14 is a sequence diagram for explaining an example of a processing procedure at the time of transfer in the embodiment of the present invention. In the sequence shown in FIG. 14, the user is assumed to be a medical person, but the user is not limited to the medical person. Further, it is assumed that the standard patient data read out in the sequence shown in FIG. 14 is encrypted and recorded by the ticket.
ステップS600において、ユーザは、転院処理要求を病院固有患者データ制御部101へ入力する。ステップS600では、医療関係者が転院する患者から受領したチケットのデータが、チケット入出力部103により取得される。続いて、病院固有患者データ制御部101は、転院処理を標準患者データ制御部201へ通知する(S601)。転院処理要求には、チケットのデータ及び転院先の病院名に関する情報が含まれる。当該チケットは、少なくとも標準患者データがダウンロード可能及びアップロード可能であるアクセス権を有する。続いて、標準患者データ制御部201は、当該チケットの読取りを行う(S602)。ステップS602におけるチケットの読取りは、転院処理要求に含まれるデータに基づいて行われる。
In step S600, the user inputs the hospital transfer processing request to the hospital-specific patient
ステップS603において、標準患者データ制御部201は、当該チケットに含まれる患者IDに対応する標準患者データを標準患者データ蓄積部202から読み出す。破線で示されるように、標準患者データ制御部201は、標準患者データ蓄積部202から、標準患者データを受信する。続いて、読み出された標準患者データは、チケットに含まれる復号鍵によって復号される(S604)。続いて、転院先の病院名に関する情報に基づいて、標準患者データ制御部201は、病院番号蓄積部203から、転院先の病院番号を読み出す(S605)。
In step S603, the standard patient
ステップS606において、標準患者データ制御部201は、ステップS601で通知された転院先の病院名に関する情報に基づいて、標準患者データの病院番号をステップS605で読み出した病院番号に変更する。これにより、当該標準患者データが転院先の病院に関連付けられる。
In step S606, the standard patient
ここで、転院処理が完了して、クラウド2000のデータ保持容量を削減する場合、ステップS607に進み、標準患者データ制御部201は、当該標準患者データを標準患者データ蓄積部202から削除する。ステップS607において、破線で示されるように、標準患者データ制御部201は、標準患者データを図9に示される手順で病院固有患者データに変換して、病院固有患者データ制御部101に送信後、当該標準患者データを削除する。病院固有患者データ制御部101は、当該病院固有患者データを病院固有患者データ蓄積部102に書き込む(S608)。破線で示されるように、書込み完了通知が、病院固有患者データ制御部101を介して、ユーザに通知されてもよい。以上の手順で、転院時の処理手順が完了する。
Here, when the transfer process is completed and the data holding capacity of the
なお、図14において、転院時の処理手順は一例であって、例えば、入院時の処理手順等を図14に示されるシーケンスにて処理してもよい。すなわち、入院処理の開始時に標準患者データがアップロードされ、当該入院処理が完了して、標準患者データが病院固有患者データに変換されて保存された場合、標準患者データ制御部201は、標準患者データ蓄積部202から当該標準患者データを削除してもよい。当該削除により、クラウド環境におけるデータの過剰な蓄積を防ぐことができる。
In addition, in FIG. 14, the processing procedure at the time of transfer is an example, and for example, the processing procedure at the time of admission may be processed by the sequence shown in FIG. That is, when the standard patient data is uploaded at the start of the hospitalization process, the hospitalization process is completed, and the standard patient data is converted into the hospital-specific patient data and stored, the standard patient
図15は、本発明の実施の形態における調剤時の処方箋作成に関する処理手順の一例を説明するためのシーケンス図である。図15に示されるシーケンスでは、ユーザは調剤薬局を想定するが、ユーザは、調剤薬局に限られない。また、図15に示されるシーケンスで読み出される標準患者データは、チケットにより暗号化されて記録されているものとする。 FIG. 15 is a sequence diagram for explaining an example of a processing procedure relating to prescription preparation at the time of dispensing in the embodiment of the present invention. In the sequence shown in FIG. 15, the user assumes a dispensing pharmacy, but the user is not limited to the dispensing pharmacy. Further, it is assumed that the standard patient data read out in the sequence shown in FIG. 15 is encrypted and recorded by the ticket.
ステップS700において、ユーザは、処方箋ダウンロード要求を処方箋制御部104へ入力する。ステップS700では、調剤薬局が処方箋を発行する患者から受領したチケットのデータが、チケット入出力部103により取得される。当該チケットは、少なくとも処方箋データがダウンロード可能及びアップロード可能であるアクセス権を有する。
In step S700, the user inputs a prescription download request to the
ステップS701において、処方箋制御部104は、処方箋ダウンロードの通知を標準患者データ制御部201へ送信する。続いて、標準患者データ制御部201は、チケット読取りを行う(S702)。ステップS702におけるチケットの読取りは、処方箋ダウンロードに含まれるデータに基づいて行われる。
In step S701, the
続いて、標準患者データ制御部201は、標準患者データ蓄積部202から、標準患者データを読み出す(S703)。破線で示されるように、標準患者データ制御部201は、標準患者データ蓄積部202から、標準患者データを受信する。続いて、読み出された標準患者データは、チケットに含まれる復号鍵によって復号される(S704)。
Subsequently, the standard patient
ステップS705において、標準患者データ制御部201は、復号された標準患者データに基づいて、処方箋を作成する。標準患者データには、図7に示されるように患者の最新の処方箋が含まれている。標準患者データ制御部201は、作成した処方箋を、処方箋制御部104へ送信する。ステップS705において、作成した処方箋を、処方箋制御部104へ送信した後、直ちに当該処方箋を削除してもよい。破線で示されるように、処方箋制御部104は、当該処方箋を受信すると、ユーザに処方箋を提供して調剤を完了すると共に、処方箋削除を標準患者データ制御部201に通知する(S706)。続いて、標準患者データ制御部201は、標準患者データに含まれる処方箋を削除する(S707)。ステップS705で処方箋が削除されている場合は、ステップS707は実行されない。破線で示されるように、削除完了通知が、処方箋制御部104に通知されてもよい。当該削除により、クラウド環境におけるデータの過剰な蓄積を防ぐことができる。以上の手順で、調剤時の処方箋作成に関する処理手順が完了する。
In step S705, the standard patient
図16は、本発明の実施の形態における生体情報を登録する処理手順の一例を説明するためのシーケンス図である。図16に示されるシーケンスでは、ユーザは患者本人を想定する。 FIG. 16 is a sequence diagram for explaining an example of a processing procedure for registering biological information according to the embodiment of the present invention. In the sequence shown in FIG. 16, the user assumes the patient himself / herself.
ステップS800において、ユーザは生体情報読取り要求を生体認証制御部105へ入力する。当該生体情報読取り要求には、生体認証制御部105によって読み取られた、ユーザの生体情報が含まれる。ユーザの生体情報は、例えば、指紋データ、静脈認証データ等である。破線で示されるように、読取り完了通知が、ユーザに通知されてもよい。
In step S800, the user inputs a biometric information reading request to the biometric
続いて、ユーザは、生体情報登録要求を生体認証制御部105へ入力する(S801)。生体情報登録要求には、ユーザの入力或いはチケット入出力部103によるチケット読み取りに基づくチケットID及び患者IDが含まれる。生体認証制御部105は、ステップS800で取得されたユーザの生体情報、チケットID及び患者IDを含む生体情報登録の通知を標準患者データ制御部201へ送信する(S802)。
Subsequently, the user inputs the biometric information registration request to the biometric authentication control unit 105 (S801). The biometric information registration request includes a ticket ID and a patient ID based on user input or ticket reading by the ticket input /
ステップS803において、標準患者データ制御部201は、生体情報登録を生体情報蓄積部204に対して行う。図17は、本発明の実施の形態における生体認証テーブルの一例を示す図である。図17に示される生体認証テーブルは、生体情報蓄積部204に記憶され、「生体認証データ」、「チケットID」及び「患者ID」が、ひとつのレコードの要素である。「生体認証データ」は、指紋データ、静脈認証データ等の生体情報を示すデータそのものである。「チケットID」は、チケットを一意に識別するIDであり、「生体認証データ」に関連付けられる「チケットID」が記憶される。例えば、図10に示されるチケット発行の際、ユーザが生体情報を送付して「生体認証データ」を生成し、当該チケットと当該「生体認証データ」は関連付けられ、「チケットID」を含むチケットがユーザに発行される。「患者ID」は、患者を一意に識別するIDであり、「生体認証データ」に関連付けられる「患者ID」が記憶される。破線で示されるように、登録完了通知が、標準患者データ制御部201及び生体認証制御部105を介して、ユーザに通知されてもよい。以上の手順で、生体情報を登録する処理手順が完了する。
In step S803, the standard patient
図18は、本発明の実施の形態における生体認証によるダウンロードの処理手順の一例を説明するためのシーケンス図である。図18に示されるシーケンスでは、ユーザは患者本人を想定する。また、図18に示されるシーケンスで読み出される標準患者データは、チケットにより暗号化されて記録されているものとする。 FIG. 18 is a sequence diagram for explaining an example of a download processing procedure by biometric authentication according to the embodiment of the present invention. In the sequence shown in FIG. 18, the user assumes the patient himself / herself. Further, it is assumed that the standard patient data read out in the sequence shown in FIG. 18 is encrypted and recorded by the ticket.
ステップS900において、ユーザは、生体情報及びチケットを使用するダウンロード要求を生体認証制御部105へ入力する。生体認証制御部105は、ユーザの生体情報を読み取り、チケット入出力部103は、チケットを読み取る。また、当該チケットは、少なくとも標準患者データのダウンロードが可能であるアクセス権を有する。続いて、生体認証制御部105は、生体情報及びチケットのデータを含むダウンロードの通知を標準患者データ制御部201へ送信する(S901)。続いて、標準患者データ制御部201は、チケット読取りを行う(S902)。ステップS902におけるチケットの読取りは、当該ダウンロードの通知に含まれるデータに基づいて行われる。
In step S900, the user inputs a download request using the biometric information and the ticket to the biometric
ステップS903において、標準患者データ制御部201は、生体情報及びチケット読取り結果に基づいた認証をチケット発行認証部205にさせる。例えば、チケット発行認証部205は、図17に示される生体認証テーブルのレコードの「チケットID」及び「患者ID」と、チケット読取り結果による「チケットID」及び「患者ID」とを比較する。「チケットID」及び「患者ID」がそれぞれ一致した場合、チケット発行認証部205は、当該レコードに記録されている生体認証データと当該ダウンロードの通知に含まれる生体情報とを照合する。破線で示されるように、チケット発行認証部205は、当該照合が成功した場合、標準患者データ制御部201へ認証の成功を通知し、当該照合が失敗した場合、標準患者データ制御部201へ認証の失敗を通知してシーケンスを終了する。
In step S903, the standard patient
ステップS904において、標準患者データ制御部201は、当該チケットに含まれる患者IDに対応する標準患者データを標準患者データ蓄積部202から読み出す。破線で示されるように、標準患者データ制御部201は、標準患者データ蓄積部202から、標準患者データを読み出す。続いて、読み出された標準患者データは、チケットに含まれる復号鍵によって復号される(S905)。破線で示されるように、復号された標準患者データは、生体認証制御部105を介して、ユーザに通知される。以上の手順で、生体認証によるダウンロードの処理手順が完了する。
In step S904, the standard patient
上述したように、本発明の実施の形態によれば、情報処理システム4000は、患者に一意に紐付けられた患者データの利用に係るチケットを発行して使用することで、クラウド2000にセキュリティが確保された患者データの保存が可能となる。また、情報処理システム4000は、チケットに関連付けられた生体情報を用いる認証によって、セキュリティが確保された簡便なアクセスが可能となる。その結果、複数の医療機関を利用する際、クラウド環境に患者と一意に紐付けられた暗号化データを保持することで、データの消失を防ぎセキュリティを向上させることができる。
As described above, according to the embodiment of the present invention, the
なお、本発明の実施の形態において、サーバ1001又は端末1002は、複数の端末の一例である。標準患者データは、標準データの一例である。標準患者データ蓄積部202、病院番号蓄積部203又は生体情報蓄積部204は、記憶部の一例である。チケットは、キーの一例である。チケット発行認証部205は、発行部の一例である。標準患者データ制御部201は、許可部の一例である。標準患者データ制御部201は、秘匿部の一例である。データ種別は、アクセス対象のデータの一例である。アクセス権の種別は、アクセス種別の一例である。クラウド2000は、装置群の一例である。病院固有患者データ制御部101は、送受信部の一例である。病院固有患者データは、個別データの一例である。
In the embodiment of the present invention, the
なお、本発明の実施の形態は本発明の範囲を限定するものではなく、クラウド2000が有する機能の一部をサーバ1001又は端末1002が有してもよい。また、本発明の実施の形態で説明した情報処理システム4000の構成は一例であり、情報処理システム4000は、様々なシステム構成を有してもよい。
The embodiment of the present invention does not limit the scope of the present invention, and the
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。 Although the embodiments of the present invention have been described in detail above, the present invention is not limited to such a specific embodiment, and various modifications are made within the scope of the gist of the present invention described in the claims.・ Can be changed.
1000a 病院A
1000b 病院B
1000c 調剤薬局C
1000d 患者自宅D
1001a、b サーバ
1002a〜d 端末
1003a〜d ファイアウォール
2000 クラウド
2001a〜c サーバ
3000 広域ネットワーク
4000 情報処理システム
2101 CPU
2102 ネットワークインタフェース
2103 入出力インタフェース
2104 補助記憶装置
2105 メモリ装置
201 標準患者データ制御部
202 標準患者データ蓄積部
203 病院番号蓄積部
204 生体情報蓄積部
205 認証部
101 病院固有患者データ制御部
102 病院固有患者データ蓄積部
103 チケット入出力部
104 処方箋制御部
105 生体認証制御部
1000a Hospital A
1000b Hospital B
1000c Dispensing pharmacy C
1000d patient home D
1001a,
2102
Claims (7)
前記複数の端末において共通して使用できる標準データを記憶する記憶部と、
前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行部と、
前記キーを用いて前記標準データへのアクセスを許可する許可部と、
前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿部とを有し、
前記複数の端末のうちいずれかの端末が、前記記憶部に所定の標準データを記憶させた後、所定の条件により前記所定の標準データが前記記憶部から削除され、
前記所定の条件は、前記所定の標準データが前記複数の端末のうち病院に関連付けられる端末において参照される個別データに変換されて前記病院に関連付けられる端末に送信されることである情報処理システム。 An information processing system that includes multiple terminals used by users.
A storage unit that stores standard data that can be used in common in the plurality of terminals,
An issuing unit that issues a key that enables access to the standard data, encryption and decryption of the standard data, and identification of the user.
A permission unit that permits access to the standard data using the key,
It has a secret unit that encrypts the standard data using the key and decrypts the encrypted standard data using the key.
After one of the plurality of terminals stores predetermined standard data in the storage unit, the predetermined standard data is deleted from the storage unit under predetermined conditions.
The predetermined condition is an information processing system in which the predetermined standard data is converted into individual data referred to in a terminal associated with a hospital among the plurality of terminals and transmitted to the terminal associated with the hospital.
前記端末は、
個別データを前記情報処理装置へ送信又は前記情報処理装置から受信する送受信部を有し、
前記プログラムは、
前記個別データを前記複数の端末において共通して使用できる標準データに変換して、
前記標準データを記憶させる制御手順と、
前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行手順と、
前記キーを用いて前記標準データへのアクセスを許可する許可手順と、
前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿手順とを情報処理装置に実行させ、
前記複数の端末のうちいずれかの端末が、前記制御手順により所定の標準データを記憶させた後、所定の条件により前記所定の標準データが削除され、
前記所定の条件は、前記所定の標準データが前記複数の端末のうち病院に関連付けられる端末において参照される個別データに変換されて前記病院に関連付けられる端末に送信されることである情報処理システム。 An information processing system including a plurality of terminals used by a user and a program that can be executed by an information processing device connected to the plurality of terminals.
The terminal is
It has a transmission / reception unit that transmits individual data to the information processing device or receives it from the information processing device.
The program
By converting the individual data into standard data that can be used in common by the plurality of terminals,
The control procedure for storing the standard data and
Issuing procedures for issuing keys that enable access to the standard data, encryption and decryption of the standard data, and identification of the user.
The permission procedure to allow access to the standard data using the key, and
The information processing apparatus is made to execute a secret procedure of encrypting the standard data using the key and decrypting the encrypted standard data using the key.
After one of the plurality of terminals stores predetermined standard data according to the control procedure, the predetermined standard data is deleted under predetermined conditions.
The predetermined condition is an information processing system in which the predetermined standard data is converted into individual data referred to in a terminal associated with a hospital among the plurality of terminals and transmitted to the terminal associated with the hospital.
前記複数の端末において共通して使用できる標準データを記憶する記憶部と、
前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行部と、
前記キーを用いて前記標準データへのアクセスを許可する許可部と、
前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿部とを有し、
前記複数の端末のうちいずれかの端末が、前記記憶部に所定の標準データを記憶させた後、所定の条件により前記所定の標準データが前記記憶部から削除され、
前記所定の条件は、前記所定の標準データが前記複数の端末のうち病院に関連付けられる端末において参照される個別データに変換されて前記病院に関連付けられる端末に送信されることである情報処理装置。 An information processing device that is connected to multiple terminals used by users.
A storage unit that stores standard data that can be used in common in the plurality of terminals,
An issuing unit that issues a key that enables access to the standard data, encryption and decryption of the standard data, and identification of the user.
A permission unit that permits access to the standard data using the key,
It has a secret unit that encrypts the standard data using the key and decrypts the encrypted standard data using the key.
After one of the plurality of terminals stores predetermined standard data in the storage unit, the predetermined standard data is deleted from the storage unit under predetermined conditions.
The predetermined condition is an information processing apparatus in which the predetermined standard data is converted into individual data referred to in a terminal associated with a hospital among the plurality of terminals and transmitted to the terminal associated with the hospital.
前記複数の端末において共通して使用できる標準データを記憶させる制御手順と、
前記標準データへのアクセス、前記標準データの暗号化及び復号、及び前記ユーザの識別を可能とするキーを発行する発行手順と、
前記キーを用いて前記標準データへのアクセスを許可する許可手順と、
前記キーを用いて前記標準データを暗号化し、前記キーを用いて前記暗号化した標準データを復号する秘匿手順とを情報処理装置に実行させ、
前記複数の端末のうちいずれかの端末が、前記制御手順により所定の標準データを記憶させた後、所定の条件により前記所定の標準データが削除され、
前記所定の条件は、前記所定の標準データが前記複数の端末のうち病院に関連付けられる端末において参照される個別データに変換されて前記病院に関連付けられる端末に送信されることであるプログラム。 A program that can be executed by an information processing device connected to multiple terminals used by users.
A control procedure for storing standard data that can be commonly used in the plurality of terminals, and
Issuing procedures for issuing keys that enable access to the standard data, encryption and decryption of the standard data, and identification of the user.
The permission procedure to allow access to the standard data using the key, and
The information processing apparatus is made to execute a secret procedure of encrypting the standard data using the key and decrypting the encrypted standard data using the key.
After one of the plurality of terminals stores predetermined standard data according to the control procedure, the predetermined standard data is deleted under predetermined conditions.
The predetermined condition is a program in which the predetermined standard data is converted into individual data referred to in a terminal associated with a hospital among the plurality of terminals and transmitted to the terminal associated with the hospital.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021164255A JP7279760B2 (en) | 2017-03-08 | 2021-10-05 | Information processing system, information processing device and program |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017043868A JP6957904B2 (en) | 2017-03-08 | 2017-03-08 | Information processing system, information processing device and program |
JP2021164255A JP7279760B2 (en) | 2017-03-08 | 2021-10-05 | Information processing system, information processing device and program |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017043868A Division JP6957904B2 (en) | 2017-03-08 | 2017-03-08 | Information processing system, information processing device and program |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2022000819A true JP2022000819A (en) | 2022-01-04 |
JP2022000819A5 JP2022000819A5 (en) | 2022-03-30 |
JP7279760B2 JP7279760B2 (en) | 2023-05-23 |
Family
ID=63591332
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017043868A Active JP6957904B2 (en) | 2017-03-08 | 2017-03-08 | Information processing system, information processing device and program |
JP2021164255A Active JP7279760B2 (en) | 2017-03-08 | 2021-10-05 | Information processing system, information processing device and program |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017043868A Active JP6957904B2 (en) | 2017-03-08 | 2017-03-08 | Information processing system, information processing device and program |
Country Status (1)
Country | Link |
---|---|
JP (2) | JP6957904B2 (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020126321A (en) * | 2019-02-01 | 2020-08-20 | Phcホールディングス株式会社 | Medical information provision system and data structure used for the same |
CN113973122B (en) * | 2021-10-14 | 2024-04-30 | 杭州卓健信息科技股份有限公司 | Encryption and decryption communication system and method |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6227820A (en) * | 1985-07-30 | 1987-02-05 | Toshiba Corp | Data input and output control device |
JP2005242740A (en) * | 2004-02-27 | 2005-09-08 | Open Loop:Kk | Program, storage medium and information processor in information security system |
JP2006099521A (en) * | 2004-09-30 | 2006-04-13 | Sanyo Electric Co Ltd | Information server |
JP2008134871A (en) * | 2006-11-29 | 2008-06-12 | Konica Minolta Medical & Graphic Inc | Medical information providing system and providing server |
JP2010061521A (en) * | 2008-09-05 | 2010-03-18 | Pfu Ltd | Electronic medical chart management device and electronic medical chart management method |
US20120148049A1 (en) * | 2007-12-14 | 2012-06-14 | International Business Machines Corporation | Handling Medical Prescriptions in a Secure Fashion |
JP2016095682A (en) * | 2014-11-14 | 2016-05-26 | 寛 江川 | System for managing prescription data, server device and program |
-
2017
- 2017-03-08 JP JP2017043868A patent/JP6957904B2/en active Active
-
2021
- 2021-10-05 JP JP2021164255A patent/JP7279760B2/en active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6227820A (en) * | 1985-07-30 | 1987-02-05 | Toshiba Corp | Data input and output control device |
JP2005242740A (en) * | 2004-02-27 | 2005-09-08 | Open Loop:Kk | Program, storage medium and information processor in information security system |
JP2006099521A (en) * | 2004-09-30 | 2006-04-13 | Sanyo Electric Co Ltd | Information server |
JP2008134871A (en) * | 2006-11-29 | 2008-06-12 | Konica Minolta Medical & Graphic Inc | Medical information providing system and providing server |
US20120148049A1 (en) * | 2007-12-14 | 2012-06-14 | International Business Machines Corporation | Handling Medical Prescriptions in a Secure Fashion |
JP2010061521A (en) * | 2008-09-05 | 2010-03-18 | Pfu Ltd | Electronic medical chart management device and electronic medical chart management method |
JP2016095682A (en) * | 2014-11-14 | 2016-05-26 | 寛 江川 | System for managing prescription data, server device and program |
Also Published As
Publication number | Publication date |
---|---|
JP7279760B2 (en) | 2023-05-23 |
JP2018147364A (en) | 2018-09-20 |
JP6957904B2 (en) | 2021-11-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11087021B2 (en) | Secure access to individual information | |
US11531781B2 (en) | Encryption scheme for making secure patient data available to authorized parties | |
US8977572B2 (en) | Systems and methods for patient-controlled, encrypted, consolidated medical records | |
US10893027B2 (en) | Secure access to individual information | |
US20090271221A1 (en) | Method and Apparatus for Providing Medical Records Registration | |
US20190327311A1 (en) | Secure access to individual information | |
JP7279760B2 (en) | Information processing system, information processing device and program | |
JP7121401B2 (en) | How to log in to the system | |
JP2015095229A (en) | Information processing device and method, and program | |
US20110313928A1 (en) | Method and system for health information exchange between sources of health information and personal health record systems | |
KR20200134744A (en) | Method and system for accessing information of medical treatment for patients | |
CN113722731A (en) | Medical data sharing method and device, electronic equipment and storage medium | |
JPWO2020129232A1 (en) | Treatment-related application management system and management server device | |
WO2021067141A1 (en) | System and method for providing access of a user's health information to third parties | |
KR100945819B1 (en) | Personal health record service method and system using mobile devices | |
JP2002279062A (en) | System and method for managing personal information | |
JP2000331101A (en) | System and method for managing information related to medical care | |
JP2018148490A (en) | Information management system, program and recording medium | |
JP5259170B2 (en) | Medical information management system | |
JP7499670B2 (en) | Electronic medical system and method | |
US20230317224A1 (en) | Patient specified health record on blockchain | |
JP6566990B2 (en) | Drug history management apparatus and method, and program | |
JP2023041390A (en) | Information processing device, authentication method, authentication program and patient authentication system | |
KR20140014871A (en) | Electronic prescription server, client terminals and method thereof | |
KR20220015073A (en) | System and method for sharing a medical informationabout patient using the ubiquitous environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20211102 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20220322 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230104 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230303 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20230411 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20230424 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 7279760 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |