CN117043870A

CN117043870A - Systems and methods for healthcare interoperability

Info

Publication number: CN117043870A
Application number: CN202280021344.3A
Authority: CN
Inventors: J·李; J·莫里穆拉; J·维格; M·克萨达; M·莫斯切蒂
Original assignee: Janssen Pharmaceutica NV
Current assignee: Janssen Pharmaceutica NV
Priority date: 2021-01-14
Filing date: 2022-01-11
Publication date: 2023-11-10
Also published as: CA3208087A1; JP2024503065A; EP4278355A1; BR112023013867A2; AU2022209069A1; WO2022152695A1

Abstract

Embodiments facilitate interoperability and safe determination of healthcare costs. An entity may receive a first Electronic Health Record (EHR) sub-block having patient medical coverage information and first treatments, and may transmit a first device medication information (DIR) sub-block including a first treatment category corresponding to each first treatment, a first treatment category member corresponding to each first treatment category, and corresponding first treatment category member cost information. In response, the entity may receive a second EHR sub-block that includes second therapies, each second therapy associated with a corresponding first therapy and selected from a corresponding first therapy class member. Upon receiving a transaction confirmation, the entity may augment the multidimensional block chain with multidimensional blocks formed by linking: a DIR block including second therapy information, an EHR block including information based on the second EHR sub-block, and a transaction block. Payment assistance information determined from the second EHR block is transmitted to the patient.

Description

Systems and methods for healthcare interoperability

Cross Reference to Related Applications

The present application claims the benefit and priority of U.S. patent application No. 17/149,703, entitled "SYSTEM AND METHOD FOR HEALTHCARE SECURITY AND INTEROPERABILITY", filed on day 2021, month 14, which is a continuation-in-part application of U.S. patent application No. 16/703,848, entitled "SYSTEM AND METHOD FOR HEALTHCARE SECURITY AND INTEROPERABILITY" (now U.S. patent No. 10,931,437), filed on day 2019, month 1, month 18, which is a continuation-in-part application of U.S. patent application No. 16/251,980, entitled "SYSTEM AND METHOD FOR HEALTHCARE SECURITY AND INTEROPERABILITY" (now U.S. patent No. 10,541,807). The above identified applications are hereby incorporated by reference in their entirety.

Technical Field

The subject matter disclosed herein relates to the safety and interoperability of healthcare systems while facilitating treatment selection and cost-effective transparency.

Background

Healthcare information systems face compliance challenges that limit interoperability. For example, the stored information may be subject to various privacy regulations, such as "health insurance privacy and liability Act" (HIPAA). HIPAA-specified privacy terms establish national standards for protecting personal medical records and other personal health information when conducting healthcare transactions electronically. These regulations may cover privacy (e.g., which entities have access to information), content (which information is accessible to authorized entities), security (how information is protected from access by unauthorized entities at the time of storage and during electronic communications), and integrity (accuracy and authenticity of information). In addition, information of commercial value may be protected by an organization policy that may restrict sharing of information with third parties (e.g., as a trade secret and/or for business or commercial reasons). Regulations such as the European Union (EU) General Data Protection Regulations (GDPR) and state regulations may also affect information collection, storage, sharing and communication. These regulations have affected the information available to healthcare market participants and led to the generation of an organization "data island" in which the information available to an entity is isolated, even when it may be useful on the system (e.g., for another non-competing entity). Such partitioning of information has resulted in increased system costs (e.g., costs of treatment alternatives considered by the patient or medical provider, treatment location, etc.), increased patient risk (e.g., due to drug interactions, prescription abuse, etc.), and limited efficacy of outcome-based medical treatments or remediation methods (e.g., making it more difficult and expensive to determine when desired outcomes have been achieved or to compare indicators in methods that achieve similar outcomes). Accordingly, there is a need for systems and techniques that address one or more of the above-mentioned problems, which will help facilitate the security of healthcare information while improving interoperability between market participants.

Disclosure of Invention

In some embodiments, a processor-implemented method may include: receiving at least one encrypted first Electronic Health Record (EHR) sub-block decryptable by the first entity, wherein the at least one EHR sub-block includes patient medical coverage information for a patient and one or more first therapies; transmitting, in response to the first EHR sub-block, at least one encrypted first medication/Device Information (DIR) sub-block decryptable by at least one corresponding second entity, wherein the at least one first DIR sub-block includes, for each of the one or more first treatments, a corresponding first treatment category, one or more corresponding first treatment category members associated with each corresponding first treatment category, and includes, for each first treatment category member, corresponding first treatment category member cost information; in response to the first DIR sub-block, receiving an encrypted second EHR sub-block decryptable by the first entity, wherein the second EHR sub-block includes one or more second therapies, wherein each second therapy of the one or more second therapies is associated with a corresponding first therapy, and each second therapy is selected from the corresponding first therapy class members associated with the corresponding first therapy; and augmenting a multidimensional block chain in response to the transaction confirmation, wherein the multidimensional block chain is augmented with a multidimensional block formed by linking: a DIR block including information associated with the one or more second therapies, an EHR block including information associated with the second EHR sub-block, and a transaction block.

In another aspect, a computing device for a first entity may include: a memory, a communication interface, and a processor coupled to the memory and the communication interface. In some embodiments, the processor may be configured to: receiving at least one encrypted first Electronic Health Record (EHR) sub-block decryptable by the first entity, wherein the at least one EHR sub-block includes patient medical coverage information for a patient and one or more first therapies; transmitting, in response to the first EHR sub-block, at least one encrypted first medication/Device Information (DIR) sub-block decryptable by at least one corresponding second entity, wherein the at least one first DIR sub-block includes, for each of the one or more first treatments, a corresponding first treatment category, one or more corresponding first treatment category members associated with each corresponding first treatment category, and includes, for each first treatment category member, corresponding first treatment category member cost information; in response to the first DIR sub-block, receiving an encrypted second EHR sub-block decryptable by the first entity, wherein the second EHR sub-block includes one or more second therapies, wherein each second therapy of the one or more second therapies is associated with a corresponding first therapy, and each second therapy is selected from the corresponding first therapy class members associated with the corresponding first therapy; and augmenting a multidimensional block chain in response to the transaction confirmation, wherein the multidimensional block chain is augmented with a multidimensional block formed by linking: a DIR block including information associated with the one or more second therapies, an EHR block including information associated with the second EHR sub-block, and a transaction block.

In another aspect, an apparatus may include: means for receiving at least one encrypted first Electronic Health Record (EHR) sub-block decryptable by a first entity, wherein the at least one EHR sub-block includes patient medical coverage information for a patient and one or more first therapies; means for transmitting, in response to the first EHR sub-block, at least one encrypted first medication/Device Information (DIR) sub-block decryptable by at least one corresponding second entity, wherein the at least one first DIR sub-block includes, for each of the one or more first treatments, a corresponding first treatment category, one or more corresponding first treatment category members associated with each corresponding first treatment category, and includes, for each first treatment category member, corresponding first treatment category member cost information; means for receiving, in response to the first DIR sub-block, an encrypted second EHR sub-block that is decryptable by the first entity, wherein the second EHR sub-block includes one or more second treatments, wherein each of the one or more second treatments is associated with a corresponding first treatment and each second treatment is selected from the corresponding first treatment class members associated with the corresponding first treatment; and means for augmenting a multidimensional block chain in response to the transaction confirmation, wherein the multidimensional block chain is augmented with a multidimensional block formed by linking: a DIR block including information associated with the one or more second therapies, an EHR block including information associated with the second EHR sub-block, and a transaction block.

In some embodiments, a non-transitory computer readable medium may include executable instructions for configuring a processor to: receiving at least one encrypted first Electronic Health Record (EHR) sub-block decryptable by the first entity, wherein the at least one EHR sub-block includes patient medical coverage information for a patient and one or more first therapies; transmitting, in response to the first EHR sub-block, at least one encrypted first medication/Device Information (DIR) sub-block decryptable by at least one corresponding second entity, wherein the at least one first DIR sub-block includes, for each of the one or more first treatments, a corresponding first treatment category, one or more corresponding first treatment category members associated with each corresponding first treatment category, and includes, for each first treatment category member, corresponding first treatment category member cost information; in response to the first DIR sub-block, receiving an encrypted second EHR sub-block decryptable by the first entity, wherein the second EHR sub-block includes one or more second therapies, wherein each second therapy of the one or more second therapies is associated with a corresponding first therapy, and each second therapy is selected from the corresponding first therapy class members associated with the corresponding first therapy; and augmenting a multidimensional block chain in response to the transaction confirmation, wherein the multidimensional block chain is augmented with a multidimensional block formed by linking: a DIR block including information associated with the one or more second therapies, an EHR block including information associated with the second EHR sub-block, and a transaction block.

Additionally, in another aspect, a processor-implemented method may include: obtaining a first set of first treatments for the patient over a period of time from at least one encrypted first Health Transaction Record (HTR) sub-block decryptable by the first entity, wherein each first treatment comprises a first diagnostic code and a first treatment code; based on the first set, the following are obtained: (a) One or more second sets of second treatments, wherein each corresponding second treatment is associated with a different first treatment in the first set, and (b) a corresponding number of iterations for each second treatment; acquiring a set of available insurance plans available to the patient and corresponding coverage related information for each available insurance plan; obtaining a corresponding estimated plan-specific cost indicator for the patient based on the set of second treatments and the corresponding coverage related information for each insurance plan; and transmitting a first encrypted medication/Device Information Record (DIR) sub-block that is decryptable by at least one second entity, wherein the DIR sub-block includes cost metrics specific to the plans of the patient.

In some embodiments, a computing device for a first entity may include: a memory, a communication interface, and a processor coupled to the memory and the communication interface. In some embodiments, the processor may be configured to: obtaining a first set of first treatments for the patient over a period of time from at least one encrypted first Health Transaction Record (HTR) sub-block decryptable by the first entity, wherein each first treatment comprises a first diagnostic code and a first treatment code; acquiring based on the first group: (a) One or more second sets of second treatments, wherein each corresponding second treatment is associated with a different first treatment in the first set, and (b) a corresponding number of iterations for each second treatment; acquiring a set of available insurance plans available to the patient and corresponding coverage related information for each available insurance plan; obtaining a corresponding estimated plan-specific cost indicator for the patient based on the set of second treatments and the corresponding coverage related information for each insurance plan; and transmitting a first encrypted medication/Device Information Record (DIR) sub-block that is decryptable by at least one second entity, wherein the DIR sub-block includes cost metrics specific to the plans of the patient.

In another aspect, an apparatus may include: means for obtaining a first set of first treatments for the patient over a period of time from at least one encrypted first Health Transaction Record (HTR) sub-block decryptable by the first entity, wherein each first treatment comprises a first diagnostic code and a first treatment code; means for obtaining, based on the first set, the following: (a) One or more second sets of second treatments, wherein each corresponding second treatment is associated with a different first treatment in the first set, and (b) a corresponding number of iterations for each second treatment; means for obtaining a set of available insurance plans available to the patient and corresponding coverage related information for each available insurance plan; means for obtaining a corresponding estimated plan-specific cost indicator for the patient based on the set of second treatments and the corresponding coverage related information for each insurance plan; and means for transmitting a first encrypted drug/Device Information Record (DIR) sub-block that is decryptable by at least one second entity, wherein the DIR sub-block comprises cost metrics specific to the plans of the patient.

In some embodiments, a non-transitory computer readable medium may include executable instructions for configuring a processor to: obtaining a first set of first treatments for the patient over a period of time from at least one encrypted first Health Transaction Record (HTR) sub-block decryptable by the first entity, wherein each first treatment comprises a first diagnostic code and a first treatment code; acquiring based on the first group: (a) One or more second sets of second treatments, wherein each corresponding second treatment is associated with a different first treatment in the first set, and (b) a corresponding number of iterations for each second treatment; acquiring a set of available insurance plans available to the patient and corresponding coverage related information for each available insurance plan; obtaining a corresponding estimated plan-specific cost indicator for the patient based on the set of second treatments and the corresponding coverage related information for each insurance plan; and transmitting a first encrypted medication/Device Information Record (DIR) sub-block that is decryptable by at least one second entity, wherein the DIR sub-block includes cost metrics specific to the plans of the patient.

The disclosed methods may be performed by one or more of a mobile computing device, a computer (including a server), a cloud-based system, etc., using a computer-readable medium or computer-readable memory.

Drawings

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings.

Fig. 1 shows a schematic block diagram illustrating interactions between some entities associated with a conventional healthcare information system.

Fig. 2 shows an example electronic health record illustrating some example data fields in the record.

Fig. 3A and 3B illustrate portions of an exemplary medication/Device Information Record (DIR) for a medication.

FIG. 3C illustrates an exemplary data flow from an initial suggested prescription to an alternative that may be presented to a patient and/or HCP along with cost information.

FIG. 4 illustrates a portion of an exemplary Pharmacy Benefit Record (PBR) that may be maintained by a pharmacy benefit manager.

Fig. 5 illustrates an exemplary pharmacy prescription record that may be maintained by an entity, such as a pharmacy.

Fig. 6 illustrates an exemplary health transaction record.

FIG. 7A shows a flow chart illustrating an exemplary process flow for facilitating healthcare cost determination, healthcare information security, and interoperability among multiple entities.

FIG. 7B illustrates entities and layers associated with an exemplary platform that facilitates security and interoperability of healthcare systems.

Fig. 8 illustrates a flow chart of an exemplary method that facilitates healthcare information security and interoperability while facilitating patient treatment selection and treatment cost transparency.

FIG. 9 shows a flow chart illustrating an exemplary process flow that facilitates healthcare insurance selection and cost determination while maintaining healthcare information security and facilitating interoperability between multiple entities.

Fig. 10A and 10B illustrate a flow chart of an exemplary method that facilitates healthcare insurance selection and cost determination while maintaining healthcare information security and facilitating interoperability between multiple entities.

FIG. 11 illustrates a schematic diagram of an exemplary computer or computing device capable of facilitating security and improving interoperability of a healthcare system.

In the drawings, like reference numbers and designations in the various drawings depicting certain exemplary embodiments indicate like elements. For example, sub-blocks having similar information are referred to by the same reference numerals. Further, multiple instances of an element may be indicated by following a first digit of the element with letters or hyphens and second digits. For example, multiple instances of element 280 may be indicated as 280-1, 280-2, etc. When only the first digit is used to refer to such an element, it should be understood that any instance of the element (e.g., element 280 in the previous example would refer to elements 280-1, 280-2 …, and/or 280-N). In addition, in the following figures, asterisks ("×") associated with reference numerals indicate that an element (or some portion thereof) is repeatable (e.g., for each instance of the element). For example, the prescription may include several instances of the drug, and the dose field may be repeated for each instance of the drug.

The following figures also illustrate the hierarchical structure of records, which may include fields and subfields. The record includes any field (and some or all portions of the sub-blocks) that is part of the record. Similarly, a field includes any subfields. The subfields may include additional subfields.

Detailed Description

The disclosed embodiments facilitate the safety of a healthcare system while improving the integrity, interoperability, treatment options, and cost transparency of the healthcare system.

Fig. 1 shows a schematic block diagram illustrating interactions between some entities associated with a conventional healthcare information system 100. A healthcare transaction may involve several entities, each of which may have some transaction-related information that may be used to complete the transaction. Thus, in conventional systems, some limited information (e.g., limited by regulations, contracts, privacy concerns, confidentiality, and/or competitive reasons) may be exchanged between transaction entities in order to complete a transaction. As used herein, the term "entity" may refer to an individual (such as a patient or group of patients) or an organization that participates in a healthcare marketplace and/or to a computing system and information system (e.g., hardware and/or software) associated with the individual/group/organization that may participate in the healthcare marketplace on behalf of the individual/group/organization. For example, a computing system associated with one entity may process information and/or exchange information with a computing system associated with another entity. The exchange of information between entities may be performed in a secure manner (e.g., using encryption) and/or on an electronic platform (such as an information exchange and/or a transaction exchange) over a secure communication network and/or over the internet.

An entity such as a patient (not shown in fig. 1) may seek treatment for a medical condition afflicting the patient from another entity such as a healthcare provider (HCP) 120. The HCP 120 may use a Health Information (HI) database 125, which may be maintained by the HCP 120 and include patient coverage related information 124, to determine patient treatment information and patient insurance. In addition, the HCP 120 may recommend treatment for the patient's medical condition. When a treatment to be prescribed is recommended, the HCP 120 may send treatment information 123 to a drug provider and/or a medical device provider (PMDP) 130. The treatment information 123 sent to the PMDP 130 may not include any patient Personally Identifiable Information (PII).

Personally Identifiable Information (PII) is any data that may potentially be used to identify a particular individual. The term "non-PII" is used herein to modify information that does not include PII. For example, the patient data record (with PII) may include the patient's name, full address, other identifiers (e.g., insurance identifier, driver's license number, social security number, and/or other identifying information) along with health-related information. The PII in the patient data record may be removed to obtain a non-PII patient data record (without name, full address, and other identifying information). For example, the non-PII patient data records may include age, gender, medical history (e.g., medical conditions afflicting the patient, other medications the patient is using, etc.), treatment, and optionally (e.g., when appropriate) city, state, and/or zip code, and may include the complete address of the HCP 120 (where care is provided).

In response, the PMDP 130 may send the drug/device profile and the security information 133 to the HCP 120 based on the information in the drug/Device Information Record (DIR) database 135. DIR database 135 may include drug/device profiles and security information 133. Drug/device profile and safety information 133 may include information about drug characteristics such as dosage, mode of administration, absorption, metabolism, duration of action, toxicity, and interactions with food or other medications. Upon receipt of the medication/device data and the security information 133, the HCP may prescribe one or more medications and/or medical devices and/or procedures, or may revise the prescription based on the received medication/device data and the security information 133.

As shown in fig. 1, the HCP 120 may also securely send stored patient insurance and treatment (e.g., medical procedure related) information 124 to a payer/insurer (hereinafter referred to as "payer") 140, and prescription information 127 to the pharmacy 160. Prescription information 132 may include patient ID and treatment (e.g., medication and/or device) information. The insurance-related and therapy information 124 may include patient Identification (ID) information, insurance plan information, group ID information, suggested therapy information (e.g., one or more of medical procedure-related information, medication-related information, medical device-related information, etc.). While insurance-related and therapy information 124 may include some Personally Identifiable Information (PII), the shared PII information may be limited. For example, patient insurance and therapy information 124 may not include patient family history and/or other patient information (which may be part of HI database 125), but may not be related to coverage determination and/or cost determination, and/or may be blocked (e.g., by law/regulation) from sharing with payer 140.

The pharmacy 160 may use the received patient prescription information 127 to enter and/or update a Patient Prescription Information (PPI) database 155 and may send patient insurance coverage and treatment related information 163 to the pharmacy stakeholder (PBM) 150.

PBM 150 is an entity that plays a role in the acquisition of pharmaceutical products (drugs and/or devices) by patients. PBM 150 based on determining the price of the drug, PBM 150 may set or determine a retail price for the pharmaceutical product, obtain payment or rebate from the manufacturer based on the sales volume of the particular product or product basket, and in some cases, also obtain after-market price offers and payments from the pharmacy according to the "prescription schedule" of payer 140. The prescription schedule may be determined based on the coverage of the medication and the distribution of the cost of the medication (e.g., the proportion of payments to be provided by the patient and the proportion to be paid by the payer 140 for each covered medication): can be used for patients. In addition, the prescription schedule typically assigns the medication to one of a plurality of cost sharing levels. The prescription drug and the cost sharing level of the drug (both of which may depend on the patient's health or prescription coverage) may determine the cost of the patient on-the-fly at the pharmacy. For example, drugs in a preference level may have lower cost sharing requirements (e.g., lower co-insurance).

Thus, the final drug cost sharing by the patient at the pharmacy may depend on: (a) Planned free-of-claims (some specified amount that the patient will pay per planned term before payor cost sharing); (b) A common payment (fixed pay-as-you-go for each transaction as specified by the patient's health plan), and (c) a common insurance (percentage of medication costs to be borne by the patient after the claim and common payment requirements have been met). In some cases, based on patient qualification information, a drug/medical device provision (PMDP) 130 may provide prepaid assistance to the patient. The patient qualification information may include one or more of the following: health insurance coverage information, patient pay-in-charge costs (which may include one or more of common payments, common insurance and claim amounts for individual prescriptions or over a period of time), and demographic information associated with the patient (e.g., one or more of patient location, age, disability information, income, prescription costs, etc.). Conventionally, patient payment assistance may be provided as a physical patient-specific rebate card applied to the patient's pay-as-you-go cost. Patient payment assistance may be provided by the PMDP 130 through a patient access procedure, which in some cases may be managed separately according to applicable laws and regulations. Due in part to the complexity of cost determination due to the number of entities involved and the data partitioning of the entities, patient cost information is not generally available to the HCP 120 and/or the patient at the time the HCP prescribes (and may only be available after the pharmacy 160 and/or the PBM 150 determines patient cost sharing).

For medical procedures, the payer 140 may compare the received patient coverage related information 124 with information in the plan/coverage database 145 to determine coverage for the patient. Based on the coverage information, the payer 140 may update the transaction information database 147 and reply to the HCP 120 with the confirmed and/or additional/updated patient coverage related information 124. Patient coverage related information 124 may include approval/denial information, coverage information related to suggested treatments, and cost and payment related information such as patient co-payment, billing codes, and the like. If the payer refuses approval, or the coverage for the proposed treatment is insufficient and/or the patient's cost criteria are not met, the HCP 120 may propose a revision, which may result in further exchange of information between the HCP 120 and the payer 140. Interaction between the HCP 120, payer 140, and PMDP 130 may continue until the HCP 120 completes the following treatment plan: (a) acceptable to the patient, (b) meeting safety and efficacy concerns, and (c) overrideable and/or approved by the payer 140.

For drugs and/or devices, the PBM 150 may use the coverage related information received from the patient (or HCP) and information in the Pharmacy Benefit Information (PBI) database 155 to determine patient coverage, whether prescription drugs are covered, pay-as-you-go patient drug costs, insurance contributions to drug costs, and the like. When a treatment (e.g., a drug and/or device) is covered, the PBM 150 may send cost information 153 to the pharmacy 160. Cost information 153 (which may include one or more of patient pay-off costs, insurance costs, cost details, and/or other information) may be sent to the pharmacy 160, which may update the PPI database 155 using the received cost information 153. If the patient later wishes to change the prescription (e.g., to a different or lower cost medication based on the pay-as-you-go cost information obtained by the patient from the pharmacy 160), the process may need to be repeated, which may result in further information exchange between the patient, the HCP 120, the pharmacy 160, and/or the PBM 150. Because cost information is not conventionally available to the HCP 120 and/or the patient at the time the HCP prescribes, the patient and/or the HCP 120 may not be aware of the cost-related aspects of the prescription until the pharmacy 160 determines a pay-as-you-go cost (e.g., based on the information provided by the PBM 150). Thus, if the cost is not acceptable to the patient, the prescribed therapy may need to be changed (or possibly not fulfilled), resulting in inefficiency of the system and poor resource utilization.

In addition, there may be other information exchanges, for example, between payers 140 and PBM 150 to exchange/verify patient coverage (e.g., whether the patient is currently covered), payment information (e.g., patient claim balances, etc.). The PBM 150 may send patient coverage information 142 to the payer 150 and receive confirmation as to whether the coverage is current and reimbursement related information, which may be used by the PBM to determine pay-for-patient costs. In addition, the PMDP 130 and the PBM may exchange sales and rebate related information 132, while the PMDP 130 and the payer 140 may exchange contract related information and/or drug/device pricing related information 137.

Thus, conventional healthcare information systems have several drawbacks. While each entity obtains and maintains information that may be relevant to conducting its business, only very little of this information may be shared (e.g., due to legal, privacy, and/or business considerations), and when sharing information, this information is typically fragmented, context-free, untimely, and may not be available for decision making/planning purposes. For example, the HCP 120 and/or the patient may not have cost information associated with the treatment at the time of prescribing. As another example, the patient or HCP 120 may not be able to obtain treatment alternatives and the costs of the various treatment alternatives when making the prescription or treatment plan.

As another example, the HCP 120 may not provide details of adverse drug reactions that may be reported by the patient to the PMDP 130 (e.g., due to privacy concerns). As another example, when the HCP 120 provides adverse drug reaction information to the PMDP 130, the information may not include non-PII demographic information (e.g., the patient's age, location, medical condition, etc. -again for privacy considerations), and thus may have limited value to the PMDP 130. Furthermore, in some cases, when an entity (e.g., a patient) reports a drug adverse reaction, verification of the drug adverse reaction may typically be performed by another entity to determine whether the adverse event is attributable to the prescribed drug. Verification (which may involve additional entities) may introduce additional complexity, which may further delay reporting and/or generate additional islanding, thereby further limiting the utility of the information (e.g., for PMDP 130).

In addition, since the exchanged information may be divided and provided on a temporary basis, aggregating the received information with the information stored by the receiving entity may be cumbersome. Furthermore, since each entity may index information differently, it may be difficult or impossible for a receiving entity (or transmitting entity) to bind received (or transmitted) information to an information record stored by the transmitting entity (or stored by the receiving entity). For example, if the HCP 120 provides medication adverse reaction information to the PMDP 130 at a point in time, it may be difficult for the HCP 120 and/or the PMDP 130 to obtain additional patient or patient medical condition information related to the medication adverse reaction even when the information is legitimately shared. For example, the partitioning of information may prevent or limit access by the PMDP 130 to aggregate demographic information that may be used to customize drug utilization. As another example, HCP 120 and/or payer 140 may have difficulty determining a patient's abuse of the prescription.

Many modern Machine Learning (ML) and other Artificial Intelligence (AI) systems can process large amounts of data to determine hazards, identify patterns that can lead to desired results, etc., which can lead to increased efficiency, reduced cost, and/or better results. Islanding and partitioning of information also limits the applicability of such ML and AI techniques, resulting in additional inefficiency.

Some attempts to improve the efficiency of healthcare delivery have focused on outcome-based approaches. The payor 140 may associate the reimbursement with the implementation of some agreement results. For example, a result-based contract may specify: the HCP 120 will reimburse at a certain agreed rate based on the patient's blood pressure decreasing to a certain defined range over a certain period of time. In conventional systems, tracking and managing such outcome-based contracts can be very difficult because several exchanges of information between the HCP 120 and the payer 140 may be required, each of which complies with legal, regulatory, privacy, and business-related guidelines.

While using a chain of blocks to store health-related information may be advantageous to ensure the integrity and authenticity of the stored information, conventional techniques do not address the problems caused by data sharing between entities in an environment of increased transaction and regulatory complexity, such as maintaining data privacy while reducing information partitioning. Furthermore, conventional techniques also fail to ensure timely availability of information (e.g., for one or more entities, in a manner that complies with legal and regulatory obligations) to facilitate transaction completion. In addition, conventional techniques do not ensure that entities have a coherent and consistent view of completed transactions. Lack of coherent and consistent views of completed transactions across entities may constrain interoperability, data utilization, and the pursuit of improving operational efficiency. Furthermore, constraints on interoperability often limit the ability of an organization to maintain customer-centric focus, as it may be difficult to consider a customer (e.g., a patient)'s request for information to aid or augment decision-making (e.g., independently or in coordination with a HCP).

The disclosed embodiments facilitate the safety of a healthcare system while improving the integrity, interoperability, and transparency of healthcare costs of the healthcare system. Some of the disclosed techniques facilitate timely exchange of appropriate data (e.g., in compliance with legal, privacy, and business guidelines) to appropriate entities (e.g., authorized entities associated with transactions) while facilitating a consistent and coherent view of information across healthcare market entities (e.g., at the time of a transaction).

Interoperability is facilitated in part because multiple entities associated with a transaction may be able to bind appropriate relevant information shared during the transaction to the completed transaction using agreed references. Consistency and coherence is facilitated because locally recorded data (e.g., local to an entity) may correspond to reference data (e.g., maintained on a shared platform) and a reference data view (or portion of reference data that can be viewed by an entity) of each entity may be consistent with a data view (and/or with locally recorded data of another authorized entity) of another authorized entity. In some implementations, the reference data may be based on and/or take the form of a decentralized ledger. In some embodiments, the distributed ledgers may be accessed by authorized entities, and the view of the distributed ledgers for each entity may conform to legal, privacy, business, and/or contractual obligations. In addition, the efficiency is improved because the information related to decision making is made available to the entity early in the transaction cycle to facilitate early consideration of the alternatives, thereby reducing the likelihood of inefficiency associated with transaction completion and reducing decision revisitation.

In some embodiments, a first entity (e.g., PMDP 130) may receive at least one encrypted first Electronic Health Record (EHR) sub-block (e.g., for a patient) that may be decrypted by the first entity. The first EHR sub-block may include patient medical coverage information of the patient and one or more first therapies (e.g., suggested drugs and/or devices, denoted by f_p, 1+.p+.p). The encrypted first EHR sub-block may be received (e.g., by the PMDP 130) with the transaction ID of the current transaction and, in some cases, may not include PII information for the patient. In other cases, the encrypted first EHR sub-block may be received (e.g., by the PMDP 130) along with the transaction ID of the current transaction (e.g., when authorized and/or when the PMDP 130 determines or uses patient qualification to pay for the assistance item managed by the PMDP 130), and may further include PII information for the patient. Upon receiving patient PII information (e.g., by the PMDP 130), the PMDP 130 may manage and fund the payment assistance project and may maintain patient privacy on behalf of the PMDP using a locally maintained chain of blocks consistent with the disclosed embodiments such that access to the patient PII information is restricted to project administrators and/or authorized personnel. Authorization to provide PII information may be obtained from the patient (e.g., previously obtained by the HCP 120 or the PMDP 130 or another entity). In some embodiments, the first EHR sub-block may further indicate that the patient has agreed to use the information in the first EHR sub-block to determine clinical trial participation eligibility.

The first entity (e.g., PMDP 130) may transmit at least one encrypted first device medication information (DIR) sub-block that may be decrypted by at least one corresponding second entity (e.g., HCP 120) in response to the first EHR sub-block, where the DIR sub-block includes a corresponding first treatment category (e.g., K_p representing a medication/device in the same category as F_p) for each of the one or more first treatments (F_p, 1.ltoreq.p.ltoreq.P). Each treatment category K_p may include one or more corresponding first treatment category members (individual drugs/devices identified by C_pd, (1. Ltoreq.p, 1. Ltoreq.d. Ltoreq.D_p), and each first treatment category member (C_pd) may be associated with corresponding first treatment category member cost information (M_pd). D_p may represent the number of class members in the treatment class k_p.

For example, upon receiving the first EHR sub-block, the first entity (e.g., PMDP 130) may determine a corresponding first therapy category (k_p) for each of the one or more first therapies (f_p). Additionally, in some embodiments, the first EHR sub-block may include patient-specific parameters, and the corresponding first treatment category may be determined based on the patient-specific parameters. The patient-specific parameters may include one or more of the following: patient co-morbid information, route of administration information, safety and efficacy information, and/or patient location information. Thus, a member c_pd in a corresponding first treatment category (k_p corresponding to treatment f_p) may be determined (e.g., by a first entity) based on patient-specific parameters.

Each first treatment category (k_p) may include one or more corresponding first treatment category members (c_pd). In addition, the first entity may determine one or more corresponding first treatment category member cost information (m_pd) for each of the one or more first treatment category members (c_pd). The first entity (e.g., PMDP 130) may then transmit an encrypted first DIR sub-block that may be decrypted by at least one corresponding second entity (e.g., HCP 120).

The one or more corresponding first treatment category member cost indicators (m_pd) include one or more of: patient-specific pay-as-you-go costs for each corresponding first treatment category member (C pd) for the corresponding treatment unit; or a patient-specific estimated total pay-as-you-go cost for a typical or prescribed treatment duration corresponding to each corresponding first treatment category member; or a patient-specific estimated total pay-as-you-go cost for the remaining duration of the medical coverage plan associated with the patient corresponding to each corresponding first treatment category member (C pd), or a combination thereof.

The first entity (e.g., PMDP 130) may receive, in response to the transmitted first DIR sub-block, an encrypted second EHR sub-block decryptable by the first entity, where the second EHR sub-block includes one or more second therapies (e.g., one or more selected drugs/devices S_p, 1+.p+.P), where each of the one or more second therapies S_p is selected from a corresponding first therapy class member (C_pd) associated with a corresponding first therapy class (K_p). For example, the set of second treatments S may include one selected corresponding first treatment category member (C pd) for each first treatment category (k_p corresponding to first treatment f_p). For example, the second EHR sub-block may include one or more selected devices/drugs, where each selected device/drug s_p is associated with a different corresponding class k_p. For example, a first EHR sub-block may include a first therapy (f_1, f_2, f_3), while a second EHR block may include a second therapy g_1, f_2, h_4, where g_1 and f_1 are both in therapy category k_1, f_2 is in therapy category k_2, and f_3 and h_4 are in therapy category k_3. As described above, each treatment category may include one or more members. In some embodiments, the selection of one or more second treatments s_p may be based on a patient-specific cost indicator.

In some embodiments, the first entity (e.g., PMDP 130) may then amplify a multidimensional block chain, wherein the multidimensional block chain is amplified with a multidimensional block formed by linking: a DD1 block including information associated with one or more second therapies, an EHR block including information associated with a second EHR sub-block, and a transaction block that may include a transaction ID.

In some embodiments, upon receiving the second EHR sub-block, the first entity (e.g., PMDP 130) may transmit a transaction block with a transaction confirmation, wherein the transaction block includes one or more prescriptions corresponding to one or more second treatments at the designated second treatment location. In some embodiments, the transaction block may include a prescription for the second treatment at a specified location specifying the cost of the patient. In some embodiments, the first entity may further transmit a confirmation of the transaction to the patient along with the at least one prescription (e.g., associated with the first EHR sub-block and the second EHR sub-block).

The term "sub-block" indicates a portion of a data record or block that (when encrypted) may be decrypted by one or more particular entities (but not by other entities). When the transaction is completed, the information in the sub-blocks decrypted by the particular entity (or entities) may be incorporated into the data record (or data blocks in the chain of blocks) maintained by the particular entity (or entities). For example, transaction U with transaction ID may involve entities A, B, C and D, which may be owners of data records W, X, Y and Z, respectively, in a multidimensional block chain. In the above example, the data record W (owned by a) associated with transaction U may be encrypted and read by owning entity a (but not by other entities). However, the data record W (in addition to transaction ID U) may include a portion of the information in other data records (e.g., data records X, Y and/or Z, which may not be readable by entity a). For example, data from one or more other data records present in W (e.g., data record X, Y and/or Z) may have been received as decryptable sub-blocks (e.g., by entity a) prior to completion of the transaction. Similarly, other entities B through D (in addition to transaction ID U) may also include transaction-related information present in non-self data records. For example, for entity B, information present in one or more of data records W, Y and/or Z may have been received in the form of sub-blocks that may be decrypted by entity B prior to the transaction being completed. Thus, each entity A, B, C and D can maintain a different independent chain of blocks that (for transaction U) include data records W, X, Y and Z, respectively, as blocks in their respective chain of blocks. The data records (or blocks) W, X, Y and Z associated with transaction U may also together form a multidimensional block in a multidimensional block chain. Thus, a coherent and consistent view of the transaction may be obtained by all market entities that may be associated with the transaction while maintaining compliance with legal, privacy, and/or other regulatory/business considerations and improving data integrity.

As used herein, the term "block chain" refers to a record or an "information block" or an extensible list of "blocks" in which the blocks are linked using encryption techniques. Each block includes a cryptographic hash of the previous block, a timestamp, and transaction data. The current block added to the block chain is also referred to as the head of the block chain. The cryptographic hash function maps data of arbitrary size to a bit string of fixed size, which is called "hashing". The hash function may be deterministic (the same input will produce the same output) and may be a one-way function that cannot be inverted (i.e., the original data input is determined from the hash value). The transaction data for a block may be represented as a merck root hash. The term "merck tree" or "hash tree" is used to refer to a tree in which each leaf node is marked with a hash of transaction data and each non-leaf node is marked with a cryptographic hash of the mark associated with its child node. The block header of a block to be added to the chain of blocks may include a hash reference to a previous block header and a hash reference to the root of the merck tree that includes transaction data. The block chain improves data integrity because changes to the data in the block chain result in inconsistencies in one or more of the hash references. The term "record" or "data record" is also used to indicate non-final data to be added to a chain of blocks. Once the data record has been validated and completed, the data record may be added to the chain of blocks and blocks formed in the chain of blocks.

The term "multidimensional block chain" is used to refer to a sequence of multidimensional records (also referred to as multidimensional blocks), wherein each multidimensional record includes two or more data records. In some cases, each of the data records that may be considered to form a dimension of a multidimensional chain of blocks may also form blocks in a different chain of blocks associated with a particular entity. Thus, in some implementations, a multidimensional block can include a data record in each dimension, where the data record corresponding to the dimension can form a block in a different chain of conventional blocks associated with the corresponding entity. For example, a multidimensional block may include an EHR data record as one dimension, a DIR data record as another dimension, and a transaction data record as a third dimension. Further, in some cases, EHR data records associated with multidimensional blocks (in a chain of multidimensional blocks) may be formed separately in different chains of EHR blocks (i.e., different from the chain of multidimensional blocks). Similarly, in some cases, DIR data records and transaction data records associated with multidimensional blocks may each form blocks in different chains of DIR blocks (e.g., associated with PMDP 130) and transaction record blocks (e.g., associated with payer 140), respectively. Thus, in some cases, a data record in the context of a multidimensional block chain may correspond to a block in a different conventional block chain. In some cases, each data record (e.g., associated with a dimension) in a multidimensional block can correspond to, form a portion of, and/or be derived from a corresponding block in a different conventional block chain. The multidimensional blocks may include a cryptographic hash, a timestamp, and data of a previous multidimensional block. The data of the multi-dimensional block may include hashes of the individual data records that make up the multi-dimensional block. In some embodiments, a consensus mechanism between entities may be used to confirm the correctness of the data in the proposed multidimensional block before the multidimensional block is committed and locked.

Thus, a multidimensional block may include two or more encrypted data records, where each encrypted data record may be associated with a different entity (e.g., in a healthcare marketplace). As described above, the data records in the multidimensional blocks may form blocks separately in different block chains, where each of the block chains may be associated with a different entity. Each encrypted data record may be capable of being decrypted by a corresponding associated entity (e.g., a data record owner). In addition, the encrypted data record may include a portion (referred to as a "sub-block") having data that may have been decrypted by at least one other particular entity other than the encrypted data record owner. For example, a sub-block may have been decrypted by at least one other different entity (other than the data record owner) when forming the corresponding multi-dimensional block. In some embodiments, the sub-blocks may have been encrypted separately at or before the formation of the multi-dimensional block, and made available to another entity along with information for decrypting the sub-blocks. Thus, the multidimensional blocks may facilitate availability of transactional data to a plurality of entities associated with a healthcare marketplace while providing coherent and consistent views of data to authorized marketplace entities, conforming to privacy and/or data sharing regulations, business guidelines, and/or contractual obligations, and improving data integrity. The entity may also ensure data dependencies with corresponding blocks in the locally maintained chain of blocks (e.g., recorded data dependencies associated with dimensions of multidimensional blocks in the chain of multidimensional blocks). In an embodiment, when information is exchanged between two entities using sub-blocks, the information exchanged via the decryptable sub-blocks may be based on an information interface between the two entities. In some embodiments, when exchanging information (e.g., when multidimensional blocks are formed), each entity may encrypt blocks associated with a local block chain maintained by the entity while generating sub-blocks that can be decrypted by other entities. The information interface may be based on an intelligent contract associated with the block chain.

The term "smart contract" is used to refer to program code or logic, which in some cases may be associated with a block chain or block chain platform. An "intelligent contract" may encode rules or agreements between two or more entities relating to data sharing, transactions, access, contract fulfillment, and the like. The intelligent contracts may be based on contracts between two or more entities and/or agreements associated with a multidimensional block chain platform. For example, a "smart contract" program code associated with a multidimensional chain of blocks may process a transaction request and determine the validity of the transaction based on program logic.

Fig. 2 shows an EHR 200 that illustrates some exemplary data fields in a record. In some embodiments, the EHR 200 may include information about the patient and may be owned and maintained by the HCP 120 (e.g., in the HI database 125). In some embodiments, the data fields in the EHR 200 may be populated and/or updated by the HCP 120 based in part on information received from the patient. EHR 200 may also include data received from other entities (e.g., as sub-blocks). The fields shown in EHR 200 are merely exemplary, and EHR 200 may include various other additional fields based on laws, standards, HCP conventions, and/or industry conventions, etc. The EHR may include fields that are different (fewer or more than those fields) than those shown with respect to the exemplary EHR 200.

The EHR 200 may be associated with a HCP profile field 295 that may store information related to the HCP 120 (e.g., HCP identification, registration and/or licensing information, address, associated healthcare professional, healthcare professional identification/registration information, etc.). In some embodiments, some or all of the information in the HCP material 295 may be shared with other entities in connection with transactions. For example, a portion of the HCP profile 295 may be sent to one or more entities, such as the PMDP 120, the payer 140, the PBM 150, and/or the pharmacy 160 (e.g., as part of an encrypted sub-block that may be capable of being decrypted by a designated receiving entity).

For example, as shown in fig. 2, EHR 200 may include basic information 230 about the patient, which may vary relatively little. The profile information 230 may include patient name, patient ID, family history 205, date of birth (DOB) 220, blood type 225, etc. Family history 205 may include a maternal history 210 and a paternal history 215. The profile information 230 can also be a medical record 232, which can include information regarding other previous or current medical conditions associated with the patient.

EHR 200 may further include other data fields such as a diagnosis 235 (e.g., for the current disease), a diagnosis code 240 (which may be a standardized code for diagnosis such as an international disease classification (ICD) code), a treatment code 245 (which may be a standardized code for describing treatment (e.g., such as a Current Program Term (CPT) code)), a prescription code 250 for each prescription, which may be used to uniquely identify each prescription. Prescription code 250 is also referred to herein as prescription 250.

In some embodiments, the (prescribed) prescription code 250 (e.g., for each drug/device prescribed in the prescription) may further include one or more subfields, such as: prescription drug field 255-P, 1.ltoreq.p.ltoreq.P (e.g., drug ID and/or Class Product Code (CPC) of medical device), dose 260-P (intensity and frequency), and duration 265-P (length of time that the drug will be used). In some cases, EHR 200 may also include other fields and/or subfields, such as an indication of whether a prescription is a new prescription or a repayment. EHR 200 may also include a Medical Device Reporting (MDR) adverse event code or other (e.g., ICD-10) code for documenting adverse drug reactions. EHR 200 may also include patient criteria 297, which may specify one or more criteria that may be provided by the patient for drug/device selection and/or cost indicator determination. For example, patient criteria 297 may specify a preferred method of administration (e.g., external, intake, inhalation, etc.), a preferred pharmacy, the area or location where the prescribed drug/device is to be obtained, the type of cost indicator desired, etc.

In some embodiments, the EHR 200 of the patient may be stored as a chain of blocks, for example, by the HCP 120, and each transaction between the HCP 120 and the patient and/or another entity may form part of an EHR information block in the chain of EHR blocks. When EHR blocks associated with a transaction are stored in a chain of blocks, in some cases, the stored information may be associated with a transaction ID 695 that may be used to uniquely identify the transaction. In some embodiments, the transaction ID 695 may be common to entities associated with the transaction (e.g., all entities associated with the transaction may use the same transaction ID). In some embodiments, the transaction initiator and/or components of the license block chain platform may provide transaction information, such as transaction ID 695, to one or more entities associated with the transaction. Thus, sub-blocks sent or received by an entity may be identified as being associated with a transaction and processed appropriately. In some embodiments, the format and content of transaction ID 695 may be predetermined and/or agreed upon by an entity associated with the transaction platform and/or provided by the transaction platform. Other transaction information related fields (not shown in fig. 2) may include transaction types that may be used by an entity to determine and process information in transmitted and/or received sub-blocks and to determine an appropriate response. For example, the transaction type may indicate that sub-block 280 is being provided to obtain a cost indicator associated with the prescription.

In the following description, when an EHR is maintained as a chain of blocks (e.g., by HCP 120), then EHR information record 200 may also be referred to as an EHR block 200. The EHR block 200 may thus form a block in an EHR block chain. When an EHR block 200 is to be added to an EHR block chain, some of the data in the EHR block 200 added to the EHR block chain may depend on other entities. For example, the treatment (e.g., specified in the treatment code 245 for the diagnosis described by the diagnostic code 240) may be approved by the payer 140 and/or the PBM 150 (not shown in fig. 2) and may be included as part of the EHR at the time of approval. As another example, a medication warning flag (not shown in fig. 2) that may form part of EHR block 200 may complete, verify, and/or update information in the warning flag using input from PMDP 130 prior to adding EHR block 200 to the EHR block chain.

In some embodiments, patient criteria 297, diagnosis 235, diagnosis code 240, treatment code 245, prescription code 250, along with data field prescription drugs/devices 255-P, dose 260-P, and duration 265-P, 1.ltoreq.p.ltoreq.p, may be used to form sub-block 280. In some implementations, the sub-block 280 may further include one or more of the following: the profile information 230, patient coverage related information 272, and/or a plan ID 270, which may be used to identify an insurance plan (e.g., health insurance plan, pharmacy welfare plan, prescription coverage, etc.) subscribed to by the patient. In some embodiments, sub-block 280 may also include some or all of the information of sub-blocks 282 and/or 284 described herein (depending on the context, applicable law, and/or patient authorization). Some or all of the information in sub-block 280 may be shared with one or more other entities and may form part of other records/blocks associated with the transaction.

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, sub-block 280 may include a record for each prescription drug/device 255-p in prescription 250. Sub-block 280 is merely an example showing some information that may be shared with another particular entity. For example, sub-block 280 may be encrypted and sent to PMDP 130 (e.g., to obtain an equivalent class of drugs, devices, and/or treatments and corresponding cost metrics) and may be decrypted by PMDP 130.

In general, information in any suitable field or combination of fields in a data record or block may be aggregated into a sub-block, which may be encrypted (e.g., by a first entity) such that the sub-block may be decrypted by some other particular entity or entities (e.g., one or more second entities). The encrypted sub-block may be sent (e.g., by a first entity) to one or more other designated entities (e.g., one or more second entities) that may decrypt the received information and operate on it appropriately (e.g., based on transaction type). Information from a data record or block in a locally maintained chain of blocks (e.g., EHR chain of blocks) used by a first entity to form a sub-block and shared with another (second) entity may depend on laws (e.g., healthcare and/or privacy regulations), administrative information sharing (e.g., which may determine information that can or cannot be shared between particular entities), business guidelines (e.g., which may govern sharing/protection of transaction secrets or sensitive information), and/or contractual obligations (e.g., between or related to entities sharing information) and/or protocols (e.g., as part of a subscription to an electronic transaction platform).

As another example, the information in sub-block 282 may include coverage related information 272, plan ID 270, common payment information 275, and the like. Some of the information in sub-block 282 may have been obtained directly from the patient, while other coverage related information may have been obtained from and/or validated by the payer 140 and/or PBM 150, and decrypted by the HCP 120 in conjunction with the transaction specified by the transaction ID 695 (e.g., for determining a cost-effective treatment) (e.g., based on one or more encrypted sub-blocks received from an appropriate entity and decrypted by the HCP 120—not shown in fig. 2). For example, the transaction type may indicate that sub-block 282 is being provided to obtain, confirm, or complete coverage related information 272.

Additionally, in some scenarios, a portion of EHR information 200, such as the profile information 230, DOB 220, blood group 225, and some portion of medical history 232, may be encrypted by HCP 120 as sub-block 284 and sent to PMDP 130, which may then decrypt sub-block 284 in connection with the transaction specified by transaction ID 695 (e.g., for determining the level of payment assistance). As another example, the portion of the profile information 230 included in the sub-block 284 may be a non-PII associated with the patient (e.g., excluding name, identification number, etc.). Thus, medical information may be safely shared with another particular entity (e.g., to determine adverse reactions, medical device malfunctions, etc.) without compromising patient privacy. In another case, where disclosure of PII information is allowed and authorized (e.g., by the patient), the sub-block may include PII information (e.g., patient qualification for the PMDP 130 to determine payment assistance, or patient qualification associated with the prescription (for the pharmacy 160 to establish patient identity)). For example, some or all of the information present in sub-blocks 282 and/or 284 (depending on the context, transaction type, applicable law, and/or patient authorization) may also be incorporated into sub-block 280.

As another example, the data in sub-block 280 may be shared by an entity, such as HCP 120, with another healthcare market entity, such as payer 140, to complete the transaction. However, the patient profile information (e.g., family history 205, maternal history 210, and/or paternal history 215) associated with the profile information 230 may be considered private (e.g., based on patient instructions/privacy, legal, and/or business guidelines), and the first entity (e.g., HCP 120) may not share the family history 205, or may restrict the shared portion of the profile information 230.

Thus, in some implementations, the data used to form the sub-blocks sent by an entity or received from another entity may depend on both the entity and the context in which the data is shared (e.g., the type or nature of the transaction). In some embodiments, the information interface between any two entities may depend on the transaction type and/or context. In some embodiments, one or more protocols (e.g., agreed/prearranged by the entity and/or established by the licensed block chain platform and/or based on criteria) may specify the transaction types and the information present in the sub-blocks sent/received by the entity for each transaction type. In some embodiments, the data fields included in the sub-blocks shared between entities in connection with the transaction type may be indicated (e.g., by a protocol and/or agreed upon criteria) as mandatory, conditional, optional, on-demand, etc.

The data in the sub-block (e.g., sub-block 280) may be encrypted separately and may only be able to be decrypted by an authorized entity. In some embodiments, encryption of the data forming the sub-block (e.g., sub-block 280) may be based on any suitable encryption method, including symmetric key encryption techniques in which entities such as HCP 120 and payer 140 share a secret key, such as Advanced Encryption Standard (AES) based techniques or variations thereof. The sub-block 280 may be encrypted (e.g., by the HCP 120) prior to sharing with another entity (e.g., the payer 140). Another entity (e.g., payer 140) may be able to decrypt sub-block 280, for example, using a shared key.

Additionally, data in the EHR 200 may also be separately encrypted by the HCP 120 using any secure encryption technique to form the EHR block 200 prior to addition to a chain of blocks (e.g., maintained by the HCP 120 and/or by an electronic trading platform). For example, data in EHR block 200 may be individually encrypted using a private key (e.g., private to HCP 120) such that the data may be decrypted and obtained by HCP 120, but not obtained and/or viewed by any other entity.

Fig. 3A and 3B illustrate portions of an exemplary medication/Device Information Record (DIR) 300 of medications that may be stored in DIR database 135. In some embodiments, DIR 300 may include information regarding treatment (e.g., medication and/or medical devices) such as medications, devices, and/or procedures. The fields shown in DIR 300 are merely exemplary, and DIR 300 may include various other fields based on laws, standards, industry practices, etc. Further, the DIR may include fields that are different (fewer or more than those fields) than those shown with respect to exemplary DIR 300.

DIR 300 may be associated with a PMDP profile field 395, which may store information related to PMDP 120 (e.g., PMDP identification, contact information, address, etc.). In some embodiments, some or all of the information in PMDP data 395 may optionally be shared with other entities associated with the transaction. For example, a portion of PMDP profile 395 may be sent to one or more entities, such as payers 140, PBMs 150, and/or pharmacies 160 (e.g., as part of an encrypted sub-block that may be capable of being decrypted by a designated receiving entity).

Referring to fig. 3a, pmdp 130 may use the information in the prescription drug/device field 255-p (e.g., received as part of sub-block 280) to determine (e.g., for each drug/device 255-p associated with prescription code 250) a corresponding drug/device class 337-p. The drug/device class 337 field may specify one or more drug/device classes associated with the drug/device 255. In some implementations, sub-block 280 may also include some or all of the information in sub-blocks 282 and/or 284.

The drug/device class may be a group of drugs/devices that may be used to treat the same medical condition. The drugs in the drug class may have: similar chemical structures, and/or similar or related mechanisms of action (e.g., that may act on or bind to the same target), and/or related modes of action (induce similar biological or functional effects), and/or may be used to treat the same disorder. For example, the drug device categories may also include branded drugs/devices and simulated drugs/devices, and/or branded biological products and biological analogs, and/or different doses of the same treatment, etc. In FIGS. 3A-3C, the drugs within each drug/device class 337-p are indicated by drugs/devices 302-pd, where 1.ltoreq.d.ltoreq.D_p, where D_p is the number of drugs in drug/device class 337-p.

In some embodiments, the drug/device class 337-p field may indicate one or more of the following: an organ or biological system treated by the drug device, and/or a treatment area, which may be specified by a treatment area field 360-pd, the treatment area field including repeated indication subfields 362-pd1, 362-pd2 …; for the corresponding indication, repeated dose subfields 364-pd1, 364-pd2 … are included; mechanism of action and/or mode of action, which may be specified by MOA field 340-pd; the general chemistry of a drug, which may be specified by the chemistry data field 350-pd, may further include subfields: molecular formula fields 353-pd describing the pharmaceutical chemistry components, and chemical structure subfields 355-pd.

Referring to FIG. 3A, DIR 300 may include various other data fields, including: drug name 304-pd of drug/device ID 302-pd; efficacy 327-pd (which may be a measure of the efficacy of treatment for a medical condition); the route of administration 335-pd (e.g., topical, oral, intravenous, etc.); security 330-pd (e.g., drug interactions, toxicity, contraindications, etc.), which may include side effect subfield 345 (e.g., secondary effects) and adverse event subfield 333-pd (e.g., adverse events for drug reporting). DIR 300 may also include various other fields related to the drug/device.

In some embodiments, the drug/device ID 302-pd, drug/device name 304-pd, security 330-pd (and subfields), and efficacy 327-pd, drug/device category 337-p, treatment area 360-p, indication 362-dh (e.g., indication 362-pd1, indication 362-pd2, etc.), and corresponding dose 364-dh (e.g., dose 364-pd1, dose 364-pd2, etc.) may form part of the sub-block 380. The information in sub-block 380 (and any other sub-blocks) may be pre-arranged between entities, determined by a protocol, and/or specified by a platform (e.g., based on laws, regulations, authorizations, and/or contractual obligations). Thus, the information in sub-block 380 (and any other sub-blocks) may be more or less than that shown for the exemplary sub-block (e.g., exemplary sub-block 380) and may also depend on the transaction type, transaction context, and interaction entity. The sub-block 380 may further optionally include administration pathways 335-pd, MOA 340-pd, chemical data 350-pd, and other related fields/sub-fields. In fig. 3A, the fields associated with exemplary sub-block 380 are shown enclosed within the dashed perimeter.

The DIR sub-block 380 may be provided by the PMDP 130 in conjunction with a transaction (e.g., identified by the transaction ID 695) to another entity (e.g., the HCP 120). In some embodiments, DIR sub-block 380 may include information for multiple drugs/devices that form part of a drug/device class 337-p or share one or more characteristics (e.g., treat the same medical condition, and/or have a similar mechanism or pattern of action, and/or have a similar chemical structure). In some implementations, the information in sub-block 380 may be associated with the transaction (e.g., identified by transaction ID 695 and transaction type) and may be encrypted by PMDP 120 and transmitted to another entity (e.g., HCP 120) during the transaction and/or prior to completion of the transaction.

In some embodiments, DIR record 300 may be associated with a transaction (e.g., specified by transaction ID 695) and may be stored as DIR blocks in a DIR block chain by an entity such as PMDP 130 upon completion of the transaction. In the following description, when DIR record 300 forms part of a DIR block chain, then DIR information record 300 may also be referred to as DIR block 300.DIR block 300 may thus form a block in a DIR block chain.

A transaction (e.g., specified by transaction ID 695) between two or more entities (e.g., patient, HCP 120, PMDP 130, payer 140, PBM 150, and/or pharmacy 160) may involve information (e.g., related to drugs/devices) maintained (or owned) by another entity. For example, the HCP 120 may request information from the PMDP 130. Some of the data integrated into the records maintained by other entities (i.e., other PMDPs 130) prior to transaction validation (e.g., maintained by PMDP 120 in DIR information block 300) may depend on input from PMDP 130, verification by PMDP, and/or validation. Conversely, the PMDP 130 may receive input in the form of sub-blocks from another entity (e.g., the HCP 120 and/or the payer 140 and/or the PBM 150). Some or all of the received information may be incorporated into DIR record 300 and/or used to determine information in DIR record 300.

For example, the HCP 120 may send the sub-block 280 to the PMDP 130.PMDP 130 may use the information in sub-block 280 (e.g., prescription drug 255-p) to determine the corresponding drug/device class 337-p and obtain the information in sub-block 380, which may be sent to payer 140 and/or PBM 150. Further, PMDP 130 may store some of the information in current (e.g., last received) sub-block 280 as part of DIR record 300 before the transaction is completed. For example, information related to a diagnosis (e.g., diagnostic code 240), a dose (e.g., dose 260), etc., may be stored as part of the DIR record 300 and associated with the corresponding drug/device ID 302-p upon confirmation (e.g., from the HCP 120) that the drug in the drug/device ID field is being prescribed (e.g., as may be indicated by the value of the prescribed drug field 255 in sub-block 280 at transaction confirmation).

Thus, when requesting information related to a transaction (e.g., related to a drug/device), the owner (e.g., PMDP 130) may respond by sending the information (e.g., in sub-block 380) to the requesting entity (e.g., HCP 120). The information (e.g., in sub-block 380) may be encrypted (e.g., by PMDP 130) prior to transmission and may be able to be decrypted by the requesting entity (e.g., HCP 120) such that the information in sub-block 380 is private between the requesting entity (HCP 120) and the transmitting entity (PMDP 130). Further, information in sub-blocks exchanged between entities may be restricted such that the shared information complies with existing regulations, privacy laws, contractual obligations, and/or authorizations received from a designated owner (e.g., patient) of the information.

FIG. 3B illustrates an exemplary DIR record 300 with some additional information that may be included in the DIR record 300 in connection with a transaction. In fig. 3B, sub-blocks 280 and 380 are shown by blocks with dashed outlines. For simplicity and ease of description, the information in sub-blocks 280 and 380 is not shown. As described above, some or all of the information in sub-block 280 may form part of DIR record 300.

As shown in fig. 3B, DIR record 300 may further include a prescription list 405, which may include a list of approved prescription drugs (e.g., simulated drugs and branding drugs) associated with a treatment category. The medication prescription schedule may be used to identify medications and/or equipment covered by the medication and/or insurance plan. The prescription schedule may be updated and/or released periodically. For example, law, regulator, health insurance exchange, and/or private employer may specify that a prescription schedule of available/approved insurance plans be published and updated at a specified time. Thus, in some cases, the prescription schedule information for the various plans may be publicly available, and/or available to plan subscribers (e.g., organizations subscribing to plans on behalf of their members/employees), and/or available from other entities (e.g., regulators, health exchanges, etc.).

The prescription schedule may distinguish products by classifying treatments into "grades". Each tier may have a different level of patient cost sharing. For example, for drugs/devices in the preference level, patient cost sharing may be $0 or limited to a common payment specified in the patient's insurance plan (subject to no claim). Drugs/devices in non-preferred classes may have additional patient cost sharing, commonly referred to as "co-insurance". For example, patients prescribed non-preferred medications may pay a percentage (e.g., 30%) of the price of the medication as a common insurance in addition to the common payment. The amount of common insurance may depend on the grade. Similar "grades" may also be applied to devices and/or other medical treatments.

Thus, prescription list 405 may include repeated payer-i fields 410-i, (1.ltoreq.i.ltoreq.n), each field having information about the corresponding payer i. In addition, for each payer-i 410-i, the prescription schedule 405 may include information about the corresponding medication level, which may appear in the repeated level-j field 410-j, (1. Ltoreq.j. Ltoreq.T_i), where T_i is the number of levels associated with the payer-i. The level associated with a drug may depend on the indication for which the drug is being used (e.g., as listed in indication field 420-k) and the payer-i 410-i. For example, prescription schedule 405 for a drug in DIR record 300 may specify (e.g., for payer 1 410-1 and some indication 320-k) that a first simulated drug is a level 1 415-1, a more expensive second simulated drug is a level 2 415-2 drug, and a nameplate drug is a level 3 415-3 drug. In addition, each level-j field 410-j may include a repeated indication-k field 420-k, (1. Ltoreq.k. Ltoreq.s). The indication-k field 420-k under the hierarchy may specify the medical condition (indication) for which the prescription schedule has been approved (e.g., by payer 1 410-1 and/or PBM 150) as treatment.

Thus, the patient pay-as-you-go cost (e.g., co-insurance) may vary according to one or more of the following: medical treatment guidelines for medical conditions; available treatment options; a treatment regimen ultimately selected by the patient or HCP 120; a grade 415 associated with the selected treatment; the indication 420 of the treatment selected; payers 140 and/or PBMs 150. However, such pay-as-you-go cost information is often difficult or not available to the patient and/or HCP 120 at the time of prescribing, which may result in higher sustained costs to the patient (e.g., if cheaper treatment options are available), and/or may result in additional transactions such as prescription/treatment changes, and/or revisitation of treatment decisions by the HCP 120 and patient. In addition, sub-optimal decisions and/or transaction overhead adversely affect overall system cost and efficiency when viewed in aggregate.

As shown in FIG. 3B, DIR 300 may include various other data fields, including prices 425-pd, which may list prices at which treatments (e.g., drugs or devices) are made available. The price 425-pd may be an estimate of the patient's cost provided by the payer 140 or the PBM 150 (as determined by the payer 140/PBM 150 based on current patient coverage information). Patient cost (as estimated by payer 140/PBM 150) may be a function of any outstanding reimbursements, patient co-payment, co-insurance (e.g., based on level 415), cost sharing (e.g., from payer 140), and negotiated price of drugs/devices (e.g., between payer 140/PBM 150 and PMDP 120/pharmacy 160). As described above, for a particular payer and treatment, the level 415 may depend on the indication 420 associated with the treatment. As another example, the prices 425-pd may reflect the negotiated prices (e.g., with the PMDP 120 and/or the pharmacy 160 and/or another entity), as well as additional cost details (e.g., the total amount 421, the claim free amount 423, may provide information related to the patient's pay-as-you-go costs).

In some cases, prescription list 405 (including subfields) and related information may be obtained (e.g., from payer 140 and/or PBM 150 and/or another entity such as a health exchange) as prescription list sub-block 480. In some embodiments, a portion of sub-block 480, such as price 425, payable amount 421, claim free amount 423, and co-insurance 429, may be obtained along with updated prescription schedule 405 during and/or prior to completion of the transaction (e.g., from payer 140 and/or PBM 150). Thus, at the time of the transaction, the information in sub-block 480 may be current (or made current/updated). The data field price 425, the total payment 421, the claim amount 423, and the common insurance 429 (which may be part of one or more sub-blocks 480, for example) may be provided for the corresponding medication/device 302 based on the coverage related information 272 and/or the plan ID 270 received from the HCP 120 (e.g., as part of the sub-block 280).

In some cases (e.g., when the sub-block 280 does not include coverage related information 272 and/or plan ID 270), the payer 140 and/or PBM 150 and the payer 140 and/or PBM 150 may determine the price 425, the total amount 421, the claim free amount 423, and the total insurance 429 and provide the information to the PMDP 130 in the sub-block 480. For example, payer 140 and/or PBM 150 may determine price 425, co-payment 421, claim free 423, and other information in co-insurance 429 and/or sub-blocks 480 by associating a request for information from PMDP 120 with previous information received from HCP 120 (e.g., in sub-blocks 280 and/or 284) using transaction ID 695 and transaction type.

In some embodiments, the PMDP 130 may use the information in block 480, including the price 425-pd, the total payment 421-pd, the claim amount 423-pd, and the total insurance 429-pd, to determine the payment assistance 391-pd for the drug/device (e.g., specified by the drug/device ID field 302-pd). The PMDP 130 may generally provide payment assistance 391-pd (e.g., for drugs/devices manufactured and/or supplied by the PMDP 130) to increase affordability and/or offset patient pay-as-you-go costs. The payment assistance provided by the PMDP 130 (or on behalf of the PMDP 130) may be based on various patient qualification criteria. Thus, updated patient cost details may be provided along with the cost index 395 for the prescription. The updated patient cost details may include for the corresponding drug/device 302-pd: (a) patient pay-as-you-go 392-pd; (b) Payment assistance 391-pd, (c) pharmacy ID 394-l at pay-as-you-go in (a) above, and (d) one or more other optional fields.

In some cases (e.g., when the patient wants to utilize payment assistance), upon patient authorization, the HCP 120 may provide (e.g., in sub-block 280) the patient's PII information along with coverage information to determine eligibility for the drug/device and payment assistance 391-pd, which may be associated with patient insurance plan information provided by the payer 140 and/or PBM 150 (e.g., in sub-block 480) and patient application information (e.g., which may have been provided by the patient separately to the PMDP 130 and/or an affiliated entity acting on behalf of the PMDP 130). Since prescription 250 may include multiple drugs/devices, payment assistance 391-pd may be determined for each corresponding drug/device 302-pd for which payment assistance may be applicable in prescription 250.

In some embodiments, the PMDP 130 and/or another entity and/or user (e.g., patient) application (e.g., running on a mobile device such as a smart phone, handheld computing device, tablet computer, etc.) may obtain payment assistance information from the plurality of PMDPs 130 to determine the cost information 395 associated with each drug/device 302 in the prescription identified by the prescription code 250. For example, the application may aggregate any payment assistance 391-pd received from one or more PMDPs 130 (or entities affiliated with one or more PMDPs 130) to determine the cost index 395. Where the entity payment assistance items may be coordinated and/or managed by entities other than the PMDPs 130 (i.e., by affiliates, patient access program providers/coordinators, community agents, non-profit organizations, governments, or other entities), then the payment assistance information may be provided (e.g., via an application on the patient's mobile computing device) by the management entity based on the information received from each of the PMDPs 130 (e.g., as reflected in sub-block 390). In some embodiments, an application on a patient's mobile computing device may be authorized by an entity associated with the licensed block chain platform (e.g., HCP 120 and/or patient access program coordinator and/or health exchange and/or PMDP 130), and may communicate with the entity that authorizes/provides the application via a secure channel to exchange information with the entity associated with the licensed block chain platform.

The cost information 395 may be based on patient criteria 297, which may specify criteria or preferences (such as location of prescription, preferred pharmacy, etc.) for determining the cost information 395. The cost indicator 395 may be at a drug level indicated by 395_pd (e.g., a cost detail for a particular drug/device 302_pd; a lowest cost pharmacy that may acquire a particular drug/device 302-pd, a lowest cost drug 302-pd in a category 337-p over a specified period such as a treatment duration and/or coverage duration), and/or at a prescription level indicated by 395_p (e.g., a lowest cost to dispense as a prescription when one or more particular drugs/devices 302 are selected; a plurality of sets of drugs/devices 302 that would provide a lowest cost to dispense as a prescription if selected; a set of drugs/devices 302 that provide a lowest cost over a treatment duration for a prescription; a set of drugs/devices 302 that provide a lowest cost over a specified period such as a current insurance/benefit coverage period, etc.).

Fig. 3C illustrates an exemplary data flow from the initial proposed prescription 250 (which may be part of the first EHR sub-block 280) to an alternative (e.g., in DIR sub-blocks 380 and/or 390) that may be presented to the patient/HCP 120 along with cost information 395 to facilitate treatment selection.

As described above, in some embodiments, information related to the initial proposed prescription 250 may be obtained (e.g., by the PMDP 130 and/or another entity) via the first EHR sub-block 280. EHR sub-block 280 may also include other information (e.g., patient medical coverage information). As shown in FIG. 3C, the exemplary proposed prescription 250 may include a plurality of first treatments (e.g., proposed drugs/devices 255-i, (1.ltoreq.i.ltoreq.N.) sub-block 280 may be encrypted and may be decrypted by PMDP 130 and/or another authorized entity.

In some embodiments, a drug/device class 337-P (1.ltoreq.p.ltoreq.P) may be determined that corresponds to one or more drugs/devices 255-P (1.ltoreq.p.ltoreq.P) in the proposed recipe 250. As shown in FIG. 3C, the drugs/devices 302_pd (1.ltoreq.d.ltoreq.D_p, where D_p is the number of selected drugs/devices in category p) corresponding to each drug/device category 337-p may be determined.

For each drug/device 302_pd in the drug/device category 337-p, a patient pay-off cost 392_pd, a pay-aid 391_pd, cost details 397_pd, and pharmacy information (e.g., pharmacy ID 394_l to which the patient pay-off cost 392_pd applies, etc.), and cost information 395_pd (at the level of the drug 302_pd) may be determined. The cost information 395_pd may be determined based on patient coverage information and/or information received from the PBM 150 and/or the payer 140 and/or another entity. In some embodiments, the pharmacy ID 394_l may be determined based on patient criteria 297 (e.g., provided in block 280). The pharmacy ID 394_l may include pharmacy related information and/or be used to find pharmacy related information. In some embodiments, the above information may be provided to the HCP 120, the patient, and/or another entity. For example, the information may be encrypted in sub-block 390 and may be decrypted and read by an authorized receiving entity. For example, the HCP 120 and/or the patient may receive such information in an application running on a smart phone or other mobile computing device.

In some embodiments, cost information for the drug/device 302_pd may be aggregated based on one or more user (e.g., patient) specified criteria to determine a cost indicator 395_p (at the level of the prescription 255_p). For example, the prescription-level (potential) cost information 395-p may be based on, for example, assumptions about the selectable drugs/devices 302-pd and/or one or more drugs/devices 302.

As another example, the cost information associated with the potentially equivalent prescription may be analyzed to determine a cost indicator 395—p, such as a single pharmacy within a threshold distance of a location (e.g., the current location or provided location) meeting the lowest total cost of the potentially equivalent prescription. As another example, cost information associated with a potentially equivalent prescription may be analyzed to determine a cost indicator 395—p, such as a minimum total cost for the potentially prescription within a certain threshold distance of a location (e.g., a current location or provided location such as a zip code or address) regardless of the number of pharmacies used to complete the prescription. As another example, the cost information associated with the potentially equivalent prescription may be analyzed to determine a cost indicator 395—p such that the total cost of the prescription within a threshold distance of a location (e.g., the current location or provided location such as a zip code or address) is within some user-specified threshold of the lowest cost prescription while limiting the number of pharmacies used to complete the prescription. As another example, the cost information associated with the prescription may be analyzed to determine a cost indicator 395—p, such as a total treatment cost over an expected treatment duration and/or over some specified period of time (e.g., for a current or remaining insurance period). Patient criteria 297 may also specify other considerations that may be used in determining cost metrics, pay-as-you-go costs, and the like, such as preferred pharmacy, mail order options, and the like. For example, if the user specifies that the mail order is acceptable, the sub-block may include costs associated with the mail order pharmacy in addition to the pharmacy 160 within the area.

When DIR block 300 is to be added to a DIR block chain, some of the data in DIR information block 300 may depend on inputs from other entities, verification and/or validation by other entities. For example, information in prescription list 405 associated with a payer (e.g., payer 140 specified in payer i 410-i) may form part of DIR block 300 and may depend on verification by the payer (e.g., payer 140). Once verification has been provided and a transaction confirmation has been received, DIR block 300 may be added to the DIR block chain. Verification may be obtained from payer 140 in the form of a sub-block (e.g., sub-block 480). The information in sub-block 480 may be transaction-specific (e.g., as identified by transaction ID 695), encrypted by payer 140, and possibly decryptable by PMDP 120. In some cases, encryption sub-block 480 (or information present in sub-block 480) may be dedicated to PMDP 120 and may not be decryptable by entities other than PMDP 120.

In some embodiments, for a transaction at a point in time, the data field prescription schedule 405, the information in payer 1 140-1, the level information in each of the level fields 415-j in the level-j fields 415-j associated with the payers in payer 1 140-1, the information in each of the indication fields 410-k in the indication-k fields associated with each level-j field may be part of the sub-block 480 received from the payer 1 140-1. However, information related to any other payers may not form part of sub-block 480, as these payers may not be parties to the transaction. Thus, in a transaction involving a single payer (e.g., payer 1 140-1), DIR record 300 may include information for that particular payer (e.g., in sub-block 480).

When multiple payers are involved in a transaction, then multiple encrypted sub-blocks (e.g., each encrypted sub-block from a corresponding payer 140-i) may be received by PMDP 130 and integrated by PMDP 130 into DIR record 300. The information in each sub-block received from payer-i may be private between PMDP 130 and the corresponding payer-i. Sub-block 480 is merely an example showing some information that may be shared with another particular entity. Generally, information used to form sub-blocks from locally maintained data records or blocks in a chain of blocks (e.g., DIR 300) may depend on regulations (e.g., healthcare and/or privacy regulations), laws governing information sharing (determining information that entities can or cannot share), business guidelines (e.g., business secrets or sensitive information), and/or contractual obligations (e.g., between or related to entities sharing information).

Thus, in some embodiments, data sent into sub-blocks of the PMDP 130 may be individually encrypted by the corresponding sending entity (e.g., payer-i 140-i) and may be able to be decrypted by the PMDP 130 and not available to unauthorized entities. In some embodiments, encryption of data in sub-blocks (e.g., received by PMDP 130) may be based on any suitable encryption technique, including symmetric key cryptography. Encryption may be based on, for example, a secret key shared between entities (e.g., payers 140-i and PMDP 130 identified in the payer 1 140-1 field). The receiving entity (e.g., PMDP 130) may be able to decrypt the received sub-blocks, e.g., based on the secret shared key.

In addition, the data in DIR block 300 may also be separately encrypted by a first entity (e.g., PMDP 130) using any secure encryption technique before being added to the block chain, such that the data is decryptable by and available to the first entity (e.g., PMDP 130), but not available to and viewable by other entities (e.g., HCP 120 and/or payer 140).

Fig. 4 illustrates a portion of an exemplary Pharmacy Benefit Record (PBR) 400 that may be maintained by the PBM 150. The term "PBM" is used to refer to any entity that manages a portion of a benefit (e.g., a drug and/or medical device prescription) on behalf of a payer (e.g., payer 140). In some cases, the PBM may be affiliated with the insurer/payer. In some cases, the insurance company/payer may directly manage the drug/device benefits such that the payer 140 and the PBM 150 may be considered a single entity, and portions of the following description may also apply to a single (payer+pbm) entity.

PBR 400 may include information regarding payers and associated benefit plans, available benefits, patient/subscriber information, payer drug/device levels, cost sharing, etc., and may be owned and maintained by PBM 150 (e.g., in PBI database 155). In some embodiments, the data fields in the PBR 400 may be populated and/or updated by the PBM 150 based in part on information received from the patient/HCP 120 and/or the payer 140 and/or other entities. PBR 400 may also include (e.g., as a sub-block) data received from other entities. The fields shown in PBR 400 are merely exemplary, and PBR 400 may include various other additional fields based on laws, standards, PBM practices, and/or industry practices, etc. The PBR may include fields that are different (fewer or more than those fields) than those shown with respect to the exemplary PBR 400.

The PBM may determine a medication level of the prescribed medication, which may determine a common insurance amount. The PBM may also set or determine a retail price for the pharmaceutical product, obtain payments or rebates from the manufacturer based on the sales volume of the particular product or product basket, and in some cases, obtain after-market price offers and payments from the pharmacy according to the prescription checklist. Accordingly, PBR 400 may include sales information field 497, which may store transaction and other sales information for each drug. The PBR 400 may also include various other fields (not shown in fig. 4) to track aggregated payer-specific and pharmacy-specific drug/device sales, discount/rebate information, and the like. The PBM 150 may exchange information (e.g., via the encrypted sub-block with the HCP 120, the payer 140, and/or the pharmacy 160, and/or the PMDP 130).

In some embodiments, the PBR 400 may be associated with a PBM material field 495, which may store information about the PBM 150 (e.g., PBM identification, contact information, address, etc.). In some embodiments, some or all of the information in the PBM profile 495 may optionally be shared with other entities associated with the transaction. For example, a portion of the PBM material 495 may be sent to one or more entities, such as the PMDP 130, the payer 140, and/or the pharmacy 160 (e.g., as part of an encrypted sub-block that may be capable of being decrypted by a designated receiving entity).

As shown in fig. 4, PBR 400 may include a portion of the information in sub-block 280 (shown enclosed in the dashed line boundary). In some embodiments, some of the information in sub-block 280 may be received from HCP 120 and updated and/or verified by PBM 150. In some implementations, the PBM 150 may receive some or all of the information in the sub-block 280 from the PMDP 130 (e.g., indirectly). In some implementations, sub-block 280 may include sub-block 284 and/or some or all of the information in 284.

Thus, as shown in fig. 4, in some embodiments, the one or more encryption sub-blocks 280 may include coverage related information 272 (e.g., based on information initially obtained by the HCP 120), a diagnosis 235, a diagnostic code 240, an indication 242, a diagnostic code 240, a treatment code 245, and a prescription code 250. In addition, PBR 400 may also include one or more of the following: the actual prescribed drugs/devices 255-ps (e.g., corresponding to drugs/devices 302-pd selected from drug/device categories 337-P), doses 260-ps, and/or durations 265-ps for PBM 150 are given along with transaction ID 695, where 1.ltoreq.p.ltoreq.P, and 1.ltoreq.s.ltoreq.D_p for each drug/device category P. The prescription codes and associated prescription drugs/devices 255-ps, doses 260-ps, and/or durations 265-ps, etc. in sub-block 280 may represent a selection of a drug/device (e.g., selected by the patient and/or prescribed by HCP 120) after evaluation of the drug/device 302-pd. For example, the HCP 120 and/or the patient (negotiating with the HCP 120) may select one drug/device 302-ps≡255-ps from each drug/device class 337-p, and the selected drug/device 255-ps may be associated with the final/selected prescription 250-s. The PBM 150 may incorporate some or all of the information in the sub-block 280 into the PBR 400 (e.g., upon transaction confirmation/completion). A transaction ID 695 that can uniquely identify a transaction between entities can facilitate information exchange and coordination between the entities. For example, a unique transaction ID 695 shared between entities that are parties to a transaction may be used to correlate and aggregate, verify, and process information received from one or more entities with locally stored information and/or with information received from other entities. In some embodiments, the final recipe 250-s (e.g., in the second sub-block 280 from the HCP 120) may be sent after the DIR sub-block 380 (with the drugs/devices 302-pd).

PBR 400 may also include a portion of the information in sub-block 380, which may be received from PMDP 130 along with transaction ID 695. For example, in some embodiments, PMDP 130 may send (e.g., in one or more encrypted sub-blocks 380) drugs/devices 302-pd corresponding to drug/device categories 337-p (where each drug/device category 337-p may be associated with at least one prescription drug 255-p (e.g., in an initial prescription 250 sent to PMDP 130). The PBR 400 may further include a drug/device name 304-pd (which may be received as part of sub-block 380) corresponding to the drug/device 302-pd. PBM 150 may process the information in sub-block 380 and return a list of approved drugs, levels, costs, etc. (e.g., in sub-block 480).

In some implementations, the PBM 150 may use the transaction ID 695 to determine that the sub-blocks 282 and 380 are associated with the same transaction. PDM 150 may then use coverage related information 272 in sub-block 280 to determine information (e.g., prescription schedule, level, etc.) in sub-block 480. In some implementations, sub-block 380 may also include plan ID 270 and coverage related information 272 (e.g., when provided to PMDP 120), which may be used by PBM 150 to determine the information in sub-block 480. For example, PBM 150 may use coverage related information 272 (for patient and payer 140-i) along with additional patient coverage information 495 (which may be maintained locally and/or obtained from payer i 410-i) to determine the information in sub-block 480.

As shown in fig. 4, sub-block 280 in PBR 400 may include, for payers 140-i (e.g., determined based on coverage information 272 and/or plan ID 270) and drugs/devices 302-pd (e.g., determined based on sub-block 380): a prescription schedule 405 including rating information 415-j and indications 420-k. In some implementations, sub-block 480 may further include one or more of the following: diagnosis 235, diagnosis code 240, indication 242, treatment code 245, prescription code 250, prescription drug/device 255, corresponding dose 260, and/or duration 265 (e.g., determined based on sub-block 280). The PBR 400 may also include a transaction ID 695. The PBM 150 may incorporate some portion of the information in sub-blocks 280 and/or 380 into the PBR 400 (e.g., upon transaction confirmation/completion).

In some embodiments, the PBM 150 may further include (e.g., as part of sub-block 480) various other data fields, including a price 425, which price 425 may list (by plan, level, and indication information) the price at which a treatment (e.g., drug or device 302-pd) is available. The price 425-pd may be an estimate of the patient's cost provided by the payer 140 or the PBM 150 (as determined by the payer 140/PBM 150 for the drug/device 302-pd), or a negotiated price (e.g., as negotiated with the PMDP 120 and/or pharmacy 160 and/or another entity). In some embodiments, additional cost details of the drugs/devices 302-pd (e.g., the co-paid 421-pd, the claim free 423-pd, the co-insurance 427-pd, the patient pay-off cost) may be provided as part of the sub-block 480.

As described above, information in sub-blocks received or transmitted by PBM 150 may be encrypted. When the PBM 150 is aimed at, the received sub-blocks may be decrypted by the PBM 150, while the sub-blocks transmitted by the PBM 150 may be decrypted by the intended recipient.

Fig. 5 illustrates an exemplary Pharmacy Prescription Record (PPR) 500 that may be maintained by an entity, such as pharmacy 160. A pharmacy refers to any entity (physical, virtual, or mail order) that completes a prescription written by a medical provider, such as HCP 120. The pharmacy may receive the prescription from the HCP 120, verify patient coverage information to the payer 140 and/or PBM 150, and interact with the patient to complete the prescription and receive payment from the patient (e.g., based on coverage, by collecting one or more of negotiated price of drugs/devices, common payment, claim free, common insurance, etc.) according to any contracts and/or payment arrangements with the payer 140/PBM 150.

In some embodiments, the PPR 500 may be owned and maintained by the pharmacy 160 (e.g., in the PPI database 165). In some embodiments, the data fields in the PPR 500 may be populated and/or updated by the pharmacy 160 based in part on information received from the patient/HCP 120 and/or the payer 140 and/or other entities. PPR 500 may also include (e.g., as a sub-block) data received from other entities. The fields shown in PPR 500 are merely exemplary, and PPR 500 may include various other additional fields based on law, standards, pharmacy practices, and/or industry practices, among others. The PPR may include fields that are different (fewer or more than those fields) than those shown with respect to the exemplary PPR 500.

In some embodiments, PPR 500 may include a pharmacy details field 595 that may store information about the pharmacy 160 (e.g., pharmacy identification, contact information, address, etc.). In some embodiments, some or all of the information in pharmacy data 595 may optionally be shared with other entities in connection with transactions. For example, a portion of pharmacy data 595 may be sent to one or more entities, such as PMDP 130, payer 140, and/or pharmacy 160 (e.g., as part of an encrypted sub-block that may be capable of being decrypted by a designated receiving entity) and/or shared with the patient.

In some embodiments, PPR 500 may include a patient information field 510, which may include subfields patient name 204, DOB 220, patient coverage information 572, PBM information 582, and patient collective payment 421-pd. PPR 500 may also include a prescription code 250 for the prescription 255-p, HCP data 295 (e.g., healthcare provider ID, registration number, contact information, etc.) associated with the prescribing entity for the prescription 255-p, prescription drugs/devices 255-ps associated with the prescription 255-p, duration 265-ps, and dose 260-ps. In some embodiments, PPR 500 may include various other fields (not shown in fig. 5) such as prescription date, fulfillment status (e.g., whether or not medication is ready to be taken, taken and/or delivered to a patient, etc.).

In some embodiments, the patient information 510 (including the sub-fields patient name 204, DOB 206, portions of patient coverage information 572), the prescription code 250, the prescription drug/device 255-ps, the duration, the dose, and the HCP profile information may be received by the pharmacy 160 from the HCP 120 as an encrypted sub-block 290 that may be decrypted by the pharmacy 160 upon completion of the prescription. For example, the HCP 120 and/or the patient may select one drug/device 255-ps from each drug/device class 337-p and provide the selected drug/device 255-ps to the pharmacy 160 as part of the sub-block 290.

In some embodiments, upon receiving and decrypting the sub-block 290, the pharmacy 160 may use patient coverage related information (e.g., coverage related information 272, which may be received as part of the sub-block 290) to determine the PBM and/or payer associated with the prescription.

In some embodiments, the pharmacy may send some or all of the information in sub-block 290 to payers 140 and/or PBM 150 (e.g., according to any current regulations). The information sent by pharmacy 160 to payer 140 and/or PBM 150 may be in the form of encrypted sub-blocks (not shown in fig. 5) that may be decrypted by a designated entity (e.g., payer 140 and/or PBM 150). In response, pharmacy 160 may receive encrypted sub-block 490 from payer 140 and/or PBM 150 and decrypt it. Sub-block 490 may include verification information (e.g., regarding patient coverage) that may be used by pharmacy 160 to verify and update patient coverage information 572, as well as update PBM information 582. In some embodiments, PBM 150 and/or payer 140 may further include collective payment information 421-ps for prescription drugs/devices 255-ps associated with prescriptions 250-s.

In some embodiments, PPR 500 may further include transaction information 515, which may store information related to the transaction, such as patient cost 515 (such as common insurance 421-ps as prescribed by pharmacy 160), payer cost 525 (e.g., amount of money to/to bill payer 140 and/or PBM 150), and payment mode (e.g., for use by the patient). For example, in some cases, where PMDP 120 provides patient assistance (e.g., as part of a patient assistance program) with a common payment (or other pay-as-a-patient cost), PMDP 120 (or the entity acting on behalf of PMDP 120) may provide a discount card, discount code, or prepaid card, which may be presented to pharmacy 160 as a payment and recorded in payment mode field 530.

Fig. 6 illustrates an example Health Transaction Record (HTR) 600. As shown in fig. 6, HTR 600 may include treatment and cost related information for transactions associated with a patient. The fields shown in HTR 600 are merely exemplary, and HTR 600 may include various other fields based on laws, standards, industry practices, etc. Further, the HTR may include fields that are different (fewer or more than those fields) than those shown with respect to the exemplary HTR 600. In some embodiments, the HTR 600 may be owned and maintained by an entity, such as the payer 140 (e.g., a health insurance company and forming part of the transaction information database 147), which may be responsible for transaction approval and/or payment to one or more entities associated with the transaction.

The HTR 600 may include various data fields including information about entities associated with and/or authorized to transact with the payer 140, including patient data 195, HCP data 295, PMDP data 395, PBM data 495, and pharmacy data 595. The stored data may include information for effecting transactions (e.g., payments, rebates, coverage verification, treatment/prescription authorization, etc.) between entities.

The HTR 600 may include cost information 605, which may include a cost view of the payer associated with the transaction. For example, cost information 605 may include payer cost 610, which may record the net cost of payer 140 to the transaction. The payor cost 610 may be a function of one or more of the following: PBM cost 612, pharmacy cost 615 (e.g., the price charged by pharmacy 160 to payer 140), PMDP cost 620 (e.g., the negotiated price between payer 140 and PMDP 120), rebate 622 (e.g., received by payer 140 from PMDP 120), HCP treatment cost 625 (e.g., the diagnosis-related treatment cost provided by HCP 120), and patient cost 630 (e.g., the patient pay-for-care cost 635 determined by payer 140 according to the plan, which may include a patient common payment 632, claim free amount 637, and common insurance 639 for treatment and prescriptions). Some of the information associated with the cost information 605 may be available to the payer 140 (e.g., based on a contract, etc.), while some of the cost information 605 may be provided by other entities (e.g., via encrypted sub-blocks that may be decrypted by the payer 140) before the transaction is completed. For example, PBM cost information 612 may be determined by decrypting information included in an encrypted sub-block 480 that may be transmitted by PBM 150 to payer 140.

As another example, the HCP 120 may send the payer 140 an encrypted sub-block 282 with coverage related information 272, plan ID 270, and/or HCP profile 295. Payer 140 may decrypt information sub-block 282 and verify patient coverage using additional patient coverage information 698. Verification of patient coverage may be provided to the HCP 120 by sending an encrypted sub-block with verification information to the HCP 120 that may be decrypted by the HCP 120. Some or all of the additional patient coverage information 698 may also be sent to the PBM 150 (e.g., as an encrypted sub-block that may be decrypted by the PBM 150) to facilitate verification of patient coverage (e.g., with respect to prescriptions) by the PBM 150.

As another example, the encryption sub-block 280 (which in some cases may include information in sub-block 282) may be sent (e.g., once the prescription has been completed) by the HCP 120 to the payer 140 for verification and transaction approval. In some embodiments, the encryption sub-block 280 may be decrypted by the payer 140, and the payer 140 may approve the transaction by sending one or more confirmation messages (e.g., to the HCP 120 and/or other entity).

In some embodiments, EHR 600 may be stored as part of a local blockchain maintained by payer 140 and accessible to the payer upon completion of the transaction. EHR 600 in encrypted form (and decryptable by payer 140) may also form part of a multidimensional block in a multidimensional block. Information not in EHR block 600 of the multidimensional block chain may be encrypted by other entities and may not be decryptable by payer 140. Conversely, EHR block 600 in a multidimensional block may not be decryptable by other entities associated with payer 140 and/or the platform. Thus, while each entity has a consistent view of transactions recorded as multidimensional blocks in a chain of multidimensional blocks, the entity cannot view information in blocks owned by other entities (stored as part of the multidimensional blocks). Thus, information in blocks owned by a first entity (stored as part of a multidimensional block) is securely masked from view by other second entities.

Fig. 7A shows a flow chart illustrating a process flow 700 for facilitating healthcare cost determination, healthcare information security, and interoperability between multiple entities. In some embodiments, portions of process flow 700 may occur on a licensed block chain platform, which may be obtained by a subscribing and/or authorized entity. In some implementations, some or all of the flow 700 may be implemented using an application running on a computing device associated with an entity. In flowchart 700, some routine messages (e.g., patient coverage verification, etc.) are not shown for ease of description.

For example, the patient 170 may initiate a transaction using an application running on a mobile computing device (e.g., a smart phone, tablet computer, laptop computer, etc.). In some embodiments, the application may be provided and/or authorized by an entity associated with the license block chain platform. For example, an application program (e.g., running on a mobile computing device associated with the patient 170) may already be provided by a first entity (e.g., the HCP 120, the PMDP 130, a health exchange, and/or a patient access program (not shown in fig. 7)) and may communicate with the first entity using an Application Programming Interface (API) and/or other network and communication protocols.

In some embodiments, at 705, the patient 170 may provide information and coverage information to the HCP 120, the pharmacy 160, and optionally to one or more of the PMDP 130 and/or one or more other entities. For example, the patient 170 may provide (or may have previously provided) patient information and coverage related information to the HCP 120 at or before the time of the acquisition of the treatment and/or to the pharmacy 160 at or before the completion of the prescription. In some cases, the patient 170 may have provided patient profile and coverage information to the PMDP 130 to participate in and/or acquire payment assistance. As described above, the patient profile and coverage information may be provided (or already provided) using an application on a mobile device that interacts with and/or is associated with an entity authorized to conduct transactions on the licensed block chain platform.

In some embodiments, HCP 120 may provide coverage related information 272 and plan ID 270 to payers 140 and/or PBMs 150 in an encryption sub-block 282 (not shown in fig. 7A), which may be capable of being decrypted by the respective receiving entity. The payer 140 and/or the PBM 150 may respond with additional encrypted sub-blocks (not shown in fig. 7A) that verify patient coverage that may be decrypted by the HCP 120.

In some embodiments, at 710, the HCP 120 may determine the diagnosis 235 and may initially provide the corresponding diagnostic code 240 and indication 242, the treatment code 245 associated with treatment for the diagnosed condition, and the prescription 250 (e.g., drug/device 255-p, corresponding doses 260-p, each dose associated with a corresponding duration 265-p). In some embodiments, the HCP may further obtain or determine the transaction ID 695 (as the initiator of the transaction). In some embodiments, the above information, along with patient criteria 297, HCP profile 295, plan ID 270, and optionally coverage information 272, may be sent to PMDP 130 as an encrypted EHR sub-block that may be decrypted by PMDP 130. For example, when authorized by the patient (e.g., when the patient is participating in or wants to apply for a payment assistance item associated with the PMDP 130), the coverage information 272 may be sent (in EHR sub-block 280) to the PMDP 130.

In some embodiments, in step 715, PMDP 130 may determine a corresponding medication class 337-p for each of the medications/devices 255-p in prescription 250. Additionally, the PMDP 130 may determine one or more drugs/devices 302-pd associated with each category 337-p.

At 720, the PMDP 130 may send the encrypted DIR sub-block 380 (or a portion thereof) with the class member drugs/devices 302-pd along with the diagnosis 235 (and related fields, such as the corresponding diagnostic code 240 and indication 242, treatment code 245) and transaction ID 695 to the PBM 150. The DIR sub-block 380 may further include information about each drug/device 302-pd (e.g., as described above with respect to fig. 3A-3C). In some cases (e.g., when payer 140 performs the function of PBM 150 and/or does not use PBM), DIR sub-block 380 may be sent to payer 140. The DIR sub-block may be capable of decryption by a designated receiving entity.

At 725, the PBM 150 (or the payer 140) may respond to the PMDP 130 with an encrypted PBR sub-block 480 that may include information about the payer's 140 prescription list 405, the level 415-j associated with each drug/device 302-pd, pricing information for each drug/device 302-pd, including one or more of: the common payment 421-pd, the common insurance 423-pd, the claim free 423-pd, and the price 425-pd. Sub-block 480 may reference transaction ID 695. For example, the PBM 150 (or payer 140) may determine the information in sub-block 480 based on the plan information (plan 1d 270 and/or coverage related information 272) in the DIR sub-block 380 and/or by looking up the coverage information associated with the patient 170 using the transaction ID 695 and transaction type. PBR sub-block 480 may be capable of decryption by PMDP 130.

In step 730, the PMDP 130 may decrypt the PBR sub-block 480 and use the level 415-j and pricing information (e.g., one or more of the total pays 421-pd, the total insurance 423-pd, the claim free 423-pd, and the price 425-pd) for each medication 302-pd along with patient criteria (e.g., location, pharmacy number, time period, etc.) to determine cost information 395 associated with the prescription. The cost information 395 may take into account any payment assistance to be received by the patient (when qualified) through the payment assistance project. In some embodiments, the cost indicator 395 may include a cost detail 307-pd, which may be a patient pay-per-drug/device 302-pd cost.

In 735, the PMDP 130 may send the encrypted DIR sub-blocks 380 and 390 with the cost information to the HCP 120. DIR sub-blocks 380 and/or 390 may include transaction ID 695, prescription code 250, drug/device categories 337-p corresponding to each drug/device 255-p in the initial prescription (e.g., at 710), and drug/devices 302-pd corresponding to each drug/device category 337-p.

At 740, the HCP 120 may send an encrypted sub-block 280-2 with the transaction ID 695 and a transaction type indicating approval of the prescription by the HCP to one or more of the HCP 120, the PBM 130, and/or the payer 140. Encryption sub-block 280-2 may further include selected drug devices 255-ps, where 1.ltoreq.p.ltoreq.p, and for each drug/device class P, 1.ltoreq.s.ltoreq.d_p, for example, one drug/device 255-ps may be selected from each drug/device class 337-P. In some embodiments, EHR sub-block 280-2 is encrypted. Each encrypted EHR sub-block 280-2 may be decrypted by a designated receiving entity. The information in encryption sub-block 280-2 may be similar to sub-block 280 (e.g., in fig. 2).

At 745, upon approval by payer 140 and/or PBM 150, the platform (e.g., private license block chain platform) may send transaction ID 695 and the transaction type indicating the confirmation of the transaction to the entity associated with the transaction. Upon receipt of the acknowledgement, each entity may add its respective encrypted record (e.g., EHR 200 for HCP 120, DIR record for PMDP 120, PBR from PBM 140, PPR for pharmacy 160, and HTR for payer 140) to the local blockchain. Further, two or more of the above-described encrypted records may form part of a multidimensional block 750 in a multidimensional block chain (not shown in FIG. 7A). The encrypted blocks in the multidimensional blocks (e.g., EHR 200 for HCP 120, DIR 300 for PMDP 120, PBR 400 for PBM 140, PPR 500 for pharmacy 160, and HTR 600 for payer 140) may be decrypted by the entity encrypting the blocks and may not be decrypted by any other entity. Thus, while each block represents a view of the transaction of an entity, that view is consistent with views of other entities related to the same transaction, because each block includes (via the received sub-blocks) approved information from other related entities when the transaction is completed. Furthermore, while each multidimensional block in the multidimensional block chain represents a snapshot of the final transaction as seen by the entity as the transactor, information in any single encrypted block (e.g., one of EHR 200, DIR 300, PBR 400, PPR 500, or HTR 600 in fig. 7A, respectively) owned and encrypted by a particular entity (e.g., one of HCP 120, PMDP 120, PBM 140, pharmacy 160, or payer 140 in fig. 7A) is shielded from non-owning entities. As shown in fig. 7A, the multidimensional blocks 750 are visualized as cubes (multidimensional volumes), wherein each face of the cubes represents a block associated with an entity that is the transactor. One or more of steps 715 through 740 may be repeated in the event that the PBM 150 and/or the payer 140 and/or another entity does not approve the transaction.

At 755, the PMDP 130 or platform may send payment assistance information to the patient 170 (e.g., via an application on a mobile computing device associated with the patient). The payment assistance information may take the form of an electronic credit card, code, or any other payment type (e.g., virtual debit/credit card, physical debit or credit card, etc.), which may be used to cover some or all of the patient's pay-as-you-go costs (e.g., for one or more specific drugs/devices 255-ps in the prescription and/or the entire prescription).

At 760, the pharmacy 160 sends a prescription confirmation (e.g., via an application and/or any other allowable communications such as secure text messages, secure emails, etc.) to the patient 170 indicating receipt and/or availability of the prescription. In some embodiments, when a prescription is acquired (e.g., in person, online, etc.), the patient 170 may present payment assistance information to reduce the pay-as-you-go.

Fig. 7B depicts entities and layers associated with an exemplary platform that facilitates security and interoperability of a healthcare system. In some implementations, various entities HCP 120, PMDP 130, payers 140, etc. may form part of the license block chain platform. In the license block chain platform, trusted entities may form a platform and invite other trusted entities to join the network. In some embodiments, the license block chain platform may also be private (e.g., to the invited and/or authorized entity). In some implementations, the license block chain platform may support a multidimensional block chain. Rules related to accessing and adding blocks to the multidimensional block chain, program code for determining contracts (e.g., smart contracts) between entities, applications utilizing platform functionality (e.g., on behalf of patient 170), verification of updates, etc., may be determined and/or authorized by the entity associated with the licensed block chain platform.

In some embodiments, the license block chain platform may take the form of a cloud-based system. Cloud-based systems refer to infrastructure, applications, services, and/or other resources (including hardware resources) that are available over a network (e.g., the internet). Cloud-based systems may be based on underlying hardware and software resources, and may be public (e.g., available to owners on a computing cost basis), private (e.g., limited to organizations), or hybrid (using some combination of public and private clouds). In some embodiments, the entities associated with the platform may be represented by servers (hardware and/or software), which may be cloud-based in some cases. For example, HCP 120, PMDP 130, and/or payer 140 may include agents running on servers, and/or agents running on cloud-based platforms including Virtual Machines (VMs).

In some embodiments, access to the functionality provided by the license block chain platform may be facilitated through a layer or API associated with the platform. For example, the patient 170 and/or another authorized entity acting on behalf of the patient (e.g., an entity facilitating access to payment assistance items provided by the PMDP 130) may provide a mobile application (e.g., running on a smart phone or other mobile computing device) that interacts with the cloud-based license block chain platform to facilitate: (a) Patient selection and associated cost metrics associated with the initial prescription of patient 170 (e.g., as indicated by data in sub-block 280-1 in fig. 7A) are determined based on patient criteria 297, and (b) prescription completion (e.g., as indicated by data in sub-block 280-2 in fig. 7A) is combined with delivery of payment assistance to patient 170.

As shown in fig. 7B, the multidimensional blocks 750 include EHR information block 200, DIR information block 300, PBR information block 400, PPR information block 500, and HTR information block 600. In some implementations, the multidimensional blocks 750 can form part of a chain of multidimensional blocks. In the multidimensional block 750, the EHR information block 200, the DIR information block 300, the PBR information block 400, the PPR information block 500, and the HTR information block 600 may be encrypted and decrypted by the HCP 120, the PMDP 130, the PBM 150, the pharmacy 160, and the payer 140, respectively.

In addition, EHR information block 200, DIR information block 300, PBR information block 400, PPR information block 500, and HTR information block 600 may also form blocks in EHR block chain 772, DIR block chain 773, PBR block chain 764, PPR block chain 775, and HTR block chain 766, respectively. As shown in fig. 7B, EHR block chain 772, DIR block chain 773, PBR block chain 764, PPR block chain 775, and HTR block chain 766 may be owned and maintained locally by HCP 120, PMDP 130, PBM 150, pharmacy 160, and payer 140, respectively. Fig. 7B also depicts sub-block 280 (which forms part of EHR block 200), sub-blocks 380 and 390 (which form part of DIR block 300), and sub-block 480 (which forms part of PBR block 400). As described above, the information in the sub-blocks may already be shared between some of the entities associated with the transaction prior to completion of the transaction, and may be consistent across the multiple blocks forming part of the multidimensional block 750 (at the completion of the transaction). In some embodiments, each field associated with an information block 200, 300, 400, 500, and/or 600 may have a unique global field id that may uniquely identify the field within the multidimensional block chain system and/or identify the field to a related entity when information related to the field is shared between the entities. The multidimensional blocks may include data and a timestamp. The time stamp may determine the order in which the multidimensional blocks (once completed) are linked.

As shown in fig. 7B, the HCP 120, the PMDP 130, the PBM 150, the pharmacy 160, and the payer 140 may interact with the authentication layer 770. The authentication layer 770 may include functionality for identification and management (addition, registration, authorization, and deletion) of system entities and/or applications (e.g., mobile applications) that use (or request to use) the functionality provided by the license block chain platform. Further, the authentication layer may include functionality for verifying permissions related to operations involving: (a) multidimensional block chains (add new blocks, create links, etc.); (b) Transaction type (e.g., whether an entity may initiate or participate in a specified transaction type), etc. The authentication layer 770 may interact with a consensus layer 780 that may include functionality for determining the ordering of transactions and verifying the correctness of a set of transactions associated with the multidimensional block 750.

In some implementations, the consensus layer 780 can confirm the correctness of the transactions that make up the multidimensional block. Upon completion of the transaction, the consensus technique applied by consensus layer 780 may confirm the correctness of the transactions (including the data shared between the entities) that make up the multidimensional block. In some embodiments, whether the multi-dimensional block 750 may be formed using constituent blocks (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 determined using a consensus technique, such as a Bayer Fault Tolerance (BFT) or variations thereof, such as redundant BFT, fast bayer consensus, dynamic quota, or some other voting-based consensus technique. A consensus is reached when an authorized entity (e.g., payer 140 or a trusted entity specified for the transaction/transaction type) or some specified number (e.g., all or a majority) of entities verify the transaction or block. The determination of consensus or transaction verification may vary depending on the type of transaction.

If the consensus technique confirms that the transaction is correct, a first instance of unlocked multidimensional block 750 can be formed. As shown in FIG. 7B, when the transaction is completed, unlocked multidimensional blocks 750 can be locked and added to the multidimensional blocks. In some implementations, the blocks forming 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 also be added as blocks to respective local block chains (e.g., EHR block chain 772, DIR block chain 773, PBR block chain 764, PPR block chain 775, and HTR block chain 766, respectively) upon completion of a transaction and upon locking of the multidimensional block 750. Thus, the information in the 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) also coincides with the information in the multidimensional block 750.

On the other hand, if the patient identified in patient ID 425 in block 480, for example, does not match the patient ID (e.g., in block 280), the transaction may be deemed incorrect and the block add request may be denied. In some embodiments, the platform or each entity may maintain a log of rejected transactions for traceability and debugging purposes. The log may indicate a reason or code associated with the transaction rejection.

In some embodiments, consensus layer 780 may apply consensus techniques and may interact with smart contract layer 790 to establish transaction correctness and/or validity and initiate further actions. The smart contract layer 790 may include program code that implements logic associated with the block chain. For example, a "smart contract" program code associated with a multidimensional chain of blocks may process a transaction request and determine the validity of the transaction based on program logic. The logic may depend on rules agreed upon by the entity with respect to transactions associated with the chain of blocks. For example, the smart contract layer 790 may reject transactions (e.g., from the HCP 120) due to incompatibilities between two or more drugs prescribed to the patient. The smart contract may operate at a verification time and a 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 regarding data sharing, transactions, etc., which may be based on real world contracts between these entities. In some implementations, each update to a legacy block chain (e.g., one of EHR block chain 772, DIR block chain 773, PBR block chain 764, PPR block chain 775, or HTR block chain 766) can be verified by smart contract program code associated with the platform. The smart contract program code may reflect agreements between entities relating to data sharing, authentication, payment, and the like. The smart contract layer may be viewed as an automated tool that facilitates interactions between entities without manual intervention. In some implementations, the smart contract layer may initiate actions based on rules associated with one or more contracts and when those rules have been satisfied. Each update and/or time lapse and/or other event made to the multidimensional block chain and/or specific request associated with a contract (e.g., identified by a contract ID) may trigger an action made by the smart contract layer.

Linking of updated records (e.g., updated record 520 and updated record 540) may be performed based on predefined rules agreed upon by the entities (e.g., HCP 120 and payer 140). In some implementations, linking of blocks (e.g., updated block 520 and updated block 540) can be performed based on a smart contract associated with a multidimensional block chain. After linking, the updated block 520 and the updated block 540 may be rehashed. As described above, the links may allow an entity to associate information in its block chain with information in a block chain maintained by another entity. Further, an entity may be able to determine one or more transactions associated with information in a particular block maintained by the entity. Thus, two or more entities may have coherent and consistent views of transactions associated with blocks in different block chains. During the formation process, multidimensional block 750 may be (at least initially) not fully formed (or an ongoing multidimensional block) such that blocks received from other entities may transform a currently ongoing (not fully formed) multidimensional block by adding another dimension. For example, the final HTR 200 (with a recipe from the HCP 120) may be added as a dimension to the multi-dimensional block currently in progress. Another dimension may then be added to the multi-dimensional block in progress, for example, a dimension with PPR 500 (with prescription information). This process may continue until the multidimensional block is fully formed (e.g., includes dimensions from all relevant parties to the transaction).

The multidimensional blocks (and their constituent records) may be locked upon completion of the transaction to prevent further modification and ensure a consistent view. Any subsequent modification may result in a new multidimensional block being added to the multidimensional block chain. For example, a new multidimensional block may be formed by an update to a data record of a single dimension, while the substantive information associated with other dimensions may remain unchanged. For example, drug related information (e.g., new contraindications) associated with drugs prescribed to the patient may be updated in the new multidimensional block (e.g., by PMDP 130) without updating other records.

The multidimensional blocks may take the form of a merck tree associated with a multidimensional block chain that includes constituent data records (e.g., EHR 200, DIR record 300, PBR 400, PPR 500, and HTR 600). As previously described, the data records may also be associated with different individual block chains.

Thus, the cryptographic hashes (e.g., separate cryptographic hashes (or "hashes") of EHR 200, DIR record 300, PBR 400, PPR 500, and HTR 600) of each record in different respective block chains (772, 773, 764, 775, and 766, respectively) may be obtained using different cryptographic hash functions, such that records owned by an entity are not decryptable or visible by other entities. A separate cryptographic function (which may be known to an entity associated with the licensed block chain platform, for example) may be used to obtain a combined cryptographic hash of the records such that the top hash is associated with the entire multidimensional block. In some embodiments, each multidimensional block can include a block header with a timestamp, a top hash, information related to a previous block, a pointer to the root of the merck tree, and other suitable information. The hash references may take the form of Uniform Resource Locators (URLs) and/or local (entity-specific) addresses on the private license block chain platform.

Fig. 7B shows a committed and locked multidimensional block 750 in which information from sub-blocks 480, 280, 380, and 390 has been shared among corresponding authorized related entities. In addition, multidimensional block 750 includes links between various constituent blocks. The multi-dimensional block 750 may represent, in part, an overall view of a transaction at a point in time, as it may include real world physical states associated with drugs (dosages, effects, etc.), patients (medical conditions, treatments, effects, etc.), and costs at that point in time. Multidimensional block 750 can also include links to previous blocks in a chain of blocks. Verified and final multidimensional block 750 can include final data records 200, 300, 400, 500, and 600, which can correspond to final information blocks 200, 300, 400, 500, and 600, respectively, in corresponding different local block chains 772, 773, 764, 775, and 766, respectively.

Fig. 8 illustrates a flow chart of an exemplary method 800 that facilitates healthcare information security and interoperability while facilitating patient treatment selection and transparency of treatment costs. In some implementations, the method 800 may use a multidimensional chain of blocks, which may be based on different chains of blocks maintained by various entities in the system. In some embodiments, the method 800 may be performed (at least in part) on a private license block chain platform, which in some cases may take the form of a cloud-based system. The method 800 may also be performed by a processor, a computer, or a network of computers such as a distributed computing system, servers (hardware and software) (including application servers), mobile computing devices (e.g., smart phones, smart wearable devices, handheld computers, tablet computers, laptop computers, etc.), and cloud-based systems.

In some implementations, the method 800 may be performed at a first entity. For example, the first entity may include at least one server or computer system associated with at least one of a drug provider or a medical device provider, such as PMDP 130. In some embodiments, a first entity may interact with one or more second entities. The second entity may include one or more servers or computer systems associated with a healthcare provider such as the HCP 120, the PBM 150, the pharmacy 160, or an insurance provider such as the payer 140, or the patient 170. In some embodiments, the first entity and the one or more second entities may form computing nodes in a distributed computing system, and the multidimensional block chain may form part of a licensed private block chain platform (such as a licensed private block chain platform).

In some embodiments, the method 700 may be invoked when an entity, such as a first entity, initiates a transaction (e.g., with a transaction ID and/or transaction type) to add a chunk to a locally maintained chain of chunks. Adding a block to a local block chain may involve input from one or more other entities, and the license private block chain platform may invoke method 800.

In some embodiments, in step 810, the first entity may receive at least one encrypted first Electronic Health Record (EHR) sub-block (e.g., sub-block 280-1) decryptable by the first entity, wherein the at least one EHR sub-block includes patient medical coverage information for the patient and one or more first treatments (with drug/device (first treatment) 255-P, prescription 250 of 1+.p+.p). For example, the one or more first treatments may include drugs D1, D2, D3, and D4.

In step 820, the first entity may transmit at least one encrypted first device medication information (DIR) sub-block (e.g., DIR sub-block 390) that may be decrypted by at least one corresponding second entity (e.g., HCP 120) in response to the first EHR sub-block, wherein the at least one first DIR sub-block includes, for each of the one or more first therapies (255-p), a corresponding first therapy class (337-p), one or more corresponding first therapy class members (302-pd, 1 +.d +.D_p) each associated with the corresponding first therapy class, and for each first therapy class member (302-pd), corresponding first therapy class member cost information (395, 397-pd).

For example, the first treatment category may include categories C1, C2, C3, and C4 corresponding to drugs D1, D2, D3, and D4, respectively. In addition, each category may include members as follows: c1 = { D11, D12}; c2 = { D21}; c3 = { D31, D32, D33, D34}; and c4= { D41, D42, D43}, where D1 εc1, D2 εc2, D3 εc3, and D4 εc4. Cost information may be provided for each category member (e.g., individually, as in cost detail 397-pd, and aggregate, as in cost index 395).

In step 830, the first entity may receive an encrypted second EHR sub-block (e.g., sub-block 280-2) in response to the first DIR sub-block, wherein the second EHR sub-block includes one or more second therapies (e.g., therapies 255-pd selected from therapies 302-ps), wherein each of the one or more second therapies (255-ps) is associated with a corresponding first therapy (302-pd), and each second therapy (255-ps) is selected from a corresponding first therapy class member (337-pd) associated with a corresponding first therapy (255-p); for example, the second treatment may include second treatments D12, D21, D31, and D43 selected from categories C1, C2, C3, and C4, respectively, wherein the second treatments D12, D21, D31, and D43 (e.g., via categories C1, C2, C3, and C4, respectively) are associated with corresponding first treatment category members (D1, D2, D3, and D4, respectively) in the first treatment (e.g., the initial prescription). In some embodiments, one or more second treatments in the second EHR block may be based on a patient-specific cost indicator.

In block 840, the first entity may amplify a multidimensional block chain, wherein the multidimensional block chain is amplified with a multidimensional block (e.g., multidimensional block 750) formed by linking: a DIR block (e.g., DIR block 300) including information associated with one or more second therapies, an EHR block (e.g., EHR block 200) including information associated with a second EHR sub-block (e.g., sub-block 280-2), and a transaction block (e.g., HTR 600). In some embodiments, the transaction block may include a prescription for the second treatment at a specified location specifying the cost of the patient.

In some implementations, upon receiving the first EHR sub-block (e.g., in step 810), the first entity may: corresponding first treatment categories (337-p-e.g., categories C1, C2, C3, and C4, respectively) are determined for each of the one or more first treatments (255-p-e.g., D1, D2, D3, and D4), wherein each corresponding first treatment category includes one or more corresponding first treatment category members (302-pd-including at least members of C1, C2, C3, and C4 of D1, D2, D3, and D4, respectively). In addition, for each corresponding first treatment category (337-p-e.g., C1, C2, C3, and C4), the first entity may determine one or more corresponding first treatment category member cost information for one or more corresponding first treatment category members associated with the first treatment category (e.g., individually, as in cost detail 397-pd for each of C1, C2, C3, and C4, and/or collectively, as in cost index 395).

In some embodiments, the first EHR sub-block (e.g., 280-1) may include patient-specific parameters (e.g., including patient criteria 297), and the at least one treatment category is determined based on the patient-specific parameters. The patient-specific parameters may include one or more of the following: patient co-morbid information; route of administration information (335-pd), safety information (330-pd) and efficacy information (337-pd); and/or patient location information.

In some embodiments, for each first treatment (255-p), corresponding first treatment category (337-p) and corresponding first treatment category member cost information (395, 397-pd) for each treatment category member (302-pd) may be determined based on patient medical coverage information. For example, the cost information may be determined further based on one or more of: (a) A provider (e.g., pharmacy 160) located within a specified distance of the patient's location, wherein the patient's location information is included in a first EHR sub-block (e.g., coverage related information 272 and/or a portion of patient profile 230 in sub-block 280, which may include information in sub-blocks 282 and/or 284); and/or (b) patient-specific pay-as-you-go costs for the corresponding treatment units (e.g., dose and duration) corresponding to each corresponding first treatment category member (302-pd); and/or (c) a patient-specific estimated total pay-as-you-go cost (392-pd) for a typical treatment duration corresponding to each corresponding first treatment category member (302-pd); and/or (d) patient-specific estimated total pay-per-view costs for each corresponding first treatment category member (302-pd) for the remaining duration of the medical coverage plan associated with the patient (e.g., the date until the end of the current patient coverage).

In some embodiments, upon receiving the second EHR sub-block (e.g., in step 830), the first entity may determine payment assistance information for at least one of the one or more second therapies; and transmitting payment assistance information with the transaction confirmation to the patient. In some embodiments, upon receiving the second EHR sub-block (e.g., in step 830), the first entity may transmit a transaction confirmation including at least one prescription for the one or more second therapies to the patient along with the payment assistance information.

The payment assistance information may take the form of an electronic credit card, code, or any other payment type (e.g., virtual debit/credit card, physical debit or credit card, etc.), which may be used to cover some or all of the patient's pay-as-you-go costs (e.g., for one or more specific drugs/devices 255-ps in the prescription and/or the entire prescription). Thus, in some cases, the payment assistance information may include an actual monetary payment to the patient 170 and/or pharmacy 160. For example, in some cases, where payment assistance may be used, the payment assistance may specify a medication and/or pharmacy (or pharmaceutical company).

Fig. 9 shows a flow chart illustrating a process flow 900 that facilitates healthcare insurance selection and cost determination while maintaining healthcare information security and facilitating interoperability between multiple entities. In some embodiments, portions of process flow 900 may occur on a licensed block chain platform, which may be obtained by a subscribing and/or authorized entity. In some implementations, some or all of the flow 700 may be implemented using an application running on a computing device associated with an entity. In flowchart 900, some routine messages are not shown for ease of description.

For example, the patient 170 may initiate a transaction using an application running on a mobile computing device (e.g., a smart phone, tablet computer, laptop computer, etc.). In some embodiments, the application may be provided and/or authorized by an entity associated with the license block chain platform. For example, an application program (e.g., running on a mobile computing device associated with the patient 170) may already be provided by a first entity (e.g., the HCP 120, the PMDP 130, and/or a patient access program (not shown in fig. 9)) and may communicate with the first entity using an Application Programming Interface (API) and/or other network and communication protocols. In some embodiments, patient 170 may invoke an application in communication with an entity such as PMDP 130 (shown in FIG. 9), or a patient assistance item, patient access program, etc. associated with the licensed block chain platform. Thus, in some embodiments, an application may act on behalf of an entity (e.g., PMDP 130), and valid and authorized transactions, communications, etc. related to the application may behave as if the entity (e.g., PMDP 130) is executing the transaction, or may be forwarded by the entity (e.g., PMDP 130) (after authorization, authentication, and appropriate processing/encoding).

For the purpose of the following description, the PMDP 130 has been used as an example. However, process flow 900 may also be practiced by other entities, such as patient assistance items and/or patient access procedures, which may assist patient 170 in acquiring health coverage and/or qualifying for patient assistance. As described above, an application (e.g., used by the patient 170) may act on behalf of an entity in a manner transparent to the patient 170. Thus, in some cases, the action indicated in fig. 9 as being performed by the patient 170 may occur through and/or be attributed to another entity (e.g., the PMDP 130). In some embodiments, the private entity providing the selection of several insurance plans may provide an application implementing process flow 900 to potential subscribers (e.g., shown as patient 170 in fig. 9) to facilitate selection of appropriate coverage.

In many cases, the patient often requires or repeatedly uses treatment (drugs, devices and/or procedures). The term "recurrent treatment" is used herein to refer to the administration, device, and/or procedure prescribed to a patient for medical conditions that are present (ongoing), and/or chronic, and/or likely to occur, and/or that will occur/manifest repeatedly (e.g., without recommended treatment) over an extended period of time (e.g., weeks, months, or years). For example, various conditions (e.g., diabetes, blood pressure, heart disease, kidney disease requiring dialysis, etc., and/or other chronic conditions) may require an extended period of time within which to apply or prescribe therapy. In these cases, the drug (e.g., medication), device (e.g., drug delivery device), or treatment (e.g., physiotherapy, dialysis, etc.) may be repeatedly used and/or prescribed over an extended period of time. However, in selecting an insurance plan, the patient typically does not have information about how the plan selection and/or the drug/device selection affects the total medical costs (premium paid to the plan, amount of claim paid, common payment paid, common insurance paid, less any payment assistance received). In some embodiments, some disclosed embodiments of the process flow 900 may be utilized to facilitate intelligent planning options to reduce costs while maintaining an appropriate level of treatment as described herein.

At 905, the patient 170 may initiate transmission of one or more of: patient recurring treatment information (e.g., drugs/devices used on an ongoing/recurring basis by patient 170) and/or coverage related information 272. For example, the patient 170 may indicate (e.g., using an application on the mobile computing device) that the stored coverage related information 272 and stored prescription information related to some prescriptions (e.g., selected by the patient 170) or all prescriptions are sent to and/or stored by an entity such as the PMDP 130 (e.g., stored locally on the device and/or in the cloud, and/or stored by the entity). For example, a patient application that may track and store patient prescription and coverage information may send or initiate the sending of local or cloud-based coverage and prescription information to the PMDP 130 upon authorization of the patient 170. In some embodiments, an application, which may take the form of a health management application, may include one or more other functions: such as tracking patient prescriptions, indicating when premium payment/renewal expires, making payments, indicating when prescription treatments will be taken, providing replenishment reminders, automatically re-ordering prescriptions/supplements, tracking costs, scheduling and providing appointment reminders, and the like. Events 910 and 915 may not occur when an application transmits coverage related information 272 and prescription information to the PMDP 130.

In some embodiments, transmission of coverage related information 272 and/or recurring treatment information may also be initiated by providing authorization to send prescription data to PMDP 130 (e.g., to payers 140 and/or PBM 150 and/or to one or more entities that may store patient health related information). In the case where authorization is provided and the coverage related information 272 and/or recurring treatment information is provided by one or more external entities, such as the payer 140 and/or the PBM 150, then at 910, the PMDP 130 may transmit to the one or more payers 140-V (1V) and/or the PBM 150-U (1U) an HTR request with patient authorization to obtain the coverage related information 272 and/or the recurring treatment information. At 915, the payer 140-V (1. Ltoreq.v) and/or the PBM 150-U (1. Ltoreq.u) may respond with the requested information about the patient 170 (e.g., in response to the PMDP 130).

In block 920, the PMDP 130 may determine that the patient is using the recurring treatment. The term "repeatedly occurring treatment" is used to refer to the administration, equipment and/or treatment prescribed to a patient for a medical condition that is likely to occur during a coverage period or that will exist over an extended period of time (e.g., days, weeks or months). Recurrent treatments differ from disposable treatments (e.g., for individual medical conditions such as a disposable/transient antibiotic regimen to cure opportunistic/unpredictable infections). In some embodiments, the information in the HTR sub-blocks may be analyzed to determine recurring patient treatments contained in the HTR sub-blocks (e.g., via treatment codes 245, prescribed drugs/devices 255-p, doses 260-p, and durations 265-p). Where patient treatment information is available (e.g., via an application used by patient 170), patient treatment may be provided by the application, and PMDP 130 may determine (e.g., in step 920) recurring patient treatment based on the provided information.

In some embodiments, at 925, the PMDP 130 may send a request for available planning information to the Health Exchange (HEX) 180. The HEX 180 may be any entity that provides a plan for consumer subscriptions. For example, the HEX 180 may be a government authorized entity that provides plans according to the plain medical act (ACA), or a department or affiliated contractor of a private employer that provides employees with multiple plans for selection/registration (e.g., during open participation periods). The request for planning information may not include PII information related to the patient 170 and may specify the type of information requested. In some embodiments, the request for the plan information may request a list of payers 140-v and PBMs 150-u that provide the plan in the location specified by the patient 170, as well as a plan identification (e.g., a plan ID and/or a group ID) for each provided plan. In some cases, where the list of payers 140-v and PBMs 150-u, and the plan identification information are publicly available (e.g., via published information), then the published information may be accessed by the PMDP 130 to obtain the information without the need for a PMDP 130 request (at 925) and a HEX 180 response (at 930).

In some embodiments, at 930, the HEX 180 may respond with a list of payers 140-v and PBMs 150-u providing the plan in the location specified by the patient 170, as well as a plan identification (e.g., a plan ID and/or group ID) for each provided plan (or, alternatively, the above information may be determined by the PMDP 130 using publicly available information, as described above).

In some embodiments, in step 933, PMDP 130 may determine treatment class 337-r and treatment class members 302-rd for each recurring treatment (drug, device, and/or procedure) 255-r associated with patient 170, where 1.ltoreq.d.ltoreq.D_r, where D_r is the number of class members in treatment class 337-r. The drugs/devices 302-rd in treatment category 337-r may: (a) treats similar treatment areas 360-r, and/or (b) has a similar mode of action/method 340-r, and/or (c) has a similar chemical structure 350-r. In addition, drugs/devices 302-rd in treatment categories 337-r may also share administration routes 335-rd and meet other patient criteria 297. For a medical procedure, members 302-rd of treatment category 337-r may: (a) Treating similar indications, and/or (b) specifying alternative facilities (e.g., species at a location) where the same/similar treatment is available (although possibly at a different price point).

In step 935, PMDP 130 may send DIR sub-blocks (e.g., DIR sub-block 380 including processing code 245 and/or other information in block 280) along with the plan identification information (e.g., plan ID and/or group ID) to one or more PBMs 150-u and/or payers 140-v as part of the request for pricing and coverage information (e.g., whether treatment is covered by a corresponding plan (e.g., available to patient 170)).

At 940, in some implementations, the PBM 150-u and/or payer 140-v may respond with prescription schedule information for each plan (e.g., as in sub-block 480) and/or authorization provider (e.g., for the procedure).

Alternatively, in some embodiments, when the prescription schedule information is publicly available (and/or available through the HEX 180) for each plan (e.g., as in sub-block 480) and/or authorized provider (e.g., for a program), then the publicly available information and/or information obtained from the HEX 180 may be used. For example, regulations may require that the plans (payers 140 and/or PBMs 150) issue and update prescription schedules and other coverage information, and thus, the most recently issued information or updates may be used to determine prescription schedule information for each plan (e.g., as in sub-block 480) and/or authorized provider (e.g., for a program). Thus, in some embodiments, events 935 and 940 may not form part of process flow 900, and as part of step 933, as a separate intermediate step between steps 933 and 945, and/or as part of step 945, PMDP 130 may determine prescription schedule information for each plan (e.g., as in sub-block 480) and/or authorized provider (e.g., for a program).

In some embodiments, in step 945, the PMDP 130 may determine total patient-specific cost information associated with each plan. For example, a cost C_hs may be assigned to each plan h and assigned based on selecting one treatment 302-rs from each treatment category 337-r. For example, for plan h, where recurring treatments (e.g., determined in step 920) are associated with four treatment categories, with one or more treatments in each treatment category 337-r, one treatment 302-rs may be selected from each of the four treatment categories to determine a patient-specific cost c_hs associated with the plan and the selected treatments. For example, the number of the cells to be processed,

c_hs= (premium in period) + (common payment) + (common insurance) + (rebate) - (payment assistance in period)

In some embodiments, patient-specific costs c_hs may be provided for various choices of treatment in each plan h. Accordingly, the patient 170 and/or the HCP 120 may be able to determine potential or likely costs associated with the plan prior to the plan selection. Payment assistance may be provided by PMDP 130 and/or by other entities (e.g., by a government paying a premium according to an ACA, or by a non-profit organization, by an organization/program affiliated with PMDP 130, and/or by tax refunds, etc.).

In some embodiments, the information may be provided in the form of a table (or database) as shown in table 1 below. The table may include information about plan h, the selected treatment group, cost c_hs, and the provider (e.g., pharmacy, location, etc.) of each selected treatment 302-rs. In some embodiments, the cost C_hs may further include a cost specification (common payment, common insurance, etc.) for each selected treatment 302-rs in the treatment group.

TABLE 1

In some embodiments, at 950, the cost information c_hs and other cost metrics may be sent to the patient 170 directly or indirectly (e.g., via the HEX 180, as shown by the dashed line). In some embodiments, the patient 170 may authorize the PMDP 130 to share treatment and cost information with the HCP 120, and/or the patient 170 may optionally share and discuss treatment information with the HCP 120.

At 955, the HCP 120 may recommend one of the treatment groups as appropriate, and the patient 170 may make a plan selection (e.g., by selecting a plan shown on the mobile device screen) and confirm the selection. The plan selected by the patient 170 may be the same as the plan recommended by the HCP 120 and/or any other available plan. After confirmation, the plan selection may be sent 955 to the HEX 180.

At 960, upon approval by payer 140 and/or PBM 150, a platform (e.g., a private license block chain platform) may indicate a transaction confirmation to an entity associated with the transaction. Upon receipt of the acknowledgement, each entity may add its respective encryption record (e.g., PBR for PBM 140, HTR for payer 140, and corresponding HEX record (not shown in fig. 9)) to the local blockchain. In some embodiments, when authorized, transaction confirmation may also be sent to PMDP 130 to facilitate participation and payment of benefits from the payment assistance program. In some embodiments, at 960, a platform (e.g., a private license block chain platform) may indicate a transaction confirmation by sending a planned subscription confirmation to the patient 170. Further, two or more of the above-described encrypted records may form part of multi-dimensional block 965, thereby augmenting the multi-dimensional block chain.

Fig. 10A and 10B illustrate a flow chart of an exemplary method 1000 that facilitates healthcare insurance selection and cost determination while maintaining healthcare information security and facilitating interoperability between multiple entities. In some implementations, the method 1000 may use a multidimensional chain of blocks, which may be based on different chains of blocks maintained by various entities in the system. In some embodiments, the method 1000 may be performed (at least in part) on a private license block chain platform, which in some cases may take the form of a cloud-based system. The method 1000 may also be performed by a processor, a computer, or a network of computers such as a distributed computing system, servers (hardware and software) (including application servers), mobile computing devices (e.g., smart phones, smart wearable devices, handheld computers, tablet computers, laptop computers, etc.), and cloud-based systems.

In some implementations, the method 1000 may be performed at a first entity. For example, the first entity may include at least one server or computer system associated with at least one of a drug provider such as the PMDP 130 and/or an application used by the patient (e.g., provided by the PMDP 130 or another entity) (which may interact and utilize functionality provided by the licensed block chain platform when the representative PMDP 130 and/or another entity is authorized). In some embodiments, a first entity may interact with one or more second entities. The second entity may include one or more servers or computer systems associated with a healthcare exchange such as the HEX 180, a pharmacy benefit manager such as the PBM 150-u, an insurance provider such as the payer 140-v, or the patient 170. In some embodiments, the first entity and the one or more second entities may form computing nodes in a distributed computing system, and the multidimensional block chain may form part of a licensed private block chain platform.

In some embodiments, the method 1000 may be invoked when an entity, such as a first entity, initiates a transaction (e.g., with a transaction ID and/or transaction type) to add a chunk to a locally maintained chain of chunks. Adding a block to a local block chain may involve input from one or more other entities, and the license private block chain platform may invoke method 1000.

Referring to fig. 10A, in step 1010, a first entity (e.g., the PMDP 130 and/or an application running a patient computing device such as a smartphone and/or another entity) may be obtained from at least one encrypted first Health Transaction Record (HTR) sub-block (e.g., sub-block 280 and/or other therapy related information in HTR 600) that may be decrypted by the first entity. In some embodiments, the HTR sub-block may be received in response to a request including patient authorization. The first entity may obtain (e.g., based on information in at least one first HTR sub-block) a first set of first therapies for the patient over a period of time, wherein each first therapy includes a first diagnostic code (e.g., diagnostic code 240) and a first therapy code (e.g., therapy code 245). In some embodiments, the first EHR sub-block may include therapy code 245, prescription drug/device 255-p, dose 260-p, and duration 265-p associated with a first (recurring) therapy 255-p. In some embodiments, the time period may include several previous coverage periods and include multiple payors 140-v, which may be advantageous in determining recurring and ongoing treatments.

In some embodiments, the first set of first treatments may be determined based on one or more of: the therapeutic code 245-p, prescribed drug/device 255-p, dose 260-p, and duration 265-p contained in the HTR sub-block. The first therapy may include recurring therapies, such as drugs, devices, and/or procedures 255-p, that may have been prescribed and/or likely will be prescribed within a specified period of time. In some embodiments, information in at least one first HTR sub-block (e.g., received by a first entity) may be analyzed (e.g., mathematically and/or statistically) to determine a first set of first treatments (e.g., repeated patient treatments). For example, the month recipe may be planned to continue until the end of a specified period of time (e.g., based on duration 265-p, based on a determined or planned frequency). In some embodiments, the planned and/or determined recurring treatments can be confirmed by the patient. In some embodiments, locally stored data (e.g., as part of a health management application) may be used to obtain a first set of first treatments.

In some embodiments, treatments associated with certain medical conditions known to be chronic or long-term (e.g., discernible via diagnostic code 240) may be automatically identified as recurring treatments. In other cases, the treatment that repeatedly occurs during the period of time may be determined to be the repeatedly occurring treatment. As another example, the treatment may be determined to occur repeatedly based in part on additional information such as a patient's calendar (e.g., as part of a health management application) that indicates a mode of scheduled appointment with the provider for a particular diagnostic code. Where an application (e.g., health management or other application) stores patient treatment and/or appointment information, recurring patient treatment information may be determined based on the stored patient treatment and/or appointment information. The first set of first treatments may be obtained from HTR 600 maintained by payer 140 and/or PBS 400 maintained by PBM 150, which may include a record of long-term treatments. In some embodiments, multiple payers 140-v and/or PBMs 150-u used by the patient (e.g., during some specified previous period) may be contacted to obtain information in the first HTR sub-block.

In some embodiments, in step 1015, a first entity (e.g., PMDP 130) may determine based on a first set of: (a) One or more second groups, wherein each second group includes a corresponding second treatment, wherein each corresponding second treatment is associated with a different first treatment in the first group, and (b) a corresponding number of iterations (e.g., within a specified period of time such as the duration of an intended coverage). The number of iterations may be used to determine the cost (e.g., by multiplying the cost per treatment by the number of proportional or normalized iterations over a period of time). In some embodiments, an application (e.g., running a patient computing device such as a smart phone) may obtain one or more second groups, corresponding to second therapies, and the recurrence corresponding to each second therapy from PMDP 130 (e.g., via a secure API).

For example, each first treatment (255-p) in the set of first treatments may be associated with a corresponding first treatment category (337-p). Each treatment category (337-p) may include one or more treatment category members (302-pd, 1.ltoreq.d.ltoreq.D_p). Each second group may include a corresponding second treatment (302-pd) associated with a different first treatment (255-p) via a first treatment category (337-p). Thus, for example, the corresponding second group may include one treatment class member (337-pd) from each treatment class (302-p) (which corresponds to the first treatment 255-p). Step 1015 may be considered to extend the set of currently prescribed therapies of the patient 170 to a similar class of available therapies.

In step 1020, a set of available insurance plans (e.g., plan IDs, group IDs, etc.) available to the patient (e.g., by the PMDP 130 and/or an application running a patient computing device such as a smartphone) and corresponding coverage related information (e.g., premium, claim free, common payment, common insurance, prescription schedule information, etc.) for each available insurance plan may be obtained. The available insurance plan and coverage related information may be obtained from the HEX 180, and/or the payer 140-v, and/or the PBM 150-u, and/or the employer (e.g., when the plan is employer sponsored) and/or from publicly available information (e.g., through published information available from government or other public sources). The set of available insurance plans and corresponding coverage related information may be obtained based on non-personal information associated with the patient (e.g., no patient PII is provided), such as location (country, state, county, city, zip code), age, etc. In some embodiments, an application (e.g., running a patient computing device such as a smart phone) may obtain the set of available insurance plans and corresponding coverage related information from the PMDP 130 (e.g., via an API) using published information.

In step 1025, for one or more available insurance plans, corresponding plan-specific cost information for the patient may be determined based on: (a) One or more sets of second treatments, and (b) corresponding coverage related information. In some embodiments, the corresponding plan-specific cost information for the patient may reflect each second set of applicable payment assistance. For example, for available plans, plan-specific cost information may be determined for the patient 170 based on the recurring treatments in each second group. In some implementations, the cost information may be ordered (e.g., from highest planning cost to lowest planning cost). In some embodiments, step 1015 may be skipped and in block 1025, plan-specific cost information may be determined for the patient based on the first set of first treatments, thereby providing a plan-specific cost estimate for the existing treatments used by the patient. In some embodiments, an application (e.g., on a smartphone or other mobile computing device associated with patient 170) may determine plan-specific cost information and provide patient 170 with a list of plan options, which may be ordered by cost or other patient criteria 297. In some embodiments, plan-specific cost information for the patient may be received by the application from the PMDP 130 (e.g., via a secure API).

In some embodiments, optionally in step 1030, the plan-specific cost information may optionally be transmitted (e.g., by the PMDP 130 in a DIR sub-block including information in DIR sub-blocks 380 and 390 and/or other information in DIR record 300) to a second entity (e.g., to HCP 120 authorized by patient 170) when determined by the PMDP 130. In some embodiments, the plan-specific cost information (e.g., in the DIR sub-block) may also be provided to the application (e.g., on a smartphone or other mobile computing device associated with the patient 170) via a secure API.

For example, the cost information may include an aggregate cost index 395-p (e.g., aggregate plan-specific cost information associated with the corresponding treatments 302-pr in the second group). For example, as shown in Table 1, DIR sub-blocks (e.g., 380 and/or 390) may include information about plan h, the selected treatment group, cost C_hs, and the provider of each selected treatment 302-rs in the corresponding second group. In some embodiments, the cost C_hs may further include a cost specification (common payment, common insurance, etc.) for each selected treatment 302-rs in the treatment group. In some embodiments, an application (e.g., on a smartphone or other mobile computing device associated with patient 170) may determine plan-specific cost information and provide patient 170 with a list of plan options, which may be ordered by cost or other patient criteria 297.

Referring to fig. 10B, at step 1035, at least one available insurance plan may be obtained from the set of available insurance plans based on plan-specific cost information for the patient. For example, the patient may select at least one available insurance plan from the set of available insurance plans. As another example, the PMDP 130 may receive at least one selected available insurance plan from an application (e.g., on a smartphone or other mobile computing device associated with the patient 170) via the security API.

In optional step 1040, the PMDP 130 may further receive a second encrypted Health Transaction Record (HTR) sub-block that is decryptable by the PMDP 130, wherein the HTR sub-block includes a selected insurance plan selected from the set of available insurance plans.

In optional step 1045 (which may be performed when PMDP 130 receives HTR sub-blocks in step 1040 and/or is considered a party to the transaction), PMDP 130 may then augment the multidimensional block chain with multidimensional blocks formed by concatenating: an HTR block including information associated with the second HTR sub-block, and a DIR block including second therapy information, a plan-specific cost indicator for the selected insurance plan, and a transaction block. In some implementations, the multidimensional block chain can be augmented in response to received transaction blocks (e.g., from the HEX 180 and/or the payer 140 and/or the PBM 150), wherein the transaction confirmation includes an insurance plan selection.

In block 1050, the application (e.g., on a smartphone or other mobile computing device associated with the patient 170) may receive confirmation to participate in the at least one selected plan (e.g., via a secure message from the HEX 180 and/or payer 140 and/or PBM 150, and/or from the PMDP 130 via a secure API).

Fig. 11 illustrates a schematic diagram of an exemplary computer 1100 or computing device capable of facilitating security and improving interoperability of a healthcare system. In some embodiments, computer 1100 can host and/or interact with a license private block chain platform. The computer 110 may be a computing device associated with an entity (e.g., HCP 120, PMDP 130, payer 140, PBM 150, pharmacy 160, and/or HEX 180) and/or patient 170, and/or may be used to implement a licensed block chain platform. Computer 130 is only an example and several computers may be used in a networked and/or distributed fashion to implement the methods and process flows disclosed herein.

In some embodiments, the exemplary computer 1100 may include a (physical) server, or a server (e.g., an application server) running for one or more entities, such as the HCP 120, the PMDP 130, the payer 140, the PBM 150, the pharmacy 160, and/or the HEX 180. In some embodiments, one computer 1100 may implement some or all of the process flows and/or methods and/or other techniques disclosed herein, including those of fig. 7-10. In some implementations, the computer 1100 can form part of a distributed computing system that can implement a license private block chain 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 smart phone, tablet computer, handheld computer, notebook computer, and/or laptop computer that may run applications to interact with other computers 1100 and/or other applications to implement the techniques disclosed herein.

In some implementations, the computer 1100/processor 1150 may be capable of processing transaction requests, including requests related to adding blocks to a chain of blocks (including a multidimensional chain of blocks). In addition, computer 1100/processor 1150 may be capable of running encryption and/or decryption algorithms, obtaining hashes of information blocks, verifying hashes, performing digital signatures, and may be capable of performing and/or supporting various methods for improving security and facilitating authentication. Authentication may refer to both: verifying the integrity of the stored information (e.g., in blocks in a chain of blocks to determine any unauthorized changes), and ensuring that the entity accessing the licensed private block chain platform is trusted and has permission to perform any requested transaction. In some implementations, the computer 1100/processor 1150 can also amplify (create or add to) a block chain with new blocks (including amplifying a multidimensional block chain with multidimensional blocks).

In some implementations, the computer 1100/processor 1150 may also store and execute smart contracts associated with the block chain to implement agreements between entities (e.g., HCP 120, PMDP 130, payer 140, and/or patient) related to privacy, information sharing, contract execution, and the like.

In some embodiments, the computer 1100/processor 1150 may be capable of mathematically analyzing and statistically compiling health related data, including determining treatment categories (e.g., drug categories, device categories, and/or program categories) associated with treatments, determining cost metrics associated individually and aggregate with treatments from treatment categories, and filtering and/or shrinking selections using patient criteria. In some implementations, the computer 1100/processor 1150 may also be capable of initiating display of information on a smart phone (e.g., on the display 1170) (e.g., using a Graphical User Interface (GUI)). The computer 1100/processor 1150 may also be capable of determining relationships between various health parameters using machine learning techniques. For example, the computer 1100/processor 1150 may include one or more neural network processors, and/or distributed processors that can be configured as a neural network and/or that can execute software to model and/or simulate a neural network that can be used to implement machine learning. For example, the PMDP 130 can use machine learning technology based RWE information (e.g., demographics, side effects, drugs used in combination with a specified drug of interest, therapeutic results, etc.) available through multidimensional blocks to customize the use of the drug. For example, machine learning may be used to determine effective dosages, demographic-based target drugs, improve drug interaction information, increase safety, determine relative efficacy of various modes of administration, and the like.

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 is commonly referred to 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 a location determination unit to automatically determine a location (e.g., of a patient), which may be used in conjunction with the techniques disclosed in fig. 7-10.

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), nonvolatile RAM, and the like. The memory 1104 may be implemented within the processor 1150 or external to the processor 1150. As used herein, the term "memory" refers to any type of long term memory, short term memory, volatile memory, nonvolatile memory, or other memory and is not to be limited to any particular type of memory or number of memories, or any type of medium upon which memory is stored.

The memory may include cache memory, main memory, and auxiliary memory. Secondary memory may include computer-readable media 1120. Computer-readable media may include magnetic and/or optical media, which in some cases may be removable media. Removable media may include optical disks such as Compact Disks (CDs), laser disks, digital Video Disks (DVDs), blu-ray disks, and other optical media, and further include USB drives, flash drives, solid state drives, memory cards, etc. The computer 1100 may further include a storage device 1160, which may include a hard disk drive, a Solid State Drive (SSD), flash memory, other non-volatile storage, and cloud-based storage.

The communication/network interface 1102, storage 1160, memory 1104, and computer readable medium 1120 may be coupled to the processor 1150 using a connection memory device 1106, which may take the form of a bus, wire, fiber optic, link, or the like.

The methods described herein may be implemented in a variety of ways depending on the application. For example, the methods may be implemented in hardware, firmware, software, or any combination thereof. For a hardware implementation, the processor 1150 may be implemented within 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, micro-controllers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, or a combination thereof.

For a particular implementation of firmware and/or software, the methods may be implemented with microcode, programs, functions, firmware and/or software to perform the functions recited herein, or the like. Any machine-readable medium tangibly embodying instructions may be used in implementing the methods described herein. For example, the software may be stored in the storage device 1160 and/or on a removable computer readable medium. Program code may reside on the computer readable medium 1120, storage 1160 and/or memory 1104 and be read and executed by the processor 1150.

If implemented in firmware and/or software, these functions may also be stored as one or more instructions or code on computer-readable medium 1120, storage 1160 and/or memory 1104. Examples include computer readable media encoded with data structures and computer programs. For example, computer readable medium 1120 may include program code stored thereon, which may include program code to support methods for facilitating the security of healthcare systems and improving system interoperability, the manner of support including: support multidimensional block chains, smart contracts, consensus determination, and perform other functions associated with a licensed private block chain platform as described herein.

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

Although the present disclosure has been described in connection with the specific embodiments for purposes of illustration, the present disclosure is not limited thereto. Various adaptations and modifications of the present disclosure can be made without departing from the scope of the disclosure. Accordingly, the spirit and scope of the appended claims should not be limited to the foregoing description.

Claims

1. A processor-implemented method at a first entity, comprising:

receiving at least one encrypted first Electronic Health Record (EHR) sub-block decryptable by the first entity, wherein the at least one EHR sub-block includes patient medical coverage information for a patient and one or more first therapies;

transmitting, in response to the first EHR sub-block, at least one encrypted first device medication information (DIR) sub-block decryptable by at least one corresponding second entity, wherein the at least one first DIR sub-block includes, for each of the one or more first treatments, a corresponding first treatment category, one or more corresponding first treatment category members associated with each corresponding first treatment category, and includes, for each first treatment category member, corresponding first treatment category member cost information;

Receiving, in response to the first DIR sub-block, an encrypted second EHR sub-block decryptable by the first entity, wherein the second EHR sub-block includes one or more second therapies, wherein each of the one or more second therapies is associated with a corresponding first therapy, and each second therapy is selected from the corresponding first therapy class members associated with the corresponding first therapy; and

in response to transaction confirmation, augmenting a multidimensional block chain, wherein the multidimensional block chain is augmented with a multidimensional block formed by linking: a DIR block including information associated with the one or more second therapies, an EHR block including information associated with the second EHR sub-block, and a transaction block.

2. The processor-implemented method of claim 1, wherein upon receiving the first EHR sub-block, the method further comprises:

determining, for each of the one or more first treatments, the corresponding first treatment category, wherein each corresponding first treatment category includes the one or more corresponding first treatment category members; and

for each corresponding first treatment category, the one or more corresponding first treatment category member cost information is determined.

3. The processor-implemented method of claim 2, further comprising:

based on the corresponding first treatment category member cost information for each first treatment category, an aggregate cost indicator is determined based on at least one of: the one or more first treatments, or the one or more second treatments, or a combination thereof.

4. The processor-implemented method of claim 1, wherein the first EHR sub-block includes a patient-specific parameter and the at least one treatment category is determined based on the patient-specific parameter.

5. The processor-implemented method of claim 4, wherein the patient-specific parameter comprises patient co-morbid information.

6. The processor-implemented method of claim 4, wherein the patient-specific parameter comprises route of administration information.

7. The processor-implemented method of claim 4, wherein the patient-specific parameters include safety and efficacy information.

8. The processor-implemented method of claim 4, wherein the patient-specific parameter comprises patient location information.

9. The processor-implemented method of claim 1, wherein, for each first treatment, the corresponding first treatment category and the one or more corresponding first treatment category member cost information for each treatment category member are determined based on the patient medical coverage information.

10. The processor-implemented method of claim 9, wherein the one or more corresponding first treatment category member cost information is determined further based on providers located within a specified distance of a patient location, wherein the patient's location information is included in the first EHR sub-block.

11. The processor-implemented method of claim 1, wherein the one or more corresponding first treatment category member cost information includes one or more of:

a patient-specific pay-as-you-go cost for each corresponding first treatment category member for the corresponding treatment unit; or alternatively

A patient-specific estimated total pay-as-you-go cost for a typical treatment duration corresponding to each corresponding first treatment category member; or alternatively

A patient-specific estimated total pay-as-you-go cost for the remaining duration of the medical coverage plan associated with the patient corresponding to each corresponding first treatment class member.

12. The processor-implemented method of claim 1, wherein upon receiving the second EHR sub-block, the method further comprises:

determining payment assistance information for at least one of the one or more second treatments; and

The payment assistance information is transmitted to the patient with a transaction confirmation.

13. The processor-implemented method of claim 1, further comprising:

a transaction confirmation including at least one prescription for the one or more second treatments is transmitted to the patient along with payment assistance information.

14. A computing device for a first entity, comprising:

the memory device is used for storing the data,

communication interface, and

a processor coupled to the memory and the communication interface, wherein the processor is configured to:

15. The computing device of claim 14, wherein upon receiving the first EHR sub-block, the method further comprises:

16. The computing device of claim 15, further comprising:

17. The computing device of claim 1, wherein the first EHR sub-block includes a patient-specific parameter, and the at least one treatment category is determined based on the patient-specific parameter.

18. The computing device of claim 14, wherein the one or more corresponding first treatment category member cost information includes one or more of:

19. The computing device of claim 14, wherein upon receiving the second EHR sub-block, the method further comprises:

20. A non-transitory computer readable medium comprising executable instructions to configure a processor to: