保健数据处理的方法和系统的制作方法

专利名称：保健数据处理的方法和系统的制作方法
技术领域：
本发明涉及一种通过可信代理进行保健数据处理的方法，该可信代理拥有或可以 使用用于访问保健数据的解密密钥。本发明还涉及一种适于处理保健数据的可信代理，其 中所述可信代理拥有或可以使用用于访问保健数据的解密密钥。本发明还涉及一种包括 请求发生器的请求者，其中请求发生器用于生成访问由所述可信代理处理的保健数据的请 求；以及涉及一种包括接收器的服务器，该接收器用于从所述可信代理接收日志。
背景技术：
在信息和通信技术方面的进步被预期在保健领域带来巨大益处可共同操作的电 子健康记录(HER)系统的引入可以减少保健系统的成本并增强治疗的整体质量，而远程患 者管理(RPM)服务将限制患者停留在医院中的时间。然而，迄今为止，EHR和RPM在相当小 的规模上使用。除了关于不同系统的整合问题和逻辑问题之外，关于信息安全和隐私的关 注是缺乏部署的系统的主要原因。例如，EHR系统正面临它们必须遵守的严格的安全和隐 私规则(比如EU规程95/46或美国的HIPAA)。现代保健通信架构倾向于开放的、互连的环境敏感的患者记录不再存在于保 健提供者内部物理隔离的主机上(其中可以采取物理安全措施来保护所述数据和所述系 统)，相反，患者文件被保持在数据被外包到的环境中或在部分地不可信的服务器上被处理 以便允许供家庭医生、医学专家以及甚至非医护提供者分散访问。当前采用的以服务器为 中心保护模型(其将数据锁定在数据库服务器中并且使用传统的访问控制模型来允许访 问数据)不能有效地应付新保健基础设施的要求。为了允许在不同的保健提供者之间或与外部参与方共享记录，可以采用有利于以 数据为中心保护的端到端安全技术数据被加密地保护并且允许被外包或者甚至在网络上 自由散播。与其依靠不同的网络提供机密性、完整性和真实性，倒不如在通信的端点处保护 数据。这可以通过应用权限管理技术-消费型电子设备领域中的数字权限管理(DRM)和商 业领域中的企业权限管理(ERM)来实现。在这种系统中，公布的DRM保护的数据被加密并 且许可证服务器仅仅在请求的用户具有足够的权限访问所述数据的情况下才向其发行许 可证。然而，该技术没有解决的特定问题是确保在紧急情况下立即访问电子患者记录而不 考虑所使用的保护模型。尽管这种DRM/ERM系统在关于仅仅向满足所有必要的访问权限的 请求者提供到保健数据的访问方面非常可靠，但是这样的系统不能处理在所述系统的正常 行为中需要豁免的紧急情况，例如其中保健提供者需要立即访问医学数据。

发明内容
本发明的目的是通过提供一种处理保健数据的安全的但同时又灵活的方式来克 服上述缺陷，所述方式的意义在于它表示所述系统的正常行为中的豁免并且可以应付以下 情况其中例如紧急救护提供者(比如医院)需要立即访问保健数据，但是没有可用的准许 所述救护提供者访问所述保健数据的常规权限。4
根据一个方面，本发明涉及一种通过拥有或可以使用用于访问保健数据的可信代 理来进行保健数据处理的方法，包括-从请求访问保健数据的请求者接收请求，-生成包括与所述请求或所述请求者或二者相关的数据的日志，以及-向所述请求者提供对所述保健数据的访问。因此，在任何时间，所述请求者可以访问医学数据，而同时有效地保护保健数据的 机密性。所述医学数据被加密并且所述可信代理可以基于请求者的身份决定是否将允许访 问(解密)。例如，所述访问策略可以是医学数据只能被保健提供者访问。而且，访问被 记录，这使得访问数据的保健提供者对他的行为负责。所述可信代理可以例如是来自可信 商家的物理设备或软件应用并且可以具有标准接口。这使得多个商家能够进行实施并且也 要求医学应用实现单个接口。在一个实施例中，所接收的请求包括表示所接收的请求是紧急请求的数据标记。因此，不同于如前所讨论的现有技术的应用，比如数字权限管理(DRM)客户端应 用，其中使用不能够处理访问保健数据的紧急请求的许可证服务器、顺从的(compliant) 客户端等等，所述紧急救护(例如医院)将被授予许可证，该许可证将允许他访问他想要访 问的数据，即使他没有正常的权限访问它。尽管这种紧急访问可能以保健数据的安全为代 价(这确实是一个重要特征)，但是与患者的安全相比，它仍然不太重要，因为这种对保健 数据的紧急访问可能挽救患者的生命。在一个实施例中，从所述请求者接收的请求包括请求用于访问保健数据的解密密 钥，向所述请求者提供对保健数据的访问的步骤将所请求的解密密钥转发给请求者。因此，避免了以下瓶颈其中所述可信代理不需要解密所接收的请求所源自的所 有客户端的数据。所述解密在客户端应用处发生。在一个实施例中，从所述请求者接收的请求包括加密形式的所述请求的保健数 据，向所述请求者提供对保健数据的访问的步骤将解密形式的保健数据转发给所述请求者ο这允许所述可信代理与不支持数字权限管理和数据解密的传统系统交互操作。在 这种情况下，所述加密的数据被离线存储在客户端应用处。在一个实施例中，在所接收的请求之后，所述代理从服务器获得加密形式的保健 数据并且对所述保健数据进行解密，向所述请求者提供对保健数据的访问的步骤将所述解 密的保健数据转发给所述请求者。该实施例提供与先前一个实施例相同的优点。然而，该实施例中的所述医学数据 被存储在集中式数据库中。在一个实施例中，所述方法进一步包括将所述日志提交给服务器以供复查。因此，所述可信代理可以记录关于所述请求、请求者的所有必要的细节。这可以是 背景(context)数据(比如日期和时间)、包含在所述请求中的信息(比如所请求的数据)、 关于所述请求者的信息(比如正在使用的医学应用或设备的注册凭证)、关于设备的信息 (比如IP地址)等等。在一个实施例中，许可证包括所述解密密钥连同用于访问保健数据的相关许可证 规则，并且其中所述请求者是数字权限管理(DRM)客户端应用或企业权限管理(ERM)客户端应用，向DRM或ERM客户端应用提供对保健数据的访问的步骤将所述许可证解密密钥连 同相关的许可证规则转发给DRM或ERM客户端应用。在一个实施例中，利用文本密钥保护保健数据，并且其中所述许可证包括针对受 保护的保健数据的利用紧急密钥KEm加密的文本密钥，所述紧急密钥KEm随后被分发给所有可信代理。在一个实施例中，所述许可证被附加到受保护的保健数据。在一个实施例中，所述紧急许可证和所保护的保健数据被转发给DRM或ERM，其中 在紧急请求时，所述DRM或ERM进一步被提供适于解密所述文本解密密钥的紧急密钥Ka。根据另一方面，本发明涉及一种计算机程序产品，其用于当该产品在计算机上运 行时指令处理单元执行上述分方法步骤。根据又一个方面，本发明涉及一种适于处理保健数据的可信代理，其中所述可信 代理拥有或可以使用用于访问保健数据的解密密钥，所述可信代理包括接收器，用于从请求者接收请求访问保健数据的请求，日志发生器，用于生成包括与所述请求或所述请求者或二者有关的数据的日志， 以及处理器，用于处理所接收的请求，所述处理导致向所述请求者提供对保健数据的 访问ο根据又一个实施例，本发明涉及一种请求者，其包括用于生成访问由所述可信代 理处理的保健数据的请求的请求发生器，其中所述请求发生器进一步适于生成表示所生成 的请求是紧急请求的数据标记。根据又一方面，本发明涉及一种服务器，其包括用于从所述可信代理接收日志的 接收器以及用于存储所接收的日志的存储器，其中所述存储器进一步存储保健数据、或用于访问保健数据的解密密钥、或包括 解密密钥连同用于访问保健数据的相关许可证规则的许可证，或它们的组合，其中所述可信服务器适于操作、提供和管理多个所述可信代理，所述操作包括响 应于从所述可信代理接收所述日志，通过提供所请求的解密密钥向所述可信代理提供对保 健数据的访问。本发明的每一个方面可以与任何其他方面相结合。本发明的这些和其他方面将根 据下文描述的实施例而变得清楚并且参照这些实施例而被阐明。


将仅仅通过实例并参照附图描述本发明的实施例，在附图中图1示出根据本发明的方法的流程图，图2图示地描绘根据本发明的可信代理、请求者和服务器，图3示出DIC0M(医学数字成像和通信)_顺从的DRM系统的加密文件和许可证，图4示出支持紧急访问的增强的DRM基础设施，其由旧DRM基础设施和新紧急基 础设施构成，图5描绘了可被认为是顺从的客户端的请求者所进行的紧急数据访问，和图6描绘了可被认为是非顺从客户端的请求者所进行的紧急数据访问。
具体实施例方式图1示出根据本发明的通过拥有或可以使用用于访问保健数据的解密密钥的可 信代理进行保健数据处理的方法的流程图。所述保健数据可以是标识患者和患者的病历的 数据。所述可信代理可以是来自例如可信商家的物理设备或软件应用。优选地，它具有使 多个商家能够进行实施并且还需要医学应用实现单个接口的标准接口。所述医学应用可以 被认为是正常医学应用或被认为是紧急医学应用。正常的医学应用必定能够访问受保护的 健康数据并且具有决策和实施功能，例如访问控制引擎、数字权限管理(DRM)客户端等等。 而且，典型地所述正常的医学应用具有凭证(即身份、解密密钥等等)，其使得所述决策和 实施功能准许或不准许对所保护的数据的访问。应当注意，所述可信代理不必需要被部署 在与所述医学应用相同的设备上。所述紧急医学应用是需要对保健数据进行紧急或“加速”的访问的地方。所述紧 急医学应用典型地可以使用受保护的数据，但是它没有准许访问的凭证。随后的步骤处理 这种情况。在步骤(Si) 101中，请求者(即在这种情况下为所述紧急医学应用)发送请求到 所述可信代理，所述可信代理如上所述地拥有或可以使用访问保健数据的解密密钥。所接 收的请求可以包括表示所接收的请求是紧急请求或“加速”访问的请求的数据标记。在步骤(S》103中，所述可信代理生成包括与所述请求或所述请求者或二者相关 的数据的日志。所述日志中所包含的信息可以例如是背景数据(比如进行请求的日期和时 间)、所述请求中所包含的信息(比如所请求数据的类型)、关于请求者的信息(例如用于 医学应用的注册凭证或请求者或正被使用的设备的ID号)、关于所述设备的信息(比如IP 地址)等等。在一个实施例中，所述日志随后被提交到服务器(S3) 105，例如医院中的中央服务器，以供复查。最后，所述请求者被提供对保健数据的访问(S4)107。在一个实施例中，所接收的请求包括请求用于访问保健数据的解密密钥，并且其 中向请求者提供对保健数据的访问的步骤(S4)107是通过将所请求的解密密钥转发给所 述请求者来完成的。因此，所述可信代理不需要解密所接收的请求所源自的所有客户端的 数据，因为解密在所述客户端应用处发生并且避免了瓶颈。在另一个实施例中，从所述请求者接收的请求包括被请求的加密形式的保健数 据，并且向请求者提供对保健数据的访问的步骤包括将解密形式的保健数据转发给请求 者。这允许所述可信代理与不支持数字权限管理和数据解密的传统系统互操作。在这种情 况下，所述加密数据被离线存储在客户端应用处。在一个实施例中，所述请求者是DRM客户端应用或企业权限管理(ERM)客户端应 用，其中许可证包括解密密钥连同用于访问保健数据的相关的许可证规则。所述向DRM或 ERM客户端应用提供对保健数据的访问的步骤可以包括将所述许可证解密密钥连同相关的 许可证规则转发到DRM或ERM客户端应用。这将在稍后更详细地讨论。在一个实施例中，在所述日志的交换过程中获得新密钥。这确保了系统不被对手 “断开”以获得不受限的访问并提供额外的安全，因为所述服务器仅仅在它接收到新鲜的和7可靠地日志信息时才将紧急密钥分发给可信代理。图2图示地描绘了适于处理保健数据并拥有或可以使用用于访问保健数据的可 信代理200、请求者220和服务器210。请求者220包括请求发生器(R_G) 221，该请求发生器(R_G) 221生成用于访问保健 数据的请求223并且进一步适于生成表示所生成的请求223是紧急请求的数据标记222。 所生成的请求223和数据标记222随后经由通信信道224(可以是有线或无线的)而被转 发或传输到可信代理200。可信代理200包括接收器(R) 203、日志发生器(L_G) 202和处理器(P) 201。接收 器(R) 203适于从请求者220接收请求访问保健数据的请求220。日志发生器(L_G) 202适 于生成如先前图1中所讨论的日志204，其包括与所述请求或所述请求者或二者相关的数 据。所述处理器适于处理所接收的请求223。所述处理包括与服务器210进行通信，及通过 例如请求用于访问保健数据的解密密钥来与所述服务器通信。所述处理包括将所请求的解 密密钥转发给请求者或将解密形式的保健数据转发给请求者(参见图1的讨论)。这里所描绘的服务器210经由可以是有线通信信道或无线的通信信道205与可信 代理200通信。服务器210包括用于从可信代理200接收日志204的接收器(R)211和用 于存储所接收的日志的存储器212。存储器212中还存储了保健数据、或用于访问保健数据 的解密密钥、或具有用于访问保健数据的相关许可证规则的许可证解密密钥，或它们的组 合。所述服务器进一步适于操作多个所述可信代理，该操作包括响应于从可信代理接收所 述日志，通过提供所请求的解密密钥向可信代理提供对保健数据的访问。这将在稍后更详 细地讨论。图3示出根据本发明的实施例，其示出本发明可以应用于DICOM(医学数字成像和fflfn )。DRM系统确保了医学信息的端到端机密性并且提供在目的地上的源控制。图 3中所示的用于DICOM文件的DRM系统使用加密消息语法和如在“National Electric Manufacturers Association (NEMA), Digital Imaging and Communications in Medicine (DICOM), part 15 :Security and system management profiles Annex E.I, 2007”中公开的DICOM去标识简档的放宽版本(relaxed version)，所示文献通过引用合并 于此。必须被保护的DICOM文件的属性因此利用内容加密密钥来加密。随后，具有所需的 密钥材料的许可证被嵌入。这是通过使用所述标准提供的工具的方式完成的，因此仍然确 保了向后兼容性。根据安全的观点，该DRM方法是关于数据分发和医学界的不同用户的隐私的控制 的改进。然而，为了使得医学安全解决方案被医疗专业人员接受，必要的是包括紧急访问的 可能性。假设一个针对保健数据(医学数据)的DRM保护的环境，其中使用许可证服务器、 顺从的客户端等。所公布的DRM保护的数据被加密并且许可证服务器向请求用户发行许可 证(包括对所述内容的使用权限)，如果他们具有足够的权限访问所述数据。因此，紧急访 问表示所述系统的正常行为的例外，在这个意义上它难以处理。所述紧急救护提供者应当 优选地被授予用于解码他想要访问的数据的许可证，即使他没有正常的权限访问它。因此， 这种访问的合法性必须稍后被证实以最终确保数据隐私。于是需要紧急访问的记录。
如前所讨论，所述紧急访问控制问题的解决方案是发行紧急许可证并记录这种事 件。这可以通过由许可证服务器210(参见图幻将紧急密钥Kai分发给所有的可信代理 200(参见图幻来完成。由利用KEm加密内容密钥构成的紧急许可证可以嵌有每个新近保 护的保健数据。在紧急访问时，可信代理200记录如前所讨论的事件并利用KEm解密所述数 据，即使所述请求者(例如请求用户)没有从例如许可证服务器获得许可。所述紧急访问控制问题的另一个解决方案是在DRM加密时间不将许可证嵌入到 数据中。然而，当紧急访问时，可以是救护提供者的请求者220经由可信代理200接触适当 的服务器210(例如许可证服务器210)并且请求紧急许可证。许可证服务器210可以实现 可信代理200的特征，及可信代理200的一些或所有特征可以被认为被并入到许可证服务 器210，或者可信代理200和许可证服务器210可以如图2所描绘的那样进行交互。所述事 件由所述许可证服务器记录并且临时许可证被发行。图2所描绘的场景(其中可信代理200负责处理紧急情况以加强数据机密性)可 以与DRM系统并行地部署。这在图4中图示地被描绘，该图4示出了支持紧急访问的增强 型DRM基础设施，其由旧DRM基础设置413和新紧急基础设施400构成。尽管图4示出如何可以增强具有紧急访问的DRM基础设施，但是不应当认为其限 于DIC0M，而是不限于各种系统。所述新紧急基础设施400包括来自图2的所述服务器210 (这里被称为紧急权威 机构(E_A)401)和多个所述可信代理200(这里被称为紧急代理(Ε_Α_Ε1_η) 402-405。所述 紧急权威机构(E_A)401独立于数据创建器(creator)和消费者，并且可以被信任。最后， 它负责证实紧急访问的合法性。所述权威机构操作一些部件以支持该过程。在请求者406请求紧急访问时紧急代理(E_A_El_n) 402-405被请求者406接 触。紧急代理(Ε_Α_Ε1_η)402-405负责准予访问紧急救护提供者并且记录这些事件。它们 例如通过证书被紧急权威机构(E_A)401信任。为此目的，这种部件的顺从性可以在假设 (assume)该信任之前由紧急权威机构(E_A)401 (及对应于所述服务器210)来检查。紧急 代理(E_A_El_n) 402-405(即对应于所述可信代理200)可以安装在部署了 DRM系统413的 医院中。紧急权威机构(E_A)401可以适于生成新紧急密钥对KprivEm(id)和KpubEm(id)。 它优选安全地将私钥KprivEm(id)传输给所有其紧急代理(Ε_Α_Ε1_η) 402-405。一旦紧急 权威机构(E_A) 401确信该新私钥已被成功地分发，则它将对应的公钥KpubEm (id)发送给许 可证服务器(L_S_l-n)409-412，使得它们可以创建用于受保护数据的紧急许可证。由紧急权威机构(E_A)401生成密钥可以遵循不同的策略例如每个医院一个密 钥对、每天一个密钥对等。作为另一个可替代方案，共同的紧急密钥可以在国家水平上用 于所有数据。然而所有这些密钥必须是每个紧急代理(Ε_Α_Ε1_η)402-405已知的，使得 确保数据的可用性，而与紧急访问时所接触的紧急代理或文件无关。重要的是，所述私钥 KprivEffl(id)停留在紧急基础设施的可信环境中。即，基于公开的私钥的包含紧急许可证的 所有DRM保护的数据的机密性是折中的。当通过DRM发布者(Publ. ) 408对原始文件F加密时，紧急许可证LFEm被嵌入在所 得的文件中。它是由负责DRM保护文件的许可证服务器使用其紧急公钥KpubEm(id)的知识 创建的。所得的加密的DRM容器(container)包含加密形式的原始数据。
当诸如紧急救护提供者之类的请求者要求紧急访问已经下载的文件F时，他优选 地接触最近的可用紧急代理(Ε_Α_Ε1_η)402-405。图4中所示的实施例聚焦在DICOM上。因此，所述交换消息被定义为新DICOM紧 急访问服务对象对(SOP)类。一般地，DICOM定义了可以应用于服务对象对(SOP)类中的信息对象定义(IOD)的 服务集。SOP类可以是被标准化的或者是复合的，这依赖于它们是应用于标准化的还是复合 的I0D。标准化的IOD是通常表示真实世界的DICOM模型中单个实体的信息对象定义。复 合的IOD是个信息对象定义，其表示真实世界的DICOM模型中所包含的若干个实体的一部 分。SOAP类由下面的唯一标识符来识别SOP类UID。对于要被描述的SOP类内的服务，首 先有必要为每个参与者分配角色。一方(peer)可以是服务类用户(SCU ；即客户端)或服 务类提供者(SCP 卩服务器)或同时假设两个角色。服务描述还定义了可以应用于所关注 的 IOD 的命令。现有命令类型包括 C-STORE、C-FIND, C-MOVE, C-GET, C-CANCEL 和 C-ECH0。当将命令从一个DICOM节点发送到另一个节点时，该命令包括对SOP类和所述命 令关注的IOD实例的参考，并且可以附加额外的数据集(所述命令的有效载荷)。所述目 的地有可能回答命令执行情况(例如，失败、成功等)还连同可选的附加的有效载荷。当两 个应用(应用实体)想要通信时，它们必须就它们将要使用的服务(SOP类)达成一致。因 此，所述通信建立过程包括被称为关联谈判的所支持的SOP类的谈判。如果通信应用实体 之一不支持SOP类，则所关注的服务不能被使用。为了在DICOM文件中包含策略，加密的属性数据集(S卩，CMS信封)被嵌入在DICOM 文件中。新属性也被引入公开密钥(disclosureKey)。它包括将被用于保护属性的对称 密钥。下面的过程在加密时发生-必须要保护的所有属性被加扰，包括disclosureKey密钥；-创建包含除了disclosureKey的属性的加密版本的CMS信封。它的文本加密密 钥是使用原始的disclosureKey属性的密钥加密的。-当用户请求访问数据时，所述许可证服务器生成新的CMS信封，其与DICOM标准 兼容，包含原始disclosureKey属性。它的文本加密密钥是使用顺从的客户端或用户的公 钥来加密的。当创建新许可证时，散布的(disseminated)DICOM内容不被修改所述许可证可 以只是附加到文件以供稍后使用。所述策略被存储在CMS信封内作为不受保护的属性。因 此，不同的策略可以针对不同的用户进行设置。该解决方案在以下意义下是非常灵活的每 个保护不同属性的信封可以具有不同的策略规范。图5图示地描绘了一种协议其中可以被认为顺从的客户端(C_C)406的请求者 406通过向紧急代理(Ε_Α_Ε1-η) 402-405发送嵌入在F中的紧急许可证(Si，)502来请求对 文件F 501的访问。在DICOM中，这可以被实现为包括紧急许可证的N-ACTION命令。如前 所述，术语紧急代理(Ε_Α_Ε1-η)402-405只是如图2所描绘的可信代理210的实施例。而 且，如前所述，紧急权威机构(E_A)401可以操作一个或多个紧急代理(Ε_Α_Ε1-η) 402-405， 其尤其响应于请求者406的请求执行所述记录操作。再次参照图5中所描绘的协议，在检查请求者406(C_C)确实是顺从的客户端之 后，生成针对请求者(C_C) 406 (S2’)503的日志.紧急权威机构(E_A)401(图5中未示出)使用适当的私钥解密所接收的紧急许可证。在恢复内容密钥之后，使用请求者的公钥构造 新临时许可证，其意图是仅仅被请求者(C_C)406使用。随后，新临时许可证(S3，)504被发送给请求者(C_C)406.在DICOM中，这可以被 实现为包括所述临时许可证的N-EVENT-REP0RT命令，因此所述临时许可证仅仅是如图3所 描绘的DICOM许可证。请求者(C_C)406现在能够通过利用他的私钥解密所述临时许可证来观看文件内 容 F(S4，)505。可能的是，医学界中的各方将使用非顺从的请求者。所述紧急过程应当因此优选 地被调试，使得这些非顺从请求者仍然可以访问紧急上下文中的数据，而不能改变系统的 总体安全。所提出的解决方案提供准许到请求的数据的完全访问。随后，紧急访问的记录甚至更加重要，因为这些请求者可以不受任何限制地公开 所获得的数据。为此，还可优选地包括水印以用于进一步的法庭跟踪。下面的扩展可以用于在正常的操作(即，不必是紧急情况)中为非顺从端(peer) 提供数据访问。图6示出为访问紧急背景中的文件F 501的非顺从客户端(N_C_C)601的请 求者与它的最近的可用紧急代理(Ε_Α_Ε1-η)402-405之间的交换。所述非顺从客户 端(N_C_C)601将文件F连同它的嵌入的紧急许可证(Sl”)602发送到紧急代理(E_A_ El-n)402-405。紧急代理(E_A_En)402-405使用它了解的对所有私有紧急密钥，以便解密 紧急许可证(S2”)603，并且因此恢复内容密钥内容。因此，随后，它可以解密文件F并获得 原始文件。所述紧急访问被记录并且文件F的解密版本被发送(S3”)604到非顺从客户端 (N_C_C) 601，其随后可以自由地访问原始文件(S4 ”)605。为了解释而不是限制的目的，所公开的实施例的某些特定细节被提及，从而提供 对本发明的清楚和透彻的理解。然而，本领域技术人员应当理解，本发明可以在与本文所叙 述的细节不完全一致的其他实施例中实践，而不足以脱离本公开的精神和范围。而且，在该 上下文中并且为了简短和清楚的目的，省略了众所周知的装置、电路和方法的详细描述，以 避免不必要的细节和可能的混淆。权利要求中包含附图标记，然而所包含的附图标记仅仅是为了清楚，不应当被解 释为限制权利要求的范围。
权利要求
1.一种通过拥有或可以使用用于访问保健数据的可信代理来进行保健数据处理的方 法，包括-从请求访问保健数据的请求者(101)接收请求，-生成包括与所述请求或所述请求者或二者相关的数据的日志(10 ，以及-向所述请求者提供对所述保健数据(107)的访问。
2.根据权利要求1的方法，其中所接收的请求包括表示所接收的请求是紧急请求的数 据标记。
3.根据权利要求1的方法，其中从所述请求者接收的请求包括请求用于访问保健数据 的解密密钥，向所述请求者提供对保健数据的访问的步骤将所请求的解密密钥转发给请求者ο
4.根据权利要求1的方法，其中从所述请求者接收的请求包括加密形式的所述请求的 保健数据，向所述请求者提供对保健数据的访问的步骤将解密形式的保健数据转发给所述 请求者。
5.根据权利要求1的方法，其中在接收的请求之后，所述代理从服务器获得加密形式 的保健数据并且对所述保健数据进行解密，向所述请求者提供对保健数据的访问的步骤将 所解密的保健数据转发给所述请求者。
6.根据权利要求1的方法，进一步包括将日志提交给服务器(105)以供复查。
7.根据权利要求1的方法，其中许可证包括解密密钥连同用于访问保健数据的相关许 可证规则，并且其中所述请求者是数字权限管理(DRM)客户端应用或企业权限管理(ERM) 客户端应用，向DRM或ERM客户端应用提供对保健数据的访问的步骤将许可证解密密钥连 同相关的许可证规则转发给DRM或ERM客户端应用。
8.根据权利要求7的方法，其中利用文本密钥保护保健数据，并且其中所述许可证包 括针对受保护的保健数据的利用紧急密钥KEm加密的文本密钥，所述紧急密钥KEm随后被分 发给所有可信代理。
9.根据权利要求8的方法，其中所述许可证被附加到所保护的保健数据。
10.根据权利要求8的方法，其中所述紧急许可证和所保护的保健数据被转发给DRM或 ERM，其中在紧急请求时，所述DRM或ERM进一步被提供适于解密该文件解密密钥的紧急密 钥 KEmo
11.一种计算机程序产品，其用于当该产品在计算机上运行时指令处理单元执行权利 要求1的方法步骤。
12.一种适于处理保健数据的可信代理000)，其中所述可信代理拥有或可以使用用 于访问保健数据的解密密钥，所述可信代理包括-接收器O03)，用于从请求者接收请求访问保健数据的请求，-日志发生器020)，用于生成包括与所述请求或所述请求者或二者有关的数据的日 志，以及-处理器001)，用于处理所接收的请求，所述处理导致向所述请求者提供对保健数据 的访问。
13.—种请求者，包括用于生成访问由如权利要求12中所述的可信代理(200)处理的 保健数据的请求023)的请求发生器021)，其中所述请求发生器进一步适于生成表示所生成的请求(22 是紧急请求的数据标记022)。
14. 一种服务器010)，包括用于从如权利要求12所述的可信代理(200)接收日志 (204)的接收器011)和用于存储所接收的日志的存储器012)，其中所述存储器(21 进一步存储保健数据、或用于访问保健数据的解密密钥、或具 有用于访问保健数据的相关许可证规则的许可证解密密钥，或它们的组合，其中所述服务器(210)适于操作、提供和管理多个所述可信代理000)，所述操作包 括响应于从所述可信代理接收所述日志，通过提供所请求的解密密钥而向所述可信代理 提供对保健数据的访问。
全文摘要
本发明涉及一种通过拥有或可以使用用于访问保健数据的解密密钥的可信代理进行保健数据处理的方法。从请求者接收请求访问保健数据的请求。生成包含与所述请求或所述请求者或二者相关的数据的日志。最后，向所述请求者提供对保健数据的访问。
文档编号G06F19/00GK102057379SQ200980120695
公开日2011年5月11日 申请日期2009年5月29日 优先权日2008年6月4日
发明者J·孔齐, M·佩特科维克, R·P·科斯特 申请人:皇家飞利浦电子股份有限公司