CN114144771A - 用于确保药物疗法的系统和方法 - Google Patents

Abstract

一种用于定制与药物治疗相关的用户参数的系统，该系统以第一格式接收与药物治疗相关联的参数的第一集合，参数指示与药物治疗相关联的因素。该系统基于一个或多个因素确定第一参数的集合的子集并将它们转换成第二格式。该系统向第二计算设备提供参数的第二集合，从第二计算设备接收参数的第三集合，其中参数的第三集合基于一个或多个因素，参数的第三集合以第三格式提供，基于参数的第二集合将参数的第三集合从第二第三格式转换成第一格式，并将从第二计算设备接收的转换后的参数的第三集合呈现给第一计算设备方。

Description

用于确保药物疗法的系统和方法

相关申请的交叉引用

本申请要求于2019年6月26日提交的标题为“SYSTEM AND METHODS FORIMPLEMENTING AN EXCHANGE TO EXPEDITE NEGOTIATIONS”的美国临时申请62/867,014和于2019年12月12日提交的标题为“SYSTEMS AND METHODS FOR IMPLEMENTING AN EXCHANGETO EXPEDITE NEGOTIATIONS”的美国临时申请62/947,453的权益，其内容通过引用整体并入本文。

技术领域

本公开涉及加速复杂决策过程的平台，该平台可以跨越组织并结合解决问题、协商和合作的要素。

背景技术

全新类型的药物疗法正在由公共研究组织和私营部门的创新者开发，以对抗各种疾病。基因组学、表观遗传学和系统生物学方面的科学突破正在取得成效。药物管线(drugpipeline)不断突破，包括靶向免疫治疗、细胞和基因疗法等。

但是，当今的市场准入过程滞后于科学创新。制药公司和政府对新型创新药的创新定价策略(如基于适应症的定价和基于价值的定价)感到兴奋，但双方之间的协商时间太长，即使只有两方参与。如果有三方或更多方，那么协商甚至会更加复杂，而且由于反垄断问题，常常不允许协商。因此，各种已获监管机构批准但尚未触及患者的药物疗法陷入僵局。患者没有得到他们需要的药物；公司没有出售他们的最新疗法；并且政府和提供者无法为他们的患者提供服务。需要新的协商系统来反映科学创新和市场上疗法的新现实。

发明内容

在一些实施例中，一种用于定制与确保药物治疗相关的用户参数的计算机化的系统包括存储器和通信耦合到存储器的处理器，其中处理器被配置为从第一计算设备接收与药物治疗相关联的参数的第一集合，其中参数的第一集合中的一个或多个参数指示与药物治疗相关联的一个或多个因素，基于在参数的第一集合中接收的信息以第一格式提供参数的第一集合中的一个或多个参数；将接收到的参数的第一集合变换成参数的第二集合，其中将参数的第一集合变换成参数的第二集合包括：基于一个或多个因素确定第一参数的集合的子集，基于一个或多个因素确定第一参数的第二格式。计算机化的系统向第二计算设备提供参数的第二集合，从第二计算设备接收与药物治疗相关联的参数的第三集合，其中参数的第三集合基于与治疗相关联的一个或多个因素，参数的第三集合以第三格式提供，基于参数的第二集合将协商价格的参数的第二第三集合从参数的第二第三格式转换成第一格式，并向第一计算设备方呈现从第二计算设备接收的经转换的参数的第三集合。

在一些实施例中，参数的第一集合包括有资格接受药物治疗的患者的数量、治疗的持续时间、每位患者的药物治疗的预期价格以及每位患者的预期返利。在一些实施例中，有资格接受药物治疗的患者的数量可以是一。在一些实施例中，被配置为确定参数的第一集合的子集的计算机化系统还被配置为基于确定与参数的第一集合相关联的一个或多个参数具有与之相关联的隐藏标志来排除参数的第一集合的一个或多个参数。在一些实施例中，与药物治疗相关联的一个或多个因素包括预定的平均患者身高、预定的平均患者体重和预定的平均患者表面积，以及治疗的持续时间。

在一些实施例中，权利要求的计算机化的系统还被配置为基于与药物治疗相关联的一个或多个因素来确定每位患者的药物治疗的平均剂量需求。在一些实施例中，计算机化的系统还被配置为基于药物治疗的平均剂量要求和治疗的持续时间来确定患者所需的药物治疗包的数量。在一些实施例中，参数的第三集合包括每包药物治疗包的提供价格和药物治疗的提供返利。

在一些实施例中，计算机化的系统还被配置为基于与药物治疗相关联的一个或多个因素将每包药物治疗的确定价格转换成药物治疗的每位患者的价格。在一些实施例中，计算机化的系统还被配置为比较药物治疗的预期价格与药物治疗的提供价格，并响应于确定药物治疗的预期价格与药物治疗的提供价格在彼此的预定范围内而向第一计算设备和第二计算设备提供同意信号。

在一些实施例中，计算机化的系统还被配置为响应于确定药物治疗的预期价格和药物治疗的提供价格在彼此的预定范围之外而向第一计算设备和第二计算设备提供不同意信号。在一些实施例中，发送到第一计算设备的不同意信号还包括基于与第一计算设备相关联的历史数据以及预期价格与提供价格之间的差异的药物治疗的建议的预期价格。在一些实施例中，发送到第二计算设备的不同意信号还包括基于与第二计算设备相关联的历史数据以及预期价格与提供价格之间的差异的药物治疗的建议的提供价格。在一些实施例中，计算机化的系统还被配置为响应于不同意信号而从第一计算设备接收药物治疗的更新后的预期价格，并且响应于不同意信号而从第二计算设备接收药物治疗的更新后的提供价格。

在阅读以下附图、详细描述和权利要求之后，将更全面地理解所公开的主题的这些和其它能力。应该理解的是，本文采用的措辞和术语是为了描述的目的，而不应该被认为是限制性的。

附图说明

当结合以下附图考虑时，参考以下对所公开的主题的详细描述，可以更全面地理解所公开的主题的各种目的、特征和优点，其中相同的附图标记表示相同的元件。

图1示出了根据本公开的一些实施例的系统100的框图。

图2描绘了根据本公开的一些实施例的提供给支付者的协商引擎108的界面。

图3描绘了根据本公开的一些实施例的在协商引擎中创建新交易空间的界面。

图4描绘了根据本公开的一些实施例的在协商引擎中创建的新交易空间内创建新交易的界面。

图5描绘了根据本公开的一些实施例的协商引擎的交易空间的示例性界面。

图6描绘了根据本公开的一些实施例的从图5的界面500发起的“持续时间上限返利”的界面。

图7描绘了根据本公开的一些实施例的从图5的界面500发起的“疗法中断返利”的界面。

图8是描绘根据本公开的一些实施例的在将交易提议提交给制药公司之前的交易提议的概要的界面。

图9描绘了根据本公开的一些实施例的提供给制药公司的协商引擎的界面。

图10描绘了根据本公开的一些实施例的呈现给制药公司以响应提出的协商的界面。

图11描绘了根据本公开的一些实施例的在协商期间呈现给支付者的界面。

图12描绘了根据本公开的一些实施例的两方之间的协商过程的说明性流程图。

具体实施方式

根据本公开的实施例，公开了加速多个组织之间的复杂决策过程并结合解决问题、协商和合作的要素的系统和方法。

全新类型的药物疗法正在由公共研究组织和私营部门的创新者开发，以对抗各种疾病。基因组学、表观遗传学和系统生物学方面的科学突破正在取得成效。药物管线不断突破，包括靶向免疫治疗、细胞和基因疗法等。

但是，这些新类型的药物疗法无法以与其被开发相同的速度进入市场。通常，生产药品的制药公司与购买药品的政府(也称为支付者)之间的协商过程滞后于科学创新。制药公司和支付者正在寻找用于基于新药疗法的治疗方案的创新定价策略，如基于适应症的定价和基于价值的定价。但有关各方之间的协商时间太长。对于联合疗法，如果涉及三方或多于三方，那么协商就甚至更加复杂，并且常常由于反垄断问题而不被允许。

因此，监管机构已批准但尚未偿付的疗法陷入僵局。患者没有得到他们需要的药物；公司没有出售他们的最新疗法；并且支付者和提供者无法为他们的患者提供服务。需要新的协商系统来反映科学创新和市场上疗法的新现实。

图1示出了根据本公开的一些实施例的系统100的框图。系统100可以包括m个支付者计算设备102A-102m、n个制药公司计算设备104A-104n和o个第三方110A-110o。在一些实施例中，每个计算设备102A-102m与不同的支付者相关联，每个计算设备104A-104n与不同的制药公司相关联，并且每个计算设备110A-110o与不同的第三方相关联。在一些实施例中，多于一个用户被授权访问通过计算设备102A-m、104A-n和110A-o中的每个计算设备路由的信息。计算设备102A-m、104A-n和110A-o中的每一个处的管理员可以将与相应计算设备相关联的相关授权用户划分为各种团队。这有助于允许将信息直接自动路由到与该信息相关联的授权用户。在一些实施例中，管理员基于他们可以访问的产品将用户分组为逻辑实体。在一些实施例中，与计算设备102A-m之一相关联的制药公司可以在与该制药公司相关联的组织中具有肿瘤学团队和心血管团队。即使在肿瘤学中，一个团队可以负责乳腺癌产品，而另一个团队负责肺癌产品。在一些实施例中，可以针对相同的产品但不同的适应症建立团队，例如，与计算设备102A相关联的制药公司的团队A可以处置针对黑色素瘤的Keytruda，而与计算设备102A相关联的制药公司的团队B可以处置针对肺癌的Keytruda。表1-3描绘了在制药公司102A和支付者104A中创建的团队的示例，并且协商是针对用于适应症A的产品A和用于适应症A的产品B。

表1

表2

表3

在一些实施例中，多个计算设备102A-m、104A-n可以是同一制药公司或支付者的一部分。在一些实施例中，如所描述的，为了便于信息分发，可以将这些用户划分为团队。在一些实施例中，协商引擎108的管理员定义了不同级别的许可，这些许可可以授予作为制药公司或支付者的一部分的各种用户。例如，许可可以基于地域限制和关于药物疗法的限制。因此，用户可以具有查看与特定国家或特定地区的政府进行的所有协商的许可。在一些实施例中，许可可以允许用户查看特定制药公司或支付者的协商。在一些实施例中，许可可以包括查看所有协商而无需任何编辑协商或对协商进行任何改变的许可。在一些实施例中，许可可以包括甚至查看已经对其它协商方隐藏的那些协商参数。例如，支付者可以选择对制药公司隐藏协商的初始价格，但如果有适当的许可，那么第三方用户可以能够查看支付者录入的协商的价格。

在一些实施例中，可以使用许可的集合来创建角色。许可的指派可以动态地进行。角色结合可以随时修改的许可的集合，而无需修改角色本身。可以基于管理员对具有角色的决定或客户的需要在任何给定时间在系统中创建角色。一些示例性角色是管理员只读、管理员用户、支付者管理员用户、支付者用户、支付者只读用户、医药管理员用户、医药只读用户、医药用户。管理员只读用户可以被定义为不能创建/修改/删除任何基于管理员应用的工件的用户。管理员用户可以被定义为对任何管理员应用工件具有完全访问权的用户。支付者管理员用户可以被定义为作为支付者的组织内的“协商引擎管理员”的支付者用户。支付者用户可以被定义为具有运行协商的能力的支付者用户。支付者只读用户可以被定义为对协商具有只读访问权的支付者用户。医药管理员用户、医药用户和医药只读用户的定义可以与其对应支付者用户类似。在一些实施例中，可以定义特定于支付者和医药用户的标准许可。在一些实施例中，可以定义特定于协商引擎108的“管理员”用户的高级许可。

在一些实施例中，政府、非政府、捐赠者、对冲基金、保险公司、金融机构、高净值个人或其他中间人可以是第三方的示例，其可以介入以为来自新兴市场的支付者保证支付。在一些实施例中，对冲基金可以是第三方的示例，其可能愿意承担与支付者与制药公司之间的协商相关联的一些风险。在一些实施例中，数据提供者可以是第三方的示例，其可以“出价”以提供用于清算支付者与制药公司之间的支付的数据。在图1的示例中，m、n和o可以是大于或等于一的任意大的有限整数。支付者和制药公司可以经由网络106连接到协商引擎108。在一些实施例中，网络106可以是无线局域网、局域网、互联网或任何其它形式的网络中的任何一种。

协商引擎108接收并评估来自双方(支付者102A-m和制药公司104A-n)的报价。协商引擎108可以由与支付者102A-m、制药公司104A-n或第三方110A-o不相关的管理员执行和维护。管理员可以向制药公司和支付者提供对协商引擎108的访问。在一些实施例中，管理员保持每个制药公司104A-n在特定时间点提供的所有产品的运行记录。在一些实施例中，产品的列表包括产品清单、产品特点以及适用于产品的产品包的列表的详细视图，其具有添加新产品、修改和删除现有产品的能力。

在一些实施例中，管理员还接收由一个或多个制药公司104A-n和一个或多个支付者104A-m商定的假设的基本集合。假设的基本集合可以包括平均患者体重、平均患者体表面积、做出假设的日期。通过包括每年施予患者的产品包的平均数量，这些假设可以针对每种产品定制。产品包是基于在预定的时间集合内施予患者的平均剂量确定的产品的单位。在一些实施例中，管理员可以基于与产品相关联的给药时间表来确定产品包和产品包的价格。从制药公司102A-m之一连同与新产品相关联的信息一起接收给药时间表。给药时间表包括开始周期、周期长度、结束周期和周期中所有天的给药，包括每天的产品施用次数以及单次施用剂量。在一些实施例中，当添加新产品时，制药公司可以将新产品添加到疗法方案。疗法方案可以包含一种产品(单一疗法)或多种产品(组合疗法)。在任何时候，管理员都可以创建具有属性(诸如诊断、方案代码、市场、疗法类型(单一或组合)、产品1、产品1初级包(primary pack)、产品1剂量计算方法、产品2(在组合疗法的情况下)、产品2初级包、产品2剂量计算方法)的新疗法。

在一些实施例中，提供给支付者的协商引擎108的界面可以不同于提供给制药公司的协商引擎的界面。在一些实施例中，协商引擎108可以相对于支付者102A-m和制药公司104A-n远程托管在web服务器上。

在一些实施例中，协商引擎可以包括不同的操作模式。在一些实施例中，协商引擎可以包括用于用户(支付者102A-m和制药公司104A-n)的多于一种环境。第一操作模式，也称为沙盒环境，可以是模拟环境。沙盒环境能够复制呈现给支付者和制药公司两者的界面。但是，对沙盒环境的访问仅限于在组织中工作的人，或与该组织相关的被提供了访问权的人。沙盒只是试用环境并且在沙盒环境中提出的买卖仅用于测试目的并且不产生后果。

第二操作模式，也称为终端环境，是可以导致绑定的买卖的真实世界环境。终端环境允许用户表达可以呈现给可以被邀请参与协商过程的其它组织的承诺。

支付者和医药数据以及支付者102A-m与制药公司104A-n之间的通信优选地被加密。

协商引擎108的界面的不同方面关于图2-16进行描述。用于药物疗法或方案的任何协商或交易都可以从支付者的一端通过协商引擎的支付者界面发起。在协商引擎的支付者界面中，协商可以按“适应症或疾病”分组，如下文更详细描述的。例如，支付者可以针对多发性骨髓瘤开启协商，无论使用何种疗法，所有针对多发性骨髓瘤的协商都将分组在同一空间中。此外，可以从制药公司的一端通过协商引擎的制药公司界面发起药物疗法或方案的协商或交易。在提供给制药公司的界面中，可以按提供的药物对协商进行分组。例如，制药公司可以将涉及特定药物(例如，Keytruda)的任何或所有协商分组，而不管可能开出它们的诊断。支付者指定协商参数，诸如合同期限、结构、方案、货币和定价单位，这些在下面更详细地描述。

图2描绘了根据本公开的一些实施例的提供给支付者的协商引擎108的界面。支付者102A-m中的任何一个都能够使用由负责管理协商引擎108的第三方提供给他们的凭证来访问协商引擎108。一旦支付者登录到协商引擎108，就向支付者呈现类似于界面200的界面。界面200包括可以被用于初始化新交易空间的按钮202。界面200还描绘了处于各个进展阶段的所有交易空间的概要204、206和208。交易空间是为特定诊断而发起的正在进行的协商的集合。如图2中所示，交易空间概要204描绘了针对非小细胞肺癌正在进行的交易的概要。交易空间概要204描绘了进行中的协商的数量、涉及的公司的数量、协商中产品的数量以及有资格的患者的数量。类似于交易空间概要204，交易空间概要206和208描绘了针对晚期黑色素瘤和多发性骨髓瘤的正在进行的协商的概要。交易空间概要204、206和208还包括关于交易空间的所有者的信息。交易空间的所有者可以是负责与识别出的诊断相关的协商的授权用户。

图3描绘了根据本公开的一些实施例的在协商引擎中创建新交易空间的界面。当用户点击图2的界面200中的按钮202以创建新交易空间时，生成图3中描绘的界面300。打开新交易空间所需的第一件事是要求药物疗法的诊断。在一些实施例中，可以从界面300中可用的下拉菜单302中选择诊断。在一些实施例中，下拉菜单302中可用的诊断可以基于各种制药公司已经提供给数据库管理员的产品和药物疗法来提供。

图4描绘了根据本公开的一些实施例的在协商引擎中创建的新交易空间内创建新交易的界面。一旦创建了新交易空间，用户就可以通过点击界面400的按钮402在新交易空间内创建新协商。为了开始新协商，协商引擎108要求被认为是协商的基石的某些信息。首先，支付者应当定义协商的合同期限404。在一些实施例中，可以使用在协商引擎108中实现的日历功能来选择合同期限404的开始日期和结束日期。其次，支付者应当从列表406中选择药物疗法，该药物疗法可以被用于治疗由交易空间识别出的所选择的诊断。列表406使用由与制药公司相关联的各种计算设备104A-n提供给管理员的信息填充在界面中。界面400还包括附加选项408。在一些实施例中，附加选项408可以包括指定支付者与制药公司之间协商的最大轮数的选项。一旦输入了所有信息，用户就可以按下按钮410以打开协商。

图5描绘了根据本公开的一些实施例的协商引擎的交易空间的示例性界面。在一些实施例中，协商引擎108的界面500描绘了Keytruda MSD的交易空间。交易空间界面500包括不同的区段。区段502是交易空间的标题。区段502包括子区段508，其包括在从图4的窗口400创建交易空间时指定的一些基本信息。区段502包括用于特定诊断的药物疗法。区段502的子区段508包括所选择的合同期限、发起协商的人的姓名、将进行协商的货币，以及在创建交易空间时指定的轮数。这些选项中的每一个都可以在任何时间使用在每个显示选项侧描绘的铅笔图标进行修改。

界面500的区段504描绘了接收价格输入以开始新协商的界面。区段504包括定价选项卡532。定价选项卡532包括定价单位下拉菜单522，其包括多个选项，例如年价格、季度价格、月价格和周期价格。周期价格反映单个患者一个周期的治疗。在一些实施例中，患者的一个治疗周期是3周。可能有患者不消费任何药物的第4周。在一些实施例中，随着周期的进行，药物的剂量可以改变。月价格反映单个患者一个月的治疗。季度价格反映单个患者一季度的治疗。年价格反映单个患者一年的治疗。

定价策略下拉列表520包括针对定价的不同患者策略。在一些实施例中，支付者可以添加相比其它疗法对特定疗法的偏好，并且界面可以允许支付者指定多个偏好。第一个定价策略是患者量。患者量定价基于接受治疗的患者的数量。因为患者量定价基于患者的数量，所以价格预配置可以基于接受治疗的患者总量而不同。输入字段524和534描绘了用于接收患者量的定价细节的输入。在524处，支付者可以指定最小患者量。在534处，支付者可以指定最大患者量，并且在526处，支付者指定针对录入的患者量的价格点。在一些实施例中，如果价格不根据量而改变，那么最大患者量字段可以留空。在一些实施例中，支付者可能希望分解定价患者量。在此类情况下，支付者可以为量相关的定价提议录入患者量中断和对应的新价格。在528处，支付者可以选择向制药公司“隐藏目标价格”。在一些实施例中，隐藏目标价格的选项可以是全局设置或个体设置。例如，在一些国家，所有数据或特定数据将始终被隐藏或始终可见，而在其它国家，支付者或制药公司可以自由选择他们想要做什么。选择这个选项将对其它协商方隐藏目标(组合)价格。在一些实施例中，可以定义患者量定价预配置中的附加预配置。这个附加预配置可以是“持续时间上限”。用于“持续时间上限”的界面可以通过按下按钮536来发起。这种持续时间上限返利允许在量预配置之上的附加预配置(例如，在预期市场份额不确定的情况下)。该界面在图6中更详细地描述。

下拉菜单520中的第二定价策略是治疗持续时间价格定价策略。治疗持续时间定价策略基于患者接受治疗多长时间。因此，基于每位患者接受治疗多长时间，治疗策略的价格将有所不同。在一些实施例中，治疗的持续时间可以分解成年、季度、月和周期。除了患者量定价策略中也可用的量中断之外，允许持续时间中断的选项。

图5的界面500包括在持续时间上限536选项卡536旁边的性能选项卡538。性能选项卡指定可以基于(治疗)性能进行价格预配置。性能选项卡的界面在图7中更详细地描述。

图5的界面500的区段510包括作为协商的基础的药物疗法的简要描述。这种简要描述常常被称为SPC(产品特点的概要)。SPC的一部分包括对有资格接受药物疗法的患者的描述。在一些实施例中，SPC是制药公司在创建这种药物疗法时提供给协商引擎108的管理员的信息。在一些实施例中，这个区段510包括子区段512，其中支付者能够修改针对这种药物疗法的患者的资格准则。在一些实施例中，区段510包括子区段514，其中支付者能够设置将为其提供这种药物疗法的患者的估计量。

界面500的区段506可视化在将药物疗法施予患者时的药物疗法的给药时间表。在一些实施例中，给药时间表由1个或多个给药时段组成，每个时段表示疗法中至少一种产品的改变的剂量。在一些实施例中，当将药物疗法添加到协商108时，将给药时间表提供给管理员。在一些实施例中，给药时间表设置模式允许用户指定开始周期和结束周期(或开放式周期)、周期长度、名称覆盖(默认情况下，名称是从周期开始和结束生成的，即，周期1-3)。周期中所有天的给药包括每天的产品施用次数，以及单次施用剂量。

界面500的区段530显示所选择的药物疗法的消费假设。消费假设的区段530有多个目的。首先，区段530视觉化协商的每个产品部分的初级包。初级包的概念在行业中是常见的，以协商特定包的定价并基于代数公式推导出其它包的价格。消费假设530能够可视化协商的每个产品部分的返利前(列表)价格。为用户公开链接以了解价格的性质(即，日期和定价来源，如右边所描绘的)。列表价格源自特定于市场(国家)的已知且可信的定价来源。如果在给定时段内将产品作为组合疗法的一部分，那么消费假设530可视化单个患者消费的包的平均数量。使用这个信息，消费假设区段530可视化对于协商的每个产品部分在给定时段(在这个示例中为年)单个患者的治疗的成本以及疗法的总成本(如果提供零返利的话)。最后，消费假设区段530能够将定价单元532与消费假设时段中指定的时段连接起来。在一些实施例中，如果用户想要协商每月返利，那么消费假设区段530将反映每月的数字。

协商引擎108包括计算单个患者在给定时段内将被施予的平均包数量的翻译器。通过具有该数量，管理员可以轻松地将时段价格翻译成包价格，反之亦然。这些是在消费假设区段530中示出的数字。

图6描绘了根据本公开的一些实施例的从图5的界面500发起的“持续时间上限返利”的界面。基于输入字段608中指定的特定比例的患者预期在输入字段602和604中指定的特定时段之后继续疗法的证据，图6的界面600在输入字段606中接收请求针对患者的价格返利(从1-100％)的输入。支付者可以选择在“注释”区段610中详细说明以定义在界面600中接收的其输入。支付者还可以通过选择选项612来选择向制药公司隐藏指定的返利。

图7描绘了根据本公开的一些实施例的从图5的界面500发起的“疗法中断返利”的界面。从图5的界面500的性能选项卡发起疗法中断返利界面。在一些实施例中，可以基于药物方案的性能来制定定价预配置。基于在输入字段708中指定的特定比例的患者预计将由于副作用/毒性或在输入字段902和704中指定的指定时段后对特定方案没有反应而中断疗法的证据，图7的界面700在输入字段706中接收请求针对患者的价格返利(从1-100％)的输入。支付者可以选择在“备注”区段710中详细说明以定义在界面900中接收的其输入。支付者还可以通过选择选项712来选择向制药公司隐藏指定的返利。

一旦支付者已经在图2-7中呈现的界面中指定了所有需要的信息，支付者就可以将他的提议提交给制药公司以供考虑。在一些实施例中，支付者可以保存协商输入的当前状态并且通过按下保存按钮516返回以完成协商。支付者可以通过按下图5的界面500中的提交按钮518来开始提交。在支付者提交可能的承诺之前，将向支付者显示类似于图8的界面800的弹出窗口。图8是描绘根据本公开的一些实施例的在将交易提议提交给制药公司之前的交易提议的概要的界面。图8的界面800的区段802总结了如图5的界面中指定的定价策略、定价单位和定价货币。呈现复选框804和806以确保数据的准确性和正确性以及隐私协议已被确认。一旦支付者确认信息并接受隐私政策，就可以通过按下按钮808将定价提议提交给其它协商方。

图9描绘了根据本公开的一些实施例的提供给制药公司的协商引擎的界面。制药公司104A-n中的任何一个都能够使用由负责管理协商引擎108的第三方提供给它们的凭证来访问协商引擎108。一旦制药公司登录到协商引擎108，与界面900类似的界面就被呈现给制药公司。界面900具有描绘制药公司参与的协商的标题902。区段904通过诊断来组织邀请制药公司参与的协商。如图9中所示，记录914总结由发起者914针对由904指定的诊断提出的协商。记录914描绘了由906中指定的发起者发起的针对产品916的协商。记录914还指定方案908、协商已经经过的轮数910和协商的当前状态912。

图10描绘了根据本公开的一些实施例的呈现给制药公司以响应提出的协商的界面。除了定价区段1002之外，图10的界面1000类似于图5的界面500。定价区段1002具有子区段1004，其显示由支付者提出的药物疗法的初始协商报价。在一些实施例中，如果支付者决定隐藏药物疗法的初始报价和相关参数，那么子区段1004的价格区段将显示“未公开”。

定价区段1002的子区段1006从制药公司接收药物疗法的提供价格。为了制药公司的方便，协商引擎108能够在字段1008中以每个初级包的价格接收药物疗法的价格。使用关于图5描述的翻译器、消费假设和给药时间表，协商引擎1008能够将由制药公司提供的每包价格转换成字段1010中的每年价格。这个每年价格被发送给支付者，以便在多种药物疗法的情况下，支付者能够计算药物方案的综合成本。一旦制药公司录入了支付者感兴趣的药物疗法的其提供价格，制药公司就能够通过按下按钮1012将其价格提交给支付者。

图11描绘了根据本公开的一些实施例的在协商期间呈现给支付者的界面。图11的界面1100是图5的界面500的修改版本。一旦参与协商的所有各方都录入了他们的提议，第一轮协商就被视为结束。界面1100包括指示器1102，其显示提议的评估以确定提议之间是否存在重叠，或者提议之间不存在匹配。在一些实施例中，当提议之间不存在匹配时，协商引擎108的界面1100可以包括色标(红黄绿)指示器代替指示器1102，并且具有代表协商成功的可能性的滑块。在一些实施例中，色标可以不是单一颜色，而是标度(更像是模拟温度计而不是数字温度计)。改变协商的不同要素(价格、量、性能预配置等)可以对标记在标度上的位置产生影响并以不同的速率改变它。例如，阈值可以具有随机生成的修正系数(fudge factor)，因此协商各方可能无法弄清楚后台发生了什么。如果支付者的价格是100美元，而制药公司的价格是110美元，那么协商引擎108的制药公司界面中的色标可以是绿色的(基于假设两者价格都会下降)。类似地，如果制药公司将其价格列为120美元，那么色标是黄色；而如果制药公司的价格是130美元，那么色标是红色。

在一些实施例中，如果协商的发起者是支付者，那么协商引擎108的界面1100在定价预配置上方或下方的定价承诺选项卡中示出定价推荐区段(未示出)。在一些实施例中，定价推荐区段包括一个或多个价格等级连同成功概率的图形表示。在一些实施例中，成功的概率可以基于由支付者指定的可能的承诺(contingent commitment)。例如，可能的承诺可以指定匹配百分比或其它的价格的百分比的限制。在一些示例中，可能的价格可以基于美元金额。在一些示例中，协商的发起者可以具有基于来自协商的对方的承诺引入承诺的能力。在一些实施例中，如果协商引擎108确定前一轮中指定的定价不应当改变，如果支付者保持同样的价格，那么“价格不应当改变”将与成功概率小部件一起出现在定价承诺选项卡中。假设制药公司有一定的概率会接受微调推荐，成功的概率可以与前一轮不同。

在一些实施例中，如果协商的发起者是支付者，那么与支付者相关联的协商引擎108的界面在治疗继续承诺上方或下方的持续时间上限选项卡中示出治疗继续推荐区段。在一些实施例中，这将包括诸如在其之后应用治疗继续返利的周期的数量、返利百分比、预期继续疗法的患者群体的百分比以及成功概率小部件之类的信息。在一些实施例中，如果协商引擎108的微调算法确定前一轮中指定的治疗继续信息不应当改变，那么在持续时间上限选项卡中将出现“不应当改变治疗继续承诺”消息连同成功概率小部件。在一些实施例中，假设支付者有一定的概率会接受微调推荐，成功的概率可以与前一轮不同。在一些实施例中，协商引擎108的微调算法将确定疗法继续承诺应当被移除并被结合到制药公司的定价承诺中。在这种情况下，将在定价和治疗持续时间上限选项卡两者上向制药公司显示足够的消息连同成功概率小部件。

在一些实施例中，如果协商的发起者是支付者，那么协商引擎108的界面在治疗中断承诺上方或下方的性能选项卡中示出疗法中断推荐区段。在一些实施例中，这将包括诸如在其之后应用疗法中断返利的周期的数量、返利百分比、预期中断疗法的患者群体的百分比、成功概率小部件之类的信息。在一些实施例中，如果协商引擎108的微调算法确定前一轮中指定的疗法中断信息不应当改变，那么在性能选项卡中将出现“疗法中断承诺不应当改变”消息以及成功概率小部件。在一些实施例中，假设支付者有一定的概率会接受微调推荐，成功的概率可以与前一轮不同。在一些实施例中，微调算法可能会确定疗法中断承诺应当被移除并结合到制药公司的定价承诺中。在一些实施例中，将在定价和性能选项卡两者上向制药公司显示足够的消息以及成功概率小部件。

在一些实施例中，协商引擎108的微调算法将检测支付者在下一轮中是否应当改变定价策略或定价单位。支付者界面将在屏幕的轮次区段紧下方向用户显示这种消息。

在一些实施例中，在轮次级别描述的成功概率小部件显示该轮次的总体成功概率。在一些实施例中，在承诺级别(例如，定价/疗法继续/疗法中断)的成功概率小部件是百分比小部件，其显示每个承诺推荐归因于总体协商成功概率的增量成功因子。

平台将指示是否已经实现匹配(纯粹基于价格)。价格可能是所有各方都可接受的，但包括取决于实际患者治疗持续时间和反应的价格预配置。如果支付者决定点击按钮1104，那么可获得有关其它相关方提供的价格的更多信息。图11中更详细地描述了由制药公司提供的定价模型的界面。

在不存在匹配的情况下，协商引擎108将区分可能存在匹配的交易组件与不存在匹配的交易。在一些实施例中，协商引擎将推动双方达成更公平的解决方案。

图12描绘了根据本公开的一些实施例的两方之间的协商过程的说明性流程图。

在1202处，协商引擎108从第一计算设备接收与药物治疗相关联的参数的第一集合，其中参数的第一集合中的一个或多个参数指示与药物治疗相关联的一个或多个因素，参数的第一集合以第一格式提供。在一些实施例中，如图3-7中所示，与协商相关联的参数的第一集合可以包括如药物的名称、给药时间表、药物疗法的持续时间、有资格接受药物疗法的患者的数量、药物疗法的价格、关于药物疗法的价格的预期返利、药物疗法的定价策略之类的信息。在一些实施例中，当在协商引擎108中创建药物疗法时，这种信息中的一些(例如，药物的名称、给药时间表、有资格的患者的准则)可以由制药公司录入。在一些实施例中，可以从支付者接收一些其它信息，诸如有资格的患者的数量、药物疗法的持续时间、预期的价格和关于价格的预期返利。

在1204处，协商引擎108基于一个或多个因素确定第一参数的集合的子集。在一些实施例中，如关于图5-7所示，支付者可以决定在创建协商提议时向制药公司隐藏一些参数。在此类实施例中，支付者可以通过从界面500选择选项528来要求协商引擎108向制药公司隐藏药物的价格，并且通过选择界面600的选项612和界面700的选项712来向制药公司隐藏预期的返利。

在1206处，协商引擎108基于一个或多个因素确定第一参数的子集的第二格式。在一些实施例中，由制药公司录入的药物疗法的价格可以是按人计算的。但是，制药公司更愿意按包接收和提供价格。使用制药公司在创建药物疗法时提供的如给药时间表和初级包尺寸之类的信息，协商引擎108可以将从支付者接收的按患者的价格(第一格式)转换成按初级包的价格(第二格式)。

在1208处，协商引擎108向第二计算设备提供参数的第二集合。协商引擎108可以向制药公司提供修改后的接收到的参数以供他们输入。

在1210处，协商引擎108从第二计算设备接收与药物治疗相关联的参数的第三集合，其中参数的第三集合基于与治疗相关联的一个或多个因素，参数的第三集合以第三格式提供。在一些实施例中，一旦将参数提供给制药公司，制药公司就能够审查该信息以提供他们自己的用于支付者请求的药物疗法的定价的输入。在一些实施例中，制药公司在做出决定时可以访问来自支付者的信息，并且在一些情况下，信息可以对制药公司隐藏。制药公司将停止访问某些参数，诸如药物疗法的持续时间、有资格的患者的数量等的某些基本参数，这些参数将帮助制药公司提供其药物疗法的价格。

在1212处，协商引擎108将参数的第三集合从第三格式转换成第一格式。在一些实施例中，支付者可以以他们的优选格式(按初级包)录入药物疗法的价格，然后使用给药时间表、初级包尺寸和药物疗法的持续时间将其转换成支付者的优选格式(按人)。

在1214处，协商引擎108将从第二计算设备接收的经转换的参数的第三集合呈现给第一计算设备。在一些实施例中，从制药公司接收的信息一旦被修改就被发送给支付者以供他们审查。在一些实施例中，协商引擎108可以基于提供给支付者和制药公司的过程之间的差异来提供指示器，以突出协商的状态。

本文描述的主题可以用数字电子电路系统或者用计算机软件、固件或硬件(包括本说明书中公开的结构部件及其结构等同物)或者它们的组合来实现。本文描述的主题可以被实现为一个或多个计算机程序产品，诸如有形地体现在信息载体中(例如，在机器可读存储设备中)或体现在传播信号中以用于由数据处理装置(例如，可编程处理器、计算机或多个计算机)执行或者控制数据处理装置的操作的一个或多个计算机程序。计算机程序(也称为程序、软件、软件应用或代码)可以用任何形式的编程语言编写，包括编译或解释语言，并且它可以以任何形式进行部署，包括作为独立程序或者作为适用于在计算环境中使用的模块、组件、子例程或其它单元。计算机程序不一定对应于文件。程序可以存储在保持其它程序或数据的文件的一部分中、专用于所讨论的程序的单个文件中、或者在多个协调文件中(例如，存储一个或多个模块、子程序或代码的部分的文件)。计算机程序可以被部署为在一个站点处或跨多个站点分布的一个或多个计算机上执行并通过通信网络互连。

本说明书中描述的处理和逻辑流程(包括本文描述的主题的方法步骤)可以由执行一个或多个计算机程序的一个或多个可编程处理器来执行，以通过操作输入数据和生成输出来执行本文描述的主题的功能。处理和逻辑流程也可以由专用逻辑电路系统，例如，FPGA(现场可编程门阵列)或ASIC(专用集成电路)来实现，并且本文描述的主题的装置可以被实现为专用逻辑电路系统，例如，FPGA(现场可编程门阵列)或ASIC(专用集成电路)。

作为示例，适用于执行计算机程序的处理器包括通用和专用微处理器以及任何类型的数字计算机的任何一个或多个处理器。通常，处理器将从只读存储器或随机存取存储器或两者接收指令和数据。计算机的基本元件是用于执行指令的处理器以及用于存储指令和数据的一个或多个存储器设备。通常，计算机还将包括一个或多个用于存储数据的大容量存储设备，例如，磁盘、磁光盘或光盘，或者计算机将可操作地耦合以从该一个或多个大容量存储设备接收数据或将数据传递到其，或两者。适用于体现计算机程序指令和数据的信息载体包括所有形式的非易失性存储器，作为示例包括半导体存储器设备(例如，EPROM、EEPROM和闪存设备)；磁盘(例如，内部硬盘或可移除磁盘)；磁光盘；以及光盘(例如，CD和DVD盘)。处理器和存储器可以由专用逻辑电路系统补充或并入其中。

为了提供与用户的交互，本文描述的主题可以在具有用于向用户显示信息的显示设备(例如，CRT(阴极射线管)或LCD(液晶显示器)监视器)以及用户可以通过它们向计算机提供输入的键盘和定点设备(例如，鼠标或轨迹球)的计算机上实现。其它种类的设备也可以用于提供与用户的交互。例如，提供给用户的反馈可以是任何形式的感官反馈(例如，视觉反馈、听觉反馈或触感反馈)，并且来自用户的输入可以以任何形式被接收，包括声学、语音或触感输入。

本文描述的主题可以在计算系统中实现，该计算系统包括后端组件(例如，数据服务器)、中间件组件(例如，应用服务器)或前端组件(例如，具有通过其用户可以与本文描述的主题的实现交互的图形用户界面或web浏览器的客户端计算机)、或者这种后端、中间件和前端组件的任何组合。系统的组件可以通过任何形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)和广域网(“WAN”)，例如，互联网。

应该理解的是，所公开的主题在其应用中不限于在以上描述中阐述的或者在附图中示出的构造的细节和组件的布置。所公开的主题能够具有其它实施例并且能够以各种方式来实践和执行。而且，应该理解的是，本文采用的措辞和术语是为了描述的目的，而不应该被认为是限制性的。

由此，本领域技术人员将认识到的是，本公开所基于的概念可以容易地用作设计用于执行所公开主题的若干目的的其它结构、方法和系统的基础。因此，重要的是，只要不脱离所公开主题的精神和范围，权利要求就应该被认为包括这样的等同构造。

虽然已经在前述示例性实施例中描述和图示了所公开的主题，但应该理解的是，本公开仅仅通过示例的方式进行，并且所公开的主题的实现细节的许多变化可以在不脱离所公开主题的精神和范围的情况下进行，所公开主题仅由随后的权利要求限定。

Claims (14)

1.一种用于定制与确保药物治疗相关的用户参数的计算机化的系统，包括：

存储器；以及

处理器，其通信耦合到存储器，其中处理器被配置为：

从第一计算设备接收与药物治疗相关联的参数的第一集合，其中参数的第一集合中的一个或多个参数指示与药物治疗相关联的一个或多个因素，参数的第一集合以第一格式提供；

基于在参数的第一集合中接收的信息，将接收到的参数的第一集合变换成参数的第二集合，其中将参数的第一集合变换成参数的第二集合包括：

基于所述一个或多个因素确定参数的第一集合的子集；

基于所述一个或多个因素确定第一参数的第二格式；

向第二计算设备提供参数的第二集合；

从第二计算设备接收与药物治疗相关联的参数的第三集合，其中参数的第三集合基于与治疗相关联的所述一个或多个因素，参数的第三集合以第三格式提供；

将参数的第三集合从第三格式转换成第一格式；以及

向第一计算设备呈现从第二计算设备接收的经转换的参数的第三集合。

2.如权利要求1所述的计算机化的系统，其中参数的第一集合包括有资格接受药物治疗的患者的数量、每位患者的药物治疗的预期价格以及每位患者的预期返利。

3.如权利要求2所述的计算机化的系统，其中有资格接受药物治疗的患者的数量可以是一。

4.如权利要求3所述的计算机化的系统，被配置为确定参数的第一集合的子集，还被配置为：

基于确定与参数的第一集合相关联的一个或多个参数具有与其相关联的隐藏标志来排除参数的第一集合的所述一个或多个参数。

5.如权利要求4所述的计算机化的系统，其中与药物治疗相关联的所述一个或多个因素包括预定的平均患者身高、预定的平均患者体重、预定的平均患者表面积以及治疗的持续时间。

6.如权利要求5所述的计算机化的系统，还被配置为：

基于与药物治疗相关联的所述一个或多个因素来确定每位患者的药物治疗的平均剂量需求。

7.如权利要求6所述的计算机化的系统，还被配置为：

基于药物治疗的平均剂量需求和治疗的持续时间来确定患者所需的药物治疗包的数量。

8.如权利要求7所述的计算机化的系统，其中参数的第三集合包括每个药物治疗包的提供价格和药物治疗的提供返利。

9.如权利要求8所述的计算机化的系统，还被配置为：

基于与药物治疗相关联的所述一个或多个因素将每个药物治疗包的确定价格转换成药物治疗的每位患者的价格。

10.如权利要求9所述的计算机化的系统，还被配置为：

将药物治疗的预期价格与药物治疗的提供价格进行比较；

响应于确定药物治疗的预期价格和药物治疗的提供价格在彼此的预定范围内，向第一计算设备和第二计算设备提供同意信号。

11.如权利要求10所述的计算机化的系统，还被配置为：

响应于确定药物治疗的预期价格和药物治疗的提供价格在彼此的预定范围之外而向第一计算设备和第二计算设备提供不同意信号。

12.如权利要求11所述的计算机化的系统，其中发送到第一计算设备的不同意信号还包括基于与第一计算设备相关联的历史数据以及预期价格与提供价格之间的差异的药物治疗的建议的预期价格。

13.如权利要求12所述的计算机化的系统，其中发送到第二计算设备的不同意信号还包括基于与第二计算设备相关联的历史数据以及预期价格与提供价格之间的差异的药物治疗的建议的提供价格。

14.如权利要求13所述的计算机化的系统，还被配置为：

响应于不同意信号而从第一计算设备接收药物治疗的更新后的预期价格；以及

响应于不同意信号而从第二计算设备接收药物治疗的更新后的提供价格。

Images