CN101645151A - 用于卫生保健服务的计算机结算和发票验证系统 - Google Patents

Abstract

一种能让付款方对卫生保健服务提供方的收费进行验证、并能更好地管理缔约和绩效管理功能的计算机结算和发票验证应用程序，本应用程序支持主张裁断和付款处理。它对从卫生保健服务提供方接收的所有病人活动数据进行验证。病人活动数据涉及与单个病人医护事件相关的事件。本应用程序应用涉及付款方临床和财务要求的事件规则。本应用程序追踪这些规则应用于事件的相关细节，然后识别事件不合规则的原因。不合规则的事件被发送给合适的人员进行审核和采取行动。审核后，事件可能被接受，予以付款，也可能因不同原因被质询。本程序实现了各种人工任务的自动化处理，人工审核任务被仅限于那些需要进一步注意和采取行动的活动。

Description

用于卫生保健服务的计算机结算和发票验证系统

相关申请的交叉引用

[0001]本申请要求2008年8月7日提交的、名为“用于卫生保健服务的计算机结算和发票验证系统”的美国临时专利申请61/086,996的优先权，这里通过引用将其并入本文。

技术领域

[0002]本申请涉及用于卫生保健服务主张的结算和验证的计算机应用程序。具体来说，本发明涉及供付款方使用的计算机结算和发票验证应用程序，付款方依照临床和财务规则，使用该程序接受卫生保健服务索款要求或对其提出质询。

背景技术

[0003]全世界的许多卫生保健系统中，第三方付款方负责管理和提供向特定社区内个人提供基本卫生保健服务的程序。在提供国有化卫生服务的国家，付款方是被授权通过政府付费向所有国民提供卫生保健服务的政府机构或实体。这些付款方通常与全国各地理区域的服务提供方签订卫生保健服务供给协议。服务收费转给付款方，经审核后，由付款方将费用支付给提供服务的服务提供方。大多数卫生保健系统中，个人第一次遇到特定健康问题时，一般先去看医生、牙医、眼科医生、药剂师或其他初级卫生保健服务提供方。为了使特定地理区域内能提供初级保健服务，付款方可以与各类不同的卫生保健服务提供方签订协议，运营非预约医疗中心(walk-in center)或诊所，提供电话服务。付款方通常与各地的卫生保健服务提供方以及地方权力机关和在当地提供卫生与社会保健服务的其他机构协作，以确保当地社区的需要得到满足。

[0004]各地的初级保健服务提供方经常处于国家卫生系统的中心，占卫生系统预算的75-80％。由于这些提供方属于地方组织，所以他们最清楚所在社区的需要，能保证提供有效的卫生与社会保健服务。例如，他们可以确保该地区具备令人满意的服务水平，而且能保证当地居民方面快捷地获得这些服务。他们还能保证提供合适的服务范围。他们开办和运营医院、诊所、非预约医疗中心和药店等机构，配备专业人员和设备，提供医疗服务、牙科服务、眼科服务、精神健康服务、配药服务，甚至病人运送(包括事故和急诊)和人群筛检服务。他们协调各种系统和活动，为保健当地病人的利益而共同协作。

[0005]近几年，有一些国家的全国卫生系统采用“根据结果付款”(Payment by Result，PbR)模式，支付由政府付款方宣布承担的费用。PbRs的目的是建立一个透明的、基于规则的系统，利用该系统向地方初级保健服务提供者支付费用。它们是要奖励效率、支持病人的选择和多样化，并且鼓励开展旨在缩短可承受等候时间的活动。将付款与活动挂钩，并使其适用病例组合。PbR系统为卫生保健资金提供了公正一致的基础，而不再主要依赖历史预算和个体管理者们的谈判技巧。

[0006]随着“根据结果付款”(PbR)模式的出现，目前是由卫生保健服务提供方就其提供的各项服务(活动)，按照全国定价或地方协议费率，向付款方收费。付款方通过不同途径获得所有收费活动的数据。例如，在英国，通过国家传送专线(national feed)或二级医护数据源如二级使用服务(Secondary Usage Services，SUS)可以取得这一数据。在称为“冻结日”(Freeze Day)的生效日之前，等待付款方验证数据，解决争议或“质询”。

[0007]大多数情况下，付款方没有一套系统的方法，能在应用符合PbR模式的付款和业务规则时保持一致性。而且他们还很难鉴别出现反常情况的活动，需要人工进行手动处理。大多数付款方采用手动或用桌面工具像Microsoft Excel或Access对数据进行处理。由于付款管理过程涉及非常多的个体，所以对规则的应用可能并不一致。

发明内容

[0008]本发明是计算机结算和发票验证应用程序，它能让付款方对卫生保健服务提供方的收费进行验证，并能更好地管理他们的缔约和绩效管理职能。本应用程序包括用于索赔裁断和付款处理的特征和功能性。本应用程序的首要目的是要帮助付款方对接收的来自初级保健提供方的所有病人活动数据进行验证。病人活动数据涉及整个事件(spell)(包括入院和出院或转院的医护事件)和事件(episode)(一个医护事件)。整个事件可能包括若干个事件。它贯穿一致地应用一套完善的规则，并且在适当时，给专门人员提供足够的信息，据此对特定活动的收费(账单)提出质询。

[0009]本计算机应用程序能处理来自卫生保健计算机系统发送的数据包，这些系统并不提供用于直接病人医护的数据，而是提供为管理和临床目的使用的数据，如卫生保健计划、临床管理、绩效提高和医疗研究。这类数据管理系统例如有英国二级使用服务(Secondary UsesServices，SUS)系统。本应用程序能应用相关数据质量规则来检测不完善或不精确的数据，能将数据装载到相关数据库中，应用各种相关费用核算和业务规则，自动将具有潜在反常情况的活动发送给付款方代表进行审查和采取行动(接受或质询)。该程序使付款方能自动操作一整套需要繁重人力完成的任务，并且仅对需要进一步注意和采取行动的活动进行审核。该系统还提供了对需要予以质询的活动、数据质量、卫生服务提供方出现的反常情况中的趋势作出的多项报告和绩效管理报告。

附图说明

[0010]图1A和1B是阐示如何将不同数据质量和业务规则应用到单一事件中的流图。

[0011]图2是阐示与第三方数据有关的行为的流图。

[0012]图3是质询管理员(Challenge Manager)使用的收件箱的屏幕截图；

[0013]图4是操作管理员(Operations Manager)使用的收件箱的屏幕截图；

[0014]图5是临床质检员(Clinical Checker)使用的收件箱的屏幕截图；

[0015]图6是包含事件细节的屏幕；以及

[0016]图7是包含更多事件细节的屏幕。

具体实施方式

[0017]数据输入：结算和发票验证应用程序接收来自不同来源的二级医护数据，以验证病人在付款方指定机构内接受的各项服务所对应的活动数据。这些二级数据支持业务规则以及结算和鉴别反常情形所要求的其他条件。在一个具体实施例中，结算部分接收二级医护数据。该实施例中，如果付款方需要的话，可以将其他二级医护数据包(如SLAM、PAS等)与结算和发票验证应用程序的数据库进行映射，使这些数据能被导入并使用。将应用程序可能需要的其他标准数据集预先装载到应用程序的存储库内。这些标准数据集例如包括基于卫生保健资源分类法(Healthcare Resource Groups，HRG)、诊断代码(ICD10)和疗程/治疗代码(如英国的OPCS代码、美国的CPT代码)的国家价格。当执行用于一特定国家卫生保健系统的结算和发票验证应用程序时，先对签订的地方合同进行分析，然后将相关条款录到应用程序的存储库中。还可以把每个付款方病人登记簿中的全科医师(GP)或家庭医生相关数据存到应用程序的存储库中。这样，在处理事件数据时，如果需要，可以同时应用国家和地方的标准和数据。

[0018]在应用于英国国家卫生保健系统的一具体实施例中，以下不同来源的数据被接收，并存到应用程序的一个或多个存储库中。

[0019]表1——结算和发票验证应用程序的数据来源

[0020]附录B中列举了详细的规则表。

[0021]参照图1A和1B，所示流图阐示了如何将各种不同数据质量和业务规则应用到事件中。这些规则被应用到向病人提供医护的事件相关记录中，事件中记录了病人生日、性别、诊断、疗程、治疗日期等相关数据。这些事件可以发生在整个事件期间，包括在医院或其他卫生保健机构驻留期间，事件中记录了病人生日、性别、诊断、疗程以及入院和出院日期或转到其他医院或卫生保健机构的日期等相关信息。典型的结算和发票验证应用程序的流程概括于表2。

[0022]表2——结算和发票验证应用程序流程

装载数据	应用程序接收输入的二级来源数据(如二级医护数据)，并装载到应用程序的存储库内。
		处理记录100(图1A)	分组处理记录。只要组内含有记录，应用程序就不断地处理记录。
数据验证程序101(图1A)	将数据验证程序应用于记录(102)。该验证程序确认记录中存在预期数据。
		重复记录检查104(图1A)	将记录与事件的现有记录进行比较(104)。重复记录标记为重复(106)。
数据质量验证108(图1A)	将数据质量验证程序应用于记录(108)。验证程序确认数据值在预期范围内或符合其他标准。将没有通过质量验证步骤110的记录标为“质询”(116)。联系提供方，使该项记录的问题能得到解决。
		临床前验证112(图1A)	将通过质量验证步骤的记录移到临床前验证步骤112。临床前验证过程中，应用与病人医护事件相关的规则，确定所提供的医护措施是否符合付款方制定的病人医护要求或标准(如：医护措施是否适当)
财务前验证114(图1A)	将通过质量验证步骤的记录移到财务前(PreFinancialvalidation)验证步骤114。在财务前验证中，应用与事件付费相关的规则，确定对所提供医护服务的收费是否符合付款方制定的财务要求或标准(如定价验证、发票验证)。
		质询记录检查118(图1A)120(图1A)	将没有通过临床前验证步骤112或财务前验证步骤114的记录标记为质询。如果组内所有记录都不合格(标记为“质询”)(118)，则停止处理这些记录。如果组内任一记录不合格(标记为“质询”)(120)，则将涉及不合格原因的数据记录到数据库122中，将该记录标为“质询”(124)。
门诊病人(OP)价格126(图1A)	继续处理通过临床前验证步骤112和财务前验证步骤114的记录。如果该记录涉及门诊病人事件130，则应用合适的门诊病人价格(128)。该价格覆盖与该病人医护事件(如检测、用药、治疗)有关的所有活动。
		事故&急诊(AE)价格130(图1A)	继续处理通过临床前验证步骤112和财务前验证步骤114的记录。如果该记录涉及事故或急诊事件126，则应用合适的门诊病人价格(132)。该价格覆盖与该病人医护事件(如检测、用药、治疗)有关的所有活动。
已完成会诊事件(FCE)134(图1A)	继续处理通过临床前验证步骤112和财务前验证步骤114的记录。如果该记录涉及已经完成的会诊事件(FCE)134，则对该记录进行转换，供进一步处理(如转换成逗号分隔值(CSV)文件)136。应用整个事件相关规则(138、140)，同时确定FCE价格(142)

处理记录144(图1B)	继续处理组内记录，直到遇到最后一项记录(144)。遇到最后一项记录时，将与处理记录相关的数据存到数据库中(156)。
		临床后验证146(图1B)	临床后验证146中，将不符合一项或多项临床前验证规则的记录传送给指定的临床人员，由其审核各事件的记录和相关数据并决定是否接受或提出质询。如果该审核员接受该项记录(成功——是)(150)，则标为“S”表示成功(152)，记录处理至此结束。如果审核员决定不接受该记录(成功——否)(150)，则标为“D”表示决定(154)，记录处理至此结束。
财务后验证148(图1B)	财务后验证148中，将不符合一项或多项临床前验证规则的记录传送给指定的财务人员，由其审核各事件的记录和相关数据并决定是否接受或提出质询。如果该审核员接受该项记录(成功——是)150，则标为“S”表示成功(152)，记录处理至此结束。如果审核员决定不接受该记录(成功——否)150，则标为“D”表示决定(154)，记录处理至此结束。

[0023]工作流程&状态：结算和发票验证应用程序使用工作流程引擎，将潜在的可质询事件发送给指定人员，他们能看到各事件的数据和相关信息并决定是否接受或提出质询。如表3所示，该工作流程引擎设计用来对质询进行管理。

[0024]表3——结算和发票验证应用程序质询管理

数据质量质询	将涉及数据质量事宜的事件不发送给任何人进行接受或质询。直接将它们标记为质询。
		其他可质询事件	所有其它没有通过一项或多项规则的事件遵循两步流程法。首先，将它们发送给依赖该规则组的主题专家(subject matterexpert)。主题专家一旦接受或作出质询标记后，则将该事件发送给能要么同意、要么否决主题专家的质询管理员。

[0025]规则一旦应用于某一事件后，该事件就处于表4所示的一种状态中。

[0026]表4——事件状态

第一通过/空白(FP)状态	事件符合所有规则，是空白的。
		未分配(UA)状态	事件不符合一项或多项规则，目前没有主题专家在审核确定是否接受或质询。
调查进行中(UI)状态	事件不符合一项或多项规则，主题专家目前正在调查，但尚未决定是否接受或质询。
		接受(AC)状态	事件不符合一项或多项规则，专题专家已决定接受事件并付款。
质询(CH)状态	事件不符合一项或多项规则，专题专家

已决定对该事件提出质询。

[0027]工作流程状态改变：一旦对事件作出质询标记后，其处于未分配(UA)状态。然后将该事件转到合适的主题专家(subject matterexpert)的电子收件箱中。专题专家一旦选定某一事件作进一步调查时，该事件的状态即变为调查进行中(UI)。一旦专题专家决定接受该事件时，其状态变为“接受”(AE)。如果主题专家决定对该事件提出质询，则其状态变为“质询”(CH)。

[0028]新数据文件对状态的影响：付款方会定期收到来自第三方来源(如二级医护数据)的事件数据更新文件。结算和发票验证应用程序会基于数据的变化和程序内事件的当前状态采取一项或多项行动。图2中的流图阐示了涉及第三方数据的行动。表5是对这些行动的解释。

[0029]表5——付款方的第三方数据更新

装载记录200	每次接收新的二级医护数据文件时，应用程序读取文件中的数据，并将其装载到程序内。
		与现有记录比较202	应用程序比较新文件中的事件数据与来自先前发送文件的已装载到程序数据库中的数据。检查数据，确认是否改变(204)。提供方有可能基于与付款方的质询对话对数据作出一些调整。
维持现有状态206	如果新文件中的事件数据没有变化，结算和发票验证应用程序则维持数据库中的现有状态。
		检查记录状态208	如果新文件中的事件数据发生变化，则结算和发票验证应用程序检查事件状态并采取以下适当的行动：FP210或UA212状态：重新设置状态并再次运行规则。规则运行后，事件状态变为FP(符合规则)或UI(不符合规则，目前未分配)。将新的事件数据与老的事件数据和所做决定链接起来(214)。UI216、AC218或CH220状态：重置状态，重置对主题专家的分配，重置所有规则标记(事件不符合的那些规则)，再次运行规则。规则运行后，事件状态变为FP(符合规则)或UI(不符合规则，目前未分配)。将新事件数据与老的事件数据和所做决定链接起来(222)。

[0030]应用程序角色&特权：结算与发票验证应用程序支持多种角色。这些角色概括于表6中。

[0031]表6——应用程序角色&特权

质询管理员	质询管理员决定是否接受事件或对其质询。将质询/接受发送给能推翻其他人所做决定的质询管理员。质询管理员可以访问所有报告。质询管理员还可以与付款方协作解决待完成的质询。图3所示为质询管理员使用的收件箱的屏幕截图。可以根据分类对质询进行统筹安排(如临床验证、发票验证)(300)。
		操作管理员	操作管理员管理结算操作的日常活动，并监控发票和质询库存水平。操作管理员可以访问所有不符合一项或多项规则的事件。操作管理员能接受事件/对事件质询，还可以看到所有的报告。图4所示为操作管理员使用的收件箱的屏幕截图。
主题专家：发票质检员或临床质检员	主题专家鉴别和解决数据质量事宜，并确定质询需求。他们还负责验证事件。主题专家还能看到其专长领域内不符合一项或多项规则的事件并决定接受那些事件或对其提出质询。例如，临床质检员查可以看到不符合一项或多项临床规则的事件。主题专家不能访问所有报告。图5所示为临床质检员所用收件箱的屏幕截图。

[0032]收件箱功能：结算和发票验证应用程序的用户能通过基于网络的收件箱访问各事件。该电子收件箱允许这些用户查看不符合一项或多项规则的事件，查看相关数据，以及接受这些事件或对其质询。一些用户还可以通过收件箱看到各种不同的报告。

[0033]图4所示为操作管理员屏幕。屏幕400的顶部是公告部分。付款方可以发布一条或多条结算和发票验证应用程序用户能看到的公告。收件箱屏幕402的底部显示了不符合一项或多项规则的所有事件。如图4所示，一个事件记录可以包含以下字段：提供方；处理日期；文件名；事件标识名；费用；细节选项；接受和质询指示项；类型(OP、AE、FCE)。每行事件404左边的选择框允许用户选择要进一步处理的事件。该选择框可以使用颜色代码(如：绿色表示该事件已经分配给用户，现正在处理中；灰色/黑色表示该事件尚未分配；黄色表示另一主题专家正在处理该事件)。用户基于收件箱屏幕中现有的摘要数据，既能接受事件，又能对其提出质询，或者可以选择细节选项406查看更多内容。

[0034]图6所示为包含事件详细内容的屏幕。选择操作管理员屏幕上的细节选项，可以看到事件的详细内容。该事件细节屏幕包含所选事件的详细细节区500。这个区域内显示有事件502的识别信息，包括文件名、事件标识名和费用。屏幕上还有事件不符合所应用规则的详细原因。不合格类别504和不合格原因506在屏幕上列出。用户选择“更多内容”选项508，还能查看其他的详细内容。最后，屏幕上提供了接受或质询选项510。用户选择接受或质询复选框时，出现文本框，用户可以输入一些说明。质询管理员可以看到这些说明，它们可以辅助管理员进行事件分配。然后用户可以选择处理选择512来记录所做的接受或质询。如果选择接受选项，文件被清除，转入付款，同时从收件箱中删除。如果选择质询选项，文件会发送给质询管理员进一步审核，同时从收件箱中删除。如果事件被质询并返回提供方，则该事件作为待处理决定返回收件箱。主题专家可以审核与文件状态相关的细节，供做决定时参考。

[0035]图7所示为含有更多事件细节的屏幕。屏幕500的细节部分的上方，屏幕600的一部分中显示有其他细节。用户可以看到入院日期、出院日期、卫生健康保健资源分类描述和事件类型。用户还可以查阅事件的起始日期和终止日期、价格类型、住院时间(length of stay，LOS)、诊断和疗程。这些额外信息可以帮助用户决定是否接受该事件或提出质询。

[0036]用户还可以看到与数据库中记录的事件及其排布有关的各种不同报告。报告选项包括绩效/资源利用报告、质询报告、趋势报告和财务调节报告。

[0037]虽然上面详细描述了本发明的某些具体实施例，但本发明的范围并不受这些公开内容的限制，而且在不脱离其精神范围内是有可能改动权利要求所述发明的。

附录A

规则分类举例

规则分组	事件/活动/操作
		数据质量	国家必填字段完整，(执行最小数据集)地方必填字段完整(付款方特定)字段满足输入标准
病人和GP资格	病人和GP属于特定付款方将外地病人/不合格GP返回提供方Detect MOD活动外国来访者(无互惠协议)
		重复检查	按月去除活动双数查出先前提交或已付款的活动查出先前提交活动的变化
临床验证	付款方特定的通常不资助的干预项目(Interventions NotNormally Funded，INNF)/低优先疗程诊断/治疗前后不一致(正确编码)，代码与性别类型等不匹配非急需诊疗/急需诊疗主张(A&E允许满足4小时)查出与中央委托服务相关的活动显示活动级别相对合同级别的趋势(上/下)
		发票验证	检查Trim点检查HRG、Grouper或每个NHS的Spell数据审核住院时间/过长的住院天数(excess bed days)符合地方协议/合同条款检查是非违反PBC PbR付款协议(诊所等)审核是否不符合绩效奖金/折扣排除国家资助的项目必要时手动计算
定价调整	Flex位置识别事故主张/代位主张付款协议
		定价决定	Trim点HRG、Grouper或每个NHS的Spell数据住院时间符合地方协议/合同条款PBC PbR付款协议(诊所等)绩效奖金国家提供方付款计划
每月预付款结算/调整	冻结点向提供方付款
		财务收回或代位	国家项目付款主张(付款方主张)事故主张/代位主张外国来访者(检查是否有针对签署互惠协议国家的主张收回方法)

附录B

规则表举例

规则	规则分组	决定	质询	OP	FCE	AE	规则算法
								缺少提供方标识名	数据质量		Y	Y	Y	Y	输入的提供方标识名不存在
没有针对付款方/提供方的合同内容	数据质量		Y	Y	Y	Y
								没有针对付款方/提供方的地方价格	数据质量		Y	Y	Y	Y
缺少NHS号或唯一病人标识名	数据质量		Y	Y	Y	Y	输入的唯一病人标识名不存在
								缺少FCE诊断/疗程代码	数据质量		Y	Y	Y		输入的FCE事件诊断代码(ICD-10)和疗程代码(OPCS4代码)不存在
诊断代码来自合适的FCE ICD-10代码集	临床验证		Y		Y		输入的诊断代码不是有效的FCE事件的ICD-10代码
								疗程代码来自合适的FCE OPCS集(HRG v3.5使用OPCS-4)(HRG4使用OPCS-4.3或OPCS-4.4)	临床验证		Y		Y		输入的疗程代码不是有效的FCE事件的OPCS4代码
缺少FCE的入院/出院日期	数据质量		Y		Y		输入的FCE事件的出院日期不存在
								缺少FCE入院类型	数据质量		Y		Y		输入的FCE事件入院类型不存在
FCE的入院日期不能大于出院日期	数据质量		Y		Y		出院日期不能小于入院日期
								FCE整个事件费用核算没有HRG价格	数据质量		Y		Y		输入的HRG没有提供适用FCE事件的价格
缺少FCE/OP年龄	数据质量		Y	Y	Y	Y	输入的FCE事件的年龄不存在
								缺少FCE的法律状态	数据质量		Y		Y		输入的FCE事件的法律状态不存在

规则	规则分组	决定	质询	OP	FCE	AE	规则算法
								缺少AE的HRG3.2代码	数据质量		Y			Y	输入的AE事件的HRG 3.2代码不存在
缺少AE/OP的求诊类型	数据质量		Y	Y		Y	输入的AE或OP事件的求诊类型不存在
								缺少AE的求诊日期	数据质量		Y			Y	输入的AE型事件的求诊日期
缺少OP的到达日期	数据质量		Y	Y			输入的OP型事件的到达日期
								缺少OP的年龄段	数据质量		Y	Y			输入的OP事件的年龄
OP的未指明科目/治疗作用代码	数据质量		Y	Y			输入的OP型事件的科目代码
								与年龄敏感HRGs不匹配的年龄	临床验证	Y		Y	Y	Y	输入的年龄对HRG无效(有效HRG表)
与病例无关的流程代码/诊断代码	临床验证		Y	Y	Y	Y	输入的流程或诊断代码与本事件类型不相关
								付款方不负责的活动收费	临床验证	Y		Y	Y	Y
高费用病人(大于10K英镑)	财务验证	Y		Y	Y	Y	输入的事件费用大于10000英镑
								HRG代码N12——产前4小时内应作为OP而非FCE处理	临床验证	Y			Y		如果时段小于4小时，输入的HRG代码N12应作为OP处理
FCE整个事件期间的OP求诊	财务验证	Y			Y		在FCE事件中被处理事件类型是OP
								重复事件记录	数据质量		Y	Y	Y	Y	输入的事件是重复事件(显示事件ID)
AE/OP同一天初次和后续求诊	财务验证	Y		Y		Y	输入的OP/AE事件的初次和后续求诊日期相同
								N12整个事件超出同年/前年的国家平均HES数据	财务验证	Y		Y		Y	输入的事件费用大于10000英镑
对急需化学治疗的整个事件的收费	财务验证	Y		Y	Y	Y	被处理事件上有化学治疗HRG
								检查不用付费的疗	临床验证	Y		Y	Y		HRG排除表含有要

规则	规则分组	决定	质询	OP	FCE	AE	规则算法
								程							排除的疗程代码
检查与国家平均水平相比LoS过长的病人	临床验证	Y			Y		将LoS与特定HRG的平均住院时间比较
								如果LoS＝2天而不是实际天数(如10天)，则支付全额HRG而不是支付约20％。	财务验证	Y			Y	Y
输入的求诊类型是初次求诊时，输入的门诊病人费用适用后续求诊，	临床验证	Y		Y			门诊病人价格表含有详细的对应具体科目代码的初次和后续价格
								非急需诊疗的住院病人在出院后14天内再次住院	财务验证				Y		将非急需诊疗的住院病人的最后出院日期与再次住院的日期进行比较
病人出院后14天内因急需诊疗/急诊再次入院	财务验证					Y	比较非急需诊疗/紧急入院病人的最后入院日期与再次入院日期
								同一天两次或更多次入院的病人	临床验证		Y		Y		a)输入的事件已经存在，事件类型相同b)输入的事件病人已经有对应该输入入院日期的另一事件
OP同一天按非急需诊疗入院	临床验证		Y	Y	？		a)输入的OP事件已经存在，“非急需诊疗”入院类型相同，入院日期相同b)输入的OP事件病人已经有对应该输入的入院日期的另一OP事件c)输入的对应该输入的入院日期的非OP事件病人
								同一天有两次或两次以上求诊的后续OP	临床验证	Y		Y			a)输入的OP事件已经存在，“后续”入院类型相同，入院日

规则	规则分组	决定	质询	OP	FCE	AE	规则算法
															期相同b)输入的OP事件病人已经有对应该输入的入院日期的另一OP事件c)输入的对应该输入的入院日期的非OP事件病人
按非急需诊疗/非急诊实施的化学治疗	财务验证	Y		Y	Y		入院类型输入为急诊，验证所选诊断(化学治疗)的正确入院类型(急诊)
								同一天有两次或两次以上求诊的初次OP	数据质量		Y	Y
没有疗程的外科手术入院(入院类型)(急需诊疗)	数据质量		Y	Y	Y	Y	“急需诊疗”的外科手术入院必须含有强制性疗程代码
								没有疗程的外科手术入院(入院类型)(非急需诊疗)	数据质量		Y		Y	Y	“非急需诊疗”的外科手术入院必须含有强制性疗程代码
执业登记属于付款方范围内	临床验证	Y		Y	Y	Y	输入相同付款人的执业代码(Orgld)
								OP同一天为NEW	临床验证	Y		Y			a)输入的OP事件已经存在，求诊类型为“初次求诊”，入院日期相同b)输入的OP事件病人已经有对应该输入的求诊日期的另一OP事件c)输入的对应该输入的求诊日期的非OP事件病人
OP同一天为FU(只是科目相同)	临床验证	Y		Y			a)输入的OP事件已经存在，求诊类型为后续求诊”，入院日期相同b)输入的OP事件病人已经有对应该

规则	规则分组	决定	质询	OP	FCE	AE	规则算法
															输入的求诊日期的另一OP事件c)输入的对应该输入的求诊日期的非OP事件病人
OP FUs编码为初次OP(特别注意产科多次求诊)	数据验证	Y		Y			输入的OP事件已经存在，求诊类型为“初次&后续求诊”
								检查将非急需诊疗分到FU求诊的N12代码重新分类(HES数据V地方数据)	临床验证	Y		Y	Y	Y
检查同一天有不止一个事件(spell)的病人	数据验证	Y		Y	Y	Y	a)输入的FCE事件(episode)已经存在，入院日期相同b)输入的FCE事件病人，已经有对应输入的求诊日期的另一FCE事件
								确定合同中没有包括专家任命事宜(SpecialistCommissioning)	财务验证		Y	Y	Y	Y
检查日间病人(daycases)是否应该依照PbR指南按OPs收费	财务验证		Y	Y	Y	Y
								检查与合同不符的高价药品，确保没有重复	财务验证		Y	Y	Y	Y
不正确地将专家预付费(Top Up)用于对过长住院天数的收费	财务验证	Y		Y		Y	输入HRG并检查APC价格中专项价格(specialized tariff)预付费是否符合要求
								同一期间多次疗程	财务验证	Y		Y	Y	Y	输入事件具体时间段的疗程代码
关键的医护住院天数计算正确	财务验证	Y			Y	Y
								按日间病人收费的复合治疗	财务验证	Y		Y

规则	规则分组	决定	质询	OP	FCE	AE	规则算法
								Trim点和科目代码规则已被应用	财务验证	Y		Y		Y	确认APC价格&FCE中Trim点&科目代码
非急需诊疗的住院病人，Trim点是住院10天	财务验证	Y			Y	Y	输入HRG，比较APC价格中专项价格预付费对应的非急需诊疗的住院时间较长的Trim点天数
								住院病人住院大于10天，超过Trim点	财务验证	Y			Y	Y	输入HRG，比较APC价格中专项价格预付费对应的非急需诊疗的住院时间较长的Trim点天数
识别并检查Trim点低、HRG中住院时间短的非急需诊疗病人	财务验证	Y			Y	Y	输入HRG，比较APC价格中专项价格预付费对应的非急需诊疗的住院时间较长的Trim点天数
								住院病人的住院时间显著高于HRGTrim点	财务验证	Y			Y	Y	输入HRG，比较APC价格中专项价格预付费对应的非急需诊疗的住院时间较长的Trim点天数
识别并检查Trim点高、HRG中住院时间短的非急需诊疗病人	财务验证	Y			Y	Y	输入HRG，比较APC价格中专项价格预付费对应的非急需诊疗的住院时间较长的Trim点天数

Claims (10)

1.一种用于卫生保健服务的结算和验证发票系统，其包括：

数据库，其包括：

(a)数据质量规则，其用于识别与单个病人医护事件有关的事件的事件数据中的不完整或不精确数据；

(b)临床验证规则，其用于确定卫生保健服务提供方是否遵守付款方制定的国家和地方病人医护标准；

(c)财务验证规则，其用于确定卫生保健服务提供方的收费是否符合所述付款方制定的国家和地方财务要求；

服务器，其用于接收来自卫生保健服务提供方计算机的与单个病人医护事件有关的事件数据，所述事件数据包含与所述卫生保健服务提供方提供的病人医护服务有关的临床数据和与所述卫生保健服务提供方提供的病人医护服务收费有关的财务数据；

所述服务器的结算和发票验证应用程序，其用于：

(a)将所述数据质量规则中的至少一项规则应用于所述事件数据，以识别事件数据中不完整或不精确的数据；

(b)如果所述至少一项数据质量规则识别出所述事件数据中的不完整或不精确数据，则拒绝所述事件数据；

(c)应用所述临床验证规则中的至少一项规则，确定所述卫生保健服务提供方是否遵守付款方制定的国家和地方病人医护标准；

(d)如果应用所述临床验证规则中的至少一项规则，确定出所述卫生保健服务提供方没有遵守付款方制定的国家和地方病人医护标准，则拒绝所述事件数据；

(e)应用至少一项财务验证规则，确定所述卫生保健服务提供方的收费是否符合所述付款方制定的国家和地方财务要求；

(f)如果应用所述财务验证规则中的至少一项规则，确定出所述卫生保健服务提供方的收费没有符合所述付款方制定的国家和地方财务标准，则拒绝所述事件数据；

(g)如果根据所述数据质量规则、所述临床验证规则或所述财务验证规则，所述事件数据没有被拒绝，则接受所述事件数据，予以付款；

(h)如果根据所述数据质量规则、所述临床验证规则或所述财务验证规则，所述事件数据被拒绝，则付款方代表

(i)将所述事件数据标为质询；并

(ii)转发要采取行动的所述事件数据。

2.根据权利要求1所述的系统，其中，付款方代表转发要采取行动的所述事件数据的步骤包括将所述事件数据转发到电子收件箱中。

3.根据权利要求1所述的系统，其中，如果所述事件数据因不符合所述临床验证规则而被拒绝，则所述付款方代表是临床主题专家。

4.根据权利要求1所述的系统，其中，如果所述事件数据因不符合所述财务验证规则而被拒绝，则所述付款方代表是财务主题专家。

5.根据权利要求2所述的系统，其进一步包括将所述事件数据转发给质询管理员，其在所述付款方代表采取的所述行动后，决定是否接受所述事件或对其提出质询。

6.一种对卫生保健服务发票进行结算和验证的方法，其包括

(a)往数据库中输入：

(i)数据质量规则，其用于识别与单个病人医护事件有关的事件的事件数据中的不完整或不精确数据；

(ii)临床验证规则，其用于确定卫生保健服务提供方是否遵守付款方制定的国家和地方病人医护标准；

(iii)财务验证规则，其用于确定卫生保健服务提供方的收费是否符合所述付款方制定的国家和地方财务要求；

(b)服务器接收来自卫生保健服务提供方计算机的与单个病人医护事件有关的事件数据，所述事件数据包含与所述卫生保健服务提供方提供的病人医护服务有关的临床数据和与所述卫生保健服务提供方提供的病人医护服务收费有关的财务数据；

(c)将所述数据质量规则中的至少一项规则应用于所述事件数据，以识别事件数据中不完整或不精确的数据；

(d)如果所述至少一项数据质量规则识别出所述事件数据中的不完整或不精确数据，则拒绝所述事件数据；

(e)应用所述临床验证规则中的至少一项规则，确定所述卫生保健服务提供方是否遵守付款方制定的国家和地方病人医护标准；

(f)如果应用所述临床验证规则中的至少一项规则，确定出所述卫生保健服务提供方没有遵守付款方制定的国家和地方病人医护标准，则拒绝所述事件数据；

(g)应用至少一项财务验证规则，确定所述卫生保健服务提供方的收费是否符合所述付款方制定的国家和地方财务要求；

(h)如果应用所述财务验证规则中的至少一项规则，确定出所述卫生保健服务提供方的收费没有符合所述付款方制定的国家和地方财务标准，则拒绝所述事件数据；

(i)如果根据所述数据质量规则、所述临床验证规则或所述财务验证规则，所述事件数据没有被拒绝，则接受所述事件数据，予以付款；

(j)如果根据所述数据质量规则、所述临床验证规则或所述财务验证规则，所述事件数据被拒绝，则付款方代表

(i)将所述事件数据标为质询；并

(ii)转发要采取行动的所述事件数据。

7.根据权利要求6所述的方法，其中，付款方代表转发要采取行动的所述事件数据包括将所述事件数据转发到电子收件箱中。

8.根据权利要求6所述的方法，其中，如果所述事件数据因不符合所述临床验证规则而被拒绝，则所述付款方代表是临床主题专家。

9.根据权利要求6所述的方法，其中，如果所述事件数据因不符合所述财务验证规则而被拒绝，则所述付款方代表是财务主题专家。

10.根据权利要求6所述的方法，其进一步包括将所述事件数据转发给质询管理员，其在所述付款方代表采取的所述行动后，决定是否接受所述事件或对其提出质询。

Images