Decentralized prescription refilling

Abstract

Example operations may include one or more of the following operations: receiving, by a pharmacy node, a request for a prescription refill from a patient node, the request including a secret key of the patient; extracting, by the pharmacy node, the secret key from the request to verify the identity of the patient; and executing, by the pharmacy node, a smart contract to: (a) decrypt prescription data located on a ledger by applying the secret key; (b) retrieve the patient's allergy record from the ledger to check the allergy record against the prescription data; (c) determine a quantity of refills remaining based on the prescription data; (d) check the validity of the prescription data based on an expiration date; and based on successful execution of (b)‑(d), submitting a prescription refill transaction to the blockchain.

Description

Technical Field

[0001] The present application relates generally to database storage systems and, more particularly, to decentralized prescription refill. Background Art

[0002] A centralized database stores and maintains data in a single database (e.g., a database server) located in one location. The location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database can typically be accessed from multiple different points. Multiple users or client workstations can work on the centralized database simultaneously, for example, based on a client / server configuration. A centralized database is easy to manage, maintain, and control because of its single location, especially for security purposes. In a centralized database, data redundancy is minimized because a single storage location for all data also means that there is only one master record for a given set of data.

[0003] However, there are obvious disadvantages of centralized databases. For example, centralized databases have a single point of failure. In particular, if there is no fault tolerance consideration and a hardware failure (e.g., hardware, firmware, and / or software failure) occurs, all data in the database will be lost and the work of all users will be interrupted. In addition, centralized databases are highly dependent on network connections. Therefore, the slower the connection, the amount of time required for each database access will increase. Another disadvantage is that bottlenecks occur when centralized databases experience high traffic due to a single location. In addition, centralized databases provide limited access to data because the database maintains only one copy of the data. Therefore, multiple devices cannot access the same piece of data at the same time without causing major problems or without the risk of overwriting the stored data. In addition, because the database storage system has little or no data redundancy, accidentally lost data is difficult to recover from backup storage unless manually operated.

[0004] Traditionally, centralized databases are limited by low search capabilities, lack of security, and slow transaction speeds. Therefore, a blockchain-based solution is needed to overcome these significant drawbacks.

[0005] Getting medications when traveling abroad or in an unfamiliar place can be difficult and expensive. People traveling abroad sometimes forget to buy medications for their upcoming trip, or may run out of medications during their trip, or may lose their medications. People may rush before a trip and end up paying more for their medications. In some cases, a person may even decide to travel without medications, which can put his or her health at risk. When medications are not available over the counter, getting prescriptions refilled becomes expensive and time-consuming because in different countries or places the patient is unfamiliar with, some medications may require a doctor's visit to obtain a prescription. Additionally, while a particular medication may be available over the counter in some places, it may be restricted in another. For example, in Canada, Piralvex TM It is possible to purchase it over the counter, whereas in the United States, such medications require a prescription. Therefore, even if a traveler has carefully planned a trip, he or she may still encounter problems when trying to purchase a medication that they initially thought was available over the counter. In situations where the medication is available over the counter in the destination country, even though a prescription is required in the home country, it is still desirable to have a system that informs the traveler about the availability over the counter. It is important to ensure that people can obtain medications in a timely manner at the lowest cost without risking their health or causing hassles. For example, someone who needs insulin, asthma inhalers, salbutamol, or even birth control pills should be able to obtain their medications without any problems even when they are abroad.

[0006] Therefore, it is expected that blockchain will be used as a way to securely process information related to health insurance, medical conditions, allergies and provide the required identification mechanism to prove the patient's identity so that travelers can easily refill their prescriptions when they travel abroad or to unfamiliar places. Summary of the invention

[0007] An example embodiment provides a system comprising a processor and a memory, wherein the processor is configured to perform one or more of the following operations: receive a request for a prescription refill from a patient node, the request comprising a secret key of the patient; extract the secret key from the request to verify the identity of the patient; and execute a smart contract to: (a) decrypt prescription data located on a ledger by applying the secret key, (b) retrieve the patient's allergy record from the ledger to check the allergy record against the prescription data, (c) determine the number of refills remaining based on the prescription data, (d) check the validity of the prescription data based on an expiration date, and submit the prescription refill transaction to a blockchain based on successful execution of (b)-(d).

[0008] Another example embodiment provides a method comprising one or more of the following operations: receiving, by a pharmacy node, a request for a prescription refill from a patient node, the request comprising a secret key of the patient; extracting, by the pharmacy node, the secret key from the request to verify the identity of the patient; and executing, by the pharmacy node, a smart contract to: (a) decrypt prescription data located on a ledger by applying the secret key, (b) retrieve the patient's allergy record from the ledger to check the allergy record against the prescription data, (c) determine a quantity of refills remaining based on the prescription data, (d) check the validity of the prescription data based on an expiration date, and submitting the prescription refill transaction to a blockchain based on successful execution of (b)-(d).

[0009] Yet another example embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following operations: receive a request for a prescription refill from a patient node, the request comprising a secret key of the patient; extract the secret key from the request to verify the identity of the patient; and execute a smart contract to: (a) decrypt prescription data located on a ledger by applying the secret key, (b) retrieve the patient's allergy record from the ledger to check the allergy record against the prescription data, (c) determine the number of refills remaining based on the prescription data, (d) check the validity of the prescription data based on an expiration date, and submit the prescription refill transaction to a blockchain based on successful execution of (b)-(d). BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A network diagram of a system including a ledger database according to an example embodiment is shown.

[0011] Figure 2A An example peer node configuration is shown according to an example embodiment.

[0012] Figure 2B Another peer node configuration according to an example embodiment is shown.

[0013] Figure 3 A permission network according to an example embodiment is shown.

[0014] Figure 4A A flow chart according to an example embodiment is shown.

[0015] Figure 4B Another flow chart according to an example embodiment is shown.

[0016] Figure 5A An example system configured to perform one or more operations described herein is shown in accordance with an example embodiment.

[0017] Figure 5BAnother example system configured to perform one or more operations described herein is shown in accordance with an illustrative embodiment.

[0018] Figure 5C A smart contract configuration between contracting parties and an intermediary server configured to enforce the terms of the smart contract on a blockchain are shown according to an example embodiment.

[0019] Figure 5D Another additional example system according to an example embodiment is shown.

[0020] Fig. 6A A process of adding new data to a database according to an example embodiment is shown.

[0021] Figure 6B The contents of a data block including new data according to an example embodiment are shown.

[0022] Figure 7 An example system is shown that supports one or more of the example embodiments. DETAILED DESCRIPTION

[0023] It is readily understood that the present components as generally described and illustrated in the figures herein may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of embodiments of at least one of the methods, devices, non-transitory computer-readable media, and systems as illustrated in the figures is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

[0024] The present features, structures, or characteristics described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, throughout the specification, the use of the phrases "example embodiments," "some embodiments," or other similar language refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Thus, the phrases "example embodiments," "some embodiments," "in other embodiments," or other similar language appearing throughout the specification do not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0025] In addition, although the term "message" may have been used in the description of the embodiments, the present application can be applied to many types of network data, such as packets, frames, datagrams, etc. The term "message" also includes packets, frames, datagrams, and any equivalents thereof. In addition, although certain types of messages and signaling may be depicted in the exemplary embodiments, they are not limited to certain types of messages, and the present application is not limited to certain types of signaling.

[0026] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide decentralized prescription refilling over a blockchain network.

[0027] A decentralized database is a distributed storage system that includes multiple nodes that communicate with each other. Blockchain is an example of a decentralized database that includes an immutable data structure that is append-only, similar to a distributed ledger that can maintain records between mutually distrustful parties. Distrustful parties are referred to as peers or peer nodes in this article. Each peer maintains a copy of the database record, and no single peer can modify the database record without consensus between distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and build a hash chain through blocks. For consistency, the process forms a ledger by sorting storage transactions as needed. In a public blockchain or permissionless blockchain, anyone can participate without a specific identity. Public blockchains typically involve native cryptocurrencies and use consensus based on various protocols such as proof of work (PoW). On the other hand, permissioned blockchain databases provide a system that can secure interactions between groups of entities that share common goals but do not fully trust each other, such as businesses exchanging funds, goods, information, etc.

[0028] Blockchain operates arbitrary programmable logic that is customized for decentralized storage solutions and is called "smart contracts" or "chaincodes". In some cases, there may be specialized chaincodes for managing functions and parameters, which are called system chaincodes. Smart contracts are trusted distributed applications that take advantage of the tamper-proof properties of the blockchain database and the underlying protocols between nodes (called endorsements or endorsement policies). In general, blockchain transactions must usually be "endorsed" before being submitted to the blockchain, and unendorsed transactions are ignored. Typical endorsement policies allow chaincodes to specify endorsers of transactions in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to verify the transaction. After verification, the transaction enters the sorting phase, in which a consensus protocol is used to produce a sorted sequence of endorsed transactions grouped into blocks.

[0029] A node is a communication entity of a blockchain system. A "node" can perform a logical function in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes can include different types, such as clients or client nodes that submit transaction calls (transaction-invocation) to endorsers (e.g., peers) and broadcast transaction proposals (transaction-proposals) to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive transactions submitted by clients, submit transactions, and maintain the state and copy of the ledger of blockchain transactions. Peers can also have the role of endorsers, although this is not required. Ordering service nodes or orderers are nodes that run communication services for all nodes, and they implement delivery guarantees, such as broadcasts to each of the peer nodes in the system when submitting transactions and modifying the world state of the blockchain, where the world state of the blockchain is another name for the initial blockchain transaction that usually includes control and setup information.

[0030] The ledger is an ordered, tamper-proof record of all state transitions of the blockchain. State transitions can result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Transactions can cause a set of asset key-value pairs to be submitted to the ledger as one or more operands, where operands are such as create, update, delete, etc. The ledger includes a blockchain (also called a chain), which is used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. There is usually one ledger per channel. Each peer node maintains a copy of the ledger for each channel it belongs to.

[0031] A chain is a transaction log structured into hash-linked blocks, and each block contains a sequence of N transactions, where N is equal to or greater than 1. The block header includes the hash of the block's transactions, as well as the hash of the previous block's header. In this way, all transactions on the ledger can be arranged in sequence and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents every transaction that has come before it on the chain, which makes it possible to ensure that all peer nodes are in a consistent and trustworthy state. The chain can be stored on the peer node file system (i.e., local, attached storage, cloud, etc.), effectively supporting the append-only nature of blockchain workloads.

[0032] The current state of the immutable ledger represents the latest values ​​for all keys included in the chain's transaction log. Because the current state represents the latest key values ​​known to the channel, the current state is sometimes referred to as the world state. Chaincode invocations execute transactions based on the current state data of the ledger. In order for these chaincode interactions to be efficient, the latest values ​​of the keys can be stored in a state database. The state database can be just an indexed view into the chain's transaction log, so the state database can be regenerated from the chain at any time. The state database can be automatically restored (or generated, if necessary) at peer startup and before transactions are accepted.

[0033] Some benefits of the present solution described and depicted herein include methods and systems for decentralized prescription refilling via a blockchain network. Exemplary embodiments address issues of time and trust by extending features of a database such as immutability, digital signatures, and being a single source of truth. Exemplary embodiments provide a solution for decentralized prescription refilling in a blockchain-based network. The blockchain network can be homogenous based on asset types and rules governing assets based on smart contracts.

[0034] Blockchain differs from traditional databases in that blockchain is not a central storage, but a decentralized, immutable, secure storage, where nodes must share changes to records in the storage. Some properties inherent in blockchain and helpful for implementing blockchain include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, etc., which will be further described in this article. According to various aspects, due to the inherent and unique immutable accountability, security, privacy, decentralized permission, availability, endorsement and accessibility of smart contracts, a system for decentralized prescription refilling on a blockchain network is implemented. In particular, blockchain ledger data is immutable, and this provides an effective method for decentralized prescription refilling on a blockchain network. In addition, the use of encryption in blockchain provides security and establishes trust. Smart contracts manage the state of assets to complete the life cycle. The example blockchain is permissioned decentralized. Therefore, each end user can have his own copy of the ledger for access. There can be multiple organizations (and peers) on the blockchain network. The key organization can act as an endorsement peer to verify the smart contract execution results, read collections, and write collections. In other words, the inherent characteristics of the blockchain provide an efficient implementation of a decentralized prescription refilling method.

[0035] One of the benefits of the example embodiments is that it improves the functionality of a computing system by implementing a method for decentralized prescription refilling in a blockchain-based system. Through the blockchain system described herein, a computing system can perform functions for decentralized prescription refilling through a blockchain network by providing access to capabilities such as distributed ledgers, peers, encryption, MSPs, event processing, etc. In addition, blockchain is able to create a business network and enable any user or organization to participate. Therefore, blockchain is more than just a database. Blockchain has the ability to create a business network of users and on / off-site organizations to collaborate and execute service processes in the form of smart contracts.

[0036] Example embodiments provide many benefits over traditional databases. For example, through blockchain, these embodiments provide the immutable accountability, security, privacy, permissioned decentralization, availability of smart contracts, endorsement, and accessibility that are inherent and unique to blockchain.

[0037] At the same time, traditional databases cannot be used to implement example embodiments because they do not bring all parties onto a business network, they do not create trusted collaboration, and they do not provide efficient storage of digital assets. Traditional databases do not provide tamper-proof storage and do not provide protection for the digital assets being stored. Therefore, the proposed method for decentralized prescription refilling through a blockchain network cannot be implemented in a traditional database.

[0038] Meanwhile, if the example embodiments were to be implemented using a traditional database, the example embodiments would suffer from unnecessary disadvantages such as search capabilities, lack of security, and slow transaction speeds. Furthermore, it is simply not possible to simply implement an automated method for decentralized prescription refilling via a blockchain network.

[0039] Thus, example embodiments provide a particular solution to a problem in the field of prescription refilling over a blockchain network.

[0040] Example embodiments also change how data is stored within the block structure of the blockchain. For example, digital asset data can be securely stored within a specific portion of a data block (i.e., within a header, within a data segment, or within metadata). By storing digital asset data within a data block of the blockchain, the digital asset data can be attached to an immutable blockchain ledger through a chain of hash links of the blocks. In some embodiments, data blocks can differ from traditional data blocks by not storing personal data associated with digital assets with the assets within the traditional block structure of the blockchain. By removing personal data associated with digital assets, blockchain can provide the advantages of anonymity based on immutable accountability and security.

[0041] According to an exemplary embodiment, a method and system are provided for enabling travelers to have their prescriptions refilled when they travel abroad or to unfamiliar places. An exemplary embodiment may use blockchain to process and store information related to medical insurance, medical conditions, patients' allergies, etc. Blockchain may also provide the required identification mechanisms to verify the identity of patients who need prescription refills. Through blockchain-enforced contracts, the system may ensure that only medications that are considered safe and urgent are obtained by the patients who are making the request. In addition, an exemplary embodiment may use special contracts to ensure that patients are not accidentally provided with medications that may cause harm to the patient due to allergic reactions. An exemplary embodiment may ensure that local (i.e., foreign) regulations are followed when filling prescriptions for (multiple) traveling patients.

[0042] Exemplary embodiments may advantageously provide immediacy of medication availability and may minimize health risks. In one embodiment, the system may utilize other blockchains containing relevant information such as a global record of medications being distributed. Smart contracts may be used to calculate the appropriate amount of medication to be provided for the duration of a given trip. Exemplary embodiments may make it easier to implement / update Drug Supply Chain Security Act (DSCSA) regulations and may provide optimized distribution of medications. An exemplary embodiment may incorporate elements of the Internet of Things (IoT) for tracking medications.

[0043] The method and system of the exemplary embodiment can not only link the patient's prescription / medical history through the blockchain, but also bind the drug supply chain guarantee (the source / and proof point of drug quality). Therefore, the system can provide a link between the prescription authorization on the immutable ledger managed by the user's consent and the drug supply chain guarantee of the source of the local drug supply according to local laws to comply with the use of controlled substances, etc. The system can provide a re-dispensing / no longer dispensing determination based on the execution of smart contracts on the pharmacy node. Specific actions / approvals can be taken, including reputable "disaster relief organizations". "Pharmacies without Borders" based on the exemplary system can provide emergency trigger approvals for certain drugs to specific places affected by natural disasters or epidemics, etc. It will be possible to raise funds for specific drugs and their delivery, and track distribution to specific pharmacies or "virtual enabled pharmacies". In the event of a disaster, mobile pharmacies / distribution centers may be located in strategic locations. The system can achieve targeted fundraising, that is, tracking the funds spent by "disaster relief organizations" on given drugs.

[0044] According to an exemplary embodiment, there are multiple blockchain entities that may be involved: pharmacies (peer nodes), prescribing doctors, insurance companies that pay for prescriptions, and patients who need to refill their prescriptions. Patient peers can be implemented on mobile devices (e.g., smart phones). These entities may not fully trust each other and may be highly distributed. In addition, there is a prescription equivalence table that the pharmacy node can use to provide generic drugs with the same or equivalent ingredients as the original prescription. Insurance coverage tables can be used to determine the drugs covered by each insurance policy. In order to achieve a "borderless pharmacy", it is necessary to verify the identity of the patient and facilitate the exchange of relevant medical information (allergy history or pre-existing conditions) between geographically distributed entities that may not fully trust each other. In addition, data related to healthcare requires strict privacy protection, so it is necessary to strengthen the confidentiality of information dissemination on a need-to-know basis and ensure appropriate authorization for patients. In this service, certain drugs may be restricted due to potential abuse by unintended populations (e.g., recreational drugs). Each prescription has an expiration date, after which no pharmacy can fill the prescription. Finally, in one embodiment, to verify that the patient is actually traveling, external information can be retrieved from the blockchain (e.g., boarding pass, proof of ticket purchase, proof of airport check-in, credit card statement, etc.) Other options may include a set of credentials, certificates, receipts, and finally some kind of "live proof" such as an on-demand code sent to the patient's phone (which is difficult to forge).

[0045] According to one embodiment, blockchain is used as a ledger to publish information about prescriptions of different patients. For privacy reasons, information about medical conditions and prescriptions can be hidden from all pharmacies until the patient requests a prescription refill. To this end, each patient is assigned an encrypted secret (i.e., a key) that will reveal the patient's information when he or she sends a request to a pharmacy to get a prescription refill. According to an exemplary embodiment, a method may include:

[0046] - The doctor writes a prescription to the patient. The prescription is cryptographically protected using a key owned by the patient. The prescription is published in the blockchain. The blockchain record can include:

[0047] a. The patient's allergy history retrieved from the medical record. For each allergy, a rule in the contract is defined to indicate that a component / drug cannot be refilled for that patient;

[0048] b. How many refills and how often they can be refilled;

[0049] c. Expiration date, indicating when the subscription is valid;

[0050] d. Identification method to verify whether the patient is requesting a refill.

[0051] - Patients can add a delegation to receive medication in the blockchain, with a deadline for the delegation to be valid within a geographic region;

[0052] - Prescription-verified smart contracts can be defined to verify that person X can now get prescription Y at location Z.

[0053] Prescription verification smart contracts could include:

[0054] a. Identification method to verify the patient who is requesting the refill or to verify an authorized third party (k out of N factors that prove the patient is there). In one embodiment, this may not be part of the contract and is verified by the pharmacist in an off-chain authentication process;

[0055] b. The patient's allergy history retrieved from the medical record. For each allergy, a rule in the contract is defined to indicate that a component / drug cannot be refilled for that patient;

[0056] c. How many refills can be made for this prescription;

[0057] d. How often the prescription is refilled;

[0058] e. Expiration date, indicating when the subscription is valid;

[0059] f. A contract that calls a regulatory smart contract based on location;

[0060] g. Flexible rules:

[0061] i. If the patient forgets / loses medication, different information can be used;

[0062] ii. Unable to refill the medicine in time.

[0063] - Local-Regulatory-Verified Smart Contracts, where each participating country / region / state can add a contract for the regulatory location. Each country / state / location may have a list of medications that cannot be obtained through the Borderless Pharmacy System. For example, a patient may not be able to obtain marijuana or tranquilizers even if they have a valid foreign prescription TM These restrictions can also be placed on the blockchain.

[0064] - Smart contracts that negotiate chemical equivalencies and insurance coverage taking into account patient allergies;

[0065] -When patients travel and need a refill of their medication:

[0066] a. He / she can go to a pharmacy without borders;

[0067] b. The patient or authorized person provides the required identification for the contract;

[0068] c. Patients can provide the keys needed to read the protected contents of prescriptions and medical records.

[0069] -Prescriptions retrieved:

[0070] a. Verify prescription-based smart contracts;

[0071] b. Execute smart contracts based on local regulations as part of this verification;

[0072] c. The pharmacist verifies the availability of the requested medication;

[0073] d. If a drug is not available (or too expensive), check the formulary equivalency table to see if a generic drug can be used.

[0074] -Transactions are recorded on the blockchain only when all conditions are met.

[0075] The following actions can occur:

[0076] a. The store that fills the prescription is recorded on the blockchain; and

[0077] b. The number of times a prescription has been refilled is updated.

[0078] -The insurance company node can be notified through another transaction to deduct the full cost and calculate the out-of-pocket expense for the patient node.

[0079] Figure 1 A logical network diagram for decentralized prescription refilling over a blockchain network is shown according to an example embodiment.

[0080] refer to Figure 1, the example network 100 includes a pharmacy node 102, which can be connected to other blockchain nodes (patient node 105, (multiple) doctor nodes 107, and (multiple) insurance company nodes 109). The pharmacy node 102 can be connected to a blockchain 106, which has a ledger 108 for storing patients' data and prescription refill transactions 110. Although this example only describes one pharmacy node 102 in detail, multiple such nodes can be connected to the blockchain 106. It should be understood that the pharmacy node 102 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of the pharmacy node 102 disclosed herein. The pharmacy node 102 can be a computing device or a server computer, etc., and can include a processor 104, which can be a semiconductor-based microprocessor, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or another hardware device. Although a single processor 104 is depicted, it should be understood that the pharmacy node 102 may include multiple processors, multiple cores, etc. without departing from the scope of the pharmacy node 102 system.

[0081] The pharmacy node 102 may also include a non-transitory computer-readable medium 112 on which machine-readable instructions executable by the processor 104 may be stored. Examples of machine-readable instructions are shown as 114-120 and are discussed further below. Examples of non-transitory computer-readable media 112 may include electronic, magnetic, optical, or other physical storage devices containing or storing executable instructions. For example, the non-transitory computer-readable medium 112 may be a random access memory (Random Access memory, RAM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a hard disk, an optical disk, or other type of storage device.

[0082] The processor 104 can fetch, decode, and execute machine-readable instructions 114 to connect to a blockchain network configured to store the patient's data on a blockchain ledger. As described above, the blockchain ledger 108 can store prescription refill transactions 110. The blockchain 106 network can be configured to use one or more smart contracts that manage transactions for multiple participating nodes.

[0083] Processor 104 may retrieve, decode, and execute machine-readable instructions 116 to receive a request for a prescription refill from patient node 105, the request including a patient's secret key. Processor 104 may retrieve, decode, and execute machine-readable instructions 118 to extract the secret key from the request to verify the patient's identity. Processor 104 may retrieve, decode, and execute machine-readable instructions 120 to execute a smart contract to: (a) decrypt prescription data located on the ledger by applying the secret key; (b) retrieve the patient's allergy record from ledger 108 to check the allergy record against the prescription data; (c) determine the number of refills remaining based on the prescription data; (d) check the validity of the prescription data based on the expiration date; and submit the prescription refill transaction to blockchain 106 based on the successful execution of (b)-(d).

[0084] Figure 2A A blockchain architecture configuration 200 is shown according to an example embodiment. Figure 2A , the blockchain architecture 200 may include certain blockchain elements, for example, a set of blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are depicted by way of example only). These nodes participate in a number of activities, such as blockchain transaction addition and verification processes (consensus). One or more of the blockchain nodes 204-210 may endorse transactions based on endorsement policies and may provide ordering services for all blockchain nodes in the architecture 200. The blockchain nodes may initialize blockchain authentication and seek to write to a blockchain immutable ledger stored in a blockchain layer 216, a copy of which may also be stored on the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224, one or more of which are linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which may be created based on the custom configuration sought by the participants and may maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed on all blockchain nodes 204-210 via appending to the distributed ledger.

[0085] The blockchain foundation or platform 212 may include various layers of blockchain data, services (e.g., encrypted trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors seeking to access data entries. The blockchain layer 216 may expose an interface that provides access to the virtual execution environment necessary to process program code and participate in the physical infrastructure 214. The encrypted trust service 218 may be used to verify transactions (such as asset exchange transactions) and keep information private.

[0086] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 via one or more interfaces exposed and services provided by the blockchain platform 212. The code 220 can control blockchain assets. For example, the code 220 can store and transmit data and can be executed by the nodes 204-210 in the form of a smart contract, and the chain code is associated with conditions or other code elements subject to its execution. As a non-limiting example, a smart contract can be created to perform reminders, updates, and / or other notifications subject to changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and the use of the ledger. For example, prescription request information 226 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The result 228 can include a data block reflecting the remaining number of refills available under the prescription. The physical infrastructure 214 can be used to obtain any data or information described herein.

[0087] Within chaincode, smart contracts can be created via high-level applications and programming languages ​​and then written into blocks of a blockchain. A smart contract may include executable code that is registered, stored, and / or replicated with a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, which may be executed in response to satisfying a condition associated with the smart contract. The execution of a smart contract may trigger (multiple) trusted modifications to the state of a digital blockchain ledger. The (multiple) modifications to the blockchain ledger caused by the execution of a smart contract may be automatically replicated in a distributed network of blockchain peers through one or more consensus protocols.

[0088] Smart contracts can write data to the blockchain in the format of key-value pairs. In addition, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in virtual machines or other computing platforms. The data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by the smart contract is saved in memory by the supplied execution environment and deleted once the data required by the blockchain is identified.

[0089] Chaincode may include a code interpretation of a smart contract, with additional features. As described herein, a chaincode may be a program code deployed on a computing network where it is executed and validated together by multiple chain validators during a consensus process. The chaincode receives a hash and obtains a hash from the blockchain that is associated with a data template created by using a previously stored feature extractor. If the hash of the hashed identifier and the hash created from the stored identifier template data match, the chaincode sends an authorization key for the requested service. The chaincode may write data associated with cryptographic details to the blockchain. In Figure 2A In the embodiment of the present invention, a prescription refill transaction may include the execution of a smart contract. One function may be to submit a transaction related to the execution of a smart contract on a ledger for recording prescription refill data, which may be provided to one or more of the nodes 204-210.

[0090] Figure 2B An example of a transaction flow 250 between nodes of a blockchain according to an example embodiment is shown. Figure 2B , the transaction flow may include a transaction proposal 291 sent by the application client node 260 to the endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute the chaincode function to initialize the transaction. The output may include the chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values ​​written in the chaincode (write set). If approved, the proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to the sorting service node 284. The sorting service node 284 then passes the sorted transaction as a block to all peers 281-283 on the channel. Each peer 281-283 may validate the transaction before submitting it to the blockchain. For example, the peer may check the endorsement policy to ensure that the correct assignment of the specified peer has signed the result and authenticated the signature against the transaction payload 293.

[0091] Reference again Figure 2B, the client node 260 initiates a transaction 291 by constructing a request and sending it to the peer node 281 as an endorser. The client 260 may include an application that utilizes a supported software development kit (SDK) (such as NODE, JAVA, PYTHON, etc.) that utilizes the available APIs to generate a transaction proposal. The proposal is a request to invoke a chaincode function so that data can be read and / or written to the ledger (i.e., write a new key-value pair for an asset). The SDK can be used as a shim to package the transaction proposal into a format of the appropriate architecture (e.g., protocol buffers for remote procedure calls (RPCs)) and utilize the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0092] In response, the endorsing peer 281 may verify that (a) the transaction proposal is well-formed, (b) the transaction has not been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in the example, client 260) is properly authorized to perform the proposed operation on the channel. The endorsing peer 281 may input the transaction proposal as a parameter to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including a response value, a read collection, and a write collection. However, no updates are made to the ledger at this time. In 292, the set of values ​​is passed back to the SDK of client 260 along with the signature of the endorsing peer 281 as a proposal response 292, and client 260 parses the payload for the application to consume.

[0093] In response, the client 260 application checks / verifies the signatures of the endorsing peers and compares the proposal responses to determine if the proposal responses are identical. If the chaincode is only querying the ledger, the application will check the query response and will typically not submit the transaction to the sorting node service 284. If the client application intends to submit the transaction to the sorting node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied (i.e., whether all peer nodes required for the transaction have endorsed the transaction) before submitting. Here, the client may include only one of the multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node will need to endorse the transaction. The architecture is such that even if the application chooses not to check the response or otherwise forward unendorsed transactions, the endorsement policy will still be enforced by the peers and maintained during the submission verification phase.

[0094] After a successful check, in step 293, client 260 assembles the endorsement into a transaction and broadcasts the transaction proposal and response to ordering node 284 within a transaction message. The transaction may contain a read / write set, signatures of endorsing peers, and a channel ID. Ordering node 284 does not need to examine the entire contents of a transaction to perform its operations. Instead, ordering node 284 can simply receive transactions from all channels in the network, sort them chronologically by channel, and create a block of transactions for each channel.

[0095] The block of transactions is passed from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 within the block are validated to ensure that any endorsement policies are met and that the state of the ledger for the read set variables has not changed since the transaction execution generated the read set. The transactions in the block are marked as valid or invalid. In addition, in step 295, each peer node 281-283 appends the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. An event is emitted to notify the client application that the transaction (call) has been immutably attached to the chain and whether the transaction is verified or unverified.

[0096] Figure 3 An example of a permissioned blockchain network 300 is shown, featuring a distributed, decentralized, peer-to-peer architecture, and a certificate authority 318 that manages user roles and permissions. In this example, a blockchain user 302 can submit a transaction to a permissioned blockchain network 310. In this example, the transaction can be a deployment, call, or query, and can be issued through a client-side application utilizing an SDK, directly through a REST API, etc. The trusted business network can provide access to a regulator system 314, such as an auditor (e.g., the Securities and Exchange Commission in the U.S. stock market). At the same time, the blockchain network operator system of node 308 manages member permissions, such as registering the regulator system 310 as an "auditor" and registering the blockchain user 302 as a "client." Auditors can be restricted to only querying the ledger, while clients can be authorized to deploy, call, and query certain types of chaincodes.

[0097] The blockchain developer system 316 writes chaincode and client-side applications. The blockchain developer system 316 can deploy chaincode directly to the network through a REST interface. In order to include credentials from a traditional data source 330 in the chaincode, the developer system 316 can use an out-of-band connection to access the data. In this example, the blockchain user 302 connects to the network through a peer node 312. Before conducting any transactions, the peer node 312 obtains the user's registration and transaction certificates from the certificate authority 318. In some cases, blockchain users must have these digital certificates in order to conduct transactions on the permissioned blockchain network 310. At the same time, users trying to drive chaincode may need to verify their credentials on the traditional data source 330. In order to confirm the user's authorization, the chaincode can use an out-of-band connection to the data through the traditional processing platform 320.

[0098] Figure 4A A flowchart 400 of an example method for decentralized prescription refilling via a blockchain network is shown according to an example embodiment. Figure 4A , method 400 may include one or more of the steps described below.

[0099] Figure 4A The pharmacy node 102 (see Figure 1 ) is a flowchart of an example method performed. It should be understood that Figure 4A The method 400 described in the embodiment may include additional operations, and some of the operations described therein may be removed and / or modified without departing from the scope of the method 400. For illustration purposes, reference is also made to Figure 1 The description of the method 400 is performed with reference to the features depicted in FIG. In particular, the processor 104 of the pharmacy node 102 can perform some or all of the operations included in the method 400.

[0100] refer to Figure 4A , at box 412, the processor 104 can be connected to a blockchain network configured to store the patient's data in a blockchain ledger. At box 414, the processor 104 can receive a request for a prescription refill from a patient node. The request can include a secret key of the patient. At box 416, the processor 104 can extract the secret key from the request to verify the identity of the patient. At box 418, the processor 104 can execute a smart contract to: (a) decrypt the prescription data on the ledger by applying the secret key; (b) retrieve the patient's allergy record from the ledger to check the allergy record against the prescription data; (c) determine the number of refills remaining based on the prescription data; (d) check the validity of the prescription data based on the expiration date; and submit the prescription refill transaction to the blockchain 106 based on the successful execution of (b)-(d).

[0101] Figure 4BA flowchart 450 is shown of an example method for decentralized prescription refilling in a blockchain network according to an example embodiment. Figure 4B , method 450 may also include one or more of the following operations. In box 452, processor 104 may execute a smart contract to check whether the prescription refill is available over the counter and notify the patient node. In box 454, processor 104 may execute a smart contract to update the number of refills remaining on the blockchain based on the prescription refill transaction. In box 456, processor 104 may execute a smart contract to calculate the amount of medication to be dispensed based on the duration of the trip retrieved from the blockchain ledger. In box 458, processor 104 may execute a smart contract to check local regulations before submitting the prescription refill transaction to the blockchain. In box 460, processor 104 may execute a smart contract to calculate the out-of-pocket cost for the prescription refill based on the patient's insurance data retrieved from the blockchain ledger. In box 462, processor 104 may execute a smart contract to determine whether there is a generic alternative for the prescription refill.

[0102] Note that while the prescription may be a refill and the country of origin jurisdiction may have permitted the combination, the country of origin may reflect compliance with the local jurisdiction and suggest an alternative generic medication. This decision and prescription fulfillment can be recorded in the patient's health record on the blockchain and can subsequently be used by healthcare providers for analysis and can trigger corrective action when the patient returns to his or her country of origin.

[0103] Figure 5A An example system 500 is shown, including a physical infrastructure 510 configured to perform various operations, according to an example embodiment. Figure 5A , the physical infrastructure 510 includes a module 512 and a module 514. The module 514 includes a blockchain 520 and a smart contract 530 (which may reside on the blockchain 520), which can perform any of the operation steps 508 (in the module 512) included in any of the example embodiments. Steps / operations 508 may include one or more of the described or depicted embodiments, and may represent output information read from or written to one or more smart contracts 530 and / or blockchains 520. The physical infrastructure 510, the modules 512, and the modules 514 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, the modules 512 and 514 may be the same module.

[0104] Figure 5B An example system 540 is shown that is configured to perform various operations according to an example embodiment. Figure 5B, system 540 includes module 512 and module 514. Module 514 includes blockchain 520 and smart contract 530 (which may reside on blockchain 520), which can perform any of the operation steps 508 (in module 512) included in one of the example embodiments. Step / operation 508 may include one or more of the described or depicted embodiments, and may represent output information read from or written to one or more smart contracts 530 and / or blockchain 520. Physical infrastructure 510, module 512, and module 514 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, module 512 and module 514 may be the same module.

[0105] Figure 5C An example smart contract configuration between contracting parties and an intermediary server configured to enforce the terms of the smart contract on a blockchain according to an example embodiment are shown. Figure 5C , configuration 550 may represent a communication session, an asset transfer session, or a process or procedure driven by a smart contract 530 that explicitly identifies one or more user devices 552 and / or 556. The execution, operation, and results of the smart contract execution may be managed by a server 554. The content of the smart contract 530 may require digital signatures of one or more entities 552 and 556 of the parties to the smart contract transaction. The results of the smart contract execution may be written to the blockchain 520 as a blockchain transaction. The smart contract 530 resides on the blockchain 520, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0106] Figure 5D A public interface 560 for accessing the logic and data of a blockchain is shown according to an example embodiment. Figure 5D In the example of , an application programming interface (API) gateway 562 provides a public interface for accessing blockchain logic (e.g., smart contracts 530 or other chaincodes) and data (e.g., distributed ledgers, etc.). In this example, the API gateway 562 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 552 and 556 to blockchain peers (i.e., servers 554). Here, the server 554 is a blockchain network peer component that holds a copy of the world state and distributed ledger, allowing clients 552 and 556 to query data about the world state and submit transactions to the blockchain network, where, according to the smart contract 530 and the endorsement policy, the endorsing peer will run the smart contract 530.

[0107] The above embodiments may be implemented using hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program may be embodied on a computer-readable medium, such as a storage medium. For example, the computer program may reside in a random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0108] An exemplary storage medium may be coupled to a processor so that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integrated into the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). Alternatively, the processor and the storage medium may reside as discrete components. For example, FIG. 6 shows an example computer system architecture 600, which may represent or be integrated in any of the above components, etc.

[0109] Fig. 6A A process 600 of adding a new block to a distributed ledger 630 is shown according to an example embodiment, and Figure 6B The content of a block structure 650 of a blockchain according to an example embodiment is shown. Fig. 6A , a client (not shown) may submit a transaction to blockchain nodes 621, 622, and / or 623. A client may be an instruction received from any source to perform an activity on blockchain 630. As an example, a client may be an application acting on behalf of a requester (such as a device, person, or entity) to propose a transaction for a blockchain. Multiple blockchain peers (e.g., blockchain nodes 621, 622, and 623) may maintain the state of the blockchain network and a copy of the distributed ledger 630. Different types of blockchain nodes / peers may exist in the blockchain network, including: an endorsement peer, which simulates and endorses a transaction proposed by a client; and a submission peer, which verifies the endorsement, validates the transaction, and submits the transaction to the distributed ledger 630. In this example, blockchain nodes 621, 622, and 623 may perform the roles of an endorser node, a submitter node, or both.

[0110] The distributed ledger 630 includes: a blockchain 632, which stores immutable, ordered records in blocks; and a state database 634 (current world state), which maintains the current state of the blockchain 632. There can be one distributed ledger 630 per channel, and each peer maintains its own copy of the distributed ledger 630 for each channel they belong to. The blockchain 632 is a transaction log, structured as hash-linked blocks, where each block contains a sequence of N transactions. Blocks can include various components, such as Figure 6B Block links (by Fig. 6A ) can be generated by adding the hash of the header of the previous block within the block header of the current block. In this way, all transactions on the blockchain 632 are arranged in sequence and cryptographically linked together, thereby preventing tampering of the blockchain data without breaking the hash link. In addition, due to the link, the latest block in the blockchain 632 represents every transaction that appeared before the latest block. The blockchain 632 can be stored on a peer-to-peer file system (local storage or attached storage) that supports append-only blockchain workloads.

[0111] The current state of the blockchain 632 and the distributed ledger 632 may be stored in a state database 634. Here, the current state data represents the latest values ​​of all keys included in the chain transaction log of the blockchain 632. Chaincode invocations execute transactions against the current state in the state database 634. In order to make these chaincode interactions very efficient, the latest values ​​of all keys are stored in the state database 634. The state database 634 may include an indexed view into the transaction log of the blockchain 632, so the state database 634 may be regenerated from the chain at any time. The state database 634 may be automatically restored (or generated, if necessary) at peer startup before a transaction is accepted.

[0112] The endorsing node receives the transaction from the client and endorses the transaction based on the simulation results. The endorsing node holds the smart contract that simulates the transaction proposal. When the endorsing node endorses the transaction, the endorsing node creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing the transaction depends on the endorsement policy that can be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction." Different channels may have different endorsement policies. The client application forwards the endorsed transaction to the sorting service 610.

[0113] The ordering service 610 accepts endorsed transactions, orders them into blocks, and delivers the blocks to committing peers. For example, when a transaction threshold is reached, a timer expires, or another condition, the ordering service 610 can initialize a new block. Fig. 6A In the example of , blockchain node 622 is a submitting peer that has received a new data block 650 to store on blockchain 630.

[0114] The ordering service 610 may consist of a cluster of orderers. The ordering service 610 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the ordering service 610 may accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 630. The architecture of the blockchain network may be designed such that the specific implementation of "ordering" (e.g., Solo, Kafka cards, BFT, etc.) becomes a pluggable component.

[0115] Transactions are written to the distributed ledger 630 in a consistent order. The order of transactions is established to ensure that updates to the state database 634 are valid when submitted to the network. Unlike cryptocurrency blockchain systems (such as Bitcoin, etc.), where ordering occurs by solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 630 can choose the ordering mechanism that best suits the network.

[0116] When the ordering service 610 initializes a new block 650, the new block 650 may be broadcast to the committing peers (e.g., blockchain nodes 621, 622, and 623). In response, each committing peer verifies the transactions within the new block 650 by checking to ensure that the read set and the write set still match the current world state in the state database 634. Specifically, the committing peer may determine whether the read data that existed when the endorser simulated the transaction is the same as the current world state in the state database 634. When the committing peer verifies the transaction, the transaction is written to the blockchain 632 on the distributed ledger 630, and the state database 634 is updated with the write data from the read-write set. If the transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 634, the transaction that was ordered into the block will still be included in the block, but the transaction will be marked as invalid and the state database 634 will not be updated.

[0117] refer to Figure 6B , a block 650 (also referred to as a data block) stored on a blockchain 632 of a distributed ledger 630 may include multiple data segments, such as a block header 660, block data 670, and block metadata 680. It should be understood that the various depicted blocks and their contents, such as block 650 and its contents. Figure 6B The illustration is for illustrative purposes only and is not meant to limit the scope of the example embodiments. In some cases, both block header 660 and block metadata 680 may be smaller than block data 670 storing transaction data, however, this is not required. Block 650 may store transaction information for N transactions (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 670. Block 650 may also include within block header 660 a link to a previous block (e.g., Fig. 6A Specifically, the block header 660 may include a hash of the header of the previous block. The block header 660 may also include a unique block number, a hash of the block data 670 of the current block 650, and the like. The block number of the block 650 may be unique and assigned in an increasing / ordered order starting from zero. The first block in the blockchain may be referred to as a genesis block, which includes information about the blockchain, its members, data stored therein, and the like.

[0118] The block data 670 may store transaction information for each transaction recorded in the block 650. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 630, transaction ID, epoch, payload visibility, chaincode path (deployment transaction (tx)), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identity such as public key and certificate, client's signature, endorser's identity, endorser signature, proposal hash, chaincode event, response status, namespace, read set (list of keys and versions read by the transaction), write set (list of keys and values, etc.), start key, end key, list of keys, Merkle tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0119] In some embodiments, block data 670 may also store data 672 that adds additional information to the hash-linked chain of blocks in blockchain 632. Thus, data 672 may be stored in an immutable log of blocks on distributed ledger 630. Some benefits of storing such data 672 are reflected in the various embodiments disclosed and described herein.

[0120] Block metadata 680 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature about the creation of the block, a reference to the last configuration block, a transaction filter identifying valid and invalid transactions within the block, the last held offset of the sorting service that sorts the block, etc. The signature, the last configuration block, and the sorter metadata may be added by the sorting service 610. At the same time, the submitter of the block (such as blockchain node 622) may add validity / invalidity information based on endorsement policies, verification of read / write collections, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 670 and a verification code identifying whether the transaction is valid / invalid.

[0121] Figure 7 It is not intended to impose any limitation on the scope of use or functionality of the embodiments of the present application described herein. Regardless, computing node 700 is capable of implementing and / or performing any of the functions set forth above.

[0122] In computing node 700, there is a computer system / server 702, which can operate with many other general or special computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, small computer systems, large computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

[0123] Computer system / server 702 may be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. In general, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 702 may be practiced in a distributed cloud computing environment, where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules may be located in local and remote computer system storage media including memory storage devices.

[0124] like Figure 7 As shown, the computer system / server 702 in the cloud computing node 700 is in the form of a general-purpose computing device. The components of the computer system / server 702 may include, but are not limited to: one or more processors or processing units 704, a system memory 706, and a bus connecting different system components (including the system memory 706 and the processing unit 704).

[0125] The term "bus" refers to one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or a local bus using any of a variety of bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0126] Computer system / server 702 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computer system / server 702, including volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 706 implements the flowcharts in other figures. System memory 706 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 710 and / or cache memory 712. Computer system / server 702 can further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 714 can be used to read and write non-removable, non-volatile magnetic media (not shown in the figure, usually referred to as "hard drive"). Although not shown in the figure, a disk drive for reading and writing removable non-volatile disks (such as "floppy disks") and an optical disk drive for reading and writing removable non-volatile optical disks (such as CD-ROM, DVD-ROM or other optical media) can be provided. In these cases, each drive can be connected to the bus through one or more data media interfaces. The memory 806 may include at least one program product. The program product has a set (eg, at least one) of program modules. The program modules are configured to execute the functions of various embodiments of the present application.

[0127] A program / utility 716 having a set (at least one) of program modules 718 may be stored, for example, in the memory 706, such program modules 718 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment. The program modules 718 generally perform the functions and / or methods of the various embodiments described herein.

[0128] As will be appreciated by those skilled in the art, aspects of the present application may be embodied as a system, method or computer program product. Therefore, aspects of the present application may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.) or an embodiment in combination with software and hardware aspects, which may be collectively referred to herein as "circuit", "module" or "system". In addition, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media, which has a computer-readable program code embodied therein.

[0129] The computer system / server 702 may also communicate with one or more external devices 720 (e.g., keyboards, pointing devices, displays 722, etc.), may communicate with one or more devices that enable a user to interact with the computer system / server 702, and / or may communicate with any device that enables the computer system / server 702 to communicate with one or more other computing devices (e.g., network cards, modems, etc.). Such communication may be performed via an input / output (I / O) interface 724. In addition, the computer system / server 702 may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 726. As shown, the network adapter 726 communicates with other modules of the computer system / server 702 via a bus. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the computer system / server 702, including, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0130] Although exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media are shown in the accompanying drawings and described in the foregoing detailed description, it should be understood that the present application is not limited to the disclosed embodiments, but can be rearranged, modified, and replaced as described and defined by the appended claims. For example, the capabilities of the systems of the various drawings can be performed by one or more of the modules or components described herein, or performed in a distributed architecture, and can include a transmitter, a receiver, or a pair of the two. For example, all or part of the functions performed by each module can be performed by one or more of these modules. In addition, the functions described herein can be performed inside or outside a module or component, at different times, and in relation to different events. In addition, the information sent between various modules can be sent between modules via at least one of a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or via multiple protocols. In addition, the message sent or received by any one of the modules can be sent or received directly and / or via one or more of the other modules.

[0131] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smart phone, or any other suitable computing device, or combination of devices. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide an example of many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

[0132] It should be noted that some of the system features described in this specification have been presented as modules in order to more particularly emphasize their implementation independence. For example, a module can be implemented as a hardware circuit that includes a custom very large-scale integration (VLSI) circuit or gate array, as well as off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module can also be implemented in a programmable hardware device (such as a field programmable gate array, programmable array logic, a programmable logic device, a graphics processing unit, etc.).

[0133] Modules may also be implemented at least in part in software for execution by various types of processors. The identified unit of executable code may for example include one or more physical or logical blocks of computer instructions, which may for example be organized as objects, processes or functions. However, the executable file of the identified module does not need to be physically located together, but may include different instructions stored in different locations, which, when logically combined together, constitute the module and realize the purpose of the module. In addition, a module may be stored on a computer-readable medium, which may for example be a hard drive, a flash memory device, a random access memory (RAM), a magnetic tape or any other such medium for storing data.

[0134] In fact, the module of executable code can be a single instruction or multiple instructions, and can even be distributed on several different code segments, distributed in different programs, and distributed in several storage devices. Similarly, operating data can be identified and shown in the module herein, and can be embodied in any suitable form, and organized in any suitable type of data structure. Operating data can be collected as a single data set, or can be distributed in different locations (including distributed on different storage devices), and can exist on a system or network at least in part only as electronic signals.

[0135] It is easy to understand that the components of the present application can be arranged and designed in a variety of different configurations as generally described and shown in the drawings herein. Therefore, the specific implementation of the embodiment is not intended to limit the scope of the claimed application, but only represents selected embodiments of the present application.

[0136] Those skilled in the art will readily appreciate that the above content may be practiced with steps in different orders and / or hardware components that are different from the disclosed configurations. Therefore, although the present application has been described based on these preferred embodiments, some modifications, variations, and alternative structures will be apparent to those skilled in the art.

[0137] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and that the scope of the present application is limited solely by the appended claims when taking into account the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A system comprising: Processor of the pharmacy node; A memory having machine-readable instructions stored thereon, which, when executed by the processor, cause the processor to: connecting to a blockchain network, the blockchain network being configured to store the patient's data on a blockchain ledger; receiving a request for a prescription refill from a patient node, the request including the patient's secret key; extracting the secret key from the request to verify the patient's identity; Execute smart contracts to: (a) decrypting prescription data located on a ledger by applying the secret key, wherein the decrypted prescription data includes an expiration date of the prescription; (b) retrieving the patient's allergy record from the ledger to check the allergy record against the prescription data; (c) determining the remaining quantity of refills based on the prescription data; (d) verifying the decrypted prescription data by executing a blockchain smart contract of the blockchain ledger based on a decrypted expiration date included in the decrypted prescription data; and Upon successful execution of (b)-(d), submit the prescription refill transaction to the blockchain, The instructions further cause the processor to execute the smart contract to calculate an amount of medication to be dispensed based on a duration of the patient's trip retrieved from the blockchain ledger.

2. The system according to claim 1, wherein: The instructions further cause the processor to execute the smart contract to check whether the prescription refill is available over the counter and to notify the patient node.

3. The system according to claim 1, wherein: The instructions further cause the processor to execute the smart contract to update a remaining refill quantity on the blockchain based on the prescription refill transaction.

4. The system according to claim 1, wherein: The instructions further cause the processor to execute the smart contract to check local regulations before submitting the prescription refill transaction to the blockchain.

5. The system according to claim 1, wherein: The instructions further cause the processor to execute the smart contract to calculate an out-of-pocket cost for the prescription refill based on the patient's insurance data retrieved from the blockchain ledger.

6. The system according to claim 1, wherein: The instructions further cause the processor to execute the smart contract to determine whether a generic substitute exists for the prescription refill.

7. A system comprising: processor; A memory having machine-readable instructions stored thereon, which, when executed by the processor, cause the processor to: receiving a request for a prescription refill from a patient node, the request including the patient's secret key; extracting the secret key from the request to verify the patient's identity; as well as Execute smart contracts stored on the blockchain network to: (a) decrypting prescription data located on a ledger by applying the secret key, wherein the decrypted prescription data includes an expiration date of the prescription; (b) retrieving the patient's allergy record from the ledger to check the allergy record against the prescription data; (c) determining the remaining quantity of refills based on the prescription data; (d) verifying the decrypted prescription data by executing a blockchain smart contract of the blockchain ledger based on a decrypted expiration date included in the decrypted prescription data; and Upon successful execution of (b)-(d), submit the prescription refill transaction to the blockchain. The instructions further cause the processor to execute the smart contract to calculate an amount of medication to be dispensed based on the duration of the trip retrieved from the blockchain ledger.

8. The system according to claim 7, wherein: The instructions further cause the processor to execute the smart contract to check whether the prescription refill is available over the counter and to notify the patient node.

9. The system according to claim 7, wherein: The instructions further cause the processor to execute the smart contract to update a remaining refill quantity on the blockchain based on the prescription refill transaction.

10. The system according to claim 7, wherein: The instructions further cause the processor to execute the smart contract to check local regulations before submitting the prescription refill transaction to the blockchain.

11. The system according to claim 7, wherein: The instructions further cause the processor to execute the smart contract to calculate an out-of-pocket cost for the prescription refill based on the patient's insurance data retrieved from the blockchain ledger.

12. The system according to claim 7, wherein: The instructions further cause the processor to execute the smart contract to determine whether a generic substitute exists for the prescription refill.

13. A system comprising: processor; A memory having machine-readable instructions stored thereon, which, when executed by the processor, cause the processor to: receiving a request for a prescription refill from a patient node, the request including the patient's secret key; extracting the secret key from the request to verify the patient's identity; as well as Execute smart contracts to: (a) decrypting prescription data located on a ledger by applying the secret key, wherein the decrypted prescription data includes an expiration date of the prescription; (b) retrieving the patient's allergy record from the ledger to check the allergy record against the prescription data; (c) determining the remaining quantity of refills based on the prescription data; (d) verifying the decrypted prescription data by executing a blockchain smart contract of the blockchain ledger based on a decrypted expiration date included in the decrypted prescription data; and Upon successful execution of (b)-(d), submit the prescription refill transaction to the blockchain, The instructions further cause the processor to execute the smart contract to calculate an amount of medication to be dispensed based on the duration of the trip retrieved from the blockchain ledger.

14. The system according to claim 13, wherein: The instructions further cause the processor to execute the smart contract to check whether the prescription refill is available over the counter and to notify the patient node.

15. The system of claim 13, wherein: The instructions further cause the processor to execute the smart contract to update a remaining refill quantity on the blockchain based on the prescription refill transaction.

16. The system of claim 13, wherein: The instructions further cause the processor to execute the smart contract to check local regulations before submitting the prescription refill transaction to the blockchain.

17. The system of claim 13, wherein: The instructions further cause the processor to execute the smart contract to calculate an out-of-pocket cost for the prescription refill based on the patient's insurance data retrieved from the blockchain ledger.

Images