JP2018147364A - Information processing system, information processing apparatus, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent loss of data and to improve security by holding encrypted data uniquely linked with a patient in a cloud environment when the client utilizes a plurality of medical institutions.SOLUTION: An information processing system has a plurality of terminals used by users and also has a storage unit for storing standard data which can be commonly used for the plurality of terminals, an issuance unit for issuing a key which allows access to the standard data, encoding and decoding of the standard data, and identification of the users, a permitting unit for permitting access to the standard data with the key, and a secrecy keeping unit for encoding the standard data using the key, and for decoding the standard data encoded with the key.SELECTED DRAWING: Figure 3

Description

  The present invention relates to an information processing system, an information processing apparatus, and a program.

  2. Description of the Related Art Conventionally, a technique in which a plurality of medical institutions share medical records, image data (X-ray photographs, MRI (Magnetic Resonance Imaging) images, etc.), prescription data, etc. as data related to patients using a server via a network. Is already known (for example, Patent Document 1). Moreover, in order to access patient data, the technique which ensures security by authenticating with a password is already known (for example, patent document 2).

  However, according to the conventional technology, a patient may need a medical examination ticket for each medical institution, and it is difficult to manage the medical examination card when visiting a large number of medical institutions. In addition, authentication by password has a risk of forgetting the password in the case of an elderly person or the like, and there is a possibility that patient data cannot be accessed.

  The present invention has been made in view of the above points, and aims to prevent loss of data and improve security by holding encrypted data uniquely associated with a patient in a cloud environment. To do.

  In order to solve the above problem, an information processing system includes a plurality of terminals used by a user, a storage unit that stores standard data that can be commonly used in 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 using the key A concealing unit that encrypts standard data and decrypts the encrypted standard data using the key.

  When using a plurality of medical institutions, by holding encrypted data uniquely associated with a patient in a cloud environment, data loss can be prevented and security can be improved.

It is a figure which shows the structural example of the information processing system 4000 in embodiment of this invention. It is a figure which shows the hardware structural example of the server 2001 in embodiment of this invention. It is a figure which shows the function structural example of the cloud 2000 in embodiment of this invention. It is a figure which shows the function structural example of the server 1001 in embodiment of this invention. It is a sequence diagram for demonstrating an example of the process sequence which converts the hospital specific patient data in embodiment of this invention into standard patient data. It is a figure which shows an example of the hospital specific patient data table in embodiment of this invention. It is a figure which shows an example of the standard patient data table in embodiment of this invention. It is a figure which shows an example of the hospital number table in embodiment of this invention. It is a sequence diagram for demonstrating an example of the process sequence which converts the standard patient data in embodiment of this invention into hospital specific patient data. It is a sequence diagram for demonstrating an example of the process procedure of ticket issuing in embodiment of this invention. It is a sequence diagram for demonstrating an example of the process sequence which downloads standard patient data with the ticket in embodiment of this invention. It is a sequence diagram for demonstrating an example of the process sequence which uploads standard patient data with the ticket in embodiment of this invention. It is a figure which shows an example of the access right of the ticket in embodiment of this invention. It is a sequence diagram for demonstrating an example of the process sequence at the time of the hospital transfer in embodiment of this invention. It is a sequence diagram for demonstrating an example of the process sequence regarding the prescription preparation at the time of dispensing in embodiment of this invention. It is a sequence diagram for demonstrating an example of the process sequence which registers the biometric information in embodiment of this invention. It is a figure which shows an example of the biometrics authentication table in embodiment of this invention. It is a sequence diagram for demonstrating an example of the process sequence of the download by biometrics authentication in embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a diagram showing a configuration example of an information processing system 4000 in the embodiment of the present invention. In FIG. 1, the information processing system 4000 includes a hospital A 1000a, a hospital B 1000b, a dispensing pharmacy C 1000c, a patient home D 1000d, a cloud 2000, and a wide area network 3000. The hospital A 1000a includes a server 1001a, a terminal 1002a, and a firewall 1003a. The hospital B 1000b includes a server 1001b, a terminal 1002b, and a firewall 1003b. Dispensing pharmacy C1000c includes a terminal 1002c and a firewall 1003c. Patient home D1000d includes a terminal 1002d and a firewall 1003d. The cloud 2000 includes a server 2001a, a server 2001b, and a server 2001c.

  Hospital A 1000a, Hospital B 1000b, Dispensing pharmacy C 1000c, and patient home D 1000d are connected to each other in a server 1001a, server 1001b, terminals 1002a to d, firewalls 1003a to d, etc. Including on-premises environment. An on-premises environment refers to an environment in which an information processing system is introduced, installed and operated in a facility managed by the user.

  The cloud 2000 is a group of server computers connected to the wide area network 3000. The cloud 2000 is composed of a plurality of server computers such as the servers 2001a to 2001c, and is an information processing apparatus that communicates with the server 1001a, the server 1001b, the terminals 1002a to 100d, and performs processing related to medical information. These facilities are assumed to be hospitals, clinics, inspection institutions or dispensing pharmacies. The user is assumed to be a doctor, a nurse, a hospital staff such as a person in charge of medical office or accounting office, a patient himself, a pharmacist at a dispensing pharmacy, an inspection engineer at a laboratory or an office worker.

  The wide area network 3000 is, for example, the Internet and is a public network. Since the wide area network 3000 is not a dedicated line but a public line, if security measures are not taken, there is a possibility of threats such as tampering, spoofing, and wiretapping.

  A server 1001a and a server 1001b (hereinafter referred to as “server 1001” when they are not distinguished from each other) are server computers. The server 1001 communicates with the servers 2001a to 2001c to perform processing related to input / output with the user and processing related to medical information.

  Terminals 1002a to 1002d (hereinafter referred to as “terminal 1002” when not distinguished from each other) are terminal devices such as a PC (Personal Computer) and a smartphone, for example. The terminal 1002 has the same function as the server 1001 in this embodiment.

  Firewalls 1003a to 1003d (hereinafter referred to as "firewalls 1003" when they are not distinguished from each other) are networks installed in hospital A1000a, hospital B1000b, dispensing pharmacy C1000c, or patient home D1000d from security threats from the wide area network 3000. It is installed to protect.

  The servers 2001a to 2001c (hereinafter referred to as “server 2001” when not distinguished from each other) are server computers included in the cloud 2000. The server 2001 performs processing related to medical information required for the cloud 2000.

  FIG. 2 is a diagram illustrating a hardware configuration example of the server 2001 according to the embodiment of the present invention. 2 includes a CPU (Central Processing Unit) 2101, a network interface 2102, an input / output interface 2103, an auxiliary storage device 2104, a memory device 2105, and the like that are mutually connected.

  A program for realizing processing in the server 2001 is stored in the auxiliary storage device 2104. The auxiliary storage device 2104 stores the installed program and also stores necessary files and data.

  The memory device 2105 reads the program from the auxiliary storage device 2104 and stores it when there is an instruction to start the program. The CPU 2101 executes functions related to the server 2001 in accordance with a program stored in the memory device 2105.

  The network interface 2102 is a wired or wireless interface for communicating with the server 1001 and the terminal 1002.

  The input / output interface 2103 is an interface for connecting to various input / output devices such as USB (Universal Serial Bus) devices, hardware keys, status notification LEDs, and liquid crystal displays.

  Note that the server 1001 and the terminal 1002 may also have the same hardware configuration as in FIG.

  FIG. 3 is a diagram illustrating a functional configuration example of the cloud 2000 according to the embodiment of the present invention. This function is realized by one or two or more servers 2001. 3 includes a standard patient data control unit 201, a standard patient data storage unit 202, a hospital number storage unit 203, a biometric information storage unit 204, and a ticket issuance authentication unit 205. Each of these units is realized by processing that one or more programs installed in the server 2001 cause the CPU 2101 to execute. In addition, the standard patient data storage unit 202, the hospital number storage unit 203, and the biological information storage unit 204 can be further realized using the auxiliary storage device 2104 or the memory device 2105.

  The standard patient data control unit 201 performs processing related to standard patient data that can be commonly used in the hospital A 1000a, the hospital B 1000b, the dispensing pharmacy C, the patient home D, or the like. Further, the standard patient data control unit 201 performs conversion processing between hospital specific patient data and standard patient data, which is data specific to the hospital A 1000a or the hospital B 1000b, and communicates with the server 1001 or the terminal 1002.

  The standard patient data storage unit 202 has a function of storing standard patient data. The standard patient data storage unit 202 writes or reads standard patient data based on the control from the standard patient data control unit 201.

  The hospital number accumulation unit 203 has a function of storing information related to the hospital. The hospital number accumulating unit 203 writes or reads information on the hospital based on the control from the standard patient data control unit 201. The information includes an ID that uniquely specifies the hospital.

  The biometric information storage unit 204 has a function of storing biometric information. The biometric information storage unit 204 performs writing, reading, or collation of biometric information based on control from the standard patient data control unit 201. The information includes an ID that uniquely designates the patient.

  The ticket issuance authentication unit 205 performs processing related to authentication of a user who uses the information processing system 4000. Users include medical personnel, dispensing pharmacies, patients, and the like. The ticket issuance authentication unit 205 issues a ticket (details will be described later) related to an access right to data handled in the information processing system 4000.

  FIG. 4 is a diagram illustrating a functional configuration example of the server 1001 according to the embodiment of the present invention. The terminal 1002 may also have the same functional configuration as that in FIG.

  The hospital-specific patient data control unit 101 performs processing related to hospital-specific patient data, which is data specific to each of the hospital A 1000a, hospital B 1000b, dispensing pharmacy C 1000c, patient home D 1000d, and the like. The hospital-specific patient data control unit 101 performs user input / output processing and communicates with the cloud 2000.

  The hospital specific patient data storage unit 102 writes or reads hospital specific patient data based on the control from the hospital specific patient data control unit 101.

  The ticket input / output unit 103 performs input / output of a ticket issued by the ticket issue authentication unit 205.

  The prescription control unit 104 communicates with the cloud 2000 to perform processing such as creation of a prescription.

  The biometric authentication control unit 105 receives input of biometric information from the user, communicates with the cloud 2000, and performs processing related to registration of biometric information or collation with registered biometric information.

  Hereinafter, an example of a processing procedure executed in the information processing system 4000 will be described.

  FIG. 5 is a sequence diagram for explaining an example of a processing procedure for converting hospital-specific patient data into standard patient data in the embodiment of the present invention. By converting the hospital specific patient data into the standard patient data, the server 1001 or the terminal 1002 can use the standard patient data in common. In the sequence shown in FIG. 5, the user is a medical person, and when the user updates the hospital specific patient data, the cloud 2000 updates the corresponding standard patient data. The user is not limited to a medical person, but may be the patient himself, a pharmacist at a dispensing pharmacy, an inspection engineer at an inspection organization, or a clerical staff.

  In step S <b> 100, the user inputs a data update request to the hospital specific patient data control unit 101.

  Subsequently, the hospital specific patient data control unit 101 reads out the hospital specific patient data from the hospital specific patient data storage unit 102. As indicated by the broken line, the hospital specific patient data control unit 101 receives the hospital specific patient data from the hospital specific patient data storage unit 102. FIG. 6 is a diagram showing an example of a hospital-specific patient data table in the embodiment of the present invention. As shown in FIG. 6, in the hospital specific patient data table, for each patient, “user ID”, “patient name”, “address”, “health insurance card number”, “medical history”, “prescription history”. “X-ray image group” and “MRI (Magnetic Resonance Imaging) image group” are recorded. “User ID” is an ID that uniquely identifies a patient within the hospital. “Patient name” is the name of the patient. The “health insurance card number” is the number of the patient's health insurance card. The “medical history” is a past medical record of the patient. For example, the department that the patient consulted in the past, the name of the diagnosed disease, and the like are included. The “prescription history” includes prescriptions received by the patient in the past. The “X-ray image group” is a set of X-ray images obtained by imaging a patient in the past. The “MRI image group” is a set of MRI images obtained by imaging a patient in the past.

  When the hospital-specific patient data control unit 101 reads the hospital-specific patient data from the hospital-specific patient data storage unit 102 (S101), the hospital-specific patient data control unit 101 updates the hospital-specific patient data based on the data input from the user in step S100. . For example, when a new X-ray image of a patient is taken, the X-ray image is added to the “X-ray image group” of the hospital-specific patient data (S102).

  Subsequently, the hospital-specific patient data control unit 101 writes the updated hospital-specific patient data in the hospital-specific patient data storage unit 102 (S103). As indicated by a broken line, the hospital-specific patient data control unit 101 may receive a completion notification of the writing result from the hospital-specific patient data storage unit 102.

  In step S <b> 104, the hospital specific patient data control unit 101 uploads the updated hospital specific patient data to the standard patient data control unit 201. The upload further includes information about the hospital name.

  Subsequently, the standard patient data control unit 201 converts the hospital-specific patient data into standard patient data (S105). FIG. 7 is a diagram showing an example of a standard patient data table in the embodiment of the present invention. As shown in FIG. 7, the standard patient data table includes “patient ID”, “hospital number”, “user ID”, “PW”, “patient name”, “address”, “health insurance” for each patient. ID number, “disease name”, “date of last visit”, “prescription”, “X-ray”, “MRI” are recorded. “Patient ID” is an ID that uniquely identifies standard patient data. The patient can be uniquely identified by the “patient ID”. “Hospital number” is an ID for uniquely identifying a hospital. The “user ID” is an ID that uniquely identifies a patient in the hospital identified by the “hospital number”. “PW” is a password input at the time of authentication when using the standard patient data. “Patient name” is the name of the patient. “Address” is the address of the patient. The “health insurance card number” is a patient's health insurance card number. “Disease name” is the current patient's disease name. The “disease name” may include a plurality of disease names. “Last visit date” is the date when the patient was last seen. The “prescription” is the latest prescription received by the patient. “X-ray” is the latest X-ray image of a patient. “MRI” is the latest MRI image of the patient.

  The standard patient data control unit 201 inputs each item of the corresponding standard patient data based on the item of the hospital specific patient data. For example, “user ID”, “patient name”, “address”, and “health insurance card number” of hospital specific patient data are respectively input as data of the same item name of standard patient data. In addition, the current disease name of the patient based on the “medical history” of the hospital-specific patient data is input to the “disease name” of the patient data. In addition, the latest prescription in the “prescription history” of the hospital-specific patient data is input to the “prescription” of the standard patient data. Similarly, the standard patient data control unit 201 inputs the latest images of the “X-ray image group” and “MRI image group” of the hospital-specific patient data to “X-ray” and “MRI” of the standard patient data, respectively. Of the standard patient data, “hospital number” is not input from the hospital-specific patient data.

  Subsequently, the standard patient data control unit 201 reads the hospital number from the hospital number storage unit 203 based on the information related to the hospital name received in step S104, and inputs it to the “hospital number” of the standard patient data (S106). . As indicated by the broken line, the standard patient data control unit 201 receives the hospital number from the hospital number storage unit 203. FIG. 8 is a diagram showing an example of a hospital number table in the embodiment of the present invention. As shown in FIG. 8, “hospital number”, “hospital name”, and “hospital address” are recorded in the hospital number table. “Hospital number” is an ID for uniquely identifying a hospital. “Hospital name” is the name of a medical institution. “Hospital address” is the address of a medical institution. A hospital number table may be prepared in advance.

  The standard patient data control unit 201 writes the standard patient data in the standard patient data storage unit 202 (S107). The standard patient data control unit 201 may encrypt the standard patient data and write it in the standard patient data storage unit 202. As indicated by a broken line, a notification of completion of writing may be notified to the user via the standard patient data control unit 201 and the hospital specific patient data control unit 101. With the above procedure, the processing procedure for converting hospital-specific patient data into standard patient data is completed.

  FIG. 9 is a sequence diagram for explaining an example of a processing procedure for converting standard patient data into hospital-specific patient data in the embodiment of the present invention. By converting standard patient data into hospital-specific patient data, the data can be referred to in the hospital. In the sequence shown in FIG. 9, the user is a medical person, and when the user obtains the hospital specific patient data, the cloud 2000 converts the standard patient data into the hospital specific patient data. The user is not limited to a medical person, but may be the patient himself, a pharmacist at a dispensing pharmacy, an inspection engineer at an inspection organization, or a clerical staff.

  In step S <b> 200, the user inputs a data acquisition request to the hospital specific patient data control unit 101. The data acquisition request includes a patient ID.

  Subsequently, the hospital-specific patient data control unit 101 notifies the standard patient data control unit 201 of download (S201), and the notification includes information related to the hospital name.

  Subsequently, the standard patient data control unit 201 reads out the hospital number from the hospital number storage unit 203 based on the information related to the hospital name received in step S201 (S202). As indicated by the broken line, the standard patient data control unit 201 receives the hospital number from the hospital number storage unit 203.

  Subsequently, the standard patient data control unit 201 reads standard patient data from the standard patient data storage unit 202 (S203). As indicated by a broken line, the standard patient data control unit 201 receives standard patient data from the standard patient data storage unit 202. The standard patient data is converted into hospital specific patient data (S204). The standard patient data control unit 201 inputs each item of the corresponding hospital specific patient data based on the standard patient data item. For example, “user ID”, “patient name”, “address”, and “health insurance card number” of standard patient data are respectively input as data of the same item name of hospital specific patient data. Further, the “prescription” of the standard patient data is input to the “prescription history” of the hospital-specific patient data. Similarly, the standard patient data control unit 201 inputs “X-ray” and “MRI” images of standard patient data to “X-ray image group” and “MRI image group” of hospital-specific patient data, respectively. At this time, if necessary, the standard patient data control unit 201 collates the hospital number included in the standard patient data with the hospital number read in step S202, and determines whether or not to continue the process according to the collation result. You may decide.

  Subsequently, as indicated by a broken line, the standard patient data control unit 201 transmits hospital specific patient data to the hospital specific patient data control unit 101. The hospital specific patient data control unit 101 writes the hospital specific patient data received from the standard patient data control unit 201 to the hospital specific patient data storage unit 102 (S205). As indicated by a broken line, a notification of completion of writing may be notified to the user via the hospital specific patient data control unit 101. With the above procedure, the processing procedure for converting standard patient data into hospital-specific patient data is completed.

  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, but the user is not limited to the patient himself, and may be a medical person, a pharmacist at a dispensing pharmacy, an inspection engineer at the inspection organization, or a clerical staff. . When a user input / output is performed in each step shown in FIG. 10, the server 1001 or the terminal 1002 is used as the user input / output interface.

  In step S300, the user inputs an authentication request to the standard patient data control unit 201. The authentication request includes “patient ID” and “PW”. When the user input / output is accompanied in the steps shown in FIG. 10, the server 1001 or the terminal 1002 is used as the user input / output interface.

  Subsequently, the standard patient data control unit 201 reads standard patient data from the standard patient data storage unit 202 (S301). As indicated by a broken line, the standard patient data control unit 201 receives standard patient data from the standard patient data storage unit 202.

  Subsequently, the standard patient data control unit 201 causes the ticket issue authentication unit 205 to perform authentication based on the authentication request from the user and the standard patient data (S302). As indicated by the broken line, the result of authentication is notified to the user via the standard patient data control unit 201.

  Subsequently, the user inputs a ticket issue request to the standard patient data control unit 201 (S303). Based on the ticket issue request, the standard patient data control unit 201 notifies the ticket issue authentication unit 205 of the ticket issue (S304). As indicated by the broken line, the ticket is acquired by the user by the ticket input / output unit 103 of the server 1001 or the terminal 1002 via the standard patient data control unit 201.

  A ticket is key data for accessing standard patient data. In the information processing system 4000, it is possible to browse, download, or upload standard patient data by authenticating with a ticket. The ticket includes at least a patient ID that identifies standard patient data. In addition, when the standard patient data is encrypted and written in the standard patient data control unit 201 in step S107 of FIG. 5, the ticket has a function as a key for decrypting the encrypted standard patient data. . In addition, the ticket has a key function of encrypting standard patient data.

  The ticket also has an access right for setting the type of accessible data or possible data processing, and a ticket ID associated with biometric authentication data (details will be described later).

  The ticket issuance authentication unit 205 issues a ticket based on the ticket issuance request and receives the ticket via the standard patient data control unit 201 and the ticket input / output unit 103. The form of the ticket may be data stored in a mobile terminal such as a smartphone or a storage medium, or may be a paper medium on which a QR code (registered trademark) or the like is printed.

  FIG. 11 is a sequence diagram for explaining an example of a processing procedure for downloading patient data using a ticket according to the embodiment of the present invention. In the sequence shown in FIG. 11, the user assumes the patient himself, but the user is not limited to the patient himself as in FIG. 10. Further, it is assumed that the standard patient data read out in the sequence shown in FIG. 11 is encrypted and recorded with a ticket. When a user input / output is performed in each step shown in FIG. 12, the server 1001 or the terminal 1002 is used as the user input / output interface.

  In step S <b> 400, the user inputs an authentication request to the standard patient data control unit 201. The authentication request includes “patient ID” and “PW”.

  Subsequently, the standard patient data control unit 201 causes the ticket issue authentication unit 205 to perform authentication based on the authentication request from the user (S401). As indicated by the broken line, the result of authentication is notified to the user via the standard patient data control unit 201. If the authentication result is acceptable, the process proceeds to step S402. If the authentication result is unacceptable, the sequence is terminated. For example, the authentication prevents impersonation such as use of a ticket by a third party.

  In step S402, the user requests ticket reading. In response to the ticket reading request, a ticket that has already been issued by the procedure shown in FIG. 10 is input to the ticket input / output unit 103 to acquire data, and the data is transmitted to the standard patient data control unit 201. The ticket input / output unit 103 acquires data according to the form of the ticket. For example, if the form of the ticket is data stored in a mobile terminal such as a smartphone or a storage medium, it is a paper medium on which a QR code or the like is printed by reading the data by wired or wireless communication or the like. If it does, read the data with a scanner or camera.

  Subsequently, the standard patient data control unit 201 reads a ticket (S403). The standard patient data control unit 201 acquires the ticket data read in step S402. As indicated by the broken line, a read completion notification may be notified to the user.

  In step S <b> 404, the user inputs a download request to the standard patient data control unit 201. In response to the download request, the standard patient data control unit 201 reads standard patient data corresponding to the patient ID read from the ticket in step S403 from the standard patient data storage unit 202 (S405). As indicated by a broken line, the standard patient data control unit 201 reads standard patient data from the standard patient data storage unit 202.

  Subsequently, the standard patient data control unit 201 decrypts the encrypted standard patient data using a ticket (S406). Subsequently, the standard patient data control unit 201 reads the hospital name from the hospital number storage unit 203 based on the hospital number of the decrypted standard patient data (S407). As indicated by a broken line, the standard patient data is acquired by the user via the standard patient data control unit 201. With the above procedure, patient data download by ticket is completed.

  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 illustrated in FIG. 12, the user is assumed to be a medical person, but the user is not limited to the medical person. When a user input / output is performed in each step shown in FIG. 12, the server 1001 or the terminal 1002 is used as the user input / output interface.

  Steps S500 to S503 are the same as steps S400 to S403 in FIG. However, in S500, the medical staff of the user makes an authentication request using “medical staff ID” and “PW”. The “medical personnel ID” is used for authentication in the ticket issuance / authentication unit 205 in the same manner as the “patient ID”. For example, the authentication prevents impersonation such as use of a ticket by a third party. The ticket used for the ticket reading request in step S502 is a ticket received from a patient related to patient data uploaded by a medical staff.

  In step S <b> 504, the user inputs an upload request to the standard patient data control unit 201. The upload request includes part or all of the hospital-specific patient data and information on the hospital name.

  Subsequently, the standard patient data control unit 201 reads out the hospital number from the hospital number storage unit 203 based on the information related to the hospital name included in the upload request (S505). As indicated by the broken line, the standard patient data control unit 201 receives the hospital number from the hospital number storage unit 203. Subsequently, the standard patient data control unit 201 converts part or all of the hospital-specific patient data included in the upload request into standard patient data corresponding to the patient ID included in the ticket read in step S503 (S506). ). In addition, the hospital number read in step S505 is input to the item of standard patient data.

  Subsequently, the standard patient data control unit 201 encrypts the converted standard patient data using the encryption key included in the ticket read in step S503 (S507). The standard patient data control unit 201 writes the encrypted standard patient data into the standard patient data storage unit 202 (S508). As indicated by a broken line, a notification of completion of writing may be notified to the user via the standard patient data control unit 201. With the above procedure, the patient data upload by the ticket is completed.

  FIG. 13 is a diagram showing an example of the ticket access right according to the embodiment of the present invention. In step S403 in FIG. 11 and step S503 in FIG. 12, the standard patient data control unit 201 confirms the access right of the ticket when reading the ticket. As shown in FIG. 13, “viewable data”, “downloadable data”, and “uploadable data” are set for each “access right type”. “Access right type” is a name for identifying the access right type. “Browsable data” is set such that browsingable data types or all data cannot be browsed. “Downloadable data” is set such that downloadable data types or all data cannot be downloaded. “Uploadable data” is set such that uploadable data types or all data cannot be uploaded.

  For example, “full access” shown in FIG. 13 indicates that “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, “read-only” shown in FIG. 13 is “readable data” can be all data, “downloadable data” can be all data, and “uploadable data” is not possible for all data. , Is set. Further, for example, “prescription only” shown in FIG. 13 is set to “viewable data” can be a prescription, “downloadable data” can be a prescription, and “uploadable data” is not possible for all data. ing. Further, for example, “image upload” shown in FIG. 13 cannot be all data for “viewable data”, cannot be all data for “downloadable data”, and can be image data for “uploadable data”. Is set. Further, for example, the “accounting processing” shown in FIG. 13 is set such that “viewable data” can be accounting data, “downloadable data” can be accounting data, and “uploadable data” can be accounting data. Has been.

  That is, the ticket read in step S403 in FIG. 11 has an access right to download at least standard patient data, and the ticket read in step S503 in FIG. 12 has an access right to upload at least standard patient data. Have

  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 illustrated 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 with a ticket.

  In step S <b> 600, the user inputs a hospital transfer process request to the hospital-specific patient data control unit 101. In step S <b> 600, the ticket input / output unit 103 acquires ticket data received from a patient who is transferred by a medical staff. Subsequently, the hospital-specific patient data control unit 101 notifies the standard patient data control unit 201 of the transfer process (S601). The transfer process request includes ticket data and information on the hospital name of the transfer destination. The ticket has access rights that allow at least standard patient data to be downloaded and uploaded. Subsequently, the standard patient data control unit 201 reads the ticket (S602). The reading of the ticket in step S602 is performed based on the data included in the transfer process request.

  In step S <b> 603, the standard patient data control unit 201 reads standard patient data corresponding to the patient ID included in the ticket from the standard patient data storage unit 202. As indicated by a broken line, the standard patient data control unit 201 receives standard patient data from the standard patient data storage unit 202. Subsequently, the read standard patient data is decrypted by the decryption key included in the ticket (S604). Subsequently, the standard patient data control unit 201 reads out the hospital number of the transfer destination from the hospital number storage unit 203 based on the information related to the hospital name of the transfer destination (S605).

  In step S606, the standard patient data control unit 201 changes the hospital number of the standard patient data to the hospital number read in step S605 based on the information regarding the hospital name of the transfer destination notified in step S601. As a result, the standard patient data is associated with the hospital to which the patient is transferred.

  Here, when the transfer process is completed and the data holding capacity of the cloud 2000 is reduced, the process proceeds to step S607, and the standard patient data control unit 201 deletes the standard patient data from the standard patient data storage unit 202. In step S607, as indicated by a broken line, the standard patient data control unit 201 converts the standard patient data into hospital specific patient data according to the procedure shown in FIG. 9 and transmits the data to the hospital specific patient data control unit 101. The standard patient data is deleted. The hospital-specific patient data control unit 101 writes the hospital-specific patient data in the hospital-specific patient data storage unit 102 (S608). As indicated by a broken line, a notification of completion of writing may be notified to the user via the hospital specific patient data control unit 101. With the above procedure, the processing procedure at the time of transfer is completed.

  In FIG. 14, the processing procedure at the time of hospital transfer is an example, and for example, the processing procedure at the time of hospitalization and the like 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 hospital-specific patient data and stored, the standard patient data control unit 201 The standard patient data may be deleted from the storage unit 202. This deletion can prevent excessive accumulation of data in the cloud environment.

  FIG. 15 is a sequence diagram for explaining an example of a processing procedure related to prescription creation 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 a dispensing pharmacy. Further, it is assumed that the standard patient data read out in the sequence shown in FIG. 15 is encrypted and recorded with a ticket.

  In step S <b> 700, the user inputs a prescription download request to the prescription control unit 104. In step S <b> 700, the ticket input / output unit 103 acquires ticket data received from a patient to whom a dispensing pharmacy issues a prescription. The ticket has an access right that allows at least prescription data to be downloaded and uploaded.

  In step S <b> 701, the prescription control unit 104 transmits a prescription download notification to the standard patient data control unit 201. Subsequently, the standard patient data control unit 201 reads a ticket (S702). The reading of the ticket in step S702 is performed based on the data included in the prescription download.

  Subsequently, the standard patient data control unit 201 reads standard patient data from the standard patient data storage unit 202 (S703). As indicated by a broken line, the standard patient data control unit 201 receives standard patient data from the standard patient data storage unit 202. Subsequently, the read standard patient data is decrypted with the decryption key included in the ticket (S704).

  In step S705, the standard patient data control unit 201 creates a prescription based on the decrypted standard patient data. The standard patient data includes the patient's latest prescription as shown in FIG. The standard patient data control unit 201 transmits the created prescription to the prescription control unit 104. In step S705, after the created prescription is transmitted to the prescription control unit 104, the prescription may be deleted immediately. As indicated by a broken line, when receiving the prescription, the prescription control unit 104 provides the prescription to the user to complete the dispensing, and notifies the standard patient data control unit 201 of the prescription deletion (S706). Subsequently, the standard patient data control unit 201 deletes the prescription included in the standard patient data (S707). If the prescription has been deleted in step S705, step S707 is not executed. As indicated by a broken line, a deletion completion notification may be notified to the prescription control unit 104. This deletion can prevent excessive accumulation of data in the cloud environment. With the above procedure, the processing procedure related to prescription creation at the time of dispensing is completed.

  FIG. 16 is a sequence diagram for explaining an example of a processing procedure for registering biometric information according to the embodiment of the present invention. In the sequence shown in FIG. 16, the user assumes the patient himself.

  In step S <b> 800, the user inputs a biometric information reading request to the biometric authentication control unit 105. The biometric information reading request includes the biometric information of the user read by the biometric authentication control unit 105. The user's biometric information is, for example, fingerprint data, vein authentication data, or the like. As indicated by the broken line, a read completion notification may be notified to the user.

  Subsequently, the user inputs a 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 / output unit 103. The biometric authentication control unit 105 transmits a biometric information registration notification including the user's biometric information, ticket ID, and patient ID acquired in step S800 to the standard patient data control unit 201 (S802).

  In step S <b> 803, the standard patient data control unit 201 performs biometric information registration on the biometric information storage unit 204. FIG. 17 is a diagram showing an example of a biometric authentication table in the embodiment of the present invention. The biometric authentication table shown in FIG. 17 is stored in the biometric information storage unit 204, and “biometric authentication data”, “ticket ID”, and “patient ID” are elements of one record. “Biometric authentication data” is data itself indicating biometric information such as fingerprint data and vein authentication data. “Ticket ID” is an ID for uniquely identifying a ticket, and “Ticket ID” associated with “Biometric authentication data” is stored. For example, when the ticket shown in FIG. 10 is issued, the user sends biometric information to generate “biometric authentication data”, the ticket and the “biometric authentication data” are associated with each other, and a ticket including “ticket ID” is generated. Issued to the user. “Patient ID” is an ID for uniquely identifying a patient, and “patient ID” associated with “biometric authentication data” is stored. As indicated by a broken line, a registration completion notification may be notified to the user via the standard patient data control unit 201 and the biometric authentication control unit 105. With the above procedure, the processing procedure for registering biometric information is completed.

  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. Further, it is assumed that the standard patient data read out in the sequence shown in FIG. 18 is recorded by being encrypted with a ticket.

  In step S <b> 900, the user inputs a download request using biometric information and a ticket to the biometric authentication control unit 105. The biometric authentication control unit 105 reads the user's biometric information, and the ticket input / output unit 103 reads the ticket. The ticket has an access right that allows at least downloading of standard patient data. Subsequently, the biometric authentication control unit 105 transmits a download notification including biometric information and ticket data to the standard patient data control unit 201 (S901). Subsequently, the standard patient data control unit 201 reads a ticket (S902). The reading of the ticket in step S902 is performed based on the data included in the download notification.

  In step S903, the standard patient data control unit 201 causes the ticket issue authentication unit 205 to perform authentication based on the biometric information and the ticket reading result. For example, the ticket issuance / authentication unit 205 compares the “ticket ID” and “patient ID” in the record of the biometric authentication table shown in FIG. 17 with the “ticket ID” and “patient ID” based on the ticket reading result. When the “ticket ID” and the “patient ID” match, the ticket issuance authentication unit 205 collates the biometric data recorded in the record with the biometric information included in the download notification. As indicated by the broken line, the ticket issuance authentication unit 205 notifies the standard patient data control unit 201 of the success of authentication when the verification is successful, and authenticates to the standard patient data control unit 201 when the verification fails. The failure is notified and the sequence is terminated.

  In step S <b> 904, the standard patient data control unit 201 reads standard patient data corresponding to the patient ID included in the ticket from the standard patient data storage unit 202. As indicated by a broken line, the standard patient data control unit 201 reads standard patient data from the standard patient data storage unit 202. Subsequently, the read standard patient data is decrypted by the decryption key included in the ticket (S905). As indicated by the broken line, the decrypted standard patient data is notified to the user via the biometric authentication control unit 105. With the above procedure, the download processing procedure using biometric authentication is completed.

  As described above, according to the embodiment of the present invention, the information processing system 4000 issues security information to the cloud 2000 by issuing and using a ticket related to use of patient data uniquely associated with a patient. The secured patient data can be saved. In addition, the information processing system 4000 enables simple access with security ensured by authentication using biometric information associated with a ticket. As a result, when using a plurality of medical institutions, it is possible to prevent data loss and improve security by holding encrypted data uniquely associated with a patient in a cloud environment.

  In the embodiment of the present invention, the server 1001 or the terminal 1002 is an example of a plurality of terminals. Standard patient data is an example of standard data. The standard patient data storage unit 202, the hospital number storage unit 203, or the biological information storage unit 204 is an example of a storage unit. A ticket is an example of a key. The ticket issue authentication unit 205 is an example of an issue unit. The standard patient data control unit 201 is an example of a permission unit. The standard patient data control unit 201 is an example of a concealment unit. The data type is an example of data to be accessed. The type of access right is an example of an access type. The cloud 2000 is an example of a device group. The hospital specific patient data control unit 101 is an example of a transmission / reception unit. Hospital specific patient data is an example of individual data.

  Note that the embodiment of the present invention does not limit the scope of the present invention, and the server 1001 or the terminal 1002 may have some of the functions of the cloud 2000. The configuration of the information processing system 4000 described in the embodiment of the present invention is an example, and the information processing system 4000 may have various system configurations.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

1000a Hospital A
1000b Hospital B
1000c Dispensing pharmacy C
1000d Patient home D
1001a, b Servers 1002a-d Terminals 1003a-d Firewall 2000 Cloud 2001a-c Server 3000 Wide area network 4000 Information processing system 2101 CPU
2102 Network interface 2103 Input / output interface 2104 Auxiliary storage device 2105 Memory device 201 Standard patient data control unit 202 Standard patient data storage unit 203 Hospital number storage unit 204 Biometric information storage unit 205 Authentication unit 101 Hospital specific patient data control unit 102 Hospital specific patient Data storage unit 103 Ticket input / output unit 104 Prescription control unit 105 Biometric authentication control unit

JP 2003-337858 A JP 2001-297153 A

Claims (9)

An information processing system including a plurality of terminals used by a user,
A storage unit for storing standard data that can be commonly used in the plurality of terminals;
An issuing unit for issuing a key that enables access to the standard data, encryption and decryption of the standard data, and identification of the user;
A permission unit for permitting access to the standard data using the key;
An information processing system comprising: a secret section that encrypts the standard data using the key and decrypts the encrypted standard data using the key.   The information processing system according to claim 1, wherein the permission unit permits access to standard data by the key based on data to be accessed and an access type.   The information processing system according to claim 1, wherein after the terminal stores predetermined standard data in the storage unit, the standard data is deleted from the storage unit according to a predetermined condition.   4. The information processing system according to claim 3, wherein the predetermined standard data includes information for identifying a hospital, and the predetermined condition is that the predetermined standard data is converted into individual data and transmitted.   The information processing system according to claim 3, wherein the predetermined standard data includes information related to a prescription, and the predetermined condition is that a prescription created based on the predetermined standard data is transmitted.   The information processing system according to claim 1, wherein the permission unit permits access to standard data by the key based on biometric information associated with the key. An information processing system including a plurality of terminals used by a user and a program executable by an information processing apparatus connected to the plurality of terminals,
The terminal
A transmission / reception unit for transmitting or receiving individual data to or from the information processing apparatus;
The program is
A control procedure for converting the individual data into standard data that can be commonly used in the plurality of terminals and storing the standard data;
An issuance procedure for issuing a key that enables access to the standard data, encryption and decryption of the standard data, and identification of the user;
An authorization procedure for permitting access to the standard data using the key;
An information processing system for causing an information processing apparatus to execute a secret procedure for encrypting the standard data using the key and decrypting the encrypted standard data using the key. An information processing apparatus connected to a plurality of terminals used by a user,
A storage unit for storing standard data that can be commonly used in the plurality of terminals;
An issuing unit for issuing a key that enables access to the standard data, encryption and decryption of the standard data, and identification of the user;
A permission unit for permitting access to the standard data using the key;
An information processing apparatus comprising: a concealing unit that encrypts the standard data using the key and decrypts the encrypted standard data using the key. A program that can be executed by an information processing apparatus connected to a plurality of terminals used by a user,
A control procedure for storing standard data that can be commonly used in the plurality of terminals;
An issuance procedure for issuing a key that enables access to the standard data, encryption and decryption of the standard data, and identification of the user;
An authorization procedure for permitting access to the standard data using the key;
A program for causing an information processing apparatus to execute a secret procedure for encrypting the standard data using the key and decrypting the encrypted standard data using the key.

Images