Towards a cross-context identity managementframework in e-health

Mina Deng, Danny De Cock, Bart PreneelKatholieke Universiteit Leuven, ESAT/COSIC, Kasteelpark Arenberg 10,

B-3001 Leuven-Heverlee, BelgiumIBBT, Gaston Crommenlaan 8, B-9050 Gent-Ledeberg, Belgium

mina.deng@esat.kuleuven.be

Abstract—Interoperability becomes an important issue whenmultiple healthcare providers are collaborating in an e-healthsystem. In cross-context communications, the same informationcan be expressed by means of different types or values. This paperproposes a new service for cross-context identity management inthe e-health application domain, aiming to improve interoperabil-ity between agencies when context-specific information is trans-ferred from one context to another. Furthermore, an algorithmfor issuing and converting context-specific identifiers, based oncryptographic techniques, is presented. How the proposed cross-context IDM service can be integrated in an e-health system isexplained with a use case scenario.

Keywords: context-specific identifier, cross-context identitymanagement, e-health

I. INTRODUCTION

In recent years, the technological evolution of e-healthsystems has drawn increasing attention from both industry andresearch communities worldwide. The goals of e-health sys-tems as follows, are fourfold. Primarily, to provide ubiquitousaccess to lifelong clinical records of a patient to all relevantstakeholders, including the patient, anytime, anywhere, onany device. In addition, to integrate and enrich the clinical,medical and operational knowledge to support lifelong healthguidance of citizens within a community, region, and country.Moreover, to streamline the workflow into shared clinical andoperational pathways in order to enable disease managementand optimally support the clinical process. Combining thesethree goals facilitates inter-professional collaboration, whileguaranteeing the privacy of the patient.

The major technical challenges facing e-health services arefacilitating efficiency, information retrieval and availability,and cross-context interoperability. The rapid aging of popula-tions, combined with pressure on budgets for healthcare deliv-ery, and technological advances are the driving forces behindthese challenges. Hence, in the realm of e-health, security andprivacy issues have a deep impact. Security techniques, suchas access control structures, are adopted in e-health systemsto ensure that only involved parties have access to sensitivedata. The circle of trusted parties should not be extended bymoving from a paper-world to an e-health administration. Apatient expects a trust relation with medics, however, as in thepast with a doctor’s secretary, the trust in the digital worldmight lead to the need to trust a system administrator too.

The adoption of user-centric federated identity managementsystems can help to keep the circle of trust as small as possible.

In traditional identity management systems identity infor-mation is hosted and managed by an identity provider using,for example, directory services [1]. It has various advantagesfrom the service provider’s point of view, such as being costeffective and easily scalable. The disadvantage is that byapplying such an approach, the user looses some control overpersonal identity information. Recently, this has resulted inthe emerging trend for user-centric identity management [2].In user-centric IDM, the user is put in the center of interest andis given control over personal information. In particular, thismeans that the user can influence or even specify which infor-mation should be forwarded or revealed to a particular serviceprovider. This has the obvious advantage of better protectingthe privacy of each individual user. However, responsibilityfor storing and updating data then lies with the user.

Previous e-health solutions were mainly concerned witha limited view on patient information utilizing a healthcareprovider-centric approach for identity management, mostlylimited to a single provider. Interoperability has becomean important issue, especially as more and more healthcareproviders collaborate in an e-health system. If we refer to eachhealthcare provider such as a hospital, general practitioner(GP) or clinical research lab as a ”context”, it is commonpractice for each entity, such as a patient, to have a uniqueidentifier within a particular context. When context-specificinformation is transferred from one context to another, thesame information can be expressed by means of differenttypes or values. Typically, healthcare providers use differentterms for the same entity, strictly relying on dictionaries maybe very misleading. Besides, all the information exchangedamong healthcare providers in the e-health system needs tobe uniquely identified. Therefore, there is a need to have anidentity management (IDM) mechanism in which a mapping ofcontext-specific identifiers and a conversion of context-specificinformation occurs when data is exchanged among differentcontexts. Note that the above problem is only a cross-contextissue when identifiers should not be shared directly amongcontexts. Linking information from one context to anothershould not be straightforward, hence the need for a privacy-friendly but interoperable IDM system. Previous work mostlyemphasized the e-health IDM issues from a provider-centric

viewpoint. However, existing work of e-health systems revealsan unsatisfactory provision for the interoperability problemin cross-context IDM systems. Therefore, a new frameworkis proposed, where each context may deploy a user-centricIDM system, with multiple IDM systems collaborating andinformation transferring from one IDM system to another.

In this paper, we move towards this framework by defininga new model for identity management with an identifierconversion mechanism to ensure information interoperabilityin e-health. Further, we propose an algorithm for issuing andconverting context-specific identifiers, based on cryptographictechniques. To illustrate the concept, we present our results inIDM-related research activities for the E-Health InformationPlatforms (EHIP) project. The objective of the EHIP project,successfully completed in Flanders, Belgium, is to create aclinical data sharing infrastructure among multiple healthcareproviders. The information sharing platform is designed insuch a way so that information, such as patient e-healthrecords, is always available and accessible at the time andplace it is required and only to authorized actors. Severalkey players in e-health, including leading sector companies,several university research groups and large hospitals, havecontributed to ensure that the project outcome is valid withina genuine context. In addition, a lifetime view is projected,which will be instrumental in guiding the transition in health-care systems from provider-centric towards patient-centric.

In 2006 the United States Department of Health and HumanService Health issued the Insurance Portability and Account-ability Act (HIPAA) [3]. This is a regulation in healthcareto demand the protection of patients data shared from itsoriginal source of collection. Since 2005 the processing andmovement of personal data is legally regulated by the EU withthe Directive 95/46/EC [4]. A citizen’s right of privacy is alsorecognized in the Article 8 [5] of the European Convention forthe Protection of Human Rights and Fundamental Freedoms.The debate surrounding the usage of single national identifica-tion numbers has longstanding historical roots. EU countrieshave sought to regulate their national number(s) in a varietyof ways. Art. 8.7 of Directive 95/46/EC [4] provides that”Member States shall determine the conditions under which anational identification number or any other identifier of generalapplication may be processed”, indicating that governmentsshould carefully consider how they allow national numbersto be used. Regardless of how national identification numbersare regulated in each respective State, they constitute ”personaldata” by nature within the meaning of Directive 95/46. Art.16 and 17 of the Directive which imposes upon the controllera general confidentiality and security obligation, including theobligation for the controller to take all reasonable measures”to prevent all other unlawful forms of processing” (Art. 17).Regardless of the possible perception that this might lead tomassive data aggregation and profiling by the government, onthe value of which we bare no judgment, it is manifestly clearthat the national number is not intended for use outside thegovernmental context.

This paper builds on the results of the IDEM project [6],

and we will explain how the proposed cross-context IDMservice that was developed within the IDEM project canbe integrated in the framework of EHIP. As the legislationsuggested, patient’s national identification number is not tobe transferred cross-context. Therefore, we provide a privacyfriendly solution such that each healthcare provider assignsa unique context-specific identifier for the patient and thepatient’s medical record respectively. When information, suchas patient’s medical data and patient identifiers, is transferredcross-context, context-specific information is converted by ouridentity management mechanism for interoperability.

The rest of the paper is organized as follows. The EHIPplatform architecture with functional components is presentedin Section II. The motivation and concept of the proposedcross-context identity management service in e-health is ex-plained in Section III. The reversible algorithm to issue andconvert context-specific identifiers is defined in Section IV.How the proposed cross-context IDM service can be integratedin an e-health system, with the EHIP platform as a casestudy is illustrated in Section V, Section VI, and SectionVII. In particular, the motivating scenario, the system modeland players, the attack model and assumptions are defined inSection V. The proposed services of each entity, the proposedapproach to request a service, and the protocol of the proposedscenario are discussed in Section VI. The security analysis isprovided in Section VII. Related work is introduced in SectionVIII. Section IX provides a conclusion.

II. THE EHIP ARCHITECTURE

Classic community healthcare systems utilize an e-Portalfunctionality to provide a many-to-one connection betweenmany GP’s and one hospital, based on propriety solutions.The disadvantages of this approach are twofold. First, it isimpossible to interconnect different entities, such as hospitals.Second, one GP needs multiple portals to access patientdata in different hospitals. As an improvement, a centralizedinfrastructure is enabled in community healthcare. Note thatthis does not need to imply that data physically resides in acentral data store. The advantage of this approach is that usersgain a consolidated overview on the clinical data of the patient,to which clinical research institutes and healthcare providerscan interconnect.

The EHIP infrastructure aims to promote community health-care and international standards on different fora. It providesa horizontal infrastructure for e-health applications compatiblewith international standards of Cross-Enterprise DocumentSharing (XDS, [7]) by Integrating the Healthcare Enterprise(IHE, [8]) and technologies such as Web 2.0 to be used inweb-based portals (AJAX [9], Portlet [10]), which are interop-erable within the Belgian e-health digital platform BeHealth[11] infrastructure and hospital IT systems, with respect tosecurity and privacy. On the other hand, it provides a verticalapplication-based prototype for hospitals and GPs to share apatient’s longitudinal record (EHR), such as medical summary,clinical results and patient discharge letters.

The functional components of the EHIP platform are de-picted in Fig. 1. Based on a Service Oriented Architec-ture (SOA), where each subsystem exposes its functionalitythrough a service interface, it utilizes a central documentregistry to contain the metadata of all available documents,and distributed document stores, where medical documentsare stored in local repositories of the corresponding healthcareproviders. The EHIP platform also contains a gateway to sup-port healthcare providers with limited resources, such as smallpractices that cannot afford a repository. Further, the platformprovides Internet-enabled access to the resources through aWeb portal, which facilitates actions such as accessing the plat-form after-hours. Documents in the platform share a commoncontent model (HL7/CDA, Clinical Document Architecture[12]), such that all parties, despite their heterogeneous internalsystems, gain easy access. The architecture employs feder-ated security, in which security is embedded in middleware.Federated policy enforcement at hospitals and GPs surgerieswith a central policy management are deployed for accesscontrol, i.e., authentication and authorization, in compliancewith the EU data protection directive. According to XDS,the electronic health record (EHR) security is covered by thefollowing Integration Profiles [7]: the Audit Trail and NodeAuthentication (ATNA) Profile to provide audit trail and theCross Enterprise User Authentication (XUA) Profile to providea federated identity management framework based on SAMLthat enables single sign-on (SSO) functionality across multipleenterprises. Wuyts et al. [13] provide a security enhancedsoftware architecture with an analysis of potential securityrisks threatening XDS-compliant systems, such as the EHIPinfrastructure.

III. CROSS-CONTEXT IDENTITY MANAGEMENT INE-HEALTH

In this section, we look at identity management from an e-health prospective. In general, there are two types of identifiersin the EHIP system: a global identifier of a patient, e.g., thenational identification number, and context-specific identifiers.The context-specific identifiers in the system are used tolocally identify a patient and the patient’s medical recordwithin a specific context, e.g., a healthcare provider.

As mentioned in Section II, all healthcare providers mayhave heterogeneous internal systems, and each healthcareprovider typically issues its own unique context-specific iden-tifier to patient as well as to the patient’s medical record, thatwill be stored in the local repository of the correspondinghealthcare provider. This means, the one patient will be issueddifferent identifiers from different healthcare providers, simi-larly the patient’s medical records stored in different healthcareproviders will be assigned with different document identifiers.According to the legal restrictions explained in Section I, forprivacy, it is not advised to share the patient’s global identifieramong contexts.

We now attempt to expand the notion of e-health identitymanagement to multiple contexts interacting and communi-cating with each other. One complication that occurs is that

administrations need to exchange information coming fromdifferent contexts. For example, one healthcare provider triesto query the medical record concerning a patient from anotherhealthcare provider, such that context-specific information isexchanged from one context to another. Further, the personalinformation exchanged needs to be uniquely identified, butthe same identifier should not be shared among contexts.Whenever information is exchanged between different contextsa mapping and conversion of identifiers is required. In order toexchange information between contexts, an identifier mappingand conversion is performed by a trusted party which isavailable for each context. [14] Since linkability of informationfrom one context to another is desirable but not yet feasible,a manageable system for information interoperability is re-quired. Therefore, or goal is to provide a cross-context IDMsystem, compatible with all the internal systems employedby the entities in the e-health platform, to translate andconvert context-specific information and identifiers used andexchanged between the concerned entities.

Fig. 2 presents a cross-context information exchange in thee-health application context. An administrative organizationof a healthcare provider can be separated as front and backoffices. The front office is connected with portals and localrepositories. It directly interacts with its users, while the backoffice provides services for system support, such as iden-tity management, authentication, authorization, informationsharing, and auditing. The identity provider from the backoffice issues context-specific identifiers to its patients. Eachhealthcare provider is responsible for the issuance and useof context-specific identifiers within its context. Accordingly,one healthcare provider cannot prevent another healthcareprovider from issuing context-specific identifiers for its pa-tients within a particular context. When healthcare providerscommunicate, information can be exchanged through a medi-ating service provided by the e-health platform. The mediatingservice, that is to say a trusted party available for eachcontext, is responsible for mapping and converting context-specific information, such as identifiers, exchanged betweenthe communicating parties. This paper does not focus onhow information is exchanged exactly, since it depends onsemantic models, and application and communication-specificscenarios. Instead, the contexts and entities involved in thiscommunication are explored. In Section V, we explain howcontext-specific information can be converted and exchangedbetween contexts within a real-life scenario.

The abstract structure of cross-context IDM applied in acommunication can be presented as an inter-connected solarsystem, as depicted in Fig. 3. In e-health, node A, B, E,etc. denote back offices. They can be the central server of ahospital, or a gateway connecting various portals of differentdepartments of a hospital. When communicating cross-contextbetween a service provider and a service requester, context-specific identifiers mapping and information conversion isperformed by a trusted agent called mediator, as denoted bynode C, D, and G.

Fig. 1. Bird-view of the EHIP infrastructure

Fig. 2. Cross-context information exchange in the e-health context

IV. ALGORITHM FOR CONTEXT-SPECIFIC IDENTIFIERISSUE AND CONVERSION

In this section, we introduce a reversable algorithm to issueand convert context-specific identifiers.

A. To issue a context-specific identifier

The algorithm to issue a context-specific identifier is definedas:

Fig. 3. An abstract structure of cross-context IDM system with context-specific information conversion

Anon is a deterministic algorithm to issue a context-specificidentifier. The algorithm’s public input are the global identifierof an objective entity GID of fixed-length, and a context-specific reference Ref of variable length. The private inputare two symmetric secret keys Ke, Kh, for the pseudo-randomfunction and the symmetric encryption function, respectively.The algorithm provides a fixed length context-specific identifieras:

Fig. 4. Algorithm for issuing a context-specific identifier

Prefix = HMACKh(Ref)

Anon(GID, Ref, Ke, Kh) = EKe

(HMACKh

(Ref)‖GID)

= EKe(Prefix‖GID)

The construction of the context-specific identifier issuealgorithm is depicted in Fig. 4. The context-specific referenceof any length is the input to a pseudo-random function witha secret key, e.g., HMAC-SHA256. This results in a 256-bitmessage digest as a prefix. Then the prefix is concatenatedto the global identifier, and encrypted using a symmetricencryption algorithm with a second secret key, such as AES inCBC mode. The result is the context-specific identifier. Notethat the secret keys for encryption and pseudo-random functionshould be different.

B. To convert a context-specific identifier

The algorithm to extract the global identifier from a context-specific identifier is defined as follows:Deanon is a deterministic algorithm to extract from a

context-specific identifier the objective entity’s global iden-tifier. The algorithm’s public input is the context-specificidentifier AID, and the private input is the symmetric secretkey Ke, for the symmetric decryption function. The algorithmprovides a fixed-length global identifier as:

Deanon(AID, Ke) = [DKe(AID)]LSBn

Note that the symbol [X]LSBnrefers to the extraction of the

n least significant bits of X , as these correspond with the bitsholding the global identifier.

As a reverse process of issuing, the construction for con-verting a context-specific identifier is depicted in Fig. 5.

Fig. 5. Algorithm for converting a context-specific identifier

The context-specific identifier is the input to a symmetricdecryption algorithm, controlled by the secret key. The result isthe prefix concatenated with the global identifier. The prefix iseasily removed allowing the global identifier to be recovered.

V. CROSS-CONTEXT IDM IN THE EHIP PLATFORM: ACASE STUDY

In this section, we explain how context-specific identifierscan be converted and exchanged accross contexts in the EHIPplatform, using a real-life scenario.

Consider the following scenario: suppose in the EHIPnetwork, a generic hospital Hospital1 H1 intends to querya medical record of patient A from a psychiatric hospitalHospital2 H2, through the EHIP registry R.

A. System model

The system model we consider consists of the followingplayers:

a) Hospital H1: is a generic hospital context, whoseback office contains a file repository FR1, a patient IDprovider PIP1, a document ID provider DIP1, and a documentanonymizer DA1.

b) Hospital H2: is a psychiatric hospital context, whoseback office contains a file repository FR2, a patient IDprovider PIP2, a document ID provider DIP2, and a documentanonymizer DA2.

c) PatientA: is a patient that requests healthcare servicesfrom a healthcare provider. Let GID denote A’s globalidentifier, e.g., the patient’s national number. Let PIDj denoteA’s context-specific identifier, i.e., pseudonym, assigned bythe healthcare provider Hj . DIDj denotes the pseudonymassigned by Hj for A’s medical record DocAj stored in thecontext Hj .

d) EHIP Registry R: is a central registry that maintainsa link between a patient’s global ID and the locations of eachhealthcare provider that stores the patient’s medical records.

B. Attack model and assumptions

The objective of an attacker Eve is to obtain private infor-mation from a particular patient. In the proposed scenario, Evemay either try to obtain the patient’s global ID or the patient’ssensitive medical information from the psychiatric hospital

H2. In order to do so, Eve has several options: first, shetries to request the patient’s global identifier from the identityproviders of each healthcare provider or the central registry.Then, Eve tries to request the sensitive medical data directlyfrom the hospital H2. Afterwhich, Eve tries to steal the secretkeys of any identity providers or the document anonymizer inthe system, in order to access the sensitive data. In addition,Eve tries to break into the system. Finally, she could try toeavesdrop the communication channel to obtain the desiredcontent. An attacker can be categorized as either internal to thee-health network, or external. An internal attacker can be eitheran authorized or unauthorized recipient of the e-health systemservices. We assume all the external attackers outside the e-health network are unauthenticated and unauthorized entitiesto the system.

The following assumptions hold for the proposed system.All entities that have been authenticated and authorized by thesystem are assumed trustworthy. The system is not protectedagainst malicious entities that are able to authenticate them-selves and who are authorized to use the system’s services. Weassume that all security-enhancing functionalities employed inthe system are robust and well-deployed. All secret keys ofthe entities in the system are stored physically secure. Thecommunication takes place through a secure communicationchannel.

VI. PROPOSED APPROACH

A. Services provided by each entity

Consider the hospital Hj , let KP j denote the secret key ofthe patient ID provider PIPj , and let KDj denote the secretkey of the document ID provider DIPj . The ID providersPIPj and DIPj are able to provide the IDIssue andthe IDConvert services. Let KDocj denote the secret keyof the document anonymizer DAj . DAj is able to providethe DocAnon and the DocDeanon services. Both Hj’s filerepository FRj and the EHIP central registry R can providethe Query service. Each kind of service is described asfollows:IDIssue: A service to issue context-specific identifiers.

Let K = {Ke, Kh}, then,

AID = IDIssue(GID, Ref, K) = Anon(GID, Ref, K)

IDConvert: A service to convert context-specific identifiersback to the global ID.

GID = IDConvert(AID, K) = Deanon(AID, Ke)

DocAnon: A service to pseudonymize part of a documentDoc by encryption, which contains sensitive medical informa-tion.

ADoc = DocAnon(Doc, K) = EK(Doc)

DocDeanon: An algorithm to convert a pseudonymized doc-ument back to the non-pseudonymized version by decryption.

Doc = DocDeanon(ADoc, K) = DK(ADoc)

Fig. 6. Check service request commands flow

Query: A database query service with the input of someattributes and the output of some other attributes from thedatabase.

B. Proposed approach to request a service

Each time before a service is delivered to a service requesterfrom a service provider, the service requester needs to beauthenticated and authorized, as depicted in Fig. 6.

1) A service requester sends a service request to a serviceprovider.

2) The service provider forwards the request to its securityfacade to check the requester.

3) The security facade checks the requester’s authenticityand authorization.

4) If the checks are passed, the security facade informsthe service provider to deliver the required service.Otherwise, the service delivery is denied.

5) The service provider delivers the service to the servicerequester.

C. Protocol of the proposed scenario

Fig. 7 presents the protocol of the scenario that Hospital1H1 queries a medical record of a patient A from Hospital2H2 through the registry R in the EHIP system. Note that Rserves as the mediator for the cross-context communicationbetween H1 and H2. R interacts with the ID providers ofthe two contexts and performs context-specific identifier issueand conversion. Fig. 8 depicts the information transferred crosscontexts in the following steps:

1) H1 queriesR with the context-specific patient ID PidA1

of a patient A.2) R request the IDConvert service with PidA1 fromH1’s patient ID provider PIP1, in order to receive theglobal ID GidA of A.

3) After the authentication and authorization check of Rby H1, PIP1 performs IDConvert(PidA1, Kp1) anddelivers the result GidA to R.

4) R queries its database to retrieve the correspondinglocation of the hospital where A’s medical record isstored. We assume the document is at H2, Loc(H2)←Query(GidA, Reg).

Fig. 7. The protocol of the cross-context query of a medical record scenario in the EHIP infrastructure

5) R request the IDIssue service from H2’s documentID provider DIP2 with GidA.

6) After the authentication and authorization check, DIP2

provides R the context-specific document ID of A’smedical record stored in H2 by performing DidA2 ←IDIssue(GidA, Kd2).

7) R sends DidA2 and H2’s location information Loc(H2)to H1.

8) H1 sends a query to H2 with DidA2.9) H2 queries its file repository FR2 and

retrieves A’s medical record DocA2, DocA2 ←Query(DidA2, TabH2).

10) H2 requests the DocAnon service from its documentanonymizer DA2 for an anonymized version of DocA2.

11) After the authentication and authorization check,DA2 performs the document pseudonymizationAnonDocA2 ← DocAnon(DocA2, Kdoc2), resultingin the pseudonymized medical record AnonDocA2.

12) H2 delivers the requested medical record AnonDocA2

to H1 through a secure channel.

VII. SECURITY ANALYSIS

In this section, we present a security analysis of ourproposed solution explained in Section VI, in correspondenceto the attack models in Sec V-B. We will show, under thepredefined assumptions, why those potential attacks cannot beperformed successfully in our system. Firstly, it is important toassume that all entities which are authenticated and authorizedto obtain a certain service from a service provider are trust-

worthy, and vice versa. We also assume that any entity, whofails to pass a service provider’s authentication or authorizationcheck, should not obtain the corresponding service.

As explained above, the system is not protected againstmalicious entities whom are checked as authenticated andauthorized. Now we consider the attacker Eve as an unauthen-ticated or unauthorized entity, and examine the five misusecases Eve may perform. In the first and the second misusecases, Eve tries to request the patient’s global identifier withthe IDConvert service from any of the healthcare provider’sidentity providers or from the central registry. Or, she tries torequest the sensitive medical data directly from the hospitalH2. However, neither case is possible, because in order toreceive the service, Eve has to pass the authentication andauthorization check by the service providers. The third attackEve may perform is to attempt to steal the secret keys ofany identity providers or the document anonymizer in thesystem, such that she could perform the IDConvert serviceor the DocDeanon service to obtain the desired information.This is unfeasible for Eve, since we assume all secret keysof the entities in the system are stored securely. In the nextmisuse case, Eve may try to hack the system and breakdownthe security. This option is not feasible either, because allthe security-enhancing functionalities employed in the systemare assumed to be robust and well-deployed in the proposedsystem. If Eve fails to perform all the above attacks, Eve canstill try to eavesdrop on the communication content. However,presumably, the communication is taking place through asecure communication channel with client-side and server-side

Fig. 8. The information flow in the cross-context query scenario in the EHIP infrastructure

authentication.We can conclude from the above analysis, that the secu-

rity of the proposed system depends on the security of thesecret key, the security of the communication channel, andthe security of the underlying system security infrastructure,such as the security of the authentication and authorizationmechanisms.

VIII. RELATED WORK

Various popular user-centric identity management systemsdeveloped over the past years include Shibboleth [15], [16],Liberty Alliance [17], [18], CardSpace [19], and Idemix [20],[21]. In the literature, there are some identity managementschemes proposed for e-health utilizing a user-centric ap-proach. Peyton et al. [22] use a simple ePrescription scenarioto analyze the business and technical issues to be addressedin a Liberty Alliance-based federated identity managementframework for e-health. They look at the potential impactof privacy compliance on three existing components of theframework, namely, Discovery Service, Identity MappingService and Interaction Service. A fourth component AuditService is proposed to address potential privacy breeches inLiberty Alliance. Au and Croll [23] recently proposed a newframework for a consumer-centric identity management fordistributed e-Health. The healthcare consumer maintains apool of pseudonym identifiers in their personal secure devicefor use in different healthcare services, perhaps in the formof a smart card. Without revealing consumer identity, healthrecord data from different medical databases distributed invarious points of clinical service can be collected and linkedtogether on demand. In particular, pseudonym identifiers arecryptographically generated by a trustee, and the binding of anidentifier to the identity key or another identifier is certified by

a Key Binding Certificate issued by the trustee. Hence, securityof the interactions among different entities in the architectureis guaranteed by certification and cryptographic technologies.

Some results have been published on privacy protectionand secondary use issues of Electronic Health Record (EHR).Iacono et al. [24] discuss the importance of protecting theprivacy of patient data kept in an EHR in cases where itleaves the control- and protection-sphere of the health carerealm for secondary uses such as clinical or epidemiologicalresearch projects, health care research, assessment of treatmentquality or economic assessments. The work focuses on multi-centric studies, where various data sources are linked togetherusing Grid technologies. It introduces a pseudonymizationsystem which enables multi-centric universal pseudonymiza-tion, meaning that a patient’s identity will result in the samepseudonym, regardless of which participating study centerthe patient data is collected. Pommerening and Reng [25]addressed the issue of secondary uses of EHR, such as healtheconomy and health care research, or disease specific clinicalor epidemiological research. For these uses in general, thepatient identity must be anonymized or pseudonymized. Theirwork describes possible model architectures, developed formedical research networks, but useful in broader contexts.

In Europe, there are several research projects on cross-boarder identity management. The concept of context-specificidentifiers was introduced in the Modinis Study on IdentityManagement [14]. Modinis-IDM [26] was an EU fundedidentity management project which focused interoperabilityaspects of identity management systems used in the EUMember States. It aims was to build on expertise and initiativesin the EU Member States to progress towards a coherentapproach in electronic identity management in eGovernmentin the European Union. The study addresses interoperability

issues in cross-context IDM in eGovernment, without ignoringdifferences in legal and cultural practices within the EUframework for data protection. GUIDE [27] was also anEC funded project aiming the creation of an architecturethat will enable open and interoperable eGovernment elec-tronic identity services in the EU. Its objective concernsinteroperability across national systems and structures withinbroader transnational, policy, legislative, and socio-economicboundaries. The PRIME [28] project looked at the applicabilityissues of using the federated identity management systemIdemix open source initiative and digital credentials in detail.The main contribution of this European research project isa broader understanding of the dependencies between thedifferent components in such a system. These dependencies arereflected by both an identity management architecture and anintegrated prototype. FIDIS [29] is a EU-sponsored Networkof Excellence targeting various aspects of digital identity andprivacy. FIDIS areas of interest includes new forms of IDcards, usage of identifiers in information systems, technologiesused for citizen’s identification and profiling. Research projectsin Belgium, such as Identity Management for eGovernment(IDEM) [6], focus on the identity management aspects thatare relevant in an heterogeneous eGovernment context andcompare the different governments in Flanders, Brussels, andWallonia that have to interoperate with the Federal services.

There are some governmental or industrial partners inBelgium in the related fields of IDM or e-health. CrossroadsBank for Social Security (CBSS) [30] is active in the field ofIDM of eGovernment in the social sector. This organizationprovides technical solutions to function as a mediator forcross-context communications among different sectors, andproposed an algorithm to issue one-way only context-specificidentifiers. Custodix [31] is a company active in the e-healthsector. Generally, Custodix is a Trusted Third Party that pro-vides security solutions based on privacy enhancing techniquesat international level. The services lay special emphasis onanonymization and pseudonymization.

IX. CONCLUSIONS

In this paper, we presented a new service for cross-contextidentity management in the e-health application domain, aim-ing to improve interoperability when context-specific informa-tion is transferred between contexts. Previous e-health IDMsolutions mainly have a limited view on patient information,where a user-centric approach for identity management usuallywas restricted to a single healthcare provider. Interoperabilitybecomes more problematic in an e-health system when moreactors collaborate, such as hospitals, GPs, clinical researchlabs, pharmacists... In such systems, it is common for apatient to be issued different unique context-specific iden-tifiers from different healthcare providers. In cross-contextcommunications, the same information can be expressed bymeans of different types or values. Since identifiers are notshared directly among contexts, linkability from one contextto another should not be straightforward. However, other formsof linkability, such as the possibility to follow-up a patient’s

medical treatment, is desirable in the e-health sector, evenwhen it needs to cross different contexts. Therefore, in the e-health context, we design an identity management mechanismin which a mapping and conversion of context-specific iden-tifiers or information occurs when data is exchanged amongdifferent authorized healthcare providers. Further, we proposean algorithm for issuing and converting context-specific iden-tifiers, based on cryptographic techniques. As an illustration ofthe concept, we presented our research activities on the IDMaspect of the EHIP project, with a real-life use case scenarioto explain how the proposed cross-context IDM service can beintegrated in the EHIP e-health platform. As the next step ofour research, we are looking for solutions on how to extend theframework to provide federated authentication and federatedauthorization mechanisms. Further work is needed to definemethods for federation and management of authorizations.

REFERENCES

[1] “Directory technology review - an investigation into the use of directo-ries for developing a management application which can manage bothdata and network services, specifically for the web hosting industry,”http://ldap.artzweb.net/.

[2] A. Josang and S. Pope, “User centric identity management,” AusCERTConference 2005, 2005.

[3] U. S. D. of Health & Human Service, “Hipaa administrative simplifica-tion: Enforcement; final rule,” Federal Register / Rules and Regulations,vol. 71, no. 32, 2006.

[4] E. Union, “Directive 95/46/ec of the european parliament and of thecouncil of 24 october 1995 on the protection of individuals with regardto the processing of personal data and on the free movement of suchdata.” Official Journal of the European Communities, vol. L 281, p.3150, 1995.

[5] C. of Europe, “European convention on human rights,” Martinus NijhoffPublishers, 1987.

[6] “Idem home,” https://projects.ibbt.be/idem/.[7] I. the Healthcare Enterprise (IHE), “It infrastructure technical frame-

work, revision 4.0,” http://www.ihe.net/Technical Framework/, August2007.

[8] “Integrating the healthcare enterprise (ihe) overview,” http://www.ihe.net/.

[9] “Ajax at the open directory project,” http://dmoz.org/Computers/Programming/Languages/JavaScript/AJAX.

[10] “Jsr-286, the java portlet api 2.0,” http://www.jcp.org/en/jsr/detail?id=268.

[11] “Behealth,” https://www.behealth.be/.[12] “hl7 cda release 2.0 hl7/cda, clinical document architecture,” http://www.

hl7.org/library/standards non1.htm.[13] K. Wuyts, R. Scandariato, G. Claeys, and W. Joosen, “Hardening

xds-based architectures,” in International Conference on Availability,Reliability and Security (ARES), March 2008.

[14] M. S. Team, “Modinis study on identity management in egovernment-the conceptual framework version 1.1,” https://www.cosic.esat.kuleuven.be/modinis-idm/twiki/bin/view.cgi/Main/ConceptualFramework,September 2006.

[15] S. W. Group, “Shibboleth overview and requirements,” http://shibboleth.internet2.edu/docs/draft-internet2-shibboleth-requirements-01.html,2001.

[16] T. Scavo and S. Cantor, “Shibboleth architecture, technical overviewworking draft 02,” Internet2/MACE, Tech. Rep., 2005.

[17] “Liberty alliance project whitepaper: Personal identity,” 2006.[18] L. Alliance, “Liberty technology glossary working draft,” http://xml.

coverpages.org/draft-liberty-tech-glossary-08.pdf.[19] “Windows cardspace,” http://cardspace.netfx3.com/.[20] “Idemix: pseudonymity for e-transactions,” http://www.zurich.ibm.com/

security/idemix/.[21] J. Camenisch and E. V. Herreweghen, “Design and implementation of

the idemix anonymous credential system,” IBM Research Division, Tech.Rep., 2002.

[22] L. Peyton, J. Hu, C. Doshi, and P. Seguin, “Addressing privacy in afederated identity management network for ehealth,” in Eighth WorldCongress on the Management of eBusiness WCMeB 2007. IEEEComputer Society, July 2007.

[23] R. Au and P. Croll, “Consumer-centric and privacy-preserving iden-tity management for distributed e-health systems,” in Proceedings of41st Hawaii International International Conference on Systems Science(HICSS-41 2008). IEEE Computer Society, January 2008.

[24] L. L. Iacono, “Multi-centric universal pseudonymisation for secondaryuse of the ehr,” STUDIES IN HEALTH TECHNOLOGY AND INFOR-MATICS, vol. 126, pp. 239–247, 2007.

[25] K. Pommerening and M. Reng, “Secondary use of the ehr viapseudonymisation,” in Medical Care Compunetics 1, L. Bos, S. Laxmi-narayan, and A. Marsh, Eds. IOS Press, 2004, pp. 441–446.

[26] M. S. Team, “Modinis study on identity management in egovernment -home,” https://www.cosic.esat.kuleuven.be/modinis-idm/twiki/bin/view.cgi/Main/WebHome.

[27] “Guide: Creating a european identity manayement architecture for egov-ernment,” http://istrg.som.surrey.ac.uk/projects/guide/overview.html.

[28] “Prime: Privacy and identity management for europe,” http://www.prime-project.org.

[29] “The fidis project website,” http://www.fidis.net/.[30] “Cbss: Crossroads bank for social security,” http://www.ksz-bcss.fgov.

be/En/CBSS.htm.[31] “Custodix home,” http://www.custodix.com/.