用于管理对医学数据的访问的系统

摘要

本申请涉及一种用于管理对医学数据的访问的系统，包括：第一模块，其显示数据请求信息，所述数据请求信息用于请求对来自所述数据提供器的所述医学数据的访问；以及第二模块，其从所述第一模块获得所述数据请求信息并基于所获得的数据请求信息来请求对来自数据提供器的所述医学数据的访问。所述第一模块能够通过显示所述数据请求信息，例如显示为快速响应(QR)码，来提供所述数据请求信息。所述数据请求信息可以包括链接到所述数据提供器的统一资源定位符(URL)。所述数据提供器能够本地存储所述医学数据，或者能够从诸如个人健康记录(PHR)服务器的远程源检索所述医学数据。响应于数据访问请求，所述数据提供器可以请求来自所述医学数据所对应于的患者的用户验证，并且仅响应于成功授权而向所述第二模块提供所述医学数据。

说明书

技术领域

本发明涉及一种用于管理对医学数据的访问的系统，尤其涉及在患者 与健康照护专业人员之间共享医学数据。

背景技术

在健康照护环境中，对患者而言合乎期望的是能够与医生或其他健康 照护专业人员共享医学数据。例如，医学数据能够包括关于针对患者的先 前测试结果的信息，并且通过共享医学数据，能够避免对重复测试的需要。 有效的医学数据管理系统能够通过允许医生花费更多的时间与患者交互而 非重复先前的工作，改善照护的质量并减少照护的成本。然而，为了确保 隐私，合乎期望的是以安全和有保障的方式共享医学数据，并且尤其是对 患者而言能够控制谁被允许访问他们的医学数据。

已知各种用于共享医学数据的系统，包括电子健康记录(EHR)、电子 医学记录(EMR)、个人健康记录(PHR)，以及医学信息卡。医学信息卡 将医学信息存储在，例如存储器模块中，存储器模块能够通过集成的USB 连接器被访问。HER或EMR为由诸如医院、综合供应网络、诊所或医师 办公室的机构生成并维护的医学记录信息的电子储存库。PHR的区别在于 其为由个体患者(与医学机构相反)维护的医学记录信息的电子储存库。

为了共享来自PHR的数据，用户必须完成若干步骤。通常，为了允许 患者共享来自PHR的数据，健康照护组织能够创建PHR集成的离线应用， 在所述离线应用中注册的患者能够登录并允许与PHR交换健康信息。该应 用也能够具有针对医师的登录窗口，以登录并访问来自PHR的患者数据。 医师能够登录应用中并使用唯一的患者ID选择特定患者。该应用将从对应 的PHR记录拉出数据并向医师绘制该数据。

发明内容

本发明的目标是提供一种用于访问患者数据的系统，该系统基本上缓 解或克服了上述问题。

根据本发明的一方面，提供一种用于管理对对应于患者的医学数据点 访问的系统，所述系统包括：数据提供器，其被布置为提供对所述医学数 据的访问；第一模块，其被布置为提供数据请求信息，所述数据请求信息 用于请求对来自所述数据提供器的所述医学数据的访问；以及第二模块， 其被布置为从所述第一模块获得所述数据请求信息，并且被配置为基于所 获得的数据请求信息来请求对来自所述数据提供器的所述医学数据的访 问。所述第一模块和第二模块能够，例如，被实现为物理上分离的设备， 或者被实现为由相同的物理设备运行的软件应用。

该布置提供以下优点：能够容易地共享医学数据，而不必须经历常规 的PHR应用所要求的耗时的注册和设置流程。为了共享数据，用户仅需要 为医生提供必要的数据请求信息，例如通过将数据请求显示为快速响应 (QR)码，医生能够使用智能手机或平板电脑扫描该QR码。数据请求信 息的使用还具有以下优点：医学数据能够被存储在任何地方，意味着系统 能够容易地与已有的记录系统(例如PHR、HER和EMR)集成。

所述数据请求信息能够包括直接链路，例如为全球资源定位符(URL) 的形式。备选地，在一些实施例中，所述数据请求信息能够为被分配给所 述医学数据的唯一识别符。例如，不同的识别符能够被分配给针对不同患 者的医学数据，并且不同的识别符能够被分配给针对相同患者的医学数据 的预定义子集。每个识别符能够被存储在数据库中并被交叉引用到识别对 应医学数据的已知位置的信息。所述第二模块能够从所述第一模块获得所 述识别符，并查询所述数据库以检索识别所述对应医学数据的所述已知位 置的所述信息，以请求来自所述数据提供器的所述医学数据。所述数据库 能够被本地存储在所述第二模块中，或者能够被远程访问。作为另外的备 选方案，在一些实施例中，所述第二模块能够通过将所述唯一识别符传输 到所述数据提供器来请求所述医学数据，并且所述数据提供器能够通过如 上所述地查询数据库来检索所述医学数据。备选地，代替唯一识别符，所 述数据请求信息能以另一种方式识别患者的医学数据的子集。例如，所述 数据请求信息能包括要请求特定子集的查询，所述请求例如为针对家族史 数据的请求，所述家族史数据涉及关于所述患者的直系亲属罹患的疾病的 信息，或者针对近期患者数据的请求，所述近期患者数据包括针对所述患 者的来自近期时间段(例如从6个月以前直到今天)的医学数据。

在一些实施例中，所述第一模块被布置为将一个或多个访问参数包括 在所述数据请求信息中，所述访问参数包括涉及要如何与所述第二模块共 享所述医学数据的参数，所述第二模块被布置为在请求所述医学数据时将 所述访问参数传输到所述数据提供器，并且所述数据提供器被布置为基于 所述访问参数控制由所述第二模块对所述医学数据的访问。所述一个或多 个访问参数能够包括：时间段参数，其限定的时间段，在所述时间段期间 所述第二模块被允许访问所述医学数据；和/或数据元素参数，其识别被包 括在所述医学数据中的多个数据元素中的哪一些能够被所述第二模块访 问。

所述访问参数能够被用于控制所述第二模块被允许访问所述医学数据 的方式。例如，用户能够设置访问限制，使得所述医学数据中的仅某些数 据元素被共享。该特征赋予用户在被共享的所述数据上的精细控制。

在一些实施例中，所述数据请求信息包括链接到所述数据提供器的统 一资源定位符URL，并且所述第二模块被布置为通过导航到所述URL来请 求所述医学数据。该布置能够允许包括所述第二模块的设备使用任意网页 浏览器来通过基于网页的应用访问医学数据。基于网页的应用的使用能够 使得来自不同类型的健康记录系统的医学数据能够在不需要在所述设备上 安装任何特殊软件的情况下被访问。

在一些实施例中，所述第一模块被布置为将所述数据请求信息显示为， 例如快速响应(QR)码。该途径允许所述数据请求信息被任何这样的设备 获得，所述设备包括相机并且具有处理所捕获的图像以检测所述数据请求 信息的能力，例如数据请求信息在被显示为QR码时使用QR阅读器应用以 检测并解码所述数据请求信息。

在一些实施例中，所述数据提供器被布置为通过请求来自所请求的医 学数据所对应于的所述患者的验证，对来自所述第二模块的要访问所述医 学数据的所述请求做出响应，并且被布置为响应于成功验证而向所述第二 模块提供所请求的医学数据。验证的使用意味着，如果包括所述第一模块 的所述设备丢失或被盗，所述医学数据的安全也不受损，这是因为第三方 在没有所必要的验证信息，例如用户姓名和口令，时不能访问所述医学数 据。

在一些实施例中，所述数据提供器被布置为通过以下来请求验证：将 验证请求传输到所述第一模块、接收来自所述第一模块的验证信息，并将 接收到的验证信息与针对所述患者的已知验证信息进行比较以确定验证是 否成功。由于所述第二模块不参与验证，因此这避免了所述验证被所述第 二模块截获的任何风险。

在一些实施例中，所述数据请求信息包括识别所述第一模块或所述第 二模块的验证设备信息，并且所述数据提供器被布置为请求来自通过所述 验证设备信息识别的所述第一模块或所述第二模块的验证。这能够允许即 使在所述第一模块不能够提供验证信息时，例如在所述第一模块不包括能 通过其输入验证信息的任意用户接口时，也能够被执行的验证。

在一些实施例中，在从所述第二模块的接收到针对对所述医学数据的 访问的所述请求之后，所述数据提供器被布置为确定所述数据请求信息是 否已被用于先前数据请求中，并仅在确定出所述数据请求信息尚未被用于 先前数据请求中时向所述第二模块提供所请求的医学数据。

在一些实施例中，所述第一模块被布置为获得受保护令牌并将所述受 保护令牌包括在所述数据请求信息中，所述受保护令牌包括已使用密码学 密钥(cryptographickey)得到保护的令牌，并且所述数据提供器被布置为 从所述第二模块接收所加密的令牌，使用预期密码学密钥处理所述受保护 令牌，并且如果使用所述预期密码学密钥成功获得所述令牌，则在所述预 期密码学密钥先前尚未被使用时，确定所述数据请求信息尚未在先前数据 请求中被使用。

在一些实施例中，所述第一模块被布置为通过获得令牌并然后使用所 述密码学密钥来保护所述令牌，获得所述受保护令牌。例如，所述第一模 块能够通过应用使用加密密钥(encryptionkey)的加密，保护所述令牌。 在其他实施例中，所述第一模块被布置为从多个受保护令牌选择所述受保 护令牌。例如，所述第一模块能够被安装有预定受保护令牌的列表，例如 已使用加密密钥被加密的加密令牌。尽管在上述范例中描述了加密，但在 其他实施例中，可以代替或额外于加密，而应用其他类型的密码学保护， 例如验证。

在一些实施例中，所述数据提供器被布置为通过对先前密码学密钥应 用密码学算法来获得所述预期密码学密钥，所述先前密码学密钥为在当前 数据请求之前最近期接收到的数据请求中使用的密码学密钥。在一些实施 例中，所述密码算法为对所述数据提供器和所述第一模块两者都已知的哈 希函数，使得所述数据提供器和所述第一模块两者都能够从先前密码学密 钥获得相同的密码学密钥。

在一些实施例中，所述数据提供器被布置为通过检索来自一个或多个 远程医学记录服务器的所述医学数据，并将检索到的医学数据传输到所述 第二模块，来提供对所述医学记录的访问。通过这么做，所述系统能够容 易地与已有的医学记录系统集成。例如，所述一个或多个远程医学记录服 务器能够包括一个或多个个人健康记录PHR服务器，和/或一个或多个电子 健康记录HER服务器，和/或一个或多个电子医学记录服务器。

在一些实施例中，所述系统中的部件，例如，所述数据提供器以及所 述第一模块或所述第二模块，能够被实现在单个物理设备中。在其他实施 例中，所述系统的各个部件能够被分布在两个或更多个设备间。

根据本发明的另一方面，提供一种用作所述系统中的第一模块的装置， 所述装置包括：数据请求信息生成器，其被布置为生成用于请求对来自所 述数据提供器的所述医学数据的访问的数据请求信息；以及数据请求信息 提供模块，其被布置为向所述第二模块提供所生成的数据请求信息。

根据本发明的另一方面，提供一种对所述第一模块的控制方法，所述 方法包括：生成用于请求对来自所述数据提供器的所述医学数据的访问的 数据请求信息；并且向所述第二模块提供所述数据请求信息。

根据本发明的另一方面，提供一种用作所述数据提供器的装置，所述 装置包括：控制器，其被布置为检索对应于患者的医学数据；验证模块， 其被布置为请求验证；以及通信模块，其被布置为与第一模块和第二模块 通信，其中，响应于通过所述通信模块从所述第二设备接收到的要提供对 所述医学数据的访问的请求，所述控制器被布置为控制所述验证模块通过 所述通信模块来请求来自所述第一模块或所述第二模块的验证，并确定验 证是否成功，并且响应于成功验证，所述控制器被布置为通过所述通信模 块向所述第二模块提供对所请求的医学数据的访问。

根据本发明的另一方面，提供一种提供医学数据的方法，所述方法包 括：接收要提供对所述医学数据的访问的请求；响应于针对所述医学数据 的所述请求，请求来自第一模块或第二模块的验证；确定验证是否成功； 以及响应于成功验证，提供对所请求的医学数据的访问。

根据本发明的另一方面，提供一种用作所述系统中的第二模块的装置， 所述装置包括：数据请求信息检测器，其被布置为从所述第一模块获得数 据请求信息；通信模块，其用于与所述数据提供器通信；以及控制器，其 被布置为基于所获得的数据请求信息来控制所述通信模块请求对来自所述 数据提供器的所述医学数据的访问。

根据本发明的另一方面，提供一种用于在第二模块请求对医学数据的 访问的方法，所述方法包括：从第一模块获得数据请求信息，所述数据请 求信息包括用于请求对来自所述数据提供器的所述医学数据的访问的信 息；并且基于所获得的数据请求信息来请求对来自所述数据提供器的所述 医学数据的访问。

根据本发明的另一方面，还提供一种被布置为存储计算机程序的计算 机可读存储介质，所述计算机程序在由设备运行时，令所述设备执行本文 中描述的所述方法中的任一种。

本发明的这些和其他方面将从后文描述的实施例变得显而易见，并将 参考这些实施例得以阐明。

附图说明

现在将参考附图，仅以举例的方式，描述本发明的实施例，在附图中：

图1示意性地示出了根据本发明的实施例的用于管理对对应于患者的 医学数据的访问的系统；

图2示意性的示出了根据本发明的实施例的用作图1的系统中的第一 设备的装置；

图3示意性地示出了根据本发明的实施例的用作图1的系统中的第二 设备的装置；

图4示意性地示出了根据本发明的实施例的用于使用验证来管理对医 学数据的访问的系统；

图5示意性地示出了根据本发明的实施例的用作图4的系统中的数据 提供器的装置；

图6示出了解释图4的系统的操作的流程图；

图7示意性地示出了根据本发明的实施例的，用于管理对来自多个个 人健康记录(PHR)的医学数据的访问的系统；

图8示出了解释根据本发明的实施例的生成并提供数据请求信息的方 法的流程图；

图9示出了解释根据本发明的实施例的管理对医学数据的访问的方法 的流程图；并且

图10示出了解释根据本发明的实施例的选择要执行验证的设备的方法 的流程图。

具体实施方式

图1示意性地示出了根据本发明的实施例的用于管理对对应于患者的 医学数据的访问的系统。所述系统能够被用于允许医师访问患者的医学数 据，并且可以被称作健康照护支持系统。

系统100包括第一设备110、第二设备120以及数据提供器130。数据 提供器130被布置为向第二设备120提供医学数据。第一设备110能够被 用于共享医学数据，并将在后文被称作“患者设备”。第二设备120能够被 用于察看由所述患者共享的医学数据，并将在后文被称作“医师设备”。医 学数据能够被本地存储或者能够由数据提供器130从远程位置访问。例如， 数据提供器130能够在因特网上从一个或多个PHR检索医学数据。在将在 下面更详细地描述的一些实施例中，数据提供器130可以在提供对医学数 据的访问之前要求患者验证。

患者设备110被布置为显示数据请求信息，以供在通过数据提供器130 访问医学数据时使用。在本实施例中，数据请求信息包括链接到数据提供 器130的统一资源定位符(URL)。此外，数据请求信息还包括用于从数据 提供器130请求医学数据的数据请求令牌。数据请求令牌被提供为要被传 送到数据提供器130的URL参数。

患者设备110能够将数据请求信息显示在屏幕上，并且能够例如为智 能手机、平板电脑、通用计算机或任何其他合适的装置。在本实施例中， 患者设备110为智能手机，并且被布置为将数据请求信息显示为快速响应 (QR)码140，但在其他实施例中，数据请求信息能够被显示为不同格式， 例如为条形码或纯文本。

在其他实施例中，患者设备110能够将数据请求信息显示在任意表面 上，该表面不必须为屏幕。例如，在一些实施例中，患者设备110能够为 可穿戴物品，例如手环，在其中数据请求信息被镌刻或打印到表面上。此 外，在其他实施例中，数据请求信息可以不被显示而是可以使用另一种合 适的方法从患者设备被转移到医师设备，例如射频识别(RFID)或其他类 型的近场通信(NFC)方法。

医师设备120被布置为检测所显示的数据请求信息。医师设备120还 被布置为基于所检测的数据请求信息来通过数据提供器130访问医学数据。 在本实施例中，由于数据请求信息被显示为QR码140，因此医师设备120 被布置为通过捕获患者设备110的图像，来处理所捕获的图像以检测QR码 140，并且对QR码140进行解码以获得数据请求信息，来获得数据请求信 息。在另一实施例中，数据请求信息被显示为条形码，并且医师设备120 被布置为使用条形码阅读器来检测所显示的数据请求信息。在本实施例中， 医师设备120为智能手机，但在其他实施例中，医师设备120能够为平板 电脑、通用计算机或任何其他合适的装置。

如上所述，在本实施例中，数据请求信息包括链接到数据提供器130 的统一资源定位符(URL)，但是在其他实施例中除URL以外的不同格式 能被用于链接到数据提供器130。为了访问医学数据，第二设备120被布置 为通过网页浏览器应用导航到URL，结果是网页浏览器应用从数据提供器 130请求URL中指定的资源。URL可以，例如通过指定对应于其医学数据 正被请求的患者的目录，包括识别正被请求的医学数据的路径。备选地， 能够以另一种方式识别正被请求的医学数据，例如通过被包括在URL中的 查询字符串，其将被传递到在数据提供器130上运行的软件。

医师设备120和数据提供器130能够被布置为在任意有线或无线连接 上通信，例如蓝牙连接或无线局域网(WLAN)连接。数据提供器130能 够被实现为与患者设备110和医师设备120分开的独立装置。备选地，在 一些实施例中，数据提供器130能够被实现在与患者设备110或医师设备 120相同的物理装置中。例如，当患者设备110为智能手机时，数据提供器 130能够被实现为患者设备110中安装的软件应用，并且医师设备120能够 与患者设备110通信以通过数据提供器130访问医学数据。

通过显示数据请求信息，患者设备110允许用户，例如患者或患者的 照护者，控制对患者的存储医学数据的访问。例如，为了允许医生访问所 存储的医学数据，患者能够向医生示出所显示的数据请求信息，医生能够 使用医师设备120扫描所显示的数据请求信息。医师设备120然后使用所 扫描的数据请求信息来访问医学数据。系统100能够安全地管理对患者的 医学数据的访问，这是因为医师设备120在没有对患者设备110的视线可 视性以检测所显示的数据请求信息时是不能访问医学数据的。

图2示意性地示了出根据本发明的实施例用作图1的系统中的患者设 备的装置。装置210包括用户界面211、访问参数设置模块212、数据请求 信息生成器213以及显示器214。

用户界面211能够接收用户输入，该用户输入选择涉及应当如何与第 二设备共享医学数据的一个或多个访问参数。这允许用户定义将与第二设 备共享医学数据的程度。能够通过用户输入选择的访问参数的范例包括， 但不限于，在其期间第二设备被允许访问医学数据的时间段，以及数据元 素限制。具体地，医学数据能够包括多个数据元素，并且用户能够设置数 据元素限制，以控制数据元素中的哪些可以被第二设备访问。

访问参数设置模块212被布置为将所限定的访问参数发送到数据请求 信息生成器213，数据请求信息生成器213将访问参数包括在所生成的数据 请求信息中。然后将所生成的包括访问参数的数据请求信息显示在显示器 214上。

在本实施例中，数据请求信息包括链接到数据提供器的URL。如上文 参考图1所述，URL的形式为数据提供器130指示那些医学数据正被第二 设备请求。而且，在本实施例中，装置210包括用于将数据请求信息转变 成QR码的软件。任意合适的QR码生成器都能够被用于该目的。然后在显 示器214上将数据请求信息显示为QR码。

尽管在本实施例中，装置210包括用于向第二设备提供数据请求信息 的显示器，但在其他实施例中，可以使用不同方法提供数据请求信息，例 如NFC。一般情况下，患者设备能够包括任意合适的数据请求信息提供模 块，其能够例如为图2中所示的显示器、RFID发射器，或网络接口模块。 本发明不限于这些类型的数据请求信息提供模块，它们是以举例的方式来 描述的。

图3示意性地示出了根据本发明的实施例用作图1的系统中的医师设 备的装置。装置320包括控制器321、数据请求信息检测器322、通信模块 323以及显示器324。装置320能够使用通信模块323与数据提供器通信， 例如在网络连接上。在本实施例中，通信模块323为WLAN模块，但在其 他实施例中，可以使用不同的通信协议。

控制器321控制数据请求信息检测器322来检测在患者设备上显示的 数据请求信息。在本实施例中，数据请求信息被显示为QR码的形式，并且 数据请求信息检测器322包括用户捕获患者设备的图像的相机。图像捕获 过程能够由用户以常规方式控制。在图像已被捕获后，所述装置处理图像 以对QR码进行检测并解码，以获得数据请求信息。为此目的，常规的QR 码阅读器能够被安装在装置320上，或者能够提供专用硬件QR码处理器。

尽管在本实施例中，数据请求信息检测器为相机，但应认识到，在其 他实施例中，可以根据由患者设备使用的用于向第二设备提供数据请求信 息的方法，使用不同类型的数据请求信息检测器。例如，数据请求信息检 测器能够为被布置为接收作为RFID信号的数据请求信息的RFID接收器， 或者被布置为在网络上接收数据请求信息的网络接口模块。本发明不限于 这些类型的数据请求信息检测器，它们是以举例的方式来描述的。

在数据请求信息已被获得后，控制器321基于数据请求信息，通过通 信模块323，请求来自数据提供器的医学数据。然后将通过通信模块323从 数据提供器接收所请求的医学数据，假定满足任意需要的验证流程和/或访 问限制。控制器321控制显示器324来显示接收到的医学数据。尽管在本 实施例中，医学数据是在与数据请求相同的通信链路上被发送的，但在其 他实施例中，医师设备320能够在不同的通信链路上接收医学数据。

诸如图3中所示的装置能够被用于简单地通过扫描被显示在患者设备 上的数据请求信息，来快速且容易地访问针对患者的医学数据。

图4示意性地示出了根据本发明的实施例的用于使用验证来管理对医 学数据的访问的系统。系统400包括患者设备410、医师设备420以及数据 提供器430。系统400类似于图1的，附加特征为数据提供器被布置为在向 医师设备420提供所请求的医学数据之前，请求来自患者的验证。

患者设备410能够显示数据请求信息，并且医师设备420能够检测由 患者设备410显示的数据请求信息，并使用上述途径中的任一种来请求来 自数据提供器430的医学数据。当本实施例的数据提供器430从医师设备 420接收到针对医学数据的请求时，数据提供器430通过请求来自所请求的 医学数据对应于其的患者的验证来做出响应。在本实施例中，如图4中所 示，数据提供器430通过将验证请求传输给患者设备410，对来自医师420 设备的数据访问请求做出响应。患者设备410接收验证请求并提示用户输 入验证信息，例如用户识别符(ID)和口令(PWD)。在验证信息已被输入 之后，患者设备410将验证信息传输到数据提供器430。验证方法是已知的 并将省略详细描述以保持简要。然而，简单来讲，数据提供器430被布置 为将接收到的验证信息与针对患者的已知验证信息进行比较，并且在接收 到的验证信息匹配已知验证信息时确定验证成功。数据提供器430还被布 置为通过向医师设备420提供所请求的医学数据来对成功验证做出响应。

在其他实施例中，能够使用不同的验证方法。例如，能够通过在患者 设备410处将所输入的验证信息与已知验证信息进行比较，在患者设备410 而不是数据提供器430执行验证。通过这么做，不需要将验证信息传输到 数据提供器430。而是相反，患者设备410仅需要将验证的结果传输到数据 提供器430。该途径可以更安全，因为没有在传输被截获时使验证信息受损 的风险。

尽管在本实施例中，被授权提供验证的用户为所请求的医学数据对应 于其的患者，但在其他实施例中，另一用户可以被允许授权数据请求，代 替或额外于患者。作为一个范例，在本发明的实施例中能够实施打破玻璃 (break-glass)的流程。在患者不能够授权数据请求的情况中，例如如果患 者因受伤或不适而丧失能力，则经批准的健康照护提供者能够被用于弃用 (override)正常的授权流程，以确保医学数据能能够被访问。打破玻璃流 程可以仅提供对医学数据的预定义子集的访问，包括对紧急情形中的使用 而言最重要的数据。应当通过审计流程来限制并监控经由紧急账户的访问， 以确保仅在真正紧急的情况中使用打破玻璃流程。

在本实施例中，数据提供器430将验证请求传输到患者设备410，但本 发明不限于该途径。例如，在其他实施例中，验证请求能够替代地被传输 到医师设备420。在患者设备410不能够执行验证时，例如在患者设备410 不具有接收或发射功能，和/或不包括用于输入验证信息的用户界面时，在 医师设备420执行验证可以是合适的。

在一些实施例中，患者设备410能够被布置为显示数据请求信息，其 包括识别患者设备410或医师设备420的验证设备信息。医师设备420然 后将验证设备信息包括在被传输到数据提供器420的数据请求中，并且数 据提供器430请求来自通过验证设备信息识别出的设备的验证。该途径允 许患者设备指定应当在患者设备或在医师设备执行验证。因此，如果患者 设备不具有参与验证的功能，则患者设备能够使用验证设备信息以用信号 通知数据提供器应当由医师设备代替执行验证。

图5示意性地示出了根据本发明的实施例的用作图4的系统中的数据 提供器的装置。如图5中所示，装置530包括控制器531、验证模块532、 通信模块533、数据访问管理模块534以及授权模块535。

控制器531被布置为通过通信模块533接收针对医学数据的请求。在 本实施例中，请求包括用于授权数据请求的令牌，并且授权模块535被布 置为核验接收到的令牌，以确定是否允许数据请求。

响应于令牌被授权模块535成功地核验，控制器531控制验证模块532 在提供所请求的数据之前执行验证。验证模块532通过通信模块533将验 证请求传输到患者设备，如上文参考图4所描述的。验证模块532通过通 信模块533接收验证信息，将接收到的验证信息与针对授权用户(其在本 实施例中为所请求的数据所对应于的患者)的已知验证信息进行比较，并 在存在匹配时确定验证成功。在一些实施例中，验证模块532也被布置为， 例如使用安全断言标记语言(SAML)令牌或公共密钥基础设施(PKI)证 书，验证请求设备(即医师设备)的用户，以证实用户为医学专业人员。

响应于成功验证，控制器531通过使用数据访问管理模块534来检索 所请求的医学数据，以从合适的数据源(例如PHR)获得医学数据，并通 过通信模块533将医学数据传输到医师设备。数据访问管理模块534能够 被配置为与多个不同的医学数据源(包括各种PHR、HER和EMR)一起操 作。

在本实施例中，在相同的通信链路上发送数据请求、验证请求、验证 信息和医学数据，但在其他实施例中，通信模块533能够被布置为利用两 个或更多个分开的通信链路。例如，通信模块533能够在蓝牙连接上与患 者设备通信以执行验证，并且能够在WLAN连接上将医学数据发送到医师 设备。

图6示出了解释图4的系统的操作的流程图。流程图图示在患者设备 410、医师设备420和数据提供器430执行的步骤。

首先，在步骤S10中，患者设备410生成数据请求信息。取决于实施 例，数据请求信息可以包括诸如访问参数、验证设备信息和/或一次性代码 (以防止医师设备420在后续数据请求中重复使用数据请求信息)的其他 信息。在本实施例中，数据请求信息包括URL和作为URL参数的数据请 求令牌，但在其他实施例中，可以使用不同格式。

然后，在步骤S11中，所生成数据请求信息被显示在患者设备410上。 在本实施例中，数据请求信息被显示为QR码，并且步骤S11包括将所生 成的URL转变成QR码。

接下来，在步骤S12中，医师设备420检测所显示的数据请求信息。 在本实施例中，该步骤涉及捕获患者设备410的图像，并处理图像以检测 并解码QR码，但如上文解释的，在其他实施例中能够使用其他检测数据请 求信息的方法。然后，在步骤S13中，医师设备420通过导航到URL并传 输被包括在数据请求信息中的数据请求令牌，来将数据访问请求传输到数 据提供器430，以请求对医学数据的访问。

然后，在步骤S14中，由数据提供器430接收包括数据请求令牌的数 据访问请求。当数据请求信息为包括诸如访问参数、验证设备信息和/或一 次性代码的其他参数的URL时，这些其他参数将被接收在数据访问请求中， 并因此对数据提供器430可用。

接下来，在步骤S15中，数据提供器430请求来自患者设备410的验 证，患者设备410在步骤S16中接收验证请求。在步骤S17中，患者设备 410获得诸如用户ID和或口令的验证信息，验证信息能够被存储在患者设 备410中或者能够通过提示用户通过用户界面输入验证信息来获得。然后， 验证信息在步骤S18中被患者设备410传输，并在步骤S19中被数据提供 器430接收。在步骤S20中，数据提供器430通过将接收到的验证信息与 针对授权用户(在该实施例中为所请求的医学数据对应于其的患者)的已 知验证信息进行比较来检查验证是否成功。

响应于成功验证，所请求的医学在步骤S21中被检索，并在步骤S22 中被传输到医师设备420，医师设备420在步骤S23中接收并显示医学数据。

图6的方法能够通过使用能够被医师设备420扫描的数据请求信息， 方便医学数据在患者与医生之间快速且容易的共享。同时，验证机制的使 用确保了医学数据在没有来自患者的明确授权时不能被访问。这能够在患 者设备410丢失或被盗的请况中提供额外的安全。

尽管在本实施例中，数据提供器430在步骤S15中请求来自患者设备 410的验证，但在另一实施例中，数据提供器430在步骤S15中请求来自医 师设备420的验证。应理解，在该其他实施例中，将在医师设备420执行 验证步骤S16、S17和S18。数据请求信息能够包括识别要在其处执行验证 的设备的设备验证信息，并且设备验证信息在数据请求时被传递到数据提 供器430。此外，如上文所述，能够在患者设备410或医师设备420执行确 定验证是否成功的步骤(S20)，意味着在在步骤S18和S19中，传输和接 收的是验证结果而非验证信息。

图7示意性地示出了根据本发明的实施例的用于管理对来自多个个人 健康记录(PHR)的医学数据的访问的系统。系统700的许多方面都与图1 和图1中所示的系统的对应方面相似，并将在这里省略对相似部分的详细 描述以保持简要。

本实施例的系统700包括患者设备710、医师设备720、数据提供器730， 以及第一PHR751、第二PHR752和第三PHR753。响应于针对特定患者 的医学数据的请求，数据提供器730被布置为从第一PHR751、第二PHR752 和第三PHR753检索针对所识别的患者的数据。在一些实施例中，针对患 者的医学数据可以以相同的患者识别符被存储在每一个PHR中。在其他实 施例中，PHR系统751、752、753中不同的一些可以使用针对相同患者的 不同识别符。在这样的实施例中，为了访问针对相同患者的医学数据，数 据提供器730能够被布置为存储对不同PHR系统751、752、752针对相同 患者使用的不同患者识别符的交叉引用。备选地，数据提供器730能够检 索患者识别信息，其例如可以包括姓名、生日、国籍或民族、和/或地址， 并查询每个PHR751、752、753以检索针对匹配所检索的识别信息的患者 的医学数据。

例如图7的实施例能够允许患者容易地共享来自多个不同记录系统(例 如PHR、EMR和EHR)的医学数据。数据提供器730能够检索来自系统的 数据，并以透明的方式将数据提供到医师设备720。通过利用通过数据提供 器720链接到医学数据的数据请求信息740，医师设备720不需要拥有被安 装用于访问每个个体记录系统751、752、753的单独的软件。数据请求信 息740允许由数据提供器730而非医师设备720管理数据检索。

尽管在图7中图示了三个PHR，但在其他实施例中，可以通过数据提 供器730访问任意数目的一个或多个PHR。作为代替或额外于访问来自PHR 的数据，数据提供器730可以访问其他类型的医学记录系统，包括一个或 多个EMR以及一个或多个HER。

图8示出了解释根据本发明的实施例的生成和提供数据请求信息的方 法的流程图。该方法能够由上述实施例中任一个中的患者设备使用。

在步骤S24中，患者设备接收用户输入，该用户输入选择用于控制如 何与第二设备共享医学数据的一个或多个访问参数。这允许用户，例如通 过选择以共享指定时间段内(例如一天、一周等等)的数据和/或通过从医 学数据中包括的多个数据元素选择要被共享的仅特定的数据元素，来定制 数据共享过程。

在本实施例中，数据请求信息包括URL，并且访问参数能够以要被附 加到URL的一个或多个查询字符串的形式被包括在数据请求信息中。以此 方式，当医师设备在网页浏览器应用中载入URL时，访问参数将在数据请 求中被自动传递到数据提供器。应认识到，在其他实施例中，能够使用针 对访问参数的其他格式。

然后，在步骤S25中，患者设备例如通过检索多个预定数据请求令牌 中的一个，或者通过使用预定算法生成新的令牌，来获得数据请求令牌。

接下来，在步骤S26中，患者设备获得用于加密令牌的加密密钥(K)。 在本实施例中，当前加密密钥是通过对在加密最近生成的数据请求信息中 的令牌时使用的先前加密密钥应用预定哈希函数来获得的。一般而言，当 前加密密钥能够被称作第N加密密钥(K_N)，并且先前加密密钥能够被称 作第(N-1)加密密钥(K_N-1)。

初始加密密钥(K₁)，通过哈希函数的重复应用从其导出第二和后续加 密密钥，是在患者设备与数据提供器之间共享的密钥。例如，患者设备和 数据提供器能够在系统的设置期间都被提供以初始加密密钥。在其中患者 设备为诸如智能手机或平板电脑的通用设备的实施例中，初始加密密钥能 够被包括在应用(“app”)中，该应用被下载并安装在患者设备中以配置 患者设备以供在系统中的使用。

尽管在本实施例中，患者设备按需生成加密密钥，在但另一实施例中， 患者设备被预先配置有N个预定义的加密密钥，它们是已被提前生成并被 安装在患者设备中的。例如，预定义的加密密钥能够被包括在应用 (“app”)中，该应用被下载并安装在患者设备中以配置患者设备以供在 系统中的使用。预定义加密密钥的使用避免了患者必须被提供哈希函数和 初始加密密钥。

然后，在步骤S27中，患者设备使用在步骤S26中获得的当前加密密 钥加密在步骤S25中获得的令牌。

通过通过对先前加密密钥进行哈希来生成每个加密密钥，能够使用不 同的密钥来加密被包括在数据请求信息的每种实例中的令牌。该途径允许 数据提供器确定任意给定数据请求信息是否在先前已被用于共享数据，如 将在后面更详细描述的。

接下来，在步骤S28中，生成数据请求信息，其包括在步骤S24中获 得的访问参数和在步骤S27中获得的加密令牌两者。然后，在步骤S29中， 数据请求信息被提供到医师设备，例如通过显示数据请求信息。

尽管在本实施例中，当前加密密钥仅被用于加密数据请求令牌，但在 其他实施例中，也可以加密数据请求信息的其他元素，例如访问参数。当 到数据提供器的连接，例如URL，被包括在数据请求信息中时，URL优选 地被留作未被加密的，从而其能够被医师设备理解。通过留下URL在数据 请求信息中未被加密，医师设备不必须被提供以初始加密密钥，由此改善 安全性，这是因为医师设备不能够访问或修改数据请求信息的加密元素中 的信息。然而在一些实施例中，医师设备也可以被提供有初始加密密钥， 在该情况中，数据请求信息的整体(包括到数据提供器的连接)能够被患 者设备加密。

而且，在另一实施例中，在步骤S24中能够检索存储的访问参数信息， 代替生成用于定义的访问参数。例如，能够在患者设备的配置期间设置并 存储缺省访问参数。

此外，在一些实施例中，可以不使用访问参数信息并且因此可以省略 步骤S24。而且，一些实施例可以不利用一次性加密方案，在该情况中可以 省略步骤S26和S27。

在另一实施例中，数据请求信息被显示为QR码并且患者设备被布置 为存储多个预定QR码，每个预定QR码包括数据请求信息以及如果要求的 话任意访问参数信息。在该实施例中，能够省略步骤S26，并且相反是在步 骤S27中按需生成数据请求信息，设备能够简单地选择预定QR码中先前 尚未被使用的一个。例如，每个代码能够在其已被使用后从可用代码的列 表被删除，或者能够被标识为不可用。由于每个预定QR码被使用一次，因 此该实施例能够实现与使用一次性代码相同的效果，而不必须每次获得一 新代码并按需生成新数据请求信息。

尽管在本实施例中，患者设备每次获得不同的加密密钥，以使得数据 提供器能够在从医师设备接收数据请求时确定数据请求信息是否已被使用 过，但在其他实施例中，可以使用备选的途径。例如，在另一实施例中， 患者设备能够被布置为在数据请求信息的每种实例中包括唯一令牌，并且 数据提供器能够维持对接收到的数据请求中的令牌的记录，以确定当前接 收到的令牌是否先前已被使用过。为了确保相同的令牌不被患者设备使用 两次，患者设备能够从预定令牌的列表获得每个令牌，并在每个令牌已被 使用后删除它或以其他方式将其标志为“己使用”。备选地，患者设备能 够使用预定算法来按需生成每个令牌，同时维持对先前使用的令牌的记录， 以确定所生成的令牌是否已被使用。如果是，则患者设备能够继续生成新 令牌，直到发现尚未被使用的一个。以此方式，能够确保每次患者设备生 成新数据请求信息用于授权针对对医学数据的访问的新请求时，唯一令牌 都能够被包括在数据请求信息中以供数据提供器的检测。

图9示出了解释根据本发明的实施例的管理对医学数据的访问的方法 的流程图。该方法能够被数据提供器用于确定接收到的数据请求是否基于 已在先前被使用过的旧的数据请求信息，以避免医师设备能够存储从患者 设备读取的数据请求信息，以在较晚的时间点再一次获得对医学数据的访 问。图9的方法能够被用于在其中已使用上文参考图8描述的方法生成了 数据请求信息的实施例中。

首先，在步骤S30中，数据提供器接收来自另一设备(例如上述医师 设备中的任一个)的数据请求。在本实施例中，医师设备被布置为在请求 来自数据提供器的医学数据时，传输被包括在数据请求信息中的加密令牌。

然后，在步骤S31中，数据提供器通过对先前加密密钥(K_N-1)应用哈 希函数来获得预期加密密钥(K_N)，先前加密密钥为被成功用于解密来自最 近接收的数据请求的令牌的密钥。应认识到，该途径要求患者设备和数据 提供器两者都拥有对相同的预定哈希函数和初始加密密钥的访问。

接下来，在步骤S32中，数据提供器使用所获得的密钥来对接收到的 令牌进行解密，并且在步骤S33中，使用核验算法来核验所解密的令牌。 在步骤S34中，如果令牌未被成功核验，则在步骤S35中确定是否检查备 选密钥。例如，有可能在先前数据请求与正被数据提供器接收的当前数据 请求之间，患者设备己生成并显示了出于任何原因尚未被使用的其他数据 请求信息。在该情况中，当前数据请求中的令牌将已使用较晚的加密密钥 (而不是数据提供器预期的那个)被加密。

因此在本实施例中，如果核验失败，则数据提供器进入在步骤S36中 通过选择备选密钥来检查备选加密密钥，例如通过返回到初始密钥(K1) 并尝试针对链条中的每个密钥的解密和核验，或者直到达到预定限度(例 如，时间限度或检查的密钥的数目)。如果达到预定限度，则在步骤S35过 程终止，并且在步骤S37拒绝数据请求。

另一方面，如果在步骤S34中核验成功，则在步骤S38中，数据提供 器检查密钥是否已被使用。在本实施例中，数据提供器维护针对已被用于 加密接收的令牌的任意加密密钥的密钥索引(N)的记录，并将当前加密密 钥(K_N)的索引(N)与所存储的记录进行比较，以确定第N个加密密钥 (K_N)是否已被使用。

如果当前加密密钥(K_N)已被使用，则在步骤S37中拒绝数据请求。 然而如果当前加密密钥(K_N)尚未在先前被用于数据请求中，则在步骤S39 中，利用当前密钥索引N更新记录，并在步骤S40中允许数据请求，并将 所请求的数据提供到从其接收请求的医师设备。

尽管在本实施例中，数据提供器在被用于加密数据请求令牌的加密密 钥的基础上确定是否允许数据请求，但在其他实施例中，可以使用其他途 径。例如，如上所述，患者设备能够包括在数据请求信息的每一实例中的 唯一代码，有或没有加密。在这样的实施例中，数据提供器能够维持对全 部先前接收的唯一代码的记录，并将当前代码与所存储的代码进行比较， 以确定接收到的唯一代码是否已被包括在先前数据请求中。

诸如本文中参考图8和图9描述的方法能够被使用以确保医师设备必 须获得新的数据请求信息以重新获得对医学数据的访问，例如在由先前获 得的数据请求信息允许的数据访问期已过期后，这为患者设备的用户赋予 在对医学数据的访问上更大的控制。

图10示出了解释根据本发明的实施例选择要执行验证的设备的方法的 流程图。该方法能够被上述系统中的任一个中的数据提供器在需要验证以 授权数据请求时使用，例如如上文参考图4、图5和图6描述的。

首先，在步骤S41中，数据提供器接收数据请求，包括识别患者设备 或医师设备的验证设备信息。验证设备信息能够，例如为被分配给患者设 备或医师设备的唯一设备识别符。备选地，验证设备信息能够为标志，其 值指示验证请求应当被发送到的设备。例如，为“0”的值能够指示验证请 求应当被发送到患者设备，而为“1”的值能够指示验证请求应当被发送到 医师设备。

在步骤S42中，数据提供器基于接收到的验证设备信息来选择验证设 备。然后，在步骤S43中，以与图6的步骤S15相似的方式，验证请求被 传输到所选择的设备。

以上已描述了本发明的实施例，在其中患者设备以URL和数据请求令 牌的形式向医师设备提供数据请求信息。然而，本发明的实施例不限于使 用令牌和URL作为数据请求信息。例如，在另一实施例中，数据请求信息 包括没有数据请求令牌的URL、所述URL直接链接到数据提供器130上的 目录数据能够通过其被访问)。该途径能够使得设备能够通过简单地导航到 URL来请求医学数据，而不需要数据请求令牌。此外，在另一实施例中， 数据提供器130的位置可以是对请求医学数据的实体已知的，意味着能够 从数据请求信息省略链接到数据提供器130的URL。

应认识到，属于“包括”不排除其他元件或步骤，并且词语“一”或 “一个”不排除多个。单个处理器可以完成权利要求中记载的若个项的功 能。尽管在互不相同的从属权利要求中记载了特定措施，但是这并不指示 不能有利地使用这些措施的组合。权利要求中的任何附图标记不应当被解 释为对权利要求的范围的限制。

尽管在本申请中权利要求被制定为特征的特定组合，但应当理解，本 发明的公开内容的范围还包括本文中明确地或暗含地公开的任意新颖特征 或所公开的特征的任意新颖组合，或是它们的任意概括，而无论其是否涉 及与任一权利要求中当前要求保护的相同发明，以及其是否减轻了与母发 明相同的技术问题中的任一个或全部。申请人特此告知，在对本申请的或 从其衍生的任意另外的申请的执行期间，可以对这样的特征和/或特征的组 合制定新的权利要求。