A SECURE PERSONAL HEALTH RECORD REPOSITORY

Tiago Pedrosa

1,3

, Rui Pedro Lopes

1,3

, Jo˜ao C. Santos

2,3

, Carlos Costa

and Jos´e Lu´ıs Oliveira

Department of Informatics and Communication, Polytechnic Institute of Braganc¸a, Braganc¸a, Portugal

Department of Electrotechnics Engineering, Coimbra Institute of Engineering, Coimbra, Portugal

IEETA, University of Aveiro, Aveiro, Portugal

Keywords:

EHR, PHR, Security, Repositories, Indexing.

Abstract:

Due to strict regulatory, ethic and legal issues, Electronic Health Record (EHR) systems have been mainly de-

ployed in federated health care scenarios. This situation have been hindering the wide adoption of EHRs, con-

tributing to delaying the establishment of a competitive market where contributions from different providers

could take full advantage of information exchange and regular practitioners’ collaboration. Moreover, with

the increasing awareness of medical subjects, patients are demanding more control over their own personal

data - Personal Health Record (PHR). This paper presents a secure PHR repository which access is controlled

through the joint use of a Virtual Health Card Service (VHCS) and an access Broker. This solution can be

deployed in any public or private storage service since it behaves as a sandbox system which access pol-

icy is deﬁned externally. To assure a friendly query-retrieve interaction the whole repository is indexed, and

separated clinical events are kept independently to increase the efﬁciency of cipher and encipher algorithms.

1 INTRODUCTION

Electronic Health Records (EHR) can be deﬁned as

digital record that aggregate all data acquired during

patient care on the healthcare system. Soon captured

the attention of practitioners, policy makers and pa-

tients since they are essential to better clinical ser-

vices integration and to health information sharing.

However, EHRs have mainly been deployed in more

or less enclosed health care scenarios. Strict regula-

tory, ethic and legal constrains (Hodge Jr et al., 1999;

Shabo, 2006), have been hindering the wide adoption

of EHRs, contributing to delaying the establishment

of a competitive market where different providers

could take full advantage of information exchange

and regular practitioners’ collaboration. Moreover

patients are demanding more control over their own

personal data.

To cope with these new user requirements, sev-

eral Personal Health Record (PHR) solutions have

been developed, enabling users to keep record of their

medical data. Examples of such system are, for in-

stance, Google Health, Microsoft HealthVault and

Dossia (Eysenbach, 2008). These web-based PHRs

are mostly based on a central repository and on a set

of core features that, in some cases, can be extended

by external third-party services. A major difference

between EHR and PHR is related to the responsibil-

ity for maintaining the information and for specify-

ing the access control policy. In the former model the

accountable are the healthcare institutions and their

professionals, while in the PHR it is the patient that

owns this responsibility. Despite this typical opera-

tional model, several PHR can also be automatically

populated from systems where the data is generated.

However, for this scenario to be possible, it will be

necessary that EHR systems generate the adequate re-

ports of clinical events and that could interact directly

with those external PHR systems.

The exchange and storage of health information is

a major security challenge, mainly its disruption may

compromise seriously personal privacy. The idea of

having an enterprise with access to all health infor-

mation of a citizen is unlikely to occur because the

risk of information discloser is higher and more dis-

astrous than in a scattered scenario. Moreover, the

Big Brother scenario also appears whenever central-

ization is suggested, despite of the guardian of the in-

formation is an enterprise or the government, and this

vision also slows down the adoption of the different

solutions. This paper presents a secure PHR reposi-

tory where access is controlled through the joint use

of a Virtual Health Card Service (VHCS) and an ac-

cess Broker. Several security features were decou-

pled along both components to assure a double con-

sensus when manipulating the data behind. It can

243

Pedrosa T., Pedro Lopes R., C. Santos J., Costa C. and Luis Oliveira J..

A SECURE PERSONAL HEALTH RECORD REPOSITORY.

DOI: 10.5220/0003781802430248

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2012), pages 243-248

ISBN: 978-989-8425-88-1

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

be deployed in any public or private storage service

since it acts as a sandbox system which access pol-

icy is deﬁned externally. To assure an efﬁcient user

interface, the whole repository is indexed and sepa-

rate clinical events are kept independently to increase

the efﬁciency of cipher-decipher and query-retrieve

algorithms. This strategy enables the citizen to safely

deposit information on the PHR repository, since not

even the repository administrator can discloser it. Un-

der an explicit owner’s authorization, the Broker may

enable other services to access or upload new data in

the PHR.

2 BACKGROUND

EHRs and PHRs can share the record architecture,

but they differ in the data custody ownership and

the management responsibilities. The PHR can be

a self-contained registry, maintained and controlled

by the subject of care, based on a speciﬁc portable

data storage device, some entry in a web service

provider or even a component of an Integrated Care

EHR (ICEHR). In the EHR case healthcare providers

are responsible for its maintenance. Different types

of EHR exist, but one that is more promising is the

ICEHR, that acts as a repository of all the health in-

formation of a patient during is life time (ISO/TC 215,

2005).

For achieving a functional EHR, interoperabil-

ity between producers and consumers of information

is needed. Standardization appears as the solution

to enable the communication between different sys-

tems. These efforts can be divided in two main areas:

the communication standard and the document stan-

dard (Sunyaev et al., 2008). The former refers to how

systems can communicate with each other and the lat-

ter describes how information is stored to ensure a

correct interpretation by other systems. The results

of researching the available standards has evidenced

interoperability barriers.

Diverse documents standards exists, as HL7

speciﬁes the Clinical Document Architecture

(CDA) (Dolin et al., 2006), ASTM the Continuity of

Care Document (CCD) and the Continuity of Care

Record (CCR) (Ferranti et al., 2006) that are con-

strains over the CDA and the OpenEHR (OpenEHR,

2007) uses archetypes for deﬁning the record struc-

ture. Those formats have is the ability to extract a

record or a subset of a record in a XML format where

the DTD deﬁnes the record structure. This provides

an easier way to export data from one system to

another.

The increased mobility and free market in health

care provisioning pushed the information to be scat-

tered through the providers. A solution can be the use

of an integrated access mechanism to the disperse in-

formation. The integrator has to know the location of

the information and how to retrieve it in a secure way.

This linkage information can be stored in the integra-

tor database, or to an extend electronic health card

to support that service (Ferreira Pol´onia et al., 2005;

Costa et al., 2003).

In a wider concept of mobility it is not feasible

that all worldwide patients will have the same type

of card. Another open question is that services and

users can’t make use of the information of the patient

if the card is not present. To overcome that difﬁculties

was proposed a Service Oriented Architecture (SOA),

making use of a Virtual Health Card Service (VHCS),

that mimics the behavior of the physical card (Pedrosa

et al., 2009). Combined with a centralized access

control mechanism that implements the intent consent

policy and with a proxy. The proxy uses the informa-

tion inside a VHC, namely the credentials of the pa-

tient to the repository, the access policy to apply to the

requester user, and the URLs to the scattered reposi-

tories to retrieve the information and create a unique

EHR read-only view (Pedrosa et al., 2010).

The tight regulatory framework that health care

services have to comply, limits their will to give ac-

cess to their systems. Therefore it will limit the use

of the previous solution. A solution that appears is

centralization of the information in one repository.

The EHR healthcare system will create and deposit

on the repository the information related to the pa-

tient attendance. If all systems this procedure, the in-

formation in the repository will enable the creation of

the ICEHR. PHRs make use of services for importing

information, but as the record management is done

by the patient, medical staff tends to question the in-

tegrity of the data.

One of the main concerns about PHR is its privacy,

as the data inside any healthcare provider allows ac-

cess to any PHR, it can potentially open the system to

large-scale disclosures (Ray and Wimalasiri, 2006).

3 PROPOSED SOLUTION

The proposed solution mimics the process for storing

safe deposit boxes inside banks. A procurator is re-

sponsible for managing the deposited goods, which,

in our case, correspond to the information stored in

health records. The citizen will authorize the procu-

rator to deposit and withdraw information from the

safe deposit to answer the needs of third party ac-

tors, previously approved by the citizen. An addi-

HEALTHINF 2012 - International Conference on Health Informatics

244

tional level of protection is added, by deﬁning several

small safes inside a larger safe. The keys for those

small safes will be stored in a different and secure

place (the VHCS), so the information will not be visi-

ble to the bank or to the procurator. When a requester

needs access to the information, he will ask the procu-

rator to provide the data and for that he also provides

a safe box that can only be opened by the procura-

tor, through the keys stored in the VHCS. The procu-

rator, after consulting the privileges of the requester,

will unlock the safe and retrieve the small safe deposit

boxes that contain the required information and tem-

porarily store it in a secure place. The citizen’s safes

will be opened and, according to the requester privi-

leges, the information will be copied to his requesting

safe, which will be then returned to him.

For depositing information, the requester asks the

procurator to bring a safe that will be used to put the

information in. Then, the procurator will take the safe

back, and store it in the citizen’s larger safe deposit

box inside the bank. This approach means that neither

the bank nor the procurator can access the informa-

tion inside the safe, but allows him to manage it. To

get into the details of the architecture, we provide an

overviewof the actors and services involved. The Vir-

tual Health Card Service (VHCS) represent the secure

key deposit; the Broker represents the procurator; the

Repository represent the bank; and the Indexer will

enable a selective retrieval from the Repository (Fig-

ure 1). We use a Service Oriented Architecture that

makes use of SSL certiﬁcates, signed by a Certiﬁcate

Authority (CA), to establish conﬁdence between the

actors and software components. The record is pop-

User/Service

Patient

Figure 1: Wide overview of several actors and services.

ulated with information resulting from several con-

tributions, associated with the different actors, when

they upload the information resultant from medical

activity. All the contributions are stored and ciphered

individually inside the repository. In the request pro-

cess these contributions are retrieved from the reposi-

tory, deciphered, reassembled and ciphered using the

requester key. This assures that the information in

transit is always encrypted and that the only service

that can read the information is the VHCS. In the

store procedure, the information generated by a med-

ical exam, for example, is ciphered using the patient’s

public key and stored in the VHCS. When sending

this information to the Repository, it is ciphered with

the public key of the receiver.

The Repository is a storage service that enables

a client to request or to store bulks of data associ-

ated to a speciﬁc identiﬁer. The identiﬁer is unique

per patient and it is used to associate the information

with a speciﬁc patient. The only way to associate the

stored information to a speciﬁc patient is through the

VHCS. The Broker is the only service that can con-

tact directly the repository. It acts as a middleman

between the users and services that need access to the

repository. It has to validate the users and fulﬁll their

requests through the VHCS when needed.

The creation of a Virtual Health Card by the pa-

tient is the ﬁrst step to enable the use of a secure

PHR repository. This phase is composed by the pa-

tient credentials generation (public/private key pair),

the initialization of a repository i.e. conﬁguring the

repository end point, and the credentials that will al-

low the broker to query that Virtual Health Card. The

users and services that want to make use of the patient

information on the repository or wants to save new in-

formation will use the services provided by the Bro-

ker (Figure 2). The VHCS components are directly

related to patient functions, supported by the follow-

ing components: the Patient Credential, the Access

Control and Repository Management. It also provides

functions and interfaces to be used by the Broker.

The Patient Credential manage public and private

patient keys. The Cryptographic component is re-

sponsible of manipulating those keys in a secure way

and it also provides cryptographicfunctions to manip-

ulate the ciphered block enforcing that the private key

never leaves the VHCS. The Access Control compo-

nent stores the policy deﬁned by the patient to reg-

ulate the access of the users and services that want

to gain access to the repository. It stores the public

key of the user/service and the type of the access he

has to the information. The Repository Management

component is responsible for managing the Reposi-

tory store and the credentials required to gain access.

The Reassemble component provides a way to ag-

gregate the requested individual contributionsin a sin-

gle one. During this phase the access control is en-

forced by the discard of information that the request-

ing user does not have access.

The Broker interface component provides access

to functions that the Broker will need to perform. It

enables the Broker to check the access policy, to know

what Repository to contact and the required creden-

A SECURE PERSONAL HEALTH RECORD REPOSITORY

245

Repository Management

Access Control

Cryptographic Component

Patient Credentials

Broker Interface

Reassembler

Backend

Indexer

Services

Indexer

EHR reassembler

Manage Repostiories

BrokerServices

Retrieve

Store

Repository

Broker

Patient Credentials

Management

Crytographic Functionality

Repository

Credentials

Management

Policy

Management

VHCS

Store Data

Request Data

Registry

User/Service

Define Access Policy

Create VHC

Patient

Uses

Figure 2: Interaction between users and services compo-

nents.

tials. It also enables the Broker to request the public

key of a patient and invokes the ciphering/deciphering

of data through the Cryptography component using

the patient keys.

The Broker components are directly related with

actions that other users/services perform on the pa-

tient repository. First, the users/services have to cre-

ate an account on the Broker, which will check for the

validity of the CA signature, and stores the public key

of the requester. This registry on the Broker is not

only used for users/services authentication. A patient

can also use this to retrieve the public key of users or

services that may want to use the VHCS access con-

trol component. The Broker makes use of the VHCS

capabilities through the broker interface, and together

they enable storing and retrieving of information to

and from the Repository. The Broker manipulates the

information using a closed envelope concept as the

information is always ciphered to the receiver, to the

patient or to user/service that request information.

Figure 3 explains how an external service or user

Repos

VHCS

Broker

Ac t o r

7: SendPatientPublicKey

6: ASKPatientPublicKey

9: CypherForPatient

8: SendPatientPublicKey

5: ASKPatientPublicKey

13: SendReposCredentials

11: CypherRecord

4: Check ok

14: Store

12: AskRepoCredentials

3: CheckPolicy

2: Check ok

10: SavePatinetData

1: Login

Figure 3: Storing information on repository.

can store information on the repository. When a

user/service wants to save new information of a pa-

tient on the Repository it contacts the Broker. First

it challenges the login and checks the authorization

policy on the VHCS. After success, the actor will

ask the public key of the patient. To be able to an-

swer, the Broker requests the patient public key to the

VHCS and forwards it to the user/service. The later

ciphers the information with the given public key and

sends the result back to the Broker. The Broker ci-

phers again using its private key and requests the pa-

tient repository information to the VHCS. Finally, it

uses this information to store the information on the

Repository.

The ﬁrst ciphering procedure ensures that the in-

formation sent to the Broker can only by read by us-

ing the patient’s private key, stored on the VHCS. The

second ciphering forces the Broker to interact with the

information stored on the inside the repository. The

double ciphering obliges the Broker and VHCS to co-

operate in order to manipulate the data.

Sometimes, the requester only needs access to a

subset of information, relieving the burden and the

overload of processing and sending the full data set.

To optimize this process, an indexing service is pro-

vided, enabling some search capabilities over the pa-

tient repository. The proposed architecture contem-

plates an independent indexing service that stores

searchable information. This Indexer accepts queries

and returns PHR repository entries that fulﬁll the

request, avoiding unnecessary manipulation of data

pieces.

Every time a new piece of patient clinical data is

archived, the Indexer securely stores a set of associ-

ated meta-information,including the eventtype, some

coded clinical details, creation date, producer infor-

HEALTHINF 2012 - International Conference on Health Informatics

246

mation and repository data location. Every patient

has its own set of index ﬁles that are ciphered with

his credentials. When creating new data in the Repos-

itory, the actor must create indexing information and

cipher it with patient public key. Both information

blocks, patient data and index metadata, are sent to

the Broker. Here, the index is delivered to Indexer

Service via VHCS and the patient record is stored in

the Repository.

The Index service is only accessible through

VHCS, which controls all access to searching oper-

ations. When an actor needs to search information,

it requests the patient public key to encrypt the query

that is sent to Broker (Figure 4). This provider will

check the actor access policies before forwarding the

request to the VHCS. Here, the query is decrypted

and injected in the Index engine. The query results,

i.e. the data repository references, are returned to the

Broker via VHCS. The Broker then gets the patient

repository information and uses it to retrieve the con-

tributions from the Repository. Next it will decipher

it using Broker’s private key and send the result to

the VHCS along with the public key of the requester.

The VHCS deciphers the received information using

the patient private key, it reassembles the various con-

tributions and ciphers it using the public key of the

requester. In the end, the result will be sent back to

the Broker, which forwards the data to the requester.

The information detained by Indexer module is only

Indexer

Repos

VHCS

Bro ker

Ac tor

13: DecipherQuery

8: CipherQuery

7: SendPatientPublicKey

5: SendPatientPublicKey

6: SendPatientPublicKey

4: ASKPatientPublicKey

3: ASKPatientPublicKey

16: SendReferences

15: SendReferences

14: GetReferences

12: GetReferences

20: SendPatiendRecord

19: RetrieveData

11: Chec k ok

24: SendRecordCypherRequester

18: SendReposCredentials

23: Reassembler

17: AskRepoCredentials

22: DecipherRecord

10: CheckPolicy

25: SendRecordCypherRequester

2: Check ok

21: DecipherRecord

9: GetSelectPatinetData

1: L ogin

Figure 4: Selective Retrieving from repository.

readable by VHCS because it is ciphered with the pa-

tient public key. Moreover, the information stored in

the Repository and Indexer can only be related by a

third secure entity – the VHCS. This approach enables

search operations over a ciphered repository, with-

out disclosing patient information during the process.

The Broker cannot use actor queries information or

Indexer results to extrapolate what kind of data exists

inside patient Repository.

This approach grants that the information is al-

ways transmitted in a closed envelope concept and

that the only actor that can read the information is the

requester. Moreover, the Broker and the VHCS have

to work together to gain access to the information on

the repository.

Although the record can follow virtually any data

format, for our proposal, we have chosen XML. Since

the record format is transparent in terms of ciphering

and storage, the producers and consumers only have

to agree on a common format for enabling collabo-

ration in the creation of the PHR. If not, they must

at least support interchangeable schemas to enable a

common understandable format. The only component

that has to be deﬁned according to a speciﬁc format is

the re-assembler in the VHCS.

The use of XML allows saving the record struc-

ture as well the data. The structure can provide in-

formation about the type of contribution that exists on

the record, even when the data is ciphered. It is true

that the data itself could be protected, but a speciﬁc

structure for saving a type of a lab test result or medi-

cal procedure can reveal, the kind of test or procedure

the patient made. This would allow guessing patient

pathologies and diseases.

4 IMPLEMENTATION

The prototype is being developed in Java EE 6), over

Glassﬁsh application server. All components are de-

ployed as Enterprise Java Beans. The interfaces be-

tween the components will be implemented via web-

services over HTTPS. The client authentication is

conﬁgured and requested in the application server,

being transparent to the developer. The OpenSSL

was chosen as public key cryptographic framework

and as digital credential management (users and ser-

vices) platform it was used the OpenCA bundle. A

Crypto API (Legion of the Bouncy Castle, 2010) is

used to manipulate certiﬁcates and for cryptographic

functions.

The Repository Service is a ﬁle system oriented

storage structure, using a unique subdirectory per pa-

tient, each with a random identiﬁcation number. Each

patient directory stores the ciphered clinical records

submitted to Repository Service by the Broker. Each

structured record ﬁle receives a sequence number that

A SECURE PERSONAL HEALTH RECORD REPOSITORY

247

unequivocally relates it to the patient index informa-

tion stored in Index system.

To test this prototype, a Google Health account

is being used to create a test record. Using the Data

Exchange tool (Mount Tabor, 2010) the record is ex-

ported to a ﬁle. That ﬁle is uploaded to our Repository

via our Broker to test the solution. The inverse pro-

cess will be also tested.

5 CONCLUSIONS

Personal Health Records have recently appeared as a

solution that allows patients to keep track of their own

clinical history. With the increasing availability of

medical information in the Internet, citizens now have

access to a tremendous amount of data sources, which

provide information such as diseases symptoms, di-

agnostics, treatments, drugs, physicians, and many

others. This situation is leading to better informed

citizens, but with much more complex requirements

– health information gathering and privacy assurance

are two critical examples.

This paper presents a secure PHR repository that

combines the notion of a safe deposit with the ability

to securely share clinical data. This particular feature

enables the integration with external services upon

an explicit authorization by the patient. In this way,

much of the data that is uploaded in the repository

can come directly from EHR systems, which allevi-

ates the user from the burden of record updating. The

aggregation of all these contributions enables a com-

prehensive overview of the patient medical status and

relevant historic information. Moreover, patient’s per-

sonal registries can also be kept in this system.

To assure security requirements, the information

in transit is always ciphered. On storage operations,

the system uses the patient public key and on retrieval

it applies the public key of the requester. In the store

procedure a second entity, the Broker, will also cipher

the data before storing it in the repository. The only

component that can read the sandbox record is a vir-

tual card component (VHCS), but without access to

its content. Despite holding the repository credentials

and the private key of the patient to decipher the data,

the VHCS would need that the Brokeralso retrieve the

data from repository. The proposed solution provides

a search capability through an indexing service that

maintains links to metadata of all the PHR contribu-

tions, allowing a selective retrieve from the repository

whenever a query is executed.

REFERENCES

Costa, C., Oliveira, J., Silva, A., et al. (2003). A new con-

cept for an integrated healthcare access model. The

new navigators: from professionals to patients: pro-

ceedings of MIE2003, page 101.

Dolin, R., Alschuler, L., Boyer, S., Beebe, C., Behlen, F.,

Biron, P., and Shabo Shvo, A. (2006). Hl7 clinical

document architecture, release 2. Journal of the Amer-

ican Medical Informatics Association, 13(1):30.

Eysenbach, G. (2008). Medicine 2.0: social networking,

collaboration, participation, apomediation, and open-

ness. Journal of Medical Internet Research, 10(3).

Ferranti, J., Musser, R., Kawamoto, K., and Hammond, W.

(2006). The clinical document architecture and the

continuity of care record. British Medical Journal,

13(3):245.

Ferreira Pol´onia, D., Costa, C., and Oliveira, J. (2005). Ar-

chitecture evaluation for the implementation of a re-

gional integrated electronic health record. In Press, I.,

editor, Proceedings of MIE2005. IOS Press.

Hodge Jr, J., Gostin, L., and Jacobson, P. (1999). Legal

issues concerning electronic health information: pri-

vacy, quality, and liability. Jama, 282(15):1466.

ISO/TC 215 (2005). Health informatics - electronic

health record - deﬁnition, scope, and context - iso/tr

20514:2005(e). Technical report, ISO.

Legion of the Bouncy Castle (2010). The Legion of

the Bouncy Castle. http://www.bouncycastle.org/

java.html, Last Checked: 1 June 2010.

Mount Tabor (2010). Mount tabor and google

health. http://www.mttaboros.com/GHPartners.html,

Last Checked: 1 June 2010.

OpenEHR (2007). Introducing openehr - revision 1.1. Tech-

nical report, OpenEHR.

Pedrosa, T., Costa, C., Lopes, R., and Oliveira, J. (2009).

Virtual health card system. Inforum 2009.

Pedrosa, T., Lopes, R., Santos, J., Costa, C., and Oliveira,

J. (2010). Towards an EHR architecture for mobile

citizens. In HealthInf 2010 Proccedings.

Ray, P. and Wimalasiri, J. (2006). The need for technical

solutions for maintaining the privacy of EHR. In IEEE

Engineering in Medicine and Biology Society.

Shabo, A. (2006). A global socio-economic-medico-legal

model for the sustainability of longitudinal electronic

health records-part 2. Methods of information in

medicine, 45(3):240.

Sunyaev, A., Leimeister, J., Schweiger, A., and Krcmar, H.

(2008). It-standards and standardization approaches in

healthcare. Encyclopedia of Healthcare Information

Systems.

HEALTHINF 2012 - International Conference on Health Informatics

248