Blockchain-based healthcare security and interoperability

Abstract

To facilitate healthcare security and interoperability.SOLUTION: A first entity receives encrypted information blocks associated with a transaction at a first time from one or more second entities. Each encrypted information block is received from a separate second entity, and includes at least one sub-block decryptable by the first entity. The first entity decrypts the sub-block, and augments a multi-dimensional blockchain. The multi-dimensional blockchain is augmented with a multi-dimensional block formed by adding at least one of the received encrypted information blocks to a blockchain associated with the transaction and linking it to a current block maintained by the first entity, thereby allowing at least one of the one or more second entities to access the multi-dimensional blockchain.SELECTED DRAWING: Figure 7

Description

[Technical Field]

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

[0002] Healthcare information systems face compliance issues that limit interoperability. For example, stored information may be used to Various privacy regulations, such as the Privacy Portability and Accountability Act and HIPAA The Privacy Rule under HIPAAA is intended to Protecting personal medical records and other personal health information when transactions are conducted electronically These regulations provide national standards for privacy (e.g., which entities the entity has access to the information), the content (what authorized entities information can be accessed), security (when information is stored and (how the data is protected from unauthorized access during communication) and Furthermore, commercially valuable information can be used to determine the accuracy and reliability of that information. may be protected under organizational policies that can limit sharing with third parties (e.g., as trade secrets and / or for business or commercial reasons). EU General Data Protection Regulation (GDPR) ) can also have a significant impact on information collection, storage, sharing, and communication. These regulations affect the information available to healthcare market participants and The available information may be of general utility (e.g., to another non-competitive entity) leads to the creation of organizational "data silos" that are disconnected even when data is being used Such compartmentalization of information can lead to increased system costs (e.g., the need to select alternative treatment options). by cost-conscious healthcare providers), increased patient risk (e.g., drug interactions, treatment (e.g., from overuse of herbal medicines) and limiting the effectiveness of outcome-based approaches to medical treatment or repair. to determine when a desired outcome has been achieved or to determine when a similar outcome has been achieved. (It becomes more difficult and expensive to compare the metrics of the approach being developed.) This will facilitate interoperability between market participants while also strengthening the healthcare information security. Approaches that address one or more of the above problems can help facilitate security. Chi is desired. Summary of the Invention [Means for solving the problem]

[0003] In some embodiments, the processor-implemented method comprises: In response to the transaction, at the first entity, receiving encrypted information blocks from one or more second entities, each The encrypted information block is received from a separate second entity and transmitted to the first entity. receiving a first sub-block including at least one sub-block decodable by the first sub-block; Decrypting the decryptable sub-block by an entity; Increasing the multidimensional blockchain by At least one of the encrypted information blocks received from one or more second entities The first one is added to the blockchain associated with the transaction. It is formed by linking to the current block maintained by the entity augmenting the multidimensional block, and adding one or more second entities to the multidimensional block; enabling access to the multidimensional blockchain of at least one of the entities; and,

[0004] In another aspect, a server for the first entity includes a memory and a communication interface. and a processor coupled to the memory and the communication interface. In some embodiments, the processor communicates with the first In response to the transaction at the time, the first entity receiving from one or more second entities an encrypted block of information associated with the session; wherein each encrypted information block is received from a distinct second entity. , a received packet including at least one sub-block decipherable by the first entity. and decrypting the decryptable sub-block by a first entity. 1 entity to augment the multidimensional blockchain that resides in memory wherein the multi-dimensional blockchain receives from one or more second entities At least one of the encrypted blocks of information is associated with the transaction. The current blockchain is maintained by the first entity. As it is augmented with multidimensional blocks formed by linking blocks, and multidimensional block by at least one of the one or more second entities. and enabling access to the block chain.

[0005] In a further aspect, the device generates a first event in response to a transaction at a first time. The entity sends one or more encrypted blocks of information related to the transaction. a means for receiving from a second entity, each encrypted block of information comprising: At least one of the following is received from a separate second entity and decipherable by the first entity: and a subblock decipherable by the first entity. A means for decrypting a block and a first entity creating a multidimensional blockchain A multi-dimensional blockchain is a means for increasing the number of transactions between one or more second entities. At least one of the encrypted information blocks received from the transaction The transaction is added to a blockchain associated with the transaction and maintained by the first entity. multidimensional blocks formed by linking to the current block and a multidimensional block of at least one of the one or more second entities. and means for enabling access to the lock chain.

[0006] In some embodiments, the non-transitory computer readable medium may be The executable instructions may be transmitted via a communications interface. In response to a transaction at a first time, a transaction is Receives encrypted blocks of information relating to the transaction from one or more second entities. and transmitting each encrypted information block from a separate second entity. the first entity decrypts the encrypted data, and the encrypted data includes at least one sub-block decrypted by the first entity; receiving, by the first entity, the decryptable sub-block; and augmenting the in-memory resident multidimensional blockchain with the first entity. wherein the multi-dimensional blockchain receives from one or more second entities Associate at least one of the encrypted blocks of information with the transaction. The current blockchain is added to the blockchain and maintained by the first entity. As augmented with multidimensional blocks formed by linking blocks , augmenting, and multidimensional by at least one of one or more second entities and configuring the processor to provide access to the blockchain. It is something that is done.

[0007] The disclosed method includes using a computer readable medium or computer readable memory to The software may be executed by one or more computers, including servers, cloud-based systems, etc. Cut. [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 promote the integrity and interoperability of healthcare systems while: Facilitating security in the healthcare system.

[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, where each An entity may have some information related to its transaction, That information can then be used to complete the transaction. In traditional systems, some limited information is required to complete a transaction. As used herein, information may be exchanged between transacting entities. In this context, the term "entity" refers to an individual (such as a patient or group of patients) or an organization or Participants in the healthcare market and / or those providing healthcare services on behalf of individuals, groups or organizations Computing systems associated with individuals / groups / organizations that may participate in the marketplace; An information system (e.g., hardware and / or software), e.g., an entity The computing systems associated with an entity may be associated with other entities. The computing system can be used to process and / or exchange information. The exchange of information between the entities is via secure communications networks and / or over the Internet. This can be done in a secure manner over the Internet (e.g., using encryption).

[0011] An entity such as a patient (not shown in Figure 1) may provide health information about the medical conditions that afflict the patient. They may seek treatment from another entity, such as a healthcare provider (HCP)120. can be maintained by the HCP 120 (or obtained by the HCP 120 from the patient), Based on the patient's health information 125, the HCP 120 determines the patient's insurance and treatment information 124. As shown in FIG. 1, the HCP 120 may collect patient insurance and treatment information 124. Insurance-related and treatment-related Treatment information 124 includes patient identification (ID) information, insurance plan information, group ID information, proposed treatment, etc. However, patient insurance and treatment information 124 may include information such as patient family history and / or may not contain other patient information, such as insurance coverage and / or may not be relevant to cost determinations and / or may not be shared with payers 140 (e.g., regulatory may be hindered by

[0012] The payer 140 may then store the received insurance-related information 124 in a plan / coverage database 14 5 to determine the patient's insurance coverage. Based on the information, the payer 140 updates the transaction information database 147; Patient insurance coverage related information 142 may be provided to the HCP 120. Relevant information includes approval / denial information, insurance coverage information related to the proposed treatment, and and cost and payment related information such as patient copayments and billing codes. Payers withhold approval or coverage for the proposed treatment is inadequate and / or If the cost criteria are not met, the HCP may propose a modification. The modifications may result in further exchange of information between the HCP 120 and the payer 140. .

[0013] In addition, if treatment is prescribed, the HCP 120 also provides treatment information 1 23 to the pharmaceutical provider and / or medical device provider (PMDP) 130 Treatment information 123 includes the medical conditions afflicting the patient, other medical treatments used by the patient, However, the treatment information 123 may also include information related to the patient. It cannot contain any personally identifiable information (PII) related to the , PMDP130 provides drug / device profile and safety information132 to HCP120 Drug / device profile and safety information can be sent to Method of administration, absorption, metabolism, duration of action, toxicity, and interactions with food or other drugs This may include information about drug characteristics such as drug / device profile and safety. Upon receiving the information 132, the HCP may prescribe the medication and / or medical device. or modify the prescription based on the drug / device profile and safety information132 Interactions between the HCP 120, the payer 140, and the PMDP 130 can be The study demonstrated that HCP120 is (a) tolerable to patients and (b) safe and effective. (c) be payable and / or approved by payer 140; This may continue until final approval of the treatment plan.

[0014] Therefore, conventional healthcare information systems have several drawbacks. The Company obtains and maintains information that may be relevant to the operation of its business. Very little of the information is shared (e.g., for legal, privacy, and / or business reasons) If information is shared, it may be fragmented. For example, HCP120 is a drug that is used to treat adverse drug effects. As another example, adverse drug effect information may not be provided to the HC If provided by P120 to PMDP130, that information is non-PII demographic information (e.g., patient age, location, medical condition, etc.), and as a result, that information is MDP130 may be of limited value. In addition, in some cases, adverse drug effects may occur. If an adverse drug effect is reported by an entity (e.g., a patient), the adverse drug effect may be reported by another entity. The adverse events are verified by a clinical entity (e.g., HCP120) and are associated with a given drug. Verification may require additional entities. , which may introduce additional complexity that may further delay reporting and / or create additional storage; This may further limit the usefulness of that information (e.g., to PMDP 130). .

[0015] In addition, information may be compartmentalized and provided on an ad-hoc basis, Aggregating the received information with information stored by the receiving entity is , can be cumbersome. Furthermore, each entity may index its information differently. Therefore, the receiving entity (or the sending entity) must be able to information generated by the transmitted information record (e.g., by the transmitting entity) For example, it may be difficult or impossible to link HCP120 to If adverse drug effect information is provided to PMDP130 at any time, that information may be legally shared. Even if HCP120 and / or PMDP130 can be administered, it is possible that they may have adverse drug effects. Obtaining additional patient or patient condition information relevant to the results can be difficult. Compartmentalization of information prevents or limits access by PMDP130 to regulate drug use. As another example, various The costs of treatment alternatives are often not readily apparent to the patient or HC at the time a prescription or treatment plan is being developed. For further examples, the HCP 120 and / or It can be difficult for a payer 140 to determine whether a patient is misusing prescription drugs.

[0016] Many modern machine learning (ML) and other artificial intelligence (AI) AI systems process large amounts of data to assess risk and deliver desired outcomes. Patterns can be identified from which efficient This can result in increased efficiency, lower costs, and / or better outcomes. Storage and compartmentalization also limit the applicability of such ML and AI techniques, thereby It comes down to inefficiency.

[0017] Several efforts to introduce efficiency into healthcare delivery have been undertaken using outcome-based approaches. Payers140 are expected to pay for the achievement of a number of agreed-upon outcomes. For example, outcome-based contracts can be used to link reimbursement to HCP12. 0 relates to a rate based on reducing a patient's blood pressure to a specified range within a certain period of time. Such performance-based payments may specify that the contract may be redeemed at an agreed rate. Tracking and managing the contracts of a service allows several exchanges of information to take place, each of which is legally binding. ,Following regulatory, privacy and business-related guidelines, HCP1 20 and the payer 140. As is known in the sense, it can be difficult.

[0018] Figure 1B shows a traditional implementation of a contract associated with a traditional blockchain system. As shown in FIG. 1B, the program code includes an entity A 163 and an entity B 164. A contract 156 can be implemented between the entity B 165 and the contract 156. In this example, information may be exchanged separately between entity A 163 and entity B 165. (e.g., as outlined above in connection with FIG. 1A), that information is then stored in a contract 156 to implement that contract. This conventional implementation suffers from several drawbacks. In the present embodiment, this program code associated with the contract 156 is entity (e.g., entity A163) and therefore can be linked to other entities. other related contracts using the It cannot be used to implement the

[0019] Furthermore, in conventional systems, the program code associated with a contract is It is specific to the two entities associated with the contract. If another entity, such as a Entity C 167, can be associated with the Contract 156, In the previous system, (a) Addendum 1 152 (Entity A 163 and Entity C 16 7) and (b) Addendum 2 154 (to reflect the interaction between to reflect the interaction between entity B 165 and entity D 169), Additional code associated with the entity C167 is typically added to encompass the entity C167. Therefore, as the number of entities associated with a contract increases, the system This dramatically increases the complexity of the system, which in turn increases contract management costs (coding costs, This increases the risk of errors (maintenance costs, etc.) and also increases the likelihood of errors. Furthermore, the information is transferred between entities, making contract changes difficult or impractical. Because it is shared externally, the potential for errors and / or data inconsistencies is significantly higher In addition, a contract may require multiple instances of an entity (e.g., associated with an HCP). Many of the traditional drugs used in In a system, contracts may be duplicated across their instances. Therefore, changes to the contract (e.g., the introduction of a new drug to treat a medical condition) (indicating approval) can be difficult and take a long time to propagate through the system. This may require additional time and effort, thereby limiting the usefulness of the platform. In situations where manual approval or intervention is often the norm, Disable the benefits of the contact management platform. Block it from storing health-related information. The use of chains ensures the integrity and authenticity of stored information. On the other hand, conventional technologies have difficulty dealing with the problems and complexities of information compartmentalization. Inconsistent or different entities may not be able to maintain consistent consistency of the stored transactions. It does not guarantee reliable browsing and facilitates interoperability.

[0020] The disclosed embodiments promote the integrity and interoperability of healthcare systems while: Facilitates security in healthcare systems. Some of the disclosed techniques To an entity (e.g., an authorized entity associated with a transaction) appropriate data (e.g., in accordance with legal, privacy, and business guidelines) Facilitate the timely exchange (e.g., at the point of transaction) of information (e.g., information that may be shared between users) and Facilitate a consistent and coherent view of information across all care market entities. Interoperability is when multiple entities involved in a transaction communicate with each other based on standards. Use agreements to tie information shared during a transaction back to the transaction This is facilitated in part because it may be possible to use locally recorded data as a reference data. It can respond to data and provide a view of each entity in the reference data (or by entity). the portion of the baseline data viewable by the user is consistent with another authorized entity's view of the data. In some embodiments, the reference data is It can be based on and / or take the form of a distributed ledger. In embodiments, the distributed ledger may be accessible to authorized entities, and Viewing each entity in the ledger is subject to legal, privacy, business, and / or contractual obligations. This can be based on the following.

[0021] In some embodiments, a first event is generated in response to a transaction at a first time. a healthcare provider to one or more second entities (e.g., healthcare providers) and / or the patient) regarding the transaction. Each encrypted block of information can be received. may be received from a separate second entity and resolved by the first entity. The first entity ( The recipient (e.g., a pharmaceutical provider) decrypts one or more of the received decryptable sub-blocks. In some embodiments, the first entity may use multidimensional blocks. This multi-dimensional block can be further expanded by At least one of the encrypted information blocks received from the second entity The blockchain is maintained by a first entity, and By linking to the current block being added to the blockchain associated with Thus, a first entity (e.g., a pharmaceutical provider) can at least one second entity (e.g., a healthcare provider and / or insurance provider) It allows for access to the multidimensional blockchain by individuals (and / or patients) Cut.

[0022] The sub-blocks that can be decrypted by the first entity (the received encrypted block) (within the context of the 'Digital Signature') is authorized by a first entity (e.g., for legal, privacy, and / or business reasons) may contain or point to information that may be viewed (in accordance with the Nest guidelines). Conversely, information outside the decipherable sub-blocks is stored in the first entity (e.g., a pharmaceutical company). The data may be inaccessible to some users (e.g., product providers), but is sent to the corresponding encrypted block. The information may be made available to a second entity (e.g., a healthcare provider). Furthermore, each encrypted block received by the first entity is: (i) a transaction and / or (ii) transmitting the corresponding encrypted block. a corresponding blog maintained by a trusted second entity (e.g., a healthcare provider) In some embodiments, the first entity may form part of a lock chain. The current block being added to the blockchain maintained by the , sub-blocks, each of which may include a corresponding second entity At the same time, the information outside the corresponding sub-block is decipherable by the second The term subblock refers to a block that is not visible to certain entities. A data record that is decipherable by an entity or by some specific entity. It refers to a part of a code or block, and is therefore transactionally consistent. Viewing may be subject to compliance with legal, privacy, and / or other regulations and business considerations. available to market entities while maintaining data integrity and promoting data integrity. .

[0023] The term "blockchain" as used herein means that the blocks are cryptographically linked. A growable list of records or "information blocks" or "blocks" that are linked using Each block contains a cryptographic hash of the previous block, a timestamp, and a The current block being added to the blockchain also contains the transaction data. Also known as the head of the blockchain, a cryptographic hash function is used to split data of any size. , into a fixed-size string of bits called a "hash." A hash function is It can be deterministic (the same input will produce the same output) or invertible (all A one-way function where it is impossible to determine the original data from the hash value. The transaction data of a block is the Merkle tree root hash and The terms "Merkle tree" or "hash tree" are used to refer to trees. Every leaf node is labeled with a hash of the transaction data. Each non-leaf node is then computed using a cryptographic hash of the label associated with its child nodes. The block header of a block added to the blockchain is labeled with the Merkle hashing criteria for block headers and transaction data It can contain a hash reference to the root of the tree. The data is deleted because a change to the data in the chain results in a mismatch in one or more of the hash criteria. The terms record or data record also refer to the blockchain. It is also used to indicate non-final data that is to be added to the data record. Once finalized and approved, the data record can be added to the blockchain. Blocks within the blockchain can be formed.

[0024] The term "multidimensional blockchain" refers to a set of multidimensional records (also known as multidimensional blocks). is used to refer to a multidimensional record (also called a multidimensional table), where each multidimensional record is a set of two or more Contains data records, potentially forming the dimensions of a multi-dimensional blockchain. Each data record is stored in a separate blockchain associated with an entity. Thus, in some embodiments, a multidimensional block can be formed. can contain data records within each dimension, in which case the data records corresponding to the dimension The code is stored in a separate traditional blockchain associated with the corresponding entity. For example, a multidimensional block can represent EHR data records in a primary As a source, DIR data records as another dimension and transaction data records as A third dimension can be included.

[0025] Furthermore, in some cases, it may be associated with a multi-dimensional block (within a multi-dimensional blockchain). The collected EHR data records will be stored in a separate EHR blockchain (i.e., a multidimensional blockchain). Blocks can be created separately within a blockchain (separate from the blockchain). Therefore, the DIR data records and transaction data associated with the multidimensional block Each data record is stored in a separate DIR blockchain (e.g., PMDP1) 30), and transaction records blockchain (e.g., A block can be formed in the payer 140 associated with the payer 140. Depending on the context, data records in a multidimensional blockchain may be separate traditional blockchains. It can correspond to blocks in a blockchain, and in some cases, multi-dimensional blocks. Each data record in (e.g., associated with a dimension) is stored in a separate conventional blockchain. corresponding to, forming part of, and / or derived from corresponding blocks in the A multi-dimensional block contains the previous multi-dimensional block, a timestamp, and a cryptographic handwriting of the data. The data in a multidimensional block can contain the individual blocks that make up the multidimensional block. In some embodiments, the entity may include a hash of each data record. Using a consensus mechanism between the parties, the validity of the data in the proposed multidimensional block is verified. The multi-dimensional block can be verified before being constrained and locked.

[0026] Thus, a multidimensional block may contain more than one encrypted data record. In that case, each encrypted data record is stored in a separate entity (e.g., As outlined above, data in multidimensional blocks can be related to Records can form separate blocks in separate blockchains, where In this case, each of the blockchains may be associated with a separate entity. The data records are then associated with the corresponding associated entities (e.g., data record owners). Furthermore, the encrypted data record can be decrypted by In addition to the data record owner, it is readable by at least one other specific entity. It may contain portions (called "sub-blocks") that can (or may be) functional For example, this sub-block can be , by at least one other distinct entity (in addition to the data record owner) In some embodiments, at the time of multidimensional block formation, , the sub-blocks may be encrypted separately and stored separately, along with information to decrypt the sub-blocks. Therefore, the multidimensional block can be made available to authorized entities. Provide a consistent and coherent view of data to selected market entities, supporting regulatory, business Comply with regulatory guidelines and / or contractual obligations and promote data integrity while Availability of transaction data for multiple entities associated with the marketplace Entities can also use locally maintained blockchains to facilitate Data correlation with corresponding blocks in a chain (e.g., multi-dimensional blocks in a multi-dimensional blockchain) It is also possible to guarantee the number of records associated with the dimensions of the original block. In an embodiment, when information is exchanged between two entities using sub-blocks, The information exchanged through the decipherable subblocks is the information interface between the two entities. In some embodiments, when exchanging information ( For example, at the time of multidimensional block formation), each entity is Local blocks maintained by the entity while generating subblocks that are decryptable. Blocks associated with a blockchain can be encrypted. The interface can be based on smart contracts tied to the blockchain. Cut.

[0027] The term "smart contract" refers to a contract that is executed on a blockchain or blockchain platform. It is used to refer to the program code or logic associated with a platform. This "smart contract" allows data sharing, transactions, access, and contracts. It can encode rules or agreements between two or more entities relating to project performance, etc. Smart contracts are related to multi-dimensional blockchain platforms. It can be based on a contract between two or more entities and / or agreements. For example, a "smart contract" program code associated with a multi-dimensional blockchain. The code processes the transaction request and executes the transaction based on the program logic. The effectiveness of the action can be determined.

[0028] Figure 2 illustrates an EHR 200 illustrating some exemplary data fields within a record. In some embodiments, the EHR 200 may include information about the patient. The fields shown in the EHR 200 are merely examples and the EHR 200 is subject to legal It may contain various other additional fields based on standards, HCPs, and / or industry practices. The EHR may contain fields other than those shown in relation to the exemplary EHR 200 ( It can contain different fields (more or less).

[0029] For example, as shown in FIG. 2, the EHR 200 stores basic profile information about the patient. 30, which may change relatively infrequently. Basic Profile Information 23 0 includes family history 205, date of birth (DOB) 220, blood type 225, etc. Family history205 may include maternal medical history210 and paternal medical history215. In some embodiments, the EHR 200 may, based on information from the patient, It can be created and / or maintained by 0.

[0030] The EHR 200 includes a diagnosis 235 (e.g., current illness), a standardized diagnostic code for the diagnosis, Code (International Classification of Diseases (ICD) code, etc.) diagnostic code 240, which may be a standardized diagnostic code to describe the treatment (e.g., Current Procedural Terminology (CPT) codes and other possible treatments Other data fields such as treatment code 245, prescription code 250 for any prescription, etc. The prescription code 250 may further include a drug 255 (e.g., drug name), a dose 26 0 (strength and frequency), and duration 265 (length of time the drug can be taken). In some cases, the EHR 200 may also indicate whether the prescription is a new prescription or It may also contain other fields and / or subfields, such as an indication of whether it is a supplement. can.

[0031] In some embodiments, the EHR 200 for a patient may be configured, for example, by the HCP 120. This can be stored as a blockchain, and each transaction between the HCP120 and the patient can be Transactions may form part of an EHR information block within an EHR blockchain. In the following discussion, when EHR is maintained as a blockchain, EHR information The record 200 can also be referred to as an EHR block 200. Block 200 can form a block within the EHR blockchain. If R-Block 200 can be added to the EHR blockchain, Some data in the EHR block 200 that is added to the application depends on other entities. For example, diagnostic treatment codes 245 may be provided by payer 140 (not shown in FIG. 2). As another example, the EHR block 200 may require approval and / or verification from the EHR. Drug warning labels (not shown in Figure 2) that may form part of the EHR block 200 is added to the EHR blockchain, PMDP 130 and / or payer 1 40 may use input and / or approval.

[0032] In some embodiments, a diagnosis 235, a diagnosis code 240, a treatment code 245, Prescription code 250 with data fields drug 255, dose 260, and duration 265 and can be used to form sub-block 280. Sub-block 280 can be These are merely examples illustrating some of the information that may be shared with another specific entity. and then store the data in a locally maintained blockchain (e.g., EHR blockchain). The information used to form subblocks from data records or blocks is health care and / or privacy), stipulate information sharing (e.g., entity laws, business guidelines (which determine what information may or may not be shared by the company) trade secrets or confidential information), and / or contractual obligations (e.g., entity sharing In some embodiments, the information may depend on the entity. The data in sub-block 280 is sent by an entity such as HCP 120 to Payer 1 40 with another healthcare market entity to complete the transaction. However, the patient profile associated with the basic profile information 230 File information may be considered private (e.g., for legal, privacy, and / or based on business guidelines), the first entity (e.g., HCP1 20) may not want to share their basic profile information 230 or may not want to share their basic profile information 230. It may be desirable to limit the portion of basic profile information 230 that is included.

[0033] Thus, in some embodiments, the ion exchange layer 240 may be used to form sub-blocks 280. The data may be encrypted separately. The encryption of the resulting data may be based on any suitable encryption scheme, including , Advanced Encryption Standard (AES)-based technology or its variants Symmetric key encryption techniques such as reconciliation (in which case, the HCP 120 and the payer 140, etc. Sub-block 280 contains the other entities (entities share a secret key). The encrypted data may be encrypted (e.g., by the HCP 120) before being shared with the entity (e.g., the payer 140). The other entity (e.g., the payer 140) can encrypt the shared key, for example. It may be possible to decrypt sub-block 280 using

[0034] Additionally, data within the EHR 200 may also be encrypted using any secure encryption technique. 20 to form EHR block 200. For example, data within the EHR block 200 may be encrypted separately using different keys. so that it is decipherable and usable by the HCP120, but It cannot be viewed by other entities. Therefore, the first entity (e.g., HCP120) can add encrypted data to the EHR blockchain. The EHR block 200 may be encrypted before being shared, so that (i) portions of the information is encrypted separately (e.g., in sub-block 280) and transmitted to another entity (e.g., , payer 140), and (ii) information outside of sub-block 280 , cannot be decrypted or accessed by any other entity, and Therefore, in some embodiments, the EHR data record From the code, the data elements that can be formed include: (a) information in field diagnostics 235, diagnostic codes; Code 240, Treatment Code 245, Prescription Code 250, Drug 255, Dose 260, and Encrypted substrings containing durations 265 that may be decryptable by a specific entity block 280 (e.g., at the time of multidimensional block formation), and (b) EHR records All information in sub-block 280 (as well as the EHR information present in sub-block 2 80 (including EHR information from outside the EHR) and HCP120 (EHR owner) Encryption that is decryptable by a The EHR block 200 may include:

[0035] Thus, in some embodiments, the other entity (e.g., the payer 140) , it may be possible to decrypt the information in sub-block 280, but the EHR block 20 It would be impossible to decrypt the encrypted information associated with 0. In an embodiment, an encrypted EHR block from a first entity (e.g., HCP 120) is The block 200 may contain information that can be used to form multiple sub-blocks. In this case, each sub-block (e.g., sub-block 280) may be a separate second entity. The signature may be decipherable by the entity (e.g., payer 140).

[0036] Figure 3 shows a typical Drug Information Record (DIR). In some embodiments, the DIR 300 may include information about the drug. The fields shown in R300 are merely illustrative; DIR300 is based on legal, standard Various other field bases may be included based on standards, industry practices, etc. , DIR may be (more or less) different from the fields shown in relation to the exemplary DIR 300. ) can contain different fields.

[0037] The DIR 300 may contain various data fields, including a formulary 305, The formulary contains approved prescription drugs associated with a drug class (e.g., generic drug names and brands). For example, the patient's payer (e.g., payer 140) may be listed as a payer for the medication included in the formulary. may cover the cost of medications and / or require the use of medications included in the formulary. DIR3 00 can also contain various other data fields, including price 325, The field may list the price (list price or negotiated price) at which the drug is available. The collection 305 includes information about the payer in payer-i fields 310-i, (1≦i ≦n). Each of the listed tier-j fields 310-j, (1≦j≦m ) can contain information about the corresponding drug class when repeating the same Examples include various drug categories, such as: For example, the prescription specified in formulary 305 and the payer specified in payer 1 310-1 In this case, the Category 1 315-1 drug may be a cheaper generic drug, whereas Therefore, Category 2 315-2 drugs may be more expensive generic drugs, and Category 3 315 The -3 drug may be a brand name drug. Further, each division-j field 310-j may include: If the prescription is approved for use (e.g., by the Food and Drug Administration, for medical conditions approved by a regulatory authority (such as the DA) and / or payer (e.g., 310-1). s) with information indicating that the do.

[0038] In addition, as shown in Figure 3, DIR300 has efficacy327 (the degree of therapeutic effect on the disease condition). possible), safety (e.g., drug interactions, toxicity, contraindications, etc.), route of administration 335 (e.g., topical, oral, intravenous, etc.), Mechanism of Action (MOA) 340 (Can identify the biochemical interactions by which drugs induce pharmacological effects) 345 (e.g., side effects), etc. do.

[0039] In some embodiments, the DIR300 for the patient comprises an enterotropic drug such as PMDP130. By virtue of its identity, it can be stored as part of the DIR blockchain. In the current case, if the DIR is maintained as a blockchain, the DIR information record 300 is It can also be called the DIR block 300. Therefore, the DIR block 300 is , a block can be formed in the DIR blockchain. DIR block 300 If can be added to the DIR blockchain, then D is added to the DIR blockchain. Some data in the IR information block 300 may be subject to verification by other entities. For example, the payer ID designated as payer 1 310-1 may form part of the DIR block 300. The information in the formulary 305 associated with the selected payer (e.g., payer 140) is stored in the DIR block. 300 to the payer (e.g., payer 140) before it is added to the DIR blockchain. This may rely on verification by

[0040] In some embodiments, the data fee for a transaction at a point in time is Information in the formulary 305, payer 1 310-1, payer 1 310-1 Segment information for each associated segment-j field 310-j, each segment-j field Using the information in each of the instruction-k fields 310-k associated with the sub-block 385. However, if the payer-i field 310-i (2≦ i≦n) because that information may be confidential (e.g. ,between each payer in payer-i, 2≦i≦n, and PMDP130),sub-block 385, and the PMDP 130 may share information related to the payer with other Contractual sharing with payers cannot be expected and / or may be prevented. Sub-block 385 provides examples of some information that may be shared with another specific entity. This is just an example to show how it works. Generally, a locally maintained blockchain (e.g., DI) R300) to form sub-blocks from data records or blocks. The information provided may be subject to regulations (e.g., healthcare and / or privacy), laws governing information sharing, and other legal requirements. rules (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 relating to entities that share information.

[0041] Thus, in some embodiments, the data in sub-blocks 385 are separately encrypted. In some embodiments, encryption of data in sub-blocks 385 may be used. The payer must be identified in the Payer1 310-1 field before it is shared. Any method involving symmetric key encryption based on a secret key shared with the payer (e.g., the payer 140) The other entity (e.g., the payer 140) can , for example, it may be possible to decrypt the sub-block 385 based on a shared key. Cut.

[0042] Additionally, as shown in FIG. 3, another sub-block 380 may be formed from the DIR 300. The sub-block 380 includes information on efficacy 327, safety 330, route of administration 335, and operation. It may contain fields such as mechanism of action (MOA) 340, side effects 345, etc. Block 380 is merely an example of some of the information that may be shared with another specific entity. As outlined above, a locally maintained blockchain (e.g., DI) R300) to form sub-blocks 380 from data records or blocks. The information used may be subject to regulations (e.g., healthcare and / or privacy), information sharing requirements, and other laws (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 relating to entities that share information) The sub-block 380 is shared with another entity (e.g., PMDP 130). It can be encrypted separately using a private key. The secret shared key can be used to decrypt and view the information in sub-block 380 It is possible.

[0043] Additionally, the data in the DIR block 300 may also be encrypted using any secure encryption technique. may be separately encrypted by a first entity (e.g., PMDP 130); As a result, the data is indecipherable to the first entity (e.g., PMDP 130). and available, but not available to other entities (e.g., HCP 120 and / or payer 14 0), it cannot be viewed. Therefore, in some embodiments, From the R data record, the data elements that can be generated include (a) information in the formulary 305, payment Person1 310-1, the division-j field associated with the payer in Payer1 310-1 The segment information for each of the segments 310-j and the instruction-k field associated with each segment-j field. Encrypted sub-blocks 385 (e.g., multi-level blocks) containing information for each of fields 310-k (b) Information on efficacy, safety, and route of administration 35, an encrypted subblock 380 containing the mechanism of action (MOA) 340 and side effects 345 (e.g., at the time of multidimensional block formation), and (c) all All information (including the DIR information also present in sub-blocks 380 and 385, and DIR information from outside of blocks 380 and 385), and PM Decryptable by DP130 (block owner) but not by any other entity The DIR block 300 may contain an encrypted DIR block 300 that is unreadable by any other means.

[0044] Therefore, the encrypted sub-blocks 380 and and 385 may be decipherable by the HCP 120 and the payer 140, respectively. Furthermore, the PMDP 130 determines whether the information in the DIR block 300 is from an entity other than the PMDP 130. The DIR block 300 may be encrypted so that it cannot be viewed by the public. In some embodiments, a first entity (e.g., PMDP 130) The encrypted DIR information block 300 is divided into multiple sub-blocks (e.g., 380 and 385), in which case each sub-block may contain information that can be used to form The payment system may be a separate second entity (e.g., HCP 120 and payer 140, respectively). may be decipherable by

[0045] FIG. 4 illustrates an exemplary Health Transaction Record (HTR) 400. Thus, the HTR 400 may contain treatment-related and cost-related information for a patient at a point in time. The fields shown in HTR400 are merely exemplary and are not intended to be limiting. 00 may contain various other fields based on legislation, standards, industry practices, etc. In addition, the HTR may be (more or less) different from that shown in connection with the exemplary HTR 400. It can contain different fields.

[0046] In some embodiments, the HTR 400 is configured by an entity such as a payer 140. The HTR 400 can store patient 425 (e.g., patient ID), cost 40 This cost can be calculated by adding various data fields, including the transaction The cost 405 can represent the associated cost. for the payer 140), drug costs 415 (e.g., prescribed drug(s) costs), HCP costs (costs by healthcare providers), and patient costs425 Patient costs 425 may include patient co-payments 430, out-of-pocket limits 435, and and deductible 440, which may depend on the patient's health insurance coverage. , and may depend on the patient's previous transactions.

[0047] In some embodiments, the HTR 400 provides a diagnosis 445 (of a patient's condition), Code 450 (e.g., for a current medical condition), treatment code 455 (e.g., for a CPT code), or another standardized code to describe the treatment), standardized to identify a given drug Repeated fields may be codes drug codes 460-1, 460-2,... and procedure code 465 to describe medical procedures associated with the treatment of a medical condition. It may also include various other fields.

[0048] In some embodiments, a patient's HTR 400 at a given time may be provided to an entity such as a payer 140. In the following explanation, H If the TR is maintained as a blockchain, the HTR information record 400 also It can also be called the R block 400. Therefore, the HTR block 400 is Blocks can be formed in the blockchain, for example, between HCP120 and the patient. Data relating to transactions between the payer 140 and / or between the patient and the payer 140 may be stored in the HT It can form part of an HTR block 400 within the R blockchain. If Rock400 can be added to the HTR blockchain, Some data in the added HTR block 400 may be verified by other entities. For example, the information in the diagnosis 445 may be dependent on whether the HTR block 400 is an HTR. It can be verified by HCP120 before being added to the blockchain.

[0049] In some embodiments, the data fee for a transaction at a point in time is Field Diagnosis 445, Diagnosis Code 450, Treatment Code 455, and Repeat Field Drug Code The information in codes 460-1, 460-2, etc. may form part of sub-block 485. Subblock 485 is shared with PMDP 130 to allow drug-described diagnoses. and whether the product is approved for use and safety (e.g., drug interactions) It can be determined.

[0050] In some embodiments, the information in the fields Patient ID 425 and Co-Payment 430 The information can be used to form another sub-block 480. Determining co-payment information for a transaction that can be shared with the HCP 120 Sub-blocks 480 and 485 can be used to enable specific entities. These are merely examples to illustrate the information that may be shared by the payer 140. , data records or blocks (e.g., The information used to form sub-blocks from the HTR400 is based on regulatory (e.g. information sharing (e.g., by an entity) laws, business guidelines (e.g., which determine what information can or cannot be shared) trade secrets or confidential information), and / or contractual obligations (e.g., entity-shared information) The information may depend on the entity (or entities related to the information shared).

[0051] Thus, in some embodiments, the data in sub-blocks 480 and 485 are In some embodiments, the data in the sub-blocks 485 can be encrypted separately. The encryption of the data is performed using symmetric key cryptography, based on a secret key that is shared with the PMDP130 before it is shared. The PMDP 130 may be based on any suitable encryption technique, including PMDP encryption. Decrypts the sub-block 485 based on a secret key shared between the sender 130 and the payer 140. In addition, sub-block 480 may be shared with HCP 120. They can be encrypted separately based on different secret keys. 0 and the payer 140 to encrypt the information in sub-block 480 using a secret key shared between Furthermore, the data in the HTR information block 400 may be Also, any secure encryption technique may be used to encrypt the first entity (e.g., payer 140 ), so that the data is encrypted by the payer 140. readable and usable by the HCP120 and / or PMDP130 It is not possible.

[0052] Thus, in some embodiments, data that can be formed from the HTR data record. The data element includes (a) an encrypted data element containing information in fields Patient ID 425 and Co-Payment 430; (b) a filtered sub-block 480 (e.g., at the time of multidimensional block formation); Field diagnosis 445, diagnosis code 450, treatment code 455, and repeat field medication Encrypted sub-blocks 485 (e.g., (e.g., at the time of multidimensional block formation), and (c) all of the data in the HTR record 400. All information (including HTR information also present in sub-blocks 480 and 485, and HTR information from outside the locks 480 and 485), and TR block owner), but not by any other entity. It may contain an encrypted HTR block 400 that is unreadable. In some embodiments, an encrypted payment from a first entity (e.g., payer 140) The HTR information block 400 is formed into several sub-blocks (e.g., 480 and 485). In this case, each sub-block may contain information that can be used to: Decoded by a separate second entity (HCP120 and PMDP130, respectively) It may be possible.

[0053] FIG. 5A illustrates an exemplary HTR information block 540, which includes sub-blocks 480 and 485. The EHR information block 540 is maintained by a first entity, such as a payer 140. In some embodiments, the blockchain may be added to the EHR blockchain 545 maintained by the EHR. The block 540 may be encrypted by the payer 140 so that the block 140 (but not by other entities) is not possible).

[0054] In some embodiments, the sub-block 480 within the EHR information block 540 is It uses symmetric key cryptography based on a secret shared key with another entity, such as a P120. The HCP 120 can then use the shared key to encrypt the transaction. Block 480 can be decrypted. However, blocks outside of sub-block 480 The information in the lock 540 cannot be deciphered by the HCP 120 .

[0055] Furthermore, sub-block 485 within HTR information block 540 may contain additional information such as PMDP 130. and to the payer 140 using symmetric key cryptography based on a secret shared key with the payer. The PMDP 130 uses the shared key to encrypt sub-block 4. However, block 54 outside sub-block 485 can be decrypted. The information in the 0 cannot be deciphered by the PMDP 130.

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

[0057] As shown in FIG. 5B, the HTR blockchain 545 maintained by the payer 140 The current information block 540 added to the As outlined above, sub-blocks can contain information that can be used to 480 may be decipherable by the HCP 120, whereas sub-block 485 may be decipherable by the PMDP 130. Also, as outlined above, 540 can be separately encrypted by the payer 140 and encrypted by an entity other than the payer 140. Business activities (e.g., to comply with legal, privacy, contractual and / or business guidelines) It may be impossible to decipher depending on the

[0058] As shown in FIG. 5B, an exemplary EHR information block 520 is formed of sub-blocks 280. The EHR information block 520 can contain information that can be used to create an EHR. can be added to the EHR blockchain 525 maintained by the HCP 120. In some embodiments, the sub-block 280 in the EHR information block 540 can be: using symmetric key cryptography based on a secret shared key with the first entity payer 140; The payer 140 may then encrypt the shared The key can be used to decrypt sub-block 280. As outlined above, HC P120 also decrypts sub-block 480 using a private key shared with payer 140. Additionally, the information in block 520 is encrypted separately by HCP 120. The information may be encrypted and may be shared with entities other than the HCP 120 (e.g., legal, public (to comply with privacy, contracts and / or business guidelines) It may be possible.

[0059] Further, as shown in FIG. 5B, the exemplary DIR information block 530 includes sub-blocks 38 5. The DIR information block 530 may be a separate second It can be added to the DIR blockchain 535 maintained by the entity In some embodiments, sub-block 385 within DIR information block 530 is by the PMDP 130 using symmetric key cryptography based on a secret shared key with the person 140. The payer 140 can then use the shared key to encrypt the sub-block 385. The PMDP 130 can also decrypt the payer 140 using a private key shared with the payer 140. can also be used to decrypt sub-block 485. Furthermore, the information in block 530 is , may be separately encrypted by the PMDP 130, and the information may be encrypted by an encoder other than the PMDP 130. Business activities (e.g., to comply with legal, privacy, contractual and / or business guidelines) It may be impossible to decipher depending on the

[0060] In FIG. 5B, the information interface 524 between the payer 140 and the HCP 120 is , can contain information shared using sub-blocks 460 and 280. Thus, the information interface between the two entities (HCP 120 and payer 140) The information in (e.g., information interface 524) is used by the HCP 120 and the payer 140. Similarly, the first entity payer 140 and the second entity payer 141 can decrypt the The information interface 534 between the entity PMDP 130 and the sub-block 38 5 and 485, and information interface 534 The information within can be deciphered by both the PMDP 130 and the payer 140.

[0061] FIG. 6A illustrates a transaction flow 600 associated with a multidimensional block. 6A is merely illustrative and is not associated with block 540 for ease of explanation. Some steps between two entities in a given transaction flow are The additional steps to obtain multidimensional blocks follow a similar pattern. In FIG. 6A, the sub-blocks shown and the fields described are shared. These are merely examples to illustrate the process flows and information that may be provided. Data records or blocks to sub-blocks are stored in a locally maintained blockchain. The information used to form the database may be subject to regulatory (e.g., healthcare and / or privacy) requirements. laws governing information sharing (e.g., what an entity can or cannot share); business guidelines (e.g., trade secrets or confidential information) and / or contractual obligations (e.g., between or to entities that share information). Once a data record is verified and completed, the completed data Records can be added to the local blockchain as blocks.

[0062] FIG. 6A shows the HTR blockchain 545, which is a first party, such as the payer 140. In FIG. 6A, data record 540 can be maintained by , can be added to the blockchain 545. FIG. 6A also shows the The head currently has an EHR blockchain 525 with records 520, and The head of the chain also shows the DIR blockchain 535, which currently contains record 530. In some embodiments, the blockchains 525 and 535 each include a second The entities HCP 120 and PMDP 130 may be maintained (see FIG. 6A). (Not shown). In some embodiments, at the time a transaction request is submitted: The latest block from each blockchain is submitted to form a multi-dimensional blockchain It is possible.

[0063] In some embodiments, the information may include information from another entity and / or may be The corresponding entities that contain the properties (e.g., HCP120, PMDP1, respectively) 30, or one of the payers 140) in a traditional blockchain (e.g., An update on the check chain (one of 525, 535, or 545) indicates that the update is bound. before being used (e.g., blockchain 525, 535, or 545, and / or related (locally in an attached multidimensional blockchain) to one or more other entities In some embodiments, the information blocks 520, 530, and / or each field associated with 540 has a separate global field id The id is used to store the field-related information shared between entities. If so, the field can be integrated into the multi-dimensional blockchain system and / or appropriate entity. The entity can be uniquely identified.

[0064] In some embodiments, the transaction request is a record, such as record 540. When a code can be added to a blockchain maintained by an entity, by the entity (e.g., by the payer 140) to the appropriate entity (e.g., HCP 120 and / or PMDP 130. In some embodiments, Transaction requests can be placed in a request pool. In the form, various entities, such as HCP 120, PMDP 130, payer 140, etc., authorize It can form part of a permissioned blockchain platform. In a blockchain platform, trusted entities form the platform, Other trusted entities can be invited to join the network. In embodiments, the permissioned blockchain platform also provides private In some embodiments, the permissioned blockchain platform may: It can support multi-dimensional blockchains. rules relating to the addition of processes and blocks, contracts between entities (e.g., The program code for determining the mart contract, update verification, etc. are handled by permissioned block. It can be determined by the entities associated with the blockchain platform. Cut.

[0065] If the payer 140 is authorized to access and update the platform, several In some embodiments, if a data record 540 can be added, the payer 140 may The block 480 can be branched and encrypted, and its sub-blocks can be optionally It can contain information from parts of data record 540. Then, sub-block 48 The information in the .0 can be decoded and read by the HCP 120. In one embodiment, a symmetric encryption algorithm may be used to encrypt the sub-blocks 480. Cut.

[0066] As outlined above, the following discussion will focus on two data records for ease of explanation. The nodes 520 and 540 are initially registered as being from the blockchains 525 and 545. As shown in FIG. 6A, a branch operation 605 determines whether a data record 540 can be branched to form branched sub-blocks 480. In this example, the branching operation 605 serves as a trigger that initiates the formation of a multidimensional block. A subblock fork operation can be used to split data records or may replicate and encrypt some subset of data in a block (e.g., to another entity) using a secret key shared with the entity) and sub-blocks (e.g., sub-block 480 In some embodiments, this sub-block can be formed in memory as For example, a sub-block can be replicated within a multi-dimensional block (e.g., The memory may reside in a memory used to form the block 610. Sub-block replication facilitates speed, storage, and complete deletion of replicated objects. (e.g., when multidimensional block formation is complete). The information associated with the block (e.g., local block 540) is used to determine the branching behavior (e.g., It is not affected by the branch operation 605).

[0067] For example, branch 605 results in subblock 480 being duplicated and block 4 The encryption key can be shared with the HCP 120. This may take the form of an authorization code and / or may be transmitted over a secure channel to the first entity. Authorization sent from the entity (Payer 140) to the second entity (HCP 120) The HCP 120 may include the authorization received from the payer 140 as part of the code. The code can be used to decrypt the sub-block 480. In this case, the sub-block 480 may be replicated in memory. Cloud replication can facilitate speed, storage, and complete deletion of replicated objects. (e.g., when multidimensional block formation is complete).

[0068] Additionally, as shown in FIG. 6A, branch operation 607 also determines whether data record 520 is HCP1 20, the data record 520 is branched and the branched sub-block In some embodiments, branching operation 607 can also form a branch 280. As a result, the sub-block 280 is duplicated and split from the data record 520 into a separate block. The encryption key can be shared with the payer 140 to 140。 The form of an authorization code transmitted from the HCP 120 to the payer 140 over the network. and / or may be included as part of the authorization code. Using the authorization code received from CP 120, sub-block 280 can be decrypted. Cut.

[0069] In some embodiments, after verification, the information in sub-blocks 280 and 480 is An information interface is formed between the records 520 and 540, and the records 520 and / or or 540 (e.g., by incorporating appropriate (by storing and / or updating in a suitable field). As an example, the HCP120 , decrypting and reading subblock 480, the co-payment 230 and patient ID 425 Similarly, the payer 140 can decrypt and read the sub-block 480. By entering the information, you can obtain the diagnosis code 240, treatment code 245, prescription code, etc. However, information outside of sub-block 280 in block 520 is 20. Similarly, sub-blocks within block 540 Information outside of 480 may remain private to the payer 140. As explained above, information interfaces between entities are subject to laws (e.g., privacy laws). , data sharing, healthcare, sales, competition), contractual obligations between entities (e.g., input by the public), and / or left to business considerations (e.g., trade secrets, etc.) Therefore, the above examples are merely illustrative and may be used for data records, blocks, The actual data shared and / or contained within the blocks and sub-blocks is may be different from

[0070] In some embodiments, the information in sub-blocks 480 and / or 280 may be verified. After successful verification, the updated data record 520 and the updated data record 5 40 can be linked to obtain an unlocked multidimensional block 610. In some embodiments, the updated records 520 and 540 and the multidimensional block 610 is currently in an unlocked form (not yet tied to any blockchain) The term "unlocked" refers to the multidimensional block The information in 610 is not yet final and is subject to change as the transaction moves toward completion. For example, sub-blocks 480 and / or If the information in 280 is determined to be inaccurate or invalid (as further outlined below), In some embodiments, the updated record The blocks 520 and / or 540 may be rehashed after linking. The data (unlocked or locked) can include data and a timestamp. The timestamp may include data records 520, 530, and / or 540. ,determines the order in which multidimensional blocks (when verified and completed) are linked.

[0071] In some embodiments, the HCP 120 and / or the payer 140, and / or the brand Other authorized entities associated with the blockchain can then access the decrypted sub-blocks. The information in the block corresponds to the information associated with blocks 520 and / or 540, respectively. The consensus technology is a method to determine whether a transaction that constitutes a multidimensional block is valid. In some embodiments, the correctness of the Byzantine fault tolerance is Byzantine Fault Tolerance (BFT), or its variants such as redundant BFT. Multidimensional block consensus using a consensus technique such as scalar or some other voting-based consensus technique. Determining whether lock 610 can be formed using blocks 520 and 540 Authorized entities (e.g., payers 140) or some specific When a number (e.g., a majority) of entities validate a transaction or block , an agreement is reached.

[0072] Once the transaction is confirmed as correct by consensus technology, it is unlocked. A first instance of a multidimensional block 610 (which is a For example, the patient identified in subblock 480 as patient ID 425 may be a patient ID (e.g., If there is no match (e.g., in subblock 280), the transaction is invalid. In some embodiments, the block add request may be rejected. The platform or each entity may have a denial of service for traceability and debugging purposes. A log of rejected transactions may be maintained. The reason and code associated with the application rejection may be provided.

[0073] In some embodiments, the consensus layer may include consensus technology, Interacts with the integrating layer to ensure the correctness and / or validity of transactions In some embodiments, a corresponding entity (e.g., HCP) 120, PMDP 130, or payer 140) by a traditional blockchain (e.g., Each update on the blockchain (one of 200, 300, or 400) is Validate by the smart contract program code associated with the blockchain This smart contract program code is used for data sharing, authentication, and payment. It can reflect agreements between entities related to the transaction, etc. The ear facilitates interaction between entities without manual intervention. It can be considered an automated tool. In some embodiments, the Smart Contractor The supplier determines whether the rules associated with one or more contracts are met. Each update to the multi-dimensional blockchain, and / or the passage of time and / or other events may trigger a smart contract layer It is possible to start an action by

[0074] Updated records (e.g., updated record 520 and updated record 54 0) is agreed upon by the entities (e.g., HCP 120 and payer 140). In some embodiments, the execution may be based on predefined rules. , the link of the blocks (e.g., updated block 520 and updated block 540) The blockchain is based on smart contract(s) associated with a multi-dimensional blockchain. After linking, the updated block 520 and the updated block The link 540 can be rehashed. As outlined above, this link An entity may share information in a blockchain maintained by another entity with that It can be used to correlate information in the blockchain. These entities may have information about the information in a particular block maintained by that entity. It is possible to determine a linked transaction or multiple transactions. Therefore, two or more entities may contribute to blocks in separate blockchains. One can have a consistent and coherent view of the associated transactions.

[0075] Thus, the disclosed embodiments provide: (a) transaction authentication; (b) transaction verification; (c) protecting the integrity of transactions; (d) maintaining the provenance of transactions; (e) comply with legal, privacy, and business guidelines maintained by the organization; For example, an organization may provide a status of the data received by that organization. It may be possible to determine the source of external data or transactions. Multidimensional blockchain is a real world evidence based on PDP130. Facilitate the use of RWE (Research, Evidence, and Experience) to provide accurate information on efficacy, efficacy, and effectiveness based on actual patient prescriptions. Dosage information can be analyzed and evaluated. For example, the HCP can Use PMDP130 to conduct some demographic information (e.g., age, location (zip code), medical condition, diagnosis, etc.) along with efficacy, medication This RWE information can be used to share efficacy and dosage information. difficult to obtain (due to legal, privacy, and other issues) and At times, information is often obtained in fragments and lacks context, i.e. demographic and Analysis was also difficult due to the lack of data and / or other useful information. In an embodiment, a smart contract layer is used to provide an information interface / data sharing As a result, data shared with participants can be managed on a regular basis, entities, while respecting business-related considerations, including legal and privacy concerns. Ability to comply with regulatory and / or contractual obligations.

[0076] In FIG. 6A, updates to data records corresponding to multiple dimensions of a multidimensional block are shown. However, in some embodiments, the new multidimensional blocks are It may be formed by updates to the original data record, while the actual data associated with other dimensions may be Qualitative information can remain unchanged, for example, associated with medications prescribed to patients. The collected drug-related information is then transferred to the EHR data 520 or the payer transaction record 140. It can be updated in a new multidimensional block without updating (e.g., PMDP130 by).

[0077] As shown in FIG. 6A, the multidimensional block 610 may be an unlocking block, This may be non-final and may still be modified. Include a link between the updated data record 520 and the updated data record 540. Sub-blocks 280 and 480 can store information between records 520 and 540. In some embodiments, the information interface may be The interface may be defined and / or managed by a smart contract layer. For example: Transaction type entities (sub-block 280 and / or sub-block 4 Information shared between individuals (e.g., within a blockchain) is stored in a smart card associated with a multi-dimensional blockchain. These can be specified and verified by program code in the contract layer.

[0078] FIG. 6A illustrates, for example, record 530 (the flow outlined above for multidimensional block 610). Based on the (possibly obeying) method, a multidimensional block 6 is created through a continuous transformation by adding another dimension. 6A shows a further increase of 10. In each iteration, two entities ( The information interface between the two dimensions in a multidimensional block is addressed as follows: For example, in subsequent iterations (e.g., unlocked multidimensional blocks), 510), the payer 140 extracts the sub-block 485 from the data record 540. The PMDP 130 can branch from the data record 530 to the sub-block 385 As outlined above, in some embodiments, the sub-blocks 485, using a key that may be shared with the PMDP 130 (e.g., via an authorization code), Similarly, sub-blocks 385 may be duplicated and encrypted separately (e.g. , authorization code) with a key that may be shared with the payer 140. After verification, blocks 530 and 540 link and rehash the Furthermore, the data in the updated block 540 may have changed, The link from block 520 to the newly updated block 540 may also be updated.

[0079] FIG. 6B illustrates a multi-dimensional blockchain including data records 520, 530, and 540. 6B shows an example Merkle tree 622 associated with 22 is associated with a multidimensional blockchain containing multiple data records, Each data record can be associated with a separate individual blockchain. Tree 625 is merely an example, and other forms may be used as appropriate. In an embodiment, data records 520, 530, and / or 540 are verified and completed. When a blockchain is created, a corresponding separate blockchain (e.g., blockchain 525, 535 and / or 545). When the example Merkle tree 622 and the data in the records 520, 530, and 540 are The data may not be verified and / or final. As shown in Figure 6B , Hash C 631 is generated by using a cryptographic hash function on the data record 520 Cryptographic hash functions are deterministic (given the same input data, is computationally cheap (generates the same output for a given input) and It is preimage-resistant (the input cannot be determined from the output) and difficult), collision-resistant (e.g., producing different outputs for different inputs) Similarly, hash D633, hash E635, and hash F637 are By using an appropriate cryptographic hash function on the data records 530, 540, and D4 In Figure 6B, record D4 is used to obtain some other (e.g., patient) records, but is not directly relevant to the description of Figure 6A. The functions 631, 633, 635, and 639 are the functions of the entity HCP12, respectively. 0, PMDP 130, Payer 140, and D4. Therefore, the HCP 120 can decrypt the data record 520. (However, the entity associated with the PMDP 130, the payer 140, or D4 Conversely, data records 530, 540, and D4 are PMDP 130, support Payer 140 and entities associated with D4 (but not any other entity) (not

[0080] Furthermore, hash A 627 is a combination of hash C 631 and hash D 633 can be obtained by using an appropriate cryptographic hash function on Hash B 629 is suitable for combination with Hash E 635 and Hash F 637 This can be obtained by using a suitable cryptographic hash function. Hash 625 is the cryptographic algorithm appropriate for the combination of Hash A 627 and Hash B 629. It can be obtained by using a hash function. Hash output (520), Hash D 633 (Hash output (530)), Hash E 635 (Hash output (540)), Hash F 637 (Hash output (D4 The data associated with the data records 520, 530, 540, or D4 It can be shared between authorized entities (e.g. For example, by entities forming a multidimensional block). Similarly, hash A 627, Hash B 629 and top hash 625 may also be shared.

[0081] Referring to FIG. 6A, each iteration / step can be followed by an unlocking block. In some embodiments, the information exchange related to the transaction is completed and the transaction is When a transaction is validated by the consensus and / or smart contract layer, Blocks 520, 530, and / or 540 may be rehashed (as appropriate) to update the links. Multidimensional blocks can also be locked, and multidimensional blocks 6 55 (Fig. 6C). Therefore, the entity can be bound as a traditional local block. associated with blockchains (e.g., blockchains 525, 525, and 545) associated with the completed local blocks (e.g., completed blocks 520, 530, and 540). The completeness of the completed multidimensional block (e.g., completed multidimensional block 655 in FIG. 6C) As shown in FIG. 6C, the multidimensional block 655 may contain verified and completed data records 520, 530, and 540, These data records are stored in separate local blockchains,525,5 35, and 545, respectively. In some embodiments, each multidimensional block may correspond to a timestamp. block header with the top hash625, information related to the previous block, It may contain a pointer to the root of the tree 625 and other appropriate information. The criteria are for private permissioned blockchain platforms and / or local (e.g. A uniform resource locator (UNIL) on an entity-specific address or URL).

[0082] FIG. 6C illustrates a system 6 for facilitating healthcare information security and interoperability. 50. In some embodiments, the system 650 may include multiple It can be based on the use of multi-dimensional blockchains, which It can be based on separate blockchains maintained by individual entities within the system. In some embodiments, the system 650 may be a private permissioned blockchain. In some embodiments, the system 650 may include a network platform. This can take the form of a cloud-based system. Applications that can be made available over a network (e.g., the Internet) , services, and / or other resources (including hardware resources). A base system can be based on underlying hardware and software resources. public (e.g., available everywhere for a fee), private private (e.g., limited to organizations), or hybrid (public and private) (using some combination of oriented clouds).

[0083] The exemplary system 650 may include various entities. The entity can be represented by a server (hardware and / or software), These servers may in some cases be cloud-based. For example, HCP12 The PMDP 130, and / or the payer 140 may include a server and / or a virtual It runs on cloud-based platforms, including virtual machines (VMs). This may also be done.

[0084] FIG. 6C illustrates an HTR blockchain 545, in which a first entity, such as a payer 140, Figure 6C also illustrates the nature of blockchain technology. an EHR blockchain 525 with a block 520 at its head, and Also shown is the DIR blockchain 535 with block 530 at its head. In some embodiments, the blockchains 525 and 535 are managed by a second entity, HCP1. 20 and PMDP130, respectively.

[0085] As shown in FIG. 6C, the HCP 120, PMDP 130, and / or payer 140 may The authentication layer 660 can interact with the authentication layer 680. Includes functionality for identifying and managing (adding, registering, and deleting) system entities. In addition, the authentication layer verifies the permissions associated with actions on the multi-dimensional blockchain. Includes functionality to verify (add new blocks, create links, etc.) The authentication layer 660 can interact with the agreement layer 670. The consensus layer determines the order of transactions and creates a set of transactions associated with a block. It may include functionality for validating transactions.

[0086] In some embodiments, the agreement layer 670 may be configured to process transactions that constitute multidimensional blocks. In some embodiments, the validity of the transaction can be verified. (BFT), or variations thereof such as redundant BFT, or some other Using a consensus technique, such as a vote-based consensus technique, a multidimensional block 610 (FIG. 6A) is formed. It can determine whether a designated formal entity, or several A specified number of entities (e.g., a majority) of If you are certifying a transaction or block, you may be liable for the validity and / or consequences associated with that transaction or block. In some embodiments, the agreement layer 670 Interact with and use functionality within the Tract Layer 680 to The validity of an ordered set of related transactions can be verified.

[0087] The smart contract layer 680 implements the logic related to the blockchain. For example, it may include program code associated with a multi-dimensional blockchain. The "smart contract" program code that is generated processes the transaction request. and can determine the validity of a transaction based on program logic. This logic is used to determine the entity for transactions related to the blockchain. For example, the smart contract layer 680 may terminate a transaction (e.g., , HCP120) can be rejected. The smart contract and can operate at verification time before the block is confined. The smart contract layer 680 is an entity associated with a multi-dimensional blockchain. The information interface between entities can be determined and / or verified. The Mart Contract Layer 680 is related to data sharing, transactions, etc. Rules or agreements between these entities can be encoded and these In some embodiments, the corresponding entities may be based on a physical agreement between them. (e.g., HCP 120, PMDP 130, or payer 140) Each on a chain (e.g., one of blockchains 625, 635, or 645) The update also includes a smart contract layer68 associated with the multi-dimensional blockchain. In some embodiments, the block may be validated, completed, and The link is a smart contract(s) associated with a multi-dimensional blockchain. In some embodiments, smart contracts can be executed based on The program code is a time, a request to add a block from one or more entities. and / or contract-related (e.g., identified by a contract ID) ) by one or more events associated with the platform, such as a specific request. It can be started by

[0088] FIG. 6C shows a constrained and locked multidimensional block 655, where the sub-blocks Information from 480, 280, 380, and 385 is sent to the appropriate authorized entity. In addition, multidimensional block 655 is shared with blocks 540, 530, and and / or 520. Multidimensional block 655 may at some point be partially It can provide a holistic view of the transaction because of its multidimensional blocks. The drug (usage, effects, etc.), the patient (symptoms, treatment, effects), and the cost at that time The multidimensional block 655 may include associated real-world physical states. Can contain a link to the previous block in the blockchain. Multidimensional block 655 contains the completed data records 520, 530, and 540. The data record can be stored in the completed information blocks 520, 530, and 540. Each may correspond to a separate local blockchain 525, 535, and 545. Each can be accommodated.

[0089] FIG. 6D illustrates a multi-dimensional block diagram that may be associated with an exemplary automated outcome-based contract execution. In some embodiments, the smart contract layer is a multi-level Based on the original blockchain, it can facilitate automated outcome-based contract execution. Cut.

[0090] As shown in FIG. 6D, a three-dimensional (3D) blockchain 690 is a series of 3D blocks where each 3D block contains an EHR data record, a DIR data The data record DIRp692 includes a data record DIRp692 and a data record HTR. which may form part of a multidimensional block and which relates to a particular drug (e.g., drug p). For example, in FIG. 6D, the multidimensional block containing the record DIRp 692 A criterion is (a) that at a certain point in time, a patient is initially diagnosed with some particular condition. and (b) when a healthcare provider initiates treatment with a specific drug. It can represent multidimensional blocks of data, e.g., treatment start date, diagnosis code, drug filter, etc. Fields may be shared between entities and may be part of a multidimensional block containing the record DIRp 692. As outlined above, data shared between entities can be identified. Data is used in accordance with legal (e.g., privacy, data sharing, healthcare, sales, competition), entity contractual obligations between entities (e.g., entered into by the entities), and / or business considerations Considerations (e.g., trade secrets, etc.) may apply. Therefore, the examples discussed herein are merely exemplary and are shared within data records, blocks, and sub-blocks. , and / or the actual data included may differ from those examples.

[0091] A single drug (e.g., drug p) can treat many patients, so EHRq Many EHR blocks, including 3D blocks such as block 694, are aligned along the EHR axis. A multidimensional blockchain can be formed that is associated with drug p. A drug (e.g., drug p) may be associated with many transactions. Many HTR blocks contain 3D blocks associated with HTRr block 696. This suggests that a multidimensional blockchain associated with drug p may form along the HTR axis. can.

[0092] The outcome-based contract between the HCP 120 and the payer 140 is a binding multi-dimensional block. When the conditions within the lock are met, a payment can be made by the payer 140 to the HCP 120. For example, the conditions can be stated as follows: (i) the level of some health parameters; or (ii) when a patient is treated with several drugs, You can specify one of several improvements in health parameters. In this embodiment, the contract duration can be encoded as a smart contract. The smart contract will be executed once its conditions are met, as further outlined below. When this happens, payments can be initiated automatically.

[0093] When a patient's treatment is initiated and a patient prescription is submitted, a request is sent to the network. an EHR information block for the patient, a DIR information block for a given drug, and transaction information blocks, and an initial multidimensional (3D) block (DIRp data) is created. Multidimensional blocks (e.g., 3D blocks containing data records 692) are formed. Start the chain.

[0094] At some point, a 3D block, such as 3D block 698, will reach a point where the health parameter value is met. or that the desired improvement in health parameters continues throughout the course of treatment with the drug. EHR blocks (associated with 3D block 698) that indicate either ), the smart contract will be bound by the specified time period. It can automatically start an action when the contract is completed. to indicate the completion of the contract, to send notifications to entities associated with the contract, Initiating a transaction to initiate payment from the payer 140 to the HCP 120; The parameters associated with the tract (e.g., length of time, initial determining and / or recording the patient's baseline and final values, number of visits, dosage, etc. In some embodiments, the transaction for initiating the payment may include , which may contain smart contract code that triggers payments and ensures traceability. The period may be, for example, at the end of treatment if the treatment is initiated within a multidimensional blockchain. The timestamp associated with the constrained 3D block 698 and the initial multidimensional block is determined by the difference between the timestamp associated with the block (e.g., the originating block) and the The determination can be made based on the time elapsed since the last item was purchased.

[0095] Referring to FIG. 6C, in some embodiments, the smart contract layer 680 It is also implemented in each dimension of the multidimensional blockchain to ensure that the multidimensional block is constructed correctly. In the example above, the smart contract layer can: Each multi-dimensional block in the blockchain represents the same patient, diagnosis, and drug, and / or condition. EH that is associated with the tract ID (e.g., between the HCP 120 and the payer 140) It can be ensured based on R.

[0096] In some embodiments, a patient (which may be an entity) in the system 650 When a medication is prescribed, the smart contract layer 680 checks the patient's insurance coverage, The payer 140 can be contacted regarding the drug's eligibility and the patient's response to its price. You may also request approval and agreement from the other party. Then, construction of the multidimensional block can begin.

[0097] In some embodiments, the holistic view enabled by the multidimensional blockchain Based on RWE, the field can facilitate the use of machine learning and AI techniques. For example, drug and medical device providers may restrict access to data, except for clinical trials. In some embodiments, (regulatory and business guidelines) Demographic information related to drug prescriptions (which may be included within EHR sub-blocks in accordance with the By linking, pharmaceutical and medical device providers can reach various demographic groups. This may allow researchers to understand the effects of drugs on patients, modify doses, monitor adverse outcomes, etc. Such data correlation (e.g., enabled via multi-dimensional blockchains) It may be possible to take preventative measures (e.g., increasing or decreasing the dose, detecting previously unknown (identifying potential drug interactions, etc.) and taking preventative measures to reduce patient risk This can increase safety and health outcomes while also reducing costs. ,sharing between entities is restricted, so patients and patients with other entities In addition, the privacy of users can be maintained by linking with multi-dimensional blockchains. Payments are routed between entities through the use of smart contracts. This can facilitate maintaining contract confidentiality between entities even when Cut.

[0098] FIG. 7 illustrates an exemplary method for facilitating healthcare information security and interoperability. 7 shows a flowchart of method 700. In some embodiments, method 700 is a multi-dimensional block diagram. It can use a blockchain, which is maintained by individual entities within the system. In some embodiments, the method may be based on a separate blockchain maintained by the 7000 will run on a private permissioned blockchain platform This can potentially take the form of a cloud-based system. The method 700 is a computer, such as a processor, computer, or distributed computing system. Including computer networks, application servers and cloud-based systems It can be executed by a server (hardware and software) that includes

[0099] In some embodiments, the method 700 may be performed at a first entity For example, the first entity may be at least one server or PMDP 130. A consumer product associated with at least one of a pharmaceutical or medical device provider In some embodiments, the first entity may include a computer system. , can interact with one or more second entities. The service may include one or more services associated with a healthcare provider, such as an HCP120. a server or computer system, or an insurance provider such as a payer 140, or a patient. In some embodiments, a first entity and one or more second entities may Entities form computing nodes within a distributed computing system. Multidimensional blockchains are permissioned private blockchain platforms. part of permissioned private blockchain platforms such as Platform 650 It can be formed.

[0100] In some embodiments, the method 700 may include: Initiate transactions to add blocks to a locally maintained blockchain It can be called when adding a block to the local blockchain. allows input from one or more other entities to be called, and allows permissioned private The blockchain platform 650 may invoke the method 700.

[0101] In some embodiments, in step 710, the first entity receiving a transaction from one or more second entities in response to a transaction at the point Each encrypted information block can be received. The block can be received from a separate second entity and sent to the first entity. Thus, the sub-block may include at least one sub-block that is decipherable. In this embodiment, for each encrypted block of information received by the first entity, The corresponding sub-block decodable by one entity is a first entity and The information interface between the first entity and the corresponding second entity can be based on the information interface between the first entity and the corresponding second entity. The information interface between the first entity and the corresponding second entity is Specifying the interaction between one entity and a corresponding second entity The determination can be based on predefined rules. The information interface between the entity and the corresponding second entity is multi-dimensional. The smart contract associated with the original blockchain (e.g., In some embodiments, the determination may be made by Smart contracts are tied to a multi-dimensional blockchain and are permissioned private. It may form part of a blockchain platform. So, smart contracts are a part of permissioned private blockchain platforms. related to information sharing, privacy, and contractual obligations between entities associated with the It can reflect your intentions.

[0102] In some embodiments, in step 720, the first entity The sub-blocks can be decrypted by the identity. In this state, to decrypt a sub-block, the first entity Receive corresponding authorization codes from one or more second entities associated with the information block. The received authorization code can be used to decrypt the decryptable sub-blocks. In some embodiments, the decryption of a sub-block by the first entity involves the decryption of the corresponding It can be based on a key that is securely shared between two entities. For example, if a subblock is When encrypted by some specific second entity, the first entity , using a key shared with or received from that second entity, In some embodiments, the shared key is part of the authorization code. can be safely received by the first entity as

[0103] In step 730, the first entity augments the multi-dimensional blockchain. The multi-dimensional blockchain can receive data from one or more second entities. At least one of the encrypted blocks of information is associated with the transaction. , the current block being added to the blockchain maintained by the first entity. can be augmented with multidimensional blocks formed by linking blocks Augmentation can involve adding multi-dimensional blocks to an existing blockchain, or is to add the first multi-dimensional block to the multi-dimensional blockchain structure (multi-dimensional block This may include adding a new shard to a newly created multi-dimensional blockchain. In some embodiments, the current block may include one or more sub-blocks, In this case, each sub-block of the current block is a first entity and a corresponding second entity. The information interface between the second entity and the corresponding For example, the sub-block j in the current block can be deciphered by The content consists of a first entity and a corresponding second entity, such as a second entity j. The information interface between the sub-block j and the second may be decipherable by entity j.

[0104] In some embodiments, growing includes adding a new multidimensional block to the multidimensional block. Multidimensional blockchains can include adding permissioned private blockchains to the blockchain. held by one or more second entities associated with the blockchain platform In some embodiments, multidimensional blocks may be stored and made accessible. (e.g., multi-dimensional blocks 655) may be one or more sub-blocks (e.g., sub-blocks 280, 380, 385, 480, and and / or 485). In some embodiments, the validity is determined by the presence of a permissioned private blockchain platform. A smart contract layer associated with the system (e.g., a smart contract layer 680) can be partially determined. For example, The layer (e.g., smart contract layer 680) is a permissioned private blockchain. Request validation from one or more of the entities associated with the platform. In some embodiments, a smart contract layer (e.g., , smart contract layer 680) is a system for authorizing entities or multiple entities to determine the identity of the subblock, verify the data associated with one or more subblocks, and Verification can be requested from one or more entities. In an embodiment, the validity of data associated with one or more sub-blocks is determined based on a consensus technique. In some embodiments, Byzantine Fault Tolerance (BFT) techniques can be used. can be used to determine the adequacy and / or reach of an agreement. By increasing the multidimensional blockchain with multidimensional blocks, the first entity The service provides at least one blockchain-based solution associated with a permissioned private blockchain platform. In some embodiments, the first smart contract may be invoked. entities are associated with a multi-dimensional blockchain via smart contracts. Based on the information provided, one or more contractual milestones and / or is one or more transactions between a first entity and one or more second entities. A contract may receive instructions to complete two or more contract outcomes.

[0105] In some embodiments, a multidimensional blockchain is augmented with multidimensional blocks. Then, a smart contract layer (e.g., smart contract layer 680) Between entities associated with a permissioned private blockchain platform It can evaluate the conditions associated with the contract and can determine the milestones on the contract. Whether the tone (e.g., between the HCP 120 and the payer 140) determines the health parameters Whether the desired criteria (meeting the desired criteria within a certain period of time from the start of treatment) have been met Desired contract outcomes (e.g., maintenance of health parameters over a period of time) are met. It can determine whether a contract has been executed, whether another contract-related event has occurred, etc. In some embodiments, one or more contract events may be associated with a contract. If it is determined that an error has occurred, the smart contract layer (e.g., smart contract Layer 680) performs one or more actions as outlined by a contract. For example, a smart contract layer (e.g., a smart contract layer 680) provides that (a) contract-related events are recorded by participating authorized entities; (b) health parameters, cost items, etc. that can be reported to the contracting party (e.g., the contracting party), , and / or performance parameters (as authorized by the contract) (c) reporting relevant data to the appropriate entities; and (d) contract-related actions, such as notifications, can be initiated automatically without human intervention. Stores information about events and actions taken in relation to contract-related events , can be associated with the corresponding contract(s).

[0106] Additionally, in some embodiments, a smart contract layer (e.g., The tract layer 680) initiates other actions to analyze the data and identify risks and treatments, Other factors that may affect outcomes, etc. may be identified. In some embodiments, Initiate a smart contract layer (e.g., smart contract layer 680) or using it to develop mechanisms based on RWE associated with a multidimensional blockchain. Machine learning tools and AI techniques can be used to identify specific drug (DIR) It can be associated with multiple patients and associated with a multi-dimensional block in a multi-dimensional blockchain. Each DIR data record for a drug being administered is associated with the patient for whom the drug was prescribed (e.g., EHR sub- Some demographic non-personal information (age, medical condition, zip code, etc.) received via the block In some embodiments, the patient may be prescribed other medications (e.g., multiple The data in the original blockchain is used in smart contracts before binding to the multi-dimensional blocks. (and have been appropriately validated using the features associated with the layer) When a specified number of transactions have occurred and / or a specified period of time has elapsed (e.g., from the introduction of a drug or the last machine learning run), a smart contract layer (e.g., smart contract layer 680) can be used to link drugs across multiple patients. Machine learning can be initiated based on the received DIR data records. potential risks associated with the drug (medical conditions, side effects, drug interactions, etc.) Predictive or enhanced cognition and / or drug efficacy was above average. Therefore, it may be possible to identify cases where the amount of Device providers (e.g., PMDP130) have conducted studies to assess the efficacy and safety of various demographic groups, dose changes, and adverse events. It may be possible to understand the effect of the drug on outcome monitoring etc. The relationship (e.g., enabled via a multi-dimensional blockchain) can take preventative measures. may be effective (e.g., increasing or decreasing dose, previously unknown drug interactions, etc.), and Preventive measures reduce patient risk and increase safety and health outcomes while also Furthermore, the DIR records associated with a particular prediction can be determined. In situations where this is possible, the corresponding multidimensional blocks (e.g., the ) can be used by an entity (e.g., by a PMDP 130) to update its predictions. The results can be validated (e.g., to determine whether further research is needed).

[0107] In step 740, the first entity selects one or more second entities. It may be possible to access a multidimensional blockchain for at least one of In some embodiments, access to the multidimensional block is based on a cryptographic hashing function. 6B) and encrypt the multidimensional block based on the This is possible by storing a multi-dimensional blockchain containing multi-dimensional blocks along with the access permissions. The data may be accessible by one or more second entities. For example, the multi-dimensional blockchain may be implemented by a processor or computer system that executes method 700. In some embodiments, the multidimensional block may be stored on cloud-based storage and used in a permissioned private blockchain platform. The appropriate entities associated with the platform can be made accessible. As outlined in the The entity that is added must verify the integrity of the information associated with the multidimensional block to which it is added. It may be possible to have a data record (e.g. For example, data records 520, 530, and 540) are Furthermore, as outlined above, multidimensional blocks (e.g., The multidimensional block 655) is used to store local data records and data records (e.g., data records 520, 530, and 540), and the link The departments may, in some cases, have corresponding separate local blockchains (e.g., Blocks can be formed within the slits 525, 535, and 545).

[0108] FIG. 8 illustrates a smart contract layer (e.g., smart contract layer 680). As shown in Figure 8, the smart contract The first 810 is a contracting entity consisting of the payer 140, the patient 805, and The smart contract 28 may be implemented to reflect an agreement between the HCP 120 and the 20 may be implemented to reflect an agreement between the payer 140 and the PMDP 130. Mart Contract 3 830 reflects the agreement between the PMDP 130 and the patient 805 In contrast, smart contract 4 840 may be implemented as PMDP 130 and HCP 120. Smart contracts (e.g., Smart Contract 1810, Smart Contract Smart Contract 2 820, Smart Contract 3 830, and Smart Contract 4 840 ) may be stored in a contract database. Each smart contract (e.g., Smart Contract 1 810, Smart Contract Smart Contract 2 820, Smart Contract 3 830, and Smart Contract 4 84 0) includes program code with rules and is used to create a multi-dimensional block within a multi-dimensional block chain. In some embodiments, the data associated with the lock can be evaluated. A smart contract layer (e.g., smart contract layer 680) may be implemented as one or more sub-contracts. It can decode the information in the block (on behalf of the receiving entity) and Decisions can be made based on the code / rules associated with the smart contracts that are used. For example, an entity can delegate some functionality to a smart contract layer. Or the smart contract layer can, when authorized, In some embodiments, one or more entities may act as proxies for The entity may share information with a smart contract for data validation and / or contract management. It can be securely shared with the smart contract layer (e.g., The port contract layer 680 flags data errors and enforces permissioned private The entity's access to other entities associated with the blockchain platform. ensure the integrity of data reported by entities, perform data validation, and and / or specify and / or monitor information interfaces between authorized For example, smart contracts can ensure that data is shared. A layer (e.g., smart contract layer 680) may use a global field ID, and / or other entities in the transaction using known correlations between fields. It is possible to ensure that the data reported by the entities is consistent. As an example, the smart contract layer 680 may be configured to allow the HCP 120 to 05 and the information in the medical parameter field (e.g., blood pressure) reported to the payer 140 Consistency can be guaranteed.

[0109] Information is distributed based on sub-blocks on a permissioned private blockchain platform. Since it is shared across multiple entities, the smart contract layer (e.g., smart contract The layer 680) manages the entities Payer 140, Patient 805, and HCP 120. Smart contracts between multiple entities, such as blockchains, can be implemented to implement contracts between multiple entities. As outlined above, conventional systems may be able to accommodate three or more engines. In addition, it may be impossible to implement contracts between entities. The chain provides a data security mechanism for data records associated with a particular entity. ensures security (so that data records cannot be shared with other unauthorized entities) Furthermore, a separate local blockchain (e.g., Completed data blocks (e.g., 520, 535, and 545, respectively) 30, and 540) are within a completed multidimensional block (e.g., multidimensional block 655). A permissioned private blockchain platform for data records entities associated with the HCP 120, PMDP 130, and Payer 1 40) share a consistent and coherent view of that information and It can be easily correlated. Smart contract layer (e.g., LactoLayer 680) can also facilitate rapid system updates, because ,When applicable, the same contract may be applied to a class of entities (e.g., patient 805). Therefore, for example, a payment by a payer 140 for a medical condition Updates to smart contract 1810 to reflect new drug approvals All patients associated with the smart contract 1 (e.g., associated with the payer 140) and provide rapid access to patients (such as Patient 805, who is being treated for a condition caused by HCP120). Furthermore, the impact of any changes to smart contracts is localized. The changes in the smart contract 4840 between the PMDP 130 and the HCP 120 are related In conventional systems, the impact would only be felt by the entity involved. A contract / entity (e.g., the addendum outlined in Figure 1B) consists of two entities The Ripple effect can be linked to contracts between other entities / consumers. This can have a major impact on the tract.

[0110] In some embodiments, as outlined above, a smart contract layer (e.g., The smart contract layer 680 periodically (e.g., at specified time intervals) and / or contract-related events (e.g., transactions and / or multi-dimensional blocks) When a transaction (addition of a block) occurs, the contract may be evaluated and executed by the entity and / or When agreed to, the request is processed by the entity associated with the contract. For example, the smart contract layer 680 can The terms and conditions associated with the smart contract 1810 between the person 140 and the patient 105 In the above example, smart contract 1 810: (a) evaluates the information authorized to be shared between entities (e.g., using subblocks) (b) contract milestones (e.g., patient 805 health parameters) The meter is configured to determine whether a desired criterion is met within a certain period of time from the start of treatment. (c) a contract between the HCP 120 and the payer 140; (d) Contract / milestone fulfillment criteria can be specified. The action to be initiated can be specified.

[0111] For example, a milestone in smart contract 1 might be to raise patient 805's blood pressure to a certain level. Specify a range between the milestones to be met within a certain time period. If satisfied, a first payment from the payer 140 to the HCP 120 can be designated. The smart contract 1 determines whether the blood pressure range of the patient 805 is within a specified range for a certain period of time. If the payment remains within the payment period, the payer 140 may specify an additional payment to the HCP 120. Submission of data records by the HCP 120 (intelligible and appropriate format by the payer 140) When the transaction is completed, smart contract 1 calculates the time elapsed since the start of treatment. and determining (e.g., the corresponding multidimensional blocks associated with the patient 805 and the HCP 120) (based on the timestamp associated with the blood pressure range). If the milestone is met, smart contract 1 will transfer the milestone to the entity. report to the company, store information associated with milestones, and create invoices with the appropriate information. and initiate payment from the payer 140 to the HCP 120. In this example, smart contract 1 determines whether the blood pressure range of patient 805 remains within a predetermined range. (e.g., the corresponding multidimensional based on the timestamp associated with the block), and report the outcome to the entity. Stores information associated with performance determination, generates invoices, and reports with pertinent information 120 , and initiate another payment from the payer 140 to the HCP 120 .

[0112] In some embodiments, one or more contract events may occur in some contracts. If it is determined that a related event has occurred, the smart contract layer (e.g., The control layer 680 may perform one or more actions as outlined by the contract. For example, a smart contract layer (e.g., (a) The contract-related events are recorded by the participating authorized entities. (b) health parameters, cost terms, and Contract details, such as specifications and / or performance parameters (as approved by the contract) (c) reporting transaction-related data to the appropriate entities; (d) contract-related actions such as reporting can be initiated automatically without human intervention; Stores information about related events and actions taken in relation to contract-related events can be associated with corresponding contract(s), and / or (e) tools (e.g., machine learning) to analyze the data associated with the multi-dimensional blockchain. It can be analyzed.

[0113] Figure 9 shows how healthcare systems can facilitate security and promote interoperability. 9 illustrates an exemplary computer 900 that can acts as a host and / or a permissioned private blockchain platform In some embodiments, the exemplary The computer 900 includes one or more entities (HCP 120, PMDP 130, and / or or payer 140, or may be a server for a server (e.g., an application In some embodiments, the computer 900 may run a Method 700, and / or other techniques disclosed herein may be implemented. In some embodiments, computer 900 forms part of a distributed computing system. This allows for the creation of a permissioned private blockchain platform. In some embodiments, a distributed computing system and / or The computer 900 may be cloud-based.

[0114] In some embodiments, the computer 900 / processor(s) 950 may It may be possible to process transaction requests, which may include blocking. It includes requests related to adding blocks to the chain, including multi-dimensional blockchains. Additionally, computer 900 / processor(s) 950 may perform encryption and / or decryption. It runs an algorithm, takes a hash of the block of information, verifies the hash, and digitally It may be possible to perform signatures and implement and / or support various methods to This may allow for facilitating security and authentication, which is the verification of the integrity of stored information. Evidence (e.g., the integrity of blocks in a blockchain to determine any unauthorized modifications) access to a permissioned private blockchain platform The entity is trusted and authorized to perform any requested transaction. In some embodiments, the computer The data processor 900 / processor(s) 950 also updates the blockchain with the new block. It is also possible to increase (create or add) the number of blocks (multidimensional blocks can be used to create multidimensional block chains). In some embodiments, the computer 900 / processor Processor(s) 950 also provides smart contract services associated with the blockchain. Save and run the project to manage entities (e.g., HCP120, PMDP130, Payer 140, and / or patient(s)) privacy, information sharing, and contract enforcement. Agreements relating to the above can also be achieved.

[0115] In some embodiments, the computer 900 / processor(s) 750 may be a machine Learning techniques can be analyzed and used to determine relationships between various health parameters. For example, computer 900 / processor(s) 950 may include one or two one or more neural network processor(s), and / or The neural network may include a distributed processor that may be configured as a network. capable of running software for modeling and / or simulating ,The software can be used to realize machine learning. For example, PMDP1 30, machine learning technology-based RWE information available through multidimensional blocks (e.g., human demographic information, side effects, drugs used in combination with drugs of particular interest, treatment outcomes, etc. For example, machine learning can be used to tailor drug use. Target drugs based on volume, demographics, improved drug interaction information, increased safety, various The relative effectiveness of various management modes can be determined. Information may not be available for PMDP130 outside of clinical trials, thereby limiting efficacy. The use of machine learning and AI technologies will be excluded or severely limited.

[0116] In some embodiments, the computer 900 includes a communication / network interface The interface 902 can be used to connect to other computers. , wired (e.g., Ethernet, including Gigabit Ethernet) and wireless interfaces The air interface may include cellular interfaces including 3G, 4G, and 5G standards. Wireless Wide Area Network (WWA) N) standard, based on the IEEE 802.11x standard, commonly known as Wi-Fi It is possible.

[0117] The computer 900 may include a memory 904, which may include read-only memory Read Only Memory (ROM), Programmable Read Only Memory (Programmable R PROM, various types of random access memory (Random Access Memory), The memory 904 may include one or more of: It may be implemented within the processor(s) 950 or external to the processor(s) 950. As used herein, the term "memory" includes long-term, short-term, volatile, and non-volatile memory. refers to any specific type of memory or memory The present invention is not limited to the number of memories or the type of media on which the memories are stored.

[0118] The memory may include cache memory, primary memory, and secondary memory. , may include computer-readable medium 920. The computer-readable medium may be magnetic and / or optical. The data may include optical media, which may in some cases be removable media. Possible media include compact discs (CDs), laser discs, and digital Digital video discs (DVDs), Blu-ray discs, and other optical media This may include optical discs such as USB drives, flash drives, solid state drives, etc. The computer 900 may further include a storage device 960. These may include hard drives, solid state drives, e, SSD), flash memory, other non-volatile storage, and cloud-based storage may include:

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

[0120] The methods described herein may be implemented by a variety of means depending on the application. For example, these methods may be implemented in hardware, firmware, software, or can be implemented with any combination of them. In the case of a hardware implementation, The sensor(s) 950 may include one or more application specific integrated circuits. rated circuit (ASIC), digital signal processor (D SP), neural network processor (NNP), Digital signal processing device (DSPD), programmer Programmable logic device (PLD), field programmer field programmable gate array (FPGA), processor, controller controllers, microcontrollers, microprocessors, electronic devices, other electronic units designed to perform the functions specified in It can be implemented.

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

[0122] When implemented in firmware and / or software, the function may also be one or more one or more instructions or code computer-readable medium 920, a storage device 960, and and / or memory 904. Examples include data structures and computer programs. For example, a computer-readable medium encoded with the The readable medium 920 may include program code stored thereon, and may be used to To support methods to facilitate security and promote system interoperability It may include program code for multi-dimensional blockchains, smart contracts, consensus judgments, etc. support the configuration of a permissioned private blockchain as described herein. and performing other functions associated with the application platform.

[0123] The processor(s) 950 are a combination of hardware, firmware, and software. In some embodiments, the computer 900 may be implemented using a combination of: Coupled to a display for viewing the GUI and interacting with administrators and other users This can facilitate the process.

[0124] Although the present disclosure has been described in connection with specific embodiments for educational purposes, the present disclosure Various adaptations and modifications to this disclosure may be made without departing from the scope of the invention. Therefore, the spirit and scope of the appended claims shall be construed as including the foregoing. should not be limited to the description of

Claims

1. 1. A processor-implemented method comprising: In response to a transaction at a first time, at the first entity, Transmitting encrypted blocks of information relating to a transaction from one or more second entities receiving from a separate second entity each encrypted block of information; at least one sub-block received from the first entity and decipherable by the first entity; receiving, decrypting, by the first entity, the decryptable sub-block; augmenting a multi-dimensional blockchain by the first entity; The multidimensional blockchain receives the cryptographic information from the one or more second entities. At least one of the encrypted information blocks is associated with the transaction. the current blockchain maintained by the first entity. as augmented with multidimensional blocks formed by combining blocks of , and increasing The multidimensional blockchain of at least one of the one or more second entities. and enabling access to the application.

2. For each received encrypted information block, decryption by the first entity The possible corresponding sub-blocks are the first entity and the corresponding second entity. The method of claim 1 , wherein the information interface is based on an information interface between the information interface and the entity.

3. The information interface between the first entity and the corresponding second entity. an interface between the first entity and the corresponding second entity; 3. The method of claim 2, wherein the determination is based on predetermined rules that define the interaction.

4. The information interface between the first entity and the corresponding second entity. The interface is operated by a smart contract associated with the multi-dimensional blockchain. The method of claim 2 , wherein the value is determined by:

5. Enabling access to the multidimensional blockchain encrypting the multidimensional block based on a hashing function; and the multidimensional block along with access permissions to allow access by the entity and storing the multi-dimensional blockchain including the block. Law.

6. Decrypting the sub-block by the first entity a corresponding one or more second entities associated with the encrypted information block; receiving an authorization code for decrypting the decryptable subtitle using the received authorization code; and decrypting the block.

7. The current block includes one or more sub-blocks, and each sub-block in the current block The block is for information exchange between the first entity and a corresponding second entity. interface and is decipherable by the corresponding second entity. The method of claim 1 .

8. The first entity is at least one of a pharmaceutical provider and a medical device provider. The method of claim 1 , including at least one server associated with one of the servers.

9. The one or more second entities may be a healthcare provider, an insurance provider, or a patient.

10. The method of claim 1, further comprising one or more servers associated with at least one of:

10. The first entity and the one or more second entities are part of a distributed computing a computing node in a computing system, and the multi-dimensional blockchain is 10. The method of claim 1, forming part of a modular private blockchain platform. How to do it.

11. The first entity uses the multidimensional block to create the multidimensional block diagram. In increasing the number of blockchains, the permissioned private blockchain platform and invoking at least one associated smart contract. The method according to claim 10.

12. The smart contract provides the information associated with the multi-dimensional blockchain. Based at least in part on the first entity and the one or more second entities. receiving an indication of completion of one or more contract milestones between the parties; The method of claim 11 further comprising:

13. 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: Responsive to a transaction at a first time via the communication interface. and at the first entity, encrypted information relating to the transaction. receiving information blocks from one or more second entities, each encrypted information block; The information block is received from a separate second entity and transmitted by the first entity. receiving a signal including at least one sub-block decipherable by the signal; decrypting, by the first entity, the decryptable sub-block; The first entity creates a multidimensional blockchain resident in the memory. and increasing the number of multidimensional blockchains by one or more of the second blockchains. At least one of the encrypted information blocks received from the entity is encrypted a blockchain associated with the transaction, Multidimensionality formed by linking to the current block maintained by the Increasing, such as by using blocks; the multidimensional block by at least one of the one or more second entities; a processor configured to: 、 A server comprising:

14. For each received encrypted information block, decryption by the first entity The possible corresponding sub-blocks are the first entity and the corresponding second entity.

14. The server of claim 13, wherein the server is based on an information interface between the server and the entity.

15. The information interface between the first entity and the corresponding second entity. an interface between the first entity and the corresponding second entity; 15. The server of claim 14, wherein the interaction is determined based on predetermined rules that govern the interaction. Ba.

16. The information interface between the first entity and the corresponding second entity. The interface is operated by a smart contract associated with the multi-dimensional blockchain. The server of claim 14, wherein the determination is made by

17. To enable access to the multidimensional blockchain, the processor: encrypting the multidimensional block based on a hashing function; storing the multidimensional block chain including the multidimensional block in the memory; 14. The server of claim 13, configured to:

18. To decrypt the sub-blocks, the processor: associated by the first entity with the received encrypted information block. receiving a corresponding authorization code from the one or more second entities associated with the one or more second entities; decrypting the decryptable sub-block using the received authorization code; 14. The server of claim 13, configured to:

19. The current block includes one or more sub-blocks, and each sub-block in the current block The block is for information exchange between the first entity and a corresponding second entity. interface and is decipherable by the corresponding second entity. The server according to claim 13.

20. The first entity is at least one of a pharmaceutical provider and a medical device provider.

14. The server of claim 13, including at least one server associated with one of the

21. The one or more second entities may be a healthcare provider, an insurance provider, or a patient.

14. The server of claim 13, comprising one or more servers associated with at least one of:

22. The first entity and the one or more second entities are part of a distributed computing a computing node in a computing system, and the multi-dimensional blockchain is 22. The method of claim 21, forming part of a configurable private blockchain platform. Server listed.

23. The processor augments the multidimensional block chain with the multidimensional block. When the permissioned private blockchain platform is created, 2. The method of claim 1, further configured to: invoke at least one smart contract.

2. The server according to claim 2.

24. The processor receives from the smart contract information relating to the multidimensional blockchain. and determining whether the first entity and the one or more An indication of the completion of one or more contract milestones with the second entity above.

23. The server of claim 22, further configured to receive:

25. A non-transitory computer-readable medium containing executable instructions, The executable instructions: Responsive to a transaction at a first time via the communication interface. and at the first entity, encrypted information relating to the transaction. receiving information blocks from one or more second entities, each encrypted information block; The information block is received from a separate second entity and transmitted by the first entity. receiving a signal including at least one sub-block decipherable by the signal; decrypting, by the first entity, the decryptable sub-block; The first entity creates a multidimensional blockchain resident in the memory. and increasing the number of the multi-dimensional blockchains by one or more of the second entities. At least one of the encrypted information blocks received from the entity is encrypted by the added to the blockchain associated with the transaction, A multidimensional block is formed by linking to the current block maintained by the Increasing, such as by using a lock; the multidimensional block by at least one of the one or more second entities; enabling access to the chain; A non-transitory computer-readable medium configured to cause a processor to 。

Images