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

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

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.