用于患者保健计划管理的系统和方法

摘要

描述了一种实现患者保健管理功能的方法和系统。本公开包括：查询临床规则集合；并且获得包含与多个患者相关的临床信息在内的索赔数据。所述系统能够基于包含与患者相关的临床信息在内的索赔数据，识别从保健管理受益的患者，并且产生与每一个识别的患者相关联的标记或疾病状况的列表。所述系统基于识别的标记和包含与患者相关的临床信息在内的索赔数据来产生针对患者的单独保健计划。

说明书

技术领域

本发明总体上涉及健康保健管理领域，更具体地涉及患者保健计划 管理的范围。

背景技术

健康保健系统包括多种参与者，包括医生、医院、保险运营商和患 者。因为通过通常地不相关的个体和组织机构传送个人保健并且在多个 位置进行支付，这些参与者针对执行他们各自的任务所必须的信息而彼 此依赖。结果，需要过多的健康保健信息存储和检索系统来支持与患者 护理相关的这些参与者之间的繁重信息流。使用已有主框架和客户端服 务器系统将关键患者数据存储在不同的位置，已有主框架和客户端服务 器系统可能不兼容和/或可能按照非标准化格式存储信息。为了确保正确 的患者诊断和治疗，健康保健提供者必须经常通过电话或传真从医院、 实验室或其他提供者来请求患者信息。因此，由多个独立的健康保健系 统分支维护的完全不同的系统和信息传递程序导致关键信息及时传输的 间隙，并损害了临床保健的总体质量。

因为典型的健康保健实践集中于给定专科机构，通常患者可能使用 多个不同专科医生的服务，每一个专科医生潜在地只具有患者医疗状况 的一部分见解。完整医疗记录中的潜在差距减小了由每一个健康保健提 供者赋予患者的医疗建议价值。为了获得他或她的医疗数据的总体看法 或者建立他或她的医疗数据趋向，强制患者(并且每一个患者的医师) 分别从每一个单独的健康保健提供者请求医疗记录，并且尝试使片段数 据一致。医疗记录数据的复杂性还要求医师投入大量时间以便阅读和理 解纸质或电子的医疗记录，并且确保一致的保健质量。此外，尽管新的 医疗研究数据不断地影响保健的医疗标准，在新的医疗知识的传播过程 中存在时间延迟和理解退化的迹象。少量的现有解决方案通常关注于健 康保健信息的集中存储，但是不能结合患者的健康保健信息的实时分析 以便迅速地识别可能需要注意的潜在医疗问题。因此，仍然需要一种基 于计算机的解决方案，能够根据适当的医疗标准来实时地临床分析累积 的健康保健信息，并且直接通知患者和健康保健提供者，以确保迅速的 追踪调查分析结果。还需要一种基于计算机的解决方案，能够实时地临 床分析累积的健康保健信息，并且产生针对患者的保健计划。

发明内容

本发明的实施例用于提供一种向患者展示由临床决策支持技术支 持的交互式个人健康记录的自动系统，所述临床决策支持技术能够基于 期待的保健医疗标准和与患者的实际医疗保健相关信息的比较来传输个 人化的警报。与只存储和展示保健相关信息的现有静态保健记录相比较， 这些实施例是有利的。健康保健组织收集和处理较宽领域的医疗保健信 息，以便建立和更新相关的保健医疗标准，识别患者接收的实际医疗保 健，产生包括医疗警报和个人化健康警报在内的定制警报，并且经由在 线交互式个人健康记录(PHR)直接向患者传输定制警报。健康保健组织 收集的医疗保健信息包括患者专有的临床数据(例如基于索赔、健康保 健提供者和患者输入的输入以及健康状况参考信息(包括与多个医疗疾 病状况相关的基于证据的文献)。除了汇集患者专有的医疗记录和临床警 报信息之外，PHR还需要用户的数据以跟踪警报之后的动作。此外，PHR 接受患者输入的家族保健历史记录、患者的过敏性反应、当前的非处方 药和草药补充剂、未报告且未治疗的疾病以及用于监测诸如血压、胆固 醇和可能在患者知识领域范围内的附加相关医疗信息之类项目的输入。

医疗保险运营商收集源自医疗服务索赔、执行的程序、药物数据和 实验室结果的临床信息，并且将其提供给健康保健组织以便存储在医疗 数据库中。医疗数据库包括位于计算机可读介质上的一个或多个医疗数 据文件，例如硬盘驱动器、CD-ROM、磁带驱动器等。

健康保健组织中的医疗专家团队考虑健康状况参考信息的各种来 源(包括基于证据的文献)，产生并且连续修订临床规则集合，所述临床 规则反映了针对多种疾病状况的最佳基于证据的保健医疗标准。将临床 规则存储在医疗数据库中。

PHR通过自动地增加与从基于索赔、药物和/或实验室结果的数据得 出的信息相对应的数据字段来便于患者产生完整保健记录的任务。优选 地，PHR经由医疗风险评估工具(HRA)收集患者输入的数据(允许用户 录入家族病史记录)、已知的慢性疾病和其他医疗数据中的至少一些，并 且提供总体患者保健评估。优选地，HRA工具向患者展示与他或她的医 疗历史记录和当前展现的疾病相关的问题。风险评估逻辑动态地分支到 相关和/或关键的问题，从而节省患者时间并且提供有目标的结果。患者 输入到HRA中的数据还增加了PHR的其他区域内的相应数据字段，并且 产生附加的临床警报以辅助患者维持最佳健康状况。

健康保健组织经由分析系统将包括患者或护士输入数据以及索赔 数据在内的医疗保健信息累积到医疗数据库中，用于后续处理，分析系 统例如是纽约的Active Health Management，Inc公司运营的 系统。系统是包括规则引擎模块在内的多维 分析应用程序，规则引擎模块包括计算机可读指令，计算机可读指令向 患者的索赔和自己输入的临床数据应用反映了针对多种疾病的最佳基于 证据的保健医疗标准的临床规则集合，患者的索赔和自己输入的临床数 据反映了正在传递给患者的实际保健情况。规则引擎模块识别一个或多 个示例，其中由索赔数据(包括医疗程序、测试、药物数据和实验室结 果)和患者输入的临床数据证明的患者的实际保健情况与最佳基于证据 的保健医疗标准不一致，并且经由包括PHR工具的网页集合直接向用户 发布患者专有的临床警报。此外，规则引擎模块应用特定规则以确定应 该何时经由PHR向用户通知与他们的临床表现相关的新近可用的保健信 息。在一个实施例中，医师在患者的同意下访问网页。

在实施例中，当规则引擎模块识别实际保健情况与所建立的最佳基 于证据的保健医疗标准不一致的示例情况时，经由PHR向患者展示临床 警报。在实施例中，临床警报包括通知联系健康保健提供者以便开始或 停止专用的药物，和/或经历与患者专有的一种或多种疾病和共同病状相 关联的特定检查或测试程序。为了确保迅速的患者响应，健康保健组织 向与PHR处的个人化警报的可用性有关的患者发送同步邮件通知。临床 警报根据最佳基于证据的保健医疗标准来向用户通知已知的药物相互作 用和建议的医疗治疗。除了疾病专有的警报之外，规则引擎模块还通过 经由PHR发布个人化的健康警报来向用户通知相关的预防性健康状态信 息。在一个实施例中，患者能够通过经由用户界面查询医疗数据库，使 用PHR来搜索与特定疾病、测试或医疗程序有关的特定健康状况参考信 息。优选地，PHR允许患者创建包含患者的健康状况信息在内的可打印 报告，以便与健康保健提供者共享，所述健康状况信息包括健康状况概 要和健康状况风险评估报告。

此外，通过用作患者的医疗信息的中央仓库，PHR授权患者更加容 易地管理他们自己的健康保健决策，这有利于患者逐渐转移到消费者引 导健康状况计划。

另一实施例包括实现多个模块，用于经由PHR向患者提供实时处理 并传输临床警报和个人化的健康警报，以及经由一个或多个健康保健提 供者应用程序提供给健康保健提供者。具体地，系统包括实时应用消息 收发模块，用于经由健康保健组织和外部系统和应用程序之间的网络来 发送和接收实时信息。优选地，实时应用消息收发模块采用面向服务的 体系(SOA)，通过定义和实施一个或多个应用程序平台无关的软件服务 来在各种系统和应用程序之间承载实时数据。

在一个实施例中，实时应用消息收发模块包括网页服务，网页服务 与外部应用程序交互，用于通过HTTP经由简单对象访问协议(SOAP)来 传输实时数据。例如，消息获取网页服务接收与最佳基于证据的保健医 疗标准相对的、随后由规则引擎模块实时处理的实时临床数据。可选地， 将输入的实时数据存储在医疗数据库中。

与给定患者相关联的输入实时数据结合先前存储的数据和可用的 临床规则，限定了要由规则引擎模块处理的规则引擎运行程序。因此， 实时应用消息收发模块从多个源收集输入的实时临床数据，并且定义与 多个患者相关联的多个规则引擎运行程序，用于同步的实时处理。

实时应用消息收发模块将规则引擎运行程序转发至规则引擎模块 以示例多个实时规则处理会话。规则引擎模块对多个服务器之间的规则 处理会话进行负载平衡，以便于临床规则(最佳基于证据的保健医疗标 准)与输入的临床数据和患者输入数据的多个同步请求进行实时匹配。 当针对给定患者的实际保健模式偏离期待的保健模式时，规则引擎模块 产生一个或多个临床警报。类似地，规则引擎模块基于预防性健康保健 的基于最佳证据的医疗标准来产生实时个人化健康警报。

在处理期间，规则引擎模块将警报理由信息记录在医疗数据库中。 在一个实施例中，警报理由信息规定了输入数据已经触发/处理了哪个临 床规则(例如，通过规则号码)、已经产生了哪种警报(例如，通过警报 号码)、针对每一个警报的时间/日期戳、针对引起规则触发的给定患者 的专有排除和包含信息(例如，已知的药物过敏性反应用于排除建议可 能引起过敏性反应的药物摄取警报)以及与触发给定规则的输入实时数 据相关联的患者输入和索赔信息。

在另一个实施例中，规则引擎模块分析患者专有的临床数据以产生 针对各种医疗疾病状况的实时风险分数。风险分数量化了现有医疗疾病 的严重性，并且根据临床规则、考虑到评估多种风险因素来评估未来疾 病的风险。例如，风险分数可以识别高风险糖尿病患者或者未来经历中 风风险的患者。系统向患者以及健康保健提供者展示了风险分数。

因此，每一个规则处理会话基于针对给定患者的实时数据集合产生 了多个临床警报，个人化健康警报，和/或计算风险分数。消息传输网页 服务进而将所产生的警报传输至PHR和/或健康保健提供者应用。替代 地，应用消息收发模块包括用于发送和接收实时数据的单个网页服务。 为了便于警报的实时传输，警报载荷过滤模块通过多种条件和类别对输 入到实时应用消息收发模块的警报进行过滤，以减小实时警报载荷。除 了改进警报的实时传输速度之外，警报过滤还消除了冗余警报并且有助 于将接收者的注意力集中于重要的警报。

在另一个实施例中，实现了患者保健管理功能。本公开包括查询临 床规则集合并且获得包含与多个患者相关的临床信息在内的索赔数据。 系统可以基于包含与患者相关的临床信息在内的索赔数据来识别要受益 于保健管理的患者，并且产生与每一个识别的患者相关联的标记或疾病 的列表。系统基于所识别的标记、目标、问题、视觉目标和包含与患者 相关的临床信息在内的索赔数据来产生针对患者的个人保健计划。

附图说明

尽管所附的权利要求具体地阐述了本发明的特征，根据结合附图的 以下详细描述可以更好地理解本发明及其优势，其中：

图1是说明了根据本发明实施例的用于向患者显示个人健康记录的 系统概述的示意图，所述系统能够传递医疗警报；

图2是说明了根据本发明实施例的用于向患者提供定制警报的方法 的流程图；

图3是根据本发明实施例的由图1的基于网页的个人健康记录 (PHR)工具的主页面展示的用户界面的图；

图4是根据本发明实施例的由图1的PHR工具的警报详情页面展示 的用户界面的图；

图5是根据本发明实施例的图1的PHR工具的医疗风险评估工具 (HRA)调查表的用户界面的图；

图6是根据本发明实施例的与图5的HRA相关联的疾病和症状界面 的图；

图7是根据本发明实施例的与图5的HRA相关联的家族病史界面的 图；

图8-12是根据本发明实施例的图1的PHR工具的附加用户界面的 图，允许患者录入与用药、过敏反应、免疫、测试和医院探视相关联的 信息；

图13是根据本发明实施例的经由图5-12的界面向患者展示可用的 健康保健信息概述的健康概述界面的图；

图14是根据本发明实施例的基于经由图1的PHR工具可用的至少 一些信息产生的紧急情况信息卡的图；

图15是根据本发明实施例的图1的PHR工具的健康保健团队界面 页面的图；

图16是根据本发明示例的经由图1的PHR可用于患者的健康保健 跟踪工具的图；

图17是根据本发明实施例的警报状态报告的图形输出的图，所述 警报状态报告指示了针对所有患者群体的警报完成和输出状态；

图18是说明了根据本发明实施例的系统概述的示意图，所述系统 用于实时处理和传输针对所述患者的临床警报、个人化的健康警报和健 康风险分数；

图19是说明了根据本发明实施例的相对于针对给定患者的多个临 床警报，通过图18的警报载荷过滤模块处理的实时警报工作流程示意 图；

图20是根据本发明实施例的图18的健康保健组织经由实时应用消 息收发模块与多个外部系统和应用程序的示范性实时交互的示意图；

图21是根据本发明实施例的图18的向患者和健康保健提供者提供 临床警报、个人化的健康警报和健康风险分数的实时处理和传输的流程 图；

图22是根据本发明实施例的用于识别可能受益于保健管理的患者 并进行优先排序的方法的流程图；

图23是根据本发明实施例的用于识别与可能受益于保健管理的患 者相关联的特定疾病的方法的流程图；以及

图24是根据本发明实施例的用于执行保健管理的方法的流程图。

具体实施方式

以下实施例进一步说明了本发明，但是不应该解释为按照任何方式 限制权利要求的范围。

回到图1，参考向患者展示由临床决策支持技术支持的交互式个人 健康记录的自动系统，示出了本发明实施例设想的系统的实施方式，临 床决策支持技术能够根据最佳基于证据的保健医疗标准与患者的实际医 疗保健情况之间的比较来传输个性化的警报(包括被称作保健事项的临 床警报)。健康保健组织100收集并且处理与患者102相关的较宽领域医疗 保健信息，以便经由在线交互式个人健康记录(PHR)108产生和直接向 患者102传输定制的警报，包括临床警报104和个人化健康警报106。除了 汇集患者专有的医疗记录和警报信息以及这里将要讨论的其他功能之 外，PHR108还请求患者的输入，用于输入附加相关医疗信息，跟踪警报 后续动作，并且允许健康保健组织100跟踪警报输出。

当患者102利用一个或多个健康保健提供者110的服务时，医疗保险 运营商112收集相关联的临床数据114以便管理针对患者102的健康保险 覆盖范围。此外，诸如医师或护士之类的健康保健提供者110在办公室访 问或疾病管理交互期间，根据患者-健康保健提供者的交互将临床数据 114输入到一个或健康保健提供者应用。临床数据114源于医疗服务索赔、 药物数据以及实验室结果，并且包括与患者-健康保健提供者交互相关联 的信息，包括与患者的诊断和治疗相关的信息、医疗程序、药物处方信 息、住院患者信息和健康保健提供者笔记。医疗保险运营商112和健康保 健提供者110进而经由一个或多个网络116将临床数据114提供给健康保 健组织100，用于存储在医疗数据库118中。医疗数据库118由基于与健康 保健提供者100相关联的一个或多个基于服务器的计算机来管理，并且包 括位于计算机可读介质上的一个或多个医疗数据文件，计算机可读介质 例如是硬盘驱动器、CD-ROM、磁带驱动器等。优选地，医疗数据库118 包括商用数据库软件应用程序，能够经由结构化查询语言(SQL)与在相 同或不同基于服务器的计算机上运行的其他应用程序交互。在实施例中， 网络116是专用医疗记录网络。替代地或附加地，网络116包括具有网络 的全部或一部分的因特网连接。

健康保健组织100中的医疗专家团队参考健康状况参考信息122的 各种来源，包括基于证据的预防性保健数据，来建立并且连续或周期性 地修订临床规则集合120，临床规则反映了针对多种疾病的最佳基于证据 的保健医疗标准。将临床规则120存储在医疗数据库118中。

为了补充从保险运营商112接收的临床数据114，PHR108允许患 者录入可能在患者知识领域内的附加相关医疗信息。示范性的患者输入 的数据120包括附加临床数据，例如患者的家族病史、非处方药物的使 用、已知过敏性反应、未报告和/或未治疗的疾病(例如，慢性下腰痛、 偏头痛等)以及自行实施的医疗测试的结果(例如，周期性的血压和/ 或血糖读数)。优选地，PHR108通过自动地增加与从基于医疗索赔、药 物数据和/或实验室结果的数据得出的信息相对应的数据字段来便于患 者产生完整保健记录的任务。在实施例中，患者输入的数据128还包括 非临床数据，例如即将发生的医生预约。优选地，PHR108经由医疗风险 评估工具(HRA)130收集患者输入的数据128，医疗风险评估工具请求 与生活方式行为、家族病史、已知慢性疾病(例如，慢性背痛、偏头痛) 和其他医疗数据有关的信息，以根据规则引擎模块126的处理标记个体 针对一种或多种医疗疾病(例如，癌症、心脏、糖尿病、中风的风险) 的风险。优选地，HRA130向患者102展示与他或她的医疗历史和当前 展现的疾病相关的问题。风险评估逻辑动态地分支到相关和/或关键问 题，从而节省患者时间并且提供有目标的结果。患者102输入到HRA130 中的数据还增加PHR108的其他区域内的相应数据字段。健康保健组织 100经由规则引擎模块126将临床数据114、患者输入的数据128以及健 康参考和医疗新闻信息122、124汇集到医疗数据库118，用于后续的处 理。

系统125是包括规则引擎模块126在内的多维分析应 用程序，规则引擎模块包括计算机可读指令，用于向医疗数据库18的内 容应用临床规则集合120，以便识别由临床数据114和患者输入的数据 128所证明的患者102的实际保健情况与最佳基于证据的保健医疗标准 不一致的示例。在收集了与患者102相关联的相关数据114和128之后， 规则引擎模块126应用对于患者的医疗数据文件专有的临床规则120， 以将患者的实际保健情况与最佳基于证据的保健医疗标准进行比较。除 了分析索赔和实验室结果得出的临床数据114之外，分析还包括考虑已 知的过敏性反应、慢性疾病、未治疗的疾病和其他患者报告的临床数据， 以处理该疾病专有的临床警报104和个人化健康警报106，并且经由包 括PHR108的网页集合直接向患者102发布该警报。由与医疗数据库118 通信的计算机执行规则引擎模块126。在一个实施例中，包括规则引擎 模块126和医疗数据库118的计算机可读指令驻留在由健康保健组织 100控制的单个计算机的计算机可读介质上。替代地，规则引擎模块126 和医疗数据库118直接或者通过网络，经由健康保健组织100控制的分 离计算机进行交互。在Ciarniello、Reisman和Rlanksteen的美国专利 No.6,802,810中描述了与规则引擎模块126采用的处理技术相关的附加 细节，将其全部合并在此作为参考。

为了确保迅速的患者响应，健康保健组织100优选地向患者102发送 并发电子邮件通知，与PHR108处的定制警报104和106的可用性有关。如 这里所述，术语“警报”和“定制警报”是指患者专有的健康相关通知， 例如在根据临床数据114和患者输入数据128的一个或多个的处理由规则 引擎模块126产生之后经由PHR108直接传输给患者102的、并且与临床规 则120中反映的最佳基于证据的保健医疗标准相匹配的临床警报104和个 人化健康警报106。在实施例中，将警报104、106还传输给健康保健提供 者110。当规则引擎模块126识别到与最佳基于证据的保健医疗标准不一 致的实际保健情况的示例时，经由PHR108向用户展示临床警报104。优 选地，临床警报104在PHR108的用户界面内显著显示。在实施例中，临 床警报104包括用于联系健康保健提供者110的通知，以便开始或停止特 定药物治疗和/或经历与患者102专有的一种或多种疾病和共同病状相关 联的特定检查或测试程序。临床警报104包括通知患者已知的药物相互作 用以及从基于当前最佳证据的保健信息120的医疗标准得出的建议医疗 处方。还考虑新的疾病和实验室结果，通过分析患者的药物摄取来提示 临床警报104。类似地，规则引擎模块126通过经由PHR108发布个人化健 康警报106向用户102通知临床相关的预防性健康状态信息122，以确保总 体保健状况一致性。

规则引擎还识别处于危险生活方式行为的成员(例如，吸烟、高压 力、较差饮食/锻炼)，并且从高风险成员中寻找同意的用户来招收他们 进入生活方式训练计划。在一个实施例中，患者102能够通过经由用户界 面查询医疗数据库118，使用PHR来搜索与特定的疾病、测试或医疗程序 有关的特定健康状况参考信息。在另一个实施例中，患者102订阅医疗新 闻信息124用于经由PHR108和/或个人电子邮件传递。在再一个实施例 中，规则引擎模块126基于患者的临床数据114和患者输入的数据128，自 动地产生健康状况参考信息122、医疗新闻124和/或医疗信息的外部来源 的定制上下文检索103，用于经由PHR108传递检索结果。在又一个实施 例中，患者102基于规则引擎模块126没有处理的患者输入数据128的非临 床分量来接收综合健康提醒132，例如与即将到来的医生预约有关的通 知。在实施例中，综合健康提醒132包括提示患者更新HRA130、查看PHR 网站的视频旅行或者更新健康跟踪信息(下面结合图16讨论)。优选地， PHR108允许患者102产生包含患者的健康状况信息的可打印报告用于与 健康保健提供者110共享，所述健康状况信息包括健康概述和健康状况风 险评估报告。

为了确保进一步追踪调查，健康保健组织100可选地向健康保健提 供者110通知显著的临床警报104，如在合并的美国专利No.6,802,810 中所公开的。例如，如果临床警报104包括严重的药物相互作用，健康保 健组织100经由电话、邮件、电子邮件或其他通信提示健康保健提供者110 来发起紧急追踪调查。

尽管上述的实体关系是代表性的，本领域普通技术人员将认识到替 代的结构是可能的。例如在一个实施例中，健康保健组织100和医疗保险 运营商是相同的实体。替代地，健康保健组织100是致力于收集、汇集和 处理来自多个源的医疗保健数据的独立服务提供者，以为一个或多个医 疗保险运营商112提供个人健康记录(PHR)服务。在另一个实施例中， 健康保健组织100通过从一个或多个医疗保险运营商112收集数据来向一 个或多个雇主提供PHR服务。

转到图2，描述了一种经由个人健康记录向各个患者提供定制化警 报的方法。在步骤200-202中，健康保健组织100收集较宽领域的医疗保 健信息114、122、124、128，并且将其汇集到医疗数据库118中用于后续 分析。在步骤204中，健康保健组织100建立针对多种疾病的临床规则集 合120，例如通过让医疗专家团队连续地查看收集的健康状况参考信息 122(包括基于证据的医疗文献)。在步骤206-208，当对于保健医疗标准 的更新可用时(例如，在收集附加或者更新的基于证据的文献时)，健康 保健组织100修订临床规则120并且建立与最佳基于证据的保健医疗标准 相关联的新规则。在步骤210和212中，规则引擎模块126将临床规则120 内包括的最新的基于证据的保健医疗标准应用于患者的实际保健，如根 据索赔、药物、实验室和患者输入的临床数据所证明的，以识别患者的 实际保健状况与临床规则120实施的预期保健状况不一致的至少一个示 例。步骤212还包括识别是否应该经由个人化的疾病警报向患者120通知 新近可用的基于证据的预防性健康保健122的标准，例如当预防健康保健 信息有益于患者的实际保健时(例如，与乳腺癌筛查有关的通知)。如果 规则引擎模块126没有检测到由护理者提出的实际保健状况和最佳基于 证据的保健医疗标准之间的差异，或者当新接收到的健康状况参考不是 有益的(例如，考虑到现有信息的累积)，所述方法返回到步骤200。否 则，在步骤214-216，规则引擎模块126将包括相关联的警报细节在内的 警报指示符存储在医疗数据库118内的患者102的医疗数据文件中，并且 经由PHR108的适当界面向患者展示一个或多个临床警报104和/或个人 化的疾病警报106。可选地，规则引擎模块126经由电子邮件通知患者102 或者登陆到PHR108中以便查看一个或多个发布的警报104、106。如下面 结合图4进一步详细讨论的，PHR108向患者102提供用警报追踪调查的状 态或结果来更新系统的机会。为此目的，如果患者102表示已经解除了警 报，PHR108将用追踪调查状态或结果更新医疗数据库118中的相应警报指 示符，步骤218和220。在一个实施例中，系统还经由在输入的临床数据 114中存在的变化，基于适当地注意警报追踪调查来自动地更新警报指示 符。例如，当输入的实验室、药物和/或医疗服务索赔数据指示了通过患 者经历建议的测试程序、修改处方和/或请教健康保健提供者而继续之前 发布的警报时，系统自动地更新PHR108处的警报追踪调查状态显示器。 否则，PHR108继续提示患者102对警报进行追踪调查。

下面的图3-17提供了与PHR108的各种实施例及其相关功能有关的 附加细节。转到图3，示出了PHR108的主页面300的实施例。在一个实施 例中，当患者102经由安全登录/退出区域302获得对于PHR108的访问时， PHR108向患者展示具有一个或多个可选择警报104、106(等待患者的跟 踪调查)的警报显示区域304。主页面300还包括通常与警报跟踪调查和 健康风险评估(HRA)306、健康状况记录管理308、账户管理310和在线 健康库访问312相关的多个链接。当PHR108使用从医疗保险运营商112 接收的临床数据预先增加一些患者信息时，患者输入的数据包括全部记 录的重要部分。因此，本发明的实施例包括向患者102提供激励以便得出 对于患者输入的数据字段的完整响应，例如HRA130中的那些，并且可选 地为了确保警报跟踪调查。在一个实施例中，所述激励包括由患者的雇 主或健康保健组织100管理的积分项目。

当选择在警报显示区域304中显示的警报链接314或者未决警报 104、106的任一个时，将患者102引导至警报细节页面400，如图4所示。 警报细节页面400向患者展示警报列表402，警报列表402包括患者跟踪调 查未决的警报、并且优选地预先存储为紧急级别404和通知日期406。在 图4所示的实施例中，警报列表402包括多个临床警报104，建议与患者的 糖尿病相关的特定测试并且推荐使用statins(例如，以降低胆固醇级 别)。在一个实施例中，列表402包括一个或多个个人化的疾病警报106， 例如针对近期还没有筛查过的预定年龄范围的女性患者推荐进行周期性 的乳腺癌筛查。列表402还包括警报完成状态下拉列表408以向健康保健 组织100提供对于发布的警报104、106的跟踪调查状态。警报完整状态下 拉列表408允许患者102指示是否已经完成特定的警报，并且如果是，则 选择与完成结果相关的附加细节。在该实施例中，下拉列表408包括表示 患者已经联系了健康保健提供者100以开始或停止标记的药物治疗和/或 完成标记测试选择。此外，列表408允许患者提供没有完成未决警报的原 因，例如通过指示患者仍然计划与健康保健提供者110讨论所述警报、患 者对于建议的药物或测试程序过敏或者不能忍受、患者不能负担建议的 治疗或者警报不可应用。警报界面400还包括警报状态下拉列表410以允 许患者102分离地查看和更新未决定和完成的警报。

PHR108主页面300(图3)还包括到HRA130的链接316，所述链接 允许健康保健组织100从患者102收集附加的数据128以执行分析用于针 对一种或多种预定的医学疾病来识别处于危险的个体。如图5-7所示，HRA 130将从医疗保险运营商112得出的组合临床数据与患者输入的个人健康 状况信息、家族医疗史、未报告医疗疾病、生活方式行为和其他信息相 结合，以向患者提供特定的健康状况改进建议，并和临床警报104以及个 人化疾病警报106一起与健康保健提供者100讨论。如在图5中可以看出 的，HRA界面130在向患者102展示疾病(conditions)/病患界面600(图 6)之前，最初提示患者102输入一般信息，例如身高500、体重502、腰 围504、种族506和最近血压读数508。疾病/病患界面600进而允许患者基 于通过规则引擎模块126在先验证并且分析的保险运营商临床数据114来 查看和更新预先增加的疾病602。HRA130还允许患者102输入健康保健提 供者110没有注意的自己报告的健康问题604和/或患者102自己治疗的健 康问题，例如肚子疼、背疼或头疼。在一个实施例中，患者102能够在疾 病和症状界面600内显示的至少一些疾病中选择退出，例如向健康保健提 供者110提供定制的患者疾病打印输出。如图7所示，患者输入的家族病 史信息700有助于预测与一定的遗传疾病相关联的风险。输入到HRA130 中的信息与PHR108的其他区域交叉影响，并且反之亦然。

如图8-12所示，PHR108的其他区域允许患者102输入和查看处方和 非处方药物和附录(图8)、列举过敏性反应和相关联的过敏性反应触发 条件(图9)、更新免疫列表(图10)、并且产生测试、程序和医院就诊的 记录(图11、12)。

为了经由图5-12查看可用信息的一些或全部的概述，PHR108包括 与健康状况概述页面702的链接318(图3)。如图13所示，健康状况概述 界面702被患者102在到医生办公室或医院就诊时用于将他或她的健康状 况的概述与健康保健提供者110共享。健康状况概述702包括从索赔得出 的数据和用户输入的数据。具体地。健康状况概述702允许患者102单独 地选择以下类别信息的一个或多个来显示：患者的个人信息704、紧急情 况联系人708、保险提供者联系人信息710、健康保健团队712(例如治疗 医师和优选的药物)、免疫情况714、处方和非处方药物716、过敏性反应 718、疾病720(包括基于规则引擎模块126分析的临床数据的潜在疾病) 以及测试、程序和医院就诊信息722-726。相反地，PHR108还允许患者 102从显示健康状况概述702中的至少一些信息中退出，以便适应在针对 特定的健康保健提供者110的报告中显示的信息类型，或者删除一定的敏 感信息。在一个实施例中，PHR108还允许患者102从显示健康状况概述 702中的一些或全部患者输入的信息中退出，同时总是显示从索赔得出的 数据。替代地或者附加地，患者102能够打印健康状况概述702的一些或 所有部分706-726与健康保健提供者110共享。包括PHR108、患者102选 择不在健康保健概述02中显示的信息在内的所有其他信息仍然存储在医 疗数据库118中，并且可用于得出临床警报104和个人化疾病警报106的规 则引擎模块126。另外，这些信息仍然可用于患者经由PHR108的其他区 域查看，如以上结合图5-12所描述的。作为进一步的优势，经由PHR108 可用的信息的浓缩概述以紧急情况信息卡732的形式经由链接730可用于 患者102(图14)。

优选地，患者102经由健康保健团队页面734补充健康保健团队列表 712，如图15所示。健康保健团队页面734允许患者102添加新的医生、药 物、按摩医师和其他健康保健提供者，并且在任意时间指派初级护理医 师，而无须等待索赔添加的信息。优选地，患者102通过经由访问链路736 向提供者选项分配用户名和口令来控制健康保健提供者对于PHR108的 读取和/或写入访问。自己报告的标号738包括自己报告的健康保健提供 者的列表，而索赔报告的标号739包括基于输入的索赔数据的提供者的列 表。在实施例中，患者102允许一个或多个健康保健提供者访问经由 PHR108可用的信息的一些或全部。其他实施例包括允许家族成员或护理 者访问PHR108，并且向患者102提供对于附属的个人健康记录信息的访 问。在再一个实施例中，PHR108向患者提供数据输入/输出功能，能够 将在健康保健提供者之间端口传输包括PHR108在内的信息。附加的实施 例包括允许患者102从列表712中删除至少一些健康保健提供者的显示。

转到图16，PHR108还包括健康状况跟踪工具740，以允许患者102 倾向于一个或多个健康状况指示符。在所示的实施例中，健康状况跟踪 工具740将索赔数据742与患者报告的数据744(例如，来自于图5的HRA 130)进行组合以向患者102提供HDL胆固醇趋势的图形表示746。健康状 况跟踪工具740的附加实施例包括跟踪能够周期性评估的其他健康状况 指示符，例如血压。规则引擎模块126基于健康状况跟踪数据和在医疗数 据库118中可用的其他临床数据来评估患者报告的和基于索赔的健康状 况跟踪数据，以确定针对给定跟踪器数值的患者特定目标、并且评估对 于所述目标的当前跟踪器值以触发对于患者的临床警报104。在下面的图 18-21的实施例中，将与当前的跟踪器值相关联的临床警报104实时传输 给健康状况跟踪工具740。优选地，图形表示区域746包括正常范围和高 风险指示符748、750以向患者102提供健康状况风险评估趋势。经由自报 告指示符752表示自报告的值。

如图17所示，健康保健组织100通过查询在医疗数据库118中存储的 患者输入的警报状态来跟踪针对所有患者群体的警报结果。在所示实施 例中，警报状态报告754经由PHR108的警报完整状态下拉列表408(图4) 指示由每一个单独的患者102所选择的针对所有患者群体的临床警报完 成状态。其他实施例包括向用于测定雇员参与性的雇主提供PHR使用报 告。

PHR108的附加实施例包括使用PHR界面来显示雇主消息，并且经由 PHR提供患者102和健康保健提供者110之间的安全消息传递。

在图18-21所示的附加实施例中，本发明的系统和方法实现了多种 模块，用于经由PHR108向患者102并且经由一个或多个健康保健提供者应 用程序756向健康保健提供者110提供临床警报104和个人化的疾病警报 106的实时处理和传递。转到图18，模块758、768包括在计算机可读介质 上编码的计算机可执行指令，例如由健康保健组织100控制的一个或多个 服务器计算机的硬盘驱动器。具体地，所述系统包括实时应用消息收发 模块758，用于在健康保健组织100和外部系统和应用程序之间经由网络 760发送和接收实时信息。优选地，实时应用消息收发模块758通过定义 和实施一个或多个应用程序平台无关软件服务来在各种系统和应用程序 之间传递实时数据，来采用服务定向的体系结构(SOA)。

在一个实施例中，实时应用消息收发模块758包括网页服务762、 764，所述网页服务与外部程序交互，用于在HTTP上经由简单对象访问协 议(SOAP)传输实时数据。例如，消息摄取网页附图762接收通过规则引 擎模块126相对于最佳基于证据的保健医疗标准120随后处理的实时数 据。消息摄取网页服务762同时收集来自医疗保险运营商112的临床数据 114、来自患者的PHR108和HRA130的患者输入的数据128(包括患者输 入的临床数据)以及健康状况参考信息和医疗新闻信息122、124。在实 施例中，消息摄取网页服务762还从一个或多个健康保健提供者应用程序 756实时接收临床数据114，例如电子医疗记录应用程序(EMR)和疾病管 理应用程序。在再一个实施例中，消息摄取服务762根据患者在疾病管理 或集成语音响应(IVR)系统中与护士的交互来接收患者输入的数据128 的至少一些。可选地，将输入实时数据存储在医疗数据库118中。另外， 与给定患者102的输入实时数据与在数据库118和临床规则120中在先存 储的数据相结合限定了将要由规则引擎模块126处理的规则引擎运行情 况770。因此，实时应用消息收发模块758从多个源收集实时数据，并且 定义与多个患者相关联的多个规则引擎运行情况770用于实时处理。

实时应用消息收发模块758将规则引擎运行情况770转发至规则引 擎模块126，以例示多个患者专有的实时规则处理会话772。由规则引擎 模块126对规则处理会话772的处理在多个逻辑和物理服务器上进行负载 平衡，以便于用于临床规则(最佳基于证据的保健医疗标准)120与输入 临床数据114和患者输入的数据128的实时匹配的多次和同步请求。优选 地，根据J2EE规范来完成会话772的负载平衡。每一个规则处理会话72 通过参考针对相应患者102的唯一成员ID字段来调用医疗数据库118，以 接收患者的医疗历史并且继承用于处理输入实时数据的规则120。由输入 实时数据114、128的医疗成分表达的针对给定患者的实际保健模式偏离 由临床规则120表达的期待保健模式时，规则引擎模块126产生一个或多 个临床警报104。规则引擎模块126还产生与患者相关的实时个人化的疾 病警报106。规则引擎模块126实现调用医疗数据库118的服务，以存储所 产生的警报104、106并且提供针对每一个会话772的运行状态更新。在处 理期间，规则引擎模块126将警报理由信息记录在医疗数据库118中。在 一个实施例中，警报理由信息规定了输入数据(例如通过规则号码)已 经触发/处理了哪一条规则、(通过警报号码)已经产生了哪一个警报、 针对每一个警报104、106的时间/日期戳、针对引起触发规则(例如，已 知的药物过敏性反应用于排除推荐可能引起过敏性反应的药物治疗的警 报)的给定患者的特定排他性和包含性信息)、以及与触发规定规则的输 入实时数据相关联的患者输入的索赔信息。

在实施例中，当患者102将数据保存在PHR108内、并且在 系统125处接收其他实时医疗保健信息114、122、124时， 实时应用消息收发模块758采用GetRTRecommendationForMember网页服 务来触发实时规则处理会话772。GetRTRecommendationForMember网页服 务的请求消息结构包括以下字段：

MemberPlanID-唯一地识别医疗数据库118内的患者102。在一个 实施例中，该字段从患者的健康保健计划识别号得出。

ProcessCareConsideration-当将该值设置为“真”时，命令规 则引擎模块126基于包括相应保健引擎运行770在内的信息来例示一个或 多个实时规则处理会话772。当将该值设置为“假”时，命令系统恢复迄 今为止针对所述患者102所产生的所有实时警报，而无须例示附加的处理 会话772。

规则引擎模块126经由GetRTRecommendationForMember网页服务的 响应消息输出实时警报104、106，所述响应消息包括以下字段：

MemberPlanID-唯一地识别医疗数据库118内的患者102。在一个 实施例中，该字段从患者的健康保健计划识别号得出。

MemberLangPref-可以依赖于患者的语言偏好设置为“英语”或 “西班牙语”，如在PHR108中所设置的那样。

RTRecommendationList-由规则引擎模块126产生的实时警报104、 106的列表，包括针对每一个所产生警报的警报号码、警报名称、指导性 文本、服务代码、创建日期和完成状态指示符(例如，开放、完成、忽 略)。

在再一个实施例中，健康保健组织100内的在职医疗专家团队采用 基于网站的规则维护应用程序来相互限定临床规则集合120，以评估预定 的患者群体。在这种情况下，健康保健组织100经由基于网络的规则维护 应用程序，通过规定患者群体(例如，与给定医疗保健计划或健康保健 提供者相关联的患者的全部或其子集)以及临床规则120的执行版本来限 定规则引擎运行情况770。实时应用消息收发模块758然后汇集来自基于 网络的规则维护应用程序的规则引擎运行情况770，用于如上所述进行实 时处理。

在又一个实施例中，规则引擎模块126应用临床数据114和患者输入 的数据128的临床内容，以产生针对多种医疗疾病的实时风险分数105(例 如，将分数分配给可能增加心脏疾病的风险的各种临床因素、并且分数 可能基于成员的生理状况(疾病)和生活方式行为，计算百分数以识别 成员对于未来心脏疾病的风险)。风险分数105量化了现有医疗疾病的严 重性，并且根据临床规则120考虑了评估多种风险因素来评估针对未来疾 病的风险。例如，风险分数105可以识别高风险糖尿病患者或未来经历中 风风险的患者。系统将风险分数105展示给患者和健康保健提供者，例如 展示给疾病管理项目中的护士。例如，在完成HRA130时，立即向患者展 示针对潜在和现有疾病的风险分数105。此外，患者可以直接经由PHR130 请求风险分数计算。在另一实施例中，临床医师使用疾病管理应用程序/ 程序来计算与患者进行疾病管理交互之前和之后的患者的风险分数，以 便评估进展。在另一个实施例中，在办公室设置下使用EMR应用程序的医 师可以在预约期间请求针对患者的实时风险分数计算。这允许医师在办 公室会晤期间与患者回顾患者的保健模式中的高风险因素，并且识别要 求未来的疾病管理会话的患者。

规则引擎模块126还基于患者的临床数据114的实时输入和患者输 入的数据128来产生健康状况参考信息122、医疗新闻124和/或医疗信息 的外部来源的定制化上下文搜索103，用于经由PHR108实时地传递搜索 结果。

因此，每一个规则处理会话772基于针对给定患者102的实时数据集 合114、122、124、128，产生多个临床警报104、个人化的疾病警报106， 计算风险分数105和/或评估实时搜索103。消息传输网页服务764进而将 所产生的警报104、106传递给PHR108和/或健康保健提供者应用程序 756，包括疾病管理应用程序。替代地，应用消息收发模块758包括用于 发送和接收实时数据的单个网页服务。为了便于警报104、106的实时传 输并且有助于将警报接收者的注意力集中于临床上重要的报告，通过去 除临床上相同的警报，警报载荷过滤模块768通过多种疾病和分类过滤输 入到实时应用消息收发模块758中的警报来减小实时警报载荷。

转到图19，针对表示与特定患者102相关联的规则处理会话772期间 产生的多个临床警报104的警报工作流程，示出了警报载荷过滤模块768 的操作方法的实施例。最初，通过规则引擎模块126考虑输入实时数据来 评估与患者102相关的所有临床规则120。然后，规则引擎模块126产生多 个临床警报104，每一个临床警报与特定的警报或推荐相对应、并且由通 过警报号码(例如“CC101”-“CC105”)来识别。在步骤776，警报 载荷过滤模块768接收多个临床警报104，并且排除由相同规则120所产生 的、但是在其理由数据中缺乏患者输入的信息的多个警报。在该示例中， 警报号码“CC103”和“CC99103”由相同的规则120产生的、但是对于 “CC99103”的理由缺乏患者输入的信息。因此，警报载荷过滤模块768 排除了与警报号码“CC99103”相对应的警报。接下来在步骤778，警报 载荷过滤模块768排除了当发现不同的规则120为“真”时产生的、但是 导致相同警报或推荐的临床警报。在这种情况下，输入实时数据触发了 两种不同的规则120，但是产生了相同的警报，每一个标记为“CC101”。 因此，警报载荷过滤模块768排除了一个冗余的警报号码“CC101”。在 步骤780，警报载荷过滤模块768将输出的警报整合到推荐族中(例如与 潜在的药物相互作用、医学测试推荐相关的警报)。在这种情况下，将警 报号码“CC103”和“CC104”整合为单独的警报号码“CC104”用于 传递。在步骤782中，警报载荷过滤模块768查询医疗数据库118以获得警 报传输方的历史以及相对于特定警报类型或号码的警报传输排除设置。 例如，基于现有的警报传输历史，需要将警报号码“CC101”传输至健 康计划成员或患者102并且传输至成员的健康保健提供者。因此，将警报 “CC101”解析为分别指定传输至健康保健提供者和成员的警报“CC 101P”和“CC101M”。另一方面，基于对这种具体的警报号码涉及微小 问题并且可以抑制(例如，为了减小总警报消息载荷，或者基于提供者 和/或用户设置)加以表示的排除设置排除了警报号码“CC105”。在一 个实施例中，例如，向个人化的疾病警报106赋予比临床警报106更低的 优先级，并且可以在高警报传输条件下排队等候未来的处理，以确保严 重警报的实时传输。替代地或者附加地，将临床警报104分配严重级别。 例如，向临床紧急药物相互作用分配比监测药物的副作用的建议更高的 安全性级别。

在步骤784中，警报载荷过滤模块768还规定了针对每一个警报号码 的实际通信方。例如，基于将健康保健提供者专业与每一个警报的主题 相匹配，警报号码“CC101P”与特定的健康保健提供者(例如，“提供 者1”)相关联，而警报号码“CC102P”与不同的健康保健提供者(例如 “提供者2”)相关联。类似地，基于先前的警报传递历史，可以将相同 的警报传递给患者和健康保健提供者两者(例如，指定警报号码“CC 101M”直接传递给成员/患者102，而警报号码“CC101P”传递给健康保 健提供者)。在步骤786中，警报载荷过滤模块768将警报文本(包括警报 理由信息)定制给所分配的传输方，并且可选地定制对于患者健康保健 计划的特效药。最后在步骤788，警报载荷过滤模块768通过消息传输网 页服务764针对每一个过滤的警报号码指定警报目的地应用程序或通信 方法用于后续的传递。在实施例中，警报目的应用程序和通信方法包括 PHR应用程序、HRA应用程序、电子医疗记录(EMR)应用程序、疾病管理 应用程序、医疗账单应用程序、传真应用程序、呼叫中心应用程序、信 件及其组合。

转到图20，说明了经由实时应用消息收发模块768的健康保健组织 100与多个外部系统和应用程序的示范性实时交互。在一个实施例中，一 旦患者102将附加数据128输入到在线PHR108中，例如新的非处方药，消 息摄取网页服务762将新的患者输入数据128同步地中继到实时应用消息 收发模块758，用于限定与患者相关联的规则引擎运行情况770以由规则 引擎模块126进行实时处理。如果规则引擎模块126确定由与患者相关的 输入和先前存储的临床数据证明的实际保健模式和由可应用临床规则 120证明的基于证据的最佳保健医疗标准之间的变化，则产生一个或多个 临床警报104。例如，临床警报104可以警告患者由患者选择的非处方药 可能与患者的药物治疗中的药物之一相互作用。替代地，临床警报104 可以警告患者102：由于患者的状况导致限制使用非处方药(例如感冒 药)，所述疾病例如是根据在先存储的生物计量装置读数(来自与PHR108、 HRA130交互的血压监控器的血压读数)获得的高血压。同样，当患者102 经由在线HRA130或者经由集成语音响应(IVR)系统796完成调查表时， 规则引擎模块126产生一个或多个临床警报104。然后，消息传输网页服 务764同步地传递通过警报载荷过滤模块768的临时警报104至PHR108、 HRA130和/或IVR系统796。

优选地，输入实时患者数据128和/或临床数据114触发附加的规则 处理会话772，所述附加的规则处理会话引起规则引擎模块126产生提示 患者102和/或健康保健提供者110收集附加信息的实时问题。除了输入实 时数据和患者的现有健康概述之外，规则引擎模块126还考虑患者的风险 分数105，用于产生与患者的健康相关的问题。例如，对于由于高血压而 导致处于中风风险的患者，如果规则引擎模块126检测到患者102应该服 用ACE抑制剂、但是没有服用的话，规则引擎模块126产生与对于ACE抑制 剂的已知过敏性反应有关的问题。类似地，如果规则引擎模块126检测到 在存储的临床数据114和/或患者输入的数据18内的适当时间范围中不存 在推荐的糖尿病检测测试，则产生针对测试结果的提示。同样地，当患 者服用与葡萄柚汁相互作用的药物时，规则引擎模块126产生与葡萄柚汁 消耗量有关的问题。在一个实施例中，规则引擎模块126基于对于前述问 题的回答展示附加的动态问题。例如，基于从前述回答得出的针对冠状 动脉疾病(CAD)和潜在的共发病状的风险分数，规则引擎模块126产生 与心绞痛症状相关的问题。

将回答传输回医疗数据库118用于存储，并且传输回规则引擎模块 126，用于与最佳基于证据的保健医疗标准120进行进一步的比较。在实 施例中，规则引擎模块126执行经由HRA130或IVR系统796接收的患者回 答、以及经由疾病管理应用程序792和/或EMR790接收的护士或健康保健 提供者的回答的实时分析。

为了便于即时的健康保健决策，健康保健组织100还从一个或多个 健康保健提供者应用程序756接收实时数据或者传递实时警报104，106， 例如EMR应用程序790或疾病管理应用程序792。例如，在办公室访问期间， 诸如医师或护士之类的健康保健提供者将处方、诊断、实验室结果或其 他临床数据114输入到EMR应用程序790中。响应于实时接收这种数据，规 则引擎模块126发起患者专有的规则处理会话772(图18)，并且当在考虑 临床规则120的情况下、输入数据和先前存储的患者数据表示与最佳基于 证据的最佳保健医疗标准的偏离时，产生一个或多个临床警报104。这允 许健康保健提供者在办公室访问期间实现对于患者的健康保健的即时调 整，例如在患者等待的同时调整处方并且修改测试程序治疗安排。

类似地，由疾病管理应用程序792将临床警报104展示给临床医师， 例如与医疗保险运营商112相关联的护士。当临床医师通过电话与患者 102交互，并且使用疾病管理应用程序792来记录患者对于医疗问题的回 答时，消息摄取网页服务762将由临床医师输入的患者响应与健康保健组 织100相关，用于实时处理。例如，如果患者的响应表示患者是吸烟者， 在电话会话期间向临床医师展示患者专有的警报104以联系患者(对于服 用口服避孕药的吸烟女性的增加血液凝固风险)。在实施例中，将临床警 报传递给呼叫中心应用程序794，用于连续患者或医师进行进一步的跟踪 调查。呼叫中心应用程序794同步地将高严重性临床警报104调度到实时 呼叫查询中，同时存储低严重性警报用于后续的呼叫跟踪调查。优选地， 结合临床警报104，规则引擎模块126还产生包括基于证据的预防性健康 保健的医疗标准在内的个人化疾病警报106，并且将此信息传输给PHR 108、HRA130、疾病管理应用程序792、EMR790和/或呼叫中心应用程序 794。

在另一个实施例中，规则引擎模块126在用户患者和/或健康保健提 供者实时回顾的个人化疾病警报106中包括相关的教育材料，例如健康状 况参考信息122和医疗新闻124。规则引擎模块126基于临床数据114、患 者输入的数据128、风险分数105以及对于动态问题的输入回答的实时分 析来识别相关的健康状况参考信息122和医疗新闻124。在实施例中，在 登陆到PHR108或HRA130中时将健康状况参考信息122和医疗新闻124展 示给患者102，在与患者的实况电话呼叫期间(基于输入的患者数据)经 由疾病管理应用程序792展示给护士，并且在办公室访问期间经由EMR 790展示给医师。例如，当患者102是糖尿病患者并且规则引擎模块126 检测到升高的血色素AlC(HbAlC)测试结果时，教育材料可以包括与饮 食和锻炼的积极效果相关的健康状况参考信息122和医疗新闻124。类似 地，基于心脏病发作的历史和患者的药物治疗依存信息(例如，由健康 保健提供者输入)，规则引擎模块126展示与服用针对心脏病发作的药物 的重要性相关的相关药物教育材料122、124。在再一个实施例中，规则 引擎模块126处理患者的健康数据概述、输入的实时临床数据114以及患 者输入的数据128，并且产生惯常的上下文搜索查询以连续地搜索相关的 医疗文献(例如，同业审查杂志、FDA更新、Medline Plus等，并且主动 地推送搜索结果以增加PHR108的研究调查312(图3)。替代地或者附加 地，规则引擎模块126将搜索结果实时地推送至多个健康保健提供者应用 程序756，例如EMR790和疾病管理应用程序792，以授权健康保健提供者 在实况电话会话期间或者在办公室访问期间教导患者。

与规则引擎模块126的输入数据的实时处理以及实时应用程序通相 关的附加实施例包括患者群体风险分数分析和按需重新评分的医师成就 度量。在一个实施例中，规则引擎模块126在健康保健提供者的实践内针 对预定的患者群体计算风险分数105。当健康保健提供者110登录到EMR 应用程序790时，向他或她展示由当前生理状况(疾病)组织的所有患者 列表以及与每一个患者群体组相关联的适当风险分数105。例如，将健康 保健提供者的患者群体内的高风险、中等风险和低风险糖尿病患者组织 成不同的组。这允许健康保健提供者以优先顺序排列高风险患者、确定 跟踪调查访问的频率、使用信息来提供先进的医疗家庭服务并且识别针 对未来疾病管理会话的患者。当健康保健提供者110经由EMR790将附加 的临床数据114提供给健康保健组织100时，规则引擎模块126自动地实时 重新计算针对健康保健提供者的患者群体的相应风险分数105，并且重新 加载患者群体显示。替代地或者附加地，健康保健提供者110在输入附加 的临床数据114之后请求风险分数重新计算。在一个实施例中，在PHR108 或HRA130从患者输入信息128接收临床数据时，规则引擎模块126实时地 重新计算针对健康保健提供者的患者群体的风险分数105。在这种情况 下，消息传输网页服务764将更新的患者群体组和相关联的风险分数105 推送至EMR790。基于风险分数105，规则引擎模块126确定针对默认医疗 办公室访问的适当时间，以及患者是否要求转诊到另一个健康保健提供 者(例如从护士到实习医生或者从初级保健医师到专家)以支持先进的 医疗家庭服务。

为了提供实时的医师成就度量，规则引擎模块126根据在临床规则 120中编码的临床成就度量预定集合来评估先前存储和输入的临床数据 114、128，以向每一个医师提供自我成就的不断反馈，并且帮助健康保 健组织100识别较高成就医师。例如，向在预定时间范围内向具有心肌梗 塞(MI)的所有患者开处方β-受体阻滞药的医师分配比相同实践领域内 的其他医师更高的成就分数。针对MIβ-受体阻滞药使用的医疗度量识别 出医师实践中的合适患者，所述患者对于MI不再有效，但是仍然是使用 β-受体阻滞药的合适候选者(即，对于β-受体阻滞药使用没有限制)。 这种数字构成了针对这种临床度量的分母；下一个步骤是识别当前正在 服用β-受体阻滞药的患者的个数。这将向医师提供与哪些患者目前没有 服用β-受体阻滞药有关的信息以及允许回顾以留意未遵医嘱是否可能 存在问题。在适当跟踪调查这些患者之后，可以重新计算医疗度量以留 意在度量分数方面是否存在改进。还可以在分母中的患者不是β-受体阻 滞药治疗(然后可以提供像CMS医师志愿报告程序的外部回顾团体)的合 适候选者的原因的证明文件之后，使用所述分数的重新计算。在实施例 中，医师110访问在线入口(或者是EMR790的一部分或者与EMR790相分 离)以回顾他或她的患者群体以及针对与给定患者或者患者组相关联的 每一个成就度量的成就分数。医师110还回顾用于确定针对每一个患者或 者患者组的成就分数的临床数据。为了发起与给定患者或患者组相关联 的成就分数的按需重新计分，医师110输入针对具体成就度量的附加信 息，例如患者对于处方药物治疗过敏或者不适应，或者医师从来没有治 疗过针对给定疾病的患者。响应于此，规则引擎模块126将附加的输入数 据应用于与患者相关的现有信息，并且相对于附加的信息重新计算医师 的成就分数，除了当产生临床警报时存储新添加的信息用于规则引擎模 块的进一步分析之外，实时地刷新针对医师的成就分数显示器。在一个 实施例中，健康保健组织100核对支持医疗数据库118中的医师成就度量 结果的临床信息，以支持针对每一个医师或医师组的成就度量报告。

再次参考图16，当患者102和/或健康保健提供者110将新健康指示 符数据744输入到基于PHR的健康状况跟踪工具740或者疾病管理应用程 序792中时，规则引擎模块126向患者102和健康保健提供者110提供实时 健康趋势范围和相应的临床推荐。具体地，规则引擎模块126考虑先前存 储的健康概述(例如，在先的健康指示符读数、患者的慢性疾病、年龄 和性别)和最佳基于证据的保健医疗标准120来处理新接收的数据点744， 以实时地产生正常或目标范围748以及高风险指示符750，提供了针对更 新的读数的场景。对于诸如血压(需要停留在给定的目标范围内)之类 的健康指示符，经由高范围和低范围来划分高风险指示符750。除了提供 目标范围和健康风险指示符之外，规则引擎向成员提供特定的消息以警 告他们像血压那样的健康指示符是否危急地高以至于需要紧急医疗护 理。在实施例中，健康指示符包括胆固醇水平、血压读数、HbAlc测试结 果和身体质量指数(BMI)读数。在一个实施例中，临床医师在电话会话 期间经由疾病管理应用程序792输入如患者102报道的健康指示符读数 744。在再一个实施例中，健康状况跟踪工具740实时地与一个或多个生 物计量装置798电学交互以上传健康指示符数据744，例如通过使用患者 计算机上的UBS、串行接口或无线接口(例如，Wi-Fi、Zigbee、蓝牙、 UWB)。示范性的生物计量装置包括血压监控器、血糖监控器、心律监控 器、EKG监控器、体温监控器或者用于监控和存储患者健康指示符数据的 任意其他电子装置。替代地或者附加地，健康状况跟踪工具740与能够将 医疗数据存储在计算机可读介质上的电子存储装置交互，例如USB、硬盘 驱动器或者光盘存储器。

转到图21，说明了提供向患者102和/或健康保健提供者110提供临 床警报104、风险分数105和个人化的疾病警报106的实时处理和传递的方 法的实施例。在步骤800-802中，健康保健组织100经由消息摄取网页服 务762接收实时医疗保健信息114、122、124、128，并且将其存储在医疗 数据库118中。在步骤804中，健康保健组织100回顾收集的健康状况参考 信息122，并且基于针对多种医疗疾病的最佳基于证据的保健医疗标准来 建立规则集合。必要时，在步骤806至808中，健康保健组织100修订在临 床规则120中实现的保健医疗标准，或者建立附加规则以反映在最佳基于 证据的保健医疗标准中的更新。否则，在步骤810中，实时应用消息收发 模块758根据规则120并且基于与每一个患者102相关联的输入实时数据 以及在数据库118中在先存储的患者数据，来限定多个规则引擎运行情况 770，用于由规则引擎模块126实时处理。

在步骤812-814中，规则引擎模块126进而发起与每一个规则引擎运 行情况770相对应的实时规则处理会话772，以向输入的医疗保健信息 114、122、124、128和在医疗数据库118中存储的患者的健康概述应用一 个或多个规则120。在步骤816，规则引擎模块126通过考虑患者数据，使 用临床规则120评估预定疾病的风险来产生风险分数105。当由输入和在 先存储的临床数据114、128表示的给定患者的实际保健情况与由临床规 则120内的最佳基于证据的保健一老标准所表示的针对给定疾病的预期 保健模式不一致时，规则引擎模块126产生多个临床警报104。类似地， 在步骤818-820中，当输入的健康状况参考信息122与患者的临床数据相 关并且有益于患者的临床数据时，规则引擎模块126还产生一个或多个个 人疾病警报106以通知患者或健康保健提供者。在步骤822中，当产生警 报104、106时，规则引擎模块126将针对每一个警报的警报理由信息存储 在医疗数据库118，并且将所有未决的已产生警报转发给警报载荷过滤模 块768。

在步骤824-828中，为了优化载荷用于实时传输，警报载荷过滤模 块768通过多种疾病和分类过滤输入到实时应用消息收发模块758的警报 (图19)，将已过滤的警报104、106的指示符存储在医疗数据库118中， 并且将包括风险分数在内的已过滤警报传输给消息传输网页服务764进 行传递。最后在步骤830，消息传输网页服务764经由PHR108、HRA130 将已过滤警报104、106和/或风险分数105传递给患者进行显示，并且将 由健康保健提供者应用程序756提供给健康保健提供者，包括EMR790、 疾病管理应用程序792和呼叫中心794。

一些实施例提供保健管理和保健计划功能。保健计划允许提供者限 定针对各种患者疾病的患者想象目标、问题、目标和动作，并且跟踪他 们的状态。提供者包括护士、保健管理者、医疗助手、医生和与健康保 健相关服务有关联的其他人。提供者还可以与保险运营商以及对患者健 康感兴趣的其他组织机构相关联。使用保健引擎，产生保健计划以解决 针对患者的患者想象目标、问题、目标和动作。可以使用上述方法和系 统实时地产生和更新保健计划。在一些实施例中，提供者识别可能尤其 受益于保健管理的患者。

转到图22，说明了识别可能受益于保健管理的患者并进行优先排序 的方法的实施例。在步骤900，运行系统125以识别可能受益 于保健管理的患者。示范性的保健管理程序包括慢性病保健管理、急性 病保健管理、疾病和妇产科疾病。在步骤902，引擎推荐可能受益于保健 管理的特定患者。在步骤902推荐的患者可以是在步骤900识别的患者的 子集，或者可以包括在步骤900识别的所有患者。用于推荐患者的示范性 标准包括针对每一种标记、产生分数和总体患者分数的患者严重性。标 记表示与患者相关联的具体疾病。产生分数量化了给定具体保健管理程 序的时机用于延伸服务。

在推荐延伸服务的患者之后，在步骤904，基于步骤902得到的分数 来优先排序患者延伸服务。在步骤906，进行患者延伸服务。示范性形式 的延伸服务包括电话呼叫、个人会议、电子邮件或其他形式的电子消息。 在步骤908，确定是否成功地联系到了患者。在步骤910，与病例管理人 员确定预约。此外在步骤912，患者可以自己参考保健计划，并且在步骤 910发起与保健管理者的预约。

转到图23，说明了用于识别与可能受益于保健管理的患者相关联的 特定疾病并且使患者参加的方法的一个实施例。在步骤914，保健管理者 发起针对患者的保健计划的产生，并且在步骤916，运行保健引擎。在该 实施例中，保健引擎936包括与保健管理相关联的附加模块。在该实施例 中，保健引擎936包括与保健管理相关联的附加模块。在步骤938，保健 引擎运行开始。在步骤940，从如上所述的所有源检索数据，包括实时医 疗保健信息临床数据114、健康状况参考信息122、医疗新闻信息124和患 者输入的数据128。此外，保健管理者可以向保健引擎提供信息。在步骤 942，确定成员健康状况。这一步骤确定了针对单独的患者可以激活哪个 受管理的保健计划。保健引擎通过相对于风险分数如上所述的具体标记 来确定任意标记、疾病、风险情况和临床风险分层来产生成员健康状态。 受监控的事件可以是临床的或者非临床的。风险分数量化了现有医疗疾 病的严重性，并且根据临床规则考虑到评估多风险因素而评估了针对未 来疾病的风险。

在一个实施例中，保健引擎包括临床规则集合，以分析患者的健康 概述的当前状态和监控的事件。患者的健康概述包括疾病、并发症 (co-morbidity)以及风险情况。基于所述疾病是否得到控制和并发症 的进展，将每一种疾病进一步分层以确定临床风险的级别为高、中等或 低。除了健康概述之外，保健引擎分析所有患者的监控事件集合以及针 对患者的健康概述所适应的监控事件。监控事件可以包括：a)对于基于 证据的推荐的遵守性，例如使用具有CAD患者的他仃药物(statins)；b) 包括与初始治疗、改进的药物治疗、监控并发症和/或诊断检查相关的那 些在内的保健偏差；c)生活方式行为，例如睡眠习惯；d)预防性保健， 例如在肾移植受体中筛查皮肤癌；e)疾病专用目的/目标，例如实现健 康体重(BMI＜25)；f)程序识别和参与，例如参加疾病管理程序；g)特 定任务的完成，例如高级指示；h)准备好改变和健康目标，例如计划戒 烟；i)不利事件的进展或者实验室结果的显著变化，例如针对心力衰竭 的住院治疗；j)愿意接受药物治疗，例如没有提供的处方药物；k)药 物或预定测试的副本；l)适用于特定的有益设计，例如药物治疗公共付 费减免；m)预约优先权和未得到的预约；n)提供者转诊推荐(referral  recommendation)；o)消费者偏好，例如通信方法、程序约定。

患者的状态随着新信息的发生和/或时间的流逝而经常改变。患者 的疾病可能在严重性方面发展，或者可以随着治疗而得到解决。在一个 实施例中，保健引擎将识别成员的当前状态，并且将位于保健引擎可以 查阅的临床规则的成员的历史。保健引擎分析所有可用的临床数据(例 如，索赔、药物数据、实验室结果、EMR数据、医院数据和患者收集的数 据)，以在进行保健时向健康保健团队和患者展示临床相关且明智的信 息。保健引擎可以在人口和患者专有级别实时地利用所有可用的临床数 据来识别疾病、共发病状和风险疾病的当前列表。

在步骤944，按照需要运行目标/动作规则。例如，病例管理者可以 请求产生保健计划，或者当会见患者时产生保健计划。目标包括高级别 项目，例如“戒烟”。动作包括使患者实现具体目标的任务。在步骤946， 创建、关闭或取消目标和动作。可以基于事实医疗保健信息、临床数据 114、健康状况参考信息122、医疗新闻信息124和患者输入的数据128来 创建目标和动作。按照这种方式，通过考虑引擎可用的所有医疗信息来 智能地创建动作。已经完成的动作将不会被添加到保健计划中。接下来， 在步骤948识别与患者的标记相关的文件。在步骤950，基于例如完成的 规则来管理文件。

在步骤918，请求患者需要的任意附加信息。步骤918可以发生在与 患者的首次电话之前的任意时间，或者当需要附加信息时发生。在步骤 920，将患者提供的任意信息输入到保健引擎。保健引擎可以基于新输入 的信息按照需要更新保健管理计划。更新可以实时发生，或者可以在随 后的时间成批处理。在步骤922，发起与患者的联系，并且在步骤924， 保健管理者联系患者。在步骤926，系统基于预先限定的列表向保健管理 者展示患者的标记。在该实施例中，保健引擎产生所述列表。保健管理 者可以基于与患者的对话向列表添加标记。在步骤928，保健管理者与患 者一起回顾所述标记、其他问题和难题。然后在步骤930，病例管理者与 患者一起回顾药物治疗和动作。在步骤932，病例管理者回顾与保健计划 相关联的文件。文件可以包括与药物治疗、过敏性反应、家族医疗病史 以及与保健计划相关的其他文件有关的信息。在步骤934，保健管理者回 顾任何保健专有的文件。保健管理者可以基于从文件接收到的信息来更 新保健引擎中的信息。保健引擎实时地分析新信息，并且所述分析可以 影响患者的保健计划和个人评估。

在一些实施例中，保健引擎936如上所述实时运行。保健管理者基 于病例管理者输入的信息来实时地更新保健计划。病例管理者可以在会 见患者期间查看更新的保健计划。

在产生保健计划并且发起联系之后，保健管理者使患者执行如图24 所示的保健计划。最初在步骤952，保健管理者回顾高严重性级别1动作。 可以按照任意方式存储动作。例如，可以通过严重性、积极管理的生理 状况(疾病)或者创建日期和时间来管理动作。接下来，在步骤954，病 例管理者回顾与动作相关联的目标。一些动作可以与多个目标相关联。 可以按照任意方式存储目标，例如通过严重性、积极管理的生理状况(疾 病)或者创建日期和时间。在回顾了与动作相关联的目标之后，在步骤 956，病例管理者为患者选择和描述针对每一个动作的目标。在步骤958， 保健管理者回顾与每一个目标和动作相关联的难题。可以按照多种方式 存储难题，包括通过严重性、积极管理的生理状况(疾病)或者创建日 期和时间。

在步骤960，保健管理者与患者讨论与每一个动作相关联的难题。 基于患者具有的问题，在步骤962，患者和保健管理者产生针对所述患者 的想象目标。想象目标是高级别的患者目标。例如，患者可能具有活的 足够长以看到她的孙女从高中毕业的目标。在步骤964，保健管理者和患 者讨论想象目标、问题、目标和动作。这些类别的每一个都应该彼此相 关。如果进行了任意改变，保健引擎可以实时地更新保健计划。

在步骤968，保健管理者可以向患者分配家庭作业。家庭作业可以 包括诸如读取信息材料、查看视频或者锻炼之类的项目。在步骤970，产 生保健计划概述，并且向病例管理者显示历史信息。基于概述和历史信 息，病例管理者与患者讨论任意附加的问题，并且在步骤972，患者会见 结束。

保健管理系统允许在保健引擎能够实现的所有疾病和问题方面的 动态和个人化医疗评估。保健引擎规则可以实时运行以帮助每一个评估 个体化并且简明化，有助于在不牺牲成员体验的情况下改进操作效率。 如上所述，评估是保健计划的组成部分。例如，评估识别了需要附加信 息的范围。基于成员健康状态的保健引擎分析来产生评估。在传统的疾 病管理中，手写会话以有助于确保一致性。这通常导致了关注于数据收 集，并且强制对话按照一定的顺序发生，设置利用了分支逻辑。

用COPD(慢性阻塞性肺病)称呼成员并且根据长期使用试图教导成 员类固醇和骨质疏松症(易坏骨头)的潜在风险的护士可能向每一个成 员询问以下问题：(1)在过去的6个月，你是否口服了类固醇(口服药丸 或液体，无吸入)？(2)(如果回答服用类固醇至少三个月的子问题) 钙和维生素D对于健壮骨头是重要的。你从饮食来源中是否获得足够的钙 和维生素D？(3)(如果回答服用类固醇至少6个月的子问题)你是否进 行过骨头测试以评估你的骨质疏松症？在保健引擎驱动的评估中，保健 引擎实时地查看来自于索赔、HIE、患者自己的报告的所有可用信息，以 帮助针对每一个单独的成员适应修改这些问题。例如，如果患者1是患有 COPD的75岁女性并且正在进行骨质疏松治疗时，当护士对其进行评估时， 护士将不会看任何这些问题，而只是在需要的情况下向成员教导当前的 骨质疏松治疗的信息。对于患者2，患有COPD、服用类固醇1年、在去年 进行了骨头测试的78岁女性将不会得到任意这些问题。对于患者3，没有 服用类固醇的61岁男性(因为在HRA中已经回答而知晓)将不会得到这些 问题，直到一年以后以确保一切都未改变。对于患者4，对于其是否服用 类固醇位置的54岁男性，将向其询问问题1，然后基于分支逻辑适当地询 问问题2或3。

按照这种方式，已经向患有COPD的每一个成员最初询问15个问题的 护士现在只需要询问与成员相关但是还未知晓的问题。

因此，可以将包括这里应用的公开、专利申请和专利在内的所有参 考文件结合在此作为参考，如同每一个参考文件单独地或者专门地表示 通过参考的方式合并，并且全部合并在此进行阐述。

术语“一”和“所述”以及类似参考术语在描述本发明的上下文中 的使用(尤其是在所附权利要求的上下文中)应该解释为覆盖单数和多 数形式，除非这里或者上下文明确限定。术语“包括”、“具有”、“包含” 和“含有”应该解释为开放式术语(即，意思是“包括但不限于”)，除 非特别指出。这里数值范围的引用只是为了用作单独参考落在所述范围 内的每一个分离的值的简略表达方法，除非这里另外表示，并且将每一 个分离的值合并到说明书中，如同单独地引用每一个值。可以按照任意 合适的顺序执行这里描述的所有方法，除非这里另有表示或者除非上下 问明确限制。任何和所有势力或者这里提供的示范性语言(例如，“诸 如”)的使用只是为了更好地理解本发明，而不是对于本发明的范围强加 限制，除非另有声明。说明书中的语言不应该解释为表示任意没有要求 权利要求的元件对于本发明的实践是重要的。

这里描述了本发明的优选实施例，包括实现本发明的发明人已知的 最佳方式。在阅读前述描述时，对于那些优选实施例的改变对于本领域 普通技术人员是清楚明白的。发明人预期本领域普通技术人员适当地采 用这些变体，并且发明人意欲按照除了这里具体描述的方式之外的方式 实践本发明。因此，本发明包括在使用适用法律所允许的范围内对所附 权利要求引用的主题的所有改进和等价。此外，本发明包括对于所有可 能变体中的上述元素的任意组合，除非这里另有说明或者上下文明确地 限制。