|
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.
|