临床决策支持的制作方法

1.本发明涉及临床决策支持领域，并且更具体地讲，涉及用于临床决策支持的用户界面。


背景技术：

2.技术进步导致在各种设置和过程中收集的数据的数量和复杂性增加。此类数据除非可以被整合、过滤和解释以获得可采取行动的见解(insight)，否则可能不会有用。这需要可将数据变换为可采取行动的见解的专用决策支持系统和计算机算法。此类系统的使用正变得越来越有意义的示例性领域是健康护理。
3.高质量的护理服务需要沿着受试者的护理轨迹对护理管理做出最佳决策。然而，健康护理专业人员和受试者(例如，患者)都可能面临复杂的临床决策(例如，由于可用数据的数量和复杂性的增加)。例如，这可能是由于迅速扩展的疾病知识和技术进步，其不仅包括新型或更先进的诊断工具和疗法，而且还包括数据源和健康护理数字化的增加的可用性。
4.尽管健康护理信息技术越来越多地被采用并且改变了现代健康护理服务，但健康护理信息系统无法将可用数据过滤并变换为在护理过程中可容易理解和可采取行动的水平。因此，临床决策支持(cds)系统正在成为健康护理信息技术的必需部件。
5.cds系统可在个体受试者水平和人口健康管理水平上显著改进护理的临床、财务和工作流程方面。然而，已经证明有效采用和实施cds系统是困难的。在提高cds系统的有效性中面临的主要挑战包括：
6.改进用户界面；
7.总结受试者特定信息；
8.对建议进行优先级排序和过滤；
9.将针对受试者的建议与并存病组合；以及
10.使用自由文本信息来驱动临床决策支持。


技术实现要素：

11.本发明旨在至少部分地满足上述需要。为此，本发明提供了独立权利要求中定义的设备、系统和方法。从属权利要求提供了有利的实施例。
12.提供了一种用于生成用于临床决策支持的受试者特定的用户界面的方法，所述方法包括：
13.获得关于已建立的临床知识的临床参考信息，所述已建立的临床知识与多个不同临床标准有关；
14.获得关于受试者的受试者特定的临床信息；
15.基于所述受试者特定的临床信息来确定描述所述多个不同临床标准中的至少一个临床标准的相关性或重要性的临床上下文信息；
16.基于所述临床参考信息、所述受试者特定的临床信息和所述临床上下文信息来确定所述受试者特定的临床信息的子集，所述子集包括与临床决策相关的受试者特定的临床信息；以及
17.基于所述受试者特定的临床信息的所述子集来定义用户界面部件和用户界面元素中的至少一项，其中确定所述受试者特定的临床信息的子集包括：
18.基于所述临床参考信息和所述临床上下文信息将权重值关联到所述受试者特定的临床信息；以及
19.基于与所述受试者特定的临床信息相关联的所述权重值来标识所述受试者特定的临床信息的子集。
20.所提出的实施例提供了用于生成灵活和/或自适应用户界面(ui)的概念。此类所生成的ui可在问题空间内提供个性化的(例如，受试者特定的)临床决策支持，该问题空间如此之大以至于其不允许为每个问题单独地手工制作ui设计。实施例可用于自动生成个性化ui，其包含特定于受试者(例如，患者)和上下文的特征。
21.实施例可帮助在临床工作流和医疗上下文中以正确的格式和定时/层次结构提供正确的数据。这可使得医疗专业人员能够基于优化以显示受试者的相关数据的ui来分析受试者特定的情况。
22.作为示例，所提出的方法可利用知识推理部件(例如，推理引擎)和临床路径模型来从受试者特定的临床信息的全集合中提取：(i)受试者特定的临床信息的相关子集，并且(ii)潜在地使用该相关子集来生成针对正在处理的临床问题的个性化建议，例如，与处理选择决策相关的诊断测试结果。
23.所提出的概念可提供ui引擎，该ui引擎被配置为自动生成(而不是手工制作)ui，该ui被优化为使用一组ui部件示出给定临床上下文(例如，用户、物理空间)中针对手头给定问题的受试者特定的临床信息的相关子集和/或个性化建议。例如，在所提出的实施例中，ui引擎选择最佳ui部件并且然后将它们组成针对该特定受试者的专用ui。
24.实施例可采用临床路径模型作为ui引擎的一部分，并且可选地可以使用诸如医院特定的临床规则或关于本地受试者数据的人工智能的其他知识库。这可有助于向用户更好地呈现决策支持结果或难题/问题，从而提高可用性并有助于更好地制定决策。提高效率可能导致改进结果、降低成本、更好的工作流程和改进用户体验。
25.所提出的实施例可解决临床决策支持系统在正确时间以正确格式呈现正确数据的挑战。例如，这可通过根据各种因素，基于信息元素相对于上下文和信息元素相对于彼此的重要性自动来生成用户界面来完成。用户界面的界面元素和部件可取决于信息的相关性而被自动赋予外观和相关性。此外，部件不仅可自适应/响应于自身，而且还可灵活地适应界面的其他部件。这可确保可强调一组部件而不是单个数据点的重要性。它还可确保保持信息的层次结构并且确保关键信息元素之间的关系或差异保持明显。以这种方式，实施例可以临床相关方式定义一组用户界面部件。
26.对用户界面(ui)的引用应被视为对通过其用户和决策支持系统进行交互或交换信息的环境(例如二维屏幕表示)的引用，该环境包括以预定义的层次结构和顺序编排的一组ui部件。
27.ui部件包括受试者特定的临床信息的相关子集的集成表示，该相关子集从较大的
数据集中过滤得到(例如，基于临床参考信息和临床上下文信息)。这可由多个ui元素或其他ui部件构建。
28.ui元素包括特定临床信息的(例如，视觉或文本的)单一表示。
29.所提出的实施例可根据知识库(例如，包含关于已建立的临床知识的临床参考信息)和受试者特定的临床信息来推理哪些是相关信息元素，关于信息相关性的信息层次结构是什么，以及用于在特定临床上下文中为受试者做出决策的重要关系/关联是什么。
30.实施例可采用输出部件，该输出部件消耗来自决策支持系统的信息，并且利用影响最佳用户界面配置的因素来推理该信息。这些因素例如可以包括：内容、上下文、数据格式、设置和物理空间、角色和简档、技术和媒体以及历史决策。
31.输出部件可自动绘制用于决策支持系统的用户界面，其中ui元素和部件的呈现、相关性和外观由诸如前一段中列出的那些因素触发。这些因素可影响ui元素和部件的内容、组成、外观和行为。例如，用户界面引擎可取决于其相关性向受试者特定的临床信息，以及该信息所驻留的用户界面元素和部件分配特定权重。然后，它可执行对所有受试者特定的临床信息和用户界面元素和部件的校准以解析其相对于彼此的外观。以这种方式，用户界面元素和部件可从库中灵活和动态地选择，在该库中它们以各种配置可用，并且然后它们的布局被适配为遵循内容优先、响应性设计原则的基于比例的网格。ui元素和部件可响应其内容和其他ui元素和部件。
32.输出部件可调整“感兴趣区域”以聚焦(即强调)一组相关特征。此外，可显示过去、现在和(可能的)未来的特征。这可导致向用户更好地呈现决策支持结果或难题/问题，从而提高可用性并有助于更好地制定决策。
33.实施例所采用的算法或模型可包括简单的线性模型或统计模型，和/或采用人工智能，这取决于所考虑的因素的数量和聚合数据的复杂性。
34.因此，所提出的实施例可帮助向用户(诸如执业医师、医生、外科医生、技术人员等)以考虑临床上下文的方式呈现相关的或重要的受试者特定的临床信息。考虑临床上下文而标识的受试者特定的临床信息可使用户能够专注于感兴趣的特定临床信息或相关性，从而减少可能由于呈现过多和/或不相关的信息而导致的复杂性或混乱。
35.实施例可通过以考虑特定(例如，选定、所选或当前)临床上下文的方式来采用上下文信息而标识信息，来增加临床信息的值。实施例可通过使用上下文信息而不是依赖于用户的技术专业知识来增加受试者特定的临床信息的临床值。
36.获得临床参考信息可包括从以下至少一项获得临床参考信息：基于知识的系统，其包括具有领域知识、规则和关联的临床知识库；以及非基于知识的系统，其包括被配置为生成临床知识的学习部件。两种主要类型的cds系统是基于知识的系统和非基于知识的系统。
37.基于知识的系统通常包括三个主要部件：(i)包含领域知识、规则和关联的知识库；(ii)推理引擎，其基于知识与受试者数据的结合进行推论；以及(iii)用户界面，即用户通过其与决策支持系统交互以及经由其将决策支持系统的结果呈现给用户的装置。在此类系统中，知识库可包括各种形式的临床参考信息，包括临床指南或路径、专家建议或诸如研究证据或其他文献的在线数据。临床指南是基于研究证据和临床实践经验的针对具有特定状况的受试者的最佳管理的一组建议。受试者的护理路径描述了受试者的多学科护理过程
中的顺序步骤。
38.非基于知识的系统通常使用人工智能或统计学以通过从临床经验中学习或在临床数据(例如本地受试者队列数据(包括临床和操作))中发现模式来生成知识。与基于知识的系统类似，它们通常也包括推理引擎和用户界面。
39.在一些实施例中，所述受试者特定的临床信息可包括以下至少一项：描述所述受试者的至少一个生理参数或特性的受试者数据；描述所述受试者的至少一个医学参数或特性的临床数据；以及描述由所述受试者进行的至少一个临床测试或过程的操作数据。因此，受试者特定的临床信息可包括各种类型的数据，包括受试者信息(例如，病史、并存病等)、测试结果(例如，医学成像、病理学和分子病理学、实验室测试等)、所接收的处理和处理结果、心理社会数据、操作数据(例如，过程质量、数据年龄等)等。
40.所述临床参考信息可包括临床路径模型。然后，确定临床上下文信息可包括：分析所述受试者特定的临床信息的临床路径模型以标识所述受试者在临床路径中的当前位置；基于所标识的所述受试者在临床路径中的当前位置，将多个不同临床标准中的一个或多个临床标准标识为相关或重要；确定所标识的一个或多个临床标准的相关性或重要性；以及确定描述所标识的一个或多个临床标准的所确定的相关性或重要性的临床上下文信息。
41.在一个实施例中，将权重值关联到所述受试者特定的临床信息可包括：利用启发式算法处理临床参考信息和所述临床上下文信息以确定所述受试者特定的临床信息的权重值。例如，当所述临床参考信息包括临床路径模型时，所述启发式算法可以处理路径知识模型以确定数据与多个不同临床标准中的所述至少一个临床标准的相关性。因此提出了通过使用路径知识模型来定义在纵向概况中的数据的相关性，以采用启发式算法来确定路径驱动器中的权重。
42.在一些实施例中，基于所述受试者特定的临床信息的所述子集来定义用户界面部件和用户界面元素中的至少一项包括：基于与所述受试者特定的临床信息相关联的所述权重值来标识所述受试者特定的临床信息的子集的至少一个数据类型；以及基于所标识的数据类型来确定用户界面部件或用户界面元素。作为示例，这可包括从一组可用的用户界面部件和用户界面元素中标识用户界面部件或用户界面元素，其中所标识的用户界面部件或用户界面元素被配置为示出所标识的数据类型的数据。例如，确定用户界面部件或用户界面元素可包括：将部件权重值关联到所述至少一个数据类型；以及基于与所述至少一个数据类型相关联的所述部件权重值，从一组可用的用户界面部件和用户界面元素中标识用户界面部件或用户界面元素。
43.在所述一组可用的用户界面部件和用户界面元素不包含适于示出所标识的至少一个数据类型的数据的用户界面部件或用户界面元素的情况下，定义用于示出所标识的数据类型的数据的新用户界面部件或用户界面元素。以这种方式，实施例可被认为包括解析针对所标识的数据类型的最合适的用户界面部件或用户界面元素的过程。例如，当所标识的受试者特定的临床信息的子集指示需要向用户传送特定形式的数据时，实施例可通过引用各自被设计成传送特定形式的数据的可用用户界面部件或用户界面元素来解决这一点。因此，可以标识(或者，如果没有标识到合适的部件/元素，则定义)针对受试者特定的临床信息的最佳用户界面部件或用户界面元素。
44.因此，在示例性实施例中，定义用户界面部件和用户界面元素中的至少一项可包
括：从用户界面部件和元素的库中选择用户界面部件或用户界面元素。
45.定义用户界面部件和用户界面元素中的至少一项可包括：基于以下至少一项来确定用户界面部件或元素的性质的值：与受试者相关联的偏好；与受试者相关联的受试者特定设置；与受试者的先前临床决策相关联的历史值；和用户输入信号。例如，可在考虑各种因素和/或输入的同时自动生成用户界面部件或元素的性质的值。
46.一些实施例还可包括：生成用于控制用户界面的显示的用户界面控制信号，其中用户界面控制信号包括描述所定义的用户界面部件和/或用户界面元素的信息。这种输出信号可包括用于控制用户界面部件和/或用户界面元素的显示的控制信号。可以只显示被标识为关于临床上下文或决策相关或重要的受试者特定的临床信息，由此防止向用户提供不相关和/或无关的信息。
47.根据另一方面，提供了一种用于生成用于cds的受试者特定的用户界面的计算机程序产品，其中所述计算机程序产品包括计算机可读存储介质，所述计算机可读存储介质具有通过其体现的计算机可读程序代码，所述计算机可读程序代码被配置为执行所提出的实施方案的全部步骤。
48.因此，还提供了一种计算机系统，包括：根据所提出的实施例的计算机程序产品；以及一个或多个处理器，其适于通过执行所述计算机程序产品的计算机可读程序代码来执行根据所提出的概念的方法。
49.根据本发明的另一个方面，提供了一种用于生成用于临床决策支持的受试者特定的用户界面的系统，所述系统包括：接口部件，所述接口部件被配置为获得关于已建立的临床知识的临床参考信息，所述已建立的临床知识与多个不同临床标准有关，以及获得关于受试者的受试者特定的临床信息；推理部件，所述推理部件被配置为基于所述受试者特定的临床信息来确定描述所述多个不同临床标准中的至少一个临床标准的相关性或重要性的临床上下文信息；分析部件，所述分析部件被配置为基于所述临床参考信息、所述受试者特定的临床信息和所述临床上下文信息来确定所述受试者特定的临床信息的子集，所述子集包括与临床决策相关的受试者特定的临床信息；以及输出部件，所述输出部件被配置为基于所述受试者特定的临床信息的所述子集来定义用户界面部件和用户界面元素中的至少一项，其中所述分析部件被配置为：
50.基于所述临床参考信息和所述临床上下文信息将权重值关联到所述受试者特定的临床信息；以及
51.基于与所述受试者特定的临床信息相关联的所述权重值来标识所述受试者特定的临床信息的子集。
52.系统可远离显示器，并且因此用户界面部件和/或用户界面元素的定义可经由通信链路进行通信。以这种方式，用户(诸如医疗专业人员)可具有适当布置的系统，该系统可在远离系统的位置处接收内容/信息以用于生成用于cds的受试者特定的用户界面。因此，实施例可使得用户能够使用本地系统(例如，其可包括便携式显示器设备，诸如膝上型计算机、平板计算机、移动电话、pda等)来远程取回和查看受试者特定的临床信息。
53.系统还可包括：服务器设备，其包括用于生成受试者特定的用户界面的系统；以及客户端设备，其包括用户界面显示器。因此，可采用专用数据处理装置来生成受试者特定的用户界面，从而减少对系统的其他部件或设备的处理要求或能力。
54.系统还可包括客户端设备，其中客户端设备包括分析部件、输出部件和显示单元。换句话说，用户(诸如医生或医疗专业人员)可具有适当布置的客户端设备(诸如膝上型计算机、平板计算机、移动电话、pda等)，其处理所接收的数据以便定义用户界面部件和用户界面元素中的至少一项，并且生成显示控制信号。
55.因此，将理解的是，处理能力因此可根据预定约束和/或处理资源的可用性以不同的方式分布在整个系统中。
56.本发明的这些和其他方面将从下面描述的实施例中变得显而易见并且参考下面描述的实施例来阐明。
附图说明
57.现在将参考所附示意图详细描述根据本发明的各方面的示例，其中：
58.图1是根据示例性实施例的系统的简化框图；
59.图2a-2c示出了图1的分析部件的示例性具体实施的框图；
60.图3a-3c描绘了与实施例的示例性用例相关联的用户界面的简化示例；
61.图4是提供不同ui的所提出的方法的示意性图示；
62.图5是根据所提出的实施例的护理路径驱动的ui的概念图示；
63.图6a-6c分别描绘了根据所提出的实施例生成的示例性ui的第一到第三实例；以及
64.图7是其中可采用实施例的一个或多个部分的计算机的简化框图。
具体实施方式
65.提出了用于提供与特定临床上下文相关或对其重要的受试者特定的临床信息的概念。实施例可提供基于信息针对临床上下文和/或临床决策的相关性或重要性的ui。
66.因此，此类提议可以支持在考虑临床上下文(例如，临床设置、状态或环境)的情况下简单和直观地导航和标识受试者特定的临床信息，例如通过使得相关或相关联的信息关于临床上下文被可视化和/或导航。因此，可通过所提出的实施例来提供改进的cds。
67.因此，本发明的实施例旨在使得受试者特定的临床信息能够参照临床上下文而呈现，以便促进或增强cds过程。此外，实施例可以旨在使得相关或重要的受试者特定的临床信息能够以简单、准确和临床上下文显示或可视化并且同时能够提供足够细节，以使得(优选地以增加的效率和/或可靠性)促进或支持临床评估或决策。因此，实施例可以协助例如临床支持评估、医疗诊断和/或支持规划。
68.说明性实施例可用于许多不同类型的临床、医疗或受试者相关的环境，诸如医院、医生办公室、病房、护理之家、个人之家等。为了提供用于说明示意性实施例的元素和功能的描述的上下文，下文提供附图作为如何可实现说明性实施例的各方面的示例。因此，应当理解，附图只是示例并且不旨在断言或暗示关于其中可实现本发明的方面或实施例的环境、系统或方法的任何限制。
69.所提出的是，各种因素对于有效地向用户传达决策支持结果是重要的，并且最好在用于cds的用户界面中考虑这些因素。此类因素的示例包括：
70.内容：
71.不同疾病类型需要不同内容(例如，受试者病史、医学成像或病理结果)。决策支持系统的更广泛应用需要可扩展的解决方案。
72.上下文：
73.例如，在该特定时刻，系统是为了什么目的而使用的。如果受试者处于主要诊断阶段，用户界面可能会更加强调这一点，从而示出诊断证据的强度、信息的差异和缺失的测试。在受试者已经具有已建立的诊断并且选择处理后，更多的重点可放在受试者健康状况和各种处理成功的可能性。在临床监测期间，可在疾病史的上下文中示出最新健康状况，并可能加上当前问题和健康风险的指示。
74.数据格式：
75.例如，结构化与非结构化信息：结构化数据被组织、编码，并且可能与其他数据元素具有已知关系。这使得结构化数据能够例如放置在用户界面的专用字段中。此外，可以示出结构化数据元素之间的关系和关联。此外，图形表示可用于结构化数据元素或它们之间的关系以使信息更加直观。然而，在数据以文本为基础时，需要适配用户界面以使文本可读并且应显示适当数量的文本以保持可理解性。
76.设置/物理空间：
77.例如，多学科小组会议、就诊(consultation)等。在多学科小组会议中，满足用户界面处应支持必须在非常有限的时间内作出决策的小组讨论。来自多学科评估的证据应该是整个团队都能理解的。在就诊中，临床医生可能需要更容易地访问更详细的信息以及在专家视图和受试者视图之间切换的可能性。
78.角色/简档：
79.用户类型(例如，临床学科或受试者)和用户简档影响最佳配置。例如，在病例审查期间，临床专家可能需要在用户界面中看到放置在来自其他学科的信息的上下文中的其自身学科的更多细节。此外，临床医生可能需要专门信息，而受试者可能需要更容易理解的信息。
80.技术/介质：
81.每个观看平台(例如，监视器、电脑屏幕、平板计算机、智能手机等)都需要优化配置以使信息可读。
82.历史决策和伴随的用户界面:
83.系统可从先前情况下的决策以及在这些时刻做出的决策的疗效中学习。此外，在不同时刻设置的用户偏好被考虑在内。
84.这些因素中的每一者可能影响特定数据或数据组合的相关性(整体上以及相对于彼此)，并且由此影响其在用户界面上的优选外观和相关性。发明人提出了生成由cds系统、诸如上述因素和受试者特定数据驱动的灵活和自适应的ui的系统。可以自动提取相关信息和所需的呈现格式，并且然后系统可取决于上述因素自适应地呈现ui界面。
85.现在参考图1，描绘了根据示例性实施例的系统的简化框图。cds系统100包括接口部件105，该接口部件被配置为获得基于知识的临床参考信息110和受试者特定的临床信息120。
86.作为示例，临床参考信息110可以是基于知识的：规则库，例如，基于临床指南、临床路径、专家提议、在线数据等来指定如果这样则进行的语句。在其他实施例中，临床参考
信息110可以是非基于知识的：生成的知识，例如根据应用数据统计或人工智能来从局部队列数据、全局数据等学习的所生成的知识。
87.例如，受试者特定的临床信息120可包括：(i)患者数据：人口统计资料、社会经济、病史等；(ii)临床数据：患者健康状况、投诉、实验室数据、诊断数据、处理数据等；和/或(iii)操作数据：检查日期、检查之间的持续时间、图像和测试质量等。
88.推理部件125被配置为基于受试者特定的临床信息120来确定描述多个不同临床标准中的至少一个临床标准的相关性或重要性的临床上下文信息130。作为示例，本实施例的推理部件采用推理引擎，该推理引擎通过推理哪个临床参考信息110适用于受试者特定的临床信息120来利用临床上下文信息130丰富临床参考信息110和受试者特定的临床信息120。例如，推理引擎可推理受试者在临床路径中的位置，并且这可以基于已经完成的检查。临床路径中的位置可指示例如需要做出的决策以及对该决策而言重要的数据。
89.分析部件135被配置为基于临床参考信息110、受试者特定的临床信息120和临床上下文信息130来确定受试者特定的临床信息的子集，该子集包括与临床决策相关的受试者特定的临床信息。因此，输入到分析部件的数据包括临床参考信息110、受试者特定的临床信息120和临床上下文信息130的完整集合。本实施例的分析部件包括考虑影响ui功效的各种驱动器的ui引擎。如针对图2a-2b和3a-3c所述，可在下面找到分析部件135的详细功能。
90.在该示例中，分析部件135的ui引擎利用来自ui库140的信息。
91.例如，ui库140包括ui元素、部件和行为性质的库。每个元素/部件等可采用多种配置或外观并且具有各自程度的细节和重点，例如：不同的尺寸、例如总结和扩展视图的不同图形表示、不同的突出显示方法，以用于例如强调数据的新颖性或数据的差异。
92.ui库140还包括包含一般定义的ui框架，例如：不同的元素和部件可映射在其上的网格系统。网格系统是确定数量的可变宽度的列，其适合于不同的屏幕尺寸，其中ui布局被指定以适合不同部件；视觉语言，其作为视觉表现的创造和研究，使用图形元素设计原则来成功地传送数据；针对如何绘制部件和元素可以实现对数据的最佳理解的规则的集合。
93.此外，该示例的ui库140包括与ui设置相关的信息，诸如偏好设置。这些可以是取决于例如用户简档而被预先设置的。此外，可存在特定的校准周期，在该校准周期中，用户与自动生成的个性化ui交互并且基于偏好在ui布局和样式中进行调整，该偏好可在用户的个人设置中存储和检索并且系统可从中学习(例如，利用悬挂(hanging)协议)。这也可以是由先前情况产生的历史设置的库，这些设置可能适用于当前情况。
94.最后，系统100包括输出部件150，该输出部件被配置为基于由分析部件135确定的受试者特定的临床信息的子集来定义用户界面部件和用户界面元素中的至少一项。例如，输出部件150提供在指定技术平台上呈现的基于网格的布局中的ui部件和元素的集成规范。这样，输出部件被配置为输出由分析部件135确定的临床信息的表示。
95.如上详细描述，ui元素包括特定临床信息的(例如，视觉或文本的)单一表示。例如，图6a中的一组肺的图形表示是ui元素的示例。
96.另一方面，ui部件包括从较大数据集中过滤得到的受试者特定的临床信息的相关子集的集成表示。这可由多个ui元素或其他ui部件构建。在图6a的中心部分，表示受试者的临床信息的支气管和伴随的字母数字字符的组合表示是ui部件的示例。
97.现在参考图2a-2c，更详细地描绘了图1的分析部件135(即ui引擎)。
98.分析部件135驱动数据权重和ui部件、校准和解析它们，并且调整它们的视觉外观和行为，以绘制灵活和动态的ui。总之，引擎通过以下方式进行这一点：
99.标识哪些数据类型是重要的；
100.标识哪些ui部件是感兴趣的；
101.查找每个ui部件中存在的数据类型；
102.计算每个ui部件的重要性；以及
103.取决于ui部件之间的相对重要性来应用视觉性质。
104.分析部件135使用下面描述并在图2a-2c中示出的各种部件/实体来完成这一点。为了帮助理解和描述这些，下面使用伪代码来描述示例性算法。此类算法的范围可从简单的线性数学公式(例如，以下公式中使用的算子用作示例)到更复杂的统计模型或机器学习具体实施。
105.分析部件中的部件/实体包括：
106.数据权重驱动器201
107.这些基于临床参考信息110、受试者特定的临床信息120和临床上下文信息130来指定哪些(类型的)数据(例如，医学成像的结果、并存病等)是相关的。取决于系统配置，激活多个数据权重驱动器，每个驱动器对信息的不同子集做出反应。数据权重驱动器201产生每个数据类型的权重的列表。权重被表示为数值。每个数据类型具有影响不同视觉性质的多个权重(即权重的列表或矩阵)是可能的。例如，权重x是关于视觉尺寸，权重y是关于视觉数据密度。从数据输入到每个数据类型的权重的转化是自由格式规则库。人们可选择简单的如果这样则进行的规则引擎，或者采用更复杂的统计模型或机器学习具体实施。
108.数据权重驱动器的示例包括：
109.(a)“临床路径数据权重驱动器”110.这是使用临床指南或路径作为载体的情况(基于知识的决策支持)。这些例如使用决策树来描述对于特定疾病类型在护理路径的不同时刻的推荐步骤。对于进行特定临床决策而言重要的所需数据元素是(在一定程度上)可预测的，这可以驱动某些数据类型的权重。所有组合的权重创建了数据相关性的唯一简档。决策树中的每个节点都有一组“变异器”(例如，简单的数学变换)，其指定当该节点处于活动状态时，如何调整做出对应于该节点的临床决策所需的每个数据类型的权重。例如，在x节点处来自ct的诊断证据的相关性增加1并且乘以2。在后续决策节点y中，诊断已经建立并且相关性减少：它仅作为上下文信息相关并且权重仅增加1。
111.用于做出具体决策的所需数据也可以被预期地使用，即根据指南/路径展望哪些是选项以及关于这些选项做出决策的所需数据是什么(以及其优点和缺点)。
112.通过使用路径知识模型来定义纵观概况中的数据的相关性，启发式算法可用于确定路径驱动器中的初始权重。
113.从这个角度看，决策点通过沿着路径的流来连接。路径有多个决策点，每个决策点具有有限数量的局部数据变量作为直接输入。此外，可能有用作决策点的间接输入的变量；例如，它们可能有影响，但不作为该特定决策点的推荐测试而被列在护理路径模型中。
114.公式定义：
115.启发式算法根据数据针对感兴趣的决策点的相关性向数据分配权重。这些权重有助于下面描述的“临床路径数据权重驱动器”的最终计算公式。它遵循的原则是：在特定的决策点，所有权重加起来应该为1。然而，不同数据的加权方式可在不同决策点上变化。
116.在所提出的定义中，护理路径模型有数量为d的决策点。在特定决策点处，可能存在总数nv个输入变量(包括直接输入变量和间接输入变量)，例如路径模型所描述的那样。
117.直接输入数据被定义为局部变量(lv1，lv2，
…
，lvn)，其中局部变量的总数为n
lv
。
118.间接输入数据的两个示例可以是：
119.相对于这些变量的先前值显著变化的变量(即变化变量；cv1，cv2，...，cv
ncv
)，其中变化变量总数为n
cv
。
120.相对于这些变量的先前值不一致的变量(即不一致变量；dv1，dv2，...，dv
ndv
)，其中不一致变量的数量为n
dv
。
121.剩余变量被定义为rv，其中剩余变量的数量为n
rv
，其中：
122.nv＝n
lv
+n
cv
+n
dv
+n
rv
[0123][0124]
lv∪cv∪dv∪rv＝v
[0125]
人们可为间接输入变量分配分数f以表示这些数据对当前决策点的影响。
[0126]
决策点的数据输入：
[0127]
当前决策点的直接数据输入：(1-f)/n
lv
[0128]
当前决策点的间接数据输入：f/(n
cv
+n
dv
)
[0129]
需注意，nv和n
lv
可直接从路径模型中计算，其中n
cv
和n
dv
只能在运行时期间确定，特定于受试者。
[0130]
然后，在其他数据权重驱动器和解析器中进一步考虑这些权重。
[0131]
(b)“会议数据权重驱动器”[0132]
这是讨论阶段确定哪些数据更相关的情况。例如，在多学科肿瘤委员会会议中的受试者介绍期间，重点在于与受试者的病史和高级护理路径有关的信息。关于诊断证据和处理的适合性的详细信息只在讨论的后期阶段相关。因此相应地调整权重。
[0133]
(c)“角色数据权重驱动器”[0134]
这是用户的角色/医学专业决定哪些数据更相关的情况。例如，与放射学相关的数据在处于“放射科医师角色”时受到更多的关注，例如，在从角色角度而不是多学科角度进行病例准备或病例审查时。
[0135]
(d)“受试者数据权重驱动器”[0136]
这基于受试者的医疗文件的内容来调整权重。例如，如果ct扫描已经过时，则它不应完全影响决策做出过程。
[0137]
数据类型ti的总数为m，并且所有数据类型的集合为与每个数据类型相关联的是影响系统的一组权重(例如，一个权重可影响分配给数据类型的视觉尺寸，另一个权重可改变其视觉重点)。总共存在n个不同权重类型，并且数据类型t的值收集在向量w
t
中
[0138][0139]
其中是数据类型t的权重类型i的权重的值。数据类型可能不使用所有权重类型：它不使用的权重类型可在向量w
t
中设置为0。
[0140]
所有数据类型的权重向量收集在矩阵中：
[0141][0142]
每个数据权重驱动器d由对w的变换组成，从而产生具有每个数据类型的数字权重的矩阵
[0143]
wd＝fd(w)
[0144]
表示wd的第i行和第j列中的元素，并且它是数据权重驱动器d中的数据类型tj的权重类型i的权重值。
[0145]
在系统中有l个数据权重驱动器di处于活动状态。
[0146]
数据权重解析器(202)
[0147]
数据权重解析器r将每个数据权重驱动器201的所有独立列表组合成一个权重矩阵从该矩阵中知道每个数据类型与其他数据类型的相关性，并且这可被认为是标识受试者特定的临床信息的子集。
[0148]
变换确定组合的所有数据权重驱动器的每个数据类型的权重：
[0149]
wr＝fr(d1,d2,
…
,d
l
)
[0150]
表示wr的第i行和第j列中的元素，并且它是数据权重解析器r中的数据类型tj的权重类型i的权重值。
[0151]
需注意到针对确切变换fr有不同选择。人们可想到一种简单机制，其将根据数据类型和权重类型分组的所有权重相加或计算其平均值。算子可通过系统配置或经由学习系统来选择。此外，来自数据权重驱动器201的每个数据类型的权重可与常数相乘：“数据权重驱动器乘法器”(m)。这允许不同的数据权重驱动器201之间的上下文校准。因此，来自数据权重解析器202的输出可被认为是标识受试者特定的临床信息的相关子集(考虑临床参考信息、受试者特定的临床信息和临床上下文信息)。
[0152]
部件驱动器(203)
[0153]
这指定了ui部件c的组成内容。数据权重驱动器201只知道哪些数据类型具有增加的相关性，但不能够确定它们如何确切地相互关联。例如，在多学科肿瘤委员会会议期间，数据的过去、现在和未来的流动应该按照已经建立的用户心智模型从左到右表示，以获得更好的易懂性。在每个部件驱动器中定义了部件的有序列表。
[0154]
由部件驱动器203解决的另一个问题是特定数据类型可存在于多个ui部件中的事实。简单地说明哪些数据类型是相关的将会导致所有这些ui部件的相关性增加。部件驱动器为ui提供上下文并且产生一组适用的有序ui部件。
[0155]
部件驱动器203的示例是基于会议在讨论中的情况来选择ui部件的“会议部件驱动器”。例如，结论性阶段将导致附加部件，其中可以标记处理计划中的下一步骤。
[0156]
存在p个ui部件ci，并且所有ui部件的集合为部件驱动器i的ui部件可被描述为的有序子集oi：
[0157][0158]
其中ni≤p是i的部件的数量并且针对j＝1,...,ni。
[0159]
在系统中有q个部件驱动器oi处于活动状态。
[0160]
部件解析器(204)
[0161]
在这里，所有的部件驱动器203被组合以创建适于当前上下文的ui部件的有序列表o(例如，当需要查看随时间的进展时，从旧数据到新数据)。总共q个部件驱动器通过算法fo来组合：
[0162]
o＝fo(o1,o2,
…
,oq)
[0163]
函数fo确定所有的唯一部件条目并且根据当前上下文对它们进行排序。这是系统的业务逻辑的一部分。
[0164]
部件权重解析器(205)
[0165]
根据ui库140中的规范知道哪些数据类型存在于哪些ui部件中。还从数据权重解析器202知道每个数据类型具有什么权重。通过组合每个ui部件的数据类型和每个数据类型的权重，可以创建描述每个ui部件的权重的合成物。这将产生定义每个ui部件的相关性的度量。该解析器还能够看到相关数据类型和相关ui部件之间的不一致。例如：数据类型根据其权重为非常相关的，但没有选择ui部件来显示该数据。解析器能够“调解”并且决定呈现包含此关键数据类型的附加ui部件。因此，可根据嵌入数据的性质(例如，不同类型的权重)来配置ui部件的性质。例如，基于与相关数据类型相关联的部件权重值，可从一组可用的用户界面部件和用户界面元素中标识(和/或定义)用户界面部件或用户界面元素。
[0166]
首先，针对每个ui部件c，获取有序规范列表其包含部件中的所有数据类型t。
[0167]
现在已知三个重要元素：(1)所有数据类型及其权重，(2)以特定顺序的所有部件和(3)每个部件中存在的数据类型。部件ci的权重类型j的权重由映射确定：
[0168][0169]
其中ki是有序列表sc中的位置i处的数据类型(其因此是)的索引并且
[0170]
外观驱动器(206)
[0171]
这些将来自部件权重解析器的每个部件(c)的抽象数值权重(w)转化为屏幕的视觉性质。例如，临床路径主要影响“列权重”，其定义一个ui部件相对于其他ui部件获得多少列(在布局网格中)。另一种类型的权重是“深度权重”，在此，行为通过确定哪种数据类型具有最高的“深度权重”并且缓慢地放大和向前移动内容来遮挡其他数据并改变重点以表达自身。当ui部件附加了在视觉上一起播放的多个权重时，出现紧急行为。每个外观驱动器可包含影响特定视觉性质的功能以使其正常工作。
[0172]
外观解析器(207)
[0173]
检查ui部件上存在哪些视觉性质，并且计算每个ui部件的合并视觉性质。当多个外观驱动器影响相同视觉性质时，根据作为系统配置的一部分的有序列表选择具有最高优先级的驱动器。
[0174]
用户界面绘制器(208)
[0175]
这将所有ui部件与新视觉性质组合并且最终绘制用户界面。
[0176]
当用户交互调整数据输入、数据权重驱动器、部件驱动器或外观驱动器的性质时，用户界面引擎的该循环自身重复。改变从每个数据类型的权重一直传播到每个ui部件的权重、到视觉性质、最后到用户界面。
[0177]
为了利用更多上下文提供分析部件135的上述描述，现在将在下面描述基于受试者用例的简单示例，其中受试者具有可疑癌症。在图3a-3c中示出了与该示例性用例相关联的示例性所得(和极大简化的)ui。这些计算、权重对ui部件施加的影响以及简化的图形表示被提供以用作分析部件135如何运行的示例。
[0178]
处理前阶段：
[0179]
在此示例中，受试者处于护理路径的主要诊断和分期阶段。已经执行诊断测试，但明确的诊断和阶段尚未建立。在多学科小组会议中讨论受试者。
[0180]
根据受试者的临床信息，系统标识受试者在护理路径或决策树中的位置(例如，基于执行的测试、诊断和阶段尚未在受试者记录中报告的事实、或受试者被选择用于第一多学科肿瘤委员会会议的事实)。可从健康护理信息系统查询测试结果。可在会议之前使用自然语言处理以从纯文本报告中提取测试结果。
[0181]
基于临床指南，在该时刻需要做出的决策是：(i)诊断和分期是什么？和(ii)所推荐的处理是什么？(例如，受试者是可手术的还是不可手术的？)。
[0182]
诊断和分期决策的相关信息是：关于已经执行了哪些测试的概况；以及这些测试的结果的概述。
[0183]
处理选择的相关信息是：受试者是可手术的还是不可手术的，例如基于整体健康状况、器官功能、并存病；以及有哪些另选处理方法？
[0184]
在选择处理之前，临床医生首先需要决定明确的诊断和分期。ui应通过正确的ui部件集以全面方式来表示该信息，在多学科团队会议中可很容易地看到该信息。系统知道它正在以该设置被使用，例如因为特定的观看模式被选择。如果数据是结构化/编码的，可使用图形表示来使信息变得能够看到；例如具有具体位置的指示的器官的图形。数据模型用于描述信息的结构和层次结构。数据用snomed ct、loinc和icd-10等来编码。
[0185]
对于患有例如可疑肺癌的该受试者，部件驱动器203定义了ui的诊断和分期部件
的部分是从左到右示出的肺和区域淋巴结站(以及远处器官，如果存在远处转移的风险的话)的图形表示。它还可确定结构化测试结果可通过测试结果的示意性表示来示出。
[0186]
对于多学科会议，优选的是，ui部件按照逻辑从过去到现在再到未来进行排序。这意味着分别从ui部件受试者历史开始，然后是分期，并且最后是健康状况测试，以供未来的处理选择。受试者历史示例和健康状况示例分别在图3a和图3c中示出，但在文本中没有进一步详细说明。分期示例在图3b中示出。
[0187]
图3a的顶部图示出了ui的示意性表示，其示出了数据权重对屏幕占用的影响。图3a的底部图示出了ui的简化图形表示，其根据示意性表示中的相对权重生成。在会议的受试者介绍阶段中，受试者历史数据和分期数据的相对权重为10和6。因此，ui被绘制为使得并存病呈现为比分期信息更突出。从部件库中进行选择，并存病在具有对应尺寸和外观的扩展视图中示出。使用具有异常的器官(例如，在该情况下为肺)的图形表示以总结性视图示出分期信息。
[0188]
图3b的顶部图示出了ui的示意性表示，其示出了数据权重对屏幕占用的影响。图3b的底部图示出了ui的简化图形表示，其根据示意性表示中的相对权重生成。在会议的诊断和分期阶段中，受试者历史的相关性低于有关诊断测试的分期的信息。因此，ui被绘制为呈现比分期信息更突出的并存病，其中受试者历史数据和分期数据的相对权重分别为4和12。从部件库中进行选择，并存病在总结性视图中示出(例如，只有图标)。分期信息在扩展视图中示出，其示出了肺部(左)和区域淋巴结站(右)的图形表示。它使用圆形图表来表示诊断结果，其中每个部分表示来自诊断模态的结果。颜色可用于指示对恶性肿瘤的怀疑程度。对于区域淋巴结站“x”，检测结果不一致。因此，与其他淋巴结站相比，它具有增加的细节权重，从而产生更突出的图形表示。
[0189]
图3c的顶部图示出了ui的示意性表示，其示出了数据权重对屏幕占用的影响。图3c的底部图示出了ui的简化图形表示，其根据示意性表示中的相对权重生成。在会议的处理选择阶段中，受试者历史和分期信息的相关性低于受试者健康状况。因此，ui被绘制为呈现比并存病和分期信息更突出的健康状况，其中受试者历史数据、分期数据和健康状况数据的相对权重分别为4、4和10。从部件库中进行选择，并存病在总结性视图中示出(例如，只有图标)。在总结性视图中还显示了分期信息；仅是诊断的摘要。在扩展视图中示出了受试者健康状况。
[0190]
在ui部件内存在的数据类型根据由数据权重驱动器201提供的权重而出现、增长或具有其他视觉外观。这意味着，如果数据权重驱动器201证明以特定方式定位的特定ui元素不相关，则它们将根本不会出现，并且由此为其他ui元素释放了空间。
[0191]
在该示例中，有一个部件驱动器203处于活动状态。因此，ui部件的排序保持与多学科会议部件驱动器中指定的排序相同。
[0192]
首先继续使用数据权重驱动器201，会议的当前阶段是诊断和分期阶段，其中重要的是知道诊断证据的强度。受试者的病史已经在会议的介绍阶段进行解释。因此，会议数据权重驱动器201向并存病数据类型给予为4的有限列权重(参见图3b)。
[0193]
临床路径模型(基于知识)描述了用于进行该决策的一组推荐/所需的信息，例如，基于已经在ct报告中记录的假设分期，处理前评估应包括测试a、b、c和d。临床路径数据权重驱动器向测试a、b、c、d的结果给予为2的列权重。
[0194]
如果缺少测试，或者这些测试的结果彼此不一致(例如，在决策树的一个分支中)，则其可在ui中突出显示以减小欠分期或过度分期的风险。
[0195]
从受试者特定的数据和路径模型可推理出对指南的遵守情况。经由api在ui环境和路径模型之间建立连接。在该示例中，测试b和d的结果与身体位置x(例如，区域淋巴结站)处的发现不一致(例如，测试b指示高度怀疑恶性肿瘤，而测试d指示不怀疑)。该发现需要在多学科会议期间给予附加关注。因此，受试者数据权重驱动器201向测试b和d给予为1的列权重。对测试b和d内存在的身体位置x的数据类型设置为1的附加细节权重(参见图3b)。
[0196]
受试者数据权重驱动器201被配置为与其他数据权重驱动器相比具有更大的影响，因为受试者特定数据对于该系统配置具有更大重要性。其权重乘以2。
[0197]
数据权重解析器202将来自不同数据权重驱动器201向量的权重合并为每个数据类型的一个向量，并且考虑它们的乘数：
[0198]
并存病：列权重＝4
[0199]
测试a：列权重＝2
[0200]
测试b：列权重＝2+1*2＝4
[0201]
测试c：列权重＝2
[0202]
测试d：列权重＝2+1*2＝4
[0203]
身体位置x：细节权重＝1*2＝2
[0204]
作为中间步骤，部件权重解析器205收集被请求绘制的每个ui部件的数据类型。为了保持即将到来的列表的简单性，将主要提到受试者历史和分期ui部件。受试者历史ui部件包含并存病和先前癌症数据类型。分期部件包含测试a、b、c和d的结果。
[0205]
然后，部件权重解析器205基于每个ui部件所包含的数据类型(来自步骤11)和每个数据类型的权重(来自步骤10)来计算所有权重。例如，ui部件现在将具有以下权重(需注意，此列表不包括这些顶级ui部件中存在的ui部件)：
[0206]
受试者历史：列权重＝4
[0207]
分期：列权重＝2+4+2+4＝12；细节权重＝2
[0208]
然后使用合并的权重来确定每个部件的视觉外观。从对列权重作出反应的列外观驱动器206开始。通常还有若干默认的ui部件，其可见且具有固定尺寸，诸如通用受试者信息、页脚等。列(24列网格系统中的列)通过总列权重4+12＝16进行适当的划分：
[0209]
受试者历史：24/16*4＝6个列
[0210]
分期：24/16*12＝18个列
[0211]
细节外观驱动器206对细节权重做出反应。针对测试b和d的身体位置x得到增加的缩放级别，以示出视觉解剖学表示中的特定细节。
[0212]
所有外观驱动器206的视觉性质被合并为一者。使用描述哪个外观驱动器更重要的优先级规范来解决冲突的视觉性质。
[0213]
最后，将合并的视觉性质应用于有序ui部件并且其被绘制为用户界面输出：
[0214]
受试者历史以6列示出。
[0215]
肺部、淋巴结和转移的图形表示以及用于分期的疾病程度的可视化占据18列。
[0216]
示出诊断结果的圆形饼图，其中测试a-d由于其列权重而被表示。
[0217]
由于它们更高的细节权重，针对身体位置x(局部淋巴结站)的测试b和d之间的不一致被突出显示。
[0218]
在诊断和分期已经被建立后，多学科讨论过渡到处理选择。此时刻可根据与界面的特定用户交互而对于系统是已知的。
[0219]
现在，只需要诊断结果的总结版本(例如，只需要肿瘤分期、细胞类型)；会议数据权重驱动器201向诊断和分期数据分配较少权重。数据权重驱动器201将更大权重分配给与受试者健康状况相关的数据元素，诸如并存病和器官功能。部件驱动器203定义诊断和分期部件的总结版本和用于示出处理适合性(treatment fitness)的面板。
[0220]
再次为不同ui部件收集数据类型，这些数据类型取决于其内容获得特定权重。在诊断和分期的上下文中，ui现在聚焦于处理和处理选项的适合性。
[0221]
处理被选择并且受试者在他/她的护理路径中进一步过渡。
[0222]
随着受试者在他/她的护理过程中进一步进展，后续的护理时期将随之而来。
[0223]
处理后阶段：
[0224]
受试者接受处理(例如，手术)并且在术后mdt会议中被讨论。流程再次从图2a的顶部开始。
[0225]
基于临床指南，在该时刻需要做出的决策是：i)手术中的发现是什么(例如，手术后的分期是什么，处理优势(margin)是什么)和ii)推荐后续处理是什么(例如，辅助治疗)
[0226]
系统基于以下项知道现在信息的重要性和层次结构已经改变：
[0227]
先验信息是决策树中的较早分支的一部分；
[0228]
已经有了处理前mdt会议；以及
[0229]
在健康信息系统中已经报告了明确的诊断和分期，并且系统包含例如预定的预约或指示例如已经执行手术的报告。
[0230]
因此，现在聚焦于术后发现。处理前评价信息成为上下文信息。
[0231]
术后发现应是更详细的版本，重点是术后分期、切缘、高危因素等。
[0232]
处理前发现的外观应该是总结性版本，只提供上下文并突出显示任何差异。
[0233]
分析部件135通过以下方式来再次对此进行调整：向数据和数据类型分配权重、从库中选择正确的部件及其配置、将所有内容合并以及一起解析以灵活和动态地绘制用户界面，该用户界面包含支持在该特定上下文中针对该特定受试者做出决策的关键信息。
[0234]
此类示例可扩展到护理路径中的每个时刻，其中指南/路径定义决策点、做出决策所需的信息、评估的原则/指南等。护理路径中的(从受试者走过护理路径的路线推理出来的)先前步骤提供了关于上下文信息是什么的信息。因此，可以在指南/护理路径的上下文中突出显示受试者特定的数据。
[0235]
分支内缺失或不一致的信息可被赋予特定的权重、标志或关联，从而影响用户界面。
[0236]
为了纵向查看，在先前评估的上文中，系统示出了最新状态。纵向缺失或不一致的信息可再次被赋予特定的权重、标志或关联，从而影响用户界面。
[0237]
总之，不同用例(例如，不同患者)可具有不同疾病类型或疾病组合，对此其遵循特定护理路径。沿着和这些不同的护理路径，可能发生各种决策时刻，为此需要专门的决策支持。ui需要在该时刻有效地传达该特定情况的决策支持输出，并且最佳ui可依赖于这个(以
及许多其他(可变)因素)。所提出的是，这些信息的组合可自动驱动ui配置，使得可最佳地递送决策支持。所提出的系统可被配置为自动生成这些个性化ui，其包含专用于该特定受试者和上下文的特征。
[0238]
通过举例说明，图4是概念的示意图，即取决于用例和上下文(例如，护理路径中的阶段)，所提出的系统可提供不同的ui。例如，对于受试者病例a，如果存在/诊断出疾病或状况“a”，则采用左手路径。该左手路径有三个决策点，a1、a2和a3。对于第一决策a1，采用三个数据权重驱动器“1、2、3”，并且其导致第一ui部件/元素配置“ui a”。对于第二决策a2，采用三个相应的数据权重驱动器“4、5、6”，并且其导致第二ui部件/元素配置“ui b”。对于第三决策a3，采用三个相应数据权重驱动器“1、3、6”，并且其导致第三ui部件/元素配置“ui c”。
[0239]
同样，对于受试者病例b，如果存在/诊断出疾病或状况“b”，则采用左手路径。该左手路径有三个决策点，b1、b2和b3。对于第一决策b1，采用三个数据权重驱动器“1、2、3”，并且其导致第四ui部件/元素配置“ui d”。对于第二决策b2，采用三个相应的数据权重驱动器“4、5、6”，并且其导致第五ui部件/元素配置“ui e”。对于第三决策b3，采用三个相应数据权重驱动器“1、3、6”，并且其导致第六ui部件/元素配置“ui f”。
[0240]
为了进一步说明，在图5中基于临床路径的一个示例从概念上说明了这一点。
[0241]
图5是护理路径驱动ui的概念图示。ui取决于用例和上下文(例如，护理路径中的阶段)。三个ui仪表板500、510、520表示护理路径中的不同时刻的ui。图5的图示的下半部分示出了护理路径，其中编号的项目符号530、540、550表示决策做出的不同时刻，以及根据在该点输入以用于决策做出的指南的图案填充条推荐的临床测试。
[0242]
在第一时刻530，来自第一组测试的信息驱动ui 500。
[0243]
在第二时刻540，来自第二组测试的信息对于做出下一决策具有最高重要性，但来自第一组测试的信息仍然是重要的上下文信息。其相应的相对的相关性驱动ui 510。
[0244]
在时间的第三时刻550，来自第三组测试的信息对决策的做出具有最高的重要性，并且在ui中最突出。来自第二组测试的信息是重要的上下文信息，而来自第一组测试的信息不是。来自第三和第二组测试的信息的相应的相对的重要性驱动ui，并且ui不再受来自第一组测试的信息的影响。
[0245]
作为进一步的说明，可如下总结所提出的实施例的两个主要步骤：步骤1：-示例1：
[0246]
1)在描述广泛的潜在相关患者数据集的临床数据模型中捕获患者数据。患者数据权重驱动器将权重分配给所有患者数据以便指示各种患者数据的相应相关性。
[0247]
2)在描述潜在相关数据元素集的临床路径模型中捕获临床路径状况。临床路径数据权重驱动器将权重分配给由临床路径状况描述的数据元素。
[0248]
3)基于所标识的患者在临床路径中的位置，将在临床数据模型中捕获的患者数据与临床路径模型匹配。这定义了受试者特定信息的相关子集，该子集基于将患者简档与路径状况匹配，可自动适应患者在路径中的位置。
[0249]
步骤1：-示例2：
[0250]
1)在描述广泛的潜在相关患者数据集的临床数据模型中捕获患者数据。患者数据权重驱动器将权重分配给所有患者数据以便指示各种患者数据的相应相关性。
[0251]
2)会议权重驱动器向mdt会议诊断阶段中相关的所有数据分配权重。这定义受试者特定信息的子集，该子集可从更广泛的相关患者数据集中提取。
[0252]
步骤2：
[0253]
数据权重解析器以由受试者数据权重驱动器、临床路径数据权重驱动器和会议权重驱动器分配给受试者特定信息子集的校准权重来组合上述步骤1的结果。
[0254]
现在参考图6a-6c，描绘了根据所提出的实施例生成的示例性ui的第一到第三实例。更具体地说，图6a-6c是针对第一患者情况的原型ui的截图(即，所显示的ui的捕获图像)。ui包括仪表板，该仪表板被配置为提供在患者护理路径中的相应时间/时刻的患者概况。因此，仪表板适于在患者护理路径中的不同时刻提供患者概况。
[0255]
在护理路径中的每个时间/时刻，患者情况在多学科小组会议(mdt会议)中进行讨论。在此类会议中，ui经由三个选项卡提供信息，即介绍(introduction)选项卡、诊断(diagnosis)选项卡和处理(treatment)选项卡。图6a-6c描绘了三个各自mdt会议上的ui，其中选择诊断选项卡(使得显示用于患者诊断的信息)，使得介绍和处理选项卡保持可选择，但没有完全显示/展开。
[0256]
具体地说，图6a是与患者护理路径中的“主要诊断和处理选择”阶段相关的第一mdt会议中的ui的截图。如上所述，在图6a中，选择了ui的诊断选项卡。
[0257]
图6b是与患者护理路径中的“术后评估”阶段相关的第二mdt会议中的ui的截图。同样，如上所述，在图6b中，选择了ui的诊断选项卡。
[0258]
图6c是与患者护理路径中的“复发”阶段相关的第三mdt会议中的ui的截图。同样，如上所述，在图6c中，选择了ui的诊断选项卡。
[0259]
从图6a-6c中的每一者中的ui的比较中，将理解的是，ui由护理路径中的点驱动。例如，在主要诊断阶段(图6a)中的所显示的用户界面部件信息与在外科评估阶段(图6b)中的所显示的信息不同。换句话说，所显示的用户界面部件信息由患者的时间线驱动，即患者信息的时间线可被认为是将用于确定受试者特定的临床信息的子集的受试者特定的临床信息。受试者特定的临床信息的所述子集将用于确定用户界面元素。时间线也显示在仪表板中。这反映了数据权重驱动器的影响；上下文相关信息由患者数据和临床路径数据驱动(即，患者简档与护理路径中的位置匹配)。
[0260]
还注意到，ui是由mdt会议期间的讨论驱动的，其中此类讨论可涵盖介绍阶段、诊断阶段和处理选择。例如，在介绍选项卡、诊断选项卡和处理选择选项卡之间，所显示的信息不同。例如，与在诊断屏幕中相比，在介绍屏幕中向并存病给予更大权重。换句话说，讨论的信息可被认为是临床上下文信息，该信息将用于确定受试者特定的临床信息的子集。受试者特定的临床信息的所述子集可用于确定用户界面元素。
[0261]
实施例可被配置为使得能够取决于临床上下文和/或受试者特定信息来激活专用ui模块(例如，用于诊断评估、用于外科评估、用于处理选择等)。例如，这可使得专用预测模型的结果能够可视化，以预测对特定处理(例如，免疫治疗)的响应以及预测所基于的各种诊断信息来源(其描述免疫系统的状态)，从而预测响应。
[0262]
从上面的描述，将理解的是，提出了为个性化决策支持生成灵活和自适应ui的系统。此类系统可自动生成个性化用户界面，其包含专用于特定受试者和上下文的ui部件和/或元素。
[0263]
实施例可用于在临床工作流和上下文(例如，用户角色)中以正确的格式和定时/层次结构提供正确的数据，并且这可使得医疗专业人员能够基于被优化以显示该特定受试
者的相关数据的ui来讨论受试者情况。
[0264]
实施例还可利用ui引擎来自动生成(而不是手工制作)ui，该ui被优化以使用一组ui部件在给定上下文(例如，用户、物理空间)中显示针对手头给定问题的受试者特定信息的上述相关子集。ui引擎选择最佳ui部件并将它们组成针对特定受试者、受众、临床问题、角色等的专用ui。
[0265]
图7示出了其中可采用实施例的一个或多个部分的计算机800的示例。上面讨论的各种操作可利用计算机800的能力。例如，用于提供受试者特定的用户界面的系统的一个或多个部分可并入本文讨论的任何元素、模块、应用程序和/或部件中。
[0266]
计算机800包括但不限于pc、工作站、膝上型计算机、pda、掌上设备、服务器、存储装置等。通常，就硬件架构而言，计算机800可包括经由本地接口(未示出)通信耦接的一个或多个处理器810、存储器820和一个或多个i/o设备870。
[0267]
处理器810是用于执行可存储在存储器820中的软件的硬件设备。处理器810实际上可以是与计算机800相关联的若干处理器中的任何定制或商业可购的处理器、中央处理单元(cpu)、数字信号处理器(dsp)或辅助处理器，并且处理器810可以是基于半导体的微处理器(以微芯片的形式)或微处理器。
[0268]
存储器820可包括以下的任何一者或其组合：易失性存储器元件(例如，随机存取存储器(ram)，诸如动态随机存取存储器(dram)、静态随机存取存储器(sram)等)和非易失性存储器元件(例如，rom、可擦除可编程只读存储器(eprom)、电子可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁带、光盘只读存储器(cd-rom)、盘、软磁盘、盒、盒式磁带等)。
[0269]
存储器820中的软件可包括一个或多个单独程序，每个程序包括用于实现逻辑功能的可执行指令的有序列表。根据示例性实施例，存储器820中的软件包括合适的操作系统(o/s)850、编译器840、源代码830和一个或多个应用程序860。如图所示，应用程序860包括用于实现示例性实施例的特征和操作的多个功能部件。
[0270]
操作系统850控制其他计算机程序的执行，并且提供调度、输入输出控制、文件和数据管理、存储器管理以及通信控制和相关服务。
[0271]
应用程序860可以是源程序、可执行程序(目标代码)、脚本、或包括待执行的指令集的任何其他实体。当为源程序时，则通常经由编译器(诸如编译器840)、汇编器、解释器(其可包括也可不包括在存储器820内)等转化该程序以便与o/s 850相关地正确操作。
[0272]
i/o设备870可包括输入设备，例如但不限于鼠标、键盘、扫描器、麦克风、相机等。最后，i/o设备870还可包括传送输入和输出两者的设备，例如但不限于nic或调制器/解调器(用于访问远程设备、其他文件、设备、系统或网络)、射频(rf)或其他收发器、电话接口、桥接器、路由器等。
[0273]
如果计算机800是pc、工作站、智能设备等，则存储器820中的软件还可包括基本输入输出系统(bios)(为简单起见省略)。
[0274]
当计算机800在操作中时，处理器810被配置为执行存储在存储器820中的软件，将数据传送到存储器820和从存储器传送数据，以及根据该软件通常控制计算机800的操作。
[0275]
当应用程序860以软件实现时，应当注意，应用程序860可存储在几乎任何计算机可读介质上以用于由任何计算机相关系统或方法使用或与任何计算机相关系统或方法结
合使用。在本文的上下文中，计算机可读介质可以是电子的、磁性的、光学的或其他物理的设备、或可包含或存储用于由计算机相关系统或方法使用的或与计算机相关系统或方法相关的计算机程序的装置。
[0276]
应用程序860可体现在用于由指令执行系统、装置或设备使用或与指令执行系统、装置或设备相关联的任何计算机可读介质中，诸如基于计算机的系统、包含处理器的系统、或可从指令执行系统、装置或设备获取指令并执行指令的其他系统。在本文档的上下文中，“计算机可读介质”可以是任何可存储、传送、传播或传输用于由指令执行系统、装置或设备使用或与之相关联的程序的装置。计算机可读介质可以是，例如但不限于，电子、磁、光、电磁、红外或半导体系统、装置、设备或传播介质。
[0277]
本发明可以是系统、方法和/或计算机程序产品。计算机程序产品可包括在其上具有计算机可读程序指令的计算机可读存储介质(或多个介质)以用于致使处理器执行本发明的各个方面。
[0278]
计算机可读存储介质可以是有形的设备，其可保留和存储用于由指令执行设备使用的指令。计算机可读存储介质可以是，例如但不限于，电子存储器设备、磁存储器设备、光存储器设备、电磁存储器设备、半导体存储器设备，或前述的任何适当组合。
[0279]
本文描述的计算机可读程序指令可从计算机可读存储介质下载到相应的计算/处理设备，或经由网络(例如，因特网、局域网、广域网和/或无线网络)下载到外部计算机或外部存储器设备。网络可包括铜传输电缆、光传输光纤、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。
[0280]
用于执行本发明的操作的计算机可读程序指令可以是汇编程序指令、指令集体系结构(isa)指令、机器指令、机器相关指令、微码、固件指令、状态设置数据，或者以一种或多种编程语言的任何组合编写的源代码或目标代码，该编程语言包括诸如smalltalk、c++等的面向对象编程语言和诸如“c”编程语言或类似编程语言的常规过程编程语言。计算机可读程序指令可完全在用户计算机上执行，部分在用户计算机上执行，作为独立的软件分组执行，部分在用户计算机上执行，部分在远程计算机上执行，或者完全在远程计算机或服务器上执行。
[0281]
本文参照根据本发明的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图来描述本发明的方面。将理解的是，流程图图示和/或框图的每个框以及流程图图示和/或框图中的框的组合可通过计算机可读程序指令来实现。
[0282]
这些计算机可读程序指令可提供给通用计算机、专用计算机的处理器或其他可编程数据处理装置以产生机器，使得经由计算机的处理器或其他可编程数据处理装置执行的指令创建用于实现流程图和/或框图的一个或多个框中指定的功能/动作的装置。这些计算机可读程序指令还可存储在计算机可读存储介质中，其可指导计算机、可编程数据处理装置和/或其他设备以特定方式运行，使得具有存储在其中的指令的计算机可读存储介质包括制品，该制品包括实现流程图和/或框图的一个或多个框中指定的功能/动作的各个方面的指令。
[0283]
计算机可读程序指令也可加载到计算机、其他可编程数据处理装置或其他设备上，以致使在计算机、其他可编程装置或其他设备上执行一系列操作步骤产生计算机实现的过程，使得在计算机、其他可编程装置或其他设备上执行的指令实现流程图和/或框图的
一个或多个框中指定的功能/动作。
[0284]
描述是出于说明和描述的目的而提出的，并且不旨在是穷尽性的或以所公开的形式限于本发明。许多修改和变化对于本领域的普通技术人员来说是显而易见的。已经选择和描述了实施例以便最好地解释所提出的实施例的原理、实际应用，并且使得本领域的其他普通技术人员能够理解具有各种修改的各种实施例。