A FEDERATED TRIPLE STORE ARCHITECTURE FOR

HEALTHCARE APPLICATIONS

Bruno Alves, Michael Schumacher and Fabian Cretton

Institute of Business Information Systems, University of Applied Sciences Western Switzerland, Sierre, Switzerland

Keywords:

Interoperability, eHealth, Metadata, Semantic web.

Abstract:

Interoperability has the potential to improve care processes and decrease costs of the healthcare system. The

advent of enterprise ICT solutions to replace costly and error-prone paper-based records did not fully convince

practitioners, and many still prefer traditional methods for their simplicity and relative security. The Medi-

coordination project, which integrates several partners in healthcare on a regional scale in French speaking

Switzerland, aims at designing eHealth solutions to the problems highlighted by reluctant practitioners. In

a derivative project and through a complementary approach to the IHE XDS IT Proﬁle, we designed, im-

plemented and deployed a prototype of a semantic registry/repository for storing medical electronic records.

We present herein the design and speciﬁcation for a generic, interoperable registry/repository based on the

technical requirements of the Swiss Health strategy. Although this paper presents an overview of the whole

architecture, the focus will be on the registry, a federated semantic RDF store, managing metadata about med-

ical documents. Our goals are the urbanization of information systems through SOA and ensure a level of

interoperability between different actors.

1 INTRODUCTION

Interoperability is known as the ability for two or

more systems to communicate together. It is a fun-

damental requirement in eHealth for enjoying the

promised beneﬁts of the adoption of electronic med-

ical records (Brailer, 2005). Together with health in-

formation communication, interoperability can make

data available where and when it is required. How-

ever, connecting systems is not enough to overcome

the complexity and heterogeneity of modern health-

care infrastructures. Different systems must under-

stand each other, they need a common knowledge.

Semantic web technologies provide the necessary

level of intelligence to enable communication and

knowledge sharing between disparate systems. Se-

mantics encode the deﬁnition of each element of data,

including its relationships with other elements. Se-

mantic data convey a meaning, which is understand-

able by third parties sharing some common domain

concept knowledge. Semantic interoperability is the

key stone of information processing by computers

(Della Valle et al., 2005a) and a new trend in health-

care informatics.

Multi-level interoperability in health information

communication has the potential to improve the care

processes and decrease costs of the health care sys-

tem (Hillestad et al., 2005). To tackle the high po-

tential of the domain of medical interoperability, but

also respond to potential risks of data abuse, strate-

gies for the interoperability exist in many countries

(Lee et al., 2009)(Ruotsalainen et al., 2008), but also

on European level (CEC, 2008).

In this context, the Swiss Confederation also

started an eHealth strategy late 2006 (OFCOM,

2007). Switzerland deﬁned its strategy relatively late

compared to its neighbors, because of its particularly

fragmented health system. The Swiss eHealth strat-

egy strives to create a clear outline for the next ten

years in managing health data at various scales, and

including participants from a large number of interest

groups. This effort has lead to several concrete propo-

sitions for potential standards for data exchange and

particularly an identiﬁcation of partners in the system.

Based on these standards, we architecture a speciﬁca-

tion for a distributed semantic storage platform, called

Medicoordination.

Medicoordination is a research project taking a

complementary approach to the IHE Proﬁle IT speci-

ﬁcations. It describes a Service-Oriented Architecture

(SOA), which can be used by different medical actors

for sharing patient records. The goal is to provide

207

Alves B., Schumacher M. and Cretton F. (2010).

A FEDERATED TRIPLE STORE ARCHITECTURE FOR HEALTHCARE APPLICATIONS.

In Proceedings of the 12th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

207-214

DOI: 10.5220/0002901102070214

 SciTePress

a fully distributed storage solution for Patient Elec-

tronic Health Records (PEHR). The platform provides

a federated metadata infrastructure allowing seman-

tic descriptions of medical documents and a decen-

tralized repository with versioning and access control

mechanisms sharing strong security policies. The ﬁ-

nality is to be able to exchange documents between

actors working in different IT environments seam-

lessly and achieve a high-level of interoperability in

completely opaque and heterogeneous environments.

Although Medicoordination is a wide project in-

volving several components and modules, this paper

concentrates on a speciﬁc point: the metadata sys-

tem architecture or Metadata Service Layer (MSL). It

consists in a federated RDF store, where metadata is

stored as triples. This paper provides ﬁrst an overview

of the global architecture and proposes a view on the

models, the derived architecture and a partially imple-

mented prototype based on it.

2 RELATED WORK

The problem of the integration and exchange of dis-

tributed health data has already been thouroughly dis-

cussed in many articles, among which (Lenz et al.,

2007)(McMurry et al., 2007)(Bergmann et al., 2007).

At the international level, large projects exist try-

ing to solve the typical interoperability gap, which

exists between hetegenous medical systems. The

COOCON (Della Valle et al., 2005b) project aims at

supporting health care professionals in reducing risks

in their daily practices by building knowledge driven

and dynamically adaptive networked communities

within european healthcare systems. The ARTEMIS

(Dogac et al., 2006) project proposes semantically en-

riched Web services in the healthcare domain in order

to seamlessly connect medical institutions running

heterogenous IT systems and exchange distributed

medical data.

At the country level, most countries propose re-

lated initiatives. In Germany, for example, the

bIT4health (better IT for better health) project de-

scribed in (Blobel and Pharow, 2007) attempts to es-

tablish a telematics platform supporting seamless care

combined with card enabled communication.

In our project Medicoordination, unlike many

other presented here before, we focus on the distri-

bution of the metadata, rather than the distribution

of the documents. We attempt to model a Virtual

Patient Record (VPR), described in (Records, 1997),

supported by a distributed metadata architecture pre-

serving the local ownership of the documents, while

allowing patient consent on a per-document basis.

3 METHODS

The objective of the MediCoordination project is de-

signing a decentralized management system for med-

ical records that can be shared among regional care

institutions. The system is composed of a registry, a

repository, identity services and a coordination layer.

It intends to address several integration problems with

existing IT infrastructures and interoperability issues.

This paper is focused on the registry component of the

system. We describe herein the models resulting in

a proposal of a technology-independent architecture

and a partially implemented prototype of a federated

metadata system.

The design of the system was constrained by

recommendations made by the Swiss confederation

eHealth coordination group. This organization pro-

vides recommendations on standards and technolo-

gies for Swiss pilot projects. It recently released

a document on eHealth architecture guidelines (E-

Healthsuisse, 2009). These guidelines are grouped

into three points of focus: security, distribution and

information management and exchange. Security en-

compasses patient security, privacy, conﬁdentiality,

data protection and transparency. Distribution relates

to decentralized structures, federalism, separation of

roles, concerns about who owns the data and who

can access it and integration of existing infrastruc-

tures and technology. Finally, data management and

exchange relates to processes for data management.

Also, the metadata architecture is based on three

models, which are derived from these points of fo-

cus. The distribution model speciﬁes the distributed

structure, which sustains the system; the data model

describes how the metadata is speciﬁed and commu-

nicated; and ﬁnally, the security model describes the

security mechanisms and how they are applied.

3.1 Distribution Model

According to the recommendations, institutions

should manage documents they generate. Since

Switzerland is a highly fragmented country and dis-

tribution is required, a federated architecture is fore-

seen. Each node of the federation is a service accessi-

ble from the Web that can store metadata for the docu-

ments it issues. Nodes are connected in a hierarchical

structure and distributed queries are performed glob-

ally on the network.

Besides regular metadata nodes, there also ex-

ist forwarding nodes, known as query hubs. These

”dummy” nodes forward the queries they receive and

aggregate results according to the some environmen-

tal policies. Forwarding nodes cannot be used to write

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

208

Figure 1: Storage architecture.

or read data directly, but they are involved in the orga-

nization of the network mesh. The federation of meta-

data nodes is built passively, i.e there is no discovery

mechanism. A regular metadata node, such as RSV

in Figure 1 must notify its existence to a query hub,

or High Valais in this case. This construction allows

deﬁning security domains as a group of nodes sharing

the same security policies. The concept of ”security

domain” is explained in the next sections.

3.2 Data Model

The current data model does not rely on semantics;

however, we wanted to prepare the architecture for a

future revision with semantic capabilities. Metadata

in MSL basically consists in properties about the doc-

uments, such as ﬁle type, ﬁle identiﬁer, author, date,

etc. Since a large share of inferencing systems, among

which Pellet and Racer, are based on RDF, document

attributes in MSL are expressed using triples in the

RDF format. A very simple ontology created with

Protg was developed for the prototype.

3.3 Security Model

The security model is broken into three sub-models:

link-level security, authentication and authorization

models.

Link-level security ensures the conﬁdentiality and

the integrity of the data by encrypting the communi-

cation channel. Certiﬁcate-based standards such as

SSL/TSL 1.0 are typically used to encrypt the com-

munication between endpoints. However, SSL does

Figure 2: Security model.

not prevent potential modiﬁcations of the SOAP mes-

sages between the application and the transport layer

of the OSI Model. It is thus necessary to complement

channel security with message-level protection mech-

anisms. Web Services Security (WSS) is a set of se-

curity policies based on XML, which provides primi-

tives for encrypting, protecting and signing messages.

Besides link-level protection, it is important to en-

sure that only authenticated parties gain access to the

resources. The difﬁculty of the MSL authentication

model resides in the distributed nature of the service.

Resources are spread all over a federated network and

it is crucial to prevent access to users who are not au-

thenticated to current node. The authentication model

of the MSL relies on the concept of domains. A group

of nodes sharing the same security policies (hospital

campus, care services ...) is called a domain. Authen-

tication is performed only once and users can directly

access resourceson nodes from the same domain, pro-

vided they have sufﬁcient privileges.

Authenticating users do not ensure however that

they are granted access to resources. For users to gain

privileges on them, it is necessary to deﬁne authoriza-

tions on documents. MSL uses a RBAC (Role-Based

Access Control) model for controlling the access to

the resources. Patients and medical staff are aggre-

gated into roles, which are assigned speciﬁc privileges

(read, write) on resources. Privileges are veriﬁed and

validated by the repository in order to prevent or grant

access to a category of users. Patient and medical staff

information is stored into special databases, named

Patient Index Store and Professional Index Store.

A FEDERATED TRIPLE STORE ARCHITECTURE FOR HEALTHCARE APPLICATIONS

209

Figure 3: Medicoordination Healthcare Infrastructure.

4 RESULTS

This section presents the global architecture, but fo-

cuses on the architecture of the MSL. It also gives an

insight into a possible implementation.

4.1 Global Architecture Overview

Figure 3 presents the Medicoordination Healthcare

Infrastructure or MHI. It is composed of the Metadata

Service Layer (MSL - registry), the Storage Service

Layer (StoSL - repository), Medicoordination Service

Layer (MeSL - a coordinator service) and of Identity

Services (IS - index stores for both patients and med-

ical staff).

The storage service handles requests for reading

and writing medical documents. The metadata asso-

ciated to these documents is stored in a metadata node

(from the issuer of the document), while the document

contents are stored on the storage node. The role of

the storage service is to manage health resources, or-

ganise documents in a patient medical record, main-

tain revisions of the ﬁles and perform sporadic audits.

The Medicoordination coordinator service repre-

sents the glue between all the components of the in-

frastructure. It is responsible for coordinating the reg-

istration and storage of the medical documents, while

verifying the authorizations of the parties involved

in the process (practitioners, medical doctors and pa-

tients). The Identity Services encompass Professional

Index Stores, Patient Index Stores and Role Servers.

A Role Server aggregates identities under a common

denomination with common rights on a particular set

of documents. The access rights for the roles are spec-

iﬁed in the metadata for the moment and must be veri-

ﬁed by the storage service. Besides that, Identity Ser-

vices also provide authentication mechanisms, which

can be endorsed by the Role Server itself. An authen-

tication service is responsible for issuing tokens for

the local domain and for the veriﬁcation of foreign

tokens issued by another domain.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

210

Figure 4: MSL architecture overview.

4.2 MSL Overview

The Metadata Service Layer is a federated metadata

system, which goal is to store information about frag-

ments (i.e: documents composing a medical record),

so that the information care professionals need is im-

mediately available anywhere within the country.

The architecture is normally intended to be inde-

pendent of any technology; however, we opted for

communication using the Simple Object Access Pro-

tocol (SOAP 1.1 and 1.2) standard. This choice is pri-

marily related to the excellent support for secure com-

munications using the Web Services Security (WSS)

speciﬁcation.

Figure 4 presents the global architecture of the

MSL. Each node is a Web Service endpoint provides

four primitives: read(), write(), remove() and query().

Primitives work with graphs (set of triples about the

same subject) and it is the role of the coordinator ser-

vice to break up the initial metadata into triples. Meta-

data is stored in a database of triples (triple store) and

is protected by a policy mechanism. The service is

protected and requires authentication.

4.3 Representing Information about

Documents

Meta-information or metadata about documents is re-

lated to the properties of the ﬁles.

4.3.1 Representing Metadata as Triples

Metadata can be represented as a set of RDF triples

referring to the same subject. RDF is a graph model

language originally used as a metadata data model.

RDF is not tied to a particular data format, but is often

associated with XML and is called RDF/XML. RDF

consists in graphs of triples referring to a same sub-

ject and allows expressing simple predicates (subject-

property-object). For example, expressing that a

particular fragment contains content about allergies,

would yield the following triples (in N-Triples nota-

tion):

<http://medicoordination.ch/frag/1a23dd12>

<http://medicoordination.ch/onto/is-about>

’Allergies’ .

The data model of the MSL does not impose any par-

ticular metadata requirements. However, there exist

metadata deﬁnition initiatives for describing medical

documents, such as (Malet et al., 1999). The metadata

system described here does not strictly require infer-

ring new triples when adding new data. In the pro-

totype MSL, metadata was limited to the use of ﬁle

properties and attributes like date, author, recipient,

etc. Since those metadatas are just properties of a sin-

gle object and thus have no relationship, they do not

need inferencing. This behaviour is intended for this

ﬁrst speciﬁcation of the architecture. Because docu-

ments are spread all over the network, metadatas on

two different nodes can relate to each other and thus,

could require a distributed inference. Distributed rea-

soning patterns are very difﬁcult to implementand are

still a ﬁeld of active research (Schenk and Petr´ak,

2008)(Fang et al., 2008).

4.3.2 Storing Metadata

Metadata is stored in a database of RDF triples, which

is called an RDF store. The MSL provides an inter-

face abstracting their behaviour: the AbstractStore.

The implementation of new types of stores can be

supported by any library supporting RDF, such as

Jena or Virtuoso. Stores are loaded at run-time either

programmatically or from a conﬁguration ﬁle.

4.3.3 Managing Access to Metadata

The AbstractStore provides almost the same interface

the Web service provides, except that its access is re-

stricted by the use of policies. Policies, which are

illustrated in Figure 6, represent a barrier between the

users and the store. Policies allow controlling the data

ﬂow between the user and the resource. They can be

used to verify access authorizations, implement secu-

rity mechanisms or transform the input/output data.

A FEDERATED TRIPLE STORE ARCHITECTURE FOR HEALTHCARE APPLICATIONS

211

Figure 5: MSL storage architecture overview.

There is only one active policy for each service prim-

itive (read, write, remove and query) and it is deﬁned

in a conﬁguration ﬁle, but can be changed program-

matically at run-time.

Figure 6: Policy mechanism overview.

When a service call is triggered, the PolicyMan-

ager class ﬁnds the active Policy for that method and

invokes it. The Policy class then accesses the Ab-

stractStore, but can perform some transformations or

access control of the data it receives. This mecha-

nism is particularly useful in the context of distributed

queries.

4.3.4 Federating Nodes

Although a MSL node is intended to work in a fed-

erated network topology, it provides no mechanisms

for constructing the federation. This limitation allows

on the other hand reusing the service in other environ-

ments.

Regular and forwarding nodes must be registered

in federated structure supported by an external frame-

work. The prototype uses WSDIR (Schumacher et al.,

2007), a federated directory system which allows reg-

istration and discovery of semantic web services to

build the federation. Each service is registered in a

node of the WSDIR service and it is then used to ﬁnd

all metadata nodes registered in the federation chil-

dren nodes.

4.3.5 Handling Queries in a Federation - from

Query Resolution to Execution

Metadata nodes do not have any knowledge of the

other nodes. The federation access mechanisms are

handled at the policy level. In this particular case,

only queries need distribution, because reading, writ-

ing and removing is done locally. Federated queries

are handled at the policy level. The prototype appli-

cation implements a FederatedQueryPolicy that ﬁrst

performs the query locally and then forwards it to the

other MSL nodes (children). Finally, it aggregates the

results and forwards it to the calling node until the

user gets a response.

4.4 Security Considerations

The MSL uses a policy-based design in order to pro-

tect access to the underlying service RDF store. There

exist a policy class for each service primitive (read,

write, remove and query), preventing unauthorised in-

bound and outbound accesses to the resources.

Policies play a double role in the design of the

architecture. First, they allow delaying the secu-

rity decisions to a latter implementation phase, al-

lowing thus concentrating on other programming as-

pects. Policies are deﬁned at run-time in a conﬁgura-

tion ﬁle. Second, policies allow applying protection

mechanisms (resource observation) at the lowest lev-

els (access level).

However, protecting the access to resource is not

sufﬁcient to prevent data stealing and data conﬁden-

tiality problems. The MSL architecture speciﬁcation

deﬁnes mechanisms to ensure the security of the com-

munication medium, conﬁdentiality and integrity of

the messages as well as resource access protection

through authentication and access control.

4.4.1 Securing the Communication Channels

The MSL communicates with the user, with other

nodes and the authentication server. It is important

to SSL-encrypt the communication channel between

all parties. Encrypting the communication between

the node and the authenticator service is important

in order to protected the token. Encrypting the com-

munication between the user and the node is neces-

sary to prevent data conﬁdentiality loss and document

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

212

stealth. Encrypting the communication between two

nodes is important in order to avoid eavesdropping

on the metadata. The prototype application uses SSL

with certiﬁcates on the service.

4.4.2 Securing the Inter-component Messages

As said previously, SSL only encrypts the TCP/IP

message payload from the transport layer of the OSI

Model to the transport layer of the remote host. It

is thus possible to forge a new message or modify

it (XML). WSS primitives allow to encrypt and sign

(XML Signature) messages. The prototype applica-

tion does not currently implement SAML tokens, but

uses custom tokens, which are passed to the service

methods. Custom tokens are validated by the service

itself.

4.4.3 Securing the Access to Resources

Access to the resources uses a RBAC access con-

trolling scheme. Users are associated roles on the

Role Server and are assigned speciﬁc access rights.

These rights are deﬁned in the metadata as read id

and write id. Each of these properties accepts a list

of roles as a value, specifying roles able to read or

write. Describing access lists in the metadata makes it

easy for authenticated and authorized patients or pro-

fessionals to change access rights when needed, but

also describing access rights on a document level.

4.4.4 Authenticating Users

The federated network is distributed into domains,

which are clusters of nodes sharing the same secu-

rity policies. Inside a domain, there is one single au-

thenticator service, which can be a Kerberos server, or

anything else that allows single sign-one. However,

supporting security domains supposes the authentica-

tion server to be able issuing security tokens. The Se-

curity Assertion Markup Language (SAML) enables

”portable trust” by supporting the assertion of au-

thentication of single principals between different do-

mains and is thus the recommended speciﬁcation for

authentication across multiple domains. The proto-

type application currently has no support for external

authentication. Instead it authenticates users them-

selves on the local level. So, the only way to support

domain authentication is through a shared database of

credentials.

5 DISCUSSION

The Medicoordination architecture has similarities

with IHE XDS in the sense that it is constituted of

a registry, a document repository and of afﬁnity do-

mains. However, Medicoordination supports RDF

metadata in a federated scheme. The advantage of a

federated triple store is to provide a high level of data

”semantization” and allowing each health care actor

to manage its own documents while providing a de-

centralized storage. Very advanced searches are then

possible on the documents. It is feasible to return a

list of accessible documents for each patient which

has a particular disease with speciﬁc symptoms. The

beneﬁts of Medicoordination are to give a speciﬁ-

cation particularly well adapted for the Switzerland.

Since each canton has its own policies on terms of

healthcare, it is convenient to have a solution with

provides decentralized storage and meta-information

while giving the full control of data to local authori-

ties. For example, a hospital, which is also a Medico-

ordination metadata node, can manage and control in-

formation about all documents produced by itself, but

can also share them with the other institutes. They are

part of a global federation across the country, but are

local to a healthcare institute. Furthermore, the Medi-

coordination architecture does not impose the choice

of a speciﬁc infrastructure or implementation. It only

gives some guidelines about how the speciﬁc parts

should work together. Medicoordination is also in-

tended to adapt to existing infrastructures. It only re-

quires thin and small clients to make the bridge be-

tween the healthcare information technologies used

by the care institutions and the platform. A part of

the existing application already supports such exten-

sions through plugins. In order to validate our results,

a full prototype has still to be implemented.

6 CONCLUSIONS

This paper introduced an architecture to be used in

situations where the heterogeneity of systems pre-

vents classic interoperability solutions to work. We

did not dig into low-level concepts to remain inde-

pendent of any architecture. The implementation of

systems based on Medicoordinationnecessitates care-

ful thought on how to get different parts working to-

gether. Medicoordination, as a research project is in-

tended to give some guidelines about a possible ar-

chitecture for electronic healthcare infrastructure co-

operation, which empowers each healthcare actor to

manage its own data, while providing a ﬂexible plat-

form, which adapts to existing standards and infras-

A FEDERATED TRIPLE STORE ARCHITECTURE FOR HEALTHCARE APPLICATIONS

213

tructures. Future development of the Medicoordina-

tion architecture may involve modiﬁcations to make it

partially compatible with IHE XDS Afﬁnity Domains

and XDS repositories. This is a necessary develop-

ment since the use of IHE proﬁles seems to be in the

focus of the Swiss Confederation eHealth Strategy.

Future work will also include a more detailed speciﬁ-

cation based on new communication standards linked

to semantic web activities.

REFERENCES

Bergmann, J., Bott, O., Pretschner, D., and Haux, R. (2007).

An e-consent-based shared EHR system architecture

for integrated healthcare networks. International jour-

nal of medical informatics, 76(2-3):130–136.

Blobel, B. and Pharow, P. (2007). A model driven ap-

proach for the german health telematics architectural

framework and security infrastructure. International

Journal of Medical Informatics, 76(2-3):169 – 175.

Connecting Medical Informatics and Bio-Informatics

- MIE 2005.

Brailer, D. (2005). Interoperability: the key to the future

health care system. Health Affairs, 24(1):19–21.

CEC (2008). Commission Recommendation on cross-

border interoperability of electronic health record

systems (notiﬁed under document number C(2008)

3282). Ofﬁcial Journal of the European Union.

Della Valle, E., Cerizza, D., Bicer, V., Kabak, Y., Laleci, G.,

and Lausen, H. (2005a). The need for semantic web

service in the eHealth. In W3C workshop on Frame-

works for Semantics in Web Services.

Della Valle, E., Gadda, L., and Perdoni, V. (2005b). CO-

COON: Building knowledge driven and dynamically

networked communities within european healthcare

systems. Presented at Med-e-tel 2005 Conference in

Luxembourg.

Dogac, A., Laleci, G., Kirbas, S., Kabak, Y., Sinir, S.,

Yildiz, A., and Gurcan, Y. (2006). Artemis: deploying

semantically enriched web services in the healthcare

domain. Information Systems, 31(4-5):321–339.

E-Healthsuisse (2009). Cybersant´e Suisse: Normes et ar-

chitecture, Premieres recommandations.

Fang, Q., Zhao, Y., Yang, G., and Zheng, W. (2008). Scal-

able distributed ontology reasoning using DHT-based

partitioning. In Proceedings of the 3rd Asian Semantic

Web Conference on The Semantic Web, pages 91–105.

Springer.

Hillestad, R., Bigelow, J., Bower, A., Girosi, F., Meili, R.,

Scoville, R., and Taylor, R. (2005). Can electronic

medical record systems transform health care? Poten-

tial health beneﬁts, savings, and costs. Health Affairs,

24(5):1103.

Lee, M., Min, S., Shin, H., Lee, B., and Kim, J. (2009).

The e-Health Landscape: Current Status and Fu-

ture Prospects in Korea. TELEMEDICINE and e-

HEALTH, 15(4):362–369.

Lenz, R., Beyer, M., and Kuhn, K. A. (2007). Semantic inte-

gration in healthcare networks. International Journal

of Medical Informatics, 76(2-3):201 – 207. Connect-

ing Medical Informatics and Bio-Informatics - MIE

2005.

Malet, G., Munoz, F., Appleyard, R., and Hersh, W. (1999).

A model for enhancing Internet medical document re-

trieval with” medical core metadata”. Journal of the

American Medical Informatics Association, 6(2):163.

McMurry, A., Gilbert, C., Reis, B., Chueh, H., Kohane, I.,

and Mandl, K. (2007). A self-scaling, distributed in-

formation architecture for public health, research, and

clinical care. Journal of the American Medical Infor-

matics Association, 14(4):527.

OFCOM (2007). Strat´egie Cybersant´e (eHealth) Suisse .

Records, P. (1997). Virtual Patient Records. COMMUNI-

CATIONS OF THE ACM, 40(8):111.

Ruotsalainen, P., Iivari, A., and Doupi, P. (2008). Fin-

land’s strategy and implementation of citizens’ access

to health information. Studies in health technology

and informatics, 137:379.

Schenk, S. and Petr´ak, J. (2008). Sesame RDF Repository

Extensions for Remote Querying. In ZNALOSTI Conf.

Schumacher, M., Pelt, T. v., Constantinescu, I., and Falt-

ings, B. (2007). Wsdir: A federated directory system

of semantic web services. In WETICE ’07: Proceed-

ings of the 16th IEEE International Workshops on En-

abling Technologies: Infrastructure for Collaborative

Enterprises, pages 98–103, Washington, DC, USA.

IEEE Computer Society.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

214