CN117441210A - 包括用户域概念的个性化数据图 - Google Patents

Abstract

个性化数据图的用户域概念(UDC)节点可由用户设备生成。该UDC节点可包括定制信息，该定制信息表示健康数据的某个用户定制部分，例如从电子健康记录(EHR)系统获得的数据。该UDC节点可基于定制请求生成，例如来自用户的定制该健康数据的该部分的请求和/或其他方面。该UDC节点可存储节点之间的关系信息，并且可用于改进呈现该健康数据的用户界面的运行。这可至少部分地通过提供该用户界面的用户定制(例如最爱记录、将记录添加到列表、给予记录别名)实现。

Description

包括用户域概念的个性化数据图

相关申请的交叉引用

本申请根据35U.S.C.§119(e)要求于2021年6月6日提交的名称为“PERSONALIZEDDATA GRAPHS INCLUDING USER DOMAIN CONCEPTS”的美国临时申请号63/197,476的优先权，该美国临时申请的内容以引用方式并入本文。

背景技术

近年来，已经取得了允许用户从远程电子健康记录(EHR)系统将健康数据下载到其移动用户设备的进步。例如，用户可使用智能电话来连接到EHR系统的端点并且下载其临床健康记录的副本。智能电话可包括被配置为处理和组织临床健康记录中存在的健康数据的应用程序。

发明内容

一个或多个计算机的系统可被配置为凭借具有安装在系统上的在操作中使得系统执行特定操作或动作的软件、固件、硬件或它们的组合来执行所述动作。一个或多个计算机程序可被配置为凭借包括当由数据处理装置执行时使得该装置执行特定操作或动作的指令来执行所述动作。一个总体方面包括一种计算机实现的方法。该计算机实现的方法包括由用户设备从电子健康记录(EHR)系统接收健康数据。该计算机实现的方法还包括接收与定制该健康数据的一部分相关的定制请求。该计算机实现的方法还包括至少部分地基于该定制请求生成个性化数据图的用户域概念(UDC)节点，该UDC节点包括表示该健康数据的所定制部分的定制信息。该计算机实现的方法还包括至少部分地基于生成该UDC节点更新该UDC节点，从而包括表示该UDC节点与该健康数据的该部分之间的关系的关系信息。该计算机实现的方法还包括在该用户设备处填充用户界面，该用户界面包括该UDC节点的表示。该方面的其他实施方案包括记录在一个或多个计算机存储设备上的对应计算机系统、装置和计算机程序，均被配置为执行所述方法的动作。

一个总体方面包括一种计算机实现的方法。该计算机实现的方法包括由用户设备从电子健康记录(EHR)系统接收健康数据。该计算机实现的方法还包括通过至少确定从该健康数据识别的医学概念与参考本体的参考节点之间的映射生成个性化数据图的概念节点。该计算机实现的方法还包括接收与定制该概念节点的方面相关的定制请求。该计算机实现的方法还包括至少部分地基于该定制请求生成该个性化数据图的用户域概念(UDC)节点，该UDC节点包括表示该概念节点的所定制方面的定制信息。该计算机实现的方法还包括至少部分地基于生成该UDC节点更新该概念节点，从而包括表示该概念节点与该UDC节点之间的关系的关系信息。该计算机实现的方法还包括在该用户设备处填充用户界面，该用户界面包括至少部分基于该UDC节点的表示。该方面的其他实施方案包括记录在一个或多个计算机存储设备上的对应计算机系统、装置和计算机程序，均被配置为执行所述方法的动作。

附图说明

图1示出了根据至少一个示例的示出用于生成个性化数据图的用户域概念节点的示例性过程的框图和流程图。

图2示出了根据至少一个示例的示出用于使得能够与生成个性化数据图的用户域概念节点相关的技术的示例性架构或系统的框图。

图3示出了根据至少一个示例的示出用于在用户设备上存储与个性化数据图的用户域概念节点相关的健康数据的示例性用户配置的图。

图4示出了根据至少一个示例的示出用于生成个性化数据图的用户域概念节点的示例性数据模型的框图。

图5示出了根据至少一个示例的示出用于生成个性化数据图的用户域概念节点的示例性过程的流程图。

图6示出了根据至少一个示例的示出用于生成个性化数据图的用户域概念节点的示例性过程的流程图。

图7示出了根据至少一个示例的示例性架构或环境，该示例性架构或环境被配置为实施本文描述的技术。

具体实施方式

在以下描述中，将描述各种示例。为了解释的目的，阐述了很多具体配置和细节以便提供对示例的彻底理解。但是，对本领域的技术人员也将显而易见的是，一些示例可在没有这些具体细节的情况下被实施。此外，可省略或简化熟知的特征部以防止对本文所述的示例造成混淆。

本公开的示例涉及生成并安全存储与健康数据相关的用户域概念(UDC)的方法、系统、设备和计算机可读介质等。UDC可存储为基于节点的关系存储结构中的节点。因此，在一些示例中，UDC可被称为UDC节点。通常，UDC可为围绕健康概念(例如，从健康数据识别的健康概念)的用户可配置的抽象，或为围绕此类健康概念的抽象。例如，智能电话应用程序可使得用户能够定制已经下载到用户智能电话上的其健康数据的某些方面，并且这些定制可使用UDC来保存。

UDC的使用提供了结构化的方式来存储和保留可定制的可变用户数据，这些可定制的可变用户数据可分别与参考本体的参考概念(因此其可被内容专家更新)和医学记录(除了保健机构之外，其通常是不可变的)两者相关联。因此，UDC提供了用于弥合不可变医学记录数据与参考本体之间的差距的机制，该参考本体可随着更多内容变得可用和相关而周期性更新。该机制提供了改进的用户体验，因为其涉及在其用户设备上定制、理解和有效地查看其健康数据。该改进的体验可至少部分地实现，因为访问某些健康数据可能需要更少的选择、点进等。例如，“固定的”或“最爱的”药物(如由UDC启用)可在应用程序的用户界面的主屏幕(或登录页面)上对用户可用，而不是用户必须在应用程序内的多个不同的可能位置处进行搜索。

UDC的使用可实现用户定制的改进的持久性，即使当定制所基于的健康数据和/或定制所基于的参考本体随时间改变时。UDC还可以当前不可用的方式跨与用户的相同用户配置文件相关联的多个设备(例如，用户已经使用相同的用户配置文件登录到智能电话、手表和平板电脑)持久化。UDC可包括一定量的实例用户配置状态(例如，最爱的、别名、存在于给定列表中等)，可连接到底层健康数据(例如，存储在用户设备上的健康数据)，可连接到其他UDC，可连接到底层参考本体(例如，表示关于某些医学概念的知识的知识图)，并且可跨设备同步并从基于云的服务提供方恢复(例如，当用户移动到新的用户设备时)。本质上，UDC创建了稳定点，围绕该稳定点可添加对健康数据的组织和表示的附加增强。

现在转到特定示例，在该示例中，包括特定应用程序的用户设备可从一个或多个电子健康记录(EHR)系统下载健康数据。该健康数据可表示如由已经治疗过用户设备的用户(例如，患者)的一个或多个健康护理专业人员生成的实验室、药物、笔记、诊断、过敏、成像等。由于患者经常在可能或可能不共享EHR系统的不同设施处看到健康护理专业人员，所以用户设备可被配置为处理来自不同EHR系统的健康数据，这些不同EHR系统中的每个EHR系统可稍微不同地存储健康数据(例如，因为其已经不同地采用了某些健康数据标准)。用户设备可从服务提供方下载参考本体，并将该参考本体存储在用户设备上的第一存储位置中。参考本体可包括关于医学概念的知识，并且可用于增强存储在用户设备上的健康数据。一旦已经下载了健康数据，用户设备就可处理健康数据(例如，下载、索引、组织等)并将健康数据存储在用户设备的第二存储位置中。处理健康数据的一部分可包括生成表示具体健康数据的个性化数据图。生成该数据图可包括使用编码技术识别健康数据中存在的医学概念，基于概念生成个性化数据图的节点，增强现有节点，和/或基于医学概念与知识图之间的关联创建新节点。用户还可利用该应用程序来查看如由个性化数据图表示的健康数据，并生成UDC来表示健康数据的定制。例如，该应用程序可用于将某个健康记录标记为快速访问的“最爱”(例如，实验室结果)，以将记录添加到列表(例如，所有有效药物的列表)，给予记录别名(例如，给予“奥美拉唑”的记录别名“胃灼热药物”)，以及执行如本文所描述的其他定制。UDC可被生成为个性化数据图中的节点。节点可存储UDC节点与其他UDC节点以及UDC节点与其他非UDC节点之间的关系。因为UDC节点是个性化数据图的一部分，所以UDC节点可存储在第二存储位置中。

本文所述的示例解决了许多技术问题，并提供了许多技术改进。在一些示例中，这些改进另外改进了其中实现这些技术的系统的各种部件的功能。本文所述的技术提供了健康数据的定制，同时还降低了设备上的存储要求和数据传输所需的带宽。这是因为用户定制数据与参考本体数据是分离的。这允许在相同设备上存储数据的任何数量的用户之间使用单个参考本体。例如，表示不同人的健康数据的多个配置文件(例如，父和子)可共享单个参考本体。因此，与可能为每个配置文件存储参考本体的传统系统不同，因为仅存储、接收和更新(例如，周期性)一个本体，所以实现了存储节省和带宽节省。在收集健康数据并连接到用户设备的其他设备处实现了附加存储节省和带宽节省，诸如智能手表和其他可穿戴设备。因为UDC可被同步和共享到这些没有自己的参考本体的其他设备，所以这些其他设备不需要承担带宽存储成本。

本文所述的技术提供了健康数据的定制，同时还提高了存储器利用率，例如，通过提供更有效的健康数据搜索。例如，UDC可允许比常规系统更有效地搜索和检索医学记录(用户数据)和/或医学概念(参考数据)。这可能是因为此类搜索和检索可由基于用户数据与参考数据之间的关系的谓词来执行(例如，“分组依据”或“是列表的元素”：)。常规系统可能需要用户设备枚举所有医学记录，寻找其相关的医学概念，将二者保存在存储器中，直到已经找到给定概念的所有记录。可以看出，基于谓词的搜索可能不包括相同的存储器密集型要求。

现在转到附图，图1示出了根据至少一个示例的示出用于生成个性化数据图的用户域概念节点的过程100的框图102和流程图。图102包括服务提供方104，该服务提供方是能够执行相对于服务提供方104所述的功能的计算设备(诸如可包括虚拟资源的一个或多个服务器计算机)的任何合适的组合。例如，服务提供方104可包括一个或多个不同的服务器和/或服务，该一个或多个不同的服务器和/或服务专用于处理使用户设备能够与EHR系统连接、维护参考本体或与用户设备共享参考本体的不同方面。

图102还包括用户设备106。用户设备106可为任何合适的设备，诸如智能电话、平板电脑、智能手表、可穿戴设备、膝上型计算机或台式计算机，可被配置为与服务提供方104和电子健康记录(EHR)系统108进行交互。例如，用户设备106可包括一个或多个网络无线电，以使得能够与诸如服务提供方104和EHR系统108等远程系统网络连接。在一些示例中，用户设备106可包括一个或多个应用程序，该一个或多个应用程序可包括定制的算法和其他逻辑，以实现本文所述的技术中的至少一些的性能。用户设备106还可包括用于存储计算机可执行指令(例如，组成应用程序的指令)和诸如本文所描述的其他数据的存储介质。用户设备106可由用户110操作。服务提供方104和/或EHR系统108可维护用户110的配置文件。例如，服务提供方104可维护与服务提供方提供的数字服务(例如，即时消息、云备份、音乐流)相关的用户配置文件，并且EHR系统108可维护与EHR系统108相关联的保健机构提供的医学服务相关的用户配置文件。EHR系统108处的用户配置文件可为患者配置文件，因为用户110可为保健机构的患者。

图102还包括EHR系统108。EHR系统108与至少一个保健机构相关联并且用于管理来自该机构的电子健康记录数据。在一些示例中，单个EHR系统108与多个保健机构相关联并且用于管理来自多个机构的电子健康记录数据。具体地，EHR系统108可存储、组织和/或以其他方式管理由保健机构的医学专业人员生成的健康记录数据。EHR系统108可以包括一个或多个网关，每个网关包括一个或多个端点以实现EHR系统108和其他电子设备之间的多个连接。在一些示例中，用户设备，诸如用户设备106可使用任何合适界面，诸如网关应用程序编程界面(API)或经由包括图形用户界面的患者门户网站来与EHR系统108进行交互。网关API可限定用于EHR系统108与用户设备之间的通信的一组功能调用。

图1、图5和图6示出了根据至少几个示例的示出过程100、500和600的示例性流程图。这些过程及本文所述的任何其他过程被示为逻辑流程图，其每个操作表示一系列能够在硬件、计算机指令或它们的组合中实现的操作。在计算机指令的上下文下，操作可表示存储在一个或多个非暂态计算机可读存储介质上的计算机可执行指令，这些计算机可执行指令由一个或多个处理器执行时执行所述操作。一般来讲，计算机可执行指令包括执行特定功能或实现特定数据类型的例程、程序、对象、部件、数据结构等。描述操作的顺序并非旨在被理解为限制，并且任何数量的所述操作均可按照任意顺序和/或平行组合以实现所述过程。

另外，本文所述的过程的一部分、任一者或全部可在一种或多种计算机系统的控制下执行，所述一种或多种计算机系统被配置为带有具体的可执行指令并且可实现为代码(例如，可执行指令、一种或多种计算机程序或一种或多种应用程序)，该代码由硬件或它们的组合在一种或多种处理器上共同执行。如上所述，代码可存储在非暂态计算机可读存储介质上，例如以计算机程序的形式存储，该计算机程序包括可由一种或多种处理器执行的多个指令。

过程100在框112处开始，用户设备106从一个或多个EHR系统108接收健康数据114。作为在框112处接收健康数据114的一部分，用户设备106和EHR系统108可执行凭证验证过程。例如，EHR系统108可使系统的端点经由基于web的门户网站可用，并且用户110可使用用户设备106使用一组凭证(例如，用户名/密码、患者标识符)登录到基于web的门户网站。在验证凭证后，服务提供方104可发送所请求的健康数据114，这可包括建立与用户设备106的持久数据连接。以这种方式，随着数据被EHR系统108更新(例如，文件被添加到患者记录)，EHR系统108可自动地(例如，以某种预定义的节奏或响应于某些触发)将新的健康数据发送到用户设备106。如本文所描述的，用户设备106可建立并同时维护与多个不同的EHR系统108的多个此类持久数据连接，该多个不同的系统与不同的保健机构(例如，本地诊所、区域性私立连锁医院、紧急护理机构和大学附属急诊室)相关联。

虽然在图1中没有明确示出，但是过程100还可包括用户设备106处理健康数据114。这可包括索引、组织和以其他方式调整健康数据114以改进健康数据114的呈现。这可包括生成表示从健康数据114中识别的医学概念的个性化数据图。如本文其他地方所描述的，个性化数据图可为由用户设备106使用健康数据以及在一些示例中其他数据构建的关系数据结构。个性化数据图表示用户110的健康数据114的唯一表示，因为用户的健康数据114是唯一的。在一些示例中，个性化数据图可基于参考本体和本文所述的UDC被进一步定制。

在框116处，过程100包括用户设备106从服务提供方104接收参考本体118。参考本体118可作为更新的一部分被共享，该更新可为带内或带外的。在一些示例中，每当新信息已经被添加到参考本体118时，参考本体118可由服务提供方104推送到用户设备106。参考本体118可包括基于某种预定义方式组织的健康相关信息的任何合适的集合。例如，参考本体118可由医学概念、医学代码、医学术语和/或任何其他合适的组织结构来组织。在一些示例中，参考本体118可包括信息集合，该信息集合可用于增强或以其他方式增加在112处获得的健康数据的丰富性。例如，来自参考本体118的信息可用于提供关于健康数据114中存在的癌症诊断的附加信息。在该示例中，附加信息可包括文章、多媒体内容、网站等，用于了解关于特定诊断的更多信息。如本文所描述的，来自参考本体118的该附加信息可从参考本体链接并存储在个性化数据图中。

在框120处，过程100包括用户设备106接收定制请求。在一些示例中，用户110可使用用户设备106的用户界面来输入定制请求(例如，经由用户设备106的触摸界面接收的命令)。用户界面可由运行在用户设备106上的应用程序来呈现，该用户设备可与服务提供方104通信。定制请求可包括定制健康数据的一些方面的请求。例如，这可包括将健康数据的记录标记为最爱的、将健康数据的记录添加到列表、给予记录别名、关联两个健康记录(先前未关联)，和/或执行其他类似操作。

在框122处，过程100包括用户设备106生成个性化数据图的用户域概念(UDC)节点124。这可基于在框120处接收的定制请求。生成UDC节点124可包括基于定制请求执行逻辑。例如，取决于在框120处请求了什么类型的定制，用户设备106可不同地生成UDC节点124的各方面。在一些示例中，UDC节点124可包括指示其与其他UDC节点和/或个性化数据图的其他节点的关系(如果存在的话)的关系信息。如本文所描述的，UDC节点124可被添加到个性化数据图中并与其一起保存。

在框126处，过程100包括用户设备106将UDC节点124存储在健康数据数据库128中。健康数据数据库128可用于存储其他健康数据，诸如健康数据114、在用户设备106处生成的和/或从相关联的用户设备(例如，智能手表、计步器、可穿戴传感器)接收的健康数据。将UDC节点124(和个性化数据图)存储在与健康数据相同的位置确保了只要健康数据数据库128持续存在，UDC节点124就会持续存在。服务提供方104不更新健康数据数据库128中的数据，因此，服务提供方104可保持UDC节点124不变。在一些示例中，健康数据数据库128可与由服务提供方104存储的数据库的基于云的版本同步。以这种方式，来自健康数据数据库128的数据可与其他用户设备106(例如，与属于用户110的用户配置文件相关联的设备)同步。

在框130处，过程100包括用户设备106用来自UDC节点124的信息填充用户设备的用户界面132。可响应于请求，诸如在用户设备106的用户界面132处接收到的来自用户110的请求，来执行框130处的该动作。例如，如果UDC节点124表示“最爱的”记录，并且框130处的请求是查看最爱的记录，则填充用户界面132可包括识别哪个UDC节点124表示最爱的记录，访问来自那些节点124的信息，并且使用所访问的信息来填充用户界面132。在一些示例中，用户界面132可包括至少两个区域134a和134b。在一些示例中，在框130处填充用户界面132可包括填充至少一个区域134。在一些示例中，其他区域(例如，134c-N)可填充有从个性化数据图的其他节点和/或从参考本体118获得的信息。

图2示出了根据至少一个示例的示出用于使得能够与生成个性化数据图的用户域概念节点相关的技术的示例性架构或系统200的框图。系统200包括图1中介绍的几个元件。具体地，系统200包括服务提供方104、与保健机构202相关联的EHR系统108(例如，一个或任何其他合适数量的EHR系统)、用户设备106和健康数据数据库128。适当地并如箭头所示，系统200的元件可以经由一个或多个合适的通信网络通信地耦接。例如，服务提供方104、用户设备106和EHR系统108可被配置为经由一个或多个网络彼此通信，如本文所描述的并且在本领域中是已知的。

从服务提供方104开始，服务提供方104包括提供方云服务器204和共享云服务器205。通常，提供方云服务器204包括一个或多个服务器计算机，其可以是虚拟的，并且被配置为机载保健机构以使得能够共享健康数据，管理保健机构(一旦被机载)的注册，并且进行保健机构202的EHR系统108的端点的测试以确保有关由服务提供方104提供的共享系统的正确操作。通常，共享云服务器205包括一个或多个服务器计算机，该一个或多个服务器计算机可为虚拟的，并且被配置为管理用户设备106与服务提供方104和保健机构202共享健康数据。具体地，共享云服务器205的不同元件管理共享的不同方面，包括用户设备106和EHR系统108的授权、数据检索等。

提供方云服务器204包括业务注册系统208、提供方服务210、提供方管理器212、提供方数据库214和测试工具216。业务注册系统208可以是被配置为收集、存储、更新和以其他方式管理业务位置(包括保健机构202的业务位置)的硬件和软件部件的任何合适集合。例如，业务注册系统208可以包括业务数据库218和订阅服务220以启用保健机构202的EHR系统108的订阅。当保健机构202被订阅并且处于活动状态时，可以允许用户设备106与EHR系统108共享健康数据并且连接到EHR系统108(例如，EHR系统108的网关)并从该EHR系统下载健康记录数据。

作为订阅和管理订阅的一部分，订阅服务220可以包括收集、存储、更新和以其他方式管理业务位置的功能。在一些示例中，订阅服务220提供一个或多个用户界面，保健机构202的授权用户可以通过该一个或多个用户界面输入有关其位置的信息。该信息可以包括地理信息(例如，地图上的实际地址和识别符)、图像信息(例如，徽标)、联系人信息(例如，业务、法律、技术)、以及与业务相关的任何其他信息。订阅服务220还可以被配置为基于接收的信息来创建和/或更新业务数据库218中的记录条目。例如，与保健机构202相关联的授权用户可以与订阅服务220共享业务信息。一旦已经共享并验证了该信息，就可以发布业务信息以供公众消费(例如，为搜索建立索引、在地图平台上可用、直接与用户共享)。

业务数据库218可以维护收集的业务信息以及由业务信息表示的实体之间的任何关系。在一些示例中，业务注册系统208可用于注册其他业务实体(不仅是保健机构202)。保健机构202的记录可被维持在业务数据库218和由提供方云服务器系统204维持的提供方数据库214两者中。在一些示例中，业务注册系统208以任何合适的方式与共享云服务器205共享业务信息。

现在转到提供方服务210，通常，提供方服务210可验证EHR系统108，维护关于保健机构202和相关联EHR系统108的信息，使得能够搜索与EHR系统108相关联的保健机构202，以及管理用户设备106对EHR系统108的访问。提供方云服务器204可以在“云”中实现。提供方服务210还可以在提供方数据库214中维护有关保健机构202和相关联EHR系统108的信息，使得能够搜索与EHR系统108相关联的保健机构202，以及管理用户设备106对EHR系统108的访问。在一些示例中，用户设备106向提供方服务210发送搜索保健机构202的请求。提供方服务210处理这些请求并返回结果。在一些示例中，作为与EHR系统108中的一个EHR系统建立连接的一部分，用户设备106将向提供方服务210登记以确定与EHR系统108相关联的任何配置信息是否已经改变。可存储在提供方数据库214中的配置信息可以包括API信息、提供方标识符、状态指示符信息、以及和EHR系统108和/或与EHR系统108相关联的其他实体的配置相关的任何其他合适信息。

作为订阅保健机构202的一部分，测试工具216可以用于测试和/或以其他方式验证使用测试用户设备106的测试用户可以连接到EHR系统108并从该EHR系统下载数据。以这种方式，测试工具216可以模拟用户设备106中的一个用户设备可执行以连接到EHR系统108的动作。在一些示例中，测试工具216可以在首次订阅保健机构202时以及在初始订阅之后的其他时间测试该连接。例如，可在满足某些条件时以及在任何其他情况下周期性测试连接。如果测试是肯定的，则可以更新与保健机构202相关联的提供方数据库214、EHR系统108和/或与EHR系统108相关联的网关中的状态指示符以反映EHR系统108或网关处于活动状态。如果测试是否定的，则可以更新状态指示符以反映EHR系统108是不活动的。当活动时，用户设备106可以能够连接到EHR系统108的网关。当不活动时，用户设备106可能无法连接到EHR系统108的网关。

提供方管理器212通常可由管理员或其他授权用户使用以管理提供方云服务器204的方面。

用户设备106可包括健康应用程序222、健康数据数据库128和本体数据库206。通常，用户设备106可以与不同的用户(例如，保健机构202的患者)相关联并由该用户操作。在功能上，健康应用程序222可使得用户设备106能够与提供方云服务器204通信(例如，搜索保健机构202、获得关于保健机构202的配置信息、以及执行其他技术)、与保健机构202的EHR系统108通信(例如，下载参考本体、下载包括电子健康记录和/或对电子健康记录的更新的数据包以及执行其他此类技术)并且与共享云服务器205通信以上载加密的健康数据并且执行本文所述的用于生成与个性化数据图相关的UDC的技术，以及执行本文所述的其他技术。

共享云服务器205可包括设备认证服务226、数据存储引擎228、访问控制存储装置230、健康数据存储装置232、数据检索引擎234、资产引擎236、EHR认证服务238和日志引擎242。通常，设备认证服务226用于认证用户设备106的用户以访问服务提供方104和/或EHR系统108。例如，设备认证服务226可使用双向认证或相互认证，诸如互联网密钥交换(IKE)、安全外壳(SSH)或传输层安全(TLS)。在使用TLS的示例中，客户端侧X.509证书可用于向服务器(例如，共享云服务器205)认证客户端(例如，用户设备106)的身份，并且X.509证书可用于向客户端认证服务器。在一些示例中，相互认证可包括除证书之外或代替证书的用户名和密码的使用。在一些示例中，访问控制存储装置230可存储可能够由设备认证服务226使用的凭证数据。

数据存储引擎228可被配置为从用户设备106接收加密的健康数据并且将其存储在健康数据存储装置232中。例如，数据存储引擎228可包括一组方法调用以便与用户设备106通信并且存储加密的健康数据。可使用Blob应用程序编程接口(API)将加密的健康数据传递到健康数据存储装置232以将数据推送到健康数据存储装置。

访问控制存储装置230通常存储保健机构和/或提供方的凭证。作为当EHR系统108做出对健康数据存储装置232的请求时的一部分，访问控制存储装置230中的信息可由提供方管理器212访问。

健康数据存储装置232可用于存储从用户设备106获得的加密的健康数据。数据检索引擎234可用于响应于来自提供仪表板221的临床医生用户设备240(例如，用户设备106的示例)的请求而从健康数据存储装置232检索加密的健康数据。例如，数据检索引擎234可使用Blob API以从健康数据存储装置232拉取数据。

资产引擎236被配置为管理共享云服务器205的资产。这可包括移除或以其他方式删除健康数据存储装置232中的旧或陈旧数据。在一些示例中，此类删除可为垃圾收集例程的一部分，或可由用户设备106请求或以其他方式指示。例如，用户设备可改变存储健康数据的方式，并且资产引擎236可在健康数据存储装置232中进行调整。

EHR认证服务238用于认证临床医生用户设备240和/或仪表板221。例如，EHR认证服务238可使用诸如OpenID的分散式认证协议来认证临床医生用户设备240和/或仪表板221。

临床医生用户设备240可由临床医生或其他授权用户操作以访问用户的健康数据。可由临床医生用户设备240呈现的仪表板221可为应用程序，诸如可经由临床医生用户设备240的web浏览器访问的web应用程序或可由临床医生用户设备240访问的任何其他合适的应用程序。在一些示例中，仪表板221可由EHR系统108托管并且可为由临床医生用来访问由EHR系统108存储的电子健康记录的典型仪表板221。为了使得仪表板221能够查看来自服务提供方104的健康数据，如本文所描述的，仪表板221可被略微修改以包括链接、图标或其他图形元素，从而使得临床医生能够使用本文所描述的技术来看到加载到EHR中的健康数据。在一些示例中，EHR系统108与健康应用程序222通信以认证用户设备106的用户。此类通信可使用现有健康等级七国际标准(HL7)来进行，诸如描述用于交换电子健康记录的数据元素、数据格式和API的快速保健互通资源(FHIR)标准。在一些示例中，FHIR标准的开源具体实施(称为FHIR上的SMART(FHIR上的替代医疗应用，可重复使用技术))可以是适当的。

用户设备106可包括健康应用程序222和健康数据数据库128。如本文所描述的，健康应用程序222可用于执行与生成UDC节点、使用此类节点存储健康数据等相关的技术。健康数据数据库128可用于存储如本文所描述的共享的健康数据以及任何其他健康记录数据。

日志引擎242可用于记录与从临床医生仪表板221和/或临床医生用户设备240接收的健康护理数据请求相关的交易信息，如本文进一步详细描述的。在一些示例中，日志引擎242还可包括用于执行密码功能的加密算法和/或解密算法，如本文所描述的。如本文所介绍的，日志引擎242可将交易信息存储在健康数据数据库128中。

图3示出了根据至少一个示例的示出用于在用户设备上存储与个性化数据图的用户域概念节点相关的健康数据的示例性用户配置的图300。图300包括健康数据数据库128和本体数据库206，如本文所描述的，这两者都可由用户设备106存储。在该图中，竖直虚线描绘了存储在两个数据库128和206的每一者中的数据之间的界限。例如，图300包括一个或多个UDC 302a-302N、参考本体概念304(例如，知识图)和医学记录数据306(例如，健康记录的样本)，并且识别这些不同信息元素存储在何处，例如，本体数据库206中的参考本体概念304以及健康数据数据库128中的UDC 302和医学记录数据306。图300还描绘了UDC 302、参考本体概念304与医学记录数据306之间的关系。

从UDC 302开始，根据所需的定制水平，可包括任何合适数量的UDC 302。单个UDC302(例如，UDC 302a)可存储与不同UDC 302(例如，UDC 302N)的连接308。连接308可为一对一的(例如，一个UDC对一个UDC)或一对多的(例如，一个UDC对多个UDC)。在一些示例中，关于连接308的信息由UDC 302存储。这可包括唯一地识别UDC 302、识别关系等的信息。因为关于UDC之间的连接308的信息存储在健康数据数据库128中，所以该信息将保留在用户设备上，即使参考本体概念304改变。取决于用户设备接收的用例和定制请求，用户设备可在UDC 302之间生成UDC连接308，并且用描述连接308的信息来更新相关的UDC 302。

UDC 302还可经由医学编码310连接到、基于或以其他方式与参考本体概念304相关联。UDC 302可存储关于医学编码310的信息，该医学编码继而可引用参考本体概念304的特定节点。医学编码310可为表示参考本体概念304中存在的医学概念的数字或其他代码。例如，医学编码310可对应于医学编码的行业标准，诸如国际疾病分类，第10版，临床修改(ICD-10-CM)，当前程序术语(CPT)，ICD-10-程序编码系统，国家药品编码(NDC)，以及任何其他合适的编码标准。取决于用户设备接收的用例和定制请求，用户设备可通过用描述医学编码310的信息更新UDC 302来生成与参考本体概念304的链接，通过该医学编码，UDC302与参考本体概念304链接。

UDC 302还可经由健康记录映射312连接到、基于或以其他方式与医学记录数据306相关联。UDC 302可存储关于健康记录映射312的信息，该健康记录映射引用具体的医学记录数据306。例如，健康记录映射312可表示医学记录数据306中存在的处方与UDC 302之间的关联，该UDC 302表示该处方已被用户喜爱。UDC 302可表示医学记录数据306的任何合适的方面，如健康记录映射312所表示的。取决于用户设备接收的用例和定制请求，用户设备可通过用描述健康记录映射312的信息更新UDC 302来生成与健康记录数据306的链接，UDC 302通过该健康记录映射与健康记录数据306链接。

医学记录数据306可连接到参考本体概念304或以其他方式与该参考本体概念相关联。由医学记录数据306表示的单独的医学记录可由健康记录标识符314表示。在一些示例中，健康记录标识符314可为通用唯一标识符(UUID)或能够唯一地识别医学记录数据306的其他合适的标识符。健康记录标识符314可在用户设备接收健康记录数据306(例如，从EHR系统)之后或之时由用户设备生成。单独的参考本体概念304可由定制标识符316来表示。本体索引318可用于在健康记录标识符314与定制标识符316之间进行映射。

图4示出了根据至少一个示例的示出用于生成个性化数据图的用户域概念节点的示例性数据模型400的框图。数据模型400表示示例性UDC节点402，并对应于图300。UDC节点402可被建模为具有基础模式404、有效载荷406、到其他UDC节点的连接408、到参考本体的连接410、到健康数据的连接412以及任何其他合适的元素。UDC节点402可被包括在个性化数据图中(例如，包括UDC节点和用户健康数据的表示的表)。健康数据可从EHR系统下载，由用户设备生成，从用户设备的传感器或外围设备获得，和/或由用户设备的用户输入。

从基础模式404开始，基础模式404可包括以下字段：用户域概念标识符(udc_id)(例如，udc节点的唯一标识符，其也可对应于行标识符(row_id))、通用唯一标识符(uuid)(例如，唯一地识别UDC节点的标识符)、模式(例如，识别模式的可空字符串)、类型(例如，将UDC节点与其他类型的数据节点区分开的enum数据类型)、删除(例如，与删除状态相关的“bool”数据类型)、创建日期(例如，识别创建UDC节点的日期的信息)、修改日期(例如，识别UDC节点的最近修改的信息)、os_version(例如，识别操作系统版本的信息)、构建(例如，标识操作系统构建的信息)、同步锚(例如，允许跟踪哪些改变尚未被推送到各个同步端点/从各个同步端点拉取的信息)、以及同步起源(例如，识别同步起源的信息)。

为了避免一些同步排序问题和新同步实体数量的大量增加，在一些示例中，UDC节点可共享单个公共同步实体。在该示例中，UDC类型特定的有效载荷数据可基于类型被串行化。

同步锚可允许跟踪哪些改变尚未被推送到各个同步端点/从各个同步端点拉取。同步锚可在数据库中被表示为给定实体的基表中的整数列。对于大多数实体，该列可简单地为自动递增的伪列。在一些示例中，同步锚可随着行的插入而增加，或如果需要对任何行执行“修改”，则可删除和重新添加。

为了维护各种表中UDC行之间的设备本地引用，可使用sync_anchor列，该列在UDC更新时递增。在一些示例中，UDC(UUID独有的)的默认冲突解决策略可为“最后修改获胜”对于特定的UDC类型，此策略可能会被重写。在一些示例中，UDC类型标识符可为由(插件模式标识符、类型enum)组成的元组。这可使用插件实现UDC生成的集成。

现在转到有效载荷406，有效载荷406可根据UDC类型而不同。因此，每种UDC类型都可能包括定制数据模型、持久性(数据库表)以及特定于其功能和用途的序列化支持。例如，到健康数据的连接412和到其他UDC节点408的连接可由基础实体实现。例如，药物示例的有效载荷可包括：

·消费者友好的名称(来自引用的本体)

·别名(用户输入的字符串)

·图标(用户选择的enum)

·状态(活动/非活动)

为了允许在具有不同操作系统和参考本体版本的设备之间向后/向前兼容同步UDC，UDC可在UDC特性集合中存储可变特性。该集合可由通用的、版本化的UDC特性对象组成。这些版本化特性的集合可以这样的方式合并或区分，即仅保留给定特性的最新版本，而不丢失可能未知的特性(因为其来自未来的操作系统)。例如，如果未来的操作系统版本将特性“用户选择的别名”添加到UDC，则该特性可同步回运行没有定义该特性类型的较旧操作系统版本的设备，并且即使集合中的其他特性在较旧设备上被修改/更新，该特性也将被保留。

现在转到其他UDC节点的连接408，到其他UDC节点的连接408可用模式来持久化，该模式包括：伪列、udc_id(引用该UDC的外键)、connection_type(enum)、target_uuid(引用其他“连接的”UDC的UDC UUIC)。改变(添加或移除UDC的连接)可能会改变UDC的同步锚，以便UDC可与其当前的连接集同步。在一些示例中，使用target_uuid而不是target_udc_id。这可能有助于支持多设备同步，在这种情况下，UDC及其连接在所有UDC连接到设备之前就出现在设备上。

现在转到参考本体的连接410，到参考本体的连接410可被配置为使得能够在给定UDC节点的情况下有效搜索连接的参考本体节点，并且在从备份恢复或同步到新设备之后保持连接。在一些示例中，UDC将为连接的本体节点保存/同步编码(例如，医学编码310)。这些编码可能来自用户为创建UDC而与之交互的健康记录，也可能是在手工创建UDC期间从参考本体中拉取的。这些连接的示例性模式可包括：row_id、udc_id(引用该UDC的外键)、系统、代码、版本、显示_字符串。在一些示例中，系统、代码、版本、显示_字符串可为对用户域概念编码字符串表中的行的可空外键引用，该用户域概念编码字符串表的存在是为了对公共编码字符串的存储进行去重复。在一些示例中，udc_id、系统、代码、版本可形成唯一的元组。用户域概念编码字符串可包括row_id，字符串(非空唯一字符串)。在一些示例中，存储UDC的系统/代码可避免构建将UDC映射到参考本体节点的索引表的需要，因为这些映射可通过有效的运行时查询来确定。

现在转到健康数据的连接412，到健康数据的连接412可被配置为实现以下中的一者或一者：在给定UDC的情况下有效地找到连接的健康记录数据(例如，样本)，在给定样本的情况下有效地找到连接的UDC，处理到非常大量样本(例如，与所有心率样本连接的UDC)的连接，在从备份恢复或同步到新设备之后维持或重建连接，在没有参考本体的情况下运行，处理由新UUID表示的新的医学记录数据，处理医学记录的快速保健互通资源(FHIR)标识符的变化(例如，DSTU-2到R4的转换)，确定给定样本是否连接到UDC的内存中(例如，支持变化检测器)。

在一些示例中，每个UDC可持续并同步一组“连接的样本描述”。符合这些描述中的一个描述的任何样本都可被认为连接到UDC。例如，使用心率类型标识符连接到所有样本的UDC。如果持久连接在数据库中具有结构化形式而不是串行化的blob，则到健康数据的连接412对于有效的双向查询(例如，连接到UDC的样本，以及样本所连接到的UDC)可能是有用的。这可允许直接创建sqlite谓词，可为给定的样本找到UDC，反之亦然。例如，当每个新类型的样本连接被提议用于某个具体用例时，可添加表示给定样本连接描述的特性。结果可能是高度非规范化的表，其中可空列表示连接描述具体的特性。

连接412的示例性模式可包括伪列、udc_id(引用该UDC的外键)、data_type(该连接所应用的可空对象类型)、量(可空健康数据量)。在一些示例中，某些连接可能难以直接从谓词查询，因为这些连接在数据库中由串行化的blob表示。为了支持查询这些类型的连接，UDC节点可为UDC映射实体中的索引查找维护持久化的设备本地UDC到样本的映射。可在生成和刷新UDC的同时建立和维护该映射。待索引的样本可在“连接的样本谓词”中定义。

手动输入的医学记录样本可能没有任何参考编码(例如，如果其是针对本身没有连接到参考本体概念的UDC输入的)。为了维护记录与UDC之间的连接，可在创建时为手动输入的记录提供映射到UDC的一些附加元数据。这可保持连接，即使稍后UDC和/或记录开始映射到参考本体概念。

在一些示例中，UDC节点402还可实现当添加或移除UDC时通知用户设备、当修改UDC时通知用户设备、当新的健康记录连接到UDC时通知用户设备、以及当添加未连接到任何UDC的新的健康记录时通知用户设备(例如，使得可提示用户向健康记录样本添加UDC连接)。

在一些示例中，UDC节点402可包括关系信息，该关系信息针对具体节点识别相对于其他节点(例如，UDC节点或概念节点)的关系。例如，此类关系信息可包括诸如列表成员(例如，定义该节点是列表的成员)、可支持(例如，定义该节点可支持)、子(例如，定义该节点是不同节点的子)、父(例如，定义该节点是不同节点的父)、更具体(例如，定义该节点比其他节点更具体)或不太具体(例如，定义该节点比其他节点更不具体)的事物。

图5示出了根据至少一个示例的示出用于生成个性化数据图的用户域概念节点的示例性过程500的流程图。过程500可由用户设备106(图1)的健康应用程序222(图2)执行。在一些示例中，至少一些部分(或其全部)可由服务提供方104(图1)来执行。

过程500在框502处开始，用户设备106从电子健康记录(EHR)系统接收健康数据。健康数据可与由EHR系统维护的患者配置文件相关联。用户设备106的用户可使用用户设备106登录到由EHR系统维护的系统中，以使该系统验证该用户被授权访问健康数据(例如，该用户是在患者配置文件中识别的相同用户或以其他方式与患者配置文件相关联)。因此，作为从EHR系统接收健康数据的一部分，用户设备106可向EHR系统发送登录请求，该登录请求可包括用户设备106的用户的凭证。

健康数据可包括临床健康记录数据、传感器数据和/或任何其他合适类型的健康数据。在一些示例中，从电子健康记录系统或从与不同保健机构相关联的不同健康记录系统接收临床健康记录数据。在一些示例中，传感器数据由移动用户设备的传感器生成，或从与用户设备相关联的不同用户设备(例如，附属设备，诸如手表、可穿戴监视器)接收传感器数据。在一些示例中，健康数据的第一部分由用户设备从电子健康记录系统获得，并且健康数据的第二部分由用户设备从与不同保健机构相关联的不同电子健康记录系统获得。在一些示例中，健康数据被组织成多个类别。健康数据可与用户设备的用户配置文件或预定义组(例如，设备家族)的成员的用户配置文件相关联。

在框504处，过程500包括用户设备106接收与定制健康数据的一部分相关的定制请求。定制请求可从用户设备的用户接收，或以自动化方式触发。例如，用户可用来查看和组织健康的健康应用程序也可包括启用某些定制的功能。此类定制可包括例如将健康记录添加到列表、将健康记录标记为最爱、将健康记录分组等。在该示例中，用户可使用用户设备106处的用户界面来与健康应用程序进行交互以定制健康数据，该健康数据继而可由用户设备106作为定制请求来接收和处理。在一些示例中，定制请求可包括以下中的至少一者：最爱健康数据的部分的请求、给予健康数据的部分别名的请求、将健康数据的部分添加到列表的请求、将健康数据与其他健康数据组合的请求、将现有UDC节点与个性化数据图的一个或多个其他UDC节点连接的请求。

在一些示例中，可省略框502，并且过程500可通过用户设备106接收定制请求在504处开始。然而，在该示例中，定制请求可涉及生成不与健康数据和/或概念节点相关联的UDC节点。例如，用户可生成独立于健康数据和/或概念节点的全新UDC节点。在一些示例中，当用户在用户设备106处输入健康数据时，也可生成此类UDC节点，而不是用户设备106从EHR系统接收健康数据。例如，用户设备106可使得用户能够输入关于健康相关事件、条件或诊断的信息。该信息可被推出并保存为健康记录，并且在一些示例中，还可用于创建UDC节点以捕获事件、条件或诊断的任何附加定制。

在框506处，过程500包括用户设备106生成个性化数据图的用户域概念(UDC)节点。生成UDC节点可包括至少部分地基于定制请求来生成。UDC节点可包括表示健康数据的所定制部分的定制信息。在一些示例中，UDC节点可包括关于图4的UDC节点402描述的信息中的至少一些信息。例如，定制请求可将UDC节点与健康数据的一部分、知识图的概念、另一个UDC节点或任何其他合适的数据元素相关联。

在一些示例中，健康数据的该部分可包括多个健康数据样本，并且UDC节点可包括与多个健康数据样本中的每个健康数据的单独的连接。例如，多个健康样本可为在不同时间进行的多个心率测量，并且甚至可能从不同的健康记录中拉取，并且UDC节点可表示这些不同心率测量之间的关联。

在框508处，过程500包括用户设备106更新UDC节点，从而包括表示UDC节点与健康数据的该部分之间的关系的关系信息。在一些示例中，更新可至少部分地基于生成UDC节点。在一些示例中，生成和更新可作为单个操作、单独的操作和/或相关的操作来执行(例如，节点可被生成，然后被更新以包括填充该节点的字段的信息)。

在一些示例中，过程500还可包括用户设备106，在接收健康数据之后，索引健康数据以将参考编码分配给健康数据的单独的部分。在该示例中，更新UDC节点，从而包括关系信息可包括更新UDC节点以包括分配给健康数据的该部分的参考编码。

在框510处，过程500包括用户设备106填充用户界面，该用户界面包括UDC节点的表示。在一些示例中，用户界面可在诸如健康应用程序的应用程序内呈现。用户界面可包括用于呈现用户界面元素的一个或多个区域，其中至少一个可用于呈现UDC节点的表示。UDC节点的表示可对应于UDC节点的内容。例如，如果UDC节点表示药物的别名，则该表示可包括识别别名的字符串(例如，“best toe cream”)、药物的图像(例如，用户捕获的或从一些其他来源获得的)以及与实际药物相关的其他信息(例如，药物的正确名称、关于剂量的信息、处方医生)。当生成UDC节点时，该信息中的至少一些信息可从健康记录数据中获得。因此，在框510处，过程500使用存储在UDC节点中的信息和用户界面中的逻辑来确定如何呈现来自UDC节点的信息。

在一些示例中，过程500还可包括用户设备106在个性化数据图的多个其他UDC节点与UDC节点之间建立多个连接；移除其他UDC节点中的至少一个其他UDC节点与UDC节点之间的多个连接中的一个连接；并且响应于移除该连接，使得UDC节点与多个其他UDC节点同步。

在一些示例中，过程500还可包括用户设备106通过至少确定从健康数据识别的医学概念与参考本体的参考节点之间的映射生成个性化数据图的概念节点。在该示例中，过程500还可包括用户设备106接收与定制概念节点的方面相关的不同的定制请求。在该示例中，过程500还可包括用户设备106至少部分地基于不同的定制请求生成个性化数据图的不同的UDC节点。不同的UDC节点可包括表示概念节点的所定制方面的不同的定制信息。在该示例中，过程500还可包括用户设备106至少部分地基于生成不同的UDC节点更新概念节点，从而包括表示概念节点与不同的UDC节点之间的关系的关系信息。

图6示出了根据至少一个示例的示出用于生成个性化数据图的用户域概念节点的示例性过程600的流程图。过程600可由用户设备106(图1)的健康应用程序222(图2)执行。在一些示例中，至少一些部分(或其全部)可由服务提供方104(图1)来执行。

过程600在框602处开始，用户设备106从电子健康记录(EHR)系统接收健康数据。该框可类似于图5的框502执行。

在框604处，过程600包括用户设备106索引健康数据。索引健康数据可包括处理健康数据以将参考编码(例如，健康记录标识符314)分配给健康数据的单独的部分。在一些示例中，索引还可包括将健康数据映射到参考本体概念的一个或多个概念(例如，304)。

在框606处，过程600包括用户设备106生成个性化数据图的概念节点。这可通过至少确定从健康数据识别的医学概念与参考本体的参考节点之间的映射执行。在一些示例中，在框606处生成的概念节点可表示健康数据中的医学概念，该医学概念至少在这一点上与UDC节点断开连接。因此，可存储在健康数据数据库128(图1)中的个性化数据图可包括UDC节点和非UDC节点。非UDC节点可为表示医学概念、医学记录或健康数据的一些其他方面并且不是定制的节点。

在框608处，过程600包括用户设备106确定是否定制在框606处创建的概念节点。在一些示例中，这可包括确定是否已经接收到定制请求。定制请求可经由用户界面或其他输入设备接收，作为用户的输入。定制请求可涉及定制概念节点的方面。在一些示例中，这可包括确定是否已经接收到一个或多个自动定制触发。例如，当用户设备106处理新的健康数据时，该事件可触发概念节点的定制。作为附加示例，当参考本体被更新时，这可能触发对概念节点的更新。在一些示例中，类似的触发可与对UDC节点的更新相关联。例如，当与特定UDC节点相关联的底层健康数据或参考本体被更新时，特定UDC节点也可被更新。

在一些示例中，概念节点可表示具体药物，并且定制请求可包括为具体药物分配别名的用户请求。在该示例中，定制信息可包括别名。在一些示例中，概念节点可表示具体实验室结果，并且定制请求可包括将该具体实验室结果添加到列表的用户请求。在该示例中，定制信息可定义列表。

如果608处的答案为“否”，则过程600前进至610并结束。如果在608处的回答是“是”，则在框612处，过程600包括用户设备106生成个性化数据图的用户域概念(UDC)节点。该生成可至少部分地基于定制请求(或在608处检测到的触发)。UDC节点可包括表示概念节点的所定制方面的定制信息。

在框614处，过程600包括用户设备106更新概念节点，从而包括关系信息。关系信息可表示概念节点与UDC节点之间的关系。在一些示例中，更新可以至少部分地基于生成UDC节点。因此，一旦已经生成UDC节点，就可更新概念节点。以这种方式，概念节点可保留关于其与UDC节点的关系的信息。在一些示例中，关系可包括以下中的至少一者：列表成员、可支持、子、父、更具体或不太具体。

在框616处，过程600包括用户设备106填充用户界面，该用户界面包括至少部分地基于UDC节点的表示。这可以类似于图5的框510的方式来执行。

在一些示例中，过程600还可包括将参考本体存储在用户设备上的第一存储位置中，并且将个性化数据图存储在用户设备上的第二存储位置中。在一些示例中，第一存储位置(例如，本体数据库206)和第二存储位置(例如，健康数据数据库128)可在逻辑上彼此分离。这可使得能够更新一个而不影响另一个。在一些示例中，填充用户界面可包括：响应于接收到请求，从第二存储位置检索与个性化数据图的UDC节点相关联的数据。在该示例中，填充还可包括使用与UDC节点相关联的数据来填充用户界面。

在一些示例中，定制请求可为第一定制请求，方面可为第一方面，概念节点可为第一概念节点，UDC节点可为第一UDC节点，并且定制信息可为第一定制信息。在该示例中，过程600还可包括用户设备106接收与定制第二概念节点的第二方面相关的第二定制请求。过程600还可包括用户设备106至少部分地基于第二定制请求生成个性化数据图的第二UDC节点。第二UDC节点可包括表示第二概念节点的第二定制方面的第二定制信息。在一些示例中，第一定制请求和第二定制请求可涉及将第一概念节点和第二概念节点添加到列表。在该示例中，该表示可包括使用来自第一UDC节点和第二UDC节点的信息生成的列表。

在一些示例中，可在框608处分析的定制请求可包括将概念节点与不同的概念节点合并的请求。在该示例中，UDC节点可包括表示概念节点和不同的概念节点的单个节点。在一些示例中，不同的概念节点可表示医学概念。在一些示例中，不同的概念节点可表示不同的医学概念。

在一些示例中，过程600还可包括用户设备106更新包括参考节点的参考本体，而不更新个性化数据图的UDC节点。在一些示例中，过程600还可包括用户设备106更新包括UDC节点的个性化数据图本体，而不更新参考本体的参考节点。

在一些示例中，用户设备可为第一用户设备，并且可与用户配置文件相关联。在该示例中，过程600还可包括用户设备106从服务提供方接收由与用户配置文件相关联的第二用户设备生成的不同的个性化数据图。过程600还可包括用户设备106比较个性化数据图和不同的个性化数据图，以生成组合的个性化数据图。过程600还可包括用户设备106与服务提供方共享组合的个性化数据图。

图7示出了根据至少一个示例的示例性架构或环境700，该示例性架构或环境被配置为实施本文描述的技术。在一些示例中，示例性架构700还可被配置为使得用户设备706和服务提供方计算机702能够共享信息。服务提供方计算机702是服务提供方104和EHR系统108的示例。用户设备706是用户设备106的示例。在一些示例中，设备可经由一种或多种网络708(例如，经由蓝牙、WiFi、互联网)连接。在一些示例中，服务提供方计算机702可被配置为实现本文中参考用户设备706描述的技术中的至少一些，反之亦然。

在一些示例中，网络708可包括许多不同类型的网络中的任一种或组合，诸如有线网络、互联网、无线网络、蜂窝网络、卫星网络、其他专用网络和/或公共网络或它们的任何组合。虽然所示出的示例表示经由网络708访问服务提供方计算机702的用户设备706，但是所述技术可同样应用于用户设备706通过固定电话、经由公用电话亭或以任何其他方式与服务提供方计算机702进行交互的实例。还需要指出，所述技术可应用于其他客户端/服务器布置(例如，机顶盒)中以及非客户端/服务器布置(例如，本地存储的应用程序、对等配置)中。

如上所述，用户设备706可为任何类型的计算设备，诸如但不限于移动电话、智能电话、个人数字助理(PDA)、膝上型计算机、台式计算机、瘦客户端设备、平板电脑、可穿戴设备(诸如智能手表)等。在一些示例中，用户设备706可经由网络708或经由其他网络连接与服务提供方计算机702进行通信。

在一种例示性配置中，用户设备706可包括至少一个存储器714和一个或多个处理单元(或处理器)716。处理器716可根据适当情况在硬件、计算机可执行指令、固件或它们的组合中实现。处理器716的计算机可执行指令或固件具体实施包括以任何合适的编程语言编写的计算机可执行指令或机器可执行指令，以执行所述的各种功能。用户设备706还可包括用于提供和/或记录与用户设备706相关联的地理位置信息的地理位置设备(例如，全球定位系统(GPS)设备等)。

存储器714可存储能够在处理器716上加载和执行的程序指令以及在执行这些程序期间生成的数据。根据用户设备706的配置和类型，存储器714可为易失性存储器(诸如随机存取存储器(RAM)和/或非易失性存储器(诸如只读存储器(ROM)、闪存存储器)。用户设备706可包括附加可移除存储装置和/或不可移除存储装置726，包括但不限于磁存储装置、光盘和/或磁带存储装置。磁盘驱动器及其相关联的非暂态计算机可读介质可为计算设备提供计算机可读指令、数据结构、程序模块及其他数据的非易失性存储装置。在一些具体实施中，存储器714可包括多种不同类型的存储器，诸如静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)或ROM。虽然本文所述的易失性存储器可以被称为RAM，但是从主机和/或电源拔下后将不会保留其中所存储的数据的任何易失性存储器都是适当的。

可移除及不可移除的存储器714和附加的存储装置726均为非暂态计算机可读存储介质的示例。例如，非暂态计算机可读存储介质可包括易失性或非易失性、可移除或不可移除介质，其通过任何方法或技术实现为用于存储信息诸如计算机可读指令、数据结构、程序模块或其他数据。存储器714和附加的存储装置726均为非暂态计算机存储介质的示例。可存在于用户设备706中的附加类型的计算机存储介质可包括但不限于：相变RAM(PRAM)、SRAM、DRAM、RAM、ROM、电可擦除可编程只读存储器(EEPROM)、闪存存储器或其他存储器技术、光盘只读存储器(CD-ROM)、数字视频光盘(DVD)或其他光学存储装置、磁带盒、磁带、磁盘存储装置或其他磁存储设备，或任何其他可用于存储所需信息并可被用户设备706访问的介质。上述任意组合也应该包括在非暂态计算机可读存储介质的范围内。另选地，计算机可读通信介质可包括计算机可读指令、程序模块或在数据信号诸如载波或其他传输手段内传输的其他数据。然而，如本文所用，计算机可读存储介质不包括计算机可读通信介质。存储器714和/或附加存储器726可存储健康数据数据库128和/或本体数据数据库206。

用户设备706还可包含通信连接728，该通信连接允许用户设备706经由网络708与数据存储库、另一种计算设备或服务器、用户终端和/或其他设备进行通信。用户设备706还可包括I/O设备730，诸如键盘、鼠标、笔、语音输入设备、触摸屏输入设备、显示器、扬声器、打印机等。

更详细地转到存储器714的内容，存储器714可包括操作系统712和/或用于实现本文所公开的特征的一个或多个应用程序或服务，诸如应用程序711(例如，健康应用程序222、数字钱包、第三方应用程序、浏览器应用程序和任何其他合适的应用程序)。在一些示例中，应用程序711可包括健康应用程序(例如，健康应用程序222)以执行如参考用户设备106所描述的类似技术。类似地，参考服务提供方计算机702所述的至少一些技术可由用户设备106执行。

服务提供方计算机702还可为任何类型的计算设备，诸如但不限于虚拟或“云”计算资源的集合、远程服务器、移动电话、智能电话、PDA、膝上型计算机、台式计算机、瘦客户端设备、平板计算机、可穿戴设备、服务器计算机或虚拟机实例。在一些示例中，服务提供方计算机702可经由网络708或经由其他网络连接与用户设备706进行通信。

在一种例示性配置中，服务提供方计算机702可包括至少一个存储器742和一个或多个处理单元(或处理器)744。处理器744可根据适当情况在硬件、计算机可执行指令、固件或它们的组合中实现。处理器744的计算机可执行指令或固件具体实施包括以任何合适的编程语言编写的计算机可执行指令或机器可执行指令，以执行所述的各种功能。

存储器742可存储能够在处理器744上加载和执行的程序指令以及在执行这些程序期间生成的数据。根据服务提供方计算机702的配置和类型，存储器742可为易失性存储器(诸如RAM)和/或非易失性存储器(诸如ROM、闪存存储器)。服务提供方计算机702还可包括附加可移除存储装置和/或不可移除存储装置746，包括但不限于磁存储装置、光盘和/或磁带存储装置。磁盘驱动器及其相关联的非暂态计算机可读介质可为计算设备提供计算机可读指令、数据结构、程序模块及其他数据的非易失性存储装置。在一些具体实施中，存储器742可包括多种不同类型的存储器，诸如SRAM、DRAM或ROM。虽然本文所述的易失性存储器可以被称为RAM，但是从主机和/或电源拔下后将不会保留其中所存储的数据的任何易失性存储器都是适当的。可移除和不可移除的存储器742和附加存储装置746均为非暂态计算机可读存储介质的附加示例。

服务提供方计算机702还可包含通信连接748，该通信连接允许服务提供方计算机702经由网络708与数据存储库、另一种计算设备或服务器、用户终端和/或其他设备进行通信。服务提供方计算机702还可包括I/O设备750，诸如键盘、鼠标、笔、语音输入设备、触摸输入设备、显示器、扬声器和打印机。

更详细地转到存储器742的内容，存储器742可包括操作系统752和/或用于实现本文所公开的特征的一个或多个应用程序741或服务，包括提供方服务210、提供方管理器212、订阅服务220、业务注册系统208、测试工具216、设备认证服务226、数据存储引擎228、数据检索引擎234、资产引擎236、EHR认证服务238、日志引擎242、访问控制存储装置230、健康数据数据库128和健康数据存储装置232数据库和/或仪表板221。

在下文中，描述了另外的条款，以促进理解本公开。

条款1.一种计算机实现的方法，包括：

由用户设备从电子健康记录(EHR)系统接收健康数据；

接收与定制该健康数据的一部分相关的定制请求；

至少部分地基于该定制请求生成个性化数据图的用户域概念(UDC)节点，该UDC节点包括表示该健康数据的所定制部分的定制信息；

至少部分地基于生成该UDC节点更新该UDC节点，从而包括表示该UDC节点与该健康数据的该部分之间的关系的关系信息；和

在该用户设备处填充用户界面，该用户界面包括该UDC节点的表示。

条款2.根据条款1所述的计算机实现的方法，其中该健康数据与该用户设备的用户配置文件相关联。

条款3.根据条款1至2中任一项所述的计算机实现的方法，其中该健康数据的该部分包括多个健康数据样本，并且其中该UDC节点包括与该多个健康数据样本中的每个健康数据样本的单独的连接。

条款4.根据条款1至3中任一项所述的计算机实现的方法，该计算机实现的方法还包括：在接收到该健康数据之后，索引该健康数据，以将参考编码分配给该健康数据的单独的部分，并且其中更新该UDC节点从而包括该关系信息包括：更新该UDC节点从而包括分配给该健康数据的该部分的参考编码。

条款5.根据权利要求1至4中任一项所述的计算机实现的方法，其中该定制请求包括以下中的至少一者：最爱该健康数据的该部分的请求、给予该健康数据的该部分别名的请求、将该健康数据的该部分添加到列表的请求、将该健康数据与其他健康数据组合的请求、将该UDC节点与该个性化数据图的一个或多个其他UDC节点连接的请求。

条款6.根据条款1至5中任一项所述的计算机实现的方法，该计算机实现的方法还包括：

在该个性化数据图的多个其他UDC节点与该UDC节点之间建立多个连接；

移除该其他UDC节点中的至少一个其他UDC节点与该UDC节点之间的该多个连接中的一个连接；和

响应于移除该连接，使得该UDC节点与该多个其他UDC节点同步。

条款7.根据条款1至6中任一项所述的计算机实现的方法，该计算机实现的方法还包括：

通过至少确定从该健康数据识别的医学概念与参考本体的参考节点之间的映射生成个性化数据图的概念节点；和

接收与定制该概念节点的方面相关的不同的定制请求；

至少部分地基于该不同的定制请求生成该个性化数据图的不同的UDC节点，该不同的UDC节点包括表示该概念节点的经定制的方面的不同的定制信息；和

至少部分地基于生成该不同的UDC节点更新该概念节点，从而包括表示该概念节点与该不同的UDC节点之间的关系的关系信息。

条款8.一种或多种非暂态计算机可读介质，该一种或多种非暂态计算机可读介质包括计算机可执行指令，该计算机可执行指令当由一个或多个处理器执行时，使得该一个或多个处理器执行根据条款1至7中任一项所述的方法。

条款9.一种计算机化系统，该计算机化系统包括：

存储器，所述存储器被配置为存储计算机可执行指令；和

处理器，该处理器被配置为访问该存储器并且执行这些计算机可执行指令以执行根据条款1至7中任一项所述的方法。

条款10.一种计算机实现的方法，包括：

由用户设备从电子健康记录(EHR)系统接收健康数据；

通过至少确定从该健康数据识别的医学概念与参考本体的参考节点之间的映射生成个性化数据图的概念节点；

接收与定制该概念节点的方面相关的定制请求；

至少部分地基于该定制请求生成个性化数据图的用户域概念(UDC)节点，该UDC节点包括表示该概念节点的所定制方面的定制信息；

至少部分地基于生成该UDC节点更新该概念节点，从而包括表示该概念节点与该UDC节点之间的关系的关系信息；和

在该用户设备处填充用户界面，该用户界面包括至少部分地基于该UDC节点的表示。

条款11.根据条款10所述的计算机实现的方法，该计算机实现的方法还包括：

将该参考本体存储在该用户设备上的第一存储位置中；和

将该个性化数据图存储在该用户设备上的第二存储位置中。

条款12.根据条款11所述的计算机实现的方法，其中填充该用户界面包括：响应于接收请求，从该第二存储位置检索与该个性化数据图的该UDC节点相关联的数据；和使用与该UDC节点相关联的该数据来填充该用户界面。

条款13.根据条款10至12中任一项所述的计算机实现的方法，其中该概念节点表示具体药物，并且定制请求包括为该具体药物分配别名的用户请求，并且其中该定制信息包括该别名。

条款14.根据条款10至13中任一项所述的计算机实现的方法，其中该概念节点表示具体实验室结果，并且该定制请求包括将该具体实验室结果添加到列表的用户请求，并且其中该定制信息定义该列表。

条款15.根据条款10至14中任一项所述的计算机实现的方法，其中该定制请求是第一定制请求，该方面是第一方面，该概念节点是第一概念节点，该UDC节点是第一UDC节点，并且该定制信息是第一定制信息，该方法还包括：

接收与定制第二概念节点的第二方面相关的第二定制请求；和

至少部分地基于该第二定制请求生成该个性化数据图的第二UDC节点，该第二UDC节点包括表示所定制的该第二概念节点的第二方面的第二定制信息。

条款16.根据条款15所述的计算机实现的方法，其中该第一定制请求和该第二定制请求涉及将该第一概念节点和该第二概念节点添加到列表，并且其中该表示包括使用来自该第一UDC节点和该第二UDC节点的信息生成的该列表。

条款17.根据条款10至16中任一项所述的计算机实现的方法，其中该定制请求包括将该概念节点与不同的概念节点合并的请求，其中该UDC节点包括表示该概念节点和该不同的概念节点的单个节点。

条款18.根据条款17所述的计算机实现的方法，其中该不同的概念节点表示该医学概念。

条款19.根据条款17所述的计算机实现的方法，其中该不同的概念节点表示不同的医学概念。

条款20.根据条款10至19中任一项所述的计算机实现的方法，其中该关系包括以下中的至少一者：列表成员、可支持、子、父、更具体或不太具体。

条款21.根据条款10至20中任一项所述的计算机实现的方法，该计算机实现的方法还包括更新包括该参考节点的该参考本体，而不更新该个性化数据图的该UDC节点。

条款22.根据条款10至21中任一项所述的计算机实现的方法，该计算机实现的方法还包括更新包括该UDC节点的该个性化数据图，而不更新该参考本体的该参考节点。

条款23.根据条款10至22中任一项所述的计算机实现的方法，其中该用户设备是第一用户设备并且与用户配置文件相关联，该计算机实现的方法还包括从服务提供方接收由与该用户配置文件相关联的第二用户设备生成的不同的个性化数据图；

比较该个性化数据图和该不同的个性化数据图，以生成组合的个性化数据图；和

与该服务提供方共享该组合的个性化数据图。

条款24.一种或多种非暂态计算机可读介质，该一种或多种非暂态计算机可读介质包括计算机可执行指令，该计算机可执行指令当由一个或多个处理器执行时，使得该一个或多个处理器执行根据条款10至23中任一项所述的方法。

条款25.一种计算机化系统，该计算机化系统包括：

存储器，所述存储器被配置为存储计算机可执行指令；和

处理器，其被配置为访问存储器并执行计算机可执行指令以执行条款10-23中任一项的方法

可进一步在各种各样的操作环境中实施各种示例，在一些情况下，操作环境可包括可用于操作多个应用程序中的任一个应用程序的一个或多个用户计算机、计算设备或处理设备。用户设备或客户端设备可包括许多通用个人计算机中的任何一个，诸如运行标准操作系统的台式计算机或膝上型计算机，以及运行移动软件并能够支持多个联网协议和即时消息协议的蜂窝设备、无线设备和手持设备。此系统还可包括运行各种可商购获得的操作系统和用于目的诸如开发和数据库管理等的其他已知应用程序中的任何一者的多个工作站。这些设备还可包括其他电子设备，诸如虚拟终端、瘦客户端、游戏系统以及能够经由网络进行通信的其他设备。

大多数示例利用本领域技术人员熟悉的至少一个网络来支持使用各种商用协议(诸如TCP/IP、OSI、FTP、UPnP、NFS、CIFS和AppleTalk)中的任何协议的通信。网络可以是例如局域网、广域网、虚拟专用网络、互联网、内联网、外联网、公共交换电话网、红外网络、无线网络及其任何组合。

在利用网络服务器的示例中，网络服务器可运行各种服务器或中间层应用中的任何一者，包括HTTP服务器、FTP服务器、CGI服务器、数据服务器、Java服务器和业务应用服务器。服务器还能够执行程序或脚本以响应来自用户设备的请求，诸如通过执行一个或多个应用程序，该一个或多个应用程序可被实现为一个或多个脚本或用任何编程语言编写的程序，该编程语言诸如C、C#或C++或任何脚本语言诸如Perl、Python或TCL以及它们的组合。服务器还可包括数据库服务器，包括但不限于可从/>和商购获得的那些。

环境可包括各种数据存储库和其他存储器和存储介质，如上所述。这些可驻留在各个位置，诸如在一个或多个计算机本地的存储介质上或者远离网络上的任何或全部计算机的存储介质上(和/或驻留在一个或多个计算机中)。在特定的一组示例中，信息可驻留在本领域的技术人员熟悉的存储区域网络(SAN)中。类似地，用于执行归属于计算机、服务器或其他网络设备的功能的任何必要文件可以根据需要本地存储以及/或者远程存储。在系统包括计算机化设备的情况下，每个此类设备可包括可经由总线电耦接的硬件元件，这些元件包括例如至少一个中央处理单元(CPU)、至少一个输入设备(例如，鼠标、键盘、控制器、触摸屏、键盘)和至少一个输出设备(例如，显示设备、打印机、扬声器)。此类系统还可包括一个或多个存储设备，诸如磁盘驱动器、光存储设备和固态存储设备，诸如RAM或ROM，以及可移除媒体设备、存储卡、或闪存卡。

此类设备还可包括如上所述的计算机可读存储介质读取器、通信设备(例如，调制解调器、网卡(无线或有线)、红外通信设备)和工作存储器。计算机可读存储介质读取器可连接至或配置为接收表示远程、本地、固定和/或可移除的存储设备的非暂态计算机可读存储介质，以及用于临时和/或更永久地包含、存储、传输和检索计算机可读信息的存储介质。系统和各种设备通常还包括位于至少一个工作存储器设备内的多个软件应用程序、模块、服务或其他元件，包括操作系统和应用程序诸如客户端应用程序或浏览器。应当理解，另选的示例可具有上文所述的许多变型形式。例如，还可使用定制硬件，和/或可在硬件、软件(包括便携式软件，诸如小应用程序)或两者中实现特定元件。此外，可使用与其他计算设备诸如网络输入/输出设备的连接。

用于包含代码或代码的部分的非暂态存储介质和计算机可读介质可包括本领域中已知的或使用的任何适当的介质，包括存储介质，诸如但不限于易失性和非易失性、可移除和不可移除介质，这些介质可在任何方法或技术中实现以用于存储信息如计算机可读指令、数据结构、程序模块或其他数据，包括RAM、ROM、EEPROM、闪存存储器或其他存储器技术、CD-ROM、DVD或其他光学存储装置、磁带盒、磁带、磁盘存储装置或其他磁存储设备，或者可用于存储所需信息并可由系统设备访问的任何其他介质。至少部分地基于本文所提供的公开和教导内容，本领域的普通技术人员将理解用于实现各种示例的其他方式和/或方法。

相应地，说明书和附图应被视为具有例示性的而非限制性的意义。然而，显而易见的是，在不脱离权利要求中阐述的本公开的更广泛的实质和范围的情况下，可对其进行各种修改和改变。

其他变型形式在本公开的实质内。因此，尽管所公开的技术容易受到各种修改和另选构造的影响，但是其某些例示的示例在附图中示出并且已经在上文详细描述。然而，应当理解，并不旨在将本公开限制于所公开的特定形式，相反，其目的在于覆盖落入由所附权利要求所限定的本公开的实质和范围内的所有修改、另选构造和等同形式。

在描述所公开的示例的上下文中(特别是在下面的权利要求书的上下文中)使用术语“一”和“一个”和“该”以及类似的指示词将被解释为覆盖单数和复数，除非另有说明或与上下文明显矛盾。除非另外指出，否则术语“包括(comprising)”、“具有”、“包括(including)”和“含有”应被理解为开放性术语(即，意指“包括但不限于”)。术语“连接”被解释为即使有干预的东西，也被部分或全部地包含在内、附接或接合在一起。除非本文另有说明，否则本文中对数值范围的叙述仅仅旨在用作单独提及落入该范围内的每个单独值的简单方法，并且每个单独的值被并入说明书中，如同在本文中单独引用。本文描述的所有方法能够以任何合适的顺序执行，除非本文另有说明或以其他方式与上下文明显矛盾。除非另有声明，否则本文提供的任何和所有示例或示例性语言(例如，“诸如”)的使用仅仅旨在更好地说明本公开的示例，并且不会限制本公开的范围。说明书中的任何语言都不应被解释为指示任何未声明的元素对于本公开的实践是必不可少的。

除非另外特别说明，否则析取语言诸如短语“X、Y或Z中的至少一者”在上下文中被理解为通常用于呈现项目、术语等，其可以是X、Y或Z，或它们的任何组合(例如，X、Y和/或Z)。因此，此类析取语言通常不旨在并且不应该暗示某些示例要求X中的至少一个、Y中的至少一个或者Z中的至少一个均各自存在。

本文描述了本公开的优选示例，包括发明人已知的用于执行本公开的最佳模式。在阅读前面的描述之后，那些优选示例的变型形式对于本领域的普通技术人员来说可变得显而易见。发明人期望技术人员适当地采用此类变型形式，并且发明人旨在以不同于本文具体描述的方式来实践本公开。因此，如适用法律所允许的，本公开包括所附权利要求中记载的主题的所有修改和等同形式。此外，除非在本文中另外指出或者明显与上下文矛盾，否则本公开包含上述元素的所有可能变型形式的任何组合。

本文引用的所有参考文献，包括出版物、专利申请和专利，均据此以引用方式并入本文，正如每篇参考文献被单独且具体地指示为以引用方式并入并且在本文全文阐述。

如上所述，本技术的一个方面在于采集和使用得自各种来源的数据，以向用户的个人健康记录提供全面且完整的窗口。本公开预期，在一些实例中，这些所采集的数据可包括唯一地识别或可用于联系或定位特定人员的个人可识别信息(PII)数据。此类个人信息数据可包括人口统计数据、基于位置的数据、电话号码、电子邮件地址、推特ID、家庭地址、与用户的健康或健身等级相关的数据或记录(例如，生命体征测量、药物信息、锻炼信息)、出生日期、健康记录数据、或任何其他识别信息或个人或健康信息。

本公开认识到在本发明技术中使用此类个人信息数据可用于使用户受益。例如，个人信息数据可以用于提供对用户的个人健康记录的增强。此外，本公开还预期个人信息数据有益于用户的其他用途。例如，健康和健身数据可用于向用户的总体健康状况提供见解，或者可用作使用技术来追求健康目标的个人的积极反馈。

本公开设想负责采集、分析、公开、传输、存储或其他使用此类个人信息数据的实体将遵守既定的隐私政策和/或隐私实践。具体地，此类实体应当实行并坚持使用被公认为满足或超出对维护个人信息数据的隐私性和安全性的行业或政府要求的隐私政策和实践。用户可以方便地访问此类策略，并应随着数据的采集和/或使用变化而更新。来自用户的个人信息应当被收集用于实体的合法且合理的用途，并且不在这些合法使用之外共享或出售。此外，应在收到用户知情同意后进行此类采集/共享。另外，此类实体应考虑采取任何必要步骤，保卫和保障对此类个人信息数据的访问，并确保有权访问个人信息数据的其他人遵守其隐私政策和流程。另外，这种实体可使其本身经受第三方评估以证明其遵守广泛接受的隐私政策和实践。另外，应当调整政策和实践，以便采集和/或访问的特定类型的个人信息数据，并适用于包括管辖范围的具体考虑的适用法律和标准。例如，在美国，对某些健康数据的收集或获取可能受联邦和/或州法律的管辖，诸如健康保险流通和责任法案(HIPAA)；而其他国家的健康数据可能受到其他法规和政策的约束并应相应处理。因此，在每个国家应保持不同的个人数据类型的不同的隐私实践。

不管前述情况如何，本公开还预期用户选择性地阻止使用或访问个人信息数据的实施方案。即本公开预期可提供硬件元件和/或软件元件，以防止或阻止对此类个人信息数据的访问。例如，就广告递送服务或与健康记录管理相关的其他服务而言，本发明技术可被配置为在注册服务期间或之后任何时候允许用户选择“选择加入”或“选择退出”参与对个人信息数据的收集。除了提供“选择加入”和“选择退出”选项外，本公开还设想提供与访问或使用个人信息相关的通知。例如，可在下载应用时向用户通知其个人信息数据将被访问，然后就在个人信息数据被应用访问之前再次提醒用户。

此外，本公开的目的是应管理和处理个人信息数据以最小化无意或未经授权访问或使用的风险。一旦不再需要数据，通过限制数据收集和删除数据可最小化风险。此外，并且当适用时，包括在某些健康相关应用中，数据去标识可用于保护用户的隐私。在适当的情况下，可以通过移除特定标识符(例如，出生日期)、控制存储的数据的量或特征(例如，在城市级而非地址级收集位置数据)、控制数据的存储方式(例如，在用户之间聚合数据)和/或其他方法来促进去标识。

因此，虽然本公开广泛地覆盖了使用个人信息数据来实现一个或多个各种所公开的实施方案，但本公开还预期各种实施方案也可在无需访问此类个人信息数据的情况下被实现。即，本发明技术的各种实施方案不会由于缺少此类个人信息数据的全部或一部分而无法正常进行。

Claims (15)

1.一种计算机实现的方法，包括：

由用户设备从电子健康记录EHR系统接收健康数据；

接收与定制所述健康数据的一部分相关的定制请求；

至少部分地基于所述定制请求生成个性化数据图的用户域概念UDC节点，所述UDC节点包括表示所述健康数据的经定制的部分的定制信息；

至少部分地基于生成所述UDC节点，更新所述UDC节点以包括表示所述UDC节点与所述健康数据的所述部分之间的关系的关系信息；以及

在所述用户设备处填充用户界面，所述用户界面包括所述UDC节点的表示。

2.根据权利要求1所述的计算机实现的方法，其中所述健康数据的所述部分包括多个健康数据样本，并且其中所述UDC节点包括与所述多个健康数据样本中的每个健康数据样本的单独的连接。

3.根据权利要求1所述的计算机实现的方法，还包括：

在接收到所述健康数据之后，索引所述健康数据，以将参考编码分配给所述健康数据的单独的部分，并且其中更新所述UDC节点以包括所述关系信息包括：更新所述UDC节点以包括分配给所述健康数据的所述部分的参考编码。

4.根据权利要求1所述的计算机实现的方法，其中所述定制请求包括以下中的至少一者：最爱所述健康数据的所述部分的请求、给予所述健康数据的所述部分别名的请求、将所述健康数据的所述部分添加到列表的请求、将所述健康数据与其他健康数据组合的请求、将所述UDC节点与所述个性化数据图的一个或多个其他UDC节点连接的请求。

5.根据权利要求1所述的计算机实现的方法，还包括：

在所述个性化数据图的多个其他UDC节点与所述UDC节点之间建立多个连接；

移除所述其他UDC节点中的至少一个其他UDC节点与所述UDC节点之间的所述多个连接中的一个连接；以及

响应于移除所述一个连接，使得所述UDC节点与所述多个其他UDC节点同步。

6.根据权利要求1所述的计算机实现的方法，还包括：

通过至少确定从所述健康数据识别的医学概念与参考本体的参考节点之间的映射来生成个性化数据图的概念节点；以及

接收与定制所述概念节点的方面相关的不同的定制请求；

至少部分地基于所述不同的定制请求生成所述个性化数据图的不同的UDC节点，所述不同的UDC节点包括表示所述概念节点的经定制的方面的不同的定制信息；以及

至少部分地基于生成所述不同的UDC节点，更新所述概念节点以包括表示所述概念节点与所述不同的UDC节点之间的关系的关系信息。

7.一种或多种非暂态计算机可读介质，所述非暂态计算机可读介质包括计算机可执行指令，所述计算机可执行指令在由用户设备的一个或多个处理器执行时，使所述用户设备执行包括以下的操作：

由所述用户设备从电子健康记录EHR系统接收健康数据；

接收与定制所述健康数据的一部分相关的定制请求；

至少部分地基于所述定制请求生成个性化数据图的用户域概念UDC节点，所述UDC节点包括表示所述健康数据的经定制的部分的定制信息；

至少部分地基于生成所述UDC节点，更新所述UDC节点以包括表示所述UDC节点与所述健康数据的所述部分之间的关系的关系信息；以及

在所述用户设备处填充用户界面，所述用户界面包括所述UDC节点的表示。

8.根据权利要求8所述的一种或多种非暂态计算机可读介质，其中所述定制请求包括以下中的至少一者：最爱所述健康数据的所述部分的请求、给予所述健康数据的所述部分别名的请求、将所述健康数据的所述部分添加到列表的请求、将所述健康数据与其他健康数据组合的请求、将所述UDC节点与所述个性化数据图的一个或多个其他UDC节点连接的请求。

9.根据权利要求8所述的一种或多种非暂态计算机可读介质，还包括附加的计算机可执行指令，所述附加的计算机可执行指令在由所述一个或多个处理器执行时，使所述用户设备执行包括以下的附加操作：

在所述个性化数据图的多个其他UDC节点与所述UDC节点之间建立多个连接；

移除所述其他UDC节点中的至少一个其他UDC节点与所述UDC节点之间的所述多个连接中的一个连接；以及

响应于移除所述一个连接，使所述UDC节点与所述多个其他UDC节点同步。

10.根据权利要求8所述的一种或多种非暂态计算机可读介质，还包括附加的计算机可执行指令，所述附加的计算机可执行指令在由所述一个或多个处理器执行时，使所述用户设备执行包括以下的附加操作：

通过至少确定从所述健康数据识别的医学概念与参考本体的参考节点之间的映射生成个性化数据图的概念节点；以及

接收与定制所述概念节点的方面相关的不同的定制请求；

至少部分地基于所述不同的定制请求生成所述个性化数据图的不同的UDC节点，所述不同的UDC节点包括表示所述概念节点的经定制的方面的不同的定制信息；以及

至少部分地基于生成所述不同的UDC节点，更新所述概念节点以包括表示所述概念节点与所述不同的UDC节点之间的关系的关系信息。

11.一种用户设备，包括：

存储器，所述存储器被配置为存储计算机可执行指令；和

处理器，所述处理器被配置为访问所述存储器并执行所述计算机可执行指令以至少执行以下操作：

从电子健康记录EHR系统接收健康数据；

接收与定制所述健康数据的一部分相关的定制请求；

至少部分地基于所述定制请求生成个性化数据图的用户域概念UDC节点，所述UDC节点包括表示所述健康数据的经定制的部分的定制信息；

至少部分地基于生成所述UDC节点，更新所述UDC节点以包括表示所述UDC节点与所述健康数据的所述部分之间的关系的关系信息；以及

填充用户界面，所述用户界面包括所述UDC节点的表示。

12.根据权利要求15所述的用户设备，其中所述健康数据与所述用户设备的用户配置文件相关联。

13.根据权利要求15所述的用户设备，其中所述健康数据的所述部分包括多个健康数据样本，并且其中所述UDC节点包括与所述多个健康数据样本中的每个健康数据样本的单独的连接。

14.根据权利要求15所述的用户设备，其中所述存储器包括附加的计算机可执行指令，并且所述处理器被进一步配置为执行所述附加的计算机可执行指令，所述附加的计算机可执行指令用于至少在接收到所述健康数据之后，索引所述健康数据，以将参考编码分配给所述健康数据的单独的部分，并且其中更新所述UDC节点以包括所述关系信息包括：更新所述UDC节点以包括分配给所述健康数据的所述部分的参考编码。

15.根据权利要求15所述的用户设备，其中所述存储器包括附加的计算机可执行指令，并且所述处理器被进一步配置为执行所述附加的计算机可执行指令，从而至少执行以下操作：

在所述个性化数据图的多个其他UDC节点与所述UDC节点之间建立多个连接；

移除所述其他UDC节点中的至少一个其他UDC节点与所述UDC节点之间的所述多个连接中的一个连接；以及

响应于移除所述一个连接，使所述UDC节点与所述多个其他UDC节点同步。