1.本公开涉及索赔分析系统和方法。
背景技术：
：：2.许多医院要求资金机构和/或保险公司为在护理患者期间提供的服务支付费用。3.保险索赔或支付索赔很复杂并且通常不准确。这导致索赔被保险公司拒绝(从而浪费大量的时间和精力)，或者索赔被接受但不完整/不准确(从而导致例如未针对已提供的项目/服务进行保险索赔)。4.然而，由于保险索赔或支付索赔的复杂性，特别是在医疗服务领域中，提供能够准确有效地识别保险索赔中潜在缺陷的系统和方法提出了一个具有挑战性的问题。5.本说明书中对任何现有技术或
背景技术：
：信息的引用并不是对该现有技术或
背景技术：
：信息构成任何司法管辖区内的公共常识的一部分或者该现有技术可被本领域的技术人员合理地预期理解、视为相关和/或与其他现有技术组合的确认或建议。技术实现要素：6.所附权利要求可用作
发明内容。附图说明7.在附图中：8.图1是根据本公开的方面的联网环境的框图。9.图2和图3提供了指示在向索赔审查系统提交索赔时执行的操作的流程图。10.图4提供了指示执行以创建随后可用于索赔分析的规则的操作的流程图。11.图5提供了指示在分析索赔中执行的操作的流程图。12.图6示出了审查系统的示例性架构。13.图7是可用于实现本公开的各种实施方案和/或特征的计算系统的框图。14.图8提供了索赔缺陷通知的示例性电子邮件格式。15.图9提供了示例性评估员用户界面。16.虽然本发明可以进行各种修改形式和替代形式，但其具体实施方案已在附图中以举例的方式示出并详细描述。然而，应当理解，附图和具体实施方式并非旨在将本发明限制于所公开的特定形式。本发明用于涵盖落入由所附权利要求书所限定的本发明的实质和范围内的所有修改形式、等同形式和替代形式。具体实施方式17.本公开的整体背景是由索赔提交者向保险公司准备和提交保险索赔。为了便于参考，索赔提交者将简称为索赔提交者，并且保险公司将称为索赔接收者。18.本公开着重于医疗服务领域，并且着重于患者医疗服务索赔的特定背景下，患者医疗服务索赔由医院准备并提交给医疗保险公司以用于评估和支付。19.本公开介绍了一种计算机实现的索赔审查系统。如下文所详述，系统自动审查所接收的索赔并实时(或近乎实时)在其上提供反馈。基于反馈，在向索赔接收者实际提交索赔之前，可以(如果必要的话)细化和优化所述提交。20.通过提供此类反馈，索赔审查系统帮助索赔提交者(例如医院)减少收入流失、减少低效率、降低成本并减少医院内的浪费。21.环境概述22.图1示出了在其中实现本公开的实施方案和特征的示例性环境100。示例性环境100包括通信网络102，该通信网络将索赔提交者系统110(例如医院的系统)、索赔审查系统120和评估员系统140互连。23.索赔提交者系统110是由索赔提交者操作的计算机系统。提交者系统110通常将包括运行各种软件应用程序的各种互操作系统。然而，与本公开相关的是，系统110包括审查系统客户端应用程序112和提交者数据库系统114。24.审查系统客户端应用程序112和提交者数据库系统114很可能设置在单独的计算机系统/设备上。例如，审查系统客户端应用程序112可安装在个人计算设备(例如膝上型计算机、台式计算机、移动电话、平板电脑或其他计算设备)上，并且提交者数据库系统114由单独的计算系统(例如，更大的医院系统)托管。在这种情况下，个人计算设备连接到医院系统以访问提交者数据库系统114–例如，通过处于同一网络、vpn连接或其他(通常是安全的)通信信道上。25.当由处理单元(例如，处理单元702)执行时，审查系统客户端应用程序112将正供客户端应用程序运行的计算机系统配置为提供客户端索赔审查系统功能。这涉及(使用通信接口，诸如下文所述的716)与索赔审查系统120(并且具体地，由其提供的服务器应用程序122)通信。26.审查系统客户端应用程序112可以采用各种形式。例如，其可以是专用应用程序客户端，该专用应用程序客户端与索赔审查系统120的api服务器和提交者系统数据库112、使用http/https协议与索赔审查系统web服务器通信的web浏览器(诸如chrome、safari、ie、firefox或另选的web浏览器)或提交者系统110的现有软件应用程序(例如计费系统)的附加/集成模块进行通信，该附加/集成模块配置现有软件应用程序以用于与索赔审查系统120通信。27.提交者数据库系统114存储由提交者系统110捕获/存储的信息，所述信息(出于当前目的)与由提交者系统110的操作者准备的索赔提交相关。28.由提交者数据库系统114存储的精确数据将取决于特定背景和具体实施：例如，由提交者系统110正常捕获的数据的类型和索赔审查系统120预期/需要的数据的类型。以举例的方式，由提交者数据库系统114存储的数据可包括：医院数据；患者识别数据；患者年龄数据；咨询医生数据；治疗医生数据(及其专长)；临床病症和/或临床代码数据；临床诊断和/或临床诊断代码数据；过去的治疗和/或治疗代码数据；过去、当前和计划的药物和剂量数据；所提议的治疗和/或治疗代码数据；实际治疗和/或治疗代码数据；所使用的植入物和/或植入物代码数据；所使用的耗材和/或耗材代码数据；手术时间长度数据；入院日期/时间数据；离院/出院日期/时间数据；住院时长数据；drg代码数据；临床记录数据；入院记录数据；转诊记录数据；和/或任何其他数据。29.尽管已示出了单个提交者系统110，但是环境通常将包括与索赔审查系统120交互的(由不同实体操作的)多个提交者系统110。例如，使用索赔审查系统的每个独立医院将拥有自己的提交者系统110。30.概括地讲，索赔审查系统120包括服务器应用程序122、分析引擎124、规则生成引擎126和数据库系统128。31.索赔审查系统服务器应用程序122将索赔审查系统120配置为提供服务器端功能—例如，通过接收和响应来自审查系统客户端应用程序112和114的请求。服务器应用程序122可以是web服务器(用于与web浏览器客户端进行交互)或应用服务器(用于与专用应用程序客户端进行交互)。32.如下所述，索赔审查系统120的分析引擎124执行索赔分析。一般来讲，这涉及访问或接收索赔数据并对其进行分析，以确定与数据相关的索赔是可接受的还是具有可能的缺陷。在某些实施方案中，可能的缺陷可被归类为潜在缺陷(也称为次要缺陷)或可能的缺陷(也称为主要缺陷)。33.索赔审查系统120的规则生成引擎126运行以生成分析引擎124在索赔分析中所应用的规则。34.审查系统数据库系统128存储由索赔审查系统120使用的各种信息。这包括关于已经被接收用于分析的索赔的索赔数据(在这种情况下存储在索赔数据库130中)、由规则生成引擎126生成并由分析引擎124使用的规则(在这种情况下存储在规则数据库132中)以及由规则生成引擎126用于生成和验证新规则的训练数据(在这种情况下，存储在学习数据库134中)。35.如下文进一步所述，审查系统120可独立于提交者系统110(例如，为各种提交者系统提供软件作为服务的云具体实施)。在另选的实施方案中，审查系统120可被实施为提交者系统110的一部分–例如通过将相关的应用程序和数据库安装在由提交者系统110维护的硬件上。这在提交者系统(或其操作者)不希望在外部传送索赔数据的情况下可能是有利的。36.环境100还包括评估员系统140。评估员系统140是其上安装有审查系统客户端应用程序142的计算机处理系统。评估员系统140还将具有安装/运行于其上的其他应用程序，例如操作系统。37.当由评估员系统140(例如，由处理单元诸如下述单元702)执行时，审查系统客户端应用程序142将评估员系统140配置为提供客户端审查系统功能。审查系统客户端应用程序142可与提交者系统110的客户端应用程序112相同，或可以是不同的客户端应用程序。然而，如下文进一步讨论，由客户端应用程序142提供的功能不同于由客户端应用程序112提供的功能。当由索赔评估员使用时，客户端应用程序142将评估员系统140配置为用于索赔评估。当由规则评估员使用时，客户端应用程序142将评估员系统140配置为用于规则评估。相比之下，客户端应用程序112将提交者系统110配置为供索赔提交者使用。在应用程序142和112是相同应用程序的情况下，基于提供给两个系统的用户凭证(提交者用户凭证被提供给提交者系统客户端应用程序112，并且索赔评估员或规则评估员用户凭证被提供给审查系统客户端应用程序112)来提供差异。38.环境100中的各种系统之间的通信经由通信网络102进行。通信网络可以是局域网、公共网络(例如，互联网)或两者的组合。在索赔审查系统由提交者系统的操作者维护的情况下，审查系统客户端应用程序112和审查系统服务器应用程序122之间的通信通常将经由专用网络连接–例如，提交者系统110的lan或vpn连接。39.虽然已经提供了环境100作为示例，但是另选的系统环境/架构是可能的。40.索赔提交过程41.本节描述了根据一个实施方案的索赔提交过程200(图2)。42.过程200可在患者的护理阶段期间的各个时间点执行，其中该过程的输出是(一般而言)指示所提交的索赔的当前状态为可接受，指示存在潜在缺陷(以及关于那些潜在缺陷的意见/建议)和/或存在可能缺陷(以及关于那些可能缺陷的意见/建议)。实时(或近乎实时)提供该输出以向提交者提供关于索赔的指导。43.例如，可以提交关于患者入院的索赔以供审查，在这种情况下，过程的输出就相关信息对提交者进行指导，这些相关信息在与患者和/或其护理人员面对面讨论期间被最佳捕获，诸如出生日期等。还可以(或作为另外一种选择)以在患者的护理阶段期间提交索赔以供审查。在这种情况下，过程的输出提供关于在患者的护理阶段期间最佳捕获的相关信息(诸如其用药史、当前治疗和所提供的服务等)的指导。还可以(或作为另外一种选择)在患者出院/完成患者的护理阶段时或之后提交索赔以供审查。在这种情况下，过程的输出提供指导以确保捕获了在患者出院后最佳捕获的相关信息，诸如所执行的完整的治疗史和所提供的服务等。44.总的来说，索赔审查过程的输出旨在帮助提交者(例如医院)减少收入流失、低效、成本和浪费。45.在202处，索赔审查系统120从提交者系统110接收索赔审查请求。更具体地，索赔审查系统120的服务器应用程序122从提交者系统110的审查系统客户端应用程序112接收索赔审查请求。46.索赔审查请求与索赔数据相关联。索赔数据通常为在提交时可供提交者使用并且与特定患者的特定护理阶段相关的所有数据。47.索赔数据通常与请求一起/与请求同时从提交者系统110接收，然而其可被单独提交/上传。此外，并且如下所述，可以随时间推移更新与给定请求有关的索赔数据(例如，提交修改后的索赔以供分析)。48.可以提交给索赔审查系统120的特定索赔数据及其提交格式将取决于特定具体实施。在某些实施方案中，当提交者系统110的操作者希望准备/提交索赔以供审查时，审查系统客户端应用程序112被配置成从提交者数据库系统114自动提取相关数据以包括在请求中。在另选的实施方案中，向希望提交索赔以供审查的提交者系统110的操作者提供用户界面(例如网页或可供选择的界面)，该用户界面具有用于手动输入所需索赔数据的输入字段。49.以举例的方式，下表a提供了用于将索赔数据从提交者系统110传送到索赔审查系统120的示例性json格式：[0050][0051]表a：示例性索赔数据json格式[0052]作为替代示例，索赔数据可以如下表b所示的表格格式传送到索赔审查系统120：[0053][0054][0055]表b：示例性索赔数据表格格式[0056]在某些实施方案中，索赔审查系统120在接收到索赔审查请求时检查该索赔审查请求，以确保其中包括的索赔数据符合格式化要求。如果索赔审查请求有错误，则索赔审查系统120向提交者系统110返回通知错误的消息(例如，经由应用程序112或其他通信信道(例如，电子邮件))。在这种情况下，索赔审查系统120暂停/停止处理索赔，直到已经接收到修改的审查请求。[0057]在204处，索赔审查系统120确定在202处接收的索赔审查请求是初始请求(即，已经向系统120提交了关于特定护理阶段的初次数据)还是后续请求(即，先前已经提交了关于特定护理阶段的数据，并且正在请求第二次/下一次的审查)。[0058]在204处的确定可以各种方式进行，但是通常将涉及从提交中提取标识符以确定具有该标识符的提交是否已被接收并分析。标识符基于在所述提交中所包括的一个或多个索赔数据项。以举例的方式，并且使用表a的索赔数据，标识符可以是hospital_name和admission_number数据项的组合。作为可供选择的示例，再次使用表a的索赔数据，标识符可以是hospital_name、admission_number、theatre_session和date_of_surgery数据项的组合。[0059]如果在204处，索赔审查系统120确定索赔审查请求是初始请求，则处理前进至206。如果索赔审查请求被确定为后续请求，则处理前进至250(图3)。[0060]在206处，索赔审查系统120已将在202处接收的索赔审查请求确定为初始请求。在这种情况下，审查系统120从请求中提取索赔数据以生成关于该请求的索赔审查系统记录。索赔审查系统120将索赔审查系统记录保存到索赔数据库130中。[0061]在208处，索赔审查系统120分析索赔数据。下文参考图4进一步详细地描述了索赔分析。[0062]索赔分析过程返回分析报告。分析报告包括有关已识别的任何潜在或可能缺陷的缺陷数据。在未识别潜在缺陷或可能缺陷的情况下，分析报告将指示这一点(例如，通过表示为空或通过明确报告索赔是可接受的)。缺陷数据包括关于所讨论的索赔的标识符、是否已检测到问题，以及在已经检测到问题的情况下对问题的指示和/或关于该问题的建议。在某些实施方案中，缺陷数据还包括一个或多个规则标识符，所述规则标识符指示被触发以导致所识别缺陷的规则。[0063]给定缺陷(可能的或潜在的)可与已被包括在提交的索赔数据中但看起来异常(即，潜在地不应被包括)的特征/项目有关。作为另外一种选择，给定缺陷可与已从提交的索赔数据中省略的特征/项目(即，应当潜在地被包括的特征/项目)有关。[0064]在210处，索赔审查系统120确定索赔是否具有潜在/可能的缺陷(例如，通过在208处处理从分析过程返回的分析报告)。如果索赔不具有任何缺陷，则处理前进到212。否则，处理前进到216。[0065]在某些实施方案中，提交者系统110被配置为维护关于由提交者系统110创建的所有索赔的块变量。可由标志或具有指示所述块处于适当位置(这防止相关联的索赔被提交给保险公司)的一个值(例如真)和指示所述块不处于适当位置(此时相关联的索赔可被提交给保险公司)的另一个值(例如假)的任何其他变量来实现的块变量。在此类实施方案中，每当创建新的索赔时，该索赔的块变量被设置为真(即，块处于适当位置)，并且只有索赔审查系统120可以使块变量被设置为假(即，释放块)。在此类实施方案中，如果审查系统120确定索赔是可接受的，则其生成关于索赔的块移除消息并将其传送至提交者系统110(使用由提交者系统110提供的api端点以用于该目的)。当被提交者系统110接收时，块移除消息使提交者系统110将块变量改变为允许提交索赔的值(即，使得块已被移除)。[0066]如果没有索赔块被实施，则省略步骤212。[0067]在214处，审查系统120生成索赔可接受通知并将其传送到提交者系统110。这通知提交者系统110在202处提交的索赔对于提交而言是可接受的(并且，在被使用的情况下，索赔审查块已被移除)。过程200随后结束。一般来讲，索赔可接受通知将包括允许所讨论的索赔被识别的识别信息和指示未检测到问题/指示索赔是可接受的。[0068]在接收到索赔可接受通知时，索赔可按正常渠道提交给保险公司。这可为自动过程(即，提交者系统110被配置为在接收到索赔可接受通知时自动提交索赔)或手动过程(即，提交者系统110的操作者必须采取进一步动作)。[0069]在216处，已识别潜在的或可能的缺陷。在这种情况下，审查系统120生成缺陷通知，所述缺陷通知提供关于已识别的一个或多个缺陷的建议并将其传送至提交者系统110。[0070]在将缺陷通知直接传送至审查系统客户端应用程序112的情况下，提交者系统110接收该通知并呈现缺陷界面，该缺陷界面显示缺陷通知(或从其得出的信息)。通过缺陷界面，提交者系统110的操作者可查看缺陷和相关信息，对索赔进行更改，和/或提供关于所提出的缺陷的意见。然后，提交者系统110的操作者可以将索赔(如修改的和/或具有意见的(如果提供的话))重新提交给索赔审查系统120。[0071]一般来讲，缺陷通知将包括允许所讨论的索赔被识别的识别信息、指示已经识别出缺陷以及与这些缺陷相关的信息(例如，建议的审查动作，诸如“请审查该外科手术中是否使用了多个瓣膜”)。在某些实施方案中，与缺陷相关的信息还可包括一个或多个规则标识符，所述规则标识符指示被触发而导致缺陷的规则。[0072]下表c提供了用于将来自索赔审查系统120的索赔缺陷信息传送至提交者系统110(或具体地，传送至在其上操作的索赔审查客户端应用程序112)的示例性json格式：[0073][0074]表a：示例性索赔数据json格式[0075]关于索赔的缺陷通知也可(或作为另外一种选择)通过电子邮件(例如，通过电子邮件发送至由与所讨论的索赔审查请求相关联的提交者系统110提供的电子邮件地址)或替代的通信信道来传送。图8提供了关于已检测到问题的关于索赔的缺陷通知的示例性电子邮件格式。[0076]转到图3，在252处，审查系统120已经确定在202处接收的索赔审查请求是后续的索赔审查请求。在这种情况下，审查系统120从请求中提取索赔数据并将其附加/保存到已经存在的针对该请求的索赔审查系统记录(例如，通过将新的/修改的索赔数据写入索赔数据库130)。[0077]在254处，索赔审查系统120分析索赔数据(下文相对于图4所述)。[0078]在256处，索赔审查系统120确定索赔是否具有任何可能的缺陷，并且如果有，则确定缺陷的类型(例如，通过在254处处理从分析过程返回的分析报告)。如果确定索赔仅具有潜在缺陷，则处理前进至258。如果确定索赔具有任何可能的缺陷，则处理前进至262。如果确定索赔没有缺陷，则处理前进至272。[0079]在258处，审查系统120已确定对索赔的后续审查仅已识别出潜在缺陷。在这种情况下，审查系统120确定是否已提供关于所识别的所有潜在缺陷的意见。如果是，则处理前进至272。如果否，则处理前进至260。[0080]在260处，审查系统120生成另外的缺陷通知并将其传送到提交者系统110。缺陷通知的内容将取决于索赔的状态(即，如何到达260)。[0081]如果由于未提供关于任何潜在缺陷(根据258)或可能缺陷(根据262，如下所述)的提交者意见而到达260，则缺陷通知指示尚未提供意见的缺陷，并且包括对由提交者系统110的操作者添加这些意见的指导。[0082]如果由于评估员意见被接收并与一个或多个可能缺陷相关联(根据270，如下所述)而到达260，则缺陷通知将包括已添加评估员意见的可能缺陷和将由提交者系统110的操作者查看的评估员意见。[0083]在任一种情况下，一旦审查系统120已在260处生成缺陷通知并将其传送至提交者系统110，过程200就结束。[0084]在262处，审查系统120已确定对索赔的后续审查已识别出可能的缺陷。在这种情况下，审查系统120确定是否已提供关于所识别的所有可能缺陷的意见。如果否，则处理前进至260(如上所述)。如果已经为所有识别的可能缺陷提供了意见，则处理前进至264。[0085]在264处，审查系统120生成评估员输入请求并将其传送至评估员系统140。[0086]评估员输入请求包括来自所讨论的索赔的数据、在索赔中识别的缺陷、以及有关如由索赔提交者提供的那些缺陷的意见。该信息被传送到安装在评估员系统140上的审查系统客户端应用程序142，该审查系统客户端应用程序使用来自评估员输入请求的信息来生成评估员界面。通过评估员界面，评估员可审查索赔/缺陷/提交者意见并提供评估员输入。评估员输入可包括例如用于指示应当允许索赔的输入或(如果评估员不允许索赔)用于提供对索赔/其中已识别的可能缺陷的评估员意见的输入。[0087]以举例的方式，图9提供了可由评估员使用以允许索赔并为该动作提供原因/意见的示例性评估员用户界面。[0088]一旦评估员已经审查了索赔并提供了评估员输入，他或她就激活评估员界面上的提交控件或类似物，使得评估员系统140将评估员输入传送回索赔审查系统120。[0089]在266处，审查系统120从评估员系统140接收评估员输入。[0090]在268处，审查系统120处理评估员输入以查看评估员是否已批准索赔。如果是，则处理前进至272。如果否，则处理前进至270。[0091]在270处，在评估员输入中接收到的评估员意见与所讨论的索赔相关联。处理随后前进至260，其中审查系统120如上所述生成并传送缺陷通知。[0092]在272处，索赔被确定为准备好提交给保险公司。这可能是因为：在索赔中未识别到缺陷(根据256)；仅识别到潜在缺陷，但已针对所有潜在缺陷提供了提交者意见(根据258)；或识别到可能的缺陷，但索赔已由评估员批准(根据268)。[0093]因此，在272处，索赔审查系统120移除关于索赔的索赔审查块(如上所述根据212)，并且在274处生成/传送索赔可接受通知(如上所述根据214)。过程200随后结束。[0094]索赔分析[0095]上述过程200涉及对索赔的分析(在208和254处)。本节描述了根据一个实施方案的索赔分析过程。[0096]在本发明中，索赔分析由分析引擎124执行。分析引擎124是使用多个规则来分析索赔数据的规则引擎。因此，分析引擎124的配置和使用涉及通用的两组操作：创建规则的规则生成过程，以及分析过程，从而分析引擎124运行以使用规则来分析索赔数据。[0097]规则和规则生成[0098]在本发明实施方案中，由索赔审查系统120生成和使用的规则可以被分类为三个领域：必需规则、逻辑规则和关联规则。一般来讲，定义的规则包括前提条件(索赔中存在一个或多个数据项)和后置条件(如果满足前提条件，则也应存在一个或多个数据项)。[0099]每种类型的规则基于与特定索赔相关的索赔数据(例如，与患者的护理阶段相关的索赔数据)中某些数据项的存在(或不存在)。以举例的方式，索赔数据项可包括由提交者数据库系统114维护的那些项，如上所述，提交者数据库系统可包括诸如以下项：医院数据；患者识别数据；患者年龄数据；咨询医生数据；治疗医生数据(及其专长)；临床病症和/或临床代码数据；临床诊断和/或临床诊断代码数据；过去的治疗和/或治疗代码数据；过去、当前和计划的药物和剂量数据；所提议的治疗和/或治疗代码数据；实际治疗和/或治疗代码数据；所使用的植入物和/或植入物代码数据；所使用的耗材和/或耗材代码数据；手术时间长度数据；入院日期/时间数据；离院/出院日期/时间数据；住院时长数据；drg代码数据；临床记录数据；入院记录数据；转诊记录数据；和/或任何其他数据项。[0100]一般而言，必需规则限定如果一个或多个具体数据项存在于一组给定的索赔数据(规则前提条件)中，则相关项也应存在于索赔数据中。如果该相关项不存在于索赔数据中，则规则运行以生成建议—例如，包括缺失的相关项应被视为患者的护理阶段的一部分/用于包括在索赔中。[0101]以举例的方式，必需规则可限定如果患者的索赔数据包括指示单个冠状动脉支架被植入的数据项(例如，特定治疗代码)，则索赔数据还应包括关于单个冠状动脉支架的数据项。[0102]又如，必需规则可限定如果患者的索赔数据包括指示腹腔镜式缝合装置发生了“重新加载”的数据项，则索赔数据还应包括关于腹腔镜式缝合装置的数据项。[0103]一般而言，逻辑规则限定如果一个或多个具体数据项存在于一组给定的索赔数据(规则前提条件)中，则应采取一个或多个定义的逻辑动作以有效诊断、治疗或提供所需服务给患者。同样，如果由规则定义的逻辑动作不存在于索赔数据中，则规则运行以生成建议—例如，该动作应被认为是患者的护理阶段的一部分/用于包括在索赔中。[0104]以举例的方式，逻辑规则可限定如果患者的索赔数据包括指示已施用药物来治疗尿道感染的数据项，则索赔数据还应包括指示已执行尿道感染诊断的数据项。[0105]以另一个示例的方式，逻辑规则可限定如果患者的索赔数据包括指示患者有人工晶状体和青光眼引流医疗装置但仅记录了青光眼治疗的数据项，则应提出查询以与索赔提交者核对该患者在其护理阶段期间是否做过白内障手术。[0106]以另一个示例的方式，逻辑规则可限定如果患者的索赔数据包括指示执行了双膝手术但外科手术中使用的植入物与单膝手术相关的数据项，则将提出查询以与索赔提交者核对对患者执行的是单膝手术还是双膝手术。[0107]一般来讲，关联规则由专业临床或程序知识或对系统内保存的历史数据使用机器学习技术生成。使用关联规则来识别一组索赔数据内的异常模式(例如，与患者的护理阶段有关)。在异常模式被识别的情况下，关联规则导致索赔数据被标记以供进一步审查，并且如果合适的话，导致信息被添加到索赔数据。在触发关联规则的情况下，也导致建议特定动作或项目应被视为患者的护理阶段的一部分/用于包括在索赔中。[0108]以举例的方式，关联规则可在如下情况下操作：索赔数据指示患者被安排输注化疗剂并且入院日期/时间和出院日期/时间与该患者和其他患者的历史化疗剂输注相关，但化疗剂未包括在索赔数据中。在这种情况下，关联规则将导致向提交者提出查询，以查看在患者的护理阶段期间是否使用了化疗剂。[0109]又如，关联规则可在如下情况下操作：索赔数据指示患者在其护理阶段内仅具有全单膝置换手术记录，但住院时长与历史住院时长相关，在历史住院时长中，单膝置换手术还具有疼痛管理和理疗服务记录。在这种情况下，关联规则将导致向提交者提出查询，以查看在患者的护理阶段期间是否向患者提供了疼痛管理和理疗服务。[0110]以更一般的示例的方式，关联规则可以是诸如以下的形式：“在医院xxx，外科医生yyy，外科手术zzz，则索赔应包含a、b、c、d”。诸如此类的关联规则仅适用于一个医院以及该医院中的一名外科医生以及该外科医生在该医院执行的一次手术。[0111]由分析引擎124使用的规则可以各种方式生成。将参考图4描述一个示例性规则创建过程400。[0112]在402处，生成或定义规则假设。规则假设基于关于维护哪个数据的两个或更多个数据字段之间的潜在关系。规则假设可由用户设想和手动输入。规则假设也可由规则生成引擎126自动生成。规则假设可基于对(例如，索赔数据库130和/或学习数据库134中的)可用数据的分析，使用诸如购物篮分析的技术或任何其他适当的技术来自动生成。[0113]以例证的方式，示例性规则假设可以是：当成年男性进行单膝手术时，他们将具有用作其手术的一部分的疼痛管理装置；当成年男性进行双膝手术时，他们将具有用作其手术的一部分的疼痛管理装置；当成年女性进行单膝手术时，他们不具有用于其手术的疼痛管理装置；当成年女性进行双膝手术时，他们不具有用于其手术的疼痛管理装置。[0114]在404处，规则生成引擎126测试在402处生成的规则假设，以确定在索赔假设中识别的数据字段之间是否存在足够强的关系。404处的假设测试能够以各种方式执行，例如通过统计方法和/或机器学习技术。以举例的方式，继续上述示例性假设，可采用各种统计方法来评估在单膝手术和双膝手术中成人患者性别与疼痛管理装置的使用之间关系的强度。[0115]在406处，规则生成引擎126确定在索赔假设中识别的数据字段是否表现出足够强的关系(例如，基于数据点之间的相关性、概率或其他形式的关系)。如果是，则处理前进至408。如果否，则过程400结束。[0116]以举例的方式，并且假设数据字段之间的关系以数值项(例如，相关系数)表示：如果关系小于下限阈值，则索赔假设被拒绝；如果关系大于/等于下限阈值但小于上限阈值，则假设被接受(并且随后的规则被视为涉及潜在/次要缺陷)；如果关系大于上限阈值，则假设被接受(并且随后的规则被视为涉及可能/主要缺陷)。可根据需要选择具体阈值，但作为具体示例，下限阈值可为80％，并且上限阈值可为90％。[0117]在408处，生成基于假设的草案规则。该规则能够以编程方式生成或由审查所述假设和结果的评估员生成。[0118]以举例的方式，由上述假设之一产生的自然语言规则可遵循以下命令行：ifmaleand>18yearsold(i.e.yearof‘dateofsurgery’‑yearofbirth＝>18)andsingleorbilateralkneesurgery,thenpainmanagementdeviceshouldbeclaimed。在该自然语言规则表达式中，“should”指示规则关于潜在/次要缺陷。如果规则与可能/主要缺陷有关，则伴随规则的建议的措辞将更强烈，例如“…thenpainmanagementdevicemustbeclaimed”。(当然，即使是主要缺陷，仍可证明此规则不适用‑尽管违反此规则，评估人员仍可在审查之后接受索赔。)[0119]在410处，规则生成引擎126在测试数据集上通过草案规则。在本示例中，测试数据集由学习数据库134维护。[0120]在411处，评估员评估将规则应用于测试数据集的结果，以确定是否要维护/发布或拒绝规则。如果规则被拒绝，则处理结束。如果要继续规则，则处理前进至412。[0121]在412处，规则生成引擎126生成草案规则的优先级评分。优先级评分可基于各种因素，例如用于验证草案规则适用性的临床专业知识的可用性、草案规则的美元影响、草案规则将被调用的预期频率和/或其他因素。草案规则的优先级评分用于帮助按优先级顺序提交草案规则给评估员以供评估员进行输入(例如，根据414和416)。[0122]在414处，规则生成引擎126将草案规则(和相关联的数据–例如，在410处在测试数据集上通过草案规则的结果以及在412处生成的优先级评分信息)传送到规则评估员。这能够以各种方式执行。例如，草案规则(和相关联的数据)可被传送到安装在评估员系统140上的审查系统客户端应用程序142。应用程序142生成规则评估界面，该规则评估界面可由规则评估员使用以审查草案规则和相关联的数据并提供输入。该输入可例如将批准草案规则、拒绝草案规则或修改草案规则。[0123]在416处，规则生成引擎126接收并处理关于草案规则的规则评估员输入。[0124]在416处，如果规则评估员输入指示规则将被拒绝，则过程400结束。[0125]在416处，如果规则评估员输入提供对规则的修改，则规则生成引擎126在418处进行这些修改，然后将修改的规则传回410，使得修改的规则可在测试数据集上通过。[0126]如果在416处，规则评估员输入允许该规则，则处理前进至420。除了接受规则之外，评估员还指示规则类型，例如规则是关于潜在缺陷还是可能的缺陷。如上所述，在某些实施方案中，基于规则的测试有效性(例如，如通过在402处测试规则所确定的关系的强度)来确定规则相关的缺陷类型(潜在或可能的缺陷)。[0127]在420处，规则生成引擎126保存规则(例如，通过将其添加到规则数据库132)，使得其可应用于传入的索赔请求。过程400随后结束。[0128]索赔分析[0129]图5提供了指示在索赔分析期间(例如，在过程200的208和254处)执行的操作的流程图。[0130]在502处，分析引擎124接收或访问索赔数据。这可例如从索赔数据库130访问。[0131]在某些实施方案中，分析引擎124被配置为过滤可潜在地应用于给定索赔请求的规则。在这种情况下，在503处执行过滤。如果不执行规则的过滤，则处理从502直接前进至504。[0132]在503处，在被实施的情况下，分析引擎根据一个或多个过滤标准来过滤规则的超集(即规则数据库132中的所有规则)。这生成在504处考虑的规则的子集。过滤标准可涉及具体规则或具体类型的规则，并且通常将是提交者特定的。例如，特定的提交者a可能仅希望被告知可能的缺陷而不是潜在缺陷。在这种情况下，当分析从提交者a接收的任何索赔审查请求时，分析引擎124将过滤规则，使得所得的子集仅包括与可能的缺陷相关的规则。[0133]在504处，分析引擎124处理(例如，来自规则数据库132的)适用的规则以确定是否有任何规则潜在地适用于索赔数据。在503处执行过滤的情况下，适用的规则将是由过滤过程产生的规则的子集。在不执行过滤的情况下，适用的规则将是规则的超集(例如，规则数据库132中的所有规则)。[0134]一般来讲，确定规则适用性涉及评估索赔数据以确定是否满足规则前提条件。如果是，则确定规则潜在地适用，如果否，则确定规则并非潜在地适用。继续上述示例性关联规则(“在医院xxx，外科医生yyy和外科手术zzz，则索赔应包含a、b、c、d”)，确定该规则是否潜在地适用涉及确定所讨论的索赔是否涉及医院xxx、外科医生yyy和外科手术zzz(规则前提条件)。如果索赔涉及所有这些事项，则满足规则前提条件，并且规则潜在地适用。如果否，则规则并非潜在地适用。[0135]如果一个或多个规则被确定为潜在地适用，则处理前进至506。如果规则均并非潜在地适用，则该过程结束。[0136]在506处，分析引擎124选择下一个未处理规则，该下一个未处理规则已被确定为潜在地适用于索赔数据。[0137]在508处，分析引擎124针对索赔数据测试在506处选择的规则。一般来讲，这涉及分析索赔数据以确定在索赔中是否存在与规则相关联的后置条件。如果存在后置条件，则规则不适用。如果不存在后置条件，则规则确实适用。[0138]再次继续上述示例性关联规则(“在医院xxx，外科医生yyy和外科手术zzz，则索赔应包含a、b、c、d”)，确定该规则是否适用涉及确定所讨论的索赔是否包含a、b、c、d中的全部(即，存在规则后置条件)。如果索赔已经包括a、b、c、d中的全部，则规则不适用(不需要建议/要求添加a、b、c、d，因为它们已经包括在索赔中)。另选地，如果a、b、c、d中的任一者不在索赔中，则规则确实适用(在这种情况下，需要建议a、b、c、d中的一者或多者包括在索赔中)。[0139]将规则应用于索赔数据生成规则应用结果。规则应用结果指示规则不适用或指示规则确实适用。在应用结果指示规则确实适用的情况下，其还包括来自适用规则的建议—即，一个或多个项目应该/必须(取决于规则是否涉及潜在/次要缺陷或可能/主要缺陷)被考虑包括在索赔中。[0140]在510处，分析引擎124(根据规则应用结果)确定当前规则是否适用于索赔数据。如果是，则处理前进至512。如果否，则处理前进至514。[0141]在512处，分析引擎124已经确定当前规则确实适用于索赔数据。在这种情况下，分析引擎124将规则应用结果(或从其导出的信息)附加到分析报告。继续以上示例，在规则被确定为适用的情况下，与该规则相关联的建议(例如，建议一个或多个特定动作或项目应被认为是患者的护理阶段的一部分/用于包括在索赔中)被附加到分析报告。处理随后前进至514。[0142]在514处，分析引擎确定是否存在潜在地适用于尚未测试的(如在504处所识别的)索赔数据的任何规则。如果是，则处理返回至506，其中下一个未处理规则被选择以供测试。[0143]在514处，如果已经测试了所有潜在适用的规则，则处理前进至516。在516处，分析引擎124返回分析报告并且处理结束。[0144]示例性审查系统架构[0145]在某些实施方案中，索赔审查系统120是提供索赔审查作为服务的云托管系统。图6提供了具有用于云实现的微服务架构的示例性审查系统120。将使用amazonweb服务(aws)平台作为特定的云提供商来描述微服务架构。然而，可使用另选的云提供商或本地托管。此外，不同的具体实施可利用另选的架构，例如具有附加的、更少的或另选的服务的架构。[0146]架构600包括用于在索赔上传服务器604之间路由传入审查请求的负载平衡服务。在aws上下文中，amazon的弹性负载平衡(elb)服务被配置为提供负载平衡服务并将外部请求映射到提供额外安全层的内部终端。[0147]架构600包括一个或多个索赔上传服务器604，审查系统客户端应用程序112可连接到该一个或多个索赔上传服务器以上传索赔进行审查。在aws上下文中，索赔上传服务器604由弹性计算云(ec2)服务提供，该服务允许基于需求缩放服务器容量，即，通过根据需要部署/移除虚拟服务器。然而，索赔上传服务器604将来可由无服务器服务(例如，awslambda)替换。[0148]架构600包括存储服务606，该存储服务用于存储关于从审查系统客户端应用程序112接收的索赔的数据。在aws环境中，存储服务606由amazon简单存储服务(s3)提供。[0149]架构600包括管理api连接608，其用于维护由索赔上传服务器604用来与审查系统客户端应用程序112通信的api。在aws环境中，管理的api连接608由awsapi网关服务提供。[0150]架构600包括用于监视索赔审查系统120的各种部件的医疗系统监视服务610。在aws环境中，监视服务610由amazoncloudwatch提供。[0151]架构600包括一个或多个索赔路由服务器612，该一个或多个索赔路由服务器托管用于对索赔进行路由的控制器。在aws环境中，索赔路由服务器612由ec2服务提供。在另选的实施方案中，索赔路由服务器612可由无服务器服务(例如，awllambda)替换。[0152]架构600包括邮件服务器614，其用于将索赔审查结果通过电子邮件发送到相关的提交者。在aws环境中，电子邮件服务可由amazon简单电子邮件服务(ses)提供。[0153]架构600包括用于分析索赔的分析引擎616(例如，规则引擎)。在aws环境中，分析引擎由ec2服务提供。[0154]架构600包括用于存储由索赔分析服务器执行的索赔分析的数据和结果的索赔结果数据库618。在本示例中，索赔结果数据库618是由amazon关系数据库服务(rds)提供的关系数据库。[0155]架构600包括相对于索赔结果数据库618提供各种报告功能的报告服务620。以举例的方式，报告服务620可使用tableau或类似产品来提供。[0156]除了上述服务之外，还提供了安全服务622。以举例的方式，安全服务622可使用cloudflare或类似产品来实现。[0157]在上述示例性微服务架构中，提交者向审查系统120提交索赔的流程如下：[0158]1.提交者提交索赔。[0159]2.包含api密钥和json消息的请求被发送到审查系统120。[0160]3.该请求由验证api密钥的api网关接收[0161]4.如果已认证，则将请求转发到审查系统应用程序服务器中[0162]5.审查系统应用程序服务器基于手术日期检查住院的截止值和有效期[0163]a.如果任何字段无效(例如，由于索赔中的代码不在其有效日期范围内)，则将响应传送给提交者以把这个通知他们并完成所述过程[0164]b.否则，请求将继续通过crs[0165]6.应用程序服务器将该请求转发到分析引擎618。[0166]7.分析引擎根据所有适用的规则来验证该请求。[0167]8.来自规则引擎的响应被发送回应用程序服务器。[0168]9.应用服务器将响应返回到电子邮件服务器，该电子邮件服务器将最终结果发送到提交者电子邮件地址和/或提交者系统(例如，在其上运行的客户端应用程序)。[0169]硬件概述[0170]本发明必须使用一个或多个计算机处理系统来实现。具体地，提交者系统110、索赔审查系统120和评估员系统140中的每一者是计算机处理系统(或一起工作的若干计算机处理系统)。[0171]图7提供了计算机处理系统700的一个示例的框图。如图7所示的系统700是通用计算机处理系统。应当理解，图7未示出计算机处理系统的所有功能或物理部件。例如，没有示出电源或电源接口，然而系统700将携带电源或被配置用于连接到电源(或两者)。还应当理解，特定类型的计算机处理系统将确定适当的硬件和架构，并且适用于实现本发明的各方面的另选的计算机处理系统可具有附加的、另选的或比所示那些部件更少的部件，组合两个或更多个部件，和/或具有不同的部件配置或布置。[0172]计算机处理系统700包括至少一个处理单元702。处理单元702可以是单个计算机处理设备(例如，中央处理单元、图形处理单元或其他计算设备)，或者可包括多个计算机处理设备。在一些情况下，所有处理将由处理单元702执行，然而，在其他情况下，处理也可或另选地由系统700(以共享或专用的方式)可访问和使用的远程处理设备执行。[0173]通过通信总线704，处理单元702与存储用于控制处理系统700的操作的指令和/或数据的一个或多个机器可读存储(存储器)设备进行数据通信。在这种情况下，系统700包括系统存储器706(例如，bios)、易失性存储器708(例如，随机存取存储器，诸如一个或多个dram模块)和非易失性存储器710(例如，一个或多个硬盘或固态驱动器)。[0174]系统700还包括通常由712指示的一个或多个接口，系统700经由该一个或多个接口与各种设备和/或网络接合。一般来讲，其他设备可与系统700物理地集成，或者可物理地分离。在设备与系统700物理分离的情况下，设备和系统700之间的连接可经由有线或无线硬件和通信协议，并且可为直接或间接(例如，联网)连接。[0175]与其他设备/网络的有线连接可通过任何适当的标准或专有硬件和连接协议来实现。例如，系统700可被配置用于通过以下中的一者或多者与其他设备/通信网络进行有线连接：usb；firewire；esata；thunderbolt；以太网；os/2；并行；串行；hdmi；dvi；vga；scsi；音频端口。当然，其他有线连接也是可能的。[0176]与其他设备/网络的无线连接可类似地通过任何适当的标准或专有硬件和通信协议来实现。例如，系统700可被配置用于使用以下中的一者或多者与其他设备/通信网络进行无线连接：红外；蓝牙；wi‑fi；近场通信(nfc)；全球移动通信系统(gsm)、增强型数据gsm环境(edge)、长期演进(lte)、宽带码分多址(w‑cdma)、码分多址(cdma)。当然，其他无线连接也是可能的。[0177]一般来讲，系统700所连接的设备，无论是通过有线还是无线方式，都允许数据被输入到系统700中/被系统700接收以供处理单元702处理，并且允许数据被系统700输出。下文描述了示例性设备，然而应当理解，并非所有计算机处理系统都将包括所有提及的设备，并且也可使用所提及的那些设备的附加和替代设备。[0178]例如，系统700可包括或连接到一个或多个输入设备，信息/数据通过该一个或多个输入设备输入到系统700中(由该系统接收)。此类输入设备可包括物理按钮、字母数字输入设备(例如，键盘)、指向设备(例如，鼠标、触控板等)、触摸屏、触摸屏显示器、麦克风、加速度计、接近传感器、gps设备等。系统700还可包括或连接到由系统700控制的一个或多个输出设备以输出信息。此类输出设备可包括诸如指示器(例如，led、lcd或其他灯)、显示器(例如，crt显示器、lcd显示器、led显示器、等离子体显示器、触摸屏显示器)、音频输出设备诸如扬声器、振动模块和其他输出设备的设备。系统700还可包括或连接到可充当输入和输出设备两者的设备，例如可供系统700读取数据和/或向其写入数据的存储器设备(硬盘驱动器、固态驱动器、磁盘驱动器、紧凑型闪存卡、sd卡等)，以及既可显示(输出)数据又可接收触摸信号(输入)的触摸屏显示器。[0179]系统700还可连接到通信网络(例如，互联网、局域网、广域网、个人热点等)以将数据传送到联网设备并从联网设备接收数据，联网设备本身可以是其他计算机处理系统。[0180]应当理解，作为非限制性示例，系统700可以是任何合适的计算机处理系统，诸如台式计算机、膝上型计算机、上网本计算机、平板电脑、智能电话、个人数字助理(pda)、蜂窝电话、web设备。通常，系统700将至少包括用户输入和输出设备714和(如果系统要联网)用于与网络102通信的通信接口716。系统700包括或连接的设备的数量和具体类型将取决于系统700的特定类型。例如，如果系统700是台式计算机，则其通常将连接到物理分离的设备，诸如(至少)键盘、指向设备(例如鼠标)、显示设备(例如lcd显示器)。另选地，如果系统700是膝上型计算机，则其通常将包括(以物理集成的方式)键盘、指向设备、显示设备和音频输出设备。还另选地，如果系统700是平板设备或智能电话，则其通常将包括(以物理集成的方式)触摸屏显示器(提供输入装置和显示输出装置两者)、音频输出设备和一个或多个物理按钮。[0181]系统700存储软件或具有对软件(例如，计算机可读指令和数据)的访问权限，该软件在由处理单元702处理时将系统700配置为接收、处理和输出数据。此类指令和数据通常将包括操作系统，诸如microsoftappleosx、appleios、android、unix或linux。[0182]系统700还存储软件或具有对软件的访问权限，该软件在由处理单元702处理时将系统700配置为执行根据本文所述的实施方案的各种计算机实现的过程/方法。此类软件的示例包括分别安装在提交者系统110和评估员系统140上的审查系统客户端应用程序112和142。在上述示例中，审查系统的每个服务也由软件实现。应当理解，在一些情况下，给定计算机实现的方法的一部分或全部将由系统700自身执行，而在其他情况下，处理可由与系统700进行数据通信的其他设备执行。[0183]指令和数据存储在系统700可访问的非暂态机器可读介质上。例如，指令和数据可存储在非暂态存储器710上。指令可经由(例如)通过有线或无线网络连接启用的传输信道中的数据信号传输到系统700/由系统700接收。[0184]在前述说明书中，已参考可因具体实施而异的许多具体细节来描述本发明的实施方案。因此，对本发明以及申请人所预期的本发明的独有的指示是一组权利要求，这些权利要求以其产生的具体形式产生于本技术中，包括任何后续的修正。本文针对包含在此类权利要求中的术语明确阐述的任何定义应以权利要求中使用的这些术语的含义为准。因此，权利要求中未明确列举的限制、元件、特性、特征、优点或属性不应以任何方式限制此类权利要求的范围。因此，说明书和附图将被视为示例性而非限制性的。[0185]如本文所用，术语“包括”和“包含”(以及那些术语的变型，诸如“具有”、“含有”、“涵盖”、“由...组成”、“由...构成”等)旨在为包括性的，并且不旨在排除其他特征、部件、整数或步骤。[0186]已使用流程图描述了本公开的各种特征。给定流程图步骤的功能/处理可潜在地以各种不同的方式并通过各种不同的系统或系统模块来执行。此外，给定的流程图步骤可分成多个步骤，和/或多个流程图步骤可组合成单个步骤。此外，在不脱离本公开的范围的情况下，可改变步骤的顺序。[0187]应当理解，本说明书中公开和限定的实施方案延伸到从文本或附图中提及或显而易见的单独特征中的两个或更多个单独特征的所有另选组合。所有这些不同的组合构成实施方案的各种另选方面。当前第1页12当前第1页12