CN103136629A

CN103136629A - 基于实时关系kpi的自发报警工具

Info

Publication number: CN103136629A
Application number: CN2012104814137A
Authority: CN
Inventors: N.V.索利洛夫; P.赖扎达; 张剑勇; T.P.德里弗; V.Y.贝雷斯汉斯基; E.J.鲍林; B.巴罗; 史天珉
Original assignee: General Electric Co
Current assignee: General Electric Co
Priority date: 2011-11-23
Filing date: 2012-11-23
Publication date: 2013-06-05
Also published as: JP2013109762A; US20130132108A1

Abstract

本发明的名称是：“基于实时关系KPI的自发报警工具”。示例操作量度收集和处理系统根据感兴趣工作流的操作量度从信息源挖掘包含患者和检查工作流数据的数据集。示例健康护理工作流绩效监测系统包含关系分析引擎，以基于健康护理工作流的当前和历史健康护理数据而挖掘数据集来识别模式并且从所识别的模式和数据挖掘信息提取关系信息。示例系统包含统计建模引擎，以基于包含健康护理工作流中的事件的关系排序的关系和模式信息动态创建关系绩效指标。示例系统包含工作流决定引擎，以基于模型评价关系绩效指标并且监测与关系绩效指标关联的测量，工作流决定引擎处理反馈来更新关系绩效指标。

Description

基于实时关系 KPI 的自发报警工具

技术领域

当前所描述的技术通常涉及确定健康护理企业的工作流中的绩效指标的系统和方法。更特别地，当前所描述的技术涉及为健康护理工作流计算绩效量度并报警。

背景技术

大多数健康护理企业和机构手动执行数据搜集和报告。许多计算机化的系统容纳积累的数据和统计，但在事后必须手动提取并分析。这些方式遭受“后视镜综合征”：当收集、分析并准备评审数据时，在资源、患者分布以及资产方面的机构组成已经改变。关于健康护理的调节的压力持续增加。类似地，患者护理上的监督增加。

受改进的生产率和护理交付质量挑战的例如Kaiser Permanente等开创性健康护理组织已经开始定义关键绩效指标（Key Performance Indicator，KPI）或量度来量化、监测并基准化在组织寻求转型的区域中的操作绩效目标。通过将部门和设施KPI对准到整个健康系统KPI，组织中的每个人可以向着组织所建立的目标而工作。

发明内容

某些示例提供用于操作量度收集和处理的系统、器件和方法，其根据感兴趣的工作流的操作量度而从信息源挖掘包含患者和检查工作流数据的数据集。

某些示例提供一种计算机实现的方法，用于生成健康护理工作流的关系绩效（contextual performance）指标。该示例方法包含基于健康护理工作流的当前和历史健康护理数据而挖掘数据集来识别模式（pattern）。该示例方法包含从所识别的模式和数据挖掘信息中提取关系信息（context information）。该示例方法包含基于关系和模式信息动态创建关系绩效指标。该示例方法包含基于模型（model）评价关系绩效指标。该示例方法包含监测与关系绩效指标关联的测量（measurement）。该示例方法包含处理反馈来更新关系绩效指标。

某些示例提供一种具有存储于其上的指令集的有形计算机可读存储介质，当执行该指令集时，指示处理器来实现用于生成健康护理工作流的操作量度的方法。该示例方法包含基于健康护理工作流的当前和历史健康护理数据而挖掘数据集来识别模式。该示例方法包含从所识别的模式和数据挖掘信息（data mined information）提取关系信息。该示例方法包含基于关系和模式信息动态创建关系绩效指标。该示例方法包含基于模型评价关系绩效指标。该示例方法包含监测与关系绩效指标关联的测量。该示例方法包含处理反馈来更新关系绩效指标。

某些示例提供一种健康护理工作流绩效监测系统，包含关系分析引擎，以基于健康护理工作流的当前和历史健康护理数据而挖掘数据集来识别模式并且用于从所识别的模式和数据挖掘信息提取关系信息。该示例系统包含统计建模引擎，以基于包含健康护理工作流中的事件的关系排序的关系和模式信息而动态创建关系绩效指标。该示例系统包含工作流决定引擎，以基于模型评价关系绩效指标并且监测与关系绩效指标关联的测量，工作流决定引擎处理反馈来更新关系绩效指标。

附图说明

图1描绘示例健康护理信息企业系统来测量、输出并改进操作绩效量度。

图2图示示例实时分析仪表板（dashboard）系统。

图3描绘用于患者和检查工作流的操作量度的计算和输出的示例方法的流程图。

图4图示示例报警和决策系统。

图5图示到医院工作人员和/或系统的KPI、通知和反馈部署的示例系统。

图6图示用于关系KPI创建和监测的方法的示例流程图。

图7是可用于实现本文所描述的系统、器件和方法的示例处理器系统的框图。

当结合附图阅读时，将更好地理解上文的概要以及本发明的某些实施例的下文的详细描述。为了图示本发明，在图中示出某些实施例。然而，应理解本发明不限于附图中所示的布置和手段。

具体实施方式

尽管下文公开了示例方法、系统、制品以及器件，除其它部件之外其还包含在硬件上执行的软件，但应该注意到这样的方法和器件仅是说明性的并且不应认为限制。例如，要领会到这些硬件和软件部件中的任何或所有可只用硬件、只用软件、只用固件、或用硬件、软件和/或固件的任何组合来实施。因此，尽管下文描述了示例方法、系统、制品以及器件，但所提供的示例并不是实现这样的方法、系统、制品以及器件的唯一方式。

当阅读任何所附的权利要求来覆盖纯软件和/或固件实现时，至少一个示例中的至少一个元件以此清楚地定义为包含存储软件和/或固件的有形介质（例如存储器、DVD、CD、蓝光等）。

健康护理近来已经看到所部署的信息系统的数量的增加。由于部门差别，系统的采用和增长路径不总是对准。部门使用具体到其工作流的部门系统。越来越多地安装企业系统来解决一些跨部门的挑战。需要很昂贵的集成工作以将这些系统联系在一起，并且典型地，保持此集成最小来降低成本并且部门改为依靠人为干预来跨接任何隔阂。

例如，医院可具有企业调度系统来调度医院内的所有部门的检查。此有益于企业和患者。然而，由于各种原因，调度系统可能没有与每个部门系统集成。由于大多数部门使用其部门信息系统来管理预订和工作流，部门工作人员必须查看调度系统应用来知道将调度执行什么检查并且潜在在其部门系统中重新创建这些检查用于进一步处理。

某些示例通过提供对发生在不同系统中的工作流的透明度而帮助精简放射科中的患者扫描过程。使用从放射科信息系统（Radiology Information System，RIS）打印的纸质申请或在干擦白板上手动追踪而管理放射科中的当前患者扫描工作流。假设不同系统用来追踪患者准备、实验室结果、口服对比，由于技术人员需要轮询不同系统来检验患者的状态，所以对于他们而言很难有效率。另外，由于此信息是手动追踪的，所以不容易通信此信息。因此任何其它个人会需要再次查找此信息或经由电话呼叫检验信息。

系统提供电子接口来显示对应于患者扫描和图像解析工作流中的任何事件的信息。利用不同系统中的工作流步骤上的完成的可见度，手动追踪系统中的工作流的完成、视觉定时器以递减计数放射科中的活动或任务。

某些示例提供电子系统和方法来得到导致延迟的附加元件。某些示例系统和方法以电子方式得到信息，该信息包含：检查的一个或多个延迟原因和/或描述检查的附加属性（例如，检查优先级标记）。

各机构的工作流定义可以不同。一些机构追踪看护准备时间、室内放射专家时间等。可以基于消费者的需要、需求和/或偏好而将这些状态（事件）动态添加到决定支持系统来使能关键绩效指标（KPI）的测量以及与KPI关联的信息的显示。

某些示例提供多个工作流状态定义。某些示例提供能力来存储每个工作流状态的事件数量并且来追踪工作流步骤。某些示例提供能力来修改具体到特定站点工作流的一系列工作流。某些示例提供能力来对照患者访问事件与检查事件。

当前仪表板解决方法典型地基于RIS或图像归档和通信系统（Picture Archiving and Communication System，PACS）中的数据。某些示例提供能力来从包含RIS、PACS、医疗器械（modality）、虚拟射线照相术（Virtual Radiography，VR）、调度、实验室、药房系统等多个来源聚集数据。弹性工作流定义使示例系统和方法能相对轻松地定制消费者工作流配置。

此外，某些示例模拟工作人员所使用的基本原理（例如，由健康护理站点的工作流而可配置）来识别相同和/或以某种方式连接的两个或者更多分离系统中的检查，而不是尝试提供不同系统之间的集成。这允许站点继续保持系统分离但通过匹配并将这些检查呈现为单个/相同的检查而增加值，因此减小在任何系统中工作人员手动链接检查的需要。

某些示例提供基于引擎的规则，其可以配置为基于用户选择的准则匹配它从两个或者更多系统接收的检查来评价这些不同的检查实际上是否是将在设施上执行的相同的检查。可以配置的属性包含患者人口统计（例如，姓名、年龄、性别、其它标识符等）、访问属性（例如，账号等）、检查日期、将执行的过程等。

一旦从不同系统接收的两个或者更多检查被识别为相同的单个检查，则从链接的检查集解除一个或多个检查，以使仅呈现一个检查条目给终端用户。可以配置系统来显示从排序系统接收的检查并且解除从调度系统接收的检查，而不是合并这两个检查。

例如，当医院的调度系统不与预订条目/管理系统对接时。当患者呼叫来调度检查时，在调度系统中创建记录，然后将该记录转发给决定支持系统。当患者到达医院时，在预订条目系统（例如，RIS）中创建预订来管理与检查相关的部门工作流。决定支持系统也接收此信息作为单独的检查。

没有识别相关的检查并确定应呈现哪个相关的检查的能力的情况下，决定支持仪表板会对于实际上单个检查显示两个检查条目。利用此能力，决定支持系统停用接收到那个患者的预订时所排定的检查，防止两个检查出现在仪表板上作为未决的检查。仅保留所排序的检查。在接收所排序的检查信息之前，决定支持系统显示所排定的检查。

因此，工作人员用户无需手动干预来从调度和/或决定支持应用中移除检查条目。而是，在工作流中检查条目没有像它的所排序的对应物那样前进。例如，可基于医院的工作流定制链接的或有关的检查的行为而无需代码改变。

某些示例提供系统和方法来确定操作量度或关键绩效指标（KPI），例如患者等待时间。某些示例利用多个患者工作流事件来适应工作流的变化从而有助于患者等待时间和/或其它量度/指标的更准确的计算。

医院管理人员应能够量化在放射科工作流期间患者等待的时间量，例如，其中患者准备并转移来获取通过例如磁共振（MR）和/或计算机断层照相（CT）成像系统等扫描仪的放射科检查。患者等待时间的更准确的量化帮助改进患者护理并最优化或改进放射科和/或其它健康护理部门/企业操作。

某些示例帮助提供企业的实时操作有效性的理解并且帮助使操作员能处理不足。因此，某些示例提供能力来实时地或大体上实时地（给定的固有的处理、存储和/或传送延迟）从健康护理企业收集、分析并评审操作数据。以易懂的方式提供数据来调整可人工影响操作数据（例如，患者等待时间）的值的因素以使可采取适当的响应动作。

医院和其它健康护理企业使用KPI来测量操作绩效并评价患者体验。KPI可以帮助健康护理机构、临床医生以及工作人员提供更好的患者护理，改进部门和企业效率，并且减小交付的整个成本。将信息汇编进KPI可能是耗时的并且涉及管理人员和/或临床分析人员（对不同信息系统生成个体报告并且手动聚集此数据为有意义的信息）。

KPI表示绩效量度，其可以是工业或商业的标准，但也可以包含具体到机构或位置的量度。使用并呈现这些量度给用户来测量并演示部门、系统和/或个人的绩效。KPI包含但不限于患者等待时间（Patient Wait Time，PWT）、报告或命令的周转时间（Turn Around Time，TAT）、发作报告周转时间（Stroke Report Turn Around Time，S-RTAT）或放射科部门中的整个胶片使用。例如，对于命令，时间可以是从完成到命令的时间、从命令到抄写的时间和/或从抄写到签署的时间的测量。

在某些示例中，从医院或部门环境内的不同信息系统聚集数据。从所聚集的数据可以创建KPI并且将KPI呈现给启用网络的装置或其它信息门户/接口上的用户。此外，可基于数据提供警报和/或预警以使职员可以在患者体验更差的问题之前采取动作。

例如，可以加亮KPI并且将KPI与响应各种状况的动作关联，例如但不限于，长的患者等待时间、未充分使用的医疗器械、发作报告、不满足医院方针的绩效量度、或持续请求胶片的咨询医生（当检查通过医院门户而电子地可用的）。例如，处理绩效的具体区域的绩效指标可以实时（或考虑处理、存储/取回和/或传送延迟而大体上实时）动作。

在某些示例中，收集并分析将在图形仪表板中呈现的数据，包含表示KPI、作为基础的数据和/或用户的关联功能的视觉指标。可以提供信息来帮助使用户能变为积极主动而不是被动的。此外，可以处理信息来提供更准确的指标，其解释超出患者、临床医生和/或临床企业的控制的因素和延迟。在一些示例中，可以将“固有的”延迟作为除关联的操作量度（例如，患者等待时间）之外的单独的可操作项目加亮。

某些示例提供健康护理企业的工作流中的可配置的KPI（例如，操作量度）计算。该计算允许KPI消费者选择有关的限定词集来确定操作量度中可计算的数据的范围。算法支持包含处于升序或降序工作流状态改变顺序中的各种工作流排除和重复（例如，检查或患者访问取消、再调度等）的复杂工作流场景，以及例如在多日和多预订患者访问的场景中的KPI计算。

例如，可以基于访问标识符、日期和/或医疗器械而链接单个患者访问期间的多个检查。出于等待时间计算的目的，不多次计数患者。此外，当接收到与一个检查的命令关联的事件时，所有关联的检查不标记为命令。

一旦完成以上计算，则根据由医院或其它监测的健康护理企业中的一个或多个用户规定的一个或多个时间阈值分组访问和检查。例如，医院中的急诊部门想要将访问期间的患者等待时间分为0-15分钟、15-30分钟以及超过30分钟的等待时间组。

一旦依据绝对数或百分数分组数据，它可以呈现给用户。可以以各种图表（例如，交通灯、条形图、和/或其它图形、和/或基于阈值的字母数字指标等）的形式呈现数据。

因此，某些示例帮助促进操作数据驱动的决策以及过程改进。为帮助改进操作生产率，提供工具来测量并显示日常操作的实时（或大体上实时）视图。为了更好地管理组织的长期策略，管理人员配备有更易使用的数据分析工具来识别改进的区域并监测改变的影响。

图1描绘测量、输出并改进操作绩效量度的示例健康护理信息企业系统100。系统100包含多个信息源、仪表板以及操作功能应用。更具体地，图1中所示的示例系统100包含多个信息源110，例如信息源110包含图像归档和通信系统（PACS）111、精度报告子系统112、放射科信息系统（RIS）113（包含数据管理、调度等）、医疗器械114、以及归档115、医疗器械116以及质量评审子系统116（例如，PeerVue™）。

多个信息源110提供数据到数据接口120。数据接口120可以包含多个数据接口用于通信、格式化和/或以其它方式将来自信息源110的数据提供到数据集市130。例如，数据接口120可以包含SQL数据接口121、基于事件的数据接口122、医学数字成像与通信（DICOM）数据接口123、健康水平7（HL7）数据接口124以及网络服务数据接口125中的一个或多个。

数据集市130经由接口120接收并存储来自信息源110的数据。例如，可以在相关数据库中和/或根据另一组织来存储数据。数据集市130提供数据到包含仪表板145的技术基础140。例如，技术基础140可以基于来自数据集市130的数据以及来自仪表板145的分析而与一个或多个功能应用150交互。例如，功能应用可以包含操作应用155。

如以下将进一步讨论的，例如，仪表板（dashboard）145包含中央工作流视图和关于KPI与关联的测量和警报的信息。操作应用155包含与设备利用、等待时间、报告阅读时间、阅读案件数量等相关的信息和动作。

KPI反映组织的战略目标。放射科中的示例包含但不限于患者等待时间的减小、改进的检查生产量、减少的命令和报告周转时间以及增加的设备利用率。KPI用来评估组织、部门或个人的目前状态并且用清晰的动作过程提供可动作信息。它们辅助健康护理组织测量朝着为成功建立的目的和目标的进步。然而，部门经理和其它前线工作人员发现很难实时地积极主动地管理这些KPI。这至少部分由于将构建KPI的数据驻留于不同的信息源并且应该关联以计算KPI绩效。

KPI可以适应但不限于以下工作流场景：

1. 检查开始之前的患者等待时间

2. 任何医院工作流状态之间的周转时间

3. 从KPI计算添加或移除多个检查/患者状态。例如，一些医院希望在患者工作流中添加多个实验室状态，并且KPI计算可以解释计算中的这些状态

4. 取消的访问和检查应自动排除于计算之外

5. 在单日内的单个患者访问中的多个检查应区别于单个患者等待时间对多日内的单个患者的相同检查

6. 应该应用等待时间扣除，其中管理药物并且药物需要时间来生效

7. 应从不同事件的周转和/或等待时间排除下班小时

8. 应允许检查倒转到任何以前的状态并且因此检查应排除或包含在KPI计算中

9. 用户应具有选项来根据医院需要/需求/偏好配置KPI，并且KPI应根据用户配置而执行计算

10. 例如，若检查来自于单个访问、相同医疗器械、相同患者以及同日，则多个检查应链接到单个检查。

使用KPI计算和关联的支持，医院和/或其它健康护理管理人员可以获取患者等待时间和/或不同工作流状态之间的周转时间的更准确的信息，以便最优化或改进操作以提供更好的患者护理。

即使患者工作流包含备选工作流，但应用可以获取多个工作流事件来处理更准确的患者等待时间。对于不同的工作流和过程，可以配置并调整患者等待时间和/或不同工作流状态之间的周转时间的计算。

图2图示示例实时分析仪表板系统200。实时分析仪表板系统200设计为向放射科和/或其它健康护理部门提供围绕对从调度（顺序）跨越到报告分布的工作流的操作绩效的透明度。

仪表板系统200包含数据聚集引擎210，其经由接口引擎250关联事件与不同来源260。系统200也包含实时仪表板220，例如可经由浏览器跨健康护理企业访问的实时仪表板网络应用。系统200包含操作KPI引擎230来积极主动地管理成像和/或其它健康护理操作。例如，聚集的数据可以存储在数据库240中用于由实时仪表板220使用。

实时仪表板系统200由数据聚集引擎210供电，数据聚集引擎210实时地（或考虑系统延迟大体上实时地）关联来自PACS、RIS和其它信息源的工作流事件，从而用户可以观察放射科和/或其它健康护理部门内部和外部的患者状态。

数据聚集引擎210已经预先建立检查和患者事件，并且支持添加自定义事件以映射到站点工作流的能力。引擎210以查询视图的形式提供用户接口，例如，查询审计事件。查询视图支持在特定时间范围内使用以下准则的查询：患者、检查、工作人员、事件类型等。查询视图可用于查找关于某个时间范围（例如，六周）内的检查和访问事件的审计信息。查询视图可用于检验检查的当前工作流状态。查询视图可用于通过对照患者和工作人员信息而验证工作人员患者交互审计一致性信息。

接口引擎250（例如，临床内容网关（CCG）接口引擎）用来与各种信息源260（例如，RIS、PACS、VR、医疗器械、电子医学记录（EMR）、实验室、药房等）以及数据聚集引擎210对接。例如，接口引擎250可以基于HL7、DICOM、可扩展标记语言（XML）、医疗器械执行的过程步骤（MPPS）和/或其它消息/数据格式进行对接。

实时仪表板220支持各种能力（例如，以基于网络格式的形式）。仪表板220可以通过设施组织KPI并且允许用户从企业挖掘到个体设施（例如，医院）。例如，仪表板220可以同时地（或大体上同时地）显示多个KPI。仪表板220提供自动的“放映幻灯片”来显示一系列公开KPI。仪表板220可用于保存公开KPI、生成报告、将数据输出到电子表格等。

操作KPI引擎230提供显示指示瓶颈和未决任务的视觉警报的能力。KPI引擎230使用来自不同来源（例如，RIS、医疗器械、PACS、VR等）的数据而计算过程量度。例如，KPI引擎230可以适应并处理多个事件的发生并且存取在聚集KPI量度之下的详细数据。引擎230可以规定用户定义的过滤器并且由选项分组。例如，引擎230可以接受定制的KPI阈值、时间深度等，并且可用于建立自定义KPI来反映站点工作流。

例如，所生成的KPI可以包含周转时间KPI，其计算从一个或多个初始工作流状态到完成一个或多个最终状态所耗的时间。例如，KPI可以呈现为量规上的平均值或在层叠条形图上显示分组成周转时间类别的计数。

例如，等待时间KPI计算从一个或多个初始工作流状态到最终工作流状态集还没完成之前的当前时间的经过的时间。例如，此KPI是用显示由时间阈值分组的检查的计数的交通灯而视觉化。

比较或计数KPI计算对于给定时间段的一个状态对另一状态中的检查的计数。备选地，可以计算单个状态中的检查的计数（例如，取消的检查的数量）。例如，此KPI以条形图的形式而视觉化。

例如，仪表板系统200可以提供图形报告来视觉化模式并且快速识别短期趋势。例如，由过程周转时间、资产利用率、生产量、体积/混合和/或延迟原因等来定义报告。

仪表板系统200还可提供例外异常值记分卡，例如由设施分组的表格列表用于超过周转时间阈值的多个检查。

例如，仪表板系统200可以提供在特定医疗器械（例如，部门）中的未决的急诊部门（ED）、门诊部和/或住院部检查的统一列表，其具有能力来：1）显示来自不同系统的工作流事件的状态，2）指示患者的未决的多医疗器械检查，3）经由倒计时定时器追踪与检查有关的某个活动的时间，和/或4）电子地记录工作流事件的发生的延迟原因、时间戳。

图3描绘表示使用例如计算机可读指令实现的过程的示例流程图，该指令可用于促进数据的收集、KPI的计算以及KPI的评审的呈现。可以使用处理器、控制器和/或任何其它合适的处理装置来执行图3的示例过程。例如，可以使用在有形计算机可读介质（例如，闪速存储器、只读存储器（ROM）和/或随机存取存储器（RAM））上存储的编码的指令（例如，计算机可读指令）来实现图3的示例过程。如本文所使用的，清楚地定义术语“有形计算机可读介质”来包含任何类型的计算机可读存储并且排除传播信号。此外或备选地，可以使用在非暂时性计算机可读介质（例如，闪速存储器、只读存储器（ROM）、随机存取存储器（RAM）、CD、DVD、蓝光、缓存或任何其它存储介质）上存储的编码指令（例如，计算机可读指令）来实现图3的示例过程，在该介质中，将信息存储任何持续时间（例如，延长时间段、持久、简短瞬间、临时缓冲和/或缓存信息）。如本文所使用的，清楚地定义术语“非暂时性计算机可读介质”来包含任何类型的计算机可读介质并且排除传播信号。

备选地，可以使用专用集成电路（ASIC）、可编程逻辑装置（PLD）、现场可编程逻辑装置（FPLD）、离散逻辑、硬件、固件等的任何组合来实现图3的示例过程中的一些或全部。而且，可以手动地或作为任何上文技术的任何组合（例如，固件、软件、离散逻辑和/或硬件的任何组合）来实现图3的示例过程中的一些或全部。另外，尽管参考图3的流程图来描述图3的示例过程，但可以采用实现图3的过程的其它方法。例如，可以改变框的执行顺序，和/或可以改变、去除、分割或组合所描述的框中的一些。此外，可以通过例如单独的处理线程、处理器、装置、离散逻辑、电路等来相继地和/或并行地执行图3的示例过程中的任何或全部。

图3描绘用于患者和检查工作流的操作量度的计算和输出的示例方法300的流程图。在框310中，挖掘可用的数据集用于与一个或多个操作量度有关的信息。例如，基于患者访问和检查工作流的初始和最终状态在特定时间范围内在检查和患者访问水平上来挖掘从多个信息源（例如，图像医疗器械以及医学记录归档数据源）获取的操作数据集。此数据集包含医院工作流连同由标准/协议（例如，HL7和/或DICOM标准）规定的检查和患者属性中的感兴趣的事件的日期和时间戳。

在框320中，选择一个或多个感兴趣的患者和/或设备用于评价和评审。例如，选择一个或多个医院部门中的一个或多个患者以及一件或多件成像设备（例如，CT扫描仪）用于评审和KPI生成。在框330中，显示排定的过程用于评审。

在框340中，用户可以规定一个或多个条件来影响数据集中的数据的解析。例如，用户可以规定是否已经到达与感兴趣的工作流有关的任何或所有状态。例如，用户也具有能力来通过具体到医院工作流的有关的过滤器。基于用户条件来动态建立结果数据集。

在框350中，确定感兴趣的事件的完成时间。在框360中，评价与感兴趣的事件关联的延迟。在框370中，提供一个或多个延迟原因。例如，可以提供设备设置时间、患者准备时间、冲突的使用时间等作为一个或多个延迟原因。

在框380中，基于可用的信息计算一个或多个KPI。在框390中，提供（例如，显示、存储、传递到另一系统/应用等）结果给用户。

因此，某些示例提供系统和方法来辅助提供形势的认识到与患者扫描工作流的完成有关的步骤和延迟。某些示例提供扫描过程中的患者的当前状态、电子地记录的延迟原因、以及聚集并提供数据的KPI计算引擎用于经由用户接口显示。例如，信息可以呈现在表格列表和/或日历视图中。形势的认识可以包含患者准备（例如，口服对比管理/分配时间）、实验室结果和/或预订结果时间、看护准备开始/完成时间、检查预订时间、检查规定时间、患者到达时间等。

给定健康护理机构中的工作流的动态性质，可以追踪自定义状态的时间戳。某些示例用极少努力而提供可扩展的方式来追踪工作流事件。例如，示例操作量度引擎也追踪检查的当前状态。例如，在仪表板（白板）上示出的活动引起基于一个或多个规则追踪时间戳、通信信息和/或自动充电状态。例如，某些示例允许状态和关联颜色和/或图标呈现的自定义添加来匹配消费者工作流。

大多组织缺少用于工作流中的延迟的电子数据。在某些示例中，实时仪表板允许经由原因代码而追踪给定检查的多个延迟原因。例如，在具有生成集（其跨由医疗器械具体原因代码延伸的所有医疗器械应用）的分层结构中定义原因代码。这允许呈现用于给定医疗器械的有关的延迟代码。

某些示例提供能力来支持单个工作流步骤（例如，用户多少次进入应用/工作流并且做某事、不做事等）的多个发生。某些示例提供能力来选择已经发生的单个工作流步骤的最小值、最大值和/或多次的计数。某些示例提供自定义的工作流定义和/或能力来关联多个医疗器械检查。某些示例提供能力来追踪跨多个系统的检查的当前状态。

某些示例提供可扩展的工作流定义，其中可以定义表示任何状态的一般事件。示例引擎动态地适应于消费者的需要而无需提前于用户的每个可能工作流的计划。例如，如果今天定义用户的工作流来包含A、B、C和D，则定义可以动态扩展来包含E、F和G并且追踪、测量、并适应绩效而无需提前创建每个工作流偶然性的工作流状态数据库中的行和列。

例如，此信息可以存储在工作流状态表的行中。例如，可以基于一个或多个规则而从仪表板动态调换数据。例如，KPI规则引擎可以获得时间戳（例如，预订的时间戳、排定的时间戳、到达的时间戳、完成的时间戳、验证的时间戳等）以及作为与多个发生关联的事件类型的每个类别的时间戳。用户可以选择事件的最小值或最大值、追踪事件的多个发生、计数患者和/或检查的事件的数量、追踪患者访问水平事件等。

经常，为单个患者预订多个测试，并且在检查列表上观察这些测试，该列表对于给定医疗器械过滤而没有其它医疗器械检查的任何指标。由于患者很经常返回到原始位置而不是从一个医疗器械切换到另一医疗器械，这带来患者运输中的“浪费”。例如，实时仪表板提供方式来关联在患者水平上的多个医疗器械检查并且显示一个或多个对应指标。例如，可以对照多个医疗器械来示出患者具有在一天内所有调度发生的X射线、CT和超声。

在某个示例中，不仅是捕获的时间戳和呈现的量度，也捕获并考虑附随的延迟原因等。例如，除系统生成的时间戳以外，用户可以结合时间戳而交互并添加延迟原因。

在某些示例中，当计算KPI时，在数据选择上排除医疗器械过滤器。例如，由访问和/或由患者标识符、选择聚集准则而分组数据以关联多医疗器械检查。例如，可以动态地调换数据。示例分析仅返回到具有多医疗器械指标的已过滤医疗器械的检查。

某些示例提供系统和方法来识别、优先化和/或同步相关检查和/或其它记录。在某些示例中，可以从不同来源接收用于相同域对象（例如，检查）的消息。例如，基于消费者所创建的规则，匹配对象（例如，检查）以使确信地确定属于实际上表示相同的检查的不同系统的两个或者更多检查记录。

例如，基于包含在检查记录中的信息，选择一个检查记录作为最合格/适用记录。例如，通过选择记录，选择将使用其记录的对应的来源系统。在一些示例中，可以选择并使用多个记录。隐藏其它的未选择的匹配记录不显示。基于规则，这些隐藏的检查隐式链接到所显示的检查。在某些示例中，没有经由引用等的显式链接。

例如，通过工作流匹配锁定步骤中的集前进中的检查。当接收到集内的一个检查的状态更新时，所有检查一起更新到相同的状态。在某些示例中，此行为仅应用于状态更新。在某些示例中，由于对来自其来源系统的个体检查记录的更新（而不是状态更新），所以如果更新后的检查不再与所链接的检查集匹配，则它自动解开与其它检查的链接并且独立地在工作流中移动（前进/退回）。在某些示例中，由于对来自其来源系统的个体检查记录的更新，所以基于工作流中的事件和/或规则，隐藏的检查可以变为显示的和/或显示的检查可以变为隐藏的。

例如，基于设置准则而自动地链接从相同系统接收的检查。因此，当排序系统在排序期间无法链路检查时，可以创建检查的自动行为。

在某些示例中，当执行检查时，由技术人员在医疗器械上链接相同研究的两个或者更多检查。从那时起，检查通过成像工作流（而不是报告工作流）进入锁定步骤。这通过在单个研究的DICOM标题中添加所链接的检查的登记号（例如，唯一的标识符）来完成。例如，能够阅读DICOM图像的系统可以推断从此标题信息链接检查。然而，这些检查看起来像预成像工作流（例如，患者等待和准备检查）以及后成像工作流，例如报告（例如，其中系统是非DICOM兼容的）中的单独的检查。

例如，使用仪表板、CT胸部、腹部和骨盆显示作为三个不同检查。在单个扫描中一起执行三个检查。因为独立地显示每个检查，所以可能有双重工作（例如，如果实验室关联到检查，则排序附加实验室）。某些示例从相同排序系统链接两个或者更多检查，其通常是链接的并且用于使用由消费者创建的规则集的不同过程，以使这些检查出现并且通过预成像和后成像工作流而作为链接的检查执行。例如，由链接的检查，两个或者更多检查记录被认为是一个检查，这是由于它们将在相同扫描时间段中获得/执行。

当单个扫描会是足够的时（例如，在单个扫描中能已经捕获所有链接的检查的图像），检查相关或“链接”帮助减少多个扫描的可能。检查相关/互相关系（relationship）帮助减少工作人员工作量和调度中的错误（例如，由于多于一个预订的单个扫描跨多天的调度）。检查相关帮助减少附加辐射、附加的实验室工作等的可能。例如，医生逐渐预订检查，其在单个扫描（尤其是外伤情况）中覆盖更多部分的身体的检查。通过区分扫描与检查，这样的相关或有关链接提供部门工作量的确实的图片。例如，扫描是工作流项目（不是检查）。

因此，某些示例使用两个或者更多检查（例如，来自相同或不同排序系统，其可以是规则自身的一部分）的基于规则的匹配来确定检查是否应该链接在一起来显示为绩效仪表板上的单个检查。例如，没有这样的基于规则的匹配，用户会看到等待完成的两个或三个不同检查（其实际上只是单个扫描）。

某些示例促进医院网络的有效管理。某些示例提供日常操作和动作影响附带结果的改进认识。某些示例辅助医院企业/工作流中的大规模异常（例如，失效）的早期检测。

某些示例促进以较低成本的改进医院管理。某些示例提供实时和未来计划中的报警。某些示例帮助用户避免复杂配置/安置时间。某些示例提供自动演进的KPI定义而没有手动干涉。

图4图示了示例报警和决策系统400。示例系统400提供基于连续的（或大体上连续的）未来发展数据分布统计模式匹配的动态关系KPI的“智能”报警和决策人工智能引擎。该引擎包含：1）现存的健康护理部门工作流的即插即用收集；2）基于历史和当前数据的健康护理部门工作流的模式识别；3）来自形成关系KPI以及适用于提供智能量度的健康护理具体部门过滤的基础的数据挖掘信息的关系提取；4）通过加入一个或多个健康护理具体部门工作流关系动态创建关系KPI；5）关系KPI与智能模型选择的自发的和连续的（或大体上连续的）评价来使用成功导向统计算法而隔离感兴趣的事件；6）如果系统运行于带附加项目（例如，扩展或添加）的自发模式中，则基于识别事件报警或自评价算法的用户评价的成功率而持续地（或大体上持续地）演进监测；7）跨冗余连网的信息源的信息的交叉检验或验证来实现统计上的重要事件识别；8）医院企业网络认识反馈合并和前后交叉合作的操作等。例如，引擎可全自发地或半自发地操作。例如，尽管用于功能的操作不需要用户输入，但用户输入产生到改进的或最佳的操作点的更快速转换。

某些示例提供健康护理具体部门工作流信息（包含历史、当前、和/或计划中的未来信息）的即插即用收集和模式识别。在安置期间，例示多个触发器来收集进来的健康护理具体（例如，HL7）消息。

某些示例提供统计分析和估计引擎处理样本。基于数据分布模式而计算统计量度，然后通过挖掘统计量度而预测趋势（例如，使用近似算法的平均值、中值、标准差等）。如果所预测的量度落在规格下限（LSL）和/或规格上限（USL）（例如，方差）之外，则引擎生成决定矩阵并且发送矩阵到用户反馈引擎。

如在图4的示例中所描绘的，分析引擎400从一个或多个健康护理系统401（例如，RIS、PACS、成像医疗器械和/或其它系统）接收一系列事件。如在图4的示例中在1示出的，将事件G添加到包含事件A-F的仓库402。事件包含从一个或多个生成实体（例如，RIS、PACS、扫描仪等）进入仓库的确实的数据。

在2中，将一个或多个事件提供到关系分析引擎403。关系分析引擎403处理事件来提供事件405的关系排序。例如，基于一个或多个预测的感兴趣的事件（或事件组）而优先化、组织、移位、分类事件“池”（注意不一定按时间顺序排列）来创建关系排序。事件405的顺序表示将执行的事件的工作流。在排序期间，例如，一些事件将在其它事件之前到来。例如，预订在完成之前到来，完成在签署事件之前到来。

关系分析引擎403经历正在执行的或持续的最佳化或改进404来基于所接收的需要事件和新的反馈而改进事件的关系排序。例如，引擎403可以基于历史和/或当前数据而提供模式识别来形成关系顺序405。

例如，关系分析引擎403接收来自在健康护理设施（例如，医院或其它健康护理企业）可用的不同数据源的输入并且基于关系信息而生成一个或多个KPI。关系引擎403帮助从数据挖掘信息提取关系。例如，如果对于医院的放射科部门生成关系KPI，则引擎403生成周转时间（TAT）KPI、计数KPI、未决检查/等待患者KPI等。基于反馈，引擎403也具有持续的最佳化能力404。患者等待时间的关系中的事件不同于所扫描的TAT中的事件。例如，TAT是分成基于周转时间的基于时间类别的检查的计数。引擎403区分此信息来生成关系KPI。

将事件405的关系排序提供给历史关系仓库406。在图4的示例中的3中，历史关系仓库406提供数据挖掘信息用于由预测建模器407的关系提取以提供一个或多个关系KPI的基础。在某些示例中，应用健康护理具体部门过滤以仅提供适用于特定工作流、状况、约束和/或手边环境的“智能”量度。预测建模器407处理历史关系信息来提供输入给一个或多个最佳化和增强引擎408。在图4的示例中示出的最佳化和增强引擎408包含工作流决定引擎409以及结果有效性分析引擎410。预测模型407还可提供反馈411到关系分析引擎403。

例如，工作流决定引擎409使用人工神经网络来分析来自例如数据关系引擎403、历史关系仓库406、预测建模器407、统计建模引擎412、KPI使用模式引擎417等的来源的多个数据输入。例如，工作流决定引擎409识别可能的作为基础的工作流并且使用该工作流来改进/最优化并增强系统能力。例如，工作流决定引擎409可以将反馈提供回预测建模器407，例如，预测建模器407又可以提供反馈411到关系分析引擎403。

例如，结果有效性分析引擎410使用人工神经网络来分析来自例如数据关系引擎403、历史关系仓库406、预测建模器407、统计建模引擎412、KPI使用模式引擎417等来源的多个数据输入，以基于结果的有效性而对系统能力提供回归的最优化和增强调整。例如，可以提供用户提供的每个关系KPI的有效性等级以及智能警报来调整系统能力/配置。例如，结果有效性分析引擎410可以将反馈提供回预测建模器407，例如，预测建模器407又可以提供反馈411到关系分析引擎403。

在图4的示例中的4中，工作流决定引擎409使用人工智能神经网络来发现接收到主系统400的事件数据的历史和预测模型之间的模式。例如，这些模式也基于来自统计建模引擎412和当前KPI 413（包含它们的配置阈值数据）的输出。工作流决定引擎409通过使用历史事件数据和当前事件数据作为工作流决定引擎409内的神经网络的训练集而工作来验证所预测的事件数据模型。然后，这些结果会馈送入统计建模引擎412以改进新的KPI 413的生成以及KPI参数的配置。在某些示例中，在系统已经运行并监测一段时间之后，可不需要生成新的KPI，但可修改或更新KPI参数的配置以反映医院的需求、生产量等的改变。通过更新/修改，KPI可以保持与系统有关。

由于工作流决定引擎409和/或结果有效性分析引擎410变得更受训练，引擎409/410更大程度地影响统计建模引擎412。引擎409/410也将数据（关于预测事件数据模型中的失败）发送到统计建模引擎412并且帮助建模引擎412移除或停用不认为有关的KPI。

统计建模引擎412提供所接收的数据的统计建模并且如在图4的示例中的5中所示，基于工作流参数（例如，四分位范围、收紧或放松阈值）（基于飞行数据）中的变化而自动调整KPI参数值或其它定义414。例如，统计建模引擎412可以基于数据分布模式计算一个或多个统计量度并且可以通过使用近似算法而挖掘统计量度（例如，平均值、中值、标准差等）来预测趋势。一个或多个统计量度可用于基于KPI定义信息414而生成系统的一个或多个KPI 413。例如，可以提供KPI 413到最佳化和增强引擎408。例如，KPI 413可以基于已搜集的统计数据而显示LSL和USL（例如，方差）。KPI 413和统计建模引擎412可以提供数据分布模式，例如其包含感兴趣的提取（例如，非平凡、固有、以前未知并潜在有用等）模式和/或来自大量可用的数据（例如，来自历史关系仓库406、预测建模407等的输入）的知识。

因此，某些示例提供至少部分基于挖掘可用数据的KPI的自动生成来从数据确定有意义的量度。例如，可以生成KPI用于放射科检查，并且算法挖掘来自检查的信息，并且可以生成新的/更新的KPI，其组合参数。在某些示例中，人工智能技术与数据挖掘的组合生成具体工作流、关系KPI。这样的KPI可用于分析系统来识别瓶颈、低效率等。在某些示例中，由于使用系统和KPI，基于实时（或考虑到系统处理、访问等延迟的大体上实时）收集的数据而收紧控制限制和/或其它约束。

在某些示例中，在系统的操作期间可以基准花特定站点/环境。历史和当前数据的数据挖掘可用于自动创建与特定站点、状况等最有关的KPI。此外，KPI分析阈值可以随着站点从KPI和关联分析的监测和反馈改进而动态改变。某些示例帮助促进量度驱动的工作流，该工作流包含基于KPI测量和监测的任务和/或数据的自动重新路由。某些示例不仅显示结果量度，也改进系统工作流。

如在图4的示例中所示，在6中，也提供一个或多个KPI 413以及KPI定义414到智能报警引擎415来在7中生成一个或多个警报416。在8中，这些警报416可以反馈到结果有效性引擎410用于处理和调整。例如，可以提供警报416到其它系统部件、用户显示、用户消息等来吸引用户和/或自动系统对不符合规定和/或预测的限度的绩效量度测量的注意。

例如，智能警报416可以包含当解决和/或未解决患者问题时生成的通知。因此，例如，当患者正经历工作流来解决和/或以其它方式对待问题时，可以监测并追踪关于有过问题和/或持续有问题的患者的通知的存在和/或缺乏。

在某些示例中，可以提供警报作为基于订阅的、定期的、基于工作流的患者更新。在某些示例中，家庭可以订阅和/或订阅和/或通知可以以其它方式基于角色和/或基于互相关系。在某些示例中，通知可以基于机密患者标记和/或受机密患者标记影响。在某些示例中，可以提供动态警报，并且可以由系统推断和/或由用户设置那些警报的接收方。

在某些示例中，当系统操作时，持续监测和评价。如在图4的示例中所示出的，KPI使用聚集引擎417接收使用信息输入418（例如KPI的用户、使用位置、使用时间等）。例如，KPI使用引擎417聚集使用信息并且在9中将使用信息反馈到结果有效性分析引擎410和/或工作流决定引擎409来改进工作流决定、KPI定义等。

例如，医师可使用不同于护士的KPI，或医师可定制使用不同于护士会定制的参数的相同KPI。取决于用户当时所处的位置，相同用户可使用不同KPI。取决于它是处于白天或夜里，相同用户还可使用不同KPI。例如，KPI使用引擎417将此外部信息418馈送到决定和建模引擎409。

图5图示到医院工作人员和/或系统的KPI 505、通知503和反馈504的部署的示例系统500。在图5的示例中，基于时间的调度501（例如计划任务）提供工作流（例如，医院工作流）的排定的任务到一个或多个机器学习算法和/或其它人工智能系统503。机器学习算法使用一个或多个KPI 505、工作流信息506、二次信息507等来处理一系列任务、作业或事件。例如，二次信息可以包含来自一个或多个医院信息系统（例如，RIS、PACS、HIS、LIS、CVIS、EMR等）的信息，其存储在数据库或其它数据存储507中。基于处理和分析，算法502生成用于通知系统503的输出。例如，通知系统503提供警报和/或其它输出到医院工作人员509和/或其它自动系统。医院工作人员509和/或其它外部系统可以提供反馈到反馈处理器504，反馈处理器504又可以提供反馈到通知系统503、机器学习算法502、KPI 505、工作流信息506等。

某些示例动态变更警报通知的参数以响应于进入系统的数据。某些示例将通知（是否相对于客户端提供元数据）通信到一个或多个客户终端。某些示例基于数据库的状态而动态变更通知参数。某些示例响应于流进系统的数据的特性而动态生成警报。

图6图示用于关系KPI创建和监测的方法600的示例流程图。在框610中，基于历史和当前数据而从健康护理部门工作流中识别一个或多个模式。在框620中，从数据挖掘信息（其形成用于应用以提供智能量度的具有健康护理具体部门过滤的关系KPI的基础）提取关系信息。在框630中，通过加入一个或多个健康护理具体部门工作流关系而动态创建关系KPI。在框640中，基于一个或多个选择的模型来评价关系KPI以隔离感兴趣的事件。在框650中，监测事件和警报。在框660中，分析反馈（例如，医院企业网络认识反馈合并和前后交叉合作操作等）。在框670中，验证结果（例如，由跨冗余连网信息源的信息的交叉检验或验证来实现统计的重要事件识别）。

因此，某些示例提供自适应算法来帮助提供不同健康护理具体工作流中的安置的容易度。某些示例帮助减少或避免由于不适当的用户调整的阈值导致的警报的过饱和。某些示例平衡数据收集、KPI和动态信息搜集与修改来提供关于健康护理设施的系统、工作流、人员等的自适应性、反应性和实时信息与反馈。

图7是可用于实现本文所所述的系统、器件和方法的示例处理器系统710的框图。如图7中所示，处理器系统710包含耦合到互连总线714的处理器712。处理器712可以是任何合适的处理器、处理单元或微处理器。尽管图7中未示出，但系统710可以是多处理器系统并且因此可包含相同或类似于处理器712并在通信上耦合到互连总线714的一个或多个附加处理器。

图7的处理器712耦合到芯片组718，其包含存储器控制器720和输入/输出（I/O）控制器722。如公知的，芯片组典型地提供I/O和存储器管理功能以及多个通用和/或专用寄存器、定时器等，其可由耦合到芯片组718的一个或多个处理器访问或使用。存储器控制器720执行使处理器712（或多个处理器（若有多个处理器））能访问系统存储器724和大容量存储存储器725的功能。

系统存储器724可包含任何所希望的类型的易失性和/或非易失性存储器，例如，静态随机存取存储器（SRAM）、动态随机存取存储器（DRAM）、闪速存储器、只读存储器（ROM）等。大容量存储存储器725可包含任何所希望的类型的大容量存储装置，包含硬盘驱动、光驱、磁带存储装置等。

I/O控制器722执行使处理器712能经由I/O总线732而与外围输入/输出（I/O）装置726和728以及网络接口730通信的功能。I/O装置726和728可以是任何所希望的类型的I/O装置（例如，键盘、视频显示器或监视器、鼠标等）。例如，网络接口730可以是以太网装置、异步传输模式（ATM）装置、802.11装置、DSL调制解调器、线缆调制解调器、蜂窝调制解调器等，其使处理器系统710能与另一处理器系统通信。

尽管在图7中将存储器控制器720和I/O控制器722描绘为芯片组718内的单独块，但由这些块执行的功能可以集成在单个半导体电路内或可以使用两个或者更多单独的集成电路实现。

某些实施例预期任何机器可读介质上的方法、系统和计算机程序产品来实现上述功能性。例如，某些实施例可以使用现存的计算机处理器、或并入用于这个或另一目的的专用计算机处理器、或由硬线和/或固件系统来实现。

例如，上述系统的部件和/或方法的步骤中的一个或多个可以用硬件、固件和/或软件的指令集单独或组合地实现。某些实施例可以作为驻留于计算机可读介质（例如，存储器、硬盘、DVD或CD）上的指令集提供，用于在通用计算机或其它处理装置上的执行。本发明的某些实施例可以省略一个或多个方法步骤和/或以与所列出的顺序不同的顺序来执行步骤。例如，在本发明的某些实施例中可不执行一些步骤。作为另外的示例，可以按照不同于以上所列的时间顺序（包含同时地）来执行某些步骤。

某些实施例包含计算机可读介质用于携带或具有存储于其上的计算机可执行指令或数据结构。这样的计算机可读介质可以是可由通用或专用计算机或具有处理器的其它机器访问的任何可用的介质。以示例的方式，这样的计算机可读介质可包括RAM、ROM、PROM、EPROM、EEPROM、闪存、CD-ROM或其它光盘存储、磁盘存储或其它磁存储装置、或可用于以计算机可执行指令或数据结构的形式携带或存储所希望的程序代码并且可由通用或专用计算机或具有处理器的其它机器访问的任何其它介质。以上组合也包含在计算机可读介质的范围内。例如，计算机可执行指令包含使通用计算机、专用计算机或专用处理机器执行某一功能或一组功能的指令和数据。

一般而言，计算机可执行指令包含例程、程序、对象、部件、数据结构等，其执行特定任务或实现特定抽象数据类型。计算机可执行指令、关联的数据结构以及程序模块表示用于执行本文所公开的某些方法的步骤以及系统的程序代码的示例。这样的可执行指令或关联的数据结构的特定序列表示用于实现在这样的步骤中所描述的功能的对应动作的示例。

本发明的实施例可以实践于具有到处理器的一个或多个远程计算机的逻辑连接的连网环境中。逻辑连接可包含局域网（LAN）、广域网（WAN）、无线网、蜂窝电话网等，此处其以示例的方式呈现且并非限制。这样的连网环境常见于办公室或企业计算机网络、内部网和因特网并且可使用多种不同通信协议。本领域技术人员将意识到，这样的网络计算环境将典型地包含许多类型的计算机系统配置，包含个人计算机、手持式装置、多处理器系统、基于微处理器的或可编程的消费者电子设备、网络PC、小型计算机、大型计算机等。本发明的实施例还可实践在分布式计算环境中，其中由通过通信网络（由硬线链接、无线链接或由硬线或无线链接的组合）链接的本地和远程处理装置来执行作业。在分布式计算环境中，程序模块可位于本地和远程存储器存储装置中。

用于实现本发明的实施例的整个或部分系统的示范性系统可包含采用计算机形式的通用计算装置，其包含处理单元、系统存储器、和将包含系统存储器的各种系统部件耦合到处理单元的系统总线。系统存储器可包含只读存储器（ROM）和随机存取存储器（RAM）。计算机还可包含用于从磁性硬盘读取和写入磁性硬盘的磁性硬盘驱动、用于从可移除磁盘读取和写入可移除磁盘的磁盘驱动、以及用于从可移除光盘（例如CD ROM或其它光学介质）读取和写入可移除光盘的光盘驱动。这些驱动以及它们关联的计算机可读介质提供计算机可执行指令、数据结构、程序模块和计算机的其它数据的非易失性存储。

尽管已经参考某些实施例描述了本发明，但本领域技术人员将理解可作出各种改变以及可替代的等效而不背离本发明的范围。此外，可以作出许多修改来将特定情况或材料适应于本发明的教导而不背离其范围。因此，旨在本发明不限于所公开的特定实施例，而是本发明将包含落于所附权利要求的范围之内的所有实施例。

Claims

1. 一种用于生成健康护理工作流的关系绩效指标的计算机实现的方法，所述方法包括：

基于健康护理工作流的当前和历史健康护理数据而挖掘数据集来识别模式；

从所识别的模式和数据挖掘信息提取关系信息；

基于所述关系和模式信息动态创建关系绩效指标；

基于模型评价所述关系绩效指标；

监测与所述关系绩效指标关联的测量；以及

处理反馈来更新所述关系绩效指标。

2. 如权利要求1所述的方法，其中所述方法相对于健康护理设施而自发地并持续地执行。

3. 如权利要求1所述的方法，其中所述评价利用人工智能和统计建模来评价并修改所述关系绩效指标。

4. 如权利要求3所述的方法，还包括基于数据的统计建模而自动调整所述关系绩效指标的一个或多个参数。

5. 如权利要求1所述的方法，其中所述处理反馈还包括评价来自所述关系绩效指标的使用的结果来调整所述关系绩效指标中的一个或多个。

6. 如权利要求1所述的方法，还包括基于用户、位置以及时间中的至少一个而聚集使用信息以及提供所聚集的用户信息用于建模和决定调整。

7. 如权利要求1所述的方法，还包括基于所述关系绩效指标生成一个或多个警报。

8. 一种有形计算机可读存储介质，所述介质具有存储于其上的指令集，当执行所述指令集时，指示处理器来实现用于生成健康护理工作流的操作量度的方法，所述方法包括：

从所识别的模式和数据挖掘信息提取关系信息；

基于所述关系和模式信息动态创建关系绩效指标；

基于模型评价所述关系绩效指标；

监测与所述关系绩效指标关联的测量；以及

处理反馈来更新所述关系绩效指标。

9. 如权利要求8所述的计算机可读介质，其中所述方法相对于健康护理设施而自发地并持续地执行。

10. 如权利要求8所述的计算机可读介质，其中所述评价利用人工智能和统计建模来评价并修改所述关系绩效指标。

11. 如权利要求10所述的计算机可读介质，还包括基于数据的统计建模自动调整所述关系绩效指标的一个或多个参数。

12. 如权利要求8所述的计算机可读介质，其中所述处理反馈还包括评价来自所述关系绩效指标的使用的结果来调整所述关系绩效指标中的一个或多个。

13. 如权利要求8所述的计算机可读介质，还包括基于用户、位置以及时间中的至少一个而聚集使用信息以及提供所聚集的用户信息用于建模和决定调整。

14. 如权利要求8所述的计算机可读介质，还包括基于所述关系绩效指标而生成一个或多个警报。

15. 一种健康护理工作流绩效监测系统，包括：

关系分析引擎，基于健康护理工作流的当前和历史健康护理数据而挖掘数据集来识别模式并且用于从所识别的模式和数据挖掘信息提取关系信息；

统计建模引擎，基于包含所述健康护理工作流中的事件的关系排序的所述关系和模式信息动态创建关系绩效指标；

工作流决定引擎，基于模型评价所述关系绩效指标，并且监测与所述关系绩效指标关联的测量，所述工作流决定引擎处理反馈来更新所述关系绩效指标。

16. 如权利要求15所述的系统，其中所述工作流决定引擎与结果有效性分析引擎一起工作来监测测量并处理反馈。

17. 如权利要求15所述的系统，其中所述关系分析引擎接收预测建模反馈用于关系分析的进一步改良。

18. 如权利要求15所述的系统，其中所述工作流决定引擎利用人工智能和统计建模来评价并修改所述关系绩效指标。

19. 如权利要求18所述的系统，其中所述工作流决定引擎和所述统计建模引擎基于数据的统计建模而自动调整所述关系绩效指标的一个或多个参数。

20. 如权利要求15所述的系统，还包括使用聚集引擎来基于用户、位置以及时间中的至少一个而聚集使用信息并且提供所聚集的用户信息用于所述关系绩效指标的建模和决定调整。

21. 如权利要求15所述的系统，还包括报警引擎来基于所述关系绩效指标生成一个或多个警报。