a mediation architecture

8/2/2019 A Mediation Architecture

http://slidepdf.com/reader/full/a-mediation-architecture 1/12

ORIGINAL PAPER

Integrating Hospital Information Systems in HealthcareInstitutions: A Mediation Architecture

Ikram El Azami &

Mohammed Ouçamah Cherkaoui Malki &

Christian Tahon

Received: 1 June 2011 /Accepted: 19 October 2011# Springer Science+Business Media, LLC 2011

Abstract Many studies have examined the integration of information systems into healthcare institutions, leading toseveral standards in the healthcare domain (CORBAmed:Common Object Request Broker Architecture in Medicine;HL7: Health Level Seven International; DICOM: DigitalImaging and Communications in Medicine; and IHE:Integrating the Healthcare Enterprise). Due to the existenceof a wide diversity of heterogeneous systems, threeessential factors are necessary to fully integrate a system:data, functions and workflow. However, most of the previous studies have dealt with only one or two of thesefactors and this makes the system integration unsatisfactory.In this paper, we propose a flexible, scalable architecturefor Hospital Information Systems (HIS). Our main purposeis to provide a practical solution to insure HIS interoper-ability so that healthcare institutions can communicatewithout being obliged to change their local informationsystems and without altering the tasks of the healthcare professionals. Our architecture is a mediation architecturewith 3 levels: 1) a database level, 2) a middleware level and3) a user interface level. The mediation is based on twocentral components: the Mediator and the Adapter. Usingthe XML format allows us to establish a structured, secured

exchange of healthcare data. The notion of medicalontology is introduced to solve semantic conflicts and tounify the language used for the exchange. Our mediationarchitecture provides an effective, promising model that promotes the integration of hospital information systems that are autonomous, heterogeneous, semantically interoperableand platform-independent.

Keywords Hospital information systems . Interoperability .Mediation . Design patterns . Ontology . XML

Introduction

The access to medical data in healthcare networks is of great importance for mastering the overall patient care process. The fact that hospitals are interconnected throughcommunication networks or the internet makes it easier toexchange medical information and restricts time andlocation constraints [ 1]. In fact, Hospital InformationSystems (HIS) should not be an isolated system, but hasto be integrated into a wider information network, whichraises the problems of information exchanges, the standardsused for these exchanges, access modes, and HIS security, for example [ 2].

The heterogeneity and diversity of hospital computer systems, the variety of stakeholders and activities, as wellas segmentation of healthcare services are important obstacles to designing and developing a homogeneous,shared computer system. These obstacles make the collab-oration between healthcare professionals difficult andcomplicate the establishing of a complete patient care process. Integrating the Hospital Information Systems is

I. El Azami ( * ) : M. O. Cherkaoui MalkiFSDM, Math & Informatics Department,University of Sidi Mohammed Ben Abdellah,BP 1796, Fez, Moroccoe-mail: [email protected]

I. El Azami : C. TahonTEMPO/PSI — Le Mont Houy,University of Valenciennes and Hainaut-Cambrésis,59313 Valenciennes Cedex 9, France

J Med Syst DOI 10.1007/s10916-011-9797-8



very difficult, but necessary. To achieve this goal, a unifiedmethodology — which can consider various aspects, such assystem architecture, information semantics, production processes, and combine different views of the system — must be implemented [ 3]. In this paper, we propose a flexiblearchitecture that allows the integration of several autono-mous, heterogeneous, distributed hospital information sys-tems, with the aim of making them communicate and sharetheir medical data without affecting the local functioning of every system, and insure the three integration factors: data,functions and workflow.

Background

Managing clinical information is a challenge that introducesstrong constraints, and, thus far, no one system has been ableto address the complexity of the overall hospital environment.Healthcare providers typically use technology in a ubiquitousmanner. They choose to rely upon the task-specific capabil-ities of a specific system, rather than the integration of allsystems in the solution space [ 4, 5].Some medical informa-tion systems (e.g., Hospital Information Systems (HIS),Picture Archiving and Communication Systems (PACS),Radiology Information Systems (RIS) and LaboratoryInformation Systems (LIS)) are now used in healthcareinstitutions. However, they are frequently heterogeneous and barely accessible. Data are incomplete, their management is

sometimes inconsistent, and the information workflow isdiscontinuous since the focus of these protocols is on data transfer and not data integration and synchronization [ 4 – 6].Therefore, the medical professionals that we worked withwanted to develop an integrated Hospital InformationSystem that could combine all the heterogeneous systemsand make all the clinical data, clinical reports, laboratoryresults and medical images available whenever and wherever they are needed (Fig. 1).

Many efforts have been made to cover integration of heterogeneous systems in healthcare institutions [ 7, 8, 9, 10].Some of them define standardized interfaces for numerous“ Object Oriented Services ” in the healthcare domain, such asthe Common Object Request Broker Architecture in Medi-cine (CORBAmed), which allows functions (e.g., accesscontrol) to be distributed among different systems. Others —

Health Level Seven (HL7) [ 11, 12], Digital Imaging andCommunication in Medicine (DICOM), and Integrating theHealthcare Enterprise (IHE) — identify guidelines or standardsfor exchanging messages between different systems, whichmake these different systems able to collaborate and thusimplement the workflow integration.

Due to the large variety of heterogeneous systems that are not designed to allow communication, three essentialfactors are necessary to fully integrate a system: data,functions and workflow. However, most of the previousstudies have dealt with only one or two of these factors andthis makes the integration unsatisfactory. It is really difficult

Fig. 1 The architecture

of a Hospital informationsystem

J Med Syst



to set up one data center with all the clinical data using onlymessage exchanges or some common function of thevarious systems. To solve these problems, this article proposes architecture based on mediation. This architecturehelps to fully integrate the heterogeneous information systemsin hospitals.

Methods

Design concept

The mediation architecture that we propose is designed as a modular organization of information systems. This architec-ture allows access to many data sources, which are connected by networks. The mediation is based on two centralcomponents: the mediator and the adapter. The mediator describes, simplifies, reduces and combines the data [ 13].This component is also responsible for processing the data from different sources for end users. The mediator can bespecialized for a variety of data sources or applicationdomains. Several mediators can constitute a hierarchy of modules between user interface level and a large number of data sources. The adapter operates as an intermediary betweenthe databases and mediators. It matches the data format,allowing data to be exchanged between a database and a mediator, and vice versa.

The mediation infrastructure collects knowledge to inte-grate the data into the components used by several applica-tions. Figure 2 presents our architecture, with its three levels:the first level, called the database level, is related to theinformation sources; the second level, called the middleware

level, contains various tools to deal with queries and resolveconflicts; and the third level, called the user interface level, isrelated to users and the customer applications. The architec-ture is modular, which allows the architecture to evolve easilyto integrate new data sources.

The mediators and adapters are the components on thesecond level of our architecture. An adapter is associated toeach database. Each adapter supplies the same access interfacefor each database, and doing so conceals the heterogeneous-ness of the associated databases.

The mediator provides transparent access to different data sources. The architecture may be composed of severalmediators grouped by application domain. The mediator isassociated with a context of application that uses theconcepts and vocabulary of an ontology. Two approachescan be distinguished: the mono-domain approach and themulti-domain approach (Fig. 3). The mono-domain approach is based on a unique set of knowledge (singledomain) to describe the semantics of the information; a mediator is then associated with a single ontology repre-senting the knowledge of the application domain. Themulti-fields based on the distribution of information onareas of different knowledge areas related with each other; a mediator supports ontologies related to the different areas of knowledge and has specific tools to define relations inter-ontologies explaining the rules of mapping between conceptsfrom different areas.

The mediator supplies a unique entry point and a uniformvision for a set of databases; it resolves heterogeneousness problems related to differences in data models and thelanguages used for requests by presenting the data in theformat of the mediation model.

Fig. 2 Our mediationarchitecture

J Med Syst



The customer application submits declarative requests to a mediator so that the users can obtain the data that they ask for.To integrate a new source of information (i.e., database), a special adapter must be developed. This adapter is thenregistered in the mediation model.

When a user submits a request for this database, thedemand is optimized by the mediator and is thenexecuted:

1. A mediator sends sub-requests to the databases throughadapters,

2. Each sub-request sent by a mediator is transformed by

the adapter into a local request in the format of thedatabase,

3. The response from the database is then transformed bythe adapter in the format of the mediator,

4. The mediator collects the results supplied by alldatabases involved in the request, combines them,resolves structural and semantic conflicts, and com- poses the response, which it sends back to the customer application.

As previously noted, the integration of new databasesrequires the development of specific adapters, whosefeatures are precisely defined. In practice, integrating a new component into the system makes it necessary to studythe component ’ s conceptual model, its data structure and itsassociated access rights. This study is needed in order todevelop the appropriate adapter and to supply a uniqueaccess interface to the other systems contained in our architecture. This adapter is responsible for collecting theresults of the queries submitted by users and adapting them

according to the requested formats and structures whilecontrolling the access rights attributed to these users.

In fact, the actual system remains functional. The modulethat serves as interface with outside the hospital is simplyadded. No change is necessary in the information system, inthe hospital organization, or in the tasks of the medical practitioners and system users.

For fast, reliable development of mediators and adapters,we propose reusing Design Patterns published by Gamma [14]. The basic principle of the design pattern concept iscapitalizing on the solution of a recurring problem in a givendomain so as to facilitate the reuse and adaptation of thissolution to solve a new problem [ 15]. In fact, reusing design patterns will reduce costs and implementation times while preserving system quality.

The ontology has a crucial role in the architecture.Medical information science specialists have recognized theneed to have various types of terminologies, whether it isfor analyzing clinical data, for processing natural language,or for decision-making support systems. The ontology usedin our architecture allows the clinical vocabularies and themedical concepts used in organizing care to be unified. Thisontology lists the concepts that applications can share, eventhough they are physically distant and developed ondifferent systems. This semantic interoperability is based onsyntactic interoperability.

For example, in surgical resuscitation, which is themedical domain specialized in the treatment of the post-operative complications, and in traumatology, which is themedical domain specialized in the treatment of injuries, the pathologies and the acts to be taken into account are

Fig. 3 The multi-domainapproach

J Med Syst



diverse, according to the surgery, the kinds of complica-tions or the kinds of injuries. The practitioners use a speciality thesaurus for their compulsory coding activities;this thesaurus was developed so that the recovery stayscould be evaluated as well as possible. However, it is a well-known secret that the thesaurus ’ ambiguity is a sourceof errors and variability for numerous reasons: omissions by the converters, who do not agree with the items proposed, lack of data in the hospitalization report, lengthof stay. An ontology that allows the concepts in the thesaurusto be organized is imperative. Consequently, the ontologyeffectively contributes to reducing the semantic ambiguity of the information exchanged, thus facilitating collaborationamong the healthcare professionals who, in turn, are able to provide better care to patients.

Data exchanges and data security

Data exchanges on the middleware level and on the user interface level are performed using the Extensible MarkupLanguage (XML). Our goal is to structure and standardizethese exchanges [ 16 , 17, 18]. The collected data arestructured in XML format (Fig. 4) by adapters that applya security process using the XML data encoding standard(Xenc) [ 19], which makes it possible to control the users ’

access privileges and to protect the confidentiality of healthcare data.

The integration of data, functions and workflow

Data integration Backing up all the clinical data in onesingle storage structure seems to be a good solution for obtaining an integrated data set. However, due to the largequantities of clinical data and the complexity of unifying allthe data from the heterogeneous systems, this solution is

only effective in small hospitals or newly-built hospitals.The clinical data are distributed and archived in thecorresponding systems. The middleware level saves connec-tion information for each data record in various heterogeneoussystems, thus functioning as a “ virtual data center ” for allclinical data.

Functional integration Hospitals need interoperable infor-mation systems, which must operate seamlessly across a wide variety of institutions (e.g., laboratories, pharmacies, physician practices). These systems have many commonoperations across clinical departments. As a new distributedmiddleware technology, Web service brings an idealsolution to the issue of system interoperability [ 8, 9]. Inour architecture, these common operations can be performedthrough a set of Web services to implement the functionintegration, such as:

Information registry service Through which all medicalinformation systems can register the data to adapters in themediation level wherever and whenever the clinical event happens. The systems must at least register the data-linkageinformation to the “ virtual data center ” while the data record iscreated, deleted or updated.

Order administration service Orders such as prescriptions,radiology inspection requests and laboratory test requests areusually involved in the interoperation among several systemsin a hospital, e.g. the HIS system requests a radiologyinspection; the RIS system receives the order and fills it. AnOrder Administration Service can be developed to facilitatecommunication among PACS, outpatient system, LIS andHIS to specify the interfaces of order entry, order filling andorder management, which facilitate the order related func-tions of systems involved.

Other Web services are expected such as Patient Identifi-cation Service to combine the medical records from multipleinstitutions in order to show a complete picture of a person ’ shealth record, Healthcare Resource Access Control Serviceto address the security concerns and requirements of health-care institutions.

Workflow integration Workflow is a technique used todefine, manage and monitor the different processes (e.g.,information, decision, documents) between individual people and/or departments. It is generally implemented by exploiting the relationship between the data in a client – server model. However, in a distributed environment,such as healthcare institutions, implementation is morecomplicated.Fig. 4 Extract of patient ’ s XML data

J Med Syst



IHE is an initiative designed to promote the integration of information systems in modern healthcare institutions. IHE is based on the current protocols, such as DICOM and HL7,which are already applied in many systems in order toimplement the workflow technique to connect devices,terminals and information systems in a hospital. However, a complete integration is still difficult if there is no framework or model to make it possible for the system to transmit the right message at the right time to the right recipient.

The middleware technologies, such as our mediationarchitecture, can be used to implement the workflow,which considers the environment of distributed databases on the database level as a single database, as inthe client – server model. In addition, our architecture isscalable in the sense that it allows a new system to beintegrated into the existing architecture using the mediators

and the adapters, especially when the database structures areunknown.

Results

Description of the prototype

A prototype of our mediation architecture was developedand tested with two information systems, which weredesigned to have a relevant set of heterogeneities. Eachsystem can extract and send data according to its own data model. Figure 5 (below) shows the architecture that wasused for the simulation.

Our architecture is a 3-level architecture: the database level,the middleware level, and the user interface level. The first level concerns the two HIS and the ontology. Each HIS systemis represented by a database: HIS 1, developed with Oracle 9,and HIS 2, developed with MS SQL SERVER. The ontologywas built with the ontology editor Protégé v3.1.1. Thisontology is used here as common reference for both HIS.The second level contains various tools (i.e., the design patterns of Mediators and Adapters) to treat queries andresolve the problems caused by the systems ’ heterogeneous-ness. Finally, the third level is dedicated to user interfaces. Wedetail each level in the following sections.

Database level

The first HIS was designed in UML (Unified ModelingLanguage). Figure 6 presents the UML class diagram of the

Fig. 5 Prototype architecture

Administrator

Pathology

Physician

Patient 1..*

1..*

1..*

1..*

1..*

1..*

1..*

1..*

1..*

0..*

1..*

0..*

Record

1..*

1..*

1..*

1..*

1

1..*

1

1..*

Nurse

1..*

1..*

1..*

1..*0..*

0..*

0..*

0..*

Fig. 6 UML class diagram of HIS 1

J Med Syst



architecture. It contains six classes: Physician, Administrator,Patient, Record, Pathology and Nurse.

The model of the second HIS was designed in Merise.Figure 7 presents the conceptual model for the second HIS. It contains six concepts: Participant, Act, Address, Record,Patient, and Pathology.

& Participant: a participant is a healthcare professional(or group of professionals) responsible for the content of an act.

& Act: an act encompasses all that has been done, or will be done, by one participant with a specificobjective.

& Address: an address contains patient address information,such as the Street, City, Zip Code and Country.

& Record: a record is the data-entry record of anyinformation related to any act performed by a participant.

& Patient: patient information contains basic informa-tion about a patient, such as name, date of birth andgender.

& Pathology: Pathology can be defined by any item in the patient record describing the patient ’ s health status,which was, or will be, the subject of a participant intervention.

Heterogeneity criteria:

– the models were designed according to two different methods (UML, Merise) and the corresponding data-

bases were built using two different database management systems (Oracle, MS SQL Server), which covers thedesign autonomy criterion.

– the “ Address ” information is represented by an attri- bute in the first HIS and by a table in the second HIS,which covers the data model criterion. This is a simpleconflict.

– the first HIS uses several entities for represent thedifferent types of employees (nurse, doctor, admin-

istrator), while the second HIS defines a singleentity (Participant) to manage all the employees, whichcovers the entity model criterion. This is a conflict of generalization versus specialization.

– the “ Date ” is represented by a date type in the first HIS and by a character string in the second HIS,which covers data type criterion. This is a conflict of type.

In addition, both components in the prototype weredistributed. The data were distributed between bothHIS. Other heterogeneities and conflicts were includedin the prototype to demonstrate the properties of our architecture.

Ontology

Our a im was to use a unified language betweenhealthcare professionals, thus avoiding semantic con-flicts that can arise during the communication and

Fig. 7 Conceptualmodel of HIS 2

J Med Syst



information sharing related to patients or medicalactivities. To do so, we built a medical ontologyaccording to the terminologies of the InternationalClassification of Diseases 10 (ICD10) and ClassificationCommune des Actes Médicaux (CCAM: Common Classi-fication Of Medical Procedures) [ 20 , 21]. We described a set of elementary concepts related to medical acts, pathological signs and medicines. This ontology iscooperatively fed through the mediators of both systems.Figure 8 presents an extract of our medical ontology usingthe Protégé editor.

Middleware level

We developed three mediators: a mediator between theHIS1 component and the ontology, a mediator between theHIS2 component and the ontology and a mediator between both mediators. Each of the first two mediators has a mission to manage the communication between the twoHIS and the ontology and provide knowledge on theconcepts described in the ontology to the third mediator.The third mediator implements services offered by themediation level. When a new concept is produced, the

Fig. 8 Extract of themedical ontology built using Protégé v 3.1.1

Fig. 9 Screenshots of the prototype

J Med Syst



source system must provide a set of descriptions accordingto the standard terminology (e.g., ICD10, SNOMED CT[20]) and update the ontology through its mediator.

The second communication feature that we implementedis between both HIS components. The third mediator wasdeveloped to lighten the operations of the first twomediators, as well as to provide a single interface betweenthe two HIS and the users. This third mediator is the router for cooperation between both mediators and thus between thethree system databases.

This “ mediator of mediators ” is the communicationinterface between the database level and the user interfacelevel. It locates the potential information sources requested by users. The treatment of the queries consists of breakingthem down and transmitting them to adapters. Then, theadapters search for the relevant information in the databasesin their own language, retrieve the results and adapt them tothe format of the user ’ s interface. We developed an adapter for each of the HIS; both adapters have the same interfacewith the mediators. Through the mediators, the adaptersallow the data to be adapted according to the needs of thecustomer ’ s applications. (The functions and the conceptualmodel of the mediators and the adapters are describedin the Appendix ).

User interface level

Developed in Java language, the user interfaces consist of a set of graphic interfaces that allow the user to consult andmodify the system components, as well as the cooperation between them. For the user, this is the guarantee of thetransparency: the user does not need to know the physicallocation of data nor the data structures of the two HISFig. 9.

Discussion and conclusion

Today, the healthcare domain is faced with two crucial problems: the design of Hospital Information Systems(HIS) and the communication between them. The researchand results presented in this paper deal with the second problem. Integrating business solution software imple-mented in hospitals is not easy. First of all, this softwarewas often not designed to communicate. Second, even if they are the object of significant investment from the HealthAuthorities, this investment doesn ’ t always provide theexpected results.

To help to solve the second problem (i.e., the communi-cation between HIS), we proposed a mediation architecture to

integrate multiple heterogeneous, distributed databases. Thisarchitecture is organized into three levels: The database level,the middleware level and the user interface level. It helps tomeet the three integration criteria: 1) data integration bystoring the binding information in each data record in variousheterogeneous systems, thus operating as a “ virtual data center ” for all clinical data; 2) functional integration in theform of a set of web services, and 3) workflow integration byconsidering the environment of distributed databases as a single database in the client – server model.

In addition, for the standardized communication betweendifferent stakeholders in the patient care process, we proposedan exchange model written in the standard XML language.This model consists of a set of data organized in fivecategories: patient data, patient history data, medical activitydata, data requirements and medical records data (e.g., pictures, letters, reports). This exchange model allowsstandardized communication between the components of theinformation systems.

Our architecture provides an infrastructure that allowsthe easy integration of heterogeneous applications in order to insure the exchanges between the individual modulesand provide a consistent, homogeneous management of therelevant information and the procedures for the wholehealthcare institution. First, the individual modules areindividually responsible for their autonomy and constitutethe functional areas. Second, they work through stable public interfaces, and third they can operate in a config-urable, progressive and distributed environment, accordingto the specific requirements and characteristics of eachinstitution.

Consequently, our architecture is scalable and can takeinto account the changes that may appear at the level of databases (e.g., addition/deletion of a system) or at the levelof the system components (e.g., modification of a database). To add a new information system, it is necessary todevelop an adapter to implement this system ’ s features andassociate it to one of mediators in the architecture.Integrating a new system does not affect i ts localfunctioning and does not alter the tasks of healthcare professionals. Developing an adapter is facilitated byreusing design patterns, which provide an effective solutionthat allows costs to be decreased and development andmaintenance deadlines to be reduced, while improvingquality. Finally, the architecture helps to accomplish the fullintegration of heterogeneous systems within the hospital.Our mediation architecture is a promising model, which promotes the integration of autonomous, heterogeneous,semantically interoperable and platform-independent healthcare information systems.

J Med Syst



Appendix

Tables 1 and 2

Table 1 Mediator design pattern

Mediator

Purpose

To simplify communication among objects in a system by introducing a single object that manages message distribution among the other mediators.

ApplicabilityUse a Mediator when:

- there are complex rules for communication among system objects, often as a result of the business model;

- you want to keep the objects simple and manageable; or

- you want the classes for these objects to be redeployable and not depend on the business model of the system.

Description

As communication among objects in an application becomes more complex, managing communication becomes more and more difficult. Handling event processing for a simple spreadsheet control might involve writing code for the grid component. However, if the Graphic User Interface (GUI) is expanded to include a grid, graph, andrecord-display fields, it becomes much more difficult to manage the code. A change in one of the components might trigger changes in some or all of the others.

The Mediator pattern helps solve this problem, since it defines a class that has overall communications responsibilities. This greatly simplifies the other classes in thesystem, since they no longer need to manage communication themselves. The mediator object – the central object to manage communication – plays the role of a system router, centralizing the logic to send and receive messages. Components send messages to the mediator rather than to other system components; likewise, theyrely on the mediator to send change notifications to them.

Implementation

The Mediator class diagram:Figure 10

The Mediator pattern requires:

Mediator The interface that defines the methods that clients can call on a mediator.

ConcreteMediator The class that implements the Mediator interface. This class mediates among several client classes. It contains application-specific informationabout the processes, and the ConcreteMediator might have some hardcoded references to its clients. Based on the information the Mediator receives, it can either invoke specific methods on the clients, or invoke a generic method to inform clients of a change, or a combination of both.

Client The interface that defines the general methods a Mediator can use to inform client instances.

ConcreteClient A class that implements the Client interface and provides an implementation for each of the client methods. The ConcreteClient can keep a reference to a Mediator instance to inform colleague clients of a change (through the Mediator).

J Med Syst



References

1. Jun, C., and Sun, K. Y., Web-based secure access from multiple patient repositories. International Journal of Medical Informatics77:242 – 248, 2008.

2. Action Spécifique 63. Gestion Hospitalière Coopérante, sciences et technique de l ’ information et de la communication, CNRS-Département STIC, Décembre 2003.

3. López, D. M., and Blobel, B., Architectural approaches for HL7-

based health information systems implementation. Methods of Information in Medicine 49(2):196 – 204, 2010.4. Esmahi Larbi, James W. Edwards, Elarbi Badidi. An exploration of

demographic inconsistencies in healthcare information environ-ments. Book chapter, the Encyclopedia of Healthcare InformationSystems, Nilmini Wickramasinghe, (Eds), Idea Group Inc. (IGI), pp.561 – 572, 2008.

5. Wilton C. Levine, Mark Meyer, Philip Brzezinski, Warren S.Sandberg. The Integration of Hospital Information Systems, Peri-operative Information Systems, and Operative Equipment into a Single Information Display. AMIA Annu Symp Proc. 2005;2005: 1054.

6. Larbi, E., and Badidi, E., Managing demographic data inconsistenciesin healthcare information systems. International Journal of Informa-tion Systems and Social Change 1(1):56 – 72, 2010.

7. Diego, M.L., and Bernd, G.M. E. B., A development framework for semantically interoperable health information systems. International

Journal of Medical Informatics 78:83 –

103, 2009.8. Zhang, J. K., Xu, W., and Ewins, D., System interoperability studyfor healthcare information system with web services. Journal of Computer Science 3(7):515 – 522, 2007. ISSN 1549 – 3636.

9. Rainer, A., and Schahram, D., Modeling and implementingmedical Web services. Data & Knowledge Engineering 55:203 –

236, 2005.

Table 2 Adapter design pattern

Adapter

Purpose

To act as an intermediary between two classes, converting the interface of one class so that it can be used with the other.

Applicability

Use an adapter when:

- you want to use an object in an environment that requires an interface that is different from the object ’

s interface;- an interface translation among multiple sources must occur; or

- an object must act as an intermediary for one group of classes, and it is not possible to know which class will be used until runtime.

Description

Sometimes you ’ d like to use a class in a new framework without recoding it to match the new environment. In such cases, you can design an Adaptee class to act as a translator.This class receives calls from the environment and modifies the calls to be compatible with the Adaptee class.

Implementation

The Adapter class diagram:

Figure 11

Implementing the adapter pattern requires the following:

Framework The Framework uses the Adapter. It either constructs the ConcreteAdapter, or it gets the set somewhere else.

Adapter The interface that defines the methods that the Framework uses.

ConcreteAdapter An implementation of the Adapter interface. It keeps a reference to the Adaptee and translates the method calls from the Framework into method using theAdaptee. This translation also possibly involves wrapping or modifying parameters and return types.

Adaptee The interface that defines the methods of the type that will be adapted. This interface allows the specific Adaptee to be dynamically loaded at runtime.

ConcreteAdaptee An implementation of the Adaptee interface. The class that needs to be adapted so that the Framework can use this class.

J Med Syst



10. Anthony Cosimo Frascina. The integration of hospital informationsystems through User Centerd Design. Thesis, Sheffield HallamUniversity. August 1994.

11. HL7: Health Level 7. http://www.hl7.org/implement/standards/ index.cfm (Accessed June 2010).

12. Walter, V. S., Overhage, M. J., Chang, S., Frohlich, J., and Faus, S. A.,The development of a highly constrained health level 7 implementationguide to facilitate electronic laboratory reporting to ambulatoryelectronic health record systems. Journal of the American Medical Informatics Association 16:285 – 290, 2009. doi: 10.1197/jamia.M2610 .

13. Wiederhold G, Genesereth M. The Basis for Mediation, Proceedingsof the third International Conference on Cooperative InformationSystems, p. 140 – 157, May 1995.

14. Gamma, E., Johnson, R., Helm, R., Vlissides, J., Design patterns,elements of reusable object-oriented software, Addison-Wesley, (1995).

15. Rieu, D., Giraudin, J. P., Saint-marcel, C., and Front-conte, A., Des Opérations et des Relations pour les Patrons de Conception .XVIIe Congrès INFORSID, Toulon, 1999.

16. Azami, I. E., Cherkaoui, M. M. O., and Tahon, C., Towards anXML-based normalization for healthcare data exchanges. Journal of Computer Science 6:800 – 807, 2010. doi: 10.3844/jcssp.2010.800.807 .

17. Sukil, K., Peter, J. H., Roberto, A. R., and Inyoung, C., Modelingthe Arden Syntax for medical decisions in XML. International Journal of Medical Informatics 77:650 – 656, 2008.

18. Rakesh, A., and Christopher, J., Securing electronic health recordswithout impeding the flow of information. International Journal of Medical Informatics 76:471 – 479, 2007.

19. W3C: XML Encryption Syntax and Processing, http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/ , (Accessed Mars 2010).

20. Merabti, T., Abdoune, H., Lecrocq, T., Joubert, M., and Darmoni,S. J., Projection des relations SNOMED CT entre les termes dedeux terminologies (CIM10 et SNOMED 3.5). JFIM. Springer, Informatique et Santé 17:79 – 88, 2009.

21. CCAM en ligne, http://www.ameli.fr/accueil-de-la-ccam/index. php (Accessed April 2010).

J Med Syst

http://www.hl7.org/implement/standards/index.cfm


http://dx.doi.org/10.1197/jamia.M2610

http://dx.doi.org/10.3844/jcssp.2010.800.807


http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/


http://www.ameli.fr/accueil-de-la-ccam/index.php








http://dx.doi.org/10.1197/jamia.M2610



a mediation architecture

Documents