CN107533555A - 用于控制针对数据拥有者选择的接收者的许可的系统和方法 - Google Patents

Abstract

描述了一种在系统中控制由数据拥有者向所选择的接收者授予许可的方法。该方法包括：标识由组织的管理员接受的许可，如果邀请来自数据的特定拥有者，则组织具有所述许可；发送电子通信，所述电子通信至少包括来自拥有者中的每一个的邀请以及与组织的管理员对应的许可的组合；以及接收拥有者中的每一个向一个或多个组织定义的访问组的分配。该方法还包括：接收所选择的工作人员向多个角色的分配；以及根据具有特定拥有者和所选择的工作人员的一个或多个访问组并且根据具有所选择的工作人员的特定拥有者的多个角色来针对拥有者中的每一个向所选择的工作人员授予特定许可。

Description

用于控制针对数据拥有者选择的接收者的许可的系统和方法

技术领域

该技术涉及控制拥有者数据的共享，并且特别涉及以数据的低粒度级别为所选择的接收者提供许可。

背景技术

医疗记录和电子医疗记录领域得到广泛应用。不幸的是，它也是非常分散的，其中患者数据源自手写和打字备注、录音和各种计算机格式。

医生和其他医疗护理专业人员被迫阅读多页数据，并在思想上构建什么正在发生、事件的顺序以及试图将药物或治疗改变与患者生理测量或症状的改变相关联的图片。

现有技术不能为医生提供一种方式来一目了然地看到患者的相关数据的清晰的时间相关视图。

经常经历的问题是：浪费时间、需要更多的专业知识和培训来阅读患者图表、以及包括经常导致严重伤害或生命损失的错误的错误。

许多健康信息技术软件应用和项目已经表明，简单地协调或合并信息系统不一定足以提高临床医生和其他医疗护理专业人员和用户正在访问的信息的质量。根本的问题是对于患者的整个护理团队需要访问大量数据，但是主要需要数据以更有用的方式被总结和呈现。如果数据没有被合适的总结和容易被理解，医疗护理专业人员将不可能有效地利用它。

当前的系统使得没有人看到整个信息图片。信息被分散在许多地方和并以许多形式被分散。经常存在阻止访问或共享数据的数据孤岛。在医疗护理领域，许多医疗护理系统与其他医疗护理系统无法沟通。因此，在特别是由可以被认为是拥有数据的患者访问患者的数据方面存在困难。此外，在美国存在与HIPAA有关的隐私问题。另一个当前的困难是不同的护理实体不在相同页面上。护理团队之间缺乏有效的沟通。在传统医学文化中，信息流是自上而下的。因此，患者仍然不能完全了解他们的健康状况，不能有效地将他们的健康故事传送给他人。所期望的是其中患者健康故事的合法所有权属于消费者的系统，然后患者可以向医生、专家和医院授予访问。

发明内容

在一个方面，存在一种在系统中控制由数据的拥有者对所选择的接收者授予许可的方法，所述系统至少包括多个计算设备、服务器、网络和数据库，所述方法包括在服务器处从被存储在数据库的拥有者的电子日记部分中的数据的拥有者来接收电子认证；在服务器处接收电子地址，所述电子地址与将被邀请以访问由所述拥有者控制的数据的指定类别的一个或多个期望的接收者中的每一个相对应；标识所述一个一个或多个接收者在所述邀请被接受的情况下将具有的特定许可，其中许可提供用于执行一个或多个指定动作的能力；经由计算机网络向所述一个或多个期望的接收者发送电子通信，其中每个电子通信包括用于回复所述通信的专用统一资源定位符；经由计算机网络从所述一个或多个接收者中的每一个接收包括对所述邀请的接受或拒绝的电子消息；以及在数据结构中存储所述一个或多个接收者中的每一个的标识符、所述邀请的所述接受或拒绝的指示符、以及在所述邀请被接受的情况下向所述一个或多个接收者中的每一个所授予的许可的对应的组合，以便促进对所述拥有者的数据的拥有者控制的电子访问。

如果所述接收者中的一个是组织，则接收一个或多个电子消息，所述一个或多个电子消息标识针对所述拥有者和一个或多个工作人员的一个或多个特定接入组、以及针对所述一个或多个工作人员和对应的数据类别的一个或多个角色，针对所述对应的数据类别所述特定许可被授予。只有在所述拥有者和特定工作人员共享公共访问组时，该工作人员才能够访问日记。特定工作人员基于来自所述工作人员属于的所有角色的累积许可来访问日记。特定许可被限于从所述拥有者的帐户被给予所述组织的那些许可。角色是组织定义的许可的组合。访问组是用于链接工作人员和拥有者的组织定义的组。

该方法还可以包括从所述拥有者接收电子请求以在没有特定接收者的同意的情况下添加或移除许可。所述方法还包括由所选择的所述接收者的所授权的所述许可的使用，包括从所述接收者中的特定接收者接收对拥有者数据的图形显示的请求；确定针对特定接收者的累积许可，其中如果所述特定接收者是组织的一部分，则所述确定还包括确定所述特定接收者是否与和拥有者所共享的访问组相关联；取回所述拥有者的电子日记中的由所述累积许可标识的数据；以及生成所取回的所述数据的基于HTML的屏幕显示。该方法还可以包括从所述特定接收者接收导航请求以操纵所述基于HTML的屏幕显示。该方法还可以包括从接收者中的特定的接收者接收导航请求以用于操纵基于HTML的屏幕显示。屏幕显示可以包括如下类别的数据，接收者中的特定接收者针对该类别具有许可，并且其中屏幕显示指示如下类别，所述接收者中的特定接收者针对该类别不具有许可。生成基于HTML的屏幕显示包括对与累积许可相对应的每个类别应用一个或多个控件，其中针对每个被许可的类别的控件可以独立于针对其他被许可的类别的控件。生成基于HTML的屏幕显示包括基于来自单个类别的数据来应用一个或多个预定义的模板化的时间轴视图。生成基于HTML的屏幕显示可以包括基于来自多个类别的数据来应用一个或多个预定义的模板化的时间轴视图。如果预定义的模板时间轴视图要求访问来自对于所述用户不被许可的类别的数据，则视图不被显示，并且用户被通知。该方法可以进一步包括接收针对时间轴显示的请求，所述时间轴显示包括从日、周、月或年中的聚集级别选择以及对应于聚集级别选择的开始日期或结束日期；以及根据所接收的请求来呈现具有两个行部分的日历栏，其中所述底行部分根据与所述聚集级别选择对应的开始日期或结束日期来显示具有日期的一系列块，并且其中所述顶行部分在所选择的聚集级别处显示一系列点，其中亮点表示在所选择的聚集级别处的针对时段的拥有者数据的缺失，而暗点表示针对该时段的拥有者数据的存在。所述日历栏的所述顶行部分进一步在与所述底行部分中的所述日期相对应的点上显示突出显示的块，并且其中如果光标被移动到悬停在所述顶行部分的另一部分上，则与悬停光标的位置相对应的另一个突出显示的块，其中如果在悬停的光标的位置处接收到点击事件，则所述时间轴根据所选择的聚集级别来显示与所述点击的所述日期相对应的数据。

数据的类别可以包括药物、锻炼、睡眠、疾病和性健康。数据的类别可以包括医疗记录、症状和/或命脉体征、药物和/或实验室结果、情感、生活事件、遗传标记和生活方式。接收者可能是访问者、工作人员和拥有者/访问者之一。所述访问者可以是具有读取和/或写入特权的访客、和具有完全拥有者特权的监护人之一。工作人员可能是属于组织的用户。所述拥有者/访问者可以是具有日记的拥有者并且还已经被给予对另一个拥有者的日记的访问的用户。许可状态可能包括被给予、被接收和被接受。许可类型可能包括读取、写入和无访问。该方法还可以包括接收电子消息，该电子消息包括对所接收的邀请的接受或拒绝的确认或取消。

在另一方面，存在一种在系统中控制由由数据的拥有者对所选择的接收者授予许可的方法，所述系统至少包括多个计算设备、服务器和网络的系统，所述方法包括：标识在来自所述数据的特定拥有者的邀请被组织的管理员接受的情况下所述组织具有的许可，其中许可提供用于执行一个或多个指定动作的能力；经由计算机网络发送电子通信，所述电子通信至少包括邀请、对所述组织的所述管理员的许可的所述组合、以及用于回复所述电子通信的专用的统一资源定位符；接收所述特定拥有者对组织定义的访问组的分配；接收所述特定拥有者和所述组织的一个或多个所选择的工作人员到所述访问组的映射，用于链接所述特定拥有者和所选择的工作人员；接收与所述组织的所述工作人员相对应的至少一个角色的标识；接收所述组织中的所述一个或多个所选择的工作人员到所述至少一个角色的分配；根据具有所述特定拥有者和所选择的工作人员的所述特定访问组并且根据具有所选择的工作人员的所述至少一个角色来向针对所述特定拥有者的所选择的工作人员授予特定许可；以及在数据结构中存储所述邀请的所述接受或拒绝的指示符、所选择的工作人员中的每一个的标识符、以及与所选择的工作人员中的每一个对应的被授予的许可的组合，以便于促进对所述拥有者的数据的拥有者控制的电子访问。

只有拥有者和工作人员共享公共访问组时，特定工作人员才可以访问拥有者的日记。特定工作人员可以基于来自所述工作人员属于的所有角色的所述累积许可来访问拥有者的日记。特定许可被限于从拥有者的帐户给予组织的那些许可。角色可能是组织定义的许可的组合。

该方法还可以包括由所选择的工作人员的所授权的许可的使用，包括从工作人员中的特定一个接收对拥有者数据的图形显示的请求；确定针对所述特定工作人员的累积许可，其中所述确定还包括确定所述特定工作人员是否与和拥有者所共享的访问组相关联；取回拥有者的电子日记中的由累积许可标识的数据；以及生成所取回的数据的基于HTML的屏幕显示。该方法还可以包括接收特定工作人员导航请求以用于操纵基于HTML的屏幕显示。工作人员可以是属于组织的用户，包括医生、护士、技术人员、药剂师和管理员之一。许可类型可能包括读取、写入和无访问。角色还包括所选择的数据类别，对应的工作人员具有对所述类别的访问，其中数据的类别包括医疗记录、症状和/或命脉体征、药物和/或实验室结果、情感、生活事件、遗传标记和生活方式。

在另一方面，存在一种在系统中控制由拥有者日记中布置的数据的拥有者向所选择的接收者授予许可的方法，所述系统至少包括多个计算设备、服务器、和网络，所述方法包括：标识在来自所述数据的特定拥有者的邀请被组织的管理员接受的情况下组织将具有的许可，其中许可提供用于执行一个或多个特定动作的能力；经由计算机网络发送电子通信，所述电子通信至少包括来自所述拥有者中的每一个的邀请以及与所述组织的所述管理员对应的许可的组合，其中每个电子通信包括用于回复所述通信的专用统一资源定位符；接收所述拥有者中的每一个到一个或多个组织定义的访问组的分配；接收特定拥有者和所述组织的一个或多个所选择的工作人员到一个或多个访问组的映射，以链接所述特定拥有者和所选择的工作人员；接收与所述组织的所述工作人员相对应的至少一个角色的标识；接收所述组织中的所述一个或多个所选择的工作人员到所述至少一个角色的分配；根据具有特定拥有者和所选择的工作人员的一个或多个访问组并且根据具有所选择的工作人员的所述特定拥有着的所述至少一个角色来针对所述拥有者中的每一个向所选择的工作人员授予特定许可；以及在数据结构中存储针对所述拥有者中的每一个的所述邀请的接受或拒绝的指示符、所选择的工作人员中的每一个的标识符、以及与针对每一个拥有者所选择的工作人员中的每一对应的被授予的许可的组合，以便于促进对每个拥有者的数据的拥有者控制的电子访问。

只有当所述对应的特定拥有者和所述工作人员共享公共访问组时，特定工作人员才能够访问特定的日记。特定工作人员基于来自所述工作人员属于的所有角色的所述累积许可来访问特定日记。特定许可被限于从对应的拥有者的帐户给予组织的那些许可。角色可以是组织定义的许可的组合。

该方法还可以包括由所选择的工作人员的所授权的许可的使用，包括：从所述工作人员中的特定工作人员接收对特定拥有者的数据的图形显示的请求，其中所述数据被分组在多个类别中；确定所述特定工作人员是否与和所述特定拥有者所共享的访问组相关联；如果所述特定工作人员与和所述特定拥有者所共享的访问组相关联，则确定来自针对所述特定工作人员的角色的累积许可；确定所述累积许可中的哪一个所述组织已经由所属拥有者授予许可；取回所述特定拥有者电子日记中的由所述累积许可所标识的数据；以及生成所取回的数据的基于HTML的屏幕显示。该方法还可以包括接收来自特定工作人员的导航请求以操纵基于HTML的屏幕显示。屏幕显示可以包括针对如下述类别的数据，特定工作人员具有针对所述类别的数据的许可，并且其中屏幕显示可以指示如下类别，特定工作人员没有针对所述类别的数据的许可。工作人员可以是属于组织的用户，包括医生、护士、技术人员、药剂师和管理员之一。

许可类型可以包括读取、写入和无访问。与角色相关联的可以是如下数据的类别，对应的工作人员具有对所述数据的类别的访问，其中数据类别可以包括医疗记录、症状和/或命脉体征、药物和/或实验室结果、情感、生活事件、遗传标记和生活方式。与角色相关联的是如下数据的类别，对应的工作人员具有对数据的类别的访问，其中数据的类别可能包括身体测量、临床备注、日记备注、饮酒、环境、感觉、免疫、实验室结果、生活事件、药物、情绪、营养、疼痛、患者压力、身体活动、睡眠、吸烟、症状、治疗和命脉体征。生成基于HTML的屏幕显示包括对与授予的许可相对应的每个类别应用一个或多个控件，其中每个被许可的类别的控件独立于其他被许可的类别的控件。控件可能包括对所取回的数据进行排序、查看、着色和过滤的选择。控件可以包括用于显示所取回的数据的列表格式和图形格式。生成基于HTML的屏幕显示可以包括基于来自单个类别的数据来应用一个或多个预定义的模板时间轴视图。生成基于HTML的屏幕显示可以包括基于来自多个类别的数据来应用一个或多个预定义的模板化时间轴视图。如果预定义的模板化时间轴视图要求对来自用户不被许可的类别的数据的访问，则该视图可以不被显示，并且用户被通知。

该方法还可以包括生成所述人访问所述拥有者数据、每个人采取的动作、以及对所述日记的所述改变或添加的时间戳日记，如果有的话。

该方法还可以包括扫描对应于特定拥有者的源文档；从所扫描的文档中提取医学数据，包括对源文档的引用；将源文档存储在电子存储装置中；并且基于所提取的数据的类别来将所提取的医学数据和对源文档的引用存储在特定日记中，其中所存储的引用使得查看所提取的数据的用户能够导航到源文档并查看源文档。源文档可以以特定网页的分辨率存储。所提取的数据可以在时间轴或数据的其他显示页面上查看。

所述方法还可以包括接收针对特定日记的所选择的类别中的数据项的选择；激活所选择的类别中的控件以发起源文档链接处理；向所述电子存储装置显示用户界面；通过要链接到数据项的源文档的所述界面的使用来接收选择；以及将针对所述数据项的所述链接记录在所述特定日记中。

数据的类别可以包括临床数据生活方式数据、心理社会数据、环境数据和遗传数据。

在又一方面，存在一种在系统中控制由数据的拥有者向所选择的接收者授予许可的方法，所述系统至少包括多个计算设备、服务器、和网络，所述方法包括：标识在来自所述数据的特定拥有者的邀请被组织的管理员接受的情况下所述组织具有的许可，其中许可提供执行一个或多个指定动作的能力；经由计算机网络发送电子通信，所述电子通信至少包括所述邀请、对所述组织的所述管理员的许可的所述组合、以及用于回复所述电子通信的专用的统一资源定位符；接收所述特定拥有者对组织定义的访问组的分配；接收所述特定拥有者和所述组织的一个或多个所选择的工作人员到所述访问组的映射，以链接所述特定拥有者和所选择的工作人员；接收所述组织的所述一个或多个所选择的工作人员对至少一个组织角色的分配；根据具有所述特定拥有者和所选择的工作人员的所述特定访问组以及根据具有所选择的工作人员的所述至少一个角色来针对所述特定拥有者向所选择的工作人员授予特定许可；在数据结构中存储所述邀请的所述接受或拒绝的指示符、所选择的工作人员中的每一个的标识符、以及与所选择的工作人员中的每一个的对应的被授予的许可的组合；从具有对应的被授予写入许可的第一用户接收对所述拥有者的数据或新数据的编辑；跟踪所述第一用户的身份、所述编辑或新数据的时间和日期、更新的类型或类别、以及数据库中的所述编辑或新数据；以及改变针对所更新的拥有者数据的版本标识符。

该方法还可以包括确定自从所述拥有者的数据被所述第一用户取回，所述拥有者的数据是否已被第二用户修改；以及通知所述第一个用户所述更新不被允许。确定自从所述拥有者的数据被取回所述拥有者的数据是否已被修改包括：确定所修改的条目是否是所述最新版本。拥有者的数据可能是医疗或健康相关数据。更新对于每个后续用户是可见的，所述后续用户具有对应授权的许可以访问具有所改变的版本标识符的拥有者的数据。

所述方法还可以包括向用户显示针对所编辑的所述拥有者的数据的先前版本的改变历史，所述用户具有对于与所编辑的所述数据对应的数据的类别的适当读取许可。

在另一方面，存在一种用于由数据拥有者控制向所选择的接收者授予许可的系统，其中所述系统至少包括多个客户端计算设备、服务器和数据库，所述系统包括：用于在服务器处从客户端计算设备接收电子认证的部件，所述客户端计算设备与被存储在数据库的拥有者的电子日记部分中的数据的拥有者对应；用于在服务器处接收电子地址的部件，所述电子地址与将被邀请以访问由拥有者控制的数据的指定类别的的一个或多个期望的接收者客户端计算设备中的每一个对应；用于标识所述一个或多个接收者在所述邀请被接受的情况下将具有的特定许可的部件，其中许可提供用于执行一个或多个指定动作的能力；用于向所述一个或多个期望的接收者客户端计算设备发送电子通信的部件，其中每个电子通信包括用于回复所述通信的专用统一资源定位符；用于从所述一个或多个接收者客户端计算设备中的每一个接收包括邀请的接受或拒绝的电子消息的部件；以及用于存储以下信息以便于促进对所述拥有者的数据的受拥有者控制的电子访问的部件：一个或多个接收者中的每一个接收者的标识符、对邀请的接受或拒绝的指示符、以及在邀请被接受的情况下一个或多个接收者中的每一个被授予的许可的对应的组合。

数据的特定拥有者可以具有与特定拥有者相对应的多个客户端计算设备。

在另一方面，存在一种用于控制由拥有者日记中布置的数据的拥有者向所选择的接收者授予许可的系统，其中所述系统包括至少多个客户端计算设备和服务器，所述系统包括：用于标识在来自所述数据的特定拥有者的邀请被组织的管理员接受的情况下所述组将具有的许可的部件，其中许可提供用于执行一个或多个指定动作的能力；用于发送电子通信的部件，所述电子通信至少包括来自与所述拥有者中的每一个对应的客户端计算设备的邀请以及与对所述组织的所述管理员对应的许可的组合，其中每个电子通信包括用于回复所述通信的专用的统一资源定位符；用于接收所述拥有者中的每一个对一个或多个组织定义的访问组的分配的部件；用于接收特定拥有者和所述组织的一个或多个所选择的工作人员到用于链接所述特定拥有者和所选择的工作人员的一个或多个访问组的映射的部件；用于接收与所述组织的所述工作人员相对应的至少一个角色的标识的部件；用于接收所述组织的所述一个或多个所选择的工作人员向至少一个角色的分配的部件；用于根据具有特定拥有者和所选择的工作人员的一个或多个访问组，以及根据具有所选择的工作人员的特定拥有者的至少一个角色，针对所述拥有者中的每一个向所选择的工作人员授予特定许可的部件；以及用于存储针对拥有者中的每一个的所述邀请的所述接受或拒绝的指示符、所选择的工作人员中的每一个的标识符、以及针对每个拥有者志所选择的工作人员中的每一个对应的被授予的许可的组合以便于促进对每个拥有者的数据的拥有者控制的电子访问的部件。

数据的特定拥有者可以具有与特定拥有者对应的多个客户端计算设备。

附图说明

在某些实施例中，数据的拥有者可以是医疗护理患者。因此，在附图指示患者的情况下，其说明了拥有者的实例。

图1是用于创建、维护和利用终身健康日记的系统工具的实施例的示例的示意图。

图2A是图1中所示的终身健康日记工具的系统配置的实施例的示例的示意图。

图2B是图2A中所示的电子存储装置的实施例的示例的示意图。

图2C是图2B中所图示的数据仓数据库、核心数据库和数据仓文件存储装置之间的交互的实施例的示例的示意图。

图3是处理特定患者的医疗信息的实施例的示例的示意图。

图4是图3中所图示的数据源和结构化部分的实施例的示例的示意图。

图5是介绍日记的许可的示意图。

图6是图示从患者帐户向拥有者/访问者、访客和组织的工作人员给出的许可的示意图。

图7是图示可以给予许可的示例方的示意图。

图8是图示针对许可的给予的组织概念的示意图。

图9是图示工作人员和角色之间的关系的示意图。

图10是图示工作人员、访问组和拥有者之间的关系的示意图。

图11是图示工作人员访问拥有者帐户的示意图。

图12是图示邀请处理的实施例的概述的示意图。

图13是图示处理纸质文档的实施例的流程图。

图14是图示链接文档的实施例的流程图。

图15是图示访问数据仓的屏幕显示的示例。

图16是图示用于数据仓的上传屏幕的屏幕显示的示例。

图17是图示用于数据仓的用户选项的屏幕显示的示例。

图18是图示拥有者和访客之间的邀请流程的示意图。

图19是图示邀请访客的处理的实施例的流程图。

图20是图示用于回复邀请的处理的实施例的流程图。

图21是图示拥有者邀请组织的处理的实施例的流程图。

图22是图示授权访问日记的处理的实施例的流程图。

图23是图示用于查看当前邀请的屏幕以及在邀请处理中要进行的新邀请的屏幕显示的示例。

图24是图示用于输入关于访客的信息和对访客的授权的许可的界面屏幕的屏幕显示的示例。

图25是图示示例电子邮件邀请的屏幕显示的示例。

图26是图示诸如使用图23的显示所取回的邀请细节的屏幕显示的示例。

图27是图示其中完成的邀请可以由拥有者和访客查看的邀请完成屏幕的屏幕显示的示例。

图28是图示访客对拥有者帐户的活动的审核的屏幕显示的示例。

图29是屏幕显示的示例，其图示已经对特定访客给予访问他们的日记的拥有者的概述。

图30是图示当用户期望更新分配给访客的许可时由用户(例如拥有者)看到的界面屏幕的屏幕显示的示例。

图31是图示当用户期望向组织中的角色分配许可时由用户(例如，拥有者)看到的界面屏幕的屏幕显示的示例。

图32是图示当组织的管理员期望管理组织中的角色时由组织中的管理员看到的界面屏幕的屏幕显示的示例。

图33是图示当组织的管理员期望创建组织中的角色时由组织的管理员看到的界面屏幕的屏幕显示的示例。

图34是图示由可以对组织中的对应角色执行的操作的组织的管理员看到的界面屏幕的屏幕显示的示例。

图35是图示由组织的管理员在管理工作人员中看到的界面屏幕的屏幕显示的示例。

图36是图示由组织的管理员看到的用于管理对组织角色的角色许可的界面屏幕的屏幕显示的示例。

图37是图示由组织的管理员看到的用于管理对日记访问角色的角色许可的界面屏幕的屏幕显示的示例。

图38是图示由组织的管理员看到的用于管理拥有者组所看到的界面屏幕的屏幕显示的示例。

图39是图示由组织管理员看到的用于输入新组的名称和描述的屏幕的屏幕显示的示例。

图40是图示由组织的管理员看到的用于显示可以对对应组执行的操作的界面屏幕的屏幕显示的示例。

图41是图示由组织的管理员看到的用于选择对应组的拥有者的界面的屏幕显示的示例。

图42是图示组织的管理员看到的用于选择对应组的工作人员的界面的屏幕显示的示例。

图43是图示组织的管理员看到的用于编辑对应组的名称和描述的界面的屏幕显示的示例。

图44是图示用于确定是否要呈现用户界面元素的处理的实施例的流程图。

图45是图示用于基于许可来确定特定工作人员是否具有访问的处理的实施例的流程图。

图46是图示用于基于许可来确定特定访客是否具有访问的处理的实施例的流程图。

图47是图示由已经设置了如所图示的某些许可的拥有者所看到的界面屏幕的屏幕显示的示例。

图48是图示当拥有者点击加号图标以查看哪些模块他们可以添加数据时显示数据模块列表的界面的屏幕显示的示例。

图49是图示当访客对图48的日记执行相同动作但是它们的许可仅允许他们针对吸烟模块输入数据时显示限制于相关项的模块的列表的界面的屏幕显示的示例。

图50是图示在只有访客具有查看许可的模块是可选择的情况下由日记的访客看到的脉搏页面的界面的屏幕显示的示例。

图51是图示已经被选择但是由于许可限制而无法取回所有模块的数据并且显示了通知用户某些数据对他们不可用的有意义的消息的时间轴的界面屏幕的屏幕显示的示例。

图52是图示示出拥有者的数据的基于时间的摘要的时间轴页面的界面屏幕的屏幕显示的示例。用户可以选择要查看的模块(如果用户不是拥有者，则服从于许可)，并且每个模块都可以具有不同的控件。

图53是图示用于显示可以用于处理该模块的数据的每个模块的页面的界面的屏幕显示的示例。

图54是图示由用户看到的用于导航拥有者的时间轴的界面屏幕的一部分的屏幕显示的示例。

图55是图示用于示出可能的聚集级别的示例的时间轴的界面屏幕的日历栏部分的屏幕显示的示例。

图56是图示示出每周聚集级别的时间轴数据图的示例的时间轴的界面屏幕的一部分的屏幕显示的示例。

图57是图示示出具有两个控件的列表视图的身体活动或运动历史的示例小部件的界面屏幕的屏幕显示的示例。

图58是图示响应于包括所选择的运动类型的所选择的控件示出图形数据视图的示例小部件的界面屏幕的屏幕显示的示例。

图59是图示响应于包括所有运动类型的所选择的控件示出图形数据视图的示例小部件的界面屏幕的屏幕显示的示例。

图60是图示响应于所选择的控件以及其中每个小部件可以具有不同的控件示出列表视图的几个示例小部件的界面屏幕的屏幕显示的示例。

图61是图示例如用于我的健康喂食小部件的示例小部件设置和小部件显示以及用于身体活动小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。

图62是图示用于药物采取小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。

图63是图示例如用于睡眠小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。

图64是图示例如用于情绪小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。

图65是图示例如用于疼痛小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。

图66是图示例如用于身体测量小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。

图67是图示例如用于重要器官小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。

图68是图示例如用于食物和饮水小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。

图69是图示例如用于访问小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。

图70是图示用于编辑和版本跟踪的处理的实施例的流程图。

具体实施方式

介绍

以下本文描述的系统和方法可以在硬件和软件的各种配置上实现。该系统可以由以下讨论的各种模块、工具和应用组成。如本领域普通技术人员可以理解的，模块中的每一个可以包括各种子例程、过程、定义语句和宏。模块中的每一个通常单独被编译并链接到单个可执行程序中。因此，为了方便描述优选系统的功能，使用模块中的每一个的以下描述。因此，模块中每一个所经历的处理可以任意地被重新分配到其它模块中的一个，在单个模块中组合在一起，或者在例如可共享的动态链接库中可用。

系统模块、工具和应用可以用任何编程语言编写，例如C、C++、C#、BASIC、VisualBasic、Pascal、Ada、Java、HTML、XML或FORTRAN，并且在操作系统上被执行，诸如Windows、Macintosh、UNIX、Linux、VxWorks或其他操作系统的变体。C、C++、C#、BASIC、Visual Basic、Pascal、Ada、Java、HTML、XML和FORTRAN是行业标准编程语言，许多商业编译器可用于为行来标准编程语言创建可执行代码。

定义

以下提供在描述所公开的系统和方法的某些实施例中使用的术语的许多有用的可能定义。

基准：药物或治疗、症状、营养、生活方式或生活方式改变、事件、精神状态或生理测量或状况的记录，包括时间戳、符号、图标或表示事件的其他方式，加上关于患者状况或背景信息的诸如数值的可选字段。

数据：多个基准。

数据源：以任何格式(包括但不限于手写笔记、键盘笔记、图像、音频或视频录制、电子文件等)提供数据输入的任何方式，包括但不限于医疗护理专业人员、患者、软件程序、计算机文件或程序、医疗设备或传感器等。

结构化：将基准归一化为一致和标准化的记录格式。

跟踪：使用时间戳或结构化数据中的其他字段来查找数据之间的相关性、对数据之间的相关性执行计算、并基于数据之间的相关性、并且图形地显示数据之间的相关性。

变量：在临床试验，治疗改变、药物改变或其他测试或实验中，被故意改变的基准、而所有其他基准保持不变(在可行的范围内)。

数据符号：描绘基准的图形图标、加上可选的文本或包括但不限于时间戳、数值、价格等的附加信息的其他描述。

时间轴：通过其时间戳排序的多个特定类型的数据符号或包括但不限于药物或治疗或代码号的其他字段的图形描绘。

信息图表：表格、图表、矩阵或与从多个患者聚集的数据相对应的数据符号的其他表示的图形或文本描述，其按时间戳或包括但不限于以下各项的其他字段排序：年龄、性别、地点、工作、生活方式选择、生活事件、包括预先存在的条件的基本健康状况、遗传标识符、症状、治疗、药物或医护人员等。

呈现：显示多个时间轴或信息图，每个具有相同的起始和结束时间以及时间尺度。

分析：孤立地或与另一个基准或其他数据相关或多重相关地理解和考虑数据或基准的过程，以便更好地了解相关或因果关系。

警报：警报是实时风险评估、关键事件、提醒、合规指标、一般指标、药物和/或治疗的建议、转介给第三方或与提供医疗护理有关的信息。警报可以包括但不限于任何图形或文本内容，诸如图标、时钟面、VU表、气压计、温度计、文本等。

消息：消息是经由网络通过包括但不限于短消息服务(SMS)、即时消息、电子邮件、推特、戳、文本、自动或手动电话呼叫、视频、音频、任何形式的计算机中介通信或用于发送信息的任何其他格式等来发送警报。

路线：基于包括但不限于专门知识、与患者的关系、认证等因素来确定适当的护理团队成员、患者或其他相关第三方以及向该一方或多方发送消息的任何方式。

网络：网络可以指跨越任何地理区域的网络或网络的组合，诸如局域网(LAN)、广域网(WAN)、区域网络、国家网络和/或全球网络。因特网是当前全球计算机网络的一个示例。这些术语可以指硬线网络、无线网络或硬线和无线网络的组合。硬线网络可以包括例如光纤线路、电缆线路、ISDN线路、铜线路等。无线网络可以包括例如蜂窝系统、个人通信服务(PCS)系统、卫星通信系统、分组无线电系统、和移动宽带系统。蜂窝系统可以使用例如码分多址(CDMA)、时分多址(TDMA)、个人数字电话(PDC)、全球系统移动(GSM)或频分多址(FDMA)等。

网站：网站可以指代一个或多个web服务器上的一个或多个相互关联的网页文件和其他文件和程序。文件和程序可通过诸如因特网的计算机网络通过发送指定统一资源定位符(URL)的超文本传输协议(HTTP或HTTPS[S-HTTP])请求来访问，该统一资源定位符(URL)标识所述web页面文件中的一个的位置，其中在某些实施例中文件和程序由单个业务实体拥有、管理或授权。这样的文件和程序可以包括例如超文本标记语言(HTML)文件、公共网关接口(CGI)文件、和Java应用。网页文件优选地包括对应于网站的主页的主页文件。主页可以作为对网站中包含的剩余文件和程序的网关或接入点。在一个实施例中，所有文件和程序位于与主页文件相同的网络域内并且可在与主页文件相同的网络域中访问。替代地，文件和程序可以通过几个不同的网络域来定位和访问。

网页或电子页面：网页或电子页面可以包括由标准web浏览器响应于指定通过其网页文件被识别的URL的HTTP请求而呈现的页面或电子页面。网页可以包括例如文本、图像、声音、视频和动画。

计算机或计算设备：计算机或计算设备可以是任何处理器控制的设备，包括终端设备、诸如个人计算机、工作站、服务器、客户端、小型计算机、主机计算机、膝上型计算机、网络个人计算机、移动计算机、掌上计算机、手持计算机、电视机顶盒、其他类型的网络电视、交互式信息亭、个人数字助理(PDA)、交互式或具有网络功能的无线通信设备、移动web浏览器或其组合。计算机还可以具有一个或多个输入设备，诸如键盘、鼠标、触摸板、操纵杆、笔-输入板等。计算机还可以具有诸如可视化显示器和音频输出的输出设备。这些计算设备中的一个或多个可以形成计算环境。

这些计算机可以是单处理器或多处理器机器。此外，这些计算机可以包括可寻址存储介质或计算机可访问介质，诸如随机存取存储器(RAM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(EPROM)、硬盘、软盘、激光盘播放器、数字视频设备、光盘、视频磁带、音频磁带、磁记录轨道、电子网络、和用于发送或存储电子内容(诸如例如程序和数据)的其他技术。在一个实施例中，计算机配备有诸如网络接口卡、调制解调器或适于连接到诸如因特网的通信网络的其他网络连接设备的网络通信设备。此外，计算机执行合适的操作系统，诸如Linux、UNIX、Microsoft Windows的版本中的任意一个、Apple MacOS、IBM OS/2、iOS、Android或其他操作系统。合适的操作系统可以包括处理通过网络传递的所有传入和传出消息流量的通信协议实现。在其他实施例中，尽管操作系统可能取决于计算机的类型而不同，操作系统将继续提供合适的通信协议以建立与网络的通信链路。

计算机可以包含程序逻辑或表示数据和指令的其他基板配置，其使得计算机以如本文所述的特定的和预定义的方式操作以成为专用机器。在一个实施例中，程序逻辑可以被实现为一个或多个对象框架或模块。这些模块可以被配置为驻留在可寻址存储介质上并且被配置为在一个或多个处理器上执行。这些模块包括但不限于执行某些任务的软件或硬件部件。因此，模块可以包括例如诸如软件部件、面向对象的软件部件、类部件和任务部件、过程、功能、属性、过程、子程序、程序代码段、驱动程序、固件、微代码、电路、数据、数据库、数据结构、表格、数组和变量的部件。

系统的各种部件可以通过诸如例如处理间通信、远程过程调用、分布式对象接口以及其他各种程序接口的机制来彼此通信和与包括各个计算机的其它部件通信。此外，部件、模块和数据库中提供的功能可以被组合成较少的部件、模块或数据库，或进一步分离为附加的部件、模块或数据库。另外，部件、模块和数据库可被实现为在一个或多个计算机上执行。在另一个实施例中，部件、模块和数据库中的一些可被实现为在网站外部的一个或多个计算机上执行。在这种情况下，网站包括程序逻辑，其使得网站能够与外部实现的部件、模块和数据库进行通信，以执行如本文所公开的功能。

概述

本文描述的系统和方法是完全以拥有者为中心的，并且促进了细粒度的用户到用户数据共享。在某些实施例中，对拥有者或其代表始终保持最终许可控制。对于未成年人和无能力人，可以存在监护关系。组织有能力使用可扩展的许可管理结构，使他们能够容易和精确地将拥有者已经给予的访问分配给他们组织内的工作人员。

该系统和方法提供了定义细粒度访问的能力，其中拥有者可以不选择、读取或写入对其数据日记的所有区域的访问。每个拥有者都有用于查看所有具有可能查看他们的日记的权限的用户的列表并查看哪些用户已经访问过他们的数据的能力/可见性。每个拥有者也具有用于查看何时和由哪个用户对他们的整个日记进行了哪些改变/添加的能力/可见性。

描述

现在将参考附图描述实施例，其中在整个附图中，同样的附图标记始指代相同的元件。在本文中呈现的描述中使用的术语不旨在仅仅因为其与某些特定实施例的详细描述结合而被利用，而以任何有限或限制性的方式来解释。此外，实施例可以包括几个新颖特征，其中没有一个单独的特征仅仅负责其期望的属性，或者对于实践本文所描述的发明是至关重要的。

一些实施例包括用于在图表上提供相关医学数据的系统和方法，使得医疗护理提供者可以快速了解历史、药物的相关性、治疗、营养、生活方式选择、患者生理值(例如血压)、和症状、包括所有这些的改变。这些系统和方法使得医疗护理提供者以及具有较少的培训和专业知识的患者和护理团队的其他成员可以胜任地阅读和分析这些数据成为可能。此外，它可以最小化错误的风险。在其他实施例中，系统和方法可以用于数据拥有者期望经由许可来控制对数据的访问的其他领域。

参考图1，系统100的实施例包括用于创建、维护和利用与个人有关的存储的医学数据的系统工具178。这样的数据收集可以被称为终身健康日记(LHD)，也称为日记。系统100的某些实施例利用下面结合图2A所描述的网络。某些实施例可以利用具有网页的网站来为下列一个或多个提供对工具的访问：拥有者或患者186(其可以包括患者代理)、亲戚188(其也可以包括家庭成员、邻居、监护人等)、医生180(其可以包括初级保健医生和/或专科医生)、护士190、药剂师182(其可以包括临床药剂师)、和其他以前没有列举的医护人员184。在某些实施例中，系统100包括利用工具178工作用于医疗信息(诸如由患者控制下的所有各方查看并由几方填充的普通患者数据集合198)的呈现、分析和显示的LHD数据库196。在某些实施例中，系统100与一个或多个健康或监视设备192(例如，血压监测器、电子秤)以及与其他数据库194通信。

系统100可以利用数据中介来指示(例如药剂师或医生)给出的示例数据源可能不直接将数据输入到日记中，但是该数据可以从医生或药剂师的记录经由替代途径(例如电子地)而被引入。下面将会诸如结合图2、4描述这些的某些实施例。

用于以如本文所述的方式在显示器上提供相关医学数据的系统和方法对于医疗护理提供者和患者来说具有许多优点。例如，系统和方法的实施例可以提供以下特征和益处中的一个或多个：

·整理来自不同来源的数据并创建该医疗信息的单一数据库允许所有相关的上下文数据的容易的和快捷的分析。

·将数据转换为通用结构化格式和通用数据格式。

·提供患者的整体健康的易于理解的图形分析。

·提供对患者对可能的药物或其药物方案中改变的反应的易于理解的图形分析。

·提供一个容易理解的图形分析，该图形分析指示可能的对策和可能的不利影响来源。这可以包括将先前存在的患者状况和投诉从新的副作用和/或治疗效果分离出来，该新的副作用和/或治疗效果在开始特定药物方案后可能出现或消失。

·替代形式的健康治疗也可以是与常规治疗方案相比更容易，无论是针对个体患者，还是基于人群健康。

·提供利用来自患者或患者护理参与的健康专业人员的背景健康信息的能力。这可以经由时间相关性进行排序，使得能够与特定药物方案进行直接比较和关联。

·能够发现药物、医疗和健康数据、患者数据和数据的专业健康意见之间的关系。

·减少不适当的处方。

·减少药物错误和疏忽。

·改善患者的依从性、健康结果和利用率。

·提高药物方案的成本效益。

·允许各种药物方案的费用的容易的总结和理解。

·实时地向合适方发送容易理解的药物方案。

·提供标识不同数据类型之间的相关性的能力。

·为查看者提供使他们自己快速熟悉日记所代表的个人(拥有者)的状况/历史的能力。

·为数据显示提供轻松地被配置为满足当前查看者的目标/兴趣的能力。

·提供在健康历史中的任何时刻轻松地/快速地导航到任何特定数据的能力。

与现有技术的医学数据收集和显示系统相比的优点可以被进一步增强，因为可以以有意义的方式实时地接收和显示数据。术语“实时”在此不用于表示绝对同时进行的数据收集、处理和显示。相反，在某些实施例中，实时意味着数据收集、处理和显示在时间上与实际的跟踪事件足够接近以允许持续地以有益的方式作出治疗决定。这通常将允许用于将数据输入医疗护理提供者数据库等的常规时间调度，以及基于用户确定什么适合正被监视的条件的显示频率。例如，实时可以包括取决于正被监视的条件的每小时、班次、每日、每周或每月更新和/或显示查看。

这样的实时过程意味着健康专业人员在护理点向患者可以提供更全面、有响应和/或成本高效的护理(护理优化)。在许多情况下，这可能会背离将以前复杂而困难的信息发送给诸如药理专家的专家来解密和解释同时要求对应的时间和费用的需要。

实施例可以包括健康调节工具，用于在单个护理点处对来自两个或更多个来源的患者健康数据进行整理、分析和显示。在某些实施例中，时间轴是包括特定拥有者日记的数据的时间相关的、聚集的视图。时间轴的视口(当前显示的区域)可以放大和缩小(例如，日-周-月-年)，并且还可以通过时间进行前进和后退。可以选择日记数据的任何子集进行查看，并以适合查看者需求的顺序进行选择。

某些实施例基于图1、图2A、图2B和图2C所示的示例开放系统集成架构。在图2A-2C中，示例开放系统集成架构可以基于例如与本地或远程数据存储库以及在本地或远程应用系统上运行的本地或远程应用(诸如web应用150'、应用编程接口(web或其他)150”和集成系统150)交互的用户界面。在某些实施例中，web应用150'、应用编程接口(API)150”和集成系统150可以各自在一个或多个服务器上或在一个服务器上操作。图2A-2C是可用于实现本文描述的某些系统和方法的示例系统100的框图。在计算系统100的部件和模块中提供的功能可以被组合成更少的部件和模块，或者进一步分为附加的部件和模块。也可以使用在联网环境中通信的各种其他类型的电子设备。

一些示例部件的简要概述如下：

·集成系统：该系统监控各种入站数据路径，并处理入站数据以添加到拥有者日记。例如，可以通过这种方式导入CCD(护理文件的连续性、基于XML的病史文档)，并且还有一种允许将具有备注的扫描纸文档导入并添加到日记和数据仓的格式。该系统仅供内部使用，不能由任何其他应用直接访问。

·通知服务：此服务监视通知数据库，当需要发送到第三方系统(例如电子邮件、短信)的通知发生时，本系统将取回数据、提供通知文本、并经由所请求的方法来发送通知。这仅是一个出站路径，并称呼消息系统。其不可以由任何其他应用联系。

·Web应用：通常称为日记，这是拥有者经由web浏览器登录以便于用他们的日记数据工作、维护它们的个人简档、邀请其他人查看他们的日记等的网站及其后台代码。

·管理站点：允许系统操作人员管理系统，包括添加/维护用户、运行报告等。不适用于非系统操作人员或拥有者。

·应用编程接口：提供对外部应用的日记数据库访问，例如iOS应用、Android应用、各种测试系统。在某些实施例中，不存在对第三方应用的访问，但是在其他实施例中，存在对第三方应用的访问。

·IIS：微软因特网信息服务器，其托管日记网络应用、管理站点和API，连同某些实施例中的各种验证服务。

API 150”提供了接口，到该接口的第三方和由系统100的操作者产生的外部应用可以与系统通信。它提供了到存储装置154的数据库的路径，以及格式化来自数据库的数据以使其适合于由这些外部客户端的消费，同样格式化来自外部客户端的数据以使其适于发送到数据库的功能。API 150”提供安全性，使得外部应用及其用户(如果有的话)只能访问他们应该具有的数据。API 150”允许用户或系统在不使用提供的网络用户界面的情况下更新其帐户及其医学数据，并取回帐户和医学数据。在某些实施例中，API 150”支持认证，作为API中日记数据的拥有者(例如，用户不能以访问者身份登录，例如，并且查看另一个拥有者的日记数据)。在其他实施例中，用户可以能够作为访问者登录，并且以适当的许可查看另一拥有者的日记数据。

参考图2A，现在将描述使用网络的系统100的实施例的部件的示例配置。在某些实施例中，移动或固定计算设备110由用户130操作。在其他实施例中，计算设备110可以是没有显式用户的服务器。这样的服务器可以由例如系统100的运营商或集成第三方系统的运营商拥有。可能还有其他移动或固定计算设备。计算设备110可以是手持式计算设备或其他便携式计算设备，例如Palm、口袋个人计算机(PC)、基于Linux的手持式设备、PDA、诸如的智能手机、诸如的平板计算机、或具有显示器的PC。在其他实施例中，计算设备可以是任何形式的因特网连接的设备，包括但不限于PC、移动设备、PDA、膝上型计算机、平板电脑、芯片、键盘、语音音频和视频软件、鼠标、键盘、触摸板、跟踪球、麦克风、视频、存储设备、网络设备、数据库、扫描仪、复印机、数字笔、图像识别软件和设备、屏幕、和其他形式的显示器、上网本和其他形式的计算机硬件。在某些实施例中，特定用户可以具有和使用与用户相对应的多个计算设备。在这种多用户设备情况下，系统100可以在与特定用户对应的每个设备之间同步数据。某些实施例中的计算设备110以独立(单独)的方式操作，诸如例如当其为服务器时。在其他实施例中，计算设备110经由网络140与网络应用150'和/或API 150”通信。在其他实施例中，可以利用其他数量的服务器。服务器可以包括一个或多个处理器152、存储器158、由处理器执行的系统软件156、以及输入或输出设备160。在某些实施例中，数据存储子系统154与集成系统150、web应用150'和API 150”通信，并存储由系统使用的一个或多个数据库，例如LHD数据库196(图1)。处理器152'可以经由诸如结构化查询语言(SQL)或开放数据库连接(ODBC)的数据库接口与数据库通信。在某些实施例中，数据存储装置154经由数据库接口与服务器进行数据通信。从计算设备110到网络140的连接可以是无线或卫星连接144或有线或直接连接142。服务器执行为专用机器，集成系统150、网络应用150'和API 150”连同系统软件和数据在该服务器上操作。在某些实施例中，服务器是诸如在内联网或因特网上的网站的一部分。

当计算设备110与服务器连接时，网站可以可选地提供对新特征的更新。在另一个实施例中，计算设备仅在连接到服务器时运行。

计算设备110包括处理器112、存储器122、显示器114和一个或多个输入设备116。当作为服务器操作时，显示器114和输入设备116可以是可选的。处理器112与数据存储装置118进行数据通信。在某些实施例中，数据存储装置118可以存储用户和/或其他数据或软件的记录。系统软件120由处理器112执行。系统软件120可以包括应用图形用户界面(GUI)。应用GUI可以包括到计算设备的数据存储装置118的数据库接口。在某些实施例中，从数据存储装置118加载软件。在某些实施例中，软件可以是移动应用。在计算设备110与网站通信的实施例中，处理器利用浏览器软件代替软件120或除了软件120之外还利用浏览器软件。网络浏览器可以是例如Microsoft InternetMozillaGoogle Chrome、Opera Software等。计算设备110连同系统软件和数据一起作为专用机器操作。诸如打印机的可选输出设备129被连接到计算设备110。

移动应用的示例包括日记iOS应用。日记iOS应用可以包括应用、LHD数据库196和HealthKit框架之间的三向同步。

数据外部源X 170、健康或监视设备171以及外部数据源N 172用有线或无线连接与网络140和/或一个或多个计算设备110进行通信。外部数据源包括但不限于诊所、医院、医疗护理网络、保险、制药、药店、区域健康委员会、药房福利管理人员、人口健康实体、政府和私人机构、医护人员、研究人员、健康教练、药理学家、医生和其他健康专业人员、患者网络、教育机构、雇主、实验室、传统的补充和替代医学从业人员、制药、临床研究机构、远程医疗提供者、联盟健康机构、陪护人员和照料者组织。外部设备170、171、172中的一个或多个可以利用API 150”来同步数据，或者可以经由计算设备110来同步数据。外部数据源170、172可以包括主机硬件，其中某些实施例使用完全冗余的硬件基础设施(例如，并行服务器或负载平衡交换服务器)来提供可用性；或通过将用于针对其主动系统的多处理器系统或一个多处理器实现为被动备用系统的数据系统的增益可扩展性。外部数据源170、172还可以包括操作系统(例如，多处理、多用户、多任务和实时)，以提供一个软件平台，外部实体的应用可以在其软件平台上运行，并确保同时运行的不同的程序和用户不会互相干扰。操作系统还负责安全性，例如确保未经授权的用户不访问外部数据源170、172。外部数据源170、172还可以包括数据库，诸如来自Oracle公司的关系数据库。关系数据库安全地整合信息并确保数据质量，提供始终可用的访问，扩展以提供用户需求的响应时间，减少停机时间，自动管理任务，并通过可扩展性降低运营成本。外部数据源可以将需要进一步处理的经处理或未处理的医学数据推送到与集成系统和web应用相关联的服务器用于医学数据的处理。经处理的数据用于更新系统LHD数据库。例如，集成系统150可以消耗由系统内部数据路径提供的数据，并写入数据库。从那里，客户端设备可以经由web应用或API来消耗数据。

参考图2B，现在将描述存储子系统154的实施例的部件的示例配置。存储子系统154可以包括数据仓存储装置161和数据库集合，该数据库集合包括摘要数据库162、核心数据库163、集成数据库164、管理数据库165、数据仓数据库166、安全数据库167、通知数据库168和其他数据库169。数据仓存储装置161是用于数据仓的批量数据存储装置，其可以是磁盘上的单个目录或第三方批量数据存储库。在某些实施例中，除了通过简单文件名，数据仓存储装置161不需要是可索引的或可搜索的。数据仓数据库166是本地数据库，该本地数据库将存储在数据仓存储装置161中的数据与日记中的拥有者用户相关联并保存诸如标签、创建日期等其他元数据。

摘要数据库162保存每个日记类别或模块随时间的聚集数据以供时间轴消耗，并且将来根据需要保存其他系统。核心数据库163包含所有核心数据，包括用户/登录、日记数据等。集成数据库164包含特定于与外部系统集成的数据，例如记录输入数据的状态。管理数据库165保存用于管理用户(例如，支持)的登录和角色数据。数据仓数据库166包含用于数据仓文档的元数据，但不存储实际的二进制数据。安全数据库167包含辅助存储的程序，并且在将来可能包括用于应用安全性的相关表。通知数据库168包含用户的通知和元数据，例如将被发送或已发送的电子邮件、屏幕上(web)通知、SMS通知等等。通知数据库168由通知服务使用以发送通知，由核心应用排队通知用于发送，并由核心应用示出屏幕通知。

核心数据库163可以包含所有核心数据，包括用户/登录、日记数据等等。在某些实施例中，核心数据库163可以存储：

·拥有者特定的日记数据，例如运动、吸烟和睡眠记录。

·由这些例如不同类型运动、药物、条件的主表引用的静态数据。

·登录凭据数据

·个人/简档数据(姓名、地址、社会安全号...)

·许可-许可的定义加上访问者/组织/角色/...邀请的许可

在某些实施例中，摘要数据库162可以是完全导出的数据。数据可以随时被丢弃，因为它可以按照需要被重新创建。在某些实施例中，它纯粹是高速缓存，其避免重新计算大量数据。该计算的数据表示随时间的日记条目组。例如，它可以包含基于每天、每周、每月和每年的拥有者锻炼活动的摘要。

摘要数据库162可以针对每个日记类别或模块随时间保存聚集数据，以供时间轴消费，并且将来根据需要保存其他系统。这由每个模块的记录构成，反映针对例如每日、每周、每月和每年的期间在该模块中保存的数据。每个记录至少由索引构成。该索引指示正在总结哪种类型的时间段，并且取决于所讨论的模块的要求，可以直接包含摘要数据，或者可以具有包含摘要数据的子记录。例如，睡眠模块可能仅需要索引，因为没有多种睡眠类型的概念。但是，症状模块可能需要索引(以在正被聚集期间提供记录)和多个摘要子记录，一个摘要子记录用于总结在该期间已经发生的每种类型的症状。

摘要数据库162数据是从核心数据库163构建的。摘要索引是每个模块的中心实体，如下：

·[Id][int]IDENTITY(1,1)NOT NULL：索引记录的ID。

·[PatientId][int]NOT NULL：数据所属的核心数据库中的拥有者的ID。

·[PeriodTypeId][int]NOT NULL：此摘要覆盖的期间类型(见下文)。

·[StartDate][date]NOT NULL：期间开始的日期。

·[EndDate][date]NOT NULL：期间结束的日期。

·[Count][int]NOT NULL：有助于此聚集的记录的数目。

期间类型是：

·ID

·值

·1每日

·2每周

·3每月

·4每年

每个索引表可以具有特定于该数据类型的更多列，或者在模块特定表与其索引之间可能存在多对一个关系。例如，症状的索引表只有上面列出的列，但它有一个子表，症状总结：

·[Id][int]IDENTITY(1,1)NOT NULL：此摘要的ID。

·[SymptomIndexId][int]NOT NULL：此摘要所属的症状索引(以上)。

·[SymptomId][int]NULL：正在总结的症状。例如，在单个月期间内，可以发生几种症状。每个都被独立地总结，所以人们可能知道本月的头痛很严重，但背部疼痛大大改善。

·[Description][nvarchar](255)NULL：症状的纯文本描述。

·[MinSeverity][int]NOT NULL：在此期间记录的此症状的最小严重性。

·[AvgSeverity][int]NOT NULL：此期间此症状的平均严重性。

·[MaxSeverity][int]NOT NULL：在此期间记录的此症状的最大严重性。

·[RecordCount][int]NOT NULL：在此期间记录的此症状的实例数。

然而，一些模块不具有可能在一段期间内发生的不同数据类型的概念。例如，压力很简单-任何一个时间点都有一定水平的压力，压力种类之间没有区别。因此，索引表可以如下所示：

上述索引中的标准字段：

·[Id][int]IDENTITY(1,1)NOT NULL

·[PatientId][int]NOT NULL

·[PeriodTypeId][int]NOT NULL

·[StartDate][date]NOT NULL

·[EndDate][date]NOT NULL

以及与上述摘要相似的目的的字段：

·[Max][int]NOT NULL

·[Min][int]NOT NULL

·[Average][int]NOT NULL

·[RecordCount][int]NOT NULL

在某些实施例中，数据仓数据库166包含用于数据仓文档的元数据，并且包括以下字段：

·UID：唯一标识文档的GUID

·FileName：文档的用户友好的文件名

·FileSize：文档的大小(以字节为单位)

·PersonId：通过其ID(从Core数据库)标识此文档的拥有者，

·CreatedDate：此文档首次上传的日期

·ModifiedDate：本文档的上次修改的日期

·Notes：免费文本备注

·DataSourceId：标识此文档的来源，例如Web应用、API(移动应用)、集成系统

·DataSourceRef：可供外部应用使用的免费文本字段

·EncryptionType：对此文档使用的加密类型(当前对磁盘上的平面文件有效)

此外，存在与文档以多对多关系存储的标签：

·UID：唯一地标识标签的GUID

·名称：标签的文本名称

·PersonId：通过ID标识(来自核心数据库)该标签的拥有者

集成数据库164包含特定于与外部系统集成的数据，例如记录输入数据的状态。它详细描述了当前支持的集成类型，并将集成系统150引用到与每个集成类型对应的代码。通过这种方式，可以经由数据库启动和停止集成路径。它记录所有集成动作的日记，并存储在集成管道中使用的集成消息。

管理数据库165保存管理用户(例如，支持)的登录和角色数据。这用于限制每个管理用户被允许查看/使用管理网络应用的哪些区域。

在某些实施例中，安全数据库167仅包含用于应用安全性(许可)的辅助存储程序。它不包含表或其他形式的数据。在其他实施例中，它可以包含与许可有关的表。

通知数据库168可以包含用户的通知和元数据，例如将被发送或已被发送的电子邮件、屏幕上(网络)通知、SMS通知等。通知数据库168由通知服务用于发送通知，由核心应用对用于发送的通知进行排队，并由核心应用示出屏幕通知。

通知数据库168可以包含用于创建通知的两个模板和所创建的通知。通知模板如下。系统能够生成多种类型的通知，目前为：

·重设密码

·新拥有者确认电子邮件

·新拥有者欢迎

·新访客确认电子邮件

·新访客欢迎

·存在新帐户电子邮件

·邀请新访客

·邀请新用户

·邀请被发送

·邀请被接受

·邀请被拒绝

·许可修改的访客

·许可修改拥有者

·帐户字段被修改

·访客被移除

·访客移除其他访客

·访客移除自己

·访客邀请其他访客

·人员添加新电子邮件

·访客接受邀请

·新的免费拥有者欢迎

可以定期添加新类型的通知。每个通知类型都有一个或多个模板，每个模板都以给定的语言表示内容。然后，每个模板都有多种内容类型，例如纯文本、HTML。以这种方式，通过选择必须发送的通知类型，系统能够以自己的语言向该用户发送通知。模板是不可变的；如果内容必须被更新，则会添加新记录集合。这允许旧的通知被准确地重新生成，如他们在原始发送时呈现的。

通知实例如下。当系统生成通知时，它被存储为参数集合和对模板的引用。这样，在某些实施例中，大量的重复样板文本不被存储在数据库中。

通知分配如下。通知数据库168可以存储每个通知的状态：

·未发送(等待发送)

·重试

·发送

·失败

这是根据需要通过通知Windows服务和其他通知消费者来更新的。

通知模板创作工具如下。通知系统包括使管理员更容易更新通知的工具。在管理员网站中，管理员用户可以修改通知模板。数据库保存模板参数的样本值，以便通知系统可以从正在更新的模板中呈现通知，以向用户提供其通知的现实示例。

该系统包括跨多个后备存储装置传播数据仓数据的能力。在某些实施例中，数据跨本地(磁盘上的平面文件)存储装置和批量数据存储提供商(例如，Amazon AWS S3)传播，但是该系统被设计为能够根据需要支持尽可能多的存储装置。以前，数据仓仅将文件存储在本地或网络共享驱动器上。这在长期来看是不可行的，因为它可能不灵活、昂贵、并且需要应用服务器(web或API)在上传或下载(例如加密)时进行大量工作。针对批量数据存储存在第三方服务，因此能够利用场景服务提供优点后面这些优点，因为与数据存储有关的所有网络业务和其他开销可以从日记服务器卸载到存储提供商的服务器。其他优点包括：

·系统可以一次处理多个存储的备份。当用户选择上传文档时，系统可以决定使用哪个提供商以及哪个站点。

·支持多个服务级别。例如，在针对这些用户的后备存储装置可以更快或更安全，并且提供针对该数据的其他访问方法的情况下，可以提供优质服务。

数据仓数据库166在被称为DocumentStore的表中包含当前支持的后备存储装置的列表。数据仓数据库文档表具有外部键入到存储表的StoreId列。在远程后备存储装置中，该文件由环境(例如，其数据仓本身的日记系统)和用户(通过URN，如下所述)存储，具有被保留的原始文件名。这样，当用户直接从后备存储装置下载文件时，所下载的文档的文件名是正确的。

在某些实施例中，在日记实例中，数据库实体仅由整数ID标识。即使在它们的数据库中这些ID也不是唯一的-它们仅在特定表格的上下文中有含义。这不是一个重要的限制。然而，如果需要能够在多个日记系统中唯一标识实体，那么这可能是一个问题，因为每个系统可能拥有具有id 1的实体、具有id 2的实体等的自己的本地版本。这种示例在认证系统实现中由系统100的操作者看到，其在一些实施例中可以是终身健康日记。在某些实施例中，可以利用基于Thinktecture IdentityServer3(OAuth)的认证系统。当用户登录时，认证系统实现必须能够告诉该用户的实体的整数ID是什么，而且还可以告诉用户的实体(和数据)存在于哪个日记实例内。为此，已经定义了指定任何给定数据库行/实体的确切位置的标准符号。当在日记中编写代码时，人们通常将不需要使用实体统一资源名称(URN)。但是，如果有人曾可能需要在全球范围内引用实体，那么可以使用实体URN来实现。EntityURNService和相关联的接口已被实现。

实体URN遵循以下格式：urn:<instance>:<db>:<typename>-<id>

上表中的示例将导致URN urn:ins2:core:Person-44。

参考图2C，将描述图2B所图示的数据仓数据库、核心数据库和数据仓文档存储装置之间的交互的实施例的示例。数据库数据库166包括具有核心人员ID、存储装置ID、文档ID、文档名称和其他数据/列/字段的文档表266。数据仓数据库166还包括具有存储装置名称、存储装置位置、存储装置ID和其它数据/列/字段的文档存储表267。核心数据库163包括具有核心人员ID和其他数据/列/字段的人员表263。文档表266包含标识文档拥有者的字段及其确切的存储位置。核心人员ID字段表示特定文档所属的、核心DB 163中的人员表263中的用户。存储装置ID、文档ID和文档名称字段定义可以找到文档的位置。存储装置ID指示在哪个存储装置(数据仓本地存储装置260、数据仓远程存储装置一261、数据仓远程存储装置二262、以及由264表示的其他存储装置)中可以找到文档。文件在存储装置中的位置可以通过文档ID、文档名称或从文档表266中的记录导出的其他元数据的某种组合来定义。文档表记录到存储装置中的位置的映射在每个在座装置的基础上被定义，所以该方案可能因存储装置而异。

在某些实施例中，数据仓将文档写入到Amazon AWS S3数据存储装置。然而，在其他实施例中，在可用存储位置之间选择的其他因素可以包括：

·当地法律要求

·业务要求

·安全要求

·地理(物理/网络接近)

·用户帐户类型-例如，免费的、标准的、高级帐户可以提供不同级别的存储装置。

为了读取文档，数据仓将通过重定向特定请求或作为对特定请求的响应将代理下载到呼叫客户端(针对API)或提供下载URL。

可以以三种方式标识数据库实体：

·整数ID仅在特定数据库实例中本地地标识实体。例如，在两个生产实例(iOS/免费帐户数据库和付费帐户数据库)中均可能存在具有id 44的人。仅指定整数ID不会指示可以在哪个数据库中找到该实体。

·UID是全球唯一的，因此以这种方式识别的实体不存在歧义。然而，仍然无法从单独的UID告诉可以在哪个数据库中找到给定实体。

·URN是一个多部分标识符，它完全指定了实体的位置，例如哪一个系统、哪一个实例、哪个类型、以及哪个记录被请求。这是完全明确的，并提供了到实体的完整路径，但可能不会和其他两个ID类型一样执行。

一些实体可以要求所有三种ID类型的使用。例如，一个人可以使用整数ID来强制数据库中的参照完整性，一个用于将其标识为集成导入的目标的UID，以及当全局认证系统引用时的URN。

医疗信息的呈现

通常，患者医疗信息被使用XML数据导出文件收集到逗号分隔值(CSV)文件，然后被手动地显示在电子表格中。这种电子表格的不同视图使得时间相关性非常具有挑战性，因为如果由药物名称排序则日期可能会无序，就像剂量和药物的任何改变一样。另一方面，其他排序则意味着药物名称混乱，使视图更加混乱。现有技术的状态的整体效果是使决策和判断耗时、非直观、复杂，并通常需要特定的专业知识。相比之下，系统100显示以对所有护理团队成员特别直观和有用的方式提供相关数据的格式。

在数据收集方面，数据可以作为XML数据导出文件(或任何其他合适的格式)被拉入出到构造和显示它们的系统中。医学数据可以从各种来源导入。这些来源包括收集或存储关于今天患者的数据(诸如纸质记录、语音记录、计算机化的电子医疗记录)，或将来可能开发的(诸如植入患者体内的纳米机器)，并且使用周期性地发送生理测量的无线通信方法的系统。数据被结构化使其被放入具有一致的字段、值的一致单位(如克)等的一致的计算机记录结构。

可以使用一致的符号集合来显示数据，以表示生理测量、药物、剂量、开始和停止等等。在某些实施例中，绘制一系列垂直排列的水平线，从起始时间(可能是数据可用的第一时间，或用户选择的任何其他时间)开始，并在结束时间(可以是当前时间或可选地由用户选择的任何先前时间)结束。每一行可以包含一个变量(例如药物)或可选的相关变量集合的数据。这些行的集合显示在屏幕或页面上(可能是患者的所有数据的完整集合或由用户选择的子集)。这些行可以被同步，使得所有行均具有相同的起始时间、结束时间和时间尺度。这允许用户查看数据之间的相关性和其他关系。在现有系统中，这些相关性和关系难于或不可能理解，因为它们来自由不同来源提供并且分离地存储的数据。

现在参考图3，将描述处理特定拥有者或患者的医疗信息的处理300的实施例的示例。如上所述的数据源310提供诸如患者背景/历史信息312的医疗信息以及诸如治疗和/或药物信息314的持续数据连同针对特定患者的任何其它先前提及的医疗信息。在某些实施例中，信息312和信息314由路由器315路由到结构化处理316、结构化处理318和数据仓321中的一个或多个。例如，数据仓可以存储包括扫描记录、备注等的各种患者信息以及以其被捕获的格式的图像、音频和视频数据等。在下文中将结合图4进一步描述路由器。在一个实施例中，患者背景信息由结构化处理316结构化，并且包括治疗和/或药物信息的持续患者数据由结构化处理318结构化。在其他实施例中，其他配置可用于结构化某些医疗信息。在结构化医疗信息之后，其可以包括将信息归一化为一致和标准化的记录格式，该信息被存储在数据库319中的特定患者的日记中。

来自患者日记的信息可以由分析处理320访问，分析处理320通过处理数据之间的复杂关系来执行分析。在处理350处，患者背景、治疗和/或药物信息和其他患者数据的这种分析可以视觉上呈现在屏幕上，包括但不限于颜色、高亮显示、箭头或指示符的形式。系统和方法也可以使用分析来建议医疗护理专业人员对药物或治疗或临床试验或实验进行改变。如果需要，分析处理320还可以用于确定是否存在风险或关键事件，或者给第三方的药物和/或治疗或介绍的建议是否适当。确定的手段包括考虑患者数据的启发法或算法。该处理的输出可以包括要作为消息发送的警报。在某些实施例中，分析处理320可以包括趋势检测，诸如确定拥有者(患者)需要多长时间达到某些目标、标识有害趋势等。

患者数据的分析可以包括复发系统。复发系统使用数据库模式，其涉及将表列集合识别为表示复发数据，例如：

·一旦处于指定时刻，此事件是否发生？

·从指定的时间开始，在几个定时发生的时刻，此事件是否重复发生？

·从指定的时间开始的一段时间，此事件是否持续发生？

·以及当事件定期发生时，此事件是否发生？或对于扩展的时段，此事件是否发生？该时段何时结束，或它还在进行中？

复发系统是核心数据库163和应用服务器代码的数据库模式的一部分。

分析处理320的输出可以被发送以呈现处理和/或被发送到干预或改变治疗状态370。一些实施例可以在路由处理360处基于他们的专业知识、与患者的关系、认证和其他相关信息或事件信息355来确定适当的人来接收每个消息，路由处理360接收来自呈现处理350或事件信息355的输入。路由处理可以确保将消息发送到所有适当的接收者，而不是发送给任何其他人。潜在的接收者包括但不限于患者362、药剂师364、护士和/或医生366以及护理人员368，它们是多学科护理团队的所有部分。路由处理360还可以从多学科护理小组的任何成员接收信息，并将信息路由到干预或改变处理状态370。例如，可以将任何干预或改变的干预信息作为新的数据源发送到结构化处理318。

分析处理320的输出也可以被发送到聚集处理330。聚集处理330可以包括通过时间戳或包括但不限于年龄、性别、位置、工作生活方式选择、生活事件、包括预先存在的条件的潜在的健康状况、遗传标识符、症状、治疗、药物或医疗护理提供者的其他字段对来自不同的源的数据进行排序。聚集可以扩展到包括聚集对应于多个患者的数据的可选步骤，该多个患者的护理是由特定医疗护理专业人员、医疗护理设施、区域、国家、和/或跨人群或人群的个体目标子集的治疗提供的任何特定形式来提供的。聚集处理330的输出被发送到分析处理322，分析处理322可以使用户能够将药物和所规定和执行的治疗相关联，以确定关于这些护理提供者的多个因素，包括药物的治疗过度或不足、治疗有效性、特定症状或疾病的优异或较差的诊断、禁忌症的识别等。这可能有助于确定医疗护理提供者的特定专业领域、和/或特定治疗方案的有效性、和/或需要附加的培训或教育的领域。例如，分析结果可以通过结构化处理318存储在LHD数据库319中。

聚集处理330的输出也被发送到测量和跟踪处理340，以跟踪、监测和测量如由特定医疗护理专业人员、医疗护理设施、地区、国家和/或跨人群、人群的个体目标子集、或特定患者的治疗提供的任何特定形式所规定的药物或治疗的结果。测量和跟踪处理340的输出可以用作上述呈现处理350的输入。

系统和方法从各种不同的源捕获来自不同类型的字段的多种类型的数据。系统和方法将来自任何类型的来源的任何类型的医学数据重新目的化为图形摘要页面，以便对包括患者和家庭陪护人员在内的护理团队更有用和有意义。

下表1中的以下数据字段示出了数据捕获源的几个示例。这仅是示意性的；右列中的数据源可以是列出的各种数据源的任意组合。可用于任何数据字段的附加来源是电子病历(EMR)。来自EMR、药剂管理软件(PMS)、或实验室馈送的数据馈送的数据提取可以是符合HL7标准的XML数据。系统和方法将所有不同的数据有效地标准化为标准、一致、易于理解的单一格式，用于所有护理团队成员共享并从中获得洞悉。

表格1

数据字段	由…捕获
		命脉体征	机器人
药物分配	护士或药剂师
		服用药物	陪护人员、患者、家庭
测试和实验室	护士或医生
		免疫接种	护士、医生或实验室网络服务
体征	护士、医生或PMS网络服务
		症状	陪护人员、患者、家庭
生活事件/生活方式	陪护人员、患者、家庭

现在参考图4，将进一步描述图3所示的患者历史数据312、患者持续数据314、路由器315和结构化316和318的示例结构和配置。在某些实施例中，患者历史数据312包括基于纸质的记录410和电子记录412。基于纸质的记录410可以通过手动数据输入420来处理，并且电子记录412可以通过自动导入操作422处理。另外，基于纸质的记录410和电子记录412可以由路由器315路由到处理操作430，例如，诸如可以是基于纸质的记录410的扫描的导入处理432。诸如电子记录412(例如数字照片)的其他信息可以以最少的处理被导入。处理432的输出被存储在数据仓321。在下文中将进一步描述在数据仓中存储信息。

在某些实施例中，患者持续数据314包括手动数据源414和电子数据源416，诸如健康或监视设备。手动数据源414可以通过手动数据输入424来处理，并且电子数据源416可以通过自动导入操作426处理。

在某些实施例中，手动数据输入420的输出被路由到结构化处理316的手动导入处理440。自动导入操作422的输出可被路由到结构化处理316的电子记录转换处理442。手动数据输入424的输出可以被路由到结构化处理318的日记手动数据输入处理444。自动导入操作426的输出可被路由到结构化处理318的电子数据流转换处理446。在结构化处理316和318将信息结构化为公共格式之后，信息被存储在日记数据库319中，并且可以在分析处理320进行分析。

在进一步的描述中，数据文档可被导入日记。在某些实施例中，日记包括健康或医疗信息的许多类别、类型或模块。这些可以是历史数据(通常来自医院、全科医生(GP)或其他存储库的批量数据)或通常特定于单个动作(例如，在药房填写处方)的持续的数据。它们可以是：1)日记数据，例如医学处方，其用于创建针对其对应的日记模块的输入，以及2)非日记数据，例如，X射线图像，其不包含特定于日记模块的信息，并且仅呈现在数据仓中。在其他实施例中，信息的类别、类型或模块可以用于非医学数据。

在某些实施例中，进入日记的每个数据文档被存储在拥有者的数据仓中。任何文档可能包含一个或多个日记数据块。例如，来自GP的记录可以包含多个状况、症状和治疗。在某些实施例中，伙伴处理并随后以商定的格式将解析的医学数据、连同以PDF格式的扫描的文档发送到日记。解析的数据中还包括每个数据项的索引，指示附带的PDF中的数据源，指示哪个文档包含它，以及该文档中的相关页面。

系统100的用户可以包括1)具有日记实例的数据(例如，健康数据)拥有者，2)没有日记但可以给定选择性地访问拥有者日记的访问者(例如，对于双亲母、兄弟姐妹、朋友等)，3)属于组织的工作人员(例如医生、护士、技术人员或行政人员)，以及4)具有日记但也被允许访问另一位拥有者的日记的拥有者/访问者。访问者可以进一步分类为具有阅读和/或写入特权的访客，或作为可以以完全拥有者特权来使用日记的监护人(例如，对于具有照顾儿童或无行为能力人的日记的可证明的法定权威的成年人，就像他们是拥有者一样)。

参考图5，将描述示例日记许可。可以将许可视为执行特定动作的能力。用于特定患者的示例患者帐户510被示出为具有各种方面，包括管理简档、管理邀请和管理商品连同针对药物、运动、睡眠和疾病的信息的类别、类型或模块。这些各方面都是通过特定的许可来保护的

参考图6和7，将描述发布许可的示例。从示例患者帐户510向另一患者/拥有者、访问者、访客和组织的工作人员中的一个或多个给予许可。患者/访客是第三方患者/拥有者，他们具有查看/更新日记中的拥有者记录的许可。

单个许可控制对由拥有者的日记所持有的信息的类型或与拥有者或组织有关的特征的访问。由许可控制的信息的示例是：锻炼记录、处方和治疗。由许可控制的特征的示例是：用户简档并向其他用户发送邀请。

许可可以是私有的、只读的(意味着不允许添加、更新或删除信息)，或者可以给予完全访问(允许添加、更新或删除信息)。

在某些实施例中，以集合为单位应用许可。许可集合可以包含任何许可组合，其中每个可以仅单独读取、全部读取或私有读取。这些集合可以由拥有者经由邀请给予第三方。

许可是分层的，诸如例如(省略只读概念)：1)对拥有者的整个帐户的许可；2)对拥有者的日记数据的许可；和3)对锻炼数据的许可。

在这种情况下，如果LHD应用的任何用户尝试查看特定拥有者的锻炼数据，并且在上述列表中没有任何许可，则将阻止该动作。为了访问锻炼数据，用户必须具有这些许可中的任何一个。如果用户只有许可3并尝试访问任何除运动数据之外的任何一个日记数据，则访问将被拒绝。如果用户具有许可2或许可1，则这将封装所有日记数据许可，因此将允许访问所有日记数据。

“只读”是可以应用于任何许可的概念。在上面的列表中，用户可以被给予类型为1，2或3的只读许可。如果用户具有类型2的只读访问许可，“对拥有者的日记数据中全部的许可”，则用户可以访问所有日记数据，但不能对其进行任何改变。此外，该用户可以具有类型3的完全、非只读许可，“对锻炼数据的许可”，在这种情况下，他们将能够对锻炼数据进行改变，但所有其他日记数据将保持对该用户只读。

拥有者可以经由邀请向其他个人(称为访客)给予对他们的数据的许可。一旦邀请处理完成，访客就可以查看来自拥有者的日记的所选数据。只有当日记的拥有者已经给予访客对应的许可时，访客才可以查看或更新特定的数据。

参考图8，将描述组织概念的示例。例如，组织可以是机构、商业或诊所。工作人员可以是由组织雇用或隶属于组织的用户。患者/拥有者是日记帐户的拥有者，组织已被给予对日记帐户的访问。许可可以是在系统中执行动作的权利。角色可以是组织定义的许可组合。访问组可以是用于链接工作人员和患者的组织定义的组。

参考图9，将描述组织角色的示例。在某些实施例中，角色的目的是允许大量工作人员上的许可的更容易的管理。工作人员获得的许可是其所属角色的积累。角色可以由每个组织定义。图9所示的示例图示管理角色、安全的临床角色、一般临床角色，其中工作人员A和B被分配管理角色，工作人员B被分配安全临床角色，并且工作人员B和C被分配一般临床角色。

参考图10，将描述组织访问组的示例。图10所示的示例示出组A和组B，其中工作人员A被分配给组A和组B，工作人员B仅被分配给组B，并且其中患者A被分配给组A，并且患者B和C都被分配给组B。

因此，许可可以由拥有者给予组织，类似于该方式，拥有者将它们给予客户。组织可以创建访问组。然后，组织可以将其拥有者或患者分配给它认为合适的访问组。拥有者可能同时是多个组的成员。同样，组织可以将其工作人员分配给访问组，代表将与该组成员一起工作的工作人员。工作人员可能属于相同组织中的多于一个组。

组织可以创建角色，这些角色是他们自己的工作人员的组。然后这些角色可以由组织分配许可。那么，如果：1)拥有者已经给予组织对应的许可，以及2)组织还给予了工作人员的角色相同(或更高)许可，以及3)拥有者处于工作人员所属的访问组中，则该组中的工作人员可能只能查看或更新拥有者日记中的数据。

角色也用于控制对组织的管理功能的访问。在管理和健康/医疗角色之间存在区别。

参考图11，将描述工作人员访问拥有者的示例，包括访问组/工作人员角色概念。组织可以将拥有者放置在一个或多个访问组中，并且可以将工作人员置于一个或多个角色中。拥有者可以向组织提供许可，组织可以指定将哪些许可被转移到每个角色。以这种方式，患者(在LHD生态系统中称为拥有者)在任何时候完全控制对他们的记录的访问。该组织能够指定给予其工作人员的访问的级别，以及哪些工作人员具有对每个访问组的访问。

在图11的示例中，拥有者A给予组织XYZ特定的许可。组织XYZ将拥有者A放置于访问组A中。组织XYZ将工作人员ABC放置在访问组A中。组织XYZ将工作人员ABC放置在角色A和B中。只有拥有者和工作人员共享公共访问组时，工作人员才可以查看拥有者的帐户。工作人员可以访问拥有者帐户的程度由来自工作人员所属的所有角色的累积许可确定。然后，这些许可仅限于从拥有者的帐户提供给组织的那些许可。

参考图12，图示邀请的示例。拥有者能够邀请访客(第三方)访问拥有者的日记记录。这个处理在日记应用中进行管理。该处理取决于受邀人是否是当前用户而改变。

为了启动拥有者帐户的共享，从拥有者的帐户生成邀请。邀请由接收者将应当接受的邀请的许可的组合构成。可以将单个邀请发送给可能是患者、访问者或组织的单个接收者。工作人员无法直接收对拥有者帐户的邀请。

数据库和模块数据创建

可以以几种方式生成模块数据和数据仓内容，包括：

1)从纸质文件，经由日记的拥有者或LHD和/或其指定的合伙伴执行的扫描和数据输入处理；

2)来自第三方数据存储库，批量作为历史记录导入，或者在持续的基础上地用实时数据来更新日记；

3)从诸如命脉体征监视器、电子秤、锻炼监视器等设备，通过：

a)经由LHD的移动或桌面应用与设备集成；

b)在设备供应商的后端系统与日记的系统之间的集成；

c)任何其他中间者；

4)通过拥有者或其代表将数据直接输入到日记的用户界面中的一个。

任何输入数据可以合并要存储在数据仓中的数据和/或日记模块数据。并非每一块数据均包括两者。在两者都被包括的情况下，日记的用户可以从正在被查看的日记数据的项直接导航到数据仓中的相关联的数据。在可能的情况下，可以在创建日记和数据仓内容的同时自动地创建此链接。

图13图示用于将历史纸质文档导入到日记中的整体处理1300。类似的处理用于从文档(历史、更新、纸张和电子)导入任何数据。日记的用户在预先存在的模块数据和数据仓中的文档之间建立链接也是可能的。模块数据和数据仓文档可能是由用户创建的，或者通过一些自动化处理创建的；这个处理不依赖于这些项目的原始来源。

从状态1310开始，源纸质文件被接收，然后在状态1320通过任何已知的扫描仪进行扫描。移动到状态1330，所扫描的文档被解析，包括对对应的源文档的引用的一个或多个日记模块的数据被提取。

在状态1320扫描文档之后，处理1300将文档在状态1340处存档以便准备发送到日记。在某些实施例中，所扫描的文档被整理成批量PDF，例如具有有限数量的页面或最大文件大小。例如，如果在状态1320处有400页进入，则它们可以在状态1340中被分类成四个PDF，每个PDF有100页。在状态1330和1340完成之后，处理1300前进到状态1350，其中PDF被提供可用使得合并所解析的日记数据(文本/数字)和PDF的单个数据块可以被发送到日记系统用于包括在拥有者的日记中。在状态1350，日记数据和文档被封包。进行到状态1360，封包被日记收到和解封包。在状态1370处，日记数据被添加到的日记模块，包括到数据仓中对应文档的链接。此外，在状态1380处，文档被添加到数据仓。

图14是图示用于链接文档的处理1400的实施例的流程图。在某些实施例中，可以在图2A所图示的系统100上执行该处理。从状态1410开始，用户导航到模块数据项。在状态1420，用户激活控制以开始文档链接处理。在状态1430，向用户示出数据仓浏览器用户界面。在状态1440，用户选择要链接的文档(可选地为页面)。在状态1450，日记记录显示该模块数据项的链接。

一旦在模块数据项和数据仓文档之间的存在链接，该链接就呈现在该模块的数据项的细节被查看的任何地方。当点击时，打开文档(到页面索引被包含并可以被查看的正确页面)，或者如果文档在应用的环境(web浏览器、移动应用等)中不可查看，则会提示用户以正常方式从外部下载/查看文档。这可以通过以符合标准的方式实现链接来实现，例如对于PDF：https://www.lhdserver.com/DataVault/edicaldocument.pdf#page＝50。维护访问由许可系统介导的文档的安全性。

图15是图示访问数据仓的屏幕显示的示例。在某些实施例中，图15图示主数据仓页面的实施例。该页面示出按日期排序和过滤的选项。这完全是经由用户界面/API和数据库之间的正常交互完成的。不需要对后备存储的引用。

图16是图示用于数据仓的上传屏幕的屏幕显示的示例。点击图15中的上传文件按钮，用户将看到如图16所示的上传对话框。用户(如拥有者)可以选择选择文件按钮选择要上传到其数据仓的文件。对于本地/磁盘/平面数据仓文件，直接对web应用的HTTP服务器执行上传，并将文件写入磁盘，或者本地于服务器，或者作为网络共享。对于远程数据仓，执行以下操作：

·客户端(web或API)通知应用已准备好上传数据仓文档。

·应用针对调用客户端生成用于上传文档的URL。这通常由批量数据存储提供商(如Amazon AWS S3)提供的工具创建。然而，如果应用将代理上传本身，或者如果该文件要在本地存储，则其可以是本地URL。

·应用用上面生成的URL加上可能需要的其他元数据(标题HTTP动作等)来响应客户端。

·客户端对指定的URL执行HTTP上传(通常为POST)。

·客户端调用应用通知它上传已成功完成。该文档现在可用于在数据仓中使用。

图17是图示用于数据仓的用户选项的屏幕显示的示例。用户可以点击上下文菜单控件(文件条目右侧的三个条图标)来查看所选文件的上下文菜单。“查看详细信息”选项会导致文件详细信息的只读视图。此外，用户可以根据应用和允许来编辑、下载或删除文件。

取回数据仓文档包括以下两个处理之一：

·客户端尝试从应用服务器下载文档。然后，这将根据需要提供该文件或用重定向到第三方批量数据存储设施进行响应。

·客户端请求从中下载文档的URL。然后，应用根据需要发送本地URL或引用第三方批量数据存储设施的URL。

为了支持旧的API客户端，仍然可以支持旧的直接上传/下载API功能。如果它们被调用，则应用代表客户端执行上述步骤，有效代理上传或下载。

图18是图示拥有者和访客之间的邀请流1800的示意图。在某些实施例中，可以在图2A所示的系统100上执行该处理。邀请流程的步骤如下：

1.所有者发布邀请

·向访客发送的通知-*注意：电子邮件不包括链接

·拥有者帐户中列出的邀请-待处理，状态＝“发送”

·访客帐户中列出的邀请-待处理，状态＝“发送”

2.访客接受或拒绝邀请

a.接受-

·客户账号中列出的邀请-动作/待处理，状态＝“接受”

·拥有者帐户中列出的邀请-待处理，状态＝“接受”

b.拒绝-

客户账号中列出的邀请-/邀请/完成，状态＝“拒绝”

拥有者帐户中列出的邀请-/邀请/完成，状态＝“拒绝”

邀请工作流程完成–没有授权访问

*没有通知发送给拥有者通知邀请拒绝

3.拥有者确认或取消邀请

a.确认-

拥有者帐户中列出的邀请-/邀请/完成，状态＝“确认”

客户账号中列出的邀请-/邀请/完成，状态＝“确认”

邀请工作流程完成-访客现在可以访问拥有者帐户

b.取消-

拥有者帐户中列出的邀请-/邀请/完成，状态＝“取消”

客户帐户中列出的邀请-/邀请/完成，状态＝“取消”

邀请工作流程完成-无授权访问

*没有通知被发送给访客通知邀请取消

图19是图示用于邀请访客的处理1900的实施例的流程图。在某些实施例中，该处理可以在图2A所示的系统100上执行。

从状态1905开始，处理1900前进到状态1910以接收电子地址的输入，诸如非拥有者(例如访客)的电子邮件地址。处理1900移动到决定状态1915以确定是否存在具有在状态1910处输入的电子地址的访客的现有连接。在某些实施例中，总是进行该检查。其阻止向已经有连接或邀请的人发送新的邀请；用户必须编辑而不是发送新的邀请。在此之后，处理1900检查关于受邀人是否被邀请以首先创建帐户或者他们的当前帐户将被用于形成连接的现有的用户控制。如果存在在决定状态1915确定的现有连接，则处理1900移动到状态1920并且显示确认消息，诸如短语“已经存在与该客户的连接”，以及经由到编辑页面的链接来编辑现有许可或者取消关闭叠加的该邀请的选项。

如果在决定状态1915处确定没有现有连接，则处理1900移动到决定状态1925以确定是否存在现有邀请。如果存在现有邀请，则处理1900移动到状态1920并且显示验证消息，诸如短语“对该访客的邀请已经存在”以及编辑现有邀请(编辑待处理邀请)或者取消该邀请(关闭叠加)的选项。在状态1920完成之后，处理1900然后在状态1910处继续以输入访客的电子地址。

如果在决定状态1925处确定没有现有邀请，则处理1900进行到状态1930，数据的拥有者分配将授予访客的许可。在下文中将进一步描述许可的分配。继续在状态1935，例如当用户点击对话框上的OK按钮时，提交了具有邀请信息的表单。在状态1910和1930，该对话具有完成的字段，标识受邀人和要给予的许可。在状态1935，处理1900将该数据发送到LHDweb应用服务器150'，其可以检查信息的有效性(例如，具有良好的电子邮件地址)，并提示用户修复发现的任何问题。移动到决定状态1940，处理1900确定表单是否有效。如果在决定状态1940处确定了该表单不是有效的，则在状态1920处显示验证消息，并且处理1900然后在状态1910处继续以输入访客的电子地址。如果在决定状态1940处确定表单是有效的，则处理1900前进到决定状态1945以确定是否存在现有用户。如果存在现有用户，则处理1900移动状态1950以发送简单的邀请，包括例如短语“Hello<用户>，<拥有者>已邀请您加入...”。随着电子邮件消息，更新由处理1900完成，该处理生成邀请被发送(向拥有者)并且邀请被接收(对于访客)的通知。

然而，如果在决定状态1945处确定没有现有用户，则处理1900前进到状态1955以发送新帐户的邀请并准备例如短语“您好，<拥有者>已经邀请您加入...”并添加了用于创建帐户的链接。该邀请与电子邮件地址相关联，因此系统可以显示待处理邀请的通知。然后，处理1900在状态1960继续，所以用户可以创建帐户。在状态1950或状态1960完成时，处理1900前进到状态1965，其中邀请状态记录被创建并存储在核心数据库163(图2B)中。进行到状态1970，向接收者传递邀请，包括个性化消息、用于回复请求的专用的统一资源定位符(URL)、以及链接到与系统100相关联的常见问题(FAQ)页面。

图20是图示用于经由URL回复邀请的处理2000的实施例的流程图。在处理2000中，用户是访客。在某些实施例中，可以在图2A所示的系统100上执行该处理。从开始状态2005开始，处理2000前进到决定状态2010以确定用户是否登录。如果用户已登录，则处理2000移动到状态2015以显示邀请页面。如果在决定状态2010中确定用户未登录，则处理2000移动到状态2020以请求用户登录或开始新登录的处理。在状态2020完成后，用户登录并前进到状态2015以显示邀请页面。

前进到决定状态2025，处理2000确定邀请是否被接受。如果邀请被接受，则处理2000在状态2030向系统100的适当用户通知所接受的邀请。用户可以是邀请者(如果拥有者向他们自己的日记发送了邀请)，或者邀请访客和拥有者两者(如果访客向某人的日记发送邀请，他们是某人的陪护人员)。然而，如果在决定状态2025未接受邀请，则处理2000在状态2035向系统100的用户通知被拒绝的邀请。在状态2050处，处理2000向邀请者发送拒绝电子邮件，并生成邀请被拒绝(对拥有者)和邀请被拒绝(对于访客)的通知，并且移动到状态2055以显示与邀请的拒绝相关联的状态消息。

然而，如果邀请被接受并且在状态2030处通知用户，则处理2000进行到状态2040，并且与邀请相对应的许可被更新，诸如在许可数据库中。如果许可在状态2040被更新，则处理2000前进到状态2055以通知适当的用户邀请被接受，包括向邀请者发送确认电子邮件，并且生成对于拥有者和访客邀请被确认的通知。处理2000在状态2030处显示关于所接受的邀请的状态消息，并且处理2000结束。

图21是图示用于邀请组织的数据拥有者的处理2100的实施例的流程图。在某些实施例中，可以在图2A所图示的系统100上执行该处理。从开始状态2105开始，拥有者通过在状态2110处输入组织的名称或在状态2115处输入医生的名称来邀请组织，例如其中在状态2120至2130可以确定医生的组织。在状态2120处处理2100查找组织的帐户。进行到状态2125，针对组织的查找的结果由处理2100显示，并且在状态2130处接收到期望组织的选择。前进到决定状态2135，处理2100确定所选择的组织是否被系统100识别。如果组织不被识别，则处理2100移动到状态2145并向拥有者显示可能的选项。如果如在决定状态2135处确定的组织被识别，则处理2100继续处于决定状态2140以确定组织是否具有对拥有者帐户的现有访问。如果组织具有现有访问许可，则处理2100移动到状态2155，并向拥有者显示关于现有访问的内联消息。在显示消息之后，处理2100返回到在状态2110或2115可以输入组织或医生的名称的屏幕。

在决定状态2140处继续，如果没有现有访问，则处理2100移动到状态2150以将许可委托给组织。与委托许可的路径并行，状态2160允许拥有者将给组织的电子邮件个性化。在状态2150处的许可委托之后，处理2100前进到状态2165，其中具有许可的表单被提交并且在决定状态2170处检查其有效性。如果表单无效，则处理移动到状态2155并向拥有者显示对应的内联消息。如果表单在决定状态2170处确定为有效，则处理2100进行到状态2175，其中邀请状态记录被创建例，如在核心数据库163的邀请表中。进行到状态2180，来自状态2160的个性化的电子邮件消息作为通知的一部分被发送，并且处理2100以发送的通知结束。

图22是图示用于授予对日记的访问的处理2200的实施例的流程图。在某些实施例中，可以在图2A所示的系统100上执行该处理。从状态2205开始，处理2200移动到状态2210，以在诸如电子邮件的电子通信中输入个人或实体的名称。进行到状态2215，处理2200创建具有子建议许可记录的邀请记录。在状态2220处继续，处理2200向该人或实体发送邀请电子邮件。在状态2225处继续，受邀者点击电子邮件中的URL，处理2200确定在决定状态2230处是否需要登录或创建帐户动作。如果受邀人没有与系统100的帐户，则处理2200移动到功能2235，其中为受邀人创建帐户，并且可以在创建帐户之后执行登录。如果受邀人如在决定状态2230处确定的具有与系统100的帐户，则处理2200移动到功能2240，其中受邀人可以登录到系统。在功能2235或2240完成时，处理2200确定邀请是否被受邀人接受或拒绝。如果邀请被拒绝，则处理2200在状态2250处继续，其中基于拒绝更新邀请状态记录，并且处理在结束状态2255处结束。

然而，如果在决定状态2245处确定邀请被接受，则处理2200前进到状态2260，并用用户标识更新核心数据库163中的邀请表。在状态2265处继续，处理2200经由电子通信信道(例如，电子邮件)向原始拥有者请求者发送接受通知。移动到状态2270，拥有者请求者选择与电子邮件中受邀人对应的URL，然后如在决定状态2275确定的要么授权或确认受邀者的接受要么取消邀请。如果邀请被取消，则处理2200进行到状态2250，其中邀请记录被更新以反映取消。如果如在决定状态2275处确定的邀请被授权，则处理2200前进到状态2280并创建访问记录，并将所提出的许可记录复制到核心数据库163中的显式许可表。处理2200在结束状态2285处结束。

图23-29图示邀请用户界面的示例。图23是图示用于查看当前邀请以及在邀请处理中进行的新邀请的的屏幕的屏幕显示的示例。拥有者可以查看他们当前的邀请。在这个页面上，他们还可以邀请新的访客查看他们的日记，或者邀请组织参与拥有者的医疗护理。

图24是图示用于输入关于访客的信息和为访客授予的许可的界面屏幕的屏幕显示的示例。点击“邀请访客”按钮后，显示对话框，其中拥有者可以输入要邀请的人的详细信息，以及他们想要给予该人的许可。例如，拥有者可以从帐户、访问、日记和数据仓组标题中的私有(无)、查看(读取)和访问(写入)许可中进行选择，其中在某些实施例中，日记具有多个类别/类型/模块的数据，每个都具有私有、查看和访问许可的选项。

图25是图示电子邮件发送邀请的示例的屏幕显示的示例。一旦细节完成并且选择了许可，则可以在图24的显示屏幕中点击发送按钮，从而向受邀人发送邀请电子邮件，诸如图25所示的示例电子邮件。受邀人可以被要求创建强密码并阅读用于使用系统100的条款和条件。

图26是图示诸如使用图23的显示取回的邀请细节的屏幕显示的示例。邀请可以出现在待处理页面的邀请被发送面板中(参见图23)。每个邀请的详细信息可由拥有者和受邀人取回和查看。

图27是图示邀请完成屏幕的屏幕显示的示例，其中拥有者和访客可以查看完成的邀请。一旦邀请处理已经完成，拥有者和访客可以查看如图27所示的这些邀请。

图28是图示访客对拥有者帐户的活动的审计的屏幕显示的示例。访客对拥有者帐户采取的动作的审计可由拥有者查看。

图29是图示为特定访客给予对他们的日记访问的拥有者的摘要的屏幕显示的示例。访客可以看到已经给访客访问他们的日记的拥有者的摘要。

日记实现易于使用界面以允许拥有者控制对他们的日记数据的访问。图30是图示当用户(例如，拥有者)期望更新分配给访客的许可时由用户(例如，拥有者)看到的界面屏幕的屏幕显示的示例。图30的示例是当web应用的用户期望更新分配的访客许可时由web应用的用户看到的界面。访客的信息显示在此弹出对话框的顶部。存在此示例中示出的四组许可-帐户、访问、日记和数据仓。每个都包括一个或多个更细粒度的许可。拥有者可以为每个许可在如下三种设置之间选择：

·私有–由该许可控制的数据不能由此访客访问。

·查看-由该许可控制的数据只能由该访客查看(只读)。访客无法添加、编辑或删除数据或与它相关联的元数据中的任何一个。

·访问-由该此许可控制的数据可由此访客查看、添加、编辑或删除。

图31是图示当用户(例如，拥有者)期望向组织中的角色分配许可时由用户(例如，拥有者)看到的界面屏幕的屏幕显示的示例。存在特别地与组织的管理有关的许可。这些只能分配给角色，使得它们可以被传递给工作人员。

组织可以创建和删除访问(患者)组和角色，并控制他们的成员资格。

角色

图32是图示当组织的管理员期望管理组织中的角色时由组织的管理员看到的界面屏幕的屏幕显示的示例。该图图示如由组织管理员可以看到的角色列表的示例。在此页面中，管理员可以添加新角色，删除角色，编辑角色的许可，并选择哪些工作人员属于角色。

图33是图示当组织的管理员期望在组织中创建角色时由组织的管理员看到的界面屏幕的屏幕显示的示例。点击图32所示的新角色按钮将导致如图33所示的对话框。在对话框中，用户可以在此处选择名称并输入此新角色的描述。用户必须选择角色是日记访问角色(允许根据许可来访问拥有者日记)或组织角色(允许访问此组织的管理功能)。此选择将控制哪些种类的许可可以分配给此角色。

图34是图示由组织的管理员所看到的、对组织中的对应角色执行的操作的界面屏幕的屏幕显示的示例。点击菜单控件将带来可以对对应角色执行的操作的菜单，诸如管理成员、管理许可、编辑角色或删除角色。

图35是图示由管理工作人员中组织的管理员所看到的的界面屏幕的屏幕显示的示例。在图34的显示中选择“管理成员”会导致如图35所图示的示例对话框。这里能够点击成员旁边的“X”控件将其从该角色中移除。“将工作人员添加到角色”按钮示出允许用户定位并选择要添加到角色的工作人员的控件。

图36是图示由组织的管理员所看到的用于管理组织角色的角色许可的界面屏幕的屏幕显示的示例。这取决于在图33所示的对话框中选择哪个选项(日记访问或组织)来达到。角色用于日记访问或组织，并且只能被分配适当的许可。选择图34中的菜单“管理许可”项可以导致组织可以选择经由此角色的成员资格来委托给其工作人员的许可列表。在这种情况下，如图36所示是针对组织角色的示例许可(例如访问)。

图37是图示由组织的管理员看到的用于管理日记访问角色的角色许可的界面屏幕的屏幕显示的示例。对于日记访问角色，在图37中示出了日记的多个类别的示例许可(例如，私有)。

访问组

图38是图示组织的管理员所看到的用于管理拥有者组的界面屏幕的屏幕显示的示例。图38中显示了如由组织的管理员可以看到的拥有者组的列表。在此页面中，管理员可以添加新组、删除组、并选择哪个拥有者和工作人员属于组。

图39是图示由组织的管理员所看到的用于输入新组的名称和描述的屏幕的屏幕显示的示例。点击图38中的“新建组”按钮将导致示出图39中的对话框，该对话框邀请用户输入新组的名称和描述的。

图40是图示组织的管理员所看到的用于显示可以对对应组执行的操作的界面屏幕的屏幕显示的示例。点击菜单控件可以带来可以对对应角色执行的操作的菜单。例如，操作可以包括：管理用户(组)、编辑组和删除组。

图41是图示由组织的管理员所看到的用于选择对应组的拥有者的界面的屏幕显示的示例。“管理组拥有者”操作允许用户(例如，组织的管理员)选择哪些拥有者将在对应的组中。显示包括用于查找系统100中的附加的拥有者的选项。

图42是图示由组织的管理员所看到的用于为对应组选择工作人员的界面的屏幕显示的示例。“管理组-工作人员”操作允许用户(例如组织的管理员)选择哪些工作人员将在对应的组中。显示包括用于在系统100中查找附加的工作人员的选项。

图43是图示组织的管理员所看到的用于编辑对应组的名称和描述的界面的屏幕显示的示例。如图40所示，“编辑组”操作允许用户(例如，组织的管理员)编辑对应的组，包括例如改变组的名称和描述。

图44是图示用于确定是否呈现用户界面元素(即确定特定用户界面元素的可见性)的处理4400的实施例的流程图。在某些实施例中，可以在图2A所示的系统100上执行该处理。XML定义文件(例如，下面描述的站点地图)被用作处理4400的一部分。在某些实施例中，每个UI元素需要关于是否应被呈现的条件检查。

针对每个用户界面(UI)元素，从开始状态4410开始，处理4400进行到决定状态4420以确定其对应的特征是否被使能。该应用具有可以在每个用户的基础上打开或关闭的多个特征。在某些实施例中，这些特征是：语言选择、护理团队和实验室结果文档链接，但是可以添加更多的特征。向用户分配这些被记录在一个简单的链接表(例如PersonApplicationFeature)中。检查处理可以是：

·确定给定的UI元素是否是应用特征的一部分。如果不是，此检查通过。

·确定当前用户是否已分配对UI元素应用特征的访问。如果是，则检查通过。

·否则，检查失败，并且处理移动到不呈现状态4460。

只有检查通过才会显示元素。

进行到决定状态4430，处理4400确定UI元素对于当前应用模式是有效的。用户的应用上下文可以是多种模式之一。这给用户呈现了适合该模式所需功能的UI。在某些实施例中，模式是：患者、工作人员和访问者。该系统被设计使得如果成为需求，立即针对用户会话支持多模式是可能的。检查处理是：

·如果该元素不是特定于任何模式，则检查通过。

·如果该元素的模式对应于用户的当前模式，则检查将通过。

·否则，检查失败，并且处理移动到不呈现状态4460。

只有检查通过才会显示元素。

进行到决定状态4440，处理4400确定当前用户是否具有足够的许可。每个用户都具有对数据(包括日记(医疗/健康)数据、数据仓文档、组织配置设置、用户简档设置等)的许可集合。在某些实施例中，用户具有暗示的许可以利用自己的数据工作，并且可以具有访问和更新其他用户的数据的许可。如果该元素被记录为与特定类型的许可(在前面提到的sitemap.xml文件中)相关，当前用户将需要具有该许可以便于能够看到UI元素。下面进一步描述组织成员和访客的许可确定。如果用户具有足够的许可，则处理4400进行到状态4450以呈现UI元素。否则，检查失败，并且处理移动到不呈现状态4460。对于其他UI元素重复处理4400，以便完成用户界面。

结合下面描述的图45和46提供许可计算处理的描述。本节处理用于存储许可相关数据的示例数据库结构。许可系统中的许可表定义了可被分配的许可集合。这个数据通常是静态的。示例许可表如下所示：

ParentPermId字段指示可以用于标识涵盖所请求的许可的许可的双亲许可标识符。例如，吸烟的双亲许可标识符是Id 12，其是日记，其中涵盖Id 28，吸烟。并非所有许可都可以使用或可见的-“可见”列控制这一点。

许可可以经由链接表分配给其他实体，如下所示：

·ExplicitPermission：Id、PersonId、PatientId、PermissionId、ReadOnly。用于分配许可(PermissionId)以将来自特定拥有者(PatientId)的数据用于具有完全访问或只读访问(ReadOnly)的日记的给定用户(PersonId)。

·OrganizationExplicitPermission：Id、OrganizationId、PatientId、PermissionId、ReadOnly。用于分配许可(PermissionId)以将来自特定拥有者(PatientId)的数据用于具有完全访问或只读访问(ReadOnly)的给定组织(OrganizationId)。当组织的工作人员经由其角色由组织给予的适当许可时，由该许可允许的数据然后可以由该组织的工作人员访问。

·ProposedPermission：Id、InvitationId、PermissionId、ReadOnly。当(向另一个用户或向组织)发送邀请时，建议的许可集合与之相关联。该表包含许可到邀请的映射。当邀请处理成功完成时，它将转换为ExplicitPermission或OrganizationExplicitPermission。

·RolePermission：Id、RoleId、PermissionId、ReadOnly。为角色分配许可。角色组织控制角色和许可之间的映射。其还控制哪些工作人员是哪个角色的成员，以及哪些工作人员属于哪个患者组。

·PatientGroup：Id、Name、OrganizationId、UID、Description。PatientGroup属于单个组织(OrganizationId)。组织控制哪些患者(拥有者)属于每个患者组。

·PatientToPatientGroupLink：PatientId、PatientGroupId。链接表记录患者(拥有者)到患者组的分配(由拥有患者组的组织执行)。

·StaffMemberToPatientGroupLink：StaffMemberId、PatientGroupId。链接表用于记录工作人员到患者组的分配(由拥有患者组的组织执行)。如果工作人员共享公共患者组，则工作人员只能访问拥有者(患者)的数据。

·StaffMemberToRoleLink：StaffMemberId、RoleId。链接表记录工作人员到角色的分配(由拥有角色的组织执行)。如果工作人员从他们的角色继承他们想访问的数据的适当许可，则工作人员只能访问拥有者(患者)的数据。

许可层次

在某些实施例中，许可层次如下：

组织

患者管理

工作人员管理

系统管理

报告

患者

简档

通信

帐户

访问

管理帐户访问

日记

过敏

喝酒

身体活动

环境

条件

免疫

实验室结果

生活事件

药物治疗

心情

营养

疼痛

日记备注

患者压力

睡觉

抽烟

症状

治疗

命脉体征

临床备注

命脉

身体测量

感觉

数据仓

文档访问

许可计算

当日记的用户想要查看或改变拥有者日记中的数据时，应用需要检查当前用户是否具有这样做的许可。日记许可指定要访问的数据类型，以及该访问是否仅需要查看，或者其是否涉及改变日记(创建、更新或删除记录)。一旦应用计算要访问哪种数据，以及用户是正编辑还是仅是正在查看，则可以按照以下处理来确定是否应当允许访问。用户将在工作人员或访客的上下文中动作，并且该处理基于该区别而不同。

图45是图示用于确定组织的特定工作人员是否基于许可具有对拥有者的数据的访问的处理4500的实施例的流程图。在某些实施例中，可以在图2A所示的系统100上执行该处理。当组织的工作人员(例如医生)试图访问来自拥有者的任何日记数据块时，遵循该处理4500。

当给定组织的工作人员尝试访问来自拥有者的日记的数据项时，从开始状态4510开始，处理4500移动到决定状态4520，其中确定工作人员和拥有者是否共享访问组(其在某些实施例中是患者组)的决定被做出。工作人员必须被分配给包含给定拥有者(患者)的访问组。如果没有，组织没有授权工作人员访问该组(因此该患者)，所以在状态4560处许可被拒绝。

进行到决定状态4530，处理4500确定角色是否具有许可。对于工作人员所属的每个角色，检查组织是否已经给出与匹配请求的许可。这表明已经给出了具体的许可，或者已经给出了涵盖所请求的许可的任何许可，诸如上面描述的。如果没有角色具有许可，则访问在状态4560处被拒绝。

前进到决定状态4540，处理4500确定组织是否具有许可。进行关于拥有者是否已经给予特定组织与请求匹配的许可的检查。这表明已经给出了特定许可，或者已经给出了涵盖所请求的许可的任何许可。如果组织没有许可，则在状态4560处访问被拒绝。如果已经满足在决定状态4520、4530和4540处的所有先前要求，则工作人员由拥有者和组织两者授权访问。因此，允许它们查看所请求的数据。注意，在决定状态4520、4530和4540处的检查可以以任何顺序执行。

图46是图示用于基于许可来确定特定访客是否具有对拥有者的数据的访问的处理4600的实施例的流程图。在某些实施例中，该处理可以在图2A所示的系统100上执行。当访客尝试访问来自拥有者的任何日记数据块时，遵循该处理4600。

当访客试图访问来自拥有者的日记数据项时，从开始状态4610开始，处理4600移动到决定状态4620，其中访客是否具有许可的确定被做出。处理4600检查访客是否已经由拥有者给出与请求匹配的许可。这意味着已经给出了特定许可，或者已经给出了涵盖所请求的许可的任何许可。如果如在决定状态4620确定的访客具有许可，则处理4600进行到状态4630，并且访客被拥有者授权访问。允许访客查看请求的数据。如果如在决定状态4620确定的访客没有许可，则处理4600进行到状态4634，并且访问被拒绝。针于访客的处理4600比针对工作人员的处理简单，因为拥有者直接向访客提供许可，并且在他们之间形成链接。

实现细节和动态用户界面

基于许可的安全性在多层中实现。在某些实施例中，旨在用户界面仅示出对用户可用的选项。例如如果当前用户没有查看数据仓的许可，则导航栏中的数据仓控件不应该是可见的。

在某些实施例中，站点布局由以XML定义的灵活站点地图定义。示例网站地图(简化)如下：

<sitemap>

<group title＝"Diary"resourcekey＝"Navigation_Diary"modes＝"Patient">

<item title＝"Pulse"resourcekey＝"Navigation_Pulse"controller＝"Pulse"

action＝"Index"area＝"PatientDiary"cssclass＝"pulse">

<systemmoduleitems/>

</item>

<item id＝"Timeline"title＝"Timeline"resourcekey＝"Navigation_Timeline"

controller＝"Timeline"action＝"Index"area＝"PatientDiary"cssclass＝"timeline"/>

<item title＝"Data Vault"resourcekey＝"Navigation_DataVault"

controller＝"DataVault"

action＝"Index"area＝"PatientDiary"cssclass＝"datavault"/>

</group>

<group title＝"Connections"resourcekey＝"Navigation_Connections">

<item title＝"User Management"controller＝"Users"action＝"Index"

area＝"Organization"modes＝"Staff"permission＝"StaffManagement"

cssclass＝"user-management">

<linkeditem controller＝"PatientGroups"action＝"Index"area＝"Organization"/>

<linkeditem controller＝"Roles"action＝"Index"area＝"Organization"/>

<linkeditem controller＝"Staff"action＝"Index"area＝"Organization"/>

</item>

<item title＝"Invitations"controller＝"Invitation"action＝"Index"

area＝"Organization"modes＝"Staff"permission＝"PatientManagement"

cssclass＝"invitations">

<linkeditem controller＝"Invitation"action＝"Completed"area＝"Organization"/>

</item>

<item title＝"Owners"controller＝"StaffProfile"action＝"Owners"

area＝"Organization"

modes＝"Staff"permission＝"PatientManagement"cssclass＝"owners"/>

<item title＝"Guests"controller＝"AccessGiven"action＝"Index"

area＝"PatientAccount"

modes＝"Patient"permission＝"PatientAccess"cssclass＝"guests">

<linkeditem controller＝"AccessGiven"action＝"Friends"area＝"PatientAccount"/>

</item>

<item title＝"Owners"controller＝"AccessReceived"action＝"Index"

area＝"PatientAccount"modes＝"Patient"permission＝"PatientAccess"

cssclass＝"owners"/>

<item title＝"Care Team"resourcekey＝"Navigation_CareTeam"controller＝"CareTeam"

action＝"Index"area＝"PatientDiary"cssclass＝"careteam"

requiresenabledfeature＝"CareTeam"/>

</group>

<group title＝"Admin"permission＝"StaffManagement"modes＝"Staff">

<item title＝"Organization Profile"controller＝"Profile"action＝"Index"

area＝"Organization"permission＝"SystemManagement"

cssclass＝"organization-profile"/>

</group>

<group title＝"Account"resourcekey＝"Navigation_Account">

<item title＝"Profile"controller＝"Profile"action＝"Index"area＝"Visitor"

modes＝"Visitor"cssclass＝"profile">

<linkeditem title＝"Password"controller＝"Profile"action＝"ChangePassword"

area＝"Visitor"/>

</item>

<item title＝"Profile"controller＝"MinimalProfile"action＝"Index"

area＝"PatientAccount"modes＝"Patient"permissionabsent＝"Profile"

cssclass＝"profile"/>

<item title＝"Notification"controller＝"Notification"action＝"Index"

area＝"PatientAccount"modes＝"Patient"permission＝"Profile"disabled＝"true"

cssclass＝"notification"/>

<item title＝"Preferences"controller＝"Settings"action＝"Index"

area＝"PatientAccount"modes＝"Patient"permission＝"Profile"

cssclass＝"preferences"/>

</group>

</sitemap>

站点地图定义何时应显示用户界面的每个部分。对于每个项，它定义标题文本、对应的动作(经由区域、控制器和动作属性)，以及在哪种情况下它应当被示出。术语区域、控制器和动作都是ASP.Net MVC标准术语，并且被使用如下：<item title＝"UserManagement"controller＝"Users"action＝"Index"area＝"Organization"modes＝"Staff"permission＝"StaffManagement"cssclass＝"user-management">。核心应用功能分为多个区域。区域的示例(在此显示)是“组织”。该区域包含特定于组织用户的所有功能。在这种情况下，该项目包括用户管理(对于该组织)-患者组、角色和工作人员。如果当前登录不在组织上下文中操作，则该项目将不会被示出，因为组织区域不相关。“用户”是组织区域内特定控制器的名称，并且索引是该控制器上的操作。用户控制器是针对组织区域内所有基于用户的功能的管理员。索引是该控制器的特定动作；在这种情况下，这是当用户输入该应用区域时示出的主要默认页面。总而言之，如果当前用户是具有StaffManagement许可(许可＝“StaffManagement”)的工作人员(模式＝“工作人员”)，则他们可以在该区域“组织”中看到控制器“用户”上的动作“索引”。

“模式”基于当前登录的用户的类型，控制可视性，例如：

·患者：拥有者正在查看他们自己的日记；

·访客：访客正在查看拥有者的日记；

·工作人员：工作人员正在使用该应用，并且可以能够看到组织管理功能(用适当的许可)。

可见性也由许可的存在来控制。“permission”和“permissionabsent”属性可以分别用于示出仅在给定许可存在或缺失时的用户界面特征。还要注意“requiresenabledfeature”属性，它基于某些应用特征当前是否被使能来控制用户界面部件的可见性。

后端许可强制执行

除了修改UI以便仅向用户呈现相关特征集合之外，后端强制执行许可限制。这主要通过在ASP.NET框架中将属性应用于MVC控制器来实现，例如在以下示例中：

PatientRequired属性强制执行当前用户必须具有当前患者上下文的要求。查看他们自己的日记的拥有者或查看另一位拥有者日记的访客满足此要求。其唯一许可是组织管理相关许可的工作人员将不会在患者上下文中操作，因此在本示例中将被拒绝访问。

PatientAuthorize属性指定当前用户对于当前日记必须具有哪些许可才能继续。在这种情况下，必须存在“简档”许可。另外，指定用户必须具有完全许可，只读是不足的(在此示例中第二个参数为“true”)。

另外，当控制器总体只需要只读许可时，MVC控制器上的某些动作可能需要完全访问。参见以下示例：

在上述示例中，默认情况下，对LabResultController的动作的访问只需要“LabResults”许可，无论是只读还是完全访问。然而，针对编辑动作对于用户将是可访问的，必须存在完全访问的“LabResults”许可；只读版本是不够的，并将导致该动作被拒绝。

基于许可更新用户界面

取决于谁正在查看拥有者的日记，拥有者的日记的视图可以不同。日记的拥有者可以无限制地看到整个日记。经由邀请(例如，访客和组织的工作人员)查看日记的用户可以具有通过由拥有者(以及由组织，工作人员)设定的许可而被限于日记的子集的视图。这在每种情况下体现在不同的用户界面(UI)体验中。

对用户界面的影响

图47是图示由如图所示已经设置了某些许可的拥有者所看到的界面屏幕的屏幕显示的示例。在图47的示例中，拥有者已经设置了某些许可。请注意，访问仅给予睡眠模块和吸烟模块。睡眠是只读的，并且完全写入访问被给予吸烟。当该访客选择查看该日记时，他们在UI中看到的选项是有限的。

图48是图示当拥有者点击“加号”图标以查看哪些模块可以添加数据时显示数据模块列表的界面的屏幕显示的示例。图48图示当拥有者点击“加号”图标时示出的示例列表的一部分。所有模块都被示出在图48所示的下拉列表中。在其他实施例中，Plus图标打开诸如用于输入新数据的输入屏幕。

图49是图示当访客对图48的日记执行相同动作时显示限制于相关项的模块的列表的界面的屏幕显示的示例。所有模块在图48中所图示的下拉列表中示出。然而，如果访客对此日记执行相同的动作，他们的许可只允许他们输入针对吸烟模块的数据，因此列表仅限于相关项目。

图50是图示针对日记访客看到的脉搏页面的界面的屏幕显示的示例。从模块查看数据时，应用类似的规则。在某些实施例中，脉搏页面是拥有者日记的仪表板，其允许用户将其日记的重要方面放在一页上。这是拥有者和访客可以扫视与他们相关的内容而无需在整个应用中导航。在图50针对该日记由访客所看到的脉搏页面上，只能选择对其访客具有查看许可的模块。

图51是图示已经被选择但由于许可限制而无法取回所有模块的数据的时间轴的界面屏幕的屏幕显示的示例。在图51的时间轴视图中，已经被选择但由于许可限制而无法取回数据的任何时间轴模块显示通知用户某些数据对他们不可用的消息。

图52是图示示时间轴页面的界面屏幕的屏幕显示的示例，时间轴页面示出拥有者数据的基于时间的概述。用户可以选择要查看哪个模块(如果用户不是拥有者，则服从于许可)。时间轴页面示出拥有者数据的基于时间的摘要。数据以线性日历状视图示出，其中时间在X轴上，不同模块(及其中的数据)在Y轴上。

时间轴是包括特定日记的数据的时间相关的、聚集的视图。时间轴的视口(当前显示的区域)可以放大和缩小(例如，按日、周、月、和年)，并且还可以在时间上进行前进和后退。可以选择日记数据的任何子集进行查看，并按照适合查看者需求的顺序进行选择。在某些实施例中，模块可以按照用户选择的顺序(诸如例如拖放重新排序或其他重新排序的方式)来布置。

时间轴提供标识不同数据类型之间的相关性的能力，并且为查看者提供使他们自己快速熟悉日记所代表的个人的状况/历史的能力。时间轴还为数据显示针提供容易被配置以满足当前查看者的目标/兴趣的能力，并提供在健康历史记录中的任何时刻容易地/快速地导航到任何特定数据的能力。

通常，患者医疗信息使用XML数据导出文件被收集到逗号分隔值(CSV)文件中，然后手动地显示在电子表格中。这种电子表格的不同视图使得时间相关性非常具有挑战性，因为如按药物名称的排序，与剂量和药物中的任何改变一样，日期可能会无序。另一方面，其他排序则意味着药物名称混在一起，使视图更加混乱。现有技术的状态的整体效果是使决定和判断耗时、非直观、复杂，通常需要特定的专业知识。

相比之下，图51和52中所阐述的是以对于所有护理团队成员特别直观和有帮助的方式提供相关数据的显示格式的示例。时间轴显示拥有者的每个模块和访客或在组织的工作人员已被授予许可的模块。每个模块都可以有附加控件，诸如列表视图或图形视图，以及下拉菜单，诸如例如：1)按何排序，2)接何查看和3)按何颜色。

可以使用一致的符号集合来显示模块数据，以表示生理测量、药物、剂量、开始和停止等。在某些实施例中，每行包含一个变量(例如药物)或可选的相关变量集合的数据。在其他实施例中，一个变量的数据可以显示在多行上。这些行集合根据授权的许可被显示在屏幕或页面上。这些行可以被同步，使得所有行都具有相同的起始时间、结束时间、和时间尺度。这允许用户查看数据之间的相关性和其他关系。在现有系统中，这些相关性和关系难于或不可能理解的，因为它们来自由不同来源提供并且分开存储的数据。

时间轴显示具有在拥有者的控制下的具有精细粒度的三个级别的控制：1)发送和接受邀请，2)选择在组级别处的并向下到模块级别的模块(类别或类型)许可的访问类型(无或私有、读取、或编辑)，以及3)向下到模块级别的许可。此外，用户(例如，访客)在选择用于显示的时间框架方面在时间轴级别和在模块级别具有控件，例如，列表或图表视图以及用于按视图、按颜色、和按排序的过滤的菜单。例如，在某些实施例中，数据过滤包括例如诸如过滤敏感数据、临床医生与非临床医生输入的数据、和/或由特定用户输入的数据等选项。在其他实施例中可以使用其他过滤选项。在某些实施例中，模块的“按何排序”下拉列表可以包括例如名称、日期、升序或降序的选项。模块的“按何查看”下拉列表可以包括例如平均值、最小值或最大值的选项。模块的“按何着色”下拉列表可以包括例如根据该单元格中表示的各种数量来对单元着色的选项。

因此，拥有者控制谁可以访问他们的数据、访问类型、以及所有下至类别或模块的粒度级别的许可。模块可以显示用户没有查看模块数据的许可的语句，用户没有针对该模块至少查看的许可。

在某些实施例中，显示屏幕呈现关于患者正在服用的药物以及对药物方案的修改的清楚信息。这些屏幕图示更好地吸收、查看以及分析复杂的药物方案及他们随时间的相对改变的方式。

应当注意，在这些实施例中，启动药物以及在一些实施例中停止药物的日期被示出并与药物名称、用量和修改中的一个或多个相关联。这使得阅读、理解和判断药物数据显著地更容易和更快地进行。这可能不仅允许专家(如稀少和昂贵的临床药理学家)查看和理解数据，还可以允许医生、临床医生、初级职员、研究人员、陪护人员、患者及其家属、以及任何其他受邀和准许的一方查看和理解数据。

在一些实施例中，显示时间轴或其他图形的步骤，提供了示出包括但不限于患者的年龄、性别、位置、工作、生活方式选择、生活事件、包括预先存在的条件的基本健康状况、遗传标识符、症状、治疗、药物或其他健康相关变量的数据。在其他实施例中，数据包括临床数据连同生活方式数据、心理社会数据、环境数据和遗传数据。该步骤可以在评估上述患者变量中的药物或治疗成功、发现禁忌症、或以其他方式评估药物功效和/或患者反应方面是有用的。

示例时间轴屏幕显示图示特定患者的医学信息的摘要页面，其可以使用时间相关性相对于患者背景/症状信息而被绘制。这种显示的优点包括但不限于丰富对患者病史的临床理解，减少疏忽和错误，并改善健康结果和患者参与。图52可以包括易于理解的患者对他们的药物方案中的可能的药物或改变的反应的图形分析。这样的图形分析帮助标识可能的禁忌症和可能的不利影响来源。

对于如图52所示的个体患者或基于人群健康(未示出)，健康治疗的替代形式可以比常规治疗方案更容易。通过系统和方法可能做出的优化的其他领域包括但不限于补充和营养、生活事件、生活方式、传统、补充和替代药物、治疗方案、患者输入和反馈、以及其他健康专业人员输入和反馈的优化。

将各种数据集合(例如，实验室测试、药物、命脉体征、症状等)针对每个特定患者被呈现在单页概要上。数据集合可以用源自不同方面的数据以不同颜色或其他标记来图形地概述。

即使时间轴页面大于屏幕尺寸，用户仅需要滚动以显示所有期望的数据，而不必必须以相邻查看的相关延迟和困难来导航其他网页的附加链接。优选地，所有上述模块或医疗信息的类别都提供在页面上，尽管在某些情况下可以呈现这种数据的子集。

系统和方法突出了在分散的数据集合中可能不容易看到的问题。更容易理解的显示有助于更快速且更全面地了解患者用药方案，命脉、实验室结果、体征和症状、以及其他背景健康数据。

系统和方法的一个优点是具有适当许可的医疗护理团队(多学科护理团队)的所有成员(包括患者和护理人员(例如，家庭和其他主要护理人员))以及自动医学数据馈送都可以输入其相应的数据，并仍然将其整理并显示在相同单个概述页面上。这种能力从根本上改变了护理团队的所有成员在任何时间内参照所有数据全面地查看患者状况的能力。

该系统和方法具有作为多学科护理团队的协作工具的能力，该能力包括使患者或其家人能够成为护理团队的一部分，提醒他们重要的风险和对患者情况的改变。

通过患者同意，患者护理团队的多个成员可能被邀请到患者记录，允许所有授权的团队成员查看患者的医疗状态的一部分或全部(取决于授予的许可的级别)。与用于在单个页面上呈现和显示所有护理团队成员的数据输入的系统和方法的能力相结合该邀请功能，无论是对于个人决策还是通过协作，均显著地提高了护理团队的协作和效率。

图53是图示用于显示可用于利用模块的数据工作的每个模块的页面的界面的屏幕显示的示例。每个模块都有可用于利用该模块的数据工作(例如添加新条目，经由过滤器来定位条目，删除或修改先前的条目)的对应的页面，。

图54是图示由用户所看到的用于导航拥有者的时间轴的界面屏幕的一部分的屏幕显示的示例。在某些实施例中，该部分允许用户从日、周、月或年中选择聚集级别，以及与聚集级别选择对应的开始日期或结束日期。在其他实施例中可以使用其他聚集级别。

图55是图示用于示出可能的聚集级别的示例的时间轴的界面屏幕的日历栏部分的屏幕显示的示例。在接收到包括从天、周、月、年的聚集级别选择以及与聚集等级选择相对应的开始日期或结束日期的时间轴显示的请求之后，系统呈现日历栏。这可以包括根据接收到的请求来呈现具有两个行部分的日历栏，使得底行部分根据与聚集级别选择相对应的开始日期或结束日期来显示具有日期的一系列块(例如，对于每天的聚集级别的12月29日、对于每周的聚集级别的9月25日至31日、对于每月的聚集级别的五月、和对于每年的聚集级别的1994年)。这可以进一步包括呈现顶行部分以在所选择的聚集级别显示一系列点，其中亮点表示在所选聚集级别的一段时间内缺少拥有者数据，而暗点表示对于此时段(例如，每日、每周、每月或每年)存在拥有者数据。在一定聚集级别中，对应的月或年也会以点显示，以标识存在和缺少数据的时间表，例如对于每天的聚集级别，显示月集合，以及对于每周或每月级别，显示年集合。呈现可以进一步包括呈现，使得日历栏的顶行部分在与底行部分中的日期相对应的点上显示突出显示的块，并且使得如果光标被移动以悬停在顶行部分的另一部分上，另一个突出显示的块被显示对应于悬停光标的位置，使得如果在悬停光标的位置处接收到点击(例如，使用鼠标或键盘)事件，则时间轴根据所选择的聚集级别显示对应于点击的日期的数据。日记支持数据事件的一天中的精确时间的输入。因此，在其他实施例中，时间轴可以按小时地或在一天的时间尺度的其他部分显示数据项。

图56是图示时间轴的界面屏幕的一部分的屏幕显示的示例，该时间轴示出了在每周聚集级别的时间轴数据图的示例。数据图在所选聚集级别处显示一系列点，其中亮点表示在所选聚集级别的时段内缺少拥有者数据，而暗点表示该时间段内存在拥有者数据。在这个示例中，对应的年也用点来显示，以标识数据存在或缺少的时间表。时间轴数据图的底部两个示例图示手形图标(表示光标)，以悬停在数据图的另一部分上，并且对应于悬停光标的位置显示另一突出显示的块，使得如果在悬停光标的位置接收到点击事件，时间轴根据所选的聚集级别显示与点击的日期相对应的数据。

版本跟踪

系统100跟踪每个拥有者的数据的版本标识符。当用户对某些类型或类别的数据具有写入许可时，系统会记录各种信息。在某些实施例中，谁编辑了什么数据以及该编辑是什么，并且来自所有授权用户的这些改变都被永久地记录在每个日记中的编辑/版本跟踪系统中。这些改变对于特定拥有者的日记的每个用户都是可见的，假设他们具有查看数据的许可的权利级别。此外，具有编辑的写入能力的那些用户可以进行进一步的编辑，并使类似地记录的结果为所有授权用户看见。在某些实施例中，核心数据库提供了验证修改的实体当前是否是最新版本的功能。如果自从它被取得后其已经被修改，则可以通知用户，并且不允许保存。

图70是图示用于编辑和版本跟踪的处理7000的实施例的流程图。在某些实施例中，可以在图2A所示的系统100上执行该处理。当用户(例如数据的拥有者、访客或诸如医生的组织的工作人员)添加或编辑拥有者的日记数据的任何部分时，遵循该处理7000。

编辑/版本跟踪在核心数据库中被支持，但是由于各种原因(包括在编辑处理中维护版本标识以及向用户呈现相关的警告/错误)，它由用户界面来处理。

从状态7010开始，具有合适写入许可的用户启动对拥有者数据的实体的编辑。进入状态7020，处理7000从核心数据库中取回实体。版本号和所有其他数据(例如，修订的日期和时间、以及执行编辑的人的标识符)作为实体本身的一部分存储在核心数据库中。在某些实施例中，实体可以是数据库中的任何数据项，诸如例如模块(类别)数据。需要被做以实现无版本冲突的实体所需的所有信息将在核心数据库中添加所需的列。构建系统识别到这些字段存在，并从该点向前引入对该实体的版本化支持。在某些实施例中，版本号是每个实体。

在状态7030处继续，打开具有实体编辑数据以及实体修订号的对话框或窗口。在状态7040，用户编辑(例如，修改、删除部分或添加数据)，并将该实体保存在对话中。移动到状态7050，实体改变，原始修订号在服务器上接收。进行到决定状态7060，处理7000确定版本号是否在核心数据库和对话框之间匹配。如果不是，则处理7000移动到状态7070，以警告用户实体(拥有者的数据的)已经由另一用户修改，因为它是由第一用户取回的，并且中止该改变。然而，如果如在决定状态7060处确定的核心数据库和对话框之间的版本号匹配，则处理7000前进到状态7080以保存改变并增加修订号。

作为将编辑相关数据与实体一起存储的结果，系统可以向任何用户显示该数据的所有先前版本的改变历史，该任何用户具有针对对应于实体项目的数据的类别的适当读取许可。

小部件

小部件是系统中的主要部件，其可以在显示屏幕上示出或者以用户的选项隐藏，并且可以用于引用时间轴和脉搏页面上的部件。在某些实施例中，小部件为用户提供模板化视图(数据组合)的预定义列表，以从例如糖尿病、体重减轻和高血压中进行选择。通常在此应用中，小部件是可以添加到页面或从页面移除的用户界面部件。如前所述，在某些实施例中，脉搏页面是拥有者日记的仪表板，其允许用户将其日记的重要方面放在一个页面上。这允许拥有者和访客可以一目了然地看到与他们相关的内容，而无需在整个应用中导航。小部件允许用户保存特定于他们自己需要的多个视图，并可以从小部件库添加到他们的视图中。用户可以根据需要对视图中的每一个添加、排序和移除小部件。

在某些实施例中，存在可以呈现包含在日记内的模块中的每一个的预定义的小部件集合。基本小部件类型包括可比较的日期时间数据小部件(例如，锻炼日记、用药日记)、不可比较的日期时间数据小部件(例如，生活事件、备注)、时间范围数据小部件(例如疾病)和头像小部件。可以在稍后的时间)开发和添加先进的模块特定小部件(例如，药物方案。此外，复合小部件(例如，一起显示多个数据源的小部件)可以在以后开发和添加。该系统提供配置每个小部件(例如，线条、条形图、或数据)的显示模式的能力。例如，该系统还提供配置数据的子维度以示出强度和/或持续时间的能力。在某些实施例中，为用户提供默认的小部件集合。默认脉搏页面的示例可以包含重量、最新的新日记条目、最新的用户活动、最新的药物服用、和最新的身体活动的小部件。

小部件可以具有数据过滤选项，诸如例如过滤敏感数据、临床医生与非临床医生输入的数据、和/或由特定用户输入的数据。在其他实施例中可以使用其他过滤选项。

时间轴的任何给定的查看者只具有对他们被授予许可来查看的基础数据的访问。这意味着虽然可以添加小部件，但该小部件的底层数据可能对特定用户不可用。

脉搏页面可以具有用户可以添加到他们的页面的各种预定义的小部件。用户能够从页面中移除小部件。在某些实施例中，小部件可以经由拖放操作或经由在移动设备环境中拖动进行排序。可以针对特定拥有者(患者)保存所选择的小部件和小部件的顺序。

现在将描述几个示例小部件。药物服用小部件可以包括标题(自定义小部件标题)、药物(选择药物)、重点(例如，服用量、服用时间)和时间跨度(今天、最近七天、最近三十天、最近六个月)的选项。身体活动小部件可以包括标题(自定义小部件标题)、身体活动(选择活动)、重点(例如，持续时间、活动时间)、和时间跨度(今天，最近七天、最近三十天、最近六个月)的选项。身体测量小部件可以包括标题(自定义小部件标题)、测量(选择测量)、重点(例如每日平均值)、和时间跨度(最近七天、最近三十天、最近六个月)的选项。命脉小部件可以包括标题(定制小部件标题)、命脉(选择一个命脉)、重点(例如平均值)、和时间跨度(今天、最近七天、最近三十天、最近六个月)的选项。营养小部件可以包括标题(定制小部件标题)、重点(例如总卡路里、总碳水化合物、总胆固醇、总纤维、总糖、总蛋白、总脂肪、总饱和脂肪、总钠)和时间跨度(今天、最近七天、最近三十天、最近六个月)的选项。其他小部件可以包括最新条目、睡眠、情绪、疼痛和访问以及对应的选项。

图57是图示用于身体活动或锻炼历史的示例小部件的界面屏幕的屏幕显示的一部分的示例，该小部件示出具有两个具有用于锻炼类型和查看的下拉菜单的控件的列表视图。每个块部分可以具有执行锻炼的持续时间，并且例如基于目标来利用颜色来指示状态。

图58是图示用于响应于所选择的控件来示出图形数据视图的示例小部件的界面屏幕的示例的屏幕显示的一部分的示例，所述控件包括所选择的运动类型和通过燃烧的卡路里的视图。

图59是图示响应于所选择的控件来示出图形数据视图的示例小部件的界面屏幕的屏幕显示的一部分的示例，所述控件包括所有锻炼类型和平均时间的视图。

图60是图示用于响应于所选择的控件来示出列表视图的几个示例小部件的界面屏幕的屏幕显示的示例，并且其中每个小部件可以具有不同的控件。

图61是图示我的健康馈送小部件的示例小部件设置和小部件显示以及身体活动小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。例如，可以在诸如智能电话的移动计算设备上看到屏幕显示。

显示屏幕6110是示例对话框，当用户点击脉搏页面上的“编辑”按钮以及+(加号)按钮来添加新的小部件时该对话框呈现。显示屏幕6120是一个示例对话框，其呈现为允许用户设置所选择的新小部件(在本例中是健康数据-最新数据)。显示屏幕6130是呈现并允许用户改变脉搏页面小部件(通常与显示屏幕6120相同)的设置的对话框的示例。显示屏幕6140是如其在脉搏页面上呈现的实际小部件的示例。

显示屏幕6150至6180图示用于身体活动的小部件。显示屏幕6150是一个示例对话框，其呈现为允许用户设置所选择的新小部件(在本例中为健康数据-身体活动)。显示屏6160是呈现并且允许用户改变脉搏页面小部件(通常与显示屏幕6150相同)的设置的对话框的示例。显示屏幕6170是如其呈现在脉搏页面上的针对一天身体活动的实际小部件的示例，并且显示屏幕6180是针对一周的身体活动。

图62是图示用于药物服用小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。显示屏幕6220是一个示例对话框，其呈现以允许用户设置所选择的新小部件(在本例中为健康数据–服用的药物)。显示屏幕6230是呈现并允许用户改变脉搏页面小部件的设置的对话框的示例。显示屏幕6240是如其呈现在脉搏页面上针对一天的药物服用的实际小部件的示例，并且显示屏幕6250是针对一周的药物服用。

图63是图示用于睡眠小部件的小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。显示屏幕6320是呈现以允许用户设置所选择的新小部件(在本例中是健康数据-睡眠)的示例对话框。显示屏幕6330是呈现并允许用户改变脉搏页面小部件的设置的对话框的示例。显示屏幕6340是如其呈现在脉搏页面上针对一天的睡眠数据的实际小部件的示例，并且显示屏幕6350是针对一周的睡眠数据。

图64是图示用于情绪小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。显示屏幕6420是呈现用于允许用户设置所选择的新小部件(在这种情况下为情绪)的示例对话框。显示屏幕6430是呈现并允许用户改变脉搏页面小部件的设置的对话框的示例。显示屏幕6440是如其呈现在脉搏页面上对于一天的情绪数据的实际小部件的示例，并且显示屏幕6450是针对一周的情绪数据。

图65是图示用于疼痛小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。显示屏幕6520是呈现以允许用户设置所选择的新小部件(在本例中为疼痛)的示例对话框。显示屏幕6530是呈现并允许用户改变脉搏页面小部件的设置的对话框的示例。显示屏幕6540是如其呈现在脉搏页面上针对一天的疼痛数据的实际小部件的示例，并且显示屏幕6550是针对一周的疼痛数据。

图66是图示用于身体测量小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。显示屏幕6620是呈现以允许用户设置所选择的新小部件(在本例中是健康数据-身体测量)的示例对话框。显示屏幕6630是呈现并允许用户改变脉搏页面小部件的设置的对话框的示例。显示屏幕6640是如其呈现在脉搏页面上针对一天的身体测量数据的实际小部件的示例，并且显示屏幕6650是针对一周的身体测量数据。

图67是图示用于命脉小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。显示屏幕6720是呈现并允许用户设置所选择的新小部件(在本例中为健康数据–命脉)的示例对话框。显示屏幕6730是呈现并允许用户改变脉搏页面小部件的设置的对话框的示例。显示屏幕6740是如其呈现在脉搏页面上针对一天的命脉数据的实际小部件的示例，并且显示屏幕6750是针对一周的命脉数据。

图68是图示用于食物和饮水小部件的示例小部件设置和对应的小部件显示的界面屏幕的屏幕显示的示例。显示屏幕6820是呈现并允许用户设置所选择的新小部件(在本例中为健康数据-食物和饮水)的示例对话框。显示屏幕6830是呈现并允许用户改变脉搏页面小部件的设置的对话框的示例。显示屏幕6840是如其呈现在脉搏页面上针对一天的食物和饮水数据的实际小部件，并且显示屏幕6850是针对一周的食物和饮水数据。

图69是图示对于访问小部件的示例小部件设置和对应小部件显示的界面屏幕的屏幕显示的示例。显示屏幕6920是呈现以允许用户设置所选择的新小部件(在本例中为访问)的示例对话框。显示屏幕6930是呈现并允许用户改变脉搏页面小部件的设置的对话框的示例。显示屏幕6940是如其呈现在列出对拥有者数据的访问的项目的脉搏页面上的实际小部件的示例。

结论

该系统和方法的总体效果是控制与数据拥有者相关联的各方的访问和访问类型，以便例如保护隐私、减少疏忽、遗漏和错误以及允许健康专业人员在更短的时间内更全面地诊断。

结合本文公开的实施例描述的各种示意性逻辑、逻辑块、模块、电路和算法步骤可以实现为电子硬件、计算机软件或电子硬件和计算机软件两者的组合。硬件和软件的互换性在功能方面已经被大体上描述，并且在上面描述的各种示意性部件、块、模块、电路和步骤中进行了说明。这种功能是在硬件还是在软件中实现取决于施加在整个系统上的特定应用和设计约束。

在一个或多个方面，所描述的功能可以在硬件、数字电子电路、计算机软件、固件中实现，包括在本说明书中公开的结构及其结构等同物、或其任何组合。本说明书中描述的主题的实现也可以被实现为一个或多个计算机程序，例如，计算机程序指令的一个或多个模块，其被编码在计算机存储介质上用于由数据处理装置执行或用于控制数据处理装置的操作。

如果以软件实现，则功能可以作为一个或多个指令或代码存储在计算机可读介质上或通过计算机可读介质传输。本文公开的方法或算法的步骤可以在可以驻留在计算机可读介质上的处理器可执行软件模块中实现。计算机可读介质包括计算机存储介质和通信介质，通信介质包括可以使计算机程序从一个地方传送到另一个地方的任何介质。存储介质可以是可由计算机访问的任何可用介质。作为示例而非限制，这样的计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储器、磁盘存储器或其他磁存储设备、或可以用于以指令或数据结构的形式存储期望的程序代码并且可以由计算机访问的任何其他介质。此外，任何连接都可以被适当地称为计算机可读介质。如本文所使用的磁盘和光盘包括光盘(CD)、激光盘、光盘、数字通用盘(DVD)、软盘和蓝光盘，其中磁盘通常以磁性方式再现数据，而光盘利用激光来光学地再现数据。以上的组合也应包括在计算机可读介质的范围内。此外，方法或算法的操作可以作为代码和指令的一个或任何组合或集合驻留在机器可读介质和计算机可读介质上，其可以并入到计算机程序产品中。

在本说明书中在单独实现的上下文中描述的某些特征也可以在单个实现中组合地实现。相反，在单个实现的上下文中描述的各种特征也可以在多个实现中单独地或以任何合适的子组合来实现。此外，虽然特征可以在上文中描述为以某些组合来动作并且甚至最初地如此要求保护，但是在某些情况下，来自要求保护的组合的一个或多个特征可以从组合中去除，并且所要求保护的组合可以针对子组合或子组合的变体。

类似地，尽管在附图中以特定顺序描绘了操作，但是这不应被理解为要求以所示的特定顺序或按顺序执行此类操作，或者执行所有所图示的操作，以实现期望的结果。在某些情况下，多任务和并行处理可能是有利的。此外，在上述实现中的各种系统部件的分离不应被理解为在所有实现中需要这样的分离，并且应当理解，所描述的程序部件和系统通常可以一起集成在单个软件产品中或封装成多个软件产品。

前面的描述详细描述了本发明的某些实施例。然而，应当理解，无论上述在文中如何详细地描述，本发明可以以许多方式实施。如上所述，应当注意，在描述本发明的某些特征或方面时特定术语的使用不应被认为意味着术语在本文中被重新定义以被限制为包括与该术语相关联的发明的特征或方面的任何特定特性。因此，本发明的范围应根据所附权利要求及其任何等同物来解释。

Claims (71)

1.一种在系统中控制由数据的拥有者对所选择的接收者授予许可的方法，所述系统至少包括多个计算设备、服务器、网络和数据库，所述方法包括：

在所述服务器处从被存储在数据库的拥有者的电子日记部分中的数据的拥有者来接收电子认证；

在所述服务器处接收电子地址，所述电子地址与将被邀请以访问由所述拥有者控制的数据的指定类别的一个或多个期望的接收者中的每一个相对应；

标识所述一个或多个接收者在所述邀请被接受的情况下将具有的特定许可，其中许可提供用于执行一个或多个指定动作的能力；

经由计算机网络向所述一个或多个期望的接收者发送电子通信，其中每个电子通信包括用于回复所述通信的专用统一资源定位符；

经由计算机网络从所述一个或多个接收者中的每一个接收包括对所述邀请的接受或拒绝的电子消息；以及

在数据结构中存储所述一个或多个接收者中的每一个的标识符、所述邀请的所述接受或拒绝的指示符、以及在所述邀请被接受的情况下向所述一个或多个接收者中的每一个所授予的许可的对应的组合，以便促进对所述拥有者的数据的拥有者控制的电子访问。

2.根据权利要求1所述的方法，其中如果所述接收者中的一个是组织，则接收一个或多个电子消息，所述一个或多个电子消息标识针对所述拥有者的一个或多个特定接入组和一个或多个工作人员、以及针对所述一个或多个工作人员和对应的数据的类别的一个或多个角色，针对所述对应的数据的类别所述特定许可被授予。

3.根据权利要求2所述的方法，其中只有在所述拥有者和特定工作人员共享公共访问组时，所述工作人员才能够访问日记。

4.根据权利要求2所述的方法，其中特定工作人员基于来自所述工作人员属于的所有角色的累积许可来访问日记。

5.根据权利要求2所述的方法，其中所述特定许可被限于从所述拥有者的帐户被给予所述组织的那些许可。

6.根据权利要求2所述的方法，其中角色是组织定义的许可的组合。

7.根据权利要求2所述的方法，其中访问组是用于链接工作人员和拥有者的组织定义的组。

8.根据权利要求1所述的方法，还包括从所述拥有者接收电子请求以在没有特定接收者的同意的情况下添加或移除许可。

9.根据权利要求1所述的方法，还包括由所选择的所述接收者的所授权的所述许可的使用，包括：

从所述接收者中的特定接收者接收对拥有者数据的图形显示的请求；

确定针对所述特定接收者的累积许可，其中如果所述特定接收者是组织的一部分，则所述确定还包括确定所述特定接收者是否与和所述拥有者所共享的访问组相关联；

取回所述拥有者的电子日记中的由所述累积许可标识的数据；以及

生成所取回的所述数据的基于HTML的屏幕显示。

10.根据权利要求9所述的方法，还包括从所述特定接收者接收导航请求以操纵所述基于HTML的屏幕显示。

11.根据权利要求9所述的方法，还包括从所述接收者中的特定接收者接收导航请求以操纵所述基于HTML的屏幕显示。

12.根据权利要求9所述的方法，其中所述屏幕显示包括如下类别的数据，所述接收者中的特定接收者针对所述类别具有许可，并且其中所述屏幕显示指示如下类别，所述接收者中的所述特定接收者针对所述类别不具有许可。

13.根据权利要求12所述的方法，其中生成所述基于HTML的屏幕显示包括针对与所述累积许可对应的每个类别应用一个或多个控件，其中针对每个被许可的类别的所述控件独立于针对其他被许可的类别的所述控件。

14.根据权利要求9所述的方法，其中生成所述基于HTML的屏幕显示包括基于来自单个类别的数据来应用一个或多个预定义的模板化的时间轴视图。

15.根据权利要求9所述的方法，其中生成所述基于HTML的屏幕显示包括基于来自多个类别的数据来应用一个或多个预定义的模板化的时间轴视图。

16.根据权利要求15所述的方法，其中如果预定义的模板化的时间轴视图要求访问来自对于所述用户不被许可的类别的数据，则所述视图不被显示，并且用户被通知。

17.根据权利要求9所述的方法，还包括：

接收针对时间轴显示的请求，所述时间轴显示包括从日、周、月或年中的聚集级别选择以及与所述聚集级别选择对应的开始日期或结束日期；以及

根据所接收的所述请求来呈现具有两个行部分的日历栏，其中底行部分根据与所述聚集级别选择对应的所述开始日期或所述结束日期来显示具有日期的一系列块，并且其中顶行部分在所选择的所述聚集级别处显示一系列点，其中亮点表示在所选择的所述聚集级别处针对时段的拥有者数据的缺失，并且暗点表示针对所述时段的拥有者数据的存在。

18.根据权利要求17所述的方法，其中所述日历栏的所述顶行部分还在与所述底行部分中的所述日期对应的所述点上显示突出显示的块，并且其中如果光标被移动到悬停在所述顶行部分的另一部分上，则与悬停的所述光标的位置对应的另一个突出显示的块被显示，其中如果在悬停的所述光标的所述位置处接收到点击事件，则所述时间轴根据所选择的所述聚集级别来显示与所述点击的所述日期对应的数据。

19.权利要求2的方法，其中数据的所述类别可以包括药物、锻炼、睡眠、疾病和性健康。

20.根据权利要求2所述的方法，其中数据的所述类别包括医疗记录、症状和/或命脉体征、药物和/或实验室结果、情感、生活事件、遗传标记和生活方式。

21.根据权利要求1所述的方法，其中所述接收者是访问者、工作人员和拥有者/访问者中的一个。

22.根据权利要求21所述的方法，其中所述访问者是具有读取和/或写入特权的访客、和具有完全拥有者特权的监护人中的一个。

23.根据权利要求2所述的方法，其中所述工作人员是属于组织的用户。

24.根据权利要求1所述的方法，其中所述拥有者/访问者是用户，所述用户是具有日记的拥有者并且还已经被给予对另一个拥有者的日记的访问。

25.根据权利要求1所述的方法，其中许可状态包括被给予、被接收和被接受。

26.根据权利要求1所述的方法，其中许可类型包括读取、写入和无访问。

27.根据权利要求1所述的方法，还包括接收电子消息，所述电子消息包括对所接收的所述邀请的所述接受或拒绝的确认或取消。

28.一种在系统中控制由数据的拥有者对所选择的接收者授予许可的方法，所述系统包括至少包括多个计算设备、服务器和网络，所述方法包括：

标识在来自所述数据的特定拥有者的邀请被组织的管理员接受的情况下所述组织具有的许可，其中许可提供用于执行一个或多个指定动作的能力；

经由计算机网络发送电子通信，所述电子通信至少包括所述邀请、对所述组织的所述管理员的许可的组合、以及用于回复所述电子通信的专用的统一资源定位符；

接收所述特定拥有者对组织定义的访问组的分配；

接收所述特定拥有者和所述组织的一个或多个所选择的工作人员到所述访问组的映射，以链接所述特定拥有者和所选择的所述工作人员；

接收与所述组织的所述工作人员对应的至少一个角色的标识；

接收所述组织中的所述一个或多个所选择的工作人员到所述至少一个角色的分配；

根据具有所述特定拥有者和所选择的所述工作人员的所述特定访问组以及根据具有所选择的所述工作人员的所述至少一个角色来向针对所述特定拥有者的所选择的所述工作人员授予特定许可；以及

在数据结构中存储所述邀请的所述接受或拒绝的指示符、所选择的所述工作人员中的每一个工作人员的标识符、以及与所选择的所述工作人员中的每一个工作人员对应的被授予的许可的组合，以便于促进对所述拥有者的数据的受拥有者控制的电子访问。

29.根据权利要求28所述的方法，其中只有所述拥有者和特定工作人员共享公共访问组时，所述工作人员才能够访问拥有者的日记。

30.根据权利要求28所述的方法，其中特定工作人员基于来自所述工作人员属于的所有角色的累积许可来访问拥有者的日记。

31.根据权利要求28所述的方法，其中所述特定许可被限于从所述拥有者的帐户被给予所述组织的那些许可。

32.根据权利要求28所述的方法，其中角色是组织定义的许可的组合。

33.根据权利要求28所述的方法，还包括由所选择的所述工作人员的所授权的所述许可的使用，包括：

从所述工作人员中的特定工作人员接收对拥有者数据的图形显示的请求；

确定针对所述特定工作人员的累积许可，其中所述确定还包括确定所述特定工作人员是否与和所述拥有者所共享的访问组相关联；

取回所述拥有者的电子日记中的由所述累积许可标识的数据；以及

生成所取回的所述数据的基于HTML的屏幕显示。

34.根据权利要求33所述的方法，还包括接收来自所述特定工作人员的导航请求以操纵所述基于HTML的屏幕显示。

35.根据权利要求28所述的方法，其中所述工作人员是属于所述组织的用户，包括医生、护士、技术人员、药剂师和管理员中的一个。

36.根据权利要求28所述的方法，其中许可类型包括读取、写入和无访问。

37.根据权利要求28所述的方法，其中所述角色还包括所选择的数据的类别，对应的工作人员具有对所述类别的访问，其中所述数据的类别包括医疗记录、症状和/或命脉体征、药物和/或实验室结果、情感、生活事件、遗传标记和生活方式。

38.一种在系统中控制由被布置在拥有者日记中的数据的拥有者向所选择的接收者授予许可的方法，所述系统至少包括多个计算设备、服务器、和网络，所述方法包括：

标识在来自所述数据的特定拥有者的邀请被组织的管理员接受的情况下所述组织将具有的许可，其中许可提供用于执行一个或多个指定动作的能力；

经由计算机网络发送电子通信，所述电子通信至少包括来自所述拥有者中的每一个拥有者的邀请以及与所述组织的所述管理员对应的许可的组合，其中每个电子通信包括用于回复所述通信的唯一统一资源定位符；

接收所述拥有者中的每一个拥有者到一个或多个组织定义的访问组的分配；

接收特定拥有者和所述组织的一个或多个所选择的工作人员到一个或多个访问组的映射，以链接所述特定拥有者和所选择的工作人员；

接收与所述组织的所述工作人员对应的至少一个角色的标识；

接收所述组织中的所述一个或多个所选择的工作人员到所述至少一个角色的分配；

根据具有特定拥有者和所选择的所述工作人员的一个或多个访问组以及根据具有所选择的所述工作人员的所述特定拥有者的所述至少一个角色来针对所述拥有者中的每一个拥有者向所选择的所述工作人员授予特定许可；以及

在数据结构中存储针对所述拥有者中的每一个拥有者的所述邀请的所述接受或拒绝的指示符、所选择的所述工作人员中的每一个工作人员的标识符、以及与针对每一个拥有者，与所选择的所述工作人员中的每一工作人员对应的被授予的许可的组合，以便于促进对每个拥有者的数据的拥有者控制的电子访问。

39.根据权利要求38所述的方法，其中只有当对应的特定拥有者和特定工作人员共享公共访问组时，所述工作人员才能够访问特定的日记。

40.根据权利要求38所述的方法，其中特定工作人员基于来自所述工作人员属于的所有角色的累积许可来访问特定日记。

41.根据权利要求38所述的方法，其中所述特定许可被限于从对应的拥有者的帐户被给予所述组织的那些许可。

42.根据权利要求38所述的方法，其中角色是组织定义的许可的组合。

43.根据权利要求38所述的方法，还包括由所选择的所述工作人员的所授权的许可的使用，包括：

从所述工作人员中的特定工作人员接收对特定拥有者的数据的图形显示的请求，其中所述数据被分组在多个类别中；

确定所述特定工作人员是否与和所述特定拥有者所共享的访问组相关联；

如果所述特定工作人员与和所述特定拥有者所共享的访问组相关联，则确定来自针对所述特定工作人员的角色的累积许可；

确定所述累积许可中的哪一个累积许可为所述组织已经由所述拥有者授予的许可；

取回所述特定拥有者电子日记中的由所述累积许可所标识的数据；以及

生成所取回的所述数据的基于HTML的屏幕显示。

44.根据权利要求43所述的方法，还包括接收来自所述特定工作人员的导航请求以操纵所述基于HTML的屏幕显示。

45.根据权利要求43所述的方法，其中所述屏幕显示包括如下类别的数据，所述特定工作人员针对所述类别具有许可，并且其中所述屏幕显示指示如下类别，所述特定工作人员针对所述类别不具有许可。

46.根据权利要求38所述的方法，其中所述工作人员是属于所述组织的用户，包括医生、护士、技术人员、药剂师和管理员中的一个。

47.根据权利要求38所述的方法，其中许可类型包括读取、写入和无访问。

48.根据权利要求38所述的方法，其中与所述角色相关联的是如下数据的类别，对应的工作人员具有对所述数据的类别的访问，其中所述数据的类别包括医疗记录、症状和/或命脉体征、药物和/或实验室结果、情感、生活事件、遗传标记和生活方式。

49.根据权利要求38所述的方法，其中与所述角色相关联的是如下数据的类别，对应的工作人员具有对所述数据的类别的访问，其中所述数据的类别包括身体测量、临床备注、日记备注、饮酒、环境、感觉、免疫、实验室结果、生活事件、药物、情绪、营养、疼痛、患者压力、身体活动、睡眠、吸烟、症状、治疗和命脉体征。

50.根据权利要求45所述的方法，其中生成所述基于HTML的屏幕显示包括对与所授予的所述许可对应的每个类别应用一个或多个控件，其中针对每个被许可的类别的所述控件独立于针对其他被许可的类别的所述控件。

51.根据权利要求50所述的方法，其中所述控件包括对所取回的所述数据进行排序、查看、着色、和过滤的选择。

52.根据权利要求50所述的方法，其中所述控件包括用于显示所取回的所述数据的列表格式和图形格式。

53.根据权利要求43所述的方法，其中生成所述基于HTML的屏幕显示包括基于来自单个类别的数据来应用一个或多个预定义的模板化时间轴视图。

54.根据权利要求43所述的方法，其中生成所述基于HTML的屏幕显示包括基于来自多个类别的数据来应用一个或多个预定义的模板化时间轴视图。

55.根据权利要求54所述的方法，其中如果预定义的模板化时间轴视图要求对来自所述用户不被许可的类别的数据的访问，则该视图不被显示，并且用户被通知。

56.根据权利要求43所述的方法，还包括生成对人访问所述拥有者数据、由每个人采取的所述动作、以及对所述日记的改变或添加的时间戳日志，如果有的话。

57.根据权利要求38所述的方法，还包括：

扫描对应于特定拥有者的源文档；

从所扫描的所述文档中提取医学数据，所述医学数据包括对源文档的引用；

将所述源文档存储在电子存储装置中；以及

基于所提取的所述数据的类别来将所提取的所述医学数据和对所述源文档的所述引用存储在特定日记中，其中所存储的所述引用使得查看所提取的所述数据的用户能够导航到所述源文档并且查看所述源文档。

58.根据权利要求57所述的方法，其中所述源文档以特定网页的分辨率被存储。

59.根据权利要求57所述的方法，其中所提取的所述数据在时间轴上或所述数据的其他显示页面上被查看。

60.根据权利要求45所述的方法，还包括：

接收针对特定日记的所选择的类别中的数据项的选择；

激活所选择的所述类别中的控件以发起源文档链接处理；

向所述电子存储装置显示用户界面；

通过要链接到所述数据项的源文档的所述界面的使用来接收选择；以及

将针对所述数据项的所述链接记录在所述特定日记中。

61.根据权利要求2所述的方法，其中所述数据的类别包括临床数据生活方式数据、心理社会数据、环境数据和遗传数据。

62.一种在系统中控制由数据的拥有者向所选择的接收者的授予许可的方法，所述系统至少包括多个计算设备、服务器、和网络，所述方法包括：

标识在来自所述数据的特定拥有者的邀请被组织的管理员接受的情况下所述组织具有的许可，其中许可提供执行一个或多个指定动作的能力；

经由计算机网络发送电子通信，所述电子通信至少包括所述邀请、对所述组织的所述管理员的许可的组合、以及用于回复所述电子通信的专用的统一资源定位符；

接收所述特定拥有者对组织定义的访问组的分配；

接收所述特定拥有者和所述组织的一个或多个所选择的工作人员到所述访问组的映射，以链接所述特定拥有者和所选择的所述工作人员；

接收所述组织的所述一个或多个所选择的工作人员对至少一个组织角色的分配；

根据具有所述特定拥有者和所选择的所述工作人员的所述特定访问组以及根据具有所选择的所述工作人员的所述至少一个角色来针对所述特定拥有者向所选择的所述工作人员授予特定许可；

在数据结构中存储所述邀请的所述接受或拒绝的指示符、所选择的所述工作人员中的每一个的标识符、以及与被选择的所述工作人员中的每一个工作人员对应的被授予的许可的组合；

从具有对应的被授予写入许可的第一用户接收对所述拥有者的数据或新数据的编辑；

跟踪第一用户的身份、所述编辑或新数据的时间和日期、更新的类型或类别、以及数据库中的所述编辑或新数据；以及

改变针对所更新的所述拥有者的数据的版本标识符。

63.根据权利要求62所述的方法，还包括：

确定自从所述拥有者的数据被所述第一用户取回，所述拥有者的数据是否已被第二用户修改；以及

通知所述第一用户所述更新不被允许。

64.根据权利要求63所述的方法，其中确定自从所述拥有者的数据被取回所述拥有者的数据是否已被修改包括：确定所修改的条目是否是最新版本。

65.根据权利要求62所述的方法，其中所述拥有者的数据是医疗或健康相关数据。

66.根据权利要求62所述的方法，其中所述更新对于每个后续用户是可见的，所述每个后续用户具有对应的被授予的许可以访问具有所改变的版本标识符的所述拥有者的数据。

67.根据权利要求62所述的方法，还包括向用户显示针对所编辑的所述拥有者的数据的先前版本的改变历史，所述用户具有对于与所编辑的所述数据对应的数据的所述类别的适当读取许可。

68.一种用于控制由数据拥有者向所选择的接收者授予许可的系统，其中所述系统至少包括多个客户端计算设备、服务器和数据库，所述系统包括：

用于在服务器处从客户端计算设备接收电子认证的部件，所述客户端计算设备与被存储在数据库的拥有者的电子日记部分中的数据的拥有者对应；

用于在服务器处接收电子地址的部件，所述电子地址与将被邀请以访问由所述拥有者控制的数据的指定类别的一个或多个期望的接收者客户端计算设备中的每一个对应；

用于标识所述一个或多个接收者在所述邀请被接受的情况下将具有的特定许可的部件，其中许可提供用于执行一个或多个指定动作的能力；

用于向所述一个或多个期望的接收者客户端计算设备发送电子通信的部件，其中每个电子通信包括用于回复所述通信的专用统一资源定位符；

用于从所述一个或多个接收者客户端计算设备中的每一个接收者客户端计算设备接收包括所述邀请的接受或拒绝的电子消息的部件；以及

用于存储以下信息以便于促进对所述拥有者的数据的拥有者控制的电子访问的部件：所述一个或多个接收者中的每一个接收者的标识符、对所述邀请的所述接受或拒绝的指示符、以及在所述邀请被接受的情况下所述一个或多个接收者中的每一个接收者所授予的许可的对应的组合。

69.根据权利要求68所述的系统，其中数据的特定拥有者具有与所述特定拥有者对应的多个客户端计算设备。

70.一种用于控制由在拥有者日记中所布置的数据的拥有者向所选择的接收者授予许可的系统，其中所述系统包括至少多个客户端计算设备和服务器，所述系统包括：

用于标识在来自所述数据的特定拥有者的邀请被组织的管理员接受的情况下所述组织将具有的许可的部件，其中许可提供用于执行一个或多个指定动作的能力；

用于发送电子通信的部件，所述电子通信至少包括来自与所述拥有者中的每一个对应的客户端计算设备的邀请以及与所述组织的所述管理员对应的许可的组合，其中每个电子通信包括用于回复所述通信的专用的统一资源定位符；

用于接收所述拥有者中的每一个对一个或多个组织定义的访问组的分配的部件；

用于接收特定拥有者和所述组织的一个或多个所选择的工作人员到用于链接所述特定拥有者和所选择的所述工作人员的一个或多个访问组的映射的部件；

用于接收与所述组织的所述工作人员对应的至少一个角色的标识的部件；

用于接收所述组织的所述一个或多个所选择的工作人员向至少一个角色的分配的部件；

用于根据具有特定拥有者和所选择的所述工作人员的一个或多个访问组，以及根据具有所选择的所述工作人员的特定拥有者的所述至少一个角色，针对所述拥有者中的每一个拥有者向所选择的所述工作人员授予特定许可的部件；以及

用于存储针对拥有者中的每一个拥有者的所述邀请的所述接受或拒绝的指示符、所选择的所述工作人员中的每一个工作人员的标识符、以及针对每个拥有者与所选择的工作人员中的每一个工作人员对应的被授予的许可的组合以便于促进对每个拥有者的数据的拥有者控制的电子访问的部件。

71.根据权利要求70所述的系统，其中数据的特定拥有者具有与所述特定拥有者对应的多个客户端计算设备。