Scaleable and Open Framework for Human and Digital Trust between Informal and Formal Infrastructures in Personal Health Care

与任何安全关键行业一样，在医疗保健数据的捕获、存储和使用方面都有强烈的信任要求。这个过程中任何部分的错误都会降低人们对基础设施的信任。不幸的是，许多系统并没有在整个基础设施中辐射访问数据的权利，因此在系统之间传输访问权利时经常存在弱点。保健方面的另一个问题涉及不同领域（例如正规保健基础设施和非正规护理基础设施）之间访问权的整合。虽然在正式基础设施中通常可以有明确定义的访问数据的角色，但很少有非正式护理的角色。该项目的主要目标是创建一个完全集成的基础设施，其中使用身份和角色来定义数据捕获和存储的权限，以及公开给不同域的服务的使用权限，这些域严格使用集成安全策略进行使用。图1概述了基础设施（请参阅附件），其中从患者环境中捕获数据，并使用所需的上下文（例如患者ID、捕获者ID、位置、设备类型、捕获单元等）进行标记。此上下文信息允许以多种不同的方式使用数据，例如跟踪医疗保健环境中的某个设备，或确定一系列患者的血压。然后，使用捕获服务和患者的加密密钥，将该数据以其原始捕获形式存储在患者数据桶中。然后，对桶的访问由安全策略仔细控制，并通过精心管理的服务公开，这些服务需要身份票证来验证使用服务的用户的角色和身份。图1显示了一个EWS（早期预警评分）的例子，它汇总了许多临床评估，如血压和心率。如果用户具有为患者访问服务的正确权限，那么该服务将提供接口的抽象，从而支持广泛的设备，并根据用户的权限定制用户界面。核心基础设施具有高度的安全性和信任度，其中安全策略控制每一个操作，并且将有三个定义良好的开放接口，以允许现有的医疗保健基础设施与电子健康云集成。一旦使用联合信任基础设施验证了身份，就会发出验证身份的票证，然后根据其权限使用票证访问服务。然后在域中仔细管理数据，除了通过仔细管理的服务之外，不能对其进行直接访问。然后使用SPoC（单点接触），如图2所示，使用定义良好的策略来控制域之间的信息流，并且权限基于角色和身份。因此，一个关键的挑战将是将现有的基础设施（如HealthVault）与新的电子健康云整合在一起，同时仍然保持安全权利。这将通过策略转换引擎实现，该引擎将增强的策略定义转换为HealthVault。该系统的一个关键要素是患者模拟代理的集成，它将模拟现实生活中的临床数据，如心率和血压，并定义患者概况，以提供测量参数的可能变化。例如，这将模拟一个病人在给定时间的血压升高，这个病人已经被建模为有心脏骤停的风险。这个模拟器将提供数据来测试一个大规模的基础设施，数以百万计的模拟病人，也将允许医疗保健专业人员和护理人员有机会测试系统，从而建立信任，使用模拟的病人档案。

As with any safety critical industry, there is a strong requirement for trust in the capture, storage and consumption of health care data. Errors in any part of this process can reduce human trust in the infrastructure. Unfortunately many systems do not radiate the rights of access to data throughout the complete infrastructure, and thus there can often be weaknesses in the transfer of rights to access between systems. Another issue in health care relates to the integration of the access rights between differing domains, such as for the formal health care infrastructure, and the informal carer infrastructure. While there can often be well-defined roles for access to data within a formal infrastructure, very little exists for informal care. The key aim of this project is to create a completely integrated infrastructure, where identity and role are used to define the rights to data capture and store, and onto the consumption of the services that are exposed to differing domains, which are strictly consumed using an integrated security policy. Figure 1 outlines the infrastructure (see attachments), where data is captured from the patient environment, and marked up with the required context (such as the patient ID, capturer ID, location, device type, captured units, and so on). This context information allows the data to be used in many different ways, such as tracking a certain device around the health care environment, or to determine the blood pressure for a range of patients. This data is then stored in its original captured form within patient data buckets, using the encryption keys of the capture service and the patient. Access to the buckets is then carefully controlled by a security policy, and is exposed through carefully managed services, which require an identity ticket verifying the role and identity of user consuming the service. Figure 1 shows an example of an EWS (Early Warning Score) which aggregates a number of clinical assessments such as blood pressure and heart rate. The service then, if the user has the correct rights to access the service for the patient, delivers an abstraction of the interface, thus supporting a wide range of devices, and customising the user interface based on the rights of the user. The core infrastructure has high levels of security and trust, where a security policy controls every action, and there will be three well defined, and open, interfaces to allow existing health care infrastructures to integrate with the e-Health Cloud. Once identity has been verified, using a federated trust infrastructure, a ticket is issued which verifies the identity, and is then used to access a service, based on their rights. The data is then carefully managed within a domain and no direct access can be made to it, apart from through carefully managed services. A SPoC (Single Point of Contact), as illustrated in Figure 2 is then used to control the flow of information between domains, using well defined policies, and rights are based on role and identity. A key challenge will thus be in integrating existing infrastructures, such as HealthVault with a new e-Health Cloud, while still perserving security rights. This will be achieved through a policy translation engine, which converts the enhanced policy definition into HealthVault.A key element of the system is the integration of patient simulation agents, that will mimic real-life clinical data, such as for heart rate and blood pressure, and which have defined patient profiles to provide likely changes in measured parameters. For example this would simulate an increase in blood pressure at given times for a patient who has been modelled at being a risk of a cardiac arrest. This simulator will provide the data to test a large scale infrastructure, with millions of simulated patients, and also will allow health care professionals and carers the opportunity to test the system and thus build up trust, using simulated patient profiles.