A Peer to Peer Agent Coordination Framework for IHE based ... · IHE pro les that address interoperability between health care systems. We focus on three pro les that propose so-lutions

A Peer to Peer Agent Coordination Framework for IHEbased Cross-Community Health Record Exchange

Visara UroviUniversity of Applied Sciences

Western SwitzerlandSierre, Switzerland

[email protected]

Alex C. OlivieriUniversity of Applied Sciences


[email protected]

Stefano BromuriUniversity of Applied Sciences


[email protected]

Nicoletta FornaraUniversità della Svizzera

italianaLugano, Switzerland

[email protected]

Michael I. SchumacherUniversity of Applied Sciences


[email protected]

ABSTRACTThis paper presents a Peer to Peer (P2P) agent coordinationframework for the exchange of Electronic Health Records(EHR) between health organisations that comply with theexisting interoperability standards as proposed by the Inte-grating Healthcare Enterprise (IHE). Every health organi-sation represents a community in a P2P network and uses aset of autonomous agents and a set of distributed coordina-tion rules to coordinate the agents in the search of specifichealth records. To model the interactions among commu-nities, the framework uses the tuple centre agent commu-nication model and semantic web technologies. In order toillustrate the scalability of our approach, we evaluate theproposed solution in distributed settings.

Categories and Subject DescriptorsH.4 [Information Systems Applications]: Miscellaneous

General TermsDesign, Experimentation

KeywordsDocument exchange, EHR, IHE, Semantic Interoperability,Coordination, TuCSoN, OWL.

1. INTRODUCTIONElectronic Health Records (EHRs) refer to the electronic

collection of health information data about individual pa-tients [13]. The advantage of EHRs is that information can

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SAC’13 March 18-22, 2013, Coimbra, Portugal.Copyright 2013 ACM 978-1-4503-1656-9/13/03 ...$10.00.

be quickly transferred and linked to best-practice guidelinesto provide decision support [12]. EHR based systems oftenoperate in a closed environment where patient’s EHRs canbe exchanged only within one organisation. As the focusof health care delivery shifts from specialist centers to com-munity settings [7], new research approaches are focusingon the integration of such records across the institutionalboundaries [26].

Integrating the Healthcare Enterprise (IHE)1 is an initia-tive focusing on integration of healthcare information sys-tems. IHE makes a major contribution to integration ofthese systems and enjoys high acceptance due to its practi-cal complement to existing standards such as HL7 CDA2, astandard supporting message-based information exchange ofmedical data. The significance of the IHE profiles stands onthe fact that they are constantly checked against practicalexperiences and are continuously adapted [26]. Despite this,IHE lacks features to handle dynamic scenarios where care-givers can dynamically connect and exchange data [17], andmechanisms on how patient’s data are found and exchangedare yet to be defined.

To address these problems, a system is needed where up-to-date patient’s health records can be shared without priorknowledge of the health organisations that produced thedata. In particular, semantic description of content has beenrecognised as a powerful tool for data sharing [14], that,combined with agent-based computing, can contribute toautomate the collection and processing of patient’s EHRs.Agent-based systems can perform distributed communica-tion and reason with semantic knowledge thus enabling EHRsharing between such heterogeneous systems. Furthermore,agent coordination models, such as tuple centres [23], thatfocus on decoupling the interaction amongst the actors, cancontribute on making the different health actors more in-teroperable. On top of coordination models, a Peer to Peer(P2P) [2] solution can link the heterogeneous health organ-isation’s systems as peers, allowing them to interact on topof existing network configurations and remove any centraldependency for sharing patient EHR. P2P networks have

1http://www.ihe.net2http://www.hl7.org

1355

© ACM, 2012. This is the author's version of the work.

It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in

Proceedings of the 28th ACM Symposium On Applied Computing (SAC 2013) http://dl.acm.org/citation.cfm?id=2480617

the advantage that they scale up for a large number of peersand are more reliable that single server architectures.

In this paper we propose an orthogonal solution to theexisting IHE profiles that deal with EHR exchange. We pro-pose a P2P agent coordination framework that enables var-ious health organisations to discover and to exchange EHR.The contribution of this work is that it provides a generalP2P agent coordination framework that extends the exist-ing interoperability standards with the ability to dynami-cally exchange EHR between different health organisations.In particular, we extend the current IHE profiles with theability to dynamically connect to other communities thatcomply with such profiles. Furthermore we use semantics toautomatically interpret the shared knowledge between differ-ent healthcare environments and to define the agent-basedcoordination mechanisms that coordinate the exchange andinterpretation of such medical knowledge.

The rest of this paper is organised as follows: Section 2 de-scribes our motivating case study, Section 3 summarises thebackground work for our coordination framework; Section4 describes how we engineer the agent-based coordinationframework to deal with the exchange of EHRs; Section 5describes the implementation of the system; Section 6 eval-uates the performance of the system; Section 7 discussesrelevant related work in the area of Semantic Interoperabil-ity and Multi-Agent Systems solutions in the eHealth field;finally, Section 8 summarises the work and draws the linesfor future works.

2. MOTIVATING CASE STUDYOur scenario is based in Switzerland, a federal country di-

vided into 26 counties called cantons. The health system ofSwitzerland is a combination of public (i.e. hospitals) andprivate systems (i.e. doctors in private clinics) and healthconditions can be treated in any of the competent health-care providers. The Swiss Government has recently recom-mended the adoption of IHE profiles to achieve interoper-ability. The first pilot deployments have just been released,such as the eToile project [10] in Geneva.

In this scenario, Mrs. Roux from Lausanne, canton Vaud,needs urgent hospital care due to a strong chest pain inSierre, canton Valais, where she is on holiday. Previouslyshe had a heart surgery in the Hospital of Lausanne, whichis also her home community and keeps all the updates onMrs. Roux health records. The home community, does notnecessarily has a copy of all the generated documents for MrsRoux, but it knows where every document is stored. Mrs.Roux has signed a privacy consent that allows the Hospitalof Lausanne to share her health records with other communi-ties. The identifier of the insurance card of Mrs Roux is usedto search for her data in the Hospital of Lausanne. Based onthe privacy consents given by Mrs. Roux, the query returnsmeta-data held on Mrs. Roux’ records (attributes describingher health documents but not the documents).

The doctor who visits Mrs Roux can view the discov-ered information and can consult the documents of interestby retrieving the content from the community where thesedocuments are stored. This is possible because Mrs Roux,through a web application, gave to medical doctors the rightto access her medical data. The doctor asks for further teststo be carried out in the hospital of Sierre. After Mrs. Roux’agreement, the tests and the doctor’s diagnosis are noti-fied to the hospital of Lausanne. The general practitioner

(GP) and the cardiologist treating Mrs. Roux are subscribedwith the hospital of Lausanne to receive notifications of newgenerated data on Mrs Roux. Hospital of Lausanne auto-matically notifies the case to her two doctors. Next time,when Mrs Roux visits such facilities, her doctors can viewthe relevant new information generated on Mrs Roux.

3. BACKGROUND WORKMotivated by our scenario, we define a P2P agent coordi-

nation framework that supports health communities to dy-namically connect, search, send and receive updates on pa-tient relevant data between one another. The choice of theP2P network is motivated by the need to have a scalable so-lution for a large number of health communities. This workextends upon the existing IHE profiles that deal with EHRexchange. In this section we explain the background worksrelated to our framework.

3.1 IHE Limitations in EHR exchangeThe IHE defines technical frameworks for different clini-

cal and organisational domains. An important part of theseframeworks are the integration profiles, which are definedin terms of actors and transactions. Actors are componentsthat act on information associated with clinical and opera-tional activities in the enterprise. Transactions are interac-tions between actors that communicate the required infor-mation through standards-based messages. There are manyIHE profiles that address interoperability between healthcare systems. We focus on three profiles that propose so-lutions for the exchange of EHRs, namely Cross-EnterpriseDocument Sharing (XDS), Cross-Community Access (XCA)and Cross-Community Patient Discovery (XCPD).

The XDS [18] profile defines how health enterprises caninter-operate to share patient-relevant documents by work-ing as one community with the same set of policies, patientidentifications and security mechanisms. In XDS, the dataproduced on a patient can be stored in a distributed way.However a set of meta-data regarding the record must bestored in a central registry which is later used to find thesedocuments. Since XDS does not resolve document shar-ing among multiple communities, the XCA profile specifieshow medical data held by other communities can be queriedand retrieved. XCA assumes that communities have pre-established agreements and knowledge of one another. Italso assumes that the community which initiates a query to-wards another community, can determine the correct patientidentifier of the patient under the authority of the receivingcommunity [17]. Finally, XCPD locates communities whichhold patient’s relevant health data and to translate patient’sidentifiers across communities. XCPD does not automatethe discovery of communities and it still requires communi-ties to have pre-established agreements for exchanging thedocuments. In fact, the actor searching for documents in thecross-community must know beforehand which communitiesto contact.

If we were to model our case study only with the currentIHE profiles, we would encounter several limitations. Wecould use XCPD to locate Mrs Roux identity in the hospitalof Laussanne. However, in order to exchange the data, thetwo hospitals should have an agreement and the necessaryintegration in place to allow data exchange between the two.This is because IHE profiles define interactions as a simplemessage exchange and, in order for communities to interact,

1356




they need to know a priory which community to address.Nowadays this is not the case as patients move considerablyand they may seek medical attention in different healthcarecommunities that may not know each other. Even if we as-sume that every IHE community can achieve point to pointintegration with every other IHE community, we still havethe problem of defining proactive propagation of health in-formation in other communities. In fact, we can use theXCA profile to query the Hospital of Lausanne about Mrs.Roux’ data, but, it is not possible to propagate the updateson her records to all the interested caregivers (that is nota direct communication between two caregivers). We canimagine that in the near future, patients will use differenthealth services with some guarantee that their health recordscan be viewed by the different service providers responsiblefor their care. The advantage of such integration is thatit fosters better patient care and it helps to avoid mistakesthat happen with limited patient information.

Motivated by the lack of support mechanisms in the aboveIHE specifications, we complement the IHE approach to en-able communities to exchange data without prior knowledgeof each other. We assume that a set of IHE complianthealthcare systems will be using our framework to discoverand exchange information with other healthcare systems.Our proposed solution extends upon the existing XDS pro-file to allow any health community to dynamically exchangeEHR without undergoing the point to point integration thatwould be needed with the current IHE models. The dynamicnature of the network we want to create requires a coordi-nation model able to provide uncoupling among the com-munities. This is why we choose a coordination middleware,such as TuCSoN [20], which provides a general approach forcombining semantics with coordination of messages for thepurpose of EHR exchange. One limitation of TuCSoN isthat it has an unstructured P2P model which considerablyincreases the time to answer semantic queries as reportedin [25]. To overcome this limitation, we define a structuredP2P model to reduce the number of propagated semanticsearch queries and to improve the performances.

3.2 Coordination in TuCSoNTuCSoN [23] is an agent coordination infrastructure based

on the concept of blackboard systems, like Linda [11]. InTuCSoN, interactions are mediated by shared tuple centres.The interacting entities of TuCSoN can use the tuple cen-tres to write, consume and read tuples without necessar-ily having to synchronise (time decoupling), share the samespace (space decoupling) or even without knowing each other(name decoupling) [11]. In addition to these advantages,the interacting entities communicate by writing and readingRDF triples, making them schema decoupled too [4]. Withthese advantages, the mediation mechanisms improve con-siderably the interoperability of EHR exchanging systemsas opposed to the simple message exchange. Apart fromreading, writing and consuming semantic tuples, TuCSoNallows to engineer additional primitives to coordinate theinteracting entities.

Agents in TuCSoN interact through tuple centres by in-serting (out operation), reading (rd operation) and consum-ing (in operation) tuples. Tuples are read and retrieved as-sociatively. In order to read or retrieve a tuple, a tupletemplate has to be specified so that it can be used to findthe requested tuple among all the existing tuples in the tuple

centre [20]. The tuple centres can be syntactic, meaning thatthe structure of the tuple templates are known to the agents,or semantic, meaning that the information is produced andconsumed following an ontology model. The behaviour ofthe tuple centres is programmable with a set of coordina-tion rules expressed in the ReSpecT language [22]. UsingReSpecT it is possible to define reactions that specify howa tuple centre reacts to incoming/outgoing communicationevents. The reaction rules syntax is defined as follows:

reaction(action, conditions, react).

where action is an operation made in a tuple centre (suchas out(tuple)), conditions specify the conditions that shouldbe verified in order to execute the react and react specifiesa set of communication events that take place as a conse-quence of the performed action. In a ReSpecT reaction it isalso possible to specify communication events (out, in, rd)towards other tuple centres. This is possible because tuplecentres are hosted in nodes and distributed in a network [6].Every node can host many tuple centres and there can bedirect communications between distributed tuple centres byaddressing the right tuple centre. In addition to point topoint communications between tuple centres, using a struc-tured P2P network enables us to search the location of therequired information.

3.3 OWL DL and query languageTuCSoN uses the OWL Web Ontology Language [15] to

model semantic tuple centres in terms of domain ontologiesand objects [20]. OWL is a practical realization of a De-scription Logic known as SHOIN (D) [16]. Using OWL itis possible to define classes (also called concepts in the DLliterature), properties, and individuals. An OWL ontologyconsists of a set of class axioms that specify logical rela-tionships between classes, which constitutes a TBox (Ter-minological Box); a set of property axioms to specify logicalrelationships between properties, which constitutes a RBox(Role Box); and a collection of assertions that describe in-dividuals, which constitutes an ABox (Assertional Box).

Classes are formal descriptions of sets of objects (takenfrom a non empty universe), and individuals are names ofobjects of the universe. Properties can be either object prop-erties, which represent binary relations between objects ofthe universe, or data properties, which represent binary rela-tionships between objects and data values (taken from XMLSchema datatypes). Class axioms allow one to specify thatsubclass (v) or equivalence (≡) relationships hold betweencertain classes and the domain and range of a property. As-sertions allow one to specify that an individual belongs toa class: C(a) means that the object denoted by a belongto the class C; and that an individual is related to anotherindividual through an object property: R(b,c) means theobject denoted by b is related to the object denoted by cthrough the property R. Complex classes can be specifiedby using Boolean operations on classes: C t D is the unionof classes, C u D is the intersection of classes, and ¬ C is thecomplement of class C. Classes can be specified also throughproperty restrictions: ∃ R.C denotes the set of all objectsthat are related through property R to some objects belong-ing to class C at least one; if we want to specify to how manyobjects an object is related we should write: ≤nR, ≥nR, =nRwhere n is any natural number.

To realise the framework presented in this paper, we need

1357




to express the conditions part of the reaction rules with in-structions that reason on the semantic model. Thus, everycondition is evaluated by quering the reasoning services ofan OWL DL reasoner, sometimes Prolog predicates are usedto construct some specific function. Given that there is notan official standard query formalism for OWL DL, we adoptthe following formalism that is inspired from [5] and whichallows to express the queries that are available in the DLQuery tab of Protege3. In our implementation those queriesare executed using the JENA API:

?-C v D ⇒ true/false checks the subclass relationship;?-C ≡ D ⇒ true/false checks class equivalence;?-C ⇒ true/false checks if the class is satisfiable;?-C(a) ⇒ true/false instance checking;?-C(*) ⇒ {a1,....an} retrieval, C can be a complex class.

3.4 Structured P2PA P2P system consists of distributed and interconnected

nodes able to self-organize into network topologies withoutrequiring the support of a centralized authority [2]. P2Pnetworks can vary from unstructured to structured topol-ogy. Unstructured P2P networks use flooding to search forpeers with the disadvantage that the messages considerablyincrease with the number of peers. In large-scale networks,in order to reduce the number of exchanged messages, struc-tures can be established within the P2P network. In a struc-tured network, a query is not forwarded to all peers, as in un-structured P2P systems, but only to a selected set of peers.The selection is based on a distance metric that finds thepeers that are close neighbors for a given key. The selectedpeers can be queried either to store or retrieve data. Thestructured P2P networks can be defined using distributedhash tables (DHT) which store and search data based onpairs (key,value). The realisations of DHTs, such as Kadem-lia [19] used here, have the advantage of scaling logarithmi-cally with the number of peers in the system. In fact mostof DHT based systems have equivalent search performancecost which is O(log N), where N is the size of network [2].

4. P2P AGENT COORDINATION FRAME-WORK FOR CROSS-COMMUNITY EHREXCHANGE

Our framework describes semantically the knowledge basesof health communities and coordinates their interactions incross-community EHR exchange. Given that different com-munities may have different ways to present their informa-tion, we specify an ontology that is used to define the knowl-edge base of every community. This enables communities tointerpret and reason on the data that are generated from dif-ferent healthcare providers. In case two communities adoptdifferent ontologies, mechanisms for ontologies reconciliationmay be adopted. We model the concept of community asan entity that exposes a set of services and its policies toenable interactions with other communities. An agent co-ordination architecture is used to coordinate the interactionsacross communities. Fig.1(a) shows the architecture for onesingle community. The Policy Tuple Centre contains the co-ordination primitives in terms of action-reaction rules thatare used to mediate interactions among the communities.The coordination primitives are coupled to a semantic tuplecentre and are specified using the ReSpecT language [23].

3http://protege.stanford.edu/

LegendPublish/Subscribe/Notify/Search operations

Tuple Center

Agent

Community/Node

Node

a) Logic Architecture of a Community

b) The P2P structure between CommunitiesSearch Agent

PolicyTuple Center

Log Agent Update Agent

COMMUNITY/Node

Node

Node

Node

Node

NodeNode

P2P NETWORK

Figure 1: The logic architecture of the communitynodes.

Fig.1(a) shows how every community has its own Policy Tu-ple Centre containing a replica of these primitives.

Currently, we use a soft model of agency where agentssimply react to specific messages exchanged in the tuplecentres, as opposed to a hard model of agency where theagents have complex cognitive models to perform complexreasoning. Nevertheless they are essential to keep the dis-tribution and the automony of all the communities of thesystem. We delegate them specific tasks that are performedwhen specific events happen in a tuple centre. Thus, inevery community, we specify three agents that are responsi-ble for performing different actions. Fig.1(a) shows the LogAgent which is responsible for logging the different queriesperformed by other communities, the Search Agent which isresponsible for performing search queries in the P2P net-work and the Update Agent which is responsible for sendingand receiving updates from/to other communities.

Fig. 1(b) shows the health communities connected in aP2P network which allows us to have a scalable mecha-nism for search queries and event notification. Each Node inthe P2P network represents a community and the physicalhealthcare system behind it. The communities share in theP2P only meta-information about which community holdsthe data of a patient id. A community that is interested infinding data about a specific patient, queries the P2P to findwhich community holds these data performs a direct queryto the community to receive the right information. Thereare other security and trust issues arising from the use ofa P2P network [3] which we are currently investigating andare subject of future publications.

4.1 The Community OntologyEvery community has its own knowledge base. Other com-

munities can query or subscribe to updates happening inmore than one knowledge base. Fig.2 shows the classes andthe data and object properties of the OWL Community On-tology4 that is used to create those knowledge bases. Theclasses are all disjoint. The RBox of the Community On-tology contains the following object properties (where thename of a property is followed by its domain and its range).The TBox contains the subsequent axioms that defines car-

4The full ontology can be found inhttp://aislab.hevs.ch/assets/OntologyCommunity.xml

1358




CommunityCommunity

DocumentDocument

PatientPatient

identifiernameaddress

identifierdate

identifiernameaddress

fatherchildren

statusauthor

hasHomeCommunity

RoleRole

identifiername

activities

PolicyPolicy

identifiername

categorydescription

ServiceService

ActorActor profession

name

contact

address

identifier

speciality

assumes

member

complies

follows

provideshas

cares

subscribe

identifiernamelink

description

∐relates

attachment

DatatypeProperty

ClassObjectProperty

∐

home

Union

Figure 2: The OWL Community Ontology.

dinality restrictions for the defined properties:

has : Patient → Document; InvFun(has);cares : Community → Patient; InvFun(cares);subscribe : Community → Patient;member : Actor → Community;provides : Community → Service; InvFun(provides);follows : Community → Policy; InvFun(follow);assumes : Actor → Role; complies : Role → Policy;relates : Policy → (Patient t Role); Fun(relates);hasHomeCommunity : Patient → Community;Fun(hasHomeCommunity);Document v =1 has−; Service v =1 provides−;Patient v =1 cares−; Actor v =1 member;Policy v =1 follows; Policy v =1 complies;

The Community provides a set of Services, follows a setof Policies and cares about Patients. Each Community cansubscribe to a Patient in another Community so that it isnotified of the changes happening elsewhere. Each Patientof a Community has a set of Documents that are part of itshealth record. Documents are generated and stored withina community and relate to a specific patient. Every docu-ment is described with a set of properties which indicate theauthor and the content of the document. The communitythat generates such documents can also update their statusby making documents obsolete or deleting them. A Commu-nity has many Actors which can assume more than one Role.The actors are the users of the system, therefore they playroles such as a cardiologist, nurse, pharmacist, administra-tion ect. The actors must act in the system by complyingwith the Policies of the Community. Such Policies define theactions that every role is allowed to perform.

4.2 Policy Tuple CentreThe Policy Tuple Centre (PTC) mediates the requests

of agents to connect, subscribe to notification of events orsearch data in the P2P network. There is one PTC in everycommunity and all the communications towards a commu-nity are made in its PTC. The Log agent is used to log allthe interactions within the PTC of a community. A pro-tocol to extract the history of how documents are accessedand exchanged in the P2P network are subject to futurework.The PTC specifies the coordination primitives for sub-scribing and unsubscribing to data generated in other com-munities and the primitives to search patient data withinthe P2P network.

4.2.1 Distributed Data Search in Other Communi-ties

A community can search other communities and patientsby generating queries in the P2P network. The Search Agentanswers to search queries by first querying the P2P networkabout the community that holds the data of a patient andlater send a request query to the home community of thepatient. The queries indicate the sender, the communitythat is requesting the data and a list of criteria to be usedfor the search. The behavior of the Search Agent can besummarised as follows:

1. The Search Agent listens to search and reply messages;

2. In case of a search message, it searches the informationby performing a rd primitive in the PTC of its commu-nity. If the searched data are contained in the Knowl-edge Base of the Community, the retrieved informationis given to the actor who performed the request. Oth-erwise, the research is forwarded automatically to theP2P network which provides the link to the commu-nity where the information is held. The Search Agentperforms a request message in the Community holdingthe information to get the information required.

3. In case of a reply message, it means that another com-munity replies with the searched results. The agentprovides the results to to the requesting actor and re-turns to step 1.

In the P2P search some criteria may not be specified. Forexample, the patient may not be able to produce a homecommunity therefore the homeCommunity of the patient maybe unknown. The coordination primitive for requesting thehealth data of a patient in another community is defined asfollows:

reaction(out(request(community, actor, patient)),?- Patient(patient) ⇒ true ,?- Policy u (∃relates.{patient}) u(∃category.{“filesharing”}) u (∃description.{“consent”})⇒ true,?- Documents u (∃has.{patient})(*) ⇒ {d1...dn},out(reply(community, actor, {d1,...dn} ))).

The above primitive is activated when the Search agent ofa community requests patient data in another community.The PTC of the community holding health information aboutthe patient checks that the identified patient belongs to itsknowledge base, checks that exists a policy describing thepatient’s consent for file sharing, and finds the documents

instances that relate to the patient and performs a replymessage in the PTC specified by the Search agent.

4.2.2 Subscribing to Community EventsCommunities can subscribe to events generated by other

communities. We envisage three types of subscriptions: sub-scriptions to events regarding a patient, subscriptions tochanges on the services a community offers and subscrip-tions to the changes of the policies that a community offers.In this paper we treat only a simplified subscription mech-anism for receiving patient updates from other communi-ties. The Update Agents of different communities interactto subscribe/unsubscribe the communities to the patient up-dates. The requests are generated by Actors towards thehome community of the patient. On such request the Up-date Agent executes the following steps:

1359




1. Writes subscribe/unsubscribe messages in the PTC ofthe home community of the patient. If the patient’shome community is not known, then it first searchesthe homeCommunity of the patient within the P2P. Italso listens to add, remove messages in its own PTC;

2. In case it listens an add message, it means that a newcommunity subscribes to specific events generated inits own community. The agent adds the new commu-nity and the subscribe relationship to the knowledgebase and returns to step 1;

3. In case it listens a remove message, it means that acommunity is unsubscribing to specific events gener-ated in its own community. The agent removes thecommunity and its subscribe relationship from the knowl-edge base and returns to step 1;

The coordination primitive for subscribing to patient up-dates is specified as follows:

reaction(out(subscribe(community, patient)),?- Patient(patient) ⇒ true ,?- Policy u (∃relates.{patient}) u(∃category.{“filesharing”}) u (∃description.{“consent”})⇒ true,out(add(community, patient))).

The above primitive is activated in the PTC of a com-munity when another community wants to subscribe to thedata of a given patient. The PTC checks that the identifiedpatient is already contained in the knowledge base and thatit exists a policy describing the patient consent into shar-ing its own files (the complex DL class is satisfiable) andgenerates an add message for the Update Agent. When anew document regarding a patient is generated in the net-work, the home community of the patient is notified. If thedocument is generated in the home community or an up-date about a patient arrives in the home community, suchupdate is propagated to all the interested subscribers. Thefollowing coordination primitive propagates the data to thesubscribers of a patient:

reaction(out(new(patient, document)),?- Document(document) ⇒ true ,?- Patient(patient) ⇒ true ,(∃homeCommunity−.{patient})(*) ⇒ {home},home = myid,?- Community u (∃subscribes.{patient})(*) ⇒ {c1...cn},out({c1...cn},update(patient, document))).

The above coordination primitive specifies that if a newdocument regarding a patient is generated in the home com-munity all the subscribers to the patient should be notified.No agents are used in this operation as the PTC can di-rectly update other PTCs by using TuCSoN coordinationprimitives. Similar coordination primitives are defined topropagate updates to the home community and to unsub-scribe from other communities.

5. IMPLEMENTATIONThe implementation of our framework is based on the

TuCSoN semantic tuple centres as defined in [20]. In or-der to improve the search of semantic information in thedistributed network, we create a P2P network over TuCSoNusing ToM P2P JAVA library 5. Additionally, we interface

5http://tomp2p.net/

with openXDS 6, an open source implementation of the XDSprofile, in order to have documents stored and retrieved inan IHE compatible manner. All these infrastructures areJAVA based.

Every community is represented with a TuCSoN node andhas its own semantic knowledge base where the semanticqueries and reasoning are performed. When users add newinformation in the system, OWL assertions are generatedand added to the knowledge base. For every assertion, adefined number of hash tags are created in the distributedhash table of the P2P network. In case of the addition ormodifications of documents, IHE compatible meta-data aregenerated to be stored in the registry of the XDS profile andthe same meta-data are stored as semantic data in the com-munity knowledge base. Updates to the meta-data of thedocuments of a patient are propagated towards the homecommunity of the patient and to the subscribed communi-ties. We assume that the actual fetching of the documents isrealised using one of the existing IHE profiles (XCA alreadyaddresses this issue).

Each Community operates with three Agents: a Log Agent,an Update Agent and a Search Agent. The agents react totuples generated by external User Agents or to tuples gener-ated by the PTC of their community. The agents use in andrd operations to search in the PTC the messages that triggertheir tasks and, at their completion, they perform out opera-tions to write the results in the PTC. The reaction primitivesare specified by calling JAVA code from reactions specifiedin ReSpecT. This is possible because TuCSoN is based ontuProlog [8], a JAVA based implementation of Prolog thatallows a seamless integration between JAVA code and Pro-log predicates. For example, the coordination primitive tosubscribe a community to patient updates is implementedas follows:

reaction(out(subscribe(Community, Patient)),in(subscribe(Community, Patient)),get semanticKB(KB),KB←getBase returns Base,KB←getModel returns Model,java object(’coordination.UpdateUtility’, [Model,Base],MyUpdateUtility),MyUpdateUtility←utilitySubscribe(Patient),out(updateAgent(add, Community, Patient)))).

The above reaction rule specifies that when an out of asubscribe tuple is made into the tuple centre, then the ref-erence to the JAVA object representing the semantic knowl-edge base KB is used (the ← notation represent a call toa JAVA module) to obtain the URI and the model Modelof the ontology. We use an UpdateUtility JAVA module tocheck if the policies allow us to subscribe the communityCommunity to the patient Patient. MyUpdateUtility is a vari-able containing an UpdateUtility object constructed with themodel Model and URI of the ontology. Finally, the tuple addis sent to the Update Agent which inserts the new informa-tion in the knowledge base.

6. EVALUATIONWe evaluated the proposed solution on the Amazon Cloud

with thirteen micro version virtual machines that generatedthe peers and the data in the P2P network. One hundredpeers at a time were added in the P2P. We measured the

6https://www.projects.openhealthtools.org/sf/projects/openxds/

1360




time to find information held by an unknown community.This time includes the time to search in the P2P networkwhich community to contact and the time to receive the in-formation from the contacted community. The top of Fig.3 shows the time to find information for different querieswith respect to a growing number of peers in the network.

Two different queries are performed. The first query is a

0 200 400 600 800 1000 12000

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Number of Peers

Timeinms

Community Search

PatientSearch

−200 0 200 400 600 800 1000 12000

500

1000

1500

2000

2500

3000

Number of Communities

Times

inms

One community subscribed

Three communities subscribed

Six community subscribed

Figure 3: On top: cross-community and patient’sidentity time search. On the bottom: EHR UpdateTime.search for a patient where we query twice the P2P network:first to find the home community for a patient and then tofind the details on the home community. The second queryis a search for a community. In this case the P2P networkis accessed once. Both results show that the time to findthe information has logarithmic growth with the number ofpeers in the network, which also corresponds to the theoret-ical complexity of the P2P network (see Section 3.4). Theseresults are encouraging as, in the current state of the art,data exchange may take days of human intervention. Inthe second test we varied the number of subscriptions fora patient from 1 to 6 and measured the average time for acommunity to send updates to the subscribed communities.The bottom of Fig. 3 shows how the update time grows lin-early with a growing number of subscriptions to a patient.This time depends on the number of instances held in theKB, which influence the time to search the subscriptions toa patient. Also, a growing number of subscriptions per pa-tient introduces a latency as multiple update messages haveto be sent.

7. RELATED WORKThe use of semantic representations for enabling interop-

erability between hospitals is not a new idea [1, 9], nor it

is new the idea to use the publish and subscribe pattern tomodel the dissemination of events in healthcare [24], but,to the best of our knowledge, the use of an agent-based co-ordination infrastructure to govern the semantic interoper-ability between distributed nodes representing communitiesis new. In particular, the epSOS project7 provides cross-border health-services to patients seeking healthcare in dif-ferent countries, by defining an integration broker for crossborder exchange of patient’s health records. In epSOS thereis no mechanism to handle the subscription of new communi-ties, thereby the responsibility to connect different providersfalls into the epSOS operator. On the contrary, we pro-pose the use of coordination primitives and agent technol-ogy to dynamically connect communities and have a flexibleapproach towards subscription and notification of relevantevents for a community.

The MediCoordination Healthcare Infrastructure (MHI) [1]aims at sharing medical data between medical actors. MHI’smodel consists of a registry/repository and two clients, onefor submitting documents and one for receiving them. OneXDS-based server is used for the repository and the registry.The MHI does not implement notifications [1]. General prac-titioners have to manually query the data in the registry.With respect to MHI, we propose a decentralized solutionthat can handle multiple communities, whereas MHI is lim-ited to a centralized repository. Furthermore, the use of theDescription Logic formalism, allows us a richer descriptionof the events happening between different actors and acrosscommunities, and, to represent subscription and notificationto complex events.

Triple space computing (TSC) applied to healthcare[21] isthe approach that it is closer to ours. Also TSC uses tuplespaces to foster the exchange of information and proposesthe use of semantic web technology to represent the dataabout the patients by associating RDF tuples to conceptsdefined in HL7 or SNOMED. In contrast with TSC, we arenot concerned with translating HL7 concepts into a semanticweb language but we deal only with the metadata associatedto medical documents. From the perspective of the compu-tation, also TSC considers the problem of publication andretrieval of health information, but it does not describe thenotification and dispatching of the events happening in thedistributed system, nor there is a clear representation of theconcept of community. Finally, by using tuple centres andReSpecT, we can modify the behaviour of our communities,including new reactions at runtime, while this is not the casefor TSC.

8. CONCLUSIONS AND FUTURE WORKIn this paper we have presented a P2P agent coordina-

tion model to enable dynamic interactions across communi-ties. We have shown how the combination of semantic rep-resentations and coordination languages such as ReSpecTcan improve the current state of the art with respect tocross-community EHR exchange. The presented coordina-tion model extends the IHE limitations by specifying a P2Pnetwork and a set of coordination primitives that enablecommunities to search data in other communities withoutprior integration among them.

As part of our future work, we plan to address securityissues arising from an open environment. Apart from the

7http://www.epsos.eu

1361




logging of events, the set of policies may help to check thatthe emerging behaviour of the actors performing the queriesis that expected within the community sub-system. We willfurther investigate how to log the access to the data in adistributed setting in such a way that it is possible to trackback all the access to documents. We also plan to modelsubscriptions to different types of events (other than patientupdates) and enable communities to apply filters to the ex-changed information. Both of these extensions will requiremore complex semantic reasoning than the one presented inthis paper.

9. ACKNOWLEDGMENTSThis work was partially funded by the Switzerland FNS

grant nr. 200021 135386 / 1, the FP7 287841 COMMOD-ITY12 project, the Hasler Foundation project nr. 11115-KGand by the SER project nr. C08.0114 within the COST Ac-tion IC0801 Agreement Technologies.

10. REFERENCES[1] B. Alves, H. Muller, M. Schumacher, D. Godel, and

O. Abu Khaled. Interoperability prototype betweenhospitals and general practitioners in Switzerland.Stud Health Technol Inform, 160:366–370, 2010.

[2] S. Androutsellis-Theotokis and D. Spinellis. A surveyof Peer-to-Peer content distribution technologies.ACM Comput. Surv., 36(4):335–371, December 2004.

[3] M. Castro, P. Druschel, A. Ganesh, A. Rowstron, andD. S. Wallach. Secure routing for structuredpeer-to-peer overlay networks. SIGOPS Oper. Syst.Rev., 36(SI):299–314, December 2002.

[4] Dario Cerizza, Emanuele Della Valle, Doug Foxvog,Reto Krummenacher, and Martin Murth. TowardsEuropean Patient Summaries based on Triple SpaceComputing. In European Conference on eHealth,volume 91, pages 143–154, 2006.

[5] M. Colombetti. Dispense corso di Ingegneria dellaconoscenza: modelli semantici, Politecnico di Milano.http://home.dei.polimi.it//colombet/IC/materiale/IC2011.

[6] M. Cremonini, A. Omicini, and F. Zambonelli.Multi-agent Systems on the Internet: Extending thescope of coordination towards Security and Topology.In Proceedings of the 9th European Workshop onModelling Autonomous Agents in a Multi-AgentWorld: MultiAgent System Engineering, pages 77–88,London, UK, 1999. Springer-Verlag.

[7] Kalra D. Electronic health record standards. InMethods Inf Med, volume 45, pages 136–144, 2006.

[8] E. Denti, A. Omicini, and A. Ricci. Multi-paradigmJava-Prolog integration in tuProlog. Sci. Comput.Program., 57(2):217–250, 2005.

[9] Asuman Dogac, Gokce B. Laleci, Serkan Kirbas,Yildiray Kabak, Siyamed S. Sinir, Ali Yildiz, andYavuz Gurcan. Artemis: deploying semanticallyenriched web services in the healthcare domain. Inf.Syst., 31:321–339, 2006.

[10] A. Geissbuhler, S. Spahni, A. Assimacopoulos,M. Raetzo, and G. Gobet. Design of apatient-centered, multi-institutional healthcareinformation network using Peer-to-Peercommunication in a highly distributed architecture.Medinfo, 11(Pt 2):1048–52, 2004.

[11] D. Gelernter. Generative communication in Linda.ACM Trans. Program. Lang. Syst., 7:80–112, 1985.

[12] J. Grimson, W. Grimson, and W. Hasselbring. The SIchallenge in health care. Commun. ACM, 43:48–55,2000.

[13] D. Tracy Gunter and P. Nicolas Terry. The emergenceof national electronic health record architectures inthe united states and australia: Models, costs, andquestions. J Med Internet Res, 7(1):e3, Mar 2005.

[14] J. Hendler. Agents and the Semantic Web. IEEEIntelligent Systems, 16:30–37, 2001.

[15] P. Hitzler, M. Krotzsch, and S. Rudolph. Foundationsof Semantic Web Technologies. Chapman &Hall/CRC, 2009.

[16] I. Horrocks, P. Patel-Schneider, and F. van Harmelen.From SHIQ and RDF to OWL: the making of a WebOntology Language. Web Semantics: Science, Servicesand Agents on the World Wide Web, 1(1):7 – 26, 2003.

[17] IHE. White paper: Cross community informationexchange, 2008. http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_White_Paper_Cross_

Community_2008-11-07.pdf.

[18] IHE. Technical framework integration profiles vol 1,2011. http://www.ihe.net.

[19] P. Maymounkov and D. Mazieres. Kademlia: APeer-to-Peer information System Based on the XORMetric. In Revised Papers from the First InternationalWorkshop on Peer-to-Peer Systems, pages 53–65.Springer-Verlag, 2002.

[20] E. Nardini, M. Viroli, and E. Panzavolta.Coordination in open and dynamic environments withTuCSoN semantic tuple centres. In Proceedings of the2010 ACM Symposium on Applied Computing (SAC),pages 2037–2044. ACM, 2010.

[21] L. Nixon, D. Cerizza, E. Della Valle, E. PaslaruBontas Simperl, and R Krummenacher. EnablingCollaborative eHealth through TriplespaceComputing. In WETICE, pages 80–85. IEEEComputer Society, 2007.

[22] A. Omicini. Formal ReSpecT in the A&A Perspective.Electron. Notes Theor. Comput. Sci., 175:97–117,2007.

[23] A Omicini and E. Denti. From Tuple Spaces to TupleCentres. Science of Computer Programming,41(3):277–294, nov 2001.

[24] J. Singh, J. Bacon, D. Weerasinghe, O. Akan,P. Bellavista, J. Cao, F. Dressler, D. Ferrari, M. Gerla,H. Kobayashi, S. Palazzo, S. Sahni, X. Shen, M. Stan,J. Xiaohua, A. Zomaya, and G. Coulson. Event-BasedData Dissemination Control in Healthcare, volume 1,pages 167–174. Springer Berlin Heidelberg, 2009.

[25] V. Urovi, A. Olivieri, S. Bromuri, N. Fornara, andM. Schumacher. An Agent Coordination Frameworkfor IHE based Cross-Community Health RecordExchange. In VII Workshop on Agents Applied inHealth Care, pages 29–40, 2012.

[26] F. Wozak, E. Ammenwerth, A. Hoerbst, P. Soegner,R. Mair, and Th. Schabetsberger. IHE basedInteroperability - Benefits and Challenges. volume 136of Studies in Health Technology and Informatics, pages771–776. IOS Press, 2008.

1362


