An Internet of Things Based Multi-Level Privacy-Preserving ... - MDPI

informatics Article

An Internet of Things Based Multi-Level Privacy-Preserving Access Control for Smart Living Usama Salama *, Lina Yao and Hye-young Paik

ID

School of Computer Science and Engineering, University of New South Wales, Sydney, NSW 2052, Australia; [email protected] (L.Y.); [email protected] (H.-y.P.) * Correspondence: [email protected]

Received: 25 January 2018; Accepted: 23 April 2018; Published: 3 May 2018

Abstract: The presence of the Internet of Things (IoT) in healthcare through the use of mobile medical applications and wearable devices allows patients to capture their healthcare data and enables healthcare professionals to be up-to-date with a patient’s status. Ambient Assisted Living (AAL), which is considered as one of the major applications of IoT, is a home environment augmented with embedded ambient sensors to help improve an individual’s quality of life. This domain faces major challenges in providing safety and security when accessing sensitive health data. This paper presents an access control framework for AAL which considers multi-level access and privacy preservation. We focus on two major points: (1) how to use the data collected from ambient sensors and biometric sensors to perform the high-level task of activity recognition; and (2) how to secure the collected private healthcare data via effective access control. We achieve multi-level access control by extending Public Key Infrastructure (PKI) for secure authentication and utilizing Attribute-Based Access Control (ABAC) for authorization. The proposed access control system regulates access to healthcare data by defining policy attributes over healthcare professional groups and data classes classifications. We provide guidelines to classify the data classes and healthcare professional groups and describe security policies to control access to the data classes. Keywords: access control; ambient assisted living; authentication; Internet of Things; IoT

1. Introduction Ambient Assisted Living (AAL) is the system that integrates healthcare devices implemented by wireless technologies, such as Radio Frequency Identification (RFID) and sensor [1], to monitor the patient’s health status in healthcare applications. The emerging paradigm of Internet of Things (IoT) with AAL has been to put personal smart health systems into place. Such systems integrate ambient intelligence into our lives to create a smart environment by responding to people’s locations and behaviours astutely. The most promising applications for AAL are aged care, patient care and independent living for the elderly. Typical health monitoring applications for AAL and smart homes generate electronic health data, forming a rich database for further analytics. The sensor-collected data could be stored as part of the personal health data of patients to improve the service provided by healthcare organizations and to provide health updates to the patient’s family members and friends. To demonstrate the benefits of collecting and storing health monitoring data and daily activity records of elderly patients, let us consider the following scenario which is illustrated in Figure 1.

Informatics 2018, 5, 23; doi:10.3390/informatics5020023

www.mdpi.com/journal/informatics

If an emergency situation arises, such as falling or another heart attack, the hospital will be alerted and so will her son Bob. Paramedics who rush to assist will have access to the necessary online healthcare data to save Mrs. Murphy’s life, hospital staff will also have all the required health and medical information related to Mrs. Murphy and in a short time she will be getting the best possible 2018, treatment. Also, Mrs. Murphy’s family doctor can use his access to the online healthcare Informatics 5, 23 2 of 18 data to follow up on the situation and update Bob when needed.

Figure 1. 1. Motivation Motivation Scenario Scenario of of Assisted Assisted Living Living in in Internet Internet of of Things Things (IoT). (IoT). Figure

Bob usually accesses a secure website a few times a day to scan a check list and find out if his Mrs. Murphy had a heart attack last month and she is now at home. Her son Bob, who is working mother has eaten normally, taken her medication on time and if she was able to manage her daily full time and lives in another city, wants to monitor/know his mother’s health status and be aware activities. Due to the fact that Mrs. Murphy lives alone, Bob has also installed a smart lock so that he of any developments that may occur. He also wants his mother’s health records to be available to will be able to open the door to ambulance officers using the smart home application on his mobile. hospital doctors and staff members who are following his mother’s case, so that he can be updated Although utilizing aggregated healthcare data could help provide the best treatment, detect with expert analysis and feedback from medical practitioners. On the other hand, Bob also wants the early signs of illness and discover new treatments, most of the current AAL platforms and solutions hospital to have access to his mother’s real-time health data, which will ensure that Mrs. Murphy for personal health monitoring and telemedicine are difficult to use due to constant challenges in receives the most efficient assistance from the medical staff in case of any health issues or developments. interoperability, usability, dependability, security and privacy [2]. Security is one of the main urgent Bob has equipped his mother’s house with wearable passive RFID tags and sensors to monitor her needs in AAL, as the life of the patient will be at risk and the right to privacy will be violated if activities and movements. Biometric sensors are also in place to monitor cardiac activities, glucose important and sensitive health data are accessible to irrelevant parties without the patient’s consent. levels, temperature, CO2 levels, brain activity, blood pressure, GSR stress levels and oxygen blood To protect privacy, any access request to data should be justified by providing a clear purpose levels. All the data will be collected and analysed in a real-time manner. The data will also be stored that necessitates a disclosure of the data. Access control is one of the promising solutions for online with other healthcare data and will be available for authenticated and authorized users. If an emergency situation arises, such as falling or another heart attack, the hospital will be alerted and so will her son Bob. Paramedics who rush to assist will have access to the necessary online healthcare data to save Mrs. Murphy’s life, hospital staff will also have all the required health and medical information related to Mrs. Murphy and in a short time she will be getting the best possible treatment. Also, Mrs. Murphy’s family doctor can use his access to the online healthcare data to follow up on the situation and update Bob when needed. Bob usually accesses a secure website a few times a day to scan a check list and find out if his mother has eaten normally, taken her medication on time and if she was able to manage her daily activities. Due to the fact that Mrs. Murphy lives alone, Bob has also installed a smart lock so that he will be able to open the door to ambulance officers using the smart home application on his mobile. Although utilizing aggregated healthcare data could help provide the best treatment, detect early signs of illness and discover new treatments, most of the current AAL platforms and solutions for personal health monitoring and telemedicine are difficult to use due to constant challenges in interoperability, usability, dependability, security and privacy [2]. Security is one of the main urgent

Informatics 2018, 5, 23

3 of 18

needs in AAL, as the life of the patient will be at risk and the right to privacy will be violated if important and sensitive health data are accessible to irrelevant parties without the patient’s consent. To protect privacy, any access request to data should be justified by providing a clear purpose that necessitates a disclosure of the data. Access control is one of the promising solutions for protecting the sensitivity of health data from being compromised and leaked. Access control is about enforcing access rules to ensure that authorized users can access the resources they need to make the best decisions. As the main contribution, in this paper we propose a novel Internet of Things endowed multi-level access control framework to regulate access to sensitive personal health data in order to protect privacy in AAL systems. This framework consists of two main components: the policy model that defines access control policies and the architecture model which defines the implementation of the policies to enforce access on data. In this paper, we presented an IoT based system that provides a care management process to help older people live independently. The system monitors the daily activities of an elderly person and reports any abnormality in their daily routine, as well as, collects and reports any abnormality in their healthcare data which may indicate early signs of health issues. The proposed access control mechanism that was introduced is an attribute-based model which adheres to the dynamic nature of the healthcare organisation and has the flexibility to adapt to new access requirements. Our proposed access control system makes contribution to the adaptable management of data access in AAL systems by addressing the need to have an adequate level of flexibility to regulate access to digital healthcare data stored in the cloud, while considering the dynamic nature of the users who may request access. The required flexibility is demonstrated in the policy model of the proposed system by implementing combinations of more than one rule to grant access in different situations. The system grants proper access levels based on the attributes of people (subject), data (object) and environments. 2. Related Work Since personal health records are often a target for malicious attacks that lead to exposure of this sensitive information, some problems may arise if patients cannot trust that their personal heath record will be secured and only used for the indented purpose. Patients may intentionally hide information or not seek medical help to avoid embarrassment, loss of employment or denial of insurance [3]. A typical privacy protection framework for RFID services addresses the privacy issue during the collection stage by allowing patients to control the access to their personal health information transmitted from RFID tags [4]. The proposed system is based on the following: 1. 2. 3.

A privacy protection system that ensures authorization, confidentially and integrity of the information. An access control mechanism to manage the collected information, personal information and logs by user groups. A provisioning system to secure communication paths, provide auditing capabilities and apply and negotiate privacy policy rules to prevent the collection of personal data without proper authorization.

There are many other solutions focusing on addressing privacy and access control of Electronic Health Records (EHR) using cryptographic and non-cryptographic approaches to preservice information privacy in the cloud [5,6]. The cryptographic techniques encrypt data in the cloud using digital signatures to authenticate users. It also enables patients to provide decryption keys to other users [7]. The security of personally controlled electronic health records (PCEHR) system was proposed by the Australian government to make the health system more agile. The system proposed a cloud-based framework that employs encryption techniques to control access to the cloud database. It also gives the patient control over their heath records by giving them the decryption key of their encrypted health


4 of 18

data [8]. The new model still needs to address emergency access to patients’ health records when a patient is not able to provide the decryption key and how the data could be accessed by different types of users such as physicians, insurers and researchers while protecting the patient’s privacy. Another system secures data on a semi-trusted cloud environment by distributing data across multiple clouds while using attribute-based encryption to protect the privacy of health data [9]. The proposed solution needs huge processing power and memory resources to minimize the processing time. Also, the use of Role Based Access Control model for authorization is not ideal for health data as users having a similar function will have the same access level and there is also a possibility for a user to have multiple roles. The use of a cloud-based healthcare system has been addressed in many papers. The security of health care data using cloud computing was mainly based on secure data collection, secure storage and the implementation of a strong access control system [10]. A security reference model consists of three core components: 1. 2. 3.

Secure collection and integration of electronic health records produced by Care Delivery Organizations (CDOs) and a guarantee that EHR in different formats can be easily integrated. Secure storage and access management by implementing data encryption and access control models based on role-based or attribute-based access control policies. A secure usage model based on signature and verification.

In addition to these core components, authors also suggested using security protocols (e.g., SSL, TLS, IPSec) to encrypt communication between parties. Most of the previous approaches and studies in the cloud solution system for healthcare focus on storing the data securely and allow access to the patient’s sensitive health data on demand. But for the healthcare system, there are different user groups, such as friends, caregivers, researchers and health practitioners. These user groups need to access the healthcare data based on their roles in order to perform their respective duties. 3. Framework Overview In this section, we first overview the structure of the framework, followed by a description of the key components of our proposed solutions. The system is built on a network of sensors deployed in-house; smart devices, sensors fixed in walls and furniture and wearable devices which are all part of an intelligent home monitoring system that runs over the Internet of Things framework. As illustrated in Figure 2, the system is a layered architecture for collecting, managing and sharing healthcare data produced by sensors, smart devices and healthcare professionals. The bottom layer, Data Collection, manages sensors associated with smart and wearable devices, collects healthcare data and sensor signals and processes data streams. As data collection is out of the scope of this paper, interested readers can refer to our previous work for more details [11,12]. The middle layer, Analytics and Data Management, generates and analyses contextual events such as localization and activity reorganization. This layer also processes and aggregates activities and objects used from smart devices’ data feed and collects healthcare data from RFID health monitoring devices. The Contextual and Healthcare Data Processing unit has two main jobs; collecting all data and storing it with the patient’s healthcare data in a secure cloud store and sending the data to the Triggering Engine which will create alerts, based on predefined rules if any of the collected information indicates health risks. The top layer, Security & Access Control, presents our complete solution for the multilevel access control system that starts when the healthcare professional requests access to the patient’s data from the user interface system. The user interface system sends the data request to the authentication server, authorization server, then to the cloud storage. This layer is the main point of this paper and we discuss our proposed solution in more details in Section 6.

Informatics 2018, 5, 23 Informatics 2018, 5, x FOR PEER REVIEW

5 of 18 5 of 17

Figure 2. Framework of Proposed Architecture. Figure 2. Framework of Proposed Architecture.

4. Data Collection Layer 4. Data Collection Layer The use of remote monitoring technology to monitor vital signs provides early indications of The use of remote monitoring technology to monitor vital signs provides early indications of patients’ health problems, thus allowing for more proactive and targeted care. It demands patients’ health problems, thus allowing for more proactive and targeted care. It demands developing developing an IoT solution to electronically record vital signs, calculate warning scores and an IoT solution to electronically record vital signs, calculate warning scores and automatically escalate automatically escalate to raise an alarm with family members and physicians. The system can also to raise an alarm with family members and physicians. The system can also use advanced analytics and use advanced analytics and combine collected data with the latest medical information to alert combine collected data with the latest medical information to alert people to any early signs of risk such people to any early signs of risk such as acute organ failure, stroke or heart attack, based on the data as acute organ failure, stroke or heart attack, based on the data collected and from previous situations. collected and from previous situations. Most of the related work uses analytics techniques applied to medical data to provide insights by Most of the related work uses analytics techniques applied to medical data to provide insights representing the relationship between different health factors. We will briefly demonstrate in Section 5 by representing the relationship between different health factors. We will briefly demonstrate in how some movement disorder diseases could be detected by using the data collected by health sensors Section 5 how some movement disorder diseases could be detected by using the data collected by in an ambient assisted home. Data sources available to the system include; health sensors in an ambient assisted home. Data sources available to the system include; 1.1. 2.

Remotemonitoring monitoringhealthcare healthcaredata datacollected collectedby bysensors. sensors. Remote Electronic healthcare data records, which includes patients’ current health status, medical history and conditions collected from healthcare practitioners and organizations.


2. 3. 4.

6 of 18

Electronic healthcare data records, which includes patients’ current health status, medical history and conditions collected from healthcare practitioners and organizations. Background information such as authenticity, dietary and lifestyle habits collected from the patient or patient’s family. Medical information related to diseases such as early and alarming signs.

Although this is outside the scope of this paper, the use of different analytics techniques to utilize the collected data should be considered for further and more focused research. Our proposed multilevel access control system supports researchers as a group of users who could have access to the healthcare data. The use of an analytics technique such as predictive analytics using statistical modelling could be the best technique to implement a proactive and more targeted care solution to complex health issues. The new healthcare analytics system could use all available medical and clinical datasets as well as up-to-date research results to raise the alarm on patients who are deteriorating, allowing early intervention or giving a new lead to contain outbreaks and find best treatments. On the other hand, using this huge volume of collected healthcare data and the patient’s medical history data could be a time-consuming task for physicians. Using visual analysis to provide physicians with a graph or tabular view of some of these unstructured data sets will save time and save lives. 5. Activity and Data Management Layer In this section, we briefly introduce how the semantic location and activities of daily lives are automatically extracted based on the data feeds from the ambient sensors. We develop a holistic view of smart home management, consolidating the resource and service management all in one place. In particular, we present a layered monitoring architecture based on IoT and cloud, which provides the infrastructure to transparently access sensors, processors and actuators using standardized protocols. The coordination module can automatically wrap up the real-time contextual events (e.g., activities and locations) and expose them as services in the form of RESTful APIs and further represent the APIs. Recently, ambient intelligence in the smart home environment was able to respond to people’s locations and behaviours using sensors and Radio Frequency Identification (RFID). This development introduces many applications in aged care, patient care and surveillance. The main prerequisite for these applications is the ability to locate and track people inside their homes. Most of the RFID techniques that used to locate people require wearing a tag, which is not very convenient for many. A tag-free RFID localization application could be the optimum solution. It is well known that received signal strength indicator (RSSI) is effected by ambient noise interference, physical antenna orientation and fluctuation of the power source. This leads to RSSI to be highly uncertain in a complex environment. The approach presented in [11] for using a passive RFID tag array for posture recognition is based on two general intuitions; RSSI will change when a subject appears in the test area, and, if the subject appears at different locations, the tag’s RSSI will show various fluctuation patterns. The approach senses the environment using a passive tag array and uses machine learning to estimate the location. By using a training data set that contains the RSSI of these passive tags at specific locations along with their correct location label, the approach will estimate the subject’s location for a given new RSSI. The approach addresses localization as a classification problem and uses passive tag array to capture the RSSI changes which then feed to a series of probabilistic approaches. Multivariate Gaussian Mixture Model (GMM) and the expectation Maximization (EM) are used to model the RSSI grid distribution (locations) which was used to locate a single object based on the maximum posterior estimation.


7 of 18

To be able to confirm the subject’s location l we need to find the maximum posterior distribution given the Pr l j , oi sequence of observed sensory value oi . ·

j = argmax Pr (l j , oi ) j

By using the Expectation-Maximization (EM) algorithm and training the model on the training set, the location of the subject is determined by the maximal probability of the subject being located at the location l. To be able to recognize activities, we have developed a Hidden Markov Model (HMM) based model to determine the conditional probability of the captured new sensory streams and determine the activity (e.g., falling on the ground or sitting from standing) [12], giving sensor data observation vector O = {o1 , ..., o T } and a sequence of different postures L = {l1 , ..., lT }, drawn from a predefined finite posture set. The joint probability sequence L and RSSI (Received Signal Strength Indication) sequence O is given by: Pr ( L, O) = Pr (o1:T , l1:T ) T

= ∏t=1 Pr (lt/lt−1 ) Pr (ot/lt ) Using the proposed solution for activity and posture recognition can help in detecting early signs of movement disorder related diseases. Movement disorders are usually detected by excess movements, by the lack of movements, or by rigidity and contraction of muscles. An article by Dr. Mandal, in News Medical Net [13] stated that movement disorders may lead to severe disability and difficulty in having a normal life, which in turn causes a huge impact on society, as patients will not be able to keep gainful employment and may need constant supervision and care. Capturing the early signs of movement disorder offers an opportunity for early diagnosis and early treatment. There are different types of movement disorders; in this section we focus on the symptoms and signs that could be detected by our approach as discussed earlier.

•

•

• •

•

•

Rigidity, which is a resistance to movement. Most affected patients have their neck or leg muscles tense and contracted. When the patient attempts to move s/he may have short and jerky movements called “cog-wheeling”. Akinesia which is slowness of movement, which is considered as one of the classic symptoms of Parkinson’s disease. Patients also may develop a stooped posture, shuffling walk and becomes erratic and unsteady and this may lead to falls. Tremors, which are one of the most common symptoms. They appear in the head, face, or limbs. Tremors may occur during attempting tasks or even at rest. Postural instability which gives patients a stooped posture with bowed head and drooped shoulders. It also affects balance and coordination, which leads to repeated falls with serious injuries as a result. Dyskinesia, which is a series of abnormal movements which manifest as rhythmic or pendulous movements of the arms and legs. It also could be in the form of rapid jerky and purposeless movements of the limbs that appear suddenly. Restless leg syndrome, which is the feeling of bugs over the legs or arms at bedtime or at rest. The feeling is relieved temporarily by movement of the limbs.

The collected data used to recognize human activity can be applied to create a single dictionary for each activity for each person. Assuming we have N predefined types of activities that are stored with other health-related data in the healthcare database for each patient, a new signal strength vector will be matched to an existing movement type. By using data classification and defining a minimum confidence or error margin when matching the new vector against the predefined activities, we would be able to indicate the abnormality of movements and detect any new involuntary movements. The


8 of 18

physician could be alerted for early treatment when the patient starts developing any of the movement disorder related diseases. 6. Access Control Layer As mentioned earlier, the aggregation of medical, health and personal records has introduced new security risks for the patient’s privacy by creating a single access point for all patients’ personal health data. Before discussing security issues for healthcare data, it is important to reference some of the reasons for choosing cloud storage as a solution to accommodate this type of data. The integration of the data feed from healthcare sensors and the patient medical records requires a flexible storage that is scalable enough to facilitate access for a large number of users and data volumes that continuously increase. Cloud computing offers the optimum solution that meets the healthcare system’s requirements for both on-demand storage and processing services. It offers the healthcare domain an affordable easy-to-manage infrastructure that is available anytime and anywhere, that is also highly scalable in order to facilitate the large number of stakeholders and millions of records. But, on the other hand, the issue of outsourcing this sensitive health information to the cloud providers leads to some serious privacy concerns. There are different types of clouds that could be used for the healthcare system. The private cloud is the cloud infrastructure for a private organization that is owned and managed by this organization. In a healthcare scenario, the cloud infrastructure is typically managed by the healthcare organization or a designated third-party and may exist on premise or off premise. The healthcare data stored on the private cloud is considered to be more secure compared to other clouds. On the other hand, a hybrid infrastructure is more common in the healthcare system. Hybrid cloud infrastructure combines private and public clouds to support the healthcare organization with limited physical resources to store health data. But, on the other hand, a hybrid infrastructure requires more security measures to preserve privacy requirements [14]. The aggregation of medical, health and personal records has introduced new security risks for patient privacy by creating a single access point for all patients’ personal health data. Generally, a patient’s health records may contain sensitive information in relation to sexual health, addictions, mental health, etc. All such digital information will last indefinitely and once released onto a cloud and accessed by remote users, can never recover its purely private status, which makes privacy of health data a big concern. Also, such a system must be available online when needed and must be only accessible by authorized personnel. Therefore, it is essential to have new access control policies and mechanisms that are suited for such systems. Privacy risks can arise from health professionals who can unintentionally cause disclosure of health data. Also, this information could be leaked for revenge, profit, or other ill purposes by system operators or healthcare workers. Risks from the inadvertent or intentional release of information concerning infections, mental health, chronic disease diagnoses and genetic information are all well recognized both online and in the mass media. In this paper, we are proposing a multilevel access control system that manages access granted to different users such as physicians, nurses, family members and other health practitioners or researchers based on their need to know. 6.1. Privacy Requirements In the healthcare environment, there are many different parties who need access to the healthcare data; 1. 2. 3.

Healthcare organizations such as hospitals, laboratories and imaging centres. Healthcare professionals such as family doctors. Patients who should have full read access to the complete health records.


4.

9 of 18

Any family member or a friend who the patients want to grant access to his/her data.

To ease illustration, we will use “owner” to denote the patient or patient’s guardian in our system as in some circumstances the patient may not be capable of managing his/her own health records due to age or illness reasons. The following are the identified requirements for healthcare data online access: 1. 2. 3. 4. 5. 6. 7. 8. 9.

10.

Each healthcare unit should have the ability to determine the type/classification of the data it produces. Owner should have the ability to grant or deny access to sensitive or private healthcare data to particular medical practitioners, healthcare unit or a family member. Owner should identify a family doctor who will have access to all data classes. Family doctor should be able to review healthcare data classification. There must be an emergency attribute which allows the available healthcare practitioner to have access and to be able to provide assistance immediately. Access could be granted to a team or a class of health professionals. Owner should have the ability to delegate access to the healthcare data to someone else if required. No-one should be able to overwrite old information but healthcare units and physicians should have the ability to add corrections to old information/reports. Permission could be conditional to a given period of time or location. As an example, all access requests from a particular hospital are authenticated during the patient’s admission time, bearing in mind the provided access level is determined by access policies. Healthcare data should be available without obstruction to legitimate users and security policies should be easy to manage, maintain and modify once there is a need.

The core of the proposed access control system includes users’ attributes that describe their association and roles and the classification of users’ personal health data. The classification forms several data classes such as physical health, mental health and private health-related information. The roles of users will be treated as the class of users. For example, GP is a class of all GPs, while a class specialist includes all different specialists who need to access the healthcare data. Besides health practitioners, owner can add a list of friends and family members as the “friend” class. The proposed system also considers the circumstances when this information is requested. Special access will be granted in emergencies and temporary access will be granted for a specific period of time if the patient is away from home. The access control policies simply regulate viewing access and addition of new data to healthcare records. Changing and deleting existing records is not allowed in order to preserve the healthcare and medical data history. Policies are not associated with individual records but with a collection of records that belong to a specific healthcare data class. There is no concept of a hierarchy of classes, so issues around policy inheritance are not relevant to the system described. The healthcare professional requesting access to a patient’s data must have a valid certificate. The process of getting access to patient healthcare data starts at the workstation which is connected to an authentication server. Authentication servers validate the healthcare professional’s digital certificate, the patient’s ID, then authenticate the healthcare professional and forward the access request to the authorization server. The authorization server checks access control policies for the patient and grants the proper access level to the healthcare professional. Policies are held by at the authorization server. This is not necessarily the same place the healthcare data itself is located but is similar to the authentication server. The actual evaluation of the policies is handled as an external service which is based on the rules and attributes supplied to evaluation. FIDO (Fast IDentity Online) can be implemented to provide the authentication part of the proposed system. FIDO Alliance developed two protocols, the Universal Authentication Framework (UAF) and the Universal Second Factor (U2F). The authentication process uses public key cryptography and nonces to demonstrate possession of the private key. For the subject to be authenticated, the corresponding public key has to be registered with the server, which happens during an initial registration step [15].


10 of 18

In this paper we are going to focus on the authorization part of the access control for the healthcare system, as there are many successful implementations of the authentication process. Table 1 summarises some different healthcare data access control systems. Table 1. Comparison of different healthcare data access control systems. Microsoft Vault

Default access

User chooses who has access to what information

PKB Everyone in patient’s health network

NASH

Proposed System

Any healthcare professional authorised by a healthcare organisation

Minimum set of data that is required in life threatening situations

Patient can specify what data to share

Patient can share their own copy or give consent

Patient can choose which healthcare organisations have access to their data

Using subject and object classifications to grant access considering environment factors

Environment factors

Use time limited access

Nothing mentioned in relation to environment but consent engine can provide temporary access when required

Nothing mentioned in relation to environment factors when granting access to system users

Utilise environment factors such as date, time and location. Other factors could be added

Sharing

Co-manage health record of another user.

Patient can share their own copy of their health data or give consent

Using consent

Using policy model or adding someone to a group

Flexibility to add more control

No available information published in relation to the system design to indicate how the system handles new requirements



New classes can be added to subjects or objects. New environment factors can also be added.

Granularity

There are attempts to use metadata to control access to medical records. In this particular case metadata associated with the patient, medical images and health professionals is considered as attributes that are used to control access in this medical imaging project grid. Semantic Access Control for Medical Application in Grid Environments [16] shows how metadata could be used to provide an efficient access control system to medical records using a set of connected computing elements and data storage on distant sites to provide a share of resources and storage capacity. The paper also introduced Semantic Access Certificates (SAC) as a way to authenticate users to medical data on the grid environments. Also, many systems have been developed to allow patients to bring together all their medical records from multiple providers including lab results, doctor’s notes and health background. These systems regulate the health practitioner’s access by providing patients with full control to authorize any person to access his/her own health record. Patients Know Best (PKB) is a system that allows the patient to access healthcare data from all of connected professionals and organizations whenever they need it. It also allows patients to share with whoever they trust. The system has the ability to gain all of the medical data, connect wearable


11 of 18

activity devices and communicate with health networks to track signs and symptoms in a safe and secure way that is approved by the US National Health Services NHS [17]. Privacy and security characteristics of Patients Know Best include:

• • • •

All healthcare data is consolidated in one record and controlled by the patient and available to everyone in patient’s health network Patients can use privacy labels for each source of data and give privacy label permissions to different teams. Patients can see which teams have access to which privacy labels. Patients can share their own copy of healthcare data.

Another similar system is the Microsoft Health Vault, which provides a trusted place for people to gather, store, use and share health information online which is also approved by NHS. Privacy and security characteristics of Microsoft Health Vault include:

• • • •

HealthVault user can share access with another healthVault user Patients can allow HealthVault programs to access and manage their data. Patients can share specific healthcare data with other people or programs that add data to health records HealthVault user can manage health records of a family member.

The Australian government, through the National Authentication Service for Health (NASH) project provides a nationwide secure and authenticated service for health organizations and personnel [18]. NASH provides healthcare professionals with access to electronic health data using a smartcard with a Public Key Infrastructure (PKI) certificate. Healthcare professionals can use their smart card and PIN to be authenticated from any workstation and to be able to send and receive digitally signed messages, prescriptions, hospital admission, hospital discharge and reports. NASH grants health professionals access to healthcare data through the use of a PKI certificate located in the smart card they have been provided with after registering. The PKI certificate is an electronic document that includes information about the certificate’s owner (subject) public key, the certificate’s owner identity and a list of additional attributes (certificate extensions) and the digital signature of the Certification Authority (CA) that verified the information on the certificate. Even though NASH is a national authentication service it easily can be used globally, by using cross certification to establish a trust relationship between the PKI certificates’ issuers. Cross certifying health professionals will authenticate them and allow them to access patient’s health records based on their attributes. Privacy and security characteristics of NASH include:

• • • • • •

Logging login issues such as multiple failed logins and multiple login within a short period. Logging high transaction rates for a given Healthcare Provider Logging after-hours access and all instances of emergency access. Setting a Record Access Code (RAC) to allow and prevent access to patient’s record unless in an emergency Flagging specific documents in patient’s record as ‘limited access,’ and controlling who can view them. Removing documents from view and requesting healthcare providers to not upload information to the healthcare records.

6.2. Our Multi-Level Access Control Model The proposed system is based on the Attribute-Based Access Control (ABAC) as it grants proper access level based on the attributes of people, data and environments. The system consists of two main components: the policy model that defines access control policies and the architecture model which defines the implementation of the policies to enforce access on data.


12 of 18

6.2.1. Attribute Definitions Our model uses resource attributes, subject attributes and environmental attributes, as well as attributes extracted from the subject’s PKI certificate. We also added attributes to resources that classify healthcare data to give more access control such as “physical health”, “mental health” and “private”.

•

Resource Attributes A resource is an entity that is acted upon by the subject, such as the healthcare records. Resources have attributes that can help group them in records such as medications, medical history, or immunization. We defined six different classes that group healthcare data records. Public: The public class contains all healthcare data that is not sensitive such as; 1. 2.

3.

Health and activity data collected from sensors which may include; blood pressure, sugar levels, oxygen levels and any alarming information. Patient instructions, which is one of the most important fields that healthcare professionals need to view before dealing with the patient. It may contain warnings such as; the patient suffers from severe autism and could act out aggressively under pressure or wearing gloves and report any direct contact with the patient, as the patient could be vulnerable to infection or have an infectious disease. The public class could also contain allergies, medications, health maintenance schedules and lifestyle habits such as smoking, drinking and exercise.

Physical: Physical classes contain all medical history related to diagnoses, laboratory and radiology results and all procedures that a patient has had or was scheduled for. Id_ info: ID info class contains all patients’ identifying data such as name, address, emergency contact and ID. Mental: Mental health class contains the information related to mental diseases such as depression, bipolar, autism and personality disorders. Neuro: Neurological health class contains medical history of any nervous system related to issues that may cause some mental disorder symptoms such as Alzheimer’s disease, stroke and injuries to the nervous system.

•

Private: Private classes contain information that the patient does not want to share with anyone unless it is related to their treatment. Private healthcare data could include sexual orientation, history of drug use or social history. Subject Attributes: A subject is an entity requesting access, in our system s/he could be the healthcare professional, insurance agent, or a researcher. Each subject/user has associated attributes which define his identity such as; name, ID, job title and organization. Our system classifies users into the following groups: Owner: The owner of the healthcare data is the patient or patient’s guardian. Owners should have access to all data classes. Family_doctor: A family doctor is the patient’s primary doctor who is aware of the patient’s health issues and history. Family doctors should have access to all data classes. Friend: A friend is a person who is nominated by the owner to have access to the patient’s healthcare data. By default, the friend group should have access to all data classes except the Private class. GP: A GP is a doctor who temporarily treats patients due to the unavailability of the family doctor. GP should have access to Public, Physical, Id_info and Neuro data classes.


13 of 18

Researcher: A researcher uses the data to research new treatments, medicines or statistical purposes. We assume the research is on physical health and the researcher should have access to Public, Physical and Neuro data classes. A new rule should be added to the policy model for different research areas. The researcher must not have access to the identifying information (Id_info) which reveals the patient’s identity. Insurance: Insurance companies need access for claims or policy requirements. Insurance companies could have access to Public, Physical, Id_info and Neuro data classes. Paramedics: Paramedics are trained to provide basic life support in short time frames. We assumed in our system that Public and Id_info should be sufficient for paramedic officers to perform their job. Hospital: Hospitals should have access to all data classes except Private data class for each patient admitted. Hospital clinics should have the same access as GP groups. Allied health: Allied health contains many professionals such as audiologists, dieticians, physiotherapists, occupational therapists, psychologists and social workers. The nature of these professions varies from providing purely physical treatments to purely mental treatments. On the other hand, occupational therapists assist people with illnesses and disabilities to develop and maintain daily living, or assist patients with mental health disorders such as autism. Based on these considerations, we decided to divide the allied health group into the following three subgroups: 1.

2.

3.

•

Allied_mental: This group includes professionals such as psychologists and social workers. Professions of this group should have access to Public, Id_info, Mental, Neuro and Private data classes. Allied_physical: This group includes professionals such as chiropractors, physiotherapists and podiatrists. Professions of this group should have access to Public, Id_info, Physical and Neurological data classes. Allied_both: This group includes all allied health professionals who may deal with mental or physical disorders such as occupational therapists and speech pathologists. For this group, we set an environmental attribute “Require Social” to indicate if this patient has any mental disorder. The “Require Social” attribute allows the professionals of this group to have access to “Mental” data class in addition to the “Allied health physical” group access.

Environment Attributes: Environmental attributes describe the operational and technical conditions that affect access, such as the date and time when hospital staff can have access to patients’ records. Environmental attributes also include location; owner could allow all requests from hospital workstations while he is admitted to hospital. We include other environment attributes such as Emergency, location, date and Require_social.

6.2.2. Policy Model Our policy model uses “u”, “hd”, “e” to denote authenticated user group, healthcare data class and environment respectively and functions to confirm user and healthcare data attributes. Our system assumes the owner of the healthcare data is the patient or the patient’s guardian if the patient is not able to manage his/her own records for age or illness reasons. The general form of the policy rule that decides whether a user u can access healthcare records hd in a particular environment e is the following Boolean function. Rule: can_access (u, hd, e) ← ƒ (Attr (u), Attr (hd), Attr (e))

6.2.2. Policy Model data 6.2.2. Policy Model classes. data classes. Professions of this group have access to Public, Id_info, Mental, Neuro and Private and environment respectively functions to and healthcare and environment data attributes. respectively Our and function Our policyand model uses “u”, “hd”, “e”user todata denote authenticated group, healthcare data class and environment respectively and functions to confirm confirm user and healthcare datauser attributes. Our licy model uses “u”, “hd”, “e” should to denote authenticated user group, healthcare class del data classes. 2.model Allied_physical: This group includes professionals such as chiropractors, physiotherapists 2. system Allied_physical: This group includes professionals such as chiropractors, physiotherapists assumes the owner of the healthcare is the patient or patient’s system guardian assumes ifif the patient owner the healthcare and environment respectively and functions tothe confirm user and dataofattributes. Our d Our policy uses “u”, “hd”, “e” todata denote authenticated user group, healthcare data class system assumes the owner of the healthcare data isdata the patient or the patient’s guardian the patient nment respectively and functions to confirm user and healthcare attributes. Our Our policy model uses “u”, “hd”, “e” to denote authenticated user group, healthcare data classhealthcare and podiatrists. Professions of this group should have access to Public, Id_info, Physical and podiatrists. Professions of this group should have access to Public, Id_info, Physical 2. Allied_physical: This group includes professionals such as chiropractors, physiotherapists is able manage his/her own records for age or illness reasons. is not or able manage guardian his/her records fo system assumes the owner of the healthcare data is the patient theto patient’s if the patient and environment respectively and functions toguardian confirm and healthcare data attributes. Our own is not not able to manage his/her own records for age or illness reasons. mesand theuses owner the healthcare data is the patient or the patient’s ifuser the patient environment respectively and functions to confirm user and healthcare data attributes. Our model “u”,of“hd”, “e” toto denote authenticated user group, healthcare data class and Neurological data classes. and Neurological data classes. and his/her podiatrists. Professions of this group should have access to Public, Physical The general form the that decides whether aOur user uuillness can The healthcare general form records of the policy rule that is not able topolicy manage his/her own records forId_info, orpatient’s reasons. system assumes the owner of the healthcare data is the the patient or the guardian if the patient The general form of the policy rule that decides whether aage user can access healthcare records o manage own records for age or of illness reasons. system assumes the owner of the healthcare data isrule the patient or patient’s guardian if access the patient nt respectively and functions to confirm user and healthcare data attributes. 3. Allied_both: This group includes all health who deal mental 3.manage Allied_both: group includes all allied health whoprofessionals may mental and Neurological classes. Informatics 2018, 5,This 23 14 ofwith 18 hd in particular environment eage the following Boolean function. hddeal in a with particular e is the follow The general ofcan the policy rule that decides whether user u may can environment access healthcare records is able to manage his/her own records for age orprofessionals illness reasons. hdnot in adata arule particular environment eais isform the following Boolean function. neral form policy that decides whether user u access healthcare records not able to his/her own records for or illness reasons. the is owner of the healthcare data is the patient or the patient’s guardian if allied the patient or physical disorders such as occupational therapists and speech pathologists. For this or physical disorders such as occupational therapists and speech pathologists. For this 3. Allied_both: This group includes all allied health professionals who may deal with mental inrule a particular environment is the Boolean general form of the policy rulewhether that decides whether a user u can function. access healthcare records cularhis/her environment e form isThe thefor following Boolean function. The general of the that decides ae user ufollowing can access healthcare records nage own records agepolicy orhd illness reasons. Rule: can_access (u, hd, e) ƒƒ (Attr (u), Attr Attr Rule: can_access (u, Rule: can_access (u, hd,speech e) ← ←Social” (Attr (u), Attr (hd), (hd), Attr (e)) has ifany group, we set an environmental attribute “Require Social” to (e)) indicate this patient has any group, we set an environmental attribute “Require to indicate if this patient disorders such aseenvironment occupational therapists and pathologists. For this hd in athat particular e is the following Boolean function. hdorof inphysical a particular environment is the following Boolean function. form the policy rule decides whether a user u can access healthcare records Rule: (u, hd, e) ← ƒ (Attr (u), (hd),toAttr (e)) Rule: can_access (u, hd, e) ← ƒ (Attr (u), Attr Attr (e)) According to this rule, user u Social” will be(hd), granted access to healthcare records hd if Attr the attributes u, mental disorder. The Social” attribute allows the professionals of of this mental disorder. The “Require attribute allows professionals of this group, we an environmental attribute “Require Social” tocan_access indicate if this patient has any According to rule, user uu will be granted access to healthcare records According hd ififgroup the to this rule, of user u to will be gr According to this this rule, user will be“Require granted access tothe healthcare records hd the attributes attributes of group r environment eset is the following Boolean function. Rule: can_access (u, hd, e) ← ƒ (Attr (u), Attr (hd), Attr (e)) Rule: can_access (u, hd, e) ← ƒ (Attr (u), Attr (hd), Attr (e)) attribute of hd and attribute of e is evaluated by the function f and returned true. have access to “Mental” data class in addition to the “Allied health physical” group access. have access to “Mental” data class in addition to the “Allied health physical” group access. mental disorder. The “Require Social” attribute allows the professionals of this group to u, attribute hd and attribute of ee is by ff and returned u,toattribute true and13attribute e is evaluat According this rule, user u the will beattributes granted access healthcare records hd if the of attributes of u, attribute of hd andaccess attribute ofto is evaluated evaluated by function and returned true.. of hd ing to this rule, user u will 2018, beof granted to healthcare records hd if function the of 2018, 5, x FOR PEER REVIEW Informatics 5,e) x FOR REVIEW Informatics 2018,Attr 5, x FOR PEER REVIEW 13 of 17 of 17 Rule: can_access (u, hd, ← ƒPEER (Attr (u), Attr (hd), (e)) access toof “Mental” data class in addition to theattribute “Allied health physical” group access. u, attribute of hd and of e is evaluated by the function f and returned true . According to this rule, user u will be granted access to healthcare records hd if the attributes of of hd have andAccording attribute e is evaluated by the function f and returned true . to this rule, user u will be granted access to healthcare records hd if the attributes of • Attributes: Environment Environmental attributes describe the operational • Environment Environmental attributes describe the operational and technical R1: can_access (u, hd, hd, e) e)Attributes: ← ((group ((group (u) єє {Paramedics}) {Paramedics}) (data_class (hd) {Public, Id_info})) ••• • (hd) R1: (u, ← (u) ٨٨ (data_class є є {Public, can_access Id_info})) (u,and hd, technical e) ← ((group (u) R1: can_access ((group (u) {Public, attribute of hd and attribute of e is evaluated by the function f and returned true . u, attribute of hd and attribute of e is evaluated by the function f and returned true . oEnvironment this rule, userconditions uu, will be granted access to healthcare records hd if the attributes of Allied_mental: This group 1. includes Allied_mental: professionals This group such 1. includes as Allied_mental: psychologists professionals This and group such social includes as workers. psychologists professionals and social such workers. as psychologists socia conditions that affect access, such as the date and time when hospital staff can have that affect access, such as the date and time when hospital staff can have access to Attributes: Environmental attributes describe the operational and technical (u) (hd)

((group Physical, Neuro})) (u) {Owner, R1: can_access (u, hd, e) ←(hd) (u) є {Paramedics}) (data_class (hd) n_access (u, hd, e) ← ((group (u) є• {Paramedics}) ٨ (data_class (data_class (hd) є{Public, {Public, Id_info})) ٧٧((group (u) є{Researcher}) ٨٨ (data_class єє {Public, Physical, Neuro})) ٧٨((group ٧٧((group (u) є {Researcher}) (u) ٨toand (data_cl ((group (u) є {Researcher}) {Researcher}) (data_class (hd) {Public, Physical, Neuro})) ((group (u)є є{Public, є access Id_info})) dconditions and attribute of e is evaluated by the function f and returned true . Professions of this group should Professions have access of this to group Public, should Professions Id_info, have Mental, access of this to Neuro group Public, and should Id_info, Private have Mental, access Neuro to Public, and Id_info, Private Mental, Neuro patients’ records. attributes also include location; owner could allow all requests patients’ records. Environmental attributes also could allow requests that affect access, the when staff can have to Family_doctor})) (u)

time {Insurance}) (data_class (hd)

(u) Physical, Neuro, Id_info})) • R1: can_access (u, hd, e)and ← ((group (u) єhospital ٨owner (data_class (hd) {Public, Id_info})) • є R1: can_access (u, hd,such e) ←as(hd) ((group (u) є(u) {Paramedics}) (data_class є{Public, {Public, Id_info})) {Owner, Family_doctor})) {Owner, Family_doctor})) ٧Environmental єє٨{Paramedics}) {Insurance}) ٨٨(hd) (data_class (hd) єєall {Public, Physical, ٧((group ٧((group ((group є {Researcher}) ٨ location; (data_class (hd) є {Public, Physical, Neuro})) ٧((group (u) (u єa {Owner, Family_doctor})) ٧((group (u)include {Insurance}) (data_class {Public, Physical, p (u) {Researcher}) ٨ (data_class єdate {Public, Physical, Neuro})) ٧((group єaccess data classes. data classes. from workstations while isєcould admitted to{Public, hospital. include other from while he admitted to hospital. We include other environment patients’ records. Environmental attributes also include location; owner allow all requests ((group (u) {Friend})

є Physical, Id_info, Mental})) Id_info})) Neuro, Id_info})) ٧٧((group (u) єis {Friend}) ٨٨{Public, (data_class (hd) єPhysical, Physical, Neuro, Id_info, ٧environment (u)Physical, є {Friend (u,classes. hd, e) ← ((group (u)data єworkstations {Paramedics}) ٨ (data_class (data_class (hd) {Public, Id_info})) {Owner, ٧he ((group (u) є Neuro, ٨We (data_class (hd) є((group ٧Neuro, ((group (u) {Researcher}) ٨(hd) (hd) {Public, Neuro})) ((group (u) є{Public, Id_info})) ((group (u) є(data_class {Friend}) (data_class (hd) є{Insurance}) {Public, Physical, Neuro, Id_info, r,ess Family_doctor})) ٧hospital ((group (u) є є{Insurance}) ٨Family_doctor})) (data_class (hd) єPhysical, {Public, Physical, ٧((group (u) єNeuro, {Researcher}) ٨hospital (data_class є(hd) {Public, Neuro})) ٧((group (u) є٧ 2. 2. Allied_physical: This group Allied_physical: includes professionals This group such includes Allied_physical: as chiropractors, professionals This physiotherapists group such includes as chiropractors, professionals physiotherapists such as chiropractors, physi attributes such as and attributes asFamily_doctor})) Emergency, location, date and from hospital workstations while admitted to include other environment Mental})) Mental})) Mental})) Neuro, Id_info})) ٧((group (u) є date {Friend}) ٨Require_social. (hd) {Public,Physical, Physical, Neuro, Id_info, {Owner, ((group (u) location, єRequire_social. {Insurance}) ٨(hd) (data_class (hd) є є{Public, ٧((group є such {Friend}) ٨٧he (data_class (hd) є hospital. {Public, Physical, Neuro, Id_info, {Owner, Family_doctor})) ((group (u) є٧Emergency, {Insurance}) ٨We (data_class є {Public, Physical, u)Id_info})) є {Researcher}) ٨ (u) (data_class (hd) є is {Public, Physical, Neuro})) ٧((group (u) є(data_class In R1, there are no environment constraints as they are irrelevant for this rule and there are five and podiatrists. Professions and of podiatrists. this group should Professions have and of access this podiatrists. group to Public, should Professions Id_info, have Physical access of this to group Public, should Id_info, have Physical access to Public, Id_inf attributes such ٧as Emergency, location, date Require_social. })) Neuro, ٧{Friend}) ((group (u) є {Friend}) (hd) є {Public, Physical, Neuro, Id_info, Neuro, Id_info})) ٧((group (u) єMental})) ٨ (data_class є {Public, Physical, Neuro, Id_info, mily_doctor})) ((group (u) єId_info})) {Insurance}) ٨and (data_class (hd) (hd) є٨ (data_class {Public, Physical, In R1, there are no environment constraints as they are irrelevant for In R1, and there there areare nofive environment constra In R1, there are no environment constraints asgranted theydata areaccess. irrelevant for this this rule rule and there are five cases under which the authenticated user u will be and Neurological data classes. and Neurological data classes. and Neurological classes. 6.2.2. Policy Model 6.2.2. Policy Model Mental})) Mental})) nfo})) ٧((group (u) є {Friend}) ٨ (data_class (hd) є {Public, Physical, Neuro, Id_info, cases under which the authenticated user u will be granted access. cases under which the authenticated user uww In R1, there are no environment constraints as they are irrelevant for this rule there are five cases under which the authenticated user u will be granted access. here are no environment constraints as they are irrelevant for this rule and there are five 3. This group3. includes Allied_both: all allied Thishealth groupprofessionals includes Allied_both: all allied whoThis may health group deal professionals with includes mental allwho allied may health dealprofessionals with mentaland who may deal . Allied_both: Policy Model Our policy model uses “u”, “hd”, “e” to denote authenticated user group, healthcare data class Our policy model uses “u”, “hd”, “e” to denote authenticated user group, healthcare data class Informatics 2018, 5, x FOR PEER REVIEW 13 of 17 Case1: if u belongs to the “Paramedics” group and requests access to healthcare data from the “Public” cases under which authenticated user will be R1, there are environment constraints asdisorders they areuthis irrelevant for thisaccess. rule and there are five which the user uphysical will beno granted access. In authenticated R1,disorders there areInsuch no environment constraints asthe they arespeech irrelevant for rule and there are five or physical as occupational therapists such or asand physical occupational pathologists. therapists such For and asgranted occupational this speech pathologists. therapists For and this speech pathologist Case1: ifif and uor belongs to the group and requests access to Case1: healthcare if u data belongs from to the “Paramedics” g Case1: u“hd”, belongs todisorders the “Paramedics” “Paramedics” group and requests access to healthcare data from the environment respectively and functions tohealthcare confirm user and healthcare data attributes. Our and environment respectively and functions to confirm user and healthcare data attributes. Our Our policy model uses “u”, “e” to denote authenticated user group, data class or “Id_info” classes. cases under which the authenticated user u will be granted access. cases under which the authenticated user u will be granted access. are no environment constraints as they are irrelevant for this rule and there are five group, we set an environmental group, attribute we set an “Require environmental Social” group, to attribute indicate we set “Require an if this environmental patient Social” has to any attribute indicate if “Require this patient Social” has to any indicate if this patie or “Id_info” classes. “Id_info” Case1: ifto ugroup belongs the “Paramedics” and requests access toorhealthcare data from the “Public” or “Id_info” classes. belongs tosystem therespectively “Paramedics” group and requests access to healthcare from theguardian system assumes the owner oftothe healthcare data isgroup the patient orOur the data patient’s guardian if theclasses. patient assumes owner of healthcare data is the patient ordata the patient’s if“Public” the patient environment and functions confirm user and healthcare data attributes. 1. “Public” This includes professionals such as psychologists and social ch the authenticated user uAllied_mental: will be granted access. Case2: ifthe u belongs to the the “Researcher” group and requests access tothe healthcare from theworkers. “Public”, mental disorder. The “Require mental Social” disorder. attribute The “Require allows mental the Social” professionals disorder. attribute The of allows “Require thisaccess group Social” professionals toCase2: attribute ofdata this allows group thethe professionals to “Researcher” of thi Case2: “Researcher” group and requests to healthcare if u belongs from to the gr “Public” or “Id_info” classes. Case1: if u belongs to the “Paramedics” group and requests Case2: if u belongs to the “Researcher” access to healthcare data from the lic” or “Id_info” classes. Case1: if u belongs to the “Paramedics” group and requests access to healthcare data from the ishealthcare nothis/her ableor toown manage own records for or illness reasons. is the not owner able toof manage records for age or illness reasons. em assumes the data is thehis/her patient or the patient’s guardian if the patient Professions of this group should have access toage Public, Id_info, Mental, Neuro and Private “Physical”, “Neuro” classes. have access to “Mental” data have class access in addition to if “Mental” to theaccess data “Allied have class access health in addition to physical” “Mental” to the group “Allied data access. class health in addition physical” to the group “Allied access. health physical” gro “Public”, “Physical”, or “Neuro” classes. “Public”, “Physical”, or “Neuro” clas Case2: u belongs to the “Researcher” group and requests access to healthcare data from the “Public” or “Id_info” classes. “Public”, “Physical”, or “Neuro” classes. belongs to the “Researcher” group and requests to healthcare data from the “Public” or “Id_info” classes. ngs to the “Paramedics” group and requests access to healthcare data from the The general form of the policy rule that adecides user u can access healthcare records The general of the policy rule that decides whether user u whether can access healthcare records ot able to manage his/her own records for age“Owner” or illness reasons. data classes. Case3: ifuuform ubelongs belongs to the or “Family_doctor” groups, access isagranted. granted. Case3: if to the “Owner” or “Family_doctor” groups, access is Case3: if u belongs to the “Owner” or “Fami Case3: if belongs to the “Owner” or “Family_doctor” groups, is granted. “Public”, “Physical”, or “Neuro” classes. Case2: u belongs to the “Researcher” group and requests access to healthcare data from the lic”, “Physical”, or “Neuro” classes. Case2: if u belongs to the “Researcher” group and requests access to healthcare data from the or “Id_info” classes. ironment Attributes: •of the Environmental Attributes: attributes •group Environmental describe Environment the operational Attributes: attributes describe and Environmental technical the operational attributes and describe technical the operational and hd inrule a particular is the following function. hd in a particular environment e is environment the following function. The general form policy that decides whether aeBoolean user u can accessBoolean healthcare records 2.Environment Allied_physical: This includes professionals such as chiropractors, physiotherapists Case4: if u belongs to the “Insurance” groups and and requests access to healthcare data from the “Public”, Case4: if u belongs to the “Insurance” groups requests access to Case4: healthcare if u data belongs from to the the “Insurance” gro Case3: if u belongs to the “Owner” or “Family_doctor” groups, access is granted. Case4: if u belongs to the “Insurance” groups and requests access to healthcare data from the elongs to the “Owner” or “Family_doctor” groups, access is granted. “Public”, “Physical”, or “Neuro” classes. “Public”, “Physical”, or “Neuro” classes. ngs to the “Researcher” group and requests access to healthcare data from the ditions that affect access, conditions such as the that date affect and access, timeconditions such when ashospital the that date affect staff andcan access, time have when such access hospital as the to Public, date staff and cantime have when access hospital to staff can hav n a particular environment e is podiatrists. the following Boolean function. and Professions of this group should have access to Id_info, Physical “Physical”, “Neuro”, or 5, “Id_info” Rule: can_access (u, hd, e) ← ƒ (Attr (u), Attr (e)) Rule: can_access (u, hd, e)classes. ← ƒ (Attr (u), Attr (hd), Attr (e))Attr (hd), Informatics 2018, 5, classes. xclasses. FOR PEER REVIEW Informatics 2018, xaccess FOR PEER REVIEW 13the of 1 “Public”, “Physical”, “Neuro”, or “Id_info” “Public”, “Physical”, “Neuro”, or “Id Case4: if u belongs to the “Insurance” groups and requests access to healthcare data from Case3: if u belongs to the “Owner” or “Family_doctor” groups, access is granted. “Public”, “Physical”, “Neuro”, or “Id_info” belongs to the “Insurance” groups and requests to healthcare data from the Case3: if u belongs to the “Owner” or “Family_doctor” groups, access is granted. “Physical”, or “Neuro” classes. ents’ records. Environmental patients’ records.also Environmental include patients’ location; attributes records. owner also could Environmental include allowlocation; all requests attributes owneralso could include allow location; all requests owner could allow a andattributes Neurological data classes. Rule: can_access (u, hd, e) ← ƒ (Attr (u), Attr (hd), Attr (e)) Case5: if u belongs to the “Friend” group and s/he requests access to healthcare data from the Informatics 2018, 5,u xwill FOR PEER REVIEW 13 of 17group Case5: if u belongs to the “Friend” group and s/he requests access to Case5: if u belongs to “Friend” “Public”, “Physical”, “Neuro”, or “Id_info” classes. Case4: to the “Insurance” groups and requests access to healthcare data from the Case5: if u belongs “Friend” group and s/he requests access to healthcare data from the lic”, “Physical”, “Neuro”, or “Id_info” classes. Case4: if u belongs to the “Insurance” groups and requests access to healthcare data from the gs to the “Owner” or “Family_doctor” groups, access is granted. According to this rule, user u will be granted access to healthcare records hd if the attributes of According to this rule, user be granted access to healthcare records hd if the attributes of m hospital workstations while hospital he is admitted workstations to includes hospital. from whilehospital he We is admitted include workstations other toprofessionals hospital. environment while he Wewho isinclude admitted to with hospital. environment We include other en 3.from Allied_both: This group all allied health may other deal mental “Public”, “Physical”, “Neuro”, “Id_info”, orclasses. “Mental” classes. 1. Allied_mental: This group includes professionals such and as psychologists 1.or Allied_mental: This group includes professionals such as psychologists social workers “Id_info”, or “Mental” classes. “Public”, “Physical”, “Id_in Case5: ifrequests belongs to the “Friend” group and s/he requests access to healthcare data from thea “Public”, “Physical”, or “Id_info” “Public”, “Physical”, “Neuro”, “Id_info”, or “Mental” classes. belongs tou, the “Friend” group and s/he access to healthcare data from the “Public”, “Physical”, “Neuro”, “Id_info” classes. ngs tosuch the “Insurance” groups and requests access to healthcare data the u, attribute ofand hd and attribute of esuch is function evaluated by ifthe function f and returned true . this “Neuro”, attribute ofattributes hd and attribute of eu is“Neuro”, evaluated by the f from and returned true . of According to this rule, user uphysical will be granted access to healthcare records hd the attributes ibutes as Emergency, location, such date as Emergency, Require_social. attributes location, date as and Emergency, Require_social. location, date and Require_social. or disorders such as occupational therapists and speech pathologists. For Professions of healthcare this group should havethe access Public, Id_info, Mental, Professions of this group should have access to Id_info, Mental, and Privat 1.classes. Allied_mental: This group includes professionals such asPublic, psychologists and social workers. “Public”, “Physical”, “Neuro”, “Id_info”, or “Mental” classes. Case5: if“Id_info”, u ebelongs the group and s/he requests to healthcare data to from the Neuro lic”, “Physical”, “Neuro”, orto “Mental” classes. Case5: if“Neuro”, u belongs the group and s/he requests access to data from “Physical”, or to “Id_info” tribute of hd and of is“Friend” evaluated by“Friend” the f(u) and returned true . access we set an environmental attribute “Require Social” to(hd) indicate ifR2: thiscan_access patient has any •attribute R2: can_access (u, hd, e) ← ((group єє ٨٨ (data_class єє є(data_class • {Public, Physical, Neuro, (u, hd,and e) ← ((group (u R2:group, can_access (u, hd, e) ← ((group (u) {GP}) ٨have {Public, •• can_access e) ←function ((group (u)

{GP}) (data_class (hd) Physical, Neuro, • R1: can_access (u, hd, e) ← ((group (u) є {Paramedics}) ٨ (hd) є {Public, Id_info})) • R1: (u, hd, e) ← ((group (u) є {Paramedics}) {Public, Id_info})) data classes. data classes. Professions of this group should access to Public, Id_info, Mental, Neuro Private “Public”, “Physical”, “Neuro”, “Id_info”, or “Mental” classes. “Physical”, “Neuro”, “Id_info”, or to “Mental” classes. ngs Model to the“Public”, “Friend” group and s/he requests access healthcare data from the licy Policy Model 6.2.2. Policy Model mental The “Require attribute allows professionals of this to Physical, R2: can_access (u, hd, e) ((group (u) {GP}) ٨ (data_class (hd) n_access (u, hd,٧(u, e)6.2.2. ← ((group (u) є•((group {GP}) (data_class (hd) єThis {Public, Physical, Id_info})) ٧((group (u) є{Researcher}) ٨٨٨(data_class єєNeuro, (Public, Physical, Neuro, ٧єgroup ((group Id_info, є(u) {Hospital}) Id_info})) ٧disorder. ((group є {Hospital}) {Hospital}) (data_class (hd) (Public, Physical, Neuro, Id_info, ((group (u)

Allied_physical: (data_class (hd)

(hd) (Public, Physical, Neuro, Id_info, Mental))) R1: can_access hd,“Id_info”, e)(u) ← є((group (u) є٨ {Paramedics}) ٨Social” (data_class (hd) є(hd) {Public, Id_info})) ٧or (u) є{Hospital}) (data_class єthe {Public, Physical, Neuro})) ٧((group є Neuro, ٨ ((group {Researcher}) ٨(u) (data_class (hd) є← {Public, Physical, Neuro})) ٧Id_info})) ((group (u) є{Public, 2. Allied_physical: This group includes professionals such(u) as chiropractors 2. group includes professionals such as chiropractors, physiotherapist data classes. “Physical”, “Neuro”, “Mental” classes. have access to “Mental” data class in addition to the “Allied health physical” group access. Mental))) Mental))) • є“u”, R2: can_access (u, hd, e) ←є ((group є є{GP}) ٨Neuro, (data_class (hd) є {Public, Physical, Neuro, Mental))) •٧ ((group R2:(u)can_access (u, hd,٨“e” e) ← ((group (u) {GP}) ٨ {Insurance}) (data_class (hd) є this {Public, Physical, Neuro, Id_info})) ((group (u) {Hospital}) ٨“hd”, (data_class (hd) єhealthcare (Public, Neuro, Id_info, })) (u) {Hospital}) ٨{Owner, (data_class (hd) єOur (Public, Physical, Id_info, model Our “hd”, policy model to denote uses authenticated “u”, “hd”, policy user to model group, denote uses healthcare authenticated “e” user class to group, denote authenticated data user class Family_doctor})) ٧(u) ((group (u) є“u”, {Insurance}) ٨should (data_class (hd)should єPhysical, {Public, Physical, {Owner, Family_doctor})) ٧((group (u) є“e” ٨Neuro})) (data_class (hd) є(u) {Public, Physical, ٧policy ((group єuses {Researcher}) (data_class (hd) є٧podiatrists. {Public, Physical, ٧data ((group єthis and podiatrists. Professions of group havegroup, accesshealthcare to Public and Professions of group have access to Public, Id_info, Physica 2. Allied_physical: This group includes professionals such as chiropractors, physiotherapists In R2: there are also no environment constraints for this rule and there are two cases where the Mental))) ))) cess (u, hd, e) ← ((group (u) є {GP}) ٨ (data_class (hd) є {Public, Physical, Neuro, Id_info})) ٧ ((group (u) є {Hospital}) ٨ (data_class (hd) є (Public, Physical, Neuro, Id_info, Id_info})) ٧ ((group (u) є {Hospital}) ٨ (data_class (hd) є (Public, Physical, Neuro, Id_info, ironment respectively environment and functions respectively to confirm and and user environment functions and healthcare respectively to confirm data attributes. user and and functions healthcare Our to confirm data attributes. user and Our healthcare data attri Neuro, Id_info})) ٧ ((group (u) є {Friend}) ٨ (data_class (hd) є {Public, Physical, Neuro, Id_info, Neuro, Id_info})) ٧ ((group (u) є {Friend}) ٨ (data_class (hd) є {Public, Physical, Neuro, Id_info, {Owner, Family_doctor})) ٧ ((group (u) є {Insurance}) ٨ (hd) є {Public, Physical, • andEnvironment Attributes: Environmental attributes describe the operational and technical and Neurological data classes. and Neurological data classes. and podiatrists. Professions of this group should have access to Public, Id_info, Physical In Intwo R2: cases there where are also the no environment co In R2: R2: there there are are also also no no environment environment constraints constraints for for this this rule rule and and there there are are two cases where the authenticated user u owner will beof granted access. Mental))) Mental))) ((group (u) єMental})) {Hospital}) ٨ (data_class (hd) є (Public, Physical, Neuro, Id_info, ssumes the owner system of the healthcare assumes the data is the system patient the healthcare assumes or the patient’s data the owner is guardian the patient of the if healthcare or the the patient patient’s data is guardian the patient if the or patient the patient’s guardian if Mental})) Neuro, Id_info})) ٧ ((group (u) є {Friend}) ٨ (data_class (hd) є {Public, Physical, Neuro, Id_info, conditions that uaffect access, such as the date time when hospital staff have access tobecases 3. Allied_both: This allcan allied health professionals who may Allied_both: This group includes allgroup allied health professionals who may deal with menta and Neurological data authenticated user be granted access. authenticated user uare will granted access. In3. R2: there areand also noclasses. environment constraints for this rule and there two where the authenticated user u will will bethis granted access. here are also no environment constraints for rule there are and two cases where theincludes le to manage his/her is not own able records to manage for age his/her or illness is own not reasons. able records to manage for age or his/her illness own reasons. records for age or illness reasons. Mental})) patients’ records. Environmental also include location; owner could allow all requests or physical disorders such asand occupational therapists and speech or physical disorders as occupational and speech pathologists. For pat thi 3. Allied_both: This group includes all allied health professionals who may deal with authenticated user uattributes will be granted access. Inalso R2: there are noare environment constraints for this rule and there are two cases where the d user uIn will access. R2:bethere are environment constraints for this rule and there are two cases where the Case1: ifare uno belongs to the “GP” group and requests access to healthcare data from “Public”, Inenvironment R1, also there no environment constraints as they are irrelevant for this rule and there aremental five Ingranted R1, there no constraints as they aresuch irrelevant for this ruletherapists there arethe five general form of the policy The general rule that form decides of the whether policy The a rule general user that u can decides form access of whether the healthcare policy a user rule records that u can decides access whether healthcare a user records u can access healthca from hospital workstations while he is admitted to hospital. We include other environment group, we set an environmental attribute “Require Social” to indicate if t group, we set an environmental attribute “Require Social” to indicate if this patient has an or physical disorders such as occupational therapists and speech pathologists. For this authenticated ufor will beas granted access. authenticated user u will be granted access. areR1, also no environment constraints this rule and there are two where thethereaccess. “Physical”, “Neuro” or “Id_info” classes. cases under which the authenticated user u will be and granted cases which theuser authenticated user u will be granted access. In there are under no environment constraints they are irrelevant forcases this rule are five articular environment hd in e a is particular the following environment Boolean hd function. in e is a the particular following environment Boolean function. e is the following Boolean function. attributes such Emergency, date and Require_social. mental disorder. The “Require Social” attribute allows the professiona mental disorder. The “Require Social” attribute allows the professionals ofhas this group t group, we setlocation, an environmental attribute “Require Social” to indicate if“Public”, this patient any u willwhich be granted access. serunder theCase2: authenticated userasuto will granted access. if u belongs the be “Hospital” group and requests access to healthcare data from the Case1: if u“Paramedics” belongs to access the “Paramedics” group and requests access to healthcare data from theto access Case1: if u belongs to the group and requests access to healthcare data from theto the have access to “Mental” data class in addition “Allied health have to “Mental” data class in addition to the “Allied health physical” group mental disorder. The “Require Social” attribute allows the professionals of this group Rule: can_access (u, hd, e) Rule: ← ƒ “Id_info” (Attr can_access (u), or Attr (u, (hd), hd, Attr e) classes. ←Rule: (e)) ƒ (Attr can_access Attr (u, (hd), hd,Attr e) ← (e)) ƒ (Attr (u), Attr (hd), Attr (e)) phys “Physical”, “Neuro”, “Mental” We(u), included “Mental” as the patient may “Public” or “Id_info” classes. “Public” or Model “Id_info” classes. e1: if u belongs 6.2.2. to thePolicy “Paramedics” group and requests access to healthcare data from the have access for to “Mental” data class in addition to the “Allied health physical” group access. be admitted to Environment hospital period of time and the hospital staff should be aware ofdescribe any •a “Researcher” Environment Environmental attributes the Attributes: Environmental attributes describe technica ording to this According uclasses. will be to rule, access user According healthcare will be granted to records this access rule, hd Attributes: ifuser to the healthcare uattributes will be granted records ofaccess access hdtoiffrom the tothe attributes healthcare of records hdoperatio if the a Case2: if•this u“Researcher” belongs to u the group and requests healthcare data fromand the Case2: if user u belongs to granted the group and requests access to healthcare data theoperational “Public” or rule, “Id_info” Our policy model uses “u”,Attributes: “hd”, “e” toEnvironmental denote authenticated userand group, healthcare data class mental care that patient may require. conditions that affect access, such as the date and time when hospital conditions that affect access, such as the date time when hospital staff can have access • Environment attributes describe the operational and technical ute and attribute u,the attribute of“Researcher” e is evaluated of hd“Public”, andgroup by attribute the function u, attribute ofrequests e is fevaluated and of hd returned and by attribute the true function is f and evaluated returned by true the function f and returned true . of e data . . stafft “Physical”, or “Neuro” “Public”, “Physical”, or “Neuro” classes. e2: of if hd u belongs to and access toclasses. healthcare from the and environmentconditions respectively and functions to confirm user and healthcare data attributes. Our patients’ records. Environmental attributes alsostaff include location; owner could patients’ records. Environmental attributes also location; owner could allto request that affect access, such as theaccess date and timeinclude when hospital can haveallow access Case3: u(u, belongs the “Owner” or “Family_doctor” groups, access is granted. Case3: if• u belongs to theif“Owner” orto “Family_doctor” groups, is granted. “Public”, “Physical”, or can_access “Neuro” classes. R3: hd, R2 Date) (Current date ≥ 01022017) (Current • e) ← R1: •← R1: can_access (u, hd, ((group can_access (u) є (u, {Paramedics}) hd, e) ← ((group ٨ ((environment(e) (data_class can_access (u) {Paramedics}) (u, (hd) hd, є=workstations {Public, e) he ← ٨is ((group (data_class Id_info})) (u) єto(hd) {Paramedics}) єowner {Public, ٨Id_info})) (data_class (hd) є {Publico system assumes the owner ofe)the healthcare dataєhospital is thewhile patient or the patient’s guardian ifWe the patient from while he is admitted to hospital. We include from hospital workstations admitted hospital. include other environmen patients’ records. Environmental attributes also include location; could allow all requests Case4: if u“Insurance” belongs to groups, the “Insurance” groups and to requests access to from healthcare Case4: if u“Owner” belongs to “Family_doctor” the groups and requests access healthcare data the data from the e3: if u belongs to the or access is granted. data < 01032017)) roup (u) є {Researcher}) ٧((group ٨ to (data_class (u) є his/her {Researcher}) (hd) єown {Public, ٧such ((group ٨ (data_class Physical, (u) є or Neuro})) (hd) {Researcher}) єisas {Public, ٧Emergency, ((group ٨date (data_class Physical, (u) є Neuro})) (hd) є include {Public, ٧((group Physical, (u) environment є Neuro})) ٧((gr is not able manage records for age illness reasons. attributes such location, date and Require_social. attributes as Emergency, location, and Require_social. from hospital workstations while he admitted to hospital. We other “Public”, “Physical”, “Neuro”, orto“Id_info” classes. “Public”, “Physical”, “Neuro”, “Id_info” classes. e4: if u belongs to the “Insurance” groups andorrequests access healthcare data from the wner, Family_doctor})) {Owner, {Owner, Family_doctor})) ٧((group (u) є {Insurance}) ٧ ((group ٨ (data_class (u) є (hd) {Insurance}) є {Public, ٧ ٨ ((group (data_class Physical, (u) є (hd) {Insurance}) є {Public, ٨ (data_class Physical, (hd) є {Public The generalFamily_doctor})) form of the policy rule that decides whether a user u can access healthcare records attributes such Emergency, location, date and Require_social. if follow u“Friend” belongs toasthe “Friend” group s/he requests access to from healthcare Case5: if u belongs the group and s/he requests access to healthcare data thethe data “Public”, “Physical”, or “Id_info” classes. In“Neuro”, R3,Case5: wetojust the access rule R2 and add anand extra level of access control, that is, date from the uro, Id_info})) ٧((group Neuro, Id_info})) Neuro, Id_info})) (u) є {Friend}) ٨ (data_class ٧ ((group (u) (hd) є {Friend}) є {Public, ٨ (data_class Physical, ٧ ((group Neuro, (hd) (u) є є {Friend}) Id_info, {Public, ٨ Physical, (data_class Neuro, (hd) Id_info, є {Public, Physical, Neur hd in a particular environment is the6.2.2. following PolicyBoolean Model function. 6.2.2. PolicyeModel “Public”, “Neuro”, “Id_info”, or “Mental” classes. “Public”, “Physical”, “Neuro”, “Id_info”, or “Mental” classes. e5: if u belongs to the a“Friend” group and“Physical”, s/he requests access to healthcare data from the that the healthcare when GP or hospital staff requests access. The date is an environment attribute ntal})) Mental})) 6.2.2. Policy Model Mental})) “Public”, “Physical”, “Neuro”, “Id_info”, “Mental” classes. Rule: can_access (u, hd, e) ←“hd”, ƒ to (Attr (u), (hd), (e)) Our policy model uses “u”, “hd”, “e” to The denote authenticated user group, he Ourorpolicy model uses “u”, to Attr denote authenticated user group, healthcare data clas data owner specifies to limit access to patients’ records a“e” certain period ofAttr time. specified dates • (u, R2: can_access (u, hd, ((group (u) є {GP}) (hd) є {Public, • R2: can_access hd, e) ← ((group (u)e)є ← {GP}) ٨ (data_class (hd)٨ є(data_class {Public, Physical, Neuro, Physical, Neuro, R1, there are no environment constraints thereOur are noasenvironment environment they are In irrelevant R1, constraints there for arethis no as rule they environment and are irrelevant there constraints are five for thisuser asrule they and are there irrelevant are five for this rule th and environment respectively and functions to confirm user and healthcare da and respectively and functions to confirm and data attributes. policy model uses “u”, “hd”, “e” denote authenticated user group, healthcare data classandOu couldInbeR1, hospital admission and discharge dates or theto time where the family doctor ishealthcare unavailable. R2: can_accessId_info})) (u, hd, e)٧←((group ((group (u) {GP}) (data_class (hd)access є {Public, Physical, Neuro, Id_info})) ((group (u) {Hospital}) ٨(data_class (hd) є (Public, Physical, Neuro, (u) єє٧{Hospital}) ٨(data_class (hd) єto(Public, Physical, Neuro, Id_info, According to this rule, user u٨ will be єgranted healthcare records hd if the attributes of Id_info, der which the authenticated cases under user which u will the be authenticated granted cases access. under user which u will the be authenticated granted access. user u will be granted access. system assumes thethe owner of the healthcare data is the patient or the patient’s gua system assumes the owner of the for healthcare data the or the patient’s ifOur the patien and grants environment respectively and functions to confirm userpatient and2017. healthcare data guardian attributes. The rule simply access as in rule R2 but only month ofisFebruary Mental))) Id_info})) ٧ ((group (u) є of {Hospital}) ٨(data_class є (Public, Id_info,true. u, attribute hdMental))) and attribute of e is(hd) evaluated by thePhysical, function Neuro, f and returned is not able to manage his/her own records for age or illness reasons. is not able to manage his/her own records for age or illness reasons. system assumes the owner of the healthcare data is the patient or the patient’s guardian if the patient u belongs to theCase1: “Paramedics” if u belongs group to and the Case1: “Paramedics” requestsif access u belongs group to healthcare toand therequests “Paramedics” data access from the group to healthcare and requests data from access theto healthcare data Mental))) • R1: R4:can_access can_access (u, hd, e)general ← ((group (u) {GP, Hospital}) (e)

є{Emergency})) In R2: there are also no environment constraints for this rule and there two access casesa where In• R2: there are no environment constraints for this rule and there arereasons. two cases where the (u, hd, e) ← єgeneral {Paramedics}) ٨(environment (data_class (hd) {Public, The form of the policy rule that whether user u the can access The form of the policy rule that decides whether adecides userare u Id_info})) can healthcare record is also not able to manage his/her own for age or illness Public” or “Id_info” classes. “Public” or “Id_info” classes. “Public” orrecords “Id_info” classes. authenticated user u will be granted access. authenticated user u (u) willThe granted access. In R2: there are also no environment constraints for this rule and there are two cases where the ٧((group єbe {Researcher}) ٨ (data_class (hd) є {Public, Physical, Neuro})) ٧ ((group (u) є agroup particular environment eBoolean isthe the following Boolean function. hdgeneral inand athe particular environment eand is the following function. form ofhd the that decides whether ahealthcare user u can accessfrom healthcare records data f u belongs to theCase2: “Researcher” if uwebelongs group to requests Case2: “Researcher” access uinpolicy belongs to rule healthcare to the requests “Researcher” datarule access from group toaccess and requests data access theto healthcare R4, have Emergency an if environment attribute. This gives all healthcare data enticated user u will {Owner, beIngranted access. Family_doctor})) ٧as((group (u)e is є the {Insurance}) ٨ Boolean (data_class (hd) єto{Public, Physical, hd in a particular environment following function. Public”, “Physical”, or “Neuro” “Public”, classes. “Physical”, “Neuro” “Public”, classes. “Physical”, or “Neuro” Rule: can_access (u,(u), hd,Attr e) ←(hd), ƒ (Attr can_access (u, hd,owner e)classes. ← ƒin(Attr Attr(u), (e))Attr (hd), Attr (e classes to doctors or hospitalsor a result of aRule: preapproval emergencies. Emergency Neuro, Id_info})) ٧((groupas(u) є {Friend}) ٨ (data_classfrom (hd)the є {Public, Physical, Neuro, Id_info, u belongs to the “Owner” Case3: if or u belongs “Family_doctor” to the “Owner” Case3: groups, if or access u “Family_doctor” belongs is granted. to the “Owner” groups, or access “Family_doctor” is (u), granted. groups, access is granted. Rule: can_access (u,doctor, hd, e) which ← ƒ (Attr Attr (hd), Attr (e)) situations should be defined by a physician or the family may include poisoning, suicidal Mental})) According to this rule, user u will be granted access to healthcare recordsdata hdo According to this rule, user u will be granted access to healthcare records hd the attributes f u belongs to the Case4: “Insurance” if or u unconsciousness. belongs groupstoand the requests Case4: “Insurance” if access u belongs groups to healthcare to and therequests “Insurance” data access from groups the to healthcare and requests data from access thetoif healthcare attempts, u, attribute ofof hd attribute ofto e is evaluatedfrecords by the function f and u, attribute of hd and attribute e and is evaluated by the function and returned true . returned According to“Neuro”, this rule, user u“Physical”, will be granted access healthcare hd if the attributes of tru Public”, “Physical”, “Neuro”, “Public”, or “Id_info” “Physical”, classes. “Public”, or “Id_info” classes. or “Id_info” In R1, there are no environment constraints as they are“Neuro”, irrelevant for this ruleclasses. and there are five u, attribute of hd and attribute of e is evaluated by the function f and returned true . •Case5: R5:ifcan_access (u, hd,can_access e) ← ((group (u)can_access

be {Allied_physical, Allied_both}) (hd)the u belongs to the “Friend” uwhich group belongs to s/he the Case5: “Friend” requests if u group belongs to and healthcare to s/he therequests “Friend” data from group the toand healthcare s/he requests data from access to{Public, healthcare data cases under the authenticated user u will granted access. • access R1: (u, hd, ← ((group (u) {Paramedics}) ٨ є (data_class (hd) є •and R1: (u, hd, e) ← ((group (u) e) єaccess {Paramedics}) ٨ є(data_class Id_info}) {Public, Physical, Neuro, Id_info})) ((group (u)

є(data_class {Allied_mental}) (hd) (Public, Public”, “Physical”, “Neuro”, “Public”, “Physical”, or “Mental” “Neuro”, classes. “Public”, “Physical”, or(u) “Mental” “Neuro”, classes. “Id_info”, or “Mental” •“Id_info”, R1: can_access (u, e) ((group є {Paramedics}) (data_class (hd)classes. {Public, Id_info})) ٧← ((group {Researcher}) ٨ (data_class (hd) є є{Public, Physical, Neuro ٧((group (u)hd, є “Id_info”, {Researcher}) ٨(u) (hd) є٨(data_class {Public, Physical, Neuro})) ٧((group (u) Case1: if u belongs to the “Paramedics” group and requests access to healthcare data from the Mental, Neuro, Id_info, Private))) {Owner, Family_doctor})) ٧((group (u) є٨ Physical, {Insurance}) ٨((group (data_class є {Owner, Family_doctor})) ٧((group (u)((group єє Neuro, {Insurance}) ٨ (data_class (hd) є {Public, ٧((group (u) є←{Researcher}) (hd) {Public, Physical, Neuro})) ٧ (u) Physica є(hd) can_access (u, hd,• e) ← R2: ((group can_access є(u, {GP}) hd, ٨classes. •e)(data_class R2: ((group can_access (hd) (u)٨єє (data_class {Public, {GP}) (u, hd, ٨ (data_class e) Physical, ← (hd) (u)є є{Public, {GP}) (data_class Neuro, (hd) є {Public, Physic “Public” or(u) “Id_info” Neuro, Id_info})) ٧є{Insurance}) ((group (u) є٨٨{Friend}) (hd) є Physical, {Public, Physic Neuro, Id_info})) ٧((group (u)(u) є(u) {Friend}) (data_class (hd)٨є(data_class {Public, Physical, Neuro, Id_info Family_doctor})) ٧٧٨((group є(hd) (data_class (hd) єєId_info, {Public, Physical, nfo})) ٧ ((groupCase2: Id_info})) (u) єId_info})) ٧{Owner, ٨((group (data_class (u) (hd) є {Hospital}) є (Public, (data_class ((group Physical, Neuro, {Hospital}) є ٨(Public, Id_info, (data_class Physical, Neuro, (hd) Neur if{Hospital}) u belongs to the “Researcher” group and requests access to healthcare data from(Public, the Mental})) Mental})) Neuro, Id_info})) ٧ ((group (u) є {Friend}) ٨ (data_class (hd) є {Public, Physical, Neuro, Id_info, ntal))) Mental))) Mental))) “Public”, “Physical”, or “Neuro” classes. Mental})) Case3: if u belongs to theIn “Owner” orare “Family_doctor” groups, accessasisthey granted. Inenvironment R1, there no environment constraints as they are irrelevant fortwo this rule R1, there are for this rule andare there are fiv R2: there are also no environment In R2: thereconstraints are also no for environment this Inrule R2: no and there constraints there are also areare two no forconstraints environment this cases rule where and constraints the there areirrelevant two forcases this rule where and the there cases Case4: if u belongs to there the “Insurance” groups and requests access to healthcare data fromand the cases under which the authenticated user u will be granted access. cases under which the authenticated user u will be granted access. In R1, are no environment constraints as they are irrelevant for this rule there are five cated user u will be authenticated granted access. user u will be authenticated granted access. user u will be granted access. “Public”, “Physical”, “Neuro”, or “Id_info”user classes. cases under which the authenticated u will be granted access.

m hospital workstations from he is admitted totherapists hospital. while We heinclude is admitted other to environment hospital. We include environment group, we set workstations an environmental attribute “Require Social” to indicate if this other patient has any or physical disorderswhile such ashospital occupational and speech pathologists. For this butes suchwe as set Emergency, location, attributes date such and as“Require Require_social. Emergency, location, date and Require_social. mental attribute disorder. The “Require Social” attribute allows of this group to group, an environmental Social” to indicate if this patientthe hasprofessionals any have access to “Mental” data class addition to the “Allied health mental disorder. The “Require Social” attribute allows thein professionals of this group to physical” group access. icyhave Model 6.2.2. data Policy Model access to “Mental” class in addition to the “Allied health physical” group access. • Environment Attributes: Environmental attributes describe the operational and technical policy modelAttributes: usesInformatics “u”,conditions “hd”, Our“e” denote model authenticated uses “u”, “hd”, user “e” group, tooperational denote healthcare authenticated data class user group, healthcare data class 2018, 5,policy 23to 15 of 18 that affect access, such as the date and time when hospital staff can have access to nvironment Environmental attributes describe the and technical ronment respectively and and environment functions to respectively confirm user and and functions healthcare to data confirm attributes. user and Our healthcare data attributes. patients’ Environmental attributes alsostaff include owner onditions that affect access, suchrecords. as the date and time when hospital can location; have access to could allow all requestsOur ssumes records. the owner of the system healthcare assumes data the isalso owner the patient of the or healthcare thehepatient’s data guardian is the patient if the or the patient’s guardian if the patient from hospital workstations while isowner admitted toallow hospital. We include other environment atients’ Environmental attributes include location; could allpatient requests Innot R5, there are also no environment constraints for this rule and there are two cases where the e to manage his/her own is records able to for manage age or illness his/her reasons. own records for age or illness reasons. attributes Emergency, location,We dateinclude and Require_social. om hospital workstations while such he is as admitted to hospital. other environment authenticated userdecides u will bewhether general form of Emergency, the policy The rule general that form ofgranted the policy aaccess. user rule u can thataccess decides healthcare whether records a user u can access healthcare records tributes such as location, date and Require_social. articular environment hd e Policy isinthe a particular following Boolean function. e is the following Boolean function. 6.2.2. Model toenvironment Case1: if u belongs the “Allied_physical” or “Allied_both” groups and requests access healthcare Policy Model data from the “Public”, “Physical,” “Neuro,” or “Id_info” classes. Rule: can_access (u,model hd, e)uses ← ƒ “u”, Rule: (Attr (u), can_access Attr Attr hd, e) (e)) ← ƒ (Attr (u), Attrgroup, (hd), Attr (e)) data class Our policy “hd”, “e” (hd), to (u, denote authenticated user healthcare and“u”, environment respectively and functions to confirm user and healthcare data attributes. ur policy model uses “e” to denote authenticated user group, data class Case2: if“hd”, u belongs to the “Allied_mental” group andhealthcare requests access to healthcare data from Our the ording to this rule, user u will According be granted to this access rule,touser healthcare u will be records granted hdaccess if the attributes to healthcare of records hd if the attributes of systemand assumes the owner of“Neuro”, the healthcare dataor is “Mental” the data patient or the patient’s nvironment respectively functions to confirm user “Id_info” and healthcare attributes. Our guardian if the patient “Public”, “Physical”, classes. ute of hd and attribute u, of attribute e is evaluated of hdby and the attribute functionoff eand is evaluated returned true by the . function f and returned true. is of notthe able to manage his/her records age or illness reasons. m assumes the owner healthcare data is theown patient or thefor patient’s guardian if the patient • e) ← can_access hd, e)hd, ← R5← ((environment(e) = {Public, Location)

{L})) •R6: R1: can_access (u, hd, ((group can_access (u)form є(u, {Paramedics}) e) ٨reasons. (data_class ((group (u)(hd) є {Paramedics}) єwhether ٨ (Location(u) (data_class (hd) є {Public,records Id_info})) The general of(u, the policy rule that decides aId_info})) user u can access healthcare able to manage his/her own records for age or illness roup (u) є {Researcher}) ٨ ٧ (data_class ((group (u) (hd) є {Researcher}) є {Public, Physical, ٨ (data_class Neuro})) (hd) є ٧ ((group {Public, (u) Physical, є Neuro})) ٧ ((group (u) є a particular environment e is the function. records he general form of hd theinpolicy rule that decides whether a following user u canBoolean access healthcare In R6, we just follow the access rule R5 and add an extra level of access control, that is, the location wner, Family_doctor})) {Owner, (u) Family_doctor})) є {Insurance}) ٨ (data_class ٧((group (u)(hd) є {Insurance}) є {Public, Physical, ٨ (data_class (hd) є {Public, Physical, a particular environment٧((group e is the following Boolean function. Rule: can_access (u, hd, e) of ← locations ƒ (Attr (u), Attrthe (hd), Attrhealth (e)) professionals of the user. Healthcare data can specify a list allied ro, Id_info})) ٧((group Id_info})) (u) Neuro, є {Friend}) ٨ (data_class ٧owner ((group (hd) (u)є є{Public, {Friend}) Physical, ٨ (data_class Neuro,when (hd) Id_info, є {Public, Physical, Neuro, Id_info, Rule: can_access (u, hd, e) ← ƒ (Attrdata. (u), Attr (hd), Attr (e)) are granted access to the healthcare The same rule could be applied for the users of a GP and a ntal})) Mental})) According to this rule, user u will be granted access to healthcare records hd if the attributes of Hospital group to limit access to GPs from L list of locations. u, attribute of hd and attribute is evaluated by thehd function f and returned true. ccording to this rule, user u will be granted accessoftoe healthcare records if the attributes of 1, there are no environmentInconstraints R1, there are as they no environment are irrelevant constraints for this rule as they and there are irrelevant are five for this rule and there are five bute of hd and attribute of e is evaluated by the function f and returned true . •• cases R7: hd, e) ((groupuser (u) u

є {Allied_both}) (data_class (hd) є

{Public, Physical, der which the authenticated under user uwhich will(u, bethe granted will be granted٨ access. R1: can_access can_access (u, hd,authenticated e) ← ←access. {Paramedics}) Id_info})) Neuro, Private}) (environment (e)єє={Public, Require_social)) 1: can_access (u, hd, e)Mental, ((group є{Researcher}) {Paramedics}) (data_class(hd) (hd) {Public, Id_info}))Neuro})) ٧((group (u) є ٧← ((group (u)(u) єId_info, ٨ ٨(data_class Physical, u belongs to the “Paramedics” Case1: if u group belongsand to the requests “Paramedics” access to group healthcare and data requests fromaccess the to healthcare data from the {Owner, Family_doctor})) ٧((groupPhysical, (u) є {Insurance}) (data_class (group (u) є {Researcher}) ٨ (data_class (hd) є {Public, Neuro})) ٧٨((group (u) є(hd) є {Public, Physical, Public” or “Id_info” classes. “Public” classes. In R7, we addedoran“Id_info” environment attribute “Require_social”, which controls the access of allied Neuro, Id_info})) ((group (u) ٨є {Friend}) ٨ (data_class (hd) є Physical, {Public, Physical, Neuro, Id_info, Owner, Family_doctor})) ٧((group (u) є ٧{Insurance}) (data_class (hd) є {Public, u belongs to thehealth “Researcher” Case2: if u group belongs and tomental requests the “Researcher” group healthcare andcircumstances requests data fromaccess the to professionals healthcare data professionals to the andaccess privatetodata where fromfrom the the Mental})) euro, Id_info})) ٧((group (u) є {Friend}) ٨ (data_class (hd) є {Public, under Physical, Neuro, Id_info, Public”, “Physical”, or “Neuro” “Public”, classes. “Physical”, orpatients “Neuro”with classes. “Allied_both” group need to assist both mental and physical issues. Mental})) u belongs to the “Owner” Case3: or if “Family_doctor” u belongs thegroups, “Owner” access or “Family_doctor” is granted. access is granted. In R1, there are notoenvironment constraints as they aregroups, irrelevant for this rule and there are five 6.2.3. Architecture ofthe Multi-Level Access Control u belongs tono the “Insurance” Case4: ugroups belongs and requests the are “Insurance” access groups healthcare and and requests data fromaccess the cases underifconstraints which authenticated user u to will be granted access. R1, there are environment astothey irrelevant for this rule there are fiveto healthcare data from the Public”, “Physical”, “Neuro”, “Public”, oruser “Id_info” “Physical”, classes. “Neuro”, “Id_info” classes. under which the authenticated u will be granted access. or attribute Theifarchitecture the proposed access control for the Case1: u belongs model to the of “Paramedics” group andbased requests access to system healthcare datahealthcare from the u belongs to the “Friend” Case5: group if u belongs and s/he to the requests “Friend” access group to healthcare and s/he data requests fromaccess the to healthcare data from the data is illustrated in Figure 3. “Public” orgroup “Id_info” if u belongs to the “Paramedics” andclasses. requests access to healthcare data from the Public”, “Physical”, “Neuro”, “Public”, “Id_info”,“Physical”, or “Mental” “Neuro”, classes. “Id_info”, or “Mental” classes. Case2: if u belongs to the “Researcher” group and requests access to healthcare data from the “Public” or “Id_info” classes. • e) “Researcher” Access Engine (AEE): AEE isє(u) responsible requesting theєauthorization decision can_access (u, to hd,the •← ((group R2:Enforcement can_access (u) є {GP}) (u, ٨ hd, (data_class e) ← ((group (hd) {Public, є {GP}) Physical, ٨ for (data_class Neuro, {Public, Physical, Neuro, “Public”, “Physical”, orrequests “Neuro” classes. if u belongs group and access to healthcare data from (hd) the and enforcing it. It is the only point of access for users who request access to healthcare data. nfo})) ٧ ((group (u) єor {Hospital}) ٨(data_class ٧to ((group (hd) (u) єor є{Hospital}) (Public, Physical, ٨(data_class Neuro, (hd) Id_info, є (Public, Physical, Neuro, Id_info, Case3: ifId_info})) u belongs the “Owner” “Family_doctor” groups, access is granted. “Public”, “Physical”, “Neuro” classes. Initially authenticated “u” sends AEE an access request for atohealthcare class “hd”. ntal))) ifMental))) uorbelongs to theuser “Insurance” groups and requests access healthcaredata data from the if u belongs to theCase4: “Owner” “Family_doctor” groups, access is granted. Then, AEE collects user and healthcare data class attributes and sends them for evaluation. Finally, “Public”, groups “Physical”, “Id_info” classes. data from the if u belongs to the “Insurance” and“Neuro”, requests or access to healthcare 2: there are also no environment R2: constraints there also for no this environment rule andthe there constraints are two cases for this where rule and the there are two users cases access where the AEEifIn receives theare access decision Access grants Case5: u belongs to theclasses. “Friend”from group and s/heDecision requestsEngine accessand to either healthcare data from the “Public”, “Physical”, “Neuro”, or “Id_info” cated user u will be granted authenticated access. user u will be granted access. or denies their request. “Public”, “Physical”, “Mental”data classes. if u belongs to the “Friend” group and s/he“Neuro”, requests “Id_info”, access to or healthcare from the • “Neuro”, Healthcare Data Repository: a healthcare “Public”, “Physical”, “Id_info”, or “Mental” classes. data repository is any server used to store the data online. R2: can_access (u, hd, (ADE): e) ← ((group є {GP})٨for (data_class є {Public, Physical, •• Access Decision Engine ADE is (u) responsible evaluating(hd) policies and making the Neuro, access 2: can_access (u, hd, e) ← ((group (u) є {GP}) ٨ (data_class (hd) є {Public, Physical, Neuro, Id_info})) ٧ ((group (u) є {Hospital}) ٨ (data_class (hd) є (Public, Physical, Neuro, Id_info, decision (grant or deny). ADE gets attributes of the user and healthcare data classes from AEE, Mental))) d_info})) ٧ ((group (u)retrieves є {Hospital}) ٨(data_class (hd) and є (Public, Physical, Neuro, environment attributes then checks the policy forId_info, the appropriate policy rule and Mental))) finally to AEE. constraints for this rule and there are two cases where the In R2: forwards there are the alsodecision no environment Policy Repository: Policy repository stores all access rules. Policies arethe defined by the owners and user u will be granted access. R2: there are also•authenticated no environment constraints for this rule and there are two cases where healthcare professionals through a designated user interface. nticated user u will be granted access. Our model works as follows. Initially, AEE receives access requests for certain healthcare data from an authenticated user, extracts user attributes and healthcare data class and sends them to ADE. ADE retrieves environment attributes, validates all attributes against Access Policy rules and then returns “grant” or “deny” to AEE. AEE, in return, enforces the access decision on the user.

•

Access Decision Engine (ADE): ADE is responsible for evaluating policies and making the access decision (grant or deny). ADE gets attributes of the user and healthcare data classes from AEE, retrieves environment attributes and then checks the policy for the appropriate policy rule and finally forwards the decision to AEE.  Policy Policy repository stores all access rules. Policies are defined by the owners Informatics 2018,Repository: 5, 23 16 of 18 and healthcare professionals through a designated user interface.

Figure 3. Architecture Model. Figure 3. Architecture Model.

7. Discussion Our model works as follows. Initially, AEE receives access requests for certain healthcare data we neededuser, an access control with and a good level of flexibility regulate fromInitially, an authenticated extracts usermodel attributes healthcare data classtoand sendsaccess them to to digital healthcare dataenvironment stored in the attributes, cloud. The validates nature of all users requesting access to thePolicy storedrules data is a ADE. ADE retrieves attributes against Access and real when it or comes to defining access controlenforces model. These groups of dynamic thenchallenge returns “grant” “deny” to AEE. an AEE, in return, the access decision on theusers user.who may request access occasionally was the main reason we chose ABAC model. 7. Discussion The assumption in the proposed model is that the patient or patient’s guardian is the owner of the healthcare data. The system has control predefined access rules similar to our policy model. These Initially, we needed an access model withpolicy a good level of flexibility to regulate access to access rules should be discussed with different healthcare professionals to enable the best treatment digital healthcare data stored in the cloud. The nature of users requesting access to the stored data is and care for the patient. is the to owner’s responsibility to define extended rules and to define a real challenge when itItcomes defining an access control model. Thesepolicy groups of dynamic users and any extra environment attributes that grant access underABAC certainmodel. circumstances. whoapprove may request access occasionally was the main reason we chose The of our policy modelmodel is demonstrated supporting multi-level access control and Theflexibility assumption in the proposed is that the by patient or patient’s guardian is the owner of by easily implementing combinations of more than one rule. Our system could also be extended to the healthcare data. The system has predefined access policy rules similar to our policy model. These address moreshould complicated issues such a defaulthealthcare access ruleprofessionals for new datatoattributes, joint ownership, access rules be discussed withasdifferent enable the best treatment owner authority and any other related issues. and care for the patient. It is the owner’s responsibility to define extended policy rules and to define

approve any extra environment attributes that grant access under certain circumstances. •and Default access rule: in the case of uploaded healthcare data that have the minimum set of The flexibility of our policy model is demonstrated by supporting multi-level access control and attributes and with no data class defined, there should be a generic access rule to allow or deny by easily implementing combinations of more than one rule. Our system could also be extended to access, or to classify these data under certain classes. For example, if a decision was made to address more complicated issues such as a default access rule for new data attributes, joint collect environmental data such as temperature or radiation levels and add this data to healthcare ownership, owner authority and any other related issues. data, a default rule must be defined to grant access to all requests, assuming no category means class, or torule: denyinaccess, assuming these data are categorized as have private.  public Default access the case of uploaded healthcare data that the minimum set of attributes and with noowner data class defined, there should generic access rule to allow or deny • Joint Ownership: The could give (delegate) onebe or amore ownerships over his data. For access, oralltochildren classify could these be data underfor certain classes. parents. For example, a decision made to example, owners their elderly In the ifcase of a jointwas ownership, we should have more than one access policy over the same data class, as owners can specify their own access rules. Our system grants access to some data when any one of the policies permits the access, which means the relation between the access policies is the logical “or” relationship. Assume both parents are owners of their child’s healthcare data. The father grants Dr. John access to the healthcare data of his child while the mother denies the access. The Access Decision Engine (ADE) will check both access policies in a policy repository and the Access Enforcement Engine


•

17 of 18

(AEE) will return with permission to access the healthcare data of the child because one of the policies grants Dr. John access. Owner authority: in our system, healthcare data could have more than one owner, thus there may be conflicts when not all owners agree or disagree to grant access. This raises more concerns about authorization: do all owners have equal authority, does any owner have the ability to add more owners, or does a new owner have the authority to turn certain private data to public. Our system has only one primary owner who has full control over the data. The primary owner could be either the patient or one of his guardians, any other owners will be a secondary owner who can only grant and deny access requests but cannot add more owners or change data sensitivity.

8. Conclusions In this paper, we have proposed a context-aware solution that helps older people to live independently in a safe environment with integrated multi-faceted authorization. Our IoT based system provides a care management process for elderly people who live alone by monitoring their daily activities and reporting any abnormality in their daily routine, based on analysing the signals collected from passive RFID. The system features a new multi-level access control mechanism that was introduced to secure access to healthcare data. The implemented mechanism is an attribute-based model which adheres to the dynamic nature of the healthcare organization and has the flexibility to adapt to new access requirements. Author Contributions: U.S. and L.Y. conceived of the presented idea and developed the analytical method. U.S. analysed the data and carried out the experiments. U.S. wrote the manuscript with support from L.Y. and H.-y.P. All authors provided critical feedback and helped improve the manuscript. Conflicts of Interest: The authors declare no conflict of interest.

References 1.

2.

3. 4.

5. 6. 7. 8.

9. 10.

Yao, L.; Sheng, Q.Z.; Benatallah, B.; Dustdar, S.; Wang, X.; Shemshadi, A.; Kanhere, S.S. WITS: An IoT-endowed computational framework for activity recognition in personalized smart homes. Computing 2018, 100, 369–385. [CrossRef] Memon, M.; Wagne, S.R.; Hansen, F.O. Ambient assisted living ecosystems of personal healthcare systems, applications, and devices. In Proceedings of the Scandinavian Conference on Health Informatics, Copenhagen, Denmark, 20 August 2013. Li, M.; Yu, S.; Zheng, Y.; Ren, K.; Lou, K. Scalable and secure sharing of personal health records in cloud computing using attribute-based encryption. IEEE Trans. Parallel Distrib. Syst. 2013, 24, 131–143. [CrossRef] Park, N. Customized healthcare infrastructure using privacy weight level based on smart device. In Proceedings of the International Conference on Hybrid Information Technology, Daejeon, Korea, 22–24 September 2011. Premarathne, U.; Abuadbba, A.; Alabdulatif, A.; Khalil, I.; Tari, Z.; Zomaya, A.; Buyya, R. Hybrid cryptographic access control for cloud-based EHR systems. IEEE Cloud Comput. 2016, 3, 58–64. [CrossRef] Gajanayake, R.; Iannella, R.; Sahama, T. Privacy oriented access control for electronic health records. Electron. J. Health Inform. 2014, 8, e15. Abbas, A.; Khan, S.U. e-Health Cloud: Privacy Concerns and Mitigation Strategies. In Medical Data Privacy Handbook; Springer: Berlin, Germany, 2015; pp. 389–421. Begum, M.; Mamun, Q.; Kaosar, M. A privacy-preserving framework for personally controlled electronic health record (PCEHR) system. In Proceedings of the 2nd Australian eHealth Informatics and Security Conference, Perth, Australia, 2–4 December 2013. Fabian, B.; Ermakova, T.; Junghanns, P. Collaborative and secure sharing of healthcare data in multi-clouds. Inf. Syst. 2015, 48, 132–150. [CrossRef] Zhang, R.; Liu, L. Security models and requirements for healthcare application clouds. In Proceedings of the 2010 IEEE 3rd International Conference on Cloud Computing (CLOUD), Miami, FL, USA, 5–10 July 2010.


11.

12.

13. 14. 15. 16. 17.

18.

18 of 18

Yao, L.; Ruan, W.; Sheng, Q.Z.; Li, X.; Falkner, N.J.G. Exploring tag-free RFID-based passive localization and tracking via learning-based probabilistic approaches. In Proceedings of the 23rd ACM International Conference on Information and Knowledge Management, Shanghai, China, 3–7 November 2014. Yao, L.; Sheng, Q.Z.; Li, X.; Gu, T.; Tan, M.; Wang, X.; Wang, S.; Ruan, W. Compressive representation for device-free activity recognition with passive RFID signal strength. IEEE Trans. Mob. Comput. 2018, 17, 293–306. [CrossRef] Mandal, A. Symptoms of Movement Disorders. News Medical 2012. Available online: http://www.newsmedical.net/health/Symptoms-of-movement-disorders.aspx (accessed on 10 February 2018). Zissis, D.; Lekkas, D. Addressing cloud computing security issues. Future Gener. Comput. Syst. 2012, 28, 583–592. [CrossRef] Fido-Alliance. Simpler, Stronger Authentication. Available online: https://fidoalliance.org (accessed on 28 February 2018). Seitz, L.; Pierson, J.M.; Brunie, L. Semantic access control for medical applications in grid environments. In Proceedings of the Euro-Par 2003 Parallel Processing, Berlin, Germany, 2–5 September 2003; pp. 374–383. Strickland, M. Patients Know Best: A Changemaker Health Case Study. Available online: https://medium. com/change-maker/patients-know-best-a-changemaker-health-case-study-2f203b0971ae (accessed on 31 January 2018). Australian Government. National Authentication Service for Health, D.H.S. Available online: https://www.humanservices.gov.au/organisations/health-professionals/services/medicare/nationalauthentication-service-health (accessed on 31 January 2018). © 2018 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

An Internet of Things Based Multi-Level Privacy-Preserving ... - MDPI

An Internet of Things Based Multi-Level Privacy-Preserving ... - MDPI

Suggest Documents

Development of an Internet of Things Based Electrochemical ... - MDPI

An Internet of Things Based Multi-Level Privacy-Preserving ... - MDPI

An Internet-of-Things (IoT) - MDPI

Internet of Things-Based Arduino Intelligent Monitoring and ... - MDPI

Context-Aware Gossip-Based Protocol for Internet of Things ... - MDPI

An Internet of Things Example: Classrooms Access Control ... - MDPI

Internet of Nano-Things, Things and Everything: Future Growth ... - MDPI

Internet of Nano-Things, Things and Everything: Future Growth ... - MDPI

An Automata Based Intrusion Detection Method for Internet of Things

An Integrated Internet of Things Based System for ...

Energy management based on Internet of Things

A Novel Scheme for an Energy Efficient Internet of Things Based - MDPI

A Novel Scheme for an Energy Efficient Internet of Things Based - MDPI

Defining an Internet-of-Things Ecosystem

An Internet of Social Things - Paul Dourish

Defining an Internet-of-Things Ecosystem

an internet of things for transport logistics

Internet of Things: An Overview - IOSR Journals

internet of things (iot): an overview

INTERNET OF THINGS (IOT): AN OVERVIEW

The Internet of Things: An Overview - Internet Society

Fashion 4.0_english - IoT (Internet of Things) | Internet of Things ...

Fashion 4.0_english - IoT (Internet of Things) | Internet of Things ...

The Internet of Things