用于基于套利的医疗服务的系统和方法
【专利摘要】描述了一种报价请求系统和方法。系统可以允许用户在地理区域中向开业医生请求针对医疗保健的报价，该开业医生具有专长和/或具有专门知识来治疗特定疾病或病情。
【专利说明】用于基于套利的医疗服务的系统和方法
[0001]优先权声明/相关申请
本申请根据美国法典第35卷119 (e)条要求2013年8月28日提交的且题为“System AndMethod For Arbitraged Based Medical Services” 的美国临时专利申请号61/871，195的权益，其整体通过参考并入在本文中。
技术领域
[0002]本公开大体上涉及医疗保健系统和方法，并且特别涉及用于基于套利的医疗服务的系统和方法。以下描述的报价请求过程优化医疗商品和服务市场中的套利过程。
【背景技术】
[0003]存在创建用于医疗保健的社交市场的系统。一些系统是针对病人的社交市场，并且一些系统针对开业医生，其允许开业医生成为会员并接触潜在客户。然而，这些系统不允许消费者搜索特定地理区域中的治疗特定病情或疾病或者具有期望的专长的医疗保健开业医生并且向开业医生请求报价。因此，期望提供下述系统和方法:该系统和方法允许消费者搜索特定地理区域中的治疗特定病情或疾病或者具有期望的专长的医疗保健开业医生并且向开业医生请求报价。
【附图说明】
[0004]图1是可以合并报价请求系统的医疗保健市场系统；
图2图示报价请求系统的实施例的细节；
图3图示用于请求报价的方法；
图4和图5图示报价请求系统的医疗保健搜索用户界面的示例；
图6图示报价请求系统的开业医生细节用户界面的示例；
图7图示报价请求系统的报价请求用户界面的示例；
图8图示报价请求系统的开业医生用户界面的示例；
图9图示报价请求系统的内部开业医生用户界面的示例；
图10图示报价请求系统的用户报价细节用户界面的示例；
图11图示报价请求系统的用户报价概要用户界面的示例；
图12图示报价请求系统的用户报价用户界面的示例；
图13图示报价请求系统的报价用户界面的创建的示例；
图14图示报价请求系统的用户未决报价用户界面的示例；
图15图示报价请求系统的开业医生报价用户界面的示例；
图16图示报价请求系统的用户接受的报价用户界面的示例；
图17图示报价请求系统的开业医生开放请求用户界面的示例；以及图18图示报价请求系统的开业医生接受的报价用户界面的示例。
【具体实施方式】
[0005]本公开特别适用于基于移动应用的医疗保健报价请求系统，该系统与基于云计算的后端系统对接并且正是在该上下文中将描述本公开。然而，将领会的是，系统和方法具有更大效用，因为系统可以与除了医疗保健以外的行业一起使用并且可以以在本公开的范围内的其他方式来实施。此外，报价请求系统可以是独立的系统。以下描述的报价请求过程优化医疗商品和服务市场中的套利过程。
[0006]医疗保健报价请求系统及方法可以是医疗保健社交市场的一部分，其允许已加入医疗保健社交社区的开业医生以甚至几年前不可想象的方式接触潜在客户。除了给开业医生社交门户(用该社交门户与消费者沟通和向消费者推销他们本身)以外，市场给每个医疗保健开业医生如下能力:在对团购、社交生活、或其他社交市场的用户所熟悉的环境中提供他们的服务。但是与这些其他社交市场不同，社交社区中的个体开业医生或实践可以以其正常现金价格或以折扣提供他们的服务的完整清单。
[0007]图1是可以合并报价请求系统的医疗保健市场系统100。医疗保健市场系统100可以具有一个或多个计算设备102，该一个或多个计算设备102通过通信路径106连接到后端系统108。每个计算设备102(诸如，如图1中示出的计算设备102a，102b，...，102η)可以是具有存储器、永久储存器、有线或无线通信电路和显示器的基于处理器的设备，该设备允许每个计算设备连接到后端系统108并通过通信路径106耦合到后端系统108。例如，每个计算设备可以是智能手机设备，诸如苹果计算机产品、基于安卓OS的产品等、平板计算机，个人计算机、终端设备、膝上型计算机等。在图1中示出的一个实施例中，每个计算设备102可以在存储器中存储应用程序104，然后使用与后端系统对接的计算设备的处理器来执行该应用程序。例如，应用程序可以是典型的浏览器应用程序或可以是诸如图4-7中的示例用户界面中示出的移动应用程序。应用程序104可以具有用户界面组件，其允许用户输入报价请求信息，如图5-7中示出的那样，并且响应于报价请求查看从每个开业医生接收的一个或多个报价。通信路径106可以是使用安全协议或不安全协议的有线或无线通信路径。例如，通信路径106可以是互联网、以太网、无线数据网络、蜂窝数字数据网络、WiFi网络等。
[0008]后端系统108也可以具有可以耦合在一起的健康市场引擎110和报价请求引擎112。可以使用一个或多个计算资源，诸如一个或多个服务器计算机、一个或多个云计算资源等实施后端系统的这些组件中的每个。在一个实施例中，健康市场引擎110和报价请求引擎112可以各自用软件来实施，在该软件中每个引擎具有由后端系统的一个或多个计算资源的处理器执行的多行计算机代码。在其他实施例中，健康市场引擎110和报价请求引擎112中的每个可以用硬件(诸如，编程的逻辑设备、编程的处理器或微控制器等)来实施。后端系统108可以耦合到存储组成医疗保健系统的各种数据和软件模块的存储区114。存储区114可以被实施为硬件数据库系统、软件数据库系统或任何其他存储系统。
[0009]健康市场引擎110可以允许已经加入医疗保健社交社区的开业医生以甚至几年前不可想象的方式接触潜在客户。除了给开业医生社交门户(用该社交门户与消费者沟通和向消费者推销他们本身)以外，市场给每个医疗保健开业医生如下能力:在对团购、社交生活、或其他社交市场的用户所熟悉的环境中提供他们的服务。
[0010]在其中报价请求引擎112是健康市场系统110的部分的图1中示出的示例中，报价请求引擎112允许健康市场系统的用户搜索在他们的区域中的治疗他们的病情或用期望的专长实践的开业医生并且请求针对他们需要的医疗服务的报价。此外，当用户/消费者可以选择最好地满足他们的选择标准的报价时，用户可以向多于一个开业医生请求相同期望的专长、疾病和/或病情的报价以创建竞争的环境。
[0011]图2图示可以具有耦合到彼此的用户界面生成器200、报价请求(RFQ)生成器202、报价生成器204和信使单元206的报价请求系统112的实施例的细节。均可以用硬件、软件或硬件和软件的组合实施报价请求系统112的组件。更具体地说，报价请求系统112中的每个组件可以用微处理器、微控制器、可编程逻辑设备、状态机、可由执行多行计算机代码的可编程逻辑设备或微控制器、处理器或微处理器(统称为配置成执行图3中示出的过程的处理器)执行的多行计算机代码来实施。用户界面生成器200可以生成报价请求系统的用户界面的数据(其示例被示出在图4-7中用于用户/消费者侧)，RFQ生成器202可以基于用户的请求生成报价请求(下文更详细地描述)，报价生成器204可以生成针对开业医生的报价和报价响应，并且信使单元206在一个或多个开业医生和正寻找在地理区域中的具有期望的专长或专业知识的开业医生来治疗病情或疾病的消费者之间协调报价请求系统的报价请求、报价等的沟通。
[0012]图3图示可以例如使用报价请求系统112的组件实施的用于请求报价的方法300。该方法也可以使用可以执行图3中示出和下面描述的过程的其他组件来实施。在方法中，每个用户/消费者可以诸如通过使用图4中示出的用户界面搜索在地理区域中的具有带有特定专长的实践的开业医生/供应商302、306，该用户界面允许用户通过医疗保健专长、通过病情/疾病和/或通过关键词在用户的地理区域中搜索。然后用户诸如通过使用图5-7中示出的示范性界面然后选择供应商(304)和填写表单(308)。图5示出地理区域中的针对成人医学的许多供应商(由图5中的用户界面示例中的针状物表示)和针对供应商之一的细节。图6示出允许用户向开业医生请求报价的用户界面的示例。图7是用户界面的示例，在该用户界面中用户可以填写有关报价请求信息，诸如在图7中的示例中的预算、预算是否可协商和支付方法，因此该系统可以向所选开业医生生成报价请求。该方法也可以允许用户/消费者向多于一个开业医生请求报价。
[0013]对于用户的每个报价请求而言，在系统接收到有关报价请求信息时，系统可以生成针对供应商的报价请求310。每个报价请求可以具有其中开业医生可以接受或拒绝RFQ的有限的受理时间段。在一个示例中，系统可以具有针对每个RFQ的72小时届期。然后系统可以然后确定开业医生是否是健康市场的会员312。如果所选开业医生不是健康市场的会员312，则可以联系系统加入系统314，以便开业医生加入系统318然后从系统接收RFQ。返回到过程312，如果所选开业医生是健康市场的会员，则系统通知开业医生/供应商RFQ已被释放316。
[0014]使用信使单元，该系统确定供应商是否响应RFQ320。如果供应商不响应RFQ，则系统通知用户并取消该RFQ 322。如果供应商响应RFQ，则供应商通过系统的报价组件填写表单提交报价324。系统然后可以使用信使单元通知用户:报价已经由特定开业医生提交326。一旦通知用户来自开业医生的报价，系统确定用户是否接受报价328。如果用户接受报价，则例如使用信使单元通知供应商该接受330。
[0015]在其中系统可以为用户生成多个报价的实施例中，方法可以涉及:I)创建和释放新的RFQ;2)提交报价;和3)接受报价。
[0016]创建和释放新的RFQ
向其释放RFQ的开业医生的列表从前端中被传递并且用于例如通过系统的RFQ生成器创建个体报价。这些报价以新的状态开始，并且保持这种方式直到开业医生采取行动或RFQ到期，无论哪个先到。
[0017]存在报价可以彼此关联的两种方式。在大量报价情境中，每个报价共享公共的母RFQ。在该情境中，开业医生列表具有多个元素。报价也可以在它们相应的RFQ被相同消费者释放并且具有相同的current_category属性(意味着它们被分组在相同的搜索结果中)的情况下彼此关联。因此，当RFQ被释放时，检查需要发生以看看是否存在起作用的关联报价，并且如果是这样的话，针对起作用的每个RFQ的竞争者列表需要被更新到接收RFQ的所有开业医生的聚合集。如之前的那样，如果所讨论的开业医生未被验证而另一方面经验证的开业医生经由正常机制(电子邮件、短信服务(SMS)、应用内通知)得到通知，则创建台票。发出提醒的未来事件以及针对RFQ的投标窗口的关闭的处理基于届满日期以适当时间来安排(stage)ο
[0018]提交报价
通知消费者开业医生已提供服务报价。发出提醒的未来事件以及报价届满的处理基于届满日期以适当时间来安排。
[0019]接受报价
所有的其他关联报价需要被隐式拒绝。外部通知开业医生报价已被消费者接受。通知消费者下一步接下来是什么。
[0020]图8图示了其中开业医生可以发布关于他的服务和专业知识的信息的报价请求系统的开业医生用户界面的示例，该信息可以被系统的用户查看。用户界面也可以具有由用户针对服务请求报价的用户界面元素。图9图示了允许是健康系统的部分的开业医生查看他的系统属性(诸如，简介页面、网站、链接帐户以及如示出的最近报价请求)的报价请求系统的内部开业医生用户界面的示例。在图9中的该用户界面中，开业医生可以使用与每个报价请求相关联的“响应”和“拒绝”按钮来响应和/或拒绝用户报价。
[0021]图10图示了报价请求系统的用户报价细节用户界面的示例。用户界面允许用户查看针对特定请求的包括请求届满时间的报价请求的细节的集合。图11图示了示出用户所做的每个报价的概要的报价请求系统的用户报价概要用户界面的示例。用户界面也可以具有针对报价剩余的时间的指示。
[0022]图12图示了其中示出等待供应商/开业医生响应的报价、未决报价和用户接受的报价的报价请求系统的用户报价用户界面的示例。在图12中的示例中，示出了以$95.00的针对过敏试验的报价请求。图13图示了允许开业医生/供应商基于来自用户的报价请求创建报价的报价请求系统的创建报价用户界面的示例。在图13中的示例中，开业医生/供应商正报价$105.00现金价格而不是用户/消费者提供的$95.00。
[0023]图14图示了其中用户可以查看等待供应商响应的报价、未决报价和接受的报价的报价请求系统的用户未决报价用户界面的示例。在该示例中，示出了针对过敏试验的$105现金的未决报价。用户界面也可以具有接受或拒绝供应商的报价的用户界面元素。
[0024]图15图示了当用户选择在图14中的接受报价按钮(其然后可以接受报价)时显示给用户/消费者的报价请求系统的开业医生报价用户界面的示例。一旦用户接受报价，图16图示其中接受的报价现在在用户界面的接受的报价部分中的报价请求系统的用户接受的报价用户界面的示例。接受的报价用户界面也可以示出报价的届满日期。
[0025]图17图示了其中特定开业医生/供应商可以查看诸如图17中示出的那些的任何开放请求的报价请求系统的开业医生开放请求用户界面的示例。图18图示了报价请求系统的开业医生接受的报价用户界面的示例。
[0026]虽然前述已参考本发明的特定实施例，但是本领域技术人员将领会到的是，在不脱离本公开的原则和精神的情况下可以做出该实施例的变化，其中由所附权利要求限定本公开的范围。
【主权项】
1.报价请求装置，包括: 医疗后端组件;并且 医疗后端组件具有报价请求组件，报价请求组件具有被配置成接收针对医疗服务的报价请求的处理器，基于针对医疗服务的报价请求传达报价请求到一个或多个开业医生，确定一个或多个开业医生是否以报价响应报价请求以及如果开业医生响应报价请求则传达报价到请求针对医疗服务的报价请求的实体，其中针对医疗服务的报价请求包括一个或多个开业医生、针对医疗服务的预算和针对所请求的医疗服务的支付方法。2.权利要求1的装置，其中处理器被配置成确定实体是否接受来自开业医生的报价。3.权利要求1的装置，其中处理器被配置成确定一个或多个开业医生是否提供新的预算作为报价的一部分。4.权利要求1的装置，其中处理器被配置成，如果一个或多个开业医生在届满期内不进行响应，则使报价请求到期。5.权利要求4的装置，其中届满期是72小时。6.权利要求1的装置，其中处理器被配置成传达报价请求到多个开业医生。7.权利要求1的装置，其中针对医疗服务的报价请求包括可协商的预算。8.一种方法，包括: 由医疗报价请求系统接收针对医疗服务的报价请求，针对医疗服务的报价请求包括一个或多个开业医生、针对医疗服务的预算和针对所请求的医疗服务的支付方法； 基于针对医疗服务的报价请求传达报价请求到一个或多个开业医生； 确定一个或多个开业医生是否用报价响应报价请求；以及 如果开业医生响应报价请求，则传达报价到请求针对医疗服务的报价请求的实体。9.权利要求8的方法，进一步包括确定实体是否接受来自开业医生的报价。10.权利要求8的方法，其中确定一个或多个开业医生是否用报价响应报价请求进一步包括确定一个或多个开业医生是否提供新的预算作为报价的一部分。11.权利要求8的方法，进一步包括如果一个或多个开业医生在届满期内不进行响应，则使报价请求到期。12.权利要求11的方法，其中届满期是72小时。13.权利要求8的方法，其中传达报价请求进一步包括传达报价请求到多个开业医生。14.权利要求8的方法，其中针对医疗服务的报价请求包括可协商的预算。15.—种系统，包括: 医疗系统，具有处理器和报价请求组件； 一个或多个计算设备，各自被配置成耦合到报价请求组件并且与报价请求组件通信； 每个计算设备具有处理器，所述处理器被配置成生成针对医疗服务的报价请求以及传达针对医疗服务的报价请求到报价请求组件，其中针对医疗服务的报价请求包括一个或多个开业医生、针对医疗服务的预算和针对所请求的医疗服务的支付方法；以及 报价请求组件具有处理器，所述处理器被配置成基于针对医疗服务的报价请求传达报价请求到一个或多个开业医生，确定一个或多个开业医生是否用报价响应报价请求以及如果开业医生响应报价请求则传达报价到请求针对医疗服务的报价请求的实体。16.权利要求15的系统，其中报价请求的处理器被配置成确定实体是否接受来自开业医生的报价。17.权利要求15的系统，其中报价请求的处理器被配置成确定一个或多个开业医生是否提供新的预算作为报价的一部分。18.权利要求15的系统，其中报价请求的处理器配置成，如果一个或多个开业医生在届满期内不进行响应，则使报价请求到期。19.权利要求18的系统，其中届满期是72小时。20.权利要求15的系统，其中报价请求的处理器被配置成传达报价请求到多个开业医生。21.权利要求15的系统，其中针对医疗服务的报价请求包括可协商的预算。22.权利要求15的系统，其中每个计算设备具有与报价请求组件对接的应用程序。23.权利要求22的系统，其中应用程序是浏览器应用程序和移动应用程序中的一个。24.权利要求22的系统，其中应用程序具有用户界面组件，所述用户界面组件允许报价请求信息的录入并且显示来自一个或多个开业医生的报价。
【文档编号】G06Q50/22GK105830116SQ201480059324
【公开日】2016年8月3日
【申请日】2014年7月11日
【发明人】T.C.坦纳, D.C.托马斯
【申请人】口袋医生公司