基于块链的医疗保健安全性和互操作性
文献发布时间:2023-06-19 12:19:35
技术领域
本文所公开的主题涉及医疗保健系统的安全性和医疗保健系统的互操作性。
背景技术
医疗保健信息系统面临限制互操作性的合规性挑战。例如,所存储的信息可受制于各种隐私法规,诸如《健康保险隐私及责任法案》(HIPAA)。HIPAA规定的隐私条款确立了在以电子方式进行医疗保健交易时保护个人医疗记录和其他个人健康信息的国家标准。这些法规可涵盖隐私(例如,哪些实体可以访问信息)、内容(被授权实体可以访问哪些信息)、安全性(在存储时以及在电子通信期间如何保护信息使其免于被未授权实体访问)和完整性(信息的准确性和真实性)。此外,具有商业价值的信息可受到组织政策的保护,该组织政策可限制与第三方共享信息(例如,作为商业秘密和/或出于业务或商业原因)。法规诸如欧盟《通用数据保护条例》也可影响信息收集、存储、共享和通信。这些法规已经影响了医疗保健市场参与者可用的信息,并且导致产生组织“数据孤岛(data silos)”,其中实体可获得的信息是孤立的,即使当其在系统上可能是有用的(例如,对于另一个非竞争性实体)时。信息的这种划分已导致系统成本增加(例如,由医疗提供者考虑治疗替代方案的成本)、患者风险增加(例如,由于药物相互作用、处方滥用等),以及基于结果的医学治疗或补救方法的疗效受到限制(例如,使确定何时已实现期望结果或比较实现类似结果的方法中的指标更加困难和昂贵)。因此,需要解决上述问题中的一个或多个问题的方法,这些方法将帮助有利于医疗保健信息的安全性同时提高市场参与者之间的互操作性。
发明内容
在一些实施方案中,处理器实现的方法可包括:响应于在第一时间进行的交易,在第一实体处从一个或多个第二实体接收与所述交易有关的加密信息块,其中从不同的第二实体接收每个加密信息块,并且每个加密信息块包括能够由所述第一实体解密的至少一个子块;由所述第一实体解密所述能够解密的子块;由所述第一实体增强多维块链,其中用多维块来增强所述多维块链,通过将从所述一个或多个第二实体接收的所述加密信息块中的至少一个加密信息块链接到当前块来形成所述多维块,所述当前块被添加到与所述交易相关联并且由所述第一实体维护的块链;以及使得所述一个或多个第二实体中的至少一个第二实体能够访问所述多维块链。
在另一方面,用于第一实体的服务器可包括:存储器、通信接口和耦合到所述存储器和所述通信接口的处理器。在一些实施方案中,所述处理器可被配置为:响应于在第一时间进行的交易,在所述第一实体处通过所述通信接口从一个或多个第二实体接收与所述交易有关的加密信息块,其中从不同的第二实体接收每个加密信息块,并且每个加密信息块包括能够由所述第一实体解密的至少一个子块;由所述第一实体解密所述能够解密的子块;由所述第一实体增强驻留在所述存储器中的多维块链,其中用多维块来增强所述多维块链,通过将从所述一个或多个第二实体接收的所述加密信息块中的至少一个加密信息块链接到当前块来形成所述多维块,所述当前块被添加到与所述交易相关联并且由所述第一实体维护的块链;以及使得所述一个或多个第二实体中的至少一个第二实体能够访问所述多维块链。
在另一方面,一种装置可包括:用于响应于在第一时间进行的交易而在第一实体处从一个或多个第二实体接收与所述交易有关的加密信息块的装置,其中从不同的第二实体接收每个加密信息块,并且每个加密信息块包括能够由所述第一实体解密的至少一个子块;用于由所述第一实体解密所述能够解密的子块的装置;用于由所述第一实体增强多维块链的装置,其中用多维块来增强所述多维块链,通过将从所述一个或多个第二实体接收的所述加密信息块中的至少一个加密信息块链接到当前块来形成所述多维块,所述当前块被添加到与所述交易相关联并且由所述第一实体维护的块链;以及用于使得所述一个或多个第二实体中的至少一个第二实体能够访问所述多维块链的装置。
在一些实施方案中,非暂态计算机可读介质可包括可执行指令,以将处理器配置为:响应于在第一时间进行的交易,在所述第一实体处通过所述通信接口从一个或多个第二实体接收与所述交易有关的加密信息块,其中从不同的第二实体接收每个加密信息块,并且每个加密信息块包括能够由所述第一实体解密的至少一个子块;由所述第一实体解密所述能够解密的子块;由所述第一实体增强驻留在所述存储器中的多维块链,其中用多维块来增强所述多维块链,通过将从所述一个或多个第二实体接收的所述加密信息块中的至少一个加密信息块链接到当前块来形成所述多维块,所述当前块被添加到与所述交易相关联并且由所述第一实体维护的块链;以及使得所述一个或多个第二实体中的至少一个第二实体能够访问所述多维块链。
所公开的方法可由一个或多个计算机(包括服务器、基于云的系统等)使用计算机可读介质或计算机可读存储器来执行。
附图说明
本发明的实施方案将仅以举例的方式结合附图来进行描述。
图1A示出了示出常规医疗保健信息系统操作的示意性框图。
图1B示出了与传统块链系统相关联的合约的常规具体实施。
图2示出了示例性电子健康记录(EHR),其示出了记录中的一些示例性数据字段。
图3示出了示例性药物信息记录(DIR)。
图4示出了示例性健康交易记录(HTR)。
图5A示出了包括多个子块的示例性HTR信息块。
图5B示出了描绘与信息块相关联的一些子块的EHR信息块、DIR信息块和HTR信息块。
图6A示出了与多维块相关联的交易流。
图6B示出了与多维块链相关联的示例性默克尔(Merkle)树,该多维块链包括多个数据记录,该多个数据记录可与不同的各个块链相关联。
图6C示出了有利于医疗保健信息的安全性和互操作性的系统的示例性架构。
图6D是可与示例性基于自动结果的合约履行相关联的多维块的视觉描绘。
图7示出了有利于医疗保健信息的安全性和互操作性的示例性方法的流程图。
图8示出了与智能合约层相关联的智能合约。
图9示出了能够有利于医疗保健系统的安全性并提高互操作性的示例性计算机。
具体实施方式
本发明所公开的实施方案有利于医疗保健系统的安全性,同时提高医疗保健系统的完整性和互操作性。
图1A示出了示出常规医疗保健信息系统100的操作的示意性框图。医疗保健交易可涉及若干实体,其中每个实体可具有与交易相关的一些信息,这些信息可用于完成该交易。因此,在常规系统中,可在交易实体之间交换一些有限的信息以便完成交易。如本文所用,术语“实体”可指可代表个体/群组/组织参与医疗保健市场的个体(诸如,患者或患者群组)/组织或参与医疗保健市场的参与者和/或与该个体/群组/组织相关联的计算系统和信息系统(例如,硬件和/或软件)。例如,与一个实体相关联的计算系统可处理信息和/或与和其他实体相关联的计算系统交换信息。实体之间的信息交换可通过安全通信网络和/或通过互联网以安全方式(例如,使用加密的方式)进行。
实体诸如患者(图1中未示出)可从另一个实体诸如医疗保健提供者(HCP)120寻求对困扰该患者的医学病症的治疗。基于可由HCP 120维护(或由HCP 120从患者获得)的患者的健康信息125,HCP 120可确定患者保险和治疗信息124。如图1所示,HCP 120可将患者保险和治疗信息124发送给付款方/保险公司(以下称为“付款方”)140。保险相关和治疗信息124可包括患者身份(ID)信息、保险计划信息、建议治疗的群组ID信息等。然而,患者保险和治疗信息124可不包括可能与覆盖范围和/或成本确定无关的患者家族史和/或其他患者信息,并且/或者可被(例如,法规)阻止与付款方140共享。
付款方140可将所接收的保险相关信息124与计划/覆盖范围数据库145中的信息进行比较,以确定针对患者的覆盖范围。基于覆盖范围信息,付款方140可更新交易信息数据库147,并将患者覆盖范围相关信息142提供给HCP 120。覆盖范围相关信息可包括批准/拒绝信息、与建议治疗相关的覆盖范围信息,以及与成本和付款相关信息,诸如患者共付额、账单代码等。如果付款方拒绝批准,或对于建议治疗的覆盖范围不足和/或不符合患者的成本标准,则HCP可提出修订,这可导致HCP 120和付款方140之间信息的进一步交换。
此外,当开具建议治疗的处方时,HCP 120还可将治疗信息123发送给药物提供者和/或医疗设备提供者(PMDP)130。治疗信息123可包括与困扰患者的医学病症、患者正在使用的其他药品相关的信息。然而,治疗信息123可不包括与患者相关的任何个人可识别信息(PII)。作为响应,PMDP130可将药物/设备概述和安全性信息132发送给HCP 120。药物/设备概述和安全性信息可包括关于药物特性的信息,诸如剂量、给药模式、吸收、代谢、作用持续时间、毒性以及与食物或其他药品的相互作用。在接收到药物/设备概述和安全性信息132时,HCP可开具药物和/或医疗设备,或者可基于药物/设备概述和安全信息132修订处方。HCP 120、付款方140和PMDP130之间的交互可继续,直到HCP 120完成以下治疗计划:(a)患者可接受的,(b)满足安全性和疗效考虑,以及(c)可由付款方140覆盖和/或批准的。
因此,常规的医疗保健信息系统具有若干缺点。虽然每个实体获取并维护可能与经营其业务相关的信息,但该信息中只有极少的信息被共享(例如,由于法律、隐私和/或业务考虑),并且当共享信息时,该信息通常是零碎的、没有上下文并且可能是不可用的。例如,HCP 120可能不向PMDP 130提供药物不良反应的细节。又如,当HCP 120向PMDP 130提供药物不良反应信息时,该信息可不包括非PII人口统计信息(例如,患者的年龄、位置、医学病症等),因此该信息可能对PMDP 130具有有限价值。此外,在一些情况下,当实体(例如,患者)报告药物不良反应时,药物不良反应可由另一个实体(例如,HCP 120)验证以确定该不良事件是否可归因于处方药物。验证(其可涉及附加实体)可引入额外的复杂性,这可进一步延迟报告和/或产生额外的孤岛,从而进一步限制信息的实用性(例如,对于PMDP 130而言)。
此外,因为信息被划分并且可在临时的基础上提供,所以将所接收的信息与由接收实体存储的信息聚合可能是麻烦的。此外,因为每个实体可以不同方式索引信息,所以接收实体(或发送实体)可能难以或不可能将所接收的(或所发送的)信息绑定到所传输的信息的起源处的(例如,由发送实体存储的)所记录的信息。例如,如果HCP 120在某个时间点向PMDP 130提供药物不良反应信息,则即使当该信息可合法地共享时,HCP 120和/或PMDP130也可能难以获取与药物不良反应有关的附加的患者或患者医学病症信息。例如,信息的划分可阻止或限制PMDP 130进行访问以聚合可用于定制药物利用的人口统计信息。又如,在制定出处方或治疗计划时,患者或HCP 120可能无法获得各种治疗替代方案的成本。又如,HCP 120和/或付款方140可能难以确定患者滥用处方。
许多现代机器学习(ML)和其他人工智能(AI)系统可处理大量数据以确定危害,识别可导致期望结果的模式等,这可使得效率提高、成本降低和/或结果更好。信息的孤岛化和划分还限制了此类ML和AI技术的适用性,从而导致效率低下。
对提高医疗保健递送的效率的一些尝试集中于基于结果的方法。付款方140可能将报销与一些约定结果的实现相关联。例如,基于结果的合约可指定:HCP 120将基于患者血压在某个时间段内降低到某个限定范围而以某个约定的费率报销。在常规系统中,跟踪和管理此类基于结果的合约可能是非常困难的,因为HCP 120和付款方140之间可能需要进行若干次信息交换,其中每次交换都符合法律、规章、隐私和业务相关指导原则。
图1B示出了与传统块链系统相关联的合约的常规具体实施。如图1B所示,程序代码可实现实体A 163和实体B 165之间的合约156。在常规系统中,信息可在实体A 163和实体B 165之间单独交换(例如,如上文相对于图1A所概述的),然后与合约156相关联的程序代码可使用这些信息来实现该合约。常规具体实施具有若干缺点。首先,在常规具体实施中,与合约156相关联的程序代码可绑定到实体(例如,实体A 163),因此可不用于实现与其他实体(例如,不涉及实体A)相关的其他合约。
此外,在常规系统中,与合约相关联的程序代码特定于与合约相关联的两个实体。因此,如果另一个实体诸如实体C 167将与合约156相关联,则在常规系统中,通常添加与以下项相关联的附加代码以涉及实体C167:(a)附录1152(以反映实体A 163和实体C 167之间的交互,和(b)附录2154(以反映实体B 165和实体D 169之间的交互)。因此,随着与合约相关联的实体数量的增加,系统的复杂性急剧增加,从而增加合约管理成本(编码成本、维护成本等),同时还增加错误的可能性,并且使合约变更难以实现或不切实际。此外,因为信息在实体之间外部共享,所以错误和/或数据不一致的可能性大大增加。此外,在合约与实体的多个实例(例如,与HCP相关联的正针对某种病症进行治疗的数百个患者)一起使用的许多常规系统中,该合约通常在这些实例之间重复。因此,合约变更(例如,指示批准新药物来治疗病症)可能不容易,并且可能需要花费很长的时间来在该系统中传播,从而限制了平台的实用性。在上述情况下,手动批准或手动干预往往是常态,从而否定了合约管理平台的优点。虽然使用块链来存储健康相关信息可有利于确保所存储信息的完整性和真实性,但常规技术不解决信息划分、复杂性的问题,或者不确保不同实体具有所存储交易的相干且一致的视图而不有利于互操作性。
本发明所公开的实施方案有利于医疗保健系统的安全性,同时提高医疗保健系统的完整性和互操作性。一些所公开的技术有利于(例如,在交易时)将适当的数据(例如,符合法律、隐私和业务指导原则)及时交换到适当的实体(例如,与交易相关联的被授权实体),同时有利于跨医疗保健市场实体的信息的一致且相干的视图。有利于互操作性的部分原因是,与交易相关联的多个实体可能够使用约定的参考将该交易期间共享的信息绑定到该交易。有利于一致性和相干性的原因是,本地记录的数据可对应于参考数据并且每个实体的参考数据视图(或参考数据的能够被实体查看的部分)与另一个被授权实体的数据视图一致。在一些实施方案中,参考数据可基于分散式账本和/或采用分散式账本的形式。在一些实施方案中,分散式账本可被授权实体访问,并且每个实体的分散式账本的视图可符合法律、隐私、业务和/或合约义务。
在一些实施方案中,响应于在第一时间进行的交易,第一实体(例如,药物提供者)可从一个或多个第二实体(例如,医疗保健提供者和/或保险提供者和/或患者)接收与交易有关的加密信息块。可以从不同的第二实体接收每个加密信息块,并且每个加密信息块可包括能够由该第一实体解密的至少一个子块。第一实体(例如,药物提供者)可解密所接收的能够解密的子块中的一个或多个子块。在一些实施方案中,第一实体还可用多维块增强多维块链。可通过将从该一个或多个第二实体接收到的加密信息块中的至少一个加密信息块链接到添加到块链的当前块来形成多维块,该块链与其中该块链由第一实体维护的交易相关联。第一实体(例如,药物提供者)可使得至少一个第二实体(例如,医疗保健提供者和/或保险提供者和/或患者)能够访问多维块链。
能够由第一实体解密的(在所接收的加密块中的)子块可包括或指向可由第一实体查看的信息(例如,符合法律、隐私和/或业务指导原则)。相反地,能够解密的子块之外的信息可能无法由第一实体(例如,药物提供者)查看,但是可能可由传输对应加密块的第二实体(例如,医疗保健提供者)获得。此外,由第一实体接收到的每个加密块可:(i)与交易相关,并且/或者(ii)形成由传输对应加密块的第二实体(例如,医疗保健提供者)维护的对应块链的一部分。在一些实施方案中,被添加到由第一实体维护的块链的当前块还可包括子块,每个子块具有能够由对应的第二实体解密的信息,而对应的子块之外的信息可能无法由第二实体查看。术语“子块”指示数据记录或可由一个或多个特定实体解密的块的一部分。因此,交易的相干且一致的视图可由市场实体获得,同时保持符合法律、隐私和/或其他法规和业务考虑并提高数据完整性。
如本文所用,术语“块链”是指记录或“信息块”或“块”的可增长列表,其中块使用加密技术进行链接。每个块包括先前块的加密散列、时间戳和交易数据。被添加到块链的当前块也被称为块链的头部。加密散列函数将任意大小的数据映射到固定大小的位串,这被称为“散列”。散列函数可以是确定性的(相同的输入将产生相同的输出),并且可以是无法反转(即,从散列值确定原始数据输入)的单向函数。块的交易数据可表示为默克尔树根散列。术语“默克尔树”或“散列树”用于指树,其中每个叶节点用交易数据的散列进行标记,并且每个非叶节点用与其子节点相关联的标记的加密散列进行标记。要添加到块链的块的块标头可包括对先前块标头的散列引用和对包含交易数据的默克尔树的根的散列引用。块链提高了数据完整性,因为对块链中的数据的改变导致散列引用中的一个或多个散列引用的不一致。术语“记录”或“数据记录”还用于指示要添加到块链的非最终数据。一旦已验证并完成数据记录,就可将该数据记录添加到块链并在该块链中形成块。
术语“多维块链”用于指多维记录(也称为多维块)的序列,其中每个多维记录包括两个或更多个数据记录。在一些情况下,形成多维块链的维度的数据记录中的每个数据记录可在与某个实体相关联的不同块链中形成块。因此,在一些实施方案中,多维块可包括每个维度中的数据记录,其中对应于维度的数据记录可在与对应实体相关联的不同常规块链中形成块。例如,多维块可包括作为一个维度的EHR数据记录、作为另一个维度的DIR数据记录以及作为第三维度的交易数据记录。此外,在一些情况下,与(在多维块链中的)多维块相关联的EHR数据记录可在不同EHR块链(即,与多维块链不同)中单独形成块。类似地,在一些情况下,与多维块相关联的DIR数据记录和交易数据记录可各自分别在不同DIR块链(例如,与PMDP 130相关联)和交易记录块链(例如,与付款方140相关联)中形成块。因此,在一些情况下,多维块链的上下文中的数据记录可对应于不同常规块链中的块。在一些情况下,多维块中的每个数据记录(例如,与维度相关联)可对应于不同的常规块链中的对应块、形成该对应块的一部分和/或来源于该对应块。多维块可包括先前多维块的加密散列、时间戳和数据。多维块的数据可包括构成多维块的各个数据记录的散列。在一些实施方案中,在多维块被提交和锁定之前,可使用实体之间的共识机制来确认所提出的多维块中的数据的正确性。
因此,多维块可包括两个或更多个加密数据记录,其中每个加密数据记录可与不同的实体相关联(例如,在医疗保健市场中)。如上所述,多维块中的数据记录可在不同块链中单独形成块,其中块链中的每个块链可与不同的实体相关联。每个加密数据记录可能够由对应的相关联实体(例如,数据记录所有者)解密。此外,加密数据记录可包括可能够由除了加密数据记录所有者之外的至少一个其他特定实体解密(或可能已能够由至少一个其他特定实体解密)的部分(称为“子块”)。例如,在形成对应多维块时,子块可能已能够由(除了数据记录所有者之外的)至少一个其他不同的实体解密。在一些实施方案中,在多维块形成时,子块可被单独加密,并且使得其连同用于解密这些子块的信息可由另一个实体获得。因此,多维块可有利于交易数据对于与医疗保健市场相关联的多个实体的可用性,同时向被授权市场实体提供数据的相干且一致的视图,符合法规、业务指导原则和/或合约义务,并且提高数据完整性。实体还可确保与本地维护的块链中的对应块的数据相关性(例如,与多维块链中的多维块的维度相关联的记录的数据相关性)。在实施方案中,当使用子块在两个实体之间交换信息时,经由能够解密的子块交换的信息可基于这两个实体之间的信息接口。在一些实施方案中,当交换信息时(例如,在多维块形成时),每个实体可加密与由实体维护的本地块链相关联的块,同时生成能够由其他实体解密的子块。信息接口可基于与块链相关联的智能合约。
术语“智能合约”用于指与块链或块链平台相关联的程序代码或逻辑。“智能合约”可编码两个或更多个实体之间与数据共享、交易、访问、合约履行等相关的规则或协议。智能合约可基于两个或更多个实体之间的合约和/或与多维块链平台相关的协议。例如,与多维块链相关联的“智能合约”程序代码可处理交易请求并基于程序逻辑来确定交易的有效性。
图2示出了EHR 200,其示出了记录中的一些示例性数据字段。在一些实施方案中,EHR 200可包括关于患者的信息。EHR 200中所示的字段仅为示例性的,并且EHR 200可包括基于法律、标准、HCP和/或行业惯例等的各种其他附加字段。EHR可包括与相对于示例性EHR200所示的那些字段不同(比那些字段更少或更多)的字段。
例如,如图2所示,EHR 200可包括关于患者的基本资料信息230,其变化可相对较少。基本资料信息230可包括家族史205、出生日期(DOB)220、血型225等。家族史205可包括母亲史210和父亲史215。在一些实施方案中,EHR200可由HCP 120基于来自患者的信息进行创建和/或维护。
EHR 200还可包括其他数据字段,诸如诊断235(例如,针对当前疾病)、诊断代码240(其可以是针对诊断的标准化代码(诸如国际疾病分类(ICD)代码))、治疗代码245(其可以是用于描述治疗的标准化代码(例如,诸如当前程序术语(CPT)代码))、针对任何处方的处方代码250等。处方代码250还可包括药物255(例如,药物名称)、剂量260(强度和频率)和持续时间265(待服用药物的时间长度)。在一些情况下,EHR 200还可包括其他字段和/或子字段,诸如对处方是新处方还是重新配药的指示。
在一些实施方案中,患者的EHR 200可例如由HCP 120存储为块链,并且HCP 120和患者之间的每个交易可形成EHR块链中的EHR信息块的一部分。在下面的描述中,当EHR被维护为块链时,那么EHR信息记录200也可被称为EHR块200。EHR块200可因此形成EHR块链中的块。当要将EHR块200添加到EHR块链时,被添加到EHR块链的EHR块200中的数据中的一些可取决于其他实体。例如,针对诊断的治疗代码245可能需要来自付款方140的批准和/或验证(图2中未示出)。又如,可形成EHR块200的一部分的药物警告标记(图2中未示出)可在EHR块200被添加到EHR块链之前使用来自PMDP 130和/或付款方140的输入和/或批准。
在一些实施方案中,诊断235、诊断代码240、治疗代码245、处方代码250连同数据字段药物255、剂量260和持续时间265可用于形成子块280。子块280仅为示出可与另一个特定实体共享的一些信息的示例。一般来讲,用于根据本地维护的块链(例如,EHR块链)中的数据记录或块形成子块的信息可取决于法规(例如,医疗保健和/或隐私法规)、管理信息共享(确定实体能够共享或不能够共享的信息)的法律、业务指导原则(例如,商业秘密或敏感信息)和/或合约义务(例如,共享信息的实体之间或与共享信息的实体相关)。在一些实施方案中,子块280中的数据可由实体诸如HCP 120与另一个医疗保健市场实体诸如付款方140共享以完成交易。然而,与基本资料信息230相关联的患者资料信息可被认为是私有的(例如,基于法律、隐私和/或业务指导原则),并且第一实体(例如,HCP 120)可能不希望共享基本资料信息230,或者可能希望限制基本资料信息230的共享部分。
因此,在一些实施方案中,用于形成子块280的数据可被单独加密。在一些实施方案中,对形成子块280的数据的加密可基于任何适当的加密方法,包括对称密钥加密技术(其中实体诸如HCP 120和付款方140共享秘密密钥),诸如基于高级加密标准(AES)的技术或其变型。子块280可在与另一个实体(例如,付款方140)共享之前被(例如,HCP 120)加密。另一个实体(例如,付款方140)可能够例如使用共享密钥来解密子块280。
此外,EHR 200中的数据也可由HCP 120使用任何安全加密技术单独加密以形成EHR块200。例如,EHR块200中的数据可使用不同的密钥单独加密,使得其能够由HCP 120解密并且可由该HCP获得,但不能由任何其他实体查看。因此,要由第一实体(例如,HCP 120)添加到EHR块链的加密EHR块200可在共享之前被加密,使得:(i)信息的一部分被单独加密(例如,在子块280中)并且能够由另一个实体(例如,付款方140)解密;以及(ii)子块280之外的信息不能由其他实体解密或访问,并对于HCP 120保持为私有的。因此,在一些实施方案中,根据EHR数据记录,可形成的数据元素可包括:(a)加密子块280(例如,在多维块形成时),该加密子块包括字段诊断235、诊断代码240、治疗代码245、处方代码250、药物255、剂量260和持续时间265中的信息,这些信息可能够由某个指定实体解密;和(b)加密EHR块200,其可包括EHR记录中的所有信息(包括存在于子块280内的EHR信息,以及来自子块280之外的EHR信息),并且能够由HCP 120(EHR拥有者)解密而不由任何其他实体解密。
因此,在一些实施方案中,其他实体(例如,付款方140)可能够对子块280中的信息进行解密,但将无法对与EHR块200相关联的加密信息进行解密。在一些实施方案中,来自第一实体(例如,HCP 120)的加密EHR块200可包括可用于形成多个子块的信息,其中每个子块(例如,子块280)可能够由不同的第二实体(例如,付款方140)解密。
图3示出了示例性药物信息记录(DIR)。在一些实施方案中,DIR300可包括关于药物的信息。DIR 300中所示的字段仅为示例性的,并且DIR 300可包括基于法律、标准、行业惯例等的各种其他字段。此外,DIR可包括与相对于示例性DIR 300所示的那些字段不同(比那些字段更少或更多)的字段。
DIR 300可包括各种数据字段,包括处方一览表305,其可列出与治疗类别相关的经批准的处方药物(例如,仿制药物和品牌药物)。例如,针对患者的付款方(诸如付款方140)可涵盖和/或请求使用包括在处方一览表中的药品。DIR 300还可包括各种其他数据字段,包括价格325,其可列出可购得药物的价格(诸如标价或协商价格)。处方一览表305还可包括具有关于付款方的信息的重复付款方-i字段310-i(1≤i≤n)。此外,付款方-i字段310-i中列出的每个付款方可包括关于重复等级j字段310-j(1≤j≤m)中的对应药物等级的信息。药物等级列出了等效药物的各种等级,这可取决于处方一览表和付款方。例如,对于处方一览表305中指定的处方一览表和付款方1310-1中指定的付款方,等级1315-1药物可以是更便宜的仿制药物,而等级2315-2药物可以是更昂贵的仿制药物,并且等级3315-3药物可以是品牌药物。此外,每个等级-j字段310-j可包括重复的指示-k字段310-k(1≤k≤s),该重复指示具有关于其处方一览表已被批准(例如,由监管机构诸如食品与药物管理局(FDA)和/或付款方1310-1批准)使用的医学病症的信息。
此外,如图3所示,DIR 300可包括各种其他字段,这些字段包括疗效327(其可为对医学病症的治疗效果的量度)、安全性330(例如,药物相互作用、毒性、禁忌等)、给药途径335(例如,外用、口服、静脉注射等)、作用机制(MOA)340(其可识别药物通过其诱导药理效应的生物化学相互作用)、副作用345(例如,次级效应)等。
在一些实施方案中,针对患者的DIR 300可由实体诸如PMDP 130存储为DIR块链的一部分。在下面的描述中,当DIR被维护为块链时,那么DIR信息记录300也可被称为DIR块300。DIR块300可因此形成DIR块链中的块。当要将DIR块300添加到DIR块链时,被添加到DIR块链的DIR信息块300中的数据中的一些可取决于由其他实体进行的验证。例如,与付款方1310-1中指定的付款方(例如,付款方140)相关的处方一览表305中的信息可形成DIR块300的一部分并且可取决于在DIR块300被添加到DIR块链之前由付款方(例如,付款方140)进行的验证。
在一些实施方案中,对于在某个时间点进行的交易,可将数据字段处方一览表305中的信息、付款方1310-1、与付款方1310-1中的付款方相关联的等级-j字段310-j中的每个字段中的等级信息、与每个等级j字段相关联的指示-k字段310-k中的每个字段中的信息用于形成字块385。然而,与付款方-i字段310-i(2≤i≤n)中的其他付款方相关的信息可不形成子块385的一部分,因为该信息可能是机密的(例如,在付款方-i(2≤i≤n)中的每个付款方和PMDP 130之间),并且PMDP 130可能不希望并且/或者可能以合约方式被阻止与其他付款方共享与付款方相关的信息。子块385仅为示出可与另一个特定实体共享的一些信息的示例。一般来讲,用于根据本地维护的块链中的数据记录或块(例如,DIR 300)形成子块的信息可取决于法规(例如,医疗保健和/或隐私法规)、管理信息共享(确定实体能够共享或不能够共享的信息)的法律、业务指导原则(例如,商业秘密或敏感信息)和/或合约义务(例如,共享信息的实体之间或与共享信息的实体相关)。
因此,在一些实施方案中,子块385中的数据可被单独加密。在一些实施方案中,在共享之前基于与另一个实体(例如,在付款方1310-1字段中识别的付款方140)共享的秘密密钥,可基于任何适当的加密技术(包括对称密钥加密)来对字块385中的数据加密。另一个实体(例如,付款方140)可能够例如基于共享密钥来解密字块385。
此外,如图3所示,另一个子块380可由DIR 300形成。子块380可包括字段诸如疗效327、安全性330、给药途径335、作用机制(MOA)340、副作用345等。子块380仅为示出可与另一个特定实体共享的一些信息的示例。如上所述,用于根据本地维护的块链中的数据记录或块(例如,DIR 300)形成子块380的信息可取决于法规(例如,医疗保健和/或隐私法规)、管理信息共享(确定实体能够共享或不能够共享的信息)的法律、业务指导原则(例如,商业秘密或敏感信息)和/或合约义务(例如,共享信息的实体之间或与共享信息的实体相关)。子块380可使用与另一个实体(例如,PMDP 130)共享的秘密密钥单独加密。PMDP 130可因此能够使用秘密共享密钥来解密和查看子块380中的信息。
此外,DIR块300中的数据也可由第一实体(例如,PMDP 130)使用任何安全加密技术单独加密,使得该数据能够由第一实体(例如,PMDP130)解密并且可由该第一实体获得,但不能由其他实体(例如,HCP 120和/或付款方140)查看。因此,在一些实施方案中,根据DIR数据记录,可形成的数据元素可包括:(a)加密子块385(例如,在多维块形成时),其包括处方一览表305中的信息、付款方1310-1、与付款方1310-1中的付款方相关联的等级-j字段310-j中的每个字段中的等级信息,以及与每个等级-j字段相关联的指示-k字段310-k中的每个字段中的信息;(b)加密子块380(例如,在多维块形成时),其包括疗效327、安全性330、给药途径335、作用机制(MOA)340、副作用345中的信息;和(c)加密DIR块300,其可包括DIR记录300中的所有信息(包括也存在于子块380和385内的DIR信息,以及来自子块380和385之外的DIR信息),并且能够由PMDP 130(块所有者)解密而不由任何其他实体解密。
因此,可由PMDP 130形成的加密子块380和385可分别能够由HCP120和付款方140解密。此外,PMDP 130可加密DIR块300,使得除PMDP 130之外的实体可能无法查看DIR块300中的信息。在一些实施方案中,来自第一实体(例如,PMDP 130)的加密DIR信息块300可包括可用于形成多个子块(例如,380和385)的信息,其中每个子块可能够由不同的第二实体(例如,分别由HCP 120和付款方140)解密。
图4示出了示例性健康交易记录(HTR)400。如图4所示,HTR 400可包括在某个时间点关于患者的治疗相关信息和成本相关信息。HTR 400中所示的字段仅为示例性的,并且HTR 400可包括基于法律、标准、行业惯例等的各种其他字段。此外,HTR可包括与相对于示例性HTR 400所示的那些字段不同(比那些字段更少或更多)的字段。
在一些实施方案中,HTR 400可由实体诸如付款方140维护。HTR400可包括各种数据字段,包括患者425(例如,患者ID)、成本405,其可表示与交易相关联的成本。成本405可包括付款方成本410(例如,对于付款方140)、药物成本415(例如,处方药物的成本)、HCP成本(由医疗保健提供者承担的成本)和患者成本425。患者成本425可取决于患者共付额430、自掏腰包极限435和自付额440,该自付额可取决于患者的健康保险覆盖范围和患者的先前交易。
在一些实施方案中,HTR 400还可包括各种其他字段,包括诊断445(针对患者的医学病症)、诊断代码450(例如,针对当前医学病症)、治疗代码455(例如,用于描述治疗的CPT代码或另一种标准化代码)、重复字段药物代码460-1、460-2……(其可以是用于识别处方药物的标准化代码),以及规程代码465(其用于描述与医学病症的治疗相关联的医学规程)。
在一些实施方案中,在某个时间点针对患者的HTR 400可由实体诸如付款方140存储为块链。在下面的描述中,当HTR被维护为块链时,那么HTR信息记录400也可被称为HTR块400。HTR块400可因此形成HTR块链中的块。例如,与HCP 120和患者和/或患者和付款方140之间的交易相关的数据可形成HTR块链中的HTR块400的一部分。当要将HTR块400添加到HTR块链时,被添加到HTR块链的HTR块400中的数据中的一些可取决于由其他实体进行的验证。例如,诊断445中的信息可在HTR块400被添加到HTR块链之前由HCP 120验证。
在一些实施方案中,对于某个时间点的交易,数据字段诊断445、诊断代码450、治疗代码455和重复字段药物代码460-1、460-2等中的信息可形成子块485的一部分。子块485可与PMDP 130共享以确定是否批准药物用于所述诊断,以确定安全性(例如,药物相互作用)等。
在一些实施方案中,字段患者ID 425和共付额430中的信息可用于形成另一个字块480。子块480可与HCP 120共享,并且可有利于确定关于交易的共付额信息。子块480和485仅为用于示出可由付款方140与特定实体共享的信息的示例。一般来讲,用于根据本地维护的块链中的数据记录或块(例如,HTR 400)形成子块的信息可取决于法规(例如,医疗保健和/或隐私法规)、管理信息共享(确定实体能够共享或不能够共享的信息)的法律、业务指导原则(例如,商业秘密或敏感信息)和/或合约义务(例如,共享信息的实体之间或与共享信息的实体相关)。
因此,在一些实施方案中,子块480和485中的数据可被单独加密。在一些实施方案中,在共享之前基于与PMDP 130共享的秘密密钥,可基于任何适当的加密技术(包括对称密钥加密)来对子块485中的数据加密。PMDP 130可能够基于PMDP 130和付款方140之间共享的秘密密钥来解密子块485。此外,可基于与HCP 120共享的不同秘密密钥对子块480进行单独加密。HCP 120可能够使用HCP 120和付款方140之间共享的秘密密钥解密和查看子块480中的信息。此外,HTR信息块400中的数据也可由第一实体(例如,付款方140)使用任何安全加密技术单独加密,使得该数据可能够由付款方140解密并且可由该付款方获得,但不能由HCP120和/或PMDP 130查看。
因此,在一些实施方案中,根据HTR数据记录,可形成的数据元素可包括:(a)加密子块480(例如,在多维块形成时),其包括字段患者ID425和共付额430中的信息;(b)加密子块485(例如,在多维块形成时),其包括字段诊断445、诊断代码450、治疗代码455和重复字段药物代码460-1、460-2中的信息;以及(c)加密HTR块400,其可包括HTR记录400中的所有信息(包括也存在于子块480和485内的HTR信息,以及来自子块480和485之外的HTR信息),并且能够由付款方140(HTR块所有者)解密而不由任何其他实体解密。因此,在一些实施方案中,来自第一实体(例如,付款方140)的加密HTR信息块400可包括可用于形成多个子块(例如,480和485)的信息,其中每个子块可能够由不同的第二实体(例如,分别由HCP 120和PMDP 130)解密。
图5A示出了包括子块480和485的示例性HTR信息块540。EHR信息块540可被添加到由第一实体诸如付款方140维护的EHR块链545。在一些实施方案中,块540可由付款方140加密,使得其可由付款方140解密和读取(但不由其他实体解密和读取)。
在一些实施方案中,EHR信息块540中的子块480可由付款方140基于与另一个实体诸如HCP 120的秘密共享密钥使用对称密钥加密来加密。HCP 120可使用共享密钥来解密子块480。然而,HCP 120可能不能够解密子块480之外的块540中的信息。
此外,HTR信息块540中的子块485可由付款方140基于与附加实体诸如PMDP 130的秘密共享密钥使用对称密钥加密来加密。PMDP 130可使用共享密钥来解密子块485。然而,PMDP 130可能不能够解密子块485之外的块540中的信息。
图5B示出了描绘与信息块相关联的一些子块的EHR信息块520、DIR信息块520和HTR信息块540。
如图5B所示,被添加到由付款方140维护的HTR块链545的当前信息块540可包括可用于形成子块480和485的信息。如上所述,子块480可能够由HCP 120解密,而子块485可能够由PMDP 130解密。同样如上所述,块540可由付款方140单独加密,并且可能不能够由除付款方140之外的实体解密(例如,以符合法律、隐私、合约和/或业务指导原则)。
如图5B所示,示例性EHR信息块520可包括可用于形成子块280的信息。可将EHR信息块520添加到由HCP 120维护的EHR块链525中。在一些实施方案中,EHR信息块540中的子块280可基于与第一实体付款方140的秘密共享密钥使用对称密钥加密(例如,由HCP 120)来加密。付款方140可使用共享密钥来解密子块280。如上所述,HCP 120还可使用与付款方140共享的秘密密钥来解密子块480。此外,块520中的信息可由HCP120单独加密,并且该信息可能不能够由HCP 120之外的其他实体解密(例如,以符合法律、隐私、合约和/或业务指导原则)。
此外,如图5B所示,示例性DIR信息块530可包括子块385。DIR信息块530可被添加到由另一个第二实体诸如PMDP 130维护的DIR块链535。在一些实施方案中,DIR信息块530中的子块385可由PMDP 130基于与付款方140的秘密共享密钥使用对称密钥加密来加密。付款方140可使用共享密钥来解密子块385。PMDP 130还可使用与付款方140共享的秘密密钥来解密子块485。此外,块530中的信息可由PMDP 130单独加密,并且该信息可能不能够由PMDP 130之外的其他实体解密(例如,以符合法律、隐私、合约和/或业务指导原则)。
在图5B中,付款方140和HCP 120之间的信息接口524可包括使用子块460和280共享的信息。因此,HCP 120和付款方140两者都可解密两个实体(HCP 120和付款方140)之间的信息接口(例如,信息接口524)中的信息。类似地,第一实体付款方140和第二实体PMDP130之间的信息接口534可包括使用子块385和485共享的信息,并且信息接口534中的信息可由PMDP 130和付款方140两者解密。
图6A示出了与多维块相关联的交易流600。图6A仅为示例性的,并且为了便于解释,概述了与块540相关联的交易流中的两个实体之间的一些步骤。获得多维块的附加步骤可遵循类似的模式。在图6A中,所示的子块和所述的字段仅为示例,以示出可共享的处理流程和信息。一般来讲,用于根据本地维护的块链中的数据记录或块形成子块的信息可取决于法规(例如,医疗保健和/或隐私法规)、管理信息共享(确定实体能够共享或不能够共享的信息)的法律、业务指导原则(例如,商业秘密或敏感信息)和/或合约义务(例如,共享信息的实体之间或与共享信息的实体相关)。当已验证并完成数据记录时,可将最终的数据记录作为块添加到本地块链。
图6A示出了HTR块链545,其可由第一实体诸如付款方140维护。在图6A中,数据记录540将被添加到块链545。图6A还示出了当前在块链的头部处具有记录520的EHR块链525和当前在块链的头部处具有记录530的DIR块链535。在一些实施方案中,块链525和535可分别由第二实体HCP 120和PMDP 130维护(图6A中未示出)。在一些实施方案中,在提交交易请求时,可提交来自每个块链的最新块以形成多维块链。
在一些实施方案中,由对应实体(例如,分别地,HCP 120、PMDP130或付款方140中的一者)(该对应实体包括来自另一个实体的信息和/或涉及其他实体)对传统块链(例如,块链525、535或545中的一者)进行的更新可在提交之前由一个或多个其他实体验证(例如,在块链525、535或545中和/或在相关联的多维块链中本地地进行)。在一些实施方案中,与信息块520、530和/或540相关联的每个字段可具有唯一的全局字段id,当与字段有关的信息在实体之间共享时,该全局字段id可唯一地标识多维块链系统和/或相关实体的该字段。
在一些实施方案中,当要将记录诸如记录540添加到由实体维护的块链时,该实体(例如,付款方140)可将交易请求发送到相关实体(例如,HCP 120和/或PMDP 130)。在一些实施方案中,交易请求可被放置在请求池中。在一些实施方案中,各种实体HCP 120、PMDP130、付款方140等可形成许可块链平台的一部分。在许可块链平台中,信任实体可形成平台并邀请其他信任实体加入网络。在一些实施方案中,许可块链平台也可以是私有的。在一些实施方案中,许可块链平台可支持多维块链。可通过与许可块链平台相关联的实体来确定与访问多维块链并将块添加到多维块链、用于确定实体之间的合约(例如,智能合约)的程序代码、更新的验证等有关的规则。
如果付款方140被授权访问平台并对平台进行更新,则在一些实施方案中,当要添加数据记录540时,付款方140可使字块480分叉并加密该字块,在一些情况下,该字块可包括来自数据记录540的一部分的信息。然后可由HCP 120解密和读取子块480中的信息。在一些实施方案中,对称加密算法可用于加密子块480。
如上所述,在下面的描述中,为了便于解释,首先认为两个数据记录520和540分别来自块链525和545。如图6A所示,分叉动作605可使数据记录540分叉并形成分叉子块480。在一些实施方案中,叉开动作605可用作发起多维块形成的触发器。子块分叉动作可包括本地块链的数据记录或块中的数据的一些子集的复制和加密(例如,使用与另一个实体共享的秘密密钥)以形成子块(例如,子块480)。在一些实施方案中,子块可在存储器中复制。例如,子块可驻留在用于形成多维块(例如,多维块610)的存储器中。存储器中的子块复制可促进复制对象的速度、存储和完全移除(例如,当多维块形成已完成时)。与原始本地块(例如,本地块540)相关联的信息不受分叉动作(例如,分叉动作605)的影响。
例如,分叉605可导致子块480被复制、被从块480分割并被单独加密。加密密钥可与HCP 120共享并且可采取授权代码的形式,并且/或者作为授权代码的一部分被包括,该授权代码通过安全信道从第一实体(付款方140)发送到第二实体(HCP 120)。HCP 120可使用从付款方140接收的授权代码来解密子块480。在一些实施方案中,子块480可在存储器中复制。存储器中的子块复制可促进复制对象的速度、存储和完全移除(例如,当多维块形成已完成时)。
此外,如图6A所示,当HCP 120提交数据记录520时,分叉动作607也可使数据记录520分叉并形成分叉子块280。在一些实施方案中,分叉动作607可导致子块280被复制、被从数据记录520分割并被单独加密。加密密钥可与付款方140共享并且可采取授权代码的形式,并且/或者作为授权代码的一部分被包括,该授权代码通过安全信道从HCP 120发送到付款方140。付款方140可使用从HCP 120接收的授权代码来解密子块280。
在一些实施方案中,在验证之后,可将形成数据记录520和540之间的信息接口的子块280和480中的信息结合到记录520和/或540中(例如,通过在记录520和/或540中的适当字段中填充和/或更新)。例如,HCP 120可在解密和读取子块480时获得共付额230和患者ID 425。类似地,付款方140可在解密和读取子块480时获得诊断代码240、治疗代码245、处方代码等。然而,块520中子块280之外的信息可对于HCP 120保持为私有的。类似地,块540中子块480之外的信息可对于付款方140保持为私有的。如前所述,实体之间的信息接口可取决于法律(例如,隐私、数据共享、医疗保健、商业、竞争)、实体之间的合约义务(例如,由实体输入的)和/或业务考虑(例如,商业秘密等)。因此,上述示例仅为示例性的,并且在数据记录、块和子块中共享和/或包括的实际数据可与这些示例不同。
在一些实施方案中,可验证子块480和/或280中的信息,并且在成功验证之后,可链接更新的数据记录520和更新的数据记录540以获得解锁的多维块610。在一些实施方案中,更新的记录520和540以及多维块610可在该阶段以解锁形式(尚未提交给任何块链)保留。术语“解锁”用于指示多维块610中的信息并非最终版本,并且可随着交易进行到完成而发生改变。例如,如果确定子块480和/或280中的信息不正确或无效(如下面进一步所述),则可拒绝交易。在一些实施方案中,更新的记录520和/或540可在链接之后重新散列。多维块(解锁或锁定的多维块)可包括数据和时间戳。数据可包括数据记录520、530和/或540。时间戳确定多维块(一旦验证并完成)链接的顺序。
在一些实施方案中,HCP 120和/或付款方140和/或与块链相关联的其他被授权实体可确定已解密子块中的信息是否分别对应于与块520和/或540相关联的信息。共识技术可确认构成多维块的交易的正确性。在一些实施方案中,可使用共识技术诸如拜占庭容错(BFT)或其变型诸如冗余BFT或一些其他基于投票的共识技术来确定是否可使用块520和540来形成多维块610。当被授权实体(例如,付款方140)或一些指定数量(例如,大多数)的实体验证了交易或块时,则达成共识。
如果共识技术确认交易正确,则可形成(解锁的)多维块610的第一实例。另一方面,如果例如在字块480中的患者ID 425中识别的患者与患者ID不匹配(例如,在字块280中),则可认为交易不正确,并且可拒绝块添加请求。在一些实施方案中,平台或每个实体可维护拒绝交易的日志以用于可追溯性和调试目的。日志可指示与交易拒绝相关联的原因或代码。
在一些实施方案中,共识层可包括共识技术,并且可与智能合约层进行交互以建立交易正确性和/或有效性。在一些实施方案中,由对应实体(例如,HCP 120、PMDP 130或付款方140)对传统块链(例如,块链200、300或400中的一者)进行的每个更新可由与多维块链相关联的智能合约程序代码来验证。智能合约程序代码可反映实体之间与数据共享、认证、支付等相关的协议。智能合约层可被视为在无需手动干预的情况下促进实体之间的交互的自动化工具。在一些实施方案中,智能合约层可基于与一个或多个合约相关联的规则并在已满足那些规则时发起动作。对多维块链进行的每个更新和/或时间流逝和/或其他事件可触发由智能合约层进行的动作。
可基于由实体(例如,HCP 120和付款方140)约定的预定义规则来执行对更新的记录(例如,更新的记录520和更新的记录540)的链接。在一些实施方案中,可基于与多维块链相关联的智能合约来执行对块(例如,更新的块520和更新的块540)的链接。在链接之后,更新的块520和更新的块540可重新散列。如上所述,链接可允许实体将其块链中的信息与由另一个实体维护的块链中的信息相关联。此外,实体可能够确定与由该实体维护的特定块中的信息相关联的一个或多个交易。因此,两个或更多个实体可具有与不同块链中的块相关联的交易的相干且一致的视图。
因此,本发明所公开的实施方案有利于:(a)认证交易;(b)保护交易完整性,(c)维护交易出处;(d)在共享信息时符合法律、隐私和业务指导原则;(e)为组织维护的数据提供上下文。例如,组织可能够确定由该组织接收的外部数据的来源或交易。又如,多维块链可有利于PMDP 130基于实际患者处方使用真实世界证据(RWE)来分析和评估疗效、效能、剂量信息。例如,HCP看能够与PMDP 130共享疗效、效能、剂量信息以及一些人口统计信息(例如,年龄、位置(邮政编码)、医学病症、诊断等),而不提供关于患者的任何个人可识别或敏感的信息。迄今为止,此类RWE信息难以获得(由于法律、隐私和其他问题)并且难以分析(因为当获得时,所获得的信息通常是零碎的并且没有上下文—即缺乏人口统计信息和/或其他有用的信息)。在一些实施方案中,智能合约层可用于管理信息接口/数据共享,使得与参与者共享的数据可以是及时的、特定于实体的,并且符合法律、隐私法规和/或合约义务,同时遵守业务相关的考虑。
在图6A中,示出了对应于多维块的多个维度的数据记录的更新。然而,在一些实施方案中,可形成具有针对单个维度的数据记录的更新的新多维块,而与其他维度相关联的实质信息可保持不变。例如,与开具给患者的药物相关联的药物相关信息可在新多维块中(例如,由PMDP 130)更新,而不对EHR数据520或付款方交易记录140进行更新。
如图6A所示,多维块610可以是解锁的块,该解锁的块可以是非最终版本并且仍然可被修改。多维块610可包括更新的数据记录520和更新的数据记录540之间的链接。子块280和480可在记录520和540之间形成信息接口。在一些实施方案中,可通过智能合约层限定和/或管理信息接口。例如,对于某种交易类型,要在实体之间(诸如,在子块280和/或子块480中)共享的信息可由与多维块链相关联的智能合约层中的程序代码指定和验证。
图6A示出了多维块610通过一系列变换而实现的进一步增强,例如通过基于记录530添加另一个维度(这可遵循上文针对多维块610所述的流程)。在图6A中,在每次迭代时,两个实体(多维块中的两个维度)之间的信息接口被示出为正在被寻址。例如,在后续迭代中(例如,在形成解锁的多维块510之后),付款方140可从数据记录540分叉子块485,并且PMDP 130可从数据记录530分叉子块385。如上所述,在一些实施方案中,子块485可被复制并用可与PMDP 130共享的密钥(例如,通过授权代码)单独加密。类似地,子块385可被复制并用可与付款方140共享的密钥(例如,通过授权代码)单独加密。在验证之后,块530和540可被链接并重新散列。因为进一步更新的块540中的数据可能已改变,所以从块520到新更新的块540的链接也可被更新。
图6B示出了与包括数据记录520、530和540的多维块链相关联的示例性默克尔树622。在图6B中,示例性默克尔树622与多维块链相关联,该多维块链包括多个数据记录,该多个数据记录可各自与不同的各个块链相关联。默克尔树625仅为一个示例,并且视情况而定可使用其他形式。在一些实施方案中,在验证并完成时,数据记录520、530和/或540可在对应的不同块链(例如,分别在块链525、535和/或545)中形成块。当处于解锁状态时,示例性默克尔树622以及记录520、530和540中的数据可不被验证和/或为非最终版本。如图6B所示,散列C 631可通过对数据记录520使用加密散列函数来获得。加密散列函数是确定性的(针对相同的输入数据产生相同的输出)、在计算上便宜的(在资源中用于针对给定输入产生输出)、抗原像性的(难以从输出确定输入)和抗冲突的(通常针对不同的输入产生不同的输出)。类似地,可通过分别对数据记录530、540和D4使用适当的加密散列函数来获得散列D633、散列E 635、散列F 637。在图6B中,记录D4用于示出一些其他(例如,患者)记录,但不与图6A的讨论直接相关。加密散列函数631、633、635和639可分别特定于实体HCP120、PMDP130、付款方140以及与D4相关联的实体。因此,HCP 120(而不是PMDP 130、付款方140或与D4相关的实体)可能够解密数据记录520。相反,数据记录530、540和D4可由PMDP 130、付款方140以及与D4相关联的实体(而不由任何其他实体)解密。
此外,可通过对散列C 631和散列D 633的组合使用适当的加密散列函数来获得散列A 627,同时可通过对散列E 635和散列F 637的组合使用适当的加密散列函数来获得散列B 629。最后,可通过对散列A 627和散列B 629的组合使用适当的加密散列函数来获得顶部散列625。与散列C631(散列(520)的输出)、散列D 633(散列(530)的输出)、散列E635(散列(540)的输出)、散列F 637(散列(D4)的输出)相关联的数据可在被授权实体之间共享(例如,由形成多维块的实体共享),而不损害数据记录520、530、540或D4的安全性。类似地,散列A 627、散列B 629和顶部散列625也可被共享。
参见图6A,可用解锁的块继续进行每次迭代/每个步骤。在一些实施方案中,当与交易相关的信息交换完成并且交易已由共识层和/或智能合约层验证时,块520、530和/或540可被重新散列(视情况而定)、链接更新和锁定,并且多维块也可被锁定并作为多维块655提交(图6C)。因此,实体可能够验证与本地块(例如,最终块520、530和540)相关联的多维块(例如,图6C中的最终多维块655)的完整性,这些本地块与常规本地块链(例如,块链525、525和545)相关联。如图6C所示,多维块655可包括经验证的和最终的数据记录520、530和540,这些数据记录可分别对应于分别在对应的不同本地块链525、535和545中的最终的信息块520、530和540。在一些实施方案中,每个多维块可包括具有时间戳的块标头、顶部散列625、与先前块相关的信息、指向默克尔树625的根的指针,以及其他适当的信息。散列引用可采取私有的许可块链平台上的统一资源定位符(URL)和/或本地(特定于实体的)地址的形式。
图6C示出了有利于医疗保健信息的安全性和互操作性的系统650的示例性架构。在一些实施方案中,系统650可基于多维块链的使用,这些多维块链可基于由系统中的各个实体维护的不同块链。在一些实施方案中,系统650可包括私有的许可块链平台。在一些实施方案中,系统650可采取基于云的系统的形式。基于云的系统是指可通过网络(例如,互联网)可用的应用、服务和/或其他资源(包括硬件资源)。基于云的系统可基于底层硬件和软件资源,并且可以是公共的(例如,对于所有人在计算费用的基础上可用)、私有的(例如,限于组织)或混合的(使用公共云和私有云的一些组合)。
示例性系统650可包括各种实体。这些实体可由服务器(硬件和/或软件)表示,该服务器在一些情况下可以是基于云的。例如,HCP 120、PMDP 130和/或付款方140可包括服务器,并且/或者在包括虚拟机(VM)的基于云的平台上运行。
图6C示出了HTR块链545,其可耦合到第一实体诸如付款方140并由该第一实体维护。图6C还示出了在块链的头部处具有块520的EHR块链525和在块链的头部处具有块530的DIR块链535。在一些实施方案中,块链525和535可分别由第二实体HCP 120和PMDP 130维护。
如图6C所示,HCP 120、PMDP 130和/或付款方140可与认证层680进行交互。认证层660可包括用于在操作期间识别和管理(添加、注册和删除)系统实体的功能。此外,认证层可包括用于验证与多维块链上的操作(添加新块、创建链接等)相关的许可的功能。认证层660可与共识层670进行交互,该共识层可包括用于确定交易的顺序并验证与块相关的一组交易的正确性的功能。
在一些实施方案中,共识层670可确认构成多维块的交易的正确性。在一些实施方案中,可使用共识技术诸如拜占庭容错(BFT)或其变型诸如冗余BFT或一些其他基于投票的共识技术来确定是否可形成多维块610(图6A)。当指定的被授权实体或一些指定数量的实体(例如,大多数)验证交易或块时,可在与交易或块相关的有效性和/或最终性方面达成共识。在一些实施方案中,共识层670可与智能合约层680进行交互并调用该智能合约层中的功能,以验证与块相关的一组有序交易的正确性。
智能合约层680可包括实现与块链相关的逻辑的程序代码。例如,与多维块链相关联的“智能合约”程序代码可处理交易请求并基于程序逻辑来确定交易的有效性。该逻辑可取决于实体就与块链相关的交易约定的规则。例如,由于开具给患者的两种或更多种药物之间的不相容性,智能合约层680可拒绝交易(例如,来自HCP 120)。智能合约可在块被提交之前的验证时间和提交时间进行操作。在一些实施方案中,智能合约层680可确定和/或验证与多维块链相关联的实体之间的信息接口。例如,智能合约层680可编码两个或更多个实体之间关于数据共享、交易等的规则或协议,这可基于这些实体之间的真实世界合约。在一些实施方案中,由对应实体(例如,HCP 120、PMDP 130或付款方140)对传统块链(例如,块链625、635或645中的一者)进行的每个更新也可由与多维块链相关联的智能合约层680来验证。在一些实施方案中,可基于与多维块链相关联的智能合约来执行块的验证、完成和链接。在一些实施方案中,智能合约程序代码可被与平台相关联的一个或多个事件触发,诸如时间、添加来自一个或多个实体的块的请求和/或与(例如,由合约ID识别的)合约相关的特定请求等。
图6C示出了已提交和锁定的多维块655,其中来自子块480、280、380和385的信息已被对应的被授权相关实体共享。此外,多维块655包括块540、530和/或520之间的链接。多维块655可部分地表示某一时间点的交易的整体视图,因为其可包括与药物(使用、效果等)、患者(医学病症、治疗、效果)和该时间点的成本相关联的真实世界物理状态。多维块655可包括到块链中的先前块的链接。经验证的和最终的多维块655可包括最终的数据记录520、530和540,这些数据记录可分别对应于分别在对应的不同本地块链525、535和545中的最终的信息块520、530和540。
图6D是可与示例性基于自动结果的合约履行相关联的多维块的视觉描绘。在一些实施方案中,智能合约层可基于多维块链来促进基于自动结果的合约履行。
如图6D所示,三维(3D)块链690可包括3D块的序列,其中每个3D块包括EHR数据记录、DIR数据记录和HTR数据记录。图6C示出了数据记录DIR p 692,其可形成多维块的一部分并与特定药物(例如,药物p)相关联。例如,在图6D中,包括记录DIRp 692的多维块可表示在以下时间形成的多维块:(a)在某个时间点,患者首次被诊断为某种特定病症时,以及(b)在医疗提供者经由特定药物开始治疗时。例如,治疗开始日期、诊断代码、药物字段可在实体之间共享,并且识别包括记录DIR p 692的多维块。如上所述,实体之间共享的数据可取决于法律(例如,隐私、数据共享、医疗保健、商业、竞争)、实体之间的合约义务(例如,由实体输入的)和/或业务考虑(例如,商业秘密等)。因此,这里讨论的示例仅为示例性的,并且在数据记录、块和子块中共享和/或包括的实际数据可与这些示例不同。
因为单种药物(例如,药物p)可治疗许多患者,所以包括包含EHR q块694的3D块的许多EHR块可沿EHR轴线形成与药物p相关联的多维块链。类似地,单一药物(例如,药物p)可与许多交易相关联。因此,包括与HTR r块696相关联的3D块的许多HTR块可沿HTR轴线形成与药物p相关联的多维块链。
HCP 120和付款方140之间基于结果的合约可指出:当在所提交的多维块中条件满足时,付款方140将向HCP 120进行支付。例如,该条件可指定以下中的一者:(i)某个健康参数的值;或(ii)当患者用某种药物治疗时,患者的某个健康参数在一定时间段内的改善。在一些实施方案中,合约条款可被编码为智能合约,并且该智能合约可在条件满足时自动发起支付,如下面进一步所述。
当开始对患者进行治疗并提交针对患者的处方时,可向网络发出请求以连接针对患者的EHR信息块、针对处方药物的DIR信息块和交易信息块,并且通过形成初始多维(3D)块(诸如,包括DIR p数据记录692的3D块)来发起多维块链。
在某个时间点,当3D块诸如3D块698与指示已满足健康参数的值或者在用药物治疗的过程中已获得健康参数的期望改善的(与3D块698相关联的)EHR块一起提交时,那么智能合约可确定结果是否在指定时间段内并且自动发起动作。这些动作可包括以下中的一者或多者:指示合约完成、向与合约相关联的实体发送通知、发起交易以触发从付款方140到HCP 120的支付、确定和/或记录与合约相关联的参数(例如,时间长度、相关健康参数的初始值和最终值、访问次数、剂量等)。在一些实施方案中,触发支付的交易可包括触发支付以确保可跟踪性的智能合约代码。可例如基于所经过的时间来确定该时间段,通过多维块链中在治疗结束时与所提交的3D块698相关联的时间戳和当治疗开始时与初始多维块(例如,创世块)相关联的时间戳之间的差值来确定所经过的时间。
参见图6C,在一些实施方案中,智能合约层680还可在多维块链的每个维度上实现,以确保多维块被正确构建。在上述示例中,智能合约层可基于EHR来确保块链中的每个多维块与同一患者、诊断和药物和/或(例如,在HCP 120和付款方140之间的)合约ID相关。
在一些实施方案中,当向系统650中的患者(其可能是实体)开具药物时,智能合约层680可与付款方140就患者覆盖范围和药物资格进行核对,并且还可请求患者批准并同意价格。在就资格和价格达成安全协议后,可发起多维块的构建。
在一些实施方案中,由多维块链启用的整体视图可有利于基于RWE的机器学习和AI技术的使用。例如,制药公司和医疗设备提供者对临床试验之外的数据的访问可能非常有限。在一些实施方案中,通过关联与药物处方相关的人口统计信息(其可包括在符合监管和业务指导原则的EHR子块中),制药公司和医疗设备提供者可能够理解药物对不同人口统计群体的影响,改变剂量,监测不良结果等。这种数据相关性(例如,经由多维块链来实现)可使得能够采取预防措施(例如,降低或增加剂量、识别先前未知的药物相互作用等),这可降低患者风险、增加安全性和健康结果,同时还降低成本。此外,由于实体之间信息的共享有限,因此可维护患者和其他实体之间的患者隐私。此外,即使在实体之间路由支付时,结合多维块链使用智能合约也可有利于维护实体之间的合约保密性。
图7示出了有利于医疗保健信息的安全性和互操作性的示例性方法700的流程图。在一些实施方案中,方法700可使用多维块链,其可基于由系统中的各个实体维护的不同块链。在一些实施方案中,方法7000可在私有的许可块链平台上运行,该私有的许可块链平台在一些情况下可采取基于云的系统的形式。方法700可由处理器、计算机或计算机的网络诸如分布式计算系统、服务器(硬件和软件)(包括应用服务器)以及基于云的系统来执行。
在一些实施方案中,方法700可在第一实体处执行。例如,第一实体可包括与药物提供者或医疗设备提供者诸如PMDP 130中的至少一者相关联的至少一个服务器或计算机系统。在一些实施方案中,第一实体可与一个或多个第二实体进行交互。第二实体可包括与医疗保健提供者(诸如,HCP 120)或保险提供者(诸如,付款方140)或患者相关联的一个或多个服务器或计算机系统。在一些实施方案中,第一实体和该一个或多个第二实体可在分布式计算系统中形成计算节点,并且多维块链可形成许可私有块链平台(诸如,许可私有块链平台650)的一部分。
在一些实施方案中,当实体诸如第一实体发起交易以将块添加到本地维护的块链时,可调用方法700。将块添加到本地块链可涉及来自一个或多个其他实体的输入,并且许可私有块链平台650可调用方法700。
在一些实施方案中,在步骤710中,第一实体可响应于在第一时间进行的交易而从一个或多个第二实体接收与该交易有关的加密信息块。可以从不同的第二实体接收每个加密信息块,并且每个加密信息块可包括能够由该第一实体解密的至少一个子块。在一些实施方案中,对于由第一实体接收的每个加密信息块,能够由第一实体解密的对应子块可基于第一实体和对应的第二实体之间的信息接口。可基于管理第一实体和对应的第二实体之间的交互的预定义规则来确定第一实体和对应的第二实体之间的信息接口。在一些实施方案中,可通过与多维块链相关联的智能合约(例如,基于智能合约层680)来确定第一实体和对应的第二实体之间的信息接口。在一些实施方案中,智能合约可与多维块链相关联,并且形成许可私有块链平台的一部分。在一些实施方案中,智能合约可反映与许可私有块链平台相关联的实体之间与信息共享、隐私和合约义务相关的协议。
在一些实施方案中,在步骤720中,第一实体可解密能够由第一实体解密的子块。在一些实施方案中,为了解密子块,第一实体可从与所接收的加密信息块相关联的该一个或多个第二实体接收对应的授权代码,并且使用所接收的授权代码来解密能够解密的子块。在一些实施方案中,由第一实体解密子块可基于与对应的第二实体安全共享的密钥。例如,当子块被某个特定第二实体加密时,第一实体可使用与该第二实体共享或从该第二实体接收的密钥来解密该子块。在一些实施方案中,共享密钥可作为授权代码的一部分由第一实体安全地接收。
在步骤730中,第一实体可增强多维块链。可用多维块来增强该多维块链,通过将从该一个或多个第二实体接收的这些加密信息块中的至少一个加密信息块链接到当前块来形成该多维块,该当前块被添加到与该交易相关联并且由该第一实体维护的块链。增强可包括将多维块添加到现有的块链,或者将第一多维块添加到多维块链结构(诸如,将多维块添加到新创建的多维块链)。在一些实施方案中,当前块可包括一个或多个子块,其中当前块中的每个子块可基于第一实体和对应的第二实体之间的信息接口,并且可能够由对应的第二实体解密。例如,当前块中的子块j的内容可基于第一实体和对应的第二实体诸如第二实体j之间的信息接口,并且子块j可能够由第二实体j解密。
在一些实施方案中,增强可包括将新多维块添加到多维块链。多维块链可被存储并且使得能够被与许可私有块链平台相关联的一个或多个第二实体访问。在一些实施方案中,用多维块(例如,多维块655)增强多维块链可包括确定与一个或多个子块(例如,子块280、380、385、480和/或485)相关联的数据的有效性。在一些实施方案中,可部分地通过与许可私有块链平台相关联的智能合约层(例如,智能合约层680)来确定有效性。例如,智能合约层(例如,智能合约层680)可向与许可私有块链平台相关联的实体中的一个或多个实体请求验证。在一些实施方案中,智能合约层(例如,智能合约层680)可确定被授权验证与一个或多个子块相关联的数据的一个或多个实体,并且向该一个或多个被授权实体请求验证。在一些实施方案中,与一个或多个子块相关联的数据的有效性可基于共识技术。在一些实施方案中,可使用拜占庭容错(BFT)技术来确定有效性和/或达成共识。在一些实施方案中,在用多维块增强多维块链时,第一实体可触发与许可私有块链平台相关联的至少一个智能合约。在一些实施方案中,第一实体可基于与多维块链相关联的信息从智能合约接收对完成第一实体和该一个或多个第二实体之间的一个或多个合约里程碑和/或一个或多个合约结果的指示。
在一些实施方案中,在用多维块增强多维块链时,智能合约层(例如,智能合约层680)可评估与和许可私有块链平台相关联的实体之间的合约相关联的条件,并确定:是否已满足合约里程碑(例如,在HCP 120和付款方140之间的合约里程碑,以确定:健康参数是否在自治疗开始起的某个时间段内满足某个期望标准)、是否已满足期望合约结果(例如,在某个时间段内维护健康参数)、是否已发生另一个合约相关事件等。在一些实施方案中,在确定已发生与某个合约相关的一个或多个合约事件时,智能合约层(例如,智能合约层680)可执行如合约所述的一个或多个动作。例如,智能合约层(例如,智能合约层680)可:(a)向感兴趣的被授权实体(例如,诸如合约当事人)报告与事件相关的合约;(b)向适当的实体报告合约相关数据,诸如健康参数、成本指标和/或性能参数(如合约所授权的);(c)在没有人为干预的情况下自动发起动作,诸如开发票、批准、支付、报告等;(d)存储关于合约相关事件的信息,并将针对合约相关事件采取的行动与相应的合约相关联。
此外,在一些实施方案中,智能合约层(例如,智能合约层680)可发起其他动作以分析数据并识别可能影响治疗、结果等的风险和/或其他因素。在一些实施方案中,智能合约层(例如,智能合约层680)可基于与多维块链相关联的RWE启动或用于启动机器学习工具和AI技术。例如,特定药物(DIR)可与多个患者相关联,并且针对与多维块链中的多维块相关联的药物的每个DIR数据记录可包括关于已被开具药物的患者(例如,通过EHR字块接收)的一些非个人人口统计信息(年龄、医学病症、邮政编码、正被开具的其他药物等)。在一些实施方案中,(例如,在提交多维块之前,已使用与智能合约层相关联的功能适当地验证多维块链中的数据)在已发生与药物相关的指定数量的交易和/或(例如,自药物引入或最后一次机器学习运行起)已经过某个指定时间段时,智能合约层(例如,智能合约层680)可基于与多个患者的药物相关联的DIR数据记录来启动机器学习。机器学习可能够预测与药物相关联的潜在风险(医学病症、副作用、药物相互作用等)或提高对该潜在风险的认识,并且/或者识别药物疗效高于标准的情况,定制剂量等。因此,制药公司和医疗设备提供者(例如,PMDP130)可能够理解药物对不同人口统计群体的影响,改变剂量,监测不良结果等。这种数据相关性(例如,经由多维块链来实现)可使得能够采取预防措施(例如,降低或增加剂量、识别先前未知的药物相互作用等),这可降低患者风险、增加安全性和健康结果,同时还降低成本。此外,在可确定与特定预测相关联的DIR记录的情况下,实体(例如,PMDP 130)可使用对应的多维块(例如,与那些DIR相关联的)来进一步验证预测(例如,以确定是否需要进一步的研究)。
在步骤740中,第一实体可使得该一个或多个第二实体中的至少一个第二实体能够访问多维块链。在一些实施方案中,可通过基于加密散列函数来加密多维块(例如,如相对于图6B所述)并存储包括该多维块的多维块链来使得能够访问该多维块,该多维块具有使得能够被该一个或多个第二实体访问的访问许可。例如,多维块链可存储在耦合到执行方法700的处理器或计算机系统的存储器中。在一些实施方案中,多维块可被存储在基于云的存储装置中,并且使得与所许可私有块链平台相关联的适当实体能够访问。如上所述,虽然与许可私有块链平台相关联的实体可能够验证与增强的多维块相关联的信息的完整性,但可与特定实体相关联的数据记录(例如,数据记录520、530和540)可对于那些实体保持为私有的。此外,如上所述,多维块(例如,多维块655)可包括本地数据记录(例如,数据记录520、530和540)之间的链接,这些本地数据记录在一些情况下可在对应的不同本地块链(例如,分别在525、535和545)中形成块。
图8示出了与智能合约层(例如,智能合约层680)相关联的智能合约。如图8所示,智能合约1810可被实现为反映合约实体付款方140、患者805和HCP 120之间的协议。智能合约2820可被实现为反映付款方140和PMDP 130之间的协议。智能合约3830可被实现为反映PMDP 130和患者805之间的协议,同时智能合约4840可被实现为反映PMDP 130和HCP 120之间的协议。在一些实施方案中,智能合约(例如,智能合约1810、智能合约2820、智能合约3830和智能合约4840)可存储在合约数据库中。在一些实施方案中,每个智能合约(例如,智能合约1810、智能合约2820、智能合约3830和智能合约4840)可包括具有用于评估与多维块链中的多维块相关联的数据的规则的程序代码。在一些实施方案中,智能合约层(例如,智能合约层680)可(代表接收实体)解密一个或多个子块中的信息,并且基于与对应智能合约相关联的代码/规则做出确定。例如,实体可将一些功能委托给智能合约层,或者智能合约层可在实体被授权时充当实体的代理。在一些实施方案中,一个或多个实体可与智能合约层安全地共享信息,以用于数据验证和/或合约管理。智能合约层(例如,智能合约层680)可标记数据错误,确保实体向与许可私有块链平台相关联的其他实体报告的数据的一致性,执行数据验证,指定和/或监测实体之间的信息接口和/或数据共享以确保共享被授权数据。例如,智能合约层(例如,智能合约层680)可使用全局字段ID和/或字段之间的已知相关性来确保实体向其他实体报告的针对交易的数据是一致的。作为一个示例,智能合约层680可确保HCP 120向患者805和付款方140报告的医疗参数字段中的信息(例如,血压)是一致的。
由于基于许可私有块链平台上的子块的信息共享,智能合约层(例如,智能合约层680)可能够实现多个实体之间的合约,诸如实体付款方140、患者805和HCP 120之间的智能合约1 810。如上所述,常规系统可能无法实现多于两个实体之间的合约。此外,多维块链确保与特定实体相关联的数据记录的数据安全性(使得数据记录不能够由其他未授权实体解密)。此外,因为不同本地块链(例如,分别在525、535和545)中的最终数据块(例如,520、530和540)对应于最终多维块(例如,多维块655)中的数据记录,所以与许可私有块链平台相关联的实体(例如,HCP 120、PMDP130和付款方140)共享信息的一致且相干的视图,该信息可容易地与本地块链相关联。智能合约层(例如,智能合约层680)还可有利于快速系统更新,因为在适用时,相同合约可应用于一类实体(例如,患者805)。因此,例如,用于反映付款方140对用于医学病症的新药物的批准的智能合约1810的更新,对于与智能合约1相关联的所有患者(例如,和与付款方140相关联的以及由HCP 120针对医学病症进行治疗的患者805类似的患者)将是可快速获得的。此外,智能合约变更的影响是局部的。PMDP 130和HCP120之间的智能合约4840的变更将仅影响所涉及的实体。在常规系统中,由于其他合约/实体(例如,如图1B中所述的附录)可能与两个实体之间的合约相关联,因此连锁反应可能影响其他实体/合约。
在一些实施方案中,如上所述,智能合约层(例如,智能合约层680)可周期性地(例如,指定的时间间隔)和/或在发生与合约相关事件(例如,交易和/或多维块添加)时、实体请求时和/或如与合约相关联的实体约定的那样评估合约。例如,智能合约层680可评估与HCP 120、付款方140和患者105之间的智能合约1810相关联的条件。在上述示例中,智能合约1810可指示:(a)被授权在实体之间共享的信息(例如,使用子块);(b)指定合约里程碑(例如,在HCP 120和付款方140之间的合约里程碑,以确定:患者805的健康参数是否在自治疗开始起的某个时间段内满足某个期望标准);(c)指定合约履行的标准;以及(d)指定要在合约/里程碑履行时发起的动作。
例如,智能合约1中的里程碑可指定患者805的血压在一段时间内降低到低于某个范围,并且指定在某个时间段内满足了该里程碑时从付款方140到HCP 120的首次支付。此外,如果患者805的血压范围在某个时间段内保持在指定范围内,则智能合约1可指定从付款方140到HCP 120的附加支付。在HCP 120提交数据记录(具有能够由付款方140解密的适当子块)时,智能合约1可确定自治疗开始所经过的时间(例如,基于和与患者805和HCP 120相关联的对应多维块相关联的时间戳),并核对血压范围。如果已满足里程碑,则智能合约1可向实体报告该里程碑,保存与该里程碑相关联的信息,生成具有适当信息的发票,并且发起从付款方140到HCP 120的支付。在后续时间,智能合约1可确定患者805的血压范围已保持在规定范围内(例如,基于和与患者805和HCP 120相关联的对应多维块相关联的时间戳),并向实体报告结果,保存与结果确定相关联的信息,生成具有适当信息的发票、报告等,并且发起从付款方140到HCP 120的另一次支付。
在一些实施方案中,在确定已发生与某个合约相关的一个或多个合约事件时,智能合约层(例如,智能合约层680)可执行如合约所述的一个或多个动作。例如,智能合约层(例如,智能合约层680)可:(a)向感兴趣的被授权实体(例如,诸如合约当事人)报告与事件相关的合约;(b)向适当的实体报告合约相关数据,诸如健康参数、成本指标和/或性能参数(如合约所授权的);(c)在没有人为干预的情况下自动发起动作,诸如开发票、批准、支付、报告等;(d)存储关于合约相关事件的信息,并将针对合约相关事件采取的行动与相应的合约相关联;并且/或者(e)启动工具(例如,机器学习等)以分析与多维块链相关联的数据。
图9示出了能够有利于医疗保健系统的安全性并提高互操作性的示例性计算机900。在一些实施方案中,计算机900可托管许可私有块链平台和/或与该许可私有块链平台进行交互。在一些实施方案中,示例性计算机900可以是服务器,或运行用于一个或多个实体(诸如,HCP 120、PMDP130和/或付款方140)的服务器(例如,应用服务器)。在一些实施方案中,计算机900可实现方法700和/或本文所公开的其他技术。在一些实施方案中,计算机900可形成分布式计算系统的一部分,该分布式计算系统可实现许可私有块链平台。在一些实施方案中,分布式计算系统和/或计算机900可以是基于云的。
在一些实施方案中,计算机900/处理器950可能够处理交易请求,包括与将块添加到块链(包括多维块链)相关的请求。此外,计算机900/处理器950可能够运行加密和/或解密算法,获得信息块的散列,验证散列,执行数字签名,并且可能够执行和/或支持用于提高安全性和促进认证的各种方法。认证可指以下两者:验证所存储的信息的完整性(例如,在块链中的块中,以确定任何未授权更改),以及确保访问许可私有块链平台的实体是可信的并具有执行任何所请求交易的许可。在一些实施方案中,计算机900/处理器950还可用新块增强(创建或添加到)块链(包括用多维块增强多维块链)。在一些实施方案中,计算机900/处理器950还可存储并执行与块链相关联的智能合约,以实现实体(例如,HCP 120、PMDP130、付款方140和/或患者)之间的与隐私、信息共享、合约执行等相关的协议。
在一些实施方案中,计算机900/处理器750可能够分析并使用机器学习技术来确定各种健康参数之间的关系。例如,计算机900/处理器950可包括一个或多个神经网络处理器,以及/或者能够被配置为神经网络和/或能够执行软件以建模和/或模拟神经网络的分布式处理器,这些神经网络可用于实现机器学习。例如,PMDP 130可使用通过多维块可用的基于机器学习技术的RWE信息(例如,人口统计信息、副作用、与感兴趣的指定药物组合使用的药物、治疗结果等)来定制药物的使用。例如,可使用机器学习来确定有效剂量,基于人口统计特征靶向药物,改善药物相互作用信息,提高安全性,确定各种给药模式的相对疗效等。如上所述,PMDP 130可能无法获得临床试验之外的该信息,从而妨碍或严重限制了机器学习和AI技术的使用。
在一些实施方案中,可使用通信/网络接口902将计算机900耦合到其他计算机,该通信/网络接口可包括有线(例如,包括千兆位以太网的以太网)和无线接口。无线接口可基于:无线广域网(WWAN)标准,诸如蜂窝标准,包括3G、4G和5G标准;IEEE 802.11x标准,其通常被称为Wi-Fi。
计算机900可包括存储器904,该存储器可包括以下中的一者或多者:只读存储器(ROM)、可编程只读存储器(PROM)、各种类型的随机存取存储器(RAM)、非易失性RAM等。存储器904可在处理器950内或在处理器950外部实现。如本文所用,术语“存储器”是指任何类型的长期存储器、短期存储器、易失性存储器、非易失性存储器或其他存储器,并且不限于任何特定类型的存储器或任何数量的存储器,或其上存储有存储器的任何类型的介质。
存储器可包括高速缓存存储器、主存储器和辅助存储器。辅助存储器可包括计算机可读介质920。计算机可读介质可包括磁性和/或光学介质,该磁性和/或光学介质在一些情况下可以是可移动介质。可移动介质可包括光碟诸如光盘(CD)、激光盘、数字视频光盘(DVD)、蓝光光盘和其他光学介质,并且还包括USB驱动器、闪存驱动器、固态驱动器、存储卡等。计算机900还可包括存储装置960,该存储装置可包括硬盘驱动器、固态驱动器(SSD)、闪存存储器、其他非易失性存储装置和基于云的存储装置。
可使用连接件906将通信/网络接口902、存储装置960、存储器904和计算机可读介质920耦合到处理器950,该连接件可采取总线、线路、光纤、链路等的形式。
本文所述的方法可根据应用通过各种方式来实现。例如,这些方法可以硬件、固件、软件或它们的任何组合来实现。对于硬件具体实施,处理器950可在一个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、神经网络处理器(NNP)、数字信号处理设备(DSPD)、可编程逻辑设备(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、电子设备、被设计成执行本文所述的功能的其他电子单元或它们的组合内实现。
对于固件和/或软件具体实施,这些方法可用微码、程序、功能和执行本文所述的功能的固件和/或软件等来实现。有形地体现指令的任何机器可读介质可用于实现本文所述的方法。例如,软件可存储在存储装置960中和/或可移动计算机可读介质上。程序代码可驻留在计算机可读介质920、存储装置960和/或存储器904上,并且可由处理器950读取和执行。
如果以固件和/或软件来实现,则这些功能也可作为一个或多个指令或代码存储在计算机可读介质920、存储装置960和/或存储器904中。示例包括用数据结构和计算机程序编码的计算机可读介质。例如,计算机可读介质920可包括存储在其上的程序代码,该程序代码可包括支持用于有利于医疗保健系统的安全性并提高系统互操作性的方法的程序代码,该支持的方式包括:支持多维块链、智能合约、共识确定并执行与如本文所述的许可私有块链平台相关联的其他功能。
处理器950可使用硬件、固件和软件的组合来实现。在一些实施方案中,计算机900可耦合到显示器,以有利于查看GUI并与管理员和其他用户进行交互。
虽然出于说明目的结合具体实施方案描述了本公开,但本公开并不限于此。在不脱离本公开范围的前提下,可对本公开进行各种调整和修改。因此,所附权利要求书的实质和范围不应受到前述描述的限制。
- 基于块链的医疗保健安全性和互操作性
- 用于区块链的互操作性的系统和方法