An Introduction to VML		Table of contents		Indexes		UIML: An XML Language for Building Device-Independent User Interfaces

Using XML in a generic model of mediators

Yigang Xu

PhD student

Medical Informatics Department Broussais University Hospital
96, rue Didot
Paris 75014 France
Phone: 33-1-43959166
Fax: 33-1-43959209
Email: xu@hbroussais.fr

Biographical notice:

France

Medical Informatics Department

Paris

Sauquet, Dominique

Yigang Xu is now a PhD student in Medical Informatics in the University of Paris VI. She has worked in the Medical Informatics Department of Broussais University Hospital (MID) in Paris since 1996. Her research interests are mainly on the middleware technology, on distributed systems and on data interchange. Her current activities mainly relate to the SynEx project.

Dominique Sauquet

Research Engineer, PhD

Medical Informatics Department Broussais University Hospital
96, rue Didot
Paris 75014 France
Phone: 33-1-43959166
Fax: 33-1-43959209
Email: sauquet@hbroussais.fr

Biographical notice:

France

Medical Informatics Department

Paris

Zapletal, Eric

Dominique Sauquet has been responsible for software development in the MID of Broussais University Hospital for more than 15 years. Her research interests are mainly on the object-oriented approaches, middleware, Web technology, distributed systems and software re-usability. She was the leader of the development of LIED, a temporal database system, and the author of the HELIOS Unification BUS. She has been involved into several European projects: HELIOS, Synapses, SynEx, HANSA.

Eric Zapletal

Research Engineer

Medical Informatics Department Broussais University Hospital
96, rue Didot
Paris 75014 France
Phone: 33-1-43959166
Fax: 33-1-43959209
Email: zapletal@hbroussais.fr

Biographical notice:

Degoulet, Pr. Patrice

France

Medical Informatics Department

Paris

Eric Zapletal worked at the MID of Broussais University Hospital as a software developer in the European projects AIM-HELIOS and ESSI-NOMAD. He was involved in the development of Graphical User Interface tools and of middleware solutions. He is now in charge of the Laboratory, Radiology and Pharmacy Information Systems of the Georges Pompidou University Hospital (Paris).

Pr. Patrice Degoulet

Head of department, MD, PhD

Medical Informatics Department Broussais University Hospital
96, rue Didot
Paris 75014 France
Phone: 33-1-43959166
Fax: 33-1-43959209
Email: degoulet@hbroussais.fr

Biographical notice:

Patrice Degoulet received his M.D. from the Broussais-Hotel-Dieu Hospital in Paris, France in 1977 and his Ph.D. degree from the University of Paris, in 1984. He is actually Professor in Broussais-Hotel-Dieu school of Medicine and the head of the MID of Broussais University Hospital in Paris. His current research interests are conceptual modelling in medicine, data and knowledge base management, hospital information systems and medical record management. He is in charge of the Integration and Communication System of the Georges Pompidou University Hospital (Paris).

ABSTRACT:

This paper presents how XML is used in the context of the SynEx project. In the today's medical informatics domain, numbers of different medical information systems have been developed in different places with different technologies. People now need to share the information distributed among these systems. SynEx is a European project in the medical informatics domain that aims at providing a solution to integrate these legacy medical information systems in an open architecture where medical records from different systems are federated in order to minimize re-developments. This project has great needs for a "glue" mechanism that provides a flexible way to bring the legacy systems together on the platform and to facilitate the communication between any pair of application components. This mechanism can be modelled as different "mediators" for the different connections.

In the SynEx project, the Medical Informatics Department of the Broussais University Hospital in Paris has the responsibility of the development of theMediator Service . This component proposes a generic model of mediators to be used to create specific mediators by specialisation. A specific mediator manages the structural, syntactic and semantic heterogeneity of the systems that it connects. Our approach integrates the XML technology as a powerful data interchange format and as an efficient data structure converter. It then attempts to prove that XML is a powerful mean to solve structural and syntactic problems.

This paper describes the modelling and implementation aspects of our study and shows how XML has enhanced the flexibility of the Mediator Service.

Distributed Information Systems
Integration
Legacy Systems
Mediator

Middleware

interoperability

Introduction

In the today's medical informatics domain, numerous medical information systems have been developed in different places with heterogeneous technologies. To improve the patients' healthcare, the co-operation among different medical information applications is required. These applications need to connect to an increasing number of information resources, which are hosted by different data management systems on different sites, and need to exchange and share those resources. Rather than the heavy and complex re-developments, the integration of such systems into an open architecture is proposed. This architecture provides the end-users with the ability to access the required information transparently independently of its nature or localisation. The SynEx project intends to bring a standard and flexible way to realise an integration platform with several application components which integrates different legacy medical systems, federates electronic healthcare records and provides services.

However, integrating distributed legacy applications is always a challenge. These applications, which either manage data or knowledge, are developed in different places and with different technologies. They can rely on file systems, databases, object stores, electronic mail systems... Some are only close systems without API (Application Programming Interface) . They use multiple operating systems, different types of inter-process communication mechanisms or different communication protocols. Different paradigms of exchange co-exist: one represented by the family of Objects Brokers, such as CORBA, coming from the RPC technology, another one where the exchange is achieved through messages with a possible set of standards (e.g. HL7, ASN.1, ASTM, DICOM, UN/EDIFACT, etc.).

Moreover, the information used by these distributed systems are represented differently:

They can be non coded or coded in different ways (e.g. The "sex" can be coded in one system as "Male : 1" and "Female : 2" but in another system as "Male : M" and "Female : F").
They might be represented by different data structures and the granularity of data can also be different.

They can reference different dictionaries. Multiple nomenclatures or classifications coexist in Health Information Systems (e.g. ICD9-CM, ICD10, Mesh, SNOMED International, UMLS, etc.) and none of these classifications is able to capture all the concepts in a living health institution .

The problem facing the distributed health information systems developers is not only based on the syntactic heterogeneity but also concerns the difficulty of semantics integration. Different levels of mismatches must then be considered. They concern: data model and structural conflicts, descriptive conflicts, semantic conflicts. It is why, to ease the construction of the SynEx integration platform, a mechanism which manages the various connections and exchanges of information, taking heterogeneity into account, is greatly required.

Previous projects include HELIOS with its the "Medical Connection Services" , and TSIMMIS with its "Wrapper" have done a lot of effort in this area. Now we propose the Mediator Service Component to offer a flexible and extensible solution for these problems by taking into account the syntactic and semantic aspects of an exchange. It uses a generic model of mediators to create, through specialisation, specific mediators for practical uses. XML has been applied to enhance the genericity of the basic model and to facilitate the specialisation from this model.

This paper introduces first the background of our work on the Mediator Service Component. After a summary of the design and development strategy of this component, it presents how the emerging XML technology has been applied to enhance the flexibility and the genericity of this component. At the end of this paper, the major positive and negative points of this work are discussed. Several improvements are envisaged as well.

Background

Both in hospitals and in primary care, healthcare information is electronically collected within distributed sites and patient care involves the sharing of responsibility between professionals working in different departments and sometimes even on different sites. Many projects have developed software systems for electronic patient records. However, they cannot be easily integrated to provide the physician a federated and shared view of the distributed health records.

The SynEx project addresses issues inherent to multimedia patient records distributed across large enterprise-wide networks. It brings together the knowledge and use of appropriate technologies from GALEN (terminology server) , , I4C (integrated platform for cardiology) , the Synapses Federated Healthcare Record server or FHCR , and TeleNurse for nursing care. It is conformant to the CEN/TC 251 European pre-standards prENV12967-1 or HISA (Healthcare Information System Architecture) and to prENV 12265 or Healthcare Record Architecture. The basic SynEx integration platform is represented by the DHE (Distributed Healthcare Environment) , a middleware implementation of HISA . Complex services, such as the FHCR module or the Mediator Service, complements this platform. Finally, SynEx aims to provide access to Hospital Information Services, to remote sources of medical data and to medical knowledge, in a seamless way, hiding the distribution aspects and the heterogeneity of systems.

To bring the interoperability among all the components and medical information systems, the SynEx integration platform implies great needs for communication services . The Mediator Service is an application component of the integration platform which offers these services and aims to manage the various connections and exchanges of information in a flexible and extensible manner.

The "Mediator Service" component

The Mediator Service Component is a software component considered as the "glue" to integrate the various legacy systems and to hide their heterogeneity. It has been designed to connect any pair of systems (aSource and aTarget ) systems with different data structures such as legacy systems, application components, client systems, ...

This service provides a methodology in order to ease the development of specific mediators for different connections, to reduce the development cost and to foster re-use. Then the Mediator Service implements a generic model that can be specialised, thanks to the Object Oriented paradigm, to create specific mediators for practical cases (i.e. a mediator adapted to a given Source and a given Target). It consists in:

a generic model of mediator
a C++ library to be used as "the tool case" by the programmers
several ready-to-use specialisations for well defined use cases to simplify the development process.

The generic model

The general model of exchange between two systems

As shown on FigureXU-005 , the main functions of aMediator are:

to get "any kind" of information (messages, responses to a SQL query, objects, etc...) from aSource Application by the means ofa (Source) Interface ;
to filter the information (keeping only what is useful for theTarget Application ), model it as anExchange ;
to pass theExchange to aTarget Application by the means of a(Target)Interface which uses the communication API of theTarget .

The model of a generic mediator should be applied to different application contexts. From a programmer's point of view, the main task should be to develop two interfaces: theSource Interface and theTarget Interface . A Source Interface can be used for different Target systems and symmetrically a Target Interface will be easily connected with various Source applications. The development of an interface is done by specialising the abstract class ApplicationInterface in the C++ library of the Mediator Service. The object oriented approach allows this model to be generic and easily extended.

FigureXU-006 illustrates a Mediator from an implementation point of view.

The implementation view of the generic model of the mediator

TheSource Interface andTarget Interface take in charge the communication protocols with both the Source and Target systems. It is up to the Source Interface to decode the coded information (by associating a specific decode process) if the Source information is a coded message and to obtain the data structure, the concepts and the data of the Source system. The Target Interface may need to restructure the adapted information in a way comprehensive for the Target.

To manage syntactic and semantic heterogeneity between Source and Target representations of information, aMapping process which changes the Source information into a Target compliant one (data structure, concepts, data format) is necessary.Intermediate Representation andAdapter are used to realise this. TheIntermediate Representation models the information exchanged between a Source and a Target system as a flattened list of Attribute-Values.Adapters , which contain aMapper (for concepts and data structures) and aConverter (for data formats), are used to transform information from a Source Representation into the Intermediate Representation and then from the Intermediate Representation into a Target Representation. This transformation of representation concerns:

Concepts (e.g. "WEIGHT" and "POIDS" may refer to the same concept into two systems)
Data structures (e.g. There are many valid ways to represent data structures for a medical prescription)
Data formats (e.g. The date format can be "DD-MM-YYYY" or "YYYY-MM-DD" or "MM-DD-YYYY").

So, a piece of information, when received by a mediator, is first decoded in theSource Interface , then adapted by theAdapter integrated in the Source Interface into anIntermediate Representation with intermediate concepts, structures and data formats. The information contained in the Intermediate Representation is then managed by the Target Interface; it is adapted by theAdapter integrated in the Target Interface into the Target representation; finally, theTarget Interface sends the adapted information to the Target system.

The specialisation of the generic model may cause quite a lot of work for a programmer who must specialise both the Source and Target interfaces. We now show how XML technology can sensibly reduce the work, by making the restructuring process in the Target Interface independent of the Target system.

The XML solution to enhance the flexibility of the "Mediator Service"

Our ambition is to provide a generic Mediator model which reaches the maximum independence and which will minimize development. The starting point of this evolution is the improvement of the Target Interface. The emerging technology of XML is applied to find out a possible way.

XML has been used today not only as a document structure format, but in a wider communication domain as an interchange format and as a powerful data structure descriptor to ease the conversion between data structures of different systems.

In the Mediator Service, a specialised Target Interface using the XML technology is ready to use for any XML compliant Target system. A class XMLInterface, derived from the class ApplicationInterface, is provided. An XML Messages Generator is integrated in this interface (FigureXU-008 ). It is an independent Java module based on the Microsoft msxml parser . The generator contains methods to inform the mediator about the data structure descriptions of the Target systems. It is done through a XML DTD (D ocumentT ypeD efinition ) which is external to the program, making the mediator independent of the target system. So when the target system is XML compliant, the programmer can use directly the XMLInterface as aTarget Interface and has only to implement aSource Interface .

The XML Messages Generator

The XML Messages Generator requires 3 inputs:

TheIntermediate Representation containing the exchange: the data from the Source system.

ADTD representing the structure of the data model of the Target system. The DTD allows to separate the structure of data from the data themselves. Once the data model of the Target system is generated, it can be translated into an XML DTD by the Target. It is stored outside the program and used by the Mediator at run-time.

TheMapping Information used to find out the semantic correspondence. These information are stored in a database. In the current version the description is done manually during configuration. They are retrieved and used by the Messages Generator at run-time.

When theIntermediate Representation is passed to the XMLInterface, theXML Messages Generator analyses the DTD, generates an image of the data model of the Target system. It then fills this image with the data represented in theIntermediate Representation by using theMapping Information . Finally, the result, that contains the Source data with the Target concepts restructured in the Target data structure, is transformed into an XML message. The XML message can then be sent to the Target system by simply using the HTTP protocol. Since XML is self-descriptive, an XML compliant Target system can easily construct its data instances by using the information contained in the message.

Thus the Mediator Service becomes more generic and independent of the XML compliant Target systems. It then can be considered as an "Intelligent and Configurable Interface" between two connected systems.

Example

We illustrate here the benefits of XML in the Mediator Service by the following example. TheSource system is a patient identity server which delivers EDIFACT messages into X400 mailboxes. The Source interface specialisation encapsulates the X400- API and the decoding functions. TheTarget system is a Synapses FHCR server, module of SynEx, which implements an object model, compatible with the PrEnv 12265, in order to federate the different sources of data coming from legacy systems such as the ID server. A XML compliant version of the Target has been prototyped in Broussais in order to create the relevant objects at the reception of an XML message. Then, in our mediator, the Target interface is the ready-to-use XML specialisation: the class XMLInterface.

Starting from the following EDIFACT message, coming from the ID server:

An EDIFACT message from the Source system

The Mediator uses (1) theIntermediate Representation which is the output of the Source Interface after the EDIFACT decode process, (2) theDTD (SynOM.dtd), which is an image of the Target data model (RecordFolder ,FolderRic ,ComRic ,RecordItem , ... are the Complex and Simple elements of the model):

The DTD containing the data structure of the Target system

and (3) theMapping information , stored in a relational database, where concepts of the Source are mapped to concepts of the Target.

The output of the Mediator is the following XML message which restructures the Source data by the Target structure:

An XML message generated by the mediator

This message has triggered the creation of the relevant objects in the FHCR server.

Conclusion and perspectives

The Mediator Service is the component on the SynEx integration platform which takes in charge the various connections among different systems. It does not prevent a developer from writing code, but it provides a methodology to ease software development and to foster re-use.

For a federating model such as the FHCR for which a specific Application Interface exists, the Mediator technique allows to integrate many different legacy systems without knowing in advance their API s. The FHCR server will not change when a new source of data has to be integrated.

In the current implementation of the mediator, the XML approach is applied as a technology that could enhanced the flexibility and genericity of the Mediator Service component and shorten the development process. For XML compliant Target systems the ready-to-use specialisation is available.

By using XML technology, the syntactic and structural conflicts during integration of distributed systems has been efficiently managed. In the Mediator Service, XML DTDs are used as descriptors and convertors of data structures. Using them to represent data models of different systems provides a way to understand the data structure of a system without coding it in the program and thus allows to build a more generic Mediator model. XML is also proposed in the Mediator Service as an EDI format, using the possibility to represent both data structure and data. This capacity has been exploited as much as possible to easily address XML compliant Target systems. In the Mediator Service, mapping and conversion processes are used to manage the semantic mismatches. Although the semantic problem is not resolved ideally in the current version, the mediator separates it from the syntactic aspects (coding and decoding process) to ease a later integration of other technologies to improve semantic management. DTD and Mapping information are external to the Mediator and then addressing a new Target system can be done without changing the code or even without recompiling the mediators.

However, the limitations of the current implementation of the Mediator Service should be pointed out. The structures of the Intermediate Representation (a list of attribute - value) and of the mapping information are not enough efficient or flexible and may not be suitable for more complex cases. The semantic conflict has not been solved efficiently in the current version of the Mediator Service. It is treated by using several mapping and conversion processes. The "manual" creation of the mapping information may be a painful process.

Perspectives of development have been planned and the possible improvements in the near future are considered. To improve the semantic management, we need to find out if the combination of the XML mechanism and of other terminology services provides a better solution. A semantic network or a generic terminology server such as GALEN could be a possible choice. The structure of the Intermediate Representation could be improved by adopting the OEM (Object Exchange Model) of the TSIMMIS project or the meta-model used in the Medical Connection Service of the HELIOS project. Some useful tools such as audit trail and monitoring tools, automation tools, ... are required. Finally, A Java version of the Mediator Service would be useful to ease the connection of Java based components.

Acknowledgments

The authors would like to thank all the members of the SynEx Consortium for their contribution to this research. The financial support of the European Commission is also gratefully acknowledged.

Bibliography

1: Kalra D (ed). Synapses Federated Healthcare Record Server-Object Model and Object Dictionary version2. London: University College, December 1996.
2: Lavril M, Dor� L, Zapletal E, Jean FC, Degoulet P, A Reuse Oriented Development Database: The HELIOS Object Information System, Comput Methods Programs Biomed. 1994; 45, Suppl.: S35-S45.
3: Papakonstantinou Y, Garcia-Molina H, Object Exchange Across Heterogeneous Information Sources, in : Proc Data Engineering Conference, Taipei, Taiwan, March, 1995.
4: Jean FC, Engelmann U, Sauquet D, Lavril M, Schr�ter A, Degoulet P, The HELIOS Medical Connection Services, Comput. Methods Programs Biomed. 1994; 45, Suppl.: S117-S126.
5: Jean FC, Mascart JJ, Codaccioni A, Lavril M, Sauquet D, Degoulet P, Using a meta-model to build a Connection Service in an object oriented medical application development environment, Proc Annu Symp Comput Appl Med Care. 1994: 483-487.
6: http://www.cs.man.ac.uk/mig/galen
7: http://www.cs.man.ac.uk/mig/giu/
8: Ferrara FM. The middleware-based architectural approach for opening and evolving healthcare information systems. Medical Informatics Europe '96. IOS Press, 1996: 264-270.
9: Graeber S, Communication services for a distributed hospital information system. Meth Inform Med 1996; 35: 230-241.
10: Degoulet P, Sauquet S, Jaulent MC, Zapletal E, Lavril M, Rational and Design Considerations for a Semantic Mediator in Health Information Systems, Meth Inform Med. 1998; 37: 518-526.
11: http://www.microsoft.com/workshop/xml/


An Introduction to VML		Table of contents		Indexes		UIML: An XML Language for Building Device-Independent User Interfaces