电子健康记录数据区块链系统和方法与流程

1.本公开内容总体上涉及区块链使能的(blockchain-enabled)患者数据系统，并且更具体地涉及被配置为便于多个实体之间的匿名患者数据交易(transaction)的区块链使能的患者数据系统。


背景技术：

2.当今的医疗保健行业由“中心化(centralized)”和“去中心化(decentralized)”(基于集线器的)网络结构和多个独立的数据筒仓(silo，竖井)组成。在传统的电子患者记录系统中，系统根据常规的客户端-服务器模型进行配置，其中根据由国家处方药计划委员会(ncpdp)发布的标准，消息被发送到服务器，并且服务器发送响应。常常，客户端和服务器可能具有不合适的数据库，诸如数据库和ms数据库。此外，发送和接收的每个消息由客户端和服务器记录。经常，由于延迟(latency)、丢包(dropped packet)和其他各种系统问题，因此在客户端和服务器之间可能出现关于消息的实际内容的差异(discrepancy)。
3.特别地，可以由多个实体在他们从药房到付款方进行支付时编辑药房患者信息消息。当链中的每个实体编辑消息时，添加附加的复杂性，该附加的复杂性可能导致附加的消息差异——包括不兼容的数据标记、数据格式化、验证等。这可能导致具有消息完整性不同的消息的多个数据库。这样的差异导致致力于解决差异的努力、时间和金钱的浪费。
4.此外，存储在数据库中的患者可识别(patient-identifiable)数据的可用性招致hippa违反和数据的不正确处理的可能性。可能需要多个系统来监测处方、提供编辑、提供报价、确定药物资格、识别履行选项(fulfilment option)和最终确定定价，从而浪费宝贵的资源，添加复杂性以及导致超额成本。


技术实现要素：

5.本公开内容教导了关于电子健康记录(ehr)数据区块链系统的技术优势，该电子健康记录(ehr)数据区块链系统被配置为允许多个实体(例如，可以充当数据、服务、产品提供方的制药行业实体，以及消费者)连接到ehr患者交易区块链(例如，ehr-data-bc)和ehr数据患者门户(portal)(例如，ehr-data-pp)以对于患者信息消息和后续编辑提供中心化位置，以确保一致的消息数据。
6.本公开内容解决了在多个系统上实施的、减轻电子患者数据的数据差异的技术问题。此外，本公开内容克服了与患者可识别信息(pii)的多次转移相关的问题。此外，本公开内容解决了与交易资金和激励相关联的问题。
7.特别地，本公开内容通过实施ehr数据区块链系统(包括ehr数据api、ehr患者交易区块链api和ehr患者交易区块链)来改善传统系统的性能，所述ehr数据区块链系统可以提供创建透明度、不可改变的证实、交互式交易编辑和数字货币交易(例如，使用各方的数字钱包信息发生的数字货币交易)的中心化患者交易处理位置。ehr数据api可以访问和检索
api)直接与ehr患者交易区块链通信。该系统可以便于匿名患者数据在多个实体之间的转移，所述多个实体包括：
13.·
医生
14.·
药房
15.ο独立的
16.ο连锁的
17.ο中央配药的(central fill)
18.ο邮购的
19.·
药物制造商
20.·
药物批发商
21.·
处方编辑提供方
22.ο药物利用审查
23.ο基因组
24.ο定价
25.·
处方福利管理者
26.·
药房软件供应商
27.·
国家促进者(national facilitator)
28.·
运输服务(联邦快递、dhl等)
29.·
递送服务
30.·
处方呼叫中心
31.·
政府机构
32.·
其他
33.本公开内容的一个目的是提供一种被配置为处理患者的处方交易的电子健康记录数据区块链系统。本公开内容的另一目的是提供一种提供基于区块链的电子健康记录数据患者交易的方法，所述方法由服务器系统实施，所述服务器系统包括执行计算机程序指令的一个或多个处理器，所述计算机程序指令在被执行时执行所述方法。本公开内容的另一个目的是提供一种被配置为处理患者的处方交易的电子健康记录数据区块链系统。这些和其他目的由以下实施方案提供。
34.在一个示例性实施方案中，一种被配置为处理患者的处方交易的电子健康记录数据区块链系统可以包括：一个或多个计算机可读存储介质，被配置为存储区块链；计算机系统，包括一个或多个处理器，所述一个或多个处理器被编程以执行计算机程序指令，所述计算机程序指令在被执行时导致所述计算机系统：为患者生成单目的患者id(sppid)；从电子医疗记录系统接收具有多个参数的电子处方；使用所述处方、所述sppid并且不使用患者识别信息在区块链上为该患者发起新的处方交易；接收来自一个或多个提供方的处方交易编辑；生成被配置为编辑多个处方参数中的至少一个并且将编辑记录写入所述区块链的智能合约；基于所述编辑记录生成结束记录(close record，终止记录)，所述结束记录指示药物和待支付的价格，并且将所述结束记录写入所述区块链；以及一旦所述结束记录已经被写入所述区块链，就发起与所述处方交易相关的一个或多个数字货币交易。
35.在另一个示例性实施方案中，一种提供基于区块链的电子健康记录数据患者交易
的方法，所述方法由服务器系统实施，所述服务器系统包括执行计算机程序指令的一个或多个处理器，所述计算机程序指令在被执行时执行所述方法，所述方法可以包括：为患者生成单目的患者id(sppid)；从电子医疗记录系统接收具有多个参数的电子处方；使用所述处方、所述sppid并且不使用患者识别信息在区块链上为该患者发起新的处方交易；接收来自一个或多个提供方的处方交易编辑；生成被配置为编辑多个处方参数中的至少一个并且将编辑记录写入所述区块链的智能合约；基于所述编辑记录生成结束记录，所述结束记录指示药物和待支付的价格，并且将所述结束记录写入所述区块链；以及一旦所述结束记录已经被写入所述区块链，就发起与所述处方交易相关的一个或多个数字货币交易。
36.在另一个示例性实施方案中，一种被配置为处理患者的处方交易的电子健康记录数据区块链系统可以包括：一个或多个计算机可读存储介质，被配置为存储区块链；以及计算机系统，包括一个或多个处理器，所述一个或多个处理器被编程为执行计算机程序指令，以对存储在所述区块链上的处方交易进行一个或多个编辑，所述计算机程序指令包括：ehr应用程序编程接口(api)，被配置为访问和检索患者可识别信息(pii)并且为患者生成非患者可识别单目的患者id(sppid)；以及区块链api，被配置为将与所述患者交易相关的sppid和非患者识别信息存储在所述区块链上，编辑所述区块链上的所述处方交易，执行与所述区块链上的所述处方交易相关的智能合约，以及控制与所述区块链上的所述处方交易相关的数字货币转移的执行。
附图说明
37.图1示出了根据本公开内容的一个或多个示例性实施方案的电子健康记录数据区块链系统的示意性视图；以及
38.图2示出了根据本公开内容的一个或多个示例性实施方案的电子健康记录数据区块链系统交易的示意性视图。
具体实施方式
39.参考包括在附图中并且如在随后的描述中详述的非限制性示例更全面地解释在以下书面描述中呈现的本公开内容的优选形式以及其各种特征和有利细节。已经省略对众所周知的部件的描述，以免不必要地模糊本文所描述的主要特征。在以下描述中使用的示例意在便于对可以实施和实践本公开内容的方式的理解。因此，这些示例不应被解释为限制权利要求的范围。
40.图1示出了根据本公开内容的一个或多个示例性实施方案的电子健康记录数据区块链系统的示意性视图。ehr-data-bc系统100可以包括服务器102、第三方数据库106、分布式账本125、网络130和外部系统140。
41.服务器102可以包括一个或多个处理器(或核)104、存储器(memory)106和机器可读指令108。在一个示例性实施方案中，机器可读指令108可以包括ehr数据api 110、交易区块链api 112、预编辑和后编辑模块114、相互作用分析模块116、资格分析模块118和支付模块120。此外，服务器102可以托管ehr数据患者门户(ehr-data-pp)，其可以在已验证的登录之后为患者提供对系统100的访问。服务器102可以硬件、软件或用于其的硬件和软件的合适的组合来实施，并且可以包括在一个或多个服务器上运行的一个或多个软件系统，所述
一个或多个服务器具有一个或多个处理器，可以访问存储器。服务器可以包括电子存储装置(storage)、一个或多个处理器和/或其他部件。服务器可以包括通信线路或端口，以实现与网络和/或其他计算平台的信息交换。服务器还可以包括多个硬件、软件和/或固件部件，所述部件一起运行以提供本文被认为是服务器所为的功能。例如，服务器可以由一起运行作为服务器的云计算平台来实施。此外，服务器可以包括存储器106。
42.服务器可以包括电子存储装置、一个或多个处理器和/或其他部件。服务器可以包括通信线路或端口，以实现与网络和/或其他计算平台的信息交换。服务器还可以包括多个硬件、软件和/或固件部件，所述部件一起运行以提供本文被认为是服务器所为的功能。例如，服务器可以由一起运行作为服务器的云计算平台来实施。
43.存储器106可以包括电子存储装置，该电子存储装置可以包括电子地存储信息的非暂时性存储介质。电子存储装置的电子存储介质可以包括可以与服务器整体地(即，基本上不可移除)提供的系统存储装置和/或可以经由例如端口(例如，usb端口、火线端口等)或驱动器(例如，磁盘驱动器等)可移除地连接到服务器的可移除存储装置中的一个或两个。电子存储装置可以包括一个或多个光可读存储介质(例如，光盘等)、磁可读存储介质(例如，磁带、磁硬盘驱动器、软盘驱动器等)、基于电荷的存储介质(例如，eeprom、ram等)、固态存储介质(例如，闪存驱动器等)和/或其他电子可读存储介质。电子存储装置可以包括一个或多个虚拟存储资源(例如，云存储、虚拟私用网络和/或其他虚拟存储资源)。电子存储装置可以存储机器可读指令、软件算法、由处理器确定的信息、从服务器接收的信息、从计算平台接收的信息和/或使得服务器能够如本文所描述的那样起作用的其他信息。电子存储装置也可以是经由网络连接可访问的。
44.处理器104可以被配置为在服务器中提供信息处理能力。这样，处理器可以包括以下中的一个或多个：数字处理器、模拟处理器、被设计以处理信息的数字电路、被设计以处理信息的模拟电路、状态机和/或用于电子地处理信息的其他机构，诸如fpga或asic。处理器可以是单个实体或包括多个处理单元。这些处理单元可以物理地位于同一设备内或代表协同运行的多个设备的处理功能或软件功能。
45.处理器104可以被配置为通过软件、硬件、固件，软件、硬件、固件的某种组合和/或用于在处理器上配置处理能力的其他机构来执行机器可读指令108或学习模块。如本文所使用的，术语“机器可读指令”可以指执行被认为是机器可读指令部件所为的功能的任何部件或部件集。这可以包括在处理器可读指令、处理器可读指令、电路系统(circuitry)、硬件、存储介质或任何其他部件的执行期间的一个或多个物理处理器。
46.服务器102可以被配置有具有一个或多个功能模块的机器可读指令108。机器可读指令可以被实施在一个或多个服务器上，所述一个或多个服务器具有一个或多个处理器，可以访问存储器。机器可读指令可以是单个联网节点或机器集群，该机器集群可以包括多个联网节点的分布式架构。机器可读指令可以包括用于实施各种功能的控制逻辑，如下文更详细描述的。机器可读指令可以包括与ehr数据患者门户(ehr-data-pp)、ehr数据api(第一服务器侧计算机系统)110、ehr患者交易区块链api(第二服务器侧计算机系统)、预编辑和后编辑模块114、相互作用分析模块116、资格分析模块118和支付模块120相关联的某个功能。外部数据库106和外部系统140以及ehr数据区块链客户端(客户端计算机系统)也可以被实施在一个或多个服务器102上，所述一个或多个服务器102具有一个或多个处理器
104，可以访问存储器106。
47.在一个示例性实施方案中，ehr数据api 110可以提供定义多个软件部件之间的相互作用的接口。例如，ehr数据api 110可以定义可以进行的调用或请求的种类、如何进行调用或请求、应使用的数据格式、要遵循的约定以及其他合适的功能。在另一个示例性实施方案中，ehr数据api 110可以访问和检索患者可识别信息(pii)并且为特定患者生成非患者可识别单目的患者id(sppid)。
48.在一个示例性实施方案中，ehr患者交易区块链api 112(例如，ehr-data-bc-api)可以提供定义多个软件部件之间的相互作用的接口。例如，ehr患者交易区块链api 112可以定义可以进行的调用或请求的类型、如何进行调用或请求、应使用的数据格式、要遵循的约定以及其他合适的功能。在另一个示例性实施方案中，交易区块链api 112可以被配置为，除了其他功能之外，存储sppid以及从ehr检索的对于患者的特定离散数据、执行智能合约和控制数字货币转移的执行。
49.在一个示例性实施方案中，预编辑和后编辑模块114可以根据从外部系统140、第三方数据库106或其他合适的系统接收的输入来编辑接收的分布式账本交易。在另一个示例性实施方案中，可以在药房按处方配药时实时地处理交易。例如，“预编辑”和“后编辑”处理在行业中可以由药房和付款者使用，以使用预定的数据和处理理赔的规则来检查处方理赔的准确性和一致性。在另一个示例性实施方案中，预编辑和后编辑模块114可以在提交的处方和关于处方药品的信息的上下文中分析患者临床数据并且完成预编辑过程。例如，模块114可以从第三方数据库106接收患者临床数据并且将处方信息与该患者临床数据相关联以考虑到患者的身高、体重或其他患者因素确定是否处方规定了不正确的剂量或时间。在另一个示例性实施方案中，ehr数据api 110可以被可操作地耦合到预编辑和后编辑模块114，以向预编辑和后编辑模块114提供与交易相关的相关患者信息。在另一个示例性实施方案中，ehr患者交易区块链api 112可以被可操作地耦合到预编辑和后编辑模块114，以存储从ehr检索的与交易相关的患者的特定离散数据。
50.在一个示例性实施方案中，相互作用分析模块116可以接收与潜在药物相互作用相关的信息，并且将该数据读取和写入分布式账本125。例如，相互作用分析模块116可以使用从第三方数据库106提取的患者临床数据来分析交易信息，所述患者临床数据包括关于与其他药物的潜在药物相互作用和患者风险因素的信息中的至少一个或多个，所述患者风险因素包括选自由患者实验室数据、基因组数据、免疫和过敏组成的组的信息。在一个示例性实施方案中，资格分析模块118可以做出与交易相关的患者资格确定。例如，资格分析模块118可以接收患者的保险信息并且将该信息与交易数据相关联以确定折扣资格和其他相关内容。
51.在一个示例性实施方案中，支付模块120可以确定在处方配药期间是否利用了智能合约并且可以导致数字货币(例如，ehrcash
tm
等)、效用代币、代金券或其他合适的票据在智能合约中涉及的各方之间的交换。例如，ehrcash
tm
代币的交换可以是即时的(亚毫秒延时)，并且可以消除对标准会计过程(即开账单、对账单、应收账款和应付账款)的需要，以从贸易伙伴收钱。在另一个示例性实施方案中，支付模块120可以利用存储的数字钱包信息来实现数字货币交易。可以经由服务器、控制逻辑、api或其他合适的方式来执行、调用或以其他方式实施本文所描述的模块。
52.分布式账本125可以是实施在一个或多个平台上的一个或多个ehr数据区块链，所述一个或多个平台包括bigchaindb、nchain、以太坊(ethereum)、超级账本(hyperledger)、r3、瑞波币(ripple)、eos或其他合适的区块链平台。ehr数据区块链可以是公众可访问的公共区块链，也可以是仅由有资格访问的各方可访问的私有区块链。
53.上述的系统部件、api和模块可以经由互联网、内联网、系统总线或其他合适的网络130相互通信地耦合。通信可以是加密的、未加密的、通过vpn隧道或其他合适的通信方式。网络130可以是wan、lan、pan或其他合适的网络。系统部件102、104、106、108、110和112之间的网络通信可以使用pgp、blowfish、aes、3des、https或其他合适的加密来加密。网络通信可以经由应用程序编程接口(api)、健康级别7(hl7)标准、ansi-x12、以太网、pci、pcie、infiniband、wi-fi、蓝牙(bluetooth)或其他合适的通信协议发生。
54.第三方数据库106可以经由网络130可操作地耦合到系统部件。在一个示例性实施方案中，第三方数据库106可以包括电子医疗记录系统(emr)、电子患者结果记录(epor)数据库、药房数据库、多个患者数据库、临床数据库、基因组数据库、实验室数据库、疾病数据库、标准化药物数据库、研究数据库和其他合适的数据库。在另一个示例性实施方案中，第三方数据库可以起档案节点的作用。档案节点可以保持分布式账本125的实时(亚毫秒)加密副本。档案节点可以提供容错并且使分布式账本125的内容对主机容易获得，使得可以实现附加的数据处理、报告以及分析。代替必须遍历ehr数据api 110，主机可以查询其自己的机器以获取数据。任何第三方都可以托管药物档案节点。在另一个示例性实施方案中，档案节点可以向分布式账本125提供数据恢复。在另一个示例性实施方案中，档案节点可以保持更旧的分布式账本数据在非生产系统中可访问，使得生产分布式账本可以指引其全部能力朝向当前交易。在另一个示例性实施方案中，一旦分布式账本交易结束，分布式账本就可以转移到档案节点。
55.外部系统140可以经由网络130可操作地耦合到系统部件。外部系统140可以包括患者设备、药房设备、付款者设备、金融机构设备、保险设备、医疗设备、lot设备或其他合适的系统或设备。这样的系统和设备可以包括智能电话、平板计算机、可穿戴设备、膝上型计算机、台式机、服务器、家用电器或其他合适的设备。在一个示例性实施方案中，外部系统140可以是ehr-data-bc-client。
56.图2示出了根据本公开内容的一个或多个示例性实施方案的电子健康记录数据区块链系统交易的示意性视图。ehr数据区块链系统200可以包括：电子健康记录(ehr)系统204，其包括存储在ehr数据库202中的多个患者的电子健康记录226；以及患者识别信息206。在一个示例性实施方案中，每个ehr可以包括患者的联系信息、身高体重、年龄、血型、处方历史、多组学数据、临床历史、患者结果数据、保险信息、账户信息以及与患者相关的其他相关信息。此外，ehr可以包括来自与用户相关的移动设备210以及与用户相关的可穿戴设备的信息。
57.可以经由ehr数据应用程序编程接口(api)110访问ehr系统数据。ehr数据api 110可以被可操作地耦合到一个或多个电子健康记录数据提供方，诸如电子患者结果记录(epor)系统212、国家促进者214或其他健康网络。在一个示例性实施方案中，ehr数据api 110可以，除了其他功能之外，查询数据库、检索请求的信息、将数据写入数据库和修改数据。ehr数据api 110可以在服务器、独立运行的计算机、家用电器、软件即服务(saas)、平台
即服务(paas)或其他合适的设备上运行。
58.为了进一步例示ehr数据区块链系统200功能和能力，下文将呈现与药房交易相关的示例性实施方案。然而，ehr数据区块链系统200不限于并且不应限于药房交易。本文所公开的ehr数据区块链系统200考虑了需要患者数据的任何医疗保健交易。
59.在一个示例性实施方案中，医生可以将患者的处方输入到客户端计算机系统——诸如或其他合适的电子医疗记录(emr)系统230——内，该客户端计算机系统可以发起区块链交易280。该处方可以遭受预编辑和后编辑114、相互作用分析116、资格分析118和最终支付120。
60.在一个示例性实施方案中，医生通过客户端计算机系统——诸如或其他合适的电子医疗记录(emr)230——可以为特定患者编写处方。医生通过客户端计算机系统230可以向ehr数据api 110发送患者查找查询222，以确定ehr系统204是否具有与该特定患者相关的任何信息。客户端计算机系统230可以向ehr数据api 110发送具有患者识别信息——诸如患者的姓名、电话号码、地址、社会保障号码或其他合适的信息——的查询222。然后，ehr数据api 110可以查询ehr系统204以识别ehr系统204是否包括指定的患者的ehr 226。
61.在另一个示例性实施方案中，如果ehr系统204包括指定的患者的记录226，ehr数据api 110可以向客户端计算机系统返回单目的患者id(sppid)224。可以使用sppid 224代替患者可识别信息以确保患者隐私。在另一个示例性实施方案中，sppid 224可以仅在交易280完成之前被使用。下次提交与患者相关的区块链交易280时，可以向患者发出新的sppid 224，从而确保sppid 224不无限期地与患者相关联以进行所有未来交易。此过程可以确保即使单个sppid 224被泄露，使得患者的可识别信息(pii)206可以被确定，该泄露也将限于单个交易。在另一个示例性实施方案中，可以通过可以被用作唯一的标识符来保护进行交易的特定药房的身份的单目的药房id(spphaid)、可以被用作唯一的标识符来保护进行交易的特定医生的身份的单目的医生id(spphyid)以及可以被用作唯一的标识符以保护进行交易的特定付款者的身份的单目的付款者id(sppayid)来发布匿名。
62.在一个示例性实施方案中，一旦交易280完成，sppid 224仅可以被用来从区块链125读取与交易相关联的信息。在另一个示例性实施方案中，基于患者授予的许可，ehr系统204可以将交易数据和与患者相关联的其他交易、医疗设备数据等分组，用于报告、分析、药物研究等。例如，制药公司可能希望了解特定药物如何影响患者心率。可以从ehr系统204向药物制造商或应用程序234、238发送报告，其包括患者对指定药物的所有交易，以及在患者服用该指定药物时为患者积累的来自用户设备210的心率数据。在其原始形式中，sppid 224可以具有预定大小(例如，256位)，但是此值可以通过ehr数据api110散列成不同的大小。
63.在一个示例性实施方案中，医生经由客户端计算机系统230可以将区块链记录经由ehr数据区块链api 275(例如，ehr-data-bc-api)写入区块链125，以发起区块链处方交易280。区块链记录可以包括传统处方中的所有数据，所述数据包括药物名称、剂量、给药期等。在另一个示例性实施方案中，ehr数据区块链api 275可以生成通知，以向药物制造商234、238通知新的区块链处方交易280，以允许药物制造商234、238通过经由ehr数据区块链api 275将具有替代药物信息236的记录写入区块链125来提供区块链交易记录232中标识
的药物的替代品——满足与指示的药物相同的治疗需要的替代品。药物制造商234、238可以使用客户端计算机系统、制造商门户或其他合适的通信方式与ehr区块链api 275通信。在另一个示例性实施方案中，一个或多个药物制造商234、238可以将记录写入区块链处方交易280。记录232可以是账本条目、智能合约、文本文件或其他合适的数据容器。因为sppid 224的使用，相互竞争的药物制造商234、238不具有患者识别信息206，因此交易不存在违反健康保险流通与责任法案(hipaa)规则的风险，即使被放置在公共区块链上。
64.在一个示例性实施方案中，ehr数据区块链api 275可以向临床编辑提供方或应用程序242通知新的交易280，诸如处方交易。在另一个示例性实施方案中，临床编辑提供方242可以从区块链处方记录232检索sppid 224和处方药物信息，将sppid 224发送到ehr数据api110以检索特定患者的多组学数据，并且使用相互作用分析模块114或其他合适的软件确定是否需要对处方进行任何改变。临床编辑提供方242可以通过ehr数据api110检索特定患者的任何可得的ehr信息(包括基因组数据、新陈代谢数据等)，以确定处方对该特定患者的适用性。在另一个示例性实施方案中，临床编辑提供方242可以通过ehr区块链api 275将基因组相互作用记录244写入区块链处方交易280，从而经由预编辑和后编辑模块114或其他合适的软件相应地编辑处方。记录244可以是在给定的某些条件下执行以实现特定结果的智能合约，诸如依照特定患者基因组相互作用确定来编辑处方记录232。
65.在一个示例性实施方案中，ehr区块链api 275可以向dur编辑提供方或应用程序246通知新的交易280，诸如处方交易。dur编辑提供方246可以从区块链处方记录232检索sppid 224和处方药物信息，将sppid 224发送到ehr数据api 110以检索特定患者的处方历史数据，并且确定是否存在任何药物相互作用使得需要对处方进行改变。在另一个示例性实施方案中，dur编辑提供方246可以通过ehr数据api 110检索特定患者的任何可得ehr信息(包括过敏数据、新陈代谢数据、先前的反应数据、正在服用的活性药物等)，以确定处方对该特定患者的适用性。dur编辑提供方246可以通过ehr区块链api 275将药物相互作用记录248写入区块链处方交易280，从而相应地编辑处方。此外，此记录248可以是在给定的某些条件下执行以实现特定结果——诸如依照药物相互作用确定对处方的编辑——的智能合约。
66.在一个示例性实施方案中，ehr区块链api 275可以向付款方或应用程序250通知新的交易280，诸如处方交易。由ehr区块链api 275生成的通知可以包括电子邮件、文本、软件提醒和其他合适的通知。可以通过网络130发送通知。在另一个示例性实施方案中，付款方250可以从区块链处方交易280检索sppid 224，将sppid 224发送到ehr数据api 110以检索特定患者的保险数据，并且经由资格分析模块118或其他合适的软件确定该患者对处方的资格。付款方可以通过ehr数据api 110检索特定患者的任何可得ehr信息(包括姓名、地址、生日、社会保障号码、账户信息、组id、订阅者id、早先存在的病症、处方历史等)，以确定特定患者是否有资格按处方配药。在另一个示例性实施方案中，患者的健康保险信息可以与来自记录232的信息相关联以确定药物、产品或服务是否被覆盖。在另一个示例性实施方案中，付款方250可以被告知患者不能够使仿制药物(generic drug)发生新陈代谢，所述仿制药物可以在付款方处方集(formulary)上。付款方250可以通过ehr区块链api 275将资格记录252写入区块链处方交易280，从而指示资格。资格记录252可以是在给定的某些条件下执行以实现特定结果——诸如资格的指示——的智能合约。
67.在一个示例性实施方案中，ehr区块链api 275可以向中央配药设施提供方或应用程序254通知新的交易280，诸如处方交易。中央配药设施提供方254可以从区块链处方交易280检索处方信息以确定在中央配药设施中处方是否可得并且提供履行选项信息。中央配药设施提供方254可以通过ehr区块链api 275将履行选项记录256写入区块链处方交易280，从而指示与处方相关的患者可得的任何履行选项。此外，此履行选项记录256可以是在给定的某些条件下执行以实现特定结果——诸如递送选项的选择——的智能合约。智能合约可以根据接收到的患者信息(例如，偏好或法律要求等)自动执行，或可以经由用户设备210提示患者进行选择。此外，智能合约可以要求来自一个或多个来源的输入来执行。
68.在一个示例性实施方案中，一旦已经确定了履行选项，就可以最终确定处方，使得患者可以去药房按处方配药。ehr区块链api 275可以向药房提供方或应用程序258通知新的交易280，诸如处方交易。药房提供方258可以从区块链处方交易280检索处方信息以选择药物、药房希望从其发药(dispense)的ndc或药物价格以及其他选择。在另一个示例性实施方案中，药房提供方258可以通过ehr区块链api 275将经修改的处方记录260写入区块链处方交易280，从而指示与处方相关的所选择的药物、ndc和药物价格。此外，此记录260可以是在给定的某些条件下执行以实现特定结果——诸如药物的选择、ndc和药物价格——的智能合约。
69.在一个示例性实施方案中，ehr区块链api 275可以向定价编辑提供方或应用程序262通知新的或经修改的交易280，诸如处方交易。定价编辑提供方262可以从区块链处方交易280检索处方信息以确定药物定价是否正确。传统上，直到患者试图为药物付费时定价编辑才发生。在另一个示例性实施方案中，中央配药设施提供方262可以通过ehr区块链api 275将定价记录264写入区块链处方交易280，从而解决与处方相关的任何定价问题。在另一个示例性实施方案中，记录264可以是在给定的某些条件下执行以实现特定结果——诸如药物的重新定价——的智能合约。sppid 224可以与记录266一起存储。
70.在一个示例性实施方案中，在接收到定价编辑260之后，药房提供方258可以接受药物的重新定价。药房提供方258可以通过ehr数据区块链api 275将最终定价记录266写入区块链处方交易280，从而指示药物和设置药物的最终价格以用于处方的履行。此外，此记录266可以是在给定的某些条件下执行以对药物重新定价的智能合约。
71.在一个示例性实施方案中，ehr区块链api 275可以向付款方或应用程序250通知新的或经修改的交易280，诸如处方交易。付款方可以从区块链处方交易280检索处方信息以确定它被授权支付的价格。付款方250可以通过ehr区块链api 275将支付价格记录写入区块链处方交易，它将为处方履行付费的价格。此外，此记录可以是在给定的某些条件下执行以实现特定结果——诸如指示药物和支付价格金额——的智能合约。
72.在一个示例性实施方案中，ehr区块链api 275可以向药房提供方或应用程序258通知新的或经修改的交易280，诸如处方交易。药房提供方可以从区块链处方交易280检索处方信息，以指示用于处方履行的来自付款方的最终支付。药房提供方可以通过ehr区块链api将支付价格记录268写入区块链处方交易，从而指示药物和最终支付的价格。此外，此记录可以是在给定的某些条件下执行以实现特定结果——诸如指示支付的最终付款金额——的智能合约。sppid 224可以与记录268一起存储。
73.在一个示例性实施方案中，一旦药房提供方已经指示了最终金额，药物就可以被
递送到患者。一旦药物已经被递送，就可能发生附加的功能，诸如结束记录的写入、支付激励、奖励积分或其他合适的功能。在另一个示例性实施方案中，药物制造商可以为待被发药的特定药物提供激励272。激励272可以经由数字货币、奖励账户或其他合适的机构被分配给患者。在另一个示例性实施方案中，药房提供方258可以向临床编辑提供方242为与识别患者不能够使特定药物发生新陈代谢的处方交易280相关的基因组/多组学信息228付费。支付272可以经由数字货币、账户或其他合适的机构被分配给临床编辑提供方242。在另一个示例性实施方案中，药房提供方258可以向定价编辑提供方262为与用于特定药物的处方交易280相关的定价信息付费。支付272可以经由数字货币、账户或其他合适的机构被分配给临床编辑提供方242。在另一示例性实施方案中，付款方250可以向药房提供方258为处方的履行付费。支付272可以经由数字货币、账户或其他合适的机构被分配给临床编辑提供方。
74.在一个示例性实施方案中，访问ehr数据区块链125的每个实体可以查看区块链125上的每个记录的内容。在另一个实施方案中，可以限制或拒绝对区块链125上的每个记录的内容的读取访问。
75.在一个示例性实施方案中，被称为ehrcash
tm
的效用代币和智能合约平台可以被用来精简利益相关者和患者之间的支付，从而消除对应收账款和应付账款系统的需要。ehrcash
tm
可以多种形式存在，但是特定形式可以被用于特定交易。在另一个示例性实施方案中，ehrcash
tm
可以原产于底层支付区块链(bsv)或基于fiat稳定币(例如，美元、欧元、英镑等)。在另一个示例性实施方案中，代币可以：
76.·
为了观看患者教育视频、阅读教育博客和患者的数据的许可使用而便于对患者的货币奖励；
77.·
便于处方的支付和保险处方的共付额；
78.·
为了药房的数据的许可利用而便于对药房的货币奖励；以及
79.·
便于来自付款方的支付。
80.患者门户
81.在一个示例性实施方案中，患者门户可以由服务器102提供。可以通过用户接口或患者门户api访问患者门户。患者门户可以软件、硬件、应用程序编程接口(api)、网络连接、网络传输协议、html、dhtml、javascript、dojo、ruby、rails、其他合适的应用程序或其合适的组合来实现。在另一个示例性实施方案中，患者门户可以允许患者：
82.·
与以下沟通：
83.ο医生
84.ο药房
85.ο递送服务
86.ο其他患者
87.ο诸如此类。
88.·
查看、添加、修改和删除他们自己的医疗信息
89.·
查看他们的用药历史
90.·
连接和配置移动医疗应用程序(mma的)和设备
91.·
连接和配置移动健身应用程序(mfa的)和设备
92.·
连接和配置物联网(iot)应用程序和设备
93.·
查看来自连接的应用程序和设备的历史数据
94.·
查看从实时救护车装备收集的历史数据。
95.·
查看他们的ehrcash
tm
账户余额。
96.·
管理他们的ehrcash
tm
代币。
97.·
添加、修改和删除与授予对他们的数据的访问相关联的许可。
98.在另一个示例性实施方案中，从门户，用户可以审查他们的药房和临床数据、询问他们的药剂师问题、参与治疗会话或请求重新按处方配药。此外，用户可以请求临床预约、预先输入免疫数据、搜索具有特定出售品的药房、选择mma许可以及使用ehrcash
tm
。
99.mma许可
100.在一个示例性实施方案中，一旦登录ehr患者门户，患者就可以修正他们的被称为mma许可的数据共享选项。在另一个示例性实施方案中，通过使他们的数据能够与第三方共享，患者可以将他们的账户注册在ehrcash
tm
计划中，其中每次患者的数据被共享，一部分计划资金将转给患者。
101.ehrcash
102.在一个示例性实施方案中，可以通过在ehr患者门户处的数据共享向患者提供ehrcash
tm
。ehrcash
tm
可以是一种代币化(tokenize，令牌化)数字货币，患者可以通过几种不同渠道兑换，所述渠道包括礼品卡、处方购买、健康支出账户、在线购买和其他合适的媒介。
103.可穿戴设备用例
104.在一个示例性实施方案中，通过集成本文所描述的系统，患者可以接收可穿戴设备作为他们参与制造商赞助的数据共享计划的交换。通过可穿戴设备收集的数据可以被添加到患者的ehr，这可以使其可用于未来的共享机会。在另一个示例性实施方案中，步数、心率、血压、活动、睡眠周期等可以作为测量的结果通过系统添加。对于每个附加的监测系统，可以创建患者的更完整的ehr，因此变成更有价值的共享工具。
105.简介评级(profile rating)
106.在一个示例性实施方案中，患者简介可以通过数据的完整性和数量来分类。通过将lab、处方、临床机会等添加到患者的简介，它变得对于制造商而言更完整和更有价值的记录。在另一个示例性实施方案中，每次较高评级的简介被共享，它可以为患者赢得更多的ehrcash
tm
。
107.医生门户
108.在一个示例性实施方案中，医生门户可以软件、硬件、应用程序编程接口(api)、网络连接、网络传输协议、html、dhtml、javascript、dojo、ruby、rails、其他合适的应用程序或其合适的组合来实现。在另一个示例性实施方案中，医生门户可以允许医生：
109.·
管理人口统计信息
110.·
管理法律信息
111.·
管理认证参考
112.·
管理数字身份参考
113.·
管理联系信息
114.·
与他们的患者联系，以：
115.ο关于医疗信息、问题、并发症等进行沟通。
116.ο审查患者的医疗历史。
117.ο审查来自各种各样的开处方者的当前用药。
118.ο审查从医疗、健身和iot设备收集的数据。
119.·
与药房沟通以：
120.ο审查处方编辑结果
121.ο授权附加重新按处方配药
122.ο改变用药
123.ο停止用药
124.·
查看他们的ehrcash
tm
账户余额。
125.·
管理他们的ehrcash
tm
代币。
126.药物制造商门户
127.在一个示例性实施方案中，药物制造商门户可以软件、硬件、应用程序编程接口(api)、网络连接、网络传输协议、html、dhtml、javascript、dojo、ruby、rails、其他合适的应用程序或其合适的组合来实现。在另一个示例性实施方案中，药物制造商门户可以允许药物制造商：
128.·
管理人口统计信息
129.·
管理法律信息
130.·
管理联系信息
131.·
请求针对特定药物列表的多种多样的数据报告和由医疗设备收集的相关联的数据。
132.·
请求多种多样的分析报告
133.·
管理教育视频
134.·
管理与教育视频相关联的奖励金额和参数
135.·
查看他们的ehrcash
tm
账户余额。
136.·
管理他们的ehrcash
tm
代币。
137.药房门户
138.在一个示例性实施方案中，药房门户可以软件、硬件、应用程序编程接口(api)、网络连接、网络传输协议、html、dhtml、javascript、dojo、ruby、rails、其他合适的应用程序或其合适的组合来实现。在另一个示例性实施方案中，药房门户可以允许药房：
139.·
管理人口统计信息
140.·
管理法律信息
141.·
管理认证参考
142.·
管理数字身份参考
143.·
管理联系信息
144.·
通过以下方式管理财务、临床和多组学编辑：
145.ο选择待被执行的编辑
146.ο为所选择的编辑定义和加载合格规则(qualification rule)
147.·
查看他们的ehrcash
tm
账户余额。
148.·
管理他们的ehrcash
tm
代币。
149.·
选择中央配药提供方
150.·
选择处方递送提供方
151.·
选择库存管理提供方
152.验证
153.在一个示例性实施方案中，ehr数据区块链系统200可以在登录药房门户、医生门户、患者门户和药物制造商门户时为用户提供“无密码”体验，包括诸如fido2标准等的标准。
154.安全性——fido2加密登录凭证在每一个网站上是唯一的，从未离开用户的设备，也从未被存储在服务器上。此安全模型消除了网络钓鱼、所有形式的密码盗窃和重放攻击的风险。
155.方便——用户可以使用简单的内置方法——诸如他们的设备上的指纹读取器或摄像头——或通过利用易于使用的fido安全密钥来解锁加密登录凭证。消费者可以选择最适合他们的需要的设备。
156.隐私——因为fido加密密钥对于每个互联网站点是唯一的，所以它们不能够被用来跨站点跟踪用户。再者，生物特征数据当被使用时从未离开用户的设备。
157.可扩展性——网站可以通过简单的javascript api调用来启用fido2，该调用在消费者每天使用的数十亿设备上的主流浏览器和平台上得到支持。
158.数字身份
159.在一个示例性实施方案中，数字身份可以由用于医生门户、药房门户和患者门户的面向公众的部件的系统实现。例如，在社交媒体上互动时，医生的数字身份可能被暴露。这些身份可以是跨管理域、应用程序和任何其他组织筒仓可共同操作的(interoperable)。
160.数字认证
161.在一个示例性实施方案中，认证可以由用于医生门户、药房门户和患者门户的面向公众的部件的系统实现。例如，医生可以在医生门户内参考他们的认证，这可以被用来：支持他们的数字身份、吸引新的业务、当在我们的社交媒体平台上互动时证明认证以及其他相关用途。
162.隐私
163.在一个示例性实施方案中，记录到区块链125的处方、处方交易和医疗数据不包含对患者、医生或药房实体的直接参考。使用单向加密技术根据实体的私人id生成的一次性使用的公共id可以使实体的实际身份混淆。此技术可以允许私人id的持有者能够出于报告目的链接他们的身份。在另一个示例性实施方案中，所有数据可以图表/层次结构形式存储在区块链上。每个节点可以在图表/层次结构中包含可以使用其自己的加密密钥进行加密的特定信息(例如，患者姓名、地址、用药等)。此图表/层次结构在区块链上可能不可见，并且从而提供数据结构的混淆。在另一个示例性实施方案中，仅患者/用户的主私人密钥可以理解该结构。
164.私密患者记录
165.在一个示例性实施方案中，患者的私人id从未被泄露，并且可以被用来识别患者
的医疗记录。患者的医疗记录可以包含信息，诸如：
166.·
姓氏
167.·
中间名字
168.·
第一名字
169.·
昵称
170.·
生日
171.·
性别
172.·
由以下组成的地址：
173.ο地址栏(address line)
174.ο城市
175.ο州
176.ο邮政编码
177.·
移动电话号码
178.·
座机号码
179.·
保险id
180.·
医疗历史
181.·
诊断
182.·
用药
183.·
治疗计划
184.·
免疫接种日期
185.·
过敏
186.·
多组学数据
187.·
实验室测试
188.·
实验室结果
189.·
放射学图像
190.·
移动医疗应用程序数据
191.·
移动健身应用程序数据
192.·
医疗设备数据
193.·
健身设备数据
194.·
物联网设备数据
195.·
其他。
196.私人医生记录
197.在一个示例性实施方案中，可以使用bip-0032算法生成医生的私人密钥和公共密钥。医生的私人密钥未被泄露并且可以被用来识别医生的信息。医生的信息可以包括：
198.·
姓氏
199.·
中间名字
200.·
第一名字
201.·
昵称
202.·
生日
203.·
性别
204.·
由以下组成的地址：
205.ο地址栏
206.ο城市
207.ο州
208.ο邮政编码
209.·
移动电话号码
210.·
座机号码
211.·
特长
212.·
许可证号码
213.·
资格证书
214.·
其他相关信息。
215.私人药房记录
216.在一个示例性实施方案中，药房的私人密钥从未被暴露并且被用来识别药房细节。药房详细信息可以包含诸如以下信息：
217.·
姓
218.·
链码
219.·
由以下组成的地址：
220.ο地址栏
221.ο城市
222.ο州
223.ο邮政编码
224.·
移动电话号码
225.·
座机号码
226.·
服务
227.·
许可证号码
228.·
身份证号码
229.·
诸如此类。
230.授予许可
231.在一个示例性实施方案中，每个实体可以具有门户，该门户可以允许该实体向第三方授予使用区块链中包含的一个特定数据项或一系列数据项的许可。在另一个示例性实施方案中，在用户/实体已经授予对他们的ehr数据的特定数据元素的读取和/或写入访问许可之后，可以为了用户/实体创建“授权代币”(例如，authtoken)。例如，“authtoken”可以具有特定的使用期(或生存时间)，并且仅通过来自用户/实体的授权进行重新开始。在另一个示例性实施方案中，门户的管理主体、政府(例如，地区、国家等)和执法机构可以被授予可以允许他们检索实体的细节的特权。一旦被泄露，这些细节必须在相关联的政府法规(例如hippa)的范围内得到保护。实体私人密钥可能从未被泄露。
232.在另一个示例性实施方案中，药物制造商可以在特定日期范围之间请求尽可能多的患者的去标识化(deidentified，去身份)数据。请求的数据可以包括：特定ndc的处方交
易数据、患者医疗细节和特定移动医疗应用程序数据。当实体接收到此请求时，它可以实施以下：
233.·
检索与药物代码匹配的所有交易。
234.·
确定与交易相关联的实体。
235.·
确定实体对被请求的特定类型的数据是否具有默认许可或特定许可。如果不具有，实体将被联系并且许可将被请求。
236.·
一旦已经确定了所有许可，结果集将被返回给药物制造商。
237.数据查询
238.在一个示例性实施方案中，数据查询可以由区块链的任何构件使用。查询区块链的请求可以包括以下：
239.·
请求者id
240.·
请求者使用(财务、研究等)
241.·
请求描述
242.·
请求类型
243.·
请求数据类型
244.ο数据字段
245.·
请求日期范围
246.·
请求奖励。
247.所选择的预定义请求类型可以指示：
248.·
数据类型(处方、处方交易、医疗设备数据等)
249.·
每个数据类型内的期望的字段。
250.在另一个示例性实施方案中，可以基于由相关联的患者授予的许可以及由请求类型指定的选择标准对通过查询返回的数据过滤。
251.本公开内容至少实现了以下优点：
252.1.通过利用ehr患者交易区块链作为工作流空间来处理交易直到交易完成、被签署和被分发以达成共识来提高传统系统的性能。
253.2.实施智能合约以确定和定义工作流过程、药物相互作用、履行、预期结果、触发事件和定价等数据元素；
254.3.从计算代价高昂的数据存储、数据瓶颈和系统查询减少附加的处理资源的利用和网络利用；
255.4.生成交易的不可改变的记录以供后续审查和审计；
256.5.提供用于提供简单并且有效的处方编辑、处理和支付、利用数字货币和api来便于交易的平台；以及
257.6.访问和检索患者可识别信息(pii)并且生成特定患者的非患者可识别单目的患者id(sppid)以供在离散交易中使用。
258.本领域技术人员将容易理解，在没有组装在本发明系统中并且在本文中描述的计算机硬件和其他结构部件和机构的特定组合的情况下，此系统的这些优点(以及发明内容中指出的优点)和目标将是不可能的。还应理解，本领域技术人员已知的各种各样的编程工具可用于实施对前述材料中所描述的特征和操作的控制。此外，编程工具的特定选择可能
由被置于为实现在本文中和在所附权利要求中阐述的构思而选择的实施计划上的特定目标和约束控制。特别地，可以在本文中所描述的新的和非常规的方式利用商业现货(cots)装备的集成来实现权利要求书的一个或多个方面。
259.本文所包含的描述不应被理解为暗示，任何特定元件、步骤或功能可以是必须被包括在权利要求范围内的必要元件或关键元件。此外，没有任何权利要求意在关于所附权利要求或权利要求要素中的任何一个援引35u.s.c.
§
112(f)，除非在特定权利要求中明确使用了确切的词语“用于
……
的装置”或“用于
……
的步骤”，随后是叙述的功能。包括但不限于权利要求中的“机构”、“模块”、“设备”、“单元”、“部件”、“元件”、“构件”、“装置”、“机器”、“系统”、“处理器”、“处理设备”或“控制器”的术语的使用可以被理解并且意在指代相关领域技术人员已知的结构，如由权利要求本身的特征进一步修改或增强的，并且不意在援引35u.s.c
§
112(f)。
260.在不背离本公开内容的精神或本质特性的情况下，本公开内容可以其他特定形式体现。例如，本文所描述的新的结构中的每个可以被修改以适应特定的局部变化或要求，同时保留它们之间的基本配置或结构关系，或同时执行本文所描述的相同或类似的功能。因此，本实施方案在所有方面都被认为是例示性的而不是限制性的。因此，本发明的范围由所附权利要求确立而不是由前述描述确立。因此，落入权利要求的含义和等效范围内的所有改变都意在被包含在其中。此外，权利要求的各个元素不是为人所熟知的、惯例的或常规的。相反，权利要求针对在说明书中所描述的非常规的发明构思。