Blockchain-Based Healthcare Security and Interoperability

Abstract

The disclosed embodiments facilitate healthcare system security and interoperability. In some embodiments, a first entity can receive encrypted blocks of information associated with a transaction from one or more second entities in response to the transaction at a first time. Each encrypted block of information can be received from a distinct second entity and can include at least one sub-block decipherable by the first entity. The first entity can decipher the decipherable sub-block and augment the multi-dimensional blockchain. The multi-dimensional blockchain can be augmented with a multi-dimensional block formed by adding at least one of the encrypted blocks of information received from the one or more second entities to a blockchain associated with the transaction and linking it to a current block maintained by the first entity. The first entity can then enable access to the multi-dimensional blockchain for at least one of the one or more second entities.

Description

[Technical Field]

[0001] The subject matter disclosed herein relates to healthcare system security and healthcare system interoperability. [Background technology]

[0002] Healthcare information systems face compliance issues that limit interoperability. For example, stored information may be subject to various privacy regulations, such as the Health Insurance Portability and Accountability Act (HIPAA). The Privacy Rule under HIPAA establishes national standards for protecting individuals' medical records and other personal health information when healthcare transactions are conducted electronically. These regulations can cover privacy (e.g., which entities have access to the information), content (what information authorized entities can access), security (how information is protected from unauthorized access when stored and during electronic communication), and integrity (accuracy and reliability of the information). Furthermore, commercially valuable information may be protected under organizational policies that can limit the sharing of that information with third parties (e.g., as trade secrets and / or for business or commercial reasons). Regulations such as the European Union (EU) General Data Protection Regulation (GDPR) can also significantly impact information collection, storage, sharing, and communication. These regulations affect the information available to healthcare market participants, leading to the creation of organizational "data silos" in which information available to entities is isolated, even if it may be useful overall (e.g., to another non-competitive entity). Such compartmentalization of information has resulted in increased system costs (e.g., by healthcare providers considering the costs of treatment alternatives), increased patient risks (e.g., from drug interactions, prescription drug abuse, etc.), and limited the effectiveness of outcomes-based approaches to medical procedures or repairs (e.g., making it more difficult and expensive to determine when a desired outcome has been achieved or to compare metrics with approaches that achieve similar outcomes).Therefore, an approach that addresses one or more of the above problems that can help facilitate healthcare information security while promoting interoperability among market participants is desirable. Summary of the Invention [Means for solving the problem]

[0003] In some embodiments, a method performed by a processor includes, in response to a transaction at a first time, receiving, at a first entity, encrypted blocks of information related to the transaction from one or more second entities, each encrypted block of information received from a separate second entity and including at least one sub-block decipherable by the first entity; deciphering, by the first entity, the decipherable sub-blocks; augmenting, by the first entity, a multidimensional blockchain, wherein the multidimensional blockchain is augmented with a multidimensional block formed by adding at least one of the encrypted blocks of information received from the one or more second entities to a blockchain associated with the transaction and linking it to a current block maintained by the first entity; and enabling access to the multidimensional blockchain for at least one of the one or more second entities.

[0004] In another aspect, a server for a first entity can include a memory, a communications interface, and a processor coupled to the memory and the communications interface. In some embodiments, the processor is configured to: receive, at the first entity via the communications interface, in response to a transaction at a first time, encrypted blocks of information associated with the transaction from one or more second entities, each encrypted block of information received from a distinct second entity and including at least one sub-block decipherable by the first entity; decipher, by the first entity, the decipherable sub-blocks; augment, by the first entity, a multidimensional blockchain resident in memory, the multidimensional blockchain being augmented with a multidimensional block formed by adding at least one of the encrypted blocks of information received from the one or more second entities to a blockchain associated with the transaction and linking it to a current block maintained by the first entity; and enable access to the multidimensional blockchain by at least one of the one or more second entities.

[0005] In a further aspect, an apparatus may comprise: means for, at a first entity, receiving encrypted blocks of information related to the transaction from one or more second entities in response to the transaction at a first time, wherein each encrypted block of information is received from a distinct second entity and includes at least one sub-block decipherable by the first entity; means for deciphering, by the first entity, the decipherable sub-blocks; means for augmenting, by the first entity, a multidimensional blockchain with a multidimensional block formed by adding at least one of the encrypted blocks of information received from the one or more second entities to a blockchain associated with the transaction and linking it to a current block maintained by the first entity; and means for enabling access to the multidimensional blockchain for at least one of the one or more second entities.

[0006] In some embodiments, a non-transitory computer-readable medium can comprise executable instructions for configuring a processor to: receive, at a first entity, via a communications interface, in response to a transaction at a first time, encrypted blocks of information related to the transaction from one or more second entities, each encrypted block of information received from a distinct second entity and including at least one sub-block decryptable by the first entity; decrypt, by the first entity, the decryptable sub-blocks; augment, by the first entity, a multidimensional blockchain resident in memory, the multidimensional blockchain being augmented with a multidimensional block formed by adding at least one of the encrypted blocks of information received from the one or more second entities to a blockchain associated with the transaction and linking it to a current block maintained by the first entity; and enable access to the multidimensional blockchain by at least one of the one or more second entities.

[0007] The disclosed methods can be performed by one or more computers, including servers, cloud-based systems, etc., using computer-readable media or computer-readable memory. [Brief explanation of the drawings]

[0008] Embodiments of the present invention will now be described, by way of example only, with reference to the drawings in which: [Figure 1A] 1 shows a schematic block diagram illustrating conventional healthcare information system operation. [Figure 1B] 1 illustrates a conventional implementation of a contract associated with a conventional blockchain system. [Figure 2] 1 illustrates an exemplary electronic health record (EHR) showing some exemplary data fields within the record. [Figure 3] 1 shows an exemplary Drug Information Record (DIR). [Figure 4] 1 illustrates an exemplary Health Transaction Record (HTR). [Figure 5A] 1 illustrates an exemplary HTR information block containing multiple sub-blocks. [Figure 5B] 1 shows an EHR information block, a DIR information block, and an HTR information block showing some of the sub-blocks associated with the information block. [Figure 6A] 1 illustrates a transaction flow associated with a multidimensional block. [Figure 6B] 1 illustrates an example Merkle tree associated with a multi-dimensional blockchain that includes multiple data records that may be associated with separate individual blockchains. [Figure 6C] 1 illustrates an example architecture of a system for facilitating healthcare information security and interoperability. [Figure 6D] 1 is a visual depiction of multi-dimensional blocks that may be associated with an exemplary automated outcome-based contract fulfillment. [Figure 7] 1 illustrates a flowchart of an exemplary method for facilitating healthcare information security and interoperability. [Figure 8] 1 shows the smart contracts associated with the smart contract layer. [Figure 9] 1 illustrates an exemplary computer that can facilitate healthcare system security and promote interoperability. DETAILED DESCRIPTION OF THE INVENTION

[0009] The disclosed embodiments facilitate security in healthcare systems while promoting the integrity and interoperability of healthcare systems.

[0010] FIG. 1A shows a schematic block diagram illustrating the operation of a conventional healthcare information system 100. A healthcare transaction may involve several entities, each of which may have some information relevant to the transaction and may use that information to complete the transaction. Thus, in conventional systems, some limited information may be exchanged between transacting entities to complete the transaction. As used herein, the term “entity” refers to an individual (such as a patient or a group of patients) or an organization or participant in the healthcare marketplace, and / or computing and information systems (e.g., hardware and / or software) associated with an individual / group / organization that may participate in the healthcare marketplace on behalf of the individual / group / organization. For example, a computing system associated with one entity may process and / or exchange information with a computing system associated with another entity. The exchange of information between entities may occur via a secure communication network and / or in a secure manner (e.g., using encryption) over the Internet.

[0011] An entity such as a patient (not shown in FIG. 1 ) may seek treatment from another entity, such as a healthcare provider (HCP) 120, for a medical condition afflicting the patient. Based on patient health information 125, which may be maintained by the HCP 120 (or obtained by the HCP 120 from the patient), the HCP 120 may determine patient insurance and treatment information 124. As shown in FIG. 1 , the HCP 120 may transmit the patient insurance and treatment information 124 to a payer / insurance company (hereinafter, “payer”) 140. The insurance-related and treatment information 124 may include patient identification (ID) information, insurance plan information, group ID information, proposed treatment, etc. However, the patient insurance and treatment information 124 may not include patient family history and / or other patient information that may not be relevant to insurance coverage and / or cost determination and / or may be prevented (e.g., by regulation) from being shared with the payer 140.

[0012] The payer 140 can compare the received insurance-related information 124 with information in a plan / coverage database 145 to determine the patient's insurance coverage. Based on the insurance coverage information, the payer 140 can update a transaction information database 147 and provide the patient's insurance coverage-related information 142 to the HCP 120. The insurance coverage-related information can include approval / denial information, insurance coverage information related to the proposed treatment, and cost and payment-related information such as the patient's copayment, billing codes, etc. If the payer withholds approval or the coverage of the proposed treatment is inadequate and / or does not meet the patient's cost criteria, the HCP can propose a modification, which can result in a further exchange of information between the HCP 120 and the payer 140.

[0013] Additionally, if a treatment recommendation is specified, the HCP 120 can also send treatment information 123 to the pharmaceutical and / or medical device provider (PMDP) 130. The treatment information 123 can include information related to the medical condition afflicting the patient and other medications used by the patient. However, the treatment information 123 cannot include any personally identifiable information (PII) related to the patient. Accordingly, the PMDP 130 can send drug / device profile and safety information 132 to the HCP 120. The drug / device profile and safety information can include information about drug characteristics such as dosage, method of administration, absorption, metabolism, duration of action, toxicity, and interactions with food or other medications. Upon receiving the drug / device profile and safety information 132, the HCP can prescribe a drug and / or medical device or modify the prescription based on the drug / device profile and safety information 132. Interaction between HCP 120, payer 140, and PMDP 130 can continue until HCP 120 finalizes a treatment plan that (a) is acceptable to the patient, (b) meets safety and efficacy considerations, and (c) can be covered and / or approved by payer 140.

[0014] Thus, traditional healthcare information systems suffer from several drawbacks. While each entity acquires and maintains information that may be relevant to operating its business, very little of that information is shared (e.g., due to legal, privacy, and / or business considerations), and when information is shared, it is often fragmented, lacking context, and not useful. For example, HCP 120 may not provide details of adverse drug effects to PMDP 130. As another example, if adverse drug effect information is provided by HCP 120 to PMDP 130, the information may not include non-PII demographic information (e.g., patient age, location, medical condition, etc.), and as a result, the information may be of limited value to PMDP 130. Additionally, in some cases, when an adverse drug effect is reported by an entity (e.g., a patient), the adverse drug effect can be verified by another entity (e.g., HCP 120) to determine whether the adverse event can be attributed to a given drug. Verification may require additional entities, introducing additional complexity that may further delay reporting and / or create additional repositories, thereby further limiting the usefulness of the information (e.g., to PMDP 130).

[0015] Additionally, because information may be compartmentalized and provided on an ad hoc basis, aggregating the received information with information stored by the receiving entity may be cumbersome. Furthermore, because each entity may index its information differently, it may be difficult or impossible for the receiving entity (or sending entity) to link the received (sent) information to the information record (e.g., stored by the sending entity) from which the sent information originated. For example, if HCP 120 provides adverse drug effect information to PMDP 130 at some point, it may be difficult for HCP 120 and / or PMDP 130 to obtain additional patient or patient condition information related to the adverse drug effect, even if that information is legally shareable. For example, compartmentalization of information may prevent or limit PMDP 130's access to aggregate demographic information that could be used to tailor drug utilization. As another example, the costs of various treatment alternatives may not be available to the patient or HCP 120 at the time a prescription or treatment plan is being developed. As a further example, it may be difficult for HCP 120 and / or payer 140 to determine prescription drug abuse by a patient.

[0016] Many modern machine learning (ML) and other artificial intelligence (AI) systems can process large amounts of data to identify patterns that can determine risk, derive desired outcomes, etc., which can lead to increased efficiency, lower costs, and / or better outcomes. Information storage and compartmentalization also limits the applicability of such ML and AI techniques, thereby resulting in inefficiencies.

[0017] Some efforts to introduce efficiency into healthcare delivery focus on outcome-based approaches. Payers 140 can tie reimbursement to the achievement of some agreed-upon outcome. For example, an outcome-based contract can specify that an HCP 120 can be reimbursed at a certain rate, the rate being based on reducing a patient's blood pressure to a certain specified range within a certain period of time. Tracking and managing such outcome-based contracts can be notoriously difficult in traditional systems because several information exchanges may need to occur between the HCP 120 and the payer 140, with each exchange following legal, regulatory, privacy, and business-related guidelines.

[0018] FIG. 1B illustrates a conventional implementation of a contract associated with a conventional blockchain system. As shown in FIG. 1B, program code can implement a contract 156 between entity A 163 and entity B 165. In conventional systems, information can be exchanged separately between entity A 163 and entity B 165 (e.g., as outlined above in connection with FIG. 1A), and that information can then be used by program code associated with contract 156 to enforce that contract. This conventional implementation suffers from several drawbacks. First, in conventional implementations, this program code associated with contract 156 can be tied to an entity (e.g., entity A 163) and therefore cannot be used to enforce other related contracts with other entities (e.g., without requiring entity A).

[0019] Furthermore, in conventional systems, the program code associated with a contract is specific to the two entities associated with that contract. Thus, if another entity, such as entity C 167, can be associated with contract 156, in conventional systems, additional code associated with (a) addendum 1 152 (to reflect the interaction between entity A 163 and entity C 167) and (b) addendum 2 154 (to reflect the interaction between entity B 165 and entity D 169) is typically added to encompass entity C 167. Thus, as the number of entities associated with a contract increases, the complexity of the system increases dramatically, thereby increasing contract management costs (coding costs, maintenance costs, etc.) and also increasing the likelihood of errors and making contract changes difficult or impractical to implement. Furthermore, because information is shared externally between entities, the likelihood of errors and / or data inconsistencies becomes very high. Additionally, in many conventional systems where a contract is used across multiple instances of an entity (e.g., hundreds of patients associated with an HCP are being treated for a medical condition), the contract is often duplicated across those instances. Thus, changes to a contract (e.g., indicating approval of a new drug to treat a medical condition) may not be easy and can take a long time to propagate through the system, thereby limiting the usefulness of the platform. In the above situations, manual approvals or manual intervention often become the norm, thereby negating the benefits of a contract management platform. While using blockchain to store health-related information can make it easier to ensure the integrity and authenticity of the stored information, conventional technologies do not address the issues, complexities, or ensure that different entities have a consistent and coherent view of stored transactions to facilitate interoperability.

[0020] The disclosed embodiments facilitate healthcare system security while promoting healthcare system integrity and interoperability. Some disclosed techniques facilitate the timely exchange (e.g., at the time of a transaction) of appropriate data (e.g., compliant with legal, privacy, and business guidelines) to appropriate entities (e.g., authorized entities associated with the transaction) while simultaneously facilitating a consistent and coherent view of information across healthcare market entities. Interoperability is facilitated in part because multiple entities associated with a transaction may be able to use standards-based agreements to tie information shared during the transaction to the transaction. Consistency and consistency are promoted because locally recorded data may correspond to reference data, and each entity's view of the reference data (or portions of the reference data viewable by an entity) is consistent with another authorized entity's view of the data. In some embodiments, the reference data may be based on and / or take the form of a distributed ledger. In some embodiments, the distributed ledger may be accessible to authorized entities, and each entity's view of the distributed ledger may comply with legal, privacy, business, and / or contractual obligations.

[0021] In some embodiments, in response to a transaction at a first time, a first entity (e.g., a pharmaceutical provider) can receive encrypted information blocks associated with the transaction from one or more second entities (e.g., a healthcare provider and / or insurance provider, and / or a patient). Each encrypted information block can be received from a distinct second entity and can include at least one sub-block decipherable by the first entity. The first entity (e.g., a pharmaceutical provider) can decipher one or more of the received decipherable sub-blocks. In some embodiments, the first entity can further augment the multidimensional blockchain with a multidimensional block. This multidimensional block can be formed by linking at least one of the encrypted information blocks received from the one or more second entities to a current block being added to a blockchain associated with the transaction, the blockchain maintained by the first entity. The first entity (e.g., a pharmaceutical provider) can enable access to the multidimensional blockchain by at least one second entity (e.g., a healthcare provider and / or insurance provider, and / or a patient).

[0022] A sub-block (within a received encrypted block) decipherable by a first entity can contain or indicate information that can be viewed by the first entity (e.g., in compliance with legal, privacy, and / or business guidelines). Conversely, information outside of a decipherable sub-block can be inaccessible to the first entity (e.g., a pharmaceutical provider) but available to a second entity (e.g., a healthcare provider) that sent the corresponding encrypted block. Furthermore, each encrypted block received by a first entity (i) can be associated with a transaction and / or (ii) can form part of a corresponding blockchain maintained by the second entity (e.g., a healthcare provider) that sent the corresponding encrypted block. In some embodiments, a current block being added to a blockchain maintained by a first entity can also include sub-blocks, each of which has information decipherable by a corresponding second entity, while information outside of the corresponding sub-block can be inaccessible to the second entity. The term sub-block refers to a portion of a data record or block that is decipherable by a particular entity or several particular entities. Thus, a consistent and coherent view of transactions is available to market entities while maintaining compliance with legal, privacy, and / or other regulatory and business considerations and promoting data integrity.

[0023] The term "blockchain" as used herein refers to a growable list of records or "blocks of information" or "blocks," where the blocks are linked using cryptographic techniques. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data. The current block being added to the blockchain is also called the head of the blockchain. A cryptographic hash function maps data of any size to a fixed-size string of bits called a "hash." A hash function may be deterministic (the same input will produce the same output) or a one-way function that is impossible to invert (i.e., determine the original data input from the hash value). The transaction data of a block can be represented as a Merkle tree root hash. The terms "Merkle tree" or "hash tree" are used to refer to a tree in which every leaf node is labeled with a hash of the transaction data and each non-leaf node is labeled with a cryptographic hash of the label associated with its child node. The block header of a block being added to the blockchain can include a hash reference to the previous block header and a hash reference to the root of the Merkle tree containing the transaction data. Blockchain promotes data integrity because changes to data within the blockchain result in a mismatch in one or more of the hash criteria. The terms record or data record are also used to refer to non-final data that is to be added to the blockchain. Once a data record is verified and finalized, it can be added to the blockchain and form a block within the blockchain.

[0024] The term "multidimensional blockchain" is used to refer to a series of multidimensional records (also referred to as a multidimensional block), where each multidimensional record includes two or more data records. In some cases, each of the data records forming a dimension of the multidimensional blockchain can form a block in a separate blockchain associated with an entity. Thus, in some embodiments, a multidimensional block can include data records in each dimension, where the data records corresponding to the dimensions can form a block in a separate conventional blockchain associated with the corresponding entity. For example, a multidimensional block can include EHR data records as one dimension, DIR data records as another dimension, and transaction data records as a third dimension.

[0025] Further, in some cases, EHR data records associated with a multidimensional block (within the multidimensional blockchain) can form blocks separately in a separate EHR blockchain (i.e., separate from the multidimensional blockchain). Similarly, in some cases, each of the DIR data records and transaction data records associated with a multidimensional block can form blocks in a separate DIR blockchain (e.g., associated with PMDP 130) and transaction record blockchain (e.g., associated with Payer 140), respectively. Thus, in some cases, data records in the context of a multidimensional blockchain can correspond to blocks in separate traditional blockchains. In some cases, each data record (e.g., associated with a dimension) in a multidimensional block can correspond to, form part of, and / or be derived from a corresponding block in a separate traditional blockchain. A multidimensional block can include a preceding multidimensional block, a timestamp, and a cryptographic hash of the data. The data in a multidimensional block can include hashes of the individual data records that make up the multidimensional block. In some embodiments, a consensus mechanism between entities can be used to verify the validity of the data in a proposed multidimensional block before the multidimensional block is bound and locked.

[0026] Thus, a multidimensional block may include two or more encrypted data records, where each encrypted data record may be associated with a separate entity (e.g., within the healthcare market). As outlined above, the data records within a multidimensional block may form blocks in separate blockchains, where each blockchain may be associated with a separate entity. Each encrypted data record may be decryptable by the corresponding associated entity (e.g., the data record owner). Furthermore, an encrypted data record may include a portion (referred to as a "sub-block") that may (or may be) decryptable by at least one other specific entity in addition to the encrypted data record owner. For example, this sub-block may have been decryptable by at least one other separate entity (in addition to the data record owner) at the time the corresponding multidimensional block was formed. In some embodiments, at the time of multidimensional block formation, the sub-block may be separately encrypted and made available to another entity along with information for decrypting the sub-block. Thus, a multidimensional block can provide a consistent and coherent view of data to authorized market entities, facilitating the availability of transactional data to multiple entities associated with the healthcare marketplace while complying with regulations, business guidelines, and / or contractual obligations and promoting data integrity. Entities can also ensure data correlation (e.g., of records associated with dimensions of a multidimensional block in a multidimensional blockchain) with corresponding blocks in a locally maintained blockchain. In some embodiments, when information is exchanged between two entities using subblocks, the information exchanged via the decipherable subblocks can be based on an information interface between the two entities.In some embodiments, when exchanging information (e.g., at the time of multidimensional block formation), each entity can encrypt a block associated with a local blockchain maintained by the entity, generating sub-blocks that are decryptable by other entities. The information interface can be based on smart contracts associated with the blockchain.

[0027] The term "smart contract" is used to refer to program code or logic associated with a blockchain or blockchain platform. This "smart contract" can encode rules or agreements between two or more entities related to data sharing, transactions, access, contract fulfillment, etc. A smart contract can be based on a contract between two or more entities and / or agreements associated with a multidimensional blockchain platform. For example, "smart contract" program code associated with a multidimensional blockchain can process transaction requests and determine the validity of the transaction based on program logic.

[0028] 2 shows an EHR 200 illustrating some exemplary data fields within a record. In some embodiments, the EHR 200 may include information about a patient. The fields shown in the EHR 200 are merely exemplary, and the EHR 200 may include various other additional fields based on legislation, standards, HCPs, and / or industry practices, etc. An EHR may include fields that differ (more or less) from those shown in connection with the exemplary EHR 200.

[0029] 2, the EHR 200 may include basic profile information 230 about the patient, which may change relatively infrequently. The basic profile information 230 may include family history 205, date of birth (DOB) 220, blood type 225, etc. The family history 205 may include maternal medical history 210 and paternal medical history 215. In some embodiments, the EHR 200 may be created and / or maintained by the HCP 120 based on information from the patient.

[0030] The EHR 200 may further include other data fields such as a diagnosis 235 (e.g., a current illness), a diagnosis code 240, which may be a standardized diagnostic code for the diagnosis (such as an International Classification of Diseases (ICD) code), a treatment code 245, which may be a standardized diagnostic code for describing the treatment (such as a Current Procedural Terminology (CPT) code), a prescription code 250 for any prescriptions, etc. The prescription code 250 may further include a medication 255 (e.g., medication name), a dose 260 (strength and frequency), and a duration 265 (length of time the medication may be taken). In some cases, the EHR 200 may also include other fields and / or subfields, such as an indication of whether the prescription is a new prescription or a refill.

[0031] In some embodiments, the EHR 200 for a patient can be stored as a blockchain, for example, by the HCP 120, and each transaction between the HCP 120 and the patient can form part of an EHR information block in the EHR blockchain. In the following description, when the EHR is maintained as a blockchain, the EHR information record 200 can also be referred to as an EHR block 200. Thus, the EHR block 200 can form a block in the EHR blockchain. When the EHR block 200 can be added to the EHR blockchain, some data in the EHR block 200 that is added to the EHR blockchain may depend on other entities. For example, the diagnostic treatment code 245 may require approval and / or verification from the payer 140 (not shown in FIG. 2 ). As another example, a drug warning label (not shown in FIG. 2 ), which can form part of the EHR block 200, can use input and / or approval from the PMDP 130 and / or the payer 140 before the EHR block 200 is added to the EHR blockchain.

[0032] In some embodiments, diagnosis 235, diagnosis code 240, treatment code 245, and prescription code 250 with data fields medication 255, dose 260, and duration 265 can be used to form sub-block 280. Sub-block 280 is merely an example illustrating some information that may be shared with another particular entity. In general, the information used to form a sub-block from a data record or block in a locally maintained blockchain (e.g., an EHR blockchain) may be subject to regulations (e.g., healthcare and / or privacy), laws governing information sharing (e.g., determining what information may or may not be shared by an entity), business guidelines (e.g., trade secrets or confidential information), and / or contractual obligations (e.g., between or associated with entities sharing information). In some embodiments, data in sub-block 280 can be shared by an entity, such as HCP 120, with another healthcare market entity, such as payer 140, to complete a transaction. However, the patient profile information associated with the basic profile information 230 may be considered private (e.g., based on legal, privacy, and / or business guidelines), and the first entity (e.g., HCP 120) may not want to share the basic profile information 230 or may want to limit the portions of the basic profile information 230 that are shared.

[0033] Thus, in some embodiments, the data used to form sub-blocks 280 may be separately encrypted. In some embodiments, the encryption of the data forming sub-blocks 280 may be based on any suitable encryption scheme, including symmetric key encryption techniques such as Advanced Encryption Standard (AES)-based techniques or variations thereof (where entities such as HCP 120 and payer 140 share a secret key). Sub-blocks 280 may be encrypted (e.g., by HCP 120) before being shared with other entities (e.g., payer 140). The other entities (e.g., payer 140) may be able to decrypt sub-blocks 280, for example, using the shared key.

[0034] Additionally, data within EHR 200 can also be separately encrypted by HCP 120 using any secure encryption technique to form EHR block 200. For example, data within EHR block 200 can be separately encrypted using different keys so that it is decryptable and usable by HCP 120, but cannot be viewed by any other entity. Thus, an encrypted EHR block 200 that may be added to an EHR blockchain by a first entity (e.g., HCP 120) can be encrypted before sharing so that (i) portions of the information are separately encrypted (e.g., within sub-block 280) and decryptable by another entity (e.g., payer 140), and (ii) information outside of sub-block 280 cannot be decrypted or accessed by other entities and remains private to HCP 120. Thus, in some embodiments, data elements that may be formed from an EHR data record may include (a) an encrypted sub-block 280 (e.g., at the time of multidimensional block formation) that includes information in field diagnosis 235, diagnosis code 240, treatment code 245, prescription code 250, drug 255, dose 260, and duration 265 that may be decipherable by a particular entity, and (b) an encrypted EHR block 200 that may include all information in the EHR record (including EHR information present in sub-block 280 as well as EHR information from outside sub-block 280) and that is decipherable by HCP 120 (the EHR owner) but not by any other entity.

[0035] Thus, in some embodiments, another entity (e.g., payer 140) may be able to decrypt the information in sub-block 280, but would not be able to decrypt the encrypted information associated with EHR block 200. In some embodiments, an encrypted EHR block 200 from a first entity (e.g., HCP 120) may include information that can be used to form multiple sub-blocks, where each sub-block (e.g., sub-block 280) may be decryptable by a separate second entity (e.g., payer 140).

[0036] 3 illustrates a typical Drug Information Record (DIR). In some embodiments, the DIR 300 can include information about a drug. The fields illustrated in the DIR 300 are merely exemplary, and the DIR 300 can include a variety of other field bases based on legislation, standards, industry practices, etc. Additionally, a DIR can include fields that differ (more or less) from those illustrated in connection with the exemplary DIR 300.

[0037] The DIR 300 may include various data fields, including a formulary 305, which may list approved prescription drugs (e.g., generic names and brand names) associated with a drug class. For example, a patient's payer (such as payer 140) may cover and / or require the use of a drug included in the formulary. The DIR 300 may also include various other data fields, including price 325, which may list the price (list price or negotiated price) at which the drug is available. The formulary 305 may further include repeating payer-i fields 310-i, (1≦i≦n), along with information about the payer. Furthermore, each listed payer-i field 310-i may include information about the corresponding drug class in repeating tier-j fields 310-j, (1≦j≦m). The drug classes list various classes of equivalent drugs, which may depend on the formulary and the payer. For example, for a prescription specified in formulary 305 and a payer specified in payer1 310-1, a category 1 315-1 drug may be a less expensive generic drug, while a category 2 315-2 drug may be a more expensive generic drug and a category 3 315-3 drug may be a brand name drug. Additionally, each category-j field 310-j may include repeat instruction-fields 310-k (1≦k≦s) with information about the medical conditions for which the prescription is approved (e.g., by a regulatory agency such as the Food and Drug Administration (FDA) and / or by payer1 310-1) for use.

[0038] Additionally, as shown in FIG. 3, the DIR 300 may include various other fields, including efficacy 327 (which may be the degree of effectiveness in treating a medical condition), safety 330 (e.g., drug interactions, toxicity, contraindications, etc.), route of administration 335 (e.g., topical, oral, intravenous, etc.), mechanism of action (MOA) 340 (which may identify the biochemical interactions by which a drug induces a pharmacological effect), side effects 345 (e.g., side effects), etc.

[0039] In some embodiments, the DIR 300 for a patient can be stored as part of a DIR blockchain by an entity such as the PMDP 130. In the following description, if the DIR is maintained as a blockchain, the DIR information record 300 can also be referred to as a DIR block 300. Thus, the DIR block 300 can form a block within the DIR blockchain. When the DIR block 300 can be added to the DIR blockchain, some data in the DIR information block 300 that is added to the DIR blockchain may depend on verification by other entities. For example, information in the formulary 305 associated with a payer (e.g., payer 140) designated in payer1 310-1, which may form part of the DIR block 300, may depend on verification by the payer (e.g., payer 140) before the DIR block 300 is added to the DIR blockchain.

[0040] In some embodiments, for a current transaction, information in data field formulary 305, payer1 310-1, the segment information in each segment-j field 310-j associated with a payer in payer1 310-1, and the information in each instruction-k field 310-k associated with each segment-j field can be used to form sub-block 385. However, information related to other payers in payer-i fields 310-i (2≦i≦n) cannot form part of sub-block 385 because that information may be confidential (e.g., between each payer in payer-i, 2≦i≦n, and PMDP 130), and PMDP 130 may not expect and / or be prevented from contractually sharing information related to a payer with other payers. Sub-block 385 is merely an example illustrating some information that may be shared with another specific entity. In general, the information used to form sub-blocks from data records or blocks within a locally maintained blockchain (e.g., DIR300) may depend on regulations (e.g., healthcare and / or privacy), laws governing information sharing (e.g., determining what information entities can or cannot share), business guidelines (e.g., trade secrets or confidential information), and / or contractual obligations (e.g., between or relating to the entities sharing the information).

[0041] Thus, in some embodiments, the data in the sub-blocks 385 may be encrypted separately. In some embodiments, the encryption of the data in the sub-blocks 385 may be based on any suitable encryption technique, including symmetric key encryption techniques, based on a secret key shared with another entity (e.g., the payer 140 identified in the Payer 1 310-1 field) before being shared. The other entity (e.g., the payer 140) may be able to decrypt the sub-blocks 385, for example, based on the shared key.

[0042] Additionally, as shown in FIG. 3 , another sub-block 380 can be formed from the DIR 300. The sub-block 380 can include fields such as efficacy 327, safety 330, route of administration 335, mechanism of action (MOA) 340, and side effects 345. The sub-block 380 is merely an example illustrating some of the information that may be shared with another particular entity. As outlined above, the information used to form the sub-block 380 from a data record or block within a locally maintained blockchain (e.g., the DIR 300) may depend on regulations (e.g., healthcare and / or privacy), laws governing information sharing (e.g., determining what information an entity can or cannot share), business guidelines (e.g., trade secrets or confidential information), and / or contractual obligations (e.g., between or associated with the entities sharing the information). The sub-block 380 can be separately encrypted using a private key shared with another entity (e.g., the PMDP 130). Thus, the PMDP 130 may be able to use the secret shared key to decrypt and view the information in the sub-block 380 .

[0043] Additionally, the data in the DIR block 300 may also be separately encrypted by a first entity (e.g., PMDP 130) using any secure encryption technique so that the data is decryptable and available to the first entity (e.g., PMDP 130), but not viewable by other entities (e.g., HCP 120 and / or payer 140). Thus, in some embodiments, data elements that may be formed from a DIR data record include: (a) information in formulary 305, payer 1 310-1, payer 1 310-2, payer 1 310-3, payer 1 310-4, payer 1 310-5, payer 1 310-6, payer 1 310-7, payer 1 310-8, payer 1 310-9, payer 1 310-10, payer 1 310-11, payer 1 310-12, payer 1 310-13, payer 1 310-14, payer 1 310-15, payer 1 310-16, payer 1 310-17, payer 1 310-18, payer 1 310-19, payer 1 310-20, payer 1 310-21, payer 1 310-22, payer 1 310-23, payer 1 310-24, payer 1 310-25, payer 1 310-36, payer 1 310-37, payer 1 310-38, payer 1 310-41, payer 1 310-42, payer 1 310-43, payer 1 310-44, payer 1 310 (b) an encrypted sub-block 385 (e.g., at the time of multidimensional block formation) containing the segment information for each of the segment-j fields 310-j associated with the payer in 310-1 and the information for each of the instruction-k fields 310-k associated with each segment-j field; (b) an encrypted sub-block 380 (e.g., at the time of multidimensional block formation) containing the information in efficacy 327, safety 330, route of administration 335, mechanism of action (MOA) 340, and side effects 345; and (c) an encrypted DIR block 300 that may contain all information within DIR record 300 (including DIR information also present in sub-blocks 380 and 385, as well as DIR information from outside sub-blocks 380 and 385) and that is decipherable by PMDP 130 (the block owner) but not by any other entity.

[0044] Thus, encrypted sub-blocks 380 and 385 that may be formed by PMDP 130 may be decipherable by HCP 120 and payer 140, respectively. Additionally, PMDP 130 may encrypt DIR block 300 such that the information in DIR block 300 may not be viewable by entities other than PMDP 130. In some embodiments, an encrypted DIR information block 300 from a first entity (e.g., PMDP 130) may contain information that may be used to form multiple sub-blocks (e.g., 380 and 385), where each sub-block may be decipherable by a separate second entity (e.g., HCP 120 and payer 140, respectively).

[0045] 4 illustrates an exemplary health transaction record (HTR) 400. As illustrated in FIG. 4, the HTR 400 may include treatment-related and cost-related information for a patient at a point in time. The fields illustrated in the HTR 400 are merely exemplary, and the HTR 400 may include various other fields based on legislation, standards, industry practices, etc. Additionally, the HTR may include different fields (more or less) than those illustrated in connection with the exemplary HTR 400.

[0046] In some embodiments, the HTR 400 can be maintained by an entity such as the payer 140. The HTR 400 can include various data fields, including a patient 425 (e.g., a patient ID), a cost 405, which can represent a cost associated with the transaction. The cost 405 can include a payer cost 410 (e.g., to the payer 140), a drug cost 415 (e.g., the cost of the prescribed drug(s)), an HCP cost (the cost due to the healthcare provider), and a patient cost 425. The patient cost 425 can be affected by a patient co-payment 430, a copayment limit 435, and a deductible 440, which can be affected by the patient's health insurance coverage and previous transactions.

[0047] In some embodiments, the HTR 400 may further include various other fields, including a diagnosis 445 (for the patient's medical condition), a diagnosis code 450 (e.g., for the current medical condition), a treatment code 455 (e.g., a CPT code or another standardized code to describe the treatment), a repeating field medication codes 460-1, 460-2, ..., which may be standardized codes to identify certain medications, and a procedure code 465 to describe a medical procedure associated with treating the medical condition.

[0048] In some embodiments, a patient's HTR 400 at a given point in time can be stored as a blockchain by an entity such as the payer 140. In the following description, if the HTR is maintained as a blockchain, the HTR information record 400 can also be referred to as an HTR block 400. Thus, the HTR block 400 can form a block within the HTR blockchain. For example, data related to transactions between the HCP 120 and the patient and / or between the patient and the payer 140 can form part of the HTR block 400 within the HTR blockchain. When the HTR block 400 is added to the HTR blockchain, some of the data in the HTR block 400 that is added to the HTR blockchain may be subject to verification by other entities. For example, the information in the diagnosis 445 can be verified by the HCP 120 before the HTR block 400 is added to the HTR blockchain.

[0049] In some embodiments, for a transaction at a given time, information such as data fields diagnosis 445, diagnosis code 450, treatment code 455, and repeating fields drug code 460-1, 460-2 may form part of sub-block 485. Sub-block 485 may be shared with PMDP 130 to determine whether a drug is approved for the described diagnosis, determine safety (e.g., drug interactions), etc.

[0050] In some embodiments, information in fields patient ID 425 and co-payment 430 can be used to form another sub-block 480. Sub-block 480 can be shared with HCP 120 to facilitate determining co-payment information for the transaction. Sub-blocks 480 and 485 are merely examples to illustrate information that may be shared by payer 140 with a particular entity. In general, the information used to form sub-blocks from data records or blocks (e.g., HTR 400) in a locally maintained blockchain may be subject to regulations (e.g., healthcare and / or privacy), laws governing information sharing (e.g., determining what information may or may not be shared by an entity), business guidelines (e.g., trade secrets or confidential information), and / or contractual obligations (e.g., between or relating to entity-shared information).

[0051] Thus, in some embodiments, the data in sub-blocks 480 and 485 may be encrypted separately. In some embodiments, the encryption of the data in sub-block 485 may be based on any suitable encryption technique, including symmetric key cryptography, based on a secret key shared with the PMDP 130 before being shared. The PMDP 130 may be able to decrypt sub-block 485 based on a secret key shared between the PMDP 130 and the payer 140. Additionally, sub-block 480 may be encrypted separately based on a different secret key shared with the HCP 120. The HCP 120 may be able to decrypt and view the information in sub-block 480 using the secret key shared between the HCP 120 and the payer 140. Furthermore, the data in the HTR information block 400 may also be encrypted separately by a first entity (e.g., the payer 140) using any secure encryption technique, such that the data is decryptable and usable by the payer 140, but cannot be viewed by the HCP 120 and / or the PMDP 130.

[0052] Thus, in some embodiments, data elements that may be formed from an HTR data record may include: (a) an encrypted sub-block 480 (e.g., at the time of multidimensional block formation) containing information in fields Patient ID 425 and Co-Payment 430; (b) an encrypted sub-block 485 (e.g., at the time of multidimensional block formation) containing information in fields Diagnosis 445, Diagnosis Code 450, Treatment Code 455, and repeating fields Drug Code 460-1, 460-2; and (c) an encrypted HTR block 400 that may contain all information in HTR record 400 (HTR information also present in sub-blocks 480 and 485, as well as HTR information from outside sub-blocks 480 and 485), and that is decipherable by payer 140 (the HTR block owner), but not by any other entity. Thus, in some embodiments, an encrypted HTR information block 400 from a first entity (e.g., payer 140) may contain information that can be used to form multiple sub-blocks (e.g., 480 and 485), where each sub-block may be decipherable by a separate second entity (HCP 120 and PMDP 130, respectively).

[0053] 5A shows an example HTR information block 540 that includes sub-blocks 480 and 485. EHR information block 540 may be added to an EHR blockchain 545 maintained by a first entity, such as payer 140. In some embodiments, block 540 may be encrypted by payer 140, such that it can be decrypted and read by payer 140 (but not by other entities).

[0054] In some embodiments, a sub-block 480 within an EHR information block 540 may be encrypted by the payer 140 using symmetric key cryptography based on a secret shared key with another entity, such as the HCP 120. The HCP 120 can use the shared key to decrypt the sub-block 480. However, information in the block 540 outside of the sub-block 480 may not be decryptable by the HCP 120.

[0055] Additionally, sub-blocks 485 within the HTR information block 540 may be encrypted by the payer 140 using symmetric key cryptography based on a secret shared key with an additional entity such as the PMDP 130. The PMDP 130 can use the shared key to decrypt the sub-blocks 485. However, information in the block 540 outside of the sub-blocks 485 may not be decryptable by the PMDP 130.

[0056] FIG. 5B shows an EHR information block 520, a DIR information block 520, and an HTR information block 540 illustrating several sub-blocks associated with the information blocks.

[0057] 5B, current information block 540 added to HTR blockchain 545 maintained by payer 140 may contain information that can be used to form sub-blocks 480 and 485. As outlined above, sub-block 480 may be decipherable by HCP 120, whereas sub-block 485 may be decipherable by PMDP 130. Also, as outlined above, block 540 may be separately encrypted by payer 140 and may be undecipherable by entities other than payer 140 (e.g., to comply with legal, privacy, contractual, and / or business guidelines).

[0058] As shown in FIG. 5B , exemplary EHR information block 520 can include information that can be used to form sub-blocks 280. EHR information block 520 can be added to an EHR blockchain 525 maintained by HCP 120. In some embodiments, sub-blocks 280 within EHR information block 540 can be encrypted (e.g., by HCP 120) using symmetric key cryptography based on a secret shared key with a first entity, payer 140. Payer 140 can decrypt sub-block 280 using that shared key. As outlined above, HCP 120 can also decrypt sub-block 480 using a private key shared with payer 140. Furthermore, information within block 520 can be separately encrypted by HCP 120, such that the information may be undecipherable by entities other than HCP 120 (e.g., to comply with legal, privacy, contractual, and / or business guidelines).

[0059] 5B , the exemplary DIR information block 530 can include sub-blocks 385. The DIR information block 530 can be added to a DIR blockchain 535 maintained by another second entity, such as the PMDP 130. In some embodiments, the sub-blocks 385 within the DIR information block 530 can be encrypted by the PMDP 130 using symmetric key cryptography based on a secret shared key with the payer 140. The payer 140 can use the shared key to decrypt the sub-blocks 385. The PMDP 130 can also decrypt the sub-blocks 485 using a private key shared with the payer 140. Furthermore, the information within block 530 can be separately encrypted by the PMDP 130, and the information can be undecipherable by entities other than the PMDP 130 (e.g., to comply with legal, privacy, contractual, and / or business guidelines).

[0060] 5B, information interface 524 between payer 140 and HCP 120 can include information shared using sub-blocks 460 and 280. Thus, information in an information interface (e.g., information interface 524) between two entities (HCP 120 and payer 140) can be interpreted by both HCP 120 and payer 140. Similarly, information interface 534 between a first entity, payer 140, and a second entity, PMDP 130, can include information shared using sub-blocks 385 and 485, and information in information interface 534 can be interpreted by both PMDP 130 and payer 140.

[0061] FIG. 6A illustrates a transaction flow 600 associated with a multidimensional block. FIG. 6A is merely exemplary, and for ease of explanation, several steps between two entities in the transaction flow associated with block 540 are outlined. Additional steps to obtain a multidimensional block may follow a similar pattern. In FIG. 6A, the sub-blocks shown and the fields described are merely examples to illustrate the process flow and information that may be shared. In general, the information used to form sub-blocks from data records or blocks in a locally maintained blockchain may be subject to regulations (e.g., healthcare and / or privacy), laws governing information sharing (e.g., determining what information entities may or may not share), business guidelines (e.g., trade secrets or confidential information), and / or contractual obligations (e.g., between or associated with the entities sharing the information). Once a data record is verified and completed, the completed data record can be added to the local blockchain as a block.

[0062] FIG. 6A illustrates an HTR blockchain 545, which may be maintained by a first entity, such as payer 140. In FIG. 6A, data record 540 may be added to blockchain 545. FIG. 6A also illustrates an EHR blockchain 525, which currently has record 520 at the head of the blockchain, and a DIR blockchain 535, which currently has record 530 at the head of the blockchain. In some embodiments, blockchains 525 and 535 may be maintained by second entities, HCP 120 and PMDP 130, respectively (not shown in FIG. 6A). In some embodiments, when a transaction request is submitted, the most recent block from each blockchain may be submitted to form a multi-dimensional blockchain.

[0063] In some embodiments, an update on a conventional blockchain (e.g., one of blockchains 525, 535, or 545) by a corresponding entity (e.g., one of HCP 120, PMDP 130, or Payer 140, respectively) that includes information from another entity and / or encompasses other entities can be verified by one or more other entities (e.g., locally in blockchain 525, 535, or 545 and / or in an associated multidimensional blockchain) before the update is bound. In some embodiments, each field associated with information blocks 520, 530, and / or 540 can have a distinct global field id that can uniquely identify the field to the multidimensional blockchain system and / or appropriate entities when information related to the field is shared between entities.

[0064] In some embodiments, a transaction request may be sent by an entity (e.g., by payer 140) to an appropriate entity (e.g., HCP 120 and / or PMDP 130) when a record such as record 540 may be added to a blockchain maintained by the entity. In some embodiments, the transaction request may be placed in a request pool. In some embodiments, the various entities HCP 120, PMDP 130, payer 140, etc. may form part of a permissioned blockchain platform. In a permissioned blockchain platform, trusted entities may form the platform and invite other trusted entities to join the network. In some embodiments, the permissioned blockchain platform may also be private. In some embodiments, the permissioned blockchain platform may support multi-dimensional blockchains. Rules related to accessing and adding blocks to the multi-dimensional blockchain, program code for determining contracts (e.g., smart contracts) between entities, validation of updates, etc. may be determined by entities associated with the permissioned blockchain platform.

[0065] If payer 140 is authorized to access and update the platform, in some embodiments, where data record 540 may be added, payer 140 may branch and encrypt sub-block 480, which may optionally contain information from portions of data record 540. The information in sub-block 480 may then be decrypted and read by HCP 120. In some embodiments, sub-block 480 may be encrypted using a symmetric encryption algorithm.

[0066] As outlined above, for ease of explanation, in the following description, two data records 520 and 540 are initially considered to be from blockchains 525 and 545, respectively. As shown in FIG. 6A , a fork operation 605 can fork data record 540 to form a forked sub-block 480. In some embodiments, fork operation 605 can serve as a trigger to initiate multidimensional block formation. A sub-block fork operation can include duplicating and encrypting (e.g., using a private key shared with another entity) some subset of data within a data record or block of a local blockchain to form a sub-block (e.g., sub-block 480). In some embodiments, this sub-block can be replicated in memory. For example, the sub-block can reside in memory used to form the multidimensional block (e.g., multidimensional block 610). In-memory sub-block replication can facilitate speed, storage, and complete deletion of replicated objects (e.g., when multidimensional block formation is complete). Information associated with the original local block (eg, local block 540) is not affected by the branch operation (eg, branch operation 605).

[0067] For example, branch 605 may result in sub-block 480 being replicated, separated from block 480, and encrypted separately. The encryption key may be shared with HCP 120, may take the form of an authorization code, and / or may be included as part of an authorization code transmitted from a first entity (payer 140) to a second entity (HCP 120) over a secure channel. HCP 120 may use the authorization code received from payer 140 to decrypt sub-block 480. In some embodiments, sub-block 480 may be replicated in memory. In-memory sub-block replication may facilitate speed, storage, and complete deletion of replicated objects (e.g., when multidimensional block formation is complete).

[0068] 6A, the forking operation 607 may also fork the data record 520 to form a forked sub-block 280 when the data record 520 is submitted by the HCP 120. In some embodiments, the forking operation 607 may result in the sub-block 280 being duplicated, split from the data record 520, and separately encrypted. The encryption key may be shared with the payer 140 and may take the form of and / or be included as part of an authorization code sent from the HCP 120 to the payer 140 over a secure channel. The payer 140 may use the authorization code received from the HCP 120 to decrypt the sub-block 280.

[0069] In some embodiments, after verification, the information in sub-blocks 280 and 480 forms an information interface between data records 520 and 540 and may be incorporated into records 520 and / or 540 (e.g., by storing and / or updating in appropriate fields within records 520 and / or 540). As an example, HCP 120 may decode and read sub-block 480 to obtain co-payment 230 and patient ID 425. Similarly, payer 140 may decode and read sub-block 480 to obtain diagnosis codes 240, treatment codes 245, prescription codes, etc. However, information outside sub-block 280 within block 520 may remain private to HCP 120. Similarly, information outside sub-block 480 within block 540 may remain private to payer 140. As previously outlined, information interfaces between entities may be subject to law (e.g., privacy, data sharing, healthcare, business, competition), contractual obligations between entities (e.g., entered by the entities), and / or business considerations (e.g., trade secrets, etc.). Thus, the above examples are merely illustrative, and the actual data shared and / or contained within data records, blocks, and sub-blocks may differ from those examples.

[0070] In some embodiments, the information in sub-blocks 480 and / or 280 may be verified, and after successful verification, updated data record 520 and updated data record 540 may be linked to obtain unlocked multidimensional block 610. In some embodiments, updated records 520 and 540 and multidimensional block 610 may be kept in unlocked form (not yet bound to any blockchain) at this stage. The term "unlocked" is used to indicate that the information in multidimensional block 610 is not yet final and may be subject to change as the transaction moves toward completion. For example, if the information in sub-blocks 480 and / or 280 is determined to be inaccurate or invalid (as further outlined below), the transaction may be rejected. In some embodiments, updated records 520 and / or 540 may be rehashed after linking. A multidimensional block (unlocked or locked) may include data and a timestamp. The data may include data records 520, 530, and / or 540. The timestamps determine the order in which the multidimensional blocks (when verified and completed) are linked together.

[0071] In some embodiments, HCP 120 and / or payer 140, and / or other authorized entities associated with the blockchain, can determine whether the information in the decrypted sub-block corresponds to the information associated with blocks 520 and / or 540, respectively. Consensus techniques can verify the correctness of the transactions that make up the multidimensional block. In some embodiments, a consensus technique, such as Byzantine Fault Tolerance (BFT), or variations thereof such as redundant BFT, or some other voting-based consensus technique, can be used to determine whether multidimensional block 610 can be formed using blocks 520 and 540. Consensus is achieved when an authorized entity (e.g., payer 140), or some specified number (e.g., a majority) of entities, validates the transaction or block.

[0072] If the transaction is verified as correct through consensus techniques, a first instance of the (unlocked) multidimensional block 610 can be formed. Conversely, if, for example, the patient identified as patient ID 425 in subblock 480 does not match the patient ID (e.g., in subblock 280), the transaction is deemed invalid and the block add request can be rejected. In some embodiments, the platform, or each entity, can maintain a log of rejected transactions for traceability and debugging purposes. This log can indicate the reason and code associated with the transaction rejection.

[0073] In some embodiments, the agreement layer can include consensus technology and interact with the smart contract layer to establish the correctness and / or validity of transactions. In some embodiments, each update on a traditional blockchain (e.g., one of blockchains 200, 300, or 400) by a corresponding entity (e.g., HCP 120, PMDP 130, or payer 140) can be verified by smart contract program code associated with the multidimensional blockchain. This smart contract program code can reflect agreements between entities related to data sharing, authentication, settlement, etc. The smart contract layer can be viewed as an automated tool that facilitates interactions between entities without manual intervention. In some embodiments, the smart contract layer can initiate actions based on rules associated with one or more contracts when those rules are satisfied. Each update to the multidimensional blockchain, the passage of time, and / or other events can trigger actions by the smart contract layer.

[0074] The linking of updated records (e.g., updated record 520 and updated record 540) can be performed based on predefined rules agreed upon by the entities (e.g., HCP 120 and payer 140). In some embodiments, the linking of blocks (e.g., updated block 520 and updated block 540) can be performed based on smart contract(s) associated with the multi-dimensional blockchain. After linking, updated block 520 and updated block 540 can be rehashed. As outlined above, this linking can enable an entity to correlate information in its blockchain with information in a blockchain maintained by another entity. Additionally, those entities may be able to determine the transaction or transactions associated with information in a particular block maintained by that entity. Thus, two or more entities can have a consistent and coherent view of transactions associated with blocks in separate blockchains.

[0075] Thus, the disclosed embodiments facilitate (a) authenticating transactions, (b) protecting the integrity of transactions, (c) maintaining the provenance of transactions, (d) complying with legal, privacy, and business guidelines when sharing information, and (e) providing context for data maintained by an organization. For example, it may be possible for an organization to determine the source of external data or transactions received by the organization. As another example, a multidimensional blockchain may facilitate the use of real-world evidence (RWE) by a PDP 130 to analyze and evaluate efficacy, efficacy, and dosage information based on actual patient prescriptions. For example, an HCP may be able to share efficacy, efficacy, and dosage information, along with some demographic information (e.g., age, location (zip code), medical condition, diagnosis, etc.), with a PMDP 130 without providing any personally identifiable or sensitive information about the patient. Such RWE information has historically been difficult to obtain (due to legal, privacy, and other issues) and difficult to analyze (because, when obtained, the information was often obtained in fragments and lacking context, i.e., lacking demographic and / or other useful information). In some embodiments, a smart contract layer can be used to manage information interface / data sharing so that data shared with participants can be related to specific entities on a termly basis and can comply with laws, privacy regulations, and / or contractual obligations while respecting business-related considerations.

[0076] 6A shows updates to data records corresponding to multiple dimensions of a multidimensional block. However, in some embodiments, a new multidimensional block may be formed with updates to data records of a single dimension, while substantive information associated with other dimensions may remain unchanged. For example, drug-related information associated with a drug prescribed to a patient may be updated (e.g., by PMDP 130) in the new multidimensional block without updates to EHR data 520 or payer transaction records 140.

[0077] As shown in FIG. 6A, multidimensional block 610 may be an unlocking block, which may be non-final and still be modified. Multidimensional block 610 may include a link between updated data record 520 and updated data record 540. Sub-blocks 280 and 480 may form an information interface between records 520 and 540. In some embodiments, the information interface may be defined and / or managed by a smart contract layer. For example, information shared between transaction-type entities (such as within sub-block 280 and / or sub-block 480) may be specified and verified by program code in a smart contract layer associated with the multidimensional blockchain.

[0078] FIG. 6A illustrates the further augmentation of multidimensional block 610 through successive transformations, for example, by the addition of another dimension, based on record 530 (which may follow the flow outlined above for multidimensional block 610). In FIG. 6A, in each iteration, an information interface between two entities (two dimensions within the multidimensional block) is shown addressed. For example, in a subsequent iteration (e.g., after the formation of unlocked multidimensional block 510), payer 140 can branch sub-block 485 from data record 540, and PMDP 130 can branch sub-block 385 from data record 530. As outlined above, in some embodiments, sub-block 485 can be replicated and separately encrypted using a key that may be shared with PMDP 130 (e.g., via an authorization code). Similarly, sub-block 385 can be replicated and separately encrypted using a key that may be shared with payer 140 (e.g., via an authorization code). After verification, blocks 530 and 540 can be linked and rehashed. Additionally, the data in updated block 540 may have changed, and the link from block 520 to the newly updated block 540 may also be updated.

[0079] FIG. 6B shows an example Merkle tree 622 associated with a multidimensional blockchain including data records 520, 530, and 540. In FIG. 6B, the example Merkle tree 622 is associated with a multidimensional blockchain including multiple data records, each of which may be associated with a separate individual blockchain. The Merkle tree 622 is merely an example, and other forms may be used as appropriate. In some embodiments, the data records 520, 530, and / or 540, when validated and completed, may form blocks in corresponding separate blockchains (e.g., blockchains 525, 535, and / or 545, respectively). When in an unlocked state, the example Merkle tree 622 and the data in records 520, 530, and 540 may not be validated and / or may not be final. As shown in FIG. 6B, a hash C 631 may be obtained by using a cryptographic hash function on the data record 520. Cryptographic hash functions are deterministic (produce the same output for the same input data), computationally inexpensive (in terms of resource usage to generate the output for a given input), preimage-resistant (it is difficult to determine the input from the output), and collision-resistant (illustratively, produce different outputs for different inputs). Similarly, hash D 633, hash E 635, and hash F 637 can be obtained by using appropriate cryptographic hash functions on data records 530, 540, and D4, respectively. In FIG. 6B, record D4 is used to indicate several other (e.g., patient) records, but are not directly applicable to the discussion of FIG. 6A. Cryptographic hash functions 631, 633, 635, and 639 may be unique to entities associated with entities HCP 120, PMDP 130, payer 140, and D4, respectively. Thus, HCP 120 may be able to decrypt data record 520 (but not the entities associated with PMDP 130, payer 140, or D4).Conversely, data records 530, 540, and D4 may be readable by entities associated with PMDP 130, payer 140, and D4 (but not any other entity).

[0080] Furthermore, hash A 627 can be obtained by using an appropriate cryptographic hash function on the combination of hash C 631 and hash D 633, while hash B 629 can be obtained by using an appropriate cryptographic hash function on the combination of hash E 635 and hash F 637. Finally, top hash 625 can be obtained by using an appropriate cryptographic hash function on the combination of hash A 627 and hash B 629. Data associated with hash C 631 (hash output (520)), hash D 633 (hash output (530)), hash E 635 (hash output (540)), and hash F 637 (hash output (D4)) can be shared among authorized entities (e.g., by entities forming a multidimensional block) without compromising the security of data records 520, 530, 540, or D4. Similarly, hash A 627, hash B 629, and top hash 625 can also be shared.

[0081] Referring to FIG. 6A, each iteration / step can be followed by unlocking blocks. In some embodiments, when the information exchange related to a transaction is complete and the transaction is verified by the consensus and / or smart contract layer, blocks 520, 530, and / or 540 can be rehashed (as appropriate), links can be updated, and the multidimensional block can also be locked and bound as multidimensional block 655 (FIG. 6C). Thus, an entity can verify the integrity of a multidimensional block (e.g., completed multidimensional block 655 in FIG. 6C) associated with a local block (e.g., completed blocks 520, 530, and 540) associated with a conventional local blockchain (e.g., blockchains 525, 525, and 545). 6C , multidimensional block 655 can include verified and completed data records 520, 530, and 540, which can correspond to completed information blocks 520, 530, and 540, respectively, in corresponding separate local blockchains 525, 535, and 545, respectively. In some embodiments, each multidimensional block can include a block header with a timestamp, a top hash 625, information related to previous blocks, a pointer to the root of Merkle tree 625, and other suitable information. The hash reference can take the form of a uniform resource locator (URL) on the private permissioned blockchain platform and / or a local (entity-specific) address.

[0082] 6C illustrates an exemplary architecture of a system 650 for facilitating healthcare information security and interoperability. In some embodiments, the system 650 can be based on the use of a multi-dimensional blockchain, which can be based on separate blockchains maintained by individual entities within the system. In some embodiments, the system 650 can include a private permissioned blockchain platform. In some embodiments, the system 650 can take the form of a cloud-based system. A cloud-based system refers to applications, services, and / or other resources (including hardware resources) that can be made available over a network (e.g., the Internet). A cloud-based system can be based on underlying hardware and software resources and can be public (e.g., available to any location on a fee-for-service basis), private (e.g., limited to an organization), or hybrid (using some combination of public and private clouds).

[0083] The exemplary system 650 may include various entities. These entities may be represented by servers (hardware and / or software), which may in some cases be cloud-based. For example, the HCP 120, the PMDP 130, and / or the payer 140 may include servers and / or run on cloud-based platforms including virtual machines (VMs).

[0084] Figure 6C shows an HTR blockchain 545, which may be coupled to and maintained by a first entity, such as a payer 140. Figure 6C also shows an EHR blockchain 525 with block 520 at the head of the blockchain, and a DIR blockchain 535 with block 530 at the head of the blockchain. In some embodiments, blockchains 525 and 535 may be maintained by second entities, HCP 120 and PMDP 130, respectively.

[0085] As shown in FIG. 6C , the HCP 120, the PMDP 130, and / or the payer 140 can interact with an authentication layer 680. The authentication layer 660 can include functionality for identifying and managing (adding, registering, and deleting) system entities during operation. Additionally, the authentication layer can include functionality for verifying permissions associated with operations on the multi-dimensional blockchain (e.g., adding new blocks, creating links, etc.). The authentication layer 660 can interact with an agreement layer 670, which can include functionality for determining transaction ordering and verifying the validity of a set of transactions associated with a block.

[0086] In some embodiments, the consensus layer 670 can verify the validity of the transactions that make up a multidimensional block. In some embodiments, a consensus technique such as Byzantine Fault Tolerance (BFT), or a variation thereof such as redundant BFT, or some other voting-based consensus technique can be used to determine whether a multidimensional block 610 (FIG. 6A) can be formed. If a designated authoritative entity, or some designated number of entities (e.g., a majority), validates the transaction or block, consensus regarding the validity and / or outcome associated with the transaction or block can be achieved. In some embodiments, the consensus layer 670 can interact with and use functionality in the smart contract layer 680 to verify the validity of an ordered set of transactions associated with a block.

[0087] The smart contract layer 680 can include program code that implements logic related to the blockchain. For example, "smart contract" program code associated with the multidimensional blockchain can process transaction requests and determine the validity of the transaction based on program logic. This logic can depend on rules agreed upon by entities for transactions related to the blockchain. For example, the smart contract layer 680 can reject a transaction (e.g., from HCP 120) due to an incompatibility between two or more medications prescribed for a patient. The smart contract can operate at validation time and before a block is committed. In some embodiments, the smart contract layer 680 can determine and / or verify information interfaces between entities associated with the multidimensional blockchain. For example, the smart contract layer 680 can encode rules or agreements between two or more entities related to data sharing, transactions, etc., which can be based on physical contracts between the entities. In some embodiments, each update on a traditional blockchain (e.g., one of blockchains 625, 635, or 645) by a corresponding entity (e.g., HCP 120, PMDP 130, or Payer 140) can also be verified by a smart contract layer 680 associated with the multidimensional blockchain. In some embodiments, the validation, completion, and linking of blocks can be performed based on smart contract(s) associated with the multidimensional blockchain. In some embodiments, the smart contract program code can be triggered by one or more events associated with the platform, such as time, a request to add a block from one or more entities, and / or a specific request associated with the contract (e.g., identified by a contract ID).

[0088] FIG. 6C illustrates a bound and locked multidimensional block 655, in which information from sub-blocks 480, 280, 380, and 385 is shared according to appropriate authorized entities. Additionally, multidimensional block 655 includes links to blocks 540, 530, and / or 520. Multidimensional block 655 can represent, in part, a holistic view of a transaction at a point in time because it can include real-world physical conditions associated with the drug (usage, effects, etc.), the patient (condition, treatment, effects), and the cost at that time. Multidimensional block 655 can include links to previous blocks in the blockchain. A verified and completed multidimensional block 655 can include completed data records 520, 530, and 540, which can correspond to completed information blocks 520, 530, and 540, respectively, and to separate local blockchains 525, 535, and 545, respectively.

[0089] 6D is a visual depiction of a multidimensional block that may be associated with an exemplary automated outcome-based contract execution. In some embodiments, a smart contract layer can facilitate automated outcome-based contract execution based on a multidimensional blockchain.

[0090] As shown in FIG. 6D , a three-dimensional (3D) blockchain 690 can include a series of 3D blocks, where each 3D block includes an EHR data record, a DIR data record, and an HTR data record. FIG. 6C shows data record DIRp 692, which can form part of a multidimensional block and can be associated with a particular medication (e.g., medication p). For example, in FIG. 6D , the multidimensional block including record DIRp 692 can represent a multidimensional block formed (a) at a certain point in time when a patient is first diagnosed with some particular condition and (b) when a healthcare provider begins treatment with a particular medication. For example, the treatment start date, diagnosis code, and medication fields may be shared between entities, identifying the multidimensional block including record DIRp 692. As outlined above, data shared between entities may be subject to legal (e.g., privacy, data sharing, healthcare, sales, competition), contractual obligations between the entities (e.g., entered by the entities), and / or business considerations (e.g., trade secrets, etc.). Therefore, the examples discussed herein are merely illustrative, and the actual data shared and / or contained within the data records, blocks, and sub-blocks may differ from the examples.

[0091] Because a single drug (e.g., drug p) can treat many patients, many EHR blocks, including a 3D block that includes an EHRq block 694, can form a multidimensional blockchain associated with drug p along the EHR axis. Similarly, a single drug (e.g., drug p) can be associated with many transactions. Thus, many HTR blocks, including a 3D block associated with an HTRr block 696, can form a multidimensional blockchain associated with drug p along the HTR axis.

[0092] An outcome-based contract between HCP 120 and payer 140 may state that payment may be made by payer 140 to HCP 120 when a condition within the bound multidimensional block is met. For example, the condition may specify one of: (i) the value of some health parameter; or (ii) an improvement in some health parameter of the patient within some time period when the patient is treated with some medication. In some embodiments, the contract term may be encoded as a smart contract, which may automatically initiate payment when the condition is met, as further outlined below.

[0093] When a patient's treatment begins and a prescription for the patient is submitted, a request can be sent to the network to initiate a multidimensional blockchain by connecting the EHR information block for the patient, the DIR information block for the given drug, and the transaction information block to form an initial multidimensional (3D) block (such as a 3D block containing DIRp data record 692).

[0094] At some point, when a 3D block such as 3D block 698 is bound to an EHR block (associated with 3D block 698) that indicates either that a health parameter value has been met or that a desired improvement in a health parameter has been achieved over the course of treatment with the drug, the smart contract can determine whether the outcome was within a specified time period and automatically initiate an action. The action can include one or more of: indicating contract completion, sending a notification to an entity associated with the contract, initiating a transaction to trigger payment from the payer 140 to the HCP 120, and determining and / or recording parameters associated with the contract (e.g., length of time, initial and final values ​​of the appropriate health parameters, number of visits, dosage, etc.). In some embodiments, the transaction to trigger payment can include smart contract code that triggers the payment and ensures traceability. The time period can be determined based on the elapsed time, for example, as determined by the difference between the timestamp associated with the last bound 3D block 698 of the treatment and the timestamp associated with an earlier multidimensional block (e.g., an occurrence block) if the treatment was initiated within the multidimensional blockchain.

[0095] 6C, in some embodiments, a smart contract layer 680 may also be implemented in each dimension of the multi-dimensional blockchain to ensure that the multi-dimensional blocks are constructed correctly. In the above example, the smart contract layer may ensure based on the EHR that each multi-dimensional block in the blockchain is associated with the same patient, diagnosis, and drug, and / or contract ID (e.g., between HCP 120 and payer 140).

[0096] In some embodiments, when a patient (which may be an entity) in the system 650 is prescribed a drug, the smart contract layer 680 can query the payer 140 regarding the patient's insurance coverage and eligibility for the drug, and can also request patient approval and agreement on its price. Once agreement on eligibility and price is solidified, construction of the multidimensional block can begin.

[0097] In some embodiments, the holistic view enabled by a multidimensional blockchain can facilitate the use of machine learning and AI techniques based on RWE. For example, pharmaceutical and medical device providers may severely restrict access to data, except for clinical trials. In some embodiments, by correlating demographic information related to drug prescriptions (which may be included within EHR subblocks, in compliance with regulatory and business guidelines), pharmaceutical and medical device providers may be able to understand the drug's effect on various demographic groups, modify dosages, monitor adverse outcomes, etc. Such data correlation (e.g., enabled via a multidimensional blockchain) may enable preventative measures (e.g., increasing or decreasing dosage, identifying previously unknown drug interactions, etc.) that can reduce patient risk, improve safety and health outcomes, and reduce costs. Additionally, because sharing between entities is limited, patient privacy between patients and other entities can be maintained. Additionally, the use of smart contracts in conjunction with a multidimensional blockchain can facilitate maintaining contract confidentiality between entities, even when payments are routed between them.

[0098] 7 shows a flowchart of an example method 700 for facilitating healthcare information security and interoperability. In some embodiments, method 700 may use a multi-dimensional blockchain, which may be based on separate blockchains maintained by individual entities within the system. In some embodiments, method 700 may be performed on a private permissioned blockchain platform, which may, in some cases, take the form of a cloud-based system. Method 700 may be performed by a processor, a computer, or a network of computers, such as a distributed computing system, an application server, and a server (hardware and software), including a cloud-based system.

[0099] In some embodiments, method 700 can be performed at a first entity. For example, the first entity can include at least one server or computer system associated with at least one of a pharmaceutical provider or a medical device provider, such as PMDP 130. In some embodiments, the first entity can interact with one or more second entities. The second entities can include one or more servers or computer systems associated with a healthcare provider, such as HCP 120, or an insurance provider, such as payer 140, or a patient. In some embodiments, the first entity and the one or more second entities can form computing nodes in a distributed computing system, and the multidimensional blockchain can form part of a permissioned private blockchain platform, such as permissioned private blockchain platform 650.

[0100] In some embodiments, method 700 can be invoked when an entity, such as a first entity, initiates a transaction to add a block to a locally maintained blockchain. Adding a block to the local blockchain can invite input from one or more other entities, and permissioned private blockchain platform 650 can invoke method 700.

[0101] In some embodiments, at step 710, a first entity may receive encrypted information blocks associated with the transaction from one or more second entities in response to the transaction at a first time. Each encrypted information block may be received from a distinct second entity and may include at least one sub-block decipherable by the first entity. In some embodiments, for each encrypted information block received by the first entity, the corresponding sub-block decipherable by the first entity may be based on an information interface between the first entity and the corresponding second entity. The information interface between the first entity and the corresponding second entity may be determined based on predefined rules that govern interactions between the first entity and the corresponding second entity. In some embodiments, the information interface between the first entity and the corresponding second entity may be determined by a smart contract (e.g., based on smart contract layer 680) associated with the multidimensional blockchain. In some embodiments, the smart contract may be associated with the multidimensional blockchain and form part of a permissioned private blockchain platform. In some embodiments, smart contracts may reflect agreements related to information sharing, privacy, and contractual obligations between entities associated with a permissioned private blockchain platform.

[0102] In some embodiments, in step 720, the first entity may decrypt the sub-blocks decipherable by the first entity. In some embodiments, to decipher the sub-blocks, the first entity may receive corresponding authorization codes from one or more second entities associated with the received encrypted information block and decipher the decipherable sub-blocks using the received authorization codes. In some embodiments, the decipherment of the sub-blocks by the first entity may be based on a key securely shared with the corresponding second entity. For example, when the sub-blocks were encrypted by some particular second entity, the first entity may decipher the sub-blocks using a key shared with or received from that second entity. In some embodiments, the shared key may be securely received by the first entity as part of the authorization code.

[0103] In step 730, the first entity may augment the multidimensional blockchain. The multidimensional blockchain may be augmented with a multidimensional block formed by linking at least one of the encrypted information blocks received from one or more second entities to a current block associated with the transaction and being added to the blockchain maintained by the first entity. Augmenting may include adding the multidimensional block to an existing blockchain or adding the first multidimensional block to a multidimensional blockchain structure (e.g., adding the multidimensional block to a newly created multidimensional blockchain). In some embodiments, the current block may include one or more sub-blocks, where each sub-block of the current block may be based on an information interface between the first entity and a corresponding second entity and may be decipherable by the corresponding second entity. For example, the content of sub-block j in the current block may be based on an information interface between the first entity and a corresponding second entity, such as second entity j, and sub-block j may be decipherable by second entity j.

[0104] In some embodiments, augmenting may include adding a new multidimensional block to the multidimensional blockchain. The multidimensional blockchain may be stored and made accessible to one or more second entities associated with the permissioned private blockchain platform. In some embodiments, augmenting a multidimensional blockchain with a multidimensional block (e.g., multidimensional block 655) may include determining the validity of data associated with one or more sub-blocks (e.g., sub-blocks 280, 380, 385, 480, and / or 485). In some embodiments, the validity may be determined in part by a smart contract layer (e.g., smart contract layer 680) associated with the permissioned private blockchain platform. For example, the smart contract layer (e.g., smart contract layer 680) may request validation from one or more of the entities associated with the permissioned private blockchain platform. In some embodiments, the smart contract layer (e.g., smart contract layer 680) may determine an authorized entity or entities to validate data associated with one or more sub-blocks and request validation from the authorized entity or entities. In some embodiments, the validity of data associated with one or more sub-blocks may be based on consensus techniques. In some embodiments, Byzantine Fault Tolerant (BFT) techniques may be used to determine the validity and / or reaching of consensus. In some embodiments, upon augmenting the multidimensional blockchain with the multidimensional blocks, a first entity may invoke at least one smart contract associated with the permissioned private blockchain platform.In some embodiments, the first entity may receive from the smart contract an indication of one or more contractual milestones and / or completion of one or more contractual outcomes between the first entity and one or more second entities based on information associated with the multidimensional blockchain.

[0105] In some embodiments, augmenting the multi-dimensional blockchain with multi-dimensional blocks may enable a smart contract layer (e.g., smart contract layer 680) to evaluate conditions associated with contracts between entities associated with the permissioned private blockchain platform to determine whether a contractual milestone (e.g., between HCP 120 and payer 140) has been met, whether a health parameter (e.g., meeting a desired criteria within a certain period of time from the start of treatment) has been met, whether a desired contract outcome (e.g., maintenance of a health parameter over a certain period of time) has been met, whether another contract-related event has occurred, etc. In some embodiments, upon determining that one or more contract events have occurred in connection with a contract, the smart contract layer (e.g., smart contract layer 680) may perform one or more actions as outlined by the contract. For example, a smart contract layer (e.g., smart contract layer 680) may (a) report contract-related events to involved authorized entities (e.g., contracting parties, etc.); (b) report contract-related data, such as health parameters, cost items, and / or performance parameters (as authorized by the contract), to appropriate entities; (c) automatically initiate actions, such as invoicing, approval, settlement, and reporting, without human intervention; and (d) store information about contract-related events and associate actions taken in connection with contract-related events with the corresponding contract(s).

[0106] Additionally, in some embodiments, the smart contract layer (e.g., smart contract layer 680) can initiate other operations to analyze the data and identify risks and other factors that may affect treatment, outcomes, etc. In some embodiments, the smart contract layer (e.g., smart contract layer 680) can initiate or use machine learning tools and AI techniques based on the RWE associated with the multidimensional blockchain. For example, a particular medication (DIR) may be associated with multiple patients, and each DIR data record for the drug associated with a multidimensional block in the multidimensional blockchain may include some demographic, non-personal information (e.g., age, medical condition, zip code, other prescribed medications, etc.) of the patient for whom the drug was prescribed (e.g., received via an EHR subblock). In some embodiments, when a specified number of transactions related to a drug have occurred (e.g., data in the multidimensional blockchain has been properly validated using functionality associated with the smart contract layer prior to binding the multidimensional block), and / or when a specified period of time has passed (e.g., since the drug's introduction or the last machine learning run), the smart contract layer (e.g., smart contract layer 680) can initiate machine learning based on DIR data records associated with the drug across multiple patients. The machine learning may be able to predict or increase awareness of potential risks associated with the drug (medical conditions, side effects, drug interactions, etc.) and / or identify instances where drug efficacy was above par, dosage adjustments, etc. Thus, pharmaceutical and medical device providers (e.g., PMDPs 130) may be able to understand the effects of drugs on various demographic groups, dosage modifications, monitoring for adverse outcomes, etc. Such data correlation (e.g., enabled via multi-dimensional blockchain) can be useful in taking preventative measures (e.g., increasing or decreasing dosage, previously unknown drug interactions, etc.) that can reduce patient risk, increase safety and health outcomes, and simultaneously reduce costs.Additionally, in situations where DIR records associated with a particular prediction can be determined, the corresponding multidimensional blocks (e.g., associated with those DIRs) can be used by an entity (e.g., by PMDP 130) to further validate the prediction (e.g., determine whether further research is needed).

[0107] At step 740, the first entity may be able to access the multidimensional blockchain for at least one of the one or more second entities. In some embodiments, access to the multidimensional block may be possible by encrypting the multidimensional block based on a cryptographic hashing function (e.g., as described in connection with FIG. 6B ) and storing the multidimensional blockchain including the multidimensional block along with access permissions, allowing access by one or more second entities. For example, the multidimensional blockchain may be stored in memory coupled to the processor or computer system executing method 700. In some embodiments, the multidimensional block may be stored on cloud-based storage and made accessible to appropriate entities associated with the permissioned private blockchain platform. As outlined above, entities associated with the permissioned private blockchain platform may be able to verify the integrity of information associated with an appended multidimensional block, although data records (e.g., data records 520, 530, and 540) that may be associated with particular entities may remain private to those entities. Additionally, as outlined above, a multidimensional block (e.g., multidimensional block 655) may include linkages between local data records and data records (e.g., data records 520, 530, and 540), which may in some cases form blocks in corresponding separate local blockchains (e.g., 525, 535, and 545, respectively).

[0108] Figure 8 illustrates smart contracts associated with a smart contract layer (e.g., smart contract layer 680). As shown in Figure 8, smart contract 1 810 may be implemented to reflect an agreement between contracting entities payer 140, patient 805, and HCP 120. Smart contract 2 820 may be implemented to reflect an agreement between payer 140 and PMDP 130. Smart contract 3 830 may be implemented to reflect an agreement between PMDP 130 and patient 805, while smart contract 4 840 may be implemented to reflect an agreement between PMDP 130 and HCP 120. In some embodiments, smart contracts (e.g., smart contract 1 810, smart contract 2 820, smart contract 3 830, and smart contract 4 840) may be stored in a contract database. In some embodiments, each smart contract (e.g., smart contract 1 810, smart contract 2 820, smart contract 3 830, and smart contract 4 840) can include program code with rules to evaluate data associated with a multidimensional block in a multidimensional blockchain. In some embodiments, a smart contract layer (e.g., smart contract layer 680) can decipher the information in one or more sub-blocks (on behalf of the receiving entity) and make a decision based on the code / rules associated with the corresponding smart contract. For example, an entity can delegate some functionality to the smart contract layer, or the smart contract layer can act as a proxy for the entity when authorized. In some embodiments, one or more entities can securely share information with the smart contract layer for data validation and / or contract management.The smart contract layer (e.g., smart contract layer 680) can flag data errors, ensure the integrity of data reported by entities to other entities associated with the permissioned private blockchain platform, perform data validation, and specify and / or monitor information interfaces between entities and / or data shares to ensure authorized data is shared. For example, the smart contract layer (e.g., smart contract layer 680) can use global field IDs and / or known correlations between fields to ensure that data reported by an entity is consistent with other entities in a transaction. As an example, the smart contract layer 680 can ensure that information in a medical parameter field (e.g., blood pressure) reported by the HCP 120 to the patient 805 and the payer 140 is consistent.

[0109] Because information is shared based on sub-blocks on a permissioned private blockchain platform, a smart contract layer (e.g., smart contract layer 680) may be able to implement contracts between multiple entities, such as smart contract 1 810 between entities payer 140, patient 805, and HCP 120. As outlined above, conventional systems may not be able to implement contracts between more than two entities. Additionally, multi-dimensional blockchains ensure data security for data records associated with a particular entity (so that the data records are unreadable by other unauthorized entities). Furthermore, because completed data blocks (e.g., 520, 530, and 540) in separate local blockchains (e.g., 525, 535, and 545, respectively) correspond to data records in completed multidimensional blocks (e.g., multidimensional block 655), entities associated with the permissioned private blockchain platform (e.g., HCP 120, PMDP 130, and payer 140) share a consistent and coherent view of that information and can easily correlate with the local blockchain. The smart contract layer (e.g., smart contract layer 680) can also facilitate rapid system updates because the same contract can be applied to classes of entities (e.g., patient 805) when applicable. Thus, for example, an update to Smart Contract 1 810 to reflect approval of a new medication for a medical condition by Payer 140 may be quickly available to all patients associated with Smart Contract 1 (e.g., patients such as Patient 805 associated with Payer 140 who are being treated for the condition by HCP 120). Furthermore, the broad impact of changes to smart contracts is localized: a change to Smart Contract 4 840 between PMDP 130 and HCP 120 will only affect the entities involved.In conventional systems, other contracts / entities (e.g., the addendum outlined in Figure 1B) may be tied to the contract between two entities, so the ripple effect can have a significant impact on the other entities / contracts.

[0110] In some embodiments, as outlined above, the smart contract layer (e.g., smart contract layer 680) may evaluate a contract periodically (e.g., at specified time intervals) and / or when a contract-related event occurs (e.g., a transaction and / or multidimensional block addition), which may be requested by an entity associated with the contract and / or when agreed upon by the entity. For example, smart contract layer 680 may evaluate conditions associated with smart contract 1 810 between HCP 120, payer 140, and patient 105. In the above example, smart contract 1 810 may (a) indicate information authorized to be shared between the entities (e.g., using sub-blocks), (b) specify milestones for the contract (e.g., between HCP 120 and payer 140 to determine whether health parameters of patient 805 meet certain desired criteria within a certain period of time from the start of treatment), (c) specify criteria for contract fulfillment, and (d) specify actions to be initiated upon contract / milestone fulfillment.

[0111] For example, a milestone in smart contract 1 may specify that patient 805's blood pressure be reduced below a certain range within a certain period of time, and may specify a first payment from payer 140 to HCP 120 if the milestone is met within the certain period of time. Additionally, smart contract 1 may specify an additional payment from payer 140 to HCP 120 if patient 805's blood pressure range remains within the specified range for a certain period of time. Upon submission of a data record by HCP 120 (with appropriate sub-blocks decipherable by payer 140), smart contract 1 may determine the time elapsed since the start of treatment (e.g., based on timestamps associated with corresponding multidimensional blocks associated with patient 805 and HCP 120) and examine the blood pressure range. If the milestone is met, smart contract 1 may report the milestone to an entity, store information associated with the milestone, generate an invoice with the appropriate information, and initiate payment from payer 140 to HCP 120. At a later point in time, smart contract 1 may determine that patient 805's blood pressure range remained within a predetermined range (e.g., based on timestamps associated with corresponding multidimensional blocks associated with patient 805 and HCP 120), report the outcome to the entity, store information associated with the outcome determination, generate an invoice, send a report with the appropriate information, and initiate another settlement from payer 140 to HCP 120.

[0112] In some embodiments, upon determining that one or more contract events have occurred in connection with some contract, the smart contract layer (e.g., smart contract layer 680) can perform one or more actions as outlined by the contract. For example, the smart contract layer (e.g., smart contract layer 680) can (a) report the contract-related event to an involved authorized entity (e.g., a contracting party, etc.), (b) report contract-related data, such as health parameters, cost items, and / or performance parameters (as authorized by the contract), to the appropriate entity, (c) automatically initiate actions, such as invoicing, approval, settlement, reporting, etc., without human intervention, (d) store information about the contract-related event and associate actions taken in connection with the contract-related event with the corresponding contract(s), and / or (e) initiate tools (e.g., machine learning, etc.) to analyze data associated with the multi-dimensional blockchain.

[0113] FIG. 9 illustrates an exemplary computer 900 that can facilitate healthcare system security and promote interoperability. In some embodiments, the computer 900 can act as a host and / or interact with a permissioned private blockchain platform. In some embodiments, the exemplary computer 900 can be a server for one or more entities (e.g., HCP 120, PMDP 130, and / or payer 140) or can execute a server (e.g., an application server). In some embodiments, the computer 900 can implement method 700 and / or other techniques disclosed herein. In some embodiments, the computer 900 can form part of a distributed computing system and can implement a permissioned private blockchain platform. In some embodiments, the distributed computing system and / or the computer 900 can be cloud-based.

[0114] In some embodiments, the computer 900 / processor(s) 950 may be capable of processing transaction requests, including requests related to adding blocks to a blockchain, including a multidimensional blockchain. Additionally, the computer 900 / processor(s) 950 may be capable of running encryption and / or decryption algorithms, obtaining hashes of blocks of information, verifying hashes, performing digital signatures, and performing and / or supporting various methods to facilitate security and authentication. Authentication may refer to both verifying the integrity of stored information (e.g., within a block in the blockchain to determine any unauthorized modifications) and ensuring that entities accessing the permissioned private blockchain platform are trustworthy and have permission to perform any requested transactions. In some embodiments, the computer 900 / processor(s) 950 may also be capable of augmenting (creating or adding) the blockchain with new blocks (including augmenting a multidimensional blockchain with multidimensional blocks). In some embodiments, the computer 900 / processor(s) 950 may also store and execute smart contracts associated with the blockchain to implement agreements between entities (e.g., HCP 120, PMDP 130, payer 140, and / or patient(s)) related to privacy, information sharing, contract execution, etc.

[0115] In some embodiments, the computer 900 / processor(s) 750 may be capable of analyzing and using machine learning techniques to determine relationships between various health parameters. For example, the computer 900 / processor(s) 950 may include one or more neural network processor(s) and / or distributed processors that may be configured as neural networks, and may execute software for modeling and / or simulating neural networks, which software may be used to implement machine learning. For example, the PMDP 130 may use machine learning-based RWE information available through the multidimensional block (e.g., demographic information, side effects, drugs used in combination with particular drugs of interest, treatment outcomes, etc.) to tailor drug usage. For example, machine learning may be used to determine effective doses, target drugs based on demographics, improved drug interaction information, increased safety, the relative effectiveness of various administration modes, etc. As outlined above, this information may be unavailable to the PMDP 130 except in clinical trials, thereby precluding or severely limiting the use of machine learning and AI techniques.

[0116] In some embodiments, computer 900 can be coupled to other computers using communication / network interface 902, which can include wired (e.g., Ethernet, including Gigabit Ethernet) and wireless interfaces. The wireless interface can be based on Wireless Wide Area Network (WWAN) standards, such as cellular standards, including 3G, 4G, and 5G standards, the IEEE 802.11x standard, commonly known as Wi-Fi.

[0117] The computer 900 may include memory 904, which may include one or more of read only memory (ROM), programmable read only memory (PROM), various types of random access memory (RAM), non-volatile RAM, etc. The memory 904 may be implemented within the processor(s) 950 or external to the processor(s) 950. As used herein, the term "memory" may refer to any type of long term, short term, volatile, non-volatile, or other memory, and may not be limited to any particular type or number of memories or the type of medium on which the memory is stored.

[0118] The memory may include cache memory, primary memory, and secondary memory. The secondary memory may include computer-readable medium 920. The computer-readable medium may include magnetic and / or optical media, which may in some cases be removable media. Removable media may include optical discs, such as compact discs (CDs), laser discs, digital video discs (DVDs), Blu-ray discs, and other optical media, as well as USB drives, flash drives, solid-state drives, memory cards, etc. The computer 900 may also include storage 960, which may include hard drives, solid-state drives (SSDs), flash memory, other non-volatile storage, and cloud-based storage.

[0119] The communication / network interface 902, storage device 960, memory 904, and computer-readable medium 920 may be coupled to the processor(s) 950 using connections 906, which may take the form of buses, lines, optical fibers, links, etc.

[0120] The methods described herein may be implemented by various means, depending on the application. For example, the methods may be implemented in hardware, firmware, software, or any combination thereof. In a hardware implementation, the processor(s) 950 may be implemented in one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), neural network processors (NNPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, or combinations thereof.

[0121] In the case of a firmware and / or software implementation, the methods may be implemented with microcode, procedures, functions, etc. that perform the functions described herein. Any machine-readable medium tangibly embodying instructions may be used to implement the methods described herein. For example, software may be stored in storage device 960 and / or on a removable computer-readable medium. Program code may reside in computer-readable medium 920, storage device 960, and / or memory 904 and may be read and executed by processor(s) 950.

[0122] When implemented in firmware and / or software, the functionality may also include one or more instructions or code on the computer-readable medium 920, the storage device 960, and / or the memory 904. Examples include computer-readable media encoded with data structures and computer programs. For example, the computer-readable medium 920 may include program code stored thereon, including program code for supporting methods for facilitating healthcare system security and promoting system interoperability, including supporting multi-dimensional blockchains, smart contracts, consensus determination, and performing other functions associated with a permissioned private blockchain platform as described herein.

[0123] The processor(s) 950 may be implemented using a combination of hardware, firmware, and software. In some embodiments, the computer 900 may be coupled to a display to facilitate viewing of the GUI and interaction with administrators and other users.

[0124] While the present disclosure has been described in connection with specific embodiments for educational purposes, the present disclosure is not limited thereto. Various adaptations and modifications can be made to the present disclosure without departing from the scope of the present invention. Therefore, the spirit and scope of the appended claims should not be limited to the foregoing description.

Claims

1. 1. A processor-implemented method comprising: receiving, at a first entity in response to a transaction at a first time, encrypted blocks of information associated with the transaction from one or more second entities, each encrypted block of information received from a distinct second entity and including at least one sub-block decryptable by the first entity; decrypting, by the first entity, the decryptable sub-block; augmenting, by the first entity, a multidimensional blockchain such that the multidimensional blockchain is augmented with a multidimensional block formed by combining at least one of the encrypted information blocks received from the one or more second entities with a current block associated with the transaction and being added to a blockchain maintained by the first entity, wherein the multidimensional block includes two or more data records in each dimension, and the data records corresponding to a dimension form a block in a separate conventional blockchain associated with a corresponding second entity; and A multidimensional block in the augmented multidimensional blockchain is characterized by including a previous multidimensional block, a timestamp, and a cryptographic hash of data; enabling at least one of the one or more second entities to access the multidimensional blockchain.

2. Enabling access to the multidimensional blockchain 2. The method of claim 1, comprising: encrypting the multidimensional block based on a hashing function; and storing the multidimensional blockchain including the multidimensional block along with access permissions to enable access by the one or more second entities.

3. 2. The method of claim 1, wherein decrypting the sub-block comprises receiving, by the first entity, a corresponding authorization code from the one or more second entities associated with the received encrypted information block, and decrypting the decryptable sub-block using the received authorization code.

4. The method of claim 1 , wherein the first entity comprises at least one server associated with at least one of a pharmaceutical provider or a medical device provider.

5. The method of claim 1 , wherein the one or more second entities include one or more servers associated with at least one of a healthcare provider, an insurance provider, or a patient.

6. 10. The method of claim 1, wherein the first entity and the one or more second entities are computing nodes in a distributed computing system, and the multi-dimensional blockchain forms part of a permissioned private blockchain platform.

7. 10. The method of claim 6, further comprising: invoking at least one smart contract associated with the permissioned private blockchain platform upon augmenting the multidimensional blockchain with the multidimensional block by the first entity.

8. 8. The method of claim 7, further comprising receiving, from the smart contract, an indication of completion of one or more contract milestones between the first entity and the one or more second entities based at least in part on information associated with the multidimensional blockchain.

9. a server for a first entity, the server comprising: a memory; a communication interface; a processor coupled to the memory and the communication interface, the processor: receiving, at the first entity via the communications interface in response to a transaction at a first time, encrypted blocks of information associated with the transaction from one or more second entities, wherein each encrypted block of information is received from a distinct second entity and includes at least one sub-block decryptable by the first entity; decrypting, by the first entity, the decryptable sub-block; augmenting, by the first entity, a multidimensional blockchain resident in the memory, such that the multidimensional blockchain is augmented with a multidimensional block formed by linking at least one of the encrypted information blocks received from the one or more second entities to a current block associated with the transaction and being added to a blockchain maintained by the first entity, wherein the multidimensional block includes two or more data records in each dimension, the data records corresponding to a dimension forming a block in a separate conventional blockchain associated with a corresponding second entity; and A multidimensional block in the augmented multidimensional blockchain is characterized by including a previous multidimensional block, a timestamp, and a cryptographic hash of data; enabling access to the multidimensional blockchain by at least one of the one or more second entities; and A server comprising:

10. To enable access to the multidimensional blockchain, the processor: encrypting the multidimensional block based on a hashing function; and storing the multidimensional block chain including the multidimensional block in the memory.

11. To decrypt the sub-blocks, the processor: receiving, by the first entity, a corresponding authorization code from the one or more second entities associated with the received encrypted information block; and decrypting the decryptable sub-block using the received authorization code.

12. The server of claim 9 , wherein the first entity comprises at least one server associated with at least one of a pharmaceutical provider or a medical device provider.

13. The server of claim 9 , wherein the one or more second entities include one or more servers associated with at least one of a healthcare provider, an insurance provider, or a patient.

14. 14. The server of claim 13, wherein the first entity and the one or more second entities are computing nodes in a distributed computing system, and the multi-dimensional blockchain forms part of a permissioned private blockchain platform.

15. 15. The server of claim 14, wherein the processor is further configured to invoke at least one smart contract associated with the permissioned private blockchain platform upon augmenting the multidimensional blockchain with the multidimensional block.

16. 15. The server of claim 14, wherein the processor is further configured to receive, from the smart contract, an indication of completion of one or more contract milestones between the first entity and the one or more second entities based at least in part on information associated with the multidimensional blockchain.

17. A non-transitory computer-readable medium containing executable instructions, The executable instructions: receiving, at the first entity via the communications interface in response to a transaction at a first time, encrypted blocks of information associated with the transaction from one or more second entities, wherein each encrypted block of information is received from a distinct second entity and includes at least one sub-block decryptable by the first entity; decrypting, by the first entity, the decryptable sub-block; augmenting, by the first entity, a multidimensional blockchain resident in the memory, such that the multidimensional blockchain is augmented with a multidimensional block formed by linking at least one of the encrypted information blocks received from the one or more second entities to a current block associated with the transaction and being added to a blockchain maintained by the first entity, wherein the multidimensional block includes two or more data records in each dimension, the data records corresponding to a dimension forming a block in a separate conventional blockchain associated with a corresponding second entity; A multidimensional block in the augmented multidimensional blockchain is characterized by including a previous multidimensional block, a timestamp, and a cryptographic hash of data; enabling access to the multidimensional blockchain by at least one of the one or more second entities; A non-transitory computer-readable medium configured to cause a processor to:

Images