JP2019185642A - Electronic prescription management method, electronic prescription management system, and program - Google Patents

Abstract

To realize an electronic prescription that can be operated in real-world.SOLUTION: The electronic prescription management method includes steps in which a blockchain database to store prescription data in association with a patient receives, from a first terminal operated by a predetermined patient, a first transaction of granting a temporal access permission to a record of the predetermined patient in a blockchain database of a physician in charge of the predetermined patient, and stores the prescription data included in a second transaction output from a second terminal operated by the physician granted the access permission in association with the predetermined patient.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an electronic prescription management method, an electronic prescription management system, and a program for creating, delivering, and storing a prescription by electromagnetic recording.

  According to the notification issued by the Ministry of Health, Labor and Welfare on March 31, 2016, electronic prescriptions can be implemented. In response to this, the Japan Association for Health Care and Welfare Information Systems (JAHIS) compiled the specifications for the implementation of electronic prescriptions (for example, see Non-Patent Document 1).

  This implementation guide describes transactions between patients, medical institutions, pharmacies, and ASP servers on the premise of using an ASP server.

Japan Health Insurance and Welfare Information System Industry Association “JAHIS Electronic Prescription Implementation Guide Ver.1.0” May 2017

  However, as this implementation guide recognizes itself, there are problems that are difficult to deal with with this implementation guide alone, and even if an electronic prescription is implemented based on this implementation guide, it is difficult to put it into actual operation. As described above, various problems remain in realizing the electronic prescription.

  Then, an object of this invention is to provide the electronic prescription management method, the electronic prescription management system, and program which can implement | achieve the electronic prescription which can be actually used without using an ASP server.

In order to solve the above-described problem, a first aspect of the present invention is that a blockchain database that stores prescription data in association with a patient is a doctor who is in charge of the predetermined patient from a first terminal operated by the predetermined patient. The first transaction for granting temporary access to the predetermined patient record in the blockchain database is received and output from the second terminal operated by the doctor who has been given the access An electronic prescription management method comprising: storing the prescription data included in a second transaction in association with the predetermined patient is provided.
Here, the prescription data is data indicating the content of the prescription, and is typically prescription CDA data. For example, prescription data created by a doctor or prescription CDA data output to a PDF file may be used. Be good.

The electronic prescription management method of the present invention having the above-described configuration is a temporary access authority from the first terminal to a record of the predetermined patient in the block chain database of a pharmacist in charge of the predetermined patient. The third transaction received by the pharmacist to which the access authority has been granted is allowed to refer to the prescription data relating to the predetermined patient, and is output from the third terminal. And storing the dispensing data included in the four transactions in association with the predetermined patient.
Here, the dispensing data is data indicating the dispensing result, and is typically dispensing CDA data. However, for example, the dispensing result itself created by a pharmacist may be used, or the dispensing CDA data may be output to a PDF file. Be good.

  According to a second aspect of the present invention, there is provided a blockchain database for storing prescription data in association with a patient, and the predetermined patient in the blockchain database of a doctor in charge of a predetermined patient according to a patient operation. A first terminal that outputs a first transaction that allows temporary access to a record; and a second terminal that outputs a second transaction including the prescription data in response to the operation of the doctor. The blockchain database stores the prescription data included in the second transaction output from the second terminal corresponding to the doctor who has been granted the access right in association with the predetermined patient; An electronic prescription management system is provided.

  In the electronic prescription management system of the present invention having the above-described configuration, the first terminal records the predetermined patient in the block chain database of the pharmacist in charge of the predetermined patient according to the patient operation. The electronic prescription management system outputs a fourth transaction including a reference request for the prescription data or dispensing data according to a pharmacist's operation. The block chain database permits the third terminal corresponding to the pharmacist to which the access authority is granted to refer to the prescription data relating to the predetermined patient, and from the third terminal. The dispensing data included in the output fourth transaction is transmitted to the predetermined patient. May be stored attach communication.

  According to a third aspect of the present invention, a block chain database that stores prescription data in association with a patient is accessible, and a terminal operated by a predetermined patient is subjected to the block by the doctor at the time of examination by a doctor. A transaction for granting access authority to the record of the predetermined patient in the chain database, and a transaction for granting the access authority to the record to the pharmacist when dispensing by a pharmacist in charge of the predetermined patient Are output to the blockchain database, and when the examination and the dispensing are completed, a program for executing a transaction for depriving the granted access authority to the blockchain database is provided. .

  According to a fourth aspect of the present invention, for a doctor terminal capable of communicating with a block chain database that stores prescription data in association with a patient, obtaining prescription data relating to a predetermined patient in response to a doctor operation, the block Outputting a transaction including the prescription data relating to the predetermined patient to the block chain database in a state where temporary access authority to the record of the predetermined patient in the chain database is granted. I will provide a.

  According to a fifth aspect of the present invention, a pharmacist terminal capable of communicating with a blockchain database that stores prescription data in association with a patient has temporary access authority to the predetermined patient record in the blockchain database. The blockchain database is requested to refer to the prescription data relating to a predetermined patient, the dispensing data relating to the predetermined patient is acquired according to a pharmacist's operation, and the predetermined patient. And outputting a transaction including the dispensing data for the block chain database.

  According to the present invention, an electronic prescription capable of actual operation can be realized without using an ASP server.

1 is an overall configuration diagram of an electronic prescription management system 1 according to a representative embodiment of the present invention. It is a block diagram which shows an example of the hardware constitutions of the computer which comprises the patient terminal of FIG. 1, a hospital information system, a doctor terminal, a pharmacy system, a computer as a pharmacist terminal, and a block chain. 3 is a block diagram illustrating an example of a software configuration of a patient terminal 10. FIG. 2 is a block diagram illustrating an example of a software configuration of a hospital information system 20. FIG. 3 is a block diagram illustrating an example of a software configuration of a doctor terminal 30. FIG. 2 is a block diagram illustrating an example of a software configuration of a pharmacy system 40. FIG. 3 is a block diagram illustrating an example of a software configuration of a pharmacist terminal 50. FIG. It is a conceptual diagram of the transaction in a block chain. It is explanatory drawing of a block chain. It is a figure which shows an example of a transaction structure. It is a figure which shows an example of the data table of a state database (DB). It is a figure which shows an example of the state transition of state DB at the time of medical treatment. It is a figure which shows an example of the state transition of state DB at the time of dispensing. It is a flowchart which shows the processing flow at the time of a medical examination. It is a flowchart which shows the processing flow at the time of dispensing.

  Hereinafter, representative embodiments of the present invention will be described in detail with reference to the drawings. However, the present invention is not limited to these drawings. Moreover, since the drawings are for conceptual description of the present invention, the dimensions, ratios, or numbers may be exaggerated or simplified as necessary for easy understanding.

[Overall configuration of electronic prescription management system]
With reference to FIG. 1, the example of the whole structure of the electronic prescription management system 1 which concerns on this embodiment is demonstrated.
The electronic prescription management system 1 is a computer system for creating, delivering and storing prescriptions by electromagnetic recording. In the electronic prescription management system 1, prescription data is stored in the block chain from the doctor side by giving temporary access authority from the patient side, and dispensing data is referred to in the block chain by referring to the prescription data from the pharmacist side. Can be saved.

  The electronic prescription management system 1 includes a patient terminal 10 (first terminal), a hospital information system 20, a doctor terminal 30 (second terminal), a pharmacy system 40, a pharmacist terminal 50 (third terminal), and a block chain 60. It is configured. The patient terminal 10, the hospital information system 20, the doctor terminal 30, the pharmacy system 40, and the pharmacist terminal 50 are connected to the block chain 60 so that they can communicate with each other by wire or wirelessly. Each of these components is one or a plurality of computers, and may be any type of computer such as a desktop type, a laptop type, a tablet type, and a portable type.

  FIG. 2 is a block diagram illustrating an example of a hardware configuration of a patient terminal, a hospital information system, a doctor terminal, a pharmacy system, a pharmacist terminal, and a computer constituting a block chain. Each of these computers includes a CPU 101, a memory 102, a storage device 103, a communication device 104, an input device 105, and an output device 106.

  The CPU 101 implements various functions as a patient terminal, a hospital information system, a doctor terminal, a pharmacy system, a pharmacist terminal, and a block chain (node), as will be described later, by reading various programs and data into the memory 102 and executing them. . The storage device 103 stores various data and programs, such as a hard disk drive, a solid state drive, and a flash memory.

  The communication device 104 is an interface for connecting to wired and wireless communication networks. For example, an adapter for connecting to Ethernet (registered trademark), a modem for connecting to a public telephone network, and performing wireless communication A wireless communication device, a USB (Universal Serial Bus) connector for serial communication, an RS232C connector, or the like.

  The input device 105 is, for example, a keyboard, a mouse, a touch panel, a button, or a microphone that inputs data. The output device 106 is, for example, a display, a printer, or a speaker that outputs data.

[Patient terminal]
A software configuration example of the patient terminal 10 will be described with reference to FIG.
The patient terminal 10 is a terminal used by a patient, a parent of the parent, and a guardian (hereinafter, some or all of them may be simply referred to as “patient”), and is an example of a first terminal. The patient terminal 10 includes a check-in unit 11, a storage area confirmation unit 12, an encryption key generation unit 13, an encryption key storage unit 14, and an access authority assignment unit 15. However, part of the functions of the patient terminal 10 may be delegated to other components. For example, an alternative node of the block chain 60 may have a function corresponding to the storage area confirmation unit 12.

  The check-in unit 11 checks in and checks out the hospital information system 20 and the pharmacy system 40 according to the operation of the patient. An electronic prescription can be issued by checking in the hospital information system 20. Prior to issuing the electronic prescription, medical treatment (or remote medical treatment) may be performed by a doctor. In addition, by checking in the pharmacy system 40, for example, a pharmacist can refer to and dispense an electronic prescription.

  The storage area confirmation unit 12 checks whether the prescription storage area of the corresponding patient exists in the block chain 60, and if the corresponding prescription storage area does not exist, the necessary prescription storage area is stored in the block chain 60. Generate.

  Specifically, the storage area check is performed by, for example, checking whether or not information specifying a patient (hereinafter referred to as “patient ID”) is stored in the state DB (see FIG. 11). This is performed by causing a computer (hereinafter simply referred to as “node”) to search. The storage area is generated by, for example, broadcasting a transaction including the patient ID to the node. Such transactions are collected into blocks, and the blocks are approved in the block chain 60, so that the corresponding patient ID can be used in the electronic prescription management system 1.

  The encryption key generation unit 13 generates a prescription encryption key and stores it in the encryption key storage unit 14. The prescription encryption key is used for generating a transaction, for example, and includes a public key and a private key unique to the patient.

The access authority granting unit 15 grants and removes the access authority to the prescription storage area of the patient in the block chain 60 for the parties other than the patient (for example, doctors and pharmacists). For example, the access authority granting unit 15 is in the state of the check-in unit 11 (whether checked in the hospital information system 20 for medical examination by a doctor or checked in the pharmacy system 40 for dispensing by a pharmacist). In response, a transaction for granting authority to either the doctor or the pharmacist is output. These transactions correspond to the first and third transactions, respectively. In this embodiment, a doctor ID or a pharmacist ID, which will be described later, is included in a transaction for granting access authority.
The access authority granting unit 15 also deprives the granted access authority. In this embodiment, the access authority is revoked after the accounting process, but may be performed without delay after the prescription data (prescription CDA data) or the dispensing data (dispensing CDA data) is transmitted.

[Hospital Information System]
A software configuration example of the hospital information system 20 will be described with reference to FIG.
The hospital information system 20 is a system responsible for information management of a medical institution, and may include, for example, a telemedicine system, an electronic medical record system, an order entry system, and a medical accounting system. The hospital information system 20 includes a reception unit 21, a patient information storage unit 22, a medical record storage unit 23, a prescription CDA generation unit 24, and an accounting processing unit 25.

  The reception unit 21 receives check-in from the patient terminal 10 and reception input from the doctor terminal 30. When the processing of the reception unit 21 is completed, medical treatment (or remote medical treatment) and prescription issuance by a doctor can be performed. In the present embodiment, it is assumed that patient information such as patient ID, name, and address is stored in the patient information storage unit 22 in advance. You may request input of information.

  The medical record storage unit 23 stores medical record data for each patient based on the input from the doctor terminal 30. Here, it is assumed that the medical record is a document in which a doctor describes the content and progress of a patient's medical care, but may include a wide variety of medical records.

  The prescription CDA generation unit 24 generates and outputs prescription CDA data based on prescription data from the doctor terminal 30. Here, the prescription data includes the patient's name, doctor's name, medical institution's name / address, delivery date, prescription content, and additional information such as insurance information and whether or not to change to generic drugs May be included. Prescription CDA (Clinical Document Architecture) data is a description of prescription data in a predetermined data structure. The predetermined data structure here is assumed to comply with standard rules such as HL7 CDA and HL7 CDA R2 established by the HL7 (Health Level Seven) Association, but the present invention is not limited to this. .

  The accounting processing unit 25 performs accounting processing such as calculation of medical fees and billing based on instructions from the patient terminal 10 and the doctor terminal 30.

[Doctor terminal]
A software configuration example of the doctor terminal 30 will be described with reference to FIG.
The doctor terminal 30 is a terminal used by a doctor and a dentist (hereinafter simply referred to as “doctor”), and is an example of a second terminal. The doctor terminal 30 includes a reception unit 31, a medical record creation unit 32, a prescription issuing unit 33, a prescription CDA storage unit 34, and a prescription CDA transmission unit 35.

  The reception unit 31 performs reception processing on the hospital information system 20. The reception process is performed, for example, by specifying a patient by name or ID.

The medical record creation unit 32 creates medical record data based on the doctor's input and outputs it to the hospital information system 20.
The prescription issuing unit 33 generates prescription data based on the doctor's input and outputs it to the hospital information system 20.

  The prescription CDA storage unit 34 stores prescription CDA data received from the hospital information system 20.

  The prescription CDA transmission unit 35 assigns an electronic signature of the doctor in charge (prescription doctor) to the prescription CDA data and stores it in the block chain 60. However, it is assumed that the access authority to the block chain 60 is given from the patient to the prescriber.

  Specifically, the prescription CDA transmission unit 35 generates a transaction (third transaction) including the patient ID and prescription CDA data, and broadcasts it to the nodes in the block chain 60. If the block containing the transaction is approved in the blockchain 60, the prescription CDA data will be stored in the blockchain 60.

[Pharmacy system]
A software configuration example of the pharmacy system 40 will be described with reference to FIG.
The pharmacy system 40 is a system responsible for information management of the pharmacy, and may include, for example, a dispensing system and a dispensing receptacle (receipt computer). The pharmacy system 40 includes a reception unit 41, a patient information storage unit 42, a prescription storage unit 43, a dispensing CDA generation unit 44, and an accounting processing unit 45.

  The reception unit 41 receives a check-in from the patient terminal 10 and a reception input from the pharmacist terminal 50. When the processing of the reception unit 41 is completed, the pharmacist can acquire prescription data in the block chain 60, dispense, and create dispensing data. In the present embodiment, it is assumed that patient information such as a patient ID, name, and address is stored in the patient information storage unit 42 in advance. You may request input of information.

  The prescription storage unit 43 stores prescription CDA data acquired in the pharmacist terminal 50.

  The dispensing CDA generation unit 44 generates dispensing CDA data based on the dispensing data from the pharmacist terminal 50 and outputs it to the pharmacist terminal 50. Here, the dispensing data includes patient information, dispensing action execution date, dispensing action performer, corresponding prescription information, and dispensing execution information. Dispensing implementation information includes the name and address of the pharmacy, the drug, and the amount of drug dispensed. Dispensing CDA (Clinical Document Architecture) data describes dispensing data in a predetermined data structure. As the predetermined structure here, for example, it is assumed that the above-mentioned standard rules are followed, but the present invention is not limited to this.

  The accounting processing unit 45 performs accounting processing such as calculation and billing of dispensing costs based on instructions from the patient terminal 10 and the pharmacist terminal 50.

[Pharmacist terminal]
A software configuration example of the pharmacist terminal 50 will be described with reference to FIG.
The pharmacist terminal 50 is a terminal used by the pharmacist and is an example of a third terminal. The pharmacist terminal 50 includes a receiving unit 51, a prescription reference unit 52, a dispensing information issuing unit 53, a dispensing CDA storage unit 54, and a dispensing CDA transmission unit 55.

  The reception unit 51 performs reception processing on the pharmacy system 40. The reception process is performed, for example, by specifying a patient by name or ID.

  The prescription reference unit 52 refers to prescription CDA data in the block chain 60. Specifically, the prescription reference unit 52 searches the state DB of the node using the patient ID as a key, and acquires prescription CDA data that has not been dispensed. However, it is assumed that the patient has been given access authority to the block chain 60 by the pharmacist.

The dispensing information issuing unit 53 generates dispensing data based on the input of the pharmacist and outputs it to the pharmacy system 40.
The dispensing CDA storage unit 54 stores the dispensing CDA data received from the pharmacy system 40.

  The dispensing CDA transmission unit 55 stores the dispensing CDA data in the block chain 60. Specifically, the dispensing CDA transmission unit 55 generates a transaction (fourth transaction) including the patient ID and the dispensing CDA data, and broadcasts it to the nodes in the block chain 60. If the block containing the transaction is approved in the block chain 60, the dispensing CDA data will be stored in the block chain 60.

[Blockchain]
The block chain 60 will be described with reference to FIGS.
The block chain 60 corresponds to a data store or database serving as a ledger held by each node in a non-centralized (P2P) network system composed of a plurality of nodes. In this embodiment, an Ethereum type block chain is assumed, but the present invention is not limited to this.

  With reference to FIG. 8 and FIG. 9, the block chain and the transaction will be outlined. In general, in a block chain, a transaction history is expressed as a chain of blocks including a transaction.

  As shown in FIG. 8, each transaction (transaction) includes the hash value of the previous transaction and the public key of the user of the new transaction, and is digitally signed with the encryption key of the user of the original transaction. Information about all transactions is shared across the P2P network. By expressing the transaction in this way, a person other than the user cannot arbitrarily rewrite or delete it without permission of the user of the original transaction, and a third party can objectively confirm the transaction progress.

  As shown in FIG. 9, each block constituting the block chain has a large number of transactions, a special value called a nonce, and a hash of the immediately preceding block. Only a transaction included in a block is recognized as a “correct transaction” and has a “single block chain” throughout the network, so that a consistent transaction history can be shared throughout the network.

Next, with reference to FIG. 10, the structure of a transaction in this embodiment will be described.
Each transaction includes a sender address, a sender signature, and data fields. The sender address is the address of the patient, doctor or pharmacist in the block chain 60, and indicates, for example, a value calculated by applying a hash function to the public key held by these persons. The sender's signature is a signature value (encrypted digest value) indicating the sender.

  The “data” field of each transaction may include patient ID, physician / pharmacist ID, access authority, and CDA data. The data may further include information about the GAS, which may be paid, for example, by an administrator of the electronic prescription management system 1 or a platform provider of the blockchain 60.

  Here, the patient ID is information for identifying a patient. In the present embodiment, the patient ID is assumed to be an address in the block chain 60 for the patient, but may be a unique number assigned to each inhabitant such as a personal number. Similarly, the doctor / pharmacist ID is information for specifying a specific doctor or pharmacist. In the present embodiment, an address on the block chain 60 for the doctor or pharmacist is assumed.

The access authority is information indicating, for each patient, a specific doctor or pharmacist who temporarily grants access to his / her record in the block chain 60, and is indicated by, for example, a doctor ID or a pharmacist ID. If there is no description in the item of access authority, it means that the third party does not have access authority to the patient's record.
CDA data refers to prescription CDA data or dispensing CDA data.

  And the block chain 60 in this embodiment preserve | saves a series of blocks containing the transaction mentioned above, and hold | maintains the state database (DB) for managing the record for every patient.

  The state DB will be described with reference to FIG. 11. This database manages prescription data (prescription CDA data) and dispensing data (dispensing CDA data) for each patient. In the present embodiment, the state DB stores the patient ID in association with prescription CDA data or dispensing CDA data, access authority, and status. Here, the status indicates the progress of prescription and dispensing such as waiting for prescription, prescription, and dispensing.

  When a prescription is issued and dispensed, the state DB is updated through a predetermined procedure. Therefore, by referring to the state DB, it is possible to know the history of prescription and dispensing for the patient. Note that “prescription (dispensing) data 1”, “prescription (dispensing) data 2”, etc. in FIG. 11 are information such as the date, hospital (pharmacy), doctor (pharmacist), etc. included in the prescription CDA data (dispensing CDA data). Shall be identified on the basis of

  Next, state transition of the state DB will be described with reference to FIGS. 12 and 13. Here, attention is focused on the latest record for a specific patient (patient ID: 0001), and other records in the state DB are omitted. Further, it is assumed that the patient terminal 10 stores the IDs of doctors and pharmacists in charge of a predetermined patient, and the doctor terminal 30 of the doctor in charge and the pharmacist terminal 50 of the pharmacist in charge store the IDs of the patients. And

First, the state transition of the state DB at the time of medical care will be described with reference to FIG.
When a predetermined patient checks in the hospital information system 20 via the patient terminal 10, a new record for this patient ID is created in the state DB, the status “waiting for prescription”, the access authority “none”, and the CDA data “none”. Is recorded.

  Next, when a predetermined patient temporarily grants access authority to the doctor in charge of the patient via the patient terminal 10, the ID of the doctor is added to the access authority column of the corresponding record in the state DB. As a result, the doctor terminal 30 operated by the doctor in charge is permitted to access the block chain 60, while a third party other than the doctor in charge continues to be denied access to the block chain 60. Here, the grant of access authority is performed, for example, by the patient terminal 10 broadcasting a transaction including a patient ID and a doctor ID.

  After the diagnosis and prescription creation by the doctor, the doctor terminal 30 accesses the block chain 60 and stores the prescription CDA data in a predetermined patient record. At this time, the status of this record is rewritten to “prescribed”. Here, the prescription CDA data is stored by, for example, the doctor terminal 30 broadcasting a transaction including the patient ID, the doctor ID, and the prescription CDA data. The update of the record is reflected in the block chain 60 when the block including the transaction is approved in the block chain 60.

  When the accounting process ends, the patient terminal 10 deprives the access authority to the doctor. The access authority is revoked, for example, by the patient terminal 10 broadcasting a transaction including the patient ID and the access authority “none”.

  In this way, by granting temporary access authority to his / her records from the patient side to the doctor in charge, the prescription data of the patient is recorded on the block chain 60 from the doctor side while ensuring a secret state as a whole. Is possible.

  Next, the state transition of the state DB at the time of dispensing will be described with reference to FIG. Here, the description will be made on the assumption that new (unprepared) prescription data is recorded in the block chain 60 for the patient.

  When a predetermined patient checks in the pharmacy system 40 via the patient terminal 10 and grants temporary access authority to the pharmacist in charge of the patient, the ID of the pharmacist is displayed in the access authority column of the corresponding record in the state DB. Added. As a result, the pharmacist terminal 50 is permitted to access the block chain 60, while a third party other than the responsible pharmacist is denied access to the block chain 60. Here, the access authority is given by, for example, the patient terminal 10 broadcasting a transaction including a patient ID and a pharmacist ID.

  The pharmacist terminal 50 accesses the block chain 60 and refers to (acquires) the prescription CDA data in the record of the corresponding patient. When a plurality of prescription CDA data is stored in the record of the corresponding patient, the pharmacist terminal 50 refers to at least the prescription CDA data of the undispensed drug, that is, the prescription CDA data corresponding to the status “prescription”. Good.

  When dispensing is performed and new dispensing CDA data is generated, the pharmacist terminal 50 accesses the block chain 60 and additionally stores the new dispensing CDA data. At this time, the status for the prescription CDA data and the new dispensing CDA data is rewritten to “dispensed”. Here, the storage of the dispensing CDA data is performed, for example, by the pharmacist terminal 50 broadcasting a transaction including the patient ID, the pharmacist ID, and the dispensing CDA data.

  When the accounting process ends, the patient terminal 10 deprives the access authority to the pharmacist. The access authority is revoked, for example, by the patient terminal 10 broadcasting a transaction including the patient ID and the access authority “none”.

  By granting temporary access authority to the pharmacist from the patient side in this way, it is possible to refer to prescription data and record dispensing data from the pharmacist side to the block chain 60 while ensuring a secret state as a whole. Become.

[Management procedure of electronic prescription]
With reference to FIG.14 and FIG.15, the management procedure of an electronic prescription is demonstrated.

  With reference to FIG. 14, the issuing procedure of an electronic prescription is demonstrated. This procedure is divided into reception of a diagnosis (STEP 1), implementation of a diagnosis (STEP 2), and completion of a diagnosis (STEP 3).

  In STEP 1, first, the patient terminal 10 and the doctor terminal 30 access the hospital information system 20 in accordance with the examination reservation, and the hospital information system 20 performs reception and patient registration processing. Then, the patient terminal 10 confirms whether or not the prescription encryption key is held, and if not, generates the encryption key.

  Next, the patient terminal 10 checks whether or not a prescription storage area for the patient exists in the block chain 60. The prescription storage area is confirmed by, for example, causing the patient terminal 10 to search the node for the corresponding patient ID. On the other hand, if there is no corresponding prescription storage area, the patient terminal 10 instructs the block chain 60 to generate a prescription storage area for the patient. For example, the patient terminal 10 broadcasts a transaction including a patient ID.

Then, the patient terminal 10 temporarily gives the doctor in charge access authority to the record in the block chain 60. When the grant of access authority to the doctor in charge is approved in the block chain 60, the doctor in charge can access the patient's record in the block chain 60.
As a result, the processing of STEP1 is completed, and the processing proceeds to STEP2.

  In STEP 2, after the medical examination and medical record creation by the doctor, the doctor terminal 30 stores the medical record data in the hospital information system 20 and then instructs the hospital information system 20 to generate prescription CDA data. This generation instruction includes information on the contents of the prescription.

  The hospital information system 20 generates prescription CDA data based on a predetermined rule according to the generation instruction and outputs the prescription CDA data to the doctor terminal 30. Of course, the hospital information system 20 may store prescription CDA data in its own storage device.

  The doctor terminal 30 stores the received prescription CDA data in its own storage device and saves it in the block chain 60, and STEP2 ends. The prescription CDA data is stored in the block chain 60 by, for example, the doctor terminal 30 broadcasting a transaction including a patient ID and prescription CDA data. Even if a doctor without access authority broadcasts a transaction from the terminal, the transaction is discarded without being incorporated into a block.

  Next, in STEP 3, the hospital information system 20 performs a medical fee accounting process based on instructions from the patient terminal 10 and the doctor terminal 30. At the same time, the patient terminal 10 removes the access authority given to the doctor in charge, and STEP 3 ends.

  In this way, by giving the doctor in charge a temporary access right to a predetermined patient record in a timely manner, the doctor can add prescription data to the block chain 60 while maintaining confidentiality. In both face-to-face medical treatment and telemedicine, it is possible to issue an electronic prescription by operating the patient terminal 10 during or after a medical examination, for example.

  Next, the dispensing procedure will be described with reference to FIG. This procedure is divided into dispensing acceptance (STEP 1), dispensing implementation (STEP 2), and dispensing termination (STEP 3).

  In STEP 1, first, the patient terminal 10 and the pharmacist terminal 50 access the pharmacy system 40, and the pharmacy system 40 performs reception and patient registration processing.

  The patient terminal 10 confirms whether or not the prescription encryption key is held, and if so, grants access authority to the own record in the block chain 60 to the responsible pharmacist. On the other hand, when the prescription encryption key is not held, since the electronic prescription has not been issued, the patient terminal 10 terminates the process and displays, for example, a paper prescription to go to the pharmacy.

  In this way, when provision of temporary access authority to the responsible pharmacist is approved in the block chain 60, the responsible pharmacist can access the patient's record in the block chain 60.

  The pharmacist terminal 50 accesses the block chain 60, references (acquires) prescription CDA data regarding the corresponding patient, and STEP1 ends. Here, the pharmacist terminal 50 may refer only to prescription CDA data that can be dispensed, or may refer to a list including dispensed prescription data and dispensing data. When there is no prescription CDA data that can be dispensed, that is, when only prescription CDA data in which the corresponding dispensing CDA data is recorded or prescription CDA data that has expired is recorded, the pharmacist terminal 50 A notification to that effect may be received from the block chain 60. Again, it goes without saying that access to the block chain 60 by a pharmacist who does not have access authority is not permitted.

  In STEP 2, after the pharmacist prepares dispensing and dispensing information, the pharmacist terminal 50 instructs the pharmacy system 40 to start dispensing information processing and generate dispensing CDA data. This generation instruction includes information indicating the contents of dispensing.

  The pharmacy system 40 generates dispensing CDA data in accordance with this generation instruction and outputs it to the pharmacist terminal 50. Of course, the pharmacy system 40 may store the dispensing CDA data in its own storage device.

  The pharmacist terminal 50 stores the received dispensing CDA data in its own storage device and saves it in the block chain 60, and STEP2 ends. Even if the pharmacist outputs a transaction without access authority, the transaction is discarded without being incorporated into a block.

  In STEP 3, the pharmacy system 40 performs a dispensing cost accounting process based on instructions from the patient terminal 10 and the pharmacist terminal 50. At the same time, the patient terminal 10 removes the access authority given to the responsible pharmacist, and STEP 3 ends.

  In this way, the pharmacist can refer to prescription data and add the dispensing data to the block chain 60 while maintaining confidentiality by giving the responsible pharmacist temporary access to the record of a given patient in a timely manner. It is possible.

  As described above, in this embodiment, an electronic prescription management system capable of actual operation can be provided. In addition, complicated systems such as prescription ID issuance processing, electronic prescription exchange certificate issuance processing, and electronic prescription invalidation processing, which are required for electronic prescription management systems using ASP servers, are no longer required. A configuration can be employed.

  Moreover, since the patient's prescription information is managed by the P2P network system, it is more resistant to failures than the management by the ASP server.

  In the electronic prescription management system 1, the patient in an environment where the prescription encryption key cannot be generated and held is not subjected to the electronic prescription processing, and the conventional paper-based processing is performed. In other words, this system can be used in conjunction with the operation of paper prescriptions.

  As mentioned above, although typical embodiment of this invention was described, this invention is not limited to these, A various design change is possible and they are also contained in this invention.

  In the present embodiment, the doctor terminal 30 outputs a transaction including prescription CDA data. However, the doctor terminal 30 includes, for example, prescription data itself or prescription CDA data output to a PDF file in the transaction. May be output. Similarly, for example, the pharmacist terminal 50 may output the dispensing data itself or the dispensing CDA data output in a PDF file as a transaction.

  In the present embodiment, the doctor terminal 30 outputs the prescription data (prescription CDA data) to the block chain 60. However, the doctor terminal 30 receives the prescription data via the hospital information system 20 or the data transmission subsystem. May be output. Similarly, the pharmacist terminal 50 may acquire prescription data (prescription CDA data) via the pharmacy system 40 or a data transmission subsystem, and output dispensing data (dispensing CDA data).

  In addition, the patient terminal 10, the hospital information system 20, the doctor terminal 30, the pharmacy system 40, and the pharmacist terminal 50 are each connected to the block chain 60 via an API (Application Programming Interface) server that performs signature on behalf of these users. May be.

  In this embodiment, the access authority to the doctor or the pharmacist is deprived by transmitting a transaction from the patient terminal 10. For example, an access authority effective only for a predetermined time (for example, 30 minutes, 1 hour, etc.) is given. By doing so, the act of depriving access authority may be omitted.

  When the block chain 60 stores the dispensing data (dispensing CDA data) from the pharmacist terminal 50 in the database, the block chain 60 transmits the dispensing data to the doctor terminal 30 of the doctor in charge or the hospital information system 20 with the consent of the patient. May be.

1 ... Electronic prescription management system,
10 ... Patient terminal,
20 ... Hospital information system,
30: Doctor terminal,
40 ... Pharmacy system,
50 ... pharmacist terminal,
60: Block chain.

Claims (7)

A blockchain database that stores prescription data in association with patients,
Receiving from a first terminal operated by a given patient a first transaction granting temporary access to the given patient's record in the blockchain database of a physician in charge of the given patient;
Storing the prescription data included in the second transaction output from the second terminal operated by the doctor who has been granted the access authority in association with the predetermined patient;
The electronic prescription management method characterized by including. Receiving from the first terminal a third transaction granting temporary access to the record of the predetermined patient in the blockchain database of a pharmacist in charge of the predetermined patient;
Allowing the third terminal operated by the pharmacist to which the access authority has been granted to refer to the prescription data relating to the predetermined patient;
Storing the dispensing data included in the fourth transaction output from the third terminal in association with the predetermined patient;
The electronic prescription management method according to claim 1, further comprising: A blockchain database that stores prescription data in association with patients,
A first terminal that outputs a first transaction that permits temporary access to the record of the predetermined patient in the blockchain database of a doctor in charge of the predetermined patient in response to a patient operation;
A second terminal for outputting a second transaction including the prescription data in response to the operation of the doctor,
The blockchain database stores the prescription data included in the second transaction output from the second terminal corresponding to the doctor who has been granted the access right in association with the predetermined patient;
Electronic prescription management system characterized by In response to the patient operation, the first terminal outputs a third transaction allowing a temporary access authority to the record of the predetermined patient in the block chain database of a pharmacist in charge of the predetermined patient. And
The electronic prescription management system further includes a third terminal that outputs a fourth transaction including a reference request for the prescription data or dispensing data in response to an operation of a pharmacist,
The block chain database permits the third terminal corresponding to the pharmacist to which the access authority has been granted to refer to the prescription data relating to the predetermined patient, and to the fourth transaction output from the third terminal. Storing the included dispensing data in association with the predetermined patient;
The electronic prescription management system according to claim 3. Access to a blockchain database that stores prescription data associated with a patient, and for a terminal operated by a given patient,
A transaction for granting the doctor access authority to the record of the predetermined patient in the blockchain database at the time of medical examination by the doctor, and the pharmacist at the time of dispensing by the pharmacist in charge of the predetermined patient Outputting a transaction for granting the access authority to the record to the block chain database, respectively,
When the examination and the dispensing are finished, respectively, outputting a transaction for depriving the granted access authority to the block chain database;
A program that executes For doctor terminals that can communicate with a blockchain database that stores prescription data in association with patients,
Obtaining prescription data for a given patient in response to a physician operation;
Outputting a transaction including the prescription data for the predetermined patient to the blockchain database with temporary access to the predetermined patient record in the blockchain database;
A program that executes For pharmacist terminals that can communicate with a blockchain database that stores prescription data in association with patients,
With temporary access to the given patient record in the blockchain database,
Requesting the blockchain database to reference the prescription data for a given patient;
Obtaining dispensing data relating to the predetermined patient in response to a pharmacist operation;
Outputting a transaction including the dispensing data for the given patient to the blockchain database;
A program that executes