2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/ 12th

IEEE International Conference On Big Data Science And Engineering

PHeDHA: Protecting Healthcare Data in Health

Information Exchanges with Active Data Bundles
Wesam H. Fadheel Raed M. Salih Leszek T. Lilien
Department of Computer Science
Western Michigan University
Kalamazoo, MI 49008, USA
{wesam.fadheel; raedmahdi.salih; leszek.lilien}@wmich.edu

Abstract— Health Information Exchanges (HIEs) collect and
disseminate electronic patient healthcare data (EHRs/EMRs)
among different healthcare providers to improve the quality and
reduce the cost of healthcare services. However, the dissemination
of patient data raises privacy and security concerns due to ease of
copying and unauthorized dissemination of electronic data. This
paper proposes a HIE system called PHeDHA (Protecting
Healthcare Data in HIEs with Active Data Bundles), which provides
privacy and security protection for patient data during their
transmission via an HIE among different healthcare providers.
PHeDHA uses as its basis the scheme named Active Data Bundles
with Trusted Third Party (ADB-TTP). As the name suggests, ADB-
TTP is based on an integration of a trusted third party (TTP) with
Active Data Bundles (ADBs). An ADB is a software object that
keeps patient healthcare data as sensitive data; includes metadata
describing these sensitive data and prescribing their use (via data
access and privacy policies specified within metadata); and
encompasses a policy enforcement engine (called a virtual machine
or VM), which controls and manages how the ADB behaves. In
particular, the VM assures ADB’s data integrity and enforces
its policies specified as a part of metadata. We describe and discuss
the conceptual model for PHeDHA, based on ADB-TTP. We are
currently evaluating PHeDHA via simulation experiments.
Keywords—active data bundles; health information exchange;
privacy; security; trusted third party.
I. INTRODUCTION
The Health Insurance Portability and Accountability Act
(HIPAA) [1] is a legal framework for protecting individuals by
assuring privacy and security of healthcare data. The U.S.
Department of Health and Human Services (HHS) issued
HIPAA Privacy Rule [1] to implement HIPAA requirements and
regulations. The Rule promotes high-quality healthcare services
for individuals in order to improve the public health and well-
being. This can be achieved by providing appropriate safeguards
and restriction conditions (or rules) to protect the privacy of
Protected Health Information (PHI) as well as dictate its use and
disclosure among healthcare providers1 [1, 2].
Since most of the PHI is created, stored, used and
disseminated electronically using computer systems, the HHS
included a Security Rule in HIPPA [1] to ensure the
1
Examples of healthcare providers include physicians, nurses, dentists,
pharmacists, healthcare researchers as well as organizations employing them
(hospitals, clinics, medical labs, medical research institutes, etc.)
confidentiality, integrity and security of individuals’ Electronic
Protected Health Information (ePHI) [1, 2]. HIPAA Security
Rule requires implementation of three levels of safeguards
including physical, administrative and technical [2]. It should be
noted that the Security Rule does not cover PHI that is
transmitted or stored on paper or provided orally, while the
Privacy rule covers the confidentiality of PHI in all formats
including electronic, paper and oral.
If healthcare providers adopt and adhere to HIPAA Privacy
and Security Rules, the exchange of individuals’ health data can
be facilitated and enhanced.
A. Health Information Exchange (HIE)
Healthcare providers include hospitals, clinics, labs and
healthcare research institutes, insurance companies and
government agencies. Typically, healthcare information is
stored across multiple healthcare providers, who cooperate to
provide technology, governance and support for so called Health
Information Exchanges.
A Health Information Exchange (HIE) enables cooperating
healthcare providers and patients to access and securely transfer
patients’ healthcare data electronically, in this way improving
the quality, safety and cost of patient care [3]. Each HIE must
adopt all HIPAA regulations, including Privacy and Security
Rules.
Patient healthcare data include Electronic Health/Medical
Records (EHRs/EMRs), which are records of patients’ long-term
health history, containing doctor visit summaries, diagnoses,
prognoses, laboratory and radiology tests, treatment
descriptions, etc. [4].
There is a difference between EMRs and EHRs. EMRs are
legal records for patients that are created in a single healthcare
provider facility (like a hospital or a clinic). In contrast, EHRs
are the summaries of EMRs for a given patient that are collected
by authorized healthcare providers from more than one
healthcare provider visited by the patient [5].
HIE manages multi-directional flows of electronic patients’
healthcare information among different healthcare providers as
shown in Figure 1.

2324-9013/18/31.00 ©2018 IEEE 1187

DOI 10.1109/TrustCom/BigDataSE.2018.00164
 Under HIPAA requirements, healthcare providers must
anonymize data by removing all “identifiers” from healthcare
records before sharing them with other healthcare providers or
other authorized parties [7, 8].
C. Privacy and Confidentiality in HIE
We define “security as the right not to have one’s activities
adversely affected via tampering with one’s objects, and
privacy as the right to have information about oneself left
alone” [9].
User privacy is a user’s right to protect and control her data.
As a special case, patient privacy refers to the patient’ right to
protect and control her healthcare-related data [23, 24]. Patients
should be able to determine when, how and which portions of
their health information are disclosed or disseminated [11].
User confidentiality is the right of an individual or user to
Figure 1. Example of Health Information Exchange (HIE).
keep her personal and medical information private unless she
gives her permission to disclose a part or the whole of this
There are three exchange procedures used by HIEs to share
information to another party [10]. As a special case, patient
patient information among multiple healthcare providers [3]:
confidentiality is the right of a patient to keep her healthcare or
1) Directed exchange – enabling healthcare providers to medical information private unless she gives her permission to
coordinate secure electronic transmissions (sending and disclose a part or the whole of this information to another party
receiving) of patient information. [11, 12].
2) Query-based exchange – enabling healthcare providers to
find and/or request information on a patient from other D. Paper Contribution and Organization
healthcare providers. This paper proposes a secure health information exchange
3) Consumer-mediated exchange – empowering patients to by a HIE using a scheme known as Active Data Bundles with
aggregate and control the use of their health information by Trusted Third Party (ADB-TTP). ADB-TTP is based on the use
healthcare providers. of a trusted third party (TTP) and Active Data Bundles (ADBs).
ADBs protect carried patient healthcare data by encapsulating
B. Protected Health Information (PHI) them as their sensitive data; by including metadata, which
describe the sensitive data and prescribe their use (via policies,
Table I shows eighteen PHI/ePHI identifiers which are
including access and privacy policies); and by encompassing an
created, stored, and maintained by or on behalf of healthcare
execution engine (called a virtual machine or VM). VM controls
providers.
and manages how the ADB behaves; among others, how it
Table I. HIPAA Protected Health Information (PHI/ePHI) [2]. enforces privacy policies.
The paper is organized as follows. Section II discusses
No. PHI/ePHI Identifiers related work. Section III presents motivation and the problem
1 Names (patient, healthcare provider) of protecting healthcare data disseminated among diverse
2 Addresses authorized healthcare providers. Section IV describes structure
3 Geographic subdivisions and operations of ADB-TTP. Section V presents the baseline
4 All elements of dates related to the individual (dates of birth,
marriage, death, etc.) HIE and the proposed HIE system named Protecting Health
5 Telephone numbers Data in HIE with ADBs (PHeDHA—pronounced FEH-dah,
6 Facsimile numbers which rhymes with “Jedah”). Section VI presents Conclusions,
7 Driver’s license numbers and Section VII presents future works.
8 Electronic mail addresses
9 Social security numbers
10 Medical record numbers
11 Health plan beneficiary numbers II. RELATED WORK
12 Account numbers, certificate/license numbers Zhou et al. [13] propose Hospital Information eXchange
13 Vehicle identifiers and serial numbers
14 Device identifiers and serial numbers (HIX) for hospital healthcare business-services system. The
15 Web Universal Resource Locators (URLs) HIX is a cloud-based computing support for business functions,
16 Internet Protocol (IP) address numbers including integrated mobile medical information services and
17 Biometric identifiers mobile health information services. The HIX uses the cloud-
18 Full face photographic images and any comparable
based technology and business model of the Monetary
Authority of Singapore (MAS). It provides total solutions for
hospital healthcare business services system, including efficient

1188
hospital information management enabling shorter waits for
registration, payments, and doctor visits. It also facilitates
doctor-patient communication and reduces costs of hospital
healthcare services. Security in HIX relies on security solutions
built into the MAS technology.
Afazl et al. [14] propose a HIE framework providing
a secure access to patient data and adhering to the
interoperability rules. HIE framework includes six
components: Health Life Horizon: Personal Health Record
(HLH PHR), which provides infrastructure for individual users
to manage their shareable data; Keys Manager (KM), which
manages keys for encryption of PHR records; Authentication
Manager (AM), which authenticates various categories of users;
Transaction Manager (TM), which releases/accepts resource
contents to be published on HLH PHR for authenticated users;
PHR Repository (PHR-R), which stores contents published on
HLH PHR; and External Interfaces, which provide patient data
in a secure manner, based on proper authentication and
authorization. The proposed framework implements the L-
diversity algorithm to ensure individual privacy when
publishing data for statistical analysis.
Lijun and Jianchao [15] propose a patient identification
service for the Chinese healthcare administration, which adopts
a centralized HIE architecture to protect patient healthcare
information. The proposed identification service is based on
Patient Identifier Cross-Reference (PIX) to process shared
information; the Master Patient Identifier (MPI) service to
construct or select a suitable unique identifier for the HIE
domain; and Match Engine (the core of HIE) to provide an
identification service using a cross-reference algorithm (which
helps to assure uniqueness of patient identifications). HIE
depends on a unique patient identity (such as a national ID card
number) to match and integrate all patient healthcare
information provided by various healthcare institutions.
Ma et al. [16] propose a hybrid cloud prototype to support
digital home-based self-care. It composes OpenStack and
Amazon Web Services to exchange health information among
patients and multiple stakeholders. The prototype exchanges
health data uses the HL7 CCD format [17]. The authors claim
that using open-source cloud computing technologies for
sharing health information is secure, scalable, cost-effective,
and partially solves interoperability and privacy problems.
Yu et al. [18] propose a city-wide HIE system for Shanghai,
the largest HIE system in China. It includes six districts
hospitals and 40 community health centers, covering 39 million
patients and saving at least 48 million RMB. The system is
based on SOA (Service-Oriented Architecture) and complies
with industry standards. Healthcare data from different
providers are integrated and stored in a central data repository,
and linked by a city-wide general patient index (using unique
patient healthcare identifiers). The authors indicate that data
security and privacy remain the major challenges.
III. MOTIVATION AND PROBLEM STATEMENT
Protecting exchanged patients’ sensitive data is commonly
considered the main problem in HIEs. Figure 1 shows diverse
1189
healthcare providers exchanging patient healthcare data via
HIE. Any request for patient data is mediated by HIE. For
instance, when Clinic requests a patient’s healthcare data
through HIE, HIE distributes the request to healthcare providers
that the patient visited. Each healthcare provider that has the
requested data, sends them to HIE. Then, HIE responds to the
Clinic’s request by sending to it all data collected from different
healthcare providers.
Clearly, dissemination of patients’ healthcare data among
many diverse providers increases the risk of disclosing (or
leaking) patients’ private information to unauthorized parties.
For protecting privacy of patients’ sensitive data
disseminated within HIE, we propose the system named
PHeDHA (Protecting Health Data in HIE with ADBs), which is
based on the ADB-TTP scheme.
IV. STRUCTURE AND BASIC OPERATIONS OF ACTIVE DATA
BUNDLES WITH TRUSTED THIRD PARTY (ADB-TTP)
A. ADB Structure
An ADB (a.k.a. AB or Active Bundle) [19] is a software
construct bundling together three components (cf. Figure 2):
1) Sensitive data representing a digital content that needs
to be protected from unauthorized access, including privacy
violations, data leaks, unauthorized dissemination, etc.
2) Metadata containing information describing sensitive
data and prescribing their use, such as access and privacy
policies for the sensitive data.
3) Virtual machine (VM) controlling and managing how
the ADB encompassing it behaves. VM is the component that
makes its ADB active because it is implemented via executable
mobile code and responsible for performing all ADB
operations. The essential tasks of the VM include assurance of
ADB data integrity, and enforcement of the privacy policies and
data dissemination rules specified by ADB metadata for ADB
data [19, 20].
Sensitive data
Metadata
Virtual machine (VM)
Figure 2. The basic structure of an Active Data Bundle (ADB) [20].
The use of the term “virtual machine (VM)” in the ADB
context is different than in the operating systems and related
areas.2 This term is used here since ADB’s VM still exhibits origination host either automatically or interactively with the
general characteristics of a VM—esp. enabling mobility, help of a user-friendly ADB Creator (ADBC) software. With an
flexibility, and compatibility [21]. assistance from ADBC, ADB is going through a sequence of
actions to assure confidentiality and integrity of the ADB’s
B. ADB Hosts and ADB Lifecycle sensitive data during the planned ADB dissemination.
Any ADB can be transmitted from its origination host to its ADBC uses data encryption and hashing techniques
destination host via a sequence of intermediate hosts multiple times to protect confidentiality and integrity of ADB’s
(optionally using a secure transmission for even better privacy components (sensitive data, metadata, and VM). To protect
and security). The intermediate and destination hosts are privacy of ADB’s sensitive data, ADBC encloses the
collectively known as visited hosts (VHs). origination host’s privacy policies for these data in the ADB’s
ADB lifecycle includes three phases: ADB creation, ADB metadata.
dissemination, and ADB enabling [19]. ADBC bundles ADB’s components, completing ADB
Any ADB lifecycle phase may require ADB reduction construction. Now, ADB-TTP sends to the TTP the enabling
and/or ADB termination [19]. ADB reduction involves a partial record, which includes decryption keys and hash values
ADB destruction, which occurs if only a part of sensitive ADB (generated by ADBC) required by the destinations for accessing
data are threatened. ADB data. The ADB is ready for sending to the destination
ADB termination always involves a complete ADB hosts.
destruction. We distinguish: (a) a triggered ADB termination, 2) ADB Dissemination
which occurs before a given ADB completes its data-delivery Using a secure transmission, ADB-TTP sends the newly
task, in response to a threat that all sensitive data in this ADB created ADB to one or more destination hosts, possibly via
will be disclosed by the attack materializing this threat; and (b) a sequence of intermediate forwarding hosts [19].
a pre-planned ADB termination, which occurs at the end of the
ADB enabling phase performed on the last host visited by the 3) ADB Enabling
given ADB while executing it multi-destination data Enabling of an ADB starts when it reaches a destination host
dissemination job.3 (DH). ADB enabling comprises four groups of activities (cf.
Figure 3): ADB Authentication, ADB Authorization, ADB
C. Partial or Complete ADB Destruction via Evaporation Integrity Verification, and ADB Policy Enforcement [6, 24].
and Apoptosis
A partial ADB destruction occurs via the mechanism of
evaporation (an analogy to a phenomenon in physics). An
evaporating ADB destroys only a part of its data, namely the
hottest data. The hottest data are identified by having data-
sensitivity level exceeding the clearance level that an entity
trying to access it possesses.
The complete ADB destruction occurs via apoptosis (an
analogy to a cell-biology phenomenon). The apoptosizing ADB
self-destroys completely (destroying its data, metadata, and
VM), irretrievably, and in a privacy-preserving and secure
manner.
As an example, suppose that a given ADB has sensitive data
with Confidential, Secret, and Top Secret data-sensitivity
levels. If there is a threat posed by an entity (a person, an
application, etc.) with the Confidential clearance, then all Secret
and Top Secret data are the “hottest” data (”hotter” than
Confidential data), and they evaporate. If there is another threat,
this time posed by an entity with the Restricted clearance
(below the Confidential level), then ADB apoptosizes.
D. More Details of ADB Lifecycle and Operations
The three ADB lifecycle phases are as follows.
1) ADB Creation Figure 3. ADB enabling steps performed by VM at a destination host [6].
In this phase, a given ADB is created for a user at the

2
A system VM (a.k.a. a hardware VM) enables access to a complete system
platform—including its operating system, the underlying hardware,
networking resources, input/output devices, and GUI [21]. A process VM
(a.k.a. an application VM) provides user applications with a high-level
abstraction through a high-level programming language. In its various
implementations, it delivers replication, emulation, and facilitates
performance optimization [21, 22].
3
We allow for multi-destination ADB dissemination, in which a single ADB
visits and delivers data to multiple destination hosts.

1190
 Figure 4. The baseline scenario for HIE: Components and process flow for Clinic’s request for P-EMR from HIE.
The enabling record (sent by ADB-TTP to the TTP during
ADB Creation) is requested from TTP and used for Steps a - c
of ADB Enabling.
The flow of control during ADB Enabling, shown in Figure
3, includes four steps:
a) If authentication fails, then VM apoptosizes the entire ADB
and ADB enabling ends. Otherwise (when authentication
succeeds), authorization starts.
b) If authorization fails, then VM apoptosizes the entire ADB
and ADB enabling ends. Otherwise, integrity verification
starts.
c) If integrity verification fails, then VM apoptosizes the
entire ADB and ADB enabling ends. Otherwise, policy
enforcement starts.
d) During policy enforcement, VM enforces the privacy
policies (stored in the ADB’s metadata) and delivers to DH
only the data that the policy permits DH to access.
V. THE BASELINE HIE AND THE PHEDHA SYSTEM
A HIE system consists of five components (cf. Figure 4):
1) Interface Application (App): used as an interface which
receives a user’s request for Patient Electronic Medical
Record (P-EMR).
2) Request Verifier (RV): used to verify any request received
either from App or from other providers.
1191
3) Control Unit (CU): used to process any request verified by
RV.
4) Database (DB): a local database holding a subset of P-
EMRs.
5) Query Interface (QI): used to send a query (a request): in
case of a P-EMR requester (e.g., Clinic), to send a request
to HIE; in case of HIE, to forward a request to healthcare
providers.
A. The Baseline Scenario for HIE
In our baseline scenario for HIE, shown in Figure 4, Clinic
requests HIE for an up-to-date P-EMR.
The actors in this scenario are: (a) Clinic acting as an
originating host with a user (a doctor) who is health data
requester for an up-to-date P-EMR; (b) HIE acting as
a mediator between the healthcare data requester and other
healthcare providers; and (c) Hospital acting as a healthcare
provider in possession of the requested up-to-date P-EMR.
The flow of requesting up-to-date P-EMR (cf. Figure 4) is
as follow:
Doctor at Clinic requests for an up-to-date P-EMR
1) A Doctor at Clinic uses App to request for P-EMR; App
forwards the request to Clinic RV.
2) After a positive verification, Clinic RV passes the request
to Clinic CU.
3) Clinic CU queries its local Clinic DB for the up-to-date P-
EMR.
 Figure 5. Basic scenario for PHeDHA: ADB-TTP components and process flow for Clinic’s request for P-EMR from HIE.

4) Local Clinic DB indicates that its copy of P-EMR is HIE responds to Clinic request
outdated. for the up-to-date P-EMR
5) Clinic CU forwards the P-EMR request to Clinic QI. 16) After a positive verification of the up-to-date P-EMR
6) Clinic QI sends the request to HIE RV. received from Hospital, HIE RV sends it to HIE CU.
HIE forwards Clinic request for the up-to-date 17) HIE CU sends the up-to-date P-EMR to the local DB so
P-EMR to Hospital4 that HIE DB can update its copy of the P-EMR.
7) After a positive verification of the Clinic request, HIE RV 18) HIE DB sends an ACK (confirmation) to HIE CU.
passes it to HIE CU. 19) HIE CU sends the response with the up-to-date P-EMR to
8) HIE CU queries its local DB for the up-to-date P-EMR. Clinic RV.
9) HIE DB indicates that its copy of P-EMR is outdated. Clinic responds to Doctor at Clinic
10) HIE CU forwards the Clinic P-EMR request to HIE QI. 20) After a positive verification of the up-to-date P-EMR
11) HIE QI sends the request to Hospital RV. received from HIE, Clinic RV sends it to Clinic CU.
Hospital responds to the HIE request 21) Clinic CU sends the up-to-date P-EMR to its local DB so
for the up-to-date P-EMR that the local DB can update its copy of the P-EMR.
12) After a positive verification of the HIE request, Hospital 22) Clinic DB sends an ACK to Clinic CU.
RV passes it to Hospital CU. 23) Clinic CU sends the up-to-date P-EMR to its App, which
13) Hospital CU queries its local DB for the up-to-date P- delivers the up-to-date P-EMR to Doctor who requested it.
EMR. B. The PHeDHA Scenario for HIE
14) Hospital DB finds the requested up-to-date P-EMR and
The analogous request-and-response scenario for PHeDHA,
sends the response with P-EMR to Hospital CU as the
which uses the ADB-TTP scheme, is significantly different than
response to the query.
the above baseline HIE scenario.
15) Hospital CU sends the up-to-date P-EMR to HIE RV. Figure 5 illustrates the data and control flow for the
4
In general, HIE can forward a party’s request for P-EMR to not just one but
many providers.

1192
scenario, involving Clinic, HIE and Hospital. Note that the
PHeDHA scenario includes not only HIE but also some details
of the modules used in Clinic and Hospital to implement the
ADB-TTP scheme. In addition to being a mediator (as in the
baseline HIE scenario), HIE in PHeDHA also acts as a TTP
(providing the enabling record to a given ADB when ADB is
processed at HIE and Clinic). Please note that HIE’s TTP
activities are not shown in Figure 5.
In PHeDHA, P-EMR is protected by being encapsulated by
an ADB. Hence, this scenario includes ADB creation, ADB
dissemination, and ADB enabling (till termination by
apoptosis).
The following steps are not shown in Figure 5:
1) Doctor at Clinic requests for an up-to-date P-EMR
(a sequence of steps identical to Steps 1-6 in the baseline
HIE scenario).
2) HIE forwards Clinic request for the up-to-date P-EMR to
Hospital (a sequence of steps identical to Steps 7-11 in the
baseline HIE scenario).
3) After a positive verification of the HIE request, Hospital
RV passes it to Hospital CU (identical to Step 12 in the
baseline HIE scenario).
4) Hospital CU queries its local DB for the up-to-date P-EMR
(the step identical to Step 13 in the baseline HIE scenario).
The steps following Step 4 (given directly above) are shown
in Figure 5; they are renumbered below starting with 1.
Continued: Hospital responds to the HIE request
for the up-to-date P-EMR using ADB
1) Hospital DB finds the requested up-to-date P-EMR and
sends the response with P-EMR to Hospital CU as the
response to the query.
2) Hospital CU attaches metadata (“MD”) to P-EMR.
3) Hospital CU encapsulates the result of Step 2 within VM,
thus completing creation of the Hospital ADB (H-ADB).
4) Hospital CU sends H-ADB to HIE RV (for verification of
H-ADB).
HIE responds to Clinic request
for the up-to-date P-EMR
5) After a positive verification, HIE RV forwards H-ADB to
HIE CU.
6) H-ADB’s VM executes ADB Authentication (on HIE CU).
If this authentication fails, H-ADB is apoptosized.
Otherwise, VM proceeds to the next step.
7) H-ADB’s VM executes ADB Authorization (on HIE CU).
If this authorization fails, H-ADB is apoptosized by VM.
Otherwise, VM proceeds to the next step.
8) H-ADB’s VM executes ADB Integrity Check (on HIE
CU), verifying P-EMR. If this check fails, H-ADB is
apoptosized by VM. Otherwise, VM proceeds to the next
5
Note that in case that multiple up-to-date E-PMR are released to HIE-CU,
they are “partial up-to-date E-PMRs.” For example, H-ADB (from Hospital)
might bring to HIE-CU a partial up-to-date E-PMR describing the most
recent hospital visits of the patient in question on, while L-ADB (from
1193
step.
9) H-ADB’s VM executes ADB Policy Enforcement (on HIE
CU), including privacy enforcement, to release the up-to-
date P-EMR to HIE.
10) H-ADB’s VM releases the up-to-date P-EMR (till now
encapsulated within H-ADB) to HIE CU.
11) HIE CU sends the released up-to-date P-EMR to the local
HIE DB so that HIE DB can update its copy of the P-EMR.
Note that Steps 5-11 can be repeated N times when N ADBs
(with N copies of the P-EMR) are received by HIE CU
from healthcare providers (such as Hospital, Laboratory,
etc., shown in Figure 1).5
12) HIE DB merges all released up-to-date P-EMRs (received
from HIE CU) into a single P-EMR and sends it to HIE
CU.
13) HIE CU attaches metadata to the merged P-EMR. These
metadata integrate (merge) metadata of all individual P-
EMRs released to HIE-CU (in one or more repetitions of
Step 10).
14) HIE CU encapsulates the result of Step 13 within VM, thus
completing construction of the HIE-ADB.
15) HIE CU sends HIE-ADB to Clinic RV (for verification of
HIE-ADB).
Clinic responds to Doctor at Clinic
16) After a positive verification, Clinic RV forwards HIE-ADB
to Clinic CU for enabling.
17) HIE-ADB’s VM executes ADB Authentication (on Clinic
CU). If this authentication fails, HIE-ADB is apoptosized
by VM. Otherwise, VM proceeds to the next step.
18) HIE-ADB’s VM executes ADB Authorization (on Clinic
CU). If this authorization fails, HIE-ADB is apoptosized
by VM. Otherwise, VM proceeds to the next step.
19) HIE-ADB’s VM executes ADB Integrity Check (on Clinic
CU), verifying P-EMR. If this check fails, HIE-ADB is
apoptosized by VM. Otherwise, VM proceeds to the next
step.
20) HIE-ADB’s VM executes ADB Policy Enforcement (on
Clinic CU), including privacy enforcement, to release the
up-to-date P-EMR to Clinic.
21) HIE-ADB’s VM releases the up-to-date P-EMR (till now
encapsulated within HIE-ADB) to Clinic CU.
22) Clinic CU sends the up-to-date P-EMR to the Clinic DB so
that Clinic DB can update its copy of the P-EMR.
23) Clinic DB sends ACK to Clinic CU. Note that there is no
merging of P-EMRs by the Clinic DB here, so Clinic CU
has this P-EMR copy already.
24) Clinic CU sends the up-to-date P-EMR to App, which
delivers the up-to-date P-EMR to Doctor who requested it.
Laboratory) might bring to HIE-CU a partial up-to-date E-PMR with the
most recent lab results for the patient.
 VI. CONCLUSIONS
Health information exchange shares healthcare data among
healthcare providers to improve the quality, safety, and cost of
healthcare services. However, sharing patient healthcare data
among many diverse providers increases the risk of disclosing
patients’ sensitive data to unauthorized parties.
This paper presents the basic structure and operations of the
PHeDHA system for protecting patient healthcare data
exchanged among different healthcare providers in a health
information exchange (HIE). PHeDHA aims to alleviate
privacy and security concerns related to these data exchanges.
We are currently designing proof-of-concept simulation
experiments using J-Sim [25] to validate effectiveness and
efficiency of PHeDHA. We plan to simulate both the baseline
HIE scenario, which shows interactions among healthcare
providers through HIE, and the analogous PHeDHA scenario,
which differs from the baseline scenario only by using in it
Active Data Bundles and Trusted Third Parties. The results
obtained in both simulations will provide quantitative data for
a comprehensive evaluation of PHeDHA versus the baseline
system.
VII. FUTURE WORK
We plan two extensions to the presented work. First, we
plan to use consent models [26] by enhancing ADB privacy
policies [19, 6] with consent rules. The consent models are
intended to maintain and control patients’ data disclosures in
electronic exchanges in HIE by enforcing patients’ selected
preferences and conditions [26].
There are five consent models:
1) No-consent: patient does not participate in electronic
exchanges (no data are exchanged).
2) Opt-in: patient expresses her desire to participate in
electronic exchanging of all her data or some pre-defined
subset of her data.
3) Opt-out: patient expresses her desire to automatically
participate in electronic exchanging of pre-defined subsets
of her data.
4) Opt-out with exceptions: patient expresses her desire to
participate in electronic exchanging (with specific
exceptions) of all her data or some pre-defined subsets of
her data.
5) Opt-out with restrictions: patient expresses her desire to
participate in electronic exchanging (with restrictions) of
all her data or some pre-defined subsets of her data.
ADBs will enforce consent rules with their privacy policies
during ADB dissemination among healthcare providers.
As the second extension, we plan to add granularity rules
[26] to ADB privacy policies.
Granularity refers to a patient’s concern or fear of how her
personal information is perceived or used during the electronic
exchange. This concern and fear can be eliminated by enforcing
granularity rules that grant the desired level of control over
specific sensitive information included in the patient’s
healthcare data.
1194
There are four granularity types:
1) Granularity by data type: a patient expresses her desire to
block or not a specific data record/element during
electronic exchanges.
2) Granularity by provider: a patient expresses her desire to
allow specific healthcare providers or staff categories (e.g.,
nurses) to access her healthcare data during electronic
exchanges.
3) Granularity by time range: a patient expresses her desire to
allow access to pre-defined subsets of her data within
a specific time range during electronic exchanges.
4) Granularity by purpose: a patient allows her data to be
accessed according to a specific purpose during electronic
exchanges.
REFERENCES
[1] “HIPAA Survival Guide,” Lions Publishing. Accessed in February 2018
from: http://www.hipaasurvivalguide.com.
[2] “HIE Privacy and Security Overview and Resource List,” National Rural
Health Resource Center. Accessed in February 2018 from:
https://www.ruralcenter.org/resource-library/hie-privacy-and-security-
overview-and-resource-list.
[3] “Health Information Exchange (HIE),” HealthIT.gov. Accessed in
February 2018 from: https://www.healthit.gov/providers-
professionals/health-information-exchange/what-hie#query-
based_exchange
[4] “Electronic Health Records Overview,” National Center for Research
Resources, NIH, Bedford, MA, April 2006. Accessed in June 2011 from:
http://www.ncrr.nih.gov/publications/informatics/ehr.pdf.
[5] D. Garets and M. Davis, “Electronic Medical Records vs. Electronic
Health Records: Yes, There Is a Difference,” White Paper, HIMSS
Analytics, Chicago, IL, January 2006.
[6] R.M. Salih, “Using Agent-based Implementation of Active Data Bundles
for Protecting Privacy in Healthcare Information Systems,” Ph.D. Thesis,
Department of Computer Science, Western Michigan University,
Kalamazoo, MI, April 2018.
[7] S. Martínez, D. Sánchez, and A. Valls, “A Semantic Framework to Protect
the Privacy of Electronic Health Records with Non-numerical Attributes,”
J. of Biomedical Informatics, vol. 46(2), New York, April 2013, pp. 294-
303.
[8] T. Mabotuwana, C.S. Hall, R. Van Ommering, R. Tellis and M. Sevenster,
“An HL7 Data Pseudonymization Pipeline,” IEEE Intl. Conf. on
Healthcare Informatics (ICHI), Dallas, TX, October 2015, pp. 303-309.
[9] A. Al-Gburi, A. Al-Hasnawi and L. Lilien, “Differentiating Security from
Privacy in Internet of Things—A Survey of Selected Threats and
Controls,” Chapter 9 in: K. Daimi et al., Computer and Network Security
Essentials, Springer International Publishing, Cham, Switzerland, 2018,
pp. 153-172.
[10] R. Shirey, “RFC 2828 - Internet Security Glossary,” Internet FAQ
Archives, June 2012. Available at: http://www.faqs.org/rfcs/
rfc2828.html
[11] R.C. Barrows and P.D. Clayton, “Privacy, Confidentiality, and Electronic
Medical Records,” J. of the American Medical Informatics Association,
vol. 3(2), March/April 1996, Avenel, NJ, pp. 139-148.
[12] “Patient confidentiality, “Encyclopedia of Surgery. June 2011.
Accessed in February 2018 from: http://www.surgeryencyclopedia.com/
Pa-St/Patient-Confidentiality.html
[13] F. Zhou, F. Cheng, L. Wei and Z. Fang, “Cloud Service Platform-
Hospital Information Exchange (HIX),” IEEE 8th Intl. Conf. on e-
Business Engineering, Beijing, China, October 2011, pp. 380-385. DOI:
10.1109/ICEBE.2011.35.
[14] M. Afzal, M. Hussain, M. Ahmad, and Z. Anwar, “Trusted Framework
 for Health Information Exchange,” Frontiers of Information Technology
(FIT), Islamabad, Pakistan, December 2011, pp. 308-313.
[15] W. Lijun and C. Jianchao, “The Identification Service in Health
Information Exchange,” IEEE 16th Intl. Conf. on Computational Science
and Engineering, Sydney, Australia, December 2013, pp. 1161-1166.
[16] J. Ma, C. Peng and Q. Chen, “Health Information Exchange for Home-
Based Chronic Disease Self-Management—A Hybrid Cloud Approach,”
5th Intl. Conf. on Digital Home, Guangzhou, China, November 2014,
pp.246-251. DOI: 10.1109/ICDH.2014.54
[17] “HL7/ASTM Implementation Guide for CDA® R2 -Continuity of Care
Document (CCD®) Release 1,” (n.d.). Accessed in February 2018 from:
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=
6 ISPA 2011, Busan, Korea, May 2011, pp. 311-315. DOI:
[18] Y. Guangjun, C. Wenbin, Z. Li, B. D. W, G. Jianlei and L. Hui,
“Implementation of a city-wide Health Information Exchange solution in
the largest metropolitan region in China,” IEEE Intl. Conf. on
Bioinformatics and Biomedicine (BIBM), Shenzhen, China, December
2016, pp. 795-798.
[19] L. Ben Othmane and L. Lilien, “Protecting Privacy in Sensitive Data
Dissemination with Active Bundles,” Seventh Annual Conf. on Privacy,
Security and Trust (PST 2009), Saint John, New Brunswick, Canada,
August 2009, pp. 202-213.
[20] L. Ben Othmane, “Active Bundles for Protecting Confidentiality of
Sensitive Data Throughout Their Lifecycle,” Ph.D. Thesis, Department of
Computer Science, Western Michigan University, Kalamazoo, MI,
December 2010.
1195
[21] “Virtual Machine,” Wikipedia. Accessed in February 2018 from:
https://en.wikipedia.org/wiki/Virtual_machine.
[22] J. Smith and R. Nair, Virtual Machines: Versatile Platforms for Systems
and Processes, Morgan Kaufmann Publishers, San Francisco, CA, 2005.
[23] R.M. Salih, L.T. Lilien, and L. Ben Othmane, “Protecting Patients’
Electronic Health Records Using Enhanced Active Bundles,” 6th Intl.
ICST Conf. on Pervasive Computing Technologies for Healthcare
(PervasiveHealth 2012), San Diego, CA, May 2012, 4 pages, DOI:
10.4108/icst.pervasivehealth.2012.248719
[24] R.M. Salih, L. Ben Othmane and L. Lilien, “Privacy Protection in
Pervasive Healthcare Monitoring Systems with Active Bundles,” Intl.
Conf. on Advanced Software Engineering (ICASE), in conjunction with
10.1109/ISPAW.2011.60.
[25] J-Sim Official, (n.d.). Accessed in February 2018 from:
https://sites.google.com/ site/ jsimofficial
[26] M. M. Goldstein, A. L. Rein, P. P. Hughes, J. K. Lappas, S. A. Weinstein
and B. Williams, “Consumer Consent Options for Electronic Health
Information Exchange: Policy Considerations and Analysis,” White
Paper, Health Information Technology, Washington, DC, March 2010,
https://www.healthit.gov/sites/default/files/choicemodelfinal032610.pdf