Supporting Interoperability of Autonomous Hospital Databases: A Case Study

We describe an approach that supports distributed information discovery when interoperating with large number of autonomous hospital databases. The approach is presented through a case study based on the health care network. The idea is to perform complete execution of a query: data request, database location and data access, in a distributed way, avoiding the use of integrated schemas and centralised structures. The discovery process is limited to a group of databases that have either related data or knowledge about other databases that possibly holds the required data. The process is recursive, executed in parallel and avoids cycles. The approach permits dynamic evolution of the system and attempts to preserve the autonomy of the databases. A prototype has been developed for academic and research purposes. It demonstrates the feasiability of the approach as an alternative to interoperate with a large number of autonomous databases without using integrated schemas.


Introduction
The ability to share and exchange data between (legacy) database systems is an important problem currently faced by many large organisations.Research is necessary to achieve interoperability so as to evolve from the situation where single databases are accessed and manipulated in isolation to the case where it is possible to access simultaneously di erent databases (local and remote access).The di culties associated with interoperability between large scale databases include heterogeneity and autonomy of the databases, conict resolution and semantic representation of the data, location and identi cation of relevant information, access of remote data, and easy evolution of the system.
An example of the interoperability problem is found in the health care network, where each hospital, or even each department in a hospital, keeps its own database.In this environment it is very important to permit users to locate and access data from several remote databases, supporting the needs of patient care, daily operations of the hospitals and research consultations.This thereby supports the sharing and exchange of data related to clinical, administrative, managerial and research (statistical) information.Examples of these situations are illustrated as follows: (1) a gynaecologist wants to know the records (the last 7 months history) of patient X who is in her 8 th month of pregnancy; (2) an administrator wants to know about the availability of operating theatres on a certain day/time to arrange a surgery; (3) a fellow student wishes to know statistics information about successful heart transplants in patients between 40 and 50 years old.
The location and identi cation of information that is relevant, identical, similar and related to requested data (information discovery) is an important issue when dealing with interoperability of autonomous databases.Existing approaches assume that the system either knows the location of the requested data, or uses centralised structures with information about the available data and where it is located.In an environment composed of databases that are created This work has been supported by Brazilian foundation CNPq, grant no.200209/94-9.and administered independently, in which each hospital or department keeps its own patient records, it is di cult and impractical to build integrated schemas.The use of a centralised structure with information about the location of data can be a performance bottleneck.Therefore, it is necessary to propose an approach that permits interoperability of these databases.
In this paper we demonstrate, through a case study, the use of the approach proposed in previous work 18,20,21,22].The approach permits distributed information discovery when interoperating with various hospital databases.Our aim is to allow \naive" users (doctors, nurses, fellows, members of the hospital sta ) to access and manipulate local and remote data.The approach is an alternative to the problem of building an integrated global schema when dealing with a large number of databases.The idea is to perform the complete execution of a query: data request, database location and data access, in a distributed way, avoiding the use of integrated schemas, centralised structures and broadcast to all the databases in the system.The approach attempts to preserve the autonomy of the hospital databases and supports evolution of the system in terms of adding or removing databases.
The case study is based on data obtained from real databases of di erent hospitals in Britain.A prototype has been built for academic and research purposes.Although it has not been tested in real situations and does not contain a large number of databases, it is su cient to show the feasibility of the approach.It has demonstrated the possibility of the execution of various queries and the access of data in remote databases.It also indicates that the discovery process terminates and that the approach supports evolution of the system.Experience indicates that it is easier to use this approach than to build a global schema composed of di erent existing schemas.It has also shown that the autonomy of the databases is preserved.
The paper addresses the setting up of the system, the location, identi cation and access of data, and the evolution of the system for a large number of hospital databases.The remainder of the paper is structured as follows.Section 2 contains an overview of the system, with a description of the di erent parts of the architecture which assist with the operation of the system.In section 3 we present how to setup the system.Section 4 contains the description of the use of the system, where we illustrate the complete execution of a request.In section 5 we present the evolution of the system.Section 6 contains some implementation experience and evaluation of the prototype.In section 7 we present an overview of related work.Finally, section 8 summarises the

System Overview
The case study is composed of three hospitals wishing to share and exchange data between each other.Hospital-A is a general hospital composed of relational multidatabases where each department of the hospital has its own database.Figure 1 presents the various departmental databases of hospital-A.Hospital-B is a child care hospital formed by a centralised relational database (DBHB).Hospital-C is a general hospital composed of a centralised object-oriented (O2) database (DBHC).
To support interoperability of the di erent databases we suggest the use of the architecture proposed in previous work 18, 21,22].The architecture supports a distributed information discovery process 20] and access and manipulation of local and remote data.
We organise the participating databases in the system into federations.A federation consists of a set of databases that wish to share and exchange data with each other.It is formed based on the shared data (public schema) of the databases and the databases that are allowed to access this data.This public schema is a subset of the local schema of the database.A database can participate in more than one federation (overlapping), sharing a distinct set of data in each of these federations.There is no communication between two federations.Inside a federation a set of shared data from one database is public for all the other participants in the federation.The idea of the federations is to provide a certain privacy of the shared data and to avoid using negotiation strategies between databases that are exchanging data.All the databases consulted during a discovery process belong to the same federation and can exchange its set of shared data, related to this federation, with each other.
Inside a federation we propose a second level of organisation, classifying the databases into groups.These groups are used to facilitate the information discovery process by reducing the universe of search.The groups are de ned based on Examples of some federations used in the case study, with its respective groups, are presented in gures 2, 3 and 4. Federation 1 is created to permit the exchange of data related to children between hospital-A and hospital-B.Federation 2 is composed of all the departmental databases of hospital-A, allowing the share of data inside the whole structure.Federation 3 is meant to let the share of data related to transplants performed in hospital-A and hospital-B.
In order to assist with the location of the data we use an unbalanced hierarchical structure.Each database has a di erent hierarchical structure for each federation in which it participates.This structure is composed of the names of the groups of the federation and specialised terms, forming a natural hierarchy of names.Associated with these terms are references to the concerned databases.Figures 5 and   6 present the hierarchical structure for database DBHB in federation 1 and federation 3, respectively.Experience indicates that it is possible to use this structure to identify the databases related to a request.
De ning the terms that compose the hierarchy requires human assistance.This is provided by the coordinator of the federation.We have built a methodology and a tool to help The idea is to de ne the terms based on the interests of the users and applications, and information that each database is sharing with the system (schema and instances).Therefore, the di erent group names refer to the type of databases participating in the federation.The other levels are related to the entities, attributes and object names, and instances of the databases.The methodology and tool permit the hierarchy to be built and to evolve by incremental addition of the participating databases, where many steps are executed automatically.The coordinator is responsible to specify the type of the participating databases and to identify the part of the schemas and instances used to compose the hierarchical structures.The tool is responsible for proposing the di erent groups composing a federation, with its related specialisations.The coordinator validates the suggestions of the tool and propose some changes, if necessary.The hierarchical structure evolves as a consequence of system modi cation (addition and removal of databases) and as needed to adjust the structure to the requirements of the users and applications.This is done based on statistical information related to the use of the di erent branches of the hierarchy, and on recommendations from users when they identify the absence of terms matching their request.
For each group in a federation we suggest the use of a special structure called master (MGx).The master of a group is the hierarchical structure described above containing the most up to date information about the organisation of the related federation.The idea of using the master is to permit the system to evolve without having to stop ongoing request executions in the system.The changes in the system such as: addition and removal of databases; creation, removal and modi cations of the groups; insertion and deletion of federations are rst noti ed to the masters of related groups.Subsequently, the hierarchical structures of the related databases are gradually updated (cf.section 5).Thus, inside a federation the hierarchical structures of the participating databases can contain di erent information.
Each database in the system contains a special structure called FED with information about the di erent federations in which the database participates.Figure 7 contains the FED structure of database DBC&P of hospital-A.The idea of using this structure is to identify the related federation where the search for a certain data should be executed.For example, it does not make sense to perform the search of data related to heart transplants executed in patients older than 35 years in federation 1.
We suggest to use a replicated relational database named Syst-DB with general information about the di erent federations, groups and participating databases of the system.This structure is consulted to identify the correct federation to add a new database.
A major issue when dealing with interoperability of autonomous databases without using integrated schemas is related to the speci cation of the queries to be executed in a remote database.It is impossible for a user to execute remote queries without knowledge of the schemas of the remote databases.As a solution for this problem we suggest the use of a graphical interface that assists the user to compose the query related to a request.The user is responsible to select and complete options in a template.The options presented to the user are associated with the terms in the hierarchy that are relevant to the request of the user.This general query is translated to the speci c schema/languages of the remote accessed databases.An example is presented in gure 8 where a user from database DBC&P in federation  3 is interested in successful kidney transplants performed in patients younger than 15 years.The di erent options presented in the graphical interface related to a certain request are based on the schema of the di erent databases that possibly contain the requested data.However, we a rm that this is not a global integrated schema formed by the integration of the di erent schemas as proposed in some existing approaches 1, 4, 16, 17].
3 System Setup The system setup is performed when two or more databases want to share and exchange data between each other.In the rst step the DBA of the involved databases determines the set(s) of data of each database to be shared and speci es the type of data being shared.Afterwards, a coordinator is elected to assist with the setup of the system.
Based on the set of shared data, on the databases allowed to access this data and on the type of information in which the users are interested, the coordinator determines the various related federations.Notice that it is only necessary to have one federation to start the system.The other federations can be added incrementally to the system during its operation.When more than one federation is speci ed it is essential to have one coordinator for each federation.In each identi ed federation it is necessary to determine the di erent groups with its associated terms.This is achieved using the methodology and tool explained above.
After organising the databases into the di erent groups the coordinator identi es the masters associated to each group and the hierarchical structures are de ned.During the creation of the system all the hierarchical structures of a certain federation contain the same information.
The next step consist of determining the graphical interface.Subsequently, the general information of the system is inserted in the Syst-DB, the FED structures of the related databases are constructed and the system can start to be used.
For the case study, let us assume two situations.First, the users of the databases of hospital-A want to share data among the di erent departments of the hospital.Second, the users of the databases of hospital-A and hospital-B wish to access and share information related to children and transplants.Therefore, the DBA of each of these databases determine the di erent sets of data to be shared.The federations presented in gures 2, 3 and 4 are constructed together with their related hierarchical structures shown in gures 5, 9, and 6.  4 System Use -Discovery Process The discovery process is executed in parallel in databases that either contain the requested information or know about other databases that possibly hold the required data.A detailed description of the process, together with the correctness proof of the algorithm and some complexities measurements, can be found in 20].
Consider the situation where a doctor from hospital-A, working at the Cardio-Pneumology department (DBC&P ), wants to know about successful kidney transplants performed in patients younger than 15 years.The rst step consists of identifying the federation in which the database DBC&P participates that is related to the request.In this case, the system presents to the doctor the information shown in gure 7, allowing him/her to choose the correct federation.The doctor identi es federation 3 as the related federation to perform the search.
After identifying the federation where the process will be executed, the user browses the local hierarchical structure of database DBC&P related to federation 3, in order to determine the group of databases to be searched, the path of terms in the hierarchy related to the request and the respective databases that possibly contain the related data.Assume the hierarchy of DBC&P is as shown in gure 6.For the current request the user identi es Renal group, the terms: history and children and the databases DBTRA, DBHB and DBR&H.The idea of browsing the hierarchical structure the rst time is to facilitate data location.Thus, we avoid the problem of keywords matching between the user input and the terms in the hierarchy.Keywords matching normally requires the use of dictionaries and depends on the order that the terms appear in the hierarchy.
Based on the speci ed group and terms the system shows the associated interface and the user composes the query q 0 as presented in gure 8.The query q 0 , the address of the source component (DBC&P ) and the related terms in the hierarchy constitute the request r 0 .The request is sent in parallel to databases DBTRA, DBHB and DBR&H.After receiving r 0 , each database is consulted to verify if it contains the requested information.This is done by translating q 0 to the speci c language/schema of the database.
Suppose that database DBTRA does not contain the data related to the request.The process is recursive and the hierarchical structure of DBTRA, related to federation 3, is automatically traversed.The hierarchy is traversed based on the terms that compose the request r 0 .This is executed to allow the identi cation of other related databases not presented in the hierarchy of the source component.It is possible that the terms in the hierarchy of DBTRA di er from the terms in the hierarchy of DBC&P .However, we guarantee that all the hierarchical structures of a federation contain the same terms related to the various group names.
Assume the hierarchical structure of DBTRA the same as presented in gure 6. DBTRA does not contain the requested information and does not know about any other database participating in federation 3 that is related to the request and has not been visited.Therefore, we propose to send the request to the master MG12 of the Renal group.Consider the case where DBHB receives the request r 0 , it does not contain the related information, but it knows about a `new' related database.That is, a database that is not presented in the associated branch of the hierarchy of DBC&P .Figure 10 presents part of the hierarchy of DBHB, related to federation 3, with the `new' database DBHC.In this case, r 0 is sent to DBTRA, DBR&H and DBHC.The related data is sent to the source database to be evaluated by the user.In the event where the user is satis ed with the data, the discovery process has to be cancelled, since it is still being executed for the other databases.Suppose that the user is not satis ed with the received data and the process continues normally.The hierarchical structure of DBR&H is consulted in order to identify other related databases.
When the master MG12 receives the request r 0 it tries to identify `new' related databases recently added to the system and not yet visited.Consider part of the hierarchy of MG12 as shown in gure 11, where MG12 contains extra information about database DB 0 .The request is sent to DB 0 .
Due to the fact that the process is executed in parallel, when a database receives a request it does not know about the other databases that have received this request before.However, the discovery process tries to prevent cycles, that is, the access to a database more than once for the same request.This is executed by maintaining, in each participating database, for each discovery process, information about the  of the discovery process of r 0 associated request.Hence, whenever a database receives a request it veri es if it has received this request before.If so, it sends a negative reply to the last sender and ignores the request.For instance, when databases DBTRA and DBR&H receive the request r 0 from database DBHB, they ignore this request and send a negative reply to DBHB.
Consider that DBHC does not have the requested information and does not know about any other database not accessed for r 0 .In this case, DBHC sends a not-existing message to DBHB denoting that it has nished the search process for r 0 .The same happens with DBR&H that sends a not-existing message to DBC&P .When a database receives negative replies and not-existing messages from all databases for where it have sent the request, this database sends a not-existing message to the rst database that had sent it the request.This process continues until reaching the source component.As a result, the source database concludes about the non existence of the requested data in the system.Thus, after DBHB receives the not-existing message from DBHC and negative replies from DBTRA, DBR&H and MG12, it sends a not-existing message to DBC&P .Suppose that DB 0 does not contain the requested data.DB 0 sends a noti cation to MG12, that sends it to DBTRA.
Figure 12 presents a graph related to the scenario being presented, with the di erent types of messages sent during the execution of r 0 .

System Evolution
The proposed approach permits dynamic evolution of the system.It allows the addition and removal processes to be executed in an interactive way, without having to stop the whole system.The idea is to rst update `strategic points', the masters of the related federation, and gradually notify the other participating databases, by updating its hierarchical structures.A database (or group) has autonomy to decide whether it wants to participate in the system.The decision is very decentralised, not requesting the approval of a central authority or of all the databases in the system.However, when a database is added into a federation the other databases in this federation have to authorise its par-ticipation.The existing databases have to agree about sharing and exchanging data with the `new' database.In order to support the evolution of the system we use the Syst-DB, together with the assistance of DBAs and coordinators of the involved databases and federations.

Addition
The system supports the addition of a database, a group of databases and a federation.The addition of a `new' database refers to the inclusion of this component into a federation.The database can already exist in the system, but participating in di erent federations.The addition of a single database can cause either the inclusion of a group inside the related federation, or the creation of a new federation.
Suppose the situation where the database of hospital-C (DBHC) wants to participate in the system.Assume that the users of DBHC are interested in sharing and exchanging information related to transplant and cancer.The rst step consists of identifying the `correct place' to execute the addition of DBHC.Therefore, the DBA of DBHC consults the Syst-DB.
For the `transplant' case, the DBA identi es federation DBHC and the master of the newly created group (Research group) available to the system, followed by updating the existing hierarchical structures with the modi cations.This is performed gradually.First the masters of the groups into which DBHC was inserted (Ophthalmology and Renal) are updated.Afterwards, the other masters of federation 3 are updated.Each master is responsible for updating the hierarchical structures of the databases participating in their respective groups.A new database exists for the system (a federation) whenever the masters of its associated groups have information about it.This is possible due to the way that the discovery process is executed.That is, by consulting the master of a related group when other accessed databases do not contain the data.When a new group is created all of the masters in the related federation are updated together.This guarantees the access of the databases in this new group during the discovery process.The hierarchical structures are gradually updated in the same way as explained above.A new group exists in the system when all of the masters in the related federation have information about it.Finally, the Syst-DB and the FED structure related to DBHC are updated.
In the `cancer' situation the DBA concludes that there is no federation in the system suitable to perform the addition of DBHC.However, some databases are identi ed as candidate to compose a new federation with DBHC and share information related to cancer.Federation 4 is created with databases DBHC, DBHB, DBCAN and DBCHI, as presented in gure 14.The initial hierarchical structure of the participating databases and masters is shown in gure 15.Notice that the creation of a federation can also occur when a suitable existing federation is identi ed, but  not all the participating databases in this federation agree with the addition of the new database.The construction of a new federation, either spontaneously or as a result of adding database(s) to the system is executed in a similar way to the setup of the system.That is, a coordinator is elected, the hierarchical structures are constructed, the masters of the di erent groups are speci ed, and the Syst-DB and the FED structures are updated.

Removal
The removal of a database does not mean its deletion from the system, but the elimination of this database from one of the federations in which it participates.Similar to the addition case, the update of the hierarchical structures about the removal of a database or a group of databases is gradually performed.Therefore, it is possible to have incorrect information in the di erent hierarchical structures for a certain period of time.That is, during a discovery process a `non-existent' database may be identi ed as a candidate to contain the requested data.This is acceptable in order to reduce the number of messages in the system and to avoid stopping the whole system to execute the updates.Hence, when a request is sent to a `removed' database, the requester receives a `special noti cation' as a reply denoting the non participation of the database in that federation anymore.The removal of databases from a federation can cause modi cations in the hierarchical structures such as: removal of some groups and terms, generalisation of other terms and combination of other groups.These tasks are executed with the assistance of the coordinator and the tool.Consider the removal of database DBLAB from federation 1.The modi ed part of the hierarchical structure related to federation 1 is presented in gure 16.The Syst-DB and the FED structure of DBLAB are updated.Afterwards, the related masters are noti ed and the hierarchical structures of the other participating databases are updated.
The removal of a federation from the system can occur either because its participating databases do not want to share and exchange data among each other, or because of decremental deletions of its databases, resulting in a federation with only one database.The procedure consists of updating the Syst-DB and the FED structures of the related databases followed by removing the hierarchical structures of the databases associated to the federation.

Implementation Experience and Evaluation
An experimental prototype of our proposal is currently under development.The initial prototype is being used to demonstrate, evaluate and re ne our approach.It is implemented in C++, using Darwin/Regis 9] environment to allow the distributed exchange of data and messages.The tool and methodology to assist with the creation, modi cation and evolution of the hierarchical structures are implemented in Java.
The prototype assists with the system setup, the concurrent execution of the discovery process for various requests, together with the dynamic evolution of the system (addition and removal of databases).We are currently developing the graphical interface that allows the user to execute the query.The prototype is small and simple.However, it demonstrates the feasibility of the approach as an alternative to the problem of interoperating with a large number of databases without using integrated schemas.It shows that it is not di cult to nd and access the databases in the system, even for the components that have recently joined the system.Access to requested data is performed as part of the distributed discovery process.The prototype supports discovery and access to one type of information.It does not deal with data that is partitioned among several databases.Our work has also denoted that the discovery algorithm terminates and the approach supports evolution of the system.
Our experience indicates that it is easier to build the hierarchical structure, determine its terms and specify the di erent options of the graphical interface, than to build an integrated global schema.The construction of a global schema is not a simple task.It has to cope with di culties such as: semantic and syntactic con icts, equivalence and ambiguity of data, and dissimilarities in modelling and viewing aspects of the real world.The use of a global schema does not guarantee the autonomy of the di erent databases and does not allow the dynamic evolution of the system to be executed in a simple way.That is, any modi cation in the system has to be re ected into the global schema causing alterations and reconsideration of many design decisions.We a rm that the de nition of the di erent sets of data shared by a database, the idea of federations, the use of the hierarchical structures together with the terms, and the graphical interface support the preservation of the autonomy of the participating databases.
In the proposed approach the number of transmitted messages during the discovery process of a request is large.However, this number can be reduced as suggested in 20].The large number of messages is related to the fact that the process is executed in parallel, there is no global schema and the dynamic evolution of the system is executed concurrently with system use.We need to perform some simulations to measure the average time necessary to locate data and the average number of messages sent during the process.
The proposed approach requires human assistance in the execution of some tasks, such as: setup of the system, creation and evolution of the hierarchical structures, specication of the graphical interface, de nition of the federation where to perform the discovery process and to add a database, formulation and validation of the request/query.However, when using an integrated schema it is also necessary to have human help during the construction and evolution of the schema.
We decided to use a hierarchical structure to assist with the location of data, due to the fact that such a structure naturally re ects the way that a person tries to search for information, i.e. from general to speci c.In addition, a hierarchy supports the organisation of grouping related objects together.A position in a hierarchy implies some context.The terms composing a path in the hierarchy have more meaning than an end single term.This fact helps to perform the queries that are sent to the remote databases, facilitating the access of the data in these components.A hierarchy supports scalabity and evolution.That is, it allows repetition of information in the structure giving more exibility to nd the databases related to the request.Inside a hierarchy it is possible to have di erent ways of organising its terms.As a result, it is di cult to choose and to decide about the combinations of appropriate keywords.However, in our approach, the decision of the terms is assisted by the schemas and instances of the involved databases, and the interest of the users.We also allow certain level of redundancy in the hierarchy.Another drawback when using a hierarchical structure is related to the limitation of searching.The search depends on the existing terms and on the way (order) that the terms are organised.We address this problem by allowing the user to browse the hierarchical structure of the source component when s/he is executing a request.Therefore, the user can be familiar to the existing terms in the hierarchy and the order that they appear.This strategy also prevents the use of dictionaries, thesaurus and context indices to execute the keyword matching between the user input and the existing terms.In addition, experience indicates that the hierarchical structures have three levels in average, allowing a good performance when traversing the hierarchy.
Apart from the de nition of the terms that compose the hierarchy, another issue in the development of the proposed approach is related to the speci cation of the query that allows the access of the data in remote databases.It is impossible for the user to perform speci c remote queries without knowing about the schemas of the remote databases.The use of the graphical interface is a promising way to solve the problem.However, it is necessary to perform more experiments to validate the approach.One more important and complex issue that will be a topic of future work is related to the access of requested data that is partitioned among several databases.

Related Work
Some approaches have been proposed in the literature to address the information discovery problem for a large number of databases 2, 3,6,10,11,12,14].These approaches present a way of identifying the content of the di erent databases, but do not specify how to access the data after locating the database.In our approach we specify the complete execution of a query (data request, database location and data access).The requested data is accessed as part of the discovery process.In 3,10,11] the authors proposed a framework that allows dynamic education of the users about the available information space.This is executed in a simple way by supporting interaction and identi cation of inter-relationships between databases.Each participating database contains an object-oriented co-database with information about coalitions and services that the database is involved.The inter-node relationships are based on `context abstraction', de ning objects using Global Concepts.The terms used in the hierarchical structures of our approach share some similarities with these Global Concepts.The approach entails high interaction with the user to build the co-databases and execute a search.The search mechanism proposed in 6, 14] performs the location of relevant databases with the help of a meta knowledge-base (MKB).The approach uses natural language to execute the discovery of related databases.This provides a user-friendly interface to the users, but requires some additional structures such as: context and part of speech indices, dictionary and thesaurus.In 12] the approach uses intelligent agents to assist with the discovery process.Each database has an agent that is responsible to receive high-level queries and translate them into a database speci c one.The approach proposed in 2, 15] relies on the use of an external indexing scheme that does not respect the autonomy of the involved databases.The databases are interdependent and changes in one tend to a ect another.

Conclusion and Future Work
In this paper we demonstrate the feasibility of using a distributed information discovery process that supports the sharing and exchange of data between `naive' users, in a number of autonomous hospital databases.Unlike 5,7,8,13], the approach aims to avoid the use of integrated schemas and centralised structures.It also permits dynamic evolution of the system.The process is assisted by dynamic hierarchical structures composed of special terms.This terms are used to identify the databases related to a query.The idea is to limit the discovery process to a group of databases that have either related data or knowledge about other databases that possibly hold the required data.Accessed databases are able to share data with the requester and among each other.The process is recursive, executed in parallel and avoids cycles.
We are currently developing the graphical interface that permits the execution of the queries and allows data access.We are also exploring the idea of expanding the approach to support the execution of queries where the data is partitioned among several databases.Before large scale experimentation and use we plan to execute more tests and compare the proposal with existing approaches.

Figure 1 :
Figure 1: Various databases participating in hospital-A

Figure 10 :
Figure 10: Part of the hierarchy structure of DBHB

Figure 11 :
Figure 11: Part of the hierarchy structure of MG12

Figure 12 :
Figure 12: Graph of the messages sent during the execution

3
as a possible federation to insert DBHC.S/He consults the DBAs of the other databases participating in federation 3 (DBHB, DBOPH, DBTRA, DBC&P and DBR&H) to authorise the insertion of DBHC.Let us assume that the databases in federation 3 agree with the insertion of DBHC.The addition of DBHC causes modi cations in the existing hierarchical structures related to federation 3, by creating a new group and updating existing ones.The modi cation of the hierarchy is assisted by the coordinator, tool and methodology.Figure 13 contains the modi ed part of the hierarchy for federation 3. The next steps consist of setting

Figure 13 :Figure 14 :
Figure 13: Up to date hierarchical structure of federation 3