Systems and methods for healthcare interoperability

Abstract

Embodiments facilitate interoperability and reliable patient selection for clinical trials and drug / device deployment. An entity may obtain a first set of health parameters and collective demographic information associated with one or more population segments and receive an electronic health record (EHR) sub-block having patient profile information and corresponding patient medical history for a patient. The entity may determine a subset of eligible candidate patients for a treatment based on information in the EHR sub-block and eligibility criteria for the treatment, which may be based on the first set of health parameters and / or the collective demographic information. The entity may transmit a sub-block including the eligible candidate patient profile and medical information associated with at least one treatment, and the entity may extend the multi-dimensional blockchain by linking the transaction block with the drug-device information block and the EHR block in response to receiving the transaction block with the transaction confirmation.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit and priority of U.S. Patent Application No. 17 / 149707, filed on January 14, 2021, entitled "SYSTEM AND METHOD FOR HEALTHCARE SECURITY AND INTEROPERABILITY", which is a continuation - in - part of U.S. Patent Application No. 16 / 703848, filed on December 4, 2019, entitled "SYSTEM AND METHOD FOR HEALTHCARE SECURITY AND INTEROPERABILITY" (currently U.S. Patent No. 10931437), which is a continuation of U.S. Patent Application No. 16 / 251980, filed on January 18, 2019, entitled "SYSTEM AND METHOD FOR HEALTHCARE SECURITY AND INTEROPERABILITY" (currently U.S. Patent No. 10541807). The applications identified above are hereby incorporated by reference in their entirety.

[0002] (Field of the Invention) The subject matter disclosed herein relates to the security and interoperability of healthcare systems, and more particularly to supporting the selection of patient clinical trials and the development of medical products.

Background Art

[0003] Healthcare information systems face compliance issues that limit interoperability. For example, stored information may be subject to various privacy regulations, such as the Health Insurance Portability and Accountability Act (HIPAA). Privacy rules under HIPAA establish national standards for protecting individuals' medical records and other personal health information when healthcare transactions are conducted electronically. These regulations may cover privacy (e.g., which entities have access to information), content (what information authorized entities may access), security (how information is protected from unauthorized access when stored and during electronic transmission), information sharing (types of information entities may share), and integrity (accuracy and reliability of information). Furthermore, commercially valuable information may be protected under organizational policies that restrict its sharing with third parties (e.g., as trade secrets and / or for business or commercial reasons). Regulations such as the European Union's General Data Protection Regulation (GDPR) and state regulations can also have a significant impact on information collection, storage, sharing, and communication. These regulations affect information sharing practices among healthcare market participants, leading to the creation of isolated, systematic "data repositories" where information available to an entity is isolated, even if it is useful overall (for example, to another non-competitive entity). Such compartmentalization of information increases the difficulty in selecting appropriate patients to participate in clinical trials and reduces the efficiency of conducting trials. For example, pre-trial screening of patients may involve manual screening by healthcare providers, manual contact with patients individually for approval, further screening by Institutional Review Boards, patient selection, and patient consent—all of which may take place before the actual trial.These inefficiencies can have negative consequences when clinical trials are conducted during health emergencies and / or when approved medical products need to be deployed quickly and effectively. In addition, these data repositories also increase system costs (e.g., by limiting the information available to patients or healthcare providers when considering the costs of alternative treatment options, treatment locations, etc.), and / or increase patient risk (e.g., from drug interactions, prescription drug abuse, etc.), and / or limit the effectiveness of outcomes-based approaches to medical treatment or remediation (e.g., making it more difficult and expensive to determine when a desired outcome was achieved or to compare it to metrics in approaches that achieve similar outcomes). Therefore, there is a need for systems and methods that address one or more of the above problems, which can help facilitate healthcare information security while promoting interoperability among market participants. [Overview of the project] [Means for solving the problem]

[0004] In some embodiments, the method performed by the processor involves obtaining a first set of health parameters and aggregate demographic information associated with one or more population segments, and one or more encrypted first electronic health records that can be decrypted by the first entity. Receiving a Record (EHR) subblock, where one or more first electronic health record (EHR) subblocks include (a) patient profile information corresponding to one or more patients, and (b) corresponding patient medical history for one or more patients; determining from one or more patients a subset of candidate patients eligible for at least one treatment based on a comparison of the information in one or more EHR subblocks with corresponding eligibility criteria for at least one treatment, where the corresponding eligibility criteria are based on one or more of a first set of health parameters or aggregate demographic information; transmitting one or more encrypted first subblocks decryptable by one or more corresponding second entities, where each first subblock includes at least one candidate patient profile and medical information associated with at least one treatment; and extending a multidimensional blockchain in response to receiving a transaction block having transaction confirmation, where the multidimensional blockchain includes (i) a transaction block containing treatment deployment-related information associated with at least one treatment, and (ii) drug-device information containing medical information associated with at least one treatment. The expansion may include, (iii) extending a multidimensional block formed by linking an Information (DIR) block with (iii) an EHR block containing information on at least one candidate patient profile, corresponding candidate patient history for at least one candidate patient, and prescription information for at least one treatment.

[0005] In another embodiment, the computing device for the first entity may include memory, a communication interface, and a processor coupled to the memory and the communication interface. In some embodiments, the processor receives: a first set of health parameters and aggregate demographic information associated with one or more population segments; and receives one or more encrypted first electronic health record (EHR) subblocks decryptable by the first entity, each of which includes (a) patient profile information relating to one or more patients and (b) corresponding patient medical history for one or more patients; and determines from one or more patients a subset of candidate patients eligible for at least one treatment based on a comparison of the information in the one or more EHR subblocks with corresponding eligibility criteria for at least one treatment, the corresponding eligibility criteria being based on one or more of the first set of health parameters or aggregate demographic information; and decryptable by one or more corresponding second entities. Transmitting, transmitting one or more encrypted first subblocks, each of which includes at least one candidate patient profile and medical information associated with at least one treatment, and extending a multidimensional blockchain in response to receiving a transaction block having transaction confirmation, wherein the multidimensional blockchain is extended by a multidimensional block formed by linking (i) a transaction block containing treatment deployment-related information associated with at least one treatment, (ii) a drug device information (DIR) block containing medical information associated with at least one treatment, and (iii) an EHR block containing information on at least one candidate patient profile, corresponding candidate patient medical history for at least one candidate patient, and prescription information for at least one treatment.

[0006] In a further embodiment, the apparatus includes means for acquiring a first set of health parameters and aggregate demographic information associated with one or more population segments, and means for receiving one or more encrypted first electronic health record (EHR) subblocks decryptable by a first entity, where one or more first EHR subblocks include (a) patient profile information corresponding to one or more patients and (b) corresponding patient medical history for one or more patients, and means for determining from one or more patients a subset of candidate patients eligible for at least one treatment based on a comparison of the information in one or more EHR subblocks with corresponding eligibility criteria for at least one treatment, where the corresponding eligibility criteria are based on one or more of the first set of health parameters or aggregate demographic information, and means for determining one or more decryptable by a corresponding second entity Means for transmitting the above-described encrypted first subblocks, wherein each transmitted first subblock includes at least one candidate patient profile and medical information associated with at least one treatment; and means for expanding a multidimensional block in response to receiving a transaction block having transaction confirmation, wherein the multidimensional block is expanded by a multidimensional block formed by linking (i) a transaction block including treatment deployment-related information associated with at least one treatment, (ii) a drug device information (DIR) block including medical information associated with at least one treatment, and (iii) an EHR block including information on at least one candidate patient profile, corresponding candidate patient medical history for at least one candidate patient, and prescription information for at least one treatment.

[0007] In some embodiments, the non-temporary computer-readable medium may comprise an executable instruction which includes: receiving a first set of health parameters and aggregate demographic information associated with one or more population segments; receiving one or more encrypted first electronic health record (EHR) subblocks decryptable by a first entity, each of which includes (a) patient profile information relating to one or more patients and (b) corresponding patient medical history for one or more patients; and determining from one or more patients a subset of candidate patients eligible for at least one treatment based on a comparison of the information in the one or more EHR subblocks with corresponding eligibility criteria for at least one treatment, the corresponding eligibility criteria being based on one or more of the first set of health parameters or aggregate demographic information, and one or more corresponding Transmitting, sending one or more encrypted first subblocks decryptable by a second entity, each of the first subblocks including at least one candidate patient profile and medical information associated with at least one treatment, and extending a multidimensional blockchain in response to receiving a transaction block having transaction confirmation, the multidimensional blockchain being extended by a multidimensional block formed by linking (i) a transaction block including treatment deployment-related information associated with at least one treatment, (ii) a drug device information (DIR) block including medical information associated with at least one treatment, and (iii) an EHR block including information on at least one candidate patient profile, corresponding candidate patient medical history for at least one candidate patient, and prescription information for at least one treatment.

[0008] The disclosed methods may be carried out using computer-readable media or computer-readable memory by one or more of the following: mobile computing devices, computers including servers, cloud-based systems, etc. [Brief explanation of the drawing]

[0009] Embodiments of the present invention will be described only by reference to the drawings. [Figure 1] This is a schematic block diagram representing the interactions between several entities associated with a conventional healthcare information system. [Figure 2] An example electronic health record is shown, with several example data fields within the record represented. [Figure 3] This shows an exemplary portion of a drug / device information record (DIR) for a drug / device that may be stored in a DIR database. [Figure 4] This shows a typical portion of a Clinical Trial Record (CTR) that may be maintained by the entity conducting the clinical trial. [Figure 5] An exemplary health transaction record is shown. [Figure 6] This shows a portion of an exemplary Public Health Entity Record (PHER) 600 that may be maintained by a public health entity. [Figure 7A] This flowchart illustrates an exemplary process flow designed to facilitate reliable candidate selection for clinical trials and promote interoperability among multiple entities. [Figure 7B] This document illustrates entities and layers associated with an exemplary platform designed to facilitate reliable clinical trial candidate selection and promote healthcare system interoperability. [Figure 7C] This flowchart illustrates an exemplary method for facilitating reliable candidate selection for clinical trials and promoting interoperability among multiple entities. [Figure 8] This flowchart illustrates an exemplary process flow designed to facilitate reliable drug / device deployment and promote interoperability between multiple entities. [Figure 9] This flowchart illustrates an exemplary method for promoting healthcare information security and interoperability while facilitating reliable drug / device deployment and advancing interoperability between multiple entities. [Figure 10] This is a flowchart of 1000 exemplary methods for facilitating patient selection for clinical trial participation and / or drug / device deployment. [Figure 11] This is a schematic diagram of an exemplary computer or computing device that can facilitate patient selection for clinical trials and / or drug / device deployment while supporting healthcare system security and interoperability.

[0010] In the figures, similar reference numbers and symbols in various figures illustrating specific exemplary embodiments indicate similar elements. For example, subblocks containing similar information are referenced by the same reference number. In addition, multiple instances of an element may be indicated by a first number for the element followed by a letter, or by a hyphen and a second number. For example, multiple instances of element 280 may be indicated as 280-1, 280-2, etc. When such an element is referenced using only the first number, any instance of that element should be understood (for example, element 280 in the above example would refer to elements 280-1, 280-2, ..., and / or 280-N). Furthermore, in the following figures, an asterisk symbol ("*") associated with a reference number indicates that an element (or part thereof) may be repeated (for example, for each instance of the element). For example, a prescription may contain several drug instances, and a dose field may be repeated for each drug instance.

[0011] The following diagram also illustrates the hierarchy of records, which may contain fields and subfields. A record contains any fields (and some or all of the subblocks) that are part of the record. Similarly, a field contains any subfields. A subfield may contain additional subfields. In addition to laws / regulations governing information sharing, fields within subblocks shared between entities may depend on one or more of the following: the information interface between entities, the transaction type, the context in which the data is shared, and the transaction state when the subblocks are exchanged. [Modes for carrying out the invention]

[0012] The disclosed embodiments promote the security of healthcare systems while advancing the integrity, interoperability, treatment options, and cost transparency of healthcare systems.

[0013] Figure 1 shows a schematic block diagram representing the interactions between several entities associated with a conventional healthcare information system 100. Figure 1 merely shows the information flow for the transactions associated with and discussed by the entities illustrated. In general, various other entities (not shown in Figure 1) and / or other types of transactions are assumed.

[0014] A healthcare transaction may involve several entities, each of which may possess some information related to the transaction and use that information to complete it. Therefore, in conventional systems, certain limited information (e.g., limited for regulatory, contractual, privacy considerations, confidentiality, and / or competitive reasons) may be exchanged between transaction entities to complete a transaction. As used herein, the term “entity” may refer to an individual (e.g., a patient or group of patients), or an organization, or a participant in the healthcare market, and / or computing and information systems (e.g., hardware and / or software) associated with an individual / group / organization that may participate in the healthcare market on their behalf. For example, a computing system associated with one entity may use a computing system associated with another entity to process and / or exchange information. Information exchange between entities may take place via a secure communication network and / or via the internet in a secure manner (e.g., using encryption) and / or on an electronic platform (e.g., for information exchange and / or transaction exchange).

[0015] A Sponsoring Entity (SE) 150 may aim to conduct clinical research, including clinical trials and observational studies, to test scientific hypotheses and obtain scientific evidence. The clinical research can be carried out in accordance with applicable laws and regulations (which may vary by jurisdiction), as well as accepted Good Clinical Practice and / or prevailing Good Clinical Practice. The clinical research can be conducted on one or more drugs and / or devices. The term Sponsoring Entity (SE) 150 is widely used to refer to any organization and / or organizational department that can conduct clinical research. Thus, SE150 can be an organization such as a university, research foundation, etc., and / or a department of an entity such as a Pharmaceutical and / or Medical Device Provider (PMDP) 130, and / or an entity employed by or contracted with an organization that conducts clinical research on behalf of the organization. As an example, SE150 can be a department of PMDP130-i, and the clinical research can involve drugs / devices from competing PMDP130-j (i≠j) (e.g., to evaluate effectiveness, performance, etc.) or can include drugs / devices.

[0016] As another example, SE150 (e.g., a department of PMDP130-k) may submit an Investigational New Drug Application (IND) to an appropriate regulatory agency such as the US Food and Drug Administration (FDA). The IND application can include the proposed protocol for the trial and any relevant past data supporting the proposed trial. When the IND application and protocol are approved, SE150 can initiate the trial process. In some cases, (prior to approval), the regulatory agency (e.g., FDA) may request protocol changes, and SE150 may go through iterations of protocol amendments (e.g., by appropriately revising and resubmitting the protocol) before receiving approval.

[0017] Upon approval from an accredited authority (e.g., the FDA), SE150 may select one or more qualified healthcare providers (HCPs) / principal investigators (PIs)120 (hereinafter collectively referred to as HCP120 and / or HCP / PI120), provide them with the proposed clinical procedure and approved protocol129, and ensure that the clinical study is conducted in accordance with the previously approved protocol and that the investigation is properly monitored. If HCP120 is the principal investigator (PI) responsible for the trial at a given trial site, or the lead PI (e.g., leading the entire trial), HCP120 may also be referred to herein as PI120 for clarity. HCP / PI120 may request modifications to the proposed clinical procedure129, and the interaction between HCP120 and SI 150 may continue until consent is obtained for the clinical procedure to be used for the trial.

[0018] The term SE150 is also used herein to refer to any institution to which SE150 may transfer some or all of its responsibilities (e.g., via a contract). Typically, SE150 may include one or more other entities such as a Protocol Validator (PV), a Clinical Trial Review Board (CTRB), an Institutional Review Board (IRB), a Data and Safety Monitoring Board (DSMB), etc., which may have specific responsibilities related to clinical research, be monitored by them, and / or interact with them. For example, the DSMB can evaluate and review the safety, conduct, progress, and effectiveness of the accumulated clinical trials. The IRB can examine, modify, and monitor clinical research and procedures when human subjects are involved. The IRB may have the authority to approve a study, require modifications to the study (e.g., to secure IRB approval), or not approve the study to ensure the protection of the rights and welfare of human subjects in the study. SE150 can provide and access some or all of the information obtained by the above entities associated with the clinical trial (subject to legal and procedural constraints).

[0019] SE150 and PMDP130 are shown as separate entities in FIG. 1 and are described as such herein. Regardless of whether SE150 and PMDP130 form departments of a single organization, data privacy, data anonymization, and various other procedural and legal considerations may limit data sharing between departments. Thus, even if SE150 and PMDP130 are related, they can be considered separate entities based on data sharing, data privacy, and / or other considerations.

[0020] PMDP130 may interact with SE150 in connection with a proposed clinical trial / investigative study (e.g., involving human subjects) by providing SE150 with known drug / device profiles and safety information 132 (e.g., pharmacological information, dosage, drug interactions, safety updates, etc.), and SE150 may relay that information to HCP120. In some cases, HCP120 may directly request and receive drug / device profiles and safety information 132 from one or more PMDP130s (e.g., when multiple drugs / devices are being clinically evaluated).

[0021] SE150 may also store approved protocols 129 as part of the clinical trial record (CTR) database 185. In addition, SE150 may also acquire clinical trial information 123 during the trial, which may be used to determine efficacy, etc. SE150 may also monitor the trial (at the start) to ensure compliance with clinical procedures and approved protocols 129. The IRB associated with the trial may also receive periodic patient data regarding patient inclusion / exclusion, provide input on the patient pool, and / or determine feasibility based on actual patient recruitment to recruitment targets. Clinical trial-related information may also be stored by SE150 in the CTR database 185.

[0022] SE150 may further select candidate patients who match a certain demographic profile 134. For example, SE150 may look for patients who have a demographic profile 134 such as (a) having one or more primary medical conditions (e.g., hypertension) and / or (b) not having one or more secondary medical conditions (e.g., not having heart disease), and / or (c) being within a certain age group (e.g., 40-55 years) and / or (d) being of a specific sex, (e) being of a certain race or ethnicity and / or (f) living in a designated area (e.g., zip code) and / or (g) being employed in a specific occupation and / or (h) having a specific lifestyle (e.g., non-smoker). The above demographic profiles and categories are merely examples, and profiles can vary significantly from trial to trial (e.g., for trials of different drugs / devices, or for different phases of trials of the same drug / device).

[0023] Therefore, SE150 may transmit demographic profile information 134 to another entity, such as one or more healthcare providers (HCPs) 120, which can assist in the initial selection or pre-screening of candidate patients 124 that appear to match the demographic profile 134 for the clinical trial. HCP 120 may refer to any healthcare provider or an organization with multiple healthcare providers. For example, PI 120 may need to manually select potential candidate patients, contact them, and obtain initial approval before providing any candidate patient information 124 to PMDP 130. Upon receiving approval, information on candidate patients 124 from one or more PIs 120 may be transmitted to SE150, and SE150 may determine several eligible patients 127 and provide PI 120 with information including instructions for the eligible patients 127. PI 120 may then contact the eligible patients 127 to obtain their consent to participate in the clinical trial. Candidate patients who then agree to participate in the clinical trial and are accepted by SE150 can form the selected patients 127.

[0024] Therefore, information regarding each of the eligible patients 127 (who consent to participate in the clinical trial) may be transmitted by the HCP 120 to the SE 150. The SE 150 may further screen the eligible patients 127 who consent to participate and respond to the HCP 120 with the selected patients 127. The exchange of information between the HCP 120 and the SE 150 may continue until the SE 150 determines that the number of selected patients 127 is appropriate for the clinical trial. The number of patients for the clinical trial may be determined during the exchange of proposed clinical trial procedure information 129 between the HCP 120 and the SE 150. In some cases, the SE 150 may receive input from the PI 120 and / or a statistical professional to ensure that the data obtained during the clinical trial are statistically relevant. Furthermore, the IRB associated with the clinical trial may also receive periodic patient data regarding patient inclusion / exclusion, provide input regarding the patient pool, and / or determine feasibility based on actual patient recruitment for the recruitment target.

[0025] At the start of the trial, a SE150 (and / or other entity / subentity) with specific responsibilities may monitor the trial to ensure that it complies with approved trial procedures and protocols. During the trial, an HCP / PI120 may monitor patients, administer therapy, and record patient trial information123. For example, an HCP / PI120 (and / or another entity such as a DSMB associated with the trial) may monitor trial-related procedures such as administering the correct dose and storing drugs at the correct temperature, and may monitor and report patient-related trial information129 (e.g., patient health parameters and other relevant information) to a PMDP130. Patient health information, trial procedure information about prescribed drugs / devices, etc., may be stored in a health information (HI) database125.

[0026] In some cases, SE150 (e.g., an entity contracted with PMDP130, and / or a department of PMDP130) may pay HCP120 and the enrolled patients (drug trial participants), and may also reimburse patients and HCP120 for costs incurred in connection with the trial. In some circumstances (e.g., when the drug / device is administered on a compassionate basis), for some selected patients127, HCP120 may also obtain and / or determine patient insurance and treatment information123 based on an HI database125 that may be maintained by HCP120. For example, an insurance provider may authorize treatment for some patients in certain circumstances.

[0027] HCP120 may also transmit treatment information 123 to a drug provider and / or medical device provider (PMDP) 130, which may respond with a drug / device profile and safety information 132 regarding the administered drug / device. The drug / device profile and safety information 132 may be stored in the HI database 125. The trial information 123, which may include treatment information transmitted to PMDP 130, may also be edited by HCP120 to remove any personally identifiable information (PII).

[0028] Personally identifiable information (PII) is any data that may be used to identify a particular individual. The term “non-PII” is used herein to refer to information that does not contain PII. For example, a patient data record (with PII) may include the patient’s name, full address, and other identifiers (e.g., insured person number, driver’s license number, social security number, and / or other identifying information) along with health-related information. A non-PII patient data record (without name, full address, and other identifying information) can be obtained by removing PII from a patient data record. For example, a non-PII patient data record may include age, sex, medical history (e.g., medical conditions the patient has, other medications the patient is using, etc.), treatment, and optionally (e.g., where appropriate), city, state, and / or zip code, and may also include the full address of the HCP120 to which care was delivered.

[0029] PMDP130 may transmit known drug / device profiles and safety information 132 to HCP120 based on information in the drug / device information record (DIR) database 135 regarding drugs / devices in the clinical trial. The DIR database 135 may include drug / device profiles and safety information 132. Furthermore, drug / device profiles and safety information 132 may include information on drug properties such as dosage, method of administration, absorption, metabolism, duration of action, toxicity, and interactions with food or other pharmaceuticals. Upon receiving the drug / device profiles and safety information 132, HCP may prescribe one or more drugs and / or medical devices in the clinical trial in appropriate doses (for example, as received from PMDP130 and / or based on treatments specified as part of clinical trial procedure information 129). For example, in a clinical trial evaluation comparing multiple drugs, the dosage and other information for drug-l may be specified in the clinical trial procedure information 129, whereas the dosage and other information for drug-m (l≠m) may be obtained from one or more PMDPs 130 as drug / device profiles and safety information 132.

[0030] As shown in Figure 1, in some cases (e.g., when a drug / device is administered on an emergency / compassionate basis), HCP120 may also securely transmit the patient's insurance and treatment (e.g., medical procedure-related) information126 to the payer / insurance company (hereinafter, "payer")140. The payer 140 may be an insurance company (e.g., when a drug / device is administered on an emergency / compassionate basis). In other circumstances (e.g., when a patient is paid for participation in a clinical trial), the payer 140 may be a division of SE150 or an agency contracted by SE150 to make payments to the patient at specified intervals and / or upon completion of specific tasks / milestones. SE150 and payer 140 are shown as separate entities in Figure 1 and will be described as such herein. As outlined earlier, whether SE150, PMDP130, and / or payer 140 form divisions of a single organization, data privacy, data anonymization, and various other procedural and legal considerations may restrict data sharing between divisions. Therefore, even if SE150, PMDP130, and / or Payer140 are involved, they can be considered separate entities based on data sharing, data privacy, and / or other considerations.

[0031] Therefore, patient insurance information 126 may be transmitted to the payer 140 in the event that the drug is being used for treatment (e.g., on compassionate or emergency use) before the drug is fully approved. Patient insurance information 126 may include patient ID and proposed treatment (e.g., prescribed drugs and / or devices). Patient insurance and treatment information 126 may include patient identification (ID) information, insurance plan information, group ID information, and proposed treatment information (e.g., one or more of the following: medical procedure-related information, drug-related information, medical device-related information, etc.). Insurance-related and treatment information 126 may include some personally identifiable information (PII), but the PII information shared may be limited. For example, regulations may indicate that patient insurance and treatment information 126 does not have to include the patient's family history and / or other patient information (which may be part of the HI database 125) that is not relevant to determining insurance coverage according to the present invention and / or not relevant to cost determination if shared with the payer 140.

[0032] Where approval is required (for example, when a drug / device is administered on an emergency / compassionate basis), payer 140 may compare the received patient coverage-related information 126 with the information in the plan / coverage database 145 to determine the coverage for the patient. Based on that coverage information, payer 140 may update the plan / coverage information database 145 and respond to HCP 120 with confirmation and / or additional / updated patient coverage-related information 142. Coverage-related information may include coverage information related to the proposed treatment, as well as cost and payment-related information such as the patient's co-payment and billing code. If payer 140 approves the proposed investigational treatment, HCP 120 may initiate the treatment and update the information in the HI database 125. In response to this, if payer 140 withholds approval, and / or the scope of the proposed treatment is insufficient, and / or the patient does not meet the cost criteria, patient enrollment in the clinical trial may be considered by SE150, which may lead to further information exchange among entities (e.g., patient, HCP120, SE150, and / or patient). For example, SE150 may choose to (a) pay the costs (associated with emergency / compassionate use) and / or enroll the patient in the clinical trial (e.g., if enrollment is open and the patient meets the enrollment criteria).

[0033] In other circumstances, such as when payments are made for patient enrollment in a clinical trial, SE150 and payer140 may share contract and participant payment information145 in order to pay clinical participants and / or reimburse patients for costs. In addition, some PII information may be transmitted to payer140 (which may be, for example, a division of SE150), and PII information may be used for tax, accounting, and / or financial purposes. However, in the above circumstances (when patients enrolled in a clinical trial are paid), payer140 cannot receive medical treatment or other patient health-related information for privacy, legal, and other reasons.

[0034] Therefore, conventional healthcare information systems have several shortcomings. Each entity acquires and maintains information that may be relevant to operating its business, but only a very small portion of that information can be shared (for example, due to legal, privacy, procedural, and / or business considerations), and when information is shared, it may be fragmented, out of context, out of time, and not useful for decision-making / planning purposes. For example, HCP120 and / or patients may not have cost information related to investigational treatments at the time of patient enrollment. As another example, if a drug adverse event 121 is reported to SE150 and / or PMDP130 by an entity (e.g., HCP120 or patient), verification of the drug adverse event may often be performed by another entity to determine whether the adverse event is attributable to the drug / device under investigation. Verification that may involve additional entities could introduce additional complexity, potentially further delaying reporting and / or creating additional storage, thereby impacting the timeliness and / or usefulness of the information (for example, SE150 and / or PMDP130).

[0035] In addition, because the information is compartmentalized and may be provided based on ad-hoc criteria, aggregating the received information together with the information stored by the receiving entity can be cumbersome. Furthermore, because each entity may index the information differently, it can be difficult for the receiving entity (or transmitting entity) to link the received (or transmitted) information to the information records stored by the transmitting entity (or stored by the receiving entity). For example, if HCP120 provides drug adverse event information 121 to PMDP130 at some point, even if that information could be legally shared, it may be difficult for HCP120 and / or PMDP130 to obtain additional patient information or patient condition information that may be related to the drug adverse event.

[0036] While the use of blockchain for storing health-related information typically facilitates ensuring the integrity and authenticity of stored information, traditional technologies fail to address the challenges posed by data sharing or movement between entities in an environment where transactional and regulatory complexity increases, such as maintaining data privacy, while information compartmentalization decreases. Furthermore, traditional methods also fail to guarantee the timely availability of information (e.g., to one or more entities in compliance with legal and regulatory obligations) to facilitate transaction completion. Moreover, traditional methods do not guarantee that entities have a consistent and coherent view of completed transactions. The lack of a consistent and coherent view of completed transactions across entities can constrain the pursuit of improved interoperability, data utilization, and operational efficiency. In addition, limitations on interoperability often limit the ability of customer-centric organizations to function, as it can be difficult to address requests from customers (e.g., patients) to provide information to support or enhance decision-making (e.g., independently or in conjunction with HCPs).

[0037] The disclosed embodiments promote the integrity and interoperability of healthcare systems, while also enhancing the security of healthcare systems and promoting transparency of healthcare costs. Several disclosed techniques facilitate the timely exchange of appropriate data (e.g., at the time of the transaction) (e.g., in compliance with legal, privacy, and business guidelines) to the appropriate entities (e.g., authorized entities associated with the transaction) to accelerate patient enrollment and / or drug / device deployment, while simultaneously facilitating consistent and consistent information access across healthcare market entities.

[0038] Interoperability is facilitated partly because multiple entities involved in a transaction may be able to link the appropriate relevant information shared during the transaction to the completed transaction using agreed-upon criteria. Consistency and integrity are facilitated because locally recorded data (e.g., locally on an entity) can correspond to criteria data (e.g., maintained on a shared platform), and each entity's view of the criteria data (or a portion of the criteria data accessible by an entity) is consistent with another authorized entity's view of the data (and / or locally recorded data on other authorized entities). In some embodiments, the criteria data may be based on and / or take the form of a distributed ledger. In some embodiments, the distributed ledger may be accessible to authorized entities, and each entity's view of the distributed ledger may comply with legal, privacy, business, and / or contractual obligations. Furthermore, efficiency is improved because information relevant to decision-making becomes available to entities early in the transaction cycle to facilitate early consideration of alternatives, thereby reducing the potential for inefficiencies associated with transaction completion and reducing the need to re-make decisions.

[0039] In some embodiments, a first entity (e.g., SE150 and / or PMDP130) may receive at least one encrypted first electronic health record (EHR) subblock (e.g., for a patient) that can be decrypted by the first entity. The first EHR subblock(s) may include patient health insurance coverage information about the patient and one or more first treatments (e.g., proposed drugs and / or devices indicated by F_p(1≦p≦P)). The encrypted first EHR subblock may be received (e.g., by SE150 and / or PMDP130) along with a transaction ID for the current transaction and may not include PII information about the patient.

[0040] In some other cases (for example, when authorized to determine payments to patients and / or HCP120 for a clinical trial program, and / or when SE150 and / or PMDP130 determine or use patient eligibility), the encrypted first EHR subblock may be received (e.g., by SE150 and / or PMDP130) along with the transaction ID for the current transaction, and may further include PII information about the patient. In situations where patient PII information is received (e.g., by SE150 and / or PMDP130), SE150 and / or PMDP130 may make payments and maintain patient privacy on behalf of SE150 and / or PMDP using a locally maintained blockchain consistent with the disclosed embodiments, so that access to patient PII information is restricted to program administrators and / or authorized personnel. Authorization to provide PII information may be obtained prior to the transaction involving the sharing of patient data, or may be pre-authorized by the patient (e.g., at the time of registration with HCP120, SE150, PMDP130, or another entity). In some embodiments, the first EHR subblock may further indicate that the patient has provided consent to the use of the information within the first EHR subblock for determining eligibility to participate in the clinical trial.

[0041] A first entity (e.g., SE150 and / or PMDP130) may determine a patient's eligibility to participate in at least one clinical trial associated with at least one medical product (e.g., a drug and / or device) based on (a) a first EHR subblock received and (b) a clinical trial record (CTR) containing one or more approved protocols, each of which is associated with a corresponding clinical trial for a corresponding medical product. For example, SE150 and / or PMDP130 may determine patient eligibility by comparing the patient's medical history, demographic information in the first EHR subblock received (e.g., age, sex, etc.), and approved protocol information in a clinical trial record (CTR) for a medical product that is undergoing a clinical trial and is currently enrolling new patients.

[0042] The first entity (e.g., SE150 and / or PMDP130) may transmit, based on the determination of patient participation eligibility (e.g., if the patient is determined to be eligible to participate in at least one clinical trial), at least one encrypted CTR subblock containing at least one approved protocol associated with at least one clinical trial, and at least one encrypted device / drug information record (DIR) subblock corresponding to at least one medical product associated with at least one clinical trial. For example, SE150 and / or PMDP130 may transmit (a) a CTR subblock for one or more approved protocols, each of which is associated with a corresponding clinical trial in which the patient has been determined to be eligible, and (b) a corresponding encrypted device / drug information record (DIR) subblock for one or more corresponding medical products associated with one or more clinical trials for each transmitted CTR subblock.

[0043] The first entity may, in response to the transmission, receive an encrypted second EHR subblock decryptable by the first entity, which includes patient profile information, patient consent to participate in at least one clinical trial, at least one second diagnostic code, and at least one second treatment code. For example, patient consent may be obtained after an HCP120 (e.g., a clinical trial coordinator or PI120) has advised the patient about the trial. A patient interested in the trial may provide consent. Thus, a patient may (in consultation with an HCP120) provide explicit consent to participate in one or more clinical trials. The second EHR block may also include one or more second diagnostic codes associated with the condition being treated, and one or more treatment codes associated with the drug / device being used for treatment. Some of the drugs / devices in the received EHR subblock may be part of at least one clinical trial.

[0044] The first entity may extend the multidimensional blockchain with multidimensional blocks when it receives a transaction block having transaction confirmation. The multidimensional block may be formed by linking (i) a transaction block containing patient profile information, patient consent, and at least one clinical trial and at least one corresponding approved protocol, (ii) a DIR block containing medical information associated with at least one medical product, and (iii) an EHR block containing information associated with a second EHR subblock. In some embodiments, the first entity may also extend a locally maintained blockchain with appropriate information regarding the clinical trial. The information in the blocks added by the first entity to the locally maintained blockchain may correspond to the information associated with the multidimensional block.

[0045] Some of the disclosed embodiments may also be used to effectively deploy medical products. For example, in situations where an emergency exists (such as an epidemic, pandemic, or localized medical emergency affecting a portion of a population), it may be useful and effective to deploy medical products (e.g., vaccines / drugs, if availability is limited and / or production is being scaled up before they are fully available) to a portion of a population determined to be at higher risk (e.g., one or more of the following: healthcare professionals, frontline workers, age groups, occupations, people with specific medical conditions, people living or working in a particular area, people who have contracted the disease, etc.). For example, a government agency or public health entity (hereinafter referred to as "PHE") may determine criteria for the deployment of a therapy, and the disclosed embodiments may facilitate deployment based on those criteria.

[0046] In some embodiments, a protocol for drug deployment in an emergency may be designated and / or mandated by a government / public health agency to effectively address the emergency and deploy resources (e.g., vaccines / drugs) to achieve a favorable outcome (e.g., control the spread of an outbreak). Thus, in some embodiments, a first set of health parameters and aggregate demographic information associated with one or more population segments may be obtained (e.g., in a first entity such as a pharmacy from PMDP130 and / or a public health agency). For example, the first set of health parameters may be associated with a population at risk or affected / infected.

[0047] Furthermore, the first entity may receive one or more encrypted electronic health record (EHR) subblocks that can be decrypted by the first entity, the one or more first EHR subblocks containing patient profile information for one or more patients and corresponding patient medical history for one or more patients. For example, PMDP130 may receive one or more encrypted EHR subblocks from HCP120, which intends to prescribe a particular product (e.g., a vaccine or drug to treat or protect against certain infections) to a patient, to determine the eligibility of patients to receive the drug / device.

[0048] In some embodiments, the first entity may determine a subset of eligible candidate patients from one or more patients who are eligible for at least one treatment, based on a comparison of information in one or more EHR subblocks with corresponding eligibility criteria, the corresponding eligibility criteria being based on one or more of a first set of health parameters or aggregate demographic information. For example, the first entity may determine a set of eligible candidate patients (which may be a subset of the set of candidate patients) who are eligible to receive a drug / vaccine, based on demographic information or health parameters received from a public health agency.

[0049] The first entity may further transmit one or more encrypted first subblocks that can be decrypted by one or more corresponding second entities, each of which the first block transmitted includes at least one eligible candidate patient profile and corresponding medical information associated with at least one treatment. For example, the first entity may transmit eligible candidate patient profiles for a subset of eligible candidate patients, based on the corresponding eligible candidate profile (of the patient to be treated), and medical information associated with at least one treatment (e.g., drug / vaccine) (e.g., dosage, drug interactions, contraindications, etc.).

[0050] The first entity may extend the multidimensional blockchain with multidimensional blocks in response to receiving a transaction block having transaction confirmation. The multidimensional block may be formed by linking (i) a transaction block containing treatment deployment-related information, (ii) a drug device information (DIR) block containing medical information associated with at least one treatment, and (iii) an EHR block containing patient profile information, medical history, and prescription information for at least one treatment. In some embodiments, the first entity may also extend a locally maintained blockchain with appropriate information regarding treatment deployment. The information in the blocks added by the first entity to the locally maintained blockchain may correspond to the information associated with the multidimensional block.

[0051] The term "subblock" refers to a portion of a data record or block that, when encrypted, can be decrypted by a particular entity(s) (but not by other entities). In the diagram, subblocks are shown as dashed boxes. Information within a subblock(s) decrypted by a particular entity(s) may be incorporated into a data record(s) (or data block(s) in the blockchain) maintained by that particular entity(s) when the transaction is completed. For example, a transaction with transaction ID U may involve entities A, B, C, and D, each of which may own data records W, X, Y, and Z in a multidimensional blockchain. In the above example, data record W (owned by A) associated with transaction U may be encrypted by the owning entity A (but not by other entities) and may be readable. However, data record W may also contain portions of information in other data records (e.g., data records X, Y, and / or Z that are not readable by entity A) in addition to transaction ID U. For example, data from one or more other data records (e.g., data records X, Y, and / or Z) existing within W may be received (e.g., by entity A) as a decryptable subblock before the transaction is completed. Similarly, other entities B-D may also contain transaction-related information existing in data records they do not own (in addition to transaction ID U). For example, for entity B, information existing in one or more of data records W, Y, and / or Z may be received by entity B in the form of a decryptable subblock before the transaction is completed. Thus, each entity A, B, C, and D may maintain a separate and independent blockchain containing data records W, X, Y, and Z (for transaction U) as blocks within their respective blockchains.The data records (or blocks) W, X, Y, and Z associated with transaction U can also collectively form multidimensional blocks within a multidimensional blockchain. Thus, a consistent and coherent viewing of the transaction is available to all market entities that may be associated with the transaction, while maintaining compliance with legal, privacy, and / or other regulatory / business considerations and promoting data integrity.

[0052] As used herein, the term “blockchain” refers to a record or “information block” or “block” that is linked together using cryptographic techniques. Each block contains the cryptographic hash, timestamp, and transaction data of a preceding block. The current block being added to the blockchain is also called the head of the blockchain. A cryptographic hash function maps data of any size to a fixed-size bit sequence called a “hash.” A hash function may be deterministic (the same input will produce the same output) or one-way (i.e., it is impossible to reverse the hash value to determine the original data that was input). The transaction data of a block can be represented as a Merkle tree root hash. The terms “Merkle tree” or “hash tree” are used to refer to a tree where all leaf nodes are labeled with a hash of the transaction data, and each non-leaf node is labeled with a cryptographic hash of the label associated with its child node. The block header of a block being added to the blockchain may include a hash criterion for the preceding block header and a hash criterion for the root of the Merkle tree containing the transaction data. Blockchain promotes data integrity because any changes to data within the blockchain result in a mismatch in one or more hash criteria. The terms record or data record are also used to indicate non-final data that is intended to be added to the blockchain. Once a data record is verified and finalized, it can be added to the blockchain and form a block within it.

[0053] The term "multidimensional blockchain" is used to refer to a set of multidimensional records (also called multidimensional blocks), in which case each multidimensional record contains two or more data records. In some cases, each of the data records that can be considered to form a dimension of a multidimensional blockchain can also form a block in a separate blockchain associated with a certain entity. Thus, in some embodiments, a multidimensional block can contain data records in each dimension, in which case the data records corresponding to the dimensions can form a block in a separate conventional blockchain associated with the corresponding entity. For example, a multidimensional block may contain EHR data records as one dimension, DIR data records as another dimension, and transaction data records as a third dimension. Furthermore, in some cases, EHR data records associated with a multidimensional block (within a multidimensional blockchain) can form a block separately in a separate EHR blockchain (i.e., separate from the multidimensional blockchain). Similarly, in some cases, DIR data records and transaction data records associated with a multidimensional block can form blocks in a separate DIR blockchain (e.g., associated with PMDP130) and a transaction record blockchain (e.g., associated with payer140), respectively. Therefore, in some cases, data records in the context of a multidimensional blockchain can correspond to blocks in a separate conventional blockchain. In some cases, each data record in a multidimensional block (e.g., associated with a dimension) can correspond to, form part of, and / or derive from, a corresponding block in a separate conventional blockchain. A multidimensional block can include preceding multidimensional blocks, timestamps, and cryptographic hashes of the data. The data in a multidimensional block can include hashes of the individual data records that make up the multidimensional block.In some embodiments, an agreement mechanism between entities can be used to verify the validity of the data within a proposed multidimensional block before the multidimensional block is constrained and locked.

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

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

[0056] Figure 2 shows an exemplary electronic health record (EHR) 200, with several exemplary data fields within the record represented. In some embodiments, the EHR 200 may contain information about a patient and may be owned and maintained by an HCP 120 (e.g., in the HI database 125). In some embodiments, the data fields in the EHR 200 may be stored and / or updated by the HCP 120, in part, based on information received from the patient. The EHR 200 may also contain data received from other entities such as the PMDP 130 and / or SE 150 and / or payer 140 (e.g., as subblocks 380, 480, 580, etc.). In some embodiments, the EHR 200 may include subblocks from other entities such as the Data Safety Monitoring Board (DSMB) subblock and the Food and Drug Administration (FDA) subblock (not shown in Figure 2). The DSMB subblock may contain, for example, information associated with the DSMB. The DSMB may periodically review the trial data to ensure the safety of the study subjects, as well as the validity and completeness of the data. The DSMB may review and evaluate the accumulated trial data for participant safety, trial execution and progress, and / or efficacy. The DSMB may also designate event triggers that will require unscheduled reviews to halt procedures that conflict with approved protocols. Similarly, the FDA subblock may include information for the FDA and / or other regulatory bodies overseeing the trial and / or the agency that approved the protocol for the trial. The fields shown in EHR200 are illustrative only, and EHR200 may include various other additional fields based on laws, standards, HCP practices, and / or industry practices, etc. The EHR may include different (fewer or more) fields than those shown in relation to the illustrative EHR200. Subblocks 380, 480, and 580 are indicated by dashed blocks to indicate that information received from the blocks may be integrated into EHR200.

[0057] The EHR200 may be associated with an HCP profile field 295 that can store information about the HCP120 (e.g., HCP identification, registration and / or license information, address, associated medical professional, medical professional identification / registration information, etc.). In some embodiments, some or all of the information in the HCP profile 295 may be shared with other entities related to the transaction. For example, a portion of the HCP profile 295 may be sent to one or more entities such as the PMDP130, payer 140, and / or SE150 (e.g., as part of an encrypted subblock 280 that may be decryptable by a designated receiving entity).

[0058] As another example, as shown in Figure 2, the EHR 200 may include basic profile information 230 about the patient, which may change relatively rarely. The basic profile information 230 may include patient name 204, patient ID 202, family history 205, date of birth (DOB) 220, blood type 225, etc. Family history 205 may include maternal medical history 210 and paternal medical history 215. The basic profile information 230 may also include medical history 232, which may include information about other past or current medical conditions associated with the patient.

[0059] In some embodiments, a portion of the basic profile information 230 can be considered PII information (e.g., patient name 204, patient ID 202, etc.). In some cases, such as when a patient consents to pre-screening for participation in a clinical trial and / or when a patient consents to the use of patient-related information for drug / device deployment, a portion of the basic profile information (e.g., patient age, patient medical history 232, blood type 225, family history 205, patient zip code, etc.) may be shared with another entity as non-PII information within a first subblock 280 (i.e., without information that uniquely identifies the patient, such as patient name 204, date of birth 220, patient ID 202, etc.) (limited, for example, to 280-1 without PII information). If a patient is selected as a candidate (for example, for a clinical trial and / or drug / device deployment), additional patient consent (if not already granted) may be obtained in accordance with applicable laws / regulations before distributing patient PII information within subsequent subblocks 280 (including, for example, 280-2), which may be used to monitor the patient during the trial and / or schedule the patient to receive prescribed drugs / devices during deployment.

[0060] EHR200 may further include other data fields such as diagnosis 235 (for example, for a current disease), diagnostic code 240 (which may be a standardized diagnostic code for diagnosis, e.g., an International Classification of Diseases (ICD) code), treatment code 245 (which may be a standardized diagnostic code for describing treatment, e.g., a Current Procedural Terminology (CPT) code), and prescription code 250 for each prescription that may function to uniquely identify each prescription. Prescription code 250 is also referred to herein as prescription 250. ICD includes fields for diagnosis and medical procedures. For example, the FDA maintains a “dictionary” for specific drugs, with each drug assigned a distinct number. Furthermore, each dose of the same drug may be assigned a distinct identification number. Thus, drugs, doses, and procedures can be uniquely identified from the ICD code.

[0061] In some embodiments, the prescription code 250 (for prescriptions) may further include one or more subfields, such as the prescription drug field 255-p, 1 ≤ p ≤ P (e.g., drug ID and / or classification product code (CPC) for medical devices), dose 260-p (intensity and frequency), and duration 265-p (length of time the drug is taken), (e.g., for each drug / device prescribed in the prescription). In some cases, the EHR 200 may also include other fields and / or subfields, such as an indication of whether the prescription is a new prescription or a supplement. The EHR 200 may also include an adverse reaction field 262-p, such as a Medical Device Report (MDR) adverse event code, or another (e.g., ICD-10) code for documenting drug side effects. In some embodiments, the adverse reaction field 262-p may be transmitted as part of subblock 280 to SE150 and / or PMDP130 (e.g., if the patient is participating in a clinical trial) and / or to PMDP130 (e.g., if prescribed as part of a drug / device deployment). EHR200 may also include patient criteria 297 which can specify one or more criteria for drug / device selection and / or cost items or cost criteria that may be provided by the patient. For example, patient criteria 297 may specify preferred method of administration if available (e.g., topical, ingestion, inhalation, etc.), area or location where the prescribed drug / device is available, patient cost considerations, etc. For example, patient criteria 297 may be used during a pre-screening process for a clinical trial or to determine the method of administration of the prescribed drug 255-p (e.g., ingestion, topical, etc.).

[0062] In some embodiments, the EHR 200 for a patient may be stored as a blockchain by, for example, an HCP 120. In some embodiments, information related to a transaction between the HCP 120 and the patient and / or another entity may form part of an EHR information block in the EHR blockchain. When an EHR block associated with a transaction is stored on the blockchain, the stored information may, in some cases, be associated with a transaction ID 695 that can function to uniquely identify the transaction. In some embodiments, the transaction ID 695 may be common to the entities associated with the transaction (for example, all entities associated with the transaction may use the same transaction ID). In some embodiments, a transaction initiator and / or a component of a permissioned blockchain platform may provide transaction information, such as the transaction ID 695, to one or more entities associated with the transaction. Thus, subblocks sent or received by an entity can be identified as associated with a transaction and processed appropriately. In some embodiments, the format and content of the transaction ID 695 may be predetermined and / or agreed upon by the entities associated with the transaction platform and / or provided by the transaction platform. Other transaction information-related fields (not shown in Figure 2) may include a transaction type, which is used by the entity to determine and process the information in the transmitted and / or received subblocks and to determine an appropriate response. For example, the transaction type may indicate that subblock 480-1 is provided (e.g., by SE150) to specify parameters associated with the prescription of a drug / device in a clinical trial (e.g., prescribed drug / device, dose, duration, etc.).These parameters may then be used (e.g., by HCP120) to add and / or update corresponding parameters in EHR 200 (e.g., prescription drug / device 255-p, dose 260-p, duration 265-p, etc.). The above parameters (e.g., prescription drug / device 255-p, dose 260-p, duration 265-p, etc.) may be selected (by SE150) for enrollment in the clinical trial and provided (e.g., by SE150, not shown in Figure 2) once approved by SE150 and the patient.

[0063] In the following description, if the EHR is maintained as a blockchain (e.g., by HCP120), the EHR information record 200 may also be referred to as an EHR block 200. Thus, an EHR block 200 can form a block within the EHR blockchain. If an EHR block 200 can be added to the EHR blockchain, some data within the EHR block 200 being added to the EHR blockchain may depend on other entities. For example, as outlined above, the prescription drug / device 255-p, dose 260-p, and duration 265-p may be provided to subblock 480-1 by SE150 at the time of patient selection and approval for the clinical trial. As another example, a treatment (e.g., specified by treatment code 245 for a diagnosis described by diagnostic code 240) may also be subject to approval by payer 140 (not shown in Figure 2) and may be included as part of the EHR at the time of approval. As a further example, before EHR block 200 is added to the EHR blockchain, a drug warning label (not shown in Figure 2) that may form part of EHR block 200 may use input from PMDP130 (e.g., received and located in subblock 380) to complete, verify, and / or update the information on the warning label.

[0064] In some embodiments, patient criteria 297, diagnosis 235, diagnostic code 240, treatment code 245, and prescription code 250, together with the prescribed drug / device 255-p, dose 260-p, and duration 265-p (1 ≤ p ≤ P) data fields, may form a portion of subblock 280. In some embodiments, at the time of approval (by SE 150 and the patient), subblock 280 may further include PII information (280-2), such as one or more of basic profile information 230, patient insurance coverage-related information 272, and / or plan ID 270, the PII information may have the function of identifying the insurance plan the patient is enrolled in (e.g., health insurance plan, drug benefit plan, prescription coverage, etc.). In some embodiments, (depending on the circumstances, applicable laws, and / or patient authorization) subblock 280 may also contain some or all of the information in subblocks 280 (280-1 and 280-2) and / or 282 as described herein (e.g., at an appropriate time during the transaction process). Some or all of the information in subblocks 280 and / or 282 may be shared with one or more other entities (e.g., payer 140 and / or SE 150, etc.) and may form part of other records / blocks associated with the transaction.

[0065] Prescription 250 may include one or more prescription drugs / devices 255-p, 1 ≤ p ≤ P, where P represents the number of drugs associated with prescription 250. Thus, in some embodiments, subblock 280 may include a record for each of the prescription drugs / devices 255-p within prescription 250. Subblock 280 is merely an example illustrating some information that may be shared with another specific entity. For example, subblock 280, or a portion thereof (e.g., 280-1), may also be encrypted by HCP 120 and transmitted to PMDP 130 (without patient PII information in 280-2, for example, to obtain safety information and other information), and may be decryptable by PMDP 130.

[0066] In general, information in any appropriate field or combination of fields within a data record or block may be aggregated into a subblock, which may be encrypted (e.g., by the first entity) so that it can be decrypted by some other specific entity(s) (e.g., one or more second entities). The encrypted subblock may be sent (e.g., by the first entity) to one or more other designated entities (e.g., one or more second entities), which may decrypt the received information and function appropriately (e.g., based on the transaction type). Information used by a first entity to form subblocks from data records or blocks within a locally maintained blockchain (e.g., an EHR blockchain) and shared with another (second) entity may depend on regulations (e.g., healthcare and / or privacy), laws governing information sharing (e.g., which may determine what information can or cannot be shared between certain entities), business guidelines (e.g., which may stipulate the sharing / protection of trade secrets or confidential information), and / or contractual obligations and / or agreements (e.g., between or relating to entities sharing information) (e.g., as part of a subscription to an electronic transaction platform).

[0067] As another example, the information in subblock 282 may include coverage-related information 272, plan ID 270, co-payment information 275, etc. Coverage-related information may be used during drug deployment if the treatment is paid for by an insurance company such as payer 140 and / or if the emergency / compassionate use of the drug / therapy may be approved by payer 140 for the patient. If a drug trial is conducted and payments (e.g., to HCP 120 and trial participants) are made by PMDP 130, some subblocks (e.g., subblock 282) may be omitted. As outlined earlier, the number of subblocks may depend on the transaction type and the entities involved. Some information within subblock 282 may have been obtained directly from the patient, if present, while other coverage-related information may have been obtained from and / or confirmed by payer 140 in connection with the transaction specified by transaction ID 695 (e.g., to determine covered costs associated with compassionate use or administered during drug / device deployment), and decrypted by HCP120 (e.g., based on one or more encrypted subblocks received from the appropriate entity and decrypted by HCP120, which are not shown in Figure 2). For example, the transaction type may indicate that subblock 282 is provided to obtain, confirm, or complete coverage-related information 272 in connection with compassionate use, or administered during drug / device deployment for prescription drug / device 255-p.

[0068] Furthermore, depending on the circumstances, a portion of the EHR information 200 (e.g., 280-1), such as basic profile information 230, DOB 220, blood type 225, and some (e.g., non-PII) portions of medical history 232, may be encrypted by HCP 120 as subblock 280 and transmitted to SE 150 and / or PMDP 130 after pre-screening the patient for trial eligibility related to one or more drugs / devices. SE 150 and / or PMDP 130 may then decrypt the subblock 280 related to the transaction specified by transaction ID 695 (e.g., to determine whether the patient meets the criteria for enrollment in the trial) and / or to determine patient / HCP payment (after patient approval) if the patient is selected for the trial. As a further example, the portion of the basic profile information 230 (e.g., 280-1) contained in subblock 280 may be non-PII related to the patient (e.g., excluding name, identification number, etc.). Therefore, medical information can be securely shared with another specific entity (for example, to determine adverse reactions, medical device malfunctions, etc.) without compromising patient privacy. In another example where the disclosure of PII information is permitted and authorized (e.g., by the patient), the subblock may contain PII information (e.g., 280-2 and / or 280-1), and as a result, SE150 and / or PMDP130 can determine patient eligibility for payment assistance, or report events, including adverse reactions 262-p, other health parameters, and / or other outcomes, during the clinical trial or during drug / device deployment in connection with prescription fulfillment (to establish patient identification). For example, (depending on the context, transaction type, applicable law, and / or patient authorization), some or all of the information present in 280-1, 280-2, and / or 284 may be incorporated into subblock 280.

[0069] As a further example, data within subblock 280 may be shared by an entity such as HCP120 with another healthcare market entity such as payer 140 to complete a transaction. However, patient profile information associated with basic profile information 230 (e.g., family history 205, maternal medical history 210, and / or paternal medical history 215) can be considered private (e.g., based on patient instructions / privacy, legal and / or business guidelines), and the first entity (e.g., HCP120) may not share family history 205, or may limit the portion of basic profile information 230 that is shared. In another example, the non-PII portion of subblock 280 may initially be shared by an entity such as HCP120 with another healthcare market entity such as SE150 during pre-screening to determine a patient's eligibility to participate in the clinical trial, and thereafter (for example, when patients for the trial have been selected by SE150 and after patient consent to participate in the trial has been secured), the subblock 280 shared with SE150 may include patient PII information.

[0070] Therefore, in some embodiments, the data used to form subblocks transmitted by an entity or received from another entity may both depend on the entities associated with the transaction (e.g., HCP120 and payer140, or HCP120 and SE150), the current transaction status (e.g., whether a patient has been pre-screened or has already been selected to participate in a clinical trial and / or has given approval), and the context in which the data is shared (e.g., the type or nature of the transaction, e.g., reporting an adverse event, obtaining payment assistance, etc.). In some embodiments, the information interface between any two entities may depend on the transaction type, transaction status, and / or context. In some embodiments, one or more protocols (e.g., agreed / pre-configured by entities and / or set up by a permissioned blockchain platform and / or set up according to a standard) may specify the transaction type and the information present in the subblocks transmitted / received by entities for each transaction type. In some embodiments, the data fields included in the subblocks shared between entities related to a transaction type may be indicated (e.g., by a protocol and / or agreed standard) as mandatory, conditional, optional, on request, etc. These instructions (required, conditional, optional, on request, etc.) may depend on the current transaction state.

[0071] The data within a subblock (e.g., subblock 280) may be individually encrypted and decryptable only by authorized entities. In some embodiments, the encryption of the data forming a subblock (e.g., subblock 280) may be based on any suitable cryptographic scheme, which may include symmetric-key cryptography (in which case entities such as HCP120 and PMDP130 share a secret key), e.g., Advanced Encryption Standard (AES) based technology or a variation thereof. Subblock 280 may be encrypted (e.g., by HCP120) before being shared with other entities (e.g., payer 140). Other entities (e.g., payer 140) may be able to decrypt subblock 280 using, for example, a shared key.

[0072] Furthermore, the data within EHR200 may be separately encrypted by HCP120 using any secure cryptographic technique before being added to the blockchain (e.g., maintained by HCP120 and / or by the electronic transaction platform) to form EHR block 200. For example, the data within EHR block 200 may be separately encrypted using a private key (e.g., private to HCP120) so that the data is decryptable by HCP120, available to HCP120, but unavailable and / or not viewable by any other entity.

[0073] Figure 3 shows a portion of an exemplary DIR 300 for a drug that may be stored in the Drug Device Information Record (DIR) database 135. In some embodiments, the DIR 300 may include information about the drug, device, and / or treatment (e.g., drug and / or medical device). The fields shown in the DIR 300 are merely exemplary, and the DIR 300 may include various other fields based on laws, standards, industry practices, etc. In addition, the DIR may include fields that are (more or less) different from the fields shown in relation to the exemplary DIR 300. In some cases, such as when SE 150 is a division of PMDP 130, the information in the DIR record 300 may be maintained and / or provided by SE 150 during the clinical trial.

[0074] DIR300 may be associated with a PMDP profile field 395 that can store information about PMDP120 (e.g., PMDP identification, contact information, address, etc.). If SE150 is a part of PMDP130, PMDP profile field 395 may correspond to information in SE profile field 440. In some embodiments, some or all of the information in PMDP profile 395 may be optionally shared with other entities related to the transaction. For example, a portion of PMDP profile 395 may be sent to one or more entities such as payer 140 and / or SE150 (e.g., as part of an encrypted subblock, e.g., subblock 380, which may be decryptable by a specified receiving entity).

[0075] Referring to Figure 3, PMDP130 may use the information in the prescription drug / device field 255-p (received, for example, from HCP120 as part of subblock 280) to determine one or more of the following: a therapeutic area, which may be specified by the therapeutic area field 360-p, and which includes repeating instruction subfields 362-p1, 362-p2... and repeating dose subfields 364-p1, 364-p2... for the corresponding instruction; an action mechanism and / or action mode, which may be specified by the MOA field 340-p; and general chemical properties of the drug, which may be specified by the chemical data field 350-p, and which may further include subfields describing the chemical components of the drug, such as the molecular formula field 353-p and the chemical structure subfield 355-p.

[0076] Referring to Figure 3, DIR300 may also include various other data fields, including drug name 304-p for drug / device ID 302-p, efficacy 327-p (which may be a measure of therapeutic effect on a medical condition), route of administration 335-p (e.g., topical, oral, intravenous, etc.), safety 330-p (e.g., drug interactions, toxicity, contraindications, etc.), which may include adverse effect subfield 345 (e.g., secondary effects), and adverse event subfield 333-p (e.g., adverse events reported for the drug, which may incorporate adverse reactions 262-p reported by HCP120 as part of subblock 280). DIR300 may also include various other fields related to the drug / device.

[0077] In some embodiments, the drug / device ID 302-p, drug / device name 304-p, safety 330-p (and subfields), and efficacy 327-p, drug / device class 337-p, therapeutic area 360-p, instruction 362-ph (e.g., instruction 362-p1, instruction 362-p2, etc.), and corresponding dose 364-ph (e.g., dose 364-p1, dose 364-p2, etc.) may form part of subblock 380. For example, information regarding the instruction 362-ph (e.g., instruction 362-p1, instruction 362-p2, etc.) and corresponding dose 364-ph (e.g., dose 364-p1, dose 364-p2, etc.) for a drug / device under investigation may be agreed upon by PMDP130 and SE150 as part of the protocol for the clinical trial.

[0078] Therefore, the information within subblock 380 (and any other subblocks) may be pre-configured between entities, determined by a protocol, and / or specified by the platform (e.g., based on laws, regulations, authorizations, and / or contractual obligations). Thus, the information within subblock 380 (and any other subblocks) may be more or less than that shown for an exemplary subblock (e.g., exemplary subblock 380), and may further depend on the transaction type, transaction context, and the entities interacting. Subblock 380 may optionally further include administration route 335-p, MOA 340-p, chemical data 350-p, and other relevant fields / subfields. In Figure 3, the fields associated with exemplary subblock 380 are shown enclosed within a dashed outline.

[0079] The DIR subblock 380 may be provided by the PMDP 130 to another entity (e.g., HCP 120) in connection with a transaction (e.g., identified by transaction ID 695). In some embodiments, the information within the subblock 380 may be associated with a transaction (e.g., identified by transaction ID 695 and transaction type), and may be encrypted by the PMDP 120 and transmitted to another entity (e.g., HCP 120) during and / or before the transaction is completed.

[0080] In some embodiments, the DIR record 300 may be associated with a transaction (for example, specified by transaction ID 695) and, upon completion of the transaction, may be stored as a DIR block, DIR blockchain, by an entity such as PMDP 130. In the following description, if the DIR record 300 forms part of the DIR blockchain, the DIR information record 300 may also be referred to as the DIR block 300. Thus, the DIR block 300 can form a block within the DIR blockchain.

[0081] A transaction between two or more entities (e.g., patient, HCP120, PMDP130, payer140, and / or SE150) (specified, for example, by transaction ID 695) may involve information (e.g., related to a drug / device) maintained (or owned) by another entity. For example, HCP120 may request information from PMDP130 regarding a drug / device under trial or being deployed. Prior to transaction confirmation, some data that is integrated into records maintained by other entities (i.e., other than PMDP120) (e.g., maintained by PMDP130 in DIR information block 300) may depend on input from PMDP130, validation by PMDP130, and / or confirmation by PMDP130. Conversely, PMDP130 may receive input from another entity (e.g., HCP120) in the form of a subblock. Some or all of the received information may be incorporated into the DIR record 300 and / or used to determine the information within the DIR record 300.

[0082] For example, HCP120 may transmit subblock 280 (which contains, for example, non-PII information) to PMDP130. PMDP130 may use the information in subblock 280 (e.g., prescription drug 255-p) to determine the corresponding drug / device 302-p, drug / device class 337-p, retrieve the information and provide it to subblock 380, which may then transmit to HCP120. HCP120 may review the information in subblock 380 (e.g., for drug interactions, adverse events 333-p, etc.) before administering drug / device-255p (corresponding to drug / device 302-p in DIR300) and completing the prescription.

[0083] In addition, PMDP130 may save some of the information in the current (e.g., most recently received) subblock 280 as part of the DIR record 300 before transaction completion. For example, information such as diagnosis (e.g., diagnostic code 240), dosage (e.g., dosage 260), and adverse events (e.g., adverse reaction 262-p reported by HCP120) may be saved as a partial DIR record 300 and associated with the corresponding drug / device ID 302-p when it is confirmed (e.g., from HCP120) that the drug in the drug / device ID field has been prescribed (e.g., as indicated by the value of the prescribed drug field 255 in subblock 280 at transaction confirmation).

[0084] Therefore, if information related to a transaction (e.g., related to a drug / device) is requested, the owner (e.g., PMDP130) may respond by sending the information (e.g., in subblock 380) to the requesting entity (e.g., HCP120). The information (e.g., in subblock 380) may be encrypted (e.g., by PMDP130) before transmission and may be decryptable by the requesting entity (e.g., HCP120) so that the information in subblock 380 is private between the requesting entity (HCP120) and the sending entity (PMDP130). In addition, the information in subblocks exchanged between entities may be restricted so that the shared information complies with existing regulations, privacy laws, contractual obligations, and / or authorizations received from the designated owner of the information (e.g., the patient).

[0085] Therefore, in some embodiments, the data in the subblock sent to PMDP130 may be separately encrypted by the corresponding sending entity (e.g., payer-i 140-i), decryptable by PMDP130, and unavailable to unauthorized entities. In some embodiments, the encryption of the data in the subblock (received by PMDP130, for example) may be based on any suitable encryption technique, including symmetric key cryptography. The encryption may be based on a secret key shared between entities (e.g., payer 140-i identified in the payer 1 140-1 field and PMDP130). The receiving entity (e.g., PMDP130) may be able to decrypt the received subblock based on, for example, the secret shared key.

[0086] Furthermore, before being added to the blockchain, the data within DIR block 300 may also be separately encrypted by a first entity (e.g., PMDP130) using any secure cryptographic technique, so that the data is decryptable and available to the first entity (e.g., PMDP130), but unavailable and inaccessible to other entities (e.g., HCP120 and / or payer 140).

[0087] Figure 4 shows a portion of an exemplary clinical trial record 400 that may be maintained by SE150. The term SE is used to refer to any entity that plays a role in conducting the clinical trial. SE150 may have overall responsibility for communicating with PMDP130, validating the clinical trial protocol, setting parameters for screening candidate patients, enrolling appropriate patients, monitoring the progress of the trial, deciding when to terminate the trial, and analyzing the results. Clinical trial information about drug / device 255-p may be stored in CTR400. CTR400 may also contain information about protocol 404 for drug / device 255-p in the trial.

[0088] The CTR may include a protocol field 404 which may contain information about eligibility criteria 410 for a patient. Patient eligibility criteria may specify age 412 (which may be an age range), sex 414 (e.g., male), previous diagnosis 416 (e.g., any previous medical conditions), current diagnosis 418, etc. One or more of the eligibility criteria 404 may be used to pre-screen patients for the clinical trial. For example, information in subblock 280 received (e.g., from HCP120) may be compared to the corresponding eligibility criteria 410 in order to select candidate patients for enrollment. In some embodiments, eligibility criteria 480-1 may be shared with HCP120 to facilitate pre-screening by HCP120 and / or as part of the decision to select (or reject) candidate patients for the clinical trial.

[0089] Protocol 404 may also include a treatment 420 which may specify a procedure 422 for treatment, a diagnosis 424 (for determining / confirming the condition), and (multiple) drugs / devices 426. A clinical trial associated with a drug / device 426 may use control variables 428 and test variables 430 which may specify the dose to be administered 436, the duration of the trial 438, the trial phase (e.g., Phase 1, Phase 2, etc.), and may also include the duration of treatment and other parameters. Some or all of the above information (e.g., in 480-2) may form part of a subblock 480 which may be shared with HCP 120 at the time of patient selection for the trial.

[0090] For example, HCP120 may use some or all of the above information in subblock 480 (e.g., 480-2) to advise the patient and / or obtain coverage information from payer 140, determine the costs associated with the patient's participation in the clinical trial (e.g., if administered on an experimental or compassionate basis), or authorize payment to the patient (e.g., if the patient is paid for participation). As an example, SE150 may recommend drug device 426 (undergoing clinical trial) to HCP120, HCP120 may revise the previous prescription 250 to include drug / device 255 (e.g., as drug / device 462-q), and then send subblock 280 to (a) PMDP130 to obtain information related to drug / device 462(255-q) in subblock 380 and advise the patient, and (b) send it to payer 140 to obtain coverage-related information.

[0091] In some embodiments, SE150 may also transmit subblock 480 along with information 480-1 and / or 480-2 to PMDP130 to determine and agree upon protocol 404. PMDP130 may respond to some or all of the information in subblock 380. The exchange of information between SE150 and PMDP130 may occur before the start of the trial and / or if one or more parameters need to be modified during the trial.

[0092] A subblock 480 transmitted by and / or received by SE150 from another entity may include a transaction ID 695 which can be used to identify the transaction associated with the subblock. In addition, if an eligible candidate patient is determined to be a potential enrollment in a clinical trial (following pre-screening), HCP120 may transmit a patient profile 230, along with PII information and drug / device 255-q, to ​​SE150 within a subblock 280 (e.g., after obtaining patient approval in accordance with some law / regulation). In some embodiments, CTR400 may also include an HCP profile 295 containing information about HCP120, and the HCP profile may be transmitted to SE150 as part of a subblock 280.

[0093] In some embodiments, the CTR 400 may also include information about the SE 150, such as the Research Institute (RI) 440, which may include other information such as the RI name 442, RI contact information 444, RI details 448, and the principal investigator. In some cases, the PI may be associated with multiple physical locations that, when aggregated, constitute a single Research Institute. For example, a physician may have rights to a university hospital, which may have many locations even within a single city.

[0094] In some embodiments, the above RI information 440 relating to a research institution (e.g., as in 480-3) may form part of the CTR subblock 480. Furthermore, in some cases, the CTR subblock 480 may include any combination of information 480-1 and / or 480-2 and / or 480-3. The information within the subblock 480 (e.g., 480-3) may facilitate the identification of RI 440 associated with the clinical trial.

[0095] Figure 5 shows an exemplary health transaction record (HTR) 500. As shown in Figure 5, the HTR 500 may include treatment and payment and / or cost-related information for transactions associated with a patient. The fields shown in the HTR 500 are merely illustrative, and the HTR 500 may include various other fields based on laws, standards, industry practices, etc. In addition, the HTR may include different (fewer or more) fields than those shown in relation to the exemplary HTR 500. In some embodiments, the HTR 500 may be owned and maintained by an entity such as a payer 140 (e.g., SE 150 or a health insurance company) and may form part of a transaction information database 157 that can play a role in transaction approval and / or payment to one or more entities associated with the transaction.

[0096] HTR500 may include various data fields containing information about entities associated with and / or authorized to transact with payer 140, including patient profiles 195, HCP profiles 295, PMDP profiles 395, SE profiles 495, etc. Stored profiles may also contain information to enable transactions between entities (e.g., payments, rebates, insurance coverage verification, treatment / prescription authorizations, etc.). HTR500 may also include an HTR profile 595, which may include payer name, payer contact information, etc., and may be used to identify and / or communicate with payer 140.

[0097] In situations where payer 140 covers the costs of experimental / compassionate use of a drug / device, HTR 500 may include cost information 505, which may include the payer's view of the costs associated with the transaction. For example, cost information 505 may include payer costs 510, which can record the net cost to payer 140 for the transaction. Payer costs 510 may be a function of one or more of the following: pharmacy costs 515 (e.g., the price charged to payer 140 by pharmacy 160), PMDP costs 520 (e.g., the price negotiated between payer 140 and PMDP 120), HCP treatment costs 525 (e.g., the cost of treatment provided by HCP 120 in connection with a diagnosis), and patient costs 530 (e.g., the patient's out-of-pocket costs 535 as seen by payer 140 in this plan, which may include, for example, the patient's out-of-pocket amount 532 for treatment and prescriptions, deductions 537, and co-payment percentages 539). Some of the information associated with cost information 605 may be available to payer 140 (for example, based on a contract, etc.), while some of the cost information 605 may be provided by other entities before transaction completion (for example, via encrypted subblocks that can be decrypted by payer 140).

[0098] In the above situation (where payer 140 covers the costs of experimental / compassionate use of a drug / device), HCP 120 may send encrypted subblocks 280 (e.g., 280-1 and / or 282 in Figure 2) to payer 140, along with coverage-related information 272, plan ID 270, and / or HCP profile 295. Payer 140 may decrypt the information in subblocks 280 (including 280-1 and / or 282) and verify patient coverage using additional patient coverage information 698. Verification of patient coverage may be provided to HCP 120 by sending encrypted HTR subblocks 580 (e.g., having information in 580-3 and 580-4) that can be decrypted by HCP 120, along with the verification information, to HCP 120. In some examples, the HCP treatment cost 525 may be based on a contractual agreement between the payer 140 and the HCP 120, while in other examples, the HCP treatment cost 525 may be transmitted to the payer 140 by the HCP 120 providing the treatment within an encrypted subblock 280. In further examples, the encrypted subblock 280 (which may contain information in some cases) may be transmitted to the payer 140 by the HCP 120 for verification and transaction approval (for example, once a prescription for a drug under investigation has been determined). In some embodiments, the encrypted subblock 280 may be decrypted by the payer 140, and the payer 140 may approve the transaction by transmitting one or more confirmation messages (for example, to the HCP 120) in the form of an HTR subblock 580 having a payer approval (HCP) 527. Similarly, in response to a query from PMDP130 (for example, regarding payment assistance for patients participating in a clinical trial), an encrypted HTR subblock 580 (e.g., with information PMDP cost 520 and payer approval (PMDP) 523 in 580-2, and related information in 580-4) that can be decrypted by PMDP130 may be transmitted to PMDP130 by payer 140.As another example, in response to a query from the pharmacy (for example, regarding prescription 250 associated with a patient participating in a clinical trial), an encrypted HTR subblock 580 (e.g., with pharmacy costs 515 and payer approval (pharmacy) 521 in 580-2, and related information in 580-4) that can be decrypted by the pharmacy may be sent to the pharmacy by the payer 140.

[0099] In situations where SE150 makes payments to clinical trial participants, cost / payment information 505 may reflect the payments made by SE150 to the entities associated with the transaction.

[0100] In some embodiments, at the completion of a transaction, the HTR500 may be maintained by the payer 140 and stored as part of a local blockchain accessible to the payer 140. The HTR500 in encrypted form (and decryptable by the payer 140) may form part of a multidimensional block within a multidimensional block. Information not present in the HTR block 500 of the multidimensional blockchain may be encrypted by other entities and may not be decryptable by the payer 140. Conversely, the HTR block 500 within a multidimensional block may not be decryptable by the payer 140 and / or other entities associated with the platform. Thus, each entity has a consistent view of the transactions recorded as multidimensional blocks within the multidimensional blockchain, but entities cannot view information in blocks owned by other entities (stored as part of multidimensional blocks). Therefore, information in blocks owned by a first entity (stored as part of a multidimensional block) is reliably shielded from viewing by other second entities.

[0101] Figure 6 shows a portion of an exemplary Public Health Entity Record (PHER) 600 that may be maintained by a PHE (e.g., PHE180 in Figure 8). The term PHE is used to refer to any entity that is tasked with working to protect and / or improve public health interests. PHEs may operate at the city, county, state, national, or international level and may include government and regulatory organizations. PHEs may have overall responsibility for implementing public health measures, including drug and / or device deployments following a public health emergency. In some embodiments, PHE180 may maintain PHE records 600 based on information reported by testing and monitoring stations, HCP120, etc. In some embodiments, portions of PHER 600, such as demographic criteria 610 (including risk factors such as age, sex, occupation, and health status) associated with one or more population segments (e.g., populations at high risk in relation to a health emergency), may be made public, available, and accessible to the general public and / or authorized entities (e.g., HCP120, PMDP130, etc.) (e.g., via the Internet).

[0102] In many public health emergencies, such as the COVID-19 pandemic, clinical trials for vaccines, drugs, etc., are often conducted very close to deployment or rollout (once the vaccine, drug, etc., is approved). Deployment of drugs, vaccines, and devices (e.g., ventilators) is often phased due to (a) initial availability being limited (e.g., during production scaling), or (b) certain population segments being prioritized when receiving drugs and / or devices (e.g., high-risk populations such as healthcare workers, first responders, essential workers, populations considered vulnerable due to demographic reasons, or people living in areas experiencing larger outbreaks). In these situations, a streamlined process to facilitate a rapid transition from clinical trial approval to prioritized and / or targeted drug deployment can improve health outcomes, help control and prevent disease spread, ensure availability in affected areas / populations, reduce drug / device shortages in critical areas, and accelerate the return to normalcy by shortening the overall duration of outbreaks. Several disclosed embodiments enhance interoperability between healthcare entities and facilitate the deployment of prioritized drugs and / or devices. In some embodiments, PHER600 may be used to facilitate the deployment of prioritized drugs and / or devices and / or targeted drugs and / or devices. Generally, PHER may include different (fewer or more) fields than those shown in relation to the exemplary PHER600. In some embodiments, data fields within PHER600 may be stored and / or updated based on information received from HCP120, clinical trial centers, and / or other entities / sources.

[0103] PHER600 may include expansion criteria 604, which may include aggregate demographic criteria 610 such as age (or age range), 612, sex 614, and health parameters such as previous diagnosis 616 (e.g., previous patient's medical condition), current diagnosis 618 (e.g., current patient's medical condition), which may identify risk factors elevated in relation to the disease 628. Demographic criteria 610 may also include several other fields (not shown in Figure 6), such as race and travel history. Demographic criteria 610 may also include at-risk occupations 606 (e.g., occupations with a higher risk of disease), outbreak locations (e.g., zip codes or regions experiencing outbreaks or increased infection rates), which may identify at-risk population segments. Thus, PHER600 may include aggregate demographic information (e.g., in demographic criteria 610) that has risk factors and / or health parameters that identify at-risk populations.

[0104] In some embodiments, each risk factor may be associated with a risk weight that reflects the degree of risk associated with that factor. In some embodiments, the risk weight may vary based on the value of the associated field. For example, the risk weight may vary with age range, blood pressure range, etc. The risk weight can be used to calculate a score for each candidate patient (e.g., by HCP120 and / or PMDP130 and / or another entity such as a pharmacy, and / or another entity that manages the drug / device). Based on individual scores for a community and / or known aggregate demographic information (e.g., provided by PHE180 via subblock 680-1), an entity such as PMDP130 may determine an aggregate score for a community and prioritize where batches of the produced drug are shipped. The score may also be used (e.g., by HCP120, or an entity that administers the drug / device at a location) to determine priorities and schedule patients to receive the deployed drug / device. In some embodiments, demographic criteria 610 may form part of PHER subblock 680-1.

[0105] Deployment criteria 604 may also include deployment information 620 such as the disease 622 associated with the current outbreak, the diagnosis 624 (used to determine, for example, whether a patient is determined to be positive for the disease 622), the drug / device 626 used for prevention and / or treatment (e.g., vaccines, drugs, health protection devices, ventilators, etc.), and the procedure 628 to be followed during the administration of the drug / device 626. The drug / device field 626 may include the dose 636 to be administered, the duration of administration 636, etc. In some embodiments, deployment information 620 may form part of the PHER subblock 680-2.

[0106] In some embodiments, PHER600 may further include a transaction ID to 695 for identifying the current transaction, a PMDP profile 395 having information about PMDP130, an HCP profile 295 having information about HCP120, and so on. PHER600 may also include other entity profiles, such as a pharmacy, a test administration entity, a reporting entity, and so on. PHER600 may also include a PHE profile 645 having information about PHE180, such as a PHE name 642, PHE contact information 644, and PHE details 648, and the PHE profile may be used to identify and communicate with PHE180. In some embodiments, the PHE profile 645 may form part of a PHER subblock 680-3.

[0107] In some embodiments, the information in subblocks 680-1 and / or 680-2 and / or 680-3 may be combined into a single subblock 680, or otherwise combined. In other examples, subblocks 680-1 and / or 680-2 and / or 680-3 may be used at various points in a transaction to communicate information with another entity. The information in subblocks 680-1 and / or 680-2 and / or 680-3 may be encrypted and decryptable by a specified entity.

[0108] Figure 7A shows a flowchart representing a process flow 700 for facilitating clinical trial patient selection and enrollment while promoting healthcare information security and increasing interoperability among multiple entities. In some embodiments, portions of the process flow 700 may occur on a permissioned blockchain platform that can be made available to participating entities and / or authorized entities. In some embodiments, portions or all of the flow 700 may be executed using applications running on computing devices associated with entities. As outlined earlier, in some situations, SE150 may be a division of PMDP130 or affiliated with PMDP130 (as indicated by the dashed line in Figure 7A).

[0109] In flow chart 700, some routine messages are omitted for the sake of clarity. Furthermore, prior to the commencement of process flow 700, SE150 may have already obtained clinical trial protocol approval and may have satisfied other regulatory requirements related to the clinical trial. Information exchange regarding protocol approval is not shown in Figure 7A. Protocol approval may involve multiple message exchanges between SE150 / PMDP130 and regulatory bodies prior to protocol approval. The approved protocol for the clinical trial of drug / device 255 may be stored in CTR400 and may include eligibility criteria 410 (which may be part of subblock 480-1) and treatment 420 (which may be part of subblock 480-2). The approved protocol may also be stored in DIR300 as part of subblock 380-1. The message exchange between PMDP130 / SE150 and regulatory bodies for determining and approving the protocol for drug / device in the clinical trial may occur independently of patient consent in 703.

[0110] In 703, patient 170 may indicate consent to participate in a clinical drug / device trial. In some embodiments, consent may be communicated to HCP 120 and / or another entity. In some embodiments, HCP 120 may obtain patient pre-consent to participate in a clinical drug / device trial from EHR 200 at any time (in accordance with any laws, regulations, privacy considerations, etc.) before disclosing any patient information. In some embodiments, in 703, patient consent may indicate that some limited (e.g., non-PII) information associated with the patient's EHR 200 may be disclosed (e.g., by HCP 120 to PMDP 130) for pre-screening purposes. Thus, even if the patient has consented to the disclosure of PII information, HCP 120 may choose to edit the patient PII information during pre-screening so that it can be exchanged with SE 150.

[0111] As an example, patient 170 may initiate a transaction using an application running on a mobile computing device (e.g., a smartphone, tablet, laptop, etc.). In some embodiments, the application may be provided and / or authorized by an entity associated with a permissioned blockchain platform. For example, the application (e.g., running on a mobile computing device associated with patient 170) may be provided by a first entity (e.g., HCP120, PMDP130, and / or a patient access program (not shown in Figure 7)) and may communicate with the first entity using an application programming interface (API) and / or other network and communication protocols.

[0112] In 705, SE150 (and / or PMDP130) may initiate transmission of CTR subblock 480 along with information to initiate a clinical trial of drug / device 255. CTR subblock 480 may include the proposed protocol (e.g., treatment 337, dose, duration, etc.), known safety information 330, etc. In some embodiments, CTR subblock 480 may include some or all of the drug / device information in DIR subblock 380-1. CTR subblock 480 may be encrypted by HCP120 and may be decryptable. In some embodiments, HCP120 may obtain the drug / device information in DIR subblock 380-1 directly from PMDP130.

[0113] In 710, SE150 (and / or PMDP130) may receive an EHR subblock 280 containing diagnostic code 240, treatment code 245, instruction 242, and other patient information such as location. In some embodiments, the subblock 280 received by SE150 (and / or PMDP130) in 710 may not contain PII information associated with patient 170. The EHR subblock 280 may be encrypted by HCP120 and decryptable by one or more designated entities (e.g., PMDP130 or SE150). In some embodiments, the EHR subblock 280 may contain information about multiple candidate patients who have given consent to pre-screening for participation in a clinical trial.

[0114] In step 712, SE150 (and / or PMDP130) may, during the pre-screening step, determine the eligibility of patient 170(possible) to participate in the trial for drug / device 255 by comparing eligibility criteria 410 (e.g., received by PMDP as part of subblock 480-1) with information in EHR subblock 280-1 (received in 710). For example, to determine whether patient 170(possible) is within an acceptable age range, patient 170(possible)'s age (e.g., determined from DOB220) may be compared with age range 412 (in subblock 480-1). Other parameters, including demographic information associated with patient 170(possible)'s health record (e.g., provided in EHR subblock 280), may also be compared with the corresponding parameters in eligibility criteria 410 (received as part of subblock 480-1) to determine patient eligibility. In step 712, a subset of patients eligible to participate in the drug / device trial 255 may be determined.

[0115] In step 714, PMDP130 (and / or SE150) may send instructions to HCP120, along with the CTR subblock 480 (which may include the relevant portion of the DIR subblock 380), indicating a subset of candidate patients determined to be eligible based on the eligibility determination in step 712. Since some patients may be determined to be ineligible in step 712, the subset of candidate patients determined to be eligible may be less than or equal to the number of candidate patients (in step 710).

[0116] In 716, HCP120 may provide the patient eligibility instructions (received in 714) to the eligible patient(s)(170)(170) based on the patient eligibility instructions.

[0117] In some embodiments, HCP120 may provide payer140 with coverage-related information 272, drug / device information 255, and trial-related information and plan ID 270 in an encrypted subblock 282 (not shown in Figure 7A) which may be decryptable by the corresponding receiving entity. Payer140 may respond with an additional encrypted subblock (not shown in Figure 7A) which may be decryptable by HCP120, verifying patient coverage, indicating whether the trial is covered by the patient's plan, and showing the patient cost. In some embodiments, coverage-related information (including cost) may be transmitted to patient170 in 716 (or before obtaining patient consent in 718).

[0118] In 718, (for example, after reviewing the information received in 716 and / or consulting with HCP120), one or more eligible patients 170 may indicate their consent to participate in a clinical trial for the drug / device 255 and may also agree to share information associated with the corresponding EHR200 with SE150 (and / or PMDP130). In some embodiments, patients 170 may also indicate their consent to comply with legal, regulatory, or trial-specific requirements electronically (for example, via an application on a mobile phone or computing device).

[0119] In 720, SE150 (and / or PMDP130) may receive from HCP120 a list of eligible, pre-screened patients who have consented to participate in the drug / device trial, along with EHR information for patient 170, which may include PII information for patient 170. Since some patients may not consent to participate, the list of patients in 720 may differ from the subset of eligible patients in 714.

[0120] In some embodiments, steps 710, 712, 716, 718, and 720 may be repeated for multiple HCPs and patients 170 until SE150 (and / or PMDP130) indicates that the number of patients in the current trial associated with the drug / device 255 is appropriate and / or enrollment in the current trial is complete. In some embodiments, since the trial protocol may diversify participants by geography (location) and HCP, termination may be HCP-specific or location-specific. Thus, enrollment may remain open to other HCPs or patient / HCPs in other locations.

[0121] In 725, at the time of approval by PMDP130 and / or SE150 and / or Payer140 (for example, if payment is made to the participant and / or if the insurance company agrees to indemnify SE150 and / or PMDP130 for compassionate / experimental use of the drug / device for Patient170), the platform (e.g., a private permissioned blockchain platform) may send transaction ID 695 and a transaction type indicating transaction confirmation to the entities associated with the transaction. Each entity, upon receiving confirmation, may add its corresponding encrypted record (e.g., EHR200 for HCP120, DIR record 300 for PMDP120, CTR400 for SE150, and HTR for Payer140) to its local blockchain. In addition, two or more of the above encrypted records may form part of a multidimensional block 750 in a multidimensional blockchain (not shown in Figure 7A). Encrypted blocks within a multidimensional block (e.g., EHR200 for HCP120, DIR300 for PMDP130, CTR400 for SE150, and HTR500 for SE150 and / or payer140) may be decrypted by the entity that encrypts the block, or may not be decrypted by any other entity. Thus, each block represents a view of an entity in a transaction, but each block, upon transaction completion, contains authorized information from other related entities (through received subblocks), so its view is consistent with the views of other entities in the same transaction.In addition, each multidimensional block in the multidimensional blockchain represents a snapshot of a completed transaction as seen by the entities that are parties to the transaction, but the information within any single encrypted block (e.g., one of EHR200, DIR300, CTR400, or HTR500 in Figure 7A) that is owned and encrypted by a specific entity (e.g., one of HCP120, PMDP120, SE150, or SE150 / payer140, respectively) is also shielded from non-owning entities. As shown in Figure 7A, the multidimensional block 750 is visualized as a cube (multidimensional volume), with each face of the cube representing a block associated with the entities that are parties to the transaction. If the transaction is not confirmed by SE150 and / or another entity, one or more of steps 710-725 may be repeated.

[0122] In 730, SE150 (and / or PMDP130), and / or HCP120, or the platform may send registration confirmation to registered patient 170. Because PMDP130 (and / or SE150) may not register some patients based on further screening, and / or due to protocol or other considerations, the set of patients registered in 730 may differ from the set of eligible patients who have given approval to participate in the trial (in 720).

[0123] Figure 7B shows entities and layers associated with an exemplary platform for promoting security and interoperability in a healthcare system. In some embodiments, various entities such as HCP120, PMDP130, SE150, payer140, etc., can form parts of a permissioned blockchain platform. In a permissioned blockchain platform, trusted entities can form the platform and invite other trusted entities to participate in the network. In some embodiments, the permissioned blockchain platform can also be private (e.g., to invited entities and / or authorized entities). In some embodiments, the permissioned blockchain platform can support a multidimensional blockchain. Rules related to access to and adding blocks to the multidimensional blockchain, program code for determining contracts between entities (e.g., smart contracts), applications affecting platform functionality (e.g., instead of patient170), update verification, etc., may be determined and / or authorized by entities associated with the permissioned blockchain platform. As outlined earlier, in some situations, PMDP130 and payer140 may be departments of SE150 and / or affiliated with SE150.

[0124] In some embodiments, the permissioned blockchain platform may take the form of a cloud-based system. A cloud-based system refers to infrastructure, applications, services, and / or other resources (including hardware resources) that can be made available over a network (e.g., the internet). A cloud-based system can be based on underlying hardware and software resources and can be public (e.g., available everywhere on a fee-based model), private (e.g., limited to an organization), or hybrid (using some combination of public and private clouds). In some embodiments, entities associated with the platform may be represented by servers (hardware and / or software), which may, in some cases, be cloud-based. For example, HCP120, PMDP130, payer140, and various other entities (e.g., FDA, IRB, CTRB, DSMB, etc. (not shown in Figure 7B)) may be associated with a private permissioned blockchain platform and may include agents running on servers and / or agents running on a cloud-based platform including virtual machines (VMs).

[0125] In some embodiments, access to the functionality provided by the permissioned blockchain platform may be facilitated through a layer or API associated with the platform. For example, patient 170 and / or another authorized entity acting on behalf of the patient (e.g., an entity facilitating access to a payment assistance program provided by PMDP130) may provide a mobile application (e.g., running on a smartphone or other mobile computing device) that interacts with a cloud-based permissioned blockchain platform to facilitate patient selection and the determination of relevant cost metrics associated with (a) an initial prescription for patient 170 (e.g., as shown by the data in subblock 280-1 of Figure 7A) and prescription completion (e.g., as shown by the data in subblock 280-2 of Figure 7A) related to the delivery of payment assistance to patient 170, based on patient criteria 297.

[0126] As shown in Figure 7B, the multidimensional block 750 includes an EHR information block 200, a DIR information block 300, a CTR information block 400, and an HTR information block 500. In some embodiments, the multidimensional block 750 may form part of a multidimensional blockchain. In the multidimensional block 750, the EHR information block 200, the DIR information block 300, the CTR information block 400, and the HTR information block 500 may be encrypted and decryptable by HCP120, PMDP130, SE150, and payer140, respectively.

[0127] Furthermore, EHR information block 200, DIR information block 300, CTR information block 400, and HTR information block 600 may also form blocks within EHR blockchain 772, DIR blockchain 773, CTR blockchain 774, and HTR blockchain 766, respectively. As shown in Figure 7B, EHR blockchain 772, DIR blockchain 773, CTR blockchain 774, and HTR blockchain 766 may be owned and maintained locally by HCP120, PMDP130, SE150, and payer140, respectively. Figure 7B also shows subblock 280 (forming part of EHR block 200), subblock 380 (forming part of DIR block 300), and subblock 480 (forming part of CTR block 400). As outlined above, the information within the subblocks may have been shared among some of the entities associated with the transaction before the transaction ended and may be consistent across multiple blocks that form part of the multidimensional block 750 (at the time of transaction completion). In some embodiments, each field associated with information blocks 200, 300, 400, 500, and / or 600 may have a unique global field ID, which can uniquely identify the field within the multidimensional blockchain system and / or to the associated entities, if the information associated with the field is shared among entities. Multidimensional blocks may include data and timestamps. Timestamps may determine the order in which multidimensional blocks are linked (when completed).

[0128] As shown in Figure 7B, HCP120, PMDP130, SE150, and payer140 can interact with the authentication layer 770. The authentication layer 770 may include functions for identifying and managing (adding, registering, authorizing, and deleting) system entities and / or applications (e.g., mobile applications) that use (or request the use of) functions provided by the permissioned blockchain platform. In addition, the authentication layer may include functions for verifying permissions related to operations involving (a) multidimensional blockchain (e.g., adding new blocks, creating links) and (b) transaction types (e.g., whether an entity can initiate or participate in a particular transaction type). The authentication layer 770 may also interact with the consensus layer 780, which may include functions for determining the order of transactions and verifying the legitimacy of sets of transactions related to a multidimensional block 750.

[0129] In some embodiments, the consensus layer 780 may verify the legitimacy of the transactions constituting the multidimensional block. At the end of a transaction, the consensus technique applied by the consensus layer 780 may verify the legitimacy of the transactions constituting the multidimensional block (including shared data between entities). In some embodiments, a consensus technique, such as Byzantine Fault Tolerance (BFT), or its variations, such as redundant BFT, fast Byzantine consensus, dynamic quorum, or some other vote-based consensus techniques, may be used to determine whether the multidimensional block 750 can be formed using component blocks (e.g., EHR information block 200, DIR information block 300, CTR information block 400, and HTR information block 500). Consensus is achieved when authorized entities (e.g., payer 140, or designated trusted entities for a transaction / transaction type), or a certain number of entities (e.g., a majority), validate the transaction or block. The decision to agree or validate a transaction may vary depending on the transaction type.

[0130] Once the transaction is validated by consensus technology, a first instance of the unlocked multidimensional block 750 may be formed. As shown in Figure 7B, the unlocked multidimensional block 750 may be locked and added to the multidimensional block when the transaction ends. In some embodiments, blocks that form part of the multidimensional block 750 (e.g., EHR information block 200, DIR information block 300, PBR information block 400, PPR information block 500, and HTR information block 600) may be added as blocks to their respective local blockchains (e.g., EHR blockchain 772, DIR blockchain 773, PBR blockchain 764, PPR blockchain 775, and HTR blockchain 766, respectively) at the end of the transaction and when the multidimensional block 750 is locked. Therefore, the information within locally stored blocks (e.g., EHR information block 200, DIR information block 300, PBR information block 400, PPR information block 500, and HTR information block 600) is consistent with the information within the multidimensional block 750.

[0131] Conversely, if, for example, a patient identified as patient ID 425 within subblock 480 does not match a patient ID (e.g., within subblock 280), the transaction may be considered invalid, and the block addition request may be rejected. In some embodiments, the platform, or each entity, may maintain a log of rejected transactions for traceability and debugging purposes. This log may show the reason and code associated with the transaction rejection.

[0132] In some embodiments, the consensus layer 780 may apply consensus technology and interact with the smart contract layer 790 to establish the legitimacy and / or validity of a transaction and initiate further actions. The smart contract layer 790 may include program code that implements logic related to the blockchain. For example, a “smart contract” program code associated with a multidimensional blockchain may process a transaction request and determine the validity of a transaction based on program logic. This logic may depend on rules agreed upon by entities regarding transactions related to the blockchain. For example, the smart contract layer 790 may reject a transaction (e.g., from HCP120) due to incompatibility between two or more drugs prescribed to a patient. The smart contract may operate at verification time and at commit time before the block is locked and / or committed. In some embodiments, the smart contract layer 790 may encode rules or agreements between two or more entities relating to data sharing, transactions, etc., and these rules or agreements may be based on actual contracts between entities. In some embodiments, each update to a conventional blockchain (e.g., one of the following: EHR blockchain 772, DIR blockchain 773, PBR blockchain 774, or HTR blockchain 766) may be verified by smart contract program code associated with the platform. This smart contract program code can reflect agreements between entities related to data sharing, authentication, settlement, etc. The smart contract layer can be considered an automated tool that facilitates interaction between entities without manual intervention. In some embodiments, the smart contract layer can initiate operation based on rules associated with one or more contracts, when those rules are met.Each update to the multidimensional blockchain, and / or the passage of time, and / or other events, and / or specific requests related to a contract (identified by the contract ID) may trigger an action by the smart contract layer.

[0133] The linking of updated records may be performed based on predefined rules agreed upon by entities (e.g., HCP120 and payer140). In some embodiments, block linking may be performed based on smart contracts associated with the multidimensional blockchain. Updated blocks may be rehashed after linking. As outlined above, this linking allows entities to correlate information in a blockchain maintained by another entity with information in their own blockchain. In addition, those entities may be able to determine the transactions or sets of transactions associated with the information in a particular block maintained by that entity. Thus, two or more entities can have a consistent and coherent view of the transactions associated with blocks in separate blockchains. During the formation process, the multidimensional block 750 may not be fully formed (or the multidimensional block may be in progress) (at least initially), and therefore, a block received from another entity can transform the currently in-progressing (not fully formed) multidimensional block by adding another dimension. For example, a completed HTR200 (containing a prescription from HCP120) may be added as one dimension to the currently ongoing multidimensional block. Then, another dimension, for example, a dimension containing DIR300 (containing drug / device information), may be added to the ongoing multidimensional block. The process may continue until the multidimensional block is fully formed (for example, until it includes dimensions from all related parties to the transaction).

[0134] Multidimensional blocks (and their component records) may be locked upon completion of a transaction to prevent further modifications and ensure consistent viewing. Any subsequent modifications may result in the addition of a new multidimensional block to the multidimensional blockchain. For example, a new multidimensional block may be formed by an update to a single-dimensional data record, while the substantial information associated with other dimensions remains unchanged. For instance, drug-related information associated with medications prescribed to a patient (e.g., new contraindications) may be updated within a new multidimensional block (e.g., by PMDP130) without updating other records.

[0135] A multidimensional block can take the form of a Merkle tree associated with a multidimensional blockchain containing component data records (e.g., EHR200, DIR record 300, CTR400, and HTR500). As outlined earlier, the data records may also be associated with separate individual blockchains.

[0136] Therefore, the cryptographic hashes of individual records in separate blockchains (772, 773, 774, and 766, respectively) (e.g., separate cryptographic hashes (or "hashes") of EHR200, DIR record 300, PBR400, PPR500, and HTR500) may be obtained using separate cryptographic hash functions so that records owned by an entity are not decryptable or viewable by other entities. A separate cryptographic function (which may be known to entities associated with a permissioned blockchain platform, for example) may be used to obtain the cryptographic hash of a combination of records so that the top hash is associated with the entire multidimensional block. In some embodiments, each multidimensional block may include a block header having a timestamp, a top hash, information relating to the preceding block, a pointer to the root of the Merkle tree, and other appropriate information. The hash criterion may take the form of a uniform resource locator (URL) on the private permissioned blockchain platform and / or local (entity-specific) address.

[0137] Figure 7B shows a constrained and locked multidimensional block 750, where information from subblocks 480, 280, and 380 is shared among their respective authorized and relevant entities. In addition, the multidimensional block 750 includes linkages between individual component blocks. The multidimensional block 750 can represent a holistic view of a transaction at a given point in time, because it may, in part, include real-world physical states associated with a drug (dosage, effect, etc.), a patient (condition, treatment, effect, etc.), and the cost at that point in time. The multidimensional block 750 may include links to preceding blocks within the blockchain. A verified and completed multidimensional block 750 may include completed data records 200, 300, 400, and 500, which may correspond to completed information blocks 200, 300, 400, and 500 in separate local blockchains 772, 773, 774, and 766, respectively.

[0138] Figure 7C shows a flowchart of an exemplary method 791 for promoting healthcare information security and interoperability while facilitating patient selection for clinical trials. In some embodiments, method 791 may use a multidimensional blockchain, which may be based on separate blockchains maintained by individual entities within the system. In some embodiments, method 800 may be implemented (at least partially) on a private permissioned blockchain platform, which may optionally take the form of a cloud-based system. Method 791 may also be implemented by processors, computers, or networks of computers, e.g., distributed computing systems, servers (hardware and software) including application servers, mobile computing devices (e.g., smartphones, smart wearable devices, handheld computers, tablets, laptops, etc.), and cloud-based systems.

[0139] In some embodiments, method 791 may be implemented in a first entity (e.g., PMDP130, SE150, etc.). For example, the first entity may comprise at least one server or computer system associated with at least one of the following: a pharmaceutical provider or a medical device provider such as SE150 (and / or PMDP130). In some embodiments, the first entity may interact with one or more second entities. The second entities may comprise one or more servers or computer systems associated with a healthcare provider such as HCP120, a payer / insurer such as payer140, or a patient such as patient170, etc. In some embodiments, the first entity and one or more second entities may form computing nodes in a distributed computing system, and the multidimensional blockchain may form part of a permissioned private blockchain platform such as a permissioned private blockchain platform.

[0140] In some embodiments, method 791 may be invoked when an entity, such as a first entity, initiates a transaction (having, for example, a transaction ID and / or transaction type) to add a block to a locally maintained blockchain. Adding a block to the local blockchain may involve input from one or more other entities, and a permissioned private blockchain platform may invoke method 791. In some embodiments, method 791 may be invoked in response to approval of at least one protocol associated with at least one clinical trial for at least one medical product. The medical product may include one or more drugs and / or one or more biologics and / or one or more medical devices and / or combinations thereof.

[0141] In some embodiments, in step 792, the first entity (e.g., PMDP130 or SE150) may receive an encrypted first electronic health record (EHR) subblock (e.g., subblock 280) that can be decrypted by the first entity, the EHR subblock including patient profile information about a patient (e.g., basic profile information 230), at least one first diagnostic code (e.g., diagnostic code 240), and at least one first treatment code (e.g., treatment code 245). In some embodiments, the patient profile information in the first EHR subblock may include non-personally identifiable (non-PII) information. If the disclosure of patient PII information has been pre-authorized by the patient, the patient profile information may include patient personally identifiable information (PII). Furthermore, in some embodiments, the patient profile information may include patient location information and healthcare provider information.

[0142] In some embodiments, the first entity may receive the first EHR subblock (for example, in step 792) when it receives approval for at least one protocol associated with at least one clinical trial. For example, the first entity may request one or more EHR subblocks from at least one second entity, and in response to the request, it may receive encrypted first EHR subblocks from at least one second entity.

[0143] In step 793, the first entity may determine patient eligibility for at least one clinical trial associated with at least one medical product based on (a) a received EHR subblock (e.g., subblock 280) and (b) a clinical trial subblock containing one or more approved protocols (e.g., subblock 480 in CTR400 or DIR300), where each approved protocol is associated with a corresponding clinical trial for a corresponding medical product.

[0144] For example, a patient's eligibility to participate in at least one clinical trial may be based on information within a first EHR subblock by determining whether the patient meets the corresponding eligibility criteria specified for at least one clinical trial, the corresponding eligibility criteria being included in at least one approved protocol. In some embodiments, the corresponding eligibility criteria include inclusion and exclusion criteria.

[0145] In step 795, the first entity may, based on the determination of patient eligibility, transmit at least one encrypted CTR subblock (e.g., CTR subblock 480) containing at least one approved protocol associated with at least one clinical trial (e.g., based on subblock 480), and at least one encrypted device / drug information record (DIR) subblock (e.g., DIR subblock 380) corresponding to at least one medical product associated with at least one clinical trial.

[0146] In step 797, the first entity may, in response to the transmission, receive an encrypted second EHR subblock decryptable by the first entity, the second EHR subblock including patient profile information (e.g., basic profile information including PII 230), patient consent to participate in at least one clinical trial, at least one second diagnostic code, and at least one second treatment code (e.g., based on a drug / device in the trial). Thus, in some embodiments, patient PII may be included in the second EHR subblock (e.g., at the time of patient selection for the trial) but not in the first EHR subblock (during pre-screening).

[0147] In step 799, the first entity may extend the multidimensional blockchain in response to receiving a transaction block having transaction confirmation, the multidimensional blockchain being extended with a multidimensional block formed by linking (i) a transaction block containing patient profile information, patient consent, and at least one clinical trial and at least one corresponding approved protocol, (ii) a DIR block containing medical information associated with at least one medical product, and (iii) an EHR block containing information associated with a second EHR subblock. In some embodiments, the multidimensional block may further include a CTR block, the CTR block containing information about at least one approved protocol.

[0148] In some embodiments, the first entity may then send the patient confirmation of enrollment in at least one clinical trial (for example, based on patient PII information).

[0149] Figure 8 shows a flowchart representing a process flow 800 for facilitating drug / device deployment while promoting healthcare information security and increasing interoperability between multiple entities. In some embodiments, parts of the process flow 800 may occur on a permissioned blockchain platform that can be made available to enrolling entities and / or authorized entities. In some embodiments, parts or all of the flow 800 may be executed using applications running on computing devices associated with entities. In flowchart 800, some routine messages are omitted for ease of explanation.

[0150] In 805, PMDP130 may retrieve a PHER subblock having deployment criteria (e.g., an encrypted PHER subblock 680 decryptable by PMDP130) from PHE180. In some embodiments, the information associated with PHER subblock 680 may be publicly available and / or available to authorized entities and may be retrieved by PMDP130. PHER subblock 680 may include aggregate demographic information having risk factors associated with one or more population segments. For example, aggregate demographic information may include a demographic criterion 610 associated with drug / device deployment, the demographic criterion may include risk factors (e.g., associated with a disease outbreak) and location information (e.g., where a disease outbreak is prevalent, emerging, or accelerating).

[0151] In 807, HCP120 may obtain patient authorization for the use of the EHR200 associated with patient 170 in connection with drug / device distribution. In some embodiments, patient authorization may include authorization for the use of PII information, which may be used for drug / device distribution. In other cases, non-PII information may be used first (for example, to determine eligibility in step 815 below), and PII information may be used once patient eligibility has been determined.

[0152] At 810, the PMDP may receive one or more EHR subblocks containing patient profile and medical history information (e.g., encrypted EHR subblock 280 that can be decrypted by the PMDP 130). The EHR subblock 280 transmitted at 810 may be based on authorization obtained at 807. Patient authorization may be obtained at any time prior to 810 and, in some cases, may be based on prior authorization obtained by the HCP 120 in accordance with general laws and regulations.

[0153] In step 815, PMDP130 may determine a set of eligible patients by comparing deployment criteria (e.g., based on subblock 680) with EHR and demographic information (e.g., based on subblock 280). For example, information within an EHR subblock (e.g., subblock 280) may be compared with deployment criteria for drug / device deployment (e.g., deployment criteria 604, which includes aggregate demographic information that may be at high risk, e.g., age group, occupation, location, etc.) to determine candidate patients who are eligible to receive the drug / device preferentially and / or are currently eligible to receive the drug / device. The set of eligible patients 170 to receive the drug / device may be several subsets of patients 170 associated with EHR subblock 280 that are sent to PMDP130 in 810.

[0154] In 820, PMDP130 may transmit one or more encrypted DIR subblocks 380, decryptable by one or more corresponding second entities (e.g., HCP120 and / or pharmacy160 that may be used by patient 170 to obtain prescription drugs / devices), along with instructions for patient eligibility to receive drugs / devices (based on the decision in 815), each of the first subblocks transmitted, including at least one candidate patient profile and at least one medical information associated with a treatment. For example, PMDP130 may transmit candidate patient profiles corresponding to candidate patients eligible to receive drugs / devices on a priority basis to HCP120 (and optionally to pharmacy160 designated by PHE180 and / or pharmacy160 based on information in the patient profile).

[0155] In 825, HCP120 may inform patient 170 of the confirmation of patient eligibility to receive the drug / device. In 830, HCP120 may send an EHR subblock (e.g., an encrypted subblock 280 decryptable by payer 140) to payer 140 to confirm coverage information for eligible patient 170. In 835, payer 140 may send an HTR subblock (e.g., an encrypted HTR subblock 580-1 confirming patient coverage) to HCP120.

[0156] In 840, HCP120 may transmit prescription information within an EHR subblock (e.g., an encrypted EHR subblock 280 decryptable by PMDP130) to pharmacy 160, and optionally to PMDP130 and / or PHE180, to confirm that the drug / device has been prescribed to patient 170. The information contained in EHR subblock 280 and transmitted by HCP120 to payer 140, PMDP130, PHE180, and pharmacy 160 may be consistent, but the data fields contained in each subblock may differ and depend on the information interface between entities (which may depend on the laws / regulations governing patient health-related information, as well as the laws / regulations governing information exchange between entities).

[0157] At 845, when PMDP130 and / or HCP120 are approved, the platform (e.g., a private permissioned blockchain platform) may send transaction ID 695 and transaction type, indicating transaction confirmation, to the entities associated with the transactions. Upon receiving the confirmation, each entity may add its corresponding encrypted record (e.g., EHR200 for HCP120, DIR record 300 for PMDP120, HTR for payer 140, and PHER600 for PHE180) to its local blockchain. In addition, two or more of the above encrypted records may form part of a multidimensional block in a multidimensional blockchain (not shown in Figure 8). The encrypted blocks within the multidimensional block (e.g., EHR200 for HCP120, DIR300 for PMDP130, PHER600 for PHE180, and HTR500 for payer 140) may be decrypted by the entity that encrypted the block, or may not be decrypted by any other entity. Therefore, each block represents a view of the transaction entities, but each block contains approved information from other related entities (via received subblocks) upon transaction completion, so its view is consistent with the view of other entities regarding the same transaction. In addition, each multidimensional block in a multidimensional blockchain represents a snapshot of a completed transaction as seen by the entities that are parties to the transaction, but any information within any single encrypted block (e.g., one of EHR200, DIR300, CTR400, or HTR500 in Figure 7A) owned and encrypted by a specific entity (e.g., one of HCP120, PMDP120, PHE180, Pharmacy160, or Payer140, respectively) is also shielded from non-owning entities.If the transaction is not approved by an entity (for example, HCP120 and / or PMDP130 and / or another entity), one or more of steps 805-840 may be repeated.

[0158] At 850, the pharmacy 160 may send a prescription confirmation to the patient 170. Once the prescription is dispensed (e.g., delivered or shipped to the patient 170), at 855, the pharmacy 160 may send information regarding the dispensing of the drug / device to one or more of the PMDP 130, HCP 120, and / or PHE 180. The information may be used by the PHE 180, for example, to update PHE aggregated information related to the dispensing of the drug / device. For example, an application (e.g., on a smartphone or other mobile computing device associated with the patient 170) may receive confirmation of enrollment in at least one selected plan (e.g., via a secure message or via a secure API communicably coupled to a private permissioned blockchain platform).

[0159] PMDP130 (and / or HCP120, and / or SE150), or the platform, may send registration confirmations to registered patients 170. Because PMDP130 (and / or SE150) may not register some patients based on further screening, and / or due to protocol or other considerations, the set of patients registered in 730 may differ from the set of eligible patients who have given approval to participate in the trial (in 720).

[0160] Figure 9 shows a flowchart of an exemplary method 900 that facilitates healthcare information security and interoperability while promoting drug / device deployment. In some embodiments, method 900 may use a multidimensional blockchain, which may be based on separate blockchains maintained by individual entities within the system. In some embodiments, method 900 may be implemented (at least partially) on a private permissioned blockchain platform, which may optionally take the form of a cloud-based system. Method 900 may also be implemented by processors, computers, or networks of computers, e.g., distributed computing systems, servers (hardware and software) including application servers, mobile computing devices (e.g., smartphones, smart wearable devices, handheld computers, tablets, laptops, etc.), and cloud-based systems.

[0161] In some embodiments, method 900 may be implemented in a first entity (e.g., PMDP130). For example, the first entity may include at least one server or a computer system associated with at least one of a pharmaceutical provider or medical device provider such as PMDP130. In some embodiments, the first entity may interact with one or more second entities. The second entities may include one or more servers or computer systems associated with a healthcare provider such as HCP120, an insurer such as PHE180, a payer 140, or a patient 170. In some embodiments, the first entity and one or more second entities may form computing nodes in a distributed computing system, and the multidimensional blockchain may form part of a permissioned private blockchain platform such as a permissioned private blockchain platform.

[0162] In some embodiments, method 900 may be invoked when an entity, such as a first entity, initiates a transaction (having, for example, a transaction ID and / or transaction type) to add a block to a locally maintained blockchain. Adding a block to the local blockchain may involve input from one or more other entities, and a permissioned private blockchain platform may invoke method 900. In some embodiments, method 900 may be invoked in response to approval of a medical product (for example, after a successful clinical trial). The medical product may include one or more drugs and / or one or more biologics and / or one or more medical devices and / or a combination thereof. In some embodiments, to ensure that the medical product is provided in accordance with public health guidelines and / or to improve overall health outcomes, the deployment of the medical product may occur during an emergency health situation or in a situation where the availability of the medical product is limited (for example, because full production has not yet started or production is being scaled up).

[0163] Therefore, deployment criteria may be based on demographic criteria associated with a high risk from infection during a public health emergency, and may include aggregate demographic information corresponding to high-risk locations and population segments. For example, a public health emergency could be a disease outbreak, e.g., a localized disease outbreak, an epidemic, or a pandemic. In the emergencies identified above, it may be advantageous to deploy preventive measures (e.g., vaccines), other preventive devices (e.g., protective equipment), treatments (e.g., to alleviate symptoms), therapeutic agents (e.g., cures), and / or other drugs and / or devices to populations based on demographics and / or risk. For example, it may be advantageous to deploy treatments to first responders, healthcare workers, emergency / essential personnel, and / or other population segments that may be particularly vulnerable. Furthermore, in some cases (e.g., the Covid-19 pandemic), large-scale drug / device deployments may occur after successful completion of clinical trials. Therefore, the technologies presented herein can facilitate more effective pre-screening and selection of patients, faster initiation of clinical trials, and more effective drug / device deployment upon completion of clinical trials, thereby supporting efforts to address public health emergencies.

[0164] In step 910, the first entity (e.g., PMDP130) may obtain an encrypted PHER subblock (e.g., PHER subblock 680) that can be decrypted by the first entity, the PHER subblock may include deployment information (e.g., deployment criteria 604) that includes demographic information associated with one or more population segments. In some embodiments, the information associated with PHER subblock 680 may be publicly available and / or available to authorized entities and may be retrieved by PMDP130. PHER subblock 680 may include aggregate demographic information having risk factors associated with one or more population segments. For example, the aggregate demographic information may include a demographic criterion 610 associated with a drug / device deployment, the demographic criterion may include risk factors (e.g., associated with a disease outbreak) and location information (e.g., where a disease outbreak is prevalent, emerging, or accelerating).

[0165] In step 920, the first entity may receive one or more encrypted electronic health record (EHR) subblocks (e.g., EHR subblock 280) that can be decrypted by the first entity, each of which is associated with a corresponding candidate patient, and the EHR subblock includes (a) the patient's medical history and (b) patient profile information for multiple candidate patients (e.g., basic profile information 230 having medical history 232 and, where applicable, optionally, diagnoses 235). In some embodiments, the received EHR subblock 280 may be based on patient authorization or prior authorization, which can be obtained by HCP 120 and / or required by PMDP 130 in accordance with any general laws and regulations.

[0166] In some embodiments, in step 930, the first entity may determine a set of eligible candidate patients who are eligible to receive one or more treatments based on one or more of the following: demographic information, patient medical history, or patient profile information, and each eligible candidate patient is selected from a group of candidate patients (associated with the EHR block received in step 920).

[0167] For example, a first entity such as PMDP130 may determine a set of eligible patients by comparing deployment criteria (e.g., based on subblock 680) with EHR and demographic information (e.g., based on subblock 280). For example, information within an EHR subblock (e.g., subblock 280) may be compared with deployment criteria for drug / device deployment (e.g., deployment criteria 604, which includes aggregate demographic information that may be at high risk, e.g., age group, occupation, location, etc.) to determine candidate patients who are eligible to receive the drug / device preferentially and / or are currently eligible to receive the drug / device. The set of candidate patients eligible to receive the drug / device (determined in step 930) may be any subset of multiple candidate patients (associated with the EHR subblock 280 sent to PMDP130 in step 920).

[0168] In step 930, the first entity may transmit one or more encrypted DIR subblocks (e.g., DIR subblock 380) that can be decrypted by one or more corresponding second entities, each DIR subblock containing one or more eligible candidate patients and medical information associated with one or more treatments (e.g., in which a drug / device is prescribed). For example, PMDP 130 may transmit candidate patient profiles corresponding to candidate patients eligible to receive a drug / device on a priority basis to HCP 120 (and optionally to pharmacy 160, for example, designated by PHE 180 to deliver a drug / device and / or based on information in the patient profile in EHR subblock 280).

[0169] In step 940, the first entity may extend the multidimensional blockchain with a multidimensional block formed by linking (i) a transaction block containing treatment deployment-related information, (ii) a DIR block containing patient profile, selection parameters, and medical information associated with at least one treatment, and (iii) an EHR block containing patient profile information, medical history, and prescription information, in response to receiving a transaction block having transaction confirmation.

[0170] In some embodiments, in step 950, the first entity may receive a transaction block having transaction confirmation, and in response to receiving the transaction block, may extend the multidimensional blockchain. The multidimensional blockchain may be extended by a multidimensional block formed by linking (i) a transaction block containing treatment deployment-related information associated with at least one treatment, (ii) a drug device information (DIR) block containing medical information associated with at least one treatment, and (iii) an EHR block containing at least one candidate patient profile information, a corresponding candidate patient medical history for at least one candidate patient, and prescription information for at least one treatment. For example, in a clinical trial setting, a multidimensional block (for extending the multidimensional blockchain) may include a transaction block (e.g., HTR500) having information about a transaction, and a DIR block (e.g., DIR record 300) having medical information associated with at least one treatment, linked to an EHR block (e.g., EHR record 200) containing candidate patient profile information for a candidate patient whose participation in the clinical trial has been confirmed.

[0171] As outlined above, in step 930, at least one treatment may form part of at least one clinical trial. At least one clinical trial may be associated with a corresponding clinical trial protocol that includes corresponding eligibility criteria. In some embodiments, the corresponding eligibility criteria may include one or more corresponding exclusion criteria for determining one or more patients who are ineligible to be included in a subset of candidate patients, and one or more corresponding inclusion criteria for determining one or more patients who may be eligible to be included in a subset of candidate patients. In some embodiments, method 900 may be initiated in response to approval of a corresponding clinical trial protocol associated with at least one clinical trial. At least one clinical trial may be associated with one or more drugs, or one or more biologics, or one or more medical devices, or a combination thereof.

[0172] Furthermore, in step 940, the multidimensional block may be further extended with a clinical trial record (CTR) block (e.g., CTR400) which includes at least one candidate patient profile, medical information associated with at least one treatment, and a corresponding clinical trial protocol, the clinical trial protocol further including a first set of health parameters.

[0173] Figure 10 shows a flowchart of an exemplary method 1000 for promoting healthcare information security and interoperability while facilitating (a) patient selection for clinical trial participation and / or (b) drug / device deployment. In some embodiments, method 1000 can use a multidimensional blockchain, which can be based on separate blockchains maintained by individual entities within the system. In some embodiments, method 1000 may be implemented (at least partially) on a private permissioned blockchain platform, which may, in some cases, take the form of a cloud-based system. Method 1000 may also be implemented by processors, computers, or networks of computers, e.g., distributed computing systems, servers (hardware and software) including application servers, mobile computing devices (e.g., smartphones, smart wearable devices, handheld computers, tablets, laptops, etc.), and cloud-based systems.

[0174] In some embodiments, method 1000 may be implemented in a first entity. For example, the first entity may comprise at least one server or computer system associated with at least one of a pharmaceutical provider or a medical device provider such as PMDP130 and / or SE150. In some embodiments, the first entity may interact with one or more second entities. The second entities may comprise one or more servers or computer systems associated with a healthcare provider such as HCP120, an insurer such as payer140, or a patient170, or a pharmacy. In some embodiments, the first entity and one or more second entities may form computing nodes in a distributed computing system, and the multidimensional blockchain may form part of a permissioned private blockchain platform such as a permissioned private blockchain platform.

[0175] In some embodiments, method 1000 may be invoked when an entity, such as a first entity, initiates a transaction (having, for example, a transaction ID and / or transaction type) to add a block to a locally maintained blockchain. Adding a block to the local blockchain may involve input from one or more other entities, and a permissioned private blockchain platform and / or the first entity may invoke method 1000.

[0176] In some embodiments, in step 1010, aggregate demographic information associated with a first set of health parameters and / or one or more population segments may be obtained by a first entity. In a clinical trial setting, the aggregate demographic information may include patient pre-cleaning information (e.g., as in subblock 480-1) which may be obtained by SE150 from one or more HCP120. In a drug / device deployment setting, the aggregate demographic information may include demographic criteria 610 associated with the drug / device deployment, which may include risk factors (e.g., associated with a disease outbreak) and location information (e.g., where a disease outbreak is prevalent, emerging, or accelerating). In a drug / device deployment setting, the aggregate demographic information may be obtained by PMDP130 from a public health entity (PHE), such as PHE180.

[0177] In step 1020, the first entity may receive one or more encrypted first electronic health record (EHR) subblocks that can be decrypted by the first entity, the one or more first EHR subblocks including (a) patient profile information relating to one or more patients, and (b) corresponding patient medical history for one or more patients.

[0178] For example, SE150 may receive one or more EHR subblocks 280 having corresponding patient profile and medical history information (which may, in some cases, be non-PII information). The patient profile information for each patient may include corresponding demographic information of the individual patient (e.g., age, sex, location, race, etc.), and the corresponding patient medical history may include one or more of the corresponding current and past patient's medical conditions, or the corresponding current and past patient's diagnoses, or the corresponding current and past patient's treatments, or the corresponding current and past patient's medical conditions.

[0179] As another example, PMDP130 may receive one or more EHR subblocks 280 containing corresponding patient profiles and (possibly non-PII) medical history information for drug / device deployment.

[0180] In step 1030, the first entity may determine a subset of candidate patients from one or more patients who are eligible for at least one treatment, based on a comparison of information in one or more EHR subblocks with corresponding eligibility criteria for at least one treatment, the corresponding eligibility criteria being based on one or more of a first set of health parameters or aggregate demographic information. For example, in a clinical trial setting, information in an EHR subblock (e.g., subblock 280) may be compared with eligibility criteria for the trial (e.g., health parameters in subblock 480-1) to determine candidate patients who are eligible to participate in the trial. As another example, in a drug / device deployment setting, information in an EHR subblock (e.g., subblock 280) may be compared with eligibility criteria for drug / device deployment (e.g., aggregate demographic information that may be at high risk, e.g., age group, occupation, location, etc.) to determine candidate patients who are eligible to receive the drug / device preferentially.

[0181] In step 1040, the first entity may transmit one or more encrypted first subblocks that can be decrypted by one or more corresponding second entities, each of which transmits a first block containing at least one candidate patient profile and at least one medical information associated with a treatment. For example, in a clinical trial setting, SE130 may transmit candidate patient profiles corresponding to selected candidate patients to HCP120. In another example, in a drug / device deployment setting, PMDP130 may transmit candidate patient profiles corresponding to candidate patients eligible to receive the drug / device on a priority basis to HCP120.

[0182] In some embodiments, in step 1050, the first entity may receive a transaction block having transaction confirmation, and in response to receiving the transaction block, may extend the multidimensional blockchain. The multidimensional blockchain may be extended by a multidimensional block formed by linking (i) a transaction block containing treatment deployment-related information associated with at least one treatment, (ii) a drug device information (DIR) block containing medical information associated with at least one treatment, and (iii) an EHR block containing at least one candidate patient profile information, a corresponding candidate patient medical history for at least one candidate patient, and prescription information for at least one treatment. For example, in a clinical trial setting, a multidimensional block (for extending the multidimensional blockchain) may include a transaction block (e.g., HTR500) having information about a transaction, and a DIR block (e.g., DIR record 300) having medical information associated with at least one treatment, linked to an EHR block (e.g., EHR record 200) containing candidate patient profile information for a candidate patient whose participation in the clinical trial has been confirmed.

[0183] As outlined above, in step 1030, at least one treatment may form part of at least one clinical trial. At least one clinical trial may be associated with a corresponding clinical trial protocol, which includes corresponding eligibility criteria. In some embodiments, the corresponding eligibility criteria may include one or more corresponding exclusion criteria for determining one or more patients who are ineligible to be included in a subset of candidate patients, and one or more corresponding inclusion criteria for determining one or more patients who may be eligible to be included in a subset of candidate patients. In some embodiments, method 1000 may be initiated in response to approval of a corresponding clinical trial protocol associated with at least one clinical trial. At least one clinical trial may be associated with one or more drugs, or one or more biologics, or one or more medical devices, or a combination thereof.

[0184] Furthermore, in step 1040, the multidimensional block may be further extended with a clinical trial record (CTR) block (e.g., CTR400) which includes at least one candidate patient profile, medical information associated with at least one treatment, and a corresponding clinical trial protocol, the clinical trial protocol further including a first set of health parameters.

[0185] In some embodiments, in method 1000, the first entity may, in response to the transmission of one or more encrypted first subblocks (e.g., in step 1040) and before the receipt of the transaction block (e.g., in step 1050), further receive at least one encrypted second EHR subblock that can be decrypted by the first entity, wherein at least one second EHR subblock includes at least one candidate patient profile and corresponding patient consent from at least one candidate patient to participate in at least one clinical trial. For example, the second EHR subblock may include the candidate patient's consent to participate in the clinical trial, along with the candidate patient profile. In some embodiments, the patient profile information in the first EHR block (e.g., in step 1020) may include non-personally identifiable (non-PII) information, and the at least one candidate patient profile information in the second EHR block may include PII information.

[0186] As outlined above, in step 1030, in some cases, at least one treatment may be associated with the deployment of at least one drug and / or device. For example, a drug / device deployment may be initiated in response to a public health emergency, and eligibility criteria may further be based on risk parameters associated with the public health emergency, where health parameters include risk parameters. Risk parameters may include locations at risk, and aggregate demographic information corresponding to a population segment may indicate a population at risk from the public health emergency. For example, a public health emergency could be a disease outbreak, e.g., a localized disease outbreak, an epidemic, or a pandemic. In the emergency identified above, it may be advantageous to deploy preventive measures (e.g., vaccines), other preventive devices (e.g., protective equipment), treatments (e.g., to alleviate symptoms), therapeutic agents (e.g., cures), and / or other drugs and / or devices within the population based on demographics and / or risk. For example, it may be advantageous to deploy treatments to first responders, healthcare workers, emergency / essential personnel, and / or other population segments that may be particularly vulnerable. Furthermore, in some cases (e.g., the Covid-19 pandemic), large-scale drug / device deployment may occur after the successful completion of clinical trials. Therefore, the technologies presented herein can facilitate more effective pre-screening and selection of patients, faster initiation of clinical trials, and effective drug / device deployment upon completion of clinical trials, thereby supporting efforts to address public health emergencies.

[0187] Figure 11 shows a schematic diagram of an exemplary computer 1100 or computing device capable of promoting security and interoperability in a healthcare system. In some embodiments, computer 1100 can act as a host and / or interact with a permissioned private blockchain platform. Computer 110 may be a computing device associated with entities (e.g., HCP120, PMDP130, payer140, SE150, pharmacy160, and / or PHE180) and / or a patient170, and / or may be used to run a permissioned blockchain platform. Computer 130 is merely an example, and several computers may be used in a networked and / or distributed manner to perform the methods and process flows disclosed herein.

[0188] In some embodiments, the exemplary computer 1100 may include (physical) servers for one or more entities (e.g., HCP120, PMDP130, payer140, SE150, pharmacy160, and / or PHE180), or may run (physical) servers (e.g., application servers). In some embodiments, one computer 1100 may execute some or all of the process flows and / or methods and / or other technologies disclosed herein, including those shown in Figures 7 to 10. In some embodiments, the computer 1100 may form part of a distributed computing system and may run a permissioned private blockchain platform. In some embodiments, the distributed computing system and / or computer 1100 may be cloud-based. In some embodiments, the computer 1100 may be a mobile computing device such as a smartphone, tablet, handheld, notebook, and / or laptop, and may run an application for interacting with other computers 1100 and / or other applications to execute the technologies disclosed herein.

[0189] In some embodiments, the computer 1100 / processor 1150 may be capable of processing transaction requests, including requests related to adding blocks to a blockchain, including a multidimensional blockchain. Furthermore, the computer 1100 / processor 1150 may be capable of running encryption and / or decryption algorithms, obtaining hashes of information blocks, verifying hashes, and performing digital signatures, and may be capable of performing and / or supporting various methods to facilitate security and authentication. Authentication may refer to both verifying the integrity of stored information (e.g., within blocks in the blockchain to determine any unauthorized alterations) and ensuring that entities accessing a permissioned private blockchain platform are trustworthy and have permission to perform any requested transactions. In some embodiments, the computer 1100 / processor 1150 may also extend (create or add to) the blockchain with new blocks (including extending a multidimensional blockchain with multidimensional blocks).

[0190] In some embodiments, the computer 1100 / processor 1150 can also store and execute smart contracts associated with the blockchain to realize agreements related to privacy, information sharing, contract execution, etc., among entities (e.g., HCP120, PMDP130, payer140, PHE180, pharmacy160, and / or patient170).

[0191] In some embodiments, the computer 1100 / processor 1150 may be capable of mathematically analyzing and statistically compiling health-related data, including determining the treatment class associated with a treatment (e.g., drug class, device class, and / or procedure class), determining cost metrics and priority scores individually and collectively for population segments, and using patient criteria to filter and / or narrow patient selection for clinical trials. In some embodiments, the computer 1100 / processor 1150 may also be capable of initiating the display of information on a smartphone (e.g., on a display 1170) (e.g., using a graphical user interface (GUI)). The computer 1100 / processor 1150 may be capable of determining relationships between various health parameters using machine learning techniques. For example, the computer 1100 / processor 1150 may comprise one or more neural network processors and / or distributed processors that can be configured as neural networks and / or may be capable of running software for modeling and / or simulating neural networks that can be used to perform machine learning. For example, PMDP130 can tailor drug use using machine learning-based RWE information (e.g., demographic information, side effects, drugs used in combination with specific drugs of interest, therapeutic outcomes, etc.) available through multidimensional blocks. For instance, machine learning can be used to determine effective doses, target drugs based on demographics, improve drug interaction information, enhance safety, and determine the relative effectiveness of different modes of administration.

[0192] In some embodiments, computer 1100 may be coupled to other computers using a communication / network interface 1102 which may include wired (e.g., Ethernet including Gigabit Ethernet) and wireless interfaces. The wireless interface may be based on wireless wide area network (WWAN) standards such as cellular standards including 3G, 4G, and 5G standards, the IEEE 802.11x standard widely known as Wi-Fi, and / or wireless personal area networks (e.g., Bluetooth, near-field communication (NFC), etc.). In some embodiments, computer 110 may include a global positioning system and / or location determination unit to automatically determine the location (e.g., a patient), which may be used in conjunction with the technologies disclosed in Figures 7-10.

[0193] The computer 1100 may include a memory 1104 which may include one or more of the following: read-only memory (ROM), programmable read-only memory (PROM), various types of random access memory (RAM), non-volatile RAM, etc. The memory 1104 may be implemented inside or outside the processor 1150. As used herein, the term “memory” refers to any type of memory, whether long-term, short-term, volatile, non-volatile, or otherwise, and is not limited to any particular type of memory, the number of memory units, or the type of medium in which the memory is stored.

[0194] Memory may include cache memory, primary memory, and secondary memory. Secondary memory may include computer-readable media 1120. Computer-readable media may include magnetic and / or optical media, which may be removable media as they are. Removable media may include optical discs such as compact discs (CDs), laser discs, digital video discs (DVDs), Blu-ray discs, and other optical media, and may further include USB drives, flash drives, solid-state drives, memory cards, etc. Computer 1100 may include storage devices 1160 which may include hard drives, solid-state drives (SSDs), flash memory, other non-volatile storage devices, and cloud-based storage devices.

[0195] The communication / network interface 1102, storage device 1160, memory 1104, and computer-readable medium 1120 can be connected to the processor 1150 using a connection 1106 that can take the form of a bus, line, fiber, link, or the like.

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

[0197] In the case of firmware and / or software implementations, the method can be implemented using microcode, procedures, functions, etc., that perform the functions described herein. The method can be implemented using any machine-readable medium that clearly embodies the instructions. For example, the software may be stored in the storage device 1160 and / or on a removable computer-readable medium. The program code may reside in the computer-readable medium 1120, the storage device 1160, and / or memory 1104 and can be read and executed by the processor 1150.

[0198] When implemented in firmware and / or software, the functionality may also be stored as one or more instructions or codes in computer-readable media 1120, storage device 1160, and / or memory 1104. Examples include computer-readable media encoded using data structures and computer programs. For example, computer-readable media 1120 may include program code stored therein that supports methods for promoting healthcare system security and advancing system interoperability, including supporting multidimensional blockchains, smart contracts, consensus determination, and performing other functions associated with permissioned private blockchain platforms as described herein.

[0199] The processor 1150 can be implemented using a combination of hardware, firmware, and software. In some embodiments, the computer 1100 may be coupled to a display to facilitate GUI browsing and interaction with administrators and other users.

[0200] While this disclosure is described in conjunction with specific embodiments for guidance purposes, it is not limited thereto. Various adaptations and modifications can be made to this disclosure without departing from the scope of the invention. Accordingly, the spirit and scope of the appended claims should not be limited to the foregoing description. The present invention includes the following embodiments. [Aspect 1] A method executed by a processor in a first entity, To obtain a first set of health parameters and aggregate demographic information associated with one or more population segments, Receiving one or more encrypted first electronic health record (EHR) subblocks decryptable by the first entity, wherein the one or more first EHR subblocks include (a) patient profile information corresponding to one or more patients, and (b) corresponding patient medical history for the one or more patients. Determining from the one or more patients a subset of multiple candidate patients eligible for at least one treatment, based on a comparison of information in one or more EHR subblocks with corresponding eligibility criteria for the at least one treatment, wherein the corresponding eligibility criteria are based on a first set of health parameters or one or more of the aggregate demographic information. Transmitting one or more encrypted first subblocks decryptable by one or more corresponding second entities, wherein each of the transmitted first subblocks includes at least one candidate patient profile and medical information associated with at least one treatment. A method performed by a processor, which involves extending a multidimensional blockchain in response to receiving a transaction block having transaction confirmation, wherein the multidimensional blockchain is extended with a multidimensional block formed by linking (i) the transaction block containing treatment deployment-related information associated with the at least one treatment, (ii) drug device information (DIR) blocks containing medical information associated with the at least one treatment, and (iii) EHR blocks containing information on the at least one candidate patient profile, corresponding candidate patient medical history for the at least one candidate patient, and prescription information for the at least one treatment. [Aspect 2] A method performed by a processor according to Embodiment 1, wherein the at least one treatment forms part of at least one clinical trial, and the at least one clinical trial is associated with a corresponding clinical trial protocol including the corresponding eligibility criteria. [Aspect 3] The multidimensional block is further extended with a clinical trial record (CTR) block comprising the at least one candidate patient profile, the medical information associated with the at least one treatment, and the corresponding clinical trial protocol, wherein the clinical trial protocol further comprises a first set of health parameters, the method executed by the processor according to embodiment 2. [Aspect 4] A method performed by the processor according to Embodiment 2, wherein the corresponding eligibility criteria include one or more corresponding exclusion criteria for determining one or more patients who are ineligible to be included in the subset of multiple candidate patients, and one or more corresponding inclusion criteria for determining one or more patients who may be eligible to be included in the subset of multiple candidate patients. [Aspect 5] The method described above is performed by the processor according to embodiment 2, and is initiated in response to approval of the corresponding clinical trial protocol associated with the at least one clinical trial. [Aspect 6] The aforementioned at least one clinical trial, One or more drugs, One or more biological products, One or more medical devices, or A method performed by the processor described in Embodiment 2, associated with these combinations. [Aspect 7] The method performed by the processor according to embodiment 2, wherein the corresponding patient profile information for each patient includes demographic information for the corresponding individual patient. [Aspect 8] A method performed by the processor according to embodiment 2, wherein for each of the one or more patients, the corresponding patient history includes one or more of the following: the current and past medical condition of the corresponding patient, the diagnosis of the current and past patient, the treatment of the current and past patient, or the current and past medical condition of the corresponding patient. [Aspect 9] A method performed by a processor according to Embodiment 2, further comprising receiving at least one encrypted second EHR subblock decryptable by the first entity in response to the transmission of the one or more encrypted first subblocks and prior to the reception of the transaction block, wherein the at least one second EHR subblock includes the at least one candidate patient profile and the corresponding patient consent of the at least one candidate patient to participate in the at least one clinical trial. [Aspect 10] A method performed by a processor according to embodiment 9, wherein the corresponding patient profile information in the first EHR subblock includes non-personally identifiable (PII) information, and the information of the at least one candidate patient profile in the second EHR subblock includes PII information. [Aspect 11] A method performed by the processor according to embodiment 1, wherein the at least one treatment is associated with at least one drug delivery. [Aspect 12] The method is performed by the processor according to Embodiment 11, wherein the at least one drug deployment is initiated in response to a public health emergency, the corresponding eligibility criteria are further based on risk parameters associated with the public health emergency, and the first set of health parameters includes the risk parameters. [Aspect 13] A method performed by a processor according to embodiment 12, wherein the risk parameter includes a location at risk, and the one or more population segments represent a population at risk from the public health emergency. [Aspect 14] A computing device for a first entity, Memory and Communication interface, The memory and the communication interface are coupled to a processor, and the processor is To obtain a first set of health parameters and aggregate demographic information associated with one or more population segments, Receiving one or more encrypted first electronic health record (EHR) subblocks decryptable by the first entity, wherein the one or more first electronic health record (EHR) subblocks include (a) patient profile information corresponding to one or more patients, and (b) corresponding patient medical history for the one or more patients. Determining from the one or more patients a subset of multiple candidate patients eligible for at least one treatment, based on a comparison of information within one or more EHR subblocks with corresponding eligibility criteria for at least one treatment, wherein the corresponding eligibility criteria are determined based on a first set of health parameters or one or more of the aggregate demographic information. Transmitting one or more encrypted first subblocks decryptable by one or more corresponding second entities, each of which includes at least one candidate patient profile and medical information associated with at least one treatment. Extending a multidimensional blockchain in response to receiving a transaction block having transaction confirmation, wherein the multidimensional blockchain is extended by a multidimensional block formed by linking (i) the transaction block containing treatment deployment-related information associated with the at least one treatment, (ii) a drug device information (DIR) block containing the medical information associated with the at least one treatment, and (iii) an EHR block containing information on the at least one candidate patient profile, corresponding candidate patient medical history for the at least one candidate patient, and prescription information for the at least one treatment. A computing device configured to perform the following actions. [Aspect 15] The computing device according to embodiment 14, wherein the at least one treatment forms part of at least one clinical trial, and the at least one clinical trial is associated with a corresponding clinical trial protocol that includes the corresponding eligibility criteria. [Aspect 16] The computing device according to embodiment 14, wherein the at least one treatment is associated with at least one drug delivery. [Aspect 17] The computing device according to embodiment 16, wherein the at least one drug deployment is initiated in response to a public health emergency, the eligibility criteria are further based on risk parameters associated with the public health emergency, and the health parameters include the risk parameters. [Aspect 18] A non-temporary computer-readable medium containing executable instructions, wherein the executable instructions are provided to a processor. To obtain a first set of health parameters and aggregate demographic information associated with one or more population segments, Receiving one or more encrypted first electronic health record (EHR) subblocks decryptable by a first entity, wherein the one or more first electronic health record (EHR) subblocks include (a) patient profile information corresponding to one or more patients, and (b) corresponding patient medical history for the one or more patients. Determining from the one or more patients a subset of multiple candidate patients eligible for at least one treatment based on a comparison of information in one or more EHR subblocks with corresponding eligibility criteria for the at least one treatment, wherein the corresponding eligibility criteria are determined based on a first set of health parameters or one or more of the aggregate demographic information. Transmitting one or more encrypted first subblocks decryptable by one or more corresponding second entities, each of which includes at least one candidate patient profile and medical information associated with at least one treatment. Extending a multidimensional blockchain in response to receiving a transaction block having transaction confirmation, wherein the multidimensional blockchain is extended by a multidimensional block formed by linking (i) the transaction block containing treatment deployment-related information associated with the at least one treatment, (ii) a drug device information (DIR) block containing the medical information associated with the at least one treatment, and (iii) an EHR block containing information on the at least one candidate patient profile, corresponding candidate patient medical history for the at least one candidate patient, and prescription information for the at least one treatment. A non-temporary computer-readable medium configured to perform the following actions. [Aspect 19] A non-temporary computer-readable medium according to aspect 18, wherein the at least one treatment forms part of at least one clinical trial, and the at least one clinical trial is associated with a corresponding clinical trial protocol including the corresponding eligibility criteria. [Aspect 20] The non-temporary computer-readable medium according to embodiment 18, wherein the at least one treatment is associated with at least one drug delivery.

Claims

1. A method executed by a processor in a first entity, To obtain a first set of health parameters and aggregate demographic information associated with one or more population segments, Receiving one or more encrypted first electronic health record (EHR) subblocks decryptable by the first entity, wherein the one or more first EHR subblocks include (a) patient profile information corresponding to one or more patients, and (b) corresponding patient medical history for the one or more patients. Determining from the one or more patients a subset of multiple candidate patients eligible for at least one treatment, based on a comparison of information within one or more EHR subblocks with corresponding eligibility criteria for the at least one treatment, wherein the corresponding eligibility criteria are based on a first set of health parameters or one or more of the aggregate demographic information. Transmitting one or more encrypted first subblocks decryptable by one or more corresponding second entities, wherein each of the transmitted first subblocks includes at least one candidate patient profile and medical information associated with at least one treatment. A method performed by a processor, which involves extending a multidimensional blockchain in response to receiving a transaction block having transaction confirmation, wherein the multidimensional blockchain is extended with a multidimensional block formed by linking (i) the transaction block containing treatment deployment-related information associated with the at least one treatment, (ii) drug device information (DIR) blocks containing medical information associated with the at least one treatment, and (iii) EHR blocks containing information on the at least one candidate patient profile, corresponding candidate patient medical history for the at least one candidate patient, and prescription information for the at least one treatment.

2. A method performed by the processor according to claim 1, wherein the at least one treatment forms part of at least one clinical trial, and the at least one clinical trial is associated with a corresponding clinical trial protocol including the corresponding eligibility criteria.

3. The method executed by the processor according to claim 2, wherein the multidimensional block is further extended with a clinical trial record (CTR) block comprising the at least one candidate patient profile, the medical information associated with the at least one treatment, and the corresponding clinical trial protocol, the clinical trial protocol further comprising a first set of health parameters.

4. The method performed by the processor according to claim 2, wherein the corresponding eligibility criteria include one or more corresponding exclusion criteria for determining one or more patients who are ineligible to be included in the subset of candidate patients, and one or more corresponding inclusion criteria for determining one or more patients who may be eligible to be included in the subset of candidate patients.

5. The method described above is performed by the processor according to claim 2, and is initiated in response to approval of the corresponding clinical trial protocol associated with the at least one clinical trial.

6. The aforementioned at least one clinical trial, One or more drugs, One or more biological products, One or more medical devices, or A method performed by the processor according to claim 2, associated with these combinations.

7. The method performed by the processor according to claim 2, wherein the corresponding patient profile information for each patient includes demographic information for the corresponding individual patient.

8. A method performed by the processor according to claim 2, wherein for each of the one or more patients, the corresponding patient medical history includes one or more of the following: the current and past medical condition of the corresponding patient, the diagnosis of the current and past patient, the treatment of the current and past patient, or the current and past medical condition of the corresponding patient.

9. A method performed by the processor according to claim 2, further comprising receiving at least one encrypted second EHR subblock decryptable by the first entity in response to the transmission of the one or more encrypted first subblocks and prior to the reception of the transaction block, wherein the at least one second EHR subblock includes the at least one candidate patient profile and the corresponding patient consent of the at least one candidate patient to participate in the at least one clinical trial.

10. A method performed by the processor according to claim 9, wherein the corresponding patient profile information in the first EHR subblock includes non-personally identifiable (PII) information, and the information of the at least one candidate patient profile in the second EHR subblock includes PII information.

11. A method performed by the processor according to claim 1, wherein the at least one treatment is associated with at least one drug delivery.

12. A method performed by the processor according to claim 11, wherein the at least one drug deployment is initiated in response to a public health emergency, and the corresponding eligibility criteria are further based on risk parameters associated with the public health emergency, and the first set of health parameters includes the risk parameters.

13. A method performed by the processor according to claim 12, wherein the risk parameter includes a location at risk, and the one or more population segments represent a population at risk from the public health emergency.

14. A computing device for a first entity, Memory and Communication interface, The memory and the communication interface are coupled to a processor, and the processor is To obtain a first set of health parameters and aggregate demographic information associated with one or more population segments, Receiving one or more encrypted first electronic health record (EHR) subblocks decryptable by the first entity, wherein the one or more first electronic health record (EHR) subblocks include (a) patient profile information corresponding to one or more patients, and (b) corresponding patient medical history for the one or more patients. Determining from the one or more patients a subset of multiple candidate patients eligible for at least one treatment based on a comparison of information within one or more EHR subblocks with corresponding eligibility criteria for at least one treatment, wherein the corresponding eligibility criteria are determined based on a first set of health parameters or one or more of the aggregate demographic information. Transmitting one or more encrypted first subblocks decryptable by one or more corresponding second entities, each of which includes at least one candidate patient profile and medical information associated with at least one treatment. Extending a multidimensional blockchain in response to receiving a transaction block having transaction confirmation, wherein the multidimensional blockchain is extended by a multidimensional block formed by linking (i) the transaction block containing treatment deployment-related information associated with the at least one treatment, (ii) a drug device information (DIR) block containing the medical information associated with the at least one treatment, and (iii) an EHR block containing information on the at least one candidate patient profile, corresponding candidate patient medical history for the at least one candidate patient, and prescription information for the at least one treatment. A computing device configured to perform the following actions.

15. The computing device according to claim 14, wherein the at least one treatment forms part of at least one clinical trial, and the at least one clinical trial is associated with a corresponding clinical trial protocol that includes the corresponding eligibility criteria.

16. The computing device according to claim 14, wherein the at least one treatment is associated with at least one drug delivery.

17. The computing device according to claim 16, wherein the at least one drug deployment is initiated in response to a public health emergency, the eligibility criteria are further based on risk parameters associated with the public health emergency, and the health parameters include the risk parameters.

18. A non-temporary computer-readable medium containing executable instructions, wherein the executable instructions are provided to a processor. To obtain a first set of health parameters and aggregate demographic information associated with one or more population segments, Receiving one or more encrypted first electronic health record (EHR) subblocks decryptable by a first entity, wherein the one or more first electronic health record (EHR) subblocks include (a) patient profile information corresponding to one or more patients, and (b) corresponding patient medical history for the one or more patients. Determining from the one or more patients a subset of multiple candidate patients eligible for at least one treatment based on a comparison of information within one or more EHR subblocks with corresponding eligibility criteria for the at least one treatment, wherein the corresponding eligibility criteria are determined based on a first set of health parameters or one or more of the aggregate demographic information. Transmitting one or more encrypted first subblocks decryptable by one or more corresponding second entities, each of which includes at least one candidate patient profile and medical information associated with at least one treatment. Extending a multidimensional blockchain in response to receiving a transaction block having transaction confirmation, wherein the multidimensional blockchain is extended by a multidimensional block formed by linking (i) the transaction block containing treatment deployment-related information associated with the at least one treatment, (ii) a drug device information (DIR) block containing the medical information associated with the at least one treatment, and (iii) an EHR block containing information on the at least one candidate patient profile, corresponding candidate patient medical history for the at least one candidate patient, and prescription information for the at least one treatment. A non-temporary computer-readable medium configured to perform the following actions.

19. The non-temporary computer-readable medium according to claim 18, wherein the at least one treatment forms part of at least one clinical trial, and the at least one clinical trial is associated with a corresponding clinical trial protocol including the corresponding eligibility criteria.

20. The non-temporary computer-readable medium according to claim 18, wherein the at least one treatment is associated with at least one drug delivery.

21. The non-temporary computer-readable medium according to claim 19, wherein the corresponding eligibility criteria include one or more corresponding exclusion criteria for determining one or more patients who are ineligible to be included in the subset of candidate patients, and one or more corresponding inclusion criteria for determining one or more patients who may be eligible to be included in the subset of candidate patients.

Images