Knowledge sharing in the health scenario
Identifieur interne : 000354 ( Pmc/Corpus ); précédent : 000353; suivant : 000355Knowledge sharing in the health scenario
Auteurs : Magí Lluch-Ariet ; Albert Brugués De La Torre ; Francesc Vallverdú ; Josep Pegueroles-VallésSource :
- Journal of Translational Medicine [ 1479-5876 ] ; 2014.
Abstract
The understanding of certain data often requires the collection of similar data from different places to be analysed and interpreted. Interoperability standards and ontologies, are facilitating data interchange around the world. However, beyond the existing networks and advances for data transfer, data sharing protocols to support multilateral agreements are useful to exploit the knowledge of distributed Data Warehouses. The access to a certain data set in a federated Data Warehouse may be constrained by the requirement to deliver another specific data set. When bilateral agreements between two nodes of a network are not enough to solve the constraints for accessing to a certain data set, multilateral agreements for data exchange are needed.
We present the implementation of a Multi-Agent System for multilateral exchange agreements of clinical data, and evaluate how those multilateral agreements increase the percentage of data collected by a single node from the total amount of data available in the network. Different strategies to reduce the number of messages needed to achieve an agreement are also considered. The results show that with this collaborative sharing scenario the percentage of data collected dramaticaly improve from bilateral agreements to multilateral ones, up to reach almost all data available in the network.
Url:
DOI: 10.1186/1479-5876-12-S2-S8
PubMed: 25471452
PubMed Central: 4255915
Links to Exploration step
PMC:4255915Le document en format XML
<record><TEI><teiHeader><fileDesc><titleStmt><title xml:lang="en">Knowledge sharing in the health scenario</title>
<author><name sortKey="Lluch Ariet, Magi" sort="Lluch Ariet, Magi" uniqKey="Lluch Ariet M" first="Magí" last="Lluch-Ariet">Magí Lluch-Ariet</name>
<affiliation><nlm:aff id="I1">Barcelona Digital Technology Centre, Roc Boronat, 117, 08018, Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="I2">Departament d'Enginyeria Telematica (ENTEL), Universitat Politècnica de Catalunya Jordi Girona, 1-3, C3, 08034 Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="De La Torre, Albert Brugues" sort="De La Torre, Albert Brugues" uniqKey="De La Torre A" first="Albert Brugués" last="De La Torre">Albert Brugués De La Torre</name>
<affiliation><nlm:aff id="I3">University of Applied Sciences Western Switzerland Sierre, Switzerland</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="I2">Departament d'Enginyeria Telematica (ENTEL), Universitat Politècnica de Catalunya Jordi Girona, 1-3, C3, 08034 Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Vallverdu, Francesc" sort="Vallverdu, Francesc" uniqKey="Vallverdu F" first="Francesc" last="Vallverdú">Francesc Vallverdú</name>
<affiliation><nlm:aff id="I2">Departament d'Enginyeria Telematica (ENTEL), Universitat Politècnica de Catalunya Jordi Girona, 1-3, C3, 08034 Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Pegueroles Valles, Josep" sort="Pegueroles Valles, Josep" uniqKey="Pegueroles Valles J" first="Josep" last="Pegueroles-Vallés">Josep Pegueroles-Vallés</name>
<affiliation><nlm:aff id="I2">Departament d'Enginyeria Telematica (ENTEL), Universitat Politècnica de Catalunya Jordi Girona, 1-3, C3, 08034 Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
</author>
</titleStmt>
<publicationStmt><idno type="wicri:source">PMC</idno>
<idno type="pmid">25471452</idno>
<idno type="pmc">4255915</idno>
<idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4255915</idno>
<idno type="RBID">PMC:4255915</idno>
<idno type="doi">10.1186/1479-5876-12-S2-S8</idno>
<date when="2014">2014</date>
<idno type="wicri:Area/Pmc/Corpus">000354</idno>
<idno type="wicri:explorRef" wicri:stream="Pmc" wicri:step="Corpus" wicri:corpus="PMC">000354</idno>
</publicationStmt>
<sourceDesc><biblStruct><analytic><title xml:lang="en" level="a" type="main">Knowledge sharing in the health scenario</title>
<author><name sortKey="Lluch Ariet, Magi" sort="Lluch Ariet, Magi" uniqKey="Lluch Ariet M" first="Magí" last="Lluch-Ariet">Magí Lluch-Ariet</name>
<affiliation><nlm:aff id="I1">Barcelona Digital Technology Centre, Roc Boronat, 117, 08018, Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="I2">Departament d'Enginyeria Telematica (ENTEL), Universitat Politècnica de Catalunya Jordi Girona, 1-3, C3, 08034 Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="De La Torre, Albert Brugues" sort="De La Torre, Albert Brugues" uniqKey="De La Torre A" first="Albert Brugués" last="De La Torre">Albert Brugués De La Torre</name>
<affiliation><nlm:aff id="I3">University of Applied Sciences Western Switzerland Sierre, Switzerland</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="I2">Departament d'Enginyeria Telematica (ENTEL), Universitat Politècnica de Catalunya Jordi Girona, 1-3, C3, 08034 Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Vallverdu, Francesc" sort="Vallverdu, Francesc" uniqKey="Vallverdu F" first="Francesc" last="Vallverdú">Francesc Vallverdú</name>
<affiliation><nlm:aff id="I2">Departament d'Enginyeria Telematica (ENTEL), Universitat Politècnica de Catalunya Jordi Girona, 1-3, C3, 08034 Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Pegueroles Valles, Josep" sort="Pegueroles Valles, Josep" uniqKey="Pegueroles Valles J" first="Josep" last="Pegueroles-Vallés">Josep Pegueroles-Vallés</name>
<affiliation><nlm:aff id="I2">Departament d'Enginyeria Telematica (ENTEL), Universitat Politècnica de Catalunya Jordi Girona, 1-3, C3, 08034 Barcelona, Catalonia, Spain</nlm:aff>
</affiliation>
</author>
</analytic>
<series><title level="j">Journal of Translational Medicine</title>
<idno type="eISSN">1479-5876</idno>
<imprint><date when="2014">2014</date>
</imprint>
</series>
</biblStruct>
</sourceDesc>
</fileDesc>
<profileDesc><textClass></textClass>
</profileDesc>
</teiHeader>
<front><div type="abstract" xml:lang="en"><p>The understanding of certain data often requires the collection of similar data from different places to be analysed and interpreted. Interoperability standards and ontologies, are facilitating data interchange around the world. However, beyond the existing networks and advances for data transfer, data sharing protocols to support multilateral agreements are useful to exploit the knowledge of distributed Data Warehouses. The access to a certain data set in a federated Data Warehouse may be constrained by the requirement to deliver another specific data set. When bilateral agreements between two nodes of a network are not enough to solve the constraints for accessing to a certain data set, multilateral agreements for data exchange are needed.</p>
<p>We present the implementation of a Multi-Agent System for multilateral exchange agreements of clinical data, and evaluate how those multilateral agreements increase the percentage of data collected by a single node from the total amount of data available in the network. Different strategies to reduce the number of messages needed to achieve an agreement are also considered. The results show that with this collaborative sharing scenario the percentage of data collected dramaticaly improve from bilateral agreements to multilateral ones, up to reach almost all data available in the network.</p>
</div>
</front>
<back><div1 type="bibliography"><listBibl><biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Hayden, E Check" uniqKey="Hayden E">E Check Hayden</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Pianykh, Os" uniqKey="Pianykh O">OS Pianykh</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Stearns, Mq" uniqKey="Stearns M">MQ Stearns</name>
</author>
<author><name sortKey="S, Ka" uniqKey="S K">KA S</name>
</author>
<author><name sortKey="Price, C" uniqKey="Price C">C Price</name>
</author>
<author><name sortKey="Wang, Ay" uniqKey="Wang A">AY Wang</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Spackman, Ka" uniqKey="Spackman K">KA Spackman</name>
</author>
<author><name sortKey="Campbell, Ke" uniqKey="Campbell K">KE Campbell</name>
</author>
<author><name sortKey="Cote, Ra" uniqKey="Cote R">RA Côté</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Isern, D" uniqKey="Isern D">D Isern</name>
</author>
<author><name sortKey="Sanchez, D" uniqKey="Sanchez D">D Sánchez</name>
</author>
<author><name sortKey="Moreno, A" uniqKey="Moreno A">A Moreno</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Annicchiarico, R" uniqKey="Annicchiarico R">R Annicchiarico</name>
</author>
<author><name sortKey="Cortes, U" uniqKey="Cortes U">U Cortés</name>
</author>
<author><name sortKey="Urdiales, C" uniqKey="Urdiales C">C Urdiales</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Merelli, E" uniqKey="Merelli E">E Merelli</name>
</author>
<author><name sortKey="Armano, G" uniqKey="Armano G">G Armano</name>
</author>
<author><name sortKey="Cannata, N" uniqKey="Cannata N">N Cannata</name>
</author>
<author><name sortKey="Corradini, F" uniqKey="Corradini F">F Corradini</name>
</author>
<author><name sortKey="D Inverno, M" uniqKey="D Inverno M">M d'Inverno</name>
</author>
<author><name sortKey="Doms, A" uniqKey="Doms A">A Doms</name>
</author>
<author><name sortKey="Lord, P" uniqKey="Lord P">P Lord</name>
</author>
<author><name sortKey="Martin, A" uniqKey="Martin A">A Martin</name>
</author>
<author><name sortKey="Milanesi, L" uniqKey="Milanesi L">L Milanesi</name>
</author>
<author><name sortKey="Moller, S" uniqKey="Moller S">S Moller</name>
</author>
<author><name sortKey="Schroeder, M" uniqKey="Schroeder M">M Schroeder</name>
</author>
<author><name sortKey="Luck, M" uniqKey="Luck M">M Luck</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Goldberger, Al" uniqKey="Goldberger A">AL Goldberger</name>
</author>
<author><name sortKey="Amaral, Lan" uniqKey="Amaral L">LAN Amaral</name>
</author>
<author><name sortKey="Glass, L" uniqKey="Glass L">L Glass</name>
</author>
<author><name sortKey="Hausdorff, Jm" uniqKey="Hausdorff J">JM Hausdorff</name>
</author>
<author><name sortKey="Ivanov, Pc" uniqKey="Ivanov P">PC Ivanov</name>
</author>
<author><name sortKey="Mark, Rg" uniqKey="Mark R">RG Mark</name>
</author>
<author><name sortKey="Mietus, Je" uniqKey="Mietus J">JE Mietus</name>
</author>
<author><name sortKey="Moody, Gb" uniqKey="Moody G">GB Moody</name>
</author>
<author><name sortKey="Peng, C K" uniqKey="Peng C">C-K Peng</name>
</author>
<author><name sortKey="Stanley, He" uniqKey="Stanley H">HE Stanley</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Komatsoulis, Ga" uniqKey="Komatsoulis G">GA Komatsoulis</name>
</author>
<author><name sortKey="Warzela, Db" uniqKey="Warzela D">DB Warzela</name>
</author>
<author><name sortKey="Hartela, Fw" uniqKey="Hartela F">FW Hartela</name>
</author>
<author><name sortKey="Shanbhaga, K" uniqKey="Shanbhaga K">K Shanbhaga</name>
</author>
<author><name sortKey="Chilukuric, R" uniqKey="Chilukuric R">R Chilukuric</name>
</author>
<author><name sortKey="Fragosoa, G" uniqKey="Fragosoa G">G Fragosoa</name>
</author>
<author><name sortKey="De Coronadoa, S" uniqKey="De Coronadoa S">S de Coronadoa</name>
</author>
<author><name sortKey="Reevesa, Dm" uniqKey="Reevesa D">DM Reevesa</name>
</author>
<author><name sortKey="Hadfielda, Jb" uniqKey="Hadfielda J">JB Hadfielda</name>
</author>
<author><name sortKey="Ludetb, C" uniqKey="Ludetb C">C Ludetb</name>
</author>
<author><name sortKey="Covitza, Pa" uniqKey="Covitza P">PA Covitza</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Pedrinaci, C" uniqKey="Pedrinaci C">C Pedrinaci</name>
</author>
<author><name sortKey="Cardoso, J" uniqKey="Cardoso J">J Cardoso</name>
</author>
<author><name sortKey="Leidig, T" uniqKey="Leidig T">T Leidig</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Lluch Ariet, M" uniqKey="Lluch Ariet M">M Lluch-Ariet</name>
</author>
<author><name sortKey="Estanyol, F" uniqKey="Estanyol F">F Estanyol</name>
</author>
<author><name sortKey="Mier, M" uniqKey="Mier M">M Mier</name>
</author>
<author><name sortKey="Delgado, C" uniqKey="Delgado C">C Delgado</name>
</author>
<author><name sortKey="Gonzalez Velez, H" uniqKey="Gonzalez Velez H">H González-Vélez</name>
</author>
<author><name sortKey="Dalmas, T" uniqKey="Dalmas T">T Dalmas</name>
</author>
<author><name sortKey="Robles, M" uniqKey="Robles M">M Robles</name>
</author>
<author><name sortKey="Saez, C" uniqKey="Saez C">C Sáez</name>
</author>
<author><name sortKey="Vicente, J" uniqKey="Vicente J">J Vicente</name>
</author>
<author><name sortKey="Huffel, Sv" uniqKey="Huffel S">SV Huffel</name>
</author>
<author><name sortKey="Luts, J" uniqKey="Luts J">J Luts</name>
</author>
<author><name sortKey="Arus, C" uniqKey="Arus C">C Arús</name>
</author>
<author><name sortKey="Silveira, Apc" uniqKey="Silveira A">APC Silveira</name>
</author>
<author><name sortKey="Julia Sape, M" uniqKey="Julia Sape M">M Julià-Sapé</name>
</author>
<author><name sortKey="Peet, A" uniqKey="Peet A">A Peet</name>
</author>
<author><name sortKey="Gibb, A" uniqKey="Gibb A">A Gibb</name>
</author>
<author><name sortKey="Sun, Y" uniqKey="Sun Y">Y Sun</name>
</author>
<author><name sortKey="Celda, B" uniqKey="Celda B">B Celda</name>
</author>
<author><name sortKey="Bisbal, Mcm" uniqKey="Bisbal M">MCM Bisbal</name>
</author>
<author><name sortKey="Valsecchi, G" uniqKey="Valsecchi G">G Valsecchi</name>
</author>
<author><name sortKey="Dupplaw, D" uniqKey="Dupplaw D">D Dupplaw</name>
</author>
<author><name sortKey="Hu, B" uniqKey="Hu B">B Hu</name>
</author>
<author><name sortKey="Lewis, P" uniqKey="Lewis P">P Lewis</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Estanyol, F" uniqKey="Estanyol F">F Estanyol</name>
</author>
<author><name sortKey="Palou, Xr" uniqKey="Palou X">XR Palou</name>
</author>
<author><name sortKey="Roset, R" uniqKey="Roset R">R Roset</name>
</author>
<author><name sortKey="Lurgi, M" uniqKey="Lurgi M">M Lurgi</name>
</author>
<author><name sortKey="Mier, M" uniqKey="Mier M">M Mier</name>
</author>
<author><name sortKey="Lluch Ariet, M" uniqKey="Lluch Ariet M">M Lluch-Ariet</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dijkstra, Ew" uniqKey="Dijkstra E">EW Dijkstra</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Brugues De La Torre, A" uniqKey="Brugues De La Torre A">A Brugues De La Torre</name>
</author>
<author><name sortKey="Lluch Ariet, M" uniqKey="Lluch Ariet M">M Lluch-Ariet</name>
</author>
<author><name sortKey="Pegueroles Valles, J" uniqKey="Pegueroles Valles J">J Pegueroles-Valles</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Tomas Buliart, J" uniqKey="Tomas Buliart J">J Tomàs-Buliart</name>
</author>
<author><name sortKey="Fernandez, M" uniqKey="Fernandez M">M Fernández</name>
</author>
<author><name sortKey="Soriano, M" uniqKey="Soriano M">M Soriano</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Rebollo Monedero, D" uniqKey="Rebollo Monedero D">D Rebollo-Monedero</name>
</author>
<author><name sortKey="Forne, J" uniqKey="Forne J">J Forné</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Sierra, C" uniqKey="Sierra C">C Sierra</name>
</author>
<author><name sortKey="Debenham, J" uniqKey="Debenham J">J Debenham</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Parsons, S" uniqKey="Parsons S">S Parsons</name>
</author>
<author><name sortKey="Tang, Y" uniqKey="Tang Y">Y Tang</name>
</author>
<author><name sortKey="Sklar, E" uniqKey="Sklar E">E Sklar</name>
</author>
<author><name sortKey="Mcburney, P" uniqKey="Mcburney P">P McBurney</name>
</author>
<author><name sortKey="Cai, K" uniqKey="Cai K">K Cai</name>
</author>
</analytic>
</biblStruct>
</listBibl>
</div1>
</back>
</TEI>
<pmc article-type="research-article" xml:lang="en"><pmc-dir>properties open_access</pmc-dir>
<front><journal-meta><journal-id journal-id-type="nlm-ta">J Transl Med</journal-id>
<journal-id journal-id-type="iso-abbrev">J Transl Med</journal-id>
<journal-title-group><journal-title>Journal of Translational Medicine</journal-title>
</journal-title-group>
<issn pub-type="epub">1479-5876</issn>
<publisher><publisher-name>BioMed Central</publisher-name>
</publisher>
</journal-meta>
<article-meta><article-id pub-id-type="pmid">25471452</article-id>
<article-id pub-id-type="pmc">4255915</article-id>
<article-id pub-id-type="publisher-id">1479-5876-12-S2-S8</article-id>
<article-id pub-id-type="doi">10.1186/1479-5876-12-S2-S8</article-id>
<article-categories><subj-group subj-group-type="heading"><subject>Research</subject>
</subj-group>
</article-categories>
<title-group><article-title>Knowledge sharing in the health scenario</article-title>
</title-group>
<contrib-group><contrib contrib-type="author" corresp="yes" id="A1"><name><surname>Lluch-Ariet</surname>
<given-names>Magí</given-names>
</name>
<xref ref-type="aff" rid="I1">1</xref>
<xref ref-type="aff" rid="I2">2</xref>
<email>magi.lluch@upc.edu</email>
</contrib>
<contrib contrib-type="author" id="A2"><name><surname>de la Torre</surname>
<given-names>Albert Brugués</given-names>
</name>
<xref ref-type="aff" rid="I3">3</xref>
<xref ref-type="aff" rid="I2">2</xref>
</contrib>
<contrib contrib-type="author" id="A3"><name><surname>Vallverdú</surname>
<given-names>Francesc</given-names>
</name>
<xref ref-type="aff" rid="I2">2</xref>
</contrib>
<contrib contrib-type="author" id="A4"><name><surname>Pegueroles-Vallés</surname>
<given-names>Josep</given-names>
</name>
<xref ref-type="aff" rid="I2">2</xref>
</contrib>
</contrib-group>
<aff id="I1"><label>1</label>
Barcelona Digital Technology Centre, Roc Boronat, 117, 08018, Barcelona, Catalonia, Spain</aff>
<aff id="I2"><label>2</label>
Departament d'Enginyeria Telematica (ENTEL), Universitat Politècnica de Catalunya Jordi Girona, 1-3, C3, 08034 Barcelona, Catalonia, Spain</aff>
<aff id="I3"><label>3</label>
University of Applied Sciences Western Switzerland Sierre, Switzerland</aff>
<pub-date pub-type="collection"><year>2014</year>
</pub-date>
<pub-date pub-type="epub"><day>28</day>
<month>11</month>
<year>2014</year>
</pub-date>
<volume>12</volume>
<issue>Suppl 2</issue>
<supplement><named-content content-type="supplement-title">Systems medicine in chronic diseases: COPD as a use case </named-content>
<named-content content-type="supplement-editor">David Gomez Cabrero, Felip Miralles, Jesper Tegner, Josep Roca, Magi Lluch-Ariet and Marta Cascante</named-content>
<named-content content-type="supplement-sponsor">Publication of this supplement has not been supported by sponsorship. Information about the source of funding for publication chanrges can be found in the individual articles. Articles have undergone the journal's standard peer review process for supplements. The Supplement Editors declare that they have no competing interests.</named-content>
</supplement>
<fpage>S8</fpage>
<lpage>S8</lpage>
<permissions><copyright-statement>Copyright © 2014 Lluch-Ariet et al.; licensee BioMed Central Ltd.</copyright-statement>
<copyright-year>2014</copyright-year>
<copyright-holder>Lluch-Ariet et al.; licensee BioMed Central Ltd.</copyright-holder>
<license license-type="open-access" xlink:href="http://creativecommons.org/licenses/by/4.0"><license-p>This is an Open Access article distributed under the terms of the Creative Commons Attribution License (<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/licenses/by/4.0">http://creativecommons.org/licenses/by/4.0</ext-link>
), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. The Creative Commons Public Domain Dedication waiver (<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/publicdomain/zero/1.0/">http://creativecommons.org/publicdomain/zero/1.0/</ext-link>
) applies to the data made available in this article, unless otherwise stated.</license-p>
</license>
</permissions>
<self-uri xlink:href="http://www.translational-medicine.com/content/12/S2/S8"></self-uri>
<abstract><p>The understanding of certain data often requires the collection of similar data from different places to be analysed and interpreted. Interoperability standards and ontologies, are facilitating data interchange around the world. However, beyond the existing networks and advances for data transfer, data sharing protocols to support multilateral agreements are useful to exploit the knowledge of distributed Data Warehouses. The access to a certain data set in a federated Data Warehouse may be constrained by the requirement to deliver another specific data set. When bilateral agreements between two nodes of a network are not enough to solve the constraints for accessing to a certain data set, multilateral agreements for data exchange are needed.</p>
<p>We present the implementation of a Multi-Agent System for multilateral exchange agreements of clinical data, and evaluate how those multilateral agreements increase the percentage of data collected by a single node from the total amount of data available in the network. Different strategies to reduce the number of messages needed to achieve an agreement are also considered. The results show that with this collaborative sharing scenario the percentage of data collected dramaticaly improve from bilateral agreements to multilateral ones, up to reach almost all data available in the network.</p>
</abstract>
<kwd-group><kwd>Network Protocols</kwd>
<kwd>Distributed Systems</kwd>
<kwd>Multiagent systems</kwd>
<kwd>Data sharing</kwd>
</kwd-group>
</article-meta>
</front>
<body><sec sec-type="intro"><title>Introduction</title>
<p>Clinicians and biomedical researchers often need to compare the information collected from the exams performed on their patients with information from similar patients in other places. This is needed for accurate diagnosis, prognosis and theragnosis and an effective management of diseases. Providing mechanisms to facilitate the access to remote worldwide distributed data sets becomes relevant to foster collaboration and knowledge sharing.</p>
<p>When all the ethical and legal regulations to protect the clinical data are satisfied a negotiation process for data exchange can start. A clinician may add some constraint and give access to the data only if a certain set of conditions are satisfied. One typical constraint may be that another dataset is provided in return. Bilateral agreements between two clinical centres will not always solve all those constraints and involving a set of centres in multilateral agreements for data exchange would increase the amount of data potentially accessible in the network.</p>
<p>In this article, we provide the details of the implementation and the evaluation of a system (<italic>MOSAIC</italic>
) for the finding of paths involving a set of nodes that all together can participate in a multilateral agreement for data exchange and knowledge sharing.</p>
<p>In this first section we have introduced the system developed, and the justification why it is needed. In the following section (The MOSAIC System), the components of the system and the negotiation process for the multilateral data exchange are explained. In the MOSAIC implementation section we explain the details of the implementation and the path selection for the network exploration. In the Validation and performance evaluation section we present the results and findings after analysing the results of the protocol execution in the proposed scenario. Finally, we summarise the main achievements and outline the future work to be done.</p>
<sec><title>State of the art</title>
<p>Public regulations push to open up and share data, for scientific publications [<xref ref-type="bibr" rid="B1">1</xref>
] (Open Data), for research data [<xref ref-type="bibr" rid="B2">2</xref>
] and also for clinical data [<xref ref-type="bibr" rid="B3">3</xref>
]. Aiming to extract the maximum amount of knowledge from the data, a global alliance [<xref ref-type="bibr" rid="B4">4</xref>
] for sharing genomic and clinical data was created on june 2013.</p>
<p>Well established interoperability standards for clinical information (DICOM [<xref ref-type="bibr" rid="B5">5</xref>
], HL7 [<xref ref-type="bibr" rid="B6">6</xref>
] or ISO/EN 13606 [<xref ref-type="bibr" rid="B7">7</xref>
]), medical reference terminologies (SNOMED [<xref ref-type="bibr" rid="B8">8</xref>
,<xref ref-type="bibr" rid="B9">9</xref>
]), clinical ontologies, Electronic Health Records [<xref ref-type="bibr" rid="B10">10</xref>
], Multi-Agent systems [<xref ref-type="bibr" rid="B11">11</xref>
-<xref ref-type="bibr" rid="B13">13</xref>
] and systems like PhysioNet [<xref ref-type="bibr" rid="B14">14</xref>
] or caCORE [<xref ref-type="bibr" rid="B15">15</xref>
], are facilitating the data transfer and interchange between clinical centres around the world. Ontologies to facilitate reasoning and support the trading of services over Internet are being designed (e.g. Linked USDL [<xref ref-type="bibr" rid="B16">16</xref>
]). Nevertheless, it is still difficult to find and gain access to the best dataset for a certain purpose and none of these systems and technologies facilitate the finding of multilateral agreements for accessing to the desired data.</p>
<p>An example of a federated Data Warehouse and its associated Decision Support System is the HealthAgents project [<xref ref-type="bibr" rid="B17">17</xref>
,<xref ref-type="bibr" rid="B18">18</xref>
], that aims to build a system to manage a network of clinical centres for the brain tumour diagnosis. This project was focused on collecting data for building classifiers that would be used during the diagnose process, but did not address the exchange of data between the nodes.</p>
<p>The problem of solving multilateral agreements includes to the problem of finding the shortest path in a complex network. This could be rapidly solved using the Dijkstra algorithm [<xref ref-type="bibr" rid="B19">19</xref>
]. However, this is possible only if the links between the nodes are known and the topology of the whole network is known. In many scenarios the information of the network topology is neither available nor complete. As an example of this, a clinician may accept to publish the reference of which datasets are available from his local repository, but the specific permission to allow access to them may not be provided before an explicit data access request from a specific centre is received. Thus, a centralised approach to solve this problem is not feasible and a distributed and dynamic mechanism for the exploration of the paths associated to possible multilateral agreements is needed.</p>
</sec>
</sec>
<sec><title>The MOSAIC System</title>
<sec><title>The components of the system</title>
<p>The agent oriented abstraction fits well in the knowledge sharing scenario due to its distributed and dynamic nature. MOSAIC (see Figure <xref ref-type="fig" rid="F1">1</xref>
) is a Multy-Agent System that facilitates the multilateral data exchange in a network by providing mechanisms for the intelligent search of paths to reach the datasets requested, involving a set of nodes in multilateral agreements. The MOSAIC System is composed by a set of interconnected nodes each one with its associated Data Mart and the Agent Platform to host the following Agents:</p>
<fig id="F1" position="float"><label>Figure 1</label>
<caption><p><bold>The Architecture of the system</bold>
. The architecture of the <italic>MOSAIC </italic>
System, showing the data flow among the agents. The Data Petitioner Node solves the constraint: 1) data delivery to third nodes, 2) data collection from third nodes needed to fulfill a constraint and 3) delivery of data requested. The Data Contributor node concludes the transaction: 4) delivery of the data requested.</p>
</caption>
<graphic xlink:href="1479-5876-12-S2-S8-1"></graphic>
</fig>
<p>• <bold>Multicast Contributor Agent (MCC)</bold>
. An Agent activated by the user to offer a certain dataset to the network, with or without constraints.</p>
<p>• <bold>Unicast Contributor Agent (UCC)</bold>
. An Agent activated by the MCC to negotiate a specific data access request sent by an MCP.</p>
<p>• <bold>Multicast Petitioner Agent (MCP)</bold>
. An Agent activated by the user or by a Unicast Petitioner Agent. The user launches it in order to explore the network looking for a certain data set. The UCP launches it in order to solve a constraint from a UCC when the dataset requested is not available at the node of the UCP.</p>
<p>• <bold>Unicast Petitioner Agent (UCP)</bold>
. An Agent activated by the MCP in order to negotiate a specific data access request with a UCC.</p>
<p>• <bold>Yellow Pages Agent (YP)</bold>
. An Agent that provides the directory service and hosts the list of references of MCCs active in the network.</p>
<p>Figure <xref ref-type="fig" rid="F2">2</xref>
shows the dependences and relationships between the <italic>MOSAIC </italic>
agents. Every link in a multilateral agreement is composed of two pairs of MCP-UCP and MCC-UCC.</p>
<fig id="F2" position="float"><label>Figure 2</label>
<caption><p><bold>The Agents of the system</bold>
. The MOSAIC Agents, their dependency and interactions during the execution of the protocol.</p>
</caption>
<graphic xlink:href="1479-5876-12-S2-S8-2"></graphic>
</fig>
</sec>
<sec><title>The negotiation process</title>
<p>From the launch of a data set request by the user, followed by the intermediate steps to solve the possible constraints, to the final delivery of the data, the <italic>MOSAIC </italic>
protocol follows a process with the following five stages:</p>
<p>• <bold>Stage 1: Network exploration</bold>
. After the activation of a MCP by the user the process to find paths that connect the requesting node with the ones hosting the desired data starts. This exploration ends with the identification of a set of nodes connected with the initiator (directly or with intermediate connections with other nodes).</p>
<p>• <bold>Stage 2: Agreement proposal notification</bold>
. Every agent participating in a successful path will notify its creator about the possible agreement. At the end of this stage the initial MCP will receive a list of all existing possible agreements for the data exchange (corresponding to a list of paths that go from the leaf to the initiating MCP.).</p>
<p>• <bold>Stage 3: Agreement selection and notification</bold>
. The MCP will select a path or a set of paths and notify this decision to all the agents involved, considering - among other criteria - to avoid overlapping agreements that solve the access to the same dataset of the same MCC through different paths, or to datasets already collected.</p>
<p>• <bold>Stage 4: Data transfer</bold>
. After receiving the notification that a possible agreement is selected, the data exchange between all the nodes starts. This may end with a complete and successful data exchange or with some failure by some nodes. All the UCP waiting to receive data will send a message of acknowledgement (ACK) to their MCP after receiving the data or a message of non-acknowledgement (NACK) in case of a failure of data reception. The ACK (or NACK) is transmitted link to link until arriving to the main MCP at the top of the path.</p>
<p>• <bold>Stage 5: Transaction completion</bold>
. After receiving all the ACK from all the nodes involved in the agreement, the initiating MCP will send a COMMIT to all the Agents. In case some ACK is not received or a NACK is transmitted by some Agent, the MCP will send a ROLLBACK message to all the nodes. Only after the reception of a COMMIT the nodes will have the authorisation to use the data received. In case the transaction is aborted with a ROLLBACK, none of the nodes of an agreement that received data are authorised to use it.</p>
<p>During the negotiation process the agents generate a number of messages (<italic>N </italic>
) and those that correspond to the communications among different nodes involved in a multilateral agreement (<italic>i</italic>
), follow the calculation of Eq. (1).</p>
<p><disp-formula id="bmcM1"><label>(1)</label>
<mml:math id="M1" name="1479-5876-12-S2-S8-i1" overflow="scroll"><mml:mrow><mml:msub><mml:mrow><mml:mi>N</mml:mi>
</mml:mrow>
<mml:mrow><mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo class="MathClass-rel">=</mml:mo>
<mml:msub><mml:mrow><mml:mi>m</mml:mi>
</mml:mrow>
<mml:mrow><mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mfenced close=")" open="("><mml:mrow><mml:mn>4</mml:mn>
<mml:msub><mml:mrow><mml:mi>u</mml:mi>
</mml:mrow>
<mml:mrow><mml:mi>i</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo class="MathClass-bin">+</mml:mo>
<mml:mn>2</mml:mn>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
<p>Where <italic>m<sub>i </sub>
</italic>
and <italic>u<sub>i </sub>
</italic>
are the number of MCP and UCP respectively, involved in the agreement <italic>i</italic>
. The four messages per UCP correspond to the following:</p>
<p>• <bold>MCP </bold>
<italic>→ </italic>
<bold>MCC</bold>
: Dataset request</p>
<p>• <bold>UCC </bold>
<italic>→ </italic>
<bold>UCP</bold>
: Notification of the constraint</p>
<p>• <bold>UCP </bold>
<italic>→ </italic>
<bold>UCC</bold>
: Constraint delivery</p>
<p>• <bold>UCC </bold>
<italic>→ </italic>
<bold>UCP</bold>
: Acceptance of the agreement</p>
<p>The two messages per MCP correspond to:</p>
<p>• <bold>MCP </bold>
<italic>→ </italic>
<bold>YP</bold>
: Request from the MCP to the YP asking for the MCC offering the desired dataset</p>
<p>• <bold>YP </bold>
<italic>→ </italic>
<bold>MCP</bold>
: Response from the YP to the MCP with the list of references of MCC available</p>
<p>This measure is useful for the assessment of communication efficiency in terms of number of messages transmitted in the network (this is analysed in the validation and performance evaluation section).</p>
</sec>
<sec><title>Network exploration</title>
<p>In this stage of the <italic>MOSAIC </italic>
process, the MCP asks the YP to obtain the list of MCC to whom the data access requests can be addressed. The reference of the MCC delivered by the YP are those hosting a dataset of the type requested by the MCP. For each MCC three situations may arise:</p>
<p>• <bold>No constraint </bold>
The MCC offers the requested data set with no constraints to fulfil through a UCC. The UCP receives the notification of the data set availability and notifies this to the MCP.</p>
<p>• <bold>Constraint resolved locally </bold>
The constraint requested by the MCC can be delivered from the dataset owned by the node (i.e. without the need of an external MCC). The UCP asks to its MCP to look for the MCC active in its node in order to collect the data from its DataMart. The UCP sends the notification of the dataset availability at the UCC after the potential fulfilment of the constraint. The UCC sends the agreement for the possible dataset transfer initially requested to the UCP. Both UCC and UCP notify their agreement for the potential exchange of the corresponding datasets to their MCC and MCP.</p>
<p>• <bold>Constraint to be resolved externally </bold>
The constrain of the MCC cannot be resolved locally at the requesting node of the MCP. If the length of the path does not exceed the limit (monitored through a Time To Live -TTL- parameter) The UCP launches a new MCP to look for the data set needed in order to solve the constraint.</p>
<p>A node and an MCC can take part more than once in a path of a multilateral agreement, however a special case occurs when in order to solve a constraint of an MCC the subsequent activations of new MCP results in a new request to the same MCC. If the request comes from an MCP "child" (belonging to the same branch), the MCC decides to activate the UCC without any constraint and thus, deliver its dataset without receiving any dataset in advance (see Figure <xref ref-type="fig" rid="F3">3</xref>
). After completing the delivery of the other datasets in the path links the MCC receives the dataset of its constraint from the first MCP of the branch that initiated the negotiations.</p>
<fig id="F3" position="float"><label>Figure 3</label>
<caption><p><bold>Network path</bold>
. Example of a path in the network exploration where a MCC (in bold) will deliver its dataset without solving its constraint after identifying a loop.</p>
</caption>
<graphic xlink:href="1479-5876-12-S2-S8-3"></graphic>
</fig>
<p>The exploration of the network may cover all the possible paths (flooding) or a selection of them. The use of flooding is not only inefficient, but not feasible due to the computational costs. Therefore, when an MCP receives the set of MCC candidates, it will select a subset of them to continue the network exploration. The goals for an intelligent selection of the path are: i) get as much data as possible from the network, ii) get the most appreciated data (ranked with higher quality marks) and iii) reduce the risk of agreement failure (rollback).</p>
<p>For the first evaluation of the protocol, the criterion of the path selection chosen in this version of the protocol was the size of the dataset hosted at the MCC node. This criterion has been compared with the random selection of an MCC among the list of candidates and the results are described in the evaluation of the protocol (Validation and performance evaluation section). There is however, a set of indicators and more elaborate strategies that can be used for this purpose:</p>
<p>• <bold>Agreement Reputation </bold>
Calculated at MCC level and based on the number of previous exchange agreements and those where the MCC has fully respected its commitments.</p>
<p>• <bold>Dataset Reputation </bold>
Calculated also at MCC level, and based on the mean of the score given by each MCP, ranking the data delivered by a MCC after a successful data exchange agreement. Specific indicators that could be used are: i) Dataset size (number of items transmitted) and ii) Dataset cost (value paid for the items exchanged).</p>
<p>• <bold>On-line Network Analysis </bold>
A dynamic classifier calculated also at MCC level, and based on stream data mining techniques, updated in real-time according to the dynamic behaviour of the negotiation process. This strategy will learn from the experience and the successful or failed attempts to reach a dataset after after every request.</p>
<p>The <italic>MOSAIC Manager </italic>
permits to adjust the network exploration according to the user preferences and the specific density, inclusiveness, or degree of distribution of the network.</p>
<p>When an MCP does not find any MCC with the data set needed to fulfil a constraint, it stops the exploration and notifies to its creator UCP on the failure of the path in its attempt to find a multilateral agreement.</p>
<p>The network exploration concludes when all the paths: i) have concluded successfully and there is a possible multilateral agreement or ii) have failed in the agreement exploration or iii) the length has exceeded the TTL limit.</p>
<p>The complexity and performance of <italic>MOSAIC </italic>
depends on the strategy and behaviour of the Agents, mainly set by two parameters: The number of branches allowed to explore by every <italic>MCP </italic>
corresponding to the number of MCC activated (N) and the maximum lenght of the paths (TTL). The computational cost grows exponentially as bigger N and TTL (see Eq. (2)), and this could be compared with the complexity of the Dijkstra algorithm, which is <italic>O(E + VlogV </italic>
), where <italic>V </italic>
is the number of vertex and <italic>E </italic>
the number of edges, but as indicated in the introduction, this approach for finding the shortest path can be only used when the topology of the network is known.</p>
<p><disp-formula id="bmcM2"><label>(2)</label>
<mml:math id="M2" name="1479-5876-12-S2-S8-i2" overflow="scroll"><mml:mrow><mml:mi>N</mml:mi>
<mml:mi>u</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>M</mml:mi>
<mml:mi>C</mml:mi>
<mml:msub><mml:mrow><mml:mi>P</mml:mi>
</mml:mrow>
<mml:mrow><mml:mi>r</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo class="MathClass-rel">=</mml:mo>
<mml:mstyle displaystyle="true"><mml:munderover><mml:mrow><mml:mo> ∑</mml:mo>
</mml:mrow>
<mml:mrow><mml:mi>n</mml:mi>
<mml:mo class="MathClass-rel">=</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mrow><mml:mi>T</mml:mi>
<mml:mi>T</mml:mi>
<mml:mi>L</mml:mi>
</mml:mrow>
</mml:munderover>
</mml:mstyle>
<mml:msup><mml:mrow><mml:mi>N</mml:mi>
</mml:mrow>
<mml:mrow><mml:mi>T</mml:mi>
<mml:mi>T</mml:mi>
<mml:mi>L</mml:mi>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
</sec>
</sec>
<sec><title>The MOSAIC implementation</title>
<p>The interaction between the actors of <italic>MOSAIC </italic>
respects the following principles: i) The users of the protocol interact with the Multicast Agents, ii) Unicast Agents are created by Multicast Agents to negotiate every possible data exchange between two nodes, and iii) Multicast Agents communicate with Multicast Agents, Unicast agents with Unicast Agents, Petitioner Agents with Petitioner Agents, and Contributor Agents with Contributor Agents. Direct communications between an MCP and a UCC or between an MCC and a UCP are avoided.</p>
<p>Two important aspects of the implementation correspond to i) the way that a path of a possible agreement is created and propagated and ii) the way a loop is detected.</p>
<p>The MCP has been implemented according to Algorithm 1, the MCC is presented in Algorithm 2, the UCC in Algorithm 3, and the UCP implementation is presented in Algorithm 4. In order to clarify the process and to highlight only the most important features of the protocol, the pseudocode presented here merges the steps of stages 2 to 5 of the negotiation process and after an agreement, the dataset is directly transfered to the requesting agent.</p>
<sec><title>Agreement paths</title>
<p>After the activation of a new request by the user a <italic>Request </italic>
object is created. An instance of this object will be linked to every UCP and includes i) the ID of the requesting node, ii) the ID of the first MCP Agent of the negotiation chain, and iii) the ID of the negotiating branch. The value of the ID of the negotiating branch corresponds to a list of numbers that increases at every step of the path creation. When an MCP is launched by another MCP it receives from its creator the <italic>Request </italic>
object and adds to the branch ID a new number. In doing so the <italic>Request </italic>
object will contain the information needed to create the agreement paths.</p>
<p>A UCP arrives to the end of a path candidate to solve a multilateral agreement, when it receives the requested data from its UCC without the need to launch any other MCP. Consequently, it creates a message that will represent the negotiation path to which the UCP belongs to. This object is propagated to the higher levels of the Petitioners chain up to the MCP that initiated the request. During this bottom up process of transferring the agreement path candidate, all the Petitioners, at every link of the path, add to the object the relevant information and reference of the nodes to which there is a possible agreement. These correspond to the nodes where the MCC participating in the negotiation process with every MCP are hosted. At the end of the process of network exploration, the MCP that initiated the request receives, for every dataset of interest, the set of negotiation paths that correspond to a possible multilateral agreement. At that point, the MCP decides which negotiation paths to select from the possible candidates. An initial selection is performed among the paths that arrive to the same dataset, but the MCP may also decide to execute only a subset of all the remaining negotiation path candidates, based on other criteria (e.g. cost or reputation).</p>
<p><bold>Algorithm 1 </bold>
Multicast Petitioner Agent (<italic>MCP </italic>
)</p>
<p>Inputs</p>
<p><italic>ResourceRequested </italic>
from <italic>User </italic>
or <italic>UCP</italic>
</p>
<p><italic>NegotiationAgreement </italic>
from <italic>UCP</italic>
</p>
<p><italic>ResourceDataset </italic>
from <italic>UCP</italic>
</p>
<p><italic>MCC </italic>
from <italic>YellowPages </italic>
(YP)</p>
<p>1: Ask <italic>Y P </italic>
for MCC hosting the <italic>ResourceRequested</italic>
</p>
<p>2: Collect <italic>MCC </italic>
compatible from <italic>YellowPages</italic>
</p>
<p>3: Select <italic>MCC </italic>
to negotiate</p>
<p>4: <bold>for all </bold>
<italic>MCC </italic>
selected <bold>do</bold>
</p>
<p>5: Create <italic>UCP (ResourceRequested</italic>
)</p>
<p>6: Ask the <italic>UCP </italic>
to start the negotiation</p>
<p>7: <bold>if </bold>
<italic>NegotiationAgreement = TRU E </italic>
<bold>then</bold>
</p>
<p>8: Collect <italic>ResourceDataset </italic>
from <italic>UCP</italic>
</p>
<p>9: Send <italic>ResourceDataset </italic>
to the <italic>User </italic>
or <italic>UCP</italic>
</p>
<p>10: <bold>end if</bold>
</p>
<p>11: <bold>end for</bold>
</p>
<p><bold>Algorithm 2 </bold>
Multicast Contributor Agent (<italic>MCC</italic>
)</p>
<p>Inputs</p>
<p><italic>ResourceOf fered </italic>
from the <italic>User</italic>
</p>
<p><italic>Constraint </italic>
from the <italic>User</italic>
</p>
<p><italic>Request </italic>
from the <italic>MCP</italic>
</p>
<p><italic>NegotiationAgreement </italic>
from the <italic>UCC</italic>
</p>
<p><italic>ConstraintDataset </italic>
from the <italic>UCC</italic>
</p>
<p>1: Add <italic>MCC </italic>
to the <italic>YellowPages </italic>
(YP)</p>
<p>2: <bold>while </bold>
User does not stop the <italic>MCC </italic>
<bold>do</bold>
</p>
<p>3: Get <italic>Request </italic>
from some <italic>MCP</italic>
</p>
<p>4: <bold>if </bold>
<italic>Request = ResourceOffered </italic>
<bold>then</bold>
</p>
<p>5: <bold>if </bold>
Child-Loop detected <bold>then</bold>
</p>
<p>6: Create <italic>UCC(Request, NUL</italic>
)</p>
<p>7: <bold>else</bold>
</p>
<p>8: Create <italic>UCC(Request, Constraint</italic>
)</p>
<p>9: <bold>end if</bold>
</p>
<p>10: Ask the <italic>UCC </italic>
to start the negotiation</p>
<p>11: <bold>if </bold>
<italic>NegotiationAgreement = TRUE </italic>
<bold>then</bold>
</p>
<p>12: Collect <italic>ConstraintDataset </italic>
from <italic>UCC</italic>
</p>
<p>13: <bold>end if</bold>
</p>
<p>14: <bold>end if</bold>
</p>
<p>15: Remove <italic>UCC</italic>
</p>
<p>16: <bold>end while</bold>
</p>
<p>17: Remove <italic>MCC </italic>
from the <italic>YP</italic>
</p>
<p><bold>Algorithm 3 </bold>
Unicast Contributor Agent (<italic>UCC</italic>
)</p>
<p>Inputs</p>
<p><italic>Request </italic>
from <italic>UCP</italic>
</p>
<p><italic>Constraint </italic>
from <italic>MCC</italic>
</p>
<p><italic>ResourceOf fered </italic>
from <italic>MCC</italic>
</p>
<p><italic>ConstraintDataset </italic>
from <italic>UCP</italic>
</p>
<p><italic>ConstraintSolved </italic>
from <italic>UCP</italic>
</p>
<p>1: <bold>if </bold>
<italic>Constraint ≠ </italic>
<italic>NUL </italic>
<bold>then</bold>
</p>
<p>2: Send <italic>ResourceOffered </italic>
to UCP</p>
<p>3: <italic>NegotiationAgreement ← TRUE</italic>
</p>
<p>4: <bold>else</bold>
</p>
<p>5: Ask the <italic>UCP </italic>
to solve the constraint</p>
<p>6: <bold>if </bold>
<italic>ConstraintSolved = TRUE </italic>
<bold>then</bold>
</p>
<p>7: Collect <italic>ConstraintDataset </italic>
from <italic>UCP</italic>
</p>
<p>8: Send <italic>ConstraintDataset </italic>
to <italic>MCC</italic>
</p>
<p>9: <italic>NegotiationAgreement ← TRUE</italic>
</p>
<p>10: <bold>else</bold>
</p>
<p>11: <italic>NegotiationAgreement ← FALSE</italic>
</p>
<p>12: <bold>end if</bold>
</p>
<p>13: <bold>end if</bold>
</p>
<p>14: <bold>return </bold>
<italic>NegotiationAgreement</italic>
</p>
<p><bold>Algorithm 4 </bold>
Unicast Petitioner Agent (<italic>UCP </italic>
)</p>
<p>Inputs</p>
<p><italic>ResourceRequested </italic>
from <italic>MCP</italic>
</p>
<p><italic>constraint </italic>
from <italic>UCC</italic>
</p>
<p><italic>constraintDataset </italic>
from <italic>MCC</italic>
</p>
<p>1: Ask the <italic>UCC </italic>
to send the <italic>ResourceRequested</italic>
</p>
<p>2: <bold>if </bold>
<italic>Constraint </italic>
≠ <italic>NUL </italic>
<bold>then</bold>
</p>
<p>3: Search <italic>MCC </italic>
in the Node to solve the constraint</p>
<p>4: <bold>if </bold>
<italic>MCC </italic>
≠ <italic>N U L </italic>
<bold>then</bold>
</p>
<p>5: <italic>ConstraintSolved ← TRUE</italic>
</p>
<p>6: Get <italic>ConstraintDataset </italic>
from <italic>MCC</italic>
</p>
<p>7: Send <italic>ConstraintDataset </italic>
to the <italic>UCC</italic>
</p>
<p>8: <bold>else</bold>
</p>
<p>9: Create <italic>MCP </italic>
to look for the <italic>ConstraintDataset</italic>
</p>
<p>10: <bold>if </bold>
<italic>ConstraintDataset </italic>
found <bold>then</bold>
</p>
<p>11: <italic>ConstraintSolved ← TRUE</italic>
</p>
<p>12: Send <italic>ConstraintDataset </italic>
to the <italic>UCC</italic>
</p>
<p>13: <bold>else</bold>
</p>
<p>14: <italic>ConstraintSolved ← FALSE</italic>
</p>
<p>15: Notify failure to solve the constraint to the <italic>UCC</italic>
</p>
<p>16: <bold>end if</bold>
</p>
<p>17: <bold>end if</bold>
</p>
<p>18: <bold>end if</bold>
</p>
<p>19: <bold>if </bold>
<italic>Constraint = N U L </italic>
<bold>or </bold>
<italic>ConstraintSolved </italic>
<bold>then</bold>
</p>
<p>20: Collect <italic>ResourceRequested </italic>
from the <italic>UCC</italic>
</p>
<p>21: Send <italic>ResourceRequested </italic>
to <italic>MCP</italic>
</p>
<p>22: <italic>NegotationAgreement ← TRUE</italic>
</p>
<p>23: <bold>else</bold>
</p>
<p>24: <italic>NegotationAgreement ← FALSE</italic>
</p>
<p>25: <bold>end if</bold>
</p>
<p>26: <bold>return </bold>
<italic>NegotationAgreement</italic>
</p>
</sec>
<sec><title>Loop detection</title>
<p>Each agreement path or branch of the <italic>Petitions Tree </italic>
is built during the network exploration. Every branch is identified with a <italic>request identifier </italic>
corresponding to an array where each of its elements represents the participation of a Petitioner in the branch. It is important to note that an MCP will belong to more than one branch when i) it has more than one UCP exploring different options of agreement or ii) there is another MCP in the lower levels of its path with the same situation (managing more than one UCP).</p>
<p>A new request received by an MCC is processed and compared with all the other active requests managed by the MCC.</p>
<p>A loop is identified when all the elements of the array of some request identifier, that are active in the MCC, is equal to the first elements of the request identifier of the new request received, which means that the request comes from the same branch of that already active request at the MCC. In that case, the associated UCC will be created without any constraint. Security issues that arise here have already been studied and analysed [<xref ref-type="bibr" rid="B20">20</xref>
].</p>
</sec>
</sec>
<sec><title>Validation and performance evaluations</title>
<p>The assessment performed to the <italic>MOSAIC </italic>
system includes the validation and evaluation of i) the correctness of the protocol, ii) the advantatges of multilateral agreements compared with bilateral ones; iii) the optimisation process for the network exploration; abd iv) the analysis of the type of nodes that most benefit from the <italic>MOSAIC </italic>
system.</p>
<sec><title>The scenario evaluation</title>
<p>COPD comorbidities include a large list of diseases (see Table <xref ref-type="table" rid="T1">1</xref>
). For a better prognosis of a certain patient, analysing the information collected from other patients with similar profiles and suffering the same comorbidities, may be relevant.</p>
<table-wrap id="T1" position="float"><label>Table 1</label>
<caption><p>Datasets of the scenario evaluation: The most common comorbidities of COPD</p>
</caption>
<table frame="hsides" rules="groups"><thead><tr><th align="center">Dataset</th>
<th align="left">COPD Comorbidity</th>
<th align="center">Number of cases</th>
</tr>
</thead>
<tbody><tr><td align="center">D01</td>
<td align="left">Peripheral arterial diseases</td>
<td align="center">3663</td>
</tr>
<tr><td align="center">D02</td>
<td align="left">Prostate cancer</td>
<td align="center">1242</td>
</tr>
<tr><td align="center">D03</td>
<td align="left">Chronic renal failure</td>
<td align="center">4747</td>
</tr>
<tr><td align="center">D04</td>
<td align="left">Osteoporosis</td>
<td align="center">1097</td>
</tr>
<tr><td align="center">D05</td>
<td align="left">Gastroesophageal reflux disease</td>
<td align="center">5194</td>
</tr>
<tr><td align="center">D06</td>
<td align="left">Hyperlipidemia</td>
<td align="center">37890</td>
</tr>
<tr><td align="center">D07</td>
<td align="left">Congestive heart failure *</td>
<td align="center">3184</td>
</tr>
<tr><td align="center">D08</td>
<td align="left">Obstructive sleep apnea</td>
<td align="center">1386</td>
</tr>
<tr><td align="center">D09</td>
<td align="left">Atrial Fibrilation/Flutter *</td>
<td align="center">3011</td>
</tr>
<tr><td align="center">D10</td>
<td align="left">Lung cancer</td>
<td align="center">1135</td>
</tr>
<tr><td align="center">D11</td>
<td align="left">Erectile dysfunction</td>
<td align="center">2251</td>
</tr>
<tr><td align="center">D12</td>
<td align="left">Depression</td>
<td align="center">4963</td>
</tr>
<tr><td align="center">D13</td>
<td align="left">Breast cancer</td>
<td align="center">511</td>
</tr>
<tr><td align="center">D14</td>
<td align="left">Pulmonary fibrosis *</td>
<td align="center">236</td>
</tr>
<tr><td align="center">D15</td>
<td align="left">Substance abuse</td>
<td align="center">3169</td>
</tr>
<tr><td align="center">D16</td>
<td align="left">Abdominal aortic aneurism *</td>
<td align="center">404</td>
</tr>
<tr><td align="center">D17</td>
<td align="left">Anxiety *</td>
<td align="center">2257</td>
</tr>
<tr><td align="center">D18</td>
<td align="left">Benign prostatic hypertrophy</td>
<td align="center">19600</td>
</tr>
<tr><td align="center">D19</td>
<td align="left">Hypertension</td>
<td align="center">77908</td>
</tr>
<tr><td align="center">D20</td>
<td align="left">Hypothyroidism</td>
<td align="center">667</td>
</tr>
<tr><td align="center">D21</td>
<td align="left">Gastric/duodenal Ulcer *</td>
<td align="center">1882</td>
</tr>
<tr><td align="center">D22</td>
<td align="left">Diabetes</td>
<td align="center">5380</td>
</tr>
<tr><td align="center">D23</td>
<td align="left">Psychiatric disorders</td>
<td align="center">1092</td>
</tr>
<tr><td align="center">D24</td>
<td align="left">Coronary artery disease *</td>
<td align="center">29806</td>
</tr>
<tr><td align="center">D25</td>
<td align="left">Pulmonary HTN+CP *</td>
<td align="center">1599</td>
</tr>
<tr><td align="center">D26</td>
<td align="left">Cataract</td>
<td align="center">194</td>
</tr>
<tr><td align="center">D27</td>
<td align="left">Cerebrovascular accident</td>
<td align="center">1814</td>
</tr>
<tr><td align="center">D28</td>
<td align="left">Degenerative joint disease</td>
<td align="center">10373</td>
</tr>
<tr><td align="center">D29</td>
<td align="left">All others</td>
<td align="center">131</td>
</tr>
<tr><td></td>
<td align="left"><bold>TOTAL</bold>
</td>
<td align="center"><bold>226791</bold>
</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>Moreover, the knowledge of the effect of certain therapies to other patients with similar profiles may help the clinician to provide a more effective and efficient treatment to his or her patients. The <italic>MOSAIC </italic>
system could help both prognosis and theragnosis by facilitating the multilateral agreements for data exchange.</p>
<p>In this framework, the scenario used to test the <italic>MOSAIC </italic>
system, is composed by a set of nodes each of them with a number of datasets corresponding to a comorbidity of COPD. For each dataset each node activates an MCC. Every MCC is associated to a constraint corresponding to a disease randomly selected from all possible comorbidities or - with the same probability as any data type - to an empty constraint, in which case the MCC freely offers its dataset to any MCP. Two datasets have been created: One with 2.852 nodes corresponding to the main cities around the world, hosting 18.902 data sets; and another one for the most complex and time consuming evaluations with a subset of 205 cities with 1.824 datasets.</p>
<p>The evaluation of <italic>MOSAIC </italic>
has been performed on this simulated, but realistic scenario. The results shown in this article are based, firstly on the activation of the MCC for the datasets with the same cases available, and secondly on the activation of a request (or MCP) for every possible dataset, by every node (or city). This corresponds to 2.852 × 28 = 79.856 requests for the whole worldwide network and to 205 × 28 = 5.740 requests for the smaller network.</p>
</sec>
<sec><title>The database of the evaluation scenario</title>
<p>The evaluation scenario corresponds to a set of nodes (cities) each hosting a number of datasets with clinical cases of people suffering COPD and some comorbidities. While some datasets are freely offered to the network without any restriction, most of them have a constraint associated, requiring the delivery of some other dataset that may be available at some other node. The data base created for the simulations (freely available upon request) is composed by a network of 2.852 nodes corresponding to cites worldwide distributed with 18.902 datasets in total.</p>
<p>The constraints have been simulated calculating a random figure (from 0 to 29) at every node for every dataset. '0' represents that there is no dataset available with a COPD patient suffering from a specific comorbidity and no constraint can be assigned for delivering nothing. Any number between '1' and '28' indicates the reference of the COPD comorbidity to be delivered by the requesting node (as constraint for authorising the access to the data). '29' indicates that there is no constraint to fulfill and the cases available at the node for that specific comorbidity will be freely delivered to the requesting node.</p>
<p>On one hand, nodes with a large number of cases covering most of the data types will have a higher chance to directly solve a possible constraint and achieve bilateral agreements. On the other hand, the nodes with a reduced number of cases in their datasets will likely need multilateral agreements to get the data desired from the network. One of our hypothesis is that the system presented here will be especially useful for nodes with less chances to achieve bilateral agreements.</p>
</sec>
<sec><title>Simulation output</title>
<p>After the simulation execution a DB with the total number of cases collected per node and datatype was created. Table <xref ref-type="table" rid="T2">2</xref>
shows a subset of that database after the execution of the simulator with TTL = 20. Its content corresponds to the following:</p>
<p>• <bold>Node</bold>
: Requesting node</p>
<p>• <bold>R</bold>
: Resource requested</p>
<p>• <bold>C</bold>
: Initial number of cases of type R at the requesting node</p>
<p>• <bold>MCP</bold>
: Number of MCP participating in the multilateral agreement</p>
<p>• <bold>MSG</bold>
: Number of messages exchanged</p>
<p>• <bold>CC</bold>
: Number of new cases of type R collected from the network</p>
<p>• <bold>Path</bold>
: Average length of the multilateral agreement path</p>
<p>All the results presented in this article have been obtained after the processing of these figures.</p>
<table-wrap id="T2" position="float"><label>Table 2</label>
<caption><p>Data Base generated after the protocol execution</p>
</caption>
<table frame="hsides" rules="groups"><thead><tr><th align="left">Node</th>
<th align="center">R</th>
<th align="center">C</th>
<th align="center">MCP</th>
<th align="center">MSG</th>
<th align="center">CC</th>
<th align="center">Path</th>
</tr>
</thead>
<tbody><tr><td align="left">Akron</td>
<td align="center">D01</td>
<td align="center">0</td>
<td align="center">2</td>
<td align="center">20</td>
<td align="center">10</td>
<td align="center">3</td>
</tr>
<tr><td align="left">Akron</td>
<td align="center">D02</td>
<td align="center">0</td>
<td align="center">6</td>
<td align="center">156</td>
<td align="center">10</td>
<td align="center">7</td>
</tr>
<tr><td align="left">Akron</td>
<td align="center">D03</td>
<td align="center">10</td>
<td align="center">2</td>
<td align="center">20</td>
<td align="center">70</td>
<td align="center">3</td>
</tr>
<tr><td align="left">Akron</td>
<td align="center">D04</td>
<td align="center">0</td>
<td align="center">8</td>
<td align="center">272</td>
<td align="center">10</td>
<td align="center">9</td>
</tr>
<tr><td align="left">...</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec><title>Evaluation results</title>
<p>A first evaluation of the <italic>MOSAIC </italic>
protocol is a cross validation to check that it works properly. For this, algorithm 5 has been created. It scans the network of 2.852 cities and their 18.902 data sets seeking for all possible bilateral agreements. This algorithm generates as an output a matrix with the figures corresponding to all the cases collected by each node for every data type after the bilateral data exchanges. These figures have been compared with those obtained by the execution of the <italic>MOSAIC </italic>
protocol with the Time to Live parameter set to 1, forcing that the maximum length of every multilateral agreement is limited to 2 nodes. The results obtained in both cases are exactly the same, showing the correctness of the protocol for this scenario.</p>
<p>The second evaluation is to prove the main goal of the <italic>MOSAIC </italic>
system which is to overcome the amount of data that can be exchanged with bilateral agreements and collect as much data as possible from the network by achieving as much data exchange agreements as possible. The results obtained strongly depend on the parameters of the protocol, namely its TTL and the number of branches selected from all the paths available during the network exploration. Figure <xref ref-type="fig" rid="F4">4</xref>
shows the results with different values for TTL (1: bilateral agreements, 2: agreements among 3 nodes, and 3: agreements among 4 nodes) and with a range selection of paths starting from 1 (only exploring a single MCC from all available) to 50 (higher values of TTL are not needed as most of the data available in the network is made accessible after much more short negotiation paths). The percentages of data collected shows a steady increase when the selection of the number of possible paths increases, and while the improvement from TTL1 to TTL2 is significant, the increase from TTL2 to TTL3 is limited.</p>
<p><bold>Algorithm 5 </bold>
Search for bilateral exchange agreements</p>
<p>1: <bold>for </bold>
<italic>i </italic>
= 1 to <italic>numCities </italic>
<bold>do</bold>
</p>
<p>2: <bold>for </bold>
<italic>j </italic>
= 1 to <italic>numDataTypes </italic>
<bold>do</bold>
</p>
<p>3: <bold>for </bold>
<italic>k </italic>
= 1 to <italic>numCities </italic>
<bold>do</bold>
</p>
<p>4: <bold>if </bold>
<italic>i/ = k </italic>
<bold>then</bold>
</p>
<p>5: <bold>if </bold>
<italic>Dataset[k, j</italic>
] ≠ 0 <bold>then</bold>
</p>
<p>6: <bold>if </bold>
<italic>constraint[k, j</italic>
] = <italic>nul </italic>
<bold>then</bold>
</p>
<p>7: collect <italic>Dataset[k, j</italic>
] for node <italic>i</italic>
</p>
<p>8: <bold>else if </bold>
<italic>constraint[k, j</italic>
] available in node <italic>i </italic>
<bold>then</bold>
</p>
<p>9: solve <italic>constraint </italic>
from data in node <italic>i</italic>
</p>
<p>10: collect <italic>Dataset[k, j</italic>
] for node <italic>i</italic>
</p>
<p>11: <bold>end if</bold>
</p>
<p>12: <bold>end if</bold>
</p>
<p>13: <bold>end if</bold>
</p>
<p>14: <bold>end for</bold>
</p>
<p>15: <bold>end for</bold>
</p>
<p>16: <bold>end for</bold>
</p>
<fig id="F4" position="float"><label>Figure 4</label>
<caption><p><bold>Cases collected from the network</bold>
. Percentage of cases collected from the total number available in the network with different values of TTL and size of the selected path set.</p>
</caption>
<graphic xlink:href="1479-5876-12-S2-S8-4"></graphic>
</fig>
<p>Due to the time constraints during the simulations of the protocol behaviour with different TTL values, a subset of the whole DB has been created. Only 205 cities of the initial DB have been used for the simulations.</p>
<p>The third evaluation refers to the optimisation process for the network exploration through the intelligent selection of the paths to follow. As indicated in the <italic>MOSAIC </italic>
implementation section, the MCP receives the list of MCC compatible from the Yellow Pages and in order to avoid unmanageable network explorations the MCP has to decide which to select and which to discard. Two cases have been evaluated. One selects a MCC randomly from those available, and the other selects the MCC with the biggest dataset. The two cases have been tested using the database of 205 cities with 1.824 datasets in total.</p>
<p>Figure <xref ref-type="fig" rid="F5">5</xref>
shows the improvement in the number of agreements, when selecting the path to follow during the network exploration according to the size of the MCC dataset, instead of a random selection among the MCC available. When an MCP child (belonging to the same branch) needs to resolve a set of constraints to obtain the desired dataset, it is more likely to have an MCC in the higher levels of its branch that can solve it when the MCC's dataset is bigger. In those cases, the MCC that will receive a data access request from a child node (belonging to the same branch) will decide to offer the requested dataset to solve the constraint as this loop will benefit the overall multilateral agreement and the MCC will also get the desired dataset initially included as a constraint.</p>
<fig id="F5" position="float"><label>Figure 5</label>
<caption><p><bold>Agreements</bold>
. Total number of agreements using <italic>MOSAIC </italic>
with different TTL values.</p>
</caption>
<graphic xlink:href="1479-5876-12-S2-S8-5"></graphic>
</fig>
<p>Figure <xref ref-type="fig" rid="F6">6</xref>
shows the reduction in the number of messages transmitted over the network needed to achieve an agreement, comparing the selection criteria of the MCC between the strategy based on the dataset size and the random selection.</p>
<fig id="F6" position="float"><label>Figure 6</label>
<caption><p><bold>Messages</bold>
. Comparative of the average number of messages needed to achieve an agreement, between the two branch selection strategies.</p>
</caption>
<graphic xlink:href="1479-5876-12-S2-S8-6"></graphic>
</fig>
<p>Finally, we checked our hypothesis that the nodes with less data which had less chances to achieve bilateral agreements would be those that specially benefit from <italic>MOSAIC</italic>
. The figures corresponding to this hypothesis are shown in Figure <xref ref-type="fig" rid="F7">7</xref>
and are generated after running the <italic>MOSAIC </italic>
protocol in the evaluation scenario of the worldwide network. The total set of nodes has been grouped in 4 categories according to the size of the datasets (e.g. "less than 25%" indicates the category of the set of nodes with a number of cases in their datasets, minor than the 25% of the average size of all datasets in the network).</p>
<fig id="F7" position="float"><label>Figure 7</label>
<caption><p><bold>Cases collected through bilateral agreements</bold>
. Average of the percentage of cases collected by the nodes after bilateral exchanges. Nodes have been grouped according to the relative size of their local Data Marts in four categories. As larger Data Marts, as more data collected.</p>
</caption>
<graphic xlink:href="1479-5876-12-S2-S8-7"></graphic>
</fig>
</sec>
</sec>
<sec><title>Conclusions and future work</title>
<p>It has been demonstrated that the multilateral agreements among a set of nodes increase significantly the amount of data accessible in a network compared with the amount of data that can be collected from bilateral agreements.</p>
<p>Besides this, the need of a distributed process to support the achievement of multilateral agreements has been justified for the lack of global knowledge of the network topology derived from the reluctance to publish certain information in a centralised repository. The use of Agents has facilitated to model the negotiation process required by the actors of this system and this seems a natural way to implement the protocol.</p>
<p>It has been proved that the strategy to select the path to follow during the exploration of the network has implications in the number of agreements achieved among the nodes. For this, two criteria have been tested: i) A random selection and ii) A selection based on the Dataset size. Finally, it has been demonstrated that the total number of agreements among the nodes achieve better marks when the path selection is based on the dataset size.</p>
<sec><title>Future work</title>
<p>The research presented here is being extended or it is planned to be extended in the following aspects:</p>
<p>• <bold>Semantic representation</bold>
. Both datasets and constraints represented using OWL, as the standard for knowledge semantic representation.</p>
<p>• <bold>Constraints enrichment</bold>
. A more natural representation of the possible constraints will be based on a boolean expression composed by a set of clauses, some of them related to the delivery of a combination of certain datasets (not only a single one) and others related to the acceptance or rejection of certain top level conditions for the data access by the user.</p>
<p>• <bold>Core implementation</bold>
. The optimisation of the code to allow wider and deeper path explorations of the network in a reasonable time and the visualisation of the protocol results in a web based interface.</p>
<p>• <bold>Security and privacy</bold>
. Data disclosure protection, attacks prevention, authenticity, and other features of privacy and security are issues that will be integrated in the protocol with the deployment of previous research in the field [<xref ref-type="bibr" rid="B21">21</xref>
,<xref ref-type="bibr" rid="B22">22</xref>
] and their adaptation to this specific scenario.</p>
<p>• <bold>System deployment and evaluation in different scenarios</bold>
. It is expected that the results of the protocol will differ significantly depending on the specific scenario and characteristics of the network. Therefore, it is also planned to adapt the behaviour of the Agents to different frameworks and to identify which strategies are the best for each case and specifically the best balance between path length and branch selection wide (number of branches to explore among all the possible).</p>
<p>• <bold>Intelligent exploration</bold>
. Increase the intelligence of the path selection by including more advanced indicators (e.g. reputation, user similarity and cost) considering also previous research in the areas of agent trust, argumentation and reasoning [<xref ref-type="bibr" rid="B23">23</xref>
,<xref ref-type="bibr" rid="B24">24</xref>
].</p>
<p>• <bold>Game theory</bold>
. During the network exploration the MCP launches a request to get the desired data or to solve a constraint (if it is not the first MCP in the path). A set of MCC may answer and one or a set of them have to be selected.</p>
<p>On the one hand, the selection of the best MCC depends on the decision of the set of nodes or MCC-MCP pairs already involved in the agreement. All of them share the goal to complete the path and achieve the multilateral agreement with the new MCC that has to be selected. All of them want to maximise the chances to achieve a successful agreement and will share the information to get the best decision. On the other hand, the set of MCC candidates compete among them to be selected and be part of the multilateral agreement.</p>
<p>This can be modelled as an auction where the buyers are the set of participants at the partial path already built and the sellers are the MCC candidates. The MCC compete among them, but they could also agree among them some strategy and build some coalition in order to overcome their rivals.</p>
</sec>
</sec>
<sec><title>Competing interests</title>
<p>The authors declare that they have no competing interests.</p>
</sec>
<sec><title>Authors' contributions</title>
<p>M. Lluch-Ariet conceived and designed the MOSAIC System. J. Pegueroles-Vallés coordinated the scientific advances of the research and provided the top level guidelines to boost the results, together with F. Vallverdú. The implementation of the system has been done together between A. Brugués de la Torre and M. Lluch-Ariet.</p>
</sec>
</body>
<back><sec><title>Acknowledgements</title>
<p>We would like to thank our colleagues from the respiratory unit at Hospital Clínic in Barcelona, the Personalised Computational Unit and the whole R+D Health department at Barcelona Digital, the Telematics Engineering department at the UPC, and the Synergy-COPD consortium for the inspiring discussions we had with them regarding the content of this paper. Special thanks to Filip Velickovski for his technical and language review of the manuscript and to Dr. Josep Roca for his comments and recommendations.</p>
</sec>
<sec><title>Declarations</title>
<p>This research (including this publication) has been partially funded by the Synergy-COPD research grant, under the Seventh Framework Program of the European Commission as a Collaborative Project with contract number 270086 (2011-2014), and by the project TAMESIS (TEC2011-22746).</p>
<p>This article has been published as part of <italic>Journal of Translational Medicine </italic>
Volume 12 Supplement 2, 2014: Systems medicine in chronic diseases: COPD as a use case. The full contents of the supplement are available online at <ext-link ext-link-type="uri" xlink:href="http://www.translational-medicine.com/supplements/12/S2">http://www.translational-medicine.com/supplements/12/S2</ext-link>
.</p>
</sec>
<ref-list><ref id="B1"><mixed-citation publication-type="other"><article-title>European Commission IP/12/790: Scientific data: open access to research results will boost Europe's innovation capacity</article-title>
<year>2012</year>
<ext-link ext-link-type="uri" xlink:href="http://europa.eu/rapid/press-release_IP-12-790_en.htm">http://europa.eu/rapid/press-release_IP-12-790_en.htm</ext-link>
</mixed-citation>
</ref>
<ref id="B2"><mixed-citation publication-type="other"><article-title>European Commission IP/13/1257: Commission launches pilot to open up publicly funded research data</article-title>
<year>2013</year>
</mixed-citation>
</ref>
<ref id="B3"><mixed-citation publication-type="other"><article-title>European Medicines Agency EMA/240810/2013: Publication and access to clinical-trial data: an inclusive development process</article-title>
<year>2013</year>
<ext-link ext-link-type="uri" xlink:href="http://www.ema.europa.eu/ema/">http://www.ema.europa.eu/ema/</ext-link>
<comment>(Last accessed: 20-2-2014)</comment>
</mixed-citation>
</ref>
<ref id="B4"><mixed-citation publication-type="other"><name><surname>Hayden</surname>
<given-names>E Check</given-names>
</name>
<article-title>Global Alliance for genomic and clinical data sharing</article-title>
<source>Nature</source>
<ext-link ext-link-type="uri" xlink:href="http://www.nature.com/news/geneticists-push-for-global-data-sharing-1.13133">http://www.nature.com/news/geneticists-push-for-global-data-sharing-1.13133</ext-link>
<comment>(Last accessed: 1-07-2014).</comment>
</mixed-citation>
</ref>
<ref id="B5"><mixed-citation publication-type="other"><name><surname>Pianykh</surname>
<given-names>OS</given-names>
</name>
<article-title>A practical introduction and survival guide</article-title>
<year>2012</year>
</mixed-citation>
</ref>
<ref id="B6"><mixed-citation publication-type="other"><article-title>ISO/HL7 27931: HL7 Version 3 - Reference Information Model. ISO/HL7</article-title>
<ext-link ext-link-type="uri" xlink:href="http://www.iso.org">http://www.iso.org</ext-link>
</mixed-citation>
</ref>
<ref id="B7"><mixed-citation publication-type="other"><article-title>ISO 13606: Electronic Health Record Communication - Part 1: Reference Model. ISO</article-title>
<ext-link ext-link-type="uri" xlink:href="http://www.iso.org">http://www.iso.org</ext-link>
</mixed-citation>
</ref>
<ref id="B8"><mixed-citation publication-type="other"><name><surname>Stearns</surname>
<given-names>MQ</given-names>
</name>
<name><surname>S</surname>
<given-names>KA</given-names>
</name>
<name><surname>Price</surname>
<given-names>C</given-names>
</name>
<name><surname>Wang</surname>
<given-names>AY</given-names>
</name>
<article-title>Snomed clinical terms: overview of the development process and project status</article-title>
<source>Proc AMIA Symp</source>
<year>2001</year>
<fpage>662</fpage>
<lpage>666</lpage>
<pub-id pub-id-type="pmid">11825268</pub-id>
</mixed-citation>
</ref>
<ref id="B9"><mixed-citation publication-type="other"><name><surname>Spackman</surname>
<given-names>KA</given-names>
</name>
<name><surname>Campbell</surname>
<given-names>KE</given-names>
</name>
<name><surname>Côté</surname>
<given-names>RA</given-names>
</name>
<article-title>Snomed rt: A reference terminology for health care</article-title>
<source>J of the American Medical Informatics Association</source>
<year>1997</year>
<fpage>640</fpage>
<lpage>644</lpage>
</mixed-citation>
</ref>
<ref id="B10"><mixed-citation publication-type="other"><collab>ISO/TR 20514: Electronic Health Record - Definition, Scope and Context. ISO</collab>
<ext-link ext-link-type="uri" xlink:href="http://www.iso.org">http://www.iso.org</ext-link>
</mixed-citation>
</ref>
<ref id="B11"><mixed-citation publication-type="journal"><name><surname>Isern</surname>
<given-names>D</given-names>
</name>
<name><surname>Sánchez</surname>
<given-names>D</given-names>
</name>
<name><surname>Moreno</surname>
<given-names>A</given-names>
</name>
<article-title>Agents applied in health care: A review</article-title>
<source>International Journal of Medical Informatics</source>
<year>2010</year>
<volume>79</volume>
<issue>3</issue>
<fpage>145</fpage>
<lpage>166</lpage>
<pub-id pub-id-type="doi">10.1016/j.ijmedinf.2010.01.003</pub-id>
<pub-id pub-id-type="pmid">20129820</pub-id>
</mixed-citation>
</ref>
<ref id="B12"><mixed-citation publication-type="book"><name><surname>Annicchiarico</surname>
<given-names>R</given-names>
</name>
<name><surname>Cortés</surname>
<given-names>U</given-names>
</name>
<name><surname>Urdiales</surname>
<given-names>C</given-names>
</name>
<source>Agent Technology and e-Health</source>
<year>2008</year>
<edition>1</edition>
<publisher-name>Whitestein Series in Software Agent Technologies and Autonomic Computing. Birkhuser Basel</publisher-name>
</mixed-citation>
</ref>
<ref id="B13"><mixed-citation publication-type="journal"><name><surname>Merelli</surname>
<given-names>E</given-names>
</name>
<name><surname>Armano</surname>
<given-names>G</given-names>
</name>
<name><surname>Cannata</surname>
<given-names>N</given-names>
</name>
<name><surname>Corradini</surname>
<given-names>F</given-names>
</name>
<name><surname>d'Inverno</surname>
<given-names>M</given-names>
</name>
<name><surname>Doms</surname>
<given-names>A</given-names>
</name>
<name><surname>Lord</surname>
<given-names>P</given-names>
</name>
<name><surname>Martin</surname>
<given-names>A</given-names>
</name>
<name><surname>Milanesi</surname>
<given-names>L</given-names>
</name>
<name><surname>Moller</surname>
<given-names>S</given-names>
</name>
<name><surname>Schroeder</surname>
<given-names>M</given-names>
</name>
<name><surname>Luck</surname>
<given-names>M</given-names>
</name>
<article-title>Agents in bioinformatics, computational and systems biology</article-title>
<source>Brief Bioinform</source>
<year>2007</year>
<volume>8</volume>
<issue>1</issue>
<fpage>45</fpage>
<lpage>59</lpage>
<pub-id pub-id-type="pmid">16772270</pub-id>
</mixed-citation>
</ref>
<ref id="B14"><mixed-citation publication-type="journal"><name><surname>Goldberger</surname>
<given-names>AL</given-names>
</name>
<name><surname>Amaral</surname>
<given-names>LAN</given-names>
</name>
<name><surname>Glass</surname>
<given-names>L</given-names>
</name>
<name><surname>Hausdorff</surname>
<given-names>JM</given-names>
</name>
<name><surname>Ivanov</surname>
<given-names>PC</given-names>
</name>
<name><surname>Mark</surname>
<given-names>RG</given-names>
</name>
<name><surname>Mietus</surname>
<given-names>JE</given-names>
</name>
<name><surname>Moody</surname>
<given-names>GB</given-names>
</name>
<name><surname>Peng</surname>
<given-names>C-K</given-names>
</name>
<name><surname>Stanley</surname>
<given-names>HE</given-names>
</name>
<article-title>PhysioBank, PhysioToolkit, and PhysioNet: Components of a new research resource for complex physiologic signals</article-title>
<source>Circulation</source>
<year>2000</year>
<volume>101</volume>
<issue>23</issue>
<fpage>215</fpage>
<lpage>220</lpage>
<comment>(June 13). Circulation Electronic Pages: <ext-link ext-link-type="uri" xlink:href="http://circ.ahajournals.org/cgi/content/full/101/23/e215">http://circ.ahajournals.org/cgi/content/full/101/23/e215</ext-link>
</comment>
<pub-id pub-id-type="doi">10.1161/01.CIR.101.23.e215</pub-id>
</mixed-citation>
</ref>
<ref id="B15"><mixed-citation publication-type="journal"><name><surname>Komatsoulis</surname>
<given-names>GA</given-names>
</name>
<name><surname>Warzela</surname>
<given-names>DB</given-names>
</name>
<name><surname>Hartela</surname>
<given-names>FW</given-names>
</name>
<name><surname>Shanbhaga</surname>
<given-names>K</given-names>
</name>
<name><surname>Chilukuric</surname>
<given-names>R</given-names>
</name>
<name><surname>Fragosoa</surname>
<given-names>G</given-names>
</name>
<name><surname>de Coronadoa</surname>
<given-names>S</given-names>
</name>
<name><surname>Reevesa</surname>
<given-names>DM</given-names>
</name>
<name><surname>Hadfielda</surname>
<given-names>JB</given-names>
</name>
<name><surname>Ludetb</surname>
<given-names>C</given-names>
</name>
<name><surname>Covitza</surname>
<given-names>PA</given-names>
</name>
<article-title>cacore version 3: Implementation of a model driven, service-oriented architecture for semantic interoperability</article-title>
<source>Journal of Biomedical Informatics</source>
<year>2008</year>
<volume>41</volume>
<fpage>106</fpage>
<lpage>123</lpage>
<pub-id pub-id-type="doi">10.1016/j.jbi.2007.03.009</pub-id>
<pub-id pub-id-type="pmid">17512259</pub-id>
</mixed-citation>
</ref>
<ref id="B16"><mixed-citation publication-type="book"><name><surname>Pedrinaci</surname>
<given-names>C</given-names>
</name>
<name><surname>Cardoso</surname>
<given-names>J</given-names>
</name>
<name><surname>Leidig</surname>
<given-names>T</given-names>
</name>
<source>Linked USDL: A Vocabulary for Web-scale Service Trading</source>
<year>2014</year>
<publisher-name>Springer, Crete (Greece). European Semantic Web Conference (ESWC)</publisher-name>
</mixed-citation>
</ref>
<ref id="B17"><mixed-citation publication-type="book"><name><surname>Lluch-Ariet</surname>
<given-names>M</given-names>
</name>
<name><surname>Estanyol</surname>
<given-names>F</given-names>
</name>
<name><surname>Mier</surname>
<given-names>M</given-names>
</name>
<name><surname>Delgado</surname>
<given-names>C</given-names>
</name>
<name><surname>González-Vélez</surname>
<given-names>H</given-names>
</name>
<name><surname>Dalmas</surname>
<given-names>T</given-names>
</name>
<name><surname>Robles</surname>
<given-names>M</given-names>
</name>
<name><surname>Sáez</surname>
<given-names>C</given-names>
</name>
<name><surname>Vicente</surname>
<given-names>J</given-names>
</name>
<name><surname>Huffel</surname>
<given-names>SV</given-names>
</name>
<name><surname>Luts</surname>
<given-names>J</given-names>
</name>
<name><surname>Arús</surname>
<given-names>C</given-names>
</name>
<name><surname>Silveira</surname>
<given-names>APC</given-names>
</name>
<name><surname>Julià-Sapé</surname>
<given-names>M</given-names>
</name>
<name><surname>Peet</surname>
<given-names>A</given-names>
</name>
<name><surname>Gibb</surname>
<given-names>A</given-names>
</name>
<name><surname>Sun</surname>
<given-names>Y</given-names>
</name>
<name><surname>Celda</surname>
<given-names>B</given-names>
</name>
<name><surname>Bisbal</surname>
<given-names>MCM</given-names>
</name>
<name><surname>Valsecchi</surname>
<given-names>G</given-names>
</name>
<name><surname>Dupplaw</surname>
<given-names>D</given-names>
</name>
<name><surname>Hu</surname>
<given-names>B</given-names>
</name>
<name><surname>Lewis</surname>
<given-names>P</given-names>
</name>
<article-title>On the Implementation of HealthAgents: Agent-Based Brain Tumour Diagnosis</article-title>
<source>Whitestein Series in Software Agent Technologies and Autonomic Computing</source>
<year>2008</year>
<publisher-name>Birkhuser Basel</publisher-name>
<fpage>5</fpage>
<lpage>24</lpage>
</mixed-citation>
</ref>
<ref id="B18"><mixed-citation publication-type="journal"><name><surname>Estanyol</surname>
<given-names>F</given-names>
</name>
<name><surname>Palou</surname>
<given-names>XR</given-names>
</name>
<name><surname>Roset</surname>
<given-names>R</given-names>
</name>
<name><surname>Lurgi</surname>
<given-names>M</given-names>
</name>
<name><surname>Mier</surname>
<given-names>M</given-names>
</name>
<name><surname>Lluch-Ariet</surname>
<given-names>M</given-names>
</name>
<article-title>A web-accessible distributed data warehouse for brain tumour diagnosis</article-title>
<source>Knowledge Eng Review</source>
<year>2011</year>
<volume>26</volume>
<issue>3</issue>
<fpage>329</fpage>
<lpage>351</lpage>
<pub-id pub-id-type="doi">10.1017/S0269888911000142</pub-id>
</mixed-citation>
</ref>
<ref id="B19"><mixed-citation publication-type="journal"><name><surname>Dijkstra</surname>
<given-names>EW</given-names>
</name>
<article-title>A note on two problems in connexion with graphs</article-title>
<source>Numerische Mathematik</source>
<year>1959</year>
<volume>1</volume>
<fpage>269</fpage>
<lpage>271</lpage>
<pub-id pub-id-type="doi">10.1007/BF01386390</pub-id>
</mixed-citation>
</ref>
<ref id="B20"><mixed-citation publication-type="book"><name><surname>Brugues De La Torre</surname>
<given-names>A</given-names>
</name>
<name><surname>Lluch-Ariet</surname>
<given-names>M</given-names>
</name>
<name><surname>Pegueroles-Valles</surname>
<given-names>J</given-names>
</name>
<source>Security analysis of a protocol based on multiagents systems for clinical data exchange</source>
<year>2013</year>
<publisher-name>Complex, Intelligent, and Software Intensive Systems (CISIS), 2013 Seventh International Conference On</publisher-name>
<fpage>305</fpage>
<lpage>311</lpage>
</mixed-citation>
</ref>
<ref id="B21"><mixed-citation publication-type="other"><name><surname>Tomàs-Buliart</surname>
<given-names>J</given-names>
</name>
<name><surname>Fernández</surname>
<given-names>M</given-names>
</name>
<name><surname>Soriano</surname>
<given-names>M</given-names>
</name>
<article-title>Protection of mobile agents execution using a modified self-validating branch-based software watermarking with external sentinel</article-title>
<year>2009</year>
<volume>5508</volume>
<fpage>287</fpage>
<lpage>294</lpage>
</mixed-citation>
</ref>
<ref id="B22"><mixed-citation publication-type="other"><name><surname>Rebollo-Monedero</surname>
<given-names>D</given-names>
</name>
<name><surname>Forné</surname>
<given-names>J</given-names>
</name>
<article-title>How do we measure privacy</article-title>
<source>Upgrade</source>
<year>2010</year>
<fpage>53</fpage>
<lpage>58</lpage>
</mixed-citation>
</ref>
<ref id="B23"><mixed-citation publication-type="book"><name><surname>Sierra</surname>
<given-names>C</given-names>
</name>
<name><surname>Debenham</surname>
<given-names>J</given-names>
</name>
<person-group person-group-type="editor">Paolucci, M</person-group>
<source>Information-based reputation</source>
<year>2009</year>
<publisher-name>Gargonza, Italy</publisher-name>
<fpage>5</fpage>
<lpage>19</lpage>
</mixed-citation>
</ref>
<ref id="B24"><mixed-citation publication-type="book"><name><surname>Parsons</surname>
<given-names>S</given-names>
</name>
<name><surname>Tang</surname>
<given-names>Y</given-names>
</name>
<name><surname>Sklar</surname>
<given-names>E</given-names>
</name>
<name><surname>McBurney</surname>
<given-names>P</given-names>
</name>
<name><surname>Cai</surname>
<given-names>K</given-names>
</name>
<source>Argumentation-based reasoning in agents with varying degrees of trust</source>
<year>2011</year>
<publisher-name>AAMAS</publisher-name>
<fpage>879</fpage>
<lpage>886</lpage>
</mixed-citation>
</ref>
</ref-list>
</back>
</pmc>
</record>
Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Ticri/CIDE/explor/TelematiV1/Data/Pmc/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 000354 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd -nk 000354 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien |wiki= Ticri/CIDE |area= TelematiV1 |flux= Pmc |étape= Corpus |type= RBID |clé= PMC:4255915 |texte= Knowledge sharing in the health scenario }}
Pour générer des pages wiki
HfdIndexSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/RBID.i -Sk "pubmed:25471452" \ | HfdSelect -Kh $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd \ | NlmPubMed2Wicri -a TelematiV1
![]() | This area was generated with Dilib version V0.6.31. | ![]() |