JP2024503065A - Systems and methods for healthcare interoperability - Google Patents

Abstract

Embodiments facilitate interoperability and secure determination of healthcare costs. The entity may receive a first electronic health record (EHR) sub-block having patient health insurance coverage information and first treatments, a first treatment class corresponding to each first treatment, and a first treatment class corresponding to each first treatment; A first device drug information (DIR) subblock may be transmitted that includes a first therapeutic class member corresponding to a therapeutic class of the first therapeutic class member and corresponding first therapeutic class member cost information. In response, the entity may receive a second EHR sub-block including second treatments, each second treatment associated with a corresponding first treatment and a corresponding first treatment class member. selected from. Upon receiving the transaction confirmation, the entity may link the multidimensional blockchain with the DIR block containing the second treatment information, the EHR block containing information based on the second EHR sub-block, and the transaction block. Can be extended with multidimensional blocks formed. Payment assistance information determined from the second EHR block may be sent to the patient.

Description

(Cross reference to related applications)
This application is based on U.S. patent application Ser. ), U.S. patent application Ser. No. 17/149,703, filed on January 14, 2021, entitled "SYSTEM AND METHOD FOR HEALTHCARE SECURITY AND INTEROPERABILITY," a continuation-in-part of US Pat. claim rights. The applications identified above are incorporated herein by reference in their entirety.

(Field of invention)
The subject matter disclosed herein relates to security and interoperability of health care systems, while promoting treatment selection and transparency in cost determination.

Healthcare information systems face compliance issues that limit interoperability. For example, stored information may be subject to various privacy regulations, such as the Health Insurance Portability and Accountability Act (HIPAA). The Privacy Rule under HIPAA establishes national standards for protecting an individual's medical records and other personal health information when health care transactions are conducted electronically. These regulations cover privacy (e.g., which entities have access to the information), content (what information may be accessed by authorized entities), security (when the information is stored, and how they are protected from unauthorized access during electronic communications), as well as integrity (accuracy and reliability of information). Additionally, commercially valuable information may be subject to organizational policies that may restrict sharing of that information with third parties (e.g., as a trade secret and/or for business or commercial reasons). can be protected by Regulations such as the European Union (EU) General Data Protection Regulation (GDPR) and national regulations can also have a significant impact on information collection, storage, sharing, and communication. These regulations affect the information available to health care market participants, and the information available to an entity may be useful in the aggregate (e.g., to another non-competitive entity). This leads to the creation of organizational “data repositories” that are disconnected from each other. Such compartmentalization of information may increase system costs (e.g., by the patient or provider considering the cost of alternative treatment options, treatment location, etc.), increase patient risk (e.g., drug interactions, (e.g., from prescription drug abuse) and limit the effectiveness of outcome-based approaches to medical treatment or remediation (e.g., determining when a desired outcome has been achieved; or making it more difficult and expensive to compare metrics for approaches that achieve similar outcomes).

Therefore, systems and techniques that address one or more of the above issues are desired, which can help facilitate healthcare information security while promoting interoperability between market participants. There is.

In some embodiments, a method performed by a processor includes 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 and is responsive to the first EHR sub-block including patient health insurance coverage information regarding the patient and the one or more first treatments; transmitting at least one encrypted first Drug/Device Information (DIR) sub-block decryptable by the at least one corresponding second entity; one or more first DIR subblocks for each of the one or more first treatments, a corresponding first treatment class and one or two first DIR subblocks associated with each corresponding first treatment class. and transmitting, in response to the first DIR sub-block, the corresponding first treatment class member and, for each first treatment class member, corresponding first treatment class member cost information. receiving an encrypted second EHR sub-block decryptable by the first entity, the second EHR sub-block including one or more second treatments; Each of the one or more second treatments is associated with a corresponding first treatment, and each second treatment is associated with a corresponding first treatment class member of the corresponding first treatment. and, in response to the transaction confirmation, extending the multidimensional blockchain, the multidimensional blockchain being associated with the one or more second treatments. extending with a multidimensional block formed by linking a DIR block containing information, an EHR block containing information associated with a second EHR sub-block, and a transaction block; may be included.

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 receives at least one encrypted first electronic health record (EHR) sub-block decryptable by the first entity, the at least one EHR sub-block being decryptable by the first entity. receiving, the block including patient health insurance coverage information regarding the patient and the one or more first treatments; and in response to the first EHR sub-block, at least one corresponding second EHR sub-block; transmitting at least one encrypted first drug/device information (DIR) sub-block decryptable by an entity of the at least one first DIR sub-block; For each of the above first treatments, a corresponding first treatment class, one or more corresponding first treatment class members associated with each corresponding first treatment class, and each and, in response to the first DIR sub-block, transmitting, for the first treatment class member, a corresponding first treatment class member cost information; receiving a second EHR sub-block, the second EHR sub-block including one or more second treatments, each of the one or more second treatments; , associated with the corresponding first treatment, each second treatment being selected from the corresponding first treatment class member associated with the corresponding first treatment; and responsive to a transaction confirmation. extending a multidimensional blockchain into a DIR block containing information associated with one or more second treatments and a second EHR subblock; The transaction block may be extended with a multidimensional block formed by linking an EHR block containing associated information and a transaction block.

In a further aspect, the apparatus includes means for receiving at least one encrypted first electronic health record (EHR) sub-block decryptable by a first entity, the apparatus comprising: means, the block comprising patient health insurance coverage information regarding the patient and the one or more first treatments; and in response to the first EHR sub-block, at least one corresponding second entity; means for transmitting at least one encrypted first drug/device information (DIR) sub-block decryptable by one or two For each of the above first treatments, a corresponding first treatment class, one or more corresponding first treatment class members associated with each corresponding first treatment class, and each corresponding first treatment class member cost information for one treatment class member; means for receiving an EHR sub-block of the invention, wherein the second EHR sub-block includes one or more second treatments, each of the one or more second treatments comprising: , wherein each second treatment is selected from the corresponding first treatment class members associated with the corresponding first treatment; and in response to the transaction confirmation. , a means for extending a multidimensional blockchain into a DIR block containing information associated with one or more second treatments and a second EHR subblock; and means extended with multidimensional blocks formed by linking EHR blocks containing associated information and transaction blocks.

In some embodiments, the non-transitory computer-readable medium may include executable instructions, the executable instructions directing the processor to at least one encrypted first entity that is decryptable by the first entity. receiving an electronic health record (EHR) sub-block of the patient, wherein at least one EHR sub-block includes patient health insurance coverage information regarding the patient and the one or more first treatments; and transmitting, in response to the first EHR sub-block, at least one encrypted first drug/device information (DIR) sub-block that is decryptable by the at least one corresponding second entity. the at least one first DIR sub-block, for each of the one or more first treatments, a corresponding first treatment class and each corresponding first treatment class; the associated one or more corresponding first treatment class members and, for each first treatment class member, corresponding first treatment class member cost information; receiving an encrypted second EHR sub-block decryptable by the first entity in response to the first DIR sub-block, the second EHR sub-block comprising one or more of the second EHR sub-blocks; each of the one or more second treatments is associated with a corresponding first treatment, and each second treatment is associated with a corresponding first treatment. selected from a corresponding first treatment class member, and in response to the transaction confirmation, extending the multidimensional blockchain, wherein the multidimensional blockchain has one or more Extended with a multidimensional block formed by linking a DIR block containing information associated with a second treatment, an EHR block containing information associated with a second EHR sub-block, and a transaction block. may be configured to perform the following steps:

Additionally, in another aspect, a method performed by a processor includes decoding data from at least one encrypted first Health Transaction Record (HTR) subblock decryptable by a first entity over a period of time. obtaining a first set of first treatments for the patient over a period of time, each first treatment including a first diagnosis code and a first treatment code; (a) a second set of one or more second treatments, each corresponding second treatment being associated with a different first treatment within the first set; (b) a corresponding number of recurrences for each second treatment; and (b) a corresponding number of recurrences for each second treatment; a set of insurance plans and corresponding insurance coverage-related information for each available insurance plan; and a second set of treatments and corresponding insurance coverage-related information for each available insurance plan. and transmitting a first encrypted drug/device information record (DIR) sub-block decryptable by the at least one second entity. and transmitting a DIR subblock that includes a patient's plan-specific cost metric.

In some embodiments, a computing device for the first entity may include memory, a communication interface, and a processor coupled to the memory and communication interface. In some embodiments, the processor determines the first treatment 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. obtaining a first set of , each first treatment including a first diagnosis code and a first treatment code; and based on the first set: (a) a second set of one or more second treatments, each corresponding second treatment being associated with a different first treatment within the first set; (b) a corresponding recurrence number for each second treatment; and (b) a set of available insurance plans available to the patient; corresponding insurance coverage-related information about the available insurance plans; and obtaining the patient's plan-specific obtaining a corresponding estimated cost metric; and transmitting a first encrypted drug/device information record (DIR) sub-block decryptable by at least one second entity, the DIR sub-block may be configured to transmit, including cost metrics specific to the patient's plan.

In a further aspect, the apparatus detects a first health transaction record (HTR) of a first treatment for a patient over a period of time from at least one encrypted first health transaction record (HTR) sub-block decryptable by the first entity. means for obtaining a set, wherein each first treatment includes a first diagnosis code and a first treatment code; and, based on the first set, (a) a second treatment code; one or more second sets of one or more second treatments, each corresponding second treatment being associated with a different first treatment within the first set; (b) a corresponding number of recurrences for each second treatment; and a set of available insurance plans available to the patient; corresponding insurance coverage-related information for the insurance plan; means for obtaining an estimated cost metric; and means for transmitting a first encrypted drug/device information record (DIR) sub-block decryptable by at least one second entity, the DIR The sub-block may include a means for including a patient's plan-specific cost metric.

In some embodiments, the non-transitory computer-readable medium may include executable instructions, the executable instructions directing the processor to at least one encrypted first entity that is decryptable by the first entity. retrieving a first set of first treatments for a patient over a period of time from a health transaction record (HTR) sub-block of the patient, each first treatment having a first diagnosis code and a first diagnosis code; and, based on the first set, (a) a second set of one or more second treatments, each corresponding second treatment having: a second set of one or more second treatments; , a second set of one or more second treatments associated with different first treatments within the first set; and (b) a corresponding number of recurrences for each second treatment. a set of available insurance plans available to the patient and corresponding insurance coverage related information for each available insurance plan; and a second set of treatments. and corresponding insurance coverage-related information for each insurance plan, obtaining a first encrypted cost metric that is decryptable by the at least one second entity. and transmitting a drug/device information record (DIR) sub-block containing a patient's plan-specific cost metric.

The disclosed methods may be implemented by one or more of mobile computing devices, computers, including servers, cloud-based systems, etc., using computer-readable media or computer-readable memory.

Embodiments of the invention will be described by way of example only with reference to the drawings.
1 depicts a schematic block diagram illustrating interactions between several entities associated with a conventional healthcare information system; FIG. 3 depicts an example electronic health record showing some example data fields within the record. 2 illustrates a portion of an exemplary drug/device information record (DIR) for a drug. 2 illustrates a portion of an exemplary drug/device information record (DIR) for a drug. FIG. 12 shows an example data flow from an initial proposed prescription to options that may be presented to the patient and/or HCP along with cost information. 1 illustrates a portion of an exemplary Pharmacy Benefits Record (PBR) that may be maintained by a pharmacy benefits manager. 2 illustrates an example pharmacy prescription record that may be maintained by an entity such as a p-pharmacy. Illustrating an exemplary health transaction record FIG. 4 depicts a flow diagram illustrating an example process flow for facilitating healthcare cost determination, healthcare information security, and interoperability between multiple entities. 1 illustrates entities and layers associated with an example platform for facilitating security and interoperability of a healthcare system. 1 illustrates a flowchart of an example method for promoting healthcare information security and interoperability while promoting patient treatment selection and treatment cost transparency. FIG. 3 depicts a flow diagram illustrating an example process flow for facilitating healthcare insurance selection and cost determination while maintaining healthcare information security and facilitating interoperability between multiple entities. 1 illustrates a flowchart of an example method for facilitating healthcare insurance selection and cost determination and interoperability between multiple entities while maintaining healthcare information security. 1 illustrates a flowchart of an example method for facilitating healthcare insurance selection and cost determination and interoperability between multiple entities while maintaining healthcare information security. 1 depicts a schematic diagram of an example computer or computing device that can facilitate security and promote interoperability in a healthcare system.

In the figures, like reference numbers and symbols in the various figures depicting particular exemplary embodiments indicate like elements. For example, subblocks with similar information are referred to using the same reference number. Additionally, multiple instances of an element may be indicated by the first number for that element followed by a letter or hyphen and a second number. For example, multiple instances of element 280 may be shown as 280-1, 280-2, etc. When referring to such an element using only the first digit, any instance of that element is to be understood (e.g., element 280 in the previous example refers to elements 280-1, 280-2, etc.). ...and/or 280-N). Additionally, in the figures below, an asterisk symbol ("*") associated with a reference number indicates that the element (or a portion thereof) may be repeated (eg, for each instance of the element). For example, a prescription may include several drug instances, and the dosage field may be repeated for each drug instance.

The diagram below also shows a hierarchy of records that may include fields and subfields. A record includes any fields (and some or all subblocks) that are part of the record. Similarly, a field includes any subfields. A subfield may include additional subfields.

The disclosed embodiments facilitate health care system security while promoting health care system integrity, interoperability, treatment selection, and cost transparency.

FIG. 1 depicts a schematic block diagram illustrating interactions between several entities associated with a conventional healthcare information system 100. A healthcare transaction may involve several entities, where each entity may have some information related to the transaction that may be used to complete the transaction. Therefore, in traditional systems, in order to complete a transaction, some limited information (e.g., limited by regulations, contracts, privacy considerations, confidentiality, and/or for competitive reasons) is required to complete the transaction. Can be exchanged between entities. As used herein, the term "entity" refers to an individual (such as a patient or group of patients) or organization or entity that participates in a healthcare market and/or acts on behalf of an individual/group/organization in a healthcare market. May refer to computing and information systems (eg, hardware and/or software) associated with individuals/groups/organizations that may participate. For example, a computing system associated with one entity may process and/or exchange information with a computing system associated with another entity. Exchange of information between entities may occur via secure communication networks and/or via the Internet and/or on electronic platforms (e.g., information exchange and/or transaction exchange). (e.g., using encryption).

An entity (not shown in FIG. 1), such as a patient, may seek treatment from another entity, such as a Healthcare Provider (HCP) 120, for a medical condition afflicting the patient. HCP 120 may determine patient treatment information and patient insurance using a health information (HI) database 125 maintained by HCP 120 that includes patient insurance coverage related information 124. may be included. Additionally, the HCP 120 may be offered treatment for the patient's medical condition. When suggesting a treatment to prescribe, HCP 120 may send treatment information 123 to a Pharmaceutical Provider and/or Medical Device Provider (PMDP) 130. Treatment information 123 sent to PMDP 130 may not include any patient personally identifiable information (PII).

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

In response, PMDP 130 may send drug/device profiles and safety information 133 to HCP 120 based on information in drug/device information record (DIR) database 135. DIR database 135 may include drug/device profiles and safety information 133. Drug/device profile and safety information 133 may include information about drug properties such as dosage, mode of administration, absorption, metabolism, duration of action, toxicity, and interactions with food or other drugs. Upon receiving the drug/device profile and safety information 133, the HCP may prescribe one or more drugs and/or medical devices and/or treatments or Therefore, the prescription may be modified.

As shown in FIG. 1, HCP 120 also transmits stored patient insurance and treatment (e.g., medical procedure related) information 124 to payor/insurer (hereinafter "payer") 140 and prescription information 127. It may be securely transmitted to pharmacy 160. Prescription information 132 may include patient ID and treatment (eg, drug and/or device) information. Insurance-related and treatment information 124 includes patient identification (ID) information, insurance plan information, group ID information, proposed treatment information (e.g., medical procedure-related information, drug-related information, medical device-related information, etc.). one or more). Insurance-related and treatment information 124 may include some personally identifiable information (PII), but the PII information shared may be limited. For example, patient insurance and treatment information 124 may not include the patient's family history and/or other patient information (which may be part of HI database 125), but may include insurance coverage determination and/or cost determination. and/or may be prevented from being shared with payer 140 (eg, by law/regulation).

Pharmacy 160 may use the received patient-prescription information 127 to enter and/or update Patient-Prescription information (PPI) database 155 and provide patient insurance coverage and treatment-related information 163 to pharmacy. The information may be sent to a Pharmacy Benefit Manager (PBM) 150.

PBM 150 is an entity that plays a role in patient access to pharmaceutical products (drugs and/or devices). The PBM 150 determines drug prices based on the PBM 150, sets or determines retail prices for pharmaceutical products, obtains payments or rebates from manufacturers based on the sales volume of a particular product or basket of products, and, in some cases, , after-sales price transfers and payments can also be obtained from pharmacies on the "prescription book" for payer 140. The formulary identifies the drugs available to the patient, the drug's insurance coverage, and the distribution of drug costs (e.g., the percentage of payments made by the patient and the percentage paid by payer 140 for each covered drug). It can be determined based on. Additionally, formularies typically assign drugs to one of multiple cost-sharing categories. The prescribed drug and the drug's cost-sharing category (both of which may depend on the patient's health or prescription insurance coverage) may determine the patient's out-of-pocket costs at the pharmacy. For example, drugs in preferred categories may have lower cost-sharing requirements (eg, lower coinsurance amounts).

Therefore, the ultimate burden of a patient's drug costs at the pharmacy is determined by (a) the plan's deductible (the specific amount paid by the patient each plan period before payer costs are incurred), (b) (c) copayments (fixed out-of-pocket payments for each transaction specified by the patient's health plan), and (c) coinsurance (the percentage of drug costs that the patient pays after deductible and copayment requirements are met). ). In some cases, based on patient eligibility information, the Pharmaceutical/Medical Device Provision (PMDP) 130 may be provided with upfront payment assistance to the patient. Patient eligibility information includes health insurance coverage information, patient out-of-pocket costs (which may include one or more of co-pays, co-pays, and deductibles for individual prescriptions or over a period of time); It may include one or more of demographic information associated with the patient (eg, one or more of the patient's location, age, disability information, income, prescription costs, etc.). Traditionally, patient payment assistance may be provided as a physical, patient-specific discount card that is applied to a patient's out-of-pocket costs. Patient payment assistance may be provided by PMDP 130 through a patient access program, which in some cases may be separately managed in accordance with applicable laws and regulations. Due in part to the complexity of cost determination due to the number of entities involved and data partitioning by entities, patient cost information is typically not available to the HCP 120 and/or the patient at the time of prescription by the HCP. No (may be available only after pharmacy 160 and/or PBM 150 determines patient cost sharing).

In the case of a medical procedure, the payer 140 may compare the received patient insurance coverage related information 124 to information in the plan/insurance coverage database 145 to determine the patient's insurance coverage. Based on the insurance coverage information, the payer 140 may update the transaction information database 147 and send confirmed and/or added/updated patient insurance coverage related information 124 back to the HCP 120. Patient insurance coverage related information 124 may include approval/denial information, insurance coverage information related to the proposed treatment, and cost and payment related information such as patient co-pays and billing codes. If the payer withholds approval or the proposed treatment has inadequate insurance coverage and/or does not meet the patient's cost criteria, the HCP 120 may suggest modifications, which the HCP 120 and Further exchange of information with payer 140 may result. The interaction between HCP 120, payer 140, and PMDP 130 determines whether HCP 120 is (a) acceptable to the patient, (b) meets safety and effectiveness considerations, and (c) is borne by payer 140. may continue until final approval of the treatment plan, which may be performed and/or approved.

With respect to drugs and/or devices, PBM 150 uses insurance coverage-related information received from the patient (or HCP) in conjunction with information in Pharmacy Benefit Information (PBI) database 155 to determine patient insurance coverage, It is possible to determine whether a prescribed drug is covered by insurance, the patient's self-pay drug cost, the insurance burden of the drug cost, etc. When a treatment (eg, drug and/or device) is covered, PBM 150 may send cost information 153 to pharmacy 160. Cost information 153 (which may include one or more of patient out-of-pocket costs, insurance costs, cost breakdowns, and/or other information) may be sent to pharmacy 160, which may receive Cost information 153 may be used to update PPI database 155. If the patient later wishes to change the prescription (e.g., to a different or lower cost drug based on out-of-pocket cost information obtained by the patient from pharmacy 160), the process may need to be repeated; , HCP 120, pharmacy 160, and/or PBM 150. Because cost information is not traditionally available to the HCP 120 and/or the patient at the time of prescription by the HCP, the patient and/or HCP 120 may be required to determine the out-of-pocket costs by the pharmacy 160 (e.g., based on information provided by the PBM 150). The cost-related aspects of a prescription may not be noticed until it is done. Therefore, if the cost is not acceptable to the patient, the prescribed treatment may need to be modified (or may remain unfulfilled), thereby leading to system inefficiency and inadequate resource utilization.

In addition, for example, patient insurance coverage (e.g., whether the patient is currently insured), payment information (e.g., remaining patient deductible, etc.) may be exchanged between payer 140 and PBM 150. There may be other information exchanges for verification. PBM 150 may transmit patient insurance coverage information 142 to payer 150 and receive confirmation of whether insurance coverage is current and deductible-related information, which allows the PBM to cover out-of-pocket patient costs. can be used to determine. Further, PMDP 130 and PBM may exchange sales and rebate related information 132, and PMDP 130 and payer 140 may exchange contract related information and/or drug/device pricing related information 137.

Therefore, traditional healthcare information systems suffer from several drawbacks. Each entity obtains and maintains information that may be relevant to operating its business, but very little of that information may be shared (e.g., due to legal, privacy, and/or business considerations). When information is shared, it may be fragmented, uncontextualized, untimely, and not useful for decision-making/planning purposes. For example, HCP 120 and/or the patient may not have cost information associated with the treatment at the time of prescription. As another example, treatment alternatives and the costs of various treatment alternatives may not be available to the patient or HCP 120 at the time the prescription or treatment plan is being developed.

As another example, HCP 120 may not provide details of adverse drug effects that may be reported to PMDP 130 by a patient (eg, due to privacy concerns). As another example, if adverse drug effect information is provided to PMDP 130 by HCP 120, that information may include non-PII demographic information (e.g., patient age, location, medical condition, etc., again due to privacy concerns). As a result, that information may be of limited value to PMDP 130. Additionally, in some cases, when an adverse drug effect is reported by an entity (e.g., a patient), verification of that adverse drug effect is often performed by another entity to determine whether the adverse event is attributable to a given drug. It can be determined whether or not it will be obtained. Verification may require additional entities, may further delay reporting, and/or may introduce additional complexity that may create additional repositories, thereby further limiting the usefulness of the information (e.g. for PMDP130).

Furthermore, because the exchanged information may be compartmentalized and provided on an ad hoc basis, aggregating the received information with information stored by the receiving entity may be cumbersome. Additionally, each entity may index its information differently, so that a receiving entity (or a sending entity) may not be able to track the information received (sent) by the sending entity (or by the receiving entity). (stored) information records may be difficult or impossible. For example, if HCP 120 provides adverse drug effect information to PMDP 130 at some point, even if that information may be legally shared, HCP 120 and/or PMDP 130 may Obtaining medical condition information can be difficult. For example, compartmentalization of information may prevent or limit access by the PMDP 130 to aggregate demographic information that may be used to coordinate drug utilization. As a further example, it may be difficult for HCP 120 and/or payer 140 to determine prescription drug abuse by a patient.

Many modern machine learning (ML) and other artificial intelligence (AI) systems process large amounts of data to determine risks, identify patterns that can lead to desired outcomes, etc. The patterns may provide increased efficiency, lower costs, and/or better outcomes. Information storage and compartmentalization also limits the applicability of such ML and AI techniques, thereby contributing to further inefficiencies.

Several efforts to introduce efficiency into healthcare delivery have focused on outcome-based approaches. Payer 140 may tie reimbursement to some agreed achievement of outcomes. For example, a performance-based contract may specify that the HCP 120 may be reimbursed at an agreed upon rate based on reducing the patient's blood pressure to some defined range within a certain period of time. Tracking and managing such performance-based contracts requires that several information exchanges occur between the HCP 120 and the payer 140, with each exchange following relevant legal, regulatory, privacy, and business guidelines. can be notoriously difficult in conventional systems.

While the use of blockchain to store health-related information can facilitate ensuring the integrity and authenticity of stored information, traditional techniques have limited data privacy while reducing information compartmentalization. does not address the issues raised by data sharing between entities in an environment of increasing transactional and regulatory complexity. Furthermore, conventional techniques also require the availability of timely information (e.g., to one or more entities in a manner compliant with legal and regulatory obligations) to facilitate final approval of transactions. Does not guarantee possibility. Furthermore, conventional techniques do not guarantee that an entity has a consistent and consistent view of completed transactions. The lack of a consistent and consistent view of completed transactions across entities may constrain the pursuit of improved interoperability, data availability, and operational efficiency. In addition, requests by customers (e.g., patients) for information to support or enhance decision-making (e.g., independently from or in conjunction with the HCP) can be difficult to accommodate. Therefore, constraints on interoperability often limit an organization's ability to maintain a customer-centric focus.

The disclosed embodiments facilitate health care system security and promote health care cost transparency while promoting health care system integrity, interoperability. Some disclosed techniques facilitate the exchange of appropriate data (e.g., compliant with legal, privacy, and business guidelines) to an appropriate entity (e.g., an authorized entity associated with a transaction). (e.g., at the point of transaction) in a timely manner, while simultaneously facilitating a consistent and consistent view of information across healthcare market entities.

Interoperability is partially facilitated. This is because multiple entities associated with a transaction may be able to use criteria-based agreements to link pertinent relevant information shared during a transaction to a completed transaction. Locally recorded data (e.g., locally at an entity) may correspond to reference data (e.g., maintained on a shared platform) and may correspond to reference data that is viewable by each entity (or viewable by the entity). Consistency and integrity are facilitated as the data may be consistent with another authorized entity's view of the data (and/or the other authorized entity's locally recorded data). In some embodiments, the reference data may be based on and/or take the form of a distributed ledger. In some embodiments, the distributed ledger may be accessible to authorized entities, and each entity's viewing of the distributed ledger may comply with legal, privacy, business, and/or contractual obligations. Furthermore, efficiency is promoted. This is because decision-relevant information is made available to entities early in the transaction cycle to facilitate early consideration of alternatives, thereby reducing the likelihood of final transaction approval and the inefficiencies associated with final transaction approval. This is because it reduces the need for reconsideration of intentions.

In some embodiments, the first entity (e.g., PMDP 130) stores at least one encrypted first electronic health record (EHR) (e.g., about the patient) that is decryptable by the first entity. A sub-block may be received. The first EHR subblock includes a patient and one or more first treatments (e.g., patient health insurance coverage for the proposed drug and/or device), represented by F_p, 1≦p≦P. The encrypted first EHR sub-block may be received (e.g., by PMDP 130) with the transaction ID for the current transaction and may, in some cases, not include PII information about the patient. In other cases (e.g., when authorized and/or when PMDP 130 determines or uses a patient's eligibility for a payment assistance program managed by PMDP 130), the encrypted first EHR sub-block may be received (e.g., by PMDP 130) along with the transaction ID for the current transaction and may further include PII information about the patient. In situations where patient PII information is received (e.g., by PMDP 130), PMDP 130 may Access to patient PII information may be administered and funded by program administrators and/or authorized personnel using a locally maintained blockchain consistent with the disclosed embodiments. Patient privacy may be maintained on behalf of the PMDP, as limited. Authorization to provide PII information may be obtained from the patient (e.g., in advance by the HCP 120 or PMDP 130 or another entity). In embodiments, the first EHR sub-block can further indicate that the patient consents to the use of the information in the first EHR sub-block to determine eligibility to participate in the clinical trial.

The first entity (e.g., PMDP 130), in response to the first EHR sub-block, generates at least one encrypted first may transmit a device drug information (DIR) sub-block for each of the one or more first treatments (F_p, 1≦p≦P), where the DIR sub-block identifies the corresponding first treatment class. (eg, K_p, which represents a drug/device in the same class as F_p). Each therapeutic class K_p may include one or more corresponding first therapeutic class members (C_pd, individual drugs/devices expressed as (1≦p≦P, 1≦d≦D_p); Each first treatment class member (C_pd) may be associated with corresponding first treatment class member cost information (M_pd). First treatment class member cost for the corresponding first treatment class member (C_pd) The information (M_pd) may include out-of-pocket costs, total costs over the expected treatment period, treatment, costs over some specified time period, etc.). D_p may represent the number of class members within treatment class K_p.

For example, upon receiving the first EHR sub-block, the first entity (e.g., PMDP 130) determines, for each of the one or more first treatments (F_p), a corresponding first treatment class (K_p). ) can be determined. Further, in some embodiments, the first EHR sub-block may include patient-specific parameters, and the corresponding first treatment class may be determined based on the patient-specific parameters. Patient-specific parameters may include one or more of patient comorbidity information, route of administration information, safety and efficacy information, and/or patient location information. Accordingly, a member C_pd within the corresponding first treatment class (K_p corresponding to treatment F_p) may be determined (eg, by the first entity) based on patient-specific parameters.

Each first therapeutic class (K_p) may include one or more corresponding first therapeutic class members (C_pd). Further, the first entity determines, for each of the one or more first treatment class members (C_pd), one or more corresponding first treatment class member cost information (M_pd). It is possible. The first entity (eg, PMDP 130) may then transmit an encrypted first DIR subblock that is decryptable by at least one corresponding second entity (eg, HCP 120).

The one or more corresponding first treatment class member cost metrics (M_pd) include patient-specific out-of-pocket costs corresponding to each corresponding first treatment class member (C_pd) for the corresponding treatment unit; or the patient-specific estimated total out-of-pocket costs for each corresponding first treatment class member for a typical or prescribed treatment period, or the remainder of the health insurance coverage plan associated with the patient. one or more of the patient-specific estimated total out-of-pocket costs corresponding to each corresponding first treatment class member (C_pd) for the duration, or a combination thereof;

The first entity (e.g., PMDP 130) may receive an encrypted second EHR sub-block decryptable by the first entity in response to the transmitted first DIR sub-block; The EHR sub-block of includes one or more secondary treatments (e.g., one or more selected drugs/devices, S_p, 1≦p≦P), one or more Each of the above second treatments S_p is selected from a corresponding first treatment class member (C_pd) associated with a corresponding first treatment class (K_p). For example, the set of second treatments S includes, for each first treatment class (K_p corresponding to the first treatment F_p), one selected corresponding first treatment class member (C_pd). obtain. For example, the second EHR sub-block may include one or more selected devices/drugs, each selected device/drug S_p being associated with a different corresponding class K_p. As an example, a first EHR sub-block may include a first treatment (F_1, F_2, F_3) and a second EHR block may include a second treatment G_1, F_2, H_4}, where: G_1 and F_1 are both in therapeutic class K_1, F_2 is in therapeutic class K_2, and F_3 and H_4 are in therapeutic class K_3. As outlined above, each therapeutic class may include one or more members. In some embodiments, the selection of one or more second treatments (S_p) may be based on patient-specific cost metrics.

In some embodiments, the first entity (e.g., PMDP 130) may then extend a multidimensional blockchain, where the multidimensional blockchain is associated with one or more second treatments. It is extended with a multidimensional block formed by linking a DD1 block containing information, an EHR block containing information associated with a second EHR sub-block, and a transaction block that may contain a transaction ID.

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

The term subblock refers to a portion of a data record or block. It may be decryptable (if encrypted) by a particular entity or entities (but not by other entities). The information in the sub-blocks decrypted by a particular entity (or entities) will be added to the data record (or blockchain) maintained by that particular entity (or entities) when the transaction is finally approved. data blocks). For example, a transaction with a transaction IDU may include entities A, B, C, and D, which may be owners of data records W, X, Y, and Z, respectively, in a multidimensional blockchain. . In the above example, the data record W (owned by A) associated with transaction U may be encrypted and readable by the owning entity A (but not encrypted and readable by other entities). . However, data record W may include portions of information in other data records (eg, data records X, Y, and/or Z) that may not be readable by entity A (in addition to the transaction IDU). For example, data from one or more other data records (e.g., data records e.g., by entity A). Similarly, other entities B-D may also include transaction-related information that resides in unowned data records (in addition to the transaction IDU). For example, in the case of entity B, the information present in one or more of data records W, Y and/or Z is received in the form of decodable sub-blocks by entity B prior to final approval of the transaction. obtain. Therefore, each entity A, B, C, and D maintains a different independent blockchain, each containing data records W, X, Y, and Z (of transaction U) as blocks in their respective blockchains. It is possible. Data records (or blocks) W, X, Y, and Z associated with transaction U may collectively form a multidimensional block in a multidimensional blockchain. Accordingly, a consistent and consistent view of transactions can be associated with transactions while maintaining compliance with legal, privacy, and/or other regulatory/business considerations, and promoting data integrity. Available to all market entities.

The term "blockchain" as used herein refers to a growable list of records or "information blocks" or "blocks" in which the blocks are linked using cryptographic techniques. Each block includes a cryptographic hash of the previous block, a timestamp, and transaction data. The current block being added to the blockchain is also called the head of the blockchain. A cryptographic hash function maps data of arbitrary size to a fixed-size string of bits, called a hash. A hash function can be deterministic (the same input will produce the same output) and cannot be reversed (i.e., determining the original input data from the hash value). It can be a directional function. Transaction data for a block may be represented as a Merkle tree root hash. The term "Merkle tree" or "hash tree" is used to refer to a tree in which every leaf node is labeled with a hash of the transaction data, and each non-leaf node is associated with its child nodes. Labeled using a cryptographic hash of the label. The block header of a block added to the blockchain may include a hash criterion for the previous block header and a hash criterion for the root of the Merkle tree containing transaction data. Blockchains promote data integrity because changes to data within the blockchain result in a mismatch in one or more of the hash criteria. The term record or data record is also used to indicate non-final data that is to be added to the blockchain. Once a data record is verified and final approved, the data record may be added to the blockchain and form a block within the blockchain.

The term "multidimensional blockchain" is used to refer to a set of multidimensional records (also referred to as a multidimensional block), where each multidimensional record contains two or more data records. . In some cases, each of the data records that may be viewed in forming a dimension of a multidimensional blockchain may also form a block within a different blockchain associated with an entity. Thus, in some embodiments, a multidimensional block may include data records within each dimension, where the data records corresponding to the dimensions are block blocks within different conventional blockchains associated with the corresponding entity. can be formed. For example, a multidimensional block may include EHR data records as one dimension, DIR data records as another dimension, and transaction data records as a third dimension. Additionally, in some cases, EHR data records associated with a multidimensional block (in a multidimensional blockchain) may form blocks separately in a different EHR blockchain (i.e., different from the multidimensional blockchain). . Similarly, in some cases, each of the DIR data records and transaction data records associated with a multidimensional block may be associated with a different DIR blockchain (e.g., associated with PMDP 130) and transaction record blockchain (e.g., payment associated with person 140). Thus, in some cases, data records in the context of a multidimensional blockchain may correspond to blocks in different conventional blockchains. In some cases, each data record (e.g., associated with a dimension) within a multidimensional block corresponds to, forms part of, and/or is connected to a corresponding block in a different conventional blockchain. It can be derived from A multidimensional block may include a previous multidimensional block, a timestamp, and a cryptographic hash of the data. A multidimensional block of data may include a hash of the individual data records that make up the multidimensional block. In some embodiments, a consensus mechanism between entities may be used to confirm the validity of data in a 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., within a healthcare market). . As outlined above, data records within a multidimensional block may form blocks separately in different blockchains, where each of the blockchains may be associated with a different entity. Each encrypted data record may be decrypted by a corresponding associated entity (eg, a data record owner). Furthermore, an encrypted data record may include portions (referred to as "subblocks") that may be decrypted by at least one other specific entity in addition to the encrypted data record owner. . For example, this sub-block may have been decoded by at least one other different entity (in addition to the data record owner) at the time the corresponding multi-dimensional block was formed. In some embodiments, prior to or at the time of multidimensional block formation, the sub-blocks are separately encrypted and made available to another entity, along with information to decrypt the sub-blocks. There may be cases. Therefore, multidimensional blocks provide consistent and consistent visibility of data to authorized market entities, comply with privacy and/or data sharing regulations, business guidelines, and/or contractual obligations, and ensure data integrity. may facilitate the availability of transactional data to multiple entities associated with the healthcare market while promoting An entity may also ensure data correlation (e.g., of records associated with dimensions of a multidimensional block in a multidimensional blockchain) with corresponding blocks in a locally maintained blockchain. In some embodiments, when information is exchanged between two entities using subblocks, the information exchanged via the decodable subblocks is based on an information interface between the two entities. obtain. In some embodiments, when exchanging information (e.g., at the point of multidimensional block formation), each entity generates subblocks that are decodable by other entities while maintaining local Blocks associated with different blockchains can be encrypted. The information interface may be based on smart contracts associated with the blockchain.

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

FIG. 2 shows an EHR 200 illustrating some example data fields within a record. In some embodiments, EHR 200 may contain information about the patient and may be owned and maintained by HCP 120 (eg, within HI database 125). In some embodiments, data fields within EHR 200 may be added and/or maintained by HCP 120 based in part on information received from the patient. EHR 200 may also include data received (eg, as subblocks) from other entities. The fields shown in EHR 200 are merely exemplary; EHR 200 may include various other additional fields based on laws, standards, HCP practices, industry practices, and the like. The EHR may include fields that are different (more or less) than those shown in connection with the example EHR 200.

The EHR 200 is associated with an 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.). obtain. In some embodiments, some or all of the information within HCP profile 295 may be shared with other entities in connection with the transaction. For example, a portion of HCP profile 295 may be sent to one or more entities such as PMDP 120, payer 140, PBM 150, and/or pharmacy 160 (e.g., encrypted data that may be decryptable by a designated receiving entity). (as part of a sub-block).

For example, as shown in FIG. 2, EHR 200 may include basic profile information 230 about a patient, which information may change relatively infrequently. Basic profile information 230 may include patient name, patient ID, family history 205, date of birth (DOB) 220, blood type 225, and the like. Family history 205 may include maternal medical history 210 and paternal medical history 215. Basic profile information 230 may also include medical history 232, which may include information about other previous or current medical conditions associated with the patient.

The EHR 200 includes a diagnosis 235 (e.g., current disease), a diagnosis code 240, which can be a standardized code for the diagnosis (such as an International Classification of Diseases (ICD) code), and a standardized code 240 for describing the treatment. other data fields, such as a treatment code 245, which may be a code (e.g., a Current Procedural Terminology (CPT) code), a prescription code 250 for each prescription, which may serve to uniquely identify each prescription; may further include. Prescription code 250 is also referred to herein as prescription 250.

In some embodiments, the prescription code 250 (for a prescription) includes a prescribed drug field 255-p, 1≦p≦P (e.g., a drug ID and/or a Classification Product Code for a medical device). , CPC)), dosage 260-p (strength and frequency), and duration 265-p (length of time the drug is taken) (e.g., in the prescription). for each drug/device being prescribed). In some cases, EHR 200 may also include other fields and/or subfields, such as an indication of whether the prescription is a new prescription or a refill. EHR 200 may also include Medical Device Report (MDR) adverse event codes or other (eg, ICD-10) codes for documenting adverse drug effects. EHR 200 may also include patient criteria 297, which may specify one or more criteria for drug/device selection and/or cost metric determinations that may be provided by the patient. For example, patient criteria 297 may specify the preferred method of administration (eg, topical, ingestion, inhalation, etc.), preferred pharmacy, area or location where the prescribed drug/device will be obtained, desired type of cost metrics, etc.

In some embodiments, the EHR 200 for a patient may be stored as a blockchain, e.g., by the HCP 120, and each transaction between the HCP 120 and the patient and/or another entity stores the EHR information in the EHR blockchain. May form part of a block. When an EHR block associated with a transaction is stored on a blockchain, the information stored may optionally be associated with a transaction ID 695 that may serve to uniquely identify the transaction. In some embodiments, the transaction ID 695 may be common to entities associated with the transaction (eg, all entities associated with the transaction may use the same transaction ID). In some embodiments, a transaction initiator and/or a component of a permissioned blockchain platform may provide transaction information, such as transaction ID 695, to one or more entities associated with the transaction. Thus, sub-blocks sent or received by an entity can 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 may be provided by the transaction platform. Other transaction information related fields (not shown in Figure 2) indicate the transaction type that may be used by the entity to determine and process the information in the sent and/or received sub-blocks and determine the appropriate response. may be included. For example, transaction type may indicate that sub-block 280 is being provided to obtain cost metrics associated with a prescription.

In the following discussion, if the EHR is maintained as a blockchain (eg, by HCP 120), EHR information record 200 may also be referred to as EHR block 200. Accordingly, EHR block 200 may form a block within the EHR blockchain. If EHR block 200 may be added to the EHR blockchain, some data within EHR block 200 that is added to the EHR blockchain may be dependent on other entities. For example, a treatment (e.g., specified by treatment code 245 for the diagnosis described by diagnosis code 240) may be approved by payer 140 and/or PBM 150 (not shown in FIG. 2) and, upon approval, in the EHR. may be included as part. As another example, before EHR block 200 is added to the EHR blockchain, a drug warning label (not shown in FIG. 2) that may form part of EHR block 200 uses input from PMDP 130 to The information within this warning label may be completed, verified, and/or updated.

In some embodiments, patient criteria 297, diagnosis 235, diagnosis code 240, treatment code 245, and data fields prescribed drug/device 255-p, dosage 260-p, and duration 265 -p, prescription code 250 with 1≦p≦P, may be used to form sub-block 280. In some embodiments, sub-block 280 includes basic profile information 230, patient insurance coverage related information 272, and/or insurance plans enrolled by the patient (e.g., health insurance plan, pharmacy benefit plan, prescription insurance coverage). etc.) may further include one or more of the plan IDs 270 that may serve to identify the plan ID 270 (e.g., plan ID 270). In some embodiments, (depending on the context, applicable law, and/or patient authorization) sub-block 280 also includes some of the information in sub-blocks 282 and/or 284 described herein. or all. Some or all of the information within sub-block 280 may be shared with one or more other entities and may form part of other records/blocks associated with the transaction.

A prescription 250 may include one or more prescribed drugs/devices 255-p, 1≦p≦P, where P represents the number of drugs associated with the prescription 250. Thus, in some embodiments, subblock 280 may comprise a record for each prescribed drug/device 255-p within prescription 250. Sub-block 280 is just an example illustrating some information that may be shared with another specific entity. For example, sub-block 280 may be encrypted and transmitted to PMDP 130 and may be decryptable by PMDP 130 (e.g., to obtain equivalent classes of drugs, devices, and/or treatments and corresponding cost metrics). .

In general, information within any suitable field or combination of fields within a data record or block may be aggregated into subblocks, which may be associated with some other specific entity or multiple entities (e.g., one or two may be encrypted (e.g., by a first entity) such that it is decryptable by one or more second entities). The encrypted sub-blocks may be transmitted (e.g., by the first entity) to another designated entity or multiple entities (e.g., one or more second entities), and may be sent to other designated entities (e.g., one or more second entities) The designated entity or entities (eg, one or more second entities) may decode the received information and act appropriately (eg, based on the transaction type). Information used to form sub-blocks from data records or blocks in a blockchain (e.g. EHR blockchain) that is locally maintained by a first entity and shared with another (second) entity is , regulations (e.g., healthcare and/or privacy), laws governing information sharing (e.g., which may determine what information may or may not be shared between certain entities), business guidelines (e.g., trade secrets or the sharing/protection of confidential information) and/or contractual obligations (e.g. between or relating to entities sharing information) and/or agreements (e.g. as part of a subscription to an electronic transaction platform). ).

As another example, the information in sub-block 282 may include insurance coverage related information 272, plan ID 270, copayment information 275, etc. While some of the information in sub-block 282 may be obtained directly from the patient, other insurance coverage-related information may be obtained in connection with the transaction specified by transaction ID 695 (e.g., determining cost-effective treatment). (e.g., received from an appropriate entity and decoded by HCP 120, may be decrypted (based on one or more encrypted sub-blocks not shown). For example, transaction type may indicate that sub-block 282 is provided for obtaining, confirming, or completing insurance coverage-related information 272.

Additionally, in some situations, portions of EHR information 200, such as basic profile information 230, DOB 220, blood type 225, and certain portions of medical history 232, are encrypted by HCP 120 as sub-blocks 284 and transmitted to PMDP 130. PMDP 130 may then decode sub-block 284 in connection with the transaction specified by transaction ID 695 (eg, to determine the level of payment assistance). As a further example, the portions of basic profile information 230 included in sub-block 284 may be non-PII related to the patient (eg, excluding name, identification number, etc.). Accordingly, medical information may be securely shared with another specific entity (eg, to determine adverse reactions, medical device malfunction, etc.) without compromising patient privacy. In other cases, if disclosure of PII information is authorized and authorized (e.g., by the patient), the sub-block may include PII information for PMDP 130 to determine the patient's eligibility for payment assistance, or may include PII information related to the prescription (for pharmacy 160 to establish patient identity); for example, some or all of the information present in sub-blocks 282 and/or 284 may be sub-block 280) (depending on applicable laws and/or patient approvals).

As a further example, data within sub-block 280 may be shared by an entity such as HCP 120 with another healthcare marketplace entity, such as payer 140, to complete a transaction. However, patient profile information (e.g., family history 205, maternal medical history 210, and/or paternal medical history 215) associated with basic profile information 230 (e.g., patient instructions/privacy, legal, and/or business (based on guidelines), the first entity (eg, HCP 120) may not share family history 205 or may limit the portions of basic profile information 230 that are shared.

Accordingly, in some embodiments, the data used to form a sub-block sent by an entity or received from another entity is transmitted by an entity or received from another entity, and the context in which the data is shared (e.g., transaction (type or nature of the material). In some embodiments, the information interface between any two entities may depend on transaction type and/or context. In some embodiments, one or more protocols (e.g., agreed upon/pre-deployed by the entities and/or configured by the permissioned blockchain platform and/or based on some standard) are: Transaction types and the information present in subblocks sent/received by an entity for each transaction type may be specified. In some embodiments, data fields included in sub-blocks that are shared between entities in relation to a transaction type may be specified as required, conditional, optional, upon request, etc. (e.g., by the protocol and/or (agreed based on standards).

Data in a sub-block (eg, sub-block 280) may be separately encrypted and may only be decryptable by an authorized entity. In some embodiments, encryption of the data forming a sub-block (e.g., sub-block 280) may be based on any suitable cryptographic scheme, including the Advanced Encryption Standard. , AES)-based technology or variations thereof, in which entities such as HCP 120 and payer 140 share a private key. Sub-block 280 may be encrypted (eg, by HCP 120) before being shared with other entities (eg, payer 140). Other entities (eg, payer 140) may be able to decrypt sub-block 280 using, for example, the shared key.

Additionally, the data within EHR 200 may be processed using any secure method to form EHR block 200 before being added to the blockchain (e.g., maintained by HCP 120 and/or maintained by an electronic transaction platform). It may be separately encrypted by HCP 120 using encryption techniques. For example, the data within EHR block 200 may be separately encrypted using a private key (e.g., private to HCP 120) such that the data is decryptable by HCP 120 and available to HCP 120. possible, but not available and/or viewable to any other entity.

3A and 3B illustrate a portion of an example drug/device information record (DIR) 300 for a drug that may be stored in the DIR database 135. In some embodiments, DIR 300 may include information regarding treatments (eg, drugs and/or medical devices), such as drugs, devices, and/or treatments. The fields shown in DIR 300 are merely exemplary; DIR 300 may include various other field bases based on laws, standards, industry practices, and the like. Additionally, a DIR may include fields that are different (more or less) than those shown in connection with example DIR 300.

DIR 300 may be associated with a PMDP profile field 395 that may store information related to PMDP 120 (eg, PMDP identification, contact information, address, etc.). In some embodiments, some or all of the information in PMDP profile 395 may optionally be shared with other entities in connection with the transaction. For example, a portion of PMDP profile 395 may be sent to one or more entities such as payer 140, PBM 150, and/or pharmacy 160 in an encrypted form that may be decryptable by a designated recipient entity (e.g., (as part of a sub-block).

Referring to FIG. 3A, PMDP 130 uses information in prescribed drug/device field 255-p (e.g., received as part of sub-block 280) to For each drug/device 255-p) corresponding drug/device class 337-p may be determined. Drug/device class 337 field may specify one or more drug/device classes associated with drug/device 255. In some embodiments, sub-block 280 may also include some or all of the information in sub-blocks 282 and/or 284.

A drug/device class can be a set of drugs/devices that can be used to treat the same medical condition. Drugs within a drug class have similar chemical structures, and/or similar or related mechanisms of action (e.g., may act or bind to the same target), and/or related modes of action (e.g., may act or bind to the same target), and/or have similar biological or functional and/or may be used to treat the same disease. For example, a drug device class may also include name brand drugs/devices and generic drugs/devices, and/or brand biologics and biosimilars, and/or different dosages of the same therapy, etc. 3A-3C, drugs within an individual drug/device class 337-p are represented by drug/device 302-pd, where 1≦d≦D_p, where D_p is a drug/device class 337-p. is the number of drugs in device class 337-p.

In some embodiments, the drug/device class 337-p field includes the organ or biological system that the drug device treats, and/or repeating instruction subfields 362-pd1, 362-pd2 . ．． ．． treatment area field 360-pd, which may be specified by treatment area field 360-pd, and dose subfields 364-pd1, 364-pd2 ., which are repeated for corresponding instructions. ．． ．． , a mechanism of action and/or mode of action, which may be specified by MOA field 340-pd, and subfields Molecular Formula field 353-pd and chemical structure, which may be specified by chemical data field 350-pd, describing the chemical constituents of the drug. Subfields 355-pd may further include general chemical properties of the drug;

Referring to FIG. 3A, the DIR 300 includes drug name 304-pd for drug/device ID 302-pd, efficacy 327-pd (which may be a measure of therapeutic effect on a medical condition), route of administration 335-pd (e.g., topical , oral, intravenous, etc.), safety 330-pd (e.g., drug interactions, toxicity, contraindications, etc.), which may include side effects subfields 345 (e.g., side effects), and various other data fields. can be provided. Adverse event subfield 333-pd (eg, adverse events reported for a drug). DIR 300 may also include various other fields related to drugs/devices.

In some embodiments, drug/device ID 302-pd, drug/device name 304-pd, safety 330-pd (and subfields), and efficacy 327-pd, drug/device class 337-p, therapeutic area. 360-p, instructions 362-pdh (e.g., instructions 362-pd1, instructions 362-pd2, etc.), and corresponding doses 364-pdh (e.g., doses 364-pd1, doses 364-pd2, etc.) May form part of 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 the platform (e.g., due to legal, regulatory, licensing, and / or based on contractual obligations). Accordingly, the information within sub-block 380 (and any other sub-blocks) may be more or less than that shown for the example sub-block (e.g., example sub-block 380), and the information within sub-block 380 (and any other sub-blocks) may be It may depend on the type, transaction context, and interacting entities. Sub-block 380 may optionally further include route of administration 335-pd, MOA 340-pd, chemistry data 350-pd, and other related fields/subfields. In FIG. 3A, fields associated with example sub-block 380 are shown enclosed within a dashed perimeter.

DIR subblock 380 may be provided by PMDP 130 to another entity (eg, HCP 120) in connection with a transaction (eg, identified by transaction ID 695). In some embodiments, DIR subblocks 380 form part of drug/device class 337-p or share one or more properties (e.g., treat the same medical condition, and and/or have a similar mechanism or mode of action and/or have a similar chemical structure). In some embodiments, the information in sub-block 380 may be associated with a transaction (e.g., identified by transaction ID 695 and transaction type) and may be encrypted during the transaction and/or prior to final approval of the transaction. , may be sent by PMDP 120 to another entity (eg, HCP 120).

In some embodiments, a DIR record 300 may be associated with a transaction (e.g., specified by transaction ID 695) and, upon final approval of the transaction, stored as a DIR block on the DIR blockchain by an entity such as PMDP 130. can be done. In the following description, if the DIR record 300 forms part of a blockchain, the DIR information record 300 may also be referred to as a DIR block 300. Thus, DIR block 300 may form a block within the DIR blockchain.

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) is maintained by another entity. (or possessed) information (e.g., related to drugs/devices). For example, HCP 120 may request information from PMDP 130. Prior to transaction confirmation, some of the data (e.g., maintained by PMDP 120 in DIR information block 300) that is integrated into records maintained by other entities (i.e., other than PMDP 130) is input from PMDP 130. , verification by, and/or confirmation by. Conversely, PMDP 130 may receive input from another entity (eg, HCP 120 and/or payer 140 and/or PBM 150) in the form of subblocks. Some or all of the received information may be incorporated into DIR record 300 and/or used to determine information within DIR record 300.

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

Accordingly, when information regarding a transaction (e.g., related to a drug/device) is requested, the owner (e.g., PMDP 130) provides the information (e.g., in sub-block 380) to the requesting entity (e.g., HCP 120). You may respond by sending: The information (e.g., in sub-block 380) may be encrypted (e.g., by PMDP 130) before transmission, such that the information in sub-block 380 is transferred between the requesting entity (HCP 120) and the sending entity (PMDP 130). may be decryptable by the requesting entity (eg, HCP 120) such that it is private. In addition, the information in the sub-blocks exchanged between entities may be subject to compliance with existing regulations, privacy laws, contractual obligations, and/or where the information is received from a designated owner of the information (e.g., a patient). may be restricted to comply with certain authorizations.

FIG. 3B shows an example 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 indicated by blocks with dashed outlines. For simplicity and ease of explanation, the information within sub-blocks 280 and 380 is not shown. As outlined above, some or all of the information within sub-block 280 may form part of DIR record 300.

As shown in FIG. 3B, the DIR 300 may further include a formulary 405, which may include a list of approved prescription drugs (eg, generic and brand names) associated with a therapeutic class. A drug formulary may be used to identify drugs and/or devices covered by a drug plan and/or insurance plan. Formularies may be updated and/or published periodically. For example, laws, regulatory agencies, health insurance exchanges, and/or private employers may specify that formularies for available/approved insurance plans be published and updated at specified times. obtain. Therefore, in some cases, prescribing information for various plans may be publicly available and/or may be available to organizations enrolling in the plan on behalf of plan participants (e.g., organizational members/employees). ) and/or may be available from other entities (eg, regulatory agencies, health exchanges, etc.).

Formularies may differentiate between products by dividing treatments into "tiers." Each category may have different levels of patient cost sharing. For example, for preferred class drugs/devices, patient cost sharing may be $0 or may be limited to a co-payment (subject to deductible) specified in the patient's insurance plan. Drugs/devices in the unfavorable category may be subject to additional patient cost burdens, often referred to as "co-pays." For example, a patient prescribed an objectionable drug may pay a certain percentage (eg, 30%) of the drug price as a co-pay in addition to the copayment. The amount of co-payments may depend on the classification. Similar "classifications" may also apply to devices and/or other medical treatments.

Accordingly, formulary 405 may include payer-i fields 410-i (1≦i≦n), each having information about a corresponding payer i. Additionally, formulary 405 may include information for each payer-i 410-i regarding the corresponding drug category, which may appear in repeated category-j field 410-j (1≦j≦T_i). Here, T_i is the number of categories associated with payer-i. The classification associated with a drug may depend on the instruction for which the drug is being used (eg, listed in instruction field 420-k) and payer-i 410-i. For example, the formulary 405 in the DIR record 300 for a drug (e.g., for Payer 1 410-1 and any order 320-k) indicates that the first generic drug is Category 1 415-1 and the more expensive second The generic drug of 2 may be designated as a Category 2 415-2 drug and the branded drug as a Category 3 415-3 drug. Furthermore, each partition-j field 410-j may include a repeated instruction-k field 420-k (1≦k≦s). The indication-k field 420-k under the category may specify the condition (indication) for which the formulary has been approved as a treatment (eg, by Payer 1 410-1 and/or PBM 150).

Therefore, a patient's out-of-pocket costs (e.g., co-payments) are based on medical treatment guidelines for the condition, available treatment options, the treatment regimen ultimately selected by the patient or HCP 120, and the classification associated with the selected treatment. 415, the instructions for the selected treatment 420, and the payer 140 and/or the PBM 150. However, such out-of-pocket cost information is often difficult to obtain or unavailable to the patient and/or HCP 120 at the time of prescription, and as a result, (e.g., less expensive treatment options (if available) may result in higher ongoing costs to the patient and/or may result in additional transactions such as prescription/therapy changes and/or review of treatment decisions by the HCP 120 and the patient. Furthermore, taken as a whole, suboptimal decision and/or transaction overhead negatively impacts overall system cost and efficiency.

As shown in FIG. 3B, DIR 300 may include various other data fields, including price 425-pd, which may list the price at which the treatment (eg, drug or device) is being made available. Price 425-pd may be a payer 140- or PBM 150-provided estimate of patient costs (as seen by payer 140/PBM 150 based on current patient insurance coverage information). Patient costs (as estimated by payer 140/PBM 150) include any unmet deductibles, patient copays, co-payments (e.g., under category 415), ) and the negotiated price of the drug/device (eg, between payer 140/PBM 150 and PMDP 120/pharmacy 160). As outlined above, for a particular payer and treatment, classification 415 may depend on instructions 420 associated with that treatment. As another example, price 425-pd may reflect a negotiated price (e.g., with PMDP 120 and/or pharmacy 160 and/or another entity), with additional cost breakdowns (.g. copays 421, Deductible 423, information may be provided in relation to patient out-of-pocket costs.

In some situations, the formulary 405 (including subfields) and related information are obtained as a formulary subblock 480 (e.g., from another entity such as the payer 140 and/or the PBM 150 and/or the health exchange). can be done. In some embodiments, portions of sub-blocks 480, such as price 425, copayments 421, deductibles 423, and copays 429, may be included in the updated formulary 405 during the transaction and/or prior to final transaction approval. (e.g., from payer 140 and/or PBM 150). Accordingly, the information in sub-block 480 may be current (or may be brought up to date/updated) at the time of the transaction. Based on insurance coverage related information 272 and/or plan ID 270 received from HCP 120 (e.g., as part of sub-block 280), ) Data fields price 425, copay 421, deductible 423, and copay 429 may be provided for the corresponding drug/device 302.

In some cases (e.g., if sub-block 280 does not include coverage-related information 272 and/or plan ID 270), payer 140 and/or PBM 150 and payer 140 and/or PBM 150 may, in sub-block 480, 425 , copayments 421 , deductibles 423 , and copayments 429 and may provide that information to PMDP 130 . For example, payor 140 and/or PBM 150 may use transaction ID 695 and transaction type to respond to requests to PMDP 120 for information about previous information received from HCP 120 (e.g., in subblocks 280 and/or 284). The price 425, copayment 421, deductible 423, and copayment 429, and/or other information in subblock 480 may be determined by correlating with the subblock 480.

In some embodiments, PMDP 130 uses the information in block 480, including price 425-pd, co-pay 421-pd, deductible 423-pd, and co-pay 429-pd (e.g., drug /device ID field 302-pd) may be determined. PMDP 130 may provide payment assistance 391--pd (e.g., for drugs/devices manufactured and/or supplied by PMDP 130) to increase affordability and/or offset patient out-of-pocket costs. There may be many cases. Payment assistance provided by (or on behalf of) PMDP 130 may be based on various patient eligibility criteria. Accordingly, an updated patient cost breakdown may be provided along with prescription cost metrics 395. The updated patient cost breakdown includes (a) out-of-pocket patient costs 392-pd, (b) payment assistance 391-pd, and (c) (a) above for the corresponding drug/device 302-pd. and (d) one or more other optional fields.

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

In some embodiments, PMDP 130 and/or another entity and/or user (e.g., patient) application (e.g., running on a mobile device such as a smartphone, handheld computing device, tablet, etc.) Payment assistance information may be obtained from PMDP 130 to determine cost information 395 associated with each drug/device 302 within the prescription identified by prescription code 250. For example, the application may determine any payment assistance 391-pd received from one or more PMDPs 130 (or an entity affiliated with one or more PMDPs 130) to determine cost metrics 395. can be aggregated. In instances where an entity payment assistance program may be coordinated and/or managed by an entity other than PMDP 130 (i.e., an affiliate, patient access program provider/coordinator, local agency, nonprofit organization, government, or other entity), payment Assistance information may be provided by the management entity (e.g., via an application on the patient's mobile computing device) based on information received from each PMDP 130 (e.g., as reflected in sub-block 390). . In some embodiments, the application on the patient's mobile computing device is an entity associated with the permissioned blockchain platform (e.g., HCP 120 and/or patient access program coordinator and/or health exchange and/or PMDP 130). may communicate via a secure channel with entities that authorize/offer the application to exchange information with entities associated with the permissioned blockchain platform.

Cost information 395 may be based on patient criteria 297 that may specify criteria or preferences (location where prescriptions are filled, preferred pharmacy, etc.) used to determine cost information 395. Cost metrics 395 include drug levels indicated by 395_pd (e.g., cost breakdown for a particular drug/device 302_pd, lowest cost pharmacy from which a particular drug/device 302-pd can be obtained, duration of treatment and/or insurance coverage). the lowest cost drug 337-pd in class 302-p over a specified period of time, such as a period of time, and/or the prescription level indicated by 395_p (e.g., one or more The set of drugs/devices 302 that will provide the lowest cost to fill the prescription when selected, provide the lowest cost over the duration of treatment for the prescription. the set of drugs/devices 302 that would provide the lowest cost over a particular period of time, such as the current insurance/benefits coverage period, etc.).

FIG. 3C shows that from the initial proposed prescription 250 (which may be part of the first EHR sub-block 280), the patient/HCP 120 may be presented with cost information 395 to facilitate treatment selection (e.g. , DIR subblocks 380 and/or 390).

As outlined above, in some embodiments, information related to the first proposed prescription 250 is obtained via the first EHR sub-block 280 (e.g., by the PMDP 130 and/or another entity). can be done. EHR subblock 280 may also include other information (eg, patient health insurance coverage information). As shown in FIG. 3C, the example proposed regimen 250 may include a plurality of first treatments (e.g., proposed drugs/devices 255-i, (1≦i≦N). Subblock 280 may be encrypted and decryptable by PMDP 130 and/or another authorized entity.

In some embodiments, drug/device class 337-p (1≦p≦P) includes one or more drugs/devices 255-p, (1≦p≦P) in proposed formulation 250. ) can be determined correspondingly. As shown in FIG. 3C, a drug/device 302_pd (1≦d≦D_p, where D_p is the number of selected drugs/devices in class p) corresponding to each drug/device class 337-p is determined. can be done.

For each drug/device 302_pd in drug/device class 337-p, patient out-of-pocket cost 392_pd, payment assistance 391_pd, cost breakdown 397_pd, and pharmacy information (e.g., pharmacy ID 394_l to which patient out-of-pocket cost 392_pd is applicable) ), and cost information 395_pd (of the level of drug 302_pd) may be determined. Cost information 395_pd may be determined based on patient insurance coverage information and/or information received from PBM 150 and/or payer 140 and/or another entity. In some embodiments, pharmacy ID 394_1 may be determined based on patient criteria 297 (eg, provided at block 280). Pharmacy ID 394_l may include pharmacy-related information and/or may be used to retrieve pharmacy-related information. In some embodiments, the above information may be provided to HCP 120, the patient, and/or another entity. For example, the above information may be encrypted in sub-block 390 and may be decrypted and read by an authorized receiving entity. As an example, HCP 120 and/or the patient may receive the above information in an application running on a smartphone or other mobile computing device.

In some embodiments, cost information for drug/device 302_pd is applied to one or more user (e.g., patient) specified criteria to determine cost metric 395_p (at the level of prescription 255_p). can be aggregated based on As an example, prescription-level (potential) cost information 395-p may be based on, for example, the drug/device 302-pd and/or assuming that one or more drugs/devices 302 may be selected. obtain.

As another example, cost information associated with potentially equivalent prescriptions may be analyzed to determine whether potentially equivalent prescriptions are available at a single pharmacy within some threshold distance of location (e.g., current or served location). A cost metric 395_p may be determined, such as the lowest total cost to fill the prescription. As a further example, cost information associated with potential equivalent prescriptions may be analyzed to determine location (e.g., current location, or postal code or A cost metric 395_p may be determined, such as the lowest total cost for a potential prescription within some threshold distance of a provided location (such as an address). As an additional example, cost information associated with potentially equivalent prescriptions may be analyzed to identify prescriptions within some threshold distance of location (e.g., current location or a provided location such as a postal code or address). The cost metric 395_p may be determined such that the total cost is within some user-specified threshold for the lowest cost prescription while limiting the number of pharmacies used to fill the prescription. As another example, cost information associated with a prescription may be analyzed to include the total cost of treatment over the expected treatment period and/or over some specified time period (e.g., current or remaining insurance period). A cost metric 395_p of . Patient criteria 297 may also specify other considerations such as preferred pharmacy, mail order options, etc. that may be used in determining cost metrics, out-of-pocket costs, and the like. For example, if the user specifies that mail order is acceptable, the sub-block may include costs associated with mail order pharmacies in addition to local pharmacies 160.

If DIR block 300 may be added to the DIR blockchain, some data within DIR information block 300 may depend on input from, validation by, and/or confirmation by other entities. . For example, information in formulary 405 that is associated with a payer (e.g., payer 140 specified within payer i 410-i) may form part of DIR block 300, 140). Once validation is provided and transaction confirmation is received, DIR block 300 may be added to the DIR blockchain. Verification may be obtained from payer 140 in the form of a sub-block (eg, sub-block 480). The information in sub-block 480 may be specific to the transaction (eg, as identified by transaction ID 695), may be encrypted by payer 140, and may be decryptable by PMDP 120. In some cases, encrypted sub-block 480 (or the information present in sub-block 480) may be intended specifically for 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 information in the data field formulary 405, Payer 1 140-1, the segment associated with the payer in Payer 1 140-1 -j field 415- The segment information in each of the segment-j, instruction-k fields associated with each segment-j field 410-k may be part of sub-block 480 received from Payer 1 140-1. . However, information related to any other payers may not form part of sub-block 480 because these payers may not be parties to the transaction. Thus, for transactions involving a single payer (eg, Payer 1 140-1), DIR record 300 may include information about that particular payer (eg, in subblock 480).

If multiple payers are involved in a transaction, multiple encrypted sub-blocks (e.g., each from a corresponding payer 140-i) may be received by PMDP 130 and integrated into DIR record 300 by PMDP 130. . The information within 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 of some information that may be shared with another specific entity. Generally, the information used to form subblocks from data records or blocks within a locally maintained blockchain (e.g., DIR300) is subject to regulations (e.g., healthcare and/or privacy) that govern information sharing. (e.g., determining what information entities can and cannot share), business guidelines (e.g., trade secrets or confidential information), and/or contractual obligations (e.g., between or among entities sharing information); related to).

Accordingly, in some embodiments, data in sub-blocks sent to PMDP 130 may be separately encrypted by the corresponding sending entity (e.g., payer-i 140-i) and decryptable by PMDP 130. possible, and may be unavailable to unauthorized entities. In some embodiments, encryption of data within sub-blocks (eg, received by PMDP 130) may be based on any suitable encryption technique, including symmetric key cryptography. Encryption may be based, for example, on a private key shared between the entities (eg, payer 140-i identified in Payer 1 140-1 field and PMDP 130). A receiving entity (eg, PMDP 130) may be able to decrypt the received sub-blocks, eg, based on a secret shared key.

Furthermore, before being added to the blockchain, the data within DIR block 300 may also be separately encrypted by the first entity (e.g., PMDP 130) using any secure encryption technique, and its As a result, the data is decryptable and usable by the first entity (eg, PMDP 130), but not viewable by other entities (eg, HCP 120 and/or payer 140).

FIG. 4 illustrates a portion of an example pharmacy benefits record (PBR) 400 that may be maintained by PBM 150. The term PBM is used to refer to any entity that serves to manage a portion of benefits (eg, prescriptions for drugs and/or medical devices) on behalf of a payer (eg, payer 140). In some cases, PBMs may partner with insurers/payers. In some cases, insurers/payers may directly manage drug/device benefits, so payer 140 and PBM 150 are considered a single entity, and portions of the following discussion will be directed to a single (payer) +PBM) entities may also be applicable.

PBR 400 may include information related to payers and associated benefit plans, available benefits, patient/enrollee information, payer drug/device classification, cost sharing, etc., and may be provided by PBM 150 (e.g., PBI database 155 can be owned and maintained within In some embodiments, data fields within PBR 400 may be added and/or updated by PBM 150 based in part on information received from patient/HCP 120 and/or payer 140 and/or other entities. . PBR 400 may also include data received from other entities (eg, as subblocks). The fields shown in PBR 400 are merely exemplary; PBR 400 may include various other additional fields based on laws, standards, PBM conventions, industry conventions, and the like. A PBR may include fields that are different (more or less) than those shown in connection with example PBR 400.

The PBM may determine the drug category of the prescribed drug, which may determine the co-pay amount. PBMs may also set or determine retail prices for pharmaceutical products, obtain payments or rebates from manufacturers based on the sales volume of a particular product or basket of products, and, in some cases, obtain payments or rebates from formulary pharmacies. Post-sale price transfers and payments may be obtained. Accordingly, PBR 400 may include a sales information field 497, which may store transaction and other sales information for each drug. PBR 400 may also include various other fields (not shown in FIG. 4) to track payer-specific and pharmacy-specific sales volume aggregates for drugs/devices, discount/rebate information, etc. PBM 150 may exchange information (eg, with HCP 120, payer 140 and/or pharmacy 160 and/or PMDP 130 via encrypted sub-blocks).

In some embodiments, PBR 400 may be associated with a PBM profile field 495 that may store information related to PBM 150 (eg, PBM identification, contact information, address, etc.). In some embodiments, some or all of the information in PBM profile 495 may optionally be shared with other entities in connection with the transaction. For example, a portion of PBM profile 495 may include one of PMDP 130, payer 140, and/or pharmacy 160 (e.g., as part of an encrypted subblock that may be decryptable by a designated receiving entity). may be sent to one or more entities.

As shown in FIG. 4, PBR 400 may include a portion of the information in sub-block 280 (shown surrounded by a dashed border). In some embodiments, some of the information within sub-blocks 280 may be received from HCP 120 and updated and/or verified by PBM 150. In some embodiments, PBM 150 may receive some or all of the information in sub-block 280 from PMDP 130 (eg, indirectly). In some embodiments, sub-block 280 may include sub-block 284 and/or some or all of the information within 284.

Thus, as illustrated in FIG. (based on), a diagnosis 235, a diagnosis code 240, an instruction 242, a diagnosis code 240, a treatment code 245, and a prescription code 250. Additionally, PBR 400 also sends the transaction ID 695 to PBM 150 along with the actual prescribed drug/device 255-ps (e.g., corresponding to selected drug/device 302-pd from drug/device class 337-p), dose 260-ps, and/or a duration of 265-ps, where 1≦p≦P and for each drug/device class p, 1≦s≦D_p It is. The prescription code and associated prescribed drug/device in sub-block 280, such as 255-ps, dose 260-ps, and/or duration 265-ps, of the drug/device after evaluation of drug/device 302-pd. It may represent a selection (eg, selected by the patient and/or prescribed by the HCP 120). For example, HCP 120 and/or a patient (consulting with 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. PBM 150 may incorporate some or all of the information in sub-block 280 into PBR 400 (eg, at the time of transaction confirmation/final approval). Transaction ID 695, which may uniquely identify transactions between entities, may facilitate information exchange and coordination between entities. For example, a unique transaction ID 695 shared between entities that are parties to a transaction may be used to identify information received from one or more entities, locally stored information and/or information received from other entities. It can be used to correlate, aggregate, verify, and process information. In some embodiments, the final approved prescription 250-s (e.g., in the second sub-block 280 from the HCP 120) is sent following the DIR sub-block 380 (with the drug/device 302-pd). can be done.

PBR 400 may also include a portion of the information in sub-block 380 that may be received from PMDP 130 along with transaction ID 695. For example, in some embodiments, PMDP 130 transmits (eg, within one or more encrypted sub-blocks 380) drug/device 302-pd corresponding to drug/device class 337-p. (in which case each drug/device class 337-p may be associated with at least one prescribed drug 255-p (e.g., within the initial prescription 250 sent to PMDP 130). may include a drug/device name 304-pd (which may be received as part of sub-block 380) that corresponds to drug/device 302-pd. PBM 150 processes the information in sub-block 380 to identify the approved drug, A list of partitions, costs, etc. may be returned (eg, in sub-block 480).

In some embodiments, transaction ID 695 may be used by PBM 150 to determine that subblocks 282 and 380 are associated with the same transaction. PDM 150 may then use insurance coverage-related information 272 in sub-block 280 to determine information in sub-block 480 (eg, formulary, tester, etc.). In some embodiments, sub-block 380 also includes plan ID 270 and insurance 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. obtain. For example, PBM 150 may include insurance coverage-related information 272 (for patient and payer 140-i) along with additional patient insurance coverage information 495 (which may be locally maintained and/or obtained from payer i 410-i). may be used to determine the information within sub-block 480.

As shown in FIG. 4, sub-block 280 within PBR 400 includes payor 140-i (e.g., determined based on insurance coverage information 272 and/or plan ID 270) and payer 140-i (e.g., based on sub-block 380). The drug/device 302-pd may include a formulary 405 that includes category information 415-j and instructions 420-k for the drug/device 302-pd (as determined by the drug/device 302-pd). In some embodiments, subblock 480 includes diagnosis 235, diagnosis code 240, instruction 242, treatment code 245, prescription code 250, prescribed drug/device 255, corresponding dose 260, and/or duration 265 ( for example, determined based on sub-block 280). PBR 400 may also include transaction ID 695. PBM 150 may incorporate some portion of the information in sub-blocks 280 and/or 380 into PBR 400 (eg, at the time of transaction confirmation/final approval).

In some embodiments, PBM 150 may further include various other data fields (e.g., as part of sub-block 480), including price 425, and various other data fields that include price 425 (e.g., as part of sub-block 480); The prices at which the device 302-pd) is made available may be listed (by plan, tier, and instruction information). Price 425-pd may be a patient cost estimate provided by payer 140 or PBM 150 (as seen by payer 140/PBM 150 for drug/device 302-pd) or (e.g., PMDP 120 and/or The price may be a negotiated price (as negotiated with pharmacy 160 and/or another entity). In some embodiments, additional cost breakdowns (.g. copayments 421-pd, deductibles 423-pd, copays 427-pd, patient out-of-pocket costs for drug/device 302-pd are included in subblock 480 may be provided as part of.

As outlined above, information within subblocks received or transmitted by PBM 150 may be encrypted. A received sub-block may be decoded by PBM 150 when it is addressed, whereas a sub-block transmitted by PBM 150 may be decodable by the intended recipient.

FIG. 5 illustrates an example pharmacy prescription record (PPR) 500 that may be maintained by an entity such as pharmacy 160. Pharmacy refers to any entity (physical, virtual, or mail order) that fulfills prescriptions written by a healthcare provider, such as HCP 120. The pharmacy receives the prescription from the HCP 120, verifies patient insurance coverage information with the payer 140 and/or PBM 150, interacts with the patient to fulfill the prescription, and establishes a contract with the payer 140/PBM 150 and/or Collecting payments from patients according to payment agreements (e.g., based on insurance coverage by collecting one or more of negotiated prices, copays, deductibles, copays, etc. for drugs/devices) can be received.

In some embodiments, PPR 500 may be owned and maintained by pharmacy 160 (eg, within PPI database 165). In some embodiments, data fields within PPR 500 are added and/or updated by pharmacy 160 based in part on information received from patient/HCP 120 and/or payer 140 and/or other entities. obtain. PPR 500 may also include data received from other entities (eg, as subblocks). The fields shown in PPR 500 are merely exemplary; PPR 500 may include various other additional fields based on laws, standards, pharmacy practices, industry practices, and the like. A PPR may include fields that are different (more or less) than those shown in connection with example PPR 500.

In some embodiments, PPR 500 may include a pharmacy profile field 595 that may store information related to pharmacy 160 (eg, pharmacy identification, contact information, address, etc.). In some embodiments, some or all of the information within pharmacy profile 595 may optionally be shared with other entities in connection with the transaction. For example, a portion of pharmacy profile 595 may be one of the following: PMDP 130, payer 140, and/or pharmacy 160 (e.g., as part of an encrypted sub-block that may be decryptable by a designated receiving entity). may be sent to one or more entities 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 insurance coverage information 572, PBM information 582, and patient copayment 421-pd. The PPR 500 also includes the prescription code 250 for the prescription 255-p, the HCP profile 295 (e.g., healthcare provider ID, registration number, contact information, etc.) associated with the prescribing entity for the prescription 255-p, the prescription code 250 for the prescription 255-p, may include a prescribed drug/device associated with 255-ps, a duration of 265-ps, and a dose of 260-ps. In some embodiments, the PPR 500 includes various other fields, such as prescription date, fulfillment status (e.g., ready for pickup, collected, and/or delivered to patient, etc.). 5) may be included.

In some embodiments, (subfields patient name 204, DOB 206, portion of patient insurance coverage information 572, prescription code 250, prescribed drug/device 255-ps, duration, dosage, and HCP profile information) The patient information 510 containing patient information 510 may be received by the pharmacy 160 from the HCP 120 as an encrypted sub-block 290 that can be decrypted by the pharmacy 160 upon confirmation of the prescription. One drug/device 255-ps may be selected from p and the selected drug/device 255-ps may be provided to pharmacy 160 as part of sub-block 290.

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

In some embodiments, the pharmacy may transmit some or all of the information in sub-block 290 to payer 140 and/or PBM 150 (eg, in accordance with any prevailing regulations). Information sent by pharmacy 160 to payer 140 and/or PBM 150 is transmitted in encrypted subblocks (not shown in FIG. 5) that can be decrypted by designated entities (e.g., payer 140 and/or PBM 150). ). In response, pharmacy 160 may receive and decrypt encrypted sub-blocks 490 from payer 140 and/or PBM 150. Sub-block 490 may include verification information (eg, regarding patient insurance coverage) that may be used by pharmacy 160 to verify and update patient insurance coverage information 572 and update PBM information 582. In some embodiments, the PBM 150 and/or the payer 140 may further include copayment information 421-ps for the prescribed drug/device 255-ps associated with the prescription 250-s.

In some embodiments, PPR 500 may further include transaction information 515, which includes information related to the transaction, such as patient costs 515 (such as co-pays 421-ps as seen by pharmacy 160), payer Costs 525 (eg, amounts billed/can be billed to payer 140 and/or PBM 150) and payment modalities (eg, used by the patient) may be stored. For example, in cases where PMDP 120 provides patient assistance (e.g., as part of a patient assistance program) in conjunction with copays (or other out-of-pocket patient costs), PMDP 120 (or an entity acting on behalf of PMDP 120): A discount card, discount code, or prepaid card may be provided that may be presented to pharmacy 160 as payment and recorded on form 530 in the payment field.

FIG. 6 shows 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; HTR 600 may include various other fields based on laws, standards, industry practices, and the like. Additionally, an HTR may include fields that are (more or less) different than those shown in connection with example HTR 600. In some embodiments, the HTR 600 includes a payer 140 (e.g., a health insurance provider and a transaction information database 147) that may be responsible for transaction approval and/or payment to one or more entities associated with the transaction. may be owned and maintained by entities such as (some forms of)

HTR 600 includes information about entities associated with and/or authorized to transact with payer 140, including patient profile 195, HCP profile 295, PMDP profile 395, PBM profile 495, and pharmacy profile 595. data fields. Stored profiles may include information for performing transactions between entities (eg, payments, rebates, insurance coverage verification, treatment/prescription authorization, etc.).

HTR 600 may include cost information 605, which may include the payer's view of the costs associated with the transaction. For example, cost information 605 may include payer costs 610, which may record the net cost to payer 140 for the transaction. Payer costs 610 include PBM costs 612, pharmacy costs 615 (e.g., the price charged to payer 140 by pharmacy 160), PMDP costs 620 (e.g., the price negotiated between payer 140 and PMDP 120), rebates 622 (e.g., received by payer 140 from PMDP 120), HCP treatment costs 625 (e.g., costs of treatment provided by HCP 120 in connection with diagnosis), and patient costs 630 (e.g., patient costs for treatments and prescriptions). may be a function of one or more of the patient out-of-pocket costs 635) as seen by payer 140 under the plan, which may include copayments 632, deductibles 637, and copayments 639. Some of the information associated with cost information 605 may be available to payer 140 (e.g., based on a contract, etc.), whereas some cost information 605 may be may be provided by another entity (eg, via an encrypted sub-block decryptable by payer 140). For example, PBM cost information 612 may be determined by decoding information contained in encrypted subblock 480 that may be sent by PBM 150 to payor 140.

As another example, HCP 120 may send encrypted sub-block 282 to payer 140 having coverage-related information 272, plan ID 270, and/or HCP profile 295. Payer 140 may decode information sub-block 282 and use additional patient insurance coverage information 698 to verify patient insurance coverage. Verification of patient insurance coverage may be provided to HCP 120 by sending to HCP 120 an encrypted sub-block that can be decrypted by HCP 120 along with verification information. Some or all of the additional patient insurance coverage information 698 may also be in encrypted subblocks (e.g., decryptable by PBM 150 ) to facilitate verification of patient insurance coverage (e.g., for treatment) by PBM 150 . ) may be sent to PBM 150.

As a further example, encrypted sub-block 280 (which may optionally include the information in sub-block 282) may be used by HCP 120 for verification and transaction approval (e.g., once the prescription is final approved). may be sent to payer 140. In some embodiments, encrypted sub-block 280 may be decrypted by payer 140, and payer 140 may send one or more confirmation messages (e.g., to HCP 120 and/or other entities). ) to authorize the transaction.

In some embodiments, once the transaction is final approved, the EHR 600 may be stored as part of a local blockchain maintained by and accessible to the payer 140. EHR 600 in encrypted form (and decryptable by payer 140) may form part of a multidimensional block within a multidimensional block. Information not within EHR block 600 of the multidimensional blockchain may be encrypted by other entities and may not be decryptable by payer 140. Conversely, the EHR block 600 within the multidimensional block may not be decodable by the payer 140 and/or other entities associated with the platform. Thus, each entity has a consistent view of transactions that are recorded as multidimensional blocks in a multidimensional blockchain, but entities are owned by other entities (stored as part of multidimensional blocks). Unable to view information within the block. Therefore, information in a block (stored as part of a multidimensional block) owned by a first entity is securely protected from viewing by other second entities.

FIG. 7A shows a flow diagram 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 permissioned blockchain platform that may be made available to subscribing and/or authorized entities. In some embodiments, some or all of flow 700 may be implemented using an application running on a computing device associated with an entity. Some routine messages (eg, patient insurance coverage verification, etc.) are not shown in flow diagram 700 for ease of explanation.

As an example, patient 170 may initiate a transaction using an application running on a mobile computing device (eg, smartphone, tablet, laptop, etc.). In some embodiments, applications may be provided and/or authorized by an entity associated with a permissioned blockchain platform. For example, an application (e.g., running on a mobile computing device associated with patient 170) may be connected to a first entity (e.g., HCP 120, PMDP 130, health exchange, and/or patient access program (e.g., (not shown) 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, patient 170 sends profile and insurance coverage information to one of HCP 120, pharmacy 160, and optionally PMDP 130, and/or one or more other entities. One or more may be provided. For example, patient 170 may provide patient profile and insurance coverage related information to HCP 120 at or before receiving treatment and/or to pharmacy 160 at or before filling a prescription may be provided). In some cases, patient 170 may provide patient profile and insurance coverage information to PMDP 130 to participate in and/or obtain payment assistance. As outlined above, patient profiles and insurance coverage information may be accessed by interacting with an entity authorized to transact on a permissioned blockchain platform and/or using an application on a mobile device associated with it. may be (or may have been) provided.

In some embodiments, HCP 120 transmits insurance coverage-related information 272 and plan ID 270 in an encrypted sub-block 282 (not shown in FIG. 7A) that may be decryptable by the respective receiving entity. It may be provided to payor 140 and/or PBM 150. Payer 140 and/or PBM 150 may respond with additional encrypted subblocks (not shown in FIG. 7A) that can be decrypted by HCP 120 to verify patient insurance coverage.

In some embodiments, at 710, the HCP 120 may determine a diagnosis 235 and first include a corresponding diagnosis code 240 and instructions 242, a treatment code 245 associated with the treatment for the diagnosed condition, and a prescription 250 ( For example, drugs/devices 255-p may be provided with corresponding doses 260-p, each associated with a corresponding duration 265-p. In some embodiments, the HCP (as the initiator of the transaction) may also obtain or determine the transaction ID 695. In some embodiments, the information outlined above, along with patient criteria 297, HCP profile 295, plan ID 270, and optionally insurance coverage information 272, is provided to PMDP 130 as an encrypted EHR sub-block that is decryptable by PMDP 130. can be sent to. For example, insurance coverage information 272 may be provided (within EHR subblock 280) when authorized by the patient (e.g., when the patient is participating or wishes to apply to a payment assistance program associated with PMDP 130). may be sent to PMDP 130.

In some embodiments, in step 715, PMDP 130 may determine, for each drug/device 255-p in prescription 250, a corresponding drug class 337-p. Further, PMDP 130 may determine one or more drugs/devices 302-pd associated with each class 337-p.

At 720, PMDP 130 sends encrypted DIR subblock 380 (or a portion thereof) with class member drug/device 302-pd to diagnosis 235 (and associated diagnosis codes 240 and instructions 242, treatment codes 245, etc.). field) and transaction ID 695 to PBM 150. DIR subblock 380 may further include information about each drug/device 302-pd (eg, as described above in connection with FIGS. 3A-3C). In some situations (eg, when payer 140 performs the functions of PBM 150 and/or when the PBM is not used), DIR subblock 380 may be sent to payor 140. A DIR subblock may be decodable by a designated receiving entity.

At 725, PBM 150 (or payor 140) may respond to PMDP 130 with an encrypted PBR sub-block 480 that includes formulary 405 for payer 140, for each drug/device 302-pd. Associated segments 415-j may include information about pricing information for each drug/device 302-pd, including copays 421-pd, co-pays 423-pd, deductibles 423-pd, and prices 425-pd. including one or more of the following. Sub-block 480 may reference transaction ID 695. For example, PBM 150 (or payor 140) may use transaction ID 695 and transaction type to The information in sub-block 480 may be determined by searching for insurance coverage information associated with. PBR subblock 480 may be decodable by PMDP 130.

At step 730, PMDP 130 decodes PBR sub-block 480 and classifies 415-j and pricing information (e.g., one or more of a co-pay 421-pd, a co-pay 423-pd, a deductible 423-pd, and a price 425-pd) to determine cost information 395 associated with the prescription. obtain. Cost information 395 may take into account any payment assistance received by the patient (when eligible) through a payment assistance program. In some embodiments, cost metrics 395 may include cost breakdown 307-pd, which may be patient out-of-pocket costs for each drug/device 302-pd.

At 735, PMDP 130 may send encrypted DIR subblocks 380 and 390 to HCP 120 along with cost information. DIR subblocks 380 and/or 390 include transaction ID 695, prescription code 250, drug/device class 337-p corresponding to each drug/device 255-p in the initial prescription (eg, at 710), and each drug. /device class 337-p.

At 740, the HCP 120 sends an encrypted sub-block 280-2 having a transaction ID 695 with a transaction type indicating HCP approval of the prescription to one or more of the HCP 120, the PBM 130, and/or the payer 140. can be sent to. Encrypted sub-block 280-2 may further include selected drug devices 255-ps, where 1≦p≦P and for each drug/device class p, 1≦s≦D_p . For example, one drug/device 255-ps may be selected from each drug/device class 337-p. In some embodiments, encrypted EHR subblock 280-2. Each encrypted EHR sub-block 280-2 may be decrypted by a designated receiving entity. The information in encrypted sub-block 280-2 may be similar to sub-block 280 (eg, that of FIG. 2).

At 745, once approved by payer 140 and/or PBM 150, the platform (e.g., a private permissioned blockchain platform) sends a transaction ID 695 and a transaction type indicating a transaction confirmation to the entity associated with the transaction. It is possible. Upon receiving confirmation, each entity sends its respective encrypted records (e.g., EHR 200 to HCP 120, DIR record to PMDP 120, PBR from PBM 140, PPR to pharmacy 160, and HTR to payer 140) to the local block. Can be added to the chain. Additionally, two or more of the encrypted records described above may form part of a multidimensional block 750 within a multidimensional blockchain (not shown in FIG. 7A). The encrypted blocks within the multidimensional block (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 block; May not be decrypted by other entities. Thus, each block represents an entity's view of a transaction, but since each block includes authorized information (via received sub-blocks) from other related entities at the time of final approval of the transaction, the view is Match other entity's views on the same transaction. In addition, each multidimensional block in a multidimensional blockchain represents a snapshot of the final approved transaction as seen by the entities that are parties to the transaction, but not the specific entities (e.g., HCP 120, PMDP 120 in FIG. 7A). , PBM 140, pharmacy 160, or payer 140) (e.g., EHR 200, DIR 300, PBR 400, PPR 500, or HTR 600, respectively, in FIG. (one of the two) is protected from non-owning entities. As shown in FIG. 7A, multidimensional block 750 is visualized as a cube (multidimensional volume), with each face of the cube representing a block associated with an entity that is a party to a transaction. If the transaction is not approved by PBM 150 and/or payer 140 and/or another entity, one or more of steps 715-740 may be repeated.

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

At 760, the pharmacy 160 notifies the patient 170 of the receipt and/or availability of the prescription (e.g., via an application and/or any other acceptable communication such as secure text message, secure email, etc.). Submit a prescription confirmation showing. In some embodiments, when obtaining a prescription (e.g., in person, online, etc.), the patient 170 may provide payment assistance information to reduce out-of-pocket costs.

FIG. 7B depicts entities and layers associated with an example platform for facilitating security and interoperability of healthcare systems. In some embodiments, various entities HCP 120, PMDP 130, payer 140, etc. may form part of a permissioned blockchain platform. In a permissioned blockchain platform, trusted entities can form the platform and invite other trusted entities to join the network. In some embodiments, a permissioned blockchain platform may also be private (eg, to invited and/or authorized entities). In some embodiments, a permissioned blockchain platform may support multidimensional blockchains. Rules related to accessing and adding blocks to the multidimensional blockchain; program code for determining contracts between entities (e.g., smart contracts); applications that leverage platform functionality (e.g., on behalf of patient 170); updates; Verification, etc., may be determined and/or authorized by an entity associated with the permissioned blockchain platform.

In some embodiments, a permissioned blockchain 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 may be made available over a network (eg, the Internet). Cloud-based systems can be based on underlying hardware and software resources and can be public (e.g., available everywhere on a fee basis), private (e.g., limited to an organization), or hybrid. (using some combination of public and private clouds). In some embodiments, these entities associated with the platform may be represented by servers (hardware and/or software), which may in some cases be cloud-based. For example, HCP 120, PMDP 130, and/or payer 140 may include agents running on a server and/or may include agents running on a cloud-based platform including a virtual machine (VM).

In some embodiments, access to functionality provided by a permissioned blockchain platform may be facilitated through layers or APIs associated with the platform. For example, patient 170 and/or another authorized entity acting on behalf of the patient (e.g., an entity that facilitates access to a payment assistance program provided by PMDP 130) may (a) patient selection for and determination of associated cost metrics associated with the initial prescription (e.g., as shown by data in sub-block 280-1 of FIG. 7A); and (b) delivery of payment assistance to patient 170. A mobile application (e.g., a smartphone or other (running on a mobile computing device).

As shown in FIG. 7B, multidimensional block 750 includes EHR information block 200, DIR information block 300, PBR information block 400, PPR information block 500, and HTR information block 600. In some embodiments, multidimensional block 750 may form part of a multidimensional blockchain. In multidimensional block 750, EHR information block 200, DIR information block 300, PBR information block 400, PPR information block 500, and HTR information block 600 are encrypted by HCP 120, PMDP 130, PBM 150, pharmacy 160, and payer 140, respectively. may be encoded and decodable.

Further, the EHR information block 200, DIR information block 300, PBR information block 400, PPR information block 500, and HTR information block 600 are respectively EHR blockchain 772, DIR blockchain 773, PBR blockchain 764, and PPR blockchain 775. , and may form blocks in the HTR blockchain 766. As shown in FIG. 7B, EHR blockchain 772, DIR blockchain 773, PBR blockchain 764, PPR blockchain 775, and HTR blockchain 766 are used by HCP 120, PMDP 130, PBM 150, pharmacy 160, and payer 140, respectively. Can be owned and locally maintained. FIG. 7B also shows sub-block 280 (forming part of EHR block 200), sub-blocks 380 and 390 (forming part of DIR block 300), and sub-block 480 (forming part of PBR block 400). ) is also described. As outlined above, the information within a sub-block may have been shared among several of the entities associated with a transaction before the transaction's final approval, and (at the time of the transaction's final approval) the information within the sub-block 750 may be consistent across multiple blocks forming part of 750. In some embodiments, each field associated with an information block 200, 300, 400, 500 and/or 600 may have a unique global field id, which id indicates that information associated with the field is unique between entities. , the field may be uniquely identified within the multidimensional blockchain system and/or to the associated entity. Multidimensional blocks may include data and timestamps. The timestamps may determine the order in which multidimensional blocks are linked (when completed).

As shown in FIG. 7B, HCP 120, PMDP 130, PBM 150, pharmacy 160, and payer 140 may interact with authentication layer 770. Authentication layer 770 provides identification and management (addition, registration, authorization, and deletion) of system entities and/or applications (e.g., mobile applications) that use (or request to use) functionality provided by the permissioned blockchain platform. ) may include functionality for In addition, the authentication layer supports actions that (a) involve multidimensional blockchains (e.g., adding new blocks, create links, etc.); (b) actions that involve transaction types (e.g., when an entity It may include functionality for verifying permissions related to, for example, whether one can initiate a particular transaction type or whether one can participate in a particular transaction type. Authentication layer 770 may interact with agreement layer 780, which may include functionality to order transactions and verify the legitimacy of the set of transactions associated with multidimensional block 750.

In some embodiments, consensus layer 780 may validate the transactions that make up the multidimensional block. At the time of final transaction approval, consensus techniques applied by consensus layer 780 may confirm the legitimacy of the transactions (including shared data between entities) that make up the multidimensional block. In some embodiments, a consensus technique such as Byzantine Fault Tolerance (BFT), or a variation thereof such as redundant BFT, fast Byzantine consensus, dynamic quorum, or some other voting-based consensus technique is used. Used to determine whether dimension block 750 can be formed using component blocks (e.g., EHR information block 200, DIR information block 300, PBR information block 400, PPR information block 500, and HTR information block 600). can be done. When an authorized entity (e.g., payer 140 or an authorized entity specified for the transaction/transaction type) or some specified number (e.g., all or a majority) of entities validate the transaction or block. , an agreement is reached. Agreement or transaction validation decisions may vary depending on the transaction type.

If the transaction is confirmed as correct by the consensus technology, a first instance of unlocked multidimensional block 750 may be created. As shown in FIG. 7B, the unlocked multidimensional block 750 may be locked and added to the multidimensional block when the transaction is final approved. In some embodiments, the blocks forming part of 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) also include: Upon final approval of the transaction and locking of the multi-dimensional block 750, blocks are added to the respective local blockchains (e.g., EHR blockchain 772, DIR blockchain 773, PBR blockchain 764, PPR blockchain 775, and HTR blockchain 766, respectively). can be added as Accordingly, information in 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 includes information in multidimensional block 750. matches.

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

In some embodiments, agreement layer 780 may apply agreement techniques and interact with smart contract layer 790 to establish the legitimacy and/or validity of the transaction and initiate further actions. Smart contract layer 790 may include program code that implements logic related to blockchain. For example, "smart contract" program code associated with a multidimensional blockchain may process transaction requests and determine the validity of transactions based on program logic. This logic may depend on rules agreed upon by entities for blockchain-related transactions. For example, smart contract layer 790 may reject a transaction (eg, from HCP 120) due to an incompatibility between two or more drugs prescribed to the patient. A smart contract may operate at validation time as well as at commit time before a block is locked and/or committed. In some embodiments, smart contract layer 790 may encode rules or agreements between two or more entities related to data sharing, transactions, etc., which are real-world contracts between the entities. Based on. In some embodiments, each update on a traditional blockchain (e.g., one of the EHR blockchain 772, DIR blockchain 773, PBR blockchain 764, PPR blockchain 775, or HTR blockchain 766) , may be verified by smart contract program code associated with the platform. This smart contract program code may reflect agreements between entities related to data sharing, authentication, payments, etc. A smart contract layer can be viewed as an automated tool that facilitates interactions between entities without manual involvement. In some embodiments, the smart contract layer may begin operating based on rules associated with one or more contracts when those rules are satisfied. Each update to the multidimensional blockchain and/or the passage of time and/or other events and/or a specific request related to the contract (e.g., identified by the contract ID) triggers an action by the smart contract layer. It is possible.

Linking of updated records (eg, updated records 520 and updated records 540) may be performed based on predefined rules agreed upon by the entities (eg, HCP 120 and payer 140). In some embodiments, linking of blocks (eg, updated block 520 and updated block 540) may be performed based on smart contracts associated with a multidimensional blockchain. After linking, updated block 520 and updated block 540 may be rehashed. As outlined above, this link may allow an entity to correlate information in its blockchain with information in a blockchain maintained by another entity. In addition, those entities may be able to determine the transaction or transactions associated with information within a particular block maintained by that entity. Thus, two or more entities may have consistent and consistent views of transactions associated with blocks in different blockchains. During the formation process, multidimensional block 750 may not be fully formed (or is a multidimensional block in progress) (at least initially), and thus blocks received from other entities may Adding dimensions may transform a multidimensional block that is currently in progress (not fully formed). For example, a completed HTR 200 (with a prescription from the HCP 120) may be added as a dimension to an ongoing multidimensional block. Another dimension may then be added to the ongoing multidimensional block, for example a dimension with PPR500 (with prescription information). The process may continue until the multidimensional block is completely formed (eg, includes dimensions from all related parties to the transaction).

Multidimensional blocks (and their component records) may be locked upon final approval of a transaction to prevent further modification and ensure consistent viewing. Any subsequent modifications may result in new multidimensional blocks being added to the multidimensional blockchain. For example, a new multidimensional block may be formed with updates to data records in a single dimension, while substantial information associated with other dimensions may remain unchanged. For example, drug-related information (eg, new contraindications) associated with a drug prescribed to a patient may be updated (eg, by PMDP 130) within a new multidimensional block without updating other records.

A multidimensional block may take the form of a Merkle tree associated with a multidimensional blockchain that includes component data records (eg, EHR 200, DIR record 300, PBR 400, PPR 500, and HTR 600). As outlined above, data records may also be associated with different individual blockchains.

Thus, cryptographic hashes of individual records in different individual blockchains (772, 773, 764, 775, and 766) (e.g., separate cryptographic hashes of EHR200, DIR record 300, PBR400, PPR500, and HTR600, respectively) or “hashes”)) may be obtained using different cryptographic hash functions so that records owned by an entity are not decryptable or visible to other entities. A separate cryptographic function (e.g., which may be known to an entity associated with a permissioned blockchain platform) may be used to obtain a cryptographic hash of a combination of records, such that the top hashes form a multidimensional block. related as a whole. In some embodiments, each multidimensional block may include a block header with a timestamp, a top hash, information related to previous blocks, a pointer to the root of the Merkle tree, and other suitable information. The hash criteria may take the form of a uniform resource locator (URL) on a private permissioned blockchain platform and/or a local (entity-specific) address.

FIG. 7B shows a committed and locked multidimensional block 750 where information from sub-blocks 480, 280, 380, and 390 is shared among corresponding authorized related entities. Additionally, multidimensional block 750 includes linkages between individual component blocks. Multidimensional block 750 may represent, in part, a holistic view of a transaction at a given point in time, because it includes drug (dosage, effect, etc.), patient (medical condition, treatment, etc.) , effects, etc.) and real-world physical conditions associated with the costs at the time. Multidimensional block 750 may also include links to previous blocks within the blockchain. Verified and final approved multi-dimensional block 750 may include final approved data records 200, 300, 400, 500 and 600, which data records are connected to corresponding different local blockchains 772, 773, 764, 775, and 766, which may correspond to final approved information blocks 200, 300, 400, 500, and 600, respectively.

FIG. 8 depicts a flowchart of an example method 800 for promoting healthcare information security and interoperability while facilitating patient treatment selection and treatment cost transparency. In some embodiments, method 800 may use a multidimensional blockchain, and it may be based on different blockchains maintained by individual entities within the system. In some embodiments, method 800 may be performed (at least in part) on a private permissioned blockchain platform, which may in some cases take the form of a cloud-based system. The method 800 also applies to processors, computers, or networks of computers, such as distributed computing systems, servers (hardware and software), including application servers, mobile computing devices (e.g., smartphones, smart wearable devices, handheld computers, tablets, etc.). laptops, etc.) as well as cloud-based systems.

In some embodiments, 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 pharmaceutical 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 an HCP 120, a PBM 150, a pharmacy 160, or an insurance provider such as a payer 140, or a patient 170. . In some embodiments, the first entity and the one or more second entities may form a computing node within a distributed computing system, and the multidimensional blockchain has permissioned private blocks. May form part of a permissioned private blockchain platform, such as a chain platform.

In some embodiments, the method 700 operates when an entity, such as a first entity, initiates a transaction (e.g., having a transaction ID and/or transaction type) to add a block to a locally maintained blockchain. , can be called. Adding a block to a local blockchain may invoke input from one or more other entities, and the permissioned private blockchain platform may invoke method 800.

In some embodiments, in step 810, the first entity generates at least one encrypted first electronic health record (EHR) subblock (e.g., subblock 280) that is decryptable by the first entity. -1), at least one EHR subblock may receive a patient and one or more first treatments (drugs/devices (first treatments) 255-p, 1.≦p≦P); Contains patient medical insurance coverage information for the accompanying prescription 250). For example, one or more of the first treatments may include drugs D1, D2, D3, and D4.

At step 820, the first entity, in response to the first EHR sub-block, generates at least one encrypted first A device drug information (DIR) subblock (e.g., DIR subblock 390) may be transmitted, the at least one first DIR subblock for each of the one or more first treatments (255-p). , a corresponding first therapeutic class (337-p) and one or more corresponding first therapeutic class members (302-pd, 1 ≦d≦D_p), and corresponding first treatment class member cost information (395, 397-pd) for each first treatment class member (302-pd).

For example, a first therapeutic class may include classes C1, C2, C3, and C4, corresponding to drugs D1, D2, D3, and D4, respectively. Additionally, each class has members as outlined below: 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 class member (eg, individually, as in cost breakdown 397-pd, and in the aggregate, as in cost metric 395).

At step 830, the first entity receives an encrypted second EHR subblock (e.g., subblock 280-2) that is decryptable by the first entity in response to the first DIR subblock. The second EHR subblock may include one or more second treatments (e.g., treatments 255-ps selected from treatments 302-pd), and the second EHR sub-block can include one or more second treatments (255-ps) are associated with a corresponding first treatment (302-pd), and each second treatment (255-ps) is associated with a corresponding first treatment (255-p). selected from the associated corresponding first treatment class member (337-pd). For example, the second treatment may include second treatments D12, D21, D31, and D43 selected from classes C1, C2, C3, and C4, respectively, and second treatments D12, D21, D31, and D43 with the corresponding first treatment class members (D1, D2, D3, and D4, respectively) in the first treatment (e.g., the first prescription) (e.g., via classes C1, C2, C3, and C4, respectively) Associated. In some embodiments, the one or more second treatments in the second EHR block may be based on patient-specific cost metrics.

At block 840, the first entity may extend a multidimensional blockchain, where the multidimensional blockchain includes a DIR block (e.g., a DIR block) that includes information associated with one or more second treatments. 300), an EHR block (e.g., EHR block 200) that includes information associated with a second EHR sub-block (e.g., sub-block 280-2), and a transaction block (e.g., HTR 600). It is extended with a multidimensional block that is formed (eg, multidimensional block 750). In some embodiments, the transaction block may include a prescription for a second treatment at a specified location at a specified patient cost.

In some embodiments, upon receiving the first EHR sub-block (e.g., at step 810), the first entity receives one or more first treatments (255-p, e.g., D1, D2). , D3, and D4), a corresponding first therapeutic class (337-p, e.g., classes C1, C2, C3, and C4, respectively) may be determined, each corresponding first therapeutic class having one or two or more corresponding first therapeutic class members (302-pd, members of C1, C2, C3, and C4, each including at least D1, D2, D3, and D4). Additionally, the first entity determines, for each corresponding first treatment class (337-p, e.g., C1, C2, C3, and C4), one or more correspondences associated with the first treatment class. one or more corresponding first therapeutic class member cost information for the first therapeutic class member (e.g., cost breakdown 397-pd for each drug in C1, C2, C3, and C4) individually and/or in the aggregate, such as cost metric 395).

In some embodiments, the first EHR subblock (e.g., 280-1) may include patient-specific parameters (e.g., including patient criteria 297), and the at least one treatment class is based on the patient-specific parameters. Determined by Patient-specific parameters may include one or more of patient comorbidity information, route of administration information (335-pd), safety (330-pd) and efficacy (337-pd) information, and/or patient location information. may contain more than one.

In some embodiments, for each first treatment (255-p), a corresponding first treatment class (337-p) and a corresponding first treatment class member for each treatment class member (302-pd). Cost information (395, 397-pd) may be determined based on patient medical insurance coverage information. For example, cost information may include: (a) a provider (e.g., pharmacy 160) located within a specified distance of the patient's location and whose location information about the patient is in a first EHR subblock (e.g., insurance coverage-related); information 272 and/or the portion of patient profile 230 in sub-block 280 that may include information in sub-blocks 282 and/or 284), and/or (b) the corresponding treatment unit (e.g. , dose and/or duration) for each corresponding first treatment class member (302-pd); and/or (c) each patient-specific out-of-pocket cost for a typical treatment duration. the patient-specific estimated total out-of-pocket costs (392-pd) corresponding to the corresponding first treatment class member (302-pd); and/or (d) the remainder of the health insurance coverage plan associated with the patient. of the total estimated patient-specific out-of-pocket costs corresponding to each corresponding first treatment class member (302-pd) for a period of time (e.g., until the end of the current patient insurance coverage). may be further determined based on one or more of the following.

In some embodiments, upon receiving the second EHR sub-block (e.g., at step 830), the first entity may receive payment for at least one of the one or more second treatments. Assistance information may be determined and payment assistance information with transaction confirmation may be sent to the patient. In some embodiments, upon receiving the second EHR sub-block (e.g., at step 830), the first entity provides the patient with payment assistance information for one or more of the second treatments. A transaction confirmation may be sent that includes at least one prescription for.

Payment assistance information may include an electronic credit, code, or any other payment type (e.g., virtual debit/credit card, physical debit or credit card) that may be used to cover some or all of the patient's out-of-pocket costs. etc.) (eg, for one or more specific drugs/devices 255-ps in the formulation and/or for the entire formulation). Thus, in some cases, payment assistance information may include actual monetary payments to patient 170 and/or pharmacy 160. For example, in some cases, the payment assistance may specify the drug and/or pharmacy (or pharmacy company) for which the payment assistance may be used.

FIG. 9 depicts a flow diagram illustrating a process flow 900 for facilitating 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 permissioned blockchain platform that may be made available to subscribing and/or authorized entities. In some embodiments, some or all of flow 700 may be implemented using an application running on a computing device associated with an entity. Some routine messages are not shown in flow diagram 900 for ease of explanation.

As an example, patient 170 may initiate a transaction using an application running on a mobile computing device (eg, smartphone, tablet, laptop, etc.). In some embodiments, applications may be provided and/or authorized by an entity associated with a permissioned blockchain platform. For example, an application (e.g., running on a mobile computing device associated with patient 170) may be connected to a first entity (e.g., HCP 120, PMDP 130, and/or patient access program (not shown in FIG. 9)). The first entity may communicate with the first entity using application programming interfaces (APIs) and/or other network and communication protocols. In some embodiments, a patient 170 may invoke an application that communicates with an entity such as a PMDP 130 (as shown in FIG. 9) or a patient assistance program, patient access program, etc. associated with a permissioned blockchain 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. associated with the application may be conducted as if the entity (e.g., PMDP 130) or may be forwarded (after authorization, verification, and appropriate processing/encoding) by an entity (e.g., PMDP 130).

For the following description, PMDP 130 has been used as an example. However, process flow 900 may also be performed by other entities, such as patient assistance programs and/or patient access programs, which help patient 170 obtain health care insurance coverage and/or qualify for patient assistance. We can help you get it. As outlined above, an application (eg, used by patient 170) may act transparently to patient 170 on behalf of an entity. Thus, in some cases, the operations shown as being performed by patient 170 in FIG. 9 may be performed through and/or attributed to another entity (eg, PMDP 130). In some embodiments, a personal entity that offers several insurance plan options provides an application that implements process flow 900 to potential enrollees (e.g., (shown as patient 170 in FIG. 9).

In many situations, patients often require or use therapy (drugs, devices, and/or treatments) repeatedly. As used herein, the term relapse treatment refers to symptoms that have been present (ongoing) for a long period of time (e.g., weeks, months, or years), and/or are chronic, and/or have the potential to occur. Used to refer to drugs, devices, and/or treatments prescribed to a patient for a medical condition that is present and/or recurs/occurs (e.g., without recommended treatment). For example, various conditions (eg, diabetes, blood pressure, heart disease, kidney disease requiring dialysis, etc., and/or other chronic diseases) may require long periods of time for treatment to be applied or prescribed. In these situations, a drug (eg, drug), device (eg, drug delivery device), or treatment (eg, physical therapy, dialysis, etc.) may be used and/or prescribed repeatedly over an extended period of time. However, when selecting an insurance plan, patients typically consider the total medical costs (premiums paid for the plan, deductibles paid, copays paid, copays paid, received). (minus payment assistance) is affected by plan selection and/or drug/device selection. In some embodiments, some disclosed embodiments that may utilize process flow 900, as described herein, incorporate techniques for reducing costs while maintaining appropriate treatment levels. This allows for easy plan selection.

At 905, patient 170 receives one or more of patient relapse treatment information (e.g., drugs/devices being used by patient 170 on an ongoing/relapse basis) and/or insurance coverage related information 272. Transmission may begin. For example, patient 170 may (e.g., using an application on a mobile computing device) retrieve stored insurance coverage-related information 272 and associated prescriptions for some (e.g., selected by patient 170) or all prescriptions. may indicate that the stored prescription information is transmitted to an entity such as PMDP 130 and/or (e.g., stored locally on the device and/or in the cloud and/or stored by the entity). As an example, a patient application that may track and store patient prescription and insurance coverage information may, upon authorization by patient 170, transmit or instruct local or cloud-based insurance coverage and prescription information to PMDP 130. can start. In some embodiments, the application may take the form of a health management application, and may track patient prescriptions, indicate when premium payments/renewals are due, make payments, manage prescriptions, etc. 1. Indicating when prescribed treatments will be performed, providing refill reminders, automatically reordering prescriptions/refills, tracking costs, scheduling and providing appointment reminders, etc. may include one or more other functions. If the application sends insurance coverage related information 272 and prescription information to PMDP 130, events 910 and 915 may not occur.

In some embodiments, transmitting insurance coverage-related information 272 and/or relapse treatment information also provides authorization to transmit prescription data to PMDP 130 (e.g., to payer 140 and/or PBM 150, and/or or to one or more entities capable of storing patient health-related information. In the example, if authorization is provided and the insurance coverage related information 272 and/or relapse treatment information is provided by one or more external entities (such as payer 140 and/or PBM 150), at 910; PMDP 130 provides one or more payers 140-v (1≦v≦V) and/or PBM 150-u with patient authorization to obtain coverage-related information 272 and/or recurrent treatment information. The requested HTR request may be sent. (1≦u≦U). At 915, payer 140-v (1≦v≦V) and/or PBM 150-u. (1≦u≦U) may respond (eg, to PMDP 130) with the requested information related to patient 170.

At block 920, PMDP 130 may determine the relapse treatment being used by the patient. The term recurrent treatment refers to medications prescribed to a patient for a medical condition that may occur or will exist for an extended period of time (e.g., days, weeks, or months) during the coverage period. , device, and/or treatment. Recurrence treatment is different from one-time treatment (eg, in the case of isolated conditions such as a one-time/short-duration antibiotic regimen to cure an opportunistic/hard-to-predict infection). In some embodiments, the information within the HTR subblock is analyzed to determine the information contained in the HTR subblock (e.g., treatment code 245, prescribed drug/device 255-p, dose 260-p, and duration 265). -p) can determine treatment for patients who relapse. If 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 determines (e.g., step 920 ) can determine treatment for patients who relapse.

In some embodiments, at 925, PMDP 130 may send a request for available plan information to Health Exchange (HEX) 180. HEX 180 may be any entity that offers subscription plans for consumers. For example, HEX180 may be used by government-authorized entities that offer plans under the Affordable Care Act (ACA) or private employers who offer multiple plans to employees for selection/enrollment (e.g., during an open enrollment period). This may be a department or contractor affiliated with. The request for plan information may not include PII information related to patient 170 and may specify the type of information requested. In some embodiments, the request for plan information includes a list of payers 140-v and PBMs 150-u that offer plans at the location specified by patient 170, as well as a plan identification (e.g., plan identification) for each offered plan. ID and/or group ID). In some cases, if the list of payers 140-v and PBMs 150-u and plan identification information are publicly available (e.g., via published information), the published information may be sent to the PMDP 130 request ( (at 925) and without a HEX 180 response (at 930) to obtain that information.

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

In some embodiments, in step 933, PMDP 130 determines, for each recurrent treatment (drug, device and/or treatment) 255-r associated with patient 170, treatment class 337-r and treatment class member 302-rd. may be determined, where 1≦d≦D_r, and D_r is the number of class members in treatment class 337-r. Drugs/devices 302-rd within therapeutic class 337-r may (a) treat similar treatment areas 360-r, and/or (b) have similar modes of action/methods of action 340-r. , and/or (c) may have a similar chemical structure 350-r. Additionally, drugs/devices 302-rd within therapeutic class 337-r may also share route of administration 335-rd and meet other patient criteria 297. In the case of medical treatments, members 302-rd of therapeutic class 337-r may (a) treat similar conditions, and/or (b) provide the same/similar treatment (even at potentially different prices). ) may specify alternative facilities (e.g., at a certain location) where the patient may receive treatment.

At step 935, PMDP 130 sends one or more PBMs 150-u and/or payers 140-v to a DIR subblock (e.g., a DIR subblock containing treatment code 245 and/or other information in block 280). block 380), along with plan identification information (e.g., plan ID and/or group ID), pricing and insurance coverage information (e.g., whether the treatment is insured by the corresponding plan (e.g., available to patient 170)). may be sent as part of the request.

At 940, in some embodiments, the PBM 150-u and/or payer 140-v provides each plan (e.g., as in sub-block 480) and/or authorized provision (e.g., for a treatment) may respond with prescription information about the patient.

Alternatively, in some embodiments. Formulary information for each plan and/or authorized provider (e.g., for the treatment) (e.g., as in sub-block 480) is publicly available (and/or available through HEX 180). In some cases, publicly available information may be used and/or information may be obtained from HEX 180. For example, rules may require plans (payer 140 and/or PBM 150) to publish and update formularies and other insurance coverage information, and therefore each plan (e.g., as in sub-block 480) ) and/or the latest published or updated information may be used to determine formulary information for authorized providers (eg, for the treatment). Thus, in some embodiments, events 935 and 940 may not form part of process flow 900, and PMDP 130, as part of step 933, may separate intermediate steps between steps 933 and 945. As such and/or as part of step 945, formulary information for each plan (eg, as in sub-block 480) and/or authorized providers (eg, for the treatment) may be determined.

In some embodiments, at step 945, PMDP 130 may determine overall patient-specific cost information associated with each plan. For example, a cost C_hs may be assigned to each plan h and may be based on selecting one treatment 302-rs from each treatment class 337-r. For example, if the recurrence treatment (e.g., determined in step 920) is plan h associated with four treatment classes with one or more treatments within each treatment class 337-r, then One treatment 302-rs from each of the two treatment classes may be selected to determine the plan and patient-specific costs C_hs associated with the selected treatment. As an example,

In some embodiments, patient-specific costs C_hs may be provided for different selections of treatments in each plan h. Accordingly, the patient 170 and/or the HCP 120 may be able to determine potential or possible costs associated with a plan prior to plan selection. Payment assistance may be provided by PMDP 130 and/or by other entities (e.g., by the government for premiums under the ACA, or by non-profit organizations, by organizations/programs affiliated with PMDP 130, and/or through tax rebates, etc.). ) may be provided.

In some embodiments, the information may be provided in the form of a table (or database) such as shown in Table 1 below. The table may include information regarding plan h, selected treatment set, cost C_hs, and provider (eg, pharmacy, location, etc.) of each selected treatment 302-rs. In some embodiments, the cost C_hs may further include a cost breakdown (copays, co-pays, etc.) for each selected treatment 302-rs in the treatment set.

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

At 955, the HCP 120 may recommend one of the treatment sets as appropriate, and the patient 170 makes a plan selection (e.g., by selecting the plan shown on the mobile device screen) and selects the plan. You can confirm your selection. The plan selected by patient 170 may be the same as the plan recommended by HCP 120 and/or any other available plan. At 955, once confirmed, the plan selection may be sent to HEX 180.

At 960, once approved by payer 140 and/or PBM 150, the platform (eg, a private permissioned blockchain platform) may indicate a transaction confirmation to the entity associated with the transaction. Upon receiving confirmation, each entity posts its respective encrypted records (e.g., PBR for PBM 140, HTR for payer 140, and corresponding HEX records (not shown in FIG. 9)) to the local blockchain. can be added. In some embodiments, once authorized, a transaction confirmation may also be sent to PMDP 130 to facilitate participation in and payment of benefits from the payment assistance program. In some embodiments, at 960, the platform (eg, a private permissioned blockchain platform) may indicate transaction confirmation by sending a plan enrollment confirmation to the patient 170. Additionally, two or more of the encrypted records described above may form part of multidimensional block 965, thereby extending the multidimensional blockchain.

10A and 10B illustrate a flowchart of an example method 1000 for facilitating healthcare insurance selection and costing and interoperability between multiple entities while maintaining healthcare information security. . In some embodiments, method 1000 may use a multidimensional blockchain, and it may be based on different blockchains maintained by individual entities within the system. In some embodiments, method 1000 may be performed at least in part on a private permissioned blockchain platform, which may in some cases take the form of a cloud-based system. Method 1000 also applies to processors, computers, or networks of computers, such as distributed computing systems, servers (hardware and software), including application servers, mobile computing devices (e.g., smartphones, smart wearable devices, handheld computers, tablets, etc.). laptops, etc.) as well as cloud-based systems.

In some embodiments, method 1000 may be performed at a first entity. For example, the first entity may include an application (e.g., provided by PMDP 130 or another entity) used by a pharmaceutical provider and/or patient, such as PMDP 130 (authorized on behalf of PMDP 130 and/or another entity). (a) may include at least one server or computer system associated with at least one of the following: (i) may interact with and take advantage of functionality provided by the permissioned blockchain platform; In some embodiments, a first entity may interact with one or more second entities. The second entity may be one or more entities associated with a healthcare exchange such as HEX 180, a pharmacy benefit manager such as PBM 150-u, an insurance provider such as payer 140-v, or a patient 170. May include a server or computer system. In some embodiments, the first entity and the one or more second entities may form a computing node within a distributed computing system, and the multidimensional blockchain has permissioned private blocks. May form part of a chain platform.

In some embodiments, the method 1000 includes: when an entity, such as a first entity, initiates a transaction (e.g., transaction ID and/or transaction type) to add a block to a locally maintained blockchain; can be called. Adding a block to a local blockchain can invoke input from one or more other entities, and the permissioned private blockchain platform can invoke method 1000.

Referring to FIG. 10A, in step 1010, a first entity (e.g., an application running on a PMDP 130 and/or a patient computing device such as a smartphone and/or another entity) performs a process that is decryptable by the first entity. The information may be obtained from at least one encrypted first health transaction record (HTR) sub-block (eg, sub-block 280 and/or other treatment-related information within HTR 600). In some embodiments, the HTR sub-block may be received in response to a request that includes patient authorization. The first entity may obtain a first set of first treatments for a patient over a period of time (e.g., based on information in at least one first HTR sub-block), each first The treatment includes a first diagnosis code (eg, diagnosis code 240) and a first treatment code (eg, treatment code 245). In some embodiments, the first EHR subblock includes the treatment code 245 associated with the first (recurrent) treatment 255-p, the prescribed drug/device 255-p, the dose 260-p, and the duration. may include time 265-p. In some embodiments, the time period may include several prior insurance coverage periods and may include multiple payers 140-v, which may facilitate relapse and ongoing treatment decisions.

In some embodiments, the first set of first treatments includes treatment code 245-p, prescribed drug/device 255-p, dose 260-p, and duration 265-p included in the HTR subblock. p may be determined based on one or more of p. The first treatment may include a relapse treatment, such as a drug, device, and/or treatment 255-p, which may have been and/or is likely to be prescribed for a specified period of time. In some embodiments, the information in the at least one first HTR sub-block (e.g., received by the first entity) is analyzed (e.g., mathematically and/or statistically) to determine the first A first set of treatments (eg, relapse patient treatment) may be determined. For example, a monthly prescription may be predicted to continue until the end of a specified time period (eg, based on duration 265-p, determined or predicted frequency). In some embodiments, the predicted and/or determined recurrence treatment may be subject to patient validation. In some embodiments, locally stored data (eg, as part of a health care application) may be used to obtain the first set of first treatments.

In some embodiments, treatments associated with certain medical conditions that are known to be chronic or persistent (e.g., identifiable by diagnosis code 240) may be automatically identified as recurrent treatments. In other examples, treatment that is repeated over that period of time may be determined to be recurrent treatment. As another example, treatment may be based in part on additional information, such as a patient's calendar (e.g., as part of a health management application) that indicates a pattern of scheduled appointments for a particular diagnosis code with a provider. It may be determined that it is a recurrence. If the application (e.g., health care or other application) stores patient treatment and/or appointment information, recurrent 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 the HTR 600 maintained by the payer 140 and/or the PBM 150 PBR 400, which may include records of treatments over time. In some embodiments, multiple payers 140-v and/or PBMs 150-u used by the patient (e.g., over some specified period of time) obtain information in the first HTR subblock. can be contacted for.

In some embodiments, in step 1015, the first entity (e.g., PMDP 130) determines, based on the first set, (a) one or more second sets, wherein each (b) a second set of two sets comprising corresponding second treatments, each corresponding second treatment being associated with a different first treatment within the first set; For example, the corresponding number of recurrences (over a specified time period, such as the duration of intended insurance coverage) may be determined. The number of relapses can be used to determine the cost (eg, by multiplying the cost per treatment by the prorated or normalized number of relapses over a period of time). In some embodiments, the application (e.g., running on a patient computing device, such as a smartphone) is configured to identify one or more second sets, a corresponding second treatment, and each second treatment. A corresponding recurrence may be obtained from PMDP 130 (eg, via a secure API).

As an example, each first treatment (255-p) within the first set of treatments may be associated with a corresponding first treatment class (337-p). Each therapeutic class (337-p) may include one or more therapeutic class members (302-pd, 1≦d≦D_p). Each second set may include a corresponding second treatment (302-pd) associated with a different first treatment (255-p) via a first treatment class (337-p). Thus, as an example, the corresponding second set may include one treatment class member (302-pd) from each treatment class (337-p) (corresponding to the first treatment 255-p). Step 1015 can be viewed as expanding the set of relapse treatments currently prescribed for patient 170 to similar classes of available treatments.

At step 1020, a set of available insurance plans (e.g., plan ID, group ID, etc.) available to the patient and corresponding insurance coverage related information (e.g., premium, deductible, etc.) for each available insurance plan are provided. amounts, co-payments, co-pays, formulary information, etc.) may be obtained (eg, by an application running on the PMDP 130 and/or a patient computing device such as a smartphone). Available insurance plans and coverage related information can be obtained from the HEX180, and/or Payer 140-v, and/or PBM150-u, and/or from the employer (e.g., if the plan is employer-funded). (if any) and/or from publicly available information (e.g., by public information available from government or other public sources). The set of available insurance plans and corresponding insurance coverage related information is based on non-personal information associated with the patient, such as location (country, state, county, city, zip code), age, etc. , without providing the patient's PII). In some embodiments, an application (e.g., running a patient computing device, such as a smartphone) can use published information and/or from the PMDP 130 (e.g., via an API) to A set of insurance plans and corresponding insurance coverage related information may be obtained.

At step 1025, for the one or more available insurance plans, corresponding plan-specific cost information about the patient is determined to include: (a) the one or more sets of second treatments; and (b) It may be determined based on corresponding insurance coverage related information. In some embodiments, the corresponding plan-specific cost information for the patient may reflect applicable payment assistance for each second set. For example, for available plans, plan-specific cost information for patient 170 may be determined based on relapse treatment in each second set. In some embodiments, cost information may be ranked (eg, from highest predicted cost to lowest predicted cost). In some embodiments, step 1015 may be skipped and, at block 1025, plan-specific cost information for the patient is determined based on the first set of first treatments, thereby determining the existing plan-specific cost information used by the patient. can provide plan-specific cost estimates for treatment. In some embodiments, an application (e.g., on a smartphone or other mobile computing device associated with patient 170) determines plan-specific cost information and provides information to patient 170 by cost or other patient criteria 297. A list of plan options that can be ranked may be provided. In some embodiments, plan-specific cost information for a patient may be received by the application from PMDP 130 (eg, via a secure API).

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

For example, cost information may include aggregated cost metrics 395-p (eg, aggregated plan-specific cost information associated with treatments 302-pr in the corresponding second set). For example (as shown in Table 1), the DIR sub-blocks (e.g., 380 and/or 390) include plan h, selected treatment set, cost C_hs, and each selected treatment in the corresponding second set. Information regarding the provider of the treatment 302-rs (eg, pharmacy, location, etc.) may be included. In some embodiments, the cost C_hs may further include a cost breakdown (copays, co-pays, etc.) for each selected treatment 302-rs in the treatment set. In some embodiments, an application (e.g., on a smartphone or other mobile computing device associated with patient 170) determines plan-specific cost information and informs patient 170 by cost or other patient criteria 297. A list of plan options that can be ranked may be provided.

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 the patient's plan-specific cost information. For example, a patient may select at least one available insurance plan from a set of available insurance plans. As another example, PMDP 130 receives at least one selected available insurance plan from an application (e.g., on a smartphone or other mobile computing device associated with patient 170) via a secure API. It is possible.

At optional step 1040, PMDP 130 may further receive a second encrypted health transaction record (HTR) sub-block decryptable by PMDP 130, where the HTR sub-block is selected from a set of available insurance plans. Includes selected insurance plans.

Then, in an optional step 1045 (which may be performed when PMDP 130 receives the HTR sub-block in step 1040 and/or is deemed to be a party to the transaction), PMDP 130 transfers the multidimensional blockchain to formed by linking an HTR block containing information associated with a second HTR sub-block and a DIR block containing second treatment information, a plan-specific cost metric for a selected insurance plan, and a transaction block. It can be extended with multidimensional blocks. In some embodiments, the multidimensional blockchain may be augmented with transaction confirmations that include insurance plan selection in response to transaction blocks received (e.g., from HEX 180 and/or payer 140 and/or PBM 150). .

At block 1050, an application (e.g., on a smartphone or other mobile computing device associated with patient 170) sends confirmation of enrollment in at least one selected plan (e.g., HEX 180 and/or 140 and/or via secure messages from PBM 150 and/or from PMDP 130 via a secure API.

FIG. 11 shows a schematic diagram of an example computer 1100 or computing device that can facilitate security and promote interoperability in a healthcare system. In some embodiments, computer 1100 may host and/or interact with a permissioned private blockchain platform. 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 a permissioned blockchain platform. can be used to implement. Computer 130 is merely an example; several computers may be used in a networked and/or distributed manner to implement the methods and process flows disclosed herein.

In some embodiments, the example computer 1100 is a (physical) server for one or more entities (such as HCP 120, PMDP 130, payer 140, PBM 150, pharmacy 160, and/or HEX 180). or may run a server (eg, an application server). In some embodiments, one computer 1100 implements some or all of the process flows and/or methods and/or other techniques disclosed herein, including those of FIGS. 7-10. obtain. In some embodiments, computer 1100 may form part of a distributed computing system and may implement a permissioned private blockchain platform. In some embodiments, distributed computing system and/or computer 1100 may be cloud-based. In some embodiments, computer 1100 may run applications that interact with other computers 1100 and/or other applications to implement the techniques disclosed herein, such as a smartphone, tablet, handheld, etc. It can be a mobile computing device such as a notebook and/or laptop.

In some embodiments, the computer 1100/processor 1150 may be capable of processing transaction requests, including requests related to adding blocks to a blockchain, including requests related to adding blocks to a blockchain, and adding a multidimensional blockchain. include. Further, the 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 perform various methods. and/or may be enabled to facilitate security and authentication. Authentication refers to the verification of the integrity of stored information (e.g., within a block within a blockchain to determine any unauthorized modification) and the verification that entities accessing a permissioned private blockchain platform It can refer both to ensuring that you are trustworthy and have permission to perform any requested transactions. In some embodiments, the computer 1100/processor 1150 can also extend (create or add to) a blockchain with new blocks (extending a multidimensional blockchain with multidimensional blocks). include).

In some embodiments, the computer 1100/processor 1150 also stores and executes smart contracts associated with blockchain to improve privacy between entities (e.g., HCP 120, PMDP 130, payer 140, and/or patient). , may implement agreements related to information sharing, contract execution, etc.

In some embodiments, the computer 1100/processor 1150 is configured to determine a therapeutic class (e.g., a drug class, a device class, and/or a treatment class) associated with a treatment; Health-related data can be mathematically analyzed and statistically compiled, including determining cost metrics individually and collectively, and filtering and/or narrowing selections using patient criteria. obtain. In some embodiments, the computer 1100/processor 1150 also initiates displaying (e.g., on the display device 1170) information on the smartphone using (e.g., a Graphical User Interface, GUI). In some embodiments, the computer 1100/processor 1150 may also be capable of determining relationships between various health parameters using machine learning techniques. 1100/Processor 1150 may include one or more neural network processors and/or distributed processors that may be configured as a neural network and/or execute software for modeling and/or simulating neural networks. and the software may be used to implement machine learning. For example, PMDP 130 may be configured to use machine learning technology-based RWE information available through multidimensional blocks (e.g., demographic information, side effects, specific (drugs used in combination with drugs of interest, treatment outcomes, etc.) may be used to adjust drug usage. For example, machine learning may be used to determine effective dosages and to adjust drug usage based on demographics. to improve drug interaction information, increase safety, determine the relative effectiveness of various modes of administration, etc.

In some embodiments, computer 1100 may couple to other computers using a communications/network interface 1102, which may include wired (eg, Ethernet, including Gigabit Ethernet) and wireless interfaces. Wireless interfaces include Wireless Wide Area Network (WWAN) standards such as cellular standards, including 3G, 4G, and 5G standards, and the IEEE 802.11x standard, commonly known as Wi-Fi. . and/or may be based on a wireless personal area network (e.g., Bluetooth, Near Field Communication (NFC), etc.). In some embodiments, the computer 110 may include a global positioning system and/or a location determination unit to automatically determine a location (eg, of a patient), as shown in FIGS. 7-10. Can be used in conjunction with the disclosed technology.

Computer 1100 may include memory 1104, including various types of read only memory (ROM), programmable read only memory (PROM), and random access memory (RAM). ), nonvolatile RAM, and the like. Memory 1104 may be implemented within processor 1150 or external to processor 1150. As used herein, the term "memory" refers to any type of long-term, short-term, volatile, non-volatile, or other memory, including any particular type or number of memory, or There is no limitation to the type of medium on which the information is stored.

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

Communications/network interface 1102, storage 1160, memory 1104, and computer readable medium 1120 may be coupled to processor 1150 using connection 1106, which may take the form of a bus, line, fiber, link, etc. .

The methods described herein may be implemented by various means depending on the application. For example, these methods may be implemented in hardware, firmware, software, or any combination thereof. For a hardware implementation, processor 1150 may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), neural network processors, NNP), digital signal processing device (DSPD), programmable logic device (PLD), field programmable gate array (FPGA), processor, controller, microcontroller, microprocessor, It may be implemented in an electronic device, other electronic unit designed to perform the functions described herein, or a combination thereof.

For a firmware and/or software implementation, the methodologies may be implemented using microcode, procedures, functions, etc. that perform the functions described herein. Any machine-readable medium tangibly embodying instructions may be used in implementing the methodologies described herein. For example, the software may be stored within storage device 1160 and/or on a removable computer-readable medium. Program code may reside in computer readable medium 1120 , storage 1160 , and/or memory 1104 and may be read and executed by processor 1150 .

If implemented in firmware and/or software, the functionality 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, the computer-readable medium 1120 may include program code stored thereon, may include program code for supporting methods for facilitating healthcare system security, promoting system interoperability, and the like. including supporting dimensional blockchains, smart contracts, consensus adjudication, and performing other functions associated with permissioned private blockchain platforms, as described herein.

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

Although this disclosure has been described in conjunction with particular embodiments for instructional purposes, the disclosure is not limited thereto. Various adaptations and modifications can be made to the present disclosure without departing from the scope of the invention. Therefore, the spirit and scope of the appended claims should not be limited to the foregoing description.

Claims (20)

A method performed by a processor in a first entity, the method 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 a patient and one or more including and receiving patient health insurance coverage information regarding the two or more first treatments;
transmitting, in response to the first EHR sub-block, at least one encrypted first device drug information (DIR) sub-block decryptable by at least one corresponding second entity; and the at least one first DIR sub-block is associated with a corresponding first treatment class and each corresponding first treatment class for each of the one or more first treatments. one or more corresponding first treatment class members and, for each first treatment class member, corresponding first treatment class member cost information;
receiving an encrypted second EHR sub-block decryptable by the first entity in response to the first DIR sub-block, the second EHR sub-block comprising one or two or more second treatments, each of said one or more second treatments being associated with a corresponding first treatment, and each second treatment being associated with said corresponding first treatment. receiving, selected from said corresponding first treatment class member associated with a treatment of;
In response to a transaction confirmation, extending a multidimensional blockchain, the multidimensional blockchain including a DIR block containing information associated with the one or more second treatments; extended with a multi-dimensional block formed by linking an EHR block containing information associated with a second EHR sub-block and a transaction block; Method. Upon receiving the first EHR sub-block, the method includes:
determining, for each of the one or more first treatments, the corresponding first treatment class, each corresponding first treatment class being one or more of the one or more first treatments; determining, including a corresponding first therapeutic class member;
and determining, for each corresponding first treatment class, the one or more corresponding first treatment class member cost information. . the one or more first treatments, or the one or more second treatments based on the corresponding first treatment class member cost information for each first treatment class; 3. The processor-implemented method of claim 2, further comprising determining an aggregate cost metric based on at least one of: or a combination thereof. 2. The processor-implemented method of claim 1, wherein the first EHR sub-block includes patient-specific parameters, and the at least one treatment class is determined based on the patient-specific parameters. 5. The processor-implemented method of claim 4, wherein the patient-specific parameters include patient comorbidity information. 5. The processor-implemented method of claim 4, wherein the patient-specific parameters include route of administration information. 5. The processor-implemented method of claim 4, wherein the patient-specific parameters include safety and efficacy information. 5. The processor-implemented method of claim 4, wherein the patient-specific parameters include patient location information. For each first treatment, the corresponding first treatment class and the one or more corresponding first treatment class member cost information for each treatment class member are included in the patient medical insurance coverage information. A method performed by a processor according to claim 1, wherein the method is determined based on: The one or more corresponding first treatment class member cost information is further determined based on providers located within a specified distance of a patient location, and location information for the patient is determined based on providers located within a specified distance of a patient location; 10. The processor-implemented method of claim 9, wherein the method is included in one EHR sub-block. the one or more corresponding first treatment class member cost information,
patient-specific out-of-pocket costs corresponding to each corresponding first treatment class member for a corresponding treatment unit; or patient-specific out-of-pocket costs corresponding to each corresponding first treatment class member for a typical treatment period. estimated total out-of-pocket costs, or patient-specific estimated total out-of-pocket costs corresponding to each corresponding first treatment class member for the remaining term of a health insurance coverage plan associated with said patient; A method performed by a processor according to claim 1, comprising one or more of: Upon receiving the second EHR sub-block, the method includes:
determining payment support information for at least one of the one or more second treatments;
2. The processor-implemented method of claim 1, further comprising: transmitting the payment assistance information with a transaction confirmation to a patient. Executed by the processor of claim 1, further comprising: transmitting to the patient a transaction confirmation including at least one prescription for the one or more second treatments along with payment assistance information. How to do it. A computing device for a first entity, the computing device comprising:
memory and
a communication interface;
a processor coupled to the memory and the communication interface, the processor 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 a patient and one or two including and receiving patient health insurance coverage information regarding the one or more first treatments;
In response to the first EHR sub-block, transmitting at least one encrypted first device drug information (DIR) sub-block decryptable by at least one corresponding second entity; , the at least one first DIR subblock being associated with a corresponding first treatment class and each corresponding first treatment class for each of the one or more first treatments. including and transmitting one or more corresponding first treatment class members and, for each first treatment class member, corresponding first treatment class member cost information;
receiving an encrypted second EHR sub-block decryptable by the first entity in response to the first DIR sub-block, the second EHR sub-block comprising one or two or more second treatments, each of said one or more second treatments being associated with a corresponding first treatment, and each second treatment being associated with said corresponding first treatment. receiving, selected from said corresponding first treatment class member associated with a treatment of;
In response to a transaction confirmation, extending a multidimensional blockchain, the multidimensional blockchain including a DIR block containing information associated with the one or more second treatments; extended with a multidimensional block formed by linking an EHR block that includes information associated with a second EHR sub-block and a transaction block. , computing device. Upon receiving the first EHR sub-block, the method includes:
determining, for each of the one or more first treatments, the corresponding first treatment class, each corresponding first treatment class being one or more of the one or more first treatments; determining, including a corresponding first therapeutic class member;
15. The computing device of claim 14, further comprising: determining the one or more corresponding first treatment class member cost information for each corresponding first treatment class. the one or more first treatments, or the one or more second treatments based on the corresponding first treatment class member cost information for each first treatment class; 16. The computing device of claim 15, further comprising determining an aggregate cost metric based on at least one of: or a combination thereof. The computing device of claim 1, wherein the first EHR sub-block includes patient-specific parameters, and the at least one treatment class is determined based on the patient-specific parameters. the one or more corresponding first treatment class member cost information,
patient-specific out-of-pocket costs corresponding to each corresponding first treatment class member for a corresponding treatment unit; or patient-specific out-of-pocket costs corresponding to each corresponding first treatment class member for a typical treatment period. estimated total out-of-pocket costs, or patient-specific estimated total out-of-pocket costs corresponding to each corresponding first treatment class member for the remaining term of a health insurance coverage plan associated with said patient; 15. The computing device of claim 14, comprising one or more of: Upon receiving the second EHR sub-block, the method includes:
determining payment support information for at least one of the one or more second treatments;
15. The computing device of claim 14, further comprising: transmitting the payment assistance information with a transaction confirmation to a patient. a non-transitory computer-readable medium containing executable instructions, the executable instructions causing 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 a patient and one or two including and receiving patient health insurance coverage information regarding the one or more first treatments;
In response to the first EHR sub-block, transmitting at least one encrypted first device drug information (DIR) sub-block decryptable by at least one corresponding second entity; , the at least one first DIR subblock being associated with a corresponding first treatment class and each corresponding first treatment class for each of the one or more first treatments. including and transmitting one or more corresponding first treatment class members and, for each first treatment class member, corresponding first treatment class member cost information;
receiving an encrypted second EHR sub-block decryptable by the first entity in response to the first DIR sub-block, the second EHR sub-block comprising one or two or more second treatments, each of said one or more second treatments being associated with a corresponding first treatment, and each second treatment being associated with said corresponding first treatment. receiving, selected from said corresponding first treatment class member associated with a treatment of;
In response to a transaction confirmation, extending a multidimensional blockchain, the multidimensional blockchain including a DIR block containing information associated with the one or more second treatments; extended with a multidimensional block formed by linking an EHR block that includes information associated with a second EHR sub-block and a transaction block. , a non-transitory computer-readable medium.

Images