KR102549812B1 - Clinical pathway design method using smart contract - Google Patents

Abstract

A standard treatment guideline generation method using a smart contract includes steps in which terminals for attempting to develop a standard treatment guideline for a specific disease participate in a contract for attempting to develop a standard treatment guideline using a smart contract, and the terminals use a smart contract to develop the specific disease Storing order information including the contents of the hospital's orders and the number of orders for each order in the blockchain, wherein the terminals add up each of the individual orders constituting the order information from the blockchain Receiving the number of uses, the terminals using the number of uses for each order to store standard practice guideline candidates and matching rates for each of the candidates in the blockchain, the terminals storing the standard care guideline candidates from the block chain Receiving summed matching rate information for guideline candidates, and generating, by the terminals, a final standard treatment guideline based on the summed matching rate information for each of the standard treatment guideline candidates.

Description

Method of generating standard treatment guidelines using smart contract {CLINICAL PATHWAY DESIGN METHOD USING SMART CONTRACT}

The technology to be described below relates to a method of generating a standard treatment guideline using a block chain.

Medical information is information related to the health of patients and, at the same time, personal information, so it must be safely managed. Therefore, many countries are forcing the safe storage and management of medical information through legal regulations.

Clinical pathway (CP) refers to standardization of the treatment and medications that patients receive by guiding them. Standard practice guidelines have the advantage of improving the efficiency of the treatment process, reducing costs, and improving patient satisfaction. Due to these advantages, the Ministry of Health and Welfare is implementing a policy of developing standard treatment guidelines for frequent diseases and distributing them to local hospitals and private medical centers.

Korean Patent Publication No. 10-2020-0034062

In the medical field, due to legal regulations, there are restrictions on sharing and utilizing data to conduct research and develop new medical services. Therefore, a system capable of developing standard treatment guidelines without exposing personal information is required.

The technology described below uses blockchain smart contracts to collect essential information of each hospital without exposing personal information so that each hospital can determine the most appropriate standard treatment guidelines for the disease.

A standard treatment guideline generation method using a smart contract includes steps in which terminals for attempting to develop a standard treatment guideline for a specific disease participate in a contract for attempting to develop a standard treatment guideline using a smart contract, and the terminals use a smart contract to develop the specific disease Storing order information including the contents of the hospital's orders and the number of orders for each order in the blockchain, wherein the terminals add up each of the individual orders constituting the order information from the blockchain Receiving the number of uses, the terminals using the number of uses for each order to store standard practice guideline candidates and matching rates for each of the candidates in the blockchain, the terminals storing the standard care guideline candidates from the block chain Receiving summed matching rate information for guideline candidates, and generating, by the terminals, a final standard treatment guideline based on the summed matching rate information for each of the standard treatment guideline candidates.

The technology described below solves the problem of leakage of medical information, and has the advantage that all hospitals can check meta information and parameters exchanged by hospitals, so that anyone can verify whether standard treatment guidelines have been accurately developed.

1 is an example of a system for developing a standard practice guideline.
Figure 2 is an example of a smart contract that manages standard practice guideline development attempts.
3 is an example of a participation process of actors for the development of standard practice guidelines.
4 is an example of order information collection process for standard practice guideline development.
5 is an example of a standard treatment guideline generation process using collected information.

Since the technology to be described below can have various changes and various embodiments, specific embodiments will be illustrated in the drawings and described in detail. However, this is not intended to limit the technology described below to specific embodiments, and it should be understood to include all modifications, equivalents, or substitutes included in the spirit and scope of the technology described below.

Terms such as first, second, A, B, etc. may be used to describe various elements, but the elements are not limited by the above terms, and are merely used to distinguish one element from another. used only as For example, without departing from the scope of the technology described below, a first element may be referred to as a second element, and similarly, the second element may be referred to as a first element. The terms and/or include any combination of a plurality of related recited items or any of a plurality of related recited items.

In terms used in this specification, singular expressions should be understood to include plural expressions unless clearly interpreted differently in context, and terms such as “comprising” refer to the described features, numbers, steps, operations, and components. , parts or combinations thereof, but it should be understood that it does not exclude the possibility of the presence or addition of one or more other features or numbers, step-action components, parts or combinations thereof.

Prior to a detailed description of the drawings, it is to be clarified that the classification of components in the present specification is merely a classification for each main function in charge of each component. That is, two or more components to be described below may be combined into one component, or one component may be divided into two or more for each more subdivided function. In addition, each component to be described below may additionally perform some or all of the functions of other components in addition to its main function, and some of the main functions of each component may be performed by other components. Of course, it may be dedicated and performed by .

In addition, in performing a method or method of operation, each process constituting the method may occur in a different order from the specified order unless a specific order is clearly described in context. That is, each process may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

First, terms used in the following description will be briefly described.

Standard practice guideline (CP) is a standardized treatment process that pre-determines the order and time of treatment so that each hospital can provide appropriate treatment for a specific disease. . That is, the standard treatment guidelines are prepared for each specific disease, but the description below does not limit the specific disease.

An order means a doctor's procedure order or instructions constituting CP. An order can generally be defined as a series of order sets. For example, the Odo set may include information such as the number of hospital stays before and after surgery, types of prophylactic antibiotics before surgery and number of days of administration, oral/injection medicines, nutritional supplements, bowel preparation, and number of days of discharge medicine prescription. Thus, an order set may consist of a sequence of information from the start of a patient treatment to the end.

Briefly explain the blockchain technology.

Blockchain refers to a distributed digital ledger that discloses the contents to all transaction participants, unlike the existing method of storing records in a centralized server when transacting data. It can be said to be a storage platform designed to make it difficult for a specific person to manipulate arbitrarily by all members participating in the blockchain verifying and storing data with each other through the network. Through this mutual distributed ledger, high security, scalability, and transparency are guaranteed beyond the existing centralized network-based infrastructure.

The characteristic of blockchain is that transaction records are organized in units called 'blocks' and are linked over time. One block contains connection information that connects the previous block and the next block, and if the content of the previous block is changed, all subsequent blocks must be regenerated. Therefore, it is difficult to manipulate the contents of past blocks.

A blockchain is a distributed ledger structure, and everyone who participates in the blockchain network owns a ledger that records all transactions. Therefore, when using blockchain technology, there is an advantage in that system maintenance costs are low and hacking can be prevented at the source because it is operated by the blockchain, a decentralized ledger without a separate transaction management institution. In a distributed ledger environment, when a user requests a certain transaction, a block in which transaction information is recorded is created and the block is transmitted to all participants on the network. At this time, when each participant approves the transmitted block, the transaction is completed as the transaction record is added to the existing block chain. For example, in order to modify the transaction information contained in the existing block chain, it is virtually impossible for hackers to simultaneously hack the block chains of network participants around the world because a majority of all block chain network participants must confirm that the information is the same.

The blockchain uses a consensus algorithm to review the legitimacy of blocks created by each node and reflect them on the blockchain shared across the network. Representative consensus algorithms used in blockchain include Proof of Work (PoW), Proof of Stake (PoS), and Practical Byzantine Fault Tolerance (PBFT).

A blockchain is a decentralized, distributed computer system formed from immutable blocks that result in transactions. Each block contains a hash of the previous block, so the blocks are linked together to create a record of all transactions recorded on the blockchain from its inception. Transactions contain small programs known as scripts that contain inputs and outputs, which specify how or by whom the transaction's outputs can be accessed.

Blockchain 1.0 was the main function of issuing, distributing and trading digital currency. Blockchain 2.0 is evolving with the goal of overcoming the limitations of the existing Bitcoin and expanding into various areas. The representative technology of block chain 2.0 is Ethereum, which implements smart contracts that make the transaction script of bitcoin programmable in various forms along with the function of digital currency. The technology described below also uses smart contracts. Therefore, the blockchain structure may be based on Ethereum. However, in the technology described below, a blockchain capable of executing smart contracts is sufficient without limiting the type of blockchain.

1 is an example of a system 100 for developing standard practice guidelines.

The system 100 includes hospital-side terminals 110, 120, and 130 participating in the development of standard practice guidelines. FIG. 1 merely illustrates three hospital terminals for convenience of description. Hereinafter, the terminal 110 of the hospital leading the development of the standard practice guideline will be referred to as the host terminal 100. In addition, the terminals 120 and 130 of hospitals participating in the development of standard practice guidelines are referred to as participating terminals.

The terminal 110, 120, or 130 of each hospital may obtain order information for a specific disease from the electronic medical record (EMR) of the hospital. 1 illustrates only the EMR 105 for the host device 110 as an example.

The host terminal 110 creates a contract for starting the development of standard treatment guidelines, and when the contract is created, participants participating in the development trial are recruited, and then each terminal participating in the development trial transmits order information for the corresponding disease to a block chain ( 150) to save.

The block chain 150 uses a pre-built smart contract to set participants, collect order information, and generate information on the number of orders for the disease. 1 illustrates one node 155 constituting the blockchain 150 as an example. A node 155 may be an object such as a computer device, server, or the like. The smart contract generates constant matching rate information based on the number of times specific orders are used and delivers it to each terminal (110, 120, 130), and each terminal (110, 120, 130) determines the final match based on the received information. Standard practice guidelines are created.

One virtual machine shared by the nodes of the blockchain network can perform a certain operation (state change) according to a certain consensus algorithm. For example, in the case of Ethereum, the blockchain constitutes the Ethereum Virtual Machine (EVM). EVM is the runtime environment for Ethereum smart contracts. The EVM can execute smart contracts held by blocks.

A detailed description related to the generation of standard practice guidelines will be described later.

2 is an example of a smart contract 200 that manages standard practice guideline development attempts.

Participant Contract (PC, 210) is a contract that manages the blockchain address (addr) and public key information (pubkey) of certified hospitals. In addition to the address and public key, the PC 210 may also store additional information related to the hospital in the corresponding smart contract. The PC 210 may have a function called registerHos for registering a new participating hospital, and this function may be called only through the government or an authorized certification authority.

The development trial contract (Trial Contract, TC, 220) governs the development trial of standard practice guidelines. Therefore, the TC 220 includes the trial identifier (ID), the address of the hospital that hosted the development trial (addr_host), the name of the target disease (disease), and the standard practice guidelines (CP) obtained as a result after the development trial. , may retain the version of the standard practice guideline. In addition, the TC 220 may store an ID (prevTrial) of a previous trial when developing an existing version of the association standard treatment guideline, if the standard treatment guideline was jointly developed by upgrading the version.

Furthermore, the TC 220 determines the limit time (endTime) for new participants to participate in the development attempt, whether the development trial is seeking participants, merging the number of orders, and merging the matching rate (state) ), and stores the address (addr_TDC) of the Trial Detail Contract containing the detailed information of the trial.

A host device that wants to host federated development can create a new development trial through the createTrial function. Terminals of other hospitals that want to participate in joint development can participate in the development trial by using the engageTrial function. When the development trial time limit has elapsed, the host terminal can use the startTrial function to prevent hospitals from participating any more and start the development trial. The terminals of each hospital can call the regOrderCount function and store the information on the number of orders necessary for developing the standard practice guideline. In addition, the terminals of each hospital may call a regMatchingRate function and store matching rate information for standard practice guideline candidates.

Trial Detail Contract (TDC, 230). TDC (230) manages the detailed information of the development attempt. Specifically, the TDC 230 includes the number of medical information held by each hospital (addr_hos - lognum), the number of hospitals participating in the development attempt (memNum), the number of hospitals that have completed sharing the number of orders (orderRegNum), and the hospitals that have completed sharing the matching rate. It manages the number of shared orders (MRRegNum), a collection of shared orders (orders), the number of uses for each order in which shared orders are collected (order - count), and matching rate information (seqIndex - MR) for each CP candidate. The TDC 230 has an addHospital function used when adding a hospital when the hospital terminal calls engageTrial of the TC 220 and a storeOrderCount function used to store order information when the TC 220 calls regOrderCount. In addition, the TDC 230 has a storeMR function used to store matching rate detailed information when terminals of hospitals call regMatchingRate of the TC 220 .

3 is an example of a participation process 300 of subjects for the development of standard practice guidelines.

The host device 110 is a device used by a host hospital that wants to develop an association standard treatment guideline. The host device 110 distributes the trial detailed contract (TDC) to the blockchain 150 (depolyTDC, 301), and receives the address (addr _TDC ) of the smart contract returned (302).

The host device 110 creates a new development trial in the trial contract (TC, 151) by using the address of the corresponding TDC (311). The host device 110 may create a development trial using the createTrial() function. At this time, the host device 110 includes the blockchain address (addr _host ) of the host (hosting hospital), the address of the distributed TDC (addr _TDC ), the name of the disease to be developed as a standard treatment guideline (disease), and the recruitment of participants in the development trial ends. The time (endTIME) can be used as a factor. When creation is completed, the host device 110 receives a trial ID (trialID) returned (312).

The host device 110 transfers the attempt ID to the participating device 120 that wants to participate (321). Although FIG. 3 shows one participating terminal 120 for convenience of explanation, a trial ID may be delivered to a plurality of participating terminals in the same process so that they may participate in the development trial. The host device 110 may transmit the trial ID to the participating device 120 through an external channel such as mail.

Among the hospitals, the hospital(s) wishing to develop an allied CP for the disease participate in CP development. In this case, the participating terminal 120 may participate in the development trial by calling the engageTrial() function (3310). The participating terminal 120 may utilize the trial ID (ID), the blockchain address (addr _hos ) of the person (hospital to participate), and the number of data (lognum) possessed by the person as factors (331).

TC (151) checks whether the time (now) of receiving the participation intention is before the participation end time (endTime) (check now≤endTIME) (341), and determines whether the hospital is already participating from the participant contract (PC, 153) Confirmation information (isExist()) may be acquired (351).

If the current point is before the participation end time, and the hospital desired to participate has not yet participated in the provincial development, the TC stores the address (addr _hos ) and the number of data (lognum) of the hospital in the TDC (addHospital()) and (361 ), and receives feedback on whether or not the storage is successful (362).

When the participating hospital successfully participates in the development attempt, the participating terminal 120 receives the TDC address (addr _TDC ) returned (371).

4 is an example of order information collection process 400 for standard practice guideline development.

The host device 110 continuously checks whether the current point in time is after the participation end time (endTime) (now>endTime) (401).

When the participation end time elapses, the host device 110 calls the startTrial () function for the development trial ID (411), and the host device 110 generates an event (trialStartedEvent) indicating that the development attempt has started from the TC 151. Receive (412). In addition, the participating terminal 120 also receives an event (trialStartedEvent) indicating that the development attempt has started (413).

When receiving the development attempt start event, the host device 110 extracts the order used from the medical information held by the user and the number of times each order is used by using the getOrderCount() function (421). Upon receiving the development trial start event, the participating terminal 120 extracts the order utilized from the medical information held by the participants and the number of times each order is used using the getOrderCount() function (422).

The host device 110 calls the regOrderCounts() function to register orders for the corresponding disease and counts of each order in the TC 151 for the corresponding development attempt ID (431). The participating terminal 120 also calls the regOrderCounts() function to register orders for the corresponding disease and counts of each order in the TC 151 for the corresponding development attempt ID (432).

The TC 151 calls the storeOrderCounts function collected for the corresponding development attempt ID, and transmits the extracted orders and the number of uses per order (counts) to the TDC 152 to be stored (441).

The TDC (152) first checks whether the terminal that sent the factor is the hospital that expressed its intention to participate, and if it is the participating hospital, the TDC (152) adds the number of uses per order to the order-count variable and increases OrderRegNum by 1 (451) . The order-count variable accumulates and holds the number of orders for the disease. OrderRegNum represents the number of participating hospitals sending order information.

If OrderRegNum is equal to the number (memNum) of hospitals that have expressed their intention to participate, the TC 151 transmits an order count completion event (orderCountCompletedEvent) to the terminal of the corresponding hospital (462 and 463). Upon receiving the corresponding event, the terminals 110 and 120 of the hospital fetch order-count information from the TDC 152 and arrange them in order of high frequency of use (481 and 482). Through this, the order in use in all hospitals is obtained by sorting the number of times of use.

Assume that the order of the orders finally sorted in the process of FIG. 4 is {A, B, C, D, E}. 5 is an example of a standard treatment guideline generation process 500 using collected information. Each of the terminals 110 and 120 of the hospital selects standard practice guideline candidates according to the order of the sorted final orders: {A} (seqIndex 1), {A, B} (seqIndex 2), {A, B, C} ( seqIndex 3), {A, B, C, D} (seqIndex 4) and {A, B, C, D, E} (seqIndex 5), and the matching rate for each standard practice guideline candidate MR) is calculated (501 and 502).

The host device 100 and the participating device 120 call the regMRs function for the corresponding development attempt ID using the calculated standard practice guideline candidates (seqIndex) and the match ratios (MRs) calculated for the candidate as factors, respectively ( 511 and 512).

The TC 151 transfers the received factors to the TDC (521). At this time, the TC 151 calls the storeMR function to deliver the matching ratio (MR) for standard practice guideline candidates (seqIndex) received from each terminal.

The TDC 152 may check whether the terminal that has delivered the match ratio (MR) for the standard practice guideline candidates (seqIndex) is the hospital participating in the development attempt. The TDC (152) adds a matching ratio to seqIndex - MR, and increases MRRegNum by 1 if it is correct whether the hospital that sent the factor is a hospital that expressed its intention to participate (522). seqIndex - MR accumulates and stores matching rates for each standard practice guideline candidate in all hospitals that participated in the standard practice guideline development. MRRegNum represents the number of subjects that sent matching rates for seqIndex.

The TC 151 transmits a matching rate registration event (MRRegisteredEvent) to the terminals 110 and 120 of the hospital if MRRegNum is equal to the number of hospitals (memNum) that have expressed their intention to participate (541 and 542).

Each of the terminals 110 and 120 of the hospitals receiving the event brings seqIndex-MR from the TDC 152 (551 and 552). Each of the terminals 110 and 120 of the hospitals sorts the matching rates of the final standard practice guideline candidates and derives the seqIndex with the highest matching rate (561 and 562). For example, assuming that seqIndex 4 has the highest matching rate, the order of the final standard treatment guideline for the disease is {A, B, C, D}.

Hospitals participating in the development of standard treatment guidelines derive standard treatment guidelines for specific diseases using the aforementioned smart contract and blockchain.

In addition, the standard treatment guideline development method and standard treatment guideline generation method for a specific disease as described above may be implemented as a program (or application) including an executable algorithm that can be executed on a computer. The program may be stored and provided in a temporary or non-transitory computer readable medium.

A non-transitory readable medium is not a medium that stores data for a short moment, such as a register, cache, or memory, but a medium that stores data semi-permanently and can be read by a device. Specifically, the various applications or programs described above are CD, DVD, hard disk, Blu-ray disk, USB, memory card, ROM (read-only memory), PROM (programmable read only memory), EPROM (Erasable PROM, EPROM) Alternatively, it may be stored and provided in a non-transitory readable medium such as EEPROM (Electrically EPROM) or flash memory.

Temporary readable media include static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), and enhanced SDRAM (Enhanced SDRAM). SDRAM, ESDRAM), Synchronous DRAM (Synclink DRAM, SLDRAM) and Direct Rambus RAM (DRRAM).

This embodiment and the drawings accompanying this specification clearly represent only a part of the technical idea included in the foregoing technology, and those skilled in the art can easily understand it within the scope of the technical idea included in the specification and drawings of the above technology. It will be obvious that all variations and specific examples that can be inferred are included in the scope of the above-described technology.

Claims (6)

Steps of terminals participating in a standard practice guideline development trial contract for a specific disease using a smart contract;
storing, by the terminals, order information including contents of orders of the corresponding hospital for the specific disease and the number of times of each order in a blockchain using a smart contract;
Receiving, by the terminals, the summed number of uses for each of the individual orders constituting the order information from the blockchain;
storing, by the terminals, standard practice guideline candidates and a matching rate for each of the candidates in the blockchain by using the number of times of use for each individual order;
receiving, by the terminals, information on matching rates combined with respect to the standard practice guideline candidates from the block chain; and
Generating, by the terminals, a final standard treatment guideline based on the summed matching rate information for each of the standard treatment guideline candidates. According to claim 1,
A method of generating standard medical guidelines using a smart contract in which a host terminal among the terminals sets a time limit for participating in the development attempt, and the order information is collected after the time limit has elapsed. According to claim 1,
The block chain collects order information delivered by the terminals using a smart contract and calculates the summed number of uses for each of the individual orders. According to claim 1,
The terminals sort the individual orders based on the total number of uses for each of the individual orders, and use a smart contract to determine the standard practice guideline candidates by considering all possible cases based on the results of the sorted orders. How to create standard practice guidelines. According to claim 1,
The blockchain collects matching rates for the standard treatment guideline candidates delivered by the terminals using smart contracts, and generates standard treatment guidelines using smart contracts to calculate the combined matching rate for each of the standard treatment guideline candidates. method. According to claim 1,
The standard treatment guideline generation method using a smart contract in which the terminals determine a candidate having the highest summed matching rate information among the standard treatment guideline candidates as the final standard treatment guideline.

Images